摘  要：当前漏洞的数量快速增长，危险级别不断提升。为了有效降低用户面临的风险，应深入研究美国国家电信和信息管理局和 FIRST（公共漏洞披露平台的管理者）颁布的《漏洞多方协同披露指南与实践》，从机制、举措方面总结指南与实践在不同情况下对漏洞协同披露的流程，归纳产生的原因及有效的应对措施，并结合我国的实际情况提出相应建议。

　　0

　　引言

　　目前，活跃的开源开发社区、bug 奖励计划的激增、供应链的日趋复杂，使得包含漏洞的部件存在多个产品共用的情况，影响范围极广，对漏洞的披露和修复带来巨大的挑战。已有的对漏洞协同披露主要依靠研究人员和供应商的直接沟通，存在覆盖范围不全、修复不及时等问题，使漏洞暴露的时间窗口加大，给用户带来巨大的安全隐患。现今，漏洞的披露迫切需要日益复杂的多方协同，像 Heartbleed 这样的漏洞进一步凸显了对多方协同披露的挑战[1]。

　　美国作为互联网的缔造者和众多权威漏洞披露平台的所在国，国家电信和信息管理局（NTIA）、事件响应和安全团队联盟［FIRST，公共漏洞披露平台（CVE）的管理者］在参考已有的披露机制基础上，如多方利益相关者共同披露[2]、CERT 的协同披露指南[3]、ENISA 的漏洞披露最佳实践指南[4]、ISO/IEC 的漏洞披露标准[5]、NIAC 的漏洞披露指南[6] 等，重点考虑供应链各元素如何在漏洞披露过程中的协同处理，共同颁布了《漏洞多方协同披露指南》[7]（以下简称“指南”）。它是管理者共同努力解决多方协同披露挑战的结果，目的是帮助改善并建立不同利益相关者间的多方漏洞协同披露机制。该指南考虑了不同情况下漏洞的协同披露场景。

　　本文从相关概念及定义、基础性工作、不同场景下披露流程等方面对《漏洞多方协同披露指南》进行梳理及分析研究，并对如何指导我国漏洞管理工作提出相关的建议举措。

　　1

　　多方协同披露的相关概念及定义

　　在协同披露的流程中，不同参与者发挥的作用和需要采取的动作存在差异，因此对披露流程中其涉及的角色、动作等相关概念根据 ISO/IEC 29147:20143 中提供的定义做了最小程度的修改。

　　* 公告：声明或公告，用于通知、建议和警告产品的漏洞。

　　* 协调人员：可选参与者，可协助产品供应商和漏洞发现者处理和披露漏洞相关信息。

　　* 防御者：负责防御攻击的利益相关者。防御者可以是系统管理人员、供应商或防御技术及服务的提供者。防御者可以检测易受攻击的系统，对攻击进行检测和响应，并执行对漏洞的修复及管理。

　　* 披露：最早向不被认为存在漏洞的一方提供漏洞信息的行为。整个披露过程通常包括多个披露事件。

　　* 暴露：从发现漏洞到无法再利用漏洞之间的时间。

　　* 发现者：识别产品或服务中潜在漏洞的个人或组织。例如，发现者可以是外部安全研究人员。

　　* 缓解措施：降低漏洞被利用的可能性或可利用范围的措施。

　　* 修复：补丁、修补、升级、配置或文档变更，以移除或缓解漏洞。

　　* 供应商：开发产品、服务或负责维护产品的个人或组织。

　　* 对等供应商：处于供应链同一层级的供应商。对等供应商可以是相同技术（例如，OpenSSL 和 GnuTLS）的独立实现者或相同上游技术（例如，Red Hat 和 SuSE）的下游用户。

　　* 上游供应商：向下游供应商提供产品或技术的供应商。

　　* 下游供应商：从上游供应商处获得产品或技术并用于下游供应商的产品、技术或服务的供应商。

