Die Oberfläche ist lokalisiert; Skill-Beschreibungen und -Dokumente werden per KI automatisch in Ihre Sprache übersetzt. Code, Befehle, Pfade und Fachbegriffe bleiben im Original, maßgeblich ist das Dokument des Autors.
Skills entdecken
Produktivität · SKILL.md

building-incident-response-playbook

building-incident-response-playbook

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

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill-Dokumentation

GitHub

name: building-incident-response-playbook description: > 设计并记录结构化的事件响应手册(Incident Response Playbook),定义与 NIST SP 800-61r3 和 SANS PICERL 框架对齐的特定事件类型逐步处理程序。涵盖手册结构、决策树、升级标准、RACI 矩阵和与 SOAR 平台的集成。适用于 IR 手册创建、事件响应程序文档、响应运行手册(Runbook)开发或 SOAR 手册设计等请求。 domain: cybersecurity subdomain: incident-response tags: [IR-playbook, runbook, NIST-800-61, SOAR-integration, response-procedures] version: 1.0.0 author: mahipal license: Apache-2.0

构建事件响应手册

适用场景

  • 从零开始建立或完善事件响应(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 小时
Gespeicherte Skills