Chapter 15 — Threat intelligence and OSINT: integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Consumers"]
N2["15.2 Service levels"]
N3["15.3 Dependencies"]
N4["15.4 Failure plans"]
N5["15.5 Feedback loop"]
N6["15.6 Incident support"]
N7["15.7 Supplier intelligence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Consumers"]
N2["15.2 Service levels"]
N3["15.3 Dependencies"]
N4["15.4 Failure plans"]
N5["15.5 Feedback loop"]
N6["15.6 Incident support"]
N7["15.7 Supplier intelligence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 Consumers]
|
v
[15.2 Service levels]
|
v
[15.3 Dependencies]
|
v
[15.4 Failure plans]
|
v
[15.5 Feedback loop]
|
v
[15.6 Incident support]
|
v
[15.7 Supplier intelligence]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) connect CTI to help desk, network, email and incident teams; (2) agree service levels; (3) map dependencies on suppliers and partners; (4) plan for dependency failure.
15.1 Consumers
Help desk: current scams and what to tell callers. Network and email teams: block lists. Incident response: context during incidents. Management: monthly summary.
Each consumer needs a different product in a different form. The help desk needs plain advice it can read to callers, while the network team needs a validated list. Tomás asks each consumer once a term whether the product still fits their work, so the outputs change when their needs do. Incident response also receives a short standing note of current campaigns aimed at colleges.
15.2 Service levels
Urgent items reviewed within four working hours; routine within two days; scam list each Monday in term time.
Urgent items include confirmed phishing aimed at Ashgrove and credential exposures, where hours matter. Routine items can wait up to two working days without causing harm. The Monday scam list in term time gives the help desk a predictable briefing before the busiest day of the week. Service levels are agreed with each consumer team and written in the CTI runbook. During college holidays the scam list pauses, while urgent items keep the four-hour review. Missed service times are recorded in the failure log with their cause.
15.3 Dependencies
ESX membership and its TAXII server; the platform's hosting; the cloud email supplier's logs; the network team's DNS filter. Each can fail.
Tomás lists each dependency with its owner and what stops if it fails. The cloud email supplier's thirty-day log retention is itself a dependency limit, because it decides which past events can be checked. The list is reviewed with the supervisor each term alongside the system diagram. For each dependency, the list also records how a failure would be noticed, such as a zero import count. ESX membership is renewed each year, and its renewal date is on the list.
15.4 Failure plans
If ESX is unavailable, use national education advisories; if the platform fails, scripts can read ESX email alerts directly; if the DNS filter fails, the proxy carries urgent domain blocks.
Each fallback is slower or narrower than the normal path, so the plan states what is lost. National advisories cover education broadly but lack ESX members' specific indicators. The proxy covers staff only, so urgent domain blocks through it would leave student devices on Wi-Fi unprotected until DNS filtering returns. The fallbacks are tested once a term, outside exam periods. Each test is recorded in the dependency list with its date and result.
15.5 Feedback loop
Help desk forwards suspicious messages reported by students and staff to the CTI queue; this is often the earliest warning.
Students and staff often see a scam before any feed reports it, as the forty enrolment-week reports showed. The help desk forwards the original message with headers, which lets Tomás run his authentication parser on it. Each forwarded report is acknowledged, so the help desk knows the queue is being read. Tomás also tells the help desk what came of their reports, so they see the value of forwarding them.
15.6 Incident support
During incidents, Tomás follows the incident lead's priorities, as NIST SP 800-61r3 places intelligence within response.
The incident lead decides what matters most, such as which systems to contain first. Tomás answers their questions with what is known about the indicators and techniques involved. He keeps his own notes timestamped in the shared incident document, as the documentation rules require. Requests from the incident lead take priority over routine triage during the incident. Tomás tells his supervisor which routine items will be delayed, so consumers can be warned. His intelligence notes in the incident follow the same three-line format.
15.7 Supplier intelligence
Advisories about the learning-platform supplier or the email supplier go to contract managers too.
A supplier advisory may require action that only the supplier can take, such as patching the learning platform they host. Contract managers can ask the supplier for written assurance or a timeline. Tomás sends them a short summary with the advisory's label, so they know what they may forward. The summary also states whether Ashgrove uses the affected product version, which the service table shows.
15.8 Calendar
Term starts, exam periods and enrolment bring scam peaks; the team plans extra monitoring then.
During enrolment week, the help desk received forty reports of fake fee payment emails in a short period. Planning ahead means extra triage time is booked and the help desk is briefed before term begins. Tomás marks these weeks in the team calendar at the start of each year. Exam periods bring a different risk: changes are avoided, so monitoring matters more than new blocks. Tomás reviews each peak afterwards, noting the scam themes seen.
Measuring integration
Count how often each consumer acted on CTI each month: blocks applied, help-desk scripts used, incident questions answered. Falling numbers may mean products no longer fit, prompting a conversation with that team.
Worked example
During enrolment week, the help desk forwards forty reports of fake "fee payment" emails. Tomás identifies two sender domains, requests blocks, gives the help desk a script for callers and sends ESX a GREEN item. Two other colleges block the domains the same day.
Synthetic case. The campaign is invented.
Errors and limits
Fallbacks need testing; an untested plan may fail when needed.
Exercises
- EX057 — Fallback list. Give the fallback for an ESX outage and for a platform failure. Rubric: 3 = national advisories; scripts read email alerts; 2 = one; 1 = vague; 0 = none.
- EX058 — Earliest warning. Which consumer is often also the earliest source? Rubric: 3 = help desk reports; 2 = partial; 1 = management; 0 = none.
- EX059 — Enrolment outputs. List the four outputs from the enrolment-week case. Rubric: 3 = blocks, help desk script, ESX item, (identification of domains); 2 = two; 1 = one; 0 = none.
- EX060 — Supplier advisory. Who besides technical owners should receive supplier advisories? Rubric: 3 = contract managers; 2 = partial; 1 = students; 0 = none.
Synthesis
Serve each consumer, set service levels, map dependencies with fallbacks and use the help desk as an early-warning source.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →