Chapter 31 — Critical infrastructure and sector security: advanced cases

Chapter 31 — Critical infrastructure and sector security: advanced cases

Lesson map

Lesson 31 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["31.1 Beyond the headline"]
  N2["31.2 Supply chains"]
  N3["31.3 A comparison frame"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["31.1 Beyond the headline"]
  N2["31.2 Supply chains"]
  N3["31.3 A comparison frame"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Learning outcomes and connection]
    |
    v
[31.1 Beyond the headline]
    |
    v
[31.2 Supply chains]
    |
    v
[31.3 A comparison frame]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes and connection

After this chapter you can (1) analyse cases where harm came through the physical process, safety systems or shared suppliers rather than data theft; (2) compare cases systematically on cause, path, consequence, detection and recovery; (3) reason about supply-chain and concentration risk across sectors; and (4) draw defensible, bounded lessons for an operator. It builds on Chapter 20 and Chapters 21–30, and prepares the comparative project (Chapter 34).

31.1 Beyond the headline

Advanced case analysis asks not "what happened?" but "which assumption failed, and is that assumption present here?" Three families of cases illustrate assumptions that critical services rely on.

Process manipulation designed to stay hidden. Langner's analysis of Stuxnet describes malware that manipulated industrial controllers driving centrifuges while presenting normal-looking values to operators (Langner, 2011). Failed assumption: what the operator sees is what the process does. Transferable lesson: independent measurement paths for critical variables, and physical limits that do not depend on the controller.

Attacks on the safety layer. The TRITON/HatMan analysis describes malware targeting a safety instrumented system controller (CISA MAR-17-352-01). Failed assumption: the safety system is independent of the networks an attacker can reach. Lesson: physically enforce SIS programming modes (key switches), separate SIS networks and treat SIS engineering workstations as the most sensitive assets.

Shared dependency failure. The July 2024 faulty security update that crashed about 8.5 million Windows devices (Microsoft, 2024) and the 2021 precautionary shutdown after ransomware on a pipeline company's IT network (CISA AA21-131A) show harm arriving through dependencies rather than the control system. Failed assumption: our risk is bounded by our own systems. Lesson: map concentration (many services relying on one product, vendor or cloud region), stage updates, and plan degraded operation that does not need business IT.

31.2 Supply chains

Every operator runs software and hardware built by others, often through long chains of components. Public measures include software bills of materials listing components (CISA SBOM), frameworks for build integrity such as SLSA (SLSA), secure development practices for suppliers (NIST SSDF, SP 800-218) and "secure by design" expectations on manufacturers (CISA Secure by Design). At bachelor's level, the operator's levers are mainly contractual and architectural: require SBOMs and vulnerability disclosure, test updates before deployment, stage rollouts, keep the ability to roll back, and avoid letting one supplier's failure stop several critical functions at once.

31.3 A comparison frame

Read the "Failed assumption" row first; it is the transferable part. Each generic control addresses that assumption rather than the specific technique.

31.4 Worked example: concentration at Calder (synthetic)

This case is synthetic. The CRP surveys its members: CVH, CEDC and Calder Mutual all use the same endpoint-security product, configured for automatic updates; CEDC and CT use the same CAD/scheduling cloud region; CW and CPN use the same OT integrator with remote access to both. Single events that could hit several sectors at once: a faulty endpoint update (hospital, dispatch, bank simultaneously); a cloud-region outage (dispatch and transit); a compromise of the integrator (water and power). Recommendations: stagger endpoint updates (a small canary group first, critical dispatch consoles last); confirm CEDC's paper-and-radio fallback does not need the cloud; require per-session approval and separate credentials for the integrator at each operator, and include it in the joint exercise. The point is not that these suppliers are bad; it is that the county's risk is shared and must be analysed jointly.

31.5 Common errors and limits

• Drawing lessons from vivid but unsourced details.
• Treating targeted state operations as the typical threat for every operator.
• Ignoring accidental shared-dependency failures because no adversary is involved.
• Teaching techniques instead of failed assumptions.

The Calder concentration example avoids these: it uses no technique detail, treats an accidental endpoint update as seriously as an integrator compromise, and does not assume a state actor. Repeating unsourced claims about Stuxnet's origin would be the first error.

The fourth error would turn a TRITON lesson into a description of how to reach a safety controller.

Exercises — chapter 31

EX061 — Find the assumption. Objective: abstract a case. Inputs: the Ukraine 2015 case (Chapter 20). Steps: state two assumptions that failed and one assumption that held and helped recovery, with source support. Expected evidence: three assumptions. Rubric: 3 = e.g. remote access/operator workstations were trustworthy (failed), call centres would remain reachable (failed), manual operation was possible (held), each tied to the CISA alert; 2 = two; 1 = one; 0 = none.

EX062 — Concentration map. Objective: identify shared dependencies. Inputs: the Calder concentration survey in this chapter's worked example. Steps: draw a bipartite map (suppliers ↔ operators), mark the supplier with the highest reach and propose one measure per supplier. Expected evidence: map and measures. Rubric: 3 = endpoint product reaches three operators across three sectors (highest), measures specific (staged updates, fallback independence, integrator controls); 2 = map without measures; 1 = list; 0 = none.

Chapter synthesis

Advanced cases teach through failed assumptions: what operators see is real, safety systems are independent, risk is bounded by our own systems. Compare cases on cause, path, consequence and assumption; manage supply-chain and concentration risk jointly across operators; and turn lessons into generic controls rather than technique knowledge.

Continue studying — chapter 31 of 40

← Chapter 30 · Course chapter index · Chapter 32 →

Continue to the next authored lesson.