摘要
NISTIR 8011专项能力卷针对各信息安全能力就安全控制评估的自动化进行了规范。各卷围绕NISTIR 8011第1卷中的相关概述内容进行了详细阐述，可作为模板，为实施符合NIST标准的具体的自动化评估做好准备。本文为NISTIR 8011第4卷，详细介绍了如何自动评估与软件漏洞管理安全能力相关的安全控制措施，以便管理软件缺陷带来的网络风险。本文档中，软件漏洞管理针对的是系统中所使用软件的已知缺陷。通用缺陷列表（CWE）为不规范编码实践所导致且有可能导致软件漏洞的缺陷提供了标识符，常见漏洞与暴露（CVE）列举了大量已知漏洞。可结合使用CVE和CWE来识别软件缺陷和导致特定缺陷的问题。有漏洞的软件是攻击者的重要目标，被用于发起内部攻击并扩大控制。
一、前言
1.1 目的和范围
NISTIR 8011第4卷为自动化评估与软件漏洞管理（VUL）中的信息安全持续监控（ISCM）安全能力相关的NIST SP 800-53[SP800-53]安全控制措施提供了操作方法。VUL能力符合NISTIR 8011第1卷[IR8011-1]中概述的原则。
本报告的范围仅限于对NIST SP 800-53中定义的管理软件安全漏洞和编码缺陷的安全控制/控制项进行评估。
1.2 目标读者
NISTIR 8011第4卷针对的是VUL能力，与授权、下载、安装和/或执行软件（尤其是软件补丁）的人强相关，还与设计、编写和测试软件的人员以及希望了解非软件资产中潜在软件风险的人相关。
1.3 内容简介
第2节简要介绍了VUL能力，确定了范围和目的，提供了VUL能力补充信息的链接。第3节详细介绍了VUL缺陷检测以及如何使用缺陷检测来自动评估支持VUL能力的NIST SP 800-53安全控制和控制项的有效性。第3节还提供了一些工具供组织使用，为支持软件漏洞管理的大多数控制项生成自动安全控制评估计划。
1.4 与本NISTIR中其他卷的关系
本NISTIR第1卷（《概述》）提供了自动化安全控制评估的概念性信息、定义和背景，方便读者理解本卷和后续卷中内容。[1]NISTIR 8011第4卷假设读者熟悉第1卷中的信息以及NIST风险管理框架[SP800-37]中的概念和术语。
VUL能力可检测目标网络中已加载或运行中的有漏洞软件，并根据组织的策略进行响应。识别有漏洞的软件可以缓解漏洞。VUL能力依赖软件资产管理（SWAM）能力[IR8011-3]提供已安装软件的清单。后续要检查清单，确定是否存在已知漏洞和不规范编码实践。有时，特别是在没有补丁的情况下，可更改配置设置（NISTIR 8011下一卷《配置设置管理》（CSM）能力的主要内容），通过禁用或以其他方式保护有漏洞的的软件功能来缓解漏洞，从而支持软件漏洞管理。
实际场景中，常使用漏洞扫描软件检测有漏洞的软件。如果软件扫描所基于的元数据条理清晰[2]，则可使用白名单[IR8011-3]中使用的数字指纹来准确可靠地识别有漏洞的代码，如2.5.2.3节所述。
二、软件漏洞管理（VUL）能力定义、概述和范围
软件漏洞管理基于这样一个认识：即使是经过组织评估和批准在系统上运行的授权软件，也可能存在已知漏洞和导致漏洞的编码缺陷（潜在未知情况）。网络设备上运行的授权软件若存在编码缺陷，也会被利用。内外部攻击者的重要攻击途径是利用软件缺陷，要么直接攻击软件本身，要么将软件作为平台，进而攻击其他资产。
攻击也会利用之前未知的软件漏洞（通常称为零日漏洞），尽管攻击已知漏洞更为常见。VUL能力将存在缺陷的软件分配给个人或团队进行响应，可以降低攻击者发现和利用软件缺陷和漏洞的概率。
2.1 发现缺陷/确定响应优先级
运用VUL能力，组织可发现已授权或待授权软件[3]中的漏洞。发现了漏洞，组织才能有效地管理和保护自己。VUL能力还提供了软件管理责任视图，方便相关管理人确定已识别缺陷的优先级，做出风险响应决策（例如缓解或接受）。
VUL能力可识别网络上存在的软件（实际状态），并将其与期望状态的软件清单进行比较，以确定是否存在漏洞较少（通常较新）的软件版本可供部署，或者是否需要使用打补丁以外的缓解策略。[4]VUL能力的重点是尽可能确保目标网络上运行的所有软件不受已知漏洞的影响，并应用有效的修补和响应策略[5]。
注意，NISTIR 8011第3卷定义的软件包含固件。本卷使用相同的定义。
这里的软件（代码）指各种资产，包括有时可能并未当作软件的资产。具体软件资产包括：
2.1.1 操作系统软件数据库（如Windows注册表、Linux软件包管理器）中列出的已安装软件文件和产品；
2.1.2 硬盘上存在但未列示在操作系统数据库中的软件文件和产品；
2.1.3 移动代码；
2.1.4 可以修改的固件（通常包括BIOS）；
2.1.5 内存中的代码（可以就地修改）。
2.2 VUL攻击场景和期望结果
NISTIR 8011使用攻击步骤模型总结了网络攻击的六大步骤，这里的“网络攻击”指NIST SP 800-53中的控制措施共同拦截或延缓的攻击。VUL安全能力仅限于在图1和表1所列的攻击步骤中拦截或延缓攻击。
需求层级之间的可追溯性。表1显示了软件漏洞管理对示例攻击步骤的影响，但通常更有用的是观察其他需求集之间的可追溯性。为了检视这种可追溯性，可以使用表2来显示不同需求类型之间的可追溯性，方法是在对应的行和列中查找单元格，然后单击链接。例如，点击“示例攻击步骤”一列中表6的链接，可以发现该攻击步骤和子能力/缺陷检测ID、名称和目的之间的关系。
控制措施和攻击步骤之间的完整可追溯性要求在路径中加上以下链接：
1. 控制到控制项（在控制项名称中提供）
2. 控制项到判断语句（见3.3节）
3. 判断语句到缺陷检测（即子能力；见3.3节）
4. 缺陷检测（即子能力）到能力（在子能力名称中提供）
5. 缺陷检测（以及能力）到攻击步骤（见表6）
6. 能力到攻击步骤（见图1（对表6的总结））
表2. 需求层级之间的可追溯性
图2. 漏洞信息披露中的组织角色[SEI]
角色有时是组织，有时是个人。
· 最常见的个人角色包括：发现者、上报者和部署者（例如家庭用户、组织用户、系统管理员）。
· 最常见的组织角色包括：厂商和协调者，若软件为政府或商业组织所使用，还有部署者（例如软件漏洞管理人、补丁管理人）。
“厂商”这一角色需要进一步解释。这类实体指当前维护有漏洞软件的一方。正如卡内基梅隆CERT报告所述，“厂商是负责更新有漏洞产品的一方。”因此，在漏洞管理方面，厂商并非部署者（个人用户或组织）所购买软件的第三方厂商。
请注意，对于定制或内部软件代码，“负责更新产品的一方”可能是部署者组织内部的员工或团队，也可能是部署者组织合作的服务提供商。
图2中所示的协调者角色通常独立于评估组织，不属于NISTIR 8011范围，在此不予赘述。通常，协调者角色由SEI、漏洞扫描器厂商和源文档中列出的其他团队执行。
对于维护和授权的软件，NISTIR 8011定义的CWE和CVE缓解角色包括软件漏洞管理人（SWFM）（与CERT定义的厂商角色对应）和补丁管理人（PatMan）（与CERT定义的部署者角色对应）。[12]图3列举了NISTIR 8011为缓解CWE和CVE而定义的角色及其职责。请注意，对于未授权软件，不会为CVE开发补丁，除了隔离或删除之外，可能没有其他的缓解办法。
图3. CVE和CWE缓解角色
SWFM和PatMan角色的职责不一定是只完成图3中的任务，相反，这些任务可能是某个角色多项职责中的一部分。
2.3.3.1 软件漏洞管理人（SWFM）
SWFM是厂商组织角色。因此，软件漏洞管理可能是第三方厂商组织的责任，软件所有组织对此几乎没有控制权（例如，对于大多数COTS软件），也可能是软件所有组织本身的责任（例如，对于内部开发的定制软件）。
当发现并确认厂商组织维护的软件存在新漏洞时，将漏洞上报给CVE项目，以便将其列为CVE（或决定不上报漏洞或何时上报漏洞[15]）。厂商组织（维护软件源代码的组织）内部的软件漏洞管理人（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负责在过渡期内应用临时规避方案。
补丁通常通过软件包管理系统应用，该系统自动执行软件文件的安装、升级、配置和删除。[16]此外，也可以手动打补丁。
有些软件产品的补丁必须按顺序应用，在这种情况下，应指定补丁级别。有些产品允许按不同顺序选择性应用补丁。在这种情况下，“补丁集”一词比“补丁级别”更准确。[17]“补丁集”本质上比“补丁级别”复杂，因为补丁应用顺序有多种组合方式。本文档中，“补丁级别”一词根据实际情况可指补丁级别，也可以指补丁集。
共享代码带来的修补复杂性。有些可执行文件由多个软件产品共享。动态链接库（DLL）可执行文件就是共享软件的典型例子。就修补DLL而言，一个产品可能为其他产品带来保护，也可能将其他产品暴露于风险中，具体是保护还是暴露取决于DLL最新补丁中有哪些漏洞以及依赖软件如何使用该库。例如，在OpenSSL加密库中存在“心脏出血”（Heartbleed）漏洞，但该漏洞只影响OpenSSL提供的传输层安全性（TLS）实现，OpenSSL加密算法应用程序编程接口（API）不受该漏洞影响。也就是说，OpenSSL的TLS实现暴露了“心脏出血”漏洞，但加密函数实现却没有。因此，部分软件产品的共享性增大了软件漏洞管理的难度。
补丁之上摞补丁。遗憾的是，补丁本身也可能包含漏洞，后续才会发现。即使补丁当前没有已知漏洞，也有可能、甚至很可能在今后发现新的或其他的不规范编码实践，成为NVD中的新CVE条目或导致新的零日攻击。
[1] NISTIR 8011第1卷（2017年6月）将VUL能力作为NISTIR 8011的第5卷。但是，后来发现，NISTIR 8011各功能卷的发布顺序需要优化，因此将VUL能力调整到第4卷。NISTIR 8011各能力卷的发布顺序将在第1卷的勘误版本中进行修订。
[2] 条理清晰是指已知哪些软件代码文件（通过其数字指纹识别）存在漏洞，并使用软件白名单来确定是否存在有漏洞的文件。
[3] 特定的软件产品得到授权后，作为组件在联网或未联网的系统上运行。而考虑到效率和有效性，系统和系统组件需要网络连接进行自动化评估。独立的系统/系统组件不适合自动评估。有关授权范围（系统）与自动评估范围（网络）的信息，参见NISTIR 8011第1卷。
[4] 关于实际和期望状态的描述，见2.5.1和2.5.2节。
[5] 修补和响应策略可纳入组织的漏洞管理策略。
[6] 硬件漏洞通常通过软件来防护，例如为固件或操作系统打补丁，控制硬件访问或关闭硬件功能。在NISTIR 8011中，软件漏洞包括通过软件缓解的硬件漏洞。若硬件漏洞无法通过软件防护，需要对硬件进行物理修改或更换，这种漏洞不在NISTIR 8011第4卷讨论之列。
[7] 本文发布时，CVE项目正处于过渡期，CVE项目的管理组织和相关网站可能会发生变化。
[8] 有关厂商组织的定义，参见2.3.3节。
[9] 请注意，虽然恶意软件因为未授权而无法在白名单环境中运行，攻击者仍然可以通过白名单软件本身的未缓解漏洞进入环境。因此，即使在白名单软件环境中，软件漏洞管理也是高优先级事项。
[10] MITRE网站[CVE]上列出的CVE描述不够完整，所以链接到NVD以提供更多信息。本文发布时，CVE项目正处于过渡期，CVE项目的管理组织和相关网站可能会发生变化。
[11] 有些厂商组织选择不向CVE项目报告漏洞，而是通过本公司专有流程维护漏洞信息并提供补丁。
[12] 有关支持VUL能力的各个角色，参见2.7节。
[13] 注意，SWFM角色通常是软件开发/维护人员或软件开发/维护管理人的子角色，而不是完全独立的角色。这里指定SWFM角色有助于缓解软件漏洞，构成VUL能力的一部分。
[14] 在他人开发的软件中查找CWE主要适用于如下情况：部署组织有内部SWFM并使用动态代码扫描器来检测他人开发的COTS或GOTS产品中的不规范编码实践（CWE）。
[15] 例如，直到开发出补丁后再上报漏洞，防止在此期间被攻击。
[16] Microsoft Windows Store、Linux Red Hat RPM package Manager、Apple Mac App Store、Debian DPKG和Perl综合典藏网（Comprehensive Perl Archive Network）都是软件包管理系统。
[17] 如果指定了补丁集，则补丁的应用顺序仍会影响结果（例如，当两个或多个补丁更改同一个文件时）。
