# Building Incident Response Playbook

> 设计并记录结构化的事件响应手册（Incident Response Playbook），定义与 NIST SP 800-61r3 和 SANS PICERL 框架对齐的特定事件类型逐步处理程序。涵盖手册结构、决策树、升级标准、RACI 矩阵和与 SOAR 平台的集成。适用于 IR 手册创建、事件响应程序文档、响应运行手册（Runbook）开发或 SOAR 手册设计等请求。

- Skill: `killvxk/building-incident-response-playbook` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add killvxk/building-incident-response-playbook`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/building-incident-response-playbook/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/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 admin@dns-primary.corp.local
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
触发器：      通过 abuse@corp.com 或钓鱼按钮报告的钓鱼邮件

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 小时
```