三、VUL安全评估计划文档模板
3.1 计划调整介绍和步骤
本节提供了符合NIST SP 800-37和NIST SP 800-53A的安全评估计划模板。有关文档元素的描述，请参见本NISTIR第1卷第6节。第1卷的第9节专门介绍如何将模板和文档与NIST SP 800-37和NIST SP 800-53A中定义的评估任务和工作产品关联。
要对安全评估计划进行调整使其满足组织的需求并实现自动化监控，可采取图6所示步骤。下文对这些步骤做了详细描述。
3.1.1 选择自动执行的缺陷检查
本节介绍了选择自动执行的缺陷检查的子步骤。
采取图7所示的子步骤选择要自动执行的缺陷检查：
子步骤1.1明确评估范围：明确要覆盖的评估范围（参见本NISTIR第1卷的4.3节）。
子步骤1.2分析系统影响：针对子步骤1.1[FIPS199]中明确的评估范围，识别联邦信息处理标准（FIPS）199所定义的影响级别（高级别）（请参见[SP 800-60-v1]和/或组织的分类记录）。
子步骤1.3 评审安全评估计划文档：
- 评审3.2节介绍的缺陷检查，初步了解要测试的拟议项目。
- 评审3.2节中的安全评估计划说明，了解如何将缺陷检查应用于支持漏洞管理的控制措施。
子步骤1.4选择缺陷检查：
- 根据子步骤1.1、1.2和1.3以及对组织的风险承受能力的理解，请使用3.2.3节的表6确定必要的缺陷检查，从而评估根据系统影响级别和组织风险承受能力实施的控制措施是否有效。
- 标记3.2.2节中选择的必要缺陷检查。组织无需采取自动化，但是控制措施评估自动化可协助实现以下两点：
- 及时生成评估结果，从而更好地防御攻击和/或
- 长期看，可以降低评估成本。
3.1.2 根据组织实际情况调整角色
本节介绍根据组织实际情况调整角色的子步骤。
采取图8所示的子步骤根据组织实际情况调整角色：
子步骤2.1审核提议的角色：有关提议的角色，请参见2.7节“VUL角色和职责（说明）”。
子步骤2.2 弥补缺失的角色：确定组织中当前未分配的所有必需角色。明确如何分配未分配的角色。
子步骤2.3 重命名角色：确定每个角色匹配的组织特定角色名称。注意，同一组织角色可能会履行多个提议的角色。
子步骤2.4 调整文档：采取以下两种方法之一将组织特定角色映射到此处提议的角色（两种方法都可接受）：
- 在2.7节的表中添加一列，列出组织特有的角色名称。
- 使用全局替换将整个文档中的角色名称从本NISTIR中建议的名称修改为组织特定名称。
3.1.3 自动执行选择的缺陷检查
本节介绍自动执行选择的缺陷检查的子步骤。
采取图9所示的子步骤选择要自动执行的缺陷检查：
子步骤3.1选择缺陷检查：查看缺陷检查定义，根据组织的风险承受能力和预期的攻击类型酌情添加检查。【角色：DSM（参见2.7节。）】
子步骤3.2调整数据采集：
- 查看所需的实际状态信息，配置自动化传感器收集所需信息。【角色：ISCM-Sys（参见2.7节。）】
- 查看所匹配的明确规定的期望状态规范，或添加其他规范匹配要检查的新增实际状态。配置采集系统接收和存储期望状态规范，可自动与实际状态数据进行比较。【角色：ISCM-Sys（参见2.7节。）】
子步骤3.3 运行ISCM系统：
- 运行采集系统，识别安全和数据质量缺陷。
- 配置采集系统将安全和数据质量信息发送至缺陷管理仪表盘。
子步骤3.4 基于结果进行风险管理：首先基于结果对发现的较高风险进行响应，评估潜在剩余风险，为总体风险承受决策提供支持。如果确定风险太大而无法承受，可基于结果对进一步缓解措施进行优先级排序。
3.2 VUL子能力和缺陷检查表格和模板
本节介绍提议的特定测试模板，我们认为这些模板足以用于评估支持VUL能力的控制项。关于缺陷检查的概要说明，请参见本NISTIR第1卷第5节。关于各缺陷检查的评估标准说明中涉及的实际状态和期望状态规范的概要说明，请参见本NISTIR第1卷4.1节。本文的3.2.1、3.2.2和3.2.3节分别介绍基础检查、数据质量检查和本地缺陷检查。3.2.1节、3.2.2节和3.2.3节中的“支持的控制项”数据明确了哪些控制措施在无效情况下可能导致特定缺陷检查失败。控制项和缺陷检查之间的关联进一步提供了检查（测试）原因的说明。关于如何调整检查（及其中的角色）满足组织的需求，参见3.1节。
本节中发现的数据可用于缺陷检查选择和根因分析。3.2.4节介绍各子能力（通过缺陷检查进行测试）如何通过提供某些示例攻击步骤和/或解决数据质量问题对整体能力提供支持。
附录G也可为根因分析提供支持。缺陷检查模板的内容如下：
- 以“该子能力目的……”开头的部分定义通过缺陷检查测试的子能力，并介绍评估标准。3.2.4节介绍子能力如何拦截或延缓执行某些示例攻击步骤。
- 以“该缺陷检查用以评估……”开头的部分介绍缺陷检查名称以及为实现子能力目的而采取的子能力有效性评估标准。
- 在以“响应示例……”开始的部分，举例说明了检出缺陷时可能作出的响应以及责任角色。可能的响应行动（含有主要职责分配示例）是常见操作，适用于特定子能力中发现缺陷时的情况。主要职责分配示例不影响其他NIST指南中定义的总体管理责任。此外，每个组织都可以自定义响应动作和职责，在最大程度上满足自身需求。
- 最后，在以“支持性控制项……”开始的部分，列明为支持子能力而互相配合的控制项。支持性控制项的识别基于3.3节中缺陷检查到控制项的映射。每个子能力都由一组控制项支持。因此，若列明的任何支持性控制措施都失败，则缺陷检查失败，总体风险可能上升。
如3.1节所述，该资料由组织进行定制和调整，最终纳入安全评估计划。
3.2.1 基础子能力和相关缺陷检查
NISTIR 8011第4卷针对VUL能力提出了一种面向安全的基础缺陷检查。基础检查为VUL-F01。
可针对单项检查（如基础检查、数据质量检查或本地检查）评估缺陷检查，或对整个评估范围之外的各设备分组（如设备管理人，设备负责人和系统）汇总缺陷检查。选择基础缺陷检查旨在将其纳入总结报告。“是否选择”列表示是否执行检查。
3.2.1.1 “减少软件漏洞子”能力和缺陷检查VUL-F01
该子能力目的如下：
| 子能力名称 | 子能力目的 |
| 减少软件漏洞 | 减少参考缺陷列表（如美国国家漏洞库【NVD】）列出的软件漏洞数量（CVE） |
该缺陷检查用以评估该子能力是否有效运行，其定义见下表。
| 缺陷检查ID | 缺陷检查名称 | 评估标准说明 |
| VUL-F01 | 存在漏洞的软件 | 1) 实际状态为包含设备中所有软件产品、版本、发布版本和补丁级别的列表。 2) 期望状态规范旨在将CVE漏洞风险降至最低（即可接受）或同等风险级别。 3) 缺陷是指存在参考缺陷列表（即国家漏洞数据库[NVD]或组织接受的其他漏洞数据集）中列出的不可接受的软件漏洞（CVE或同等漏洞）。 |
响应示例：
| 缺陷检查ID | 可能的响应行动 | 主要责任人 |
| VUL-F01 | 安装软件补丁 | PatMan |
| VUL-F01 | 卸载软件 | SWMan |
| VUL-F01 | 评估为误报 | RskEx |
| VUL-F01 | 减少误报 | ISCM-Ops |
| VUL-F01 | 采取临时缓解措施 | PatMan |
| VUL-F01 | 接受风险 | RskEx |
| VUL-F01 | 响应监测和协调 | DSM |
支持性控制项：
| 缺陷检查ID | 基线 | NIST SP 800-53 控制项代号 |
| VUL-F01 | 低 | RA-5(a) |
| VUL-F01 | 低 | RA-5(b) |
| VUL-F01 | 低 | RA-5(c) |
| VUL-F01 | 低 | RA-5(d) |
| VUL-F01 | 低 | RA-5(e) |
| VUL-F01 | 低 | SI-2(a) |
| VUL-F01 | 低 | SI-2(c) |
| VUL-F01 | 低 | SI-2(d) |
| VUL-F01 | 中 | SA-11(d) |
| VUL-F01 | 高 | SI-2(1) |
3.2.2 数据质量子能力和相关缺陷检查
NISTIR 8011第4卷提出了四种数据质量缺陷检查，以VUL-Q01至VUL-Q04命名。数据质量缺陷检查非常重要，因为它们提供了确定整体评估自动化过程可靠性的必要信息，该信息可用于确定其他缺陷检查数据的可信度（即更好地保证安全控制的有效性）。数据质量缺陷检查与特定控制项无关，根据在总结报告中的重要性进行选择。“是否选择”列显示组织执行了哪些检查。关于数据质量检查的更完整信息，参见NISTIR 8011第1卷“概述”的5.5节“数据质量措施”。
3.2.2.1 确保设备级报告完整性”子能力和缺陷检查VUL-Q01
该子能力目的如下：
| 子能力名称 | 子能力目的 |
| 确保设备级报告的完整性 | 确保向实际状态清单上报VUL信息的设备上报这些信息，确保检出存在的所有CVE和CWE。 |
该缺陷检查用以评估该子能力是否有效运行，其定义见下表。
| 缺陷检查ID | 缺陷检查名称 | 评估标准说明 | 是否选择 |
| VUL-Q01 | 非上报设备 | 1) 实际状态指上报软件漏洞（CVE或同等漏洞及CWE）的HWAM-F01中的期望状态设备列表。 2) 期望状态指HWAM-F01中检测到的实际设备列表，包括已授权和非授权设备。 3)在实际状态所确定的预期最近时间未检测到期望状态设备时，则认为存在缺陷。制定标准，根据HWAM-Q01中列出的同样考虑因素对每个设备或设备类型定义“预期最近时间”阈值。 | 是 |
响应示例：
| 缺陷检查ID | 可能的响应行动 | 主要责任人 |
| VUL-Q01 | 恢复设备上报 | ISCM-Ops |
| VUL-Q01 | 宣布设备丢失 | DM |
| VUL-Q01 | 接受风险 | RskEx |
| VUL-Q01 | 监控、协调响应活动 | RskEx |
支持性控制项：
| 缺陷检查ID | 基线 | NIST SP 800-53 控制项代号 |
| VUL-Q01 | 低 | RA-5(a) |
| VUL-Q01 | 低 | RA-5(c) |
| VUL-Q01 | 低 | SI-2(a) |
| VUL-Q01 | 低 | SI-2(b) |
| VUL-Q01 | 高 | SI-2(1) |
3.2.2.2 确保缺陷检查级报告完整性”子能力和缺陷检查VUL-Q02
该子能力目的如下：
| 子能力名称 | 子能力目的 |
| 确保缺陷检查级报告的完整性 | 确保缺陷检查信息正确上报至实际状态清单，避免出现系统无法检测到任何设备缺陷的情况。 |
该缺陷检查用以评估该子能力是否有效运行，其定义见下表。
| 缺陷检查ID | 缺陷检查名称 | 评估标准说明 | 是否选择 |
| VUL-Q02 未上报的适用缺陷检查 | 未上报的适用缺陷检查 | 1) 实际状态指各采集周期内对每个设备测试和采集的一系列漏洞。 2) 期望状态指被定义为适用于该设备且应已测试和采集的一系列漏洞。 3) 缺陷指期望状态中的设备上在实际状态中未采集和测试的任何漏洞。缺陷有两种类型： a. 采集系统未在任何适用设备上测试和采集缺陷数据； b. 采集系统仅测试和采集一些适用设备上的缺陷数据。 根因说明： • 3a通常为采集系统的系统错误。 • 3b可能与设备和采集系统的交互相关；设备或采集系统可能是根本原因。 | 是 |
响应示例：
| 缺陷检查ID | 可能的响应行动 | 主要责任人 |
| VUL-Q02 | 恢复缺陷检查上报 | ISCM-Ops |
| VUL-Q02 | 接受风险 | RskEx |
| VUL-Q02 | 监控、协调响应活动 | RskEx |
支持性控制项：
| 缺陷检查ID | 基线 | NIST SP 800-53 控制项代号 |
| VUL-Q02 | 低 | RA-5(a) |
| VUL-Q02 | 低 | RA-5(b) |
| VUL-Q02 | 低 | RA-5(c) |
| VUL-Q02 | 低 | SI-2(a) |
| VUL-Q02 | 低 | SI-2(b) |
| VUL-Q02 | 中 | RA-5(1) |
| VUL-Q02 | 中 | RA-5(2) |
| VUL-Q02 | 高 | SI-2(1) |
3.2.2.3 确保整体缺陷检查上报完整”子能力和缺陷检查VUL-Q03
该子能力目的如下：
| 子能力名称 | 子能力目的 |
| 确保整体缺陷检查上报完整 | 尽可能向实际状态清单上报正确且全面的缺陷检查数据，确保缺陷被及时发现。 |
该缺陷检查用以评估该子能力是否有效运行，其定义见下表。
| 缺陷检查ID | 缺陷检查名称 | 评估标准说明 | 是否选择 |
| VUL-Q03 | 完整性低指标 | 完整性指标不是设备级缺陷，但适用于任何设备集合，如授权范围内的设备。完整性指标用于评估收集系统的可信性。 1) 实际状态指收集系统在报告窗口期中提供的指定缺陷检查的数量。 说明：特定的检查设备组合只能在要求的最小报告期内计算一次。例如，如果每三天检查一次，若在该时间段内进行两次检查则计为一次。但若上报时间窗口期为30天，则检查设备组合按每三天一周期计算，需计算10个周期的检查次数。 2) 期望状态为同一报告窗口期内应提供的特定缺陷检查的数量。 说明：不同设备可能对应不同的特定检查集，这主要取决于设备功能/类型。此示例中，在30天的报告窗口期内（上报周期为3天），期望状态包括10个周期内的特定缺陷检查组合的次数。 3) “完整性”指标定义为实际状态数量除以期望状态数量。完整性是在报告窗口期内采集的特定缺陷检查的百分比。完整性衡量长期收集所有必要数据的能力。 完整性太低（与定义的阈值相比）即为缺陷。完整性较低时，未发现的缺陷的风险随之增加。可接受的完整性级别指在技术可行性与100％完整性需求之间达到平衡。 | 是 |
响应示例：
| 缺陷检查ID | 可能的响应行动 | 主要责任人 |
| VUL-Q03 | 恢复完整性 | ISCM-Ops |
| VUL-Q03 | 接受风险 | RskEx |
| VUL-Q03 | 监控、协调响应活动 | RskEx |
支持性控制项：
| 缺陷检查ID | 基线 | NIST SP 800-53 控制项代号 |
| VUL-Q03 | 低 | RA-5(a) |
| VUL-Q03 | 低 | RA-5(c) |
| VUL-Q03 | 低 | SI-2(a) |
| VUL-Q03 | 低 | SI-2(b) |
| VUL-Q03 | 中 | SI-2(2) |
| VUL-Q03 | 高 | SI-2(1) |
3.2.2.4 确保总体报告及时性”子能力和缺陷检查VUL-Q04
该子能力目的如下：
| 子能力名称 | 子能力目的 |
| 确保总体报告及时性 | 确保实际状态下及时报告尽可能多的缺陷检查数据以降低缺陷检测延迟。 为了有效起见，必须在缺陷被利用前尽快发现和缓解缺陷。 |
该缺陷检查用以评估该子能力是否有效运行，其定义见下表。
| 缺陷检查ID | 缺陷检查名称 | 评估标准说明 | 是否选择 |
| VUL-Q04 | 及时性较差指标 | 及时性指标不是设备级缺陷，但适用于任何设备集合，如授权范围内的设备。该指标用于评估收集系统的准确性。 1)实际状态指收集系统在收集周期内（每个缺陷应检查一次）提供的特定缺陷检查次数。 说明：特定检查设备组合在收集周期内只统计一次。 2)期望状态指收集系统在收集周期内应提供的特定缺陷检查的数量。 说明：不同设备可能对应不同的特定检查集，这主要取决于设备功能/类型。 3) “及时性”指标定义为实际状态数量除以期望状态数量。及时性是在报告周期中实际收集的特定缺陷检查的百分比。及时性衡量的是按时间要求所收集数据的比例。 4)及时性太差（与定义的阈值相比较）则为缺陷。若及时性差，未发现缺陷的风险会增加。及时性较差时，未发现的缺陷的风险随之增加。 | 是 |
响应示例：
| 缺陷检查ID | 可能的响应行动 | 主要责任人 |
| VUL-Q04 | 恢复频率 | ISCM-Ops |
| VUL-Q04 | 接受风险 | RskEx |
| VUL-Q04 | 监控、协调响应活动 | RskEx |
支持性控制项：
| 缺陷检查ID | 基线 | NIST SP 800-53 控制项代号 |
| VUL-Q04 | 低 | RA-5(a) |
| VUL-Q04 | 低 | RA-5(b) |
| VUL-Q04 | 低 | RA-5(c) |
| VUL-Q04 | 低 | SI-2(a) |
| VUL-Q04 | 低 | SI-2(b) |
| VUL-Q04 | 低 | SI-2(c) |
| VUL-Q04 | 中 | SI-2(2) |
| VUL-Q04 | 高 | SI-2(1) |
3.2.3 本地子能力和相关缺陷检查
本节以本地缺陷检查VUL-L01为例介绍组织可在基础检查中添加的内容，为具备VUL的NIST SP 800-53控制措施进行更全面自动化评估提供支持。
组织可自行决定实施哪些缺陷检查进行风险管理。通常，选择更多缺陷检查可能会降低风险（如果有能力解决发现的缺陷）并提供更可靠的保障，但也可能会增加检测和缓解成本。组织可对缺陷检查进行取舍，以平衡收益和成本，首先关注会产生最大风险的问题（即管理风险），确定风险响应措施的优先级。
注意：根据组织的风险承受能力和系统的影响级别，可在缺陷检查中增加选项，让检查更为严格或宽松。
“是否选择”列显示组织根据文档记录或依据修改而选择执行的本地缺陷检查。
3.2.3.1 减少不规范编码实践”子能力和缺陷检查VUL-L01
该子能力目的如下：
| 子能力名称 | 子能力目的 |
| 减少不规范编码实践 | 减少不规范软件编码实践（CWE）。关于不规范编码实践，参见https://cwe.mitre.org。 |
该缺陷检查用以评估该子能力是否有效运行，其定义见下表。
| 缺陷检查ID | 缺陷检查名称 | 评估标准说明 | 是否选择 |
| VUL-L01 | 不规范编码实践 | 不规范编码实践的评估适用于组织的存在不规范编码实践的任何软件。组织负责查找这些软件并开发补丁纠正这些软件中的不规范问题。该评估也适用于COTS和/或GOTS软件，验证从软件提供商获得的成品。 1)实际状态指CWE代码分析对象（设备）中的软件产品及相关版本和补丁级别列表（清单）。 说明：软件文件列表来源于SWAM能力。硬件设备列表来源于HWAM能力。 2)期望状态规范指设备上的软件文件中的CWE实例具备最低（即可接受的）风险。 3)缺陷是指处于实际状态的设备上存在不可接受的编码实践（CWE）。 说明：由于代码分析器可能会产生相当数量的误报，所以利用独立的风险评估功能（例如，独立的验证和确认团队、评估团队、系统安全员和组织风险主管）识别误报并从不规范编码实践实例列表中删除误报非常重要。 | 待定 |
响应示例：
| 缺陷检查ID | 可能的响应行动 | 主要责任人 |
| VUL-L01 | 评估为误报 | RskEx |
| VUL-L01 | 卸载软件 | PatMan |
| VUL-L01 | 获取补丁 | SWFM |
| VUL-L01 | 安装软件补丁 | PatMan |
| VUL-L01 | 采取临时缓解措施 | PatMan |
| VUL-L01 | 接受风险 | RskEx |
| VUL-L01 | 监控、协调响应活动 | DSM |
支持性控制项：
| 缺陷检查ID | 基线 | NIST SP 800-53 控制项代号 |
| VUL-L01 | 低 | RA-5(a) |
| VUL-L01 | 低 | RA-5(c) |
| VUL-L01 | 低 | RA-5(d) |
| VUL-L01 | 低 | RA-5(e) |
| VUL-L01 | 低 | SI-2(a) |
| VUL-L01 | 低 | SI-2(c) |
| VUL-L01 | 低 | SI-2(d) |
| VUL-L01 | 中 | SA-11(d) |
| VUL-L01 | 高 | SI-2(1) |
3.2.4 各子能力对攻击步骤模型的安全影响
表6列明NIST SP 800-53安全控制措施派生的缺陷检查协助阻止攻击/事件的主要方式，如图1所示。说明：表6中的一些单元格内容可能包含其他单元格的重复信息。这一方面是设计原因，另一方面是由于NISTIR 8011是自动化完成编写。
译者声明：
小蜜蜂翻译组公益译文项目，旨在分享国外先进网络安全理念、规划、框架、技术标准与实践，将网络安全战略性文档翻译为中文，为网络安全从业人员提供参考，促进国内安全组织在相关方面的思考和交流。