Managing Your Vulnerabilities, FedRAMP Style

As a member of Coalfire’s Cyber Engineering team, I frequently get questions about vulnerability Deviation Requests (DRs) from Cloud Service Providers (CSPs) seeking Federal Risk and Authorization Management Program (FedRAMP) authorizations. Typical questions include:

• What are common types of deviations? 
• How detailed should justifications be documented for a vulnerability deviation request?
• Where should deviation rationale be monitored or documented?

In this post, I’ll try to answer these and other questions we frequently encounter about Deviation Requests and provide some useful resource links.

The DR Process

CSPs use DRs to document their rationale for not remediating vulnerabilities. Per FedRAMP guidance, a deviation request rationale is documented in the FedRAMP deviation request form and/or in the ‘Deviation Rationale’ column in the Plan of Action and Milestones (POA&M) document for each vulnerability. The FedRAMP Joint Authorization Board (JAB) expects deviation request forms to be submitted upon discovery and during the monthly POA&M submissions. The deviation rationale should be clear and complete for FedRAMP reviewers and 3PAOs to review during the Security Assessments and monthly Continuous Monitoring Process. 3PAOs such as Coalfire will be reviewing FedRAMP-approved and pending-approval deviation requests each year during the assessment process. 3PAOs are not required to accept pre-approved FedRAMP deviation requests if the provided justifications are not sufficient; the JAB will also reject DRs that do not fully explain the rationale. 

An Example

One CSP I worked with wrote an insufficient deviation request justification stating, “A vulnerability was an operational requirement due to the cost and complexity of replacing a device.” The CSP did not describe the complete picture to the reviewer including type of device, listing functions that will break if the device was replaced, or listing functions that will not work appropriately if this vulnerability were to be remediated. CSP should not copy and paste the recommendations and mitigation strategies from the scanning tool results in their DR rationale description without putting it in the context of the specific system. Therefore, the CSP should define the deviation rationale in its entirety by explaining the following:

• CSP contact information
• Vulnerability information (such as POA&M ID, scan ID, assets impacted, vulnerability name, vulnerability source, initial rating, detection date, CSP-provided additional vulnerability information, tool-provided vulnerability description, and tool-provided recommended action)
• Deviation request summary (DR number, DR submission date, type of DR, DR rationale)
• Additional information: False Positive (evidence description and list of evidence attachments)
• Additional information: Operational Requirement (operational impact statement, justification, and list of operational requirement attachments)
• Additional information: Risk Reduction (attack vector, attack complexity, privileges required, user interaction, impact metrics around confidentiality integrity, and availability, remediation level, and list of risk reduction attachments)
• CSP Signature

Addressing and Tracking Vulnerabilities

There are several methods to address and track vulnerabilities:

1. Vendor Dependency

Vendor dependency vulnerabilities are considered an open vulnerability and tracked in the open tab within the POA&M. This vulnerability will only be remediated and closed on the POA&M if the CSP applies a vendor approved patch, configuration change, or upgrade.  FedRAMP requests that CSPs contact their third-party vendor monthly (every thirty days) to determine if a fix or upgrade has been released. The vendor’s fix or upgrade release date starts the remediation timeframe (FedRAMP requirement was thirty days for high vulnerabilities and ninety days for moderate vulnerabilities). CSPs should document the vendor last check-in date, vendor product name, and milestone updates within the POA&M. By performing these actions, the vulnerability will not be considered as missing the remediation timeframe. 

2. Risk Adjustment

Risk adjustment deviations are changes to an original risk exposure level identified within the vulnerability scan results to a different risk level (e.g., high to moderate, moderate to low, or high to low) using the Common Vulnerability Scoring System (CVSS) v3.0 Specifications, which include the Exploitability Metrics - Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), and User Interaction (UI).

• AV is rated by the context in which it is possible to exploit (e.g., exploitable vulnerability with access to either the network, adjacent network, local, and/or physical vectors)
• AC is rated on the conditions beyond the attacker’s control (e.g., low – specialized access conditions or mitigating controls do not exist; and high – requires effort and reconnaissance by the attacker)
• PR is rated on the attacker’s access privileges (e.g., none – attacker is unauthorized prior to attack; low – attacker has basic user access permissions; and high – attacker has administrative access permissions)
• UI is rated on the user participation (e.g., not defined, none, and required)

