soc-operations

SOC Operations — 构建和运营安全运营中心

位于 siem-detection（工程规则）和 incident-triage（响应）之上的运营层。本技能关注 7×24 小时告警分诊的 人员与流程——告警优先级排序、运行手册编写、升级、值班管理、平均检测时间（MTTD）/平均响应时间（MTTR），以及导致 SOC 陷入告警疲劳的缓慢恶化过程。

三种模式：

• 构建 — 从头设计 SOC（小型组织建立首个事件响应能力，或 MSSP 入驻）
• 运营 — 运营现有 SOC 的日常工作
• 改进 — 分析现有 SOC 的指标并修复问题

交叉引用：siem-detection（向 SOC 提供告警的规则）、incident-triage（已确认事件的应对手册）、threat-hunting（告警分诊间隙开展的主动工作）、breach-patterns（SOC 应准备应对的攻击）、log-watch（小型团队尚无 SIEM、也无 SOC 时的起点——本技能将帮助他们进阶）。

授权

为用户自己的组织或聘请用户提供服务的客户设计并改进安全运营。运行手册和监控设计涵盖组织拥有的系统和账户，并遵守 HR、法律及当地法律对员工监控的规定。升级和轮班值守方面的调整均为提案，须由 SOC 负责人批准。

模式 1 — 构建 SOC

决策：内部建设、MSSP，还是混合模式？

模式	适用场景	隐患
完全内部建设	安全组织成熟、拥有 ≥ 5 名专职分析师、受监管行业	少于 8 人难以提供 7×24 小时值守；值班导致倦怠
完全外包（MSSP）	规模较小的组织，或有合规要求但内部人员不足	MSSP 对业务背景了解不足，导致上下文偏移；告警调优缓慢
混合模式（MSSP 负责 Tier 1，内部负责 Tier 2 及以上）	成长期公司最常见	交接复杂；存在“MSSP 筛选了告警却没通知我们”的漏洞

人员配置模式

内部提供 7×24 小时值守的计算方式：

• 每周需要 24 × 7 = 168 小时的覆盖时间
• 一名分析师每周工作 40 小时（= 每年 160 小时 × 50 周 ≈ 8000 小时/年 - 带薪休假 - 培训 ≈ 1700 小时有效工作时间）
• 若没有重叠值守，真正实现 7×24 小时覆盖至少需要 5 名分析师；考虑带薪休假和倦怠，实际最低人数为 6–7 人
• 少于 6 人时，考虑由 MSSP 提供非工作时间的覆盖；“永远在线”带来的倦怠成本不容忽视

分析师分级

标准分级模式（可按需调整）：

• Tier 1 — 分诊： 初步审核告警。记录备注并关闭误报。将真实发现升级给 Tier 2。通常遵循运行手册；如有偏离，需做好记录。
• Tier 2 — 调查： 深入分析升级上来的问题。切换多个数据源进行调查、关联事件，并判断是“事件”还是“噪声”。为 Tier 1 下次应对类似情况编写新运行手册。
• Tier 3 — 工程与响应： 检测工程（参见 siem-detection）、威胁狩猎（参见 threat-hunting）、事件响应领导（参见 incident-triage）。他们资深、成本高，负责构建 SOC 的能力。

对于小型 SOC（≤ 4 名分析师），各级职责会合并——每名分析师都承担 T1 和 T2 工作，T3 则由兼职人员或外部承包人员负责。如果没有真正的分级，就不要假装存在分级。

实际需要的工具

• SIEM，用于日志聚合和告警（参见 siem-detection）
• 案例管理 — ServiceNow / Jira Security / TheHive / Tines 工作流。用工单，不要用 Slack 讨论串。Slack 用于交流；审计跟踪记录在工单中
• SOAR，用于自动化运行手册 — Tines、Torq、Cortex XSOAR、Splunk SOAR。只有在已有稳定且值得自动化的运行手册后才值得采用
• EDR / NDR 控制台，供分析师在分诊期间切换查看
• 资产清单，供分析师查询 — Snipe-IT、ServiceNow CMDB、Axonius
• 文档 — 存放运行手册的 Wiki（Notion / Confluence / GitBook）。不要放在 Slack 私信中

