Chapter 18 — Critical infrastructure and sector security: controls
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes and connection"]
N1["18.1 From scenario to control set"]
N2["18.2 Catalogues as checklists for completeness"]
N3["18.3 Implementation qualities"]
N4["18.4 A control that is a process: key life cycle"]
N5["18.5 Evidence that a control works"]
N6["18.7 Practical activity: key-rotation runbook"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["18.1 From scenario to control set"]
N2["18.2 Catalogues as checklists for completeness"]
N3["18.3 Implementation qualities"]
N4["18.4 A control that is a process: key life cycle"]
N5["18.5 Evidence that a control works"]
N6["18.7 Practical activity: key-rotation runbook"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]
[Learning outcomes and connection]
|
v
[18.1 From scenario to control set]
|
v
[18.2 Catalogues as checklists for completeness]
|
v
[18.3 Implementation qualities]
|
v
[18.4 A control that is a process: key life cycle]
|
v
[18.5 Evidence that a control works]
|
v
[18.7 Practical activity: key-rotation runbook]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes and connection
After this chapter you should be able to:
- select controls for a scenario by mapping cause and path to prevent, detect and recover functions;
- implement a control so that it is owned, documented, testable and monitored;
- use a control catalogue such as NIST SP 800-53 to check completeness without copying it wholesale;
- manage a key life cycle as an example of a control that is a process, not a setting.
Chapter 5 introduced control cards; Chapter 13 produced scenarios. This chapter connects them: which controls LANTERN needs, how to implement each one so that it stays effective, and how to show that it does.
18.1 From scenario to control set
For each top scenario, walk its path step by step and ask at each step: what could prevent this step, what would detect it, and what would recover from it? For R2 (a stolen vendor credential used to change PS-07's dosing setpoint, Chapter 13) the steps are: credential stolen → used to log in → reaches the control system → changes the setpoint → water quality changes. Controls attach to each step: phishing-resistant MFA and time-bound enablement (prevent use); session logging and alerting on vendor logins outside an approved window (detect); setpoint limits engineered into the PLC (prevent harm); LANTERN telemetry alert on chlorine outside its band (detect effect); manual dosing procedure and water-quality sampling (recover). Defence in depth (Chapter 8) is the result of doing this walk honestly.
18.2 Catalogues as checklists for completeness
Control catalogues — NIST SP 800-53 Rev. 5 is the most comprehensive (NIST SP 800-53) — describe controls by family: access control, audit and accountability, configuration management, contingency planning, incident response, system and communications protection, and more. Use a catalogue after the scenario walk to ask "did we forget a family?", not as a list to implement in full. In OT, check catalogue controls against the operational constraints described in NIST SP 800-82, which provides OT-specific guidance and an overlay for SP 800-53 (NIST SP 800-82 Rev. 3).
18.3 Implementation qualities
A control that exists on day one and is ineffective by day ninety is common. Implement each control with five qualities:
- Owned — a role that maintains it and answers for it.
- Documented — a control card (Chapter 5) saying what it does, where, and how it fails.
- Configured as code where possible — so that its desired state is in version control and drift is detectable (Chapter 22).
- Testable — a safe way to show it works, run on a schedule (Chapter 23).
- Monitored — a signal when it stops working: a heartbeat, a count, a health check.
18.4 A control that is a process: key life cycle
LANTERN's HMAC keys (Chapter 15) show why some controls are processes. Each station key must be generated with a cryptographically secure random source; distributed to station gateway and relay by a protected route; stored where only the intended service can read it; rotated on a schedule and when staff with access leave; revoked when a station is decommissioned or a key may be exposed; and recorded — which key version is active where, without recording the key itself. A key that has never been rotated is a key whose exposure you would not detect. Rotation must be rehearsed: if stations and relay disagree on the active key, every message fails the MAC check and the station goes silent.
18.5 Evidence that a control works
Evidence differs by type of control. For a configuration control (SSH bound to the management interface) evidence is the drift check result and a connection attempt from a permitted and a non-permitted address in a test. For a detective control evidence is a test event that produced an alert in a measured time. For a process control (access review, key rotation) evidence is the dated record of the last run and its findings. For a recovery control evidence is a timed restore. "Configured" is not evidence that it works.
18.6 Worked example: control cards for R2 (synthetic)
| Control | Function | Owner | Evidence it works | Monitored by |
|---|---|---|---|---|
| Vendor account time-bound, MFA | Prevent | FSTS Security | Enablement log; expiry tested monthly | Alert on vendor login outside window |
| Vendor session logging | Detect | FSTS Security | Sample session reviewed weekly | Alert if recording service stops |
| PLC dosing setpoint limits | Prevent harm | Water engineering | Engineering test record; value read back at site visit | Comparison with approved setpoint baseline |
| Chlorine out-of-band telemetry alert | Detect effect | FSTS monitoring | Injected test reading raised alert in 2 min | Rule heartbeat (Chapter 19) |
| Manual dosing and sampling procedure | Recover | Water operations | Exercise record within 12 months | Exercise schedule |
18.7 Practical activity: key-rotation runbook
Write a rotation runbook for one station key: preparation (new key generated and stored, relay configured to accept old and new for a short overlap), cut-over at the station gateway, verification (messages accepted with the new key version; MAC failures counted), removal of the old key, and rollback. State the overlap length and why.
For PS-07, whose gateway key sat on a removable card in an unlocked enclosure, rotation is no longer routine maintenance: it is the response to a physical finding. An overlap of a few hours, long enough to confirm accepted messages under the new key version, keeps the station reporting during cut-over.
18.8 Common errors and limits
- Selecting controls from a catalogue without walking a scenario, producing many controls and gaps between them.
- Controls with no owner, or owned by a person rather than a role.
- Treating "configured" as "effective".
- Key rotation never rehearsed, so it is avoided.
- Removing a compensating control when the fix is scheduled rather than verified.
The R2 cards avoid these: each control has a role owner and evidence, and the chlorine alert's test raised an alert in 2 minutes.
Key rotation for PS-07 was avoided for years for the fourth reason.
Exercises — chapter 18
EX052 — Walk a scenario. Objective: build a control set from a path. Inputs: R3 from Chapter 13 (relay disk fills; telemetry dropped). Constraints: at least one control per step and per function. Steps: (1) write the path in steps; (2) attach prevent, detect and recover controls; (3) name the evidence for each. Expected evidence: table. Rubric: 3 = steps such as growth → threshold → write failure → dropped messages, with controls like retention enforcement, capacity forecast and alarm with lead time (Chapter 1), disk alarm and reject/drop count alert, station buffering and backlog upload; evidence specified; 2 = one function missing; 1 = single control; 0 = none.
EX053 — Catalogue check. Objective: use a catalogue for completeness. Inputs: the R2 control cards in Chapter 18 ("Worked example: control cards for R2") and SP 800-53 Rev. 5 control family list. Constraints: cite the families by identifier. Steps: (1) map each card to a family; (2) name one family relevant to R2 that has no card; (3) propose a card for it. Expected evidence: table with citation. Rubric: 3 = sensible mappings (for example AC, AU, CM/SI, IR or CP) and a credible missing family such as personnel security for vendor staff, supply chain risk management (SR) for the vendor's own security, or incident response (IR) for a dosing incident, with a concrete card; 2 = mapping right, missing family weak; 1 = no citation; 0 = none.
EX054 — Overlap length. Objective: reason about key rotation. Inputs: stations buffer up to 24 hours; backlog messages are sealed with the key active when they were created. Constraints: the relay should accept as few keys as possible for as short as possible. Steps: (1) say how long the relay must keep accepting the old key after cut-over; (2) explain how the relay knows which key to try. Expected evidence: paragraph. Rubric: 3 = old key accepted for at least the 24 h buffer period (plus margin) because backlog messages carry old-key MACs; messages carry a key version identifier inside the authenticated body or alongside it so the relay selects the key rather than trying all; old key then removed and the removal verified; 2 = overlap right, selection vague; 1 = no overlap; 0 = none.
Chapter synthesis
Select controls by walking each scenario's path and attaching prevent, detect and recover controls to its steps; use catalogues to check completeness. Implement every control owned, documented, configured as code where possible, testable and monitored. Some controls are processes — key life cycle is the clearest example — and must be rehearsed. "Configured" is never the same as "works".
Continue studying — chapter 18 of 30
← Chapter 17 · Course chapter index · Chapter 19 →
Continue to the next authored lesson.