CVSS also uses impact metrics. These reflect the confidentiality, integrity, and availability (CIA) impact levels for vulnerable components. The CIA metric values are none (no loss or impact), low (limited information can be obtained, limited amount of data can be modified, and/or reduced performance), and high (information is disclosed, information can be modified, and/or resource can be unavailable). Remediation level prioritizes the urgency for remediation by adjusting the temporal score downwards. The remediation level metric values are:

FedRAMP requires that the exploitability metrics, impact metrics, and remediation level CVSS specifications be defined in detail for each deviation request form documenting a risk reduction. Vulnerabilities could be considered risk adjusted if the CSP provided what changed about the system environment, types of access permissions, mitigating factors, and compensating controls. Once approved, risk adjusted vulnerabilities allow the CSP more time for remediation actions. Risk adjusted vulnerabilities are tracked in the deviation request form and within the POA&M.

3. Operational Requirement

Operational requirement deviations are open vulnerabilities that cannot be corrected without impacting the system functionality. Operational requirement vulnerabilities are tracked in the deviation request form and in the open tab within the POA&M. This type of vulnerability will only be closed on the POA&M if the CSP resolved the conditions creating the operational requirement and submit supporting evidence (e.g., screenshot/monthly or ad-hoc scans). For high-risk exposure vulnerabilities that cannot be resolved, the CSP cannot request an operational requirement with the original risk exposure level. The CSP should justify the mitigating factors and compensating controls for a risk adjustment.

4. False Positive

False positive deviations are vulnerabilities that are non-existent within the system and/or were incorrectly identified by the vulnerability scanner. Deviation requests for false positives are submitted and tracked within the POA&M as yes, no, or pending. False positives identified during the security assessment report (SAR) are not entered into the POA&M. False positive vulnerabilities can be closed from the POA&M after the deviation request form was approved by the authorizing official. As per FedRAMP guidance, CSPs should provide a detailed description and screenshots justifying how the vulnerability was not accurate for the system. If the CSPs cannot show proof of the false positive in the explanation and corresponding evidence, it will be difficult for the JAB to approve it.

In summary, CSPs should appropriately categorize vulnerability deviation requests and provide clearly written and detailed rationales, justifications, and evidence for the FedRAMP JAB/Agency and their 3PAO to decide if a vulnerability was remediated within the organization-defined timeframes.

Resources:

FedRAMP Tips & Cues – https://www.fedramp.gov/tips-cues/
FedRAMP Deviation Request Form – https://s3.amazonaws.com/sitesusa/wp-content/uploads/var/www/html/sites/www/app/wordpress/wp-content/blogs.dir/482/files/2016/04/FedRAMP_Deviation_Request_Form_v1.0-1.pdf

FedRAMP Plan of Action and Milestones (POA&M) Template Completion Guide v2.0 (Dated 1/31/2018) – https://s3.amazonaws.com/sitesusa/wp-content/uploads/var/www/html/sites/www/app/wordpress/wp-content/blogs.dir/482/files/2016/06/FedRAMP_POAM_Template_Completion_Guide_v2.0-1.pdf

FedRAMP Continuous Monitoring Strategy Guide v3.0 (Dated 1/31/2018) – https://s3.amazonaws.com/sitesusa/wp-content/uploads/var/www/html/sites/www/app/wordpress/wp-content/blogs.dir/482/files/2016/06/FedRAMP_Continuous_Monitoring_Strategy_Guide_v3.0.pdf  

FedRAMP Continuous Monitoring Performance Management Guide (Dated 1/31/2018) – https://s3.amazonaws.com/sitesusa/wp-content/uploads/var/www/html/sites/www/app/wordpress/wp-content/blogs.dir/482/files/2016/06/FedRAMP_Continuous_Monitoring_Performance_Management_Guide_v2.0-1.pdf

Agency Authorization Playbook – https://s3.amazonaws.com/sitesusa/wp-content/uploads/sites/482/2017/11/FRP-0002_Agency-Playbook_FINAL-1.pdf

National Vulnerability Database (NVD): Vulnerability Metrics – https://nvd.nist.gov/vuln-metrics

Common Vulnerability Scoring System v3.0: Specification Document – https://www.first.org/cvss/specification-document