Chapter 20 — Threat intelligence and OSINT: troubleshooting
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Symptoms"]
N2["20.2 Method"]
N3["20.3 Fault types"]
N4["20.4 Communicating"]
N5["20.5 Preventing recurrence"]
N6["20.6 Keeping a fault log"]
N7["20.7 Asking for help"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Symptoms"]
N2["20.2 Method"]
N3["20.3 Fault types"]
N4["20.4 Communicating"]
N5["20.5 Preventing recurrence"]
N6["20.6 Keeping a fault log"]
N7["20.7 Asking for help"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Symptoms]
|
v
[20.2 Method]
|
v
[20.3 Fault types]
|
v
[20.4 Communicating]
|
v
[20.5 Preventing recurrence]
|
v
[20.6 Keeping a fault log]
|
v
[20.7 Asking for help]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) diagnose failures in the intelligence pipeline methodically; (2) distinguish data, code and configuration faults; (3) communicate incidents in the pipeline; (4) prevent recurrence.
20.1 Symptoms
Typical symptoms: no new indicators today; a spike of false-positive blocks; exports rejected by a tool; matches missing that should exist. Each starts a structured check rather than random fixes.
Each symptom points to a different part of the flow. No new indicators suggests the source or import; a spike of false blocks suggests a bad batch or a normalisation fault; rejected exports point to the receiving tool; missing matches may mean logs are not arriving. Naming the symptom first narrows where in the flow Lena needs to look.
20.2 Method
Work from the source forward: did data arrive? Did parsing accept it? Did the store hold it? Did export send it? Did the tool load it? Check one hand-off at a time and record each result.
Checking the hand-offs in order avoids fixing the wrong thing first. In the worked example, Lena's first check showed that data did not arrive at all, because TAXII requests were refused, so there was no point examining parsing or exports. Recording each result also lets a colleague take over if the fault outlasts her shift.
20.3 Fault types
Data faults: a partner changed a column name or label spelling. Code faults: a script assumed lower-case labels. Configuration faults: an expired API key, a firewall rule blocking TAXII, a full disk.
The three categories decide who is responsible for fixing the fault. A data fault needs a conversation with the partner, a code fault needs a change to Lena's script, and a configuration fault needs whoever owns that setting, such as the supervisor renewing an API key. The expired key in the worked example is a configuration fault.
20.4 Communicating
If indicators stopped flowing, tell consumers: "Since 06:00 no new MCX indicators have reached the DNS filter; existing blocks remain; fix expected by noon." Silence makes people assume protection that is not there.
The example message gives three facts: what stopped and since when, what still works, and when it should be fixed. Consumers such as the network team can then decide whether to watch new fraud domains manually until noon. Without the message, they would assume the DNS filter was receiving MCX indicators as usual.
20.5 Preventing recurrence
After the fix, add a check: a test that alerts when daily imports fall to zero, or when a new label value appears.
Each new check targets the specific fault that has just been seen. A zero-import alert would have caught the expired key on Monday morning rather than when someone noticed the platform, and a new-label alert catches a partner's spelling change before indicators are silently dropped. Lena's authentication-failure alert in the worked example is this kind of check. Each new check is listed in the fault log entry that prompted it, so the link between fault and prevention is kept.
20.6 Keeping a fault log
Each fault gets an entry: symptom, cause, fix, prevention, time lost. Patterns appear over months — for example, most faults follow partner format changes.
Recording time lost shows which faults cost the most, which helps decide where to put prevention effort. If most faults follow partner format changes, asking MCX for advance notice and test files is worth more than further work on Lena's own scripts. The log turns individual outages into evidence for that choice. Lena reviews the log with her supervisor every few months, looking for repeated causes rather than single incidents.
20.7 Asking for help
Escalate when the fault sits in another team's system. Bring evidence of where the flow stops so they can act quickly.
If the fault is in the DNS filter or a firewall rule, Lena cannot fix it and should not try. Evidence of where the flow stops, for example that exports leave the platform but the filter shows no new entries, lets the owning team start at the right place. That shortens the outage more than a general report that something is broken.
Partner format changes
Ask MCX to announce format changes in advance and keep a test file of the new format. Running it through the parser before the change date prevents a Monday morning outage.
Worked example
On Monday the platform shows zero MCX imports. Lena checks: TAXII requests return "unauthorised". The API key expired over the weekend. She informs consumers, the supervisor renews the key, imports resume, and Lena adds an alert for authentication failures and a calendar reminder 30 days before expiry.
Synthetic case. The outage is invented.
Errors and limits
Root causes can be multiple; do not stop at the first plausible one if symptoms remain.
Exercises
- EX058 — Key fault type. Classify the expired API key fault and name the prevention added. Rubric: 3 = configuration; auth-failure alert + expiry reminder; 2 = one; 1 = data fault; 0 = none.
- EX059 — Forward check. In what order should Lena check pipeline hand-offs? Rubric: 3 = source→parse→store→export→tool, one at a time; 2 = partial; 1 = random; 0 = none.
- EX060 — Outage message. Why must consumers be told when indicators stop flowing? Rubric: 3 = avoid false assumption of protection; plan around gap; 2 = partial; 1 = unnecessary; 0 = none.
Synthesis
Troubleshoot hand-off by hand-off, classify faults, communicate gaps and add checks so the same fault is caught earlier.
Continue studying — chapter 20 of 30
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →