Soc Operations

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?

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 judgment." Judgment lives at Tier 3+; lower tiers need rules.

Shift handoffs

The single most preventable cause of breaches detected days late is "the night shift had something interesting and the morning shift never heard about it."

Handoff checklist (5–10 minutes per shift):

• Open cases — what's in progress, what's blocked, what's the next step
• Watch items — anything not yet a case but worth keeping eyes on
• Active tuning — rules under tuning, FP patterns being investigated
• Pages received during shift — even if resolved, the next shift should know
• Anything you decided to ignore — and why — so next shift doesn't quietly disagree without context

Write it down. Slack handoff channel, daily summary doc, ticketing system shift report — any format works as long as it's persistent and searchable.