Chapter 11 — Threat intelligence and OSINT: assets and context
Lesson map
Lesson 11 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Relevance view"]
N2["11.2 Business impact"]
N3["11.3 Seasonal context"]
N4["11.4 Owner conversations"]
N5["11.5 Dependencies"]
N6["11.6 Writing context into notes"]
N7["Crown jewels"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Relevance view"]
N2["11.2 Business impact"]
N3["11.3 Seasonal context"]
N4["11.4 Owner conversations"]
N5["11.5 Dependencies"]
N6["11.6 Writing context into notes"]
N7["Crown jewels"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[11.1 Relevance view]
|
v
[11.2 Business impact]
|
v
[11.3 Seasonal context]
|
v
[11.4 Owner conversations]
|
v
[11.5 Dependencies]
|
v
[11.6 Writing context into notes]
|
v
[Crown jewels]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) build a threat-relevance view of CMS assets; (2) link asset types to likely techniques; (3) prioritise intelligence by business impact; (4) keep context current with owners.
11.1 Relevance view
Lena adds two columns to the asset list: "services residents depend on" and "techniques of concern". The payments portal: fraud lookalikes and T1190. Staff email: T1566. File servers: T1486. This view lets her sort incoming intelligence quickly.
With these columns, an MCX item about T1190 against payment software sorts straight to the payments portal, while an item about T1486 goes to the file-server owner. Lena no longer reads every item against the whole estate; the technique identifier points to the rows that matter, and the owner column says who receives the note.
11.2 Business impact
Payments and permits affect residents directly and bring revenue; the intranet affects only staff. When two advisories arrive together, the one touching resident-facing services goes first.
Resident-facing services carry two kinds of harm at once: residents cannot do what they need, and CMS loses income and trust. An intranet outage inconveniences staff, but a fix can usually wait a day. This ordering lets Lena decide quickly when two items compete for the same morning, without asking the manager every time. Lena writes the reason for the order into her notes, so an owner whose item waited knows why it came second.
11.3 Seasonal context
Council tax deadlines and elections bring spikes in fraud and attention. Lena marks those dates on the team calendar so monitoring increases beforehand.
Fraudsters time lookalike payment pages for when residents expect to pay, so a deadline makes fake reminders more convincing. Marking the dates in advance gives time to warn residents and to watch for lookalike domains before the texts start. The worked example below shows this working two weeks before a council-tax deadline. The calendar also includes election dates, when defacement of the council website would attract more attention than usual.
11.4 Owner conversations
Owners know what spreadsheets say nothing about: that the permits portal will be replaced in spring, or that a supplier connects every night. Quarterly chats keep context fresh.
Knowing that the permits portal will be replaced in spring changes how Lena treats an advisory for its current software: still relevant now, but not worth a long-term plan. A supplier connecting every night explains traffic that would otherwise look suspicious. Both of these facts come only from talking to the owners themselves. Lena writes down what each owner tells her, so the context survives when she or the owner moves on.
11.5 Dependencies
The payments portal depends on an external payment provider. Intelligence about that provider matters to CMS even though CMS does not run it.
CMS cannot patch or monitor the payment provider's systems, but residents will blame the council if payments through its portal go wrong. Intelligence about the provider therefore goes to the payments owner, who can ask the provider questions under their contract. Lena keeps the provider's name beside the payments portal entry, so advisories that mention the provider are matched like any other product. The same applies to any supplier with access to CMS systems, such as the one that connects every night.
11.6 Writing context into notes
Each intelligence note names the affected asset, its owner, its exposure and the relevant date context, so the reader understands why the item matters to CMS today.
A note that names the payments portal, its owner, its internet exposure and an approaching tax deadline tells the reader why it cannot wait until next week. Without those details, the same item could look like general news. Writing context in also helps later readers who see the note without knowing what was happening at the time.
Crown jewels
Ask leadership which three services would cause the most harm if lost for a week. For CMS the answer was payments, permits and the emergency-notification system. Intelligence touching these always receives same-day review, whatever its source or apparent severity.
Worked example
Two weeks before the council-tax deadline, MCX reports fraud texts imitating tax-payment pages in another city. Lena's relevance view marks payments as top priority and the calendar shows the deadline. She drafts an early warning for the communications team and asks the network team to watch DNS for "tax" lookalikes.
Synthetic case. The report and dates are invented.
Errors and limits
Relevance views encode assumptions; revisit them when services change.
Exercises
- EX031 — Asset technique. Which technique of concern did Lena assign to file servers, and why? Rubric: 3 = T1486 ransomware encryption; holds shared data; 2 = name; 1 = T1566; 0 = none.
- EX032 — Seasonal spike. Why mark council-tax deadlines on the calendar? Rubric: 3 = fraud spikes; raise monitoring in advance; 2 = partial; 1 = no reason; 0 = none.
- EX033 — Provider dependency. Why does intelligence about the payment provider matter to CMS? Rubric: 3 = portal depends on it; its compromise affects residents; 2 = partial; 1 = doesn't; 0 = none.
Synthesis
Tie assets to techniques and impact, watch seasons and dependencies, and keep context fresh with owners.
Continue studying — chapter 11 of 30
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →