愿你生活在有趣的时代 | MSRC 博客

作者：Adrian Stone（StoneZ）
职位：高级安全项目经理主管
发布日期：2010年7月28日
阅读时间：4分钟

两年前，我的同事 Katie Moussouris 在黑帽大会上宣布了微软漏洞研究（MSVR）计划的启动。不久后，我接手了这一新兴计划，开始将我们的目标变为现实。最初定义的主要目标听起来很简单：通过协调的方式报告由微软资源发现的漏洞，保护更大的生态系统，同时 MSVR 通过分享微软和 MSRC 的经验教训，协助其他供应商应对漏洞修复的挑战。

尽管 MSVR 的核心使命保持不变，但在计划启动后的两年中，该计划已发展到应对其他出现的挑战。我们这样做既是因为这些挑战需要解决，也因为 MSRC 的协调性质是完成任务的最佳工具。这些挑战的例子包括 MSVR 在协调其他外部安全研究人员发现的大规模跨行业漏洞方面的作用，例如 Dan Kaminsky 在 2009 年披露的 DNS 重绑定问题。微软和 MSVR 还面临了一个独特的情况，即协调修复微软自身代码中的一个漏洞，该漏洞由于 Ryan Smith 和 David Dewey 发现的 ATL Killbit 绕过漏洞而影响了整个生态系统的供应商。

MSVR 还协助向供应商报告针对其产品的零日攻击实例，这些实例是通过 MSRC 响应过程中内置的遥测和其他威胁检测资源发现的。MSVR 并非旨在充当 CERT 实体；然而，我们认为在这些情况下利用 MSVR 是必要的，因为漏洞影响了微软和其他供应商产品中的代码。

那么，我们学到了什么？首先，正如您可能预期的那样，整个生态系统中供应商的安全成熟度差异巨大。有时，仅仅在一家大公司中找到正确的组织实体或个人来报告漏洞可能是任务中最困难的部分。在其他情况下，MSVR 不得不不仅承担漏洞报告者的角色，还承担响应教育者的角色，因为供应商不知道或不确信如何以最佳方式向客户传达有关其产品中漏洞的信息。不止一次，我们遇到了类似的陈述和问题，例如“我们应该在公告中放什么？”——或者更具挑战性的是，断言“我们认为这个问题不值得发布公告或公开披露”。特别是第二种回应，需要 MSVR 耐心地向供应商解释为什么通知客户很重要。这是一项棘手的工作，但值得。

（有趣的是，在过去的两年中，很明显，没有什么比 calc.exe 更能作为通用的漏洞翻译器了。有时，所有花费在打包看似连贯和可靠的漏洞报告给供应商的人力和时间，在收到“不是漏洞”的回应时，会变成彻底的愤怒……直到 MSVR 的后续回应是弹出 calc 所需的 PoC。此后不久，MSVR 与供应商的对话似乎突然变得顺畅起来。）

我们还了解到，整个生态系统的工程流程因公司而异，每个公司都有其独特的挑战，这些挑战可能使工程修复变得复杂。因此，供应商需要的时间表因每个供应商和每个产品而异，以便他们正确修复。更直白地说，来自 MSVR（或任何其他供应商）的通用修复时间要求是不现实的。云服务供应商解决跨站脚本漏洞的速度无法与修复更传统盒装产品中客户端代码漏洞所需的时间相比。即使是由同一供应商负责易受攻击产品的盒装版本和云版本，这一说法仍然成立。

最后，我们清楚地认识到，与供应商分享关于对我们共同客户构成风险的硬数据可能是获得进展的关键。在过去的一年中，我们利用 MSRC 的遥测收集能力（包括微软内部和通过我们的 MAPP 合作伙伴关系），在我们认为我们的共同客户面临他们可能不知道的零日漏洞的真实风险的情况下，帮助向供应商提供清晰的信息。这要求我们传达清晰且经过验证的数据，供应商可以使用这些数据来更好地优先考虑和加速他们的工程流程，相对于他们必须做出的权衡。

在过去的两年中，这绝对是一段疯狂的旅程——确实是有趣的时代。在此过程中，我们解决了许多安全研究人员在向供应商报告漏洞时面临的相同问题，并且我们学到了宝贵的经验教训，这些经验教训不仅将继续使 MSVR 变得更好，而且我们可以反馈给 MSRC 的同事。我们还与整个生态系统中的其他安全响应团队和供应商，以及微软内部和外部的有才华的安全研究人员建立了更牢固的关系。

我们感谢所有选择与我们合作并在需要时提供必要帮助的研究人员和 MSVR 合作伙伴，例如 MMPC 和各种 MAPP 参与者。接下来的两年将为 MSVR 带来更大的挑战和更大的机遇，并且我相信还会带来我目前无法想象的挑战。感兴趣吗？我绝对鼓励您查看白皮书。如果您在黑帽大会现场，请访问微软展位，我们一起聊聊。

Adrian Stone