OpenCyber AcademyLesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Layers"]
N2["16.2 CTI at each layer"]
N3["16.3 Segmentation"]
N4["16.4 Choosing enforcement"]
N5["16.5 Architecture reviews"]
N6["16.6 Backups as a CTI consumer"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Layers"]
N2["16.2 CTI at each layer"]
N3["16.3 Segmentation"]
N4["16.4 Choosing enforcement"]
N5["16.5 Architecture reviews"]
N6["16.6 Backups as a CTI consumer"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Layers]
|
v
[16.2 CTI at each layer]
|
v
[16.3 Segmentation]
|
v
[16.4 Choosing enforcement]
|
v
[16.5 Architecture reviews]
|
v
[16.6 Backups as a CTI consumer]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) describe defence in depth in a hospital network; (2) place CTI inputs at each layer; (3) explain segmentation for clinical systems; (4) choose where an indicator should be enforced.
16.1 Layers
Email filtering, web proxy, DNS filtering, endpoint protection, identity controls, segmentation and backups form layers. No single layer stops every attack; intelligence helps tune each.
Amara maps each type of intelligence HCHT receives to the layer that can use it and the team that owns that layer. The map shows layers no intelligence reaches, such as backups, and intelligence no layer can use, such as indicators for systems HCHT does not run. Both gaps are discussed with the security lead.
16.2 CTI at each layer
Sender domains feed email filters; malicious domains feed DNS and proxy; hashes feed endpoint tools; technique intelligence informs detection rules and hardening; ransomware intelligence (Data Encrypted for Impact, T1486) informs backup isolation.
Amara routes each item to the right owner with a short explanation of what to do. Hash lists go to the endpoint team with the source and confidence; technique summaries go to the detection engineer with ideas for searches; ransomware intelligence goes to infrastructure with the specific backup risks. Each owner confirms what was done, which feeds the outcome measures.
16.3 Segmentation
Clinical devices sit in separate network zones with tightly limited paths. Intelligence about lateral movement through remote services strengthens the case for blocking unnecessary paths between office and clinical zones.
Amara collects sector reports where attackers moved from office systems to clinical ones and summarises the paths they used. The network team compares these with HCHT's firewall rules and finds two paths no longer needed, which are closed after checking with clinical engineering. The summary is kept as evidence for the change.
16.4 Choosing enforcement
Block where the indicator is reliable and the blast radius is acceptable. A hash of a known malicious file is safe to block on endpoints. A shared cloud address is not safe to block at the firewall.
Amara writes the reason for the chosen enforcement point next to each blocking recommendation. When reliability is uncertain, she recommends monitoring first and blocking later if the evidence grows. The same domain may be safe to block at the email gateway, where only messages are affected, but risky at DNS, where clinical systems could lose access to a supplier's service.
16.5 Architecture reviews
When HCHT designs a new system, the CTI team summarises relevant techniques seen in the sector so architects can design against them from the start.
The summary is short and lists techniques relevant to the system's type, such as remote access for a supplier portal or phishing for a new email workflow. Architects use it to check their design, and the CTI team checks the design afterwards for the listed techniques. Amara helped with the summary for a new laboratory system.
16.6 Backups as a CTI consumer
Sector intelligence that ransomware groups seek and delete backups before encrypting (T1490 Inhibit System Recovery is a related ATT&CK technique) tells the infrastructure team what to protect: offline or immutable copies, separate credentials for backup administration and regular restore tests that prove recovery works.
Amara's summary of the sector reports goes to the infrastructure team, who confirm which protections are in place. They also run a restore test after the summary, which shows that one backup set shares credentials with ordinary administration. The credentials are separated within the month, and the result is recorded as an outcome of the intelligence.
Worked example
A sector report describes attackers encrypting file servers after deleting backups. Amara maps it to T1486 and passes it to the infrastructure lead with a question: are HCHT backups offline or immutable? They are not for one site. The lead adds an immutable copy, citing the report in the change request.
Synthetic case. The report and backup gap are invented.
Errors and limits
Architecture changes take time; intelligence should inform priorities, not demand instant redesign.
Exercises
- EX046 — Layer match. Which layer should receive a SHA-256 hash of a malicious attachment?
Show marking criteria
Rubric: 3 = endpoint (and mail attachment scanning), with reason; 2 = endpoint; 1 = firewall; 0 = none. - EX047 — Cloud address. Why not block a shared cloud address at the firewall?
Show marking criteria
Rubric: 3 = many legitimate services share it; collateral; 2 = partial; 1 = always block; 0 = none. - EX048 — Backup question. What question did ransomware intelligence prompt, and what changed?
Show marking criteria
Rubric: 3 = offline/immutable backups? immutable copy added at one site; 2 = one; 1 = vague; 0 = none.
Synthesis
Feed each layer the intelligence it can use, enforce where reliable and harmless, and use technique intelligence to shape architecture.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →