Vulnerability Detection and Response¶

Providers MUST systematically, persistently, and promptly discover and identify vulnerabilities within their cloud service offering using appropriate techniques such as assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, supply chain monitoring, and other relevant capabilities; this process is called vulnerability detection.

Terms: Cloud Service Offering, Persistently, Promptly, Vulnerability, Vulnerability Detection

Providers MUST systematically, persistently, and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities within their cloud service offering; this process is called vulnerability response.

Note: If it is not possible to fully mitigate or remediate detected vulnerabilities, providers SHOULD instead partially mitigate vulnerabilities promptly, progressively, and persistently.

Terms: Cloud Service Offering, Persistently, Promptly, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers SHOULD make design and architecture decisions for their cloud service offering that mitigate the risk of vulnerabilities by default AND decrease the risk and complexity of vulnerability detection and response.

Terms: Cloud Service Offering, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers SHOULD use automated services to improve and streamline vulnerability detection and response.

Terms: Vulnerability, Vulnerability Detection, Vulnerability Response

Providers SHOULD automatically perform vulnerability detection on representative samples of new or significantly changed information resources.

Terms: Information Resource, Vulnerability, Vulnerability Detection

Providers SHOULD NOT weaken the security of information resources to facilitate vulnerability scanning, detection, or assessment activities.

Terms: Information Resource, Vulnerability, Vulnerability Detection

Providers SHOULD NOT deploy or otherwise activate new machine-based information resources with Known Exploited Vulnerabilities.

Terms: Information Resource, Known Exploited Vulnerability (KEV), Machine-Based (Information Resources), Vulnerability

Providers MAY sample effectively identical information resources, especially machine-based information resources, when performing vulnerability detection UNLESS doing so would decrease the efficiency or effectiveness of vulnerability detection.

Terms: Information Resource, Machine-Based (Information Resources), Vulnerability, Vulnerability Detection

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities.

Notes:

• The simple reality is that most traditional vulnerabilities discovered by scanners or during assessment are not likely to be exploitable; exploitation typically requires an unrealistic set of circumstances that will not occur during normal operation. The likelihood of exploitation will vary depending on so many factors that FedRAMP will not recommend a specific framework for approaching this beyond these rules.
• The proof, ultimately, is in the pudding - providers who regularly evaluate vulnerabilities as not likely exploitable without careful consideration are more likely to suffer from an adverse impact where the root cause was an exploited vulnerability that was improperly evaluated. If done recklessly or deliberately, such actions will have a negative impact on a provider's FedRAMP Certification.

Terms: Cloud Service Offering, Likely, Likely Exploitable Vulnerability (LEV), Regularly, Vulnerability, Vulnerability Detection

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities.

Notes:

