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?

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

| Condition | Escalate to | How quickly | |---|---|---| | Active data egress observed | Tier 2 / on-call | Immediately | | Privileged account behavior anomaly | Tier 2 | This shift | | Multiple correlated alerts on one host | Tier 2 | This shift | | Detection rule firing > 50× / hour with high TP rate | Tier 3 (engineering) | Next business day | | Detection rule firing > 50× / hour with 100% FP | Tier 3 (engineering) | Next business day | | Anything Tier 1 doesn't know how to handle | Tier 2 | After 30 minutes of triage |

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.

Mode 3 — Improve the SOC

KPIs that actually matter

| Metric | Definition | Target | |---|---|---| | MTTD | Mean Time To Detect — from event to alert firing | 30% for any rule; tune or kill rules below | | Alert volume per analyst per shift | Alerts per Tier 1 analyst per 8-hour shift | 80% of alert volume | | Time to runbook | New alert-type to runbook delivered | 25% / year

• "We didn't catch X" post-mortems pointing to an alert that fired but wasn't actioned

When you see these: full-stop the new-rule pipeline and spend a cycle on tuning. Adding more rules to an over-firing SOC makes things worse.

Output Format

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

Boundaries

• This skill produces operations plans, not exploitation
• Refuse to design SOC capabilities for unauthorized surveillance of employees or third parties
• Alert tuning that intentionally hides legitimate security events is a finding, not a deliverable
• Don't help build "compliance-theater" SOCs — if the org's intent is "check the box without actually detecting," push back
• Where the assessment surfaces an active incident, hand off to incident-triage — don't continue planning work mid-fire

References

• NIST SP 800-61 Rev. 3 (Computer Security Incident Handling Guide)
• "Crafting the InfoSec Playbook" — Bollinger / Enright / Valites
• "The Practice of Network Security Monitoring" — Richard Bejtlich
• "Intelligence-Driven Incident Response" — Brown / Roberts
• SANS SOC Survey (annual)
• Gartner Magic Quadrant for SIEM (rotating — use the current edition)
• ATT&CK for SOC analysts — attack.mitre.org/resources/training
• MITRE D3FEND — defensive countermeasures catalog
• "SOC Maturity Model" — various — pick one and measure against it

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: briiirussell
• Source: briiirussell/cybersecurity-skills
• License: MIT

Install and usage instructions live in the source repository linked above.