Chapter 11 — OT, IoT and cyber-physical security: assets and context
Lesson map
Lesson 11 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Two sources, neither complete"]
N2["11.2 Reading the conflicts"]
N3["11.3 Context"]
N4["11.4 Unknown devices"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Two sources, neither complete"]
N2["11.2 Reading the conflicts"]
N3["11.3 Context"]
N4["11.4 Unknown devices"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]
[Learning outcomes]
|
v
[11.1 Two sources, neither complete]
|
v
[11.2 Reading the conflicts]
|
v
[11.3 Context]
|
v
[11.4 Unknown devices]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) build an inventory by combining documentation with passive observation; (2) interpret conflicts between sources; (3) add business context — function and consequence — to each asset; and (4) decide what to do about unknown devices.
11.1 Two sources, neither complete
Documentation from the refrigeration contractor lists what was installed; passive observation of network traffic shows what is talking now. Documentation misses later additions; observation misses devices that are quiet or switched off. NIST SP 800-82r3 recommends combining methods rather than relying on active scanning, which can disturb fragile devices.
"""Lab 11: merge two synthetic NCS asset lists and flag conflicts (no scanning)."""
eng = {"PLC-R1": "fw 2.4", "PLC-R2": "fw 2.4", "HMI-C": "win10-ltsc", "GW-LOG": "fw 1.9"}
seen = {"PLC-R1": "fw 2.4", "PLC-R2": "fw 2.1", "GW-LOG": "fw 1.9", "CAM-DOCK": "fw ?"}
for a in sorted(set(eng) | set(seen)):
e, s = eng.get(a), seen.get(a)
status = "match" if e == s else ("only-in-docs" if s is None else "only-on-network" if e is None else "VERSION-CONFLICT")
print(f"{a:9} docs={e or '-':11} network={s or '-':8} {status}")
Run with python3 lab_inv.py. Verified output:
CAM-DOCK docs=- network=fw ? only-on-network
GW-LOG docs=fw 1.9 network=fw 1.9 match
HMI-C docs=win10-ltsc network=- only-in-docs
PLC-R1 docs=fw 2.4 network=fw 2.4 match
PLC-R2 docs=fw 2.4 network=fw 2.1 VERSION-CONFLICT
At NCS, the documentation lacked CAM-DOCK, and the observation lacked HMI-C; neither source alone was the inventory.
The comparison also produced PLC-R2's version conflict, which only a walk-down could settle.
11.2 Reading the conflicts
CAM-DOCK appears only on the network: someone installed a camera without updating records. HMI-C appears only in documentation: it may have been quiet during the observation window, or its traffic was not captured. PLC-R2 shows a version conflict — documentation says 2.4, the network shows 2.1 — which matters because an advisory might affect 2.1 but not 2.4.
Priya resolved the PLC-R2 conflict by walking the machine room with the contractor and reading the version from the front panel: 2.1. The documentation was wrong; the controller had never been upgraded. She corrected the inventory with the walk-down as source.
11.3 Context
For each asset add function, zone, owner and consequence of loss. The camera's consequence is low for cooling but it may be an entry point; PLC-R2's consequence is high, so its version conflict goes first.
Priya's notebook gives each of the five rows those four fields. PLC-R2: compressor control, refrigeration control zone, contractor and facilities manager, loss of cooling within hours. CAM-DOCK: dock video, currently on the logging network, logistics team, low for cooling but a possible foothold. The consequence column is what turns five statuses into an ordered work list.
11.4 Unknown devices
An unknown device is investigated physically before anything else: find it, identify the owner, decide whether it belongs. Never "test" an unknown device by sending it traffic.
At NCS, the unknown address 10.4.2.77 seen in Chapter 19 was traced this way: a physical search found a dock printer plugged into a camera-zone port, installed by the logistics team with an address copied from another site's plan. Nobody sent it a packet to find out what it was. It was moved, re-addressed and added to the inventory with logistics as owner.
Worked example (synthetic NCS)
Priya walks the machine room with the contractor and reads PLC-R2's version from its front-panel display: 2.1. The documentation was wrong; the controller was never upgraded. She corrects the inventory, records the walk-down as the source, and opens a ticket to plan the upgrade with the contractor.
Synthetic case — Northgate Cold Storage. The lab data and the walk-down are invented.
Errors and limits
Passive observation depends on capture location; a mirror port on one switch sees only that switch's traffic. A device's self-reported version string can be wrong or spoofed.
Exercises
- EX031 — Explaining "only-in-docs". Give two possible reasons HMI-C did not appear in the network observation. Rubric: 3 = quiet/off during window; capture point did not see its traffic; 2 = one; 1 = "it doesn't exist"; 0 = none.
- EX032 — Prioritising conflicts. Which conflict does Priya handle first and why? Rubric: 3 = PLC-R2 version, high consequence and advisory relevance; 2 = choice only; 1 = camera; 0 = none.
- EX033 — Adding a fifth device. Add
"SENS-NH3": "fw 3.0"toseenonly. What does the lab print for it? Rubric: 3 = "SENS-NH3 docs=- network=fw 3.0 only-on-network"; 2 = status only; 1 = match; 0 = none.
Synthesis
An inventory worth trusting reconciles documents, observation and walk-downs, and puts consequence beside every row.
Continue studying — chapter 11 of 30
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →