Chapter 24 — OT, IoT and cyber-physical security: controls
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Control families"]
N2["24.2 Matching controls to S-3"]
N3["24.3 Controls that hurt"]
N4["24.4 Legacy and compensating controls"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 Control families"]
N2["24.2 Matching controls to S-3"]
N3["24.3 Controls that hurt"]
N4["24.4 Legacy and compensating controls"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Control families]
|
v
[24.2 Matching controls to S-3]
|
v
[24.3 Controls that hurt]
|
v
[24.4 Legacy and compensating controls]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) choose preventive, detective and corrective controls for a scenario; (2) map them to IEC 62443-3-3 foundational requirements; (3) recognise controls that could harm availability or safety; and (4) design compensating controls for legacy devices.
24.1 Control families
IEC 62443-3-3 groups system requirements under seven foundational requirements: identification and authentication control (FR 1), use control (FR 2), system integrity (FR 3), data confidentiality (FR 4), restricted data flow (FR 5), timely response to events (FR 6) and resource availability (FR 7). Using them as headings keeps a control plan balanced.
Maya's control table for S-3 shows the effect: five controls spread over FR 1, 3, 5, 6 and 7. Without the headings, a first draft tends to list three firewall rules and nothing for recovery, which is FR 7's concern. The empty columns, FR 2 and FR 4 here, are not automatically gaps, but each needs a sentence explaining why it does not apply to this scenario.
24.2 Matching controls to S-3
For the setpoint-manipulation scenario: restrict data flow with a firewall allow-list (FR 5); require named accounts on HMI-1 (FR 1); add operator-confirmed setpoint limits in PLC-H logic (FR 3 in effect, and a process control); alert on setpoint writes from any host other than HMI-1 (FR 6); keep tested backups of PLC logic (FR 7).
Maya's table records the setpoint-limit row in full: PLC-H rejects supply setpoints outside 70–110 °C unless engineer mode is active, FR 3, preventive, with the failure mode that it blocks a legitimate out-of-band change during commissioning, mitigated by logged engineer mode, owned by control engineering.
24.3 Controls that hurt
Active intrusion prevention that drops "suspicious" Modbus writes can block a legitimate emergency command. Account lockout after failed logins can lock an operator out during an incident. Each control needs a failure-mode question: if it misfires, what happens to the process?
Maya's setpoint-limit row asks this question and answers it: during commissioning, a legitimate setpoint outside 70–110 °C would be refused, so engineer mode, with logging, exists for that case. The same question applied to an intrusion-prevention device in line with PLC-H has a worse answer: if it drops an operator's emergency write during a cold-night fault, the process loses its only fast recovery path. That is why LDHP monitors passively and enforces with the firewall's allow-list, which blocks by source rather than by guessing intent.
24.4 Legacy and compensating controls
PLC-H's firmware cannot authenticate Modbus clients. The compensating approach is to surround it: allow-list conduits so only HMI-1 and HIST-1 can reach it, monitor traffic passively, and protect the engineering workstation that can change its logic.
Chapter 27's allow-list makes the first measure testable: HMI-1 may write registers 100–119, HIST-1 may only read, and every other source is blocked. The monitoring is the passive sensor on the control switch, and EWS-1's protection includes forwarding its driver-load events, which Maya adds after reading AA22-103A in Chapter 31. None of these changes PLC-H; together they decide who can reach it.
Worked example (synthetic LDHP)
Maya's table has columns: control, FR, prevents/detects/corrects, failure mode, owner. The setpoint-limit row reads: "PLC-H rejects supply setpoints outside 70–110 °C unless engineer mode is active — FR 3 — prevents — failure mode: blocks a legitimate out-of-band change during commissioning; mitigated by engineer mode with logging — owner: control engineering."
Synthetic case — Lakeside District Heating Plant. Limits and owners are invented.
Errors and limits
Controls listed but not tested provide no assurance. Mapping to FRs shows coverage of categories, not that a requirement is satisfied at the target security level.
Exercises
- EX070 — Mapping a meter-zone control. Give one control for each of FR 1, FR 5 and FR 6 in the meter zone. Rubric: 3 = three relevant controls correctly mapped; 2 = two; 1 = one; 0 = none.
- EX071 — Asking the failure-mode question. What is the failure mode of locking HMI accounts after three bad passwords, and a safer alternative? Rubric: 3 = operator locked out in emergency; alert-and-delay or exempt control-room consoles with physical security; 2 = one; 1 = vague; 0 = none.
- EX072 — Compensating for a device that cannot authenticate. List three compensating controls for a meter gateway that cannot change its default password. Rubric: 3 = isolate, restrict management interface, monitor, plan replacement (any three); 2 = two; 1 = one; 0 = none.
Synthesis
A good OT control plan covers all seven foundational requirements, asks how each control fails, and surrounds what cannot be fixed.
Continue studying — chapter 24 of 40
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →