incident-triage

事件分诊 — 安全事件响应

指导如何快速分诊并初步响应安全事件。遵循 NIST SP 800-61 Rev. 3（2025 年 4 月），该版本用 CSF 2.0 功能替代了 Rev. 2 的四阶段生命周期：Govern、Identify 和 Protect 是事件发生前的准备工作；Detect、Respond 和 Recover 则属于响应。本技能覆盖最初几个小时的工作——从 Detect 到 Respond 阶段的开始——其余工作将移交处理。每个步骤都会列出其产出的 CSF 2.0 成果，因此报告可直接映射到组织的 CSF 配置文件（参见 csf-mapping）。

交叉参考：siem-detection 用于查看触发本次分诊响应的规则；disk-forensics 用于主机被隔离后的深入磁盘和内存分析；breach-patterns 用于提取事后模式，以强化防护、避免事件再次发生；soc-operations 用于了解本技能之上的运营层（运行手册、升级、交接）；security-comms 用于处理响应过程中产生的利益相关者／客户通知；当涉及个人数据、PHI 或持卡人数据时，使用 privacy-engineering / hipaa-audit / pci-audit 确定法规时限；ai-risk-management 用于处理 AI 特定事件类别（模型故障、公平性漂移、生产环境中的越狱利用）；如果怀疑入口点是 AI 编码 Agent 扩展（技能、插件、钩子或 MCP 服务），则使用 agent-supply-chain-audit；log-watch 用于定期日志审查，小型团队往往会在其中发现首个警报；怀疑凭据被盗时，使用 secrets-audit 中的外泄数据收集器域名列表（webhook.site、requestbin、ngrok、Discord / Telegram / Slack webhooks）检查出口日志。

授权

仅代表系统所有者或事件负责人，对范围内的系统执行操作。下列只读命令（进程、网络、用户和文件列表）已获预先批准。每项遏制操作——拦截、隔离、停用账户、停止服务——都会改变生产环境：运行前，说明操作及其影响范围，并获得事件负责人的批准。切勿触碰已声明范围之外的系统，即使指标指向这些系统也不例外；应改为报告相关情况。

优先事项（按顺序）

1. 保障人身安全
2. 遏制事件，防止造成进一步损害
3. 为调查保全证据
4. 确定根本原因和影响范围
5. 记录所有事项

步骤 1：声明、验证并确定优先级（DE.AE-02、DE.AE-08、RS.MA-02、RS.MA-03）

这是一起事件吗？在调动人员之前验证报告：通过第二个来源（原始日志、主机本身）核实警报，排除已知变更或测试，并记录报告人及报告时间。如果符合组织的事件标准，正式声明事件并记录声明时间（UTC）——法规时限通常从发现或判定时开始计算，而不是从攻击发生时开始。如果 IR 计划指定了事件负责人、第三方（MSSP、IR 顾问服务、网络保险公司——许多保单要求在聘请外部响应人员前通知保险公司）或战情室频道，立即启动相关流程（RS.MA-01）。

确定事件类型：

• 恶意软件： 勒索软件、木马、蠕虫、加密货币挖矿程序
• 未授权访问： 凭据遭入侵、漏洞利用
• 数据外泄： 数据窃取、内部人员威胁
• 拒绝服务
• 网站遭入侵： 篡改、窃取支付信息、后门
• 网络钓鱼／社会工程

确定严重程度：

• 严重： 正在发生数据外泄、勒索软件正在传播、关键系统遭入侵
• 高： 已确认遭入侵、检测到恶意软件、未授权访问
• 中： 可疑活动、潜在指标、攻击未遂
• 低： 违反策略、检测到侦察活动、很可能是误报

当严重程度为高或以上、可能涉及受监管数据（个人数据、PHI、持卡人数据）、攻击者可能仍在活动，或影响范围跨越多个团队或供应商时，应升级处理（RS.MA-04）。

步骤 2：初步遏制（RS.MI-01）

根据类型和严重程度：

• **网络：**在防火墙上阻止可疑 IP／域名
• **主机：**隔离受影响的系统（断开网络连接，不要关机——易失性内存是证据）
• **账户：**禁用已被入侵的账户，强制重置密码
• **应用程序：**在安全可行的情况下，禁用受影响的服务
• **凭据和令牌：**撤销会话，并轮换攻击者可能掌握的密钥；使用 secrets-audit 查找它们的存放位置

在可行时，遏制行动应避免惊动仍在活动的攻击者：如果攻击者仍在系统内，应协调隔离、禁用和轮换操作同时进行，否则攻击者会转向你尚未发现的持久化机制。

**重要：切勿关闭系统。**易失性内存中包含证据。

步骤 3：证据保全（RS.AN-06、RS.AN-07）

按易失性顺序采集（最易失的优先）：

# 1. Running processes
ps auxf                         # Linux
tasklist /v                     # Windows

# 2. Network connections
ss -tupn                        # Linux
netstat -anob                   # Windows

# 3. Logged-in users
who -a                          # Linux
query user                      # Windows

# 4. Open files
lsof -nP                        # Linux

# 5. System logs
journalctl --since "1 hour ago" # Linux/systemd

如果有内存取证工具（LiME、WinPmem），应先采集内存转储，再进行其他操作。

保全证据的完整性和来源信息：在采集时对每份材料计算哈希值（sha256sum），记录采集人、采集地点和时间，并记录每条已运行命令及已采取遏制措施的操作日志（时间、执行人、结果）。在云端和 SaaS 日志的保留期限结束前复制这些日志。更深入的镜像和内存分析交由 disk-forensics 处理。

步骤 4：初步分析和范围界定（RS.AN-03、RS.AN-08）

针对每个可疑指标，记录：

• **内容：**描述证据材料
• **时间：**使用 UTC 时间戳
• **位置：**受影响的系统
• **方式：**说明发现该指标的方式

常见分析内容：

• **进程树：**查找异常的进程名称、路径或父子进程关系
• **网络指标：**异常出站连接、向可疑域名发起的 DNS 查询、信标通信模式（固定时间间隔）
• **文件指标：**近期在异常位置修改的文件、隐藏文件、新可执行文件
• **日志分析：**身份验证失败、权限提升、服务变更、日志清除
• **持久化：**crontab、systemd 单元、注册表 Run 键、计划任务、启动项

评估影响规模（RS.AN-08）并及时更新：受影响的系统、账户和数据集，攻击者从这些位置可能访问的内容，以及最早发现的活动时间。将范围记录为已确认／疑似／已排除，并为每项注明证据——通知决策取决于这些信息。

步骤 5：提取 IOC（RS.AN-07、RS.CO-03）

提取并记录所有入侵指标：

类型	示例
IP 地址	源 IP 和目标 IP
域名	C2 域名、钓鱼域名
文件哈希值	可疑文件的 MD5 和 SHA256
文件路径	恶意软件位置、投放的文件
电子邮件地址	钓鱼邮件发件人地址
URL	恶意 URL、C2 端点
User-Agent	异常或已知恶意的 User-Agent

将 IOC 纳入检测流程（使用 siem-detection、threat-hunting 扫描其他位置），并在事件负责人批准后与指定方（ISAC、供应商、IR 常驻服务商）共享。

第 6 步：沟通和通知时限（RS.CO-02、RS.CO-03）

根据 IR 计划通知内部相关方，并确定哪些外部时限可能已经开始。由法律顾问作出判断；你的职责是尽早说明事实和截止日期。常见时限如下（请核实最新文本）：

制度	时限
GDPR（个人数据）	自知悉起 72 小时内通知监管机构
NIS2（欧盟重要实体和基本实体）	24 小时内发出预警，72 小时内通知，一个月内提交最终报告
HIPAA（PHI）	不得无理延迟，最迟须在发现后 60 天内通知
SEC Form 8-K Item 1.05（美国上市公司）	事件被认定为重大事件后 4 个工作日内
PCI DSS（持卡人数据）	根据卡品牌和收单机构的要求，通常须立即通知
美国各州的数据泄露法律、合同、网络保险	各不相同；请查看合同和保单

使用 security-comms 起草消息；受监管数据的判定由 privacy-engineering、hipaa-audit 和 pci-audit 负责。

第 7 步：移交清除、恢复和经验总结工作（RS.MI-02、RS.MA-05、RC.RP、ID.IM）

事件得到遏制并明确范围后，分诊工作即告结束。为下一位负责人记录以下内容：

• 清除（RS.MI-02）：需要移除或轮换的所有持久化机制和凭据，以及确认其已清除的方法
• 恢复（RS.MA-05、RC.RP）：启动恢复的标准、已知干净的还原点，以及在恢复后的系统重新接入生产环境前，确认其运行正常的检查项
• 经验总结（ID.IM）：安排事件后审查；breach-patterns 会将其转化为审计问题

输出格式

# Incident Triage Report
## Incident ID: [ID]
## Date/Time: [UTC]
## Severity: [Critical/High/Medium/Low]
## Classification: [incident type]
## Status: [Triage/Contained/Analyzing/Recovering/Closed]
## Declared: [UTC time and who declared]   ## Incident lead: [name]

### Summary
[2-3 sentence overview]

### Scope
| Asset (host / account / data set) | Status (known / suspected / ruled out) | Evidence |
|-----------------------------------|----------------------------------------|----------|

### Timeline
| Time (UTC) | Event | Source | Notes |
|------------|-------|--------|-------|

### Indicators of Compromise
| Type | Value | Context | Confidence |
|------|-------|---------|------------|

### Action Log
| Time (UTC) | Actor | Action | Approved by | Result |
|------------|-------|--------|-------------|--------|

### Evidence Preserved
| Type | Location | Hash | Notes |
|------|----------|------|-------|

### Recommended Next Steps
1. [Immediate priority]
2. [Short-term action]
3. [Follow-up investigation]

### Notification Clocks
| Regime | Clock started (UTC) | Deadline | Owner | Status |
|--------|---------------------|----------|-------|--------|

### Escalation Checklist
- [ ] Incident lead and management notified
- [ ] Legal / counsel notified (if regulated data may be involved)
- [ ] Cyber insurer notified (before engaging outside responders, if the policy requires it)
- [ ] Law enforcement (if applicable)
- [ ] Affected parties notified (per counsel)

### Handoff
- Eradication: [persistence and credentials to remove, how to confirm]
- Recovery: [criteria, clean restore points, health checks]
- Lessons learned: [review date, owner]

边界

• 专注于防御和遏制，而非反击
• 保全证据——切勿修改日志或时间戳
• 确认发生泄露后，建议上报法律和管理层
• 如果不确定某项遏制措施的影响，请谨慎处理并提出疑问
• 切勿建议“黑回去”或采取报复行动
• 拒绝掩盖事件或篡改证据的请求

参考资料

• NIST SP 800-61 Rev. 3（2025 年 4 月）：事件响应建议和网络安全风险管理注意事项——CSF 2.0 社区配置文件；取代 Rev. 2（2012 年）
• NIST Cybersecurity Framework 2.0（响应和恢复职能）
• SANS Incident Handler's Handbook
• MITRE ATT&CK Framework