killvxk 构建事件响应手册
适用场景
- 从零开始建立或完善事件响应（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 的组织没有有文档记录的钓鱼响应程序。分析师处理钓鱼报告的方式不一致。
方法：
- 采访 SOC 分析师，记录他们当前的临时流程
- 定义触发器：用户通过 abuse@ 邮箱或钓鱼按钮报告钓鱼邮件
- 编写分诊步骤：提取邮件头、检查发件人信誉、在沙箱中分析 URL/附件
- 定义遏制：从所有邮箱中隔离邮件、封锁发件人域、如果输入了凭据则重置密码
- 构建 SOAR 自动化：自动从报告邮件中提取 IOC，通过 VirusTotal 丰富化，在 TheHive 中创建案例
- 用模拟钓鱼邮件测试并衡量响应时间改善
常见陷阱：
- 编写过于通用的程序，不引用特定工具界面或命令
- 未包含通知收到钓鱼邮件的用户的通信计划
- 忘记定义钓鱼报告何时升级为完整事件调查的标准
- 不对手册进行版本控制或安排定期审查周期
输出格式
事件响应手册（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 小时