Chapter 27 — Critical infrastructure and sector security: control design | Engineering Critical infrastructure and sector security

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 27 — Critical infrastructure and sector security: control design

Lesson map

Lesson 27 published. Map, example, EX053.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["27.1 From scenario to control"]
  N2["27.3 Independent layers"]
  N3["27.4 Specifying controls"]
  N4["27.6 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX053"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["27.1 From scenario to control"]
  N2["27.3 Independent layers"]
  N3["27.4 Specifying controls"]
  N4["27.6 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX053"]

[Learning outcomes and connection]
    |
    v
[27.1 From scenario to control]
    |
    v
[27.3 Independent layers]
    |
    v
[27.4 Specifying controls]
    |
    v
[27.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX053]

Learning outcomes and connection

After this chapter you can (1) design controls that address specific scenarios with defined performance; (2) combine preventive, detective and recovery controls into defence in depth whose layers fail independently; (3) prefer engineered, physics-based limits for the worst consequences; and (4) specify each control so that it can be verified. It applies Chapters 15, 23 and 26 and prepares Chapters 28 and 30.

27.1 From scenario to control

Each scenario from Chapter 23 gets controls at three points: prevent the threat event, detect it if prevention fails, and limit and recover from consequences. Example — forged stop commands to PS3 and PS4: prevent with authenticated commands (R1); detect with alarms on command anomalies and unexpected state changes; limit with local automatic restart logic and the hospital tank; recover with local manual procedures (R4).

Each of these controls must then be specified and verified, as the rest of the chapter shows, before the forged-stop scenario can be called covered in the dossier.

27.2 Engineered limits first

For the worst consequences, the most robust controls do not depend on software at all: pressure relief valves, mechanical stops, hard-wired interlocks, chemical dosing pumps physically sized so they cannot overdose at maximum stroke. Cyber-informed engineering (see INL CCE) emphasises such controls because they hold even if every digital system is compromised. They cannot cover everything — a mechanical relief valve cannot stop a pump from being switched off — but they bound the worst cases.

For LRWA's dosing pump, the stroke limit sized by process engineers is such a control.

27.3 Independent layers

Defence in depth works only if layers fail independently. List each layer's dependencies: if authentication, monitoring and logging all depend on the SCADA servers, one compromise defeats all three. Place at least one detection layer outside the systems it watches (passive network monitoring, an independent analyser), and keep recovery materials (offline backups, procedures, spare keys) outside the reach of the threat being recovered from.

TMRP applies this by putting the chlorine analyser alarm on a separate logger and keeping offline backups away from the SCADA servers they would restore.

27.4 Specifying controls

A control specification states: the scenario(s) it addresses; its function; performance (detection within X, rejection rate, restoration time); dependencies; failure mode (fail-safe or fail-operational, and what that means here); owner; and verification method. Without performance and verification, a control is an intention.

The setpoint bounds specification in the worked example below shows every element: the scenario, the bounds and step limit, the alarm rule, the dependencies, retaining the last valid setpoint as its failure mode, and test T3 as verification. Its owner is the control engineering team that configures the dosing controller.

27.5 Worked example: setpoint bounds (synthetic)

Scenario: forged or erroneous setpoint drives the chlorine dosing pump to overdose. Controls: (1) engineered — dosing pump stroke physically limited so that maximum dose at maximum flow stays below a harmful concentration (sized by process engineers); (2) preventive — controller-side bounds and step limits (R3), implemented in the controller, not the HMI, so a compromised SCADA cannot bypass them; (3) detective — independent chlorine analyser alarm (R9) on a separate logger; (4) recovery — procedure to isolate the dosing line and flush. Specification for (2): reject setpoints outside 0.5–5.5 mg/L or changing by more than 0.5 mg/L per command, reject non-finite values, log every rejection, alarm on three rejections in 10 minutes; fail-safe = retain last valid setpoint; verified by test T3 including property-based testing (Lab 11).

27.6 Practical activity

Write full specifications for two controls of the forged-stop scenario in §27.1, including performance, dependencies, failure mode and verification.

Choose one preventive control, such as authenticated commands, and one recovery control, such as local manual operation at PS3 and PS4. For each, state the performance it must achieve, what it depends on and what happens when it fails. Authentication should fail closed for commands; local manual operation must work without SCADA or the network. Name an owner by role and a verification method, then check whether the two controls share any dependency that would let one event defeat both.

27.7 Common errors and limits

Controls without performance criteria.
Bounds enforced in the HMI rather than the controller.
"Layers" that share dependencies.
No engineered limit for the worst consequence when one is feasible.
Recovery materials reachable by the same attacker.

The dosing example avoids each: bounds live in the controller, the analyser alarm uses a separate logger, the stroke limit is engineered, and every element has a performance target. The bounds also retain the last valid setpoint when a command is rejected, so the failure mode is stated, and each rejection is logged for the alarm rule.

Exercises — chapter 27

EX053 — Dependency audit of layers. Objective: check independence. Inputs: the four controls in §27.5 and their implementation: controller bounds in the dosing PLC; analyser on separate logger; logging via SCADA. Steps: list dependencies of each layer; identify any shared dependency; propose a change. Expected evidence: table and change. Rubric: 3 = shared dependency found (rejection logging and alarm via SCADA), change proposed (local log plus independent alarm path); 2 = no change; 1 = list only; 0 = none.

EX054 — Fail-safe meaning. Objective: define failure modes in context. Inputs: authenticated telemetry gateway at PS4. Steps: for gateway failure, define what fail-safe means for (a) commands, (b) telemetry, (c) local control, and justify. Expected evidence: three definitions. Rubric: 3 = commands fail closed (rejected), telemetry fails visible (alarm at SCADA), local control continues automatically; 2 = one misdefined; 1 = "fail-safe = shut down"; 0 = none.

Chapter synthesis

Design controls per scenario at prevention, detection and recovery points. Put engineered physical limits on the worst consequences, enforce bounds where the attacker cannot bypass them, make layers independent, and specify each control's performance, dependencies, failure mode, owner and verification.

Continue studying — chapter 27 of 50

← Chapter 26 · Course chapter index · Chapter 28 →

Continue to the next authored lesson.