Chapter 4 — Critical infrastructure and sector security: guided lab and applied synthesis

Chapter 4 — Critical infrastructure and sector security: guided lab and applied synthesis

Lesson map

Lesson 04 published. Map, example, EX050.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["4.1 Cascades"]
  N2["Visual 4 — why a power backup may not save the clini"]
  N3["4.2 Lab 4 — what else fails? synthetic"]
  N4["4.4 Practical activity and assessment rubric"]
  N5["Chapter synthesis"]
  N6["Chapter 1"]
  N7["Chapter 2"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX050"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["4.1 Cascades"]
  N2["Visual 4 — why a power backup may not save the clini"]
  N3["4.2 Lab 4 — what else fails? synthetic"]
  N4["4.4 Practical activity and assessment rubric"]
  N5["Chapter synthesis"]
  N6["Chapter 1"]
  N7["Chapter 2"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX050"]

[Learning outcomes and connection]
    |
    v
[4.1 Cascades]
    |
    v
[Visual 4 — why a power backup may not save the clini]
    |
    v
[4.2 Lab 4 — what else fails? synthetic]
    |
    v
[4.4 Practical activity and assessment rubric]
    |
    v
[Chapter synthesis]
    |
    v
[Chapter 1]
    |
    v
[Chapter 2]
    |
    v
[Worked example] --> [Exercise EX050]

Learning outcomes and connection

After this chapter you will be able to:

• read a simple dependency map written as text, including backups;
• predict, then check, which services fail when one service fails (a cascade);
• explain why a backup can fail to protect a service, and what a model leaves out;
• produce a one-page, annotated service card that brings together Chapters 1–3;
• check your own readiness with a short course self-check.

This chapter applies everything so far: consequence first (Chapter 1), safe practice on synthetic data only (Chapter 2) and dependencies (Chapter 3). It completes the course's guided task.

4.1 Cascades

When one service fails and others that depend on it fail in turn, the failure cascades. Cascades are why critical infrastructure is treated as a connected system rather than a list of separate organizations, and why national lists group services into functions that depend on one another (CISA, National Critical Functions Set). The Ukrainian outages and the pipeline ransomware incident in earlier chapters both had effects far beyond the first organization hit.

You can reason about cascades with a pencil: draw each service, draw an arrow to each thing it needs, then "switch off" one box and follow the arrows backwards. A few lines of code can do the same bookkeeping without mistakes, which is what Lab 4 does.

Visual 4 — why a power backup may not save the clinic (synthetic)

flowchart LR
    P[Grid power fails] --> N[Phone network fails]
    P --> W[Water pumps fail]
    N --> C[Clinic cannot operate]
    W --> C
    G[Diesel generator works] --> L[Clinic has local power]
    L -. insufficient without phones and water .-> C
    C --> PH[Pharmacy loses an upstream service]

Text alternative: in Lab 4's synthetic map, losing grid power also removes the phone network and water pumps. The generator preserves local electricity, but the clinic still cannot operate without phones and water, and the pharmacy then loses the clinic. The model omits time, partial failures and manual workarounds; confirm real dependencies with the service owner.

4.2 Lab 4 — what else fails? (synthetic)

Goal: trace the cascade when one or two Larkfield services fail. Inputs: the synthetic map in the code. Authorized scope: your own computer only; no network, no real data. Steps: read the map; before looking at the output, write down what you expect to fail for each scenario; then compare with the printed output (or run python3 lab4.py). Expected evidence: your predictions, the output and one sentence per difference.

How to read the map: each line is service ; what it needs. Needs are separated by commas — the service needs all of them. A vertical bar a|b means either a or b is enough (b is a backup for a). A service with nothing after the semicolon depends on nothing in this model.

# Lab 4 - who is affected if one thing fails? (offline, standard library only; all data synthetic)
# Each line: service ; what it needs to keep working (comma-separated)
MAP = """
grid power      ;
backup diesel   ; fuel delivery
fuel delivery   ; roads
roads           ;
phone network   ; grid power
water pumps     ; grid power, phone network
clinic          ; grid power|backup diesel, water pumps, phone network
card payments   ; phone network, grid power
pharmacy        ; card payments, clinic
"""
needs = {}
for line in MAP.strip().splitlines():
    name, deps = (part.strip() for part in line.split(";"))
    # "a|b" means: either a or b is enough (a backup)
    needs[name] = [set(d.strip().split("|")) for d in deps.split(",") if d.strip()]

def still_working(failed):
    up = {s for s in needs if s not in failed}
    changed = True
    while changed:
        changed = False
        for s in sorted(up):
            for options in needs[s]:
                if not (options & up):
                    up.discard(s)
                    changed = True
                    break
    return up

for failed in (["grid power"], ["phone network"], ["roads"], ["grid power", "roads"]):
    up = still_working(set(failed))
    down = sorted(set(needs) - up - set(failed))
    print(f"FAIL {' + '.join(failed):<20} -> also down: {', '.join(down) if down else '(nothing else)'}")

Output (Python 3.13.5):

FAIL grid power           -> also down: card payments, clinic, pharmacy, phone network, water pumps
FAIL phone network        -> also down: card payments, clinic, pharmacy, water pumps
FAIL roads                -> also down: backup diesel, fuel delivery
FAIL grid power + roads   -> also down: backup diesel, card payments, clinic, fuel delivery, pharmacy, phone network, water pumps

Reading the result.

1. Grid power fails. The clinic has a diesel backup, yet the clinic still goes down. Why? The clinic also needs water pumps and the phone network, and in this map both need grid power with no backup. The generator keeps the clinic's lights on, but without water and phones it cannot work. A backup protects one dependency, not the whole service.
2. Phone network fails. The water pumps go down — because in this map the pumps need the phone network (think of remote control and telemetry). Then the clinic and pharmacy follow. Whether real pumps stop when communications fail is exactly the kind of question to ask an owner; many stations can run locally. The model is only as true as its lines.
3. Roads fail. Only fuel delivery and backup diesel go down. Nothing else is affected — while the grid is up. The backup has quietly failed, and nobody would notice until it was needed.
4. Grid and roads fail together. Everything goes down. Real crises (storms, floods) often break several things at once.

What the model leaves out. Time (the generator has two hours of fuel, the phone network may have batteries), partial failure (a weak signal, a slow system), people (staff who cannot reach work) and manual fallbacks (cash payments, paper lists). A model helps you ask better questions; it does not tell you what will really happen.

Trying a change. Two "what if" edits show how backups change the picture. These outputs were produced by editing the map exactly as described:

• Edit A: give the phone network a battery — change its line to phone network ; grid power|phone battery and add a line phone battery ;. Grid failure now takes down: card payments, clinic, pharmacy, water pumps. The phones survive, but the clinic still fails because the water pumps still need grid power.
• Edit B: Edit A plus give the water pumps the diesel backup — water pumps ; grid power|backup diesel, phone network. Grid failure now takes down only: card payments, pharmacy. The clinic survives. The pharmacy fails because card payments need grid power directly — which suggests the question "can the pharmacy take cash or record sales on paper?"

4.3 Worked example: Sam's service card (synthetic)

The course's annotated artifact is a one-page service card: a plain-language summary of one essential service that a newcomer can write from public or synthetic information. Sam's card for the clinic:

Service card — Larkfield Community Clinic (synthetic) · Author: Sam Reyes · Date: week 4 · Sharing: TLP:AMBER+STRICT (inside the clinic only)

Function: provide walk-in medical care and dispense medicines to about 20,000 residents. First harmed if it stops: patients needing same-day care and repeat prescriptions; the pharmacy downstream.

Order of concern: (1) safety — wrong or missing medicines, vaccines kept at the wrong temperature; (2) continuity — no appointment list or phones; (3) trust — wrong records; (4) privacy — patient data leaked.

Key dependencies: grid power (backup: generator, 2 h fuel — depends on fuel delivery); LinkNet phones and internet (no backup known); MedBook (cloud); Larkfield Water; one nurse who knows the fridge alarm.

Two risk sentences: (a) Because LinkNet is our only connection, a LinkNet outage could stop appointments, phone bookings and card payments at once, leading to patients being turned away for hours. (b) Because staff receive fake MedBook emails, someone could enter their password on a fake page, leading to an outsider locking the appointment list.

Lab finding (synthetic map): in Lab 4, a grid failure stops the clinic even with the generator, because water pumps and phones also fail.

Assumed / unknown: that there is no paper appointment list; whether LinkNet has a battery backup; whether MedBook uses a second factor.

Questions for the owner (H. Novak): Is there a daily printed list? Is a second internet line or mobile backup possible? Can someone else be trained on the fridge alarm?

What I did not do: contact LinkNet or MedBook, test any system, or change any setting.

Every line can be traced to something learned in the course, and every guess is marked.

4.4 Practical activity and assessment rubric

Write your own service card for a service you choose (from public information) or for Larkfield Water using the synthetic details in this book. Use the headings in 4.3. Then complete the self-check below without notes.

A card scoring 12 or more of 15, with no zero, meets the course standard.

Course self-check (short quiz). Answer in one line each, then check the worked results under EX050.

1. Name two critical-infrastructure sectors.
2. Put in order: confidentiality, safety, availability.
3. Is having a login the same as having permission?
4. What are the five parts of a good report?
5. Who may receive TLP:RED information?
6. What does a PLC do?
7. What is a shared dependency?
8. Why can a backup fail to protect a service?

4.5 Common errors and limits

• Reading the lab output as a prediction of reality rather than a consequence of the map's lines.
• Forgetting that a|b means either and commas mean all.
• Adding a backup and assuming the whole service is now safe.
• Writing a service card full of unmarked guesses, or gathering facts by probing a real service.
• Limits: the lab ignores time, partial failure, people and manual fallbacks; real dependency analysis is done by owners with real data and is taught in later courses.

Exercises — chapter 4

EX039 — Read the map. Objective: interpret notation. Inputs: the line clinic ; grid power|backup diesel, water pumps, phone network. Steps: explain in words what the clinic needs. Expected evidence: one or two sentences. Rubric: 3 = needs (grid power or backup diesel) and water pumps and phone network — all three groups; 2 = minor slip about either/all; 1 = treats all as alternatives; 0 = none.

EX040 — Predict before you look. Objective: practise prediction. Inputs: the map, scenario "grid power fails". Steps: without the output, list what you expect to fail, then compare. Expected evidence: prediction, output, one sentence per difference. Rubric: 3 = honest prediction recorded, differences explained (especially why the clinic fails despite the generator); 2 = comparison without explanation; 1 = copies output only; 0 = none.

EX041 — Why the generator was not enough. Objective: explain the key result. Inputs: output line 1. Steps: explain in two sentences. Expected evidence: explanation. Rubric: 3 = generator covers power only; clinic also needs water pumps and phones, which fail without grid power; 2 = mentions one; 1 = vague; 0 = none.

EX042 — Silent failure. Objective: recognize hidden loss of backup. Inputs: output line 3. Steps: explain why "roads fail" is more worrying than it looks and suggest one way an owner might notice. Expected evidence: two sentences. Rubric: 3 = nothing visible fails but the clinic has lost its backup while the grid is up; owner could check fuel levels/delivery status or test the generator regularly; 2 = first part only; 1 = "nothing happens, so fine"; 0 = none.

EX043 — Question the model. Objective: challenge assumptions. Inputs: output line 2 (pumps fail when phones fail). Steps: write one question for the water owner and say why the answer matters. Expected evidence: question and reason. Rubric: 3 = asks whether pumps can run locally/manually without communications, explaining that if yes the cascade to the clinic would not happen; 2 = question without reason; 1 = accepts the output as fact; 0 = none.

EX044 — Edit A. Objective: reason about a change. Inputs: Edit A result. Steps: explain why the clinic still fails with a phone battery. Expected evidence: one or two sentences. Rubric: 3 = phones now survive, but water pumps still need grid power with no backup, and the clinic needs water; 2 = partial; 1 = wrong; 0 = none.

EX045 — Edit B. Objective: follow a second change. Inputs: Edit B result. Steps: explain why the clinic survives and the pharmacy does not, and propose one manual fallback for the pharmacy. Expected evidence: explanation and fallback. Rubric: 3 = clinic's power, water and phones now all have a working path; pharmacy needs card payments, which need grid power directly; fallback such as cash or paper records with later entry; 2 = explanation only; 1 = vague; 0 = none.

EX046 — What the model leaves out. Objective: state limits. Inputs: section 4.2. Steps: name three things the lab does not model and how each could change the result. Expected evidence: three pairs. Rubric: 3 = three of time, partial failure, people, manual fallbacks, each with an effect (for example, the generator runs out after two hours); 2 = three without effects; 1 = one or two; 0 = none.

EX047 — Draw it. Objective: turn text into a diagram. Inputs: the original map. Steps: draw boxes and arrows (on paper or as a text sketch) and shade what fails when the phone network fails. Expected evidence: diagram with shading matching output line 2. Rubric: 3 = all nine services, arrows from dependant to dependency, either/or marked, correct shading; 2 = one error; 1 = several; 0 = none.

EX048 — Write a service card. Objective: produce the course artifact. Inputs: the synthetic Larkfield Water details in Chapters 1–4 (pumps, treatment, D. Brandt, power, LinkNet, the pump supplier). Steps: write a service card using the 4.3 headings. Expected evidence: one-page card. Rubric: use the 4.4 rubric; 3 = 13–15 with no zero; 2 = 10–12; 1 = 6–9; 0 = below 6.

EX049 — Peer review. Objective: assess against a rubric. Inputs: Sam's card in 4.3. Steps: score it with the 4.4 rubric and name one improvement. Expected evidence: five scores, total and improvement. Rubric: 3 = defensible scores (high in most criteria) with a concrete improvement (for example, add a downstream dependant beyond the pharmacy, or a contact for reporting); 2 = scores without improvement; 1 = scores unjustified; 0 = none.

EX050 — Course self-check. Objective: confirm core knowledge. Inputs: the eight questions in 4.4. Steps: answer each in one line without notes. Expected evidence: eight answers. Rubric: 3 = seven or eight correct; 2 = five or six; 1 = three or four; 0 = fewer.

Chapter synthesis

Failures in critical infrastructure cascade along dependencies, and backups protect only the dependency they replace — and only while their own dependencies hold. A small, synthetic model makes cascades visible and, more importantly, produces good questions; it never replaces the owner's knowledge. The service card brings the course together in one honest page: function, consequence order, dependencies, risk sentences, assumptions and what you did not do.

Continue studying — chapter 04 of 04

← Chapter 03 · Course chapter index · Next course via chapter index →

This is the final chapter of this course; the index links the next course in the full study path.