小蜜蜂公益译文 -- NISTIR 8011 第4卷 安全控制评估自动化支持：软件漏洞管理（上）

概要

NISTIR8011第4卷按步骤详细描述了安全控制措施的自动化评估过程，这些评估为特定评估范围（目标网络）内的漏洞管理提供了支持，并将结果应用于该网络内所有授权范围内的评估。还提供了一个流程用以评估（诊断）和响应所发现的漏洞。本文所述的与VUL能力相关的自动化控制测试与NIST的其他指南一致。

NISTIR8011第4卷提供了详细的评估计划，以评估与漏洞管理相关的控制措施的有效性。其中包括支撑该计划的具体测试、测试对于特定控制措施的适用性以及缓解评估中所发现缺陷所需的资源。可以看出，针对VUL能力，在NISTSP 800-53的低-中-高基线控制措施中，87.5%[1]的判断语句的评估可以完全或部分自动化。

本文所述方法旨在客观、及时、完整地识别支持VUL能力的安全控制的有效性缺陷，用较低成本（与手动方法相比）进行风险管理。基于安全控制的缺陷信息，可以对所发现的安全缺陷以最快的速度做有效的响应

一. 前言

1.1目的和范围

NISTIR8011第4卷为自动化评估与软件漏洞管理（VUL）中的信息安全持续监控（ISCM）安全能力相关的NISTSP 800-53[SP800-53]安全控制措施提供了操作方法。VUL能力符合NISTIR 8011第1卷[IR8011-1]中概述的原则。

本报告的范围仅限于对NIST SP 800-53中定义的管理软件安全漏洞和编码缺陷的安全控制/控制项进行评估。

1.2 目标读者

NISTIR8011第4卷针对的是VUL能力，与授权、下载、安装和/或执行软件（尤其是软件补丁）的人强相关，还与设计、编写和测试软件的人员以及希望了解非软件资产中潜在软件风险的人相关。

1.3内容简介

第2节简要介绍了VUL能力，确定了范围和目的，提供了VUL能力补充信息的链接。第3节详细介绍了VUL缺陷检测以及如何使用缺陷检测来自动评估支持VUL能力的NISTSP 800-53安全控制和控制项的有效性。第3节还提供了一些工具供组织使用，为支持软件漏洞管理的大多数控制项生成自动安全控制评估计划。

1.4与本NISTIR其他卷的关系

本NISTIR第1卷（《概述》）提供了自动化安全控制评估的概念性信息、定义和背景，方便读者理解本卷和后续卷中内容。[2]NISTIR8011第4卷假设读者熟悉第1卷中的信息以及NIST风险管理框架[SP800-37]中的概念和术语。

VUL能力可检测目标网络中已加载或运行中的有漏洞软件，并根据组织的策略进行响应。识别有漏洞的软件可以缓解漏洞。VUL能力依赖软件资产管理（SWAM）能力[IR8011-3]提供已安装软件的清单。后续要检查清单，确定是否存在已知漏洞和不规范编码实践。有时，特别是在没有补丁的情况下，可更改配置设置（NISTIR8011下一卷《配置设置管理》（CSM）能力的主要内容），通过禁用或以其他方式保护有漏洞的的软件功能来缓解漏洞，从而支持软件漏洞管理。

实际场景中，常使用漏洞扫描软件检测有漏洞的软件。如果软件扫描所基于的元数据条理清晰[3]，则可使用白名单[IR8011-3]中使用的数字指纹来准确可靠地识别有漏洞的代码，如2.5.2.3节所述。

二. 软件漏洞管理

软件漏洞管理基于这样一个认识：即使是经过组织评估和批准在系统上运行的授权软件，也可能存在已知漏洞和导致漏洞的编码缺陷（潜在未知情况）。网络设备上运行的授权软件若存在编码缺陷，也会被利用。内外部攻击者的重要攻击途径是利用软件缺陷，要么直接攻击软件本身，要么将软件作为平台，进而攻击其他资产。

攻击也会利用之前未知的软件漏洞（通常称为零日漏洞），尽管攻击已知漏洞更为常见。VUL能力将存在缺陷的软件分配给个人或团队进行响应，可以降低攻击者发现和利用软件缺陷和漏洞的概率。

2.1发现缺陷/确定响应优先级

运用VUL能力，组织可发现已授权或待授权软件[4]中的漏洞。发现了漏洞，组织才能有效地管理和保护自己。VUL能力还提供了软件管理责任视图，方便相关管理人确定已识别缺陷的优先级，做出风险响应决策（例如缓解或接受）。

VUL能力可识别网络上存在的软件（实际状态），并将其与期望状态的软件清单进行比较，以确定是否存在漏洞较少（通常较新）的软件版本可供部署，或者是否需要使用打补丁以外的缓解策略。[5]VUL能力的重点是尽可能确保目标网络上运行的所有软件不受已知漏洞的影响，并应用有效的修补和响应策略[6]。

注意，NISTIR8011第3卷定义的软件包含固件。本卷使用相同的定义。

这里的软件（代码）指各种资产，包括有时可能并未当作软件的资产。具体软件资产包括：

2.1.1操作系统软件数据库（如Windows注册表、Linux软件包管理器）中列出的已安装软件文件和产品；

2.1.2硬盘上存在但未列示在操作系统数据库中的软件文件和产品；

2.1.3移动代码；

2.1.4可以修改的固件（通常包括BIOS）；

2.1.5内存中的代码（可以就地修改）。

2.2VUL攻击场景和期望结果

NISTIR8011使用攻击步骤模型总结了网络攻击的六大步骤，这里的“网络攻击”指NIST SP 800-53中的控制措施共同拦截或延缓的攻击。VUL安全能力仅限于在图1和表1所列的攻击步骤中拦截或延缓攻击。

图1. VUL对攻击步骤模型的影响

表1. VUL对攻击步骤模型的影响

需求层级之间的可追溯性。表1显示了软件漏洞管理对示例攻击步骤的影响，但通常更有用的是观察其他需求集之间的可追溯性。为了检视这种可追溯性，可以使用表2来显示不同需求类型之间的可追溯性，方法是在对应的行和列中查找单元格，然后单击链接。例如，点击“示例攻击步骤”一列中表6的链接，可以发现该攻击步骤和子能力/缺陷检测ID、名称和目的之间的关系。

控制措施和攻击步骤之间的完整可追溯性要求在路径中加上以下链接：

1. 控制到控制项（在控制项名称中提供）
2. 控制项到判断语句（见3.3节）
3. 判断语句到缺陷检测（即子能力；见3.3节）
4. 缺陷检测（即子能力）到能力（在子能力名称中提供）
5. 缺陷检测（以及能力）到攻击步骤（见表6）
6. 能力到攻击步骤（见图1（对表6的总结））

表2. 需求层级之间的可追溯性

a各四级标题（如3.3.1.1）为支持该能力的一个控制项。

b见各缺陷检测的“支持控制项”部分的表格。

2.3VUL管理和评估的评估对象

VUL能力管理和评估的对象包括软件漏洞和通过软件缓解的硬件漏洞。[7]VUL能力直接管理、评估的软件漏洞有两种：（1）在设备上使用的软件文件的特定版本和补丁级别中发现、分析并确定存在的CVE[CVE]；（2）在设备上使用的软件产品和文件的软件代码中暴露出的不规范编程实践，即CWE[CWE]。当设备上运行的软件中包含的CVE和CWE引起的风险若在组织可容忍的范围内，即认为设备受到保护。

系统上的软件漏洞数量随着时间的推移而有增有减。发现了新漏洞，则数量增加；漏洞被修复，则数量减少。需要定期重复评估，以保持信息的时效性。

VUL能力重在防护已知漏洞，因为针对这些漏洞，潜在攻击者能够以很低的成本轻松获取攻击知识和工具。大多数已知漏洞有修补程序（否则，该漏洞被视为零日漏洞，因为该漏洞虽被披露，却没有可用的缓解措施；见2.3.1节）。遗憾的是，已知漏洞并不总能及时修补，也就是说，在任何时候，某些系统和系统组件都可能存在未修补的、可利用的软件漏洞。

合理的漏洞管理程序，即使是只关注已知漏洞，也有助于抵御有钱、有干劲、有能力的攻击者。老练的攻击者会花费大量资源来发现、武器化和隐藏未知漏洞。他们在部署武器化的未知漏洞方面非常谨慎，因为这种行为有暴露漏洞的风险（即从未知变为已知），一旦暴露，可能会被防御方缓解和修复。因此，有钱、有干劲、有能力的攻击者通常更倾向于利用已知漏洞进行攻击，因为已知漏洞的攻击成本低，利用这些漏洞就不需要浪费宝贵的未知漏洞资源来实现攻击目标。因此，若软件针对已知漏洞做了保护，即使是老练的攻击者也会增加攻击成本。

VUL能力还可能会处理未知漏洞，例如，扫描不规范的编码实践（如CWE）。扫描CWE可以让未知漏洞变成已知，进而处理这些漏洞。因此，虽然VUL能力主要关注的是已知漏洞（如CVE），但也会通过关注软件缺陷的常见来源（如CWE）来解决与未知漏洞相关的风险。

2.3.1 CVE

CVE项目[CVE]提供了漏洞列表，每条漏洞都包含唯一的标识号、描述以及至少一个公开参考链接。[8]这些漏洞均为特定软件中发现、公开披露且上报给https://cve.mitre.org的网络安全漏洞。CVE因为具有如下重要特征，因而适用于自动评估：

• CVE是描述软件中包含的公开披露的网络安全漏洞的标准方法；
• CVE列表是一个字典，每个漏洞或暴露就是一个条目；
• 每个CVE具有唯一标识符，可在业界各软件系统间通用；
• 同一CVE在不同的产品、工具和服务间具有相同含义。

漏洞一旦被公开且被分配CVE ID，维护软件的厂商组织[9]就会着手开发补丁来修复该漏洞。对编码缺陷进行修复（打补丁等方法）的目的是在攻击者发现并利用它们之前发现并缓解问题。对于防御者来说，挑战在于在管理不断增加的代码复杂性的同时，还要领先于攻击者一步。

从（某人）发现漏洞到软件控制组织知道漏洞并提供补丁期间，该漏洞被称为零日漏洞。在这段时间内，软件一直暴露在风险之下，直到发布并应用补丁。在暴露期间，防御攻击的选项仅限于白名单、[10]应用常见的安全配置、隔离或删除。

在评估风险时，应明白上报的软件漏洞数量不一定与软件厂商和产品中的实际软件漏洞数量相一致。攻击者希望经济高效地利用漏洞，这样，跨平台（如Acrobat和Java）实现的软件或在主流平台（如微软或思科）上实现的软件最具吸引力，因为所需要的时间最少。所以，基于主流平台的软件代码报告的漏洞最多。

上报的漏洞数量多可能是由于漏洞研究和报告越来越集中于主流软件。通常情况下，某一系列软件版本中公开披露的漏洞数量越多，说明软件提供商的成熟度越高。软件平台提供商常拥有强大的漏洞披露、上报和管理程序，这些都说明软件提供商具有良好的风险管理实践。反之，没有上报漏洞的产品不一定就没有漏洞。

国家漏洞数据库[NVD]以标准的机器可读格式向公众发布CVE信息。就已知软件漏洞和漏洞信息分析而言，NVD是美国政府最全面的一种公开信息来源。CVE项目还维护了一个CVE数据集，该数据集可能包含更多的漏洞[11]，但提供的漏洞相关信息较少。在本文件中，术语NVD同时指nvd.nist.gov和cve.mitre.org。有时，业界会发现尚未在NVD中分类的公开披露的漏洞，但此类来源通常是未公开的私有渠道。

漏洞一般通过以下方式识别：

• NVD[NVD]中的每条CVE由CVE[CVE]编号机构[CNA]分配ID。CNA可以是厂商、开源提供商或研究人员。NVD从CVE获取数据。
• 知名的软件制造商拥有成熟强大的漏洞管理程序，它们会上报已验证漏洞。
• 第三方道德黑客上报漏洞。

有些可利用的代码漏洞未通过CVE项目公开，因此未作为CVE列入NVD。[12]已知漏洞未公开披露的原因可能有多种，包括但不限于：

• 只有犯罪分子和/或情报机构发现了漏洞，他们打算有朝一日利用该漏洞，因此不想披露。
• 漏洞可能只存在于定制软件和/或工业控制系统中。由于用户数量有限且所涉及系统具有潜在敏感性，漏洞未在NVD中列出，可能的原因是披露这些漏洞或会增加攻击的风险，而不是保护受影响的系统。
• 漏洞存在于商用现成（COTS）软件中，但在补丁出现之前不会公布，因为披露该漏洞可能会增加攻击风险，而不是保护系统。
• 漏洞扫描提供商可能在分配CVE ID之前已发现漏洞。

由于厂商和攻击者在公开漏洞方面存在的差异，再加上攻击者发现漏洞后有意瞒报，软件产品的CVE数量不一定能反映产品的实际漏洞数量。

2.3.2 CWE

CWE是一种广为人知的分类法，针对的是生产软件过程中发现的不规范编码实践[CWE]，例如“输入验证问题”，CWE网站上对此描述如下：

“软件不能正确验证输入时，攻击者就能构造输入，让应用程序的其他部分无法识别，这样，系统的某些部分就会接收到意外输入，导致控制流改变、任意资源控制或任意代码执行。”[CWE]

缺乏充分验证的话，攻击者就能以意外方式更改程序流，造成安全漏洞。更多例子，见[CWE]。

与自动化评估相关的常见缺陷具有以下重要特征：

• 代码分析器一般要么是静态，要么是动态。静态代码分析器用于检查源代码（编程语言级别）或编译代码（机器语言级别）。动态代码分析器用于观察代码执行时的行为、探测应用程序以及分析应用程序响应。
• 虽然NVD中的CVE描述通常会提供导致CVE的不规范编码实践（即CWE）的相关信息，但CWE并不一定会导致CVE。如果没有对代码进行分析、探测，或者未检测缺陷，那么就可能忽略缺陷。这种情况下，缺陷可能最终会发展为CVE。
• 即使对代码进行了分析且将一段代码标记为了CWE，仍不一定会实际导致CVE，因为用于检测不规范编码实践的代码分析器会有大量误报（代码分析器将代码标识为包含不规范的编码实践，而实际并非如此）。
• 代码分析器识别出的、未验证为误报的不规范编码实践被视为软件漏洞。由于代码分析器报告经常出现误报，一般通过对所识别的不规范编码实践进行单独确认和验证进行修正。对所谓的不规范编码实践需要进一步分析，确定应该忽略（确定是误报），还是采取行动（问题确实存在），进行恰当响应或上报。
• CWE主要是控制、维护源代码的开发或测试人员最为关注，这类人群所在的组织主要开发COTS、政府现成（GOTS）或定制代码。此外，将软件部署到生产环境中之前需要验证软件安全性（即需要额外的软件安全保证）的组织也会关注CWE。

确保代码不包含CWE的方法主要有三种，按有效性排序，分别为：

1. 招募有安全编码实践经验的开发人员，同时确保现有开发人员接受安全编码实践培训；
2. 采用流程：确保代码由具有安全编码实践经验的程序员团队独立审查；
3. 使用代码分析器：在编写或编译代码后，代码分析器常常能发现代码中的不规范代码实践；此外，代码分析器还会自动检查应用程序。

2.3.3 CVE和CWE缓解角色

要理解NISTIR 8011所定义的漏洞管理角色，首先要了解组织角色。卡内基梅隆CERT的特别报告《CERT漏洞协同披露指南》[SEI]描述了漏洞管理角色，如下图所示。

图2. 漏洞信息披露中的组织角色[SEI]

角色有时是组织，有时是个人。

• 最常见的个人角色包括：发现者、上报者和部署者（例如家庭用户、组织用户、系统管理员）。
• 最常见的组织角色包括：厂商和协调者，若软件为政府或商业组织所使用，还有部署者（例如软件漏洞管理人、补丁管理人）。

“厂商”这一角色需要进一步解释。这类实体指当前维护有漏洞软件的一方。正如卡内基梅隆CERT报告所述，“厂商是负责更新有漏洞产品的一方。”因此，在漏洞管理方面，厂商并非部署者（个人用户或组织）所购买软件的第三方厂商。

请注意，对于定制或内部软件代码，“负责更新产品的一方”可能是部署者组织内部的员工或团队，也可能是部署者组织合作的服务提供商。

图2中所示的协调者角色通常独立于评估组织，不属于NISTIR8011范围，在此不予赘述。通常，协调者角色由SEI、漏洞扫描器厂商和源文档中列出的其他团队执行。

对于维护和授权的软件，NISTIR8011定义的CWE和CVE缓解角色包括软件漏洞管理人（SWFM）（与CERT定义的厂商角色对应）和补丁管理人（PatMan）（与CERT定义的部署者角色对应）。[13]图3列举了NISTIR8011为缓解CWE和CVE而定义的角色及其职责。请注意，对于未授权软件，不会为CVE开发补丁，除了隔离或删除之外，可能没有其他的缓解办法。

图3. CVE和CWE缓解角色

SWFM和PatMan角色的职责不一定是只完成图3中的任务，相反，这些任务可能是某个角色多项职责中的一部分。

2.3.3.1 软件漏洞管理人（SWFM）

SWFM是厂商组织角色。因此，软件漏洞管理可能是第三方厂商组织的责任，软件所有组织对此几乎没有控制权（例如，对于大多数COTS软件），也可能是软件所有组织本身的责任（例如，对于内部开发的定制软件）。

当发现并确认厂商组织维护的软件存在新漏洞时，将漏洞上报给CVE项目，以便将其列为CVE（或决定不上报漏洞或何时上报漏洞[16]）。厂商组织（维护软件源代码的组织）内部的软件漏洞管理人（SWFM）随后开发新补丁以缓解漏洞。

• 对于COTS或外部维护的GOTS软件，补丁由外部厂商组织的SWFM开发。
• 对于定制或内部维护的GOTS软件，补丁由内部组织（厂商和部署者）的SWFM开发。

无论是缓解CVE还是CWE，SWFM都负责向厂商组织上报所维护软件中发现的不规范编码实践和漏洞，评估需修复的代码数量，进行必要的修复，准备补丁，进行集成，测试补丁，撰写文档，并将补丁发送给部署者组织。

2.3.3.2 补丁管理人（PatMan）

补丁管理人（PatMan）是部署者组织角色，存在于授权和使用软件的组织（部署者组织）中。

PatMan负责检测设备和授权软件中存在的CVE，并应用补丁或临时规避方案。此处提到的软件（即代码）通常按以下级别进行分析和管理：

• 软件文件（通过数字指纹识别）
• 软件源代码（即版本/补丁级别的软件文件内容）
• 软件产品（版本/补丁级别）
• 可修改的固件（通常包括BIOS，版本/补丁级别）

就漏洞管理而言，准确检测软件的具体版本和补丁级别非常重要。这是因为不同的软件版本根据所应用的补丁，包含不同的漏洞。数字指纹唯一地标识软件文件的特定版本和补丁级别。

PatMan在检测系统中存在的CVE时使用的主要工具是商业漏洞扫描器。漏洞扫描器自动发现系统中各个设备上安装的所有软件文件中的CVE和所需的补丁程序。同时，补丁程序也会提供它们所缓解的CVE信息。

PatMan负责从内部或外部开发组织（即厂商组织）接收补丁，测试本地系统上补丁的互通性，并将补丁应用到生产环境中的设备上。在厂商提供补丁之前，可以其他方法来缓解某些CVE。这种情况下，PatMan负责在过渡期内应用临时规避方案。

补丁通常通过软件包管理系统应用，该系统自动执行软件文件的安装、升级、配置和删除。[17]此外，也可以手动打补丁。

有些软件产品的补丁必须按顺序应用，在这种情况下，应指定补丁级别。有些产品允许按不同顺序选择性应用补丁。在这种情况下，“补丁集”一词比“补丁级别”更准确。[18]“补丁集”本质上比“补丁级别”复杂，因为补丁应用顺序有多种组合方式。本文档中，“补丁级别”一词根据实际情况可指补丁级别，也可以指补丁集。

共享代码带来的修补复杂性。有些可执行文件由多个软件产品共享。动态链接库（DLL）可执行文件就是共享软件的典型例子。就修补DLL而言，一个产品可能为其他产品带来保护，也可能将其他产品暴露于风险中，具体是保护还是暴露取决于DLL最新补丁中有哪些漏洞以及依赖软件如何使用该库。例如，在OpenSSL加密库中存在“心脏出血”（Heartbleed）漏洞，但该漏洞只影响OpenSSL提供的传输层安全性（TLS）实现，OpenSSL加密算法应用程序编程接口（API）不受该漏洞影响。也就是说，OpenSSL的TLS实现暴露了“心脏出血”漏洞，但加密函数实现却没有。因此，部分软件产品的共享性增大了软件漏洞管理的难度。

补丁之上摞补丁。遗憾的是，补丁本身也可能包含漏洞，后续才会发现。即使补丁当前没有已知漏洞，也有可能、甚至很可能在今后发现新的或其他的不规范编码实践，成为NVD中的新CVE条目或导致新的零日攻击。

2.4VUL数据需求示例[19]

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

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

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

a该值由组织根据其分配给资产的值定义。有关设备属性的说明，参见[IR8011-1] 。

b组织可以为本地环境定义数据需求和相关漏洞。

c有些已知漏洞可通过不安装部分代码段、可执行文件或通过配置选项有效缓解。

d如果可以通过检查注册表设置、可执行哈希或配置设置来确定是否已实施替代缓解方法，则可以制定规范，自动验证是否存在漏洞。

2.5VUL相关的运营实施概念

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

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

图4. VUL运营概念（CONOPS）

2.5.1 采集实际状态

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

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

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

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

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

• 软件未列入OSSD。设备中有些软件未在OSSD中列出（即，软件由于未列入OSSD而无法被OSSD识别）。
• OSSD条目无法识别安装的所有软件。对于特定产品版本来说，不同安装介质实例可能会安装稍有差别的可执行文件，因此可能存在不同漏洞。OSSD可能检测不到这一点。
• 产品卸载过程可能会删除OSSD中的软件文件条目，但不会删除所有代码。卸载过程中存在的问题可能会导致OSSD无法识别的设备仍存在漏洞代码，因此这些代码可被利用但不会被OSSD发现。
• OSSD不包含共享代码。使用OSSD无法解决共享代码的问题，使用共享代码开发的程序若安装了补丁，可能会导致共享代码发生变化。参见2.5.2.6节。

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

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

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

• 确保组织编写的漏洞扫描器可检查大部分已知漏洞。否则，该漏洞扫描器可能会漏报漏洞。组织将扫描器发现的漏洞与NVD进行对比，明确该扫描器发现的已知漏洞的百分比，并将该百分比纳入扫描器采购流程。
• 确保扫描器的误报率和漏报率在可接受范围内。没有任何一项测试是百分百可靠。扫描器扫描漏洞时可能会上报不存在的漏洞（误报），也可能不上报确实存在的漏洞（漏报）。采购流程中要评估扫描器的误报率和漏报率。一般情况下，误报率和漏报率成反比—一个较高，另一个必然较低。需平衡两者，也就是说，避免过多误报和过多漏报。
• 确保新漏洞发现时，漏洞扫描器厂商及时提供更新，而且扫描器可快速[22]更新，提供新的检测代码。请注意，检测（扫描）和响应（安装补丁）对于实现有效漏洞管理来说不可或缺。

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

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

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

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漏洞[24]。

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

2.5.2.3 开发人员包清单

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

• 版本中的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）可能会被代码分析器错误地识别为未知漏洞。无论如何，完成实际状态与期望状态比较后，都要确定的缺陷进行优先级排序[26]，以便采取合理响应措施（如首先解决高风险问题）。

2.6支持VUL的NIST SP 800-53控制措施和控制项

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

2.6.1 必要控制措施确定流程

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

1. 用关键字搜索NIST SP800-53中的控制措施，确定可能支持该功能的控制措施或控制项。请参见附录B中的关键字规则。
2. 手动识别确实支持该能力的NISTSP 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能力并针对（且仅针对）大括号内的内容。

2.7VUL角色和责任

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

表5. VUL相关的运营和管理角色[27]

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

2.8VUL评估范围

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

2.9VUL的实际状态和期望状态规范

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

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

2.10VUL授权范围和继承

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

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

2.11VUL评估标准建议的分数和风险接受阈值

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

2.12VUL评估标准涉及的设备分组

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

参考文献

[1]根据本卷中的控制分配表（CAT）得来。对于NISTSP 800-53[SP800-53]低-中-高基线中选取的支持VUL能力的安全控制措施，48个判断语句中有42个（87.5%）可以完全或部分自动化。

[2]NISTIR8011第1卷（2017年6月）将VUL能力作为NISTIR 8011的第5卷。但是，后来发现，NISTIR 8011各功能卷的发布顺序需要优化，因此将VUL能力调整到第4卷。NISTIR 8011各能力卷的发布顺序将在第1卷的勘误版本中进行修订。

[3]条理清晰是指已知哪些软件代码文件（通过其数字指纹识别）存在漏洞，并使用软件白名单来确定是否存在有漏洞的文件。

