conducting-cyber-risk-assessment-with-nist-800-30

使用 NIST SP 800-30 开展网络风险评估

何时使用

• 当组织需要进行真正的风险评估——分析具体威胁、可能性与影响——而不是对照某个框架给出成熟度评分时。（成熟度告诉你实践有多成熟；风险评估告诉你什么可能伤害你，以及伤害有多严重。）
• 当另一个框架要求将书面风险分析作为强制输入时：NIST CSF（ID.RA）、ISO 27001（第 6.1.2 条）、NIST RMF / 800-37（Prepare 和 Select 步骤）、SOC 2（CC3）、PCI DSS 或 HIPAA（§164.308(a)(1)(ii)(A)）。
• 当要上线一个新系统或对系统进行重大变更，并且必须在授权或上线前了解其风险时。
• 当领导层要求给出组织最高风险的排序，并附上他们能向董事会或监管机构辩护的理由时。
• 当构建或更新企业风险登记册时。

前提条件

• 范围内资产、系统及其处理的信息类型的清单（已定义系统边界）。
• 可获取威胁情报（内部事件历史、行业 ISAC 情报源、MITRE ATT&CK），以便将威胁事件可能性建立在已观察到的行为之上。
• 范围内系统的脆弱性数据（扫描结果、渗透测试发现、配置/架构审查）。
• 业务背景：系统支持哪些任务/流程，以及机密性、完整性或可用性方面的影响用业务语言意味着什么。
• 在评分前就风险模型和量表达成一致，使结果可比较且可重复（见 references/standards.md）。
• 熟悉 NIST SP 800-39 中的三层风险管理背景（组织、任务/业务流程、信息系统）。

工作流

NIST SP 800-30 Rev 1 定义了四个步骤。步骤 1 和步骤 4 分别为评估划定起止边界；步骤 2 是分析核心。

1. 为评估做准备

定义并记录：

• 目的（例如，支持授权决策、为控制措施选择提供信息、满足 ISO 6.1.2）。
• 范围——组织层级（Tier 1/2/3）、系统和时间范围。
• 假设和约束（例如，假设存在具有中等能力的外部对抗性威胁）。
• 信息来源——威胁、脆弱性和影响输入。
• 风险模型和分析方法——各项因素（威胁源、威胁事件、脆弱性、可能性、影响）以及量表（定性 Very Low–Very High，或半定量 0–10）。现在就把这些锁定。

2. 开展评估

按顺序完成各项分析任务。800-30 附录提供了参考分类法（D–I）。

2a. 识别威胁来源（附录 D）。 按类型分类：对抗性（个人、团体、民族国家——刻画其能力、意图、目标选择）、偶然性（用户错误）、结构性（设备/软件故障）、环境性（自然灾害、基础设施中断）。

2b. 识别威胁事件（附录 E）。 来源可能采取的具体行动（例如，“对手通过网络钓鱼窃取凭据，然后横向移动”）。将对抗性事件映射到 MITRE ATT&CK 技术以实现可追溯性。

2c. 识别脆弱性和诱发条件（附录 F）。 弱点（缺少 MFA、未修补的服务）以及使利用更可能或更不可能发生的条件（互联网暴露、扁平网络、缺乏分段隔离）。

2d. 确定可能性（附录 G）。 评估威胁事件被发起（对抗性）或发生（非对抗性）的可能性，以及在给定脆弱性的情况下导致不利影响的可能性。在商定的量表上合并为总体可能性。

2e. 确定影响（附录 H）。 事件成功时造成的危害程度——对运营、资产、个人、其他组织或国家。按商定的量表并以业务术语表达。

2f. 确定风险（附录 I）。 风险是可能性和影响的函数。在风险矩阵上标出每个威胁事件（例如，可能性 × 影响 → 极低……极高）。记录风险级别、促成因素以及不确定性/假设。

3. 沟通并共享结果

生成风险登记册和执行简报。对于每项风险：威胁事件、受影响资产、可能性、影响、风险级别、关键促成的脆弱性以及建议的处置。按风险级别排序，使决策者首先看到最高风险。

4. 维护评估

风险不是静态的。定义更新频率以及强制重新评估的触发条件（新系统、重大架构变更、重大事件、新威胁情报）。随时间推移跟踪风险接受决策和处置进展。

5. 推动处置决策

将排好序的登记册交给风险责任人。为每项风险选择一种处置方式——缓解（增加/加强控制）、转移（保险、合同）、规避（停止该活动）或接受（记录残余风险并附授权签名）。在计划控制措施实施后重新评分残余风险，以展示处置后的状况。

关键概念

概念	定义
威胁来源	威胁事件的原因：对抗性、偶然性、结构性或环境性。
威胁事件	可能造成损害的具体行动或事件（对抗性情形映射到 ATT&CK）。
脆弱性	威胁事件可利用的弱点。
诱发条件	增加或降低不利影响可能性的条件（例如，互联网暴露）。
可能性	威胁事件发起/发生并且导致不利影响的几率。
影响	事件成功时造成的危害程度。
风险	可能性和影响的函数；组织预期遭受的危害。
固有风险 vs 残余风险	计划/已实施控制措施之前 vs 之后的风险。
风险容忍度 / 风险偏好	领导层愿意接受的风险水平。
风险登记册	风险、评分、责任人和处置方式的优先级记录。

工具与系统

• NIST SP 800-30 Rev 1 — 方法论及附录 D–I 分类体系（威胁源、威胁事件、脆弱性、可能性、影响、风险）。
• NIST SP 800-39 — 企业风险管理背景（三个层级）。
• MITRE ATT&CK — 用于枚举并将对抗性威胁事件锚定于已观测的 TTP。
• 漏洞扫描器 / 渗透测试报告 — 实证性脆弱性输入。
• 威胁情报来源 — 行业 ISAC、供应商情报源、内部事件历史，用于支撑可能性评估。
• GRC / 风险登记工具 — 电子表格，或 ServiceNow GRC、Archer、OneTrust 等平台，用于存储和跟踪风险登记册。
• FAIR（可选）— 当领导层希望以美元区间而非定性等级表达风险时使用的定量模型。

常见场景

• CSF/ISO/SOC 2 需要风险分析。 运行 800-30 以产出这些框架所需的文档化评估作为输入，然后将结果映射到其控制集。
• 新系统上线前。 针对系统架构评估威胁事件，并将结果输入授权（RMF Select/Authorize）决策。
• 董事会需要了解首要风险。 交付一份排序后的风险登记册，以业务术语说明影响，并给出清晰的处理建议。
• 事件发生后。 重新评估受影响的系统；事件会更新可能性证据，并可能暴露新的威胁事件。
• 年度更新。 依据当前威胁情报和控制措施变化重新评分；展示残余风险的逐年变化。

输出格式

使用 assets/template.md 生成一份 风险评估报告，包含：

1. 目的、范围与层级 — 评估了什么以及为什么。
2. 假设、约束与风险模型 — 所使用的因素和量表（以便结果可复现）。
3. 威胁源 — 按类型划分，并附对抗性特征描述。
4. 威胁事件 — 每项包含受影响资产及对抗性场景下的 ATT&CK 映射。
5. 脆弱性与诱发条件 — 与威胁事件关联。
6. 风险登记册 — 表格：ID、威胁事件、资产、可能性、影响、风险等级、贡献脆弱性、建议处理措施、负责人、残余风险。
7. 首要风险摘要 — 按排序呈现，以业务术语表述，供领导层参考。
8. 维护计划 — 更新频率与重新评估触发条件。

使用 scripts/process.py 从风险输入 JSON 为登记册评分（可能性 × 影响 → 在可配置矩阵上的风险等级），对风险排序，并输出登记册表格。