Chapter 28 — Critical infrastructure and sector security: failure analysis | 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.

Lesson map

Lesson 28 published. Map, example, EX056.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["28.1 Fault trees"]
  N2["28.2 FMEA"]
  N3["28.4 Blameless post-incident review"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX056"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["28.1 Fault trees"]
  N2["28.2 FMEA"]
  N3["28.4 Blameless post-incident review"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX056"]

[Learning outcomes and connection]
    |
    v
[28.1 Fault trees]
    |
    v
[28.2 FMEA]
    |
    v
[28.4 Blameless post-incident review]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX056]

Learning outcomes and connection

After this chapter you can (1) build a simple fault tree with AND and OR gates and compute the top-event probability under independence; (2) carry out a failure modes and effects analysis (FMEA) for a small system; (3) add a cyber path to a safety analysis and see how it changes the result; and (4) conduct a blameless post-incident review that looks for system causes. It builds on Chapters 12, 21, 22 and 26 and prepares Chapter 29 (operations) and Chapter 31 (advanced cases).

28.1 Fault trees

A fault tree starts from an undesired top event and decomposes it into causes connected by gates. An AND gate means all inputs must occur; an OR gate means any one suffices. With independent basic events, AND multiplies probabilities and OR combines them as $1 - \prod (1 - p_i)$. Fault trees make assumptions explicit and show which basic events dominate. They are traditionally built for random failures; security analysis adds paths where an adversary can make an event happen on purpose — and an adversary's "probability" is not a property of hardware.

28.2 FMEA

Failure modes and effects analysis works bottom-up: for each component, list ways it can fail (fails to start, fails open, gives false reading), the effect on the system, how it would be detected, and existing controls; then rank. FMEA finds single-component problems well and interactions poorly, which is why it pairs with STPA (Chapter 26) and fault trees.

EX056 applies FMEA to CW's dosing pump and analyser.

A row for CW's dosing pump reads: component dosing pump; mode runs at maximum rate; effect over-chlorination at the outlet; detection outlet residual analyser alarm; existing control hard-wired maximum pump rate.

28.3 Worked example and Lab 11 (synthetic)

This case is synthetic. Top event at CVH: "hospital loses mains-quality power to critical loads". Physically, this needs a grid outage AND failure of the backup (generator fails to start OR fuel contaminated OR automatic transfer switch fails). Separately, the hospital's BMS can command the essential-supply panel; a compromise of the BMS could shed critical loads regardless of the grid.

# Lab 11 - a small fault tree for "hospital loses mains-quality power" (synthetic annual probabilities)
P = {"grid": 0.05, "gen_fails_start": 0.02, "fuel_contaminated": 0.005, "ats_fails": 0.01, "cyber_bms": 0.002}
# top = grid AND (backup fails); backup fails = gen_fails_start OR fuel_contaminated OR ats_fails
# separately: a compromised building-management system can shed critical loads whatever the grid state
backup_fails = 1 - (1 - P["gen_fails_start"]) * (1 - P["fuel_contaminated"]) * (1 - P["ats_fails"])
top_physical = P["grid"] * backup_fails
top = 1 - (1 - top_physical) * (1 - P["cyber_bms"])
print(f"P(backup fails on demand) = {backup_fails:.5f}")
print(f"P(top) physical only = {top_physical:.6f}")
print(f"P(top) with BMS path  = {top:.6f}")
print(f"share from cyber path ~ {P['cyber_bms'] / top:.0%}")

Expected output:

P(backup fails on demand) = 0.03465
P(top) physical only = 0.001733
P(top) with BMS path  = 0.003729
share from cyber path ~ 54%

Under these synthetic numbers the physical design is good: two independent failures are needed. The cyber path is a single event that bypasses the AND gate and roughly doubles the top-event probability. The deeper point does not depend on the 0.002 estimate: an attacker does not fail at random, so a path that needs only one "event" under adversary control can dominate whatever number you write. The engineering response is to restore the AND structure — make critical loads impossible to shed from the BMS (a hard-wired inhibit, or BMS control limited to non-critical panels) — rather than only to lower the estimated probability.

28.4 Blameless post-incident review

When failures happen, a blameless review asks how the system allowed a reasonable person's action to cause harm, not who to punish. Reason's model of organisational accidents describes defences as layers with holes that occasionally align (Reason, 2000). Ask: what did people know at the time; what made their action seem right; which defences were absent or bypassed; what will we change in the system? Blame suppresses reporting, and unreported near-misses are lost evidence.

In the Lab 11 case, a blameless review of a lost-power event would ask why the BMS could shed critical loads at all.

28.5 Common errors and limits

Multiplying probabilities of events with common causes (Chapter 12).
Treating adversary actions as random failures.
FMEA without interactions; fault trees without the human.
Reviews that end with "human error" and retraining.

Lab 11 assumes independence of generator failure and fuel contamination; EX024 shows how a shared fuel tank breaks that. The BMS path is the second error made explicit: 0.002 is not a property of the BMS. The third appears if an FMEA of the generator ignores the operator who must start it manually. A review ending "estates engineer error; retrain" is the fourth.

Exercises — chapter 28

EX055 — Restore the AND gate. Objective: see the effect of an engineering fix. Inputs: Lab 11. Steps: model a fix where the BMS can shed critical loads only if a grid outage is also present (i.e. the cyber path joins the grid AND gate as an extra backup-failure cause). Compute the new top-event probability. Expected evidence: modified code and value. Rubric: 3 = backup fails = 1−(0.98)(0.995)(0.99)(0.998) ≈ 0.03658, top ≈ 0.001829, with comment that the cyber path now needs a coincident grid outage; 2 = approach right, arithmetic slip; 1 = unchanged structure; 0 = none.

EX056 — FMEA rows. Objective: apply bottom-up analysis. Inputs: CW chlorine-dosing pump and its residual analyser. Steps: write four FMEA rows (component, failure mode, effect, detection, existing control). Expected evidence: table. Rubric: 3 = realistic modes (pump runs at max, pump stops, analyser reads low, analyser frozen) with effects on water safety and credible detections; 2 = three; 1 = vague; 0 = none.

Chapter synthesis

Fault trees and FMEA make failure assumptions explicit, top-down and bottom-up. Adding cyber paths reveals single events that bypass designed redundancy; the strongest response restores structural independence rather than tuning an estimate. When failures happen, review the system, not the person.