Let’s break down the relationship between FIPS and FedRAMP, specifically FIPS 140-2/3. Anyone who provides support to Cloud Service Providers (CSP) in their FedRAMP authorization journey, whether a direct employee of a CSP, in an advisory role, or as an assessor, is aware of the challenges brought about by FedRAMP’s FIPS 140-2/3 requirements. Those challenges have been, at times, the bane of many system administrators’ and developers’ existence.
As we dive deeper into the FIPS and FedRAMP relationship, let’s take a closer look at the SC-13 security control from a FedRAMP perspective. Understanding the SC-13 security control may not be an easy task but may be even more challenging looking at it from a FedRAMP perspective, with the additional FedRAMP-Defined Assignment / Selection Parameters and Additional FedRAMP Requirements and Guidance within the FedRAMP baselines.
It is important to note that SC-13 is technical in nature, in that it requires CSPs to implement FIPS 140-2/3 validated (not compliant; we’ll discuss this later in this article) or NSA-approved cryptographic modules, but also requires CSPs to define, identify, and document all those areas where cryptographic functions take place within their Cloud Service Offerings (CSO). There may be many different cryptographic uses and mechanisms within a single CSO, making this a sizeable challenge for CSPs.
For our discussion here, we will focus specifically on FIPS-validated cryptography and not NSA-approved cryptography. Not to take anything away from NSA-approved cryptography, but FIPS is more prevalent with CSPs providing services to federal agencies through their CSOs.
When dealing with encryption through the lens of FedRAMP, it is safe to consider the SC-13 security control as the parent of all cryptographic-related security controls within the FedRAMP baselines. Although SC-13 does not speak specifically to cryptographic use-cases such as Data-At-Rest (DAT) or Data-In-Transit (DIT), it throws the proverbial blanket on all use-cases within a Cloud Service Offering’s (CSO) authorization boundary, requiring organizations to apply FIPS 140-2/3 validated cryptography everywhere cryptography is implemented.
At a minimum, the FedRAMP baseline security controls that are impacted or augmented by the SC-13 requirements are as follows: AU-9 (3), CP-9 (8), IA-2 (6), IA-5 (1), MP-5, SC-8 (1), and SC-28 (1). It is important to mention that SC-13 is not specific to encryption only, but also to other cryptographic functions such as hashing, random number generation, and key generation.
As we dive deeper into the FIPS and FedRAMP relationship, let’s take a closer look at the SC-13 security control from a FedRAMP perspective.
Control Statement
a. Determine the [Assignment: organization-defined cryptographic uses]; and
b. Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use].
The above SC-13 security control language states that organizations (CSPs as far as FedRAMP is concerned) can define and select the uses of cryptography within their CSOs, as mentioned in part a of the security control.
FedRAMP, however, points out many other security controls within the FedRAMP baselines to otherwise define these areas of encryption. It is important to apply the SC-13 security control in conjunction with other FedRAMP-required security controls. As previously mentioned, those controls at a minimum, are AU-9 (3), CP-9 (8), IA-2(6), IA-5(1), MP-5, SC-8 (1), and SC-28 (1).
Part b of the SC-13 security control description states that organizations (again, CSPs in this case) may determine for themselves and implement the types of cryptography for each use case, but again, we must look further into the FedRAMP requirements and parameters. In this case, FedRAMP defines the types of cryptography to be used as FIPS-validated or NSA-approved cryptography, meaning that in all cases where a CSP applies cryptography within their information system, FIPS-validated or NSA-approved cryptography is required.
The FedRAMP Readiness Assessment Report (RAR) breaks down the SC-13 security control and its FIPS requirement in four (4) primary usage areas where FIPS 140-2/3 validated cryptographic modules must be implemented. In addition, the FedRAMP Requirements and Guidance tacks hashing, random number and key generation onto the list:
- Data at Rest
- Data in Transit
- Remote Access
- Authentication
- Hashing/random number and key generation
Each of the above-mentioned SC-13 security control areas can be traced back to other security controls within NIST SP 800-53 and it is these controls that require the specific area of encryption to be implemented. The SC-13 security control is simply the driving factor for the FIPS 140-2/3 and NSA encryption requirement for each of those areas of encryption.
To expand upon the SC-13 security control and the subject of the FIPS 140-2/3 requirement, another authoritative element to point out is the FIPS 140-2/3 federal mandate found in Table 4-1 in both the FedRAMP High RAR and FedRAMP Moderate RAR. This federal mandate leaves little to no leeway on the FIPS 140-2/3 requirement and must be met as part of an organization’s overall security implementations to obtain an Authority to Operate (ATO) for their CSO. This federal mandate is provided in question format (Are FIPS 140-Validated cryptographic modules consistently used where cryptography is required?) and requires a 3PAO to validate the implementation of this requirement during assessment. The implementation of FIPS 140-2/3 validated cryptography must be fully and strictly met in all areas of encryption (data at rest, data in transit, remote access, authentication, and hashing/random number and key generation), to be considered met, according the FedRAMP High and Moderate RARs.
Note: With the release of the FedRAMP Rev 5 baselines, FedRAMP allows for some leniency regarding the use of FIPS-validated or NSA-approved cryptography, but only in certain circumstances as stated in the ‘Additional FedRAMP Requirements and Guidance.
- The current FIPS-validated version(s) in use has a known vulnerability.
- A feature with a vulnerability is in use within the information system.
- A non FIPS-validated version fixes the vulnerability, and the non FIPS-validated version is submitted to NIST for review and pending FIPS validation.
- The CSPs POA&M is updated to reflect, and track status of the cryptographic module and its FIPS validation approval.
CSPs must ensure that all cryptographic modules implemented to support the CSO, are documented and tracked within Appendix Q of the FedRAMP Rev. 5 SSP template(s). It is important to note that with the most recent update of NIST SP 800-56A Rev 3, the FedRAMP PMO now deems many FIPS 140-2 validated cryptographic modules historical. CSPs must document and track any historical cryptographic modules within their POA&Ms. Historical cryptographic modules must be slated for replacement with a plan in place on how and when to do so. For further guidance on how CSPs must address historical cryptographic modules please see the FedRAMP PMO’s blog post at the following link: https://www.fedramp.gov/blog/2022-12-22-crypto-modules-historical-status/
Now that we’ve addressed the SC-13 control, areas within a CSO where encryption must be implemented, the FIPS federal mandate within the FedRAMP High and Moderate RARs, and historical FIPS modules, let’s revisit our comment earlier in this article regarding the difference between “compliant” and “validated” when talking FIPS 140-2/3 cryptography. It’s easy to assume that these terms are synonymous; however, looking deeper into the meaning of each tells us differently.
FIPS 140-2/3 compliant simply means that only certain aspects of a module have been tested and approved to meet FIPS standards, but not the entire module. An example of this is a module’s use of FIPS-approved security functions and cypher suites, such as AES-256, SHA-256, etc., but the module itself has not undergone testing through the NIST Cryptographic Module Validation Program (CMVP).
On the other hand, FIPS 140-2/3 validated means that the entire module has been tested and validated through the NIST CMVP. It is the latter FIPS 140-2/3 validated state that FedRAMP requires CSPs to implement within their CSOs. It is important to note that NIST considers non-FIPS validated cryptography to be in plain text, as stated on the https://csrc.nist.gov/projects/cryptographic-module-validation-program website: “Non-validated cryptography is viewed by NIST as providing no protection to the information or data—in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 or FIPS 140-3 is applicable. In essence, if cryptography is required, then it must be validated.”
FedRAMP holds this same view and considers non-FIPS validated cryptography untrusted and therefore, not to be utilized for the protection of data within an information system.
Contact us today to book a conversation with one of our experts to see how 38North can help you achieve your business goals.
References:
https://csrc.nist.gov/projects/cryptographic-module-validation-program
https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402annexa.pdf
https://csrc.nist.gov/projects/cryptographic-module-validation-program
https://www.fedramp.gov/blog/2022-12-22-crypto-modules-historical-status/
