Chapter 22 — OT, IoT and cyber-physical security: data and dependencies
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Inventory first"]
N2["22.2 Dependency chains"]
N3["22.3 Supplier dependencies"]
N4["22.4 People as dependencies"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Inventory first"]
N2["22.2 Dependency chains"]
N3["22.3 Supplier dependencies"]
N4["22.4 People as dependencies"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Inventory first]
|
v
[22.2 Dependency chains]
|
v
[22.3 Supplier dependencies]
|
v
[22.4 People as dependencies]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) build an asset and dependency inventory; (2) trace data flows from field device to business use; (3) find single points of failure, including people and suppliers; and (4) use a software bill of materials to reason about inherited vulnerabilities.
22.1 Inventory first
You cannot protect what you have not listed. NIST SP 800-82r3 places asset inventory at the start of an OT security programme. A useful inventory records not only make, model and firmware but also function, zone, owner, criticality and what depends on the asset.
Maya's dependency list in this chapter starts from such an inventory: TT-101, PLC-H with firmware v3.2, FV-12, control switch SW-2, HMI-1, licence server LIC-1, EWS-1 and the vendor support contract. Recording v3.2 is what would let LDHP answer a PLC firmware advisory the same day; recording LIC-1 as a dependency of HMI-1 is what exposed a single point of failure no network diagram showed.
22.2 Dependency chains
PLC-H depends on 24 V power, its I/O modules, the control network switch, the engineering workstation for logic changes and the vendor for firmware. HMI-1 depends on Windows, the HMI runtime licence server and the domain controller for named accounts. A licence server outage that blanks HMIs is an availability incident with a cyber root cause, even with no attacker.
Maya marked LIC-1 as the hidden single point of failure and asked the HMI vendor about a licence grace period, which would let HMI-1 keep running if LIC-1 were down for a night.
22.3 Supplier dependencies
The meter gateway firmware embeds an open-source TCP/IP stack and a TLS library. If a vulnerability is published in the stack, every gateway inherits it. A software bill of materials (SBOM) lists such components so that, when an advisory appears, the plant can answer "are we affected?" in hours rather than weeks. CISA ICS advisories identify affected products and versions, which only helps if your inventory records versions.
Chapter 30's MTR-C is the case where an SBOM alone is not enough: even if it shows an affected stack, the device cannot be updated.
22.4 People as dependencies
If only one engineer can restore PLC-H's logic from backup, that person is a single point of failure. Document procedures and cross-train.
At LDHP the risk is sharpest at night in winter. If PLC-H's logic were corrupted, by a failed download from EWS-1 or deliberately, restoring it needs the last good program file, the matching firmware version (v3.2 in Maya's list) and someone who knows the restore steps on that controller. If that person is on leave in January, the boiler runs on local manual control until they return. Maya's recommendation was a written restore procedure, tested on the bench once a year by a second engineer, with the backup file's hash recorded beside each tested restore.
Worked example (synthetic LDHP)
Maya writes the dependency list for the supply-temperature function: TT-101, PLC-H (firmware v3.2), FV-12, control switch SW-2, HMI-1, licence server LIC-1, engineering workstation EWS-1, vendor support contract. She marks LIC-1 as a hidden single point of failure and recommends a licence grace-period check with the HMI vendor.
Synthetic case — Lakeside District Heating Plant. Versions and names are invented.
Errors and limits
An inventory built only from network scanning misses serial devices and switched-off spares, and active scanning can disturb fragile devices; combine passive capture, configuration exports and walk-downs.
Exercises
- EX064 — Fields of an inventory record. List six fields for an OT asset inventory entry. Rubric: 3 = six including firmware version, zone and criticality; 2 = four or five; 1 = make/model only; 0 = none.
- EX065 — Answering an advisory. A CISA advisory lists the gateway's TLS library versions 2.0–2.4 as affected. What two inventory facts decide whether LDHP is affected? Rubric: 3 = gateway firmware version and its SBOM component version; 2 = one; 1 = vendor name only; 0 = none.
- EX066 — A hidden single point. Identify one non-network single point of failure at LDHP and a mitigation. Rubric: 3 = e.g. one engineer, licence server, sole spare; with mitigation; 2 = point only; 1 = network device only; 0 = none.
Synthesis
Inventories, dependency chains and SBOMs let a plant reason about failures and advisories before they arrive.
Continue studying — chapter 22 of 40
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →