各卷围绕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. VUL对攻击步骤模型的影响图1说明图1所示的攻击步骤仅限于对抗性攻击。
（见NISTIR 8011第1卷3.2节）如果在步骤2中成功发起攻击，那么，正常的攻击进程中，攻击者在步骤3会立即（通过软件）在受影响的设备上建立据点。
步骤5（传播、扩大控制）中，入侵某台设备后，返回到步骤2，再攻击其他设备。
表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.3 VUL管理和评估的评估对象VUL能力管理和评估的对象包括软件漏洞和通过软件缓解的硬件漏洞。
[6]VUL能力直接管理、评估的软件漏洞有两种：（1）在设备上使用的软件文件的特定版本和补丁级别中发现、分析并确定存在的CVE[CVE]；（2）在设备上使用的软件产品和文件的软件代码中暴露出的不规范编程实践，即CWE[CWE]。
当设备上运行的软件中包含的CVE和CWE引起的风险若在组织可容忍的范围内，即认为设备受到保护。
系统上的软件漏洞数量随着时间的推移而有增有减。
发现了新漏洞，则数量增加；漏洞被修复，则数量减少。
需要定期重复评估，以保持信息的时效性。
VUL能力重在防护已知漏洞，因为针对这些漏洞，潜在攻击者能够以很低的成本轻松获取攻击知识和工具。
大多数已知漏洞有修补程序（否则，该漏洞被视为零日漏洞，因为该漏洞虽被披露，却没有可用的缓解措施；见2.3.1节）。
遗憾的是，已知漏洞并不总能及时修补，也就是说，在任何时候，某些系统和系统组件都可能存在未修补的、可利用的软件漏洞。
合理的漏洞管理程序，即使是只关注已知漏洞，也有助于抵御有钱、有干劲、有能力的攻击者。
老练的攻击者会花费大量资源来发现、武器化和隐藏未知漏洞。
他们在部署武器化的未知漏洞方面非常谨慎，因为这种行为有暴露漏洞的风险（即从未知变为已知），一旦暴露，可能会被防御方缓解和修复。
因此，有钱、有干劲、有能力的攻击者通常更倾向于利用已知漏洞进行攻击，因为已知漏洞的攻击成本低，利用这些漏洞就不需要浪费宝贵的未知漏洞资源来实现攻击目标。
因此，若软件针对已知漏洞做了保护，即使是老练的攻击者也会增加攻击成本。
VUL能力还可能会处理未知漏洞，例如，扫描不规范的编码实践（如CWE）。
扫描CWE可以让未知漏洞变成已知，进而处理这些漏洞。
因此，虽然VUL能力主要关注的是已知漏洞（如CVE），但也会通过关注软件缺陷的常见来源（如CWE）来解决与未知漏洞相关的风险。
2.3.1 CVECVE项目[CVE]提供了漏洞列表，每条漏洞都包含唯一的标识号、描述以及至少一个公开参考链接。
[7]这些漏洞均为特定软件中发现、公开披露且上报给https://cve.mitre.org的网络安全漏洞。
CVE因为具有如下重要特征，因而适用于自动评估：· CVE是描述软件中包含的公开披露的网络安全漏洞的标准方法；· CVE列表是一个字典，每个漏洞或暴露就是一个条目；· 每个CVE具有唯一标识符，可在业界各软件系统间通用；· 同一CVE在不同的产品、工具和服务间具有相同含义。
漏洞一旦被公开且被分配CVE ID，维护软件的厂商组织[8]就会着手开发补丁来修复该漏洞。
对编码缺陷进行修复（打补丁等方法）的目的是在攻击者发现并利用它们之前发现并缓解问题。
对于防御者来说，挑战在于在管理不断增加的代码复杂性的同时，还要领先于攻击者一步。
从（某人）发现漏洞到软件控制组织知道漏洞并提供补丁期间，该漏洞被称为零日漏洞。
在这段时间内，软件一直暴露在风险之下，直到发布并应用补丁。
在暴露期间，防御攻击的选项仅限于白名单、[9]应用常见的安全配置、隔离或删除。
在评估风险时，应明白上报的软件漏洞数量不一定与软件厂商和产品中的实际软件漏洞数量相一致。
攻击者希望经济高效地利用漏洞，这样，跨平台（如Acrobat和Java）实现的软件或在主流平台（如微软或思科）上实现的软件最具吸引力，因为所需要的时间最少。
所以，基于主流平台的软件代码报告的漏洞最多。
上报的漏洞数量多可能是由于漏洞研究和报告越来越集中于主流软件。
通常情况下，某一系列软件版本中公开披露的漏洞数量越多，说明软件提供商的成熟度越高。
软件平台提供商常拥有强大的漏洞披露、上报和管理程序，这些都说明软件提供商具有良好的风险管理实践。
反之，没有上报漏洞的产品不一定就没有漏洞。
国家漏洞数据库[NVD]以标准的机器可读格式向公众发布CVE信息。
就已知软件漏洞和漏洞信息分析而言，NVD是美国政府最全面的一种公开信息来源。
CVE项目还维护了一个CVE数据集，该数据集可能包含更多的漏洞[10]，但提供的漏洞相关信息较少。
在本文件中，术语NVD同时指nvd.nist.gov和cve.mitre.org。
有时，业界会发现尚未在NVD中分类的公开披露的漏洞，但此类来源通常是未公开的私有渠道。
漏洞一般通过以下方式识别：· NVD[NVD]中的每条CVE由CVE[CVE]编号机构[CNA]分配ID。
CNA可以是厂商、开源提供商或研究人员。
NVD从CVE获取数据。
· 知名的软件制造商拥有成熟强大的漏洞管理程序，它们会上报已验证漏洞。
· 第三方道德黑客上报漏洞。
有些可利用的代码漏洞未通过CVE项目公开，因此未作为CVE列入NVD。
[11]已知漏洞未公开披露的原因可能有多种，包括但不限于：· 只有犯罪分子和/或情报机构发现了漏洞，他们打算有朝一日利用该漏洞，因此不想披露。
· 漏洞可能只存在于定制软件和/或工业控制系统中。
由于用户数量有限且所涉及系统具有潜在敏感性，漏洞未在NVD中列出，可能的原因是披露这些漏洞或会增加攻击的风险，而不是保护受影响的系统。
· 漏洞存在于商用现成（COTS）软件中，但在补丁出现之前不会公布，因为披露该漏洞可能会增加攻击风险，而不是保护系统。
· 漏洞扫描提供商可能在分配CVE ID之前已发现漏洞。
由于厂商和攻击者在公开漏洞方面存在的差异，再加上攻击者发现漏洞后有意瞒报，软件产品的CVE数量不一定能反映产品的实际漏洞数量。
2.3.2 CWECWE是一种广为人知的分类法，针对的是生产软件过程中发现的不规范编码实践[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中所示的协调者角色通常独立于评估组织，不属于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] 如果指定了补丁集，则补丁的应用顺序仍会影响结果（例如，当两个或多个补丁更改同一个文件时）。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）