Looking into Vulnerability Management for FedRAMP Containers
Requirements for containers in FedRAMP can be confusing to navigate. The FedRAMP Program Management Office (PMO) issued its initial container security guidance in March of 2021. Less than a few weeks ago at the time of this writing (February 16th), the FedRAMP PMO released additional updatesfor NIST SP 800-53 Rev. 5. These updates to Version 3.0 of the vulnerability scanning guidelines include additional guidance on container scanning, reporting, remediations, and encryption.
In this article, we will explore container vulnerability scanning, frame the vulnerability management requirements in a FedRAMP context, and provide commentary on the new FedRAMP PMO updates to container scanning requirements for cloud service providers (CSPs).
Container Threat Landscape
According to Sysdig’s Cloud-Native Security and Usage Report, 87% of container images running in production environments have critical or high-severity vulnerabilities, an increase from 75% in 2022. This increase highlights a desperate need for the vulnerability management of containers.
The FedRAMP PMO has identified the following risks and threats that should have proper mitigations employed in a production environment that will be explored in this blog:
- External software that is unvalidated
- Configurations that deviate from standards
- Container-to-container networking
- Untracked, ephemeral instances
- Unauthorized access
- Container repository poisoning
- Unmanaged Container repositories
Container Hardening
Container hardening involves resolving vulnerabilities through patching, remediation, and removal of unnecessary components. This is usually done through a security pipeline, starting with a secure base image. Secure base images can be found from various sources such as Chainguard, Iron Bank or Harbor.
From a FedRAMP perspective, NIST 800-53 controls are used to assess the environment that containers run in and the container workloads themselves. NIST 800-70 provides guidelines (via guidance available in NIST’s National Checklist Program for verifying a product has been secured correctly. From a container hardening perspective, third-party assessment organizations (3PAOs) will check for the following baseline controls from NIST 800-53 and ensure that all containers have been hardened using an appropriate benchmark before authorizing a solution for FedRAMP.
Vulnerability Scanning
Inside Container Pipelines
Vulnerability Scanning should occur in the development environment with an appropriate scanning solution, preferably within the container pipeline. Note that vulnerability scans are an essential part of the FedRAMP continuous monitoring (ConMon) and are provided to agency authorizing officials (or Joint Authorization Board) on a monthly basis.
Another key point is that the scanning solution used within the container pipeline should not perform vulnerability scanning directly on containers during runtime; rather, independent security sensors deployed alongside containers should be used instead. We’ll discuss this further in the “Runtime Security Sensors” section of this article.
Container Registry Monitoring
A monitoring solution must also be deployed that scans container registries on a regular basis per unique container. Only containers scanned within the past 30 days can be actively deployed in the production environment. Similar to the container pipeline, when a vulnerability is found within the registry, there should be some mechanism or event-oriented solution that actively prevents the deployment of containers with vulnerabilities.
Runtime Security Sensors
To continuously monitor containers as they are running in an environment, an independent deployment of security sensors should be deployed alongside containers (either on the container host or inside the cluster itself). Some examples of security sensors that can be deployed alongside production workloads include Prisma Cloud Compute or Anchore. These security sensors would run with sufficient privileges to avoid a lack of visibility or false negatives.
Asset Management for Deployments
As part of the System Security Plan (SSP) that must be submitted for FedRAMP Authorization, an Integrated Inventory Workbook is attached to this document. In a container context, each type of image corresponding to one or more deployed production containers should be accounted for in this workbook. The key phrase is “type of image” – there is no need to have an inventory of each individual deployment in this workbook. One key exception is that if a container is singled out as a target of a security sensor scan, it should be included in this workbook. Keep in mind that per NIST 800-53 CM-8, there should be a way to see all containers running within your production environment that correspond to the images described in the inventory workbook.
Encryption
Per SC-8, encryption must occur in any data-in-transit situation, which includes the following communication: container-to-container, container-to-host, container-to-external, and even from one memory processing space to another. This usually requires the deployment of a service mesh that provides mutual TLS (mTLS) protections, such as Tetrate Istio, Anthos Service Mesh, or AWS App Mesh.
Note that FedRAMP requires the cryptographic specifications from the Federal Information Processing Standard (FIPS) 140-2. Utilizing a module that NIST validates for FIPS 140-2 such as OpenSSL 3.0.8 is important in container images that will run within the FedRAMP boundary.
Your Best Friend in Container Security
Securing containers to FedRAMP requirements can be cumbersome and expensive, but it doesn’t need to be this way. Partnering with HanaByte ensures industry veterans can assist you every step of the way and ensure that best-in-class yet cost-effective solutions are in place within your environment to meet these control standards. Reach out to us today for a free, no-obligation discussion about your needs.
