Chapter 26 — OT, IoT and cyber-physical security: methods II
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Data-flow diagrams"]
N2["26.2 STRIDE per element"]
N3["26.3 Abuse cases"]
N4["26.4 Mapping to ATT&CK"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Data-flow diagrams"]
N2["26.2 STRIDE per element"]
N3["26.3 Abuse cases"]
N4["26.4 Mapping to ATT&CK"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Data-flow diagrams]
|
v
[26.2 STRIDE per element]
|
v
[26.3 Abuse cases]
|
v
[26.4 Mapping to ATT&CK]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) apply STRIDE-style threat modelling to a data-flow diagram of the meter system; (2) translate threats into ATT&CK for ICS techniques where applicable; (3) write abuse cases with preconditions; and (4) prioritise mitigations against the consequence ranking from Chapter 23.
26.1 Data-flow diagrams
Draw processes (circles), data stores (parallel lines), external entities (boxes) and data flows (arrows), then mark trust boundaries where data crosses from one zone to another. LDHP's meter system: meters → gateway (radio) → gateway → billing cloud (TLS) → cloud → billing database → historian replica (one-way export for network balancing).
For LDHP, the radio link from meters to gateway and the gateway's TLS uplink to the billing cloud are trust boundaries, and so is the one-way export into the historian replica. Each boundary is where Maya's STRIDE table asks its questions; a diagram without them would put the household readings and the boiler data in the same trust zone.
26.2 STRIDE per element
Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege give a prompt list. At the meter–gateway radio link: spoofing (a fake meter), tampering (altered readings), information disclosure (household consumption). At the gateway: elevation of privilege via its web interface. STRIDE was designed for software, so add an OT prompt: physical consequence — can this threat change heat delivery?
Maya's table produced 14 threats in total. The top three by consequence were gateway takeover pushing malicious configuration to every meter in its street, tampering with readings in transit, and a cloud-account compromise exposing every household's history.
26.3 Abuse cases
An abuse case states actor, precondition, action and outcome. "A tenant with radio equipment and knowledge of the meter protocol (precondition: no message authentication on the radio link) replays last month's lower readings (action) so that the bill is reduced (outcome)." Writing preconditions makes the mitigation obvious: authenticate readings and use counters, as in Chapter 17.
The tenant replay ranks low in Maya's table because its outcome is one reduced bill; the abuse case still matters because the same missing counter would let a gateway-level attacker replay a whole street. Chapter 17's HMAC lab shows the fix: the replayed message is rejected on its counter even though its tag is correct.
26.4 Mapping to ATT&CK
Not every IoT threat has an ATT&CK for ICS technique, and that is fine. Where it does — gateway reached from the internet (T0883), remote services abused (T0886) — record the ID to link with threat intelligence.
For LDHP's meter system, T0883 fits a gateway management interface reachable from the internet, and T0886 fits abuse of a remote service used to manage gateways. Household-level threats, such as one tenant replaying last month's reading, have no ATT&CK for ICS technique, because the framework describes attacks on industrial control rather than billing fraud. Maya's table leaves those rows blank in the technique column rather than forcing a poor match, and notes the ETSI EN 303 645 provision that applies instead.
Worked example (synthetic LDHP)
Maya's table yields 14 threats. Ranked by consequence, the top three are: gateway takeover pushing malicious configuration to all meters in its street; tampering with readings in transit; cloud account compromise exposing every household's history. Replay by one tenant ranks lower: real, but limited to one bill.
Synthetic case — Lakeside District Heating Plant. The threat list is an exercise output, not an assessment of a real product.
Errors and limits
A threat model is only as complete as its diagram. STRIDE lists threats, not likelihood. Re-run the model when the architecture changes.
Exercises
- EX076 — STRIDE at the trust boundary. Name one threat for each of S, T and D at the gateway-to-cloud flow. Rubric: 3 = three plausible threats; 2 = two; 1 = one; 0 = none.
- EX077 — Writing an abuse case. Write an abuse case for the gateway's web interface. Rubric: 3 = actor, precondition, action, outcome; 2 = three; 1 = vague; 0 = none.
- EX078 — Ranking replay below gateway takeover. Justify the ranking. Rubric: 3 = scope of impact (one bill vs a whole street/configuration) and consequence; 2 = partial; 1 = "less likely" only; 0 = none.
Synthesis
Threat modelling turns a diagram into a ranked list of abuse cases whose preconditions point directly to mitigations.
Continue studying — chapter 26 of 40
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →