Chapter 21 — Threat intelligence and OSINT: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Consumers"]
N2["21.2 Service desk"]
N3["21.3 Operations"]
N4["21.4 Incident response"]
N5["21.5 Service levels"]
N6["21.6 Feedback"]
N7["21.7 Routing table"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Consumers"]
N2["21.2 Service desk"]
N3["21.3 Operations"]
N4["21.4 Incident response"]
N5["21.5 Service levels"]
N6["21.6 Feedback"]
N7["21.7 Routing table"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Consumers]
|
v
[21.2 Service desk]
|
v
[21.3 Operations]
|
v
[21.4 Incident response]
|
v
[21.5 Service levels]
|
v
[21.6 Feedback]
|
v
[21.7 Routing table]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) integrate CTI outputs with the service desk, operations and incident response; (2) define simple service levels; (3) route items to the right team; (4) gather feedback systematically.
21.1 Consumers
The service desk receives resident and staff reports of suspicious messages. Operations runs monitoring tools. Incident response handles confirmed incidents. Communications warns the public. Each needs a different product.
The service desk needs to know what to tell callers; operations needs indicators and technique notes; incident response needs fast searches during an incident; and communications needs a plain description for residents. Sending everyone the same note would give each team too much of what it does not need and too little of what it does.
21.2 Service desk
Lena gives the service desk a short weekly list of current scams with sample subject lines and what to tell callers. When reports come in, the desk forwards samples to the CTI queue, closing the loop.
The weekly list helps the desk recognise a scam on the first call rather than after many. Samples forwarded by the desk give Lena new indicators, such as the domain in a fresh fraud text, which she can then check and add to block requests. The worked example below starts from exactly such reports by the service desk.
21.3 Operations
Operations receives indicators through the platform's export and technique notes for tuning alerts. Urgent items come by phone.
The export carries indicators directly into tools, so operations does not retype them. Technique notes explain what behaviour to watch for, which helps tune alerts beyond single indicators. A phone call for urgent items is used because a ticket or export could sit unseen for hours, which is too slow when a fraud page is live. Operations tells Lena which technique notes led to tuned alerts, which helps her judge what to write next.
21.4 Incident response
During incidents, Lena searches for related indicators and checks MCX for similar cases, following the incident lead's priorities. NIST SP 800-61r3 places such intelligence support within incident response.
Following the incident lead's priorities keeps Lena's searches on the questions that decide containment rather than on interesting side paths. Similar cases from MCX can show what the attacker did next elsewhere, which helps the team look ahead. Lena's searches and their results are recorded in the incident ticket like any other evidence.
21.5 Service levels
Urgent items reviewed within four hours in working time; routine items within two days; weekly scam list every Monday.
Four working hours for urgent items means a fraud domain reported in the morning can be in a block request by the afternoon. Two days for routine items keeps the queue moving without demanding instant answers. The Monday scam list gives the service desk a fixed point in the week they can plan around. The service levels are written in the routing table, so anyone covering for Lena knows the deadlines without asking.
21.6 Feedback
A two-question monthly form: what helped, what was noise. Answers adjust content.
Two questions are short enough that busy teams actually answer. If the service desk says the scam list helped but the vulnerability notes were noise for them, Lena stops sending those notes to the desk. The answers also show which products to keep when time is short, for example during staff absence. Lena summarises the answers each month for her supervisor, with the changes she made in response to them. A product that several teams call noise twice in a row is shortened or dropped, which frees time for the products they do use.
21.7 Routing table
A table maps item types to teams: fraud against residents to communications and web; staff phishing to email and service desk; vulnerabilities to system owners; partner compromise to supervisor.
The table removes guesswork for Lena and for anyone covering her. A fake parking-fine text goes to communications and web; an invoice phishing email aimed at finance goes to email and the service desk; a flaw in portal software goes to its owner. Partner compromise goes to the supervisor because it may change what CMS shares with that partner.
Communications partnership
Public warnings must be accurate and calm. Lena gives communications a plain description — what the scam looks like, what the council will never ask for, how to report it — and leaves wording and timing to them. Agreeing a template in advance makes the next warning faster.
Worked example
The service desk reports twenty calls about a fake parking-fine text. Lena checks: the domain is new and absent from MCX. She adds it to the block request, sends a CLEAR description to communications for a public warning and shares a GREEN item with MCX so neighbouring councils can prepare.
Synthetic case. The text and calls are invented.
Errors and limits
Service levels slip during staff absence; plan cover.
Exercises
- EX061 — Desk loop. How does the service desk close the intelligence loop? Rubric: 3 = forwards reported samples to CTI queue; 2 = partial; 1 = vague; 0 = none.
- EX062 — Parking text routing. Which three teams or bodies received outputs from the parking-fine case? Rubric: 3 = network block, communications, MCX; 2 = two; 1 = one; 0 = none.
- EX063 — Routing table. Where should a vulnerability advisory be routed? Rubric: 3 = system owner (via asset list); 2 = IT generally; 1 = communications; 0 = none.
Synthesis
Serve each consumer with the product it needs, set service levels, route by type and collect feedback.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →