Chapter 2 — Security operations and blue team: current practice
Lesson map
Lesson 02 published. Map, example, EX006.
flowchart TD
N0["Learning outcomes"]
N1["2.1 The modern SOC"]
N2["2.2 Detection engineering"]
N3["2.3 Alert overload"]
N4["2.4 Managed detection and response"]
N5["2.5 Maturity assessment"]
N6["2.6 Regulation"]
N7["2.7 Comparing with peers"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX006"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 The modern SOC"]
N2["2.2 Detection engineering"]
N3["2.3 Alert overload"]
N4["2.4 Managed detection and response"]
N5["2.5 Maturity assessment"]
N6["2.6 Regulation"]
N7["2.7 Comparing with peers"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]
[Learning outcomes]
|
v
[2.1 The modern SOC]
|
v
[2.2 Detection engineering]
|
v
[2.3 Alert overload]
|
v
[2.4 Managed detection and response]
|
v
[2.5 Maturity assessment]
|
v
[2.6 Regulation]
|
v
[2.7 Comparing with peers]
|
v
[Worked example] --> [Exercise EX006]
Learning outcomes
You will (1) survey current SOC practice and its tensions; (2) relate practice to published frameworks and studies; (3) assess one's own SOC against peers; (4) identify practices worth adopting.
2.1 The modern SOC
Current SOCs combine SIEM or data platforms, endpoint detection, identity analytics, case management and automation. Many use managed services for some hours or functions. Knerler, Parker and Zimmerman (2022) describe eleven strategies covering mission, authority, structure, staffing, response, intelligence, data, tools, communication, measurement and expansion. Meridian's SOC uses most of these components but staffs only daytime hours, which the contractor incident exposed. The eleven strategies give Daniel a checklist for comparing Meridian with others in the sector, and later for choosing among night-coverage options.
2.2 Detection engineering
Detections are increasingly managed as code in shared formats such as Sigma, mapped to MITRE ATT&CK and tested before release. This shifts SOCs from buying content to engineering it. At Meridian, the claims-export rule that fired on the contractor account is now kept in version control with a Sigma description and a mapping to ATT&CK, and every change is tested on stored alerts before release. That practice lets Daniel show the board which techniques his team covers and which it does not, and it is what makes tested coverage measurable later. Rules bought from vendors are reviewed in the same way before they are switched on.
2.3 Alert overload
Studies continue to report alert fatigue and benign triggers (Alahmadi et al., 2022). Automation and better context are common responses, with mixed results. Meridian's own alert queue shows the pattern: many claims-access flags turn out to be benign triggers caused by project work, like the handler assigned 900 legacy claims. Daniel's response combines better context, such as assignment data as enrichment, with automation only where the decision is simple. His later critique of the Alahmadi paper led him to separate benign triggers from false positives in closure codes, so the two can be counted apart.
2.4 Managed detection and response
Outsourcing night or tier-1 work gives coverage but risks losing local knowledge. Contracts need clear escalation, data access and quality measures. For Meridian, this risk shaped the choice of a hybrid night model rather than full outsourcing. The managed provider handles tier-1 triage, while escalation goes to Meridian's own on-call engineers who know the claims system and the contractors. The contract names escalation targets, data access and quality reviews, and the first night P1 tested the runbook. Gaps in the provider's escalation notes were fixed in the runbook template rather than left to goodwill.
2.5 Maturity assessment
The SOC-CMM (van Os, 2016) lets SOCs self-assess across business, people, process, technology and services. Meridian's last assessment showed strong tooling but weak service definitions. The weak service definitions found by the assessment led directly to Daniel's service catalogue, which lists what the SOC provides to each business unit with scope and service levels. Meridian's next assessment will show whether the catalogue closed that gap. Using the same model each time keeps the comparison fair across years and gives the board a familiar format for progress. Daniel files the assessment evidence so the next assessor can check it.
2.6 Regulation
Health insurers face data protection and sector regulation; incident reporting timelines shape SOC procedures. For Meridian, the contractor export was a possible disclosure of health data, so legal and the data protection officer had to be informed quickly and the time of awareness recorded. Procedures name who decides whether a case is notifiable and how the SOC supports that decision with facts. The partner breach later in the book followed the same path, and the business request to delay notification was refused because these duties do not bend to a product launch.
2.7 Comparing with peers
Daniel joins a sector forum where SOC leads share anonymised practices and metrics. The forum's comparisons are anonymised, so Daniel learns from patterns rather than from named companies. It was through the forum that he noticed two peers had service catalogues while Meridian did not, which became one of his first improvements. He shares Meridian's own figures on the same basis, after checking with the CISO what may be disclosed. The forum also gives him peers to ask when a decision has no clear precedent at Meridian.
Threat-informed defence
Many SOCs now prioritise work by the techniques their likely adversaries use, drawn from intelligence and ATT&CK, rather than by what tools happen to alert on. This keeps detection effort tied to real risk.
Worked example
Daniel compares Meridian with three forum peers. Two have documented service catalogues listing what the SOC provides to each business unit; Meridian does not. He drafts a catalogue: monitoring, investigation, insider-risk support, detection engineering and incident coordination, each with scope and service levels.
Synthetic case. The forum and comparisons are invented.
Errors and limits
Peer practice reflects their context; adopt practices for reasons that apply to you.
Exercises
- EX006 — Eleven strategies. Name four of the eleven SOC strategy areas. Rubric: 3 = four of mission, authority, structure, staffing, response, intelligence, data, tools, communication, measurement, expansion; 2 = three; 1 = one; 0 = none.
- EX007 — Detection as code. What shift does detection-as-code represent? Rubric: 3 = from buying content to engineering tested, versioned detections; 2 = partial; 1 = vague; 0 = none.
- EX008 — MDR risk. What is the main risk of managed detection and response? Rubric: 3 = losing local knowledge; needs escalation and quality terms; 2 = partial; 1 = cost; 0 = none.
- EX009 — Maturity gap. What did Meridian's SOC-CMM assessment reveal? Rubric: 3 = strong tooling, weak service definitions; 2 = partial; 1 = vague; 0 = none.
- EX010 — Service catalogue. What did Daniel's draft catalogue list? Rubric: 3 = monitoring, investigation, insider support, detection engineering, coordination with scope and levels; 2 = three; 1 = one; 0 = none.
Synthesis
Current practice blends engineering, automation and sourcing choices; compare with peers to find practices that fit your context.
Continue studying — chapter 02 of 12
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →