◇ OpenCyber Academy
Master's · Chapter 2 · English

Chapter 2 — Security operations and blue team: advanced seminar

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 2 — Security operations and blue team: advanced seminar

Lesson map

Lesson 02 published. Map, example, EX008.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 What a SOC does"]
  N2["2.2 Detection engineering"]
  N3["2.3 Continuous monitoring"]
  N4["2.4 Metrics and side effects"]
  N5["2.5 Maturity models"]
  N6["2.6 Seminar format"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX008"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 What a SOC does"]
  N2["2.2 Detection engineering"]
  N3["2.3 Continuous monitoring"]
  N4["2.4 Metrics and side effects"]
  N5["2.5 Maturity models"]
  N6["2.6 Seminar format"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]

[Learning outcomes]
    |
    v
[2.1 What a SOC does]
    |
    v
[2.2 Detection engineering]
    |
    v
[2.3 Continuous monitoring]
    |
    v
[2.4 Metrics and side effects]
    |
    v
[2.5 Maturity models]
    |
    v
[2.6 Seminar format]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX008]

Learning outcomes

You will (1) discuss SOC models and functions critically; (2) relate detection engineering to frameworks; (3) debate metrics and their side effects; (4) present a seminar argument with sources.

2.1 What a SOC does

Knerler, Parker and Zimmerman (2022) describe SOC functions from monitoring and analysis to incident response, threat intelligence and expanded services such as hunting. Their first strategy, "know what you are protecting and why", anchors tuning decisions: a rule matters according to the assets it guards.

For Pelham, knowing what is protected means knowing that a rule guarding the patch-management servers matters more than one guarding meeting-room displays. That ranking affects tuning: an allow-list on a rule that watches the patching account carries more risk if it is wrong, which is exactly where Tariq's study later finds a problem.

2.2 Detection engineering

Detections are written, tested, deployed and maintained like software. MITRE ATT&CK (Strom et al., 2018) gives a shared vocabulary of adversary behaviour so coverage can be mapped; Sigma gives a portable rule format. D3FEND (Kaloroumakis and Smith, 2021) maps defensive techniques, helping teams see which countermeasure a detection belongs to.

Treating rules like software is what makes Tariq's study possible: Pelham's rules are stored in Sigma format, and allow-list entries are version-controlled with reasons, so the tuning can be described, diffed and reviewed. Mapping each of the twenty rules to an ATT&CK tactic also let him match tuned and control rules on tactic.

2.3 Continuous monitoring

NIST SP 800-137 frames monitoring as an ongoing programme tied to risk, with defined frequencies and metrics, not a set of tools.

For Tariq, this means tuning is not a project that ends in week 8. Allow-lists change what the SOC monitors, including on the rule that watches the patching account, so they belong in the monitoring programme with their own review frequency and metric. His recommendations later make this concrete: quarterly replay of allow-list entries against purple-team events, and suppressed-attack tests tracked beside volume.

2.4 Metrics and side effects

Counting closed alerts rewards speed over depth; mean time to resolve can push analysts to close uncertain cases. Kokulu et al. (2019) found such metric mismatches a frequent issue. Tariq's seminar argues that tuning studies must measure suppressed attacks alongside volume, or they reward silence.

Tariq's seminar question sharpens the point: what suppressed-attack rate would an analyst accept for a 30% volume cut? Asking it forces a team to state the trade-off before tuning rather than discover it later. Without a measure of suppressed attacks, a tuning project can only report success.

2.5 Maturity models

The SOC-CMM (van Os, 2016) assesses business, people, process, technology and services domains. It helps place tuning within process maturity rather than treating it as a one-off clean-up.

For Pelham, the SOC-CMM framing places Tariq's work in the process domain: allow-list entries need the same review, version control and periodic testing as rules. The external reviewer's later comment, that his review process assumes a mature change process, is a maturity question in exactly this sense. The model also gives Pelham a way to show progress after the study, by reassessing the process domain once quarterly replay is running.

2.6 Seminar format

Each student presents a claim, evidence, counter-evidence and a question for discussion.

The question is the part most students neglect. Tariq's question, quoted in the worked example below, forced the seminar to argue about a trade-off rather than agree that noise is bad. Presenting counter-evidence alongside his own claim also showed the examiners later that he had engaged with the strongest objection to it. Tariq's own slide named Axelsson and Kokulu et al. as evidence and Alahmadi et al. as counter-evidence, and Dr. Solberg used the question to start the discussion.

Worked example

Tariq's seminar claim: "Alert-volume reduction is a misleading success metric on its own." Evidence: Axelsson's base-rate argument and Kokulu et al. on metrics. Counter-evidence: Alahmadi et al. report that volume itself drives burnout, so reduction has value. Question: "What suppressed-attack rate would you accept for a 30% volume cut?"

Synthetic case. The seminar is invented.

Errors and limits

Frameworks change versions; cite the version used.

Exercises

Synthesis

Advanced SOC practice links detections to frameworks, assets and maturity, and judges metrics by their side effects.

Continue studying — chapter 02 of 08

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →