Chapter 20 — Security operations and blue team: foundational cases
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Learning from cases"]
N2["20.2 Riverton's campaign"]
N3["20.3 Synthetic ransomware exercise"]
N4["20.4 Published studies"]
N5["20.5 Decision points"]
N6["20.6 Generalising"]
N7["Using cases in training"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Learning from cases"]
N2["20.2 Riverton's campaign"]
N3["20.3 Synthetic ransomware exercise"]
N4["20.4 Published studies"]
N5["20.5 Decision points"]
N6["20.6 Generalising"]
N7["Using cases in training"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Learning from cases]
|
v
[20.2 Riverton's campaign]
|
v
[20.3 Synthetic ransomware exercise]
|
v
[20.4 Published studies]
|
v
[20.5 Decision points]
|
v
[20.6 Generalising]
|
v
[Using cases in training]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) analyse published and synthetic SOC cases; (2) identify detection, triage and response decisions in each; (3) extract lessons that generalise; (4) compare cases with Riverton's campaign.
20.1 Learning from cases
Cases show how principles play out under pressure. Lucas studies three: Riverton's phishing campaign, a synthetic ransomware case from a teaching exercise, and the findings of published SOC studies.
Each case adds something the others lack. The phishing campaign has real timings and decisions from Riverton's own systems. The ransomware exercise covers a kind of attack Riverton has not suffered. The published studies show patterns across many SOCs, which helps Lucas judge whether Riverton's experience is typical or unusual. Using all three guards against generalising from one event.
20.2 Riverton's campaign
Detection came first from user reports, then from the z-score flag on s2047. Containment took about six hours for s2047 because the flag ran only in a morning batch.
The batch timing explains most of that delay: the account began sending at about 02:30, but the check that flagged it did not run until 07:00. Earlier user reports pointed to the campaign but not to which account had been compromised. The lesson Lucas draws is that detection speed depends on schedule as much as on rule quality.
20.3 Synthetic ransomware exercise
In the course's tabletop exercise, a file server's files are encrypted. Detection comes from users reporting unreadable files; response hinges on isolating the server and restoring from backups. The exercise shows that tested backups decide recovery time.
In the exercise, the team discovered that the most recent backup restore test had been a year earlier, and nobody knew how long a full restore would take. Participants estimated anywhere from four hours to two days. The exercise led to a scheduled restore test, which is cheaper to learn from than a real outage.
20.4 Published studies
Alahmadi et al. (2022) describe analysts overwhelmed by benign triggers; Kokulu et al. (2019) describe mismatched SOC priorities between managers and analysts. Both explain why Riverton's student analysts sometimes ignore low-severity alerts.
At Riverton, low-severity alerts such as antivirus quarantines on student laptops are numerous and almost always harmless. Students learn to skim them, which is the overload these studies describe. The risk is that a rare important one is skimmed too, so the triage lab teaches ordering by score and judgement rather than by habit.
20.5 Decision points
In each case Lucas lists decision points: when to escalate, when to contain, whom to inform. Delays often come from unclear authority, not missing tools.
In the phishing campaign, the key decision was whether to wake the on-call engineer when early reports arrived overnight. Nobody was sure who could make that call, so nobody did. The improvement was not a new tool but a written rule naming who decides and on what evidence, which the student analysts could follow without hesitation.
20.6 Generalising
Lessons that recur — user reports matter, batch detection is slow, unclear authority delays action — are candidates for SOC improvement.
Lucas checks each lesson against the cases before recommending a change. User reports mattered in both the phishing and ransomware cases. Batch detection mattered only in phishing, so the evidence is narrower, but the timings were measured precisely. Unclear authority appeared in both and in the published studies, which makes it the strongest candidate. Lucas ranks the lessons by how much evidence supports each, and presents that ranking to Dr. Kim with the cases listed beside every lesson.
20.7 Limits
Cases are selected and simplified; they illustrate, they do not prove.
The ransomware exercise left out the stress of a real outage, angry users and incomplete information; the phishing case was written up after the fact, when the right answers were known. Lucas uses the cases to suggest what to look at, and the measured improvements in later chapters to check whether each change actually helped. A lesson drawn from a case is a hypothesis about Riverton's SOC, and it stays one until the measurements in later chapters confirm or reject it. Lucas marks each lesson in his notes with its status.
Using cases in training
New student analysts read the case write-ups in their first week, with names removed, and discuss what they would have done at each decision point.
Worked example
Lucas's comparison table shows that in both the phishing and ransomware cases, the first signal came from people, not tools. He recommends making user reporting faster (a report button in mail) and running the z-score check hourly rather than daily.
Synthetic case. Cases are invented except the cited studies.
Errors and limits
Synthetic exercises may miss real-world friction.
Exercises
- EX058 — Containment delay. Why did s2047's containment take about six hours? Rubric: 3 = z-score check ran in morning batch; 2 = partial; 1 = unknown; 0 = none.
- EX059 — Recurring lesson. What lesson recurred across cases? Rubric: 3 = first signal from people, not tools; 2 = partial; 1 = vague; 0 = none.
- EX060 — Delay source. What often causes response delays according to Lucas's analysis? Rubric: 3 = unclear authority rather than missing tools; 2 = partial; 1 = tools; 0 = none.
Synthesis
Cases reveal recurring decision points and delays; their lessons guide improvements when generalised carefully.
Continue studying — chapter 20 of 40
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →