◇ OpenCyber Academy
Engineering · Chapter 21 · English

Chapter 21 — OT, IoT and cyber-physical security: requirements

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 21 — OT, IoT and cyber-physical security: requirements

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 Sources"]
  N2["21.2 Three families"]
  N3["21.3 Acceptance criteria"]
  N4["Practice note"]
  N5["21.1b MoSCoW under safety"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 Sources"]
  N2["21.2 Three families"]
  N3["21.3 Acceptance criteria"]
  N4["Practice note"]
  N5["21.1b MoSCoW under safety"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 Sources]
    |
    v
[21.2 Three families]
    |
    v
[21.3 Acceptance criteria]
    |
    v
[Practice note]
    |
    v
[21.1b MoSCoW under safety]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) elicit requirements from process safety, operations and security; (2) separate functional, safety and measurement requirements; (3) write acceptance criteria a tester can run on synthetic fixtures.

21.1 Sources

Process safety wants independent protection layers. Operations wants viewing without downtime. Security wants deny-by-default conduits. Elicitation interviews produce shall-statements tagged by source. Conflicts (convenience viewing vs SIS isolation) are recorded, not papered over.

At ABP, Lena interviewed the process-safety engineer, the shift leads, the control engineers and the IT network team separately, then brought conflicts to a joint meeting. The clearest conflict was the remote-viewing rule FW-12, which operations valued and safety could not accept. It was recorded with both positions, and the resolution, viewing through the DMZ replica, became a requirement with an owner.

21.2 Three families

Functional: "The serial monitor shall decode Modbus RTU on trunk A and emit allow/deny decisions." Safety: "If the allow-list file does not load, the monitor shall fail closed (drop all non-essential traffic or alarm and require human action per the design)." Measurement: "CNHP shall report planned-vs-observed ATT&CK for ICS technique coverage with denominators." Safety requirements win ties.

Lena tags each CNHP requirement with its family, so reviews can check that safety ones are tested first. Ties are settled in writing.

21.3 Acceptance criteria

Each requirement has a Given/When/Then on synthetic data. Example: Given deny of L2 to L1-SIS, When reachability runs from L4, Then L1-SIS not in the reachable set. Criteria that need a live plant write are rejected at review.

Synthetic case — Ashford Batch Plant. Safety requirement S-1 "fail closed on missing allow-list" failed its acceptance test when a typo path returned PASS. The fix shipped before any plant window.

Criteria are reviewed with the requirement's owner. Each criterion is a test.

21.4 Errors and limits

Stakeholders invent requirements mid-window; park them in a backlog with an AUTH ticket, do not hot-patch production monitors during a batch.

When someone asks for a new monitor rule during a batch, Lena records it in the backlog with an authorization ticket and evaluates it after the window. Changing a production monitor mid-batch risks an outage or a fail-open bug that nobody has tested. The backlog item names who asked, why and when it will be reviewed, so the request is not lost and the person who raised it sees it handled.

Practice note

CNHP acceptance tests carry the requirement id in their name and fail CI when skipped, so a monitor requirement without a test shows up in the build. Orphan Must requirements are either tested or formally deferred with an executive owner.

21.1b MoSCoW under safety

Must/Should/Could prioritization still places all safety requirements in Must. A Could that weakens Must (optional deny of write codes) is reclassified or rejected. Product managers do not outvote fail-closed. Log fields carry the requirement id as well (req=S-1), so a deny event can be traced to the requirement it enforces.

At ABP, S-1 and R-12 are both Must items, and no product decision can move them down. A request to make write-code denies optional for convenience was rejected on this basis, and the rejection is recorded with the requirement it would have weakened.

Exercises

Synthesis

CNHP requirements come from the plant's operators and engineers, split into families, and ship with acceptance tests on synthetic plant fixtures.

Continue studying — chapter 21 of 50

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →