弥合检测缺口与衡量指标

紫队演练会产生丰富的数据，但没有指标，这些数据就只能算作零散案例。指标可以将演练转化为一套能够向管理层和预算负责人证明改进成效的依据。

• 指标能够显示防御措施是否确实变得更好
• 指标能够帮助确定有限工程资源应优先投入的方向
• 指标能够将抽象的“安全态势”变得具体且可跟踪

目标不是为了分数本身而追求高分，而是针对相关威胁实现可衡量且持续的改进。

核心指标是检测覆盖率：已测试技术中产生警报的比例。

请分别按战术和总体情况计算：

覆盖率百分比可能会误导您。只统计您选择测试的技术会抬高数值，而将脆弱的规则算作“已覆盖”则会夸大实际防御能力。

• 覆盖率应针对与威胁相关的技术集合进行衡量，而不是针对精心挑选的集合
• “已检测到”的结果必须来自稳健的、基于行为的规则
• 仅记录的结果不属于覆盖率，只能算作潜在覆盖

请始终将百分比与分母一起列出：“FIN7 技术的 80%”比单独写“80%”所传达的信息多得多。

响应速度与可见性同样重要。两项时间指标可以体现防御响应能力：

• MTTD — 平均检测时间：从操作时间戳到警报时间戳
• MTTR — 平均响应时间：从警报到遏制操作

由于紫队演练会记录每项技术运行的确切时刻，因此您可以精确测量这些指标，而不必根据杂乱的事件数据进行估算。

并非所有缺口都需要同等程度的紧迫处理。请综合技术发生的可能性及其可能造成的损害，按风险为缺口排序。

• 高可能性 + 高影响（例如 LSASS 转储）= 优先修复
• 低可能性 + 低影响 = 加入待办列表
• 根据威胁情报中是否出现该技术进行加权

将可能性乘以影响进行简单评分，就能生成有序的修复清单，把精力集中在最能降低现实风险的地方。

在编写规则之前，请先诊断缺口为何存在。修复方式取决于根本原因：

• 无遥测数据 — 启用缺失的数据源（例如 Sysmon 配置、脚本块日志记录）
• 有遥测数据但没有规则 — 编写检测规则
• 规则存在但未触发 — 修复抑制其触发的逻辑或筛选条件
• 警报已触发但被忽略 — 这是流程或研判问题，而不是内容缺口

如果底层日志从未被收集，修复逻辑错误就是在浪费精力。

最根本的缺口是数据缺失。例如，可以通过组策略或注册表启用 PowerShell 脚本块日志记录，从而提供事件 ID 4104。

遥测数据就绪后，请编写检测规则并调优其有效信号。未经调优的规则会让分析员淹没在误报中，最终被忽略。

• 先采用宽泛条件，确认痕迹能够出现
• 为已知正常的基线活动添加排除项
• 根据正常流量衡量误报率
• 重新运行仿真，确认规则仍能捕获攻击

只有当检测规则能够可靠地针对攻击触发，并且在良性活动上保持静默时，才算“完成”。

单次演练的数字只是快照；趋势才能说明真实情况。请跨季度跟踪覆盖率和 MTTD。

• 第一季度：45% 覆盖率，MTTD 22 分钟
• 第二季度：62% 覆盖率，MTTD 14 分钟
• 第三季度：71% 覆盖率，MTTD 9 分钟

不断改善的趋势表明紫队演练正在产生回报。持平或下降的趋势则说明检测能力正在衰减，或者修复没有真正落实。

检测规则会随着环境变化而静默失效。请将其视为代码，并针对回归问题进行测试。

• 每个周期重新运行之前通过的技术
• 自动执行持续验证，以便在检测规则失效时触发警报
• 对检测内容进行版本控制，并审查变更

一个悄然停止触发的检测规则可以说比从未存在过更糟，因为团队会以为自己受到保护，实际却并非如此。

请根据受众调整报告内容。工程师需要技术级别的细节；管理层需要结果和风险。

• 面向工程师：每项技术的结果、创建的规则、调优说明
• 面向管理层：覆盖率趋势、MTTD 趋势、已消除和剩余的主要风险
• 可视化：展示一段时间内进展的 ATT&CK Navigator 热力图

将结果表述为风险降低，而不是原始技术数据，才能持续获得对该项目的支持和资金。

测试您对弥合缺口和使用指标的理解。

现在您已经能够严格衡量并改进检测覆盖率：

• 使用覆盖率、MTTD 和 MTTR作为核心指标，并始终注明分母
• 避免由精心挑选或脆弱的检测规则造成的覆盖率假象
• 修复每个缺口前先进行根因分析：遥测数据、规则、逻辑或研判
• 启用缺失的数据，然后调优规则以降低误报率
• 跟踪趋势，防范静默的检测回归
• 使用 ATT&CK 热力图，以降低风险的方式进行报告，从而维持该项目

您已经完成紫队演练课程：将红队和蓝队衔接成一个持续、可衡量的闭环，让防御能力得到可验证的改善。