美国家标准与技术研究院发布《对联邦漏洞披露指南的建议》

近日，美国国家标准与技术研究院发布《对联邦漏洞披露指南的建议》（NIST SP 800-216）。本文件就建立联邦漏洞披露框架、正确处理漏洞报告以及沟通漏洞的缓解和/或修复提出了指导建议。该框架在提供联邦监督的同时允许地方解决支持，并应适用于联邦控制下的所有软件、硬件和数字服务。

美国政府漏洞披露

每年都有数以千计的计算机软件和系统的安全漏洞被发现并公开披露。可能，更多的漏洞是由开发人员发现并悄悄修复的，没有人知道。仅在2021年，就有超过20,000个新漏洞报告给NIST国家漏洞数据库[NVD]。漏洞是由各种来源发现的。软件的开发者可能会在已经部署的代码中发现安全漏洞。安全研究人员和渗透测试人员可能通过扫描或手动测试软件和可访问系统（遵循公布的行为规则）发现漏洞。在发现问题的同时，系统的用户可能会偶然发现一个漏洞。恶意行为者可能会寻找未知或未公布的漏洞，并在恶意软件中使用它们。然后，这些攻击的证据可能被安全专家发现和分析，从而导致一个被识别的漏洞被报告。

(相关资料图)

根据《2020年网络安全改进法案》，NIST被指示为联邦机构制定与ISO/IEC标准一致的漏洞披露指南。根据该立法，本文件提供了以下指南：

1.接收有关联邦信息系统中潜在安全漏洞的信息；

2.与利益相关者进行协调；

3.解决并传播有关此类安全漏洞的信息。

为了定义漏洞披露准则，本文件描述了一个框架，供美国政府建立和维护一个统一的、灵活的漏洞披露的收集和管理程序。该框架可以应用于各个层面，从中央监督机构到各个项目办公室。该框架还可以应用于政府系统使用的所有政府开发的、商业的和开源的软件。所有包括开发或支持服务的政府数据和信息系统都能从漏洞披露计划的覆盖范围中受益。

图1.高级别的联邦漏洞披露框架和信息流

这些指导方针的重点是评估已确定的漏洞的风险，并鼓励整个联邦政府的所有组织收集和评估漏洞。漏洞的风险，并鼓励整个联邦政府的所有组织收集和评估漏洞 披露，以实现最大程度的沟通和问责。创建高效和有效的漏洞披露计划可以帮助最大限度地减少政府和私人信息的意外暴露、数据的损坏和服务的损失。本文件利用ISO/IEC标准定义了一个专门为美国联邦机构设计的漏洞披露框架。本文件利用ISO/IEC标准定义了一个专门为美国联邦政府设计的漏洞披露框架。它的实施规定了在联邦、机构和信息系统层面工作的行为者，以及他们在执行漏洞披露时应如何协调。该指南还与2020年发布的约束性操作指令[BOD20-01]保持一致，并利用该指令，要求联邦机构发布漏洞披露政策，使用户能够报告联邦政府系统的漏洞。

图1提供了一个框架的高层视图，显示了主要的行动者和信息流。信息流。两个主要的政府实体是联邦协调机构（FCB）和漏洞披露项目办公室（VDPO）。框架中定义的其他行动者包括报告人、公众和外部协调者，所有这些人将在本文件后面的章节中得到更详尽的描述。

FCB是一个由合作成员组成的团体，共同为政府机构提供灵活的、高水平的漏洞披露协调。该小组代表了政府应跟踪漏洞的主要机制，并为其制作漏洞咨询。

外部协调者（EC）是指不在FCB或VDPO内的、接收源漏洞报告的任何漏洞披露实体。EC可以是一个私人的、学术的或 非营利性的漏洞项目，与政府无关，或者是政府内的另一个VDPO。它也可以是政府系统中使用的商业或开源软件的开发者。联邦政府内现有的漏洞披露项目早于这些指南，而且这些项目的公开政策和指南似乎基本符合ISO/IEC标准。

1.1 文件术语的使用

在本文件中，术语"漏洞"是指信息系统中的安全漏洞。它并不指其他类型的漏洞，本文件在为联邦政府制定漏洞披露指南时，尽可能地利用了ISO/IEC标准。联邦漏洞披露协调机构 联邦协调机构（FCB）是一个由合作的政府实体组成的团体，在联邦一级运作，以确保为所有政府机构提供漏洞披露协调服务，也可能为非政府行业部门（如医疗保健）提供服务。FCB的成员利用其资源和能力来：

接收源漏洞报告

协调和调查，以确定脆弱系统；

将发现的报告转给适当的实体；

编写关于漏洞的建议。这里对协调过程进行了总结，并在随后的章节中进行了详细描述。

图2.联邦漏洞披露协调过程

每个FCB成员至少应履行图中所示的三个高级功能。在行动之前，FCB成员应该已经发展了接收源头漏洞报告的能力，确定了他们的行动范围，并建立了联邦和地方政府之间的联系。漏洞报告的能力，确定其行动范围，并建立联邦和行业联系。行业联系。一些成员还支持技术分析能力。

图2的其余部分涉及操作方面。在运行过程中，FCB接收源漏洞报告，并对其进行调查，以确定其有效性并对资源分配进行优先排序。

分配的优先次序。不确定政府专用系统的漏洞报告可能会被转到一个行业漏洞协调小组和/或直接交付给适当的执行委员会，如软件开发商。

FCB与最接近受影响系统的VDPO合作，确定具体的漏洞。如果有漏洞的软件或服务不是政府拥有的，FCB会将报告转发给适当的开发商或行业漏洞协调小组。然后，FCB可以与相关的VDPO合作，就该漏洞对适用的政府系统的影响提出建议。

漏洞对适用的政府系统的影响。如果该软件或服务是由政府开发或支持的，FCB将向适用的VDPO提交一份调查结果报告，以进行漏洞验证和补救。如果被要求并根据资源可用性，FCB将协助相关的VDPO。最后，如果该机构，相关的系统所有者，确定该漏洞可能对公众产生影响，FCB可以发布关于该漏洞的咨询。

预计不会有大量的FCB成员。相反，FCB可能包括具有特殊任务专长的机构业务单位，而这些专长与现有的FCB成员。每个家庭福利局成员支持政府的一个明确的子集，尽可能减少范围的重叠。尽可能地减少范围的重叠。此外，FCB成员花费资源参与 此外，FCB成员还花费资源与工业界进行接触和协调，以修复政府使用的工业产品中的漏洞。政府。大多数机构将利用FCB成员提供的服务，而不是自己成为FCB的一部分。自己不是FCB的一部分，而是建立自己的VDPO来处理自己系统中发现的漏洞。在他们自己的系统中发现的漏洞。

2.1 准备工作

FCB成员需要发展一些基本的政策和能力，包括接收源漏洞报告的能力，与报告者安全协调，确定联邦系统的服务范围，以及可选择发展一个技术漏洞分析和缓解团队。

01 创建源漏洞报告的接收能力

每个FCB成员都应该发展从报告者那里接收源漏洞报告的能力，维护一个收到的报告的数据库，并进行安全的沟通。实际收到源头漏洞报告可能采取多种形式，并应在公共政策中说明。还建议 建议将 FCB 成员支持的VDPO列表及其外部漏洞披露政策的链接公开。这样，报告人既可以选择向哪里发送报告，也可以知道哪些自愿者组织与该FCB 成员合作。

潜在漏洞可以被识别、证明或复制；以及该漏洞允许哪种类型的功能影响。由于信息的敏感性，各机构应提供机制，以保密方式接收报告中的其他信息。

由于信息的敏感性，各机构应提供机制，以保密方式接收报告中的额外信息。为了促进对漏洞的验证，各机构应设计报告机制，以评估漏洞的有效性、技术严重性、范围和影响。

这些信息可以包括：

产品或服务名称和受影响的版本；

确定的主机或其网络接口；

漏洞的类别或类型，可选择使用CWE（通用弱点列举）这样的分类法；

可能的根本原因（或CVE，如果已知）；

概念验证代码或其他实质性证据；

重现漏洞行为的工具和步骤；

影响和严重性估计；

范围评估和其他被认为会受到影响的产品、组件、服务或供应商；

披露计划（具体而言，禁运和发布时间）；

在适用的情况下，源漏洞报告还应该指出该漏洞是否影响到多个系统，它们的共同性，以及其他系统所有者是否已被通知。漏洞是否影响到多个系统，它们的共同性，以及是否已经通知了其他系统的所有者。

02 确定范围并获得联系

在收到任何漏洞之前，每个FCB 成员将确定哪些政府VDPO属于其服务的范围。然后，FCB成员将获得并保持一份 然后，FCB成员将获得并保持一份在相关政府机构中接收和处理源漏洞报告的VDO联系人名单。每个FCB 成员都应发展能力，将报告转发给 脆弱性组织，并参与持续的沟通，以实现协调。最后，FCB成员可以与行业相关的漏洞协调实体（如CERT/CC3）合作，以促进 与非政府软件和/或服务供应商的协调。

