Chapter 22 — Critical infrastructure and sector security: data and dependencies | 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 22 published. Map, example, EX024.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["22.1 Inventory is evidence, not a list"]
  N2["22.2 Kinds of dependency"]
  N3["22.4 Data quality"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX024"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["22.1 Inventory is evidence, not a list"]
  N2["22.2 Kinds of dependency"]
  N3["22.4 Data quality"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX024"]

[Learning outcomes and connection]
    |
    v
[22.1 Inventory is evidence, not a list]
    |
    v
[22.2 Kinds of dependency]
    |
    v
[22.4 Data quality]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX024]

Learning outcomes and connection

After this chapter you can (1) build and maintain an asset and dependency inventory from several imperfect sources; (2) add time to a dependency model using backup autonomy; (3) compute which services are lost for outages of different lengths and identify the weak links; and (4) state the data-quality limits of such models. It builds on Chapters 6, 9 and 21 and prepares Chapter 23 (risk methods) and Chapter 28 (failure analysis).

22.1 Inventory is evidence, not a list

No organisation knows exactly what it has. Asset data comes from purchasing records, network observations, configuration databases, vendor documentation and walking the site; each source misses something. Treat the inventory as evidence with sources and dates (Chapter 15): for each asset record who confirmed it and when. Passive network observation finds devices that talk; it misses idle and serial devices. Active scanning finds more but can disrupt fragile OT devices and must only be done under authorisation with operations' agreement (Chapter 10). Dependencies are harder still: they live in people's heads, contracts and unwritten habits.

22.2 Kinds of dependency

Rinaldi and colleagues distinguish physical (power to pumps), cyber (telemetry over telecom), geographic (cables in the same trench) and logical (financial or regulatory ties) interdependencies (Rinaldi et al., 2001). Add people (one engineer who knows the legacy system) and suppliers (a single CAD vendor, a cloud region). Chapter 6's graph showed what can be affected; time turns it into what will be lost when. Each service has autonomy: how long it continues on its own backup — batteries, generators and fuel, stored water, paper processes.

22.3 Worked example and Lab 9 (synthetic)

This case is synthetic. The CRP collected backup autonomy for key services during a regional grid outage. Card payments depend on telecom exchange A, which has batteries only; exchange B also has a generator.

# Lab 9 - which services survive a grid outage of a given length? (synthetic backup autonomy, offline)
AUTONOMY_H = {  # hours each service keeps running on its own backup
    "hospital (generator, fuel on site)": 72, "telecom exchange A (batteries)": 4,
    "telecom exchange B (batteries + generator)": 48, "water pumps (no generator)": 0,
    "water treated storage": 10, "dispatch centre (UPS + generator)": 24,
    "card payments (relies on telecom)": None, "rail signalling (UPS)": 2,
}
for outage in (1, 6, 30):
    down = []
    for s, h in AUTONOMY_H.items():
        if h is None:   # dependent service: fails when 4-h exchange A fails
            h = AUTONOMY_H["telecom exchange A (batteries)"]
        if h < outage: down.append(s.split(" (")[0])
    print(f"outage {outage:>2} h -> {len(down)} services lost: {', '.join(down) or 'none'}")

Expected output:

outage  1 h -> 1 services lost: water pumps
outage  6 h -> 4 services lost: telecom exchange A, water pumps, card payments, rail signalling
outage 30 h -> 6 services lost: telecom exchange A, water pumps, water treated storage, dispatch centre, card payments, rail signalling

Interpretation: the shortest autonomies set the early story — pumps stop at once (customers still receive stored water for about 10 hours), rail signalling stops after 2 hours, and card payments fail after 4 hours because exchange A has no generator. At 30 hours, water supply and dispatch are lost. The hospital's 72 hours looks reassuring, but its water arrives from storage that lasts 10 hours: a building can be powered and still unusable. The model is crude — it ignores dependencies of the backups themselves (who refuels the dispatch generator after 24 hours, and over which roads?) — but it already identifies three cheap questions: can exchange A get a generator; can water pumps get a mobile generator connection point; and what fuel-delivery agreements exist across operators?

22.4 Data quality

Every number above is an operator's claim. Generator autonomy depends on fuel actually in the tank, starting reliability (Chapter 12, EX024) and load. Battery autonomy degrades with age. Record the evidence behind each autonomy — a test, a design figure, an estimate — and run the model with pessimistic values. A dependency model is only as good as its least-checked number.

In Lab 9, halving every autonomy (EX043) moves water treated storage into the 6-hour loss list.

For CEDC's generator, the evidence would be the last load test date and the fuel level on the day of the survey.

22.5 Common errors and limits

Treating one inventory source as complete.
Recording dependencies without time.
Taking autonomy figures from design documents without tests.
Forgetting second-order dependencies of backups (fuel, staff, roads).
Active scanning of OT without authorisation and operational agreement.

Lab 9 illustrates the first three: a design autonomy of 72 hours for the hospital assumes a full tank, and exchange A's 4 hours assumes healthy batteries. The fourth is the refuelling question behind the dispatch centre's 24 hours. The fifth is why the CRP's inventory relied on passive observation and operator statements rather than scanning.

Exercises — chapter 22

EX043 — Fix the weak link. Objective: test an intervention. Inputs: Lab 9. Steps: give card payments the autonomy of exchange B (48 h), and rerun. Then halve every autonomy (pessimistic case) and rerun for 6 h. Report both and recommend. Expected evidence: two outputs and a recommendation. Rubric: 3 = card payments survive to 48 h in the first run; the pessimistic 6-h run loses telecom exchange A, water pumps, water treated storage, card payments and rail signalling (5 services); recommendation addresses evidence for autonomy figures; 2 = runs without recommendation; 1 = one run; 0 = none.

EX044 — Second-order dependencies. Objective: look behind backups. Inputs: the dispatch centre's 24-hour generator. Steps: list four dependencies of that backup itself and one way to evidence each. Expected evidence: list. Rubric: 3 = fuel supply contract and delivery route, staff to operate/refuel, generator start reliability (test records), cooling/ventilation or switchgear; each with evidence; 2 = three; 1 = one or two; 0 = none.

Chapter synthesis

Inventories and dependency maps are evidence with sources, dates and gaps. Adding time — backup autonomy — turns exposure into a timeline of loss, exposes weak links such as a battery-only exchange and reveals that a powered building can still be unusable. Test autonomy claims and look behind each backup to its own dependencies.