Guide: FedRAMP Requirements for Vulnerability Scanning

FedRAMP Requirements for Vulnerability Scanning
Facebook
Twitter
Pinterest
LinkedIn

FedRAMP is a key part of maintaining the digital security of the federal government, by way of enforcing security rules across departments and the cloud service providers that work with them. Any CSP that wishes to work with a federal agency or department and handle controlled information needs to obtain an authority to operate (ATO) from the program management office. Part of that ATO is the continuous monitoring of the CSP’s systems to ensure ongoing security in a changing world.

A big part of maintaining security throughout the year in between partial audits and in the three-year spans between complete reviews is vulnerability scanning. FedRAMP has a whole set of guidelines for vulnerability scanning for FedRAMP CSPs, 3PAOs, contractors, and government employees under the purview of their program. What does it include, and what do you need to do with regard to vulnerability scanning? Let’s discuss.

BLUF - Bottom Line Up Front

FedRAMP is crucial for federal digital security, enforcing security standards for cloud service providers (CSPs) through continuous monitoring and vulnerability scans. CSPs must obtain an authority to operate (ATO) and adhere to stringent requirements, including scanning systems monthly and addressing vulnerabilities based on risk levels within specified timeframes. Proper scanning ensures strong security postures, preventing audit failures and ensuring compliance. Understanding FedRAMP’s guidelines helps maintain security across federal systems and containerized environments.

What is Continuous Monitoring?

The final phase of FedRAMP compliance is continuous monitoring. Once you have your authority to operate, you must continue to monitor your systems for security. This means many things, including making sure your software is patched and updated, your user accounts are properly authenticated and restricted, information is protected and encrypted as necessary, and that you have active detection in place to notify stakeholders if there are signs of an intrusion.

What is Continuous Monitoring

Continuous monitoring is not a one-time event. As the name implies, it’s something you have implemented and maintain indefinitely while you work on government contracts and handle controlled unclassified information. We have a more detailed guide to continuous monitoring here, as well as coverage of modern initiatives like the push for Zero Trust elsewhere on this blog. If you have specific questions, we’re also a validated 3PAO, so you can reach out and ask us questions as well.

What is Vulnerability Scanning?

Vulnerability scanning is the process of scanning your systems for vulnerabilities.

What is Vulnerability Scanning

While that sounds reductive, it’s basically true. Vulnerability scanning involves the use of tools that can rapidly evaluate complex systems, using definitions created by experts, to search for the presence of vulnerabilities within those systems.

An example many people are familiar with is antivirus software. Antivirus software can scan a computer, checking every running process and every file for signs of data that match known viruses, ransomware, and other intrusion. An ideal result is 0 such malicious software detected, and if any is detected, it’s a problem that needs solving.

The biggest difference between antivirus software and FedRAMP vulnerability scanning is that antivirus software seeks to block those processes from running or stop them if they’re already present, but it does not search for the vectors by which those malicious programs arrived.

Vulnerability scanning is like going through an immense security checklist and looking for specific information that matches a vulnerability. For example, it might:

  • Check all software plugins to see if they are enabled or disabled as relevant, and make sure they’re up to date.
  • Check for known vulnerabilities in software or frameworks to ensure that they’re patched. This could be software updates, Windows updates, configurations in firewalls, and more.
  • Checking for valid encryption across data at rest and data in transit.
  • Checking user accounts for appropriate permissions levels.

Different kinds of vulnerability scans might look at different aspects of your overall security, and together, they can form a comprehensive picture of any known or unknown gaps in security that need monitoring or remediation. Not all vulnerabilities can be closed, but they need to be known and, if possible, fixed.

Why is Vulnerability Scanning Important?

Vulnerability scanning is critical for several reasons.

Why is Vulnerability Scanning Important

The first is that it’s a key part of the security controls you need to adhere to at all levels of FedRAMP security. Failure to maintain appropriate vulnerability scanning not only leads to a failure of an audit but can even prevent earning your ATO in the first place. In fact, it’s one of the most common reasons why ATOs are denied, despite how relatively easy it is to implement once you know what’s going on.

The second reason is that it’s a good, automated way to ensure ongoing security. Vulnerability scanning is generally not a manual process. You don’t have someone going through each and every user account and reviewing their permissions; you have a scanning app that builds a list and checks it against known use cases.

Another reason is that vulnerability scanning can be a pivotal part of achieving a good security posture in the first place. It can help you identify holes that need to be addressed along the way. It’s also a key piece of data to give to your 3PAO when you’re expecting a security assessment, whether it’s your final audit or a progress report.

A failed scan is not necessarily grounds for a failed audit so long as you rapidly address the issue when it’s discovered. After all, the world of information security is constantly changing, new zero-day exploits are discovered and abused on a regular basis, and we can’t predict the future. Being proactive as well as reactive is necessary to be successful.

What are the FedRAMP Requirements for Vulnerability Scanning?

The FedRAMP program management office maintains a vulnerability scanning requirements guide. This guide can (for now) be found here. It is currently on version 3.0, updated in February of 2024 as of this writing. Depending on when you’re reading this article, you may want to check to see if anything has changed since. If it has, feel free to let us know to update this guide as well.

What are the scanning requirements as laid out by FedRAMP?

What are the FedRAMP Requirements for Vulnerability Scanning

Security control RA-5a-d stipulates that CSPs must:

  • Scan all operating systems, web applications, and databases monthly and send reports to their Reviewer
  • Mitigate all discovered high-risk vulnerabilities within 30 days
  • Mitigate all discovered moderate-risk vulnerabilities within 90 days
  • Mitigate all discovered low-risk vulnerabilities within 180 days
  • Send their Reviewer updated scan reports (called artifacts) every 30 days as proof of mitigate

There are more specific guidelines in the FedRAMP Low, FedRAMP Moderate, and FedRAMP High security control guides.

There are also additional expansions of the requirements present in the vulnerability scanning guide.

You must perform appropriate types of scans. Operating systems, web applications, and databases must be scanned at least monthly. In most cases, you must scan the entire inventory. In cases where your total inventory is too large, an approved statistical sampling can be used instead.

Vulnerability scanners must be resilient. Scanning apps must themselves be hardened against unauthorized use or modification. Additionally, you must provide evidence that the configuration settings of your vulnerability scanner are approved by a 3PAO and have not been altered since. If a configuration change is required, it must be approved before you can use it.

Vulnerability scanners must be updated. Much like how an antivirus program needs to have a list of virus definitions to check against, your scanning app must have updated vulnerability signature lists and proof that it checks for that list before scanning.

Scans must be authenticated for FedRAMP Moderate and High reports. An unauthenticated scan is performed by an app with no special credentials or permissions. Since Moderate and High baseline systems are gated behind credentials, unauthenticated scanning apps can’t view and scan them. Therefore, to scan them properly, the scanning app itself must have access via credentials. Most good scanning apps have a built-in way to do this.

Scan results must be formatted to be machine-readable. This is also something that modern scanning programs do automatically. Since a single comprehensive vulnerability scan can have thousands of lines of results at minimum, it’s near-impossible for humans to comb through the results. To ensure that they’re useful, the scan results need to be machine-readable so that Reviewers and 3PAOs can analyze them using their own review apps. Acceptable formats can vary but are most typically CSV, JSON, or XML. This requirement also stipulates that, where the choice of format is available, you must pick the one that provides the greatest amount of information.

NVD reference numbers must be included where applicable. The National Institute of Standards and Technology maintains a database of common vulnerabilities and exposures called the NVD or National Vulnerability Database. If and when your scanning results find a vulnerability, it must cross-reference that vulnerability with the database. If the vulnerability is present in the database, your scan report must include the reference number of the vulnerability as part of the results.

Scan results must use accepted risk scoring where applicable. When we talk about a risk having high, moderate, or low impact risk, those aren’t arbitrary distinctions. NIST provides a scoring system called the Common Vulnerability Scoring System, or CVSS. Any vulnerability that has a score in CVSSv3 must have that score assigned. If no V3 score exists, a V2 score should be used instead; if no score at all is available, your scanner app will generally assign a score to use.

Scan results must have adequate asset identification. Each inventory item, system, and service must have a unique asset identifier that is used both for your inventory tracking and for validating scans against those items. This is not just a data-tracking requirement; it’s a practical tool so that when an issue arises, you can trace it to the specific affected system without having to flail around looking for it first.

Every detected vulnerability needs a POA&M entry. The POA&M, or Plan of Action and Milestones document, is your general guide toward reaching a fully validated security posture. If there are ever gaps in your security control implementation, and they aren’t severe enough to immediately fail an audit or deny an ATO, they can be addressed through a POA&M. This document lays out what the vulnerability is, its severity and impact, and your timeline for remediating it, as well as the stakeholder in charge. We have plenty of information on POA&Ms elsewhere on this blog, and of course, we can answer questions you may have if you contact us directly.

Of note is that if a single vulnerability is large, complex, or multifaceted (such as one type of vulnerability affecting multiple systems in different ways, each requiring its own remediation process), it can be broken into several POA&M line items. Conversely, multiple vulnerabilities cannot be grouped into a single POA&M item.

All non-destructive testing must be enabled. Scanners often allow you to pick a scope and list of scans to perform. For your validated monthly scans, you must have all non-destructive scans enabled. Partial scans for internal use don’t carry this requirement.

Systems that use containers need to be scanned as well. For a while, there was a gap in the requirements for containerized systems. Understanding how scanning requirements and vulnerabilities worked within containerized systems was complex, so FedRAMP released additional rules in their latest guidelines to clarify the requirements. The vulnerability scanning requirements document goes into greater detail on these requirements in the fourth section. In summation:

  • Containerized systems still need to be scanned and secured.
  • Containers need to use hardened images, according to NIST benchmarks.
  • CSPs must develop a built-test-orchestration pipeline for designing, testing, and deploying containerized systems.
  • All elements of a containerized system need to be scanned prior to deployment according to FedRAMP security control guidelines.

There’s more to it as well, but it largely boils down to “your containers and images must be scanned and secure, they aren’t exempt from the rules because they’re semi-isolated.”

Let Us Help

At Ignyte, we have a lot of ways we can help you out with this whole process. As a CSP ourselves, we’ve been through the ATO process. As a 3PAO, we know what is involved in audits and scan validation.

Let Us Help

While we don’t provide a vulnerability scanning app ourselves, we can help you choose one that works best for you and consult with you in other ways. Simply drop us a line, and we can chat about your needs, our services, and where the two meet. We can’t wait to work with you!

Stay up to date with everything Ignyte