03 开发技术分析能力

FCB可以开发技术性漏洞分析和修复能力，对收到的源漏洞报告的重要性进行分流，验证所报告的漏洞是否存在，并协助最接近受影响系统的VDO进行分析和修复工作。例如，它们可用于解决适用于多个VDO的严重漏洞，并协助可能没有足够资源来评估和补救漏洞的较小的VDO。

2.2 接收源漏洞报告

FCB成员利用第2.1节中制定的政策和能力，接收来自政府内部和外部的报告者的源漏洞报告。如果报告不在范围内或无法核实，FCB成员应通知报告人和/或将报告转发给适当的FCB成员或EC。如果报告被确定为在范围之内，金融情报机构成员和报告人之间应保持对话，以便能够交流额外的和澄清的信息。如果报告者打算公开宣布该漏洞，FCB可以和他们一起制定一个披露时间表（例如，协调公开披露和补丁分发）。

虽然 FCB接收所有政府系统的源漏洞报告，但报告人可以选择直接向有漏洞的系统的VDPO 报告。在这种情况下，适用的VDPO 将与FCB协调（视情况而定），以通知其他受影响的机构，请求技术援助，并制作公告。VDPO还向其相应的FCB成员提供所有收到的报告的副本，以便进入FCB报告数据库。

2.3 对源漏洞报告进行分类和优先排序

FCB成员应根据漏洞的明显程度对源漏洞报告进行优先排序：

政府系统对该漏洞的暴露程度，以及

对受影响的软件或服务的用户的影响的技术严重程度。

为了计算漏洞的严重性和利用的难易程度，FCB成员应使用记录在案的漏洞评分方法（例如，通用漏洞评分系统[CVSS]）。该评分应根据预期的政府系统暴露和用户影响等环境因素进行定制，以计算所有收到的报告的优先级。FCB可能需要与VDPO协调，以确定受报告漏洞影响的政府资源的可能范围。这种优先次序的确定可以优化资源分配，并确定处理报告的紧迫性。一个软件库或其他共享资源中的漏洞可能会影响多个政府系统，其技术严重程度各不相同。为了确定优先次序，应使用计算出的最高严重程度。

2.4 确定报告的易受攻击系统

通过与VDPO合作，FCB成员应确定报告的潜在漏洞可能存在的系统的所有者。如果报告不适用于政府系统（即报告涉及非政府编写的、不为政府使用的软件），则应将其转发给适当的执委会。这可能是一个以行业为重点的漏洞处理组织或负责的供应商。在通知报告人解决方案后，可能没有必要进一步参与FCB。

2.5 识别被报告的易受攻击的软件

如果所报告的漏洞确实与VDO的系统有关，FCB应该支持VDO识别任何受影响的政府IT系统和潜在的漏洞。识别任何受影响的政府IT系统以及该系统中可能存在的漏洞软件。的软件。源漏洞报告可能会确定一个有漏洞的服务，而不说明什么基础软件有漏洞。

许多产品是复杂的系统，包括或依赖于其他产品或组件。组件。因此，最初的分析可能无法清楚地了解哪些 产品受到漏洞的影响。可能要经过多次反复的发现和 漏洞存在于政府生产的软件或政府使用的商业或开放源码软件中。

如果可能存在漏洞的软件是商业或开放源码。如果有潜在漏洞的软件是商业或开源的，FCB成员或VDPO应确定软件所有者并将报告转发给该执委会。如果无法做到这一点，则应将该报告 报告应被发送到一个以行业为重点的漏洞处理组织。如果有要求，应将信用 如果被要求的话，应将信用给予原始报告人。金融犯罪调查局应该监控漏洞验证和修复的进展，并更新 漏洞验证和修复的进展，并向报告人和受影响的 VDPO漏洞的解决状态。

2.6 验证和修复漏洞

如果有潜在漏洞的软件是政府开发的或支持的软件，那么 漏洞报告的控制权。如果潜在的漏洞软件是在政府开发或支持的软件中，FCB将把收到的源漏洞报告的控制权移交给离受影响系统最近的VDPO，该报告还包括迄今为止的额外发现（例如，具体的脆弱系统）。系统。VDPO随后将根据他们的内部漏洞披露政策，领导漏洞处理决议。内部漏洞披露政策（验证和缓解漏洞），如3.2.1节所述。3.2.1节中所述。VDPO应该通知FCB成员他们在解决该漏洞方面的状况。漏洞，而FCB成员应将此记录在其漏洞报告数据库中。FCB可以根据漏洞的优先级和资源的可用性来提供技术援助。资源的可用性。

2.7 确定是否发布警告

对于每一个经过验证的漏洞，都必须确定是否要发布公告，公告的目标受众，以及应该使用哪个公告服务。一般来说，在开发和部署了补救措施（例如，发布了补丁）后，就会发布咨询。然而，情有可原的情况下，可能需要多于一个咨询。如果一个临时的缓解措施可以防止漏洞被利用，那么就应该发布一个描述缓解步骤的公告，并附上适当的注释。当漏洞可以被修复的时候，应该发布一个额外的警告。

01 确定是否有理由公开披露

对于在政府系统中发现的每个漏洞，其系统中存在漏洞的VDO应确定是否需要公开披露。如果该漏洞存在于多个机构系统中，FCB应与利益相关者协调响应和发布。

在以下情况下可以考虑公开披露：

如果漏洞不影响公众，可能没有必要或不建议公开披露。例如，如果政府工作人员已经修复了有漏洞的系统，并且没有发现漏洞被利用的证据，则可能没有必要公布。这样，咨询系统就可以把重点放在需要用户采取行动以保持安全和隐私的漏洞上。如果政府系统中的漏洞是由使用商业或开源软件造成的，那么FCB应该努力为有漏洞的软件创建一个公共咨询。

漏洞的软件。这种咨询可能不使用特定的政府系统咨询服务，而是使用解决软件行业漏洞的服务。如果公众因政府系统中存在的漏洞而受到影响，FCB应考虑发布一个单独的政府咨询。

在某些情况下，记者会就某一漏洞向政府提出建议，而这一漏洞并不适合创建一个官方咨询。这可能会使他们无法为所提供的服务获得公共信用。

具体的漏洞不为公众所知；

有漏洞的系统是由公众使用的；

存在个人身份信息（PII）或其他敏感信息被暴露的风险；

具体的漏洞与受影响产品的缺陷或瑕疵有关，这可能会影响到VDPO机构以外的用户的安全；

公众在某种程度上有受到伤害的风险，或需要采取一些行动来保护自己的安全；

如果漏洞不影响公众，可能没有必要或不建议公开披露。例如，如果政府工作人员已经修复了有漏洞的系统，并且没有发现漏洞被利用的证据，则可能没有必要公布。这样，咨询系统就可以把重点放在需要用户采取行动以保持安全和隐私的漏洞上。如果政府系统中的漏洞是由使用商业或开源软件造成的，那么FCB应该为有漏洞的软件创建一个公共咨询。

02 制作咨询

FCB应该是政府漏洞咨询的主要联络点。然而，这不应该妨碍一个机构针对其系统中的漏洞发布咨询，或与适当的利益相关者进行沟通。咨询应该发布或披露有关识别和修复漏洞的信息，并对漏洞进行简要的、高层次的总结，以帮助用户了解调查结果报告的要点，并迅速确定咨询是否适用于他们的环境。

对于没有可用补救措施的积极利用的漏洞，公告可以告知用户当前的威胁和为了减少风险而采取的步骤。当其他产品与其他产品和/或系统共享 漏洞时，作者应与这些产品和/或系统所有者协调咨询发布的时间。咨询内容应包含足够的信息，使目标受众能够决定这些漏洞是否相关以及如何补救。咨询意见的发布时间应该平衡风险和对用户的潜在干扰。例如，分批或按计划发布可将干扰降至最低。

建议作者还应该考虑目标受众的需求，并在信息内容、发布机制和演示格式方面制作有效的建议。典型的受众包括负责识别脆弱系统和执行补救措施的用户。建议可以包括针对特定受众的部分，如针对开发人员、系统管理员或最终用户的进一步补救建议。建议中针对受众的语言是可选的。

应考虑将以下内容纳入到咨询中：

咨询标识符和漏洞标识符应该包括产品名称；版本信息；对已知的、受支持的和受影响的产品的参考，以及验证产品版本的说明；以及一个独特的、一致的标识符，以减少与不同咨询或漏洞的混淆。建议作者应该选择一个共同的、共享的漏洞识别系统，如CVE。然而，该信息不应提供过多的细节，以避免使漏洞被利用。描述受影响产品的有用信息可以包括：

o 常见的或历史上的产品名称

o 版本号或字符串

o 漏洞的类别或类型（例如，CWE分类法）

o 文件散列值

o 用于安全测试漏洞存在的概念验证代码

该建议应包含首次发布的日期以及可能的其他日期。

对漏洞的潜在影响或后果的描述，至少应解释该漏洞所允许的潜在行为。该信息可包括安全侵犯、访问或特权的获得、可能的后续影响以及常见的攻击场景。咨询中使用的技术严重性评级系统应该被记录下来，并从咨询中引用该文件。现有的技术严重性评级系统，如CVSS，应尽可能地利用；

补救要素应包括受影响的用户为补救该漏洞应采取的行动的信息。该建议还可以提供缓解措施，以保护受影响的产品或服务，直到实施补救措施；

可以增加对其他或相关信息的参考，并应使用原始或源材料和常见的交叉参考，如CVE，在适用的情况下；

该建议应提供联系信息，并应建立和维护向用户传达建议的方法；

如果报告者希望得到公众的认可，公告应该承认报告者报告了该漏洞；

该公告还应该包括版权、使用条款和公告的再分发。

03 政府顾问服务

联邦政府维持咨询服务，以减少美国网络安全和经济安全的风险，包括为公众服务的联邦机构和国家的所有经济行为者。计算机安全行业也保持着各种免费和收费的漏洞咨询服务。联邦政府参与了咨询服务的生态系统，以确保提供准确和全面的漏洞清单。

以下是截至本文件撰写时，政府漏洞咨询资源的部分清单。以下是截至本文件撰写之时的部分政府漏洞咨询资源。

2.7.3.1. 国家网络意识系统（NCSA）

国家网络意识系统（NCAS）包含五个产品，它们向用户提供有关漏洞和相关威胁的信息。漏洞和相关威胁的信息[CISA]给技术用户：

当前活动：提供关于最频繁、影响最大的安全事件类型的详细信息。当前的活动--提供目前报告的最频繁、影响最大的安全事件类型的细节；

警报：及时提供有关当前安全问题、漏洞和利用的信息；

公告：提供最新漏洞的每周摘要；

分析报告：提供关于新的或不断发展的网络威胁的深入分析；

工业控制系统（ICS）：及时提供有关当前安全问题、漏洞和利用的信息

2.7.3.2. 国家漏洞数据库

NIST维护着国家漏洞数据库[NVD]，它是美国政府基于标准的漏洞管理数据的存储库。它包含一个几乎所有公开披露的漏洞的数据库--更具体地说，是包含在通用漏洞和暴露（CVE）字典[CVE]中的所有漏洞。NVD工作人员分析了漏洞描述，以提供简洁和机器可读的信息，如脆弱的软件版本、信息参考、漏洞属性、基础软件缺陷类型和技术严重性评分。

2.8 联邦漏洞披露协调中的利益相关者

每个政府机构都是联邦漏洞披露协调的利益相关者，每个机构都应该至少有一个VDO，或者通过与上级机构的协议得到一个VDO的支持。协调VDPO之间的协调是FCB的一个主要作用。FCB的成员可能会随着时间的推移而改变和扩大。

2.9 技术方法和资源

在漏洞管理协调过程中，FCB应尽可能地利用现有的技术基础设施来披露漏洞。

本节建议使用某些技术来加强漏洞协调活动。随着漏洞报告的成熟，FCB可能会推荐取代本节指南的替代技术。

在引用公开披露的漏洞时，应该使用CVE的命名方案。CVE网站的重点是为每个漏洞提供独特的标识以维护CVE列表。它并不打算充当咨询服务。当引用CVE漏洞时，应该使用NVD链接，因为它提供了对每个CVE的分析和任何引用的信息。FCB成员也应该准备好通过成为CVE编号机构（CNA）或授权数据提供者（ADP）来提交CVE。所有漏洞的技术严重性可以用通用漏洞评分系统（CVSS）来评定。它的分数反映了该漏洞在全球信息技术基础设施方面的估计技术严重性。

3.漏洞披露计划办公室

本节描述了漏洞披露项目办公室（VDPO）的职责和运作，以及它应该如何与FCB和报告人合作，以评估潜在的脆弱系统和软件。在验证源漏洞报告的价值后，漏洞披露计划办公室应支持系统所有者进行漏洞验证、缓解和/或修复，以及发布咨询意见等工作。

3.1 漏洞披露计划办公室描述

VDPO最好作为信息技术安全办公室（ITSO）或现有计划的一部分来实施。ITSO已经对所有的系统负有安全监督和支持的职责，这有利于VDPO为所有的系统提供必要的沟通和联系。VDPO的作用将反过来有利于ITSO对报告的漏洞进行管理。VDPO可以是一个有自己专门人员的办公室，也可以是一个虚拟办公室，其职责和角色由运营单位的ITSO成员承担。至少，它将由以下人员组成：它至少包括履行协调和监督职责以及与漏洞披露报告者接触的工作人员。然而，VDPO可以扩展到向系统所有者提供技术服务，以支持他们验证和修复漏洞的工作。在这种情况下，VDPO可以包括更多的技术导向的开发人员或具有安全专业知识的系统管理员。

3.2 漏洞披露计划办公室结构要求

漏洞披露计划办公室是信息技术安全办公室的一个关键单位，主要负责漏洞报告管理。其结构要求包括：

1. 制定源漏洞报告的接受政策和接收源漏洞报告的能力

2. 对源漏洞报告的监控

3. 处理和解决源漏洞报告

a. 识别有潜在漏洞的系统和软件

b. 核实源漏洞报告

c. 监督和支持对已核实的漏洞的缓解或补救工作。

4. 漏洞披露处理程序的开发

3.2 漏洞披露计划办公室的结构要求

漏洞披露计划办公室是信息技术安全办公室的一个关键单位，主要负责漏洞报告管理。它的结构要求包括：

1. 制定源漏洞报告接受政策和接收源漏洞报告的能力。

2. 对源漏洞报告的监控

3. 处理和解决源漏洞报告

a. 识别有潜在漏洞的系统和软件

b. 核实源漏洞报告

c. 监督和支持对已核实的漏洞的缓解或补救工作。

4. 漏洞披露处理程序的开发

图3. VDPO的结构要求

这些要素将在随后的章节中详细解释。志愿服务组织应考虑将其具体政策和程序建立在联邦调查局和类似的志愿服务组织所使用的准则和程序之上。类似的村级组织所使用的准则和程序为基础。它不需要孤立地制定或实施这些政策和程序。

1 开发源漏洞报告的接受政策

敦促每个虚拟桌面组织采用其相关的金融情报机构成员的通用政策，并酌情进行修改。为了与[BOD20-01]保持一致，外部政策应该详细说明向受影响系统的ITSO报告漏洞的方法。受影响系统的ITSO，以及对漏洞披露报告的确认和解决的期望。它还应该描述在探测机构系统的漏洞时应遵循的参与规则，以及在发现漏洞时应探测多深。这与安全研究人员特别相关，无论它是否与漏洞赏金计划相联系。该政策应包括一项承诺，即如果规则得到遵守，则不建议对报告人采取法律行动，以及关于获得公众认可的资格和/或潜在的赏金的信息。

内部政策规定了处理、协调和解决所收到的漏洞报告的规则和程序；用于跟踪报告的机制；以及与报告人和其他利益相关者沟通的期望。与报告者和其他利益相关者沟通的期望。预期的反应和补救措施处理漏洞报告的预期反应和补救措施，以及在与FCB合作发布漏洞报告时应遵循的程序，都应予以明确。

2 对源头脆弱性报告的监测

VDPO应该监控他们的报告机制，以获得新的报告和与现有报告有关的沟通。VDPO还应该监测漏洞报告的公共来源和可能收到这些报告的组织沟通渠道，如客户服务和支持。

3 源漏洞报告的处理和解决

每个 VDPO应发展与FCB 成员沟通和协调的能力，以解决漏洞报告，这需要发展技术和人员/程序能力。如果FCB 成员提供技术机制来简化这一过程，VDPO应该使用所提供的机制。也可以采购商业性的VDP服务，特别是用于报告、跟踪和研究人员沟通。如果一个自愿者组织选择进行自己的漏洞研究和测试，它应该将所有相关信息转发给其FCB成员，以纳入FCB漏洞报告数据库。

这种能力可用于为内部发现的漏洞或直接发送给离受影响系统最近的ITSO的外部报告生成漏洞报告。通过这样做，各机构可以选择自行处理系统的漏洞披露职责，同时让其相关的FCB成员了解收到的报告，并利用它们来发布漏洞咨询。VDPO应该在接收和传达漏洞报告的整个过程中实施操作安全。报告机制和持续的通信应该是安全的，并限制对敏感的、非公开的漏洞信息的未授权访问。内部操作安全也应该限制非公开的漏洞信息和任何获得的关于报告者的PII在需要了解的基础上被工作人员和组织单位使用。

4 漏洞披露处理程序的开发

每个VDPO都应制定和维护内部漏洞处理程序，以说明它如何 漏洞处理程序，以便与外部和内部漏洞披露政策协调，调查和补救漏洞。漏洞披露政策。内部漏洞处理程序应规定在漏洞处理过程的每个阶段由谁负责，以及他们应如何处理有关潜在漏洞的报告。它应包括管理产品或服务中潜在漏洞的指导、原则和责任；负责处理潜在漏洞的内部组织和角色的清单。

负责处理潜在漏洞的内部组织和角色清单；防止潜在漏洞信息过早披露的保障措施。潜在漏洞的信息过早披露的保障措施；以及补救措施制定的目标时间表。补救措施的目标时间表。VDPO政策可以利用FCB提供的模。它们应尽可能地使用相同的漏洞 披露术语、技术严重性评级、技术和标准。相关的FCB成员所使用的技术和标准。

5 漏洞披露计划办公室的运作职责

本节详细介绍了漏洞披露计划办公室在接收、处理和解决漏洞报告时应采取的步骤。解决漏洞报告的步骤。本指南主要适用于美国政府环境中的报告处理。政府环境下的报告处理。图2 和图4 共同描述了FCB 成员与VDPO 之间的协调。漏洞披露过程中，FCB成员和VDPO之间的协调。

图4显示了VDPO的业务职责

3.2.5.1收到源漏洞报告

VDPO在收到源漏洞报告时，应向报告人发送接收确认函，并与系统所有者合作，确定可能存在漏洞的系统和软件。每个源漏洞报告都应该有一个由FCB成员分配的优先级，用来优化资源分配和确定处理每个报告的紧迫性。VDPO可以选择在与FCB成员沟通前进行优先级评定。漏洞报告的优先级，或者它可以与FCB 合作确定优先级。

3.2.5.2识别潜在的易受攻击的系统和软件

处理源漏洞报告的第一步是确定潜在的脆弱技术和报告所属的IT系统。技术和报告所属的IT系统。为了做到这一点，每个VDPO应该 为其管辖范围内的每个系统维护一个最新的联系人名单或数据库。某些情况下，收到源漏洞报告的VDPO 可能需要协调多个 系统所有者（或其安全官员）进行协调，以确定哪个系统或软件有潜在的漏洞。漏洞。这一步骤并不涉及验证漏洞的存在，而只是 识别该报告属于哪个系统。许多产品是复杂的系统，包括或依赖于其他产品或组件。组件。因此，最初的分析可能无法清楚地了解哪些 漏洞所影响的产品。可能要经过多次反复的发现和 漏洞存在于政府生产的软件或政府使用的商业/开源软件中。

3.2.5.3 监督和支持对源漏洞报告的验证

最接近受影响系统的VDPO 应支持系统所有者（或其安全官员）验证漏洞的存在。如果VDPO或相关的FCB的成员有技术资源可以帮助系统所有者验证漏洞，可以根据系统所有者的要求利用这些资源。对一个可能的漏洞的调查通常涉及到试图重现报告人所描述的环境和行为。分析也可以包括关联 类似或相关的报告，评估技术严重性，并确定其他受影响的产品。产品、子组件和利用方法都应该被记录下来。如果最初的 如果最初的分析显示漏洞存在于系统的产品或服务中，则需要进一步调查，包括根本原因。需要进一步调查，包括根本原因分析。调查可能会扩展到相关的 的相关产品，以评估影响的程度、漏洞的总体严重性以及对其的影响。漏洞的整体严重性，以及利用的可能性。这些信息可能 影响后续活动的优先次序。

如果在政府系统使用的非政府开发的软件中发现了漏洞，源漏洞报告应转给FCB进行协调和处理。如果确定不存在漏洞，最初收到源漏洞报告的实体应该回应报告者并解释调查结果。然后，报告人可以提供更多的细节，证明漏洞的存在，并引发进一步的调查。如果源漏洞报告不能被验证，它应该被转发给FCB，以便在他们的数据库中最终确定，并与报告者进行最后沟通。即使源漏洞报告不能被核实，与报告人进行适当的沟通仍然是很重要的。

3.2.5.4 监督和支持对已验证漏洞的补救工作

一旦漏洞被验证，VDPO将确保系统所有者已经对发现的漏洞进行了缓解或补救。与验证步骤一样，如果VDPO或相关的FCB成员拥有技术资源来协助漏洞修复，他们可以根据系统所有者的要求进行部署。

在某些情况下，制定短期缓解措施可能是有效的，然后再进行更彻底的缓解或补救。缓解或补救方法可能涉及补丁、修复、升级或配置更改，以减少漏洞的利用，并应包括适当的文件。在为所有受影响的平台和服务开发和测试完整的解决方案时，可能有必要进行一系列的早期沟通以提醒用户群。随后的监测和测试也是必要的，以确保解决方案以利益相关者可接受的方式解决漏洞问题，而不影响产品的功能或引入新的漏洞。

漏洞。VDPO应确保将吸取的教训纳入开发过程，以减少未来的漏洞。如果在他人使用的信息系统、产品或服务中发现漏洞，自愿发展办公室也应通知财务控制委员会。

补救此类漏洞通常需要产品或服务所有者的参与，以制作和分发补丁或更新。VDPO也可以通过现有的支持渠道直接通知产品或服务所有者。反过来，产品或服务所有者应协助利益相关者处理漏洞，直到产品达到服务的终点。如果产品或服务所有者选择不对所有支持的版本进行修复，则应提供一个合理的升级路径，将其升级到具有修复功能的版本。在漏洞修复发布后，应继续对产品或服务的稳定性进行监控。负责的VDPO应酌情更新补救措施，直到不再需要进一步更新。在根本原因分析中获得的信息应被用于更新开发生命周期要素，以防止新的或更新的产品或服务出现类似的漏洞。拟议的补救措施和沟通可能需要法律审查的咨询，以确保负责机构遵守内部政策、法律和现有合同。

3.2.5.5. 漏洞咨询发布

第2.7节提供了关于是否应该为已修复的漏洞发布警告的指导。2.7节提供了关于是否应该为已修复的漏洞发布公告的指导。含有该漏洞的系统的所有者应与VDPO协调做出决定。

与VDPO协调决定。如果该漏洞涉及多个如果该漏洞涉及多个政府系统，那么适用的FCB成员应做出决定。只向系统的用户发布的警告可以在系统层面上进行 在VDPO的支持下，可以在系统层面上发布。公众咨询应该通过已建立的FCB咨询服务来进行 使用已建立的 FCB 咨询服务。

3.3 管理方面的考虑

本节介绍创建一个或多个VDPO 的管理注意事项。

1 领导支持

领导层的支持是这项工作的关键，应该包括对计划重要性的沟通。的重要性。最高管理层应该确保漏洞处理计划的目标与企业自身的利益相一致。

漏洞处理计划的目标与组织的战略方向相一致，并与组织的现有流程相结合。纳入组织的现有流程。应指定角色和资源，以便 赋予该计划的实施权力。领导层的沟通应强调 支持一个持续改进的过程，并包括一个向上级管理层报告进展的机制。进展的机制。机构向领导层报告其网络安全状况时应包括与VDPO相关的指标。VDPO。这将使领导层了解该机构的漏洞披露和修复过程的进展情况。和修复过程的进展。

2 人员配置需求

强烈鼓励使用现有的信息安全操作和合规人员。VDPO的工作人员需要对报告的漏洞的性质有很强的把握，以便 与有关方面协调，处理敏感信息，并与合作伙伴和利益相关者进行保密的互动。伙伴和利益相关者进行保密互动。管理层应指定角色并分配适当的授权，以允许问责并使 角色，并分配适当的授权，以实现问责制并使该计划得以成功实施。这些职位可以包括一个倡导者，作为变革的推动者，促进沟通和3.3.3.

3 充分利用现有的程序

可以利用多个项目的现有操作流程来支持脆弱性过程，尽管它们可能有所不同，并需要进行调整。可能有必要进行差距分析，以确定基本的政策组成部分，使机构内和机构间的项目能够共享和合作。作为持续改进的努力的一部分，应该实施一种机制，以便对所制定的程序的有效性进行定期评估和反馈，并为洞察力、改进和经验教训提供数据。

4 将承包商的支持纳入VDPO

与处理、解决和纠正漏洞披露信息有关的政策考虑应包括在任何支持联邦信息系统的合同中，以减轻或解决漏洞披露问题。

5 客户支持和公共关系

处理漏洞需要一个全面的方法，涉及到工程和技术以外的方面。客户服务和公共关系同样重要。如果披露的漏洞是一个严重的或广泛的问题，可能需要与公共关系进行协调，以便 准备好与新闻媒体的联系。组织规划应考虑促进密切的 工作关系并支持客户服务，以处理和回应安全漏洞。漏洞。这些能力可以从与利益相关者的保密沟通方式到将利益相关者的问题上报的方式不等。这些能力可以从与利益相关者的保密沟通方式到将咨询中的问题升级为协调的反应。

标签：