在您发送“安全缓解”之前

大家好，在我做漏洞研究的这些年里，以及我在零项目中的时间里，我经常遇到关于新的安全缓解措施的建议。有些很棒，有些不太好。现实情况是，大多数减税或强化功能都会在某个地方对某人征收税款，而且很可能是一笔重税。许多安全人员没有运行可靠基础设施的丰富经验，而且他们的一些解决方案可能会以相当繁琐的方式破坏生产中的事情。更糟糕的是，许多缓解措施的提出和实施都带有非常简单和非科学的理由-它使攻击变得更加困难，它提高了标准，等等，使得第三方很难或不可能理解设计过程中考虑的设计和权衡。多年来，我曾多次抱怨这一点，尤其是在这个推特帖子中：https://twitter.com/halvarflake/status/1156815950873804800这篇博客帖子实际上只是推特帖子的重述：以下是我不久前为有效缓解而写的规则：“在你发布缓解之前……。

有一份缓解措施的设计文档，明确声明要实现什么目标。理想情况下，这应该是使CVE1、CVE2、CVE3或类似的错误不可能得到可靠利用；像这样的声明使其更难量化。如果您无法避免这类陈述，请量化它们：确保针对CVE4、CVE5等缺陷开发漏洞需要超过N个月的时间。

挑选几个历史错误(最好是从设计文档中)，并让具有扎实的漏洞开发经验的人参与进来；给他4-8个完整的工程周时间，以便在利用历史错误时尝试绕过缓解。看看缓解是否有效，在多大程度上有效。在大多数情况下，结果将是缓解措施没有兑现承诺。这是个好消息：您避免了向没有提供或没有提供足够好处的每个人征税(在复杂性、可用性、性能方面)。

在编写缓解代码时，*尤其是*当它涉及内核组件时，要有非常严格的代码审查和审查历史记录。审查者应该质疑任何不必要的复杂性，并要求澄清。遵循良好的编码原则-避免具有从名称中看不到的隐藏副作用的函数，等等-代码审查的严格性至少应该与挑剔的C++可读性审查器的严格性相匹配，如果不超过它的话。“。

简而言之：使人们更容易理解缓解措施背后的设计原理。确保此设计原理既易于理解，又易于辩论/讨论。在你的主张中要精确和可量化，这样人们就可以对它所宣称的优点的缓解提出质疑。