Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 The kill chain paper"]
N2["20.2 Group reporting"]
N3["20.3 Ransomware against health"]
N4["20.4 Supply chain"]
N5["20.5 Reading cases ethically"]
N6["20.6 Comparing cases"]
N7["From case to local question"]
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 The kill chain paper"]
N2["20.2 Group reporting"]
N3["20.3 Ransomware against health"]
N4["20.4 Supply chain"]
N5["20.5 Reading cases ethically"]
N6["20.6 Comparing cases"]
N7["From case to local question"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 The kill chain paper]
|
v
[20.2 Group reporting]
|
v
[20.3 Ransomware against health]
|
v
[20.4 Supply chain]
|
v
[20.5 Reading cases ethically]
|
v
[20.6 Comparing cases]
|
v
[From case to local question]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) analyse published cases that shaped CTI practice; (2) extract lessons without repeating attack details; (3) compare cases using models; (4) relate lessons to HCHT.
20.1 The kill chain paper
Hutchins et al. described defenders tracking a persistent adversary across repeated intrusions, using indicators from earlier phases to block later attempts. The lesson: intelligence from one intrusion protects against the next, and defenders gain when they analyse failed attempts too.
Amara applies this at HCHT by recording blocked phishing attempts with the same care as successful ones. Patterns in failed attempts, such as the same sender infrastructure, often appear before an attack succeeds. She also notes which phase each attempt reached.
20.2 Group reporting
Public reporting on long-running groups, catalogued in ATT&CK group entries such as G0016 (APT29), showed that adversaries reuse techniques more stably than infrastructure. The lesson: behavioural detection outlasts indicator lists.
Amara uses this lesson when deciding how to spend the team's limited time: a detection for a technique seen across many sector reports is worth more effort than updating a long list of addresses that may change next week. Indicators still matter for quick blocks, but they are expected to age, while behavioural detections are reviewed less often and remain useful for longer.
20.3 Ransomware against health
Many public advisories describe ransomware disrupting hospitals. Common lessons: phishing or exposed services as entry, valid-account abuse, encryption for impact (T1486), and the decisive role of tested, isolated backups.
Amara reads several public advisories and lists the recurring lessons in a short table for HCHT's infrastructure team. The table supports their request for funds to isolate backups and test restores more often. It cites each advisory, so the evidence can be checked and updated when new advisories appear, and it notes which lessons HCHT has already acted on.
20.4 Supply chain
Compromises of trusted software updates (Supply Chain Compromise, T1195) showed that trusted channels can deliver malicious code. The lesson for HCHT: supplier intelligence and update monitoring matter.
HCHT relies on many suppliers for clinical and administrative software, and some push updates automatically. Amara helps compile a list of those suppliers and the systems they update, so that intelligence about a supplier compromise can be checked against it in minutes. The infrastructure team adds monitoring for unexpected changes after updates on the most critical systems, and the list is reviewed every quarter.
20.5 Reading cases ethically
Case studies teach patterns; reproducing malware or step-by-step procedures is unnecessary and inappropriate in coursework.
Amara's coursework describes cases at the level of techniques and lessons, citing public sources. She does not download samples or repeat attack steps, even in a lab, because the course asks for defensive understanding. If a case seems to need deeper technical detail, she asks her supervisor whether it is necessary and how to obtain it safely, and she records the answer with her notes.
20.6 Comparing cases
A comparison table helps: for each case list entry technique, persistence approach, impact and the defensive lesson. Patterns across rows — credentials appear again and again — are more useful than any single dramatic story, and the table keeps attention on defence rather than on adversary mystique.
Amara builds such a table from five public cases. Two rows share the use of stolen credentials, and three end with encryption and a long recovery. She presents the table to the security team as a summary of what defences mattered most, with each row citing its public source, and adds new cases each quarter.
From case to local question
Each case should end with a question for HCHT: do we monitor supplier updates, are backups isolated, would we notice valid-account abuse at night? Writing that question turns history into a concrete check that an owner can answer within a week.
Worked example
Amara builds a table of three public health-sector ransomware cases: entry route, time to impact, backup status, recovery time. Two recovered faster because backups were offline. She presents the table, with sources, in a team learning session.
Synthetic case. Amara's table and session are invented; real cases would be cited from public sources.
Errors and limits
Published cases favour dramatic events. Avoid overgeneralising from them.
Exercises
- EX058 — Kill chain lesson. State the main lesson of the Hutchins et al. paper for defenders.
Show marking criteria
Rubric: 3 = intelligence from each intrusion (incl. failed) blocks later phases/attempts; 2 = partial; 1 = vague; 0 = none. - EX059 — Behaviour vs infrastructure. Why does behavioural detection outlast indicator lists?
Show marking criteria
Rubric: 3 = techniques change less than domains/addresses; 2 = partial; 1 = opposite; 0 = none. - EX060 — Backup pattern. What pattern did Amara's ransomware table reveal?
Show marking criteria
Rubric: 3 = offline backups → faster recovery; 2 = partial; 1 = vague; 0 = none.
Synthesis
Foundational cases teach durable lessons: reuse intelligence across intrusions, detect behaviour, protect backups, watch suppliers.
Continue studying — chapter 20 of 40
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →