Chapter 33 — Threat intelligence and OSINT: safety and resilience
Lesson map
Lesson 33 published. Map, example, EX097.
flowchart TD
N0["Learning outcomes"]
N1["33.1 How intelligence can hurt operations"]
N2["33.2 Interlocks"]
N3["33.3 Resilience to source loss"]
N4["33.4 Rollback"]
N5["33.5 Coordinating with operations"]
N6["Practice note — safety cases"]
N7["After an override"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX097"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["33.1 How intelligence can hurt operations"]
N2["33.2 Interlocks"]
N3["33.3 Resilience to source loss"]
N4["33.4 Rollback"]
N5["33.5 Coordinating with operations"]
N6["Practice note — safety cases"]
N7["After an override"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX097"]
[Learning outcomes]
|
v
[33.1 How intelligence can hurt operations]
|
v
[33.2 Interlocks]
|
v
[33.3 Resilience to source loss]
|
v
[33.4 Rollback]
|
v
[33.5 Coordinating with operations]
|
v
[Practice note — safety cases]
|
v
[After an override]
|
v
[Worked example] --> [Exercise EX097]
Learning outcomes
You will (1) analyse how CTI outputs could harm operational technology; (2) design safety interlocks for automated actions; (3) plan resilience against loss of feeds or partners; (4) rehearse safe rollback.
33.1 How intelligence can hurt operations
An over-broad block on an OT firewall could cut a SCADA master from remote terminal units, removing visibility of the grid. A mistaken "malicious" tag on a vendor update server could block a safety-relevant patch. In critical infrastructure, false positives have physical consequences.
Kofi's design reviews ask of every automated action what physical effect a wrong decision could have. For corporate IT the answer is usually a blocked website and a ticket. For OT it may be a control room losing sight of part of the network during a storm, when operators most need it. That difference justifies different rules for the two environments.
33.2 Interlocks
Lantern applies interlocks: no automatic action on OT segments; an allow-list of protected operational addresses that no block may include; a maximum change size per push; and two-person approval for any OT rule. These mirror safety engineering's idea that one failure should not cause harm.
Kofi tests each interlock with a synthetic push designed to trip it: a list containing a protected address, a list far larger than the limit, an approval by one person only. Each test must be refused and logged.
33.3 Resilience to source loss
If a key partner stops sharing, detection should degrade gracefully. Diverse sources, internal telemetry analytics and behaviour-based detections mapped to ATT&CK reduce dependence on any single feed.
Kofi tested this by replaying a month of synthetic traffic with the largest partner removed. Detections fell, but the behavioural rules still caught most of the simulated intrusions that the indicators had caught, though often later. The result told BEN how exposed it would be if that partner stopped sharing and supported investing in internal analytics.
33.4 Rollback
Every push records the previous rule set. A tested one-command rollback restores it within minutes. Rollback drills run quarterly in the test environment.
Kofi's drill measures how long the rollback takes and checks that the restored rules match the stored copy exactly. The first drill took twenty minutes because the command needed a credential that nobody had to hand; the runbook now names where it is kept. A rollback that is never practised tends to fail the first time it is really needed.
33.5 Coordinating with operations
OT engineers own operational decisions. Lantern provides advice and evidence; it does not override operations.
In practice this means Lantern's outputs to OT are recommendations with evidence attached. An OT engineer may decline a block because it would interrupt a planned maintenance window, and that decision stands. Kofi records the reason, so analysts can see why the block did not happen. If the threat grows, the analysts raise it again with new evidence rather than going around the operations team. Both teams review declined recommendations together each month.
Practice note — safety cases
A short safety argument states the hazard, the interlocks that prevent it and the evidence each interlock works. Reviewers can then challenge a specific link rather than the whole design.
After an override
Whenever an engineer overrides an interlock, the next working day includes a short review of why, whether the interlock was wrong, and whether the rule should change.
Worked example
A partner tags the address of BEN's relay vendor's update server as malicious after a compromise elsewhere. The protected-address interlock blocks the automatic push; OT engineers review, confirm the vendor's server is clean for BEN's region, and record the decision.
Synthetic case. The vendor and tag are invented.
Errors and limits
Interlocks can be bypassed under pressure; audit every override. Safety analysis must involve OT engineers.
Exercises
- EX097 — Physical harm. Give one way an IT-style block could cause operational harm in a grid. Rubric: 3 = specific mechanism (cut SCADA visibility, block safety patch); 2 = vague; 1 = minimal attempt; 0 = none.
- EX098 — Interlock list. Name three interlocks Lantern applies to OT actions. Rubric: 3 = three of no auto OT/protected allow-list/max change size/two-person approval; 2 = two; 1 = one; 0 = none.
- EX099 — Source loss. How does ATT&CK-mapped behavioural detection help when a feed disappears? Rubric: 3 = detects techniques independent of feed indicators; 2 = partial; 1 = no help; 0 = none.
Synthesis
Treat false positives as physical risks, interlock automated actions, diversify sources and drill rollback.
Continue studying — chapter 33 of 50
← Chapter 32 (draft) · Course chapter index · Chapter 34 (draft) →