在从事漏洞研究和Project Zero工作的多年中，我经常遇到新的安全缓解措施提案。其中一些很棒，另一些则不尽如人意。

现实是，大多数缓解措施或“强化”功能都会对某些人或某些地方施加负担，甚至可能是沉重的负担。许多安全人员缺乏运行可靠基础设施的经验，他们的解决方案可能会以相当麻烦的方式在生产环境中破坏事物。

更糟糕的是，许多缓解措施的提出和实施基于非常模糊和非科学的理由——“它使攻击更难”，“提高了门槛”等，这使得第三方难以或不可能理解设计及其权衡。

多年来，我反复抱怨这一点，尤其是在这条Twitter推文中：

https://twitter.com/halvarflake/status/1156815950873804800

这篇博客文章实际上只是对Twitter推文的复述：

以下是我之前为好的缓解措施写的规则：“在发布缓解措施之前…

为缓解措施编写设计文档，明确说明其预期实现的目标。理想情况下，这应该是诸如‘使像CVE1、CVE2、CVE3这样的漏洞无法被可靠利用’之类的声明；像‘使其更难’这样的声明难以量化。如果无法避免此类陈述，请量化它们：‘确保针对像CVE4、CVE5这样的漏洞开发利用程序需要超过N个月’。

选择一些历史漏洞（最好来自设计文档），并邀请具有扎实漏洞开发经验的人员；给他4-8个完整的工程周，尝试在利用历史漏洞时绕过缓解措施。看看缓解措施是否有效，以及有效的程度。大多数情况下，结果会是缓解措施未能达到承诺。这是好消息：你避免了给所有人施加没有或不足够好处的负担（在复杂性、可用性、性能方面）。

在编写缓解措施代码时，特别是当它涉及内核组件时，进行非常严格的代码审查并保留审查历史。审查者应质疑任何不必要的复杂性并要求澄清。遵循良好的编码原则——避免名称中不可见的具有隐藏副作用的函数等——代码审查的严格性应至少匹配挑剔的C++可读性审查者的严格性，如果不是超过的话。”

还有这三张幻灯片要记住：

简而言之：让人们容易理解缓解措施背后的设计原理。确保这个设计原理既易于访问，又易于辩论/讨论。在声明中要精确和可量化，以便人们可以根据其宣称的优点来挑战缓解措施。