用途
SOC Operations 是位于 siem-detection（工程规则）和 incident-triage（响应）之上的运营层技能，关注的是运行 7×24 小时告警分诊的人员与流程：告警优先级排序、运行手册编写、升级标准、值班卫生、MTTD/MTTR，以及逐渐侵蚀 SOC 的告警疲劳问题。
该技能提供三种模式：
- Build（搭建）：从零设计 SOC（小型组织建立首个 IR 能力，或 MSSP 接入）。
- Run（运营）：现有 SOC 的日常运营。
- Improve（改进）：分析现有 SOC 的指标并修复问题环节。
交叉引用：siem-detection（向 SOC 提供告警的规则）、incident-triage（已确认事件的处置手册）、threat-hunting（告警分诊之间的主动工作）、breach-patterns（SOC 应准备好的攻击模式）。
主要能力
模式一：搭建 SOC
自建、MSSP 还是混合？
| 模式 | 适用场景 | 陷阱 |
|---|---|---|
| 完全自建 | 成熟安全组织、≥5 名专职分析师、受监管行业 | 少于 8 人难以 7×24 值班；值班倦怠 |
| 完全外包（MSSP） | 较小组织、有合规要求但无内部人员 | MSSP 缺乏业务上下文；告警调优慢 |
| 混合（MSSP 一级，内部二级以上） | 成长型公司最常见 | 交接复杂；"MSSP 过滤了但没告诉我们"的缺口 |
人员编制：7×24 内部覆盖需要每周 168 小时。一名分析师每周 40 小时（约 1700 有效小时/年）。无重叠时真正 7×24 最少需 5 名分析师，考虑休假和倦怠现实最少 6–7 名。低于 6 人可考虑用 MSSP 覆盖非工作时间。
分析师分层：
- 一级 — 分诊：初步告警审查，带备注关闭误报，将真实发现升级至二级，通常遵循运行手册。
- 二级 — 调查：对升级项深入分析，跨数据源关联，判定"事件"还是"噪音"，为一级编写新运行手册。
- 三级 — 工程与响应：检测工程、威胁狩猎、事件响应领导，资深且昂贵，负责构建 SOC 能力。
小型 SOC（≤4 名分析师）层级会合并，每人都做一级+二级工作，三级为兼职或外包。
实际需要的工具：SIEM（日志聚合与告警）、案例管理（ServiceNow / Jira Security / TheHive / Tines，用工单而非 Slack 线程）、SOAR（Tines、Torq、Cortex XSOAR、Splunk SOAR，需在运行手册稳定后才值得自动化）、EDR/NDR 控制台、资产清单（Snipe-IT、ServiceNow CMDB、Axonius）、文档 wiki（Notion / Confluence / GitBook）。
模式二：运营 SOC
告警优先级排序（默认排序，可按环境调整）：
- 严重：已确认的入侵指标（已知恶意哈希、C2 回连、勒索软件行为、向已知恶意基础设施的数据外泄）
- 高：凭据访问模式（LSASS dump、票据伪造）、特权账户异常行为、安全控制被禁用（EDR 被移除、审计日志停止）
- 中：持久化指标（新计划任务、注册表 Run 键）、服务账户的发现命令、MFA 失败激增
- 低：单事件异常、无上下文的行为离群值
- 信息：供后续关联的上下文丰富事件，单独不可操作
严重和高危绝不等待。中危在班次内分诊（≤8 小时）。低危和信息批量处理。
运行手册编写：任何触发超过 2–3 次的告警都需要运行手册。结构包括：触发条件（精确的 SIEM 规则/检测名称）、负责人、最后审查日期、快速参考（告警含义、常见误报、常见真报）、分诊步骤、误报处理、真报处理、常见关联查询。运行手册应存放在版本控制或带版本的 wiki 中，而非 Slack 私信或个人笔记。
升级标准（应明确而非"自行判断"）：
| 条件 | 升级至 | 速度 |
|---|---|---|
| 观察到活跃数据外泄 | 二级/值班 | 立即 |
| 特权账户行为异常 | 二级 | 本班次 |
| 单主机多个关联告警 | 二级 | 本班次 |
| 检测规则每小时触发 >50 次且真报率高 | 三级（工程） | 下一工作日 |
| 检测规则每小时触发 >50 次且 100% 误报 | 三级（工程） | 下一工作日 |
| 一级不知如何处理 | 二级 | 分诊 30 分钟后 |
交接班：最可预防的"数天后才发现入侵"原因是夜班有发现但早班从未听说。交接清单（每班 5–10 分钟）：进行中的案例、观察项、活跃调优、班次内收到的呼叫、决定忽略的事项及原因。需持久且可搜索。
模式三：改进 SOC
真正重要的 KPI：
| 指标 | 定义 | 目标 |
|---|---|---|
| MTTD | 平均检测时间（事件到告警触发） | 高置信规则 <5 分钟；行为类 <1 小时 |
| MTTR | 平均响应时间（告警到分诊决策） | 一级：严重 <15 分钟；中危 <4 小时 |
| MTTC | 平均遏制时间（确认事件到阻止扩散） | 确认入侵 <1 小时 |
| 每规则真报率 | 真报/总告警 | 任何规则 >30%；低于则调优或停用 |
| 每分析师每班告警量 | 一级分析师每 8 小时班次告警数 | <25，超过则疲劳主导 |
| ATT&CK 战术覆盖率 | 至少有一条检测规则的战术 | 初始访问、执行、持久化、防御规避、凭据访问力求 100% |
| 运行手册覆盖率 | 有运行手册的告警占比 | >80% 告警量 |
| 运行手册时效 | 新告警类型到手册交付 | <5 次该类型告警 |
不要测量无法行动的东西。"处理告警数"是虚荣指标。
调优循环：SOC 主要失败模式是未调优规则导致的告警疲劳。每周审查告警量最高的规则；真报率 <30% 则规则有问题，调优或停用；概念合理则调优（加过滤、提高阈值、加允许列表），概念不合理则停用；记录每次停用；跟踪调优周期——"规则 X 在 6 个月内调优 3 次"意味着规则概念错误而非参数问题。
告警疲劳诊断：一级分析师 <30 秒关闭告警、同类告警反复被忽略且无记录抑制、分析师年流失率 >25%、"我们没抓到 X"的事后复盘指向已触发但未处理的告警。出现这些时应全面停止新规则管道，花一个周期调优。
使用方式
该技能输出格式为 SOC 评估/建设计划，包含：组织名称、模式（Build/Run/Improve）、日期、当前状态（或提议）、发现（改进模式）/缺口（搭建模式）表格、建议表格（优先级/事项/负责人/时间线）、KPI 仪表盘提案、运行手册待办清单。
适用场景
- 小型组织建立首个事件响应能力
- MSSP 接入新客户
- 现有 SOC 的日常运营与交接
- 分析 SOC 指标并修复问题
- 诊断和缓解告警疲劳
限制
- 该技能产出运营计划，不涉及漏洞利用
- 拒绝为未经授权监视员工或第三方设计 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 Magic Quadrant for SIEM（轮换，使用当前版本）
- ATT&CK for SOC analysts — attack.mitre.org/resources/training
- MITRE D3FEND — 防御对策目录
- "SOC Maturity Model" — 多种版本，选一个并对照测量