killvxk/building-incident-response-playbook

构建事件响应手册

适用场景

• 从零开始建立或完善事件响应（Incident Response）项目
• 在新型攻击发生后为新事件类型记录处理程序
• 在 SOAR 平台（Cortex XSOAR、Splunk SOAR）中自动化响应工作流
• 为需要有文档化 IR 程序的合规审计做准备（SOC 2、PCI-DSS、HIPAA）
• 针对特定威胁场景对现有 IR 能力进行差距分析

不适用于一次性临时调查；手册是可复用的程序文档，而非特定案例的报告。

前置条件

• 根据可能性和影响识别主要事件场景的组织风险评估
• 已采用 NIST SP 800-61r3 或 SANS PICERL 框架作为组织 IR 标准
• 具有业务关键性评级和数据分类的资产清单
• 定义了以下角色的 RACI 图：事件指挥官、SOC 分析师、系统管理员、法律、通信
• 现有检测能力清单（SIEM 规则、EDR 检测、IDS 特征）
• 如果构建自动化手册，需要 SOAR 平台访问权限

工作流程

步骤 1：选择和界定事件类型

定义手册将处理的特定场景：

• 根据组织风险评估和历史数据确定主要事件类型
• 将每个手册的范围限定为单一事件类型以确保清晰性（不要合并不相关的场景）
• 定义激活手册的触发条件

常见手册类型：

优先手册（首先构建）：
1. 勒索软件（Ransomware）事件响应
2. 钓鱼（Phishing）/凭据泄露
3. 商业电子邮件攻击（BEC）
4. 恶意软件感染
5. 数据泄露/外泄（Exfiltration）
6. DDoS 攻击
7. 内部威胁（Insider Threat）
8. 账户接管（Account Takeover）
9. Web 应用程序攻陷
10. 云基础设施攻陷

步骤 2：定义手册结构

每个手册应遵循一致的结构：

手册模板
━━━━━━━━━━━━━━━━
1. 手册元数据
   - 名称、版本、负责人、最后审查日期
   - 触发条件
   - 严重性标准

2. RACI 矩阵
   - 每个步骤的责任人（Responsible）、审批人（Accountable）、咨询对象（Consulted）、知情人（Informed）

3. 检测与分诊（Triage）
   - 事件如何被检测到
   - 初始分诊检查表
   - 严重性分类标准

4. 遏制（Containment）
   - 短期遏制措施
   - 长期遏制措施
   - 证据保全要求

5. 根除（Eradication）
   - 根本原因识别
   - 恶意软件/威胁清除步骤
   - 验证程序

6. 恢复（Recovery）
   - 系统恢复步骤
   - 验证标准
   - 恢复后监控要求

7. 事后处理（Post-Incident）
   - 经验教训会议触发条件
   - 报告模板
   - 检测改进操作

8. 通信
   - 内部通知矩阵
   - 外部通知要求（监管机构、客户、执法部门）
   - 状态更新频率

9. 附录
   - 工具特定程序
   - 联系人列表
   - 证据收集检查表

步骤 3：编写决策树和升级标准

定义具有二元结果的清晰决策点：

收到检测告警
├── 告警是真阳性吗？
│   ├── 是 → 分类严重性
│   │   ├── P1（严重）→ 传呼事件指挥官，立即开始遏制
│   │   ├── P2（高）→ 通知 IR 负责人，30 分钟内开始调查
│   │   ├── P3（中）→ 4 小时内排队调查
│   │   └── P4（低）→ 记录并在 24 小时内调查
│   └── 否 → 记录为误报，调整检测规则
└── 无法确定 → 升级到 Tier 2 进行深入分析

升级触发器：

• 任何 P1 事件：立即升级至 IR 负责人和 CISO
• 确认数据外泄：通知法律顾问和隐私保护负责人
• 涉及客户数据：激活客户通知流程
• 涉及第三方：联系供应商安全联系人
• 需要执法部门：法律总顾问授权后再联系

步骤 4：定义具体技术程序

为每个步骤编写工具特定的指令（而非通用指南）：

遏制 - 通过 CrowdStrike 隔离端点：
1. 打开 Falcon 控制台 > Hosts > 搜索受影响的主机名
2. 点击主机 > Host Details
3. 点击右上角的"Contain Host"按钮
4. 确认隔离（主机将只与 CrowdStrike 云通信）
5. 在事件工单中记录遏制操作及时间戳
6. 验证遏制：主机应显示"Contained"状态标志

遏制 - 在 DNS 处封锁 C2 域：
1. SSH 到 DNS 服务器：ssh [email protected]
2. 添加到阻止区：echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. 重新加载 DNS：rndc reload
4. 验证：dig @dns-primary evil.com（应解析到网络陷阱 IP 10.0.0.99）
5. 在事件工单中记录已封锁的域名

步骤 5：与 SOAR 平台集成

将手动手册步骤转换为自动化工作流：

• 将每个手册步骤映射到 SOAR 操作（API 调用、脚本、人工决策点）
• 定义自动化边界（自动运行什么 vs. 需要分析师审批什么）
• 构建分诊阶段的丰富化自动化
• 为高影响操作创建带审批门控的遏制自动化
• 配置利益相关者通信的通知自动化

步骤 6：测试和维护手册

通过演练验证手册并保持时效性：

• 与 IR 团队一起进行桌面演练（Tabletop Exercise），逐步走过手册
• 在测试环境中模拟事件类型进行实战演练
• 每次使用该手册处理真实事件后审查并更新
• 每季度审查联系人列表、工具程序和升级路径的准确性
• 跟踪手册指标：平均遏制时间、平均解决时间、误报率

核心概念

| 术语 | 定义 | |------|------------| | 手册（Playbook） | 用于响应特定事件类型的有文档记录的、可重复的程序集合 | | 运行手册（Runbook） | 比手册更细粒度；手册中特定任务的逐步技术指令 | | RACI 矩阵 | 责任分配图，定义每项活动中谁负责（Responsible）、谁审批（Accountable）、谁咨询（Consulted）、谁知情（Informed） | | 决策树（Decision Tree） | 基于每个决策点二元条件定义响应路径的流程图逻辑 | | 升级标准（Escalation Criteria） | 触发通知更高级别人员或外部各方的预定义条件 | | SOAR 手册 | 在安全编排、自动化和响应（Security Orchestration, Automation, and Response）平台中执行手册步骤的自动化工作流 |

工具与系统

• Cortex XSOAR：具有可视化手册编辑器、700+ 集成和协作作战室（War Room）的 SOAR 平台
• Splunk SOAR：与 Splunk ES 集成的 SOAR 平台，具有拖放手册构建器和 2800+ 自动化操作
• TheHive：开源事件响应平台，具有用作手册框架的案例模板
• Confluence / GitLab Wiki：用于维护带版本控制的人类可读手册文档的文档平台
• Tines：无代码安全自动化平台，无需编程即可构建手册工作流

常见场景

场景：从零开始构建钓鱼响应手册

场景背景：一个拥有 5 人 SOC 的组织没有有文档记录的钓鱼响应程序。分析师处理钓鱼报告的方式不一致。

方法：

1. 采访 SOC 分析师，记录他们当前的临时流程
2. 定义触发器：用户通过 abuse@ 邮箱或钓鱼按钮报告钓鱼邮件
3. 编写分诊步骤：提取邮件头、检查发件人信誉、在沙箱中分析 URL/附件
4. 定义遏制：从所有邮箱中隔离邮件、封锁发件人域、如果输入了凭据则重置密码
5. 构建 SOAR 自动化：自动从报告邮件中提取 IOC，通过 VirusTotal 丰富化，在 TheHive 中创建案例
6. 用模拟钓鱼邮件测试并衡量响应时间改善

常见陷阱：

• 编写过于通用的程序，不引用特定工具界面或命令
• 未包含通知收到钓鱼邮件的用户的通信计划
• 忘记定义钓鱼报告何时升级为完整事件调查的标准
• 不对手册进行版本控制或安排定期审查周期

输出格式

事件响应手册（INCIDENT RESPONSE PLAYBOOK）
============================
手册名称：    钓鱼（Phishing）事件响应
版本：        2.1
负责人：      SOC 经理
最后审查：    2025-11-01
下次审查：    2026-02-01
触发器：      通过 [email protected] 或钓鱼按钮报告的钓鱼邮件

RACI 矩阵
活动                    | SOC L1 | SOC L2 | IR 负责人 | 法律 | 通信
初始分诊                |   R    |   C    |   I      |      |
邮件分析                |   R    |   A    |   I      |      |
遏制                    |        |   R    |   A      |   I  |
凭据重置                |        |   R    |   A      |      |
用户通知                |        |   C    |   A      |      |   R
监管通知                |        |        |   C      |   R  |   A
经验教训                |   C    |   C    |   R      |   I  |   I

程序步骤
[详细步骤，含工具特定指令]

决策树
[流程图逻辑]

升级矩阵
[条件和联系人]

指标
目标 MTTA：15 分钟
目标 MTTC：1 小时
目标 MTTR：4 小时