FedRAMP encryption requirements for data transmission are specific. FedRAMP requires FIPS 140-2 validated cryptography for all transmissions that cross the boundary and for all transmissions inside the boundary that involve Federal data or sensitive metadata. In contrast, FedRAMP does not mandate specifically what types of data require encryption at rest. For controls SC-28 and SC-28(1), the type of information that is encrypted at rest is determined by an organizationally defined parameter. This means that CSPs have discretion to define exactly what types of data at rest are encrypted.
Passwords at rest must be cryptographically protected in accordance with IA-5(1) and FedRAMP will require that all sensitive data be encrypted at rest, but otherwise, CSPs in coordination with their Agencies have flexibility in terms of defining what data is encrypted at rest. However, there are some constraints on that flexibility. The CSP has to identify some data that will be encrypted at rest, and as mentioned, “sensitive data” at a minimum must be encrypted. Choosing to encrypt nothing at all is not a feasible option. The expectations of customer agencies for protecting data at rest need to be addressed. Though FedRAMP doesn’t define one-size-fits-all requirements, the CSP’s agency customers will have requirements that are tailored to the particular risk profile of the system and its data. CSPs should assume, for example, that any sensitive data that is stored within the system will require encryption at rest. CSPs should give careful thought to determine what types of data warrant encryption at rest. The FedRAMP PMO may question the CSP about any data that is not encrypted at rest, so CSPs should be prepared to explain and justify any data that is stored within the boundary in clear text. Simply asserting to the PMO that data is not sensitive is unlikely to persuade the PMO. A specific risk-based justification may be required.
The SSP must clearly describe the data (or data stores) that are encrypted at rest so that constituencies like agencies customers and the FedRAMP PMO have full visibility into the cloud system’s encryption practices. CSPs must also depict on their data flow diagram each data store within the boundary and note each store’s encryption status and whether it is leveraging FIPS 140-2 validated modules.
Encryption of data at rest can be performed at different layers of the system: the storage layer, the database layer, or the application layer. There are no specific FedRAMP requirements about how or where in the stack encryption should be implemented. However, CSPs are advised to think through the threats that encryption is intended to protect against. When PII or otherwise very sensitive data is stored in the system, encryption may be intended to protect that data from access by system administrators. In those situations, encryption at the storage or database layer may not be sufficient since data is often automatically decrypted by administrative users. Instead, data may need to be encrypted at the application layer using tenant-specific keys before it is stored to ensure that system admins and DBAs can’t access the protected information. Or, segregation of duties and access controls may need to be applied to encryption keys to prevent administrative users from being able to decrypt PII. In the absence of PII or similar highly sensitive data, there may not be a need to perform encryption at the application layer. Instead, encryption at the database or storage layer is often used to provide encryption of data because it is simpler to configure and validate. When a SaaS provider uses FedRAMP authorized IaaS or PaaS offerings like AWS, leveraging built-in encryption at rest features for RDS, S3, or EBS volumes is highly recommended as a straightforward means of meeting FedRAMP requirements. Using these services makes it possible to encrypt all data stores across the board and eliminate any question about whether all data that warrants encryption has been encrypted.
Although SC-28 and SC-28(1) give the CSP discretion to define the type of information to be encrypted to rest, the control and enhancement requirements clarify that data protection must address both confidentiality and integrity. Protecting confidentiality is straightforward, but it may not always be obvious how to prevent unauthorized modification of data to ensure integrity. In some cases, other controls may need to supplement encryption to provide integrity to data at rest. For example, it may be appropriate to maintain some off-line storage to help protect data in case it is re-encrypted with a secret key by ransomware or otherwise corrupted by malware.
Furthermore, all uses of cryptography in FedRAMP, including encryption of data at rest, must follow appropriate key generation and management practices (SC-12) and use only FIPS validated cryptography (SC-13). Refer to SecureIT’s FedRAMP Tech Bulletin on FIPS 140-2 Validation for more information.