Chapter 22 — Critical infrastructure and sector security: system and data models
Lesson map
Lesson 22 published. Map, example, EX043.
flowchart TD
N0["Learning outcomes and connection"]
N1["22.1 Inventory first"]
N2["22.2 Three views of a system"]
N3["22.3 Degraded states"]
N4["22.4 The model as sensitive information"]
N5["22.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX043"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["22.1 Inventory first"]
N2["22.2 Three views of a system"]
N3["22.3 Degraded states"]
N4["22.4 The model as sensitive information"]
N5["22.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX043"]
[Learning outcomes and connection]
|
v
[22.1 Inventory first]
|
v
[22.2 Three views of a system]
|
v
[22.3 Degraded states]
|
v
[22.4 The model as sensitive information]
|
v
[22.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX043]
Learning outcomes and connection
After this chapter you can (1) build an asset inventory and a system model that supports security analysis; (2) model functional dependencies, data flows and trust boundaries; (3) represent degraded states, not just up/down; and (4) keep the model current and protected as sensitive information. It builds on Chapters 2, 13 and 21 and prepares Chapter 23 (threat and failure analysis).
22.1 Inventory first
You cannot protect what you do not know. An OT asset inventory records, for each device: identity, location, function, zone, network addresses, hardware and firmware versions, communication relationships, owner, criticality and support status. Build it from several sources and reconcile: design documents, passive network monitoring, configuration exports and site walk-downs. Each source misses things — documents drift, passive monitoring misses quiet devices, walk-downs miss virtual ones.
For LRWA, the inventory covers all 42 field stations, the SCADA pair and the gateways, built from design documents, passive monitoring at the control switch and LTE head-end, and site visits.
22.2 Three views of a system
- Functional view: what the system does — functions such as "maintain reservoir level", "disinfect", "provide operator visibility" — and which functions depend on which (Lab 2's graph).
- Physical/network view: where assets are and how they connect — zones, conduits, links.
- Data-flow view: which data move where, in which direction, with which protection, across which trust boundaries. Data-flow diagrams with trust boundaries are the input to threat modelling (Chapter 23).
Keep the views linked: every function maps to the assets that implement it; every flow maps to a conduit.
22.3 Degraded states
Up/down graphs are useful (Chapter 2) but insufficient. A pumping station may be in remote automatic, local automatic, local manual, degraded (one pump of two) or out of service; the reservoir may be normal, low or below floor. A state model for each critical function, with transitions caused by faults, attacks and operator actions, lets you ask: from normal operation, what sequence of events reaches an unacceptable state, and which control interrupts it?
PS4 is the obvious first candidate at LRWA, because it feeds the hospital directly.
22.4 The model as sensitive information
An accurate system model is a map for an adversary. Store it with access control, version it, and publish only abstractions. Treat exports to vendors and consultants under agreements. Keep a model change log linked to configuration management (Chapter 16) so that the model stays current; a model that is a year out of date is a liability presented as an asset.
LRWA's model, including the dependency graph and the zone allowlists, is held with access control and versioned with each configuration change.
22.5 Worked example: Hollin Hill functional model (synthetic)
Function F1 "supply St Brenna's" is satisfied if either path A (PS4 direct) or path B (Hollin Hill reservoir fed by PS3) is available, and the hospital's on-site tank bridges the gap during switchover. Path A needs PS4, its power (feeder F2 or generator) and its control (local automatic suffices). Path B needs the reservoir above floor and PS3 with power from feeder F1. Telemetry is not needed for supply — local automatic control keeps pumps running — but is needed for visibility (F3) and remote intervention. This insight changes priorities: the most important security property for F1 is that nobody can remotely command pumps into an unsafe state, while loss of telemetry is a visibility problem with a 72 h local-automatic buffer (R-local). Chapter 23's fault tree formalises exactly this AND/OR structure.
22.6 Practical activity
Extend Lab 2 so that each node has an AND or OR dependency type, and implement an availability function that evaluates whether hospital_supply works given a set of failed nodes. Test with the failures {grid_f1}, {ps4} and {ps4, grid_f1}.
Model the hospital supply as an OR of its two paths, with PS4's power as an OR of feeder F2 and the generator. Keep telemetry out of the supply function, as the worked example argues, but keep it in a separate visibility function so its loss still shows up. Then check your three results against EX043: the supply should survive losing feeder F1 or losing PS4, and fail only when both are lost.
22.7 Common errors and limits
- Inventory from one source only.
- Diagrams without trust boundaries or data direction.
- Up/down models where degraded modes decide outcomes.
- Models that are never updated, or that are shared freely.
- Treating telemetry loss and control misuse as the same consequence.
The Hollin Hill model shows the last error clearly: treating telemetry loss as loss of supply would send TMRP's budget to communications redundancy, when the property that actually protects the hospital is that pumps cannot be commanded remotely into an unsafe state.
Exercises — chapter 22
EX043 — AND/OR evaluation. Objective: implement and use a mixed dependency model. Inputs: §22.6. Steps: implement, run the three tests, report results. Expected evidence: code and output. Rubric: 3 = correct semantics; {grid_f1} → supply survives via PS4 if PS4 runs in local automatic (no LTE needed); {ps4} → survives via reservoir; {ps4, grid_f1} → fails; 2 = telemetry wrongly required for supply; 1 = not run; 0 = none.
EX044 — State model. Objective: model degraded states. Inputs: PS4 modes in §22.3. Steps: draw a state model with at least five states and the events (fault, attack, operator action) between them; identify one path from remote automatic to out of service that a remote attacker could drive, and the control that breaks it. Expected evidence: state table and analysis. Rubric: 3 = coherent states and events, attack path realistic, control breaks it (e.g., trip reset requires local action); 2 = states only; 1 = up/down only; 0 = none.
Chapter synthesis
Build the inventory from several reconciled sources, model the system in functional, physical and data-flow views with trust boundaries, represent degraded modes explicitly, and keep the model current and protected. Good models separate visibility from control and show which property actually protects the service.
Continue studying — chapter 22 of 50
← Chapter 21 · Course chapter index · Chapter 23 →
Continue to the next authored lesson.