◇ OpenCyber Academy
Doctoral research · Chapter 2 · English

Chapter 2 — OT, IoT and cyber-physical security: research frontier

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 2 — OT, IoT and cyber-physical security: research frontier

Lesson map

Lesson 02 published. Map, example, EX008.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["2.1 Why the frontier is hard to see"]
  N2["2.2 Research families"]
  N3["2.3 Standards as hypotheses"]
  N4["2.4 Appraisal: what makes an OT detection paper cred"]
  N5["2.6 Practical activity — Lab 2: code the map"]
  N6["2.7 A falsifiable gap"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX008"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["2.1 Why the frontier is hard to see"]
  N2["2.2 Research families"]
  N3["2.3 Standards as hypotheses"]
  N4["2.4 Appraisal: what makes an OT detection paper cred"]
  N5["2.6 Practical activity — Lab 2: code the map"]
  N6["2.7 A falsifiable gap"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]

[Learning outcomes and connection]
    |
    v
[2.1 Why the frontier is hard to see]
    |
    v
[2.2 Research families]
    |
    v
[2.3 Standards as hypotheses]
    |
    v
[2.4 Appraisal: what makes an OT detection paper cred]
    |
    v
[2.6 Practical activity — Lab 2: code the map]
    |
    v
[2.7 A falsifiable gap]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX008]

Learning outcomes and connection

After this chapter you can (1) organize the OT security literature into research families, (2) read standards as testable hypotheses, (3) appraise detection papers against known evaluation pitfalls, (4) use public incidents only at the level their analysts published, and (5) state a falsifiable gap. It builds on the claim ladder of Chapter 1 and feeds the proposal of Chapter 3.

2.1 Why the frontier is hard to see

OT security research is scattered across control engineering (fault detection, resilient control), computer security (intrusion detection, protocol analysis), safety engineering (hazard analysis, functional safety), and industrial practice (vendor white papers, government advisories). The same idea appears under different names: a control engineer's residual-based fault detection is a security researcher's physics-based anomaly detection. A scoping search must therefore use synonyms from each community and search engineering databases as well as security venues.

Keep a synonym table with a column per community and a row per idea, and update it as screening reveals new terms. Search engineering databases with the control vocabulary and security venues with the security vocabulary, then merge and deduplicate. Record which community each included study came from, so a reader can see whether the map is balanced or leans to one tradition.

2.2 Research families

Architecture and segmentation. The Purdue reference model, described in NIST SP 800-82 Rev. 3, layers enterprise (levels 4–5), operations management (3), supervisory control (2), basic control (1) and the physical process (0), with an industrial DMZ between IT and OT. ISA/IEC 62443-3-2 reframes segmentation as zones and conduits with target security levels. Research questions include whether segmentation designs actually reduce reachable attack paths and how cloud-connected IIoT erodes the layered model.

Protocol security. Classic industrial protocols such as Modbus were designed without authentication: the Modbus Application Protocol specification defines function codes and data models but no security fields. DNP3 added Secure Authentication; OPC UA includes a security model. Research studies adoption, implementation flaws and the cost of retrofitting security into deterministic networks.

Detection. Network-based detection models traffic; process-based (physics-based) detection models the plant. Giraldo et al. surveyed physics-based detection and found that evaluations rarely consider an adversary who knows the detector; Urbina et al. proposed measuring how much a stealthy attacker can move the process while staying below the detector's threshold — the impact-at-detection idea from Chapter 1.

Safety–security co-engineering. Hazard analysis methods (HAZOP, STPA) are being extended to adversarial causes; IEC 62443 and functional-safety standards are being aligned. Research asks how a security failure can defeat a safety function and how to certify both.

Threat evidence. MITRE ATT&CK for ICS catalogues adversary techniques such as Modify Parameter, Spoof Reporting Message and Manipulation of View, each grounded in public reporting. Public incidents — Stuxnet's manipulation of centrifuge drives while showing normal values, the 2015 Ukrainian distribution outages, and malware targeting safety instrumented systems (TRITON/TRISIS) — show that manipulation of view, the replay of normal values to operators, is a documented adversary goal, not a speculative one.

