# Triaging Security Incident

> 使用 NIST SP 800-61r3 和 SANS PICERL 框架对安全事件进行初始分类，确定严重性、范围和所需响应行动。 按类型对事件分类，根据业务影响分配优先级，并路由到相应的响应团队。适用于事件分类、 安全告警分类、严重性评估、事件优先级排序或初始事件分析等请求场景。

- Skill: `killvxk/triaging-security-incident` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add killvxk/triaging-security-incident`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/triaging-security-incident/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/killvxk/triaging-security-incident

---


# 安全事件分类（Triaging Security Incidents）

## 适用场景

- SIEM 或 EDR 告警触发，需要人工分类后再升级
- 多个并发告警同时到来，SOC 需要对响应顺序进行优先排序
- 最终用户报告可疑活动，事件需要初始分类
- 威胁情报订阅中发现与环境中观察到的 IOC 匹配

**不适用场景**：常规漏洞扫描结果或不代表活跃安全事件的合规审计发现。

## 前置条件

- 访问含当前告警数据的 SIEM 平台（Splunk、Elastic、Microsoft Sentinel）
- 与 NIST SP 800-61r3 类别对齐的事件分类法
- 将资产重要性与威胁类型映射的预定义严重性矩阵
- 升级路径联系人名册（一级到三级和 CIRT）
- 含业务重要性评级的资产清单

## 工作流程

### 步骤 1：收集初始告警数据

在做出分类决定前，从触发告警中收集所有可用的上下文：

- **告警来源**：哪个检测系统生成了告警（EDR、SIEM、IDS/IPS、防火墙、用户报告）
- **时间戳**：事件发生时间和检测时间（驻留时间差）
- **受影响资产**：涉及的主机名、IP 地址、用户账号
- **告警可信度**：此检测规则的历史真阳性率
- **原始证据**：日志条目、数据包捕获、进程执行链

```
SIEM 告警上下文示例：
来源：       CrowdStrike Falcon
检测：       可疑 PowerShell 执行（T1059.001）
主机：       WORKSTATION-FIN-042
用户：       jsmith@corp.example.com
时间戳：     2025-11-15T14:23:17Z
严重性：     High（检测规则置信度：92%）
进程：       powershell.exe -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoA...
父进程：     outlook.exe（PID 4812）
```

### 步骤 2：对事件类型进行分类

按照 NIST SP 800-61r3 将告警映射到标准事件类别：

| 类别 | 示例 |
|------|------|
| 未授权访问 | 凭据攻陷、权限提升、IDOR |
| 拒绝服务 | 容量型 DDoS、应用层泛洪、资源耗尽 |
| 恶意代码 | 恶意软件执行、勒索软件引爆、挖矿软件 |
| 不当使用 | 违反策略、内部数据外泄、影子 IT |
| 侦察 | 端口扫描、目录枚举、凭据喷洒 |
| Web 应用攻击 | SQL 注入、XSS、SSRF 利用 |

### 步骤 3：使用影响矩阵分配严重性

结合资产重要性和威胁严重性计算严重级别：

```
严重性 = f（资产重要性, 威胁类型, 数据敏感性, 横向移动潜力）

严重（P1）：关键系统受攻陷、活跃数据外泄、勒索软件正在传播
高（P2）：  生产系统受攻陷、确认恶意软件执行、特权账号接管
中（P3）：  非生产系统受攻陷、未成功的利用尝试、单端点恶意软件
低（P4）：  侦察活动、违反策略、良性真阳性
```

响应 SLA 目标：
- P1：15 分钟内确认，1 小时内遏制
- P2：30 分钟内确认，4 小时内遏制
- P3：2 小时内确认，24 小时内调查
- P4：8 小时内确认，72 小时内调查

### 步骤 4：执行初始丰富化

升级前，用上下文数据丰富告警：

- **威胁情报**：在 TI 平台（VirusTotal、OTX、MISP）检查 IOC（IP、哈希、域名）
- **资产上下文**：查询 CMDB 获取资产所有者、业务功能、数据分类
- **用户上下文**：检查身份提供商的最近认证异常、MFA 状态
- **历史关联**：搜索过去 30 天内同一主机/用户的相关告警
- **网络上下文**：验证源/目标 IP 是内部、已知合作伙伴还是外部威胁行为者

### 步骤 5：记录并升级

创建结构化分类记录并路由到适当的响应层级：

```
事件分类记录
━━━━━━━━━━━━━━━━━━━━━
工单 ID：       INC-2025-1547
分类分析员：    [分析员姓名]
分类时间：      2025-11-15T14:35:00Z（告警后 12 分钟）
分类：          恶意代码 - 基于宏的初始访问
严重性：        P2 - High
受影响资产：    WORKSTATION-FIN-042（财务部门，处理 PII）
受影响用户：    jsmith@corp.example.com
已识别 IOC：    outlook.exe 生成 powershell.exe，编码命令
TI 匹配：       Base64 载荷与已知 Qakbot 加载器模式匹配
升级路径：      二级 - 恶意软件 IR 团队
建议行动：      隔离端点、保全内存转储、阻断发件人域名
```

### 步骤 6：启动遏制保持

若严重性为 P1 或 P2，在等待完整调查的同时启动立即遏制措施：

- 通过 EDR 对受影响端点进行网络隔离（CrowdStrike contain、Defender isolate）
- 在 Active Directory 或身份提供商中禁用受攻陷用户账号
- 在防火墙和 DNS Sinkhole 阻断已识别的恶意 IP/域名
- 在任何修复前保全易失性证据（内存转储）

## 核心概念

| 术语 | 定义 |
|------|------|
| **分类（Triage）** | 基于严重性和业务影响对安全事件进行分类和优先排序的快速评估过程 |
| **PICERL** | SANS 事件响应框架：准备（Preparation）、识别（Identification）、遏制（Containment）、根除（Eradication）、恢复（Recovery）、经验教训（Lessons Learned） |
| **驻留时间（Dwell Time）** | 初始攻陷到检测之间的时长；Mandiant M-Trends 2025 显示平均为 10 天 |
| **真阳性率（True Positive Rate）** | 检测规则告警中代表真实安全事件的百分比 |
| **关键资产（Crown Jewel Assets）** | 对业务运营至关重要的系统和数据，其攻陷将对组织造成严重影响 |
| **告警疲劳（Alert Fatigue）** | 由大量低质量或误报告警导致的分析员性能下降 |
| **平均确认时间（MTTA）** | 从告警生成到分析员确认的平均时间；关键 SOC 性能指标 |

## 工具与系统

- **Splunk Enterprise Security**：用于告警聚合、关联和分类工作流管理的 SIEM 平台
- **CrowdStrike Falcon**：提供端点遥测、检测和一键主机遏制的 EDR 平台
- **TheHive**：用于案例管理、任务追踪和团队协作的开源事件响应平台
- **MISP**：用于分类期间 IOC 丰富化的威胁情报共享平台
- **Cortex XSOAR**：用于自动化丰富化 Playbook 和分类决策树的 SOAR 平台

## 常见场景

### 场景：来自邮件客户端的编码 PowerShell

**背景**：SOC 分析员收到 P2 告警，显示财务部门工作站上 `outlook.exe` 作为父进程生成了带 Base64 编码命令的 `powershell.exe` 子进程。

**方法**：
1. 解码 Base64 载荷以确定命令意图
2. 检查父进程链是否有异常（Outlook 生成 PowerShell 属异常行为）
3. 在 VirusTotal 查询已解码载荷的哈希
4. 与邮件网关日志关联，识别触发邮件和发件人
5. 检查组织内其他收件人是否收到相同邮件
6. 隔离端点并携带完整分类上下文升级至二级

**注意事项**：
- 未解码载荷就将编码 PowerShell 误判为误报
- 未检查同一钓鱼邮件的其他收件人是否已受感染
- 捕获易失性内存证据前就修复端点

## 输出格式

```
事件分类报告
======================
工单：          INC-[YYYY]-[NNNN]
日期/时间：     [ISO 8601 时间戳]
分类分析员：    [姓名]
分类耗时：      [从告警到分类的分钟数]

分类
类型：          [NIST 类别]
严重性：        [P1-P4] - [严重/高/中/低]
置信度：        [高/中/低]
MITRE ATT&CK：  [技术 ID 和名称]

受影响范围
资产：          [主机名、IP]
用户：          [账号]
数据风险：      [分类级别]
业务单元：      [部门]

证据摘要
[关键观察项目列表]

丰富化结果
TI 匹配：       [是/否 - 详情]
历史记录：      [相关历史事件]
资产重要性：    [评级]

建议行动
1. [立即行动]
2. [调查步骤]
3. [升级目标]

升级
路由至：        [团队/个人]
SLA 目标：      [遏制截止时间]
```