Chapter 13 — Critical infrastructure and sector security: risk scenarios
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes and connection"]
N1["13.1 Scenarios, not categories"]
N2["13.2 Consequence first"]
N3["13.3 Existing controls and residual risk"]
N4["13.4 From scenarios to work"]
N5["13.6 Practical activity: scenario ranking"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["13.1 Scenarios, not categories"]
N2["13.2 Consequence first"]
N3["13.3 Existing controls and residual risk"]
N4["13.4 From scenarios to work"]
N5["13.6 Practical activity: scenario ranking"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]
[Learning outcomes and connection]
|
v
[13.1 Scenarios, not categories]
|
v
[13.2 Consequence first]
|
v
[13.3 Existing controls and residual risk]
|
v
[13.4 From scenarios to work]
|
v
[13.6 Practical activity: scenario ranking]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes and connection
After this chapter you should be able to:
- write a risk scenario as a specific story: cause, path, affected asset, consequence for people, and existing controls;
- assign consequence and likelihood bands with stated reasons, measuring consequence in people and time;
- rank scenarios consequence first where safety is involved, and explain why a likelihood × consequence product can mislead;
- turn the top scenarios into implementation work with owners.
Risk assessment can be done at many depths; NIST's guide describes a full process for organizations (NIST SP 800-30 Rev. 1). This chapter teaches the implementer's version: writing scenarios precise enough that a technologist can build, test and monitor the controls they imply.
13.1 Scenarios, not categories
"Ransomware" is a category. A scenario is: "Ransomware delivered through a phishing email encrypts HIST-01; station data still reach the relay, which buffers them; operators lose trend displays and weekly compliance reports until the historian is restored." A good scenario names the cause, the path, the affected asset, the consequence for people and service, and the existing controls. It can then be tested ("does the relay really buffer? for how long?") and monitored.
R2 meets the test: stolen vendor credential, vendor remote access, PS-07's dosing setpoint, a chlorine change people drink.
13.2 Consequence first
Consequence describes what happens to people: how many, for how long, and whether anyone could be harmed. A simple banding uses people × hours of disruption, with any credible safety effect placed in the highest band regardless of numbers. Likelihood is a judgement band (1 to 5) informed by exposure, known threats and history. Write the reason for each band; a band without a reason cannot be challenged.
Many registers rank by the product likelihood × consequence. The product is convenient and dangerous: it treats a frequent nuisance and a rare catastrophe as equal if the products match, and lets an often-seen but recoverable problem outrank a safety scenario. Where safety is possible, rank consequence first and then likelihood within the band; use the product, if at all, only within a consequence band. Consequence-driven methods developed for critical infrastructure take the same view: start from the outcomes that must not happen (INL CCE).
13.3 Existing controls and residual risk
For each scenario record the controls that already reduce it and whether they have been tested (Chapter 23). An untested control is a hope, and should not lower the band much. The residual risk — what remains after controls — needs an owner who has accepted it, by name of role, with a review date.
For R1, historian ransomware, the key control is the relay's buffering of station data while HIST-01 is down. Until that buffering has been tested by stopping the historian on purpose and checking how many hours the relay holds, it is a hope, and R1's low band rests on it. The residual-risk owner for R1 would be Water operations, because compliance reporting is theirs.
13.4 From scenarios to work
The register's value is the work it produces. For each of the top scenarios, list the implementation tasks that would reduce consequence or likelihood, and the monitoring that would detect it in progress. A register that produces no tasks is a document; one that produces tasks with owners is a plan.
For R3, the relay disk filling, the work is concrete: find what keeps RLY-01's data beyond 30 days, set a disk alert before the 85 % alarm, and test the buffer's behaviour when the disk is full. For R2 it is the vendor-account controls and the chlorine out-of-band alert that appear as control cards in Chapter 18.
13.5 Worked example: six Fallowmere scenarios (synthetic)
Lab 13 ranks six scenarios. Two carry a safety flag — a stolen vendor credential used to change PS-07's dosing setpoint (R2), and a clinical gateway outage preventing infusion-pump drug-library updates (R4) — and go to consequence band 5. Ranked consequence first, R2 and R4 lead, followed by the relay disk filling (R3) and the carrier outage (R6). Ranked by product, R3 (16) and R6 (12) outrank both safety scenarios (10 each). The product ranking would send next quarter's effort to disk capacity — useful, but not where harm to people is possible.
Notice also R1, historian ransomware, at the bottom with consequence 1. That reflects the design: telemetry and control continue without the historian. It is not a reason to ignore R1 — compliance reporting and investigations depend on the historian — but a reason to trust the design property of Chapter 8, if the relay's buffering has been tested.
R2 deserves a note. LANTERN does not carry commands, so R2's path does not pass through LANTERN. It passes through the vendor's remote access to the control system. A technologist's risk register should include scenarios that the service does not cause but must detect or support: LANTERN's telemetry is how operators would notice an unexpected dosing change.
13.6 Practical activity: scenario ranking
Lab 13 (save as lab13.py, run with python3 lab13.py):
# Lab 13 - a small risk-scenario register ranked by consequence first (offline, standard library only)
# Synthetic: Fallowmere scenarios. Likelihood band 1-5 (judgement), consequence in service units.
scenarios = [ # id, scenario, likelihood band, people affected, hours of disruption, safety flag
("R1", "Ransomware encrypts historian; station data still reaches relay", 3, 0, 0, False),
("R2", "Stolen vendor credential used to change PS-07 dosing setpoint", 2, 41000, 24, True),
("R3", "Relay disk fills; telemetry dropped for remote stations", 4, 41000, 6, False),
("R4", "Clinical gateway outage stops infusion-pump library updates", 2, 300, 72, True),
("R5", "Depot kiosk defaced", 4, 0, 2, False),
("R6", "Upstream carrier outage isolates 6 stations", 3, 18000, 8, False),
]
def consequence_band(people, hours, safety):
ph = people * hours
band = 1 if ph == 0 else 2 if ph < 10_000 else 3 if ph < 100_000 else 4 if ph < 1_000_000 else 5
return 5 if safety else band # any credible safety effect goes to the top band
rows = []
for sid, text, lik, people, hours, safety in scenarios:
c = consequence_band(people, hours, safety)
rows.append((c, lik, sid, text, c * lik))
print("ranked by consequence, then likelihood:")
for c, lik, sid, text, prod in sorted(rows, key=lambda r: (-r[0], -r[1])):
print(f" {sid} C{c} L{lik} CxL={prod:>2} {text}")
print("ranked by CxL product only:")
print(" " + " ".join(sid for c, lik, sid, text, prod in sorted(rows, key=lambda r: -r[4])))
Expected output (Python 3.13.5):
ranked by consequence, then likelihood:
R2 C5 L2 CxL=10 Stolen vendor credential used to change PS-07 dosing setpoint
R4 C5 L2 CxL=10 Clinical gateway outage stops infusion-pump library updates
R3 C4 L4 CxL=16 Relay disk fills; telemetry dropped for remote stations
R6 C4 L3 CxL=12 Upstream carrier outage isolates 6 stations
R5 C1 L4 CxL= 4 Depot kiosk defaced
R1 C1 L3 CxL= 3 Ransomware encrypts historian; station data still reaches relay
ranked by CxL product only:
R3 R6 R2 R4 R5 R1
Run it and compare the two orderings. Ranked by consequence first, R2 and R4 lead because both carry the safety flag at band 5. Ranked by product, R3 at 16 and R6 at 12 overtake them, and R1 stays at the bottom either way. Then change one input that you consider uncertain, such as R2's likelihood, and see whether it moves R2 below R3. If the consequence-first ordering survives your change and the product ordering does not, that is the argument to put in front of the people who allocate next quarter's work.
13.7 Common errors and limits
- Writing categories instead of scenarios.
- Bands without reasons.
- Ranking by product when safety is involved.
- Lowering likelihood for controls that have never been tested.
- Residual risk with no owner.
- Leaving out scenarios outside your system that your system must detect.
Bands are judgements. Their value is that they make reasoning explicit and comparable, not that they measure risk precisely.
Lab 13 shows the third error: ranking by product puts disk capacity above chlorine dosing.
Leaving out R2 because LANTERN carries no commands would be the sixth error: LANTERN's telemetry is how operators notice an unexpected dosing change.
Exercises — chapter 13
EX037 — Write two scenarios. Objective: write testable scenarios. Inputs: LANTERN design from Chapters 2 and 8. Constraints: each must name cause, path, asset, consequence (people and time) and existing controls. Steps: write a scenario about the BayTel carrier and one about the FSTS jump host. Expected evidence: two scenarios of 80–120 words. Rubric: 3 = specific, testable, consequences in people and time, controls named with test status; 2 = one vague element; 1 = categories; 0 = none.
EX038 — Product versus consequence. Objective: explain a ranking choice to a manager. Inputs: Lab 13 output. Constraints: 150 words; no jargon. Steps: explain why R2 and R4 should be addressed before R3 even though R3 scores higher by product, and what R3 still needs. Expected evidence: paragraph. Rubric: 3 = clear argument about possible harm to people, irrecoverability, and the product's equal-weighting flaw; acknowledges R3 still needs capacity action (Chapter 1) and is cheap to fix; 2 = argument partial; 1 = "safety first" only; 0 = none.
EX039 — From scenario to work. Objective: produce implementation tasks. Inputs: R2 (vendor credential used to change a dosing setpoint). Constraints: tasks FSTS or Water can deliver; each with owner and evidence of completion. Steps: list three prevention or reduction tasks and two detection tasks. Expected evidence: table. Rubric: 3 = for example time-bound vendor access with MFA (Chapter 7), session logging, PLC setpoint limits engineered by Water, telemetry alert on chlorine/dosing change outside an approved window, and comparison of setpoint values with an approved baseline; owners and evidence named; 2 = tasks generic; 1 = fewer than three; 0 = none.
Chapter synthesis
Write risks as specific scenarios — cause, path, asset, consequence and controls — so they can be tested and monitored. Measure consequence in people and time, put credible safety effects at the top, and rank consequence first; the likelihood × consequence product can let nuisances outrank harm. Give residual risk an owner, include scenarios your service must detect, and turn the register into tasks.
Continue studying — chapter 13 of 30
← Chapter 12 · Course chapter index · Chapter 14 →
Continue to the next authored lesson.