FedRAMP is a government-wide program meant to ensure a standardized baseline for information security throughout the cloud service providers working with the federal government.

It’s a tall order. Setting forth standards that are robust enough to cover all the bases, while being open and flexible enough to cover every CSP, is not easy. NIST has spent a very long time with a lot of experts developing the standards FedRAMP is based on, and the FedRAMP process is iterated and developed over time to get better and better at it.

Even so, there are always going to be businesses and cloud services that don’t quite fit the mold.

So, what happens when that’s the case? It would have to be one of three things.

1. The CSP is ineligible for FedRAMP authorization due to this deviation from the framework; the incompatibility makes it impossible to comply.
2. The CSP is granted authorization regardless, potentially opening up a security hole through the inconsistent implementation of the standard.
3. The CSP addresses the gap in a specific way, documents it, and applies for a deviation exemption.

Option two is obviously bad and removes the entire point of the framework. Option one is also bad, as many businesses could be perfectly secure, but by not meeting an inapplicable guideline, they can’t provide services to the government.

Fortunately, FedRAMP has a process built in for handling these cases: the deviation request process. It’s option three, and while it’s quite narrow in scope, it’s critical for the CSPs that it applies to.

What is a deviation request, when does it apply, and how do you submit such a request? Let’s run through everything you need to know.

What is a FedRAMP Deviation?

A deviation is what happens when a CSP’s architecture or operations don’t quite fit the standards and rules laid out in NIST SP 800-53 and FedRAMP itself, but can still be addressed and mitigated in an acceptable way.

They are not an excuse to use alternative methods of securing a system. Instead, they are the option available if using the normally mandatory means of securing a system would unduly hinder or break the operations of that system.

For example, if data that needs to be secured lives on an unsecured system, this will trip a flag showing a vulnerability that needs to be remediated. However, if that unsecured system is completely airgapped and inaccessible from any source, it doesn’t really matter if it’s insecure, because it can’t be reached through any means other than access-controlled visiting in person.

Normally, you would have to secure that system anyway. However, since it’s both irrelevant and could potentially hinder accessibility, you could instead submit a deviation request for the system to get it approved as-is.

When are FedRAMP Deviations Requested?

A deviation request is submitted when the deviation is discovered, analyzed, and determined to warrant a deviation.

This can be during the initial auditing process to obtain approval. More often, though, it occurs as part of continuous monitoring. Systems change and architectures evolve over time, and they all need to remain secure. If a fault is detected and needs to be explained rather than fixed, a deviation request can be submitted.

A deviation request is not used when a security control is not applicable. The N/A designation is for controls that apply to systems the CSP doesn’t have or use, not for systems that exist and are vulnerable.

Similarly, a deviation request is not a significant change request, though the two are similar requests with similar processes. A significant change request is for cases where a large-scale change is made to the CSP’s systems and needs to be reviewed.

What Are the Three Types of Deviation Requests?

Deviations from the norm in FedRAMP fall into one of three categories, and knowing which category it is becomes a critical part of requesting the deviation in the first place. The category of the fault indicates what measures need to be proven to request and be granted a deviation.

The first category is the false positive. These occur when an automated scanner finds a vulnerability, but that vulnerability is either not actually present or is not actually exploitable within your systems.

For example, if your systems are built using a specific software ecosystem and a library is flagged as vulnerable, when that library just shares a name with a vulnerable library from another ecosystem, it can be a false positive. Automated scanners don’t necessarily have context to understand when they’re wrong and can flag non-issues as vulnerabilities.

The second category is the risk adjustment. A risk adjustment is when a vulnerability is identified and does exist within your systems; however, the scanner identifies it as a higher risk than it actually is. This happens most commonly when you are aware of the risk and have taken steps to mitigate it, but can’t fix it entirely according to FedRAMP standards. You can file a deviation request in order to have the risk’s severity reduced so it doesn’t hurt your authorization.

The third category is an operational requirement. These are risks that are known and flagged in scans, but can’t be fixed without harming the CSP’s operations.

For example, if the CSP requires a specific port to be opened for access to function, but that port is commonly a vector of attack, the fact that the port is open will be flagged as a vulnerability. By proving that your CSP needs the port open, you can get a deviation granted to remain authorized despite the vulnerability.

Notably, FedRAMP will not grant a deviation request for a high-impact operational requirement. However, if you have taken steps to remediate it, you can file a simultaneous risk adjustment and operational requirement deviation request to validate that you’ve mitigated the risk as much as possible.

What Goes into a Deviation Request?

A deviation request is a multi-part process.

It starts with identifying the fault, analyzing it, and determining the need for a deviation. Many faults need remediation and can’t be waived with a deviation, so this initial analysis is extremely important.

If a fault is analyzed and it’s determined that it can’t be addressed without significant obstruction to operations, or that it’s otherwise secure and lower-risk (or even inapplicable) than a scanner shows, a deviation request can be filed.

A deviation request requires two things. First, it requires the CSP to fill out the deviation request form (XLSX link). Second, it needs to be documented in the CSP’s POA&Ms.

The deviation request form requires a lot of specific information.

• The name of the CSP.
• The name of the specific system.
• The impact level of the CSP’s authorization.
• The submission date of the deviation request.
• The name and title of the CSP’s point of contact.
• The phone number and email of the point of contact.
• The DR number and POA&M ID.
• The scan ID.
• The related CVE.
• The assets impacted by the CVE.
• The vulnerability name and source.
• The initial risk rating.
• The CVSS score.
• The original detection date for the vulnerability.
• Information from the scanning tool of the vulnerability and suggested remediation.
• Added information about the vulnerability from the CSP.
• The type of DR from the three above.
• The requested adjusted severity rating and CVSS score.
• The date of DR submission.
• The rationale for submitting the DR.
• A submission of evidence and attachments to prove the need for the DR.
• An operational impact statement of normal remediation and justification.
• Deep information on a potential attack, including the vector, complexity, privileges required, user interaction required, and impact metrics.
• Status tracking information for the DR.
• Additional comments from government entities, including the GSA, the DoD, the DHS, and others, as necessary.

You can see all of this in the DR request form under the DR Sheet tab.

Will a Deviation Request be Granted?

There’s a generally high rate of acceptance of deviation requests, but that alone is misleading. That’s because the bar to even file a deviation request is quite high. By the time you’ve reached a point of identifying that a deviation request is a possibility, you’ve likely exhausted the other options.

A deviation request needs to be submitted to your point of contact within your sponsoring agency. That individual is the one who will make the determination. After all, as a member of the government, it’s their data at risk if your vulnerability is exploited.

If the justification for a deviation request is weak, if the point of contact can identify other options for mitigation to explore that you haven’t, or if security is genuinely compromised by the fault regardless of mitigations, they can deny the deviation request.

This is not a unilateral decision, generally speaking. The entire deviation request process will require significant dialogue with stakeholders, agency contacts, and other relevant people. Everyone here is on the same side, trying to ensure the best security possible in situations where it may not be ideal to follow the letter of the law.

Generally speaking, if a deviation request is going to be denied, it’s for one of a handful of reasons.

• The justification isn’t good enough. You have to have a very valid, evidence-backed reason for wanting a deviation rather than just doing the work to fix an issue. Deviations are most commonly for false positives for this reason.
• The evidence is insufficient. Even having a valid reason can leave you hanging if you don’t have enough valid documentation to prove your claims.
• You’re trying to use a deviation request for something that isn’t a deviation, like a significant change request or a not-applicable control.

As long as you are well-documented and maintain good communication with your 3PAO and your POC within your sponsoring agency, you should be able to navigate the process effectively.

If you need assistance with documentation and evidence collection, consider exploring the Ignyte Assurance Platform. Our platform is made to track and maintain evidence and documentation across multiple frameworks smoothly and effectively. With it, you can aggregate everything from your core evidence to your POA&M status. Give us a call to see how it can work for you, with deviation requests and more.

What Happens Upon a Deviation Approval?

If the deviation request is approved, business continues as usual. The deviation is noted in the POA&Ms for the CSP and becomes part of continuous monitoring.

If, in the future, something changes in a way that the flaw is mitigated or removed, or the deviation is no longer necessary, it can then be resolved. Otherwise, it just needs to be monitored and maintained just like any other identified threat.

What Happens if a Deviation is Denied?

If you submit a deviation request and have it denied, what happens?

You have a few possibilities.

First, you can try again. As part of open dialogue with your agency POC, they’ll tell you why they rejected the request, and you can try to fix the problem if it’s relevant. For example, if you don’t have sufficient evidence to back up your position, you can gather more evidence and testing to prove it and try again.

Second, you can accept the judgment and take actions to fix the problem according to FedRAMP rules. This isn’t really applicable to false positives that often, but for risk adjustments and for operational requirements, it might take some work, but it can be done. If your agency POC believes that you can do so without undue burden, and you can’t prove otherwise, you’ll just need to put in that work.

Third, if this causes irreconcilable friction between you and your agency, there may be no option but to end the contract. If you believe and have proven that your CSP can’t operate without the fault, and that you’ve taken steps to mitigate it, but your agency believes that’s still not good enough, there’s no middle ground to be found.

Most of the time, though, you’ll be able to figure something out. Maybe there’s an approach you didn’t think of that can remediate the issue. Maybe you can find better evidence to prove the need and keep the contract.

The goal, after all, is secure operations. Your sponsoring agency doesn’t want to lose your functionality any more than you want to lose their contract. Keep working at it, and you’ll find a way to navigate the situation appropriately.

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/fedramp/fedramp-deviation-requests-submit/