csf-mapping

CSF Mapping — NIST Cybersecurity Framework 2.0 姿态评估

将你的安全态势转换为所有 CISO、董事会、审计师和保险公司都熟悉的语言。与审计技能（用于发现具体问题）不同，此技能根据公认框架评估你的计划，并生成可用于治理的结果。

截至 2024 年，NIST CSF 2.0 已取代 CSF 1.1。它新增了第六项功能——Govern，以此承认，其他功能若没有治理支持便无法发挥作用。

六项功能：

功能	涵盖内容
Govern (GV)	网络安全战略、职责、政策、监督、供应链风险
Identify (ID)	资产清单、业务环境、风险评估、供应链
Protect (PR)	访问控制、安全意识、数据安全、基线配置、维护、防护技术
Detect (DE)	持续监控、异常检测、不利事件分析
Respond (RS)	事件管理、分析、缓解、报告、沟通
Recover (RC)	恢复规划、改进、沟通

每项功能都包含类别（例如，PR.AA — 身份管理、身份验证和访问控制），每个类别又包含子类别（例如，PR.AA-01 — 管理授权用户、服务和硬件的身份与凭证）。

此技能会将你的实际情况映射到这些子类别。

交叉参考：此仓库中的每项审计技能（它们会生成证据，作为此处的“当前状态”条目）、iam-audit（涵盖大部分 PR.AA）、siem-detection（涵盖大部分 DE）、incident-triage（涵盖大部分 RS）、threat-modeling（为 ID.RA 风险评估提供参考）、breach-patterns（为根据经验教训改进 ID.IM 提供参考）。

授权

根据用户提供或指定的证据，评估用户自己的组织，或聘请用户提供服务的客户。此技能会读取政策、配置和审计结果；不会探测系统。评估过程中应将证据保留在评估范围内，不要根据公开数据推断其他组织的安全态势。

方法

步骤 1 — 确定范围

CSF 评估有明确的范围边界。确定要评估以下哪一项：

• 整个组织 — 每个系统、每个业务部门
• 一项产品 / 服务 — 用于供应商尽职调查问卷（SIG、CAIQ）
• 一个环境 — 仅生产云环境，或仅 PCI 范围内的环境
• 监管范围 — 受 HIPAA 约束的系统、FedRAMP 边界等

记录范围内和范围外的内容。大多数 CSF 评估都会因范围漂移而失败。

步骤 2 — 选择 CSF 配置文件

CSF 2.0 引入了组织配置文件，不再是“为每个子类别赋予同等权重”，而是根据实际需求进行定制。

• 当前配置文件 — 你目前的实际情况
• 目标配置文件 — 你希望达到的状态（参考业务目标、监管要求和风险承受能力）
• 社区配置文件 — 为所在行业预先构建的配置文件（制造业、医疗保健、金融服务行业等，由 NIST 等机构发布）

首次评估时，如果所在行业有社区配置文件，请从该配置文件开始，然后再进行定制。

步骤 3 — 评估每个子类别

对于范围内的每个子类别：

字段	记录内容
ID	例如，PR.AA-05
子类别文本	逐字引用 NIST 原文或进行转述
当前状态	你今天实际在做什么（依据证据，而非愿景）
证据	能证明当前状态的文档 / 系统 / 流程
层级	部分 / 风险知情 / 可重复 / 自适应（1-4）
目标层级	你的目标
差距	差距大小
计划	弥补差距的措施
负责人	谁负责
时间线	时间安排

CSF 实施层级

层级	名称	特征
1	部分实施	临时应对、被动响应、缺少文档；认知仅停留在非正式层面
2	风险知情	风险管理已获批准，但未覆盖整个组织；部分团队的流程可重复执行
3	可重复	组织范围内有成文政策；流程一致；预算制定考虑风险
4	自适应	持续改进；量化风险；从事故（自身及同行的事故）中学习；形成网络安全文化

第 4 级很少见，成本也很高。大多数成熟的 SaaS 组织会以大多数子类别达到第 3 级为目标。应根据业务的实际需求设定目标，而不是追求表面好看。

步骤 4 — 识别差距并确定优先级

对于每项差距，请评估：

• 若遭到利用／未得到解决，其影响有多大（监管、声誉、财务）
• 根据当前威胁形势和具体暴露情况，其可能性有多大
• 修复成本（工程工时、工具、人力）
• 对其他差距先行解决的依赖关系

按风险 × 修复成本确定优先级，而不只看风险。有些高风险项目需要一年时间和三家供应商才能完成；有些快速见效的项目则能在一个迭代周期内降低实际风险。

步骤 5 — 制定路线图

CSF 路线图通常按季度推进，并设定年度目标。可采用以下结构：

• 未来 30 天 — 立即解决的差距（快速见效的项目、成本低但风险高的项目）
• 未来 90 天 — 中等工作量的项目，明确负责人并设定成功标准
• 未来 12 个月 — 需要批准预算、决定工具和增加人力的战略性差距
• 年度审查 — 全面重新评估；更新配置文件；提升实施层级

路线图中的每个项目都应注明：要解决的子类别、负责人、预算、成功指标和审查日期。

本仓库中的子类别与技能交叉参考

一个实用的捷径——以下列出可为哪些 CSF 子类别生成证据的审计技能。

CSF 子类别	审计技能	证据类型
GV.SC (供应链风险)	dependency-audit	CVE 清单、供应商列表、供应链风险登记册
ID.AM (资产管理)	cloud-audit、container-audit、recon	资产清单输出
ID.RA (风险评估)	threat-modeling、breach-patterns	威胁模型、违规模式覆盖文档
ID.IM (从过往事故中改进)	incident-triage 事后复盘、breach-patterns	事故后审查、已落实的经验教训
PR.AA (身份与访问控制)	iam-audit	IAM 审计报告、角色清单
PR.DS (数据安全)	crypto-audit、secrets-audit	加密安全状况、密钥管理安全状况
PR.PS (平台安全)	container-audit、cloud-audit	K8s 加固、云安全状况
PR.IR (基础设施韧性)	container-audit、cloud-audit	网络策略、分段、备份安全状况
DE.CM (持续监控)	siem-detection、soc-operations	SIEM 覆盖情况、ATT&CK Navigator 导出文件
DE.AE (异常与事件分析)	siem-detection、threat-hunting	检测规则清单、威胁搜寻发现
RS.MA (事件管理)	incident-triage、soc-operations	IR 计划、运行手册、近期事件报告
RS.AN (分析)	disk-forensics、incident-triage	取证分析输出
RS.MI (缓解)	finding-triage、incident-triage	分类决策、缓解措施跟踪
RC.RP (恢复计划)	（未直接覆盖 — 需单独开展 BCP/DR 工作）	BCP / DR 计划、经过测试的恢复方案

对于没有对应技能直接覆盖的子类别，差距通常在于“我们具备技术深度，但缺少项目级文档”。例如，RC.RP-01（在事件发生期间或之后执行恢复计划）需要一份真正成文且经过测试的 BCP/DR 计划——运行 incident-triage 并不会自动生成该计划。

大多数组织存在的高影响差距

我在 CSF 评估中反复看到的模式。并非普遍适用，但可作为起点：

• GV.OC-04（识别并传达关键目标、能力和服务） — 大多数组织无法让安全、IT 和工程团队一致说出其最重要的系统
• GV.SC（供应链风险管理类别） — 要么完全没有供应商风险计划，要么计划只停留在纸面上，实际上并不会影响采购决策
• ID.AM-08（在系统、硬件、软件、服务和数据的整个生命周期内进行管理） — 资产清单就是“ SaaS 供应商提供的列表”加上“我们记得的内容”
• ID.IM-04（演练事件响应计划） — 计划是有的，但上次测试已是三年前
• PR.AA-05（管理访问权限和授权，并贯彻最小权限原则） — 政策中规定每季度进行访问审查，实际上却没有执行
• PR.DS-01（保护静态数据的机密性、完整性和可用性） — 静态加密“是”，但密钥管理“问 AWS”
• DE.AE-08（在不利事件符合既定标准时宣布事件） — 实际上并没有定义标准；“看到时就知道了”
• RS.CO-02（通知内部和外部利益相关方事件情况） — 通知矩阵只存在某个人的脑子里
• RC.RP-01（执行恢复计划） — 有文档记录，但从未测试

输出格式

# NIST CSF 2.0 Posture Assessment
## Organization: [name]
## Scope: [what's in / out]
## Date: [date]
## Assessor: [name]

## Executive summary
[2-3 paragraphs in plain English — overall posture, top 3 risks, top 3 wins, recommended 90-day priorities]

## Profile

### Tier summary across functions
| Function | Current tier | Target tier |
|----------|--------------|-------------|
| GV | 2 | 3 |
| ID | 2 | 3 |
| PR | 3 | 3 |
| DE | 2 | 3 |
| RS | 3 | 3 |
| RC | 1 | 2 |

### Per-Subcategory detail
| Subcategory | Current state | Evidence | Tier | Target | Gap | Owner | Timeline |
|-------------|---------------|----------|------|--------|-----|-------|----------|

## Prioritized roadmap

### Next 30 days
- [Item, owner, success metric]

### Next 90 days
- [Item, owner, success metric]

### Next 12 months
- [Item, owner, success metric]

## Cross-references
[Links to evidence — audit reports, IR plans, IAM reports, etc.]

转化为董事会语言

董事会不想看子类别 ID。他们想要三个问题的答案：

1. 我们面临哪些风险？（3 到 5 项重大风险）
2. 我们正在采取什么措施？（具体投资、明确负责人、日期）
3. 我们如何判断情况有所改善？（量化指标、目标日期）

将 CSF 评估作为支撑细节。面向董事会的内容应是一页热力图和三张重点事项幻灯片。评估内容放在附录中。

适用边界

• 此技能用于生成治理材料和路线图，不用于漏洞利用
• CSF 评估不等同于监管意义上的审计（SOC 2 审计、FedRAMP 评估和 ISO 27001 认证审计都是独立流程）；CSF 映射可为这些流程提供参考，但不能取而代之
• 对于接受审计的环境（PCI、HIPAA、FedRAMP），审计方指定的框架具有权威性；CSF 映射是有用的补充
• 没有证据时，拒绝夸大层级评级——Tier 3 意味着“有证据表明组织范围内已形成文档化流程”，而不是“希望有一天能做到”
• 如果评估发现需要立即采取行动的问题（正在发生的事件、暴露的系统），应交接给 incident-triage 或相关审计技能

参考资料

• NIST Cybersecurity Framework 2.0（nist.gov/cyberframework）
• NIST CSF 2.0 快速入门指南
• NIST CSF 社区配置文件（特定行业的起点）
• NIST SP 800-53（控制措施目录，提供与 CSF 子类别对应的具体控制措施）
• ISO 27001:2022（替代性 ISMS 框架；同时采用两者的组织经常将其与 CSF 对照映射）
• CIS Critical Security Controls v8（替代性优先级框架；与 CSF 高度重叠）
• Cybersecurity Maturity Model Certification（CMMC）——适用于国防部承包商；采用 CSF + NIST 800-171
• 《Cybersecurity Risk Management: Mastering the Fundamentals Using the NIST Cybersecurity Framework》——Cynthia Brumfield