[4]特定的软件产品得到授权后，作为组件在联网或未联网的系统上运行。而考虑到效率和有效性，系统和系统组件需要网络连接进行自动化评估。独立的系统/系统组件不适合自动评估。有关授权范围（系统）与自动评估范围（网络）的信息，参见NISTIR 8011第1卷。

[5]关于实际和期望状态的描述，见2.5.1和2.5.2节。

[6]修补和响应策略可纳入组织的漏洞管理策略。

[7]硬件漏洞通常通过软件来防护，例如为固件或操作系统打补丁，控制硬件访问或关闭硬件功能。在NISTIR 8011中，软件漏洞包括通过软件缓解的硬件漏洞。若硬件漏洞无法通过软件防护，需要对硬件进行物理修改或更换，这种漏洞不在NISTIR8011第4卷讨论之列。

[8]本文发布时，CVE项目正处于过渡期，CVE项目的管理组织和相关网站可能会发生变化。

[9]有关厂商组织的定义，参见2.3.3节。

[10]请注意，虽然恶意软件因为未授权而无法在白名单环境中运行，攻击者仍然可以通过白名单软件本身的未缓解漏洞进入环境。因此，即使在白名单软件环境中，软件漏洞管理也是高优先级事项。

[11]MITRE网站[CVE]上列出的CVE描述不够完整，所以链接到NVD以提供更多信息。本文发布时，CVE项目正处于过渡期，CVE项目的管理组织和相关网站可能会发生变化。

[12]有些厂商组织选择不向CVE项目报告漏洞，而是通过本公司专有流程维护漏洞信息并提供补丁。

[13]有关支持VUL能力的各个角色，参见2.7节。

[14]注意，SWFM角色通常是软件开发/维护人员或软件开发/维护管理人的子角色，而不是完全独立的角色。这里指定SWFM角色有助于缓解软件漏洞，构成VUL能力的一部分。

[15]在他人开发的软件中查找CWE主要适用于如下情况：部署组织有内部SWFM并使用动态代码扫描器来检测他人开发的COTS或GOTS产品中的不规范编码实践（CWE）。

[16]例如，直到开发出补丁后再上报漏洞，防止在此期间被攻击。

[17]Microsoft Windows Store、Linux Red Hat RPM package Manager、Apple Mac App Store、Debian DPKG和Perl综合典藏网（Comprehensive Perl Archive Network）都是软件包管理系统。

[18]如果指定了补丁集，则补丁的应用顺序仍会影响结果（例如，当两个或多个补丁更改同一个文件时）。

[19]支持VUL能力所需的特定数据因组织平台、工具、配置等而异。

[20]完全没有已知漏洞几无可能，也不现实（例如，当尚未提供补丁或尚未修补低风险漏洞时），因此，目标是尽量降低环境中的已知漏洞数量。

[21]例如，Windows注册表或Linux包管理器

[22]由组织根据攻击者预期利用未知漏洞进行攻击的速度而定义。

[23]要求厂商基于数字指纹上报数据从而实现可靠的漏洞检测对于漏洞检测过程来说是一项重大提升。

[24]准确地说，预期状态指所有软件都安装补丁，符合组织的风险承受能力。例如，一些组织可承受其认为的低风险CVE漏洞。

[25]包清单列明了补丁发布涉及的文件。若清单列明了每个文件的数字指纹，可对补丁全部内容的完整性/真实性进行验证。因此，为了更可靠地识别CVE漏洞，软件厂商需提供包清单列明每个文件的数字指纹。

[26]对缺陷进行评分或优先级排序所必需的风险优先级排序方法不在本出版物的范围内。有关风险管理，风险评估和风险优先级的讨论，请参见[SP800-30]和[SP800-39]。

[27]若未明确说明该角色为自动化，则由个人或团队担任。

[28]漏洞管理过程中，利用风险评分（也称“缺陷评分”）衡量缺陷的可利用性。

原文链接：https://csrc.nist.gov/publications/detail/nistir/8011/vol-4/final

关于小蜜蜂翻译组公益译文项目

小蜜蜂翻译组公益译文项目，旨在分享国外先进网络安全理念、规划、框架、技术标准与实践，将网络安全战略性文档翻译为中文，为网络安全从业人员提供参考，促进国内安全组织在相关方面的思考和交流。

内容编辑：翻译组郝秀文 责任编辑：高深