模式 2 — 运营 SOC

告警优先级

五分钟内收到十条告警时，应该按什么顺序处理？

默认排序（可根据环境调整）：

1. 严重 — 已确认的入侵指标（已知恶意哈希、C2 回连、勒索软件行为、向已知恶意基础设施传出数据）
2. 高 — 凭证访问模式（LSASS 转储、伪造票据）、特权账户的异常行为、安全控制被禁用（EDR 被移除、审计日志停止记录）
3. 中 — 持久化指标（新建计划任务、注册表 Run 键）、服务账户执行发现命令、MFA 失败次数激增
4. 低 — 单一事件异常、缺乏上下文的行为异常
5. 信息 — 上下文丰富、供后续关联分析的事件，单独来看不可采取行动

严重和高优先级告警绝不能延后处理。中优先级告警应在当班期间完成分流（≤ 8 小时）。低优先级和信息类告警可批量处理。

编写运行手册

每条触发超过 2-3 次的告警都需要运行手册。没有运行手册，每位分析师都得重新推导响应方式，导致处理质量参差不齐。

运行手册结构：

# Runbook: [Alert name]
## Trigger: [exact SIEM rule / detection name]
## Owner: [team / person]
## Last reviewed: [date]

## Quick reference
- **What the alert means in plain English:** [one sentence]
- **Common false positives:** [list, with how to recognize]
- **Common true positives:** [list, with what to look for next]

## Triage steps
1. [Step 1 — specific query / action]
2. [Step 2]
3. [Decision point — true positive / false positive / escalate]

## False positive handling
- [How to close + what to document]
- [Whether to add to suppression list]

## True positive handling
- [Immediate containment if any]
- [Escalation to whom, with what info]
- [Link to incident-triage skill for full IR]

## Common pivots
- [Other data sources to check]
- [Other systems likely affected]

运行手册应保存在版本控制系统或带版本管理的 Wiki 中，而不是 Slack 私信或分析师个人笔记里。

升级标准

升级规则应明确，不能只说“自行判断”。判断空间应留给 Tier 3 及以上人员；较低层级需要明确规则。

条件	升级至	时限
观察到正在发生的数据外传	Tier 2 / 值班人员	立即
特权账户行为异常	Tier 2	当班期间
同一主机上出现多条相关告警	Tier 2	当班期间
检测规则每小时触发 > 50×，且 TP 率较高	Tier 3（工程团队）	下一个工作日
检测规则每小时触发 > 50×，且 FP 率为 100%	Tier 3（工程团队）	下一个工作日
Tier 1 不知道如何处理的任何情况	Tier 2	分流 30 分钟后

交接班

导致泄露事件被延迟数天才发现、且最容易预防的原因，就是“夜班发现了一些值得关注的情况，但早班从未收到消息”。

交接清单（每班 5–10 分钟）：

• 未结案例 — 正在处理什么、哪些事项受阻、下一步是什么
• 关注事项 — 尚未成为案例，但值得持续关注的事项
• 正在调优的规则 — 正在调优的规则，以及正在调查的 FP 模式
• 当班期间收到的页面通知 — 即使已经解决，下一班也应知晓
• 决定忽略的任何事项 — 以及原因，避免下一班在不了解上下文时默默持不同意见

记下来。可以使用 Slack 交接频道、每日摘要文档、工单系统的交班报告——任何格式都可以，只要内容持久保存且可搜索。

模式 3 — 改进 SOC

真正重要的 KPI

指标	定义	目标
MTTD	平均检测时间 — 从事件发生到告警触发	高置信度规则 < 5 分钟；行为检测 < 1 小时
MTTR	平均响应时间 — 从告警触发到完成分流决策	Tier 1：严重告警 < 15 分钟；中优先级告警 < 4 小时
MTTC	平均遏制时间 — 从确认事件到阻止扩散	已确认的入侵 < 1 小时（行业 P50 约为 6 天；目标应更高）
每条规则的 TP 率	真阳性数 / 告警总数	每条规则都应 > 30%；低于此值的规则应调优或停用
每位分析师每班的告警量	每位 Tier 1 分析师每个 8 小时班次处理的告警数	< 25 — 超出后，告警疲劳将占主导
ATT&CK 战术覆盖率	至少有一条检测规则覆盖的战术	目标是覆盖 100% 的初始访问、执行、持久化、防御规避、凭证访问
运行手册覆盖率	有运行手册的告警所占比例	覆盖 > 80% 的告警量
编写运行手册所需时间	从出现新告警类型到交付运行手册所需的告警数	< 5 条同类型新告警

不要衡量无法据此采取行动的指标。“处理的告警数量”是虚荣指标——规则噪声越大，这个数字就越高。

调优循环

未调优规则导致的告警疲劳，是 SOC 最主要的失效模式。防止这种情况的循环如下：

1. 每周： 按告警量审查排名前 N 的规则
2. 对于每条高告警量规则： 真阳性率是多少？如果低于 30%，说明规则有问题——进行调优或停用
3. 停用还是调优： 如果规则背后的概念合理，就进行调优（添加筛选条件、提高阈值、添加允许列表）；如果概念不合理（在你的环境中属于正常现象的异常），就停用
4. 记录每次停用——未来的工程师会想知道规则为何被移除
5. 跟踪调优周期——“规则 X 在 6 个月内调优了 3 次”说明规则概念有问题，而非参数有问题

有关工程层面的内容，请参阅 siem-detection 的调优部分；这里讲的是运营层面。

告警疲劳诊断

以下迹象表明 SOC 正受到告警疲劳影响：

• 一级分析师在不到 30 秒内关闭告警（并未调查，只是在点击处理）
• 反复忽略相同类型的告警，却没有记录抑制原因
• 分析师离职率超过每年 25%
• 事后复盘中出现“我们没能发现 X”，且问题指向已触发但未采取行动的告警

出现这些情况时：立即暂停新增规则流程，并用一个周期进行调优。向告警过多的 SOC 添加更多规则只会让情况恶化。

输出格式

# SOC Assessment / Build Plan
## Organization: [name]
## Mode: Build / Run / Improve
## Date: [date]

### Current state (or proposed)
- Coverage hours, staffing model
- Tier structure
- Tools in use
- Alert volume / day
- Key metrics — MTTD, MTTR, TP rate distribution

### Findings (Improve mode) / Gaps (Build mode)
| Category | Issue / Gap | Severity |
|----------|-------------|----------|

### Recommendations
| Priority | Item | Owner | Timeline |
|----------|------|-------|----------|

### KPI dashboard proposal
[What to measure, how to source it, target thresholds]

### Runbook backlog
[Alert types that lack runbooks, ranked by volume]

边界

• 此技能用于制定运营计划，而非进行漏洞利用
• 拒绝为未经授权监控员工或第三方设计 SOC 能力
• 故意隐藏合法安全事件的告警调优，应作为发现的问题，而非交付成果
• 不要帮助构建“做样子”的 SOC——如果组织的意图是“只走过场，实际上不进行检测”，应提出异议
• 如果评估发现正在发生的事件，应移交给 incident-triage——不要在事件处理中继续规划工作

参考资料

• NIST SP 800-61 Rev. 3（计算机安全事件处理指南）
• 《Crafting the InfoSec Playbook》——Bollinger / Enright / Valites
• 《The Practice of Network Security Monitoring》——Richard Bejtlich
• 《Intelligence-Driven Incident Response》——Brown / Roberts
• SANS SOC Survey（年度）
• Gartner SIEM 魔力象限（定期更新——请使用当前版本）
• 面向 SOC 分析师的 ATT&CK——attack.mitre.org/resources/training
• MITRE D3FEND——防御性对策目录
• 《SOC Maturity Model》——多种版本——选择一种并据此衡量