什么是FedRAMP偏差？
偏差是指在云服务提供商（CSP）的架构或运营不完全符合NIST SP 800-53和FedRAMP自身规定的标准和规则，但仍能以可接受的方式进行处理和缓解的情况。偏差不是使用替代方法来保护系统的借口，而是在使用通常强制性的系统安全手段会过度阻碍或破坏该系统运营时的可用选项。
例如，如果需要保护的数据位于一个未受保护的系统中，这将触发一个需要修复的漏洞警报。但是，如果该未受保护的系统是完全物理隔离的，并且无法从任何来源访问，那么它是否安全其实并不重要，因为除了通过访问控制的现场访问外，无法通过任何方式接触到它。通常情况下，无论如何都需要保护该系统。然而，既然它无关紧要且可能妨碍可访问性，您可以提交一份偏差请求，以使该系统按原样获得批准。
何时需要申请FedRAMP偏差？
当偏差被发现、分析并确定有理由申请偏差时，即可提交偏差申请。这可能发生在为获得批准而进行的初始审计过程中。但更常见的是，它作为持续监控的一部分发生。系统会变化，架构会随着时间演变，它们都需要保持安全。如果检测到故障需要解释而非修复，则可以提交偏差申请。
偏差申请不适用于安全控制不适用的情况。N/A 指定适用于CSP没有或不使用的系统，不适用于存在且存在漏洞的系统。同样，偏差申请也不是重大变更请求，尽管两者是类似流程的相似请求。重大变更请求适用于对CSP系统进行大规模更改并需要审查的情况。
偏差请求的三种类型是什么？
FedRAMP中的偏差分为三类，了解偏差的类别是提出偏差请求的关键部分。故障的类别表明了需要证明哪些措施才能申请并获得偏差。
第一类是误报。当自动化扫描器发现一个漏洞，但该漏洞实际上不存在或在您的系统中实际上无法利用时，就会发生这种情况。例如，如果您的系统是使用特定的软件生态系统构建的，并且一个库被标记为存在漏洞，而该库只是与另一个生态系统中的漏洞库同名，这就可能是一个误报。自动化扫描器不一定具备上下文来理解它们何时出错，并可能将非问题标记为漏洞。
第二类是风险调整。风险调整是指识别出一个漏洞并且该漏洞确实存在于您的系统中；然而，扫描器将其评估为比实际风险更高的风险。这种情况最常发生在您意识到风险并已采取措施缓解，但无法完全按照FedRAMP标准修复时。您可以提交偏差请求，以降低风险的严重性，从而不影响您的授权。
第三类是运营需求。这些是已知并在扫描中被标记的风险，但如果不损害CSP的运营就无法修复。例如，如果CSP需要打开特定端口才能实现功能访问，而该端口通常是攻击向量，那么端口开放的事实将被标记为漏洞。通过证明您的CSP需要该端口开放，您可以获得偏差批准，从而在存在漏洞的情况下仍保持授权状态。
值得注意的是，FedRAMP不会为高影响的运营需求批准偏差请求。但是，如果您已采取措施进行修复，您可以同时提交风险调整和运营需求偏差请求，以验证您已尽可能减轻了风险。
偏差请求包含哪些内容？
偏差请求是一个多步骤的过程。首先需要识别故障、分析故障，并确定是否需要偏差。许多故障需要修复，不能通过偏差豁免，因此这个初步分析极其重要。如果分析后确定，不进行重大运营阻碍就无法解决该故障，或者其安全性比扫描器显示的更低风险（甚至不适用），则可以提交偏差申请。
偏差申请需要两样东西。首先，需要CSP填写偏差申请表（XLSX链接）。其次，它需要在CSP的计划与行动（POA&M）中进行记录。
偏差申请表要求提供大量具体信息，包括：
- CSP名称。
- 特定系统名称。
- CSP授权的影响级别。
- 偏差请求的提交日期。
- CSP联系人的姓名和职位。
- 联系人的电话号码和电子邮件。
- DR编号和POA&M ID。
- 扫描ID。
- 相关的CVE（通用漏洞披露）。
- 受CVE影响的资产。
- 漏洞名称和来源。
- 初始风险评级。
- CVSS评分。
- 漏洞的最初检测日期。
- 来自扫描工具的漏洞信息和建议修复措施。
- CSP提供的关于漏洞的补充信息。
- 上述三种偏差请求类型中的哪一种。
- 请求调整后的严重性评级和CVSS评分。
- DR提交日期。
- 提交DR的理由。
- 证明DR需求的证据和附件提交。
- 关于正常修复和理由的运营影响声明。
- 关于潜在攻击的详细信息，包括攻击向量、复杂性、所需权限、所需用户交互和影响指标。
- DR的状态跟踪信息。
- 政府实体（如GSA、DoD、DHS等，视情况而定）的附加评论。
所有这些信息均可在DR请求表格的“DR Sheet”选项卡中查看。
偏差请求会被批准吗？
偏差请求的接受率普遍较高，但仅凭这一点可能会产生误导。这是因为提交偏差请求的门槛本身就相当高。当您发现偏差请求是一个可能选项时，您很可能已经穷尽了其他途径。
偏差请求需要提交给您发起机构内的联系人。该联系人将做出决定。毕竟，作为政府成员，如果您的漏洞被利用，他们的数据将面临风险。如果偏差请求的理由不够充分，如果联系人能识别出您尚未探索的其他缓解方案，或者如果无论如何缓解，该故障确实危及安全，他们可以拒绝该偏差请求。
一般来说，这不是一个单方面的决定。整个偏差请求过程需要与利益相关者、机构联系人和其他相关人员进行大量对话。这里的每个人目标一致，都试图在可能无法完全遵循规则条文的情况下确保最佳的安全。
通常来说，如果偏差请求被拒绝，主要是出于以下几个原因之一：
- 理由不够充分。您必须有一个非常有效、有证据支持的理由来申请偏差，而不是仅仅为了完成修复问题的工作。因此，偏差最常见于误报情况。
- 证据不足。即使有合理的理由，如果没有足够有效的文件来证明您的说法，也可能导致请求失败。
- 试图将偏差请求用于非偏差事项，例如重大变更请求或不适用的控制。
只要您文件齐全，并与您的第三方评估机构（3PAO）和发起机构内的联系人保持良好的沟通，您就应该能够有效地推进这一流程。
如果您在文件编制和证据收集方面需要帮助，请考虑探索 Ignyte Assurance Platform。我们的平台旨在跨多个框架平稳有效地跟踪和维护证据与文件。通过它，您可以汇总从核心证据到POA&M状态的所有信息。
偏差请求获批后会发生什么？
如果偏差请求获得批准，业务将照常进行。偏差将在CSP的POA&M中被注明，并成为持续监控的一部分。如果在未来，情况发生变化，导致该缺陷得到缓解或消除，或者偏差不再必要，则可以将其关闭。否则，它只需要像任何其他已识别的威胁一样进行监控和维护。
如果偏差请求被拒绝会怎样？
如果您提交了偏差请求但被拒绝，会发生什么？您有几种可能性。
首先，您可以再试一次。作为与您的机构联系人公开对话的一部分，他们会告诉您拒绝请求的原因，如果问题相关，您可以尝试解决。例如，如果您没有足够的证据来支持您的立场，您可以收集更多证据和测试来证明并再次尝试。
其次，您可以接受该判断，并根据FedRAMP规则采取措施来解决问题。这对于误报通常不适用，但对于风险调整和运营需求，可能需要一些工作，但可以完成。如果您的机构联系人认为您可以在没有过度负担的情况下完成，而您又无法证明并非如此，您就需要投入这项工作。
第三，如果这导致您与机构之间产生不可调和的摩擦，可能除了终止合同别无选择。如果您已经证明您的CSP运营无法摆脱该故障，并且您已采取措施缓解，但您的机构仍然认为这不够好，那就没有中间地带。
不过，大多数情况下，您都能够找到解决方案。也许有您没想到的方法可以修复问题。也许您可以找到更好的证据来证明需求的必要性并保住合同。
毕竟，目标是安全的运营。您的发起机构不希望失去您的功能，就像您不希望失去他们的合同一样。持续努力，您将找到适当应对这种情况的方法。