On March 16, the US Federal Risk and Authorization Management Program (FedRAMP) released the document “FedRAMP Vulnerability Scanning Requirements for Containers”, which describes “cloud systems using container technology”. Specific Processes, Architecture, and Security Considerations for Vulnerability Scanning” to ensure that cloud service providers (CSPs) maintain their container technology compliance, bridging the compliance gap between traditional and containerized cloud systems.
ONE
1. Background
FedRAMP is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring (ConMon) of cloud products and services. By providing the Joint Authorization Board (JAB) and Agency Authorization Officers (AO) with deep insights into the changing security posture of the system, ConMon ensures that cloud service providers continue to secure FedRAMP authorization systems. As technology evolves with each passing day, cloud service providers are constantly evolving to improve and adapt to their customers’ needs. Certain technical changes affect how ConMon performs.
This document supplements and updates the existing requirements defined in the FedRAMP Continuous Monitoring Strategy Guide and FedRAMP Vulnerability Scanning Requirements, and describes the use of FedRAMP in cloud systems using container technology. Specific compliance requirements in terms of processes, architecture, and security considerations that need to be followed in vulnerability scanning.
TWO
2. Characteristics and risks of container technology
Container technology can be deployed on bare metal or virtual machines, on-premises self-built systems, or in elastic cloud environments. Various container orchestration tools are usually used to implement the deployment and management of large-scale distributed containers. The following are common characteristics of container technology:
Container-launched applications and their dependent libraries are isolated from other processes
Containers have host-independent networking
Containers are elastic and occasionally ephemeral
Containers are immutable, the upgrade operation happens on the source image in a secure pre-release environment, upgrading a container refers to destroying an existing container and replacing it with a new container
Important risks and threats associated with the use of containerization technologies include:
Unauthenticated External Software
Non-standard configuration
Communication between unmonitored containers
untracked temporary instance
unauthorized access
Registry/Repository repository poisoning
Unmanaged Registry/Repository repository
The security requirements outlined in this document help cloud service providers take full advantage of container technology while complying with FedRAMP compliance requirements. The purpose of the following security requirements is to ensure that the risks associated with the use of container technology (including but not limited to those listed in the bullet point form above) are at least mitigated, if not addressed. While these requirements apply broadly, FedRAMP also recognizes that some specific implementations may require alternative measures to address risks.
THREE
3. System scan requirements using container technology
Existing scanning requirements are outlined in the FedRAMP Continuous Monitoring Policy Guidelines, FedRAMP Low, Moderate, and High Security Control Baselines, and FedRAMP Vulnerability Scanning Requirements. The following requirements are supplemental and apply to all implementation containers technical system.
1. Mirror reinforcement
Cloud service providers must only use containers with hardened images. Reinforcement must comply with the relevant benchmarks listed in the National Institute of Standards and Technology (NIST) National Checklist Program and the provisions of NIST SP 800-70. The final configuration must be verified by a third-party evaluation agency (3PAO), and unhardened or generic images must not be used within authorized boundaries.
2. Container build, test and orchestration pipeline
Cloud service providers must leverage automated container orchestration tools to build, test, and deploy containers into production. These automated tools must be validated by third-party evaluation agencies. Non-automated processes should not be part of the container testing and orchestration process unless intentionally manual for quality review purposes.
3. Container Image Vulnerability Scanning
Before deploying containers into production, cloud service providers must ensure that all components of a container image are scanned as specified in the FedRAMP Vulnerability Scanning Requirements document. Where possible, the container orchestration process should include scanning as one of the steps in the deployment pipeline. Additionally, it is not recommended to perform vulnerability scans directly on containers deployed to production, except through an independent security sensor.
4. Safety sensor
Independent security sensors can be deployed alongside containers in production environments to continuously inventory and assess the security posture of cloud service providers. Independent deployment allows security sensors to maintain broad visibility across containers. Security sensors should operate with sufficient permissions to avoid lack of visibility and false positives.
5. Registry Monitoring
The container registry must monitor each individual image to ensure that containers corresponding to images that are not scanned within the 30-day vulnerability scanning window are not actively deployed to production. Since a container registry itself is usually not a policy control point, this process can be managed through alerts that notify operators or other control mechanisms to prevent unauthorized deployments.
6. Asset management and inventory reporting for deployed containers
In order to identify the total number of relevant vulnerabilities on the production environment associated with that container, each type of image corresponding to one or more containers must be assigned a unique asset identifier so that automated systems can ensure that each production deployed container Corresponds to the source image.
FOUR
4. Transition plan
Each FedRAMP system utilizing container technology has 1 month to submit a transition plan, if applicable, and 6 months from the date of this document to transition to full compliance.
If full implementation is not possible, cloud service providers must work with their authorized officials to develop mitigation plans. The administrative agency is required to review and approve the cloud service provider’s mitigation plan. For systems with Joint Authorization Board Temporary Operational Authorization (JAB P-ATO), cloud service providers should publish mitigation plans to the FedRAMP repository and email notification to info@fedramp.gov, or contact their FedRAMP Liaison (FedRAMP POC) to discuss options. Any current cloud service provider authorized by an agency authorized officer will need to consult with their authorized officer.
The Links: NL12876BC26-22F MG100J2YS40 COMPONENTS