阅读： 6
2.4 VUL数据需求示例
VUL能力的期望状态是：已知漏洞列表准确、完整，包含最新信息；所有设备上安装的软件产品均无已知漏洞。实际状态的VUL能力数据需求的示例见表3。期望状态的VUL能力数据需求示例见表4。
| 数据项 | 理由 |
| 发现每台设备上安装的软件中存在的漏洞 | 识别软件漏洞 |
| 符合替代性缓解要求的设备软件（包括已修复漏洞的相关CVE或本地标识符） | 防止已修复漏洞出现在结果中 |
| 用以确定漏洞在设备中存在时间的数据；至少包括： 首次在设备上发现漏洞的日期/时间最后一次在设备上发现漏洞的日期/时间 | 确定漏洞在设备中存在的时间 |
| 数据项 | 理由 |
| 授权硬件清单 | 确定需要检查哪些设备 |
| 设备各属性关联值a | 确定设备相关漏洞的优先级 |
| 列出包含至少一个漏洞的所有软件产品，该列表要有版本控制且注明日期，包括如下内容： 与“授权软件清单”格式相同的有漏洞软件产品（类似于通用平台枚举项[CPE] 或软件标识[SWID][IR8060]）与软件产品相关的所有CVE与软件产品相关的所有CWE 列出本地定义b的已知漏洞，该列表应有版本控制且注明日期，包括如下内容： 与“授权软件清单”格式相同的有漏洞软件产品（类似于CPE或SWID）与软件产品相关的所有本地漏洞标识符（类似于CWE等）各本地漏洞的严重性（类似于通用漏洞评分系统[CVSS] 分数） | 上报系统中存在的已知漏洞 |
| 针对已知漏洞的替代性缓解要求c，其中源厂商提供了可实施的缓解方案，而不是修补软件或发布新版本，内容包括： CVE或本地标识符相关系统属性需求/可接受值 | 避免上报通过替代方法缓解的漏洞，这种情况下，可自动检查缓解情况d |
| 合规性定义（期望状态规范标准） | 确定是否通过各项具体检查 |
a该值由组织根据其分配给资产的值定义。有关设备属性的说明，参见[IR8011-1]。
b 组织可以为本地环境定义数据需求和相关漏洞。
c 有些已知漏洞可通过不安装部分代码段、可执行文件或通过配置选项有效缓解。
d 如果可以通过检查注册表设置、可执行哈希或配置设置来确定是否已实施替代缓解方法，则可以制定规范，自动验证是否存在漏洞。
2.5 相关的运营实施概念
VUL识别网络设备（实际状态）中实际存在的软件（包括虚拟机上的软件），将这些软件与期望状态列表对比，明确软件中存在哪些已知漏洞（或缺陷），并安装补丁（或其他缓解方法），降低系统漏洞的可利用性。
软件漏洞管理能力运营概念（CONOPS）定义了如何实现VUL能力，是自动化评估流程的核心。请参见图4。
2.5.1 采集实际状态
ISCM数据采集流程利用工具识别补丁级别的网络设备中的软件文件（和产品），包括大容量存储器和固件中的软件。这些工具进一步提供必要信息，将实际软件与发现的补丁级别（实际状态）与授权的补丁级别（期望状态）进行比较。本节通过举例介绍用于识别实际和期望补丁级别的方法。
同时，ISCM数据采集流程还会明确目标网络的监控范围和频率，最终确定完整性和及时性度量标准。设备可能因为以下各种原因而无法监控：（1）设备未联网，可能在特定扫描过程中检测不到；（2）设备关掉；扫描过程中发生错误；（3）设备位于扫描范围之外的被保护地区；（3）设备在预期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）可能会被代码分析器错误地识别为未知漏洞。无论如何，完成实际状态与期望状态比较后，都要确定的缺陷进行优先级排序，以便采取合理响应措施（如首先解决高风险问题）。
2.6 VUL的NIST SP 800-53控制措施和控制项
本节介绍如何明确支持VUL能力所需的NIST SP 800-53控制措施和控制项，并介绍用于描述各控制措施和控制项重点关注的软件漏洞的术语。
2.6.1 必要控制措施确定流程
- 用关键字搜索NIST SP800-53中的控制措施，确定可能支持该功能的控制措施或控制项。请参见附录B中的关键字规则。
- 手动识别确实支持该能力的NIST SP 800-53控制措施或控制项（有效告警），而忽略不支持该能力的控制措施或控制项（误报）。
以上两个步骤后续会生成三套NIST SP 800-53控制措施/控制项：
- 支持VUL能力的低风险、中风险和高风险基线中的控制措施/控制项（3.3和3.4节）。
- 通过关键词搜索选择的低风险、中风险和高风险基线中的控制措施/控制项。不过，这些控制措施/控制项是手动确定为误报（附录C中列出）。
- 关键词搜索后未进一步分析的基线之外的控制措施:
- 程序管理（PM）控制措施，原因是PM控制措施不适用于单个系统。
- 未选择的控制措施—NIST SP 800-53中未分配基线或基线中未选择的控制措施；和
- 隐私控制措施。
组织若要开展自动化测试，参见附录D中的未分析控制措施/控制项。
2.6.2 控制项术语
支持VUL能力的许多控制项还支持其他几种能力，例如，配置管理控制措施可辅助硬件资产管理，软件资产管理和配置设置管理能力。
有些控制项支持多种能力，为明确其适用范围，相关描述用大括号括起来，
例如，{…软件…}，表示特定控制项支持VUL能力并针对（且仅针对）大括号内的内容。
2.7 VUL角色和责任
表5列举了VUL相关角色及其职责。图5说明了角色如何与运营概念相结合。组织若进行自动化评估，可将职责分配给承担现有角色的人员，自行定制方案。
| 角色代码 | 角色名称 | 角色描述 | 角色类型 |
| DSM | 期望状态管理人（DSM） | ISCM目标网络和每个评估对象都需要期望状态管理人。期望状态管理人确保将定义相关能力期望状态的数据输入到ISCM系统的期望状态数据中，并且确保该数据的可用性，为实际状态收集子系统提供指导性信息，帮助识别缺陷。ISCM目标网络的DSM还要明确哪个系统授权范围存在缺陷（若有）。 授权者也承担部分责任，对特定项目（例如设备、软件或设置）进行授权，按照DSM委托，定义期望状态。DSM负责监督和组织这项活动。 | 运营 |
| ISCM-Ops | ISCM 运营商（ISCM-Ops） | ISCM运营商负责ISCM系统运营（参见ISCM-Sys）。 | 运营 |
| ISCM-Sys （自动化） | 用于采集、分析和显示ISCM安全相关信息的自动化系统 | ISCM-Sys是自动化角色，负责按照本NISTIR描述的方法执行自动化任务。 ISCM系统：a）收集期望状态规范， b）从传感器（例如扫描器、代理和培训应用程序）收集安全相关信息，并且c）将这些信息转化为有用形式。 为了支持任务C，系统会执行特定缺陷检查，将缺陷信息发送到涵盖相关系统的ISCM仪表盘。ISCM系统负责评估大多数NIST SP 800-53安全控制措施。 | 运营（自动） |
| MAN | 评估人员 | ISCM系统无法自动进行的评估由评估人员使用手动/程序方法完成。有数据质量担忧时，也可进行手动/过程评估对ISCM系统收集的自动化安全相关信息进行验证。 | 运营 |
| PatMan | 补丁管理人（PatMan） | 补丁管理人分配给特定设备或设备组，负责修复受影响的设备上的软件产品。补丁管理人在期望状态规范中指定。补丁管理人可以是个人或小组。若是小组，则需指定组管理人。 说明：补丁管理人角色可由设备管理人通过HWAM能力履行，也可由SWMan通过SWAM能力执行，具体取决于所需的补丁安装量。该角色也可由集中式或分布式补丁管理团队管理的自动化中央过程执行。 | 运营 |
| RskEx | 风险管理人员、系统负责人和/或授权人员（RskEx） | SP 800-37 [SP800-37]和SP 800-39 [SP800-39]中定义。 | 管理 |
| SWFM | 软件缺陷管理人（SWFM） | 软件缺陷管理人分配给特定软件产品或软件产品组，负责确保发现并修改导致授权软件中存在漏洞的CWE。因此，SWFM通常是开发/维护团队的一部分。SWFM在软件产品的期望状态规范中指定。SWFM可能是个人或小组。若是小组，则需指定小组管理人。 说明：大多数SWFM活动在系统工程期间进行，软件在目标网络的生产环境中使用时，会使用该过程中获得的数据进行缺陷评分。很多（但并非全部）COTS软件制造商自行跟踪缺陷，进行评分。 SWFM支持期望状态管理人，确保针对定制软件和制造商未跟踪安全缺陷的软件，跟踪不规范编码带来的风险。 | 运营 |
| SWMan | 软件管理人 | 软件管理人分配给特定设备，负责设备软件的安装和/或删除。软件管理人的主要职责是仅安装授权的软件，并及时删除所有发现的未授权软件。软件管理人还负责确保软件媒体可支持撤销更改，并将软件还原到之前状态。 此角色可由DM（设备管理人）和/或PatMan（补丁管理人）履行。 如果授权用户安装软件，则他们也是相关设备的SWMan（软件管理人）。 | 运营 |
2.8 VUL评估范围
评估范围涵盖整个计算机网络上的所有软件，“整个”是指从网络最中间到网闸所在的或与其他网络相连的边界。对于VUL能力，评估范围涉及所有设备上的软件，包括扫描时发现的可移动设备上的软件。有关评估范围相关术语的更多信息和定义，参见本NISTIR第1卷中的4.3.2节。
2.9 的实际状态和期望状态规范
有关VUL能力的实际状态和期望状态规范的信息，参见第3.2节中的缺陷检查表的评估标准注释部分。
请注意，许多支持VUL能力的控制措施都引用了最新的设备软件清单（或其他清单）。SWAM能力提供软件列表。此外，还要注意，根据IST SP 800-53A [SP800-53A]对测试的定义，测试VUL控制措施时，需要同时编制实际状态清单和期望状态清单，将两者进行比较。有关比较详情，参见第3.2节中的缺陷检查表。
2.10 授权范围和继承
关于如何解决自动评估的授权范围问题，参见本NISTIR第1卷的4.3.1节。简言之，对于VUL能力，NIST SP 800-53、CM-08(5)、《信息系统组件清单》|《组件无重复登记》指出，每个设备上的软件被分配到一个且仅一个授权（系统）范围。ISCM仪表盘可提供一种机制，记录软件分配的授权范围，确保所有软件分配给至少一个授权范围，而且一个软件产品不会分配给多个授权范围。
关于如何管理公共控件的继承，请参见此NISTIR第1卷的4.3.3节。对于VUL，很多实用程序、数据库管理软件产品、Web服务器软件对象以及操作系统的某些部件为其他系统提供了可继承的支持和/或控件。ISCM仪表盘可提供一种机制，记录继承相关信息和评估系统的整体风险。
2.11 VUL评估标准建议的分数和风险接受阈值
该NISTIR不涉及用于设置阈值的风险评分选项的常规指南。对于VUL能力，建议组织利用指标衡量每个设备的平均风险评分和最大风险评分。需要说明的是，漏洞扫描工具可能在评估发现的漏洞时进行风险评分。
2.12 评估标准涉及的设备分组
为了支持自动化评估和持续授权，应按授权范围对软件进行明确分组（请参见NIST SP 800-53中的控制项CM-8（a）和CM-8（5））。此外，还可根据人员角色（设备管理人、补丁管理人、软件管理人和软件缺陷管理人）对软件进行清晰梳理，对特定设备进行软件漏洞管理（请参见NIST SP 800-53中的控制项CM-8（4））。除了这两个重要分组，组织可能希望利用其他分组方法进行风险分析，详情请参见本NISTIR第1卷5.6节。
译者声明：
小蜜蜂翻译组公益译文项目，旨在分享国外先进网络安全理念、规划、框架、技术标准与实践，将网络安全战略性文档翻译为中文，为网络安全从业人员提供参考，促进国内安全组织在相关方面的思考和交流。