◇ OpenCyber Academy
Technologist · Chapter 13 · English

Chapter 13 — Threat intelligence and OSINT: risk scenarios

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 13 — Threat intelligence and OSINT: risk scenarios

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 Scenario structure"]
  N2["13.2 Grounding"]
  N3["13.3 Mapping"]
  N4["13.4 Bands"]
  N5["13.5 Controls"]
  N6["13.6 Review rhythm"]
  N7["13.7 Audience"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 Scenario structure"]
  N2["13.2 Grounding"]
  N3["13.3 Mapping"]
  N4["13.4 Bands"]
  N5["13.5 Controls"]
  N6["13.6 Review rhythm"]
  N7["13.7 Audience"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 Scenario structure]
    |
    v
[13.2 Grounding]
    |
    v
[13.3 Mapping]
    |
    v
[13.4 Bands]
    |
    v
[13.5 Controls]
    |
    v
[13.6 Review rhythm]
    |
    v
[13.7 Audience]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) write threat scenarios grounded in intelligence; (2) map scenarios to ATT&CK techniques and kill-chain phases; (3) estimate likelihood and impact in bands; (4) link scenarios to controls.

13.1 Scenario structure

A scenario names the actor type, goal, entry route, key techniques, affected service and impact. Example: "Fraud group registers lookalike payment domains, sends texts to residents, collects card details; residents lose money and trust in CMS falls."

The fraud example fills each part: a fraud group as actor, money as goal, texts with links as entry route, lookalike domains and fake pages as techniques, payments as the affected service, and losses and reduced trust as impact. A scenario missing one part usually means a question nobody has answered yet.

13.2 Grounding

Each scenario cites intelligence: MCX reports from other councils, public advisories, CMS incidents. Scenarios without evidence are speculation.

Grounding gives each scenario a reason to exist that a manager can check. The fraud scenario rests on MCX reports of fake payment pages at other councils and on residents' complaints at CMS. A scenario with no such basis may still be worth noting, but it is labelled as speculation so nobody spends money on it as if it were evidenced. Each citation in a scenario uses the source's TLP label, so the scenario itself is marked no more widely than its most restricted source.

13.3 Mapping

The ransomware scenario: phishing (T1566) for entry, valid accounts (T1078), remote services (T1021) to spread, encryption (T1486) for impact. Mapped to kill-chain phases: delivery, exploitation via credentials, actions on objectives.

The mapping shows where CMS can act at each step. Phishing is met at the email gateway, valid accounts at the identity provider with MFA, spread through remote services at zone boundaries, and encryption with offline backups. A step with no matching control is visible at once, which is the purpose of the next measure.

13.4 Bands

Likelihood: likely, roughly even, unlikely. Impact: minor, moderate, severe. Bands keep discussion honest when data is thin.

Lena rarely has data to calculate a probability, and a precise-looking number would invite arguments about decimals. Three bands are enough to rank scenarios, as the worked example shows: fraud likely and moderate, ransomware roughly even but severe. Managers can then see that rare but severe and frequent but minor need different responses. Lena rates each scenario together with her supervisor, so the band reflects two judgements rather than one person's impression.

13.5 Controls

Each scenario lists existing controls and gaps. The fraud scenario: CT-log monitoring exists; resident warnings exist; takedown process is slow — a gap.

Listing gaps next to controls turns the scenario into a request for something specific. For fraud, CT-log monitoring and resident warnings work, but a slow takedown process leaves fraud pages live longer. That gap is what the manager funded in the worked example, which shows the list leading directly to a decision. Gaps are written as specific missing capabilities, so the manager can see what money or time would close each one.

13.6 Review rhythm

Scenarios are reviewed every six months, or sooner if MCX reports a new pattern. Retired scenarios are archived, not deleted.

Six months suits a council whose services change slowly, while an MCX report of a new pattern is a reason to review early. Archiving retired scenarios keeps the reasoning behind past decisions, so if a pattern returns, Lena can see what was decided before and why the scenario was retired. Each review records what changed and why, so the history of a scenario's rating can be followed from one review to the next.

13.7 Audience

Managers read scenarios to set priorities; engineers read them to choose detections. A short summary line and a technical table serve both.

The summary line for fraud might say that residents are being targeted with fake payment pages and that takedown is slow. The technical table lists the techniques, data sources and detections. A manager reads the first and decides; an engineer reads the second and builds, from the same scenario. Lena checks that the summary line and the table agree, so the two audiences are not given different versions of the same risk.

Using the Diamond Model

For each scenario, fill the four Diamond vertices: adversary (a fraud group), capability (lookalike pages and text messages), infrastructure (newly registered domains and bulk-text services) and victim (residents paying fees). Gaps in any vertex show where intelligence is missing, and the infrastructure vertex shows which monitoring — such as certificate-transparency checks — can detect the scenario early.

Worked example

Lena drafts three scenarios: payment fraud, ransomware and website defacement. With her supervisor she rates fraud likely/moderate, ransomware roughly even/severe, defacement likely/minor. The manager funds faster takedown support for fraud and an offline backup test for ransomware.

Synthetic case. The ratings are invented.

Errors and limits

Scenarios can anchor thinking; add a "surprise" scenario each review.

Exercises

Synthesis

Write evidence-based scenarios, map them to techniques and phases, rate in bands and tie them to control decisions.

Continue studying — chapter 13 of 30

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →