安全缓解措施部署前的关键考量与最佳实践
大家好，
在我从事漏洞研究和在Project Zero工作的这些年里，我经常遇到新的安全缓解措施的提案。其中一些很棒，而另一些则不尽如人意。
现实情况是，大多数缓解措施或“加固”功能都会对某些人或某些地方施加负担，而且很可能是沉重的负担。许多安全人员没有太多运行可靠基础设施的经验，他们的一些解决方案可能会以相当繁琐的方式在生产环境中破坏事物。
更糟糕的是，许多缓解措施的提出和实施都是基于非常模糊和非科学的理由——“它使攻击更难”、“提高了门槛”等等，这使得第三方难以或无法理解设计过程中考虑的设计和权衡。
多年来，我反复抱怨这一点，尤其是在这条Twitter推文中：
https://twitter.com/halvarflake/status/1156815950873804800
这篇博客文章实际上只是对Twitter推文的复述：
以下是我之前为好的缓解措施写下的规则：“在部署缓解措施之前…
为缓解措施编写设计文档，明确说明其旨在实现的目标。理想情况下，这应该是诸如‘使像CVE1、CVE2、CVE3这样的漏洞无法被可靠利用’之类的声明；类似‘使其更难’的声明难以量化。如果无法避免此类陈述，请量化它们：‘确保针对像CVE4、CVE5这样的漏洞开发利用程序需要超过N个月的时间’。 选择一些历史漏洞（最好来自设计文档），并邀请具有扎实漏洞开发经验的人员；给他4-8个完整的工程周，尝试在利用历史漏洞时绕过缓解措施。看看缓解措施是否有效，以及有效的程度。大多数情况下，结果会是缓解措施未能达到承诺。这是好消息：你避免了给所有人施加负担（在复杂性、可用性、性能方面），而这些负担没有提供或提供了不足的好处。
在编写缓解措施的代码时，尤其是当它涉及内核组件时，进行非常严格的代码审查并保留审查历史。审查者应质疑任何不必要的复杂性并要求澄清。遵循良好的编码原则——避免名称中不可见的具有隐藏副作用的函数——代码审查的严格性至少应与挑剔的C++可读性审查者相匹配，甚至超过它。”
还有这三张幻灯片要记住：
简而言之：让人们容易理解缓解措施背后的设计原理。确保这一设计原理既易于理解，又易于辩论/讨论。在声明中要精确和可量化，以便人们可以根据其声称的优点来挑战缓解措施。
发布者：halvar.flake
时间：上午9:00
无评论：
发表评论
较新的文章
较旧的文章
首页
订阅：文章评论（Atom）
博客归档
►
2025 (6)
►
七月 (2)
►
五月 (1)
►
四月 (2)
►
三月 (1)
►
2024 (4)
►
十二月 (1)
►
七月 (2)
►
一月 (1)
►
2023 (1)
►
十二月 (1)
►
2021 (1)
►
二月 (1)
▼
2020 (4)
►
九月 (1)
►
八月 (1)
►
五月 (1)
▼
三月 (1) 在部署“安全缓解措施”之前…
►
2019 (1)
►
八月 (1)
►
2018 (3)
►
十月 (1)
►
三月 (1)
►
二月 (1)
►
2017 (1)
►
八月 (1)
►
2016 (3)
►
十月 (1)
►
九月 (1)
►
一月 (1)
►
2015 (3)
►
十二月 (2)
►
五月 (1)
►
2014 (2)
►
一月 (2)
►
2013 (3)
►
六月 (1)
►
三月 (1)
►
一月 (1)
►
2012 (1)
►
七月 (1)
►
2011 (2)
►
九月 (1)
►
三月 (1)
►
2010 (3)
►
三月 (1)
►
二月 (1)
►
一月 (1)
►
2009 (17)
►
十二月 (1)
►
十一月 (3)
►
十月 (1)
►
九月 (2)
►
八月 (1)
►
七月 (4)
►
三月 (2)
►
二月 (1)
►
一月 (2)
►
2008 (34)
►
十二月 (2)
►
十一月 (5)
►
十月 (4)
►
九月 (1)
►
七月 (8)
►
六月 (4)
►
四月 (6)
►
三月 (2)
►
二月 (1)
►
一月 (1)
►
2007 (17)
►
十月 (1)
►
九月 (2)
►
八月 (3)
►
七月 (5)
►
六月 (1)
►
四月 (1)
►
三月 (1)
►
二月 (2)
►
一月 (1)
►
2006 (47)
►
十二月 (1)
►
十一月 (4)
►
十月 (2)
►
九月 (2)
►
八月 (3)
►
七月 (7)
►
六月 (5)
►
五月 (8)
►
四月 (8)
►
三月 (2)
►
二月 (4)
►
一月 (1)
►
2005 (10)
►
十二月 (4)
►
十一月 (1)
►
九月 (1)
►
八月 (4)
关于我
halvar.flake
查看我的完整个人资料
链接
Off Convex
由Blogger提供支持。