Chapter 24 — Critical infrastructure and sector security: controls
Lesson map
Lesson 24 published. Map, example, EX047.
flowchart TD
N0["Learning outcomes and connection"]
N1["24.1 Frameworks as organisers"]
N2["24.2 Types of control"]
N3["24.3 Mapping and gaps"]
N4["24.4 OT constraints"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX047"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["24.1 Frameworks as organisers"]
N2["24.2 Types of control"]
N3["24.3 Mapping and gaps"]
N4["24.4 OT constraints"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX047"]
[Learning outcomes and connection]
|
v
[24.1 Frameworks as organisers]
|
v
[24.2 Types of control]
|
v
[24.3 Mapping and gaps]
|
v
[24.4 OT constraints]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX047]
Learning outcomes and connection
After this chapter you can (1) use a framework — NIST CSF 2.0, the UK CAF or sector goals — to organise controls; (2) classify controls by type (preventive, detective, corrective) and nature (technical, procedural, physical, engineering); (3) map controls to the scenarios and techniques they address and find gaps; and (4) choose controls appropriate to OT constraints. It builds on Chapters 16 and 23 and prepares Laboratory I (Chapter 25) and Chapter 27 (verification).
24.1 Frameworks as organisers
A framework organises outcomes so nothing large is forgotten. NIST's Cybersecurity Framework 2.0 groups outcomes under six functions: Govern, Identify, Protect, Detect, Respond and Recover (NIST CSF 2.0). The UK CAF expresses outcomes and indicators of good practice for operators of essential services (NCSC CAF). Sector-specific goals exist too — for example, the US Department of Health and Human Services' healthcare cybersecurity performance goals (HHS HPH CPGs). Detailed control catalogues such as NIST SP 800-53 list specific controls (SP 800-53 Rev. 5). Frameworks tell you what outcomes to achieve; they do not tell you which risk matters most for your service — that comes from Chapter 23.
24.2 Types of control
Preventive controls stop an event (allowlisting, authentication, a hard-wired limit). Detective controls notice it (monitoring, integrity checks, alarms). Corrective or recovery controls restore service (backups, manual procedures, spare equipment). By nature, controls are technical, procedural (two-person approval, change management), physical (locked cabinets, key switches) or engineering (designs that make a harmful state impossible, such as a pump sized so it cannot overdose). In OT, engineering and physical controls are often the most reliable, because they keep working when computers are compromised.
24.3 Mapping and gaps
A control is only valuable against something. Build a mapping from scenarios (or catalogued techniques, for example from ATT&CK for ICS) to controls, with each control marked preventive, detective or corrective. Gaps show up as scenarios with only detective controls (you will know, but not stop it), with no corrective control (you cannot recover), or covered only by controls that share a single point of failure (Chapter 16's common mode). The mapping also exposes orphan controls that address nothing on your list — candidates for review.
24.4 OT constraints
Some controls standard in IT are risky or impossible in OT: endpoint agents that consume controller resources, automatic patching, active scanning, account lockout on an operator HMI during an emergency (locking out the operator may be more dangerous than the attacker). Alternatives include passive network monitoring, application allowlisting on stable workstations, read-only data diodes for one-way flows, physical key switches for programming modes, and procedural controls tied to the operator's shift log.
CVH's BMS map applies them: passive monitoring of the BMS VLAN instead of agents on the controller, and a hard-wired minimum airflow interlock for theatre ventilation instead of relying on lockout or patching.
24.5 Worked example: CVH BMS control map (synthetic)
This case is synthetic.
| Scenario | Preventive | Detective | Corrective | Gap |
|---|---|---|---|---|
| Remote compromise of BMS via corporate network | Firewall allowlist to BMS server; MFA for BMS admin | Passive monitoring of BMS VLAN | Local manual control of air-handling units | None obvious; verify manual control drill |
| Malicious or mistaken change to theatre ventilation setpoints | Role-based change rights | Alarm on out-of-range air changes | Estates on-call restores setpoints | No independent limit: add hard-wired minimum airflow interlock |
| Vendor laptop on BMS controller | Locked cabinets; vendor escort | — | Restore controller config from backup | No detection; config backup untested |
The map turns a vague "BMS is a risk" into two specific actions: an engineering interlock and a tested configuration restore.
24.6 Common errors and limits
- Treating framework completion as risk reduction.
- Counting controls instead of mapping them to scenarios.
- Relying solely on detection for consequences that need prevention.
- Importing IT controls into OT without considering operational safety.
The CVH BMS map avoids each: it counts no controls, it maps them to three scenarios, it adds an engineering interlock where only detection existed, and it rejects IT controls such as automatic patching of the BMS controller. A framework score of "Protect: implemented" would have told the hospital nothing about theatre airflow.
Exercises — chapter 24
EX047 — Classify controls. Objective: use type and nature. Inputs: offline backups; two-person payment approval; outlet chlorine analyser tripping a valve; SIEM alert on new admin accounts; key switch for PLC programming. Steps: classify each by type and nature. Expected evidence: table. Rubric: 3 = backups corrective/technical; two-person approval preventive/procedural; analyser trip preventive (limits consequence)/engineering; SIEM alert detective/technical; key switch preventive/physical; 2 = one error; 1 = two errors; 0 = none.
EX048 — Find the gap. Objective: map and judge. Inputs: the CVH table. Steps: add one scenario (ransomware on the BMS server) with controls in each column, then name the single most valuable improvement and justify it. Expected evidence: row and justification. Rubric: 3 = plausible controls including tested restore and local manual control; improvement justified by consequence; 2 = row without justification; 1 = incomplete row; 0 = none.
Chapter synthesis
Frameworks organise outcomes; risk analysis decides priorities; mappings connect controls to the scenarios they address and reveal gaps. Prefer combinations of prevention, detection and recovery, and in OT favour engineering and physical controls that keep working when computers do not.
Continue studying — chapter 24 of 40
← Chapter 23 · Course chapter index · Chapter 25 →
Continue to the next authored lesson.