协调漏洞披露：平衡安全与披露的艺术
今天，在MSRC博客上，可信计算安全总经理Matt Thomlinson宣布了微软关于协调漏洞披露（Coordinated Vulnerability Disclosure, CVD）的新理念。我想提供一些背景和历史，说明这一理念是如何形成的。这篇文章旨在改变微软谈论一些熟悉披露概念的方式，并作为微软希望与研究者互动方式的介绍。我们在此与社区展开对话，并欢迎您的反馈。
负责任披露（Responsible Disclosure, RD）和完全披露（Full Disclosure, FD）——每个人都有观点，每个人都认为自己的方式是保护用户安全的最佳方式。作为背景，大多数厂商定义的RD一般是指问题被私下报告给厂商且不向其他人透露，直到厂商发布补丁。相比之下，FD的支持者同时向所有人提供所有漏洞细节，这一举措旨在促使厂商更快提供更新。
不用说，包括微软在内的大多数厂商都支持RD，而发现者则分布在从FD到RD的整个光谱上。最终，我们都是虚拟安全团队的一部分，共同目标是使互联网更安全并保护使用它的人们——提醒大家我们属于同一团队是好事，即使我们意见不同，也应保持对话开放。
协调漏洞披露这一术语最初是由OpenSecurityFoundation.org的Jake Kouns介绍给我的，当时我在RSA关于负责任披露的小组讨论后与他进行了深入交谈。WeldPond（又名Chris Wysopal，Veracode的首席技术官）最近发推文说：“我们需要开始将与厂商合作称为‘协调披露’。我同意‘负责任’这个词太有负担了。”
使名称更具描述性的概念对我来说非常合理，因为“负责任”一词对许多人来说可能是主观的。甚至最初标题为“负责任漏洞披露”的ISO草案标准现在称为“漏洞披露”，这表明研究者、厂商和（天哪！）甚至政策制定者都同意旧术语更主观。
RD的意图是设计一种公平的方式，在研究者和厂商之间就漏洞报告和解决进行谈判。然而，这导致了厂商和发现者之间的许多辩论。那么，我们如何超越这一辩论，提供更好的解决方案？
负责任披露应被弃用，转而专注于完成任务，即提高安全性并保护用户和系统。因此，微软要求研究者与我们合作，采用协调漏洞披露，并在厂商提供的补丁可用之前，当活跃攻击进行时，增加了一些协调公开披露的可能性。它使用野外攻击作为触发条件来切换模式，这是一个可以由许多独立来源客观观察到的事件。
毫无疑问，CVD基本上建立在负责任披露的初始前提上，但如果野外开始攻击，则采用协调公开披露策略。也就是说，重新框架中的关键是协调和共享责任在漏洞披露的性质和公认实践中扮演的增强角色。在不断变化的威胁环境中，理解这一点至关重要，我们都接受不再有一个个人、公司或技术能够解决在线犯罪挑战。
以下是我们设想的协调漏洞披露的简单原则。
步骤1：保持私有，保持安全
- 报告：将问题报告给厂商，或报告给CERT-CC或您信任的其他协调者，他们将私下报告给厂商，或将其出售给会这样做的服务。
- 沟通和时间表：在CVD下，与RD相同，发现者和厂商应尝试就修复问题的时间表达成一致。复杂情况可能需要更长时间修复，微软将尽可能透明地与发现者分享我们的调查，让他们知道我们在调查和解决过程中的位置。我们感谢发现者在与我们分享信息时保持灵活，说明为什么修复可能需要比发现者认为的更长的时间。
- 状态更新：同样在传统负责任披露中，在CVD下，微软将提供及时更新和解决目标日期，以便发现者了解案例状态。
- 当厂商完全不响应时的FD替代方案：在某些情况下，厂商可能不愿意或无法响应漏洞报告，这就是提前安全公告的用途——发布有限细节且没有概念验证的公告，加上缓解措施和变通方法。发现者可以尝试这种方法，然后再 resort 到发布完整细节。有些漏洞不容易适用于这种方法，但关键是尝试。
步骤2：加快速度并等待
厂商和许多发现者知道必须在速度和质量之间取得平衡。对于微软来说，即使1%的测试失败率也可能影响数百万客户，因此我们像测试以确保更新全面解决漏洞一样认真对待功能影响测试。
理想情况下，厂商和发现者都应勤奋工作，找到保护客户安全的解决方案。如果发现者只对攻击工作感兴趣，那也没问题，只要他们给厂商一个机会进行调查、工程和测试。
在更新上合作，分享想法，并测试彼此的想法是明智的。
当研究者提供关于如何缓解甚至完全修复问题的想法时，这很好，但厂商处于最佳位置进行所需的集成测试和应用程序兼容性测试，因为他们了解自己的产品和客户所需的完整测试矩阵。
当我们与发现者关系良好时，微软通常会向发现者提供我们提议的解决方案，以查看它是否从安全角度全面解决漏洞。
如果发现者选择，我们愿意提供机会，让他们与我们分享他们提议的修复，如果我们想测试与其他产品的安全性和应用程序兼容性，或通常在我们客户机器上找到的产品。
简单漏洞类（如缓冲区溢出）的安全测试通常非常快。更复杂的攻击，依赖于多步利用过程，或具有多个向量到达易受攻击代码的漏洞需要更多的安全测试时间。如果安全测试是厂商唯一要做的事情，我们就不会有那么多时间分歧。
其他测试时间将取决于更新所触及功能的复杂性、产品的使用方式以及其他产品与受影响产品的集成方式。
步骤3：协调公开披露
协调公开发布 ideally 发生在厂商发布更新时。在公开可验证的活跃攻击情况下，细节可能在更新发布之前发布，重点是向保护提供商提供细节。
如果野外有活跃攻击，发现者和厂商合作寻找最佳临时解决方案。 厂商和发现者就告诉用户采取什么行动保护自己达成一致。
对于仍然认为完全披露是保护用户最佳方式的发现者，我们 respectfully 不同意，但如果您愿意，我们仍然希望与您合作。我们鼓励支持FD的人仍然联系我们，因为我们可以尝试与可用的保护措施协调信息发布。当然，我们仍然认为这不是最佳方法，因为绝大多数客户只会通过更新得到保护——但我们相信即使这种协调水平也绝对比没有好。
例如，CVD是当我们是发现者时处理事情的方式。当微软发现者发现第三方产品中的问题时，他们可以使用微软漏洞研究计划（MSVR）向厂商报告问题。如果野外开始攻击，我们可能会通过微软主动保护计划（MAPP）向AV/IDS/IPS提供商发布漏洞细节，或在易受攻击的Active X控件情况下发布第三方killbit。我们将在所有情况下尽可能与受影响厂商协调。
所以这就是协调漏洞披露的 nutshell——对负责任披露的重新命名，提供了期望和过程，供微软和研究者合作，而不会让任何一方用一个容易被误解的术语混淆讨论，即使在披露理念可能不完全一致的情况下。我们甚至希望尽可能与完全披露支持者合作，在攻击者之前武装保护提供商。
这里并未涵盖披露中的所有角色，因此请 stay tuned 更多内容，因为我们收集社区的反馈。我要感谢以下个人和组织对这一概念的审查，并欢迎社区（包括研究者、厂商、协调者和用户）的进一步评论。-Katie Moussouris
Jake Kouns, Open Security Foundation Steve Christey, CVE Editor, MITRE Avishai Avivi, Juniper Networks Bruce Monroe, Intel PSIRT Pete Allor Toshio Miyachi, JPCERT Coordination Center Brian Martin, Tenable Network Security Art Manion, CERT Coordination Center Damir Rajnovic (Gaus), Cisco Dan Kaminsky, Chief Scientist, Recursion Ventures Mike Caudill, Cisco PSIRT Jeremiah Grossman, WhiteHat Security Jayson Jean, iDefense-VeriSign Ryan Permeh, McAffee Cassio Goldschmidt, Symantec Arturo ‘Buanzo’ Busleiman, Buanzo Consulting / ArCERT and ONTI Security Advisor Andy Steingruebl, PayPal Dino Dai Zovi, Independent Security Researcher, Trail of Bits Chris Wysopal, CTO Veracode