SC-28 Protection of Information at Rest (M) (H)

NIST 800-53 (r4) Control:

The information system protects the [FedRAMP Selection: (M)(H) confidentiality AND integrity] of [Assignment: organization-defined information at rest].

SC-28 Additional FedRAMP Requirements and Guidance:

Guidance: The organization supports the capability to use cryptographic mechanisms to protect information at rest.

NIST 800-53 (r4) Supplemental Guidance:

This control addresses the confidentiality and integrity of information at rest and covers user information and system information. Information at rest refers to the state of information when it is located on storage devices as specific components of information systems. System-related information requiring protection includes, for example, configurations or rule sets for firewalls, gateways, intrusion detection/prevention systems, filtering routers, and authenticator content. Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing Write-Once-Read-Many (WORM) technologies. Organizations may also employ other security controls including, for example, secure off-line storage in lieu of online storage when adequate protection of information at rest cannot otherwise be achieved and/or continuous monitoring to identify malicious code at rest. Related controls: AC-3, AC-6, CA-7, CM-3, CM-5, CM-6, PE-3, SC-8, SC-13, SI-3, SI-7.

NIST 800-53 (r5) Discussion:

Information at rest refers to the state of information when it is not in process or in transit and is located on system components. Such components include internal or external hard disk drives, storage area network devices, or databases. However, the focus of protecting information at rest is not on the type of storage device or frequency of access but rather on the state of the information. Information at rest addresses the confidentiality and integrity of information and covers user information and system information. System-related information that requires protection includes configurations or rule sets for firewalls, intrusion detection and prevention systems, filtering routers, and authentication information. Organizations may employ different mechanisms to achieve confidentiality and integrity protections, including the use of cryptographic mechanisms and file share scanning. Integrity protection can be achieved, for example, by implementing write-once-read-many (WORM) technologies. When adequate protection of information at rest cannot otherwise be achieved, organizations may employ other controls, including frequent scanning to identify malicious code at rest and secure offline storage in lieu of online storage.

38North Guidance:

Meets Minimum Requirement:

• Ensure FIPS 140-2 validated cryptographic algorithms and modules are used for all cryptographic use cases involving federal data/metadata at rest. FIPS 140-2 Compliant is not sufficient. FIPS Validation means a product has undergone and passed detailed conformance testing at an accredited national laboratory. FIPS Compliance means that different components of a product have received FIPS validation, but the product in its entirety has not passed testing or has not been tested at all.

• Identify all non-validated cryptographic modules in use.

• Full Disk Encryption (FDE) should suffice for FedRAMP. However, customers may have organizationally-defined requirements for application-level encryption.

Best Practice:

• Best practices suggest that whenever technically and financially feasible, CSP's should encrypt all data in their system using FIPS 140-2 validated cryptographic modules. In addition to FDE, CSPs should utilize encryption at the following levels of the technology stack: File/Volume/Object; Database; Application.

• Utilize Transparent Data Encryption (TDE) for databases.

• Encrypt Amazon EC2 Instance Stores (Amazon EC2 Instance Store).

• Utilize cloud-native solutions for encryption and key management.

Unofficial FedRAMP Guidance:

• Although FIPS 140-2 validated encryption is the preferred choice for protecting the confidentiality and integrity of data at rest, CSPs can also: restrict the number of users who can access/modify the data; implement versioning, utilize data integrity checks (e.g., MAC/HMAC, Digital Signatures, Authenticated Encryption), create data backups, replicate data (active/standby configurations)/backups to different geographic locations (e.g., multiple Availability Zones and/or Regions in the case of AWS).

• Use of non-FIPS 140-2 validated cryptographic modules is a SHOWSTOPPER.

Assessment Evidence:

• Screenshots of configuration settings for storage devices (e.g., file, block volume, object, database, cache, container, etc.) showing that encryption is enabled.

• List of Cryptographic Module Validation Program (CMVP) Certificate Numbers for all employed FIPS 140-2 validated modules. (Cryptographic Module Validation Program | CSRC).

• Screenshots of configuration settings for Operating Systems and applications showing that FIPS mode is enabled.

• Role-Based Access Control (RBAC) schema for data at rest storage devices.

• Sample manifest with a list of computed hash values for each file, object, etc..

• Screenshots showing backup creation and location.

CSP Implementation Tips - Data at Rest Encryption:

• Amazon Web Services (AWS):

  1. Useful Link:

     • Amazon EFS

     • Amazon S3

     • Amazon EBS

     • Amazon RDS

     • Amazon ECR

     • Amazon EC2 Instance Store

     • AWS CloudTrail

     • Amazon EKS

  2. EKS customers who use EC2 can configure encryption for the EBS volumes used by their EC2 instances. Customers choosing to mount storage services to their container or EC2 instance are responsible for ensuring the storage is configured for encryption of data at rest.

Customers who use EKS/Fargate platform version 1.4 or later get encryption at rest for the ephemeral task storage by default, no configuration required.

The control plane data in the EKS service account is stored in an encrypted AWS-managed database. Customers cannot configure this database, which serves the backend of the Kubernetes cluster.  

• Microsoft Azure:

• Google Cloud Platform: