Skip to content

Vulnerability Scanning

Vulnerability Detection and Response Balance Improvement Release

This entire section and set of requirements does not apply to cloud service providers who have met all of the requirements for adopting the optional Vulnerability Detection and Response Balance Improvement Release.

Continuous monitoring ensures CSPs continuously maintain the security of their FedRAMP Authorized systems by providing AOs monthly insight into the security posture of the system. CSP scanning policies, procedures, and tools (including vulnerability scanners) are key components to ConMon activities. In an effort to increase the efficiency and effectiveness of ConMon activities, this section provides guidance for scanning requirements.

Background

Vulnerability scanning is a key part of continuous monitoring. Agencies who wish to review CSP vulnerability scans on a routine basis should require CSPs to do so by initiating a customer agreement. These scans augment the FedRAMP Integrated Inventory Workbook Template and FedRAMP Plan of Action and Milestones (POA&M) to provide the designated agency ConMon lead and consuming agencies monthly insights into the risk posture of the CSO. This section does not define additional requirements; rather, it clarifies existing requirements and provides best practices for implementing FedRAMP vulnerability scanning for all FedRAMP security control baselines, specifically in control RA-5.

General Scanning Requirements

Scanner Resiliency: Scanners should be hardened to resist unauthorized use or modification (i.e., unnecessary ports and/or unnecessary services should be closed).

Authenticated Scanning: For Moderate and High systems, the CSP must ensure authenticated scans are performed wherever possible. [RA-5(5)]

Scanning with Full Authorization: For all Moderate and High systems, the CSP must ensure that scans are being performed with full system authorization. [RA-5(5)]

  • Scanning must avoid typical lack of authorization issues (including lack of access to remote registry, limited registry access, limited file access, etc.).

Machine-Readable Findings: The scan output must display all scan findings with a low risk or higher in a structured, machine-readable format (such as XML, CSV, or JSON).

  • If the scanner is able to output/export findings in more than one machine-readable format, the CSP must select the format that provides the greatest amount of information.
  • Where possible, the machine-readable data must include the authentication and authorization status of the scans to demonstrate the degree to which an authenticated scan was performed on each host.

National Vulnerability Database (NVD): For any vulnerability listed in the latest version of the National Institute of Standards and Technology (NIST) NVD, the Common Vulnerabilities and Exposures (CVE) reference number must be included with the machine-readable findings data for that vulnerability.

Common Vulnerability Scoring System (CVSS) Risk Scoring: For any vulnerability with a CVSSv3 base score assigned in the latest version of the NVD, the CVSSv3 base score must be used as the original risk rating. If no CVSSv3 score is available, a CVSSv2 base score is acceptable where available. If no CVSS score is available, the native scanner base risk score can be used.

Configuration Settings: The CSP must provide machine-readable evidence that the scanner's configuration settings have not been altered from the assessor-validated configuration settings approved during the initial authorization assessment.

Configuration Changes: If a scanner configuration change is required (above and beyond normal patching and updates) the AO must be notified and approve of the change.

Signature Updates: For each deliverable, the CSP must update the list of vulnerabilities scanned to the latest available list. [RA-5(2)]

  • The CSP must use a vulnerability scanner that checks for automatic signature updates of the scanner's vulnerability database at least monthly.
  • The CSP must provide automated machine-readable evidence of the most recent update performed prior to scanning.

Adequate Asset Identification: The scanner findings must contain unique asset identifiers that map to an inventory.

  • The CSP must have an automated mechanism to identify and catalog all assets, within the authorization boundary, every month in order to ensure that everything is being scanned appropriately.
  • For Web scans, a dynamically updated catalog of Web services should be maintained to include the ports where Web services reside.
  • Ephemeral assets: All ephemeral/dynamic assets must be uniquely tagged as such. Oftentimes, ephemeral environments can cause discrepancies when ensuring all assets identified within the inventory have been scanned.
  • Container Images: A unique asset identifier must be assigned to every class of image which corresponds to one or more production-deployed containers. These image-based asset identifiers must be documented in the inventory. Instances of production-deployed containers must be tracked internally by the CSP via an automated mechanism, which must be validated by an assessor to meet the baseline control CM-8. Every production-deployed container must correspond to the image from which the deployed container originated, in order to identify the total number of relevant vulnerabilities on production associated with that container.

Types of Scans: CSPs must scan operating systems, Web applications, and databases monthly. [RA-5]

  • The entire inventory (or approved sampling percentage) within the boundary must be scanned at the operating system (OS) level at least once a month.
  • All Web interfaces and services (or approved sampling percentage) must be scanned.
  • All databases (or approved sampling percentage) must be scanned, including those required to support the infrastructure.

Plan of Action and Milestones (POA&M) Entries: The CSP must track each unique vulnerability as an individual POA&M item.

  • Individual vulnerabilities must be based on the scanning tool's unique vulnerability reference identifier (ID).
  • The CSP may break a unique vulnerability into multiple POA&M items, such as for a vulnerability that applies to different asset types that will be remediated in different ways.
  • The CSP must not group multiple unique vulnerabilities into a single POA&M item.

All Non-Destructive Detections: The CSP must enable all non-destructive detections within the scanner.

Image Scanning: Where the CSP offers services, such as virtual images, and where the customer is responsible for scanning but is reliant on the CSP for patching, the CSP must scan the source image for all available customer leveraged images.

  • This applies to all images in use or available for use by federal government customers.

Container Unique Requirements

The following requirements are applicable for all CSPs implementing container technologies:

Hardened Images: The CSP must only utilize containers where the image is "hardened." Where applicable, the hardening must be in accordance with relevant benchmarks listed in the National Checklist Program and defined by the National Institute of Standards and Technology (NIST) SP 800-70. Benchmarks are used as a baseline and may be altered. However, the final configurations must be validated by an assessor to ensure they meet FedRAMP requirements for the baseline controls CM-6, SC-2, SC-3, SC-4, SC-6, SC-28, and SC-39. In the case of containers leveraging an image that does not have a listed benchmark available, the CSP must create and maintain an assessor validated benchmark for the purpose of hardening. Non-hardened or general-purpose images may not be used within the authorization boundary. The assessor must validate the CSP build, test, and orchestration pipeline and process of hardening images intended for deployment. Assessor validation of every individual container instance deployed to production is not required. This requirement should not restrict a CSP from leveraging third-party software within hardened containers. This requirement also does not restrict a CSP from using hardened images or software obtained from a secure repository in groups which share IP addresses and may share volumes.

Container Build, Test, and Orchestration Pipeline: The CSP must leverage automated container orchestration tools to build, test, and deploy containers to production. These automated tools must be validated by an assessor to meet FedRAMP requirements for the baseline controls CA-2, CM-2, CM-3, SC-28, SI-3, and SI-7. However, components of the pipeline that fall to the left of the production container registry, including environments intended for development or testing, may reside outside of the system boundary. Non-automated processes should not be considered part of the container testing and orchestration process, except in the case of intentional manual procedures for quality review purposes. These processes and tools must include a mechanism to restrict containers that do not adhere to FedRAMP requirements from successfully deploying.

Vulnerability Scanning for Container Images: Prior to deploying containers to production, a CSP must ensure that all components of the container image are scanned. When possible, the container orchestration process should incorporate scanning as one of the steps in the deployment pipeline. The 30-day scanning window begins as soon as the container is deployed to the production registry. Only containers from images that have been scanned within a 30-day vulnerability scanning window can be actively deployed on the production environment. Additionally, modification of configuration settings defined within the image or software patching should never occur directly on the production environment, but rather on the replacement image to be deployed to production. Performing vulnerability scanning directly on containers deployed to production is not recommended, unless it is performed via the use of independent security sensors deployed alongside production-deployed containers.

Security Sensors: Independent security sensors may be deployed alongside production-deployed containers to continuously inventory and assess a CSP's security posture. This independent deployment allows the security sensors to maintain broad visibility across containers. Security sensors should be run with sufficient privileges to avoid lack of visibility and false negatives. If utilized, security sensors should be deployed everywhere containers execute to include within registries, as general-purpose sensors, and within CI/CD pipelines. If this approach is taken, the sampling guidance below MAY be applicable.

Registry Monitoring: The container registry MUST be monitored per unique image to ensure that containers corresponding to an image that has not been scanned within the 30-day vulnerability scanning window are not actively deployed on production. As the registry itself is often not a policy control point, this process may be managed by alarms that inform operators or other control mechanisms to prevent unauthorized deployment.

Sampling for Vulnerability Scanning

In order to respond to rapidly changing demands for increases and decreases in cloud resources in this environment, CSPs must maintain rigid change management processes and highly automated mechanisms for deploying system images in large geographically dispersed production environments. This leads to establishing a very short list of standard system images that make up the unique inventory. Usually, vulnerability scans are performed on 100% of these assets, but because of the high fidelity of system configurations across the environments, the scan results of a subset of components can be used to ascertain the state of the entire population. Therefore, a sampling of the assets within each of the standard system images is considered sufficient. An assessor must attest that the sample selected is sufficient to represent the state of the unique inventory and the AO must approve the sample methodology prior to implementation.

A unique inventory item is a grouping of one or more discrete inventory assets that are managed as a single asset class. For example, 1,000 servers deployed using the same system build or system image release are considered to be a single, unique inventory item, even if that system build has been updated and only a subset of the 1,000 servers is running the newest version, because the servers are being managed as a single asset class. In these cases, the configuration management plan must identify how the CSP is managing the inventory items and asset classes, ensuring all assets are updated within an appropriate/approved amount of time (limiting the number of different builds/versions in a given asset type). Unique inventory items must be defined as part of the Vulnerability Sampling Plan reviewed by the assessor.

This guidance applies to system builds that are deployed from standard images (that must remain unchanged when pushed to and running on subsequent devices or machines in production) to general purpose servers in highly dynamic virtual, and some physical, environments. The guidance also applies to operating systems deployed to network devices, web applications, databases, and other software products where appropriate.

FedRAMP vulnerability scanning guidelines require at least monthly scans of 100% of inventory components. Vulnerability scanning using sampling targets the same component asset categories but instead requires scanning of a sample attested to represent the unique inventory by an assessor and approved by the AO. Given the risk, FedRAMP recommends that externally accessible (outside of the boundary, without the use of a VPN) system components do not use this sampling methodology; 100% of externally accessible system components should be scanned, using a scanning technology appropriate for the access type (web scanners for web endpoints and portals, network scanners for operating systems, etc.).

The following steps are required for the CSP and assessor to ensure that an appropriate Vulnerability Sampling Plan is implemented, a unique inventory is maintained, components are appropriately selected, scans are performed, and results are reviewed and remediated:

  1. Comply with FedRAMP Requirements for Vulnerability Scans

  2. Activate Capabilities to Ensure Unique Inventory Items are Identical

    • The CSP will activate a method to demonstrate that all individual assets in a class are identical; within operational and management parameters.

    • The CSP will provide, to the assessor, a description of the product/method for ensuring unique inventory items are configured appropriately. The CSP will perform a test of the solution to demonstrate effectiveness annually, at time of FedRAMP Annual Assessment of the system, and provide the results to the assessor.

  3. Develop Vulnerability Sampling Plan

    • Establish a Plan (methodology) by which sampling will be used; the Plan shall be reviewed at least annually, and maintained current.

    • Describe how components will be selected. Justify how the unique inventory item (such as a network device OS version) is built from a standard image and meets the intent of this guideline.

    • Ensure at each selection interval (each month when scans are run), that the assets are selected randomly from the total inventory. Describe the randomization method.

    • Describe how this sample effectively represents the entire inventory and satisfies the intent of vulnerability scan requirements.

  4. Establish Unique Inventory and Samples:

    • Establish a list of the unique inventory.

    • Ensure each unique inventory item is based on system builds that are deployed from standard images (that must remain unchanged when pushed to and running on subsequent devices or machines in production) to general purpose servers in highly dynamic virtual, and some physical, environments. This also applies to operating systems deployed to network devices, web applications, databases, and other software products where appropriate.

    • Select a sample sufficient to represent the unique inventory item. The sample must be attested to by an assessor at the time of the FedRAMP Annual Assessment.

      • Should the unique inventory change during the year, the CSP will update the Vulnerability Sampling Plan, including documenting how these devices continue to implement previously approved change, deviation, and security controls. Assessors will perform an assessment over the changed inventory at the time of the next FedRAMP Annual Assessment.

      • FedRAMP recommends that 100% of externally accessible (outside of the boundary, without the use of a VPN) system components be scanned. However, if a sampling methodology is approved, there should be a strong justification, given the potential risk.

  5. Analyze Scan Results:

    • Analyze the scan results to determine whether there was any variance in findings among components within the same unique inventory group outside of documented operational or management parameters. All unexpected variances within a unique inventory group must be discussed with the AO with the next Plan of Action and Milestones (POA&M). If applicable, a high-risk POA&M item should be created to investigate and explain why the variance occurred, and correct the unexpected variance. At the discretion of the AO, if the sampling methodology is found to be inefficient (whether through one variance, or multiple variances), the AO may rescind sampling approval, requiring 100% scanning.
  6. Justify Appropriateness of CSP's Participation in "Sampling:"

    • Prior to acceptance to participate in sampling, the CSP should provide a convincing justification that participation is appropriate. This justification should reference all implemented controls that demonstrate adherence with the principles and requirements contained within this vulnerability scan sampling guide, enabling successful adherence to FedRAMP vulnerability scanning requirements testing using sampling.
  7. Assessment and Attestation by Assessor and Approval of Authorization Official:

    • The assessor will review the CSP's Vulnerability Sampling Plan, implementation and test results and attest to the sampling's effectiveness.

    • The AO for any agency issuing an ATO must approve the plan and justification, prior to participating in sampling.

    • Approval for using sampling can be rescinded by the AO due to identification of weaknesses in the plan, implementation or effectiveness, for example, if an anomaly was identified and a major issue was discovered during the investigation (as part of the high POA&M item).