• FedRAMP focuses on internet-reachable (rather than internet-accessible) to ensure that any service that might receive a payload from the internet is prioritized if that service has a vulnerability that can be triggered by processing the data in the payload.
• The simplest way to prevent exploitation of internet-reachable vulnerabilities is to intercept, inspect, filter, sanitize, reject, or otherwise deflect triggering payloads before they are processed by the vulnerable resource; once this prevention is in place the vulnerability should no longer be considered an internet-reachable vulnerability.
• A classic example of an internet-reachable vulnerability on systems that are not typically internet-accessible is SQL injection, where an application stack behind a load balancer and firewall with no ability to route traffic to or from the internet can receive a payload indirectly from the internet that triggers the manipulation or compromise of data in a database that can only be accessed by an authorized connection from the application server on a private network.
• Another simple example is the infamous Log4Shell (https://en.wikipedia.org/wiki/Log4Shell) vulnerability from 2021, where exploitation was possible via vulnerable internet-reachable resources deep in the application stack that were often not internet-accessible themselves.

Terms: Cloud Service Offering, FedRAMP Certified, Internet-Reachable Vulnerability (IRV), Vulnerability, Vulnerability Detection

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the potential adverse impact of exploitation on government customers AND assign one of the following Potential Adverse Impact N-ratings (PAIN):

• N1: Exploitation could be expected to have negligible adverse effects on one or more agencies that use the cloud service offering.
• N2: Exploitation could be expected to have limited adverse effects on one or more agencies that use the cloud service offering.
• N3: Exploitation could be expected to have a serious adverse effect on one agency that uses the cloud service offering.
• N4: Exploitation could be expected to have a catastrophic adverse effect on one agency that uses the cloud service offering OR a serious adverse effect on more than one federal agency that uses the cloud service offering.
• N5: Exploitation could be expected to have a catastrophic adverse effect on more than one agency that uses the cloud service offering.

Terms: Catastrophic Adverse Effect, Cloud Service Offering, Limited Adverse Effect, Negligible Adverse Effect, Potential Adverse Impact, Serious Adverse Effect, Vulnerability, Vulnerability Detection

Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to identify logical groupings of affected information resources that may improve the efficiency and effectiveness of vulnerability response by consolidating further activity; FedRAMP Vulnerability Detection and Response rules are then applied to these consolidated groupings of vulnerabilities instead of each individual detected instance.

Terms: Cloud Service Offering, Information Resource, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are false positive vulnerabilities.

Terms: Cloud Service Offering, False Positive Vulnerability, Vulnerability, Vulnerability Detection

Providers SHOULD consider at least the following factors when considering the context of the cloud service offering to evaluate detected vulnerabilities:

1. Criticality: How important are the systems or information that might be impacted by the vulnerability?
2. Reachability: How might a threat actor reach the vulnerability and how likely is that?
3. Exploitability: How easy is it for a threat actor to exploit the vulnerability and how likely is that?
4. Detectability: How easy is it for a threat actor to become aware of the vulnerability and how likely is that?
5. Prevalence: How much of the cloud service offering is affected by the vulnerability?
6. Privilege: How much privileged authority or access is granted or can be gained from exploiting the vulnerability?
7. Proximate Vulnerabilities: How does this vulnerability interact with previously detected vulnerabilities, especially partially or fully mitigated vulnerabilities?
8. Known Threats: How might already known threats leverage the vulnerability and how likely is that?

Terms: Cloud Service Offering, Fully Mitigated Vulnerability, Likely, Vulnerability, Vulnerability Detection

Providers MUST report vulnerability detection and response activity (including persistent verification and validation) to all necessary parties persistently, summarizing ALL activity since the previous report; these reports are FedRAMP Certification Data and are subject to FedRAMP Certification Data Sharing rules.

Terms: All Necessary Parties, Certification Data, Persistently, Validation, Verification, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers MUST NOT irresponsibly disclose specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST disclose sufficient information for informed risk-based decision-making to all necessary parties.

Note: This requirement will be superseded in the event of formal action related to an investigation or corrective action plan.

Terms: All Necessary Parties, Likely, Vulnerability

Providers MUST include the following information (if applicable) on detected vulnerabilities when reporting on vulnerability detection and response activity, UNLESS it is an accepted vulnerability:

1. Provider's internally assigned tracking identifier
2. Time and source of the detection
3. Time of completed evaluation
4. Is it an internet-reachable vulnerability or not?
5. Is it a likely exploitable vulnerability or not?
6. Historically and currently estimated Potential Adverse Impact N-rating of exploitation
7. Time and Potential Adverse Impact N-rating of each completed and evaluated reduction in Potential Adverse Impact N-rating
8. Estimated time and target Potential Adverse Impact N-rating of next reduction in Potential Adverse Impact N-rating
9. Is it currently or is it likely to become an overdue vulnerability or not? If so, explain.
10. Any supplementary information the provider responsibly determines will help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the vulnerability
11. Final disposition of the vulnerability

Terms: Accepted Vulnerability, Cloud Service Offering, Federal Customer Data, Internet-Reachable Vulnerability (IRV), Likely, Likely Exploitable Vulnerability (LEV), Overdue Vulnerability, Potential Adverse Impact, Responsibly, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers MUST include the following information on accepted vulnerabilities when reporting on vulnerability detection and response activity:

1. Provider's internally assigned tracking identifier
2. Time and source of the detection
3. Time of completed evaluation
4. Is it an internet-reachable vulnerability or not?
5. Is it a likely exploitable vulnerability or not?
6. Currently estimated Potential Adverse Impact N-rating
7. Explanation of why this is an accepted vulnerability
8. Any supplementary information the provider determines will responsibly help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the accepted vulnerability

Terms: Accepted Vulnerability, Cloud Service Offering, Federal Customer Data, Internet-Reachable Vulnerability (IRV), Likely, Likely Exploitable Vulnerability (LEV), Potential Adverse Impact, Responsibly, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers SHOULD include high-level overviews of ALL vulnerability detection and response activities conducted during this period for the cloud service offering; this includes vulnerability disclosure programs, bug bounty programs, penetration testing, assessments, etc.

Terms: Cloud Service Offering, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers MAY responsibly disclose vulnerabilities publicly or with other parties if the provider determines doing so will NOT likely lead to exploitation.

Terms: Likely, Responsibly, Vulnerability

Providers MUST report vulnerability detection and response activity to all necessary parties in a consistent format that is human readable at least monthly.

Timeframe: 1 month

Terms: All Necessary Parties, Vulnerability, Vulnerability Detection, Vulnerability Response

Providers MUST categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability.

Timeframe: 192 days

Terms: Accepted Vulnerability, Vulnerability

Providers SHOULD remediate Known Exploited Vulnerabilities according to the due dates in the CISA Known Exploited Vulnerabilities Catalog (even if the vulnerability has been fully mitigated) as required by CISA Binding Operational Directive (BOD) 22-01 or any successor guidance from CISA.

Reference: CISA BOD 22-01

Terms: Known Exploited Vulnerability (KEV), Vulnerability

Terms: All Necessary Parties, Machine-Readable, Persistently, Vulnerability, Vulnerability Detection, Vulnerability Response

Terms: Information Resource, Machine-Based (Information Resources), Persistently, Vulnerability, Vulnerability Detection

Terms: Drift, Information Resource, Likely, Persistently, Vulnerability, Vulnerability Detection

Terms: Drift, Information Resource, Likely, Persistently, Vulnerability, Vulnerability Detection

Terms: Vulnerability, Vulnerability Detection

Terms: Likely, Potential Adverse Impact, Vulnerability

Providers SHOULD mitigate or remediate remaining vulnerabilities during routine operations as determined necessary by the provider.

Terms: Vulnerability

Terms: Incident, Likely, Likely Exploitable Vulnerability (LEV), Potential Adverse Impact, Vulnerability

Terms: Incident, Likely, Likely Exploitable Vulnerability (LEV), Potential Adverse Impact, Vulnerability