Chapter 26 — Critical infrastructure and sector security: methods II | Bachelor's 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 26 — Critical infrastructure and sector security: methods II

Lesson map

Lesson 26 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["26.1 Threat modelling with data flows"]
  N2["26.2 STPA: hazards from control structure"]
  N3["26.3 Tabletop exercises"]
  N4["26.4 Choosing methods"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["26.1 Threat modelling with data flows"]
  N2["26.2 STPA: hazards from control structure"]
  N3["26.3 Tabletop exercises"]
  N4["26.4 Choosing methods"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX051"]

[Learning outcomes and connection]
    |
    v
[26.1 Threat modelling with data flows]
    |
    v
[26.2 STPA: hazards from control structure]
    |
    v
[26.3 Tabletop exercises]
    |
    v
[26.4 Choosing methods]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes and connection

After this chapter you can (1) build structured threat models of a system using data-flow diagrams and a threat checklist; (2) apply systems-theoretic hazard analysis (STPA) to find unsafe control actions; (3) design and run a tabletop exercise as a method for testing plans; and (4) compare these methods with the risk methods of Chapter 23 and choose among them. It builds on Chapters 21–24 and prepares Chapter 27 (verification) and Chapter 28 (failure analysis).

26.1 Threat modelling with data flows

A data-flow diagram shows processes, data stores, external entities, flows and trust boundaries (where data crosses from one level of trust to another). Threat modelling walks each element and asks a checklist of questions. A widely used checklist, STRIDE, asks about Spoofing identity, Tampering with data, Repudiation (denying an action), Information disclosure, Denial of service and Elevation of privilege. Every flow that crosses a trust boundary deserves the full checklist. The output is a list of threats with the element, the threat type and a proposed mitigation.

26.2 STPA: hazards from control structure

Leveson's STAMP model treats accidents as the result of inadequate control rather than chains of component failure (Leveson, 2004). Its analysis method, STPA, proceeds: define losses and hazards; model the control structure (who controls what, with which feedback); for each control action, identify unsafe control actions (UCAs) in four forms — not provided when needed, provided when unsafe, provided too early/late or out of order, stopped too soon or applied too long; then find causal scenarios, including manipulated feedback or commands. STPA suits critical services because it treats operators, procedures, software and attackers within one structure.

26.3 Tabletop exercises

A tabletop exercise walks a team through a scenario in discussion, step by step, with injects ("it is now 03:40; the CAD screens show a ransom note"). It tests plans, roles and communication without touching live systems. Good tabletops have objectives (e.g. "test the decision to switch to paper dispatch"), a realistic synthetic scenario, a facilitator, observers recording decisions and timings, and a hot debrief followed by an improvement plan. They are evidence of preparedness only to the extent that findings are acted on.

26.4 Choosing methods

Method	Best for	Weakness
Risk assessment (Ch. 23)	Prioritising across many scenarios	Likelihood estimates weak for novel threats
Consequence-first / CCE	Worst outcomes, engineering mitigations	Can neglect frequent moderate harms
STRIDE threat model	Software and data flows	Weak on physical process and humans
STPA	Control structures, human and software interactions	Effortful; needs process knowledge
Tabletop	Plans, roles, communication	Discussion is not execution

For CEDC, the table suggests STPA for dispatch control and a tabletop for the paper fallback, as the chapter does; a risk assessment then ranks the resulting work.

26.5 Worked example: STPA for CEDC dispatch (synthetic)

This case is synthetic. Loss: delayed emergency response. Hazard: an ambulance is not dispatched to a life-threatening call within target time. Control structure: call handler → CAD → dispatcher → ambulance crew (via radio and mobile data terminals); feedback from vehicle location system to CAD. Control action: "assign nearest available ambulance". UCAs: not provided — CAD queue frozen after a failed update; provided when unsafe — CAD assigns a unit shown "available" because location feedback is stale or spoofed; too late — manual fallback adopted only after 20 minutes because nobody owns the decision; stopped too soon — a dispatcher cancels an assignment after a duplicate-call merge error. Each UCA leads to requirements: a CAD freeze alarm, staleness indicators on vehicle locations, a named fallback decision owner with a 5-minute trigger, and confirmation before cancelling a high-priority assignment. Note that two UCAs involve no attacker at all.

26.6 Common errors and limits

Threat models without trust boundaries.
STPA reduced to a list of component failures.
Tabletops with no objectives or follow-up.
Picking the most impressive method rather than the one the question needs.

The CEDC STPA avoided the second error by naming unsafe control actions, two without any attacker. A STRIDE review of the CW historian flow without marking the DMZ-to-control trust boundary would make the first. A tabletop without the objective "decide on paper dispatch" makes the third. And choosing STPA to impress when the question is "which backup strategy" makes the fourth.

Exercises — chapter 26

EX051 — STRIDE a flow. Objective: apply the checklist. Inputs: the CW flow "historian collector in DMZ reads OPC UA from SCADA server". Steps: write one threat for each STRIDE letter with a mitigation. Expected evidence: six rows. Rubric: 3 = six plausible threats with matching mitigations (e.g. spoofed collector → mutual certificates; tampering → signed/authenticated session; DoS → rate limits on SCADA side); 2 = four or five; 1 = fewer; 0 = none.

EX052 — Design a tabletop. Objective: plan an exercise. Inputs: CVH, scenario "ransomware encrypts the patient-administration system on a Saturday night". Steps: write objectives (two), participants, four injects with times and the evidence you will record. Expected evidence: plan. Rubric: 3 = measurable objectives, clinical and technical participants, escalating realistic injects (including data-protection and communication decisions), recorded timings and decisions; 2 = partial; 1 = scenario only; 0 = none.

Chapter synthesis

Threat modelling finds threats where data crosses trust boundaries; STPA finds unsafe control actions in socio-technical structures; tabletops test plans and people. Each sees what others miss, so choose by the question — and remember that many hazards involve no adversary at all.

Continue studying — chapter 26 of 40

← Chapter 25 · Course chapter index · Chapter 27 →

Continue to the next authored lesson.