When we talk about scans, tests, and authorization in the context of StateRAMP assessment, we tend to think that the process (and all its moving parts) are relatively stable and predictable. And, for the most part, this thinking is correct. However, it’s normal, and in some ways expected, to run into issues where scans and tests return problems that can halt a StateRAMP authorization process–even if there isn’t a clear and unmitigated system failure. These instances fall under the category of a vulnerability deviation, and cloud service providers have a path toward working around these issues and gaining their StateRAMP ATO.

What Are Vulnerability Deviations?

When an organization fails an assessment, there could be several reasons to point to. While the most straightforward explanation is a simple failure or discrepancy in that system, the reality is that many providers will undergo some sort of preparation before being assessed. This means that surprises should be rare. 

In other cases, organizations may face issues with their audits–namely, that disqualifying vulnerabilities are part of a risk or operational infrastructure, or they simply aren’t real. 

These potential issues include:

• False Positives: False positives can occur when a system misreports critical information or if a scanner processes data incorrectly. These can occur if there are configuration issues with the scanner, if the scanner is out of date, or if there are compatibility issues between the scanner and system components.
  
• Operational Requirements: Sometimes, vulnerabilities pop up in systems that must remain operational for logistical or business reasons.
  
• Risk Reduction: A vulnerability may exist only because of specific component configurations and interactions, such that with a reduction in the risk present for that system through changing component interactions.

Thus, the StateRAMP PMO provides a Vulnerability Deviation Request form, where the provider may ask why they have a specific vulnerability in place and why they are not changing the component with the vulnerability. 

Examples of Risk Reduction for Vulnerability Deviations

“Risk reduction” might seem like a confusing approach to vulnerability deviation. Essentially, this process refers to the organization taking steps to minimize or eliminate the impact of a vulnerability on sensitive data.

Some examples of this process might include:

• Limiting Access to Vulnerable Systems: A component may only introduce vulnerabilities within a regulated system if connected to the Internet or a Local Area Network (LAN). If the provider limits or removes network access to this component in such a way as to remove the threat to protected data, then there is an argument that authorization may continue without remediating the issue directly.
  
• Disable User Interactions: If a specific interaction, or set of interactions, is required to trigger a vulnerability, the provider can disable those interactions and argue that the vulnerability is no longer an issue for authorization.
  
• Complexity: If a vulnerability is 100% exploitable typically, but implemented in an environment that reduces or eliminates that exploitability, the organization may argue to avoid remediation or removal.
  
• Privileges: If a vulnerability is 100% exploitable, but is only accessible by high-level, trusted privileges or administrators, then there is an argument that the vulnerable component can remain.

How to Address Failures in StateRAMP Authorization Due to Vulnerabilities

If there are actual vulnerabilities that may disqualify your organization from StateRAMP authorization, there are a few ways to address those issues based on the situation:

Vulnerability Deviation

If you’re vulnerable, system components are in a place where you can:

• Demonstrate a false positive,
• Serves a business-critical function, and/or
• Can be mitigated through risk reduction

Then you can complete the StateRAMP Vulnerability Deviation Form and outline the reasoning for your vulnerability and your approach to its continued existence.

Legitimate Vulnerability Issues

If your infrastructure has vulnerabilities you have no reasoning or support for, the bottom line is that they must be rectified before you can gain StateRAMP authorization. To begin solving issues, there are some key approaches you must take:

• Forensic Investigation: Because a failed bid for authorization should never occur due to a surprising lack of basic functionality or technology, it’s more likely than not then something more complex is at work. It’s critical to understand the nature and impact of a vulnerability. Forensic investigations, derived from scanning results and audit logs, can help you accomplish this task.
  
• Conduct Additional Scans and Tests: After remediating issues, always conduct rigorous and comprehensive scans of the offending components. Don’t skimp on this or put on kid gloves–you must know the component is compliant before you attempt remediation and another round of authorization.
  
• Map Scanning Methods with Government Standards: Ensure that your scanning approaches align with the standards of the StateRAMP PMO, which are derived from federal standards associated with FedRAMP. This includes ensuring that scanning technology has the proper authorizations in place, that they are updated correctly, and that they are scanning the right components.
  
• Hire Dedicated Compliance Officers: Technically-minded executives or managers will help your organization better track and manage vulnerabilities (and risk mitigation) effectively without having to deploy ad hoc solutions. In turn, you’ll find your company making better progress towards compliance and authorization rather than putting out new fires as soon as the old ones are extinguished.

Is a Vulnerability Deviation the Same as a Plan of Action and Milestones (POA&M)?

The short answer is no. a POA&M is a document created by the CSP and their 3PAO for the StateRAMP PMO to map out a plan for remediating security issues during continuous monitoring. The idea is that when these issues are remedied, the organization would otherwise be authorized to operate, but they aren’t severe enough to require an entirely new assessment. Therefore, the organization is authorized with the understanding that it will quickly and effectively fix any issues in the POA&M.

On the other hand, vulnerability deviations are issues the provider has a vested interest in (risk-based, operational, or false positive) in not remediating. As such, they are arguing that they have, or can, make immediate changes to the issue to allow for authorization without removing the vulnerable component entirely.

Avoid Vulnerability Issues in StateRAMP Authorization

StateRAMP certification isn’t a one-time effort. It calls for continuing adherence to rigorous security standards that can evolve to meet the challenges of also-evolving threats. That’s why CSPs should rely on the expertise and tools of their 3PAO partners to streamline and automate continuous monitoring and ensure compliance and security every year. 

If you or your CSP partner need an experienced and certified 3PAO to support your ongoing StateRAMP or FedRAMP continuous monitoring, contact Lazarus Alliance at 1-888-896-7580 or contact us through the form below.