　　* 漏洞：软件、硬件或服务中可被利用的脆弱点。

　　众多利益相关角色之间的关系和通信路径如图 1 所示。

　　图片

　　图 1　利益相关角色及通信路径

　　2

　　多方协同披露的基础

　　指南讨论了多方协同披露的实例，归纳起来，多方协同披露需要在统一的共识、遵循相关的原则、降低漏洞暴露的时间窗口、合理设定协调人员的介入时机等基础上，对漏洞的协同披露做出及时的响应。

　　2.1　达成统一的共识

　　所有参与披露各方，特别是供应商，应建立并公布可采取行动的公开漏洞系统披露策略及预期，包括披露的时间表和阈值。各方应保持对等方和其他潜在利益相关者群体的危机意识。

　　供应商应预先建立上游和下游供应商关系和沟通渠道，以了解潜在影响和统一的协同披露时间表。此外，还应考虑跟踪第三方组件的使用情况，以更好地开发库存并了解上下游间的依赖。

　　2.2　漏洞披露应遵循的原则

　　漏洞披露前，各方的沟通应遵循以下原则。

　　第一，参与披露的各方应清楚、安全地沟通和协商预期和时间表。

　　第二，供应商应提供当前可接受的联系机制。

　　第三，参与披露的各方应对每一次沟通进行确认。

　　第四，供应商或协调人员应与发现者保持频繁沟通，包括状态披露时间表的状态更新和潜在影响。

　　第五，漏洞发现者应提供清晰的文档和工具，以支持漏洞验证。第五，漏洞发现者应提供清晰的文档和工具，以支持漏洞验证。

　　第六，供应商应明确记录产品支持的时间表和限制。

　　第七，各方应避免个别通信故障点。

　　在漏洞披露后，各参与方应遵循以下原则。

　　第一，供应商应以人工和机器可读格式提供与漏洞保护和缓解措施相关的明确建议和公告。

　　第二，除了通过通用电子邮件进行沟通，供应商还应为上游和下游利益相关者确定专门的联系方式。如果需要，供应商应利用协调人员进行广泛的沟通和协调。

　　第三，各方应利用通用漏洞的跟踪和聚合能力，如 NIST 国家脆弱性数据库（NVD）和通用漏洞披露（CVE）。

　　第四，所有各方，特别是CVE 编号机构（CNA），应遵循适当的指南来分配 CVE 编号和填充 CVE 条目。

　　第五，各方应提供信息，帮助其他利益相关者评估与漏洞相关的严重性、优先级和风险，如通用漏洞评分系统（CVSS）。

　　在对漏洞的披露做出响应时，应遵循以下原则。

　　第一，涉及的各方应采取措施确保通信和处理敏感信息的安全。

　　第二，供应商在安全许可发布之前必须对更新进行严格测试。

　　第三，供应商可以建立缺陷奖励计划，信用或安全港，以在发布前主动识别漏洞。

　　第四，各方应尽可能避免事态升级。利益相关者应鼓励在相关法律框架内进行安全研究和协调披露。

　　2.3　尽量减少利益相关者的暴露

　　多方协同披露的目的是减少利益相关者暴露的时间窗口，为达到这一目标，需要注意的事项如下。

　　第一，供应商可以按照预先确定的时间表（例如，星期二修补）发布补丁。在可能的情况下，更新和补丁应只包括安全设施，而不包括新功能或者非安全缺陷域。如可能，供应商应为用户提供自动更新流程，用户应启用供应商补丁自动更新功能。

　　第二，供应商应意识到，修补措施的发布可能披露其他供应商组件中存在的相同漏洞。

　　第三，供应商可以提供任何可用的缓解措施或变通办法来降低漏洞的影响，即使它们可能导致一些服务降级。

　　第四，利益相关者应考虑部分的、初步的漏洞公开披露。在缺乏明确证据证明事先公开披露（包括积极利用）的情况下，利益相关者应向供应商提供合理的禁售期，以调查和开发修补。

　　第五，下游供应商应考虑在上游供应商推荐一个新版本后尽快更新其组件。

　　在漏洞披露的过程中，需要对早期披露迅速做出快速的反应以最大限度地降低漏洞的影响范围。在漏洞的早期披露时期，供应商可分析情况并制定优先补救时间表，应向用户提供关于漏洞信息及潜在的缓解措施。在可能的情况下，供应商可以联系漏洞发现者确定早期披露的范围并实现损坏控制。

　　2.4　协调人员介入的时机

　　协调人员之间应建立并保持联系，以促进披露工作的进行。当涉及多个协调人员时，为避免混乱，应该有一个协调人员被选为负责人来主导协调工作。

　　协调人员可以帮助联系研究人员、供应商和其他利益相关者，当涉及多方（供应商）或无法联系一方（供应商）时，这一点尤为关键。此外，还可借助其他力量，为研究人员、供应商和其他利益相关者提供额外的技术、影响和范围分析，特别是在一些技术点存在分歧时。

　　3

　　不同场景下多方协同披露漏洞的流程

　　由于漏洞的披露通常偏离预期的或理想的过程，每个应用场景示例中可能存在诸多特殊情形，指南对此也进行详细的阐述，包括产生的原因、如何响应及预防措施等。

　　涉及多方的漏洞协同披露，根据受影响的用户、披露的时机、公开细节内容的程度，包括不存在受影响的用户、漏洞的协同披露、修复前公开有限的漏洞信息、在供应商发现前公开信息或利用漏洞四种典型的应用场景。

　　3.1　不存在受影响的用户

　　没有用户的软件或硬件漏洞是一个安全漏洞，不会以任何方式影响其他人，如图 2 所示。这种情况的例子包括非生产性、实验性、内部或个人使用、从未出版或出售或者正在开发的产品。

　　图片

　　图 2　产品存在漏洞但不存在受影响的用户

　　3.2　漏洞的多方协同披露流程

　　在协同披露过程中，以下利益相关者扮演某些角色：漏洞的发现者，使用标准漏洞报告渠道与供应商联系；供应商，当供应商修补漏洞时，在适当的时间，与上游和下游供应商进行沟通，并根据需要发布公告；防御者，制定缓解措施或签名，以检测和保护用户免受漏洞的影响，而不包含或暗示可能有助于潜在攻击者的信息，同时要求供应商提供相关测试用例，以检测基于重现的高级威胁；用户（user），尽快部署供应商提供的补丁程序或缓解措施。

　　在漏洞信息未公开的情况下，协同披露的一般流程如图 3 所示。

　　图片

　　图 3　漏洞的协同披露时序图

　　在漏洞的协同披露时，会存在上游供应商之间无法联系的情况，此种情况下需要协调人员的介入，介入后的披露过程如图 4 所示。在这种情况下，协调人员称为沟通的中心节点。

　　图片

　　图 4　上游供应商之间无法通信

　　相对于漏洞信息的完全公开，大多数情况下是发现者发布了一些关于该漏洞的信息，但没有给出如何利用该漏洞的提示。作为全面公开披露和私下协调披露之间的一种中间方式，发现者或供应商可以发布一些关于漏洞的存在及其披露时间表的初步通知。所披露的信息可能包含易受攻击的产品或组件的名称、最坏情况的影响以及未来公告的链接，但不提供关于如何利用该漏洞的任何提示，例如源代码更改或漏洞类型。这种情况在漏洞影响范围较广、保密性存在较大困难时比较常见。这种情况下的漏洞协同披露时序及用户面临的风险如图 5所示。

　　图片

　　图 5　修复前的协同披露时序及用户面临的风险

　　当在已部署的产品中发现漏洞时，发现者通过在互联网上发布、邮件列表、学术论文或会议等方法，使任何人都可以获得该漏洞的所有信息。披露的信息可能包括有缺陷的产品和版本、能够触发或证明漏洞的验证代码，以及缺陷或攻击方法的详细解释。在不等待开发或部署修复或缓解措施的情况下进行漏洞信息的公开披露，被称为“全面披露”或“零日”。这种情况下的漏洞协同披露时序及用户面临的风险如图 6 所示。

　　图片

　　图 6　在供应商发现前公布或利用漏洞

　　3.3　制定网络军控的发展路线

　　指南中对上面提到的不同场景的用例可能存在的情况进行分析，主要是针对协同过程中可能出现的种种情况进行列举，并对每种情况下产生的原因、应该如何进行预防和响应给出了详细的解答。

　　产生的原因，从漏洞发现者的动机、供应商的响应、用户的敏感度等方面进行了分析，归纳起来有以下几点。

　　第一，漏洞发现者在修复之前便公布细节信息。

　　第二，   漏洞发现者为了某种利益直接公布信息，导致漏洞被利用，用户面临极大的风险。

　　第三，供应商之间的沟通协调机制不通畅。

　　第四，供应商或协同人员在漏洞修复前公布细节。

　　第五，供应商对报告的漏洞未采取任何补救措施。

　　第六，供应商未将漏洞信息通报给所有受影响的产品供应商。

　　第七，用户对漏洞修复信息不够重视。

　　为了将用户的风险降到最低，指南对上面提到的不同原因产生的场景如何预防做了详细的指导，总结看有以下几方面。

　　在产品生产的全周期内进行安全审计，一是确保不存在已公开的漏洞，二是避免堆栈溢出、引用过界等明显漏洞的出现。

　　加快供应商的漏洞修复节奏，缩短漏洞利用的时间窗口。

　　自动更新机制的引入，避免由于用户薄弱的安全意识而带来的风险。

　　产品供应链上的供应商应建立完善、顺畅的协同机制，使得漏洞的修复可以在最短的时间内完成。

　　漏洞的修复应尽可能摆脱对产品的依赖，降低修复的难度。

　　4

　　结　语

　　漏洞已对当前的网络带来严重的安全隐患，日趋复杂的产品供应链为漏洞的修复带来了巨大的挑战，为最大限度地降低漏洞暴露的时间窗口，NTIA 和 FIRST 颁布了协同披露指南。指南中，对不同情形下的漏洞协同披露、如何预防以及回应给出了详细流程和应对措施，为我国漏洞的管理组织给出了参考与借鉴。

　　围绕降低漏洞暴露的时间窗口和“零日”漏洞的应对，可以加强以下四方面的工作：

　　充分发挥国家互联网应急中心的统筹作用。国家互联网应急中心作为对国内互联网安全事件的应急响应中心，可以统筹网络安全厂商的先进技术，对已有的漏洞进行常态化的检测预警，并设置相应的修复机制，将用户的风险尽可能地降低。

　　充分发挥我国国家漏洞库的协调作用。国家漏洞库是由国家互联网应急中心联合国内重要信息系统单位、基础电信运营商、网络安全厂商、软件厂商和互联网企业建立的国家网络安全漏洞库。可以充分利用国家平台的优势，聚焦减少影响范围，通过行政、技术双重手段，发布漏洞的协同响应机制，及时跟踪处理国际平台的最新漏洞披露信息，尽可能降低我国受影响产品暴露的时间窗口。

　　充分调动国家网络安全人才团队的技术力量。畅通地方网络安全人才的技术支持渠道，充分利用地方网络安全的强大技术实力，通过协同披露机制，协调服务提供商，对发现的漏洞进行及时修补，将漏洞的暴露时间降到最低。

　　加强网络行为审计工作。从前面的介绍中可以看出，“零日”漏洞的危害是最大的，需要加强网络行为的审计工作，尤其是关键基础设施，将行为审计作为常态化的工作。通过异常行为的发现，反溯、定位漏洞的位置及类型，及时修补。