Chapter 23 — Security operations and blue team: threat and failure analysis
Lesson map
Lesson 23 published. Map, example, EX067.
flowchart TD
N0["Learning outcomes"]
N1["23.1 Threat analysis"]
N2["23.2 Technique coverage"]
N3["23.3 Failure analysis"]
N4["23.4 Silent failures"]
N5["23.5 Combining views"]
N6["23.6 Review"]
N7["23.7 Avoiding bias"]
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 Threat analysis"]
N2["23.2 Technique coverage"]
N3["23.3 Failure analysis"]
N4["23.4 Silent failures"]
N5["23.5 Combining views"]
N6["23.6 Review"]
N7["23.7 Avoiding bias"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]
[Learning outcomes]
|
v
[23.1 Threat analysis]
|
v
[23.2 Technique coverage]
|
v
[23.3 Failure analysis]
|
v
[23.4 Silent failures]
|
v
[23.5 Combining views]
|
v
[23.6 Review]
|
v
[23.7 Avoiding bias]
|
v
[Worked example] --> [Exercise EX067]
Learning outcomes
You will (1) analyse threats relevant to the organisation using ATT&CK; (2) analyse failure modes of the monitoring system; (3) combine threat and failure views into priorities; (4) document analyses for review.
23.1 Threat analysis
Lindqvist's threat analysis asks which adversaries target logistics firms and which techniques they use. Public reporting and ATT&CK groups show credential abuse, phishing of staff, ransomware and fraud through customer accounts.
Starting with adversaries who target the sector keeps the analysis grounded in what actually happens to similar firms. For a logistics company, delivery fraud and payment diversion are as relevant as data theft. ATT&CK groups document techniques seen in real campaigns, which turns general concern about ransomware into specific behaviours the SOC can look for.
23.2 Technique coverage
For each relevant technique, the team records data sources needed, detections present and confidence. Coverage maps show strengths (credential abuse on the portal) and gaps (lateral movement in depot networks).
Confidence records how sure the team is that a detection would work, based on testing rather than on its existence. A rule written but never tested earns low confidence. The coverage map makes priorities visible to managers who cannot read rules: strong in one area, weak in another, with the evidence behind each rating.
23.3 Failure analysis
The monitoring system itself fails: sources go silent, parsers break after upgrades, enrichment tables go stale, rules are disabled and forgotten. A failure mode and effects table lists each failure, its effect on detection, how it would be noticed and its likelihood.
The format comes from engineering safety analysis, where it is used for machines and plants. Applied to monitoring, each row asks: if this part fails, which detections stop working, how quickly would we know, and how likely is it? A parser breaking after an upgrade is likely and may go unnoticed for days, so it ranks high.
23.4 Silent failures
The worst failures are silent: a source stops sending and nothing alerts. These get detection of their own, covered in chapter 47.
Silence is dangerous because the absence of alerts looks the same as the absence of attacks. A source that normally sends ten thousand events an hour and suddenly sends none should itself raise an alarm. Expected volumes per source, with alerts on large drops, turn silence into a visible signal. Some sources are naturally quiet at night, so thresholds compare each hour with the same hour on previous weeks rather than with a flat daily average.
23.5 Combining views
Priority is highest where an important technique depends on a fragile component — for example, account-takeover detection depending on a single load-balancer log feed.
Threat analysis shows what matters; failure analysis shows what is fragile. Their overlap is where a single failure would blind the SOC to an important technique. The load-balancer feed is a clear example: if it stops, account-takeover detection degrades. The response is either a second feed or close monitoring of the existing one. Amara marks such overlaps in red on the coverage map.
23.6 Review
Analyses are reviewed by analysts, IT operations and the CISO's office, then revisited after incidents or major changes.
Analysts know which detections are trusted in practice; IT operations know which components are fragile; the CISO's office knows business priorities. Each view corrects the others. Revisiting after incidents keeps the analysis current, since an incident often reveals a technique or failure mode the original review overlooked. Each review produces a dated version with a short list of changes and who requested them, so later readers can see how the team's view of threats and failures evolved over time.
23.7 Avoiding bias
Teams overweight recent incidents. Using ATT&CK as a checklist helps consider techniques that have not yet hit Lindqvist.
After the portal incident, attention focuses on credential abuse, and it is tempting to spend all effort there. A checklist forces the team to look systematically at other techniques, such as misuse of remote management tools in depots, that have not yet caused trouble. Recent pain is a useful signal but a poor complete guide. Each technique left out is marked with a short reason.
Insider and fraud threats
Not every threat is external. Staff with access to customer accounts could misuse it, and fraudsters may use legitimate portal features. These threats rely on business logs, such as address changes and refunds, more than on technical telemetry.
Worked example
Amara's failure table entry: "Load-balancer log feed stops → no account-takeover alerts → noticed only by chance → likelihood medium (feed broke twice last year) → priority high. Action: heartbeat monitoring and a second feed path."
Synthetic case. The analyses are invented.
Errors and limits
Threat reports describe others' experiences; tailor them to your environment.
Exercises
- EX067 — Coverage record. What is recorded for each relevant technique? Rubric: 3 = data sources, detections, confidence; 2 = two; 1 = one; 0 = none.
- EX068 — Silent failure. Why are silent failures the worst? Rubric: 3 = nothing alerts, so detection disappears unnoticed; 2 = partial; 1 = vague; 0 = none.
- EX069 — Combined priority. Why was the load-balancer feed ranked high? Rubric: 3 = important detection depends on fragile single feed; 2 = partial; 1 = random; 0 = none.
Synthesis
Combine threat coverage with failure analysis of the monitoring system to set priorities.
Continue studying — chapter 23 of 50
← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →