【公益译文】安全控制评估自动化支持：软件漏洞管理（二）

VUL能力的期望状态是：已知漏洞列表准确、完整，包含最新信息；所有设备上安装的软件产品均无已知漏洞。实际状态的VUL能力数据需求的示例见表1。期望状态的VUL能力数据需求示例见表2。

表1 VUL实际状态数据需求示例

表2 VUL期望状态数据需求示例

VUL识别网络设备（实际状态）中实际存在的软件（包括虚拟机上的软件），将这些软件与期望状态列表对比，明确软件中存在哪些已知漏洞（或缺陷），并安装补丁（或其他缓解方法），降低系统漏洞的可利用性。

软件漏洞管理能力运营概念（CONOPS）定义了如何实现VUL能力，是自动化评估流程的核心。请参见图1。

图1 VUL运营概念（CONOPS）

2.5.1 采集实际状态

ISCM数据采集流程利用工具识别补丁级别的网络设备中的软件文件（和产品），包括大容量存储器和固件中的软件。这些工具进一步提供必要信息，将实际软件与发现的补丁级别（实际状态）与授权的补丁级别（期望状态）进行比较。本节通过举例介绍用于识别实际和期望补丁级别的方法。

同时，ISCM数据采集流程还会明确目标网络的监控范围和频率，最终确定完整性和及时性度量标准。设备可能因为以下各种原因而无法监控：（1）设备未联网，可能在特定扫描过程中检测不到；（2）设备关掉；扫描过程中发生错误；（3）设备位于扫描范围之外的被保护地区；（4）设备在预期IP地址范围之外（若扫描器扫描特定范围）等等。请注意，若列表数据质量可接受，可依据硬件资产管理（HWAM）能力列表检查扫描范围。

需对所有能力的实际状态数据进行有效配置管理。附录G介绍如何对实际状态进行配置管理。附录G中列出的控件为VUL能力评估流程的元控件。

2.5.1.1 操作系统软件数据库的实际状态数据

有一些组织将操作系统软件数据库（OSSD）作为软件版本的实际状态数据的来源。不过，OSSD的多个运行特征可能会在软件版本识别过程导致如下错误：

• 软件未列入OSSD。设备中有些软件未在OSSD中列出（即，软件由于未列入OSSD而无法被OSSD识别）。

• OSSD条目无法识别安装的所有软件。对于特定产品版本来说，不同安装介质实例可能会安装稍有差别的可执行文件，因此可能存在不同漏洞。OSSD可能检测不到这一点。

• 产品卸载过程可能会删除OSSD中的软件文件条目，但不会删除所有代码。卸载过程中存在的问题可能会导致OSSD无法识别的设备仍存在漏洞代码，因此这些代码可被利用但不会被OSSD发现。

• OSSD不包含共享代码。使用OSSD无法解决共享代码的问题，使用共享代码开发的程序若安装了补丁，可能会导致共享代码发生变化。参见2.5.2.6节。

2.5.1.2 漏洞扫描器提供的实际状态数据

漏洞扫描是在实际状态中查找CVE的最常用方法之一。漏洞扫描器将存在漏洞的软件文件版本列表与系统设备上的实际软件文件版本进行对比。

为确保风险识别的准确性，建议对漏洞扫描器功能进行验证，保证扫描结果的可靠性。漏洞扫描器验证过程包括以下步骤：

• 确保组织编写的漏洞扫描器可检查大部分已知漏洞。否则，该漏洞扫描器可能会漏报漏洞。组织将扫描器发现的漏洞与NVD进行对比，明确该扫描器发现的已知漏洞的百分比，并将该百分比纳入扫描器采购流程。

• 确保扫描器的误报率和漏报率在可接受范围内。没有任何一项测试是百分百可靠。扫描器扫描漏洞时可能会上报不存在的漏洞（误报），也可能不上报确实存在的漏洞（漏报）。采购流程中要评估扫描器的误报率和漏报率。一般情况下，误报率和漏报率成反比—一个较高，另一个必然较低。需平衡两者，也就是说，避免过多误报和过多漏报。

• 确保新漏洞发现时，漏洞扫描器厂商及时提供更新，而且扫描器可快速更新，提供新的检测代码。请注意，检测（扫描）和响应（安装补丁）对于实现有效漏洞管理来说不可或缺。

2.5.1.3 软件白名单提供的实际状态数据

若能获得有漏洞软件文件的数字指纹，我们可根据数字指纹制作软件文件列表，从而准确、可靠地识别设备中的软件数字指纹。更多详情，参见2.5.2.3节。

软件白名单中数据的主要问题是：截至本文写作时，NVD或厂商对明确包含已知漏洞的软件文件尚未提供任何数字指纹。

2.5.1.4 代码分析器提供的实际状态数据

静态和动态代码分析器（参见术语表）用于识别可能成为漏洞的编码缺陷。通常，在软件运行前部署代码分析器（即在系统工程/系统开发生命周期早期），原因是在开发早期修复发现的缺陷成本较低。

若组织无法控制源代码但希望评估购买的产品（或考虑购买的产品）是否采取了安全设计，通常会部署动态代码分析器识别和诊断安全缺陷。组织在模拟生产的测试环境中部署采购的代码（最好在最终采购决策前），根据其风险承受能力评估缺陷是否可接受。

2.5.2 采集期望状态数据

VUL能力的期望状态为将可接受软件文件版本列举出来，将网络中已安装软件的已知缺陷限制在组织的风险承受范围内。因此，对于网络中的所有软件文件来说，要定义期望状态需知晓如何确定存在最少已知缺陷的最佳版本（即补丁级别）。正如下述数据采集方法所述，期望状态的识别是个持续演进过程，需纳入和整合多个来源的信息，有时，还需根据具体情况考虑组织的风险承受能力。

每项能力的期望状态数据都需要有效配置管理。附录G介绍了如何对期望状态进行配置管理。附录G中的控件为VUL能力评估过程的元控件。

2.5.2.1 国家漏洞数据库（NVD）

VUL能力的期望状态是尽可能使用无缺陷（CVE）软件，而NVD是CVE的重要信息来源。每个CVE都有唯一标识符，NVD是CVE的权威性来源。由于NVD数据为网上公共资源，多方均通过下载NVD数据并结合其他数据识别和修复漏洞，如包含CVE的软件文件特征、CVE相关文章或CVE补丁号。

2.5.2.2 漏洞扫描器

除了提供实际状态数据（参见2.5.1.2节），漏洞扫描器也能提供期望状态数据。漏洞扫描器从NVD上获得CVE信息、将CVE与包含CVE漏洞的软件的标识符相关联，检查联网设备上的软件是否存在CVE缓解补丁，从而检测出系统内联网设备的软件存在的已知漏洞。就特定扫描而言，期望状态指软件中不存在CVE漏洞。

说明：任一漏洞扫描器可能只检测一部分已知漏洞，所以各检测器对期望状态的定义不尽相同。

2.5.2.3 开发人员包清单

漏洞扫描器具备商业可行性的其中一个原因是，扫描器在扫描时，将设备上的代码与已知包含CVE的代码进行比对，提供的结果与实际情况较为接近（可接受精度范围内）。包清单若列明每个文件的数字签名，则提供了更可靠的CVE漏洞识别方法和修复补丁。开发人员一般会针对每个版本提供以下补丁级文件列表信息：

• 版本中的CVE漏洞。

• 列明包含每个漏洞的软件文件、含有漏洞修复的文件以及每个文件的数字指纹。

若提供补丁级清单信息，扫描器可非常准确地描述设备上漏洞的实际状态（CVE漏洞）和期望状态（具体应包含哪些文件以及这些文件的补丁级别）。若采取补丁级厂商清单，非常有可能降低漏洞扫描错误率（误报和漏报）。补丁级清单可基于SWID标签编制。

2.5.2.4 批准的补丁级别列表

有些组织会直接编制一份已批准（和必要）补丁列表。该核准的补丁列表即为期望状态。任何缺乏必要补丁和/或其他缓解措施的软件都被标记为有漏洞软件。该补丁列表基于组织的风险承受能力编制，需要手动管理该列表。

2.5.2.5 CWE（编码缺陷）信息

CWE相关的VUL能力的期望状态是软件中不存在与组织的风险承受能力不一致的CWE。CWE信息采集和响应是自定义软件开发过程的重要环节。若厂商不太可能发现并上报软件漏洞，则CWE信息对于组织计划部署的商业软件至关重要。有关发现CWE（实际状态和期望状态）的工具，见2.3.2节。

2.5.2.6 共享代码

解决共享代码问题可进一步减少软件漏洞带来的风险。组织可识别不同产品更新的软件文件，并将所识别的软件文件与使用共享代码的一个或多个产品的漏洞列表进行比较，从而确定补丁中的共享代码文件是否达到期望状态。

2.5.3 发现缺陷/进行优先级排序

VUL能力侧重于将评估边界（实际状态）内发现的软件对象版本与应该存在的最新软件对象版本列表（期望状态）进行对比，并确定响应的优先级（通常对存在漏洞的软件打补丁）。期望状态软件对象是为了将未修补漏洞的风险降至最低而选择的版本。使用商业漏洞扫描器（一般内置CVE漏洞和补丁信息）比较实际状态和期望状态是最常用的方法，但在漏洞管理中，其他缺陷（如组织明确须修复的CWE）可能会被代码分析器错误地识别为未知漏洞。无论如何，完成实际状态与期望状态比较后，都要确定的缺陷进行优先级排序，以便采取合理响应措施（如首先解决高风险问题）。

本节介绍如何明确支持VUL能力所需的NIST SP 800-53控制措施和控制项，并介绍用于描述各控制措施和控制项重点关注的软件漏洞的术语。

2.6.1 必要控制措施确定流程

本NISTIR第1卷中的3.5.2节“安全控制项与能力”中详细描述了用于明确支持能力所需的NIST SP 800-53控制措施和控制项的过程。简言之，该过程包括两个步骤：

1. 用关键字搜索NIST SP800-53中的控制措施，确定可能支持该功能的控制措施或控制项。请参见附录B中的关键字规则。

2. 手动识别确实支持该能力的NIST SP 800-53控制措施或控制项（有效告警），而忽略不支持该能力的控制措施或控制项（误报）。

以上两个步骤后续会生成三套NIST SP 800-53控制措施/控制项：

1. 支持VUL能力的低风险、中风险和高风险基线中的控制措施/控制项（3.3和3.4节）。

2. 通过关键词搜索选择的低风险、中风险和高风险基线中的控制措施/控制项。不过，这些控制措施/控制项是手动确定为误报（附录C中列出）。

3. 关键词搜索后未进一步分析的基线之外的控制措施：

a. 程序管理（PM）控制措施，原因是PM控制措施不适用于单个系统。

b. 未选择的控制措施—NIST SP 800-53中未分配基线或基线中未选择的控制措施；和

c. 隐私控制措施。

组织若要开展自动化测试，参见附录D中的未分析控制措施/控制项。

2.6.2 控制项术语

支持VUL能力的许多控制项还支持其他几种能力，例如，配置管理控制措施可辅助硬件资产管理，软件资产管理和配置设置管理能力。有些控制项支持多种能力，为明确其适用范围，相关描述用大括号括起来，例如，{…软件…}，表示特定控制项支持VUL能力并针对（且仅针对）大括号内的内容。

 表3列举了VUL相关角色及其职责。图2说明了角色如何与运营概念相结合。组织若进行自动化评估，可将职责分配给承担现有角色的人员，自行定制方案。

表3 VUL相关的运营和管理角色

图1. VUL中的自动化评估涉及的主要角色

评估范围涵盖整个计算机网络上的所有软件，“整个”是指从网络最中间到网闸所在的或与其他网络相连的边界。对于VUL能力，评估范围涉及所有设备上的软件，包括扫描时发现的可移动设备上的软件。有关评估范围相关术语的更多信息和定义，参见本NISTIR第1卷中的4.3.2节。

有关VUL能力的实际状态和期望状态规范的信息，参见第3.2节中的缺陷检查表的评估标准注释部分。

请注意，许多支持VUL能力的控制措施都引用了最新的设备软件清单（或其他清单）。SWAM能力提供软件列表。此外，还要注意，根据IST SP 800-53A [SP800-53A]对测试的定义，测试VUL控制措施时，需要同时编制实际状态清单和期望状态清单，将两者进行比较。有关比较详情，参见第3.2节中的缺陷检查表。

关于如何解决自动评估的授权范围问题，参见本NISTIR第1卷的4.3.1节。简言之，对于VUL能力，NIST SP 800-53、CM-08(5)、《信息系统组件清单》|《组件无重复登记》指出，每个设备上的软件被分配到一个且仅一个授权（系统）范围。ISCM仪表盘可提供一种机制，记录软件分配的授权范围，确保所有软件分配给至少一个授权范围，而且一个软件产品不会分配给多个授权范围。

关于如何管理公共控件的继承，请参见此NISTIR第1卷的4.3.3节。对于VUL，很多实用程序、数据库管理软件产品、Web服务器软件对象以及操作系统的某些部件为其他系统提供了可继承的支持和/或控件。ISCM仪表盘可提供一种机制，记录继承相关信息和评估系统的整体风险。

该NISTIR不涉及用于设置阈值的风险评分选项的常规指南。对于VUL能力，建议组织利用指标衡量每个设备的平均风险评分和最大风险评分。需要说明的是，漏洞扫描工具可能在评估发现的漏洞时进行风险评分。

为了支持自动化评估和持续授权，应按授权范围对软件进行明确分组（请参见NIST SP 800-53中的控制项CM-8（a）和CM-8（5））。此外，还可根据人员角色（设备管理人、补丁管理人、软件管理人和软件缺陷管理人）对软件进行清晰梳理，对特定设备进行软件漏洞管理（请参见NIST SP 800-53中的控制项CM-8（4））。除了这两个重要分组，组织可能希望利用其他分组方法进行风险分析，详情请参见本NISTIR第1卷5.6节。