soc-operations

Name: soc-operations
Author: briiirussell

111installs36forks

How to install soc-operations?

briiirussell/cybersecurity-skills/soc-operations

$npx -y skills add briiirussell/cybersecurity-skills --skill soc-operations

Installs into the current project.

Summary

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,

Files · 1

View on GitHub

SKILL.md

1	# SOC Operations — Building and Running a Security Operations Center
2
3	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.
4
5	Three modes:
6	- Build — designing a SOC from scratch (small org standing up its first IR capability, or MSSP onboarding)
7	- Run — daily operations for an existing SOC
8	- Improve — analyzing an existing SOC's metrics and fixing the broken parts
9
10	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).
11
12	## Mode 1 — Build a SOC
13
14	### Decision: in-house, MSSP, or hybrid?
15
16	\| Model \| When it fits \| Pitfalls \|
17	\|---\|---\|---\|
18	\| Fully in-house \| Mature security org, ≥ 5 dedicated analysts, regulated industry \| Hard to staff 24/7 with under 8 people; on-call burnout \|
19	\| Fully outsourced (MSSP) \| Smaller orgs, regulated requirements without internal staffing \| MSSP context drift — they don't know your business; alert tuning slow \|
20	\| 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 \|
21
22	### Staffing model
23
24	For 24/7 in-house coverage, the math:
25
26	- 24 × 7 = 168 hours per week of coverage needed
27	- One analyst at 40 hours/week (= 160 hr/yr × 50 weeks ≈ 8000 hr/yr - PTO - training ≈ 1700 productive hours)
28	- Minimum 5 analysts for true 24/7 if no overlap; realistic minimum 6–7 to handle PTO and burnout
29	- Below 6 — consider MSSP for off-hours coverage; the burnout cost of "always on" is real
30
31	### Analyst tiering
32
33	Standard tier model (adjust to taste):
34
35	- Tier 1 — Triage: initial alert review. Closes false positives with notes. Escalates real findings to Tier 2. Typically follows runbooks; deviates with documentation.
36	- 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.
37	- 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.
38
39	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.
40
41	### Tools you actually need
42
43	- SIEM for log aggregation and alerting (see `siem-detection`)
44	- Case management — ServiceNow / Jira Security / TheHive / Tines workflow. Tickets, not Slack threads. Slack is for chatter; the audit trail is in the ticket
45	- SOAR for playbook automation — Tines, Torq, Cortex XSOAR, Splunk SOAR. Only worth it after you have stable runbooks worth automating
46	- EDR / NDR consoles the analyst can pivot into during triage
47	- Asset inventory the analyst can look up — Snipe-IT, ServiceNow CMDB, Axonius
48	- Documentation — a wiki where runbooks live (Notion / Confluence / GitBook). Not Slack DMs
49
50	## Mode 2 — Run the SOC
51
52	### Alert prioritization
53
54	When ten alerts land in five minutes, what's the order?
55
56	The default ranking (tweak per environment):
57
58	1. Critical — confirmed compromise indicator (known-bad hash, C2 callback, ransomware behavior, data egress to known-bad infrastructure)
59	2. High — credential-access patterns (LSASS dump, ticket forging), privileged-account unusual behavior, security-control disablement (EDR removed, audit log stopped)
60	3. Medium — persistence indicators (new scheduled task, registry run key), discovery commands by service accounts, MFA failures spike
61	4. Low — single-event anomalies, behavioral outliers without context
62	5. Informational — context-rich events for correlation later, not actionable alone
63
64	Critical and High should never wait. Medium triages within shift (≤ 8 hours). Low and Info batched.
65
66	### Runbook authoring
67
68	Every alert that fires more than 2-3 times needs a runbook. Without one, every analyst re-derives the response and quality varies.
69
70	Runbook s

People who liked this also viewed

6 picks

Type

soc-operations

111installs36forks

View on GitHub

How to install soc-operations?

briiirussell/cybersecurity-skills/soc-operations

$npx -y skills add briiirussell/cybersecurity-skills --skill soc-operations

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SOC Operations — Building and Running a Security Operations Center
2
3	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.
4
5	Three modes:
6	- Build — designing a SOC from scratch (small org standing up its first IR capability, or MSSP onboarding)
7	- Run — daily operations for an existing SOC
8	- Improve — analyzing an existing SOC's metrics and fixing the broken parts
9
10	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).
11
12	## Mode 1 — Build a SOC
13
14	### Decision: in-house, MSSP, or hybrid?
15
16	\| Model \| When it fits \| Pitfalls \|
17	\|---\|---\|---\|
18	\| Fully in-house \| Mature security org, ≥ 5 dedicated analysts, regulated industry \| Hard to staff 24/7 with under 8 people; on-call burnout \|
19	\| Fully outsourced (MSSP) \| Smaller orgs, regulated requirements without internal staffing \| MSSP context drift — they don't know your business; alert tuning slow \|
20	\| 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 \|
21
22	### Staffing model
23
24	For 24/7 in-house coverage, the math:
25
26	- 24 × 7 = 168 hours per week of coverage needed
27	- One analyst at 40 hours/week (= 160 hr/yr × 50 weeks ≈ 8000 hr/yr - PTO - training ≈ 1700 productive hours)
28	- Minimum 5 analysts for true 24/7 if no overlap; realistic minimum 6–7 to handle PTO and burnout
29	- Below 6 — consider MSSP for off-hours coverage; the burnout cost of "always on" is real
30
31	### Analyst tiering
32
33	Standard tier model (adjust to taste):
34
35	- Tier 1 — Triage: initial alert review. Closes false positives with notes. Escalates real findings to Tier 2. Typically follows runbooks; deviates with documentation.
36	- 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.
37	- 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.
38
39	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.
40
41	### Tools you actually need
42
43	- SIEM for log aggregation and alerting (see `siem-detection`)
44	- Case management — ServiceNow / Jira Security / TheHive / Tines workflow. Tickets, not Slack threads. Slack is for chatter; the audit trail is in the ticket
45	- SOAR for playbook automation — Tines, Torq, Cortex XSOAR, Splunk SOAR. Only worth it after you have stable runbooks worth automating
46	- EDR / NDR consoles the analyst can pivot into during triage
47	- Asset inventory the analyst can look up — Snipe-IT, ServiceNow CMDB, Axonius
48	- Documentation — a wiki where runbooks live (Notion / Confluence / GitBook). Not Slack DMs
49
50	## Mode 2 — Run the SOC
51
52	### Alert prioritization
53
54	When ten alerts land in five minutes, what's the order?
55
56	The default ranking (tweak per environment):
57
58	1. Critical — confirmed compromise indicator (known-bad hash, C2 callback, ransomware behavior, data egress to known-bad infrastructure)
59	2. High — credential-access patterns (LSASS dump, ticket forging), privileged-account unusual behavior, security-control disablement (EDR removed, audit log stopped)
60	3. Medium — persistence indicators (new scheduled task, registry run key), discovery commands by service accounts, MFA failures spike
61	4. Low — single-event anomalies, behavioral outliers without context
62	5. Informational — context-rich events for correlation later, not actionable alone
63
64	Critical and High should never wait. Medium triages within shift (≤ 8 hours). Low and Info batched.
65
66	### Runbook authoring
67
68	Every alert that fires more than 2-3 times needs a runbook. Without one, every analyst re-derives the response and quality varies.
69
70	Runbook s

People who liked this also viewed

6 picks

Type