Navigating FedRAMP’s Security Requirements for Containers

As a Third Party Assessment Organization (3PAO), Schellman has been performing FedRAMP security assessments for Cloud Service Providers (CSPs) since 2014. During this time, we have seen our CSP clients pioneer technologies that provide federal agencies an opportunity to leverage new and innovative cloud services, all while modernizing their approach to building, deploying, and managing applications through containerization. Though this gradual shift to containerizing system components has increased CSPs’ operational efficiency and scale, it has also introduced new security risks to FedRAMP systems.

In response, the FedRAMP Program Management Office (PMO) issued new guidance in March 2021 that standardized the vulnerability scanning requirements for container technologies. While these requirements are thoroughly explained by the FedRAMP PMO, Schellman often still receives additional questions when reviewing containers during the FedRAMP assessment process. Even though the security controls and requirements summarized below are not meant to be comprehensive in nature, they are designed to address some of the most important requirements and give CSPs a general idea of how container technologies may impact a FedRAMP assessment.

1. Image Hardening
   Prior to being deployed into the production environment, all container images must undergo “hardening,” utilizing the security benchmarks located within the National Checklist Program repository when possible. For instance, if an organization utilizes Docker containers, then the corresponding Center for Information Security (CIS) Benchmark for Docker should be used to securely configure the Docker images. In the event that an organization is running a container type that does not have a published benchmark available, then a custom benchmark must be developed by the CSP and assessed by the 3PAO during the FedRAMP assessment.
   
   The container hardening process should mirror the organization’s operating system and database hardening process. Hardening requirements are outlined in the CM-6 security control and should include implementing configuration checks in accordance with an applicable benchmark (e.g., Docker), scanning the container image for compliance with the benchmark, reviewing and approving the benchmark scan results, and then documenting approved deviations from the benchmark (i.e., false positives, operational requirements).

2. Continuous Integration/Continuous Deployment (CI/CD) Pipeline
   Once container images have been hardened as part of the development process, they should be stored within an approved registry to control the image types deployed to production—as such, automation must be used to build, test, and deploy containers as part of the CSP’s CI/CD pipeline. In this, orchestration tools such as Kubernetes and Docker Swarm are commonly used by CSPs to automate management of containers within their CI/CD pipeline. When interacting with the container registry, these tools should have a mechanism restricting unapproved images from being deployed into production. As the CI/CD pipeline must be assessed by the 3PAO during the FedRAMP assessment for compliance with the CM-2 and CM-3 security controls, the CSP should ensure container images are properly managed within the registry and configuration changes follow the organization’s change control process.

3. Asset Management and Inventory Reporting
   Containerization typically creates a large, highly dynamic environment that does not translate well when developing the static system inventory necessary for FedRAMP, and as such, it commonly creates a lot of questions regarding asset management and inventory reporting for containers. The good news is that CSPs are not required to report each individual production-deployed container instance within the FedRAMP Integrated Inventory Workbook when scanning container images pre-production. However, they are required to report each container instance if the organization is leveraging security sensors to scan containers within the production environment. (More on these two approaches later.)
   
   If a CSP opts to perform pre-production image scans, they must assign a unique asset identifier to each container image type that corresponds to a production-deployed container image. For example, a CSP’s environment may contain a thousand container instances running in production that are sourced from 10 unique container images stored within an approved registry, each of which should then be included in the FedRAMP Integrated Inventory Workbook. While each individual container instance is not required to be reported in the inventory workbook, the CSP is still required to internally track these via an automated mechanism to support the CSP’s vulnerability management process. These steps taken will help when the 3PAO assesses the CSP’s container inventory management process during the FedRAMP assessment, as they will examine the tracking of each individual container instance in order to validate compliance with the CM-8 and RA-5 security controls.

4. Vulnerability Scanning
   Moving right along, when it comes to developing a strategy for container vulnerability scanning, it is important to understand the distinctions between scanning containers and scanning traditional infrastructure, as the ephemeral nature of containers is not suited for the conventional scanning tools and methods used for static infrastructure. Consequently, CSPs must adopt a new strategy to be in compliance with the security control RA-5 and the corresponding control enhancements. Fortunately, the FedRAMP PMO has outlined two acceptable approaches for scanning containers—similar to those for their inventory reporting standards mentioned in the previous point, these include pre-production image scanning and sensor-based production scanning.
   
   Pre-production scans consist of scanning container images as a step in the CSP’s CI/CD pipeline. This process must follow all requirements outlined in the PMO’s FedRAMP Vulnerability Scanning Requirements guidance, including the performance of scans on a monthly basis. All unique images that correspond to a production-deployed container must be scanned prior to being placed within the production registry and every 30 days thereafter. As previously stated, CSPs should monitor their container registry to ensure each unique image is scanned monthly and that the identified vulnerabilities from each image can be traced to the specific production-deployed container instance. To ensure compliance with the 30-day scanning requirement, CSPs should also implement detective controls such as automatic alerts that notify system administrators when an image is out of compliance or preventative controls like the configuration of orchestration tools to only deploy compliant images.
   
   On the other hand, the sensor-based approach outlined by the FedRAMP PMO permits vulnerability scanning within the production environment using security sensors—these security sensors are typically deployed alongside production-deployed containers as a “side car” container that monitor other containers on the same host for vulnerabilities in real-time. In addition, the PMO has stated the security sensors should be deployed anywhere containers execute, including the CSP’s container registry and CI/CD pipeline. Similar to the pre-production image scanning approach, CSPs are expected to follow all requirements outlined in the FedRAMP Vulnerability Scanning Requirements guidance, which includes ensuring the security sensors operate with sufficient privileges to perform authenticated and authorized scans. However, unlike the pre-production image scanning approach, CSPs are required to include each individual production-deployed container instance within the FedRAMP Integrated Inventory Workbook. If using sensor-based production scanning, it may make sense for the CSP to determine whether sampling is appropriate for the environment. For more information, the PMO’s Guide for Determining Eligibility and Requirements for the Use of Sampling for Vulnerability Scans outlines the FedRAMP requirements for sampling and describes the necessary steps for compliance.

5. Encryption
   With all that being said, containerized environments are held to the same standards as traditional virtualized environments when it comes to encrypting data in accordance with the Federal Information Processing Standard (FIPS). Irrespective of the CSP’s architecture, all FedRAMP systems must employ FIPS 140-2 validated cryptographic modules and algorithms for encrypting data-in-transit and data-at-rest. Nevertheless, a CSP’s strategy for obtaining FIPS 140-2 compliance will undoubtedly differ based on the system’s architecture, and so it’s critical that every CSP understand how their containerized environment is transmitting data across nodes, pods, and clusters, as well as how FIPS 140-2 encryption is ultimately being enforced for the traffic. For example, the CSP may need to enable FIPS 140-2 on the host operating system running the container workload and also build the container with a FIPS 140-2 module installed and enabled. Whatever encryption implementations are made by each organization will be evaluated by the 3PAO as part of a CSP’s FedRAMP assessment to ensure compliance with FIPS 140-2 requirements.

Something else to perhaps consider is the implementation of security controls for containerized environments that address network separation, authentication and authorization, audit logging, and system backups, but the introduction of containers will likely impact a CSP’s FedRAMP assessment in many other facets that were not mentioned here at all as well. And while the aforementioned security requirements are not all-inclusive, they are still a great starting point for organizations evaluating their compliance with FedRAMP’s container requirements. As containers continue to grow in popularity within federal cloud service offerings, it will be critical for CSPs to understand these requirements and the resulting implications for their FedRAMP assessments.