开展紫队演练

紫队演练是一个结构化过程，而不是临时的黑客活动。它遵循一个可重复的生命周期：

• 规划 — 选择目标、范围和技术
• 准备 — 确认遥测数据、工具和授权
• 执行 — 运行技术并实时观察
• 分析 — 对结果分类并记录缺口
• 改进 — 调整检测并重新测试
• 报告 — 记录指标和行动

将其视为一个生命周期，才能使结果具有长期可比性。

从一个明确且以威胁为依据的目标开始。模糊的目标（“测试我们的安全性”）只会产生模糊的结果。

好的目标应当具体且可衡量：

• 验证对勒索软件团伙使用的凭据访问技术的检测能力
• 确认横向移动战术的可见性
• 衡量针对已知入侵链的平均检测时间

将目标锚定到与组织相关的真实威胁行为者或场景，这样您测试的技术才是组织最有可能遭遇的技术。

将目标转化为一份按顺序排列、包含具体实施方式的技术清单。这就是您的仿真计划。

每个条目都应说明技术 ID、实施方式、预期遥测数据以及待验证的假设：

• 技术： T1003.001 LSASS 内存
• 实施方式： 使用无害测试工具转储 LSASS
• 预期遥测数据： 系统监视器事件 ID 10（进程访问 lsass.exe）
• 假设： EDR 会针对未经授权的 LSASS 句柄访问发出警报

在运行任何内容之前，必须取得书面授权并记录交战规则（ROE）。这能在法律和运营层面保护团队。

• 已定义范围：涉及的主机、网络和账户
• 时间窗口和明确的停止条件
• 已批准与禁止的技术
• 紧急联系人和中止信号
• 数据处理：绝不外泄真实的敏感数据

即使是协作测试，也可能触发警报或中断服务，因此 ROE 必须明确，并获得利益相关者的批准。

在现场会话开始前确认基础条件正常，否则您会把宝贵时间浪费在调试日志记录上。

• 确认端点代理和系统监视器已经部署并持续上报
• 确认日志以可接受的延迟到达 SIEM
• 准备仿真工具（原子红队、卡尔德拉）
• 为每项预期产物准备保存好的 SIEM 查询

例如，通过检查已知事件是否出现来执行快速冒烟测试，可以在真实技术开始前验证数据流水线。

执行期间，应在受控时间窗口内一次运行一项技术，以确保因果关系清晰明确。红队讲解操作并记录准确的时间戳。

例如，执行用于计划任务持久化的原子测试：

执行后，蓝队立即运行准备好的查询，并记录所观察到的内容。请明确分类结果：

• 已阻断 — 操作被直接阻止
• 已告警 — 检测规则已触发
• 仅记录 — 存在证据，但没有警报
• 无遥测数据 — 未捕获任何内容

请记录操作和警报的时间戳，以便稍后计算检测耗时。

许多仿真工具会创建残留物：计划任务、注册表项、文件或账户。每项技术执行后都应进行清理，以保持环境整洁，并避免今后出现误报结果。

Atomic Red Team 提供清理命令：

紫队的核心特征是在同一会话中修复缺口。当某项技术未被检测到时，检测工程师会编写规则，然后团队重新运行该技术，以确认规则现在能够触发。

• 发现缺口：计划任务创建未触发警报
• 针对事件 ID 4698（任务创建）编写规则，并加入可疑模式
• 重新运行 Atomic 测试
• 确认新规则触发，然后记录成果

这种即时迭代远比将修复推迟到待办列表中有效。

严谨地记录结果，才能让这项演练在之后真正发挥价值。请为每项技术记录结构化结果：

• 技术 ID 和操作步骤
• 结果（已阻断 / 已告警 / 已记录 / 盲区）
• 观察到的数据源
• 触发的检测规则（或新创建的规则）
• 检测耗时，以及任何后续操作

VECTR 等工具可以存储这些结果，并让您比较一段时间内的多次运行，以展示可衡量的改进。

请在细节仍然清晰时进行复盘，结束本次演练。输出应是一份按优先级排列的可执行清单，而不是一大段文字。

• 哪些内容已检测到、未检测到，以及新增覆盖了哪些内容
• 按风险和可能性排序的检测缺口
• 每项修复任务的负责人和截止日期
• 下一周期需要重新验证的技术

请将检测待办项交给工程团队，并安排下一次运行。只有真正落实这些行动，这项演练才能产生价值。

测试您对紫队演练执行方式的理解。

现在您已经能够端到端地运行紫队演练：

• 遵循规划、准备、执行、分析、改进、报告的生命周期
• 设定基于威胁的目标和具体的仿真计划
• 确保获得授权和 ROE，并首先验证遥测数据
• 一次运行一项技术，实时观察并分类结果
• 清理残留物，并在会话内弥合缺口
• 记录结构化结果，并以按优先级排列的交接结束

接下来您将学习如何使用推动改进的指标来衡量覆盖率并弥合检测缺口。