2.3 Standards as hypotheses

A standard encodes expert belief: "zones with security level 2 resist casual attackers". Treat such statements as hypotheses. A thesis can measure whether a zone design reduces reachability, whether a recommended alarm practice reduces operator overload, or whether a security level is achievable within a controller's scan-time budget. Do not cite a standard as evidence that its recommendations work; cite it as the claim you test.

Write each tested statement in the thesis as the standard puts it, then as the measurable hypothesis you derived from it, so readers can judge the translation. A null result is useful: if a recommended zone design does not reduce reachability in your topology, that says something about the design or the topology, and both are worth reporting.

2.4 Appraisal: what makes an OT detection paper credible

Apply Sommer and Paxson's warning — anomaly detection works poorly when the "normal" space is open and attacks are rare — and the Arp et al. checklist. Ask of every paper: Was the dataset a testbed or a plant? Were attacks generated by the same people who built the detector? Is the adversary aware of the detector? Is the threshold chosen on the test set? Is impact at detection reported? Public datasets such as iTrust's SWaT come from a real (scaled-down) water treatment testbed, which makes them valuable, but each dataset has a fixed attack set and a fixed plant; generalization claims beyond them need a second context.

2.5 Worked example: appraising synthetic studies S1–S8

Study (synthetic) Data Adversary aware? Threshold source Impact reported? Verdict
S1 one public testbed dataset no test set no optimistic
S2 simulation yes (bounded) validation yes strong but single plant
S3 plant logs, no attacks — — — false-alarm study only
S4 testbed no test set no point-adjusted F1
S5 simulation + testbed partial validation partial promising
S6 network only no validation no rung 1 only
S7 testbed, multi-sensor spoof yes validation yes shows replay+flow evasion
S8 survey — — — map

The pattern is the gap: no study combines (a) a detector-aware adversary, (b) thresholds fixed before testing, (c) impact at detection, and (d) validation on a second, independent plant.

2.6 Practical activity — Lab 2: code the map

Copy the table into a CSV and count, with Python's csv module, how many studies satisfy each criterion. Expected counts from the table: adversary aware fully = 2 (S2, S7), validation thresholds = 4 (S2, S5, S6, S7), impact reported fully = 2 (S2, S7), two contexts = 1 (S5). Change one coding decision and note how the gap statement changes; record that sensitivity in your notes.

A small change can move a study across the line. If S5's adversary awareness is coded as full rather than partial, three studies satisfy that criterion instead of two, but none yet combines all four properties, so the gap survives. Record each coding rule with an example, and ask a second coder to code the table independently before you rely on it.

2.7 A falsifiable gap

Weak gap: "Physics-based detection is understudied." Strong gap: "No evaluation reports both detection delay and maximum process deviation at detection for sensor-replay attacks on a level loop, with thresholds fixed in advance, on two independent plants; we predict that a mass-balance residual reduces delay relative to a band alarm, and that the advantage disappears when the attacker also controls the independent flow sensor." The strong version names the condition under which the contribution fails.

The strong gap predicts its own failure, which the Setpoint Study later confirms as class B. That prediction is what lets a committee judge the thesis fairly: if the residual detector had also caught class B, the gap would need revisiting, because a detector should not be able to see through a consistent lie on both sensors without some other independent signal.

2.8 Common errors and limits

Citing vendor marketing as evidence; treating ATT&CK techniques as frequencies (they are documented possibilities, not base rates); claiming novelty because of a new dataset name; describing incidents beyond what public analyses state.

A vendor paper can point to a question but cannot answer it. ATT&CK tells you that manipulation of view has been seen, not how often. A new dataset is novel only if it lets you test something you could not test before. When describing Stuxnet, Ukraine or TRITON, say what the cited analysts reported and stop there.

Exercises — chapter 2

Chapter synthesis

The frontier lies across communities; read it with synonyms, treat standards as hypotheses and appraise detection papers for adversary awareness, threshold leakage, impact reporting and second-context validation. A gap is useful only when it says how it could be closed and how the closing could fail.

Continue studying — chapter 02 of 08

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →