Chapter 23 — Threat intelligence and OSINT: threat and failure analysis
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Threats to Lantern"]
N2["23.2 FMEA"]
N3["23.3 Example rows"]
N4["23.4 Acting on rankings"]
N5["23.5 Accidents"]
N6["Practice note — Abuse cases"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX067"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["23.1 Threats to Lantern"]
N2["23.2 FMEA"]
N3["23.3 Example rows"]
N4["23.4 Acting on rankings"]
N5["23.5 Accidents"]
N6["Practice note — Abuse cases"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Threats to Lantern]
|
v
[23.2 FMEA]
|
v
[23.3 Example rows]
|
v
[23.4 Acting on rankings]
|
v
[23.5 Accidents]
|
v
[Practice note — Abuse cases]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) threat-model the CTI platform itself; (2) perform a failure modes and effects analysis (FMEA); (3) rank risks by severity, occurrence and detection; (4) map adversary techniques against Lantern using ATT&CK IDs.
23.1 Threats to Lantern
Feed poisoning, credential theft (T1078 Valid Accounts), supply-chain compromise of a dependency (T1195), exfiltration of restricted reports, and denial of service by oversized feeds. Each threat maps to a control.
Kofi wrote each threat as a short scenario with the attacker's goal and the route they would take. Poisoning, for instance, could come through a compromised partner or a forged delivery. Writing the route shows which control interrupts it: signature checks stop forgery but not a compromised partner, which needs anomaly checks. The scenarios are kept with the risk register and reviewed when a component changes.
23.2 FMEA
For each component, list failure modes, effects and causes. Score severity (S), occurrence (O) and detection difficulty (D) on 1–10; the risk priority number RPN = S × O × D ranks attention.
The three scores come from the team's judgment, informed by incident history where it exists. Kofi runs the scoring with an operator, an engineer and an analyst in the room, because each sees different failures. The number that results is useful for ranking; the discussion that produces it often matters more, since it surfaces failure modes no single person had considered.
23.3 Example rows
Collector stops silently: S6, O4, D7 → RPN 168. Bad block pushed to IT: S8, O3, D4 → 96. TLP:RED report mis-shared: S9, O2, D6 → 108. The silent collector stop ranks highest because nobody would notice for days.
The ranking surprised the team, who had expected the mis-shared RED report to come first because its harm is greatest. Its likelihood is low and access logging would reveal it fairly quickly. The collector failure is less severe, but nothing alerts anyone, so harm accumulates quietly while indicators go stale. That is the case the worked example addresses.
23.4 Acting on rankings
High detection scores call for monitoring: a heartbeat alert if no objects arrive from a partner for six hours. High severity calls for prevention and approval gates.
Kofi's heartbeat alert compares each partner's arrival history with the current gap. A partner that normally sends every hour triggers the alert after six quiet hours; one that publishes once a day has a longer window. After the change, the team re-scored the row and recorded the lower number with the reason, so the effect of the control is visible in the register.
23.5 Accidents
Not every failure is malicious. A partner's mistaken mass upload or a clock error can cause harm. Failure analysis covers both.
Kofi's register gives accidents their own rows. A partner once uploaded an entire test dataset by mistake, filled with harmless domains. The volume check held the delivery, and the partner withdrew it the same day. A clock set to the wrong year on a test server produced indicators that appeared already expired. Neither event involved an adversary, yet both could have disrupted BEN.
Practice note — Abuse cases
Alongside use cases Kofi writes abuse cases: 'A partner account uploads ten million objects', 'An analyst exports a RED report to personal mail'. Each abuse case maps to a control and a test, turning the threat model into verifiable work. The abuse cases are reviewed whenever a new partner or interface joins the platform.
Worked example
Kofi's FMEA shows the silent collector stop at RPN 168. He adds per-partner heartbeat monitoring, reducing D to 2 and RPN to 48, and records the change in the risk register.
Synthetic case. Scores are invented.
Errors and limits
RPN multiplies ordinal scales, so treat it as a ranking aid, not a precise measure. Threat models go stale; review after major changes.
Exercises
- EX067 — RPN compute. Compute RPN for S7, O3, D5. Rubric: 3 = 105; 2 = method right; 1 = sum; 0 = none.
- EX068 — After heartbeat. With D reduced from 7 to 2, what is the collector RPN? Rubric: 3 = 48; 2 = method; 1 = wrong; 0 = none.
- EX069 — Technique link. Which ATT&CK technique ID covers an attacker using a stolen analyst login? Rubric: 3 = T1078 Valid Accounts; 2 = name only; 1 = wrong; 0 = none.
Synthesis
Threat-model the platform, rank failures with FMEA, add detection where failures are silent, and cover accidents as well as adversaries.
Continue studying — chapter 23 of 50
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →