/soc-operations

name: soc-operations
description: "Build, run, and improve a Security Operations Center — alert prioritization, runbook authoring, escalation criteria, on-call structure, alert tuning workflow, MTTD / MTTR / fidelity KPIs, analyst tiering, and shift handoffs. Use when the user mentions 'SOC,' 'security operations,' 'SOC analyst,' 'alert triage workflow,' 'runbook,' 'escalation,' 'on-call,' 'SOC tiering,' 'tier 1 / tier 2,' 'MTTD,' 'MTTR,' 'alert fatigue,' 'alert tuning,' 'shift handoff,' 'SOAR,' or wants to design or improve a security operations team."
allowed-tools: Read, Write, Grep, Glob, WebSearch

SOC Operations — Building and Running a Security Operations Center

The operations layer above `siem-detection` (engineering rules) and `incident-triage` (response). This skill is about the *people and process* of running 24/7 alert triage — alert prioritization, runbook authoring, escalation, on-call hygiene, MTTD / MTTR, and the slow drift toward alert fatigue that kills SOCs.

Three modes:

• **Build** — designing a SOC from scratch (small org standing up its first IR capability, or MSSP onboarding)
• **Run** — daily operations for an existing SOC
• **Improve** — analyzing an existing SOC's metrics and fixing the broken parts

Cross-references: `siem-detection` (the rules that feed alerts to the SOC), `incident-triage` (the playbook for confirmed incidents), `threat-hunting` (proactive work between alert triage), `breach-patterns` (what attacks the SOC should be ready for).

Mode 1 — Build a SOC

Decision: in-house, MSSP, or hybrid?

| Model | When it fits | Pitfalls | |---|---|---| | Fully in-house | Mature security org, ≥ 5 dedicated analysts, regulated industry | Hard to staff 24/7 with under 8 people; on-call burnout | | Fully outsourced (MSSP) | Smaller orgs, regulated requirements without internal staffing | MSSP context drift — they don't know your business; alert tuning slow | | Hybrid (MSSP Tier 1, in-house Tier 2+) | Most common for growth-stage companies | Handoff complexity, "MSSP filtered it but didn't tell us" gaps |

Staffing model

For 24/7 in-house coverage, the math:

• 24 × 7 = 168 hours per week of coverage needed
• One analyst at 40 hours/week (= 160 hr/yr × 50 weeks ≈ 8000 hr/yr - PTO - training ≈ 1700 productive hours)
• Minimum 5 analysts for true 24/7 if no overlap; realistic minimum 6–7 to handle PTO and burnout
• Below 6 — consider MSSP for off-hours coverage; the burnout cost of "always on" is real

Analyst tiering

Standard tier model (adjust to taste):

• **Tier 1 — Triage:** initial alert review. Closes false positives with notes. Escalates real findings to Tier 2. Typically follows runbooks; deviates with documentation.
• **Tier 2 — Investigation:** deeper analysis on escalations. Pivots across data sources, correlates events, decides "incident" vs "noise." Authors new runbooks for patterns Tier 1 should handle next time.
• **Tier 3 — Engineering & response:** detection engineering (see `siem-detection`), threat hunting (see `threat-hunting`), incident response leadership (see `incident-triage`). Senior, expensive, the ones building the SOC's capability.

For small SOCs (≤ 4 analysts), the tiers collapse — every analyst does T1+T2 work, T3 is part-time or contracted. Don't pretend you have tiers if you don't.

Tools you actually need

• **SIEM** for log aggregation and alerting (see `siem-detection`)
• **Case management** — ServiceNow / Jira Security / TheHive / Tines workflow. Tickets, not Slack threads. Slack is for chatter; the audit trail is in the ticket
• **SOAR** for playbook automation — Tines, Torq, Cortex XSOAR, Splunk SOAR. Only worth it after you have stable runbooks worth automating
• **EDR / NDR consoles** the analyst can pivot into during triage
• **Asset inventory** the analyst can look up — Snipe-IT, ServiceNow CMDB, Axonius
• **Documentation** — a wiki where runbooks live (Notion / Confluence / GitBook). Not Slack DMs

Mode 2 — Run the SOC

Alert prioritization

When ten alerts land in five minutes, what's the order?

The default ranking (tweak per environment):

1. **Critical** — confirmed compromise indicator (known-bad hash, C2 callback, ransomware behavior, data egress to known-bad infrastructure) 2. **High** — credential-access patterns (LSASS dump, ticket forging), privileged-account unusual behavior, security-control disablement (EDR removed, audit log stopped) 3. **Medium** — persistence indicators (new scheduled task, registry run key), discovery commands by service accounts, MFA failures spike 4. **Low** — single-event anomalies, behavioral outliers without context 5. **Informational** — context-rich events for correlation later, not actionable alone

Critical and High should never wait. Medium triages within shift (≤ 8 hours). Low and Info batched.

Runbook authoring

Every alert that fires more than 2-3 times needs a runbook. Without one, every analyst re-derives the response and quality varies.

Runbook structure:

# 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]

Runbooks live in version control or a versioned wiki — not in Slack DMs, not in individual analyst notes.

Escalation criteria

Escalation rules should be explicit, not "use your