FedRAMP: Three Stages of Vulnerability Scanning and Their Pitfalls

Though vulnerability scanning is only one of the control requirements in FedRAMP, it is actually one of the most frequent pitfalls in terms of impact to an authorization to operate (ATO), as FedRAMP requirements expect cloud service providers (CSPs) to have a mature vulnerability management program. A CSP needs to have the right people, processes and technologies in place, and must successfully demonstrate maturity for all three. CSPs that have an easier time with the vulnerability scanning requirements follow a similar approach, which can be best articulated by breaking down the expectations into three stages.

1. Pre-Assessment

Approximately 60-90 days from an expected security assessment report (SAR), a CSP should provide the third-party assessment organization (3PAO) a recent set of scans, preferably from the most recent three months. The scan data should be provided in a format that can be parsed by the 3PAO. By providing the scan data early, Schellman can identify potential issues that may delay the SAR or result in high severity findings. There are several questions that can be answered by providing scans well ahead of time:

• Credentials – Are the scans being conducted from an authenticated perspective with a user having the highest level of privileges available?
• All Plugins Enabled – Are any vulnerability checks disabled?
• Scan Types - Are infrastructure, database, and web application scans being performed?
• Points of Contact – Who is responsible for configuring the scanner and running scans? Who is responsible for remediation?
• Entire Boundary Covered – Is the full, in-scope environment being scanned?
• Remediation – Are high severity findings being remediated in 30 days? Are moderate severity findings being remediated within 90 days?

Within the pre-assessment, having all plugins enabled is frequently an area of discussion, as many CSPs want to disable plugins or sets of checks. Should a check need to be disabled, there must be a documented reason (e.g. degradation of performance or denial of service occurs with a given plugin). Do not disable checks simply because it is assumed a given type of asset doesn’t exist in the environment. Properly configured and authenticated vulnerability scanners will typically not send families of vulnerability checks against hosts if the operating system or application does not match what is required by the family of checks--i.e., Netware checks will not be run if Netware is not detected during the scan of the environment. The safest bet is to always enable everything. If a given check needs to be disabled, it should be noted as an exception with formal documentation detailing why it is disabled, and what processes are in place to ensure the vulnerability being detected is covered by other mitigating factors. The pre-assessment phase is also a good time for the CSP to document any known false positives that occur within the scan results and any operational requirements that prevent remediation from occurring.

2. Assessment

During the assessment kickoff, the CSP should be ready for the 3PAO to conduct vulnerability scans. If the CSP successfully addresses the questions in the pre-assessment phase, then any findings or issues during the assessment phase should be easy to address. There are three main areas to tackle while reviewing the scan data in the assessment past:

• Current Picture - What vulnerabilities exist in the environment as of the current date?
• Reassurance on Remediation – Are vulnerabilities continuing to be remediated in a timely manner?
• Adjustments – What changes have been taken since the pre-assessment?

Of the aforementioned three items, adjustments often have the biggest impact. Examples of adjustments that frequently occur and need to be addressed include:

• If the vulnerability scanning tool has changed
• If the scan checks have been modified
• If the personnel responsible for configuring and running the scans are no longer with the organization
• If the technologies within the environment have changed
• If the environment hosting the solution has changed

If any of these adjustments exist, the 3PAO will need to perform additional validation activities.

3. Final Scan

A final round of scans should be run by the CSP 5 to 10 days prior to the issuance of the SAR. At this point, all questions related to the personnel running the scans, the processes deployed, and the technologies implemented should be answered. The last set of scans should be limited in scope and used to show evidence of remediation activities on the vulnerabilities identified in the assessment phase. There are three primary goals related to the last piece of scan evidence:

• Targeted scans – Has a final set of scans that shows remediation of findings from the assessment phase been provided?
• Operational Requirements (OR) and False Positives (FP) – Are all ORs and FPs documented, reviewed and understood?
• Ready for Continuous Monitoring – Are there any high severity findings remaining, and is the CSP ready to provide monthly results to an agency or the Joint Authorization Board (JAB)?

High severity findings are highlighted due to their outsized impact on a FedRAMP ATO. A CSP cannot receive a recommendation for an ATO if any high severity vulnerabilities are present. Should any findings persist as of the date the SAR is issued, these findings should be tracked in the CSPs Plan of Action and Milestones (POA&M).

For additional information on the timing and handling of vulnerability scans, please see the following documents on the FedRAMP website:

FedRAMP Tips and Cues Compilation

FedRAMP JAB P-ATO Process, Timeliness and Accuracy of Testing Requirements