Chapter 10 — Critical infrastructure and sector security: orientation

Lesson map

Lesson 10 published. Map, example, EX028.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["10.1 What makes a service critical"]
  N2["10.2 How sectors differ"]
  N3["10.3 Dependencies and interdependencies"]
  N4["10.4 The operator's obligations and your part in the"]
  N5["10.6 Practical activity: consequence and deadline ta"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX028"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["10.1 What makes a service critical"]
  N2["10.2 How sectors differ"]
  N3["10.3 Dependencies and interdependencies"]
  N4["10.4 The operator's obligations and your part in the"]
  N5["10.6 Practical activity: consequence and deadline ta"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX028"]

[Learning outcomes and connection]
    |
    v
[10.1 What makes a service critical]
    |
    v
[10.2 How sectors differ]
    |
    v
[10.3 Dependencies and interdependencies]
    |
    v
[10.4 The operator's obligations and your part in the]
    |
    v
[10.6 Practical activity: consequence and deadline ta]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX028]

Learning outcomes and connection

After this chapter you should be able to:

• explain what makes a service critical: the consequence of its loss for people, other services and society;
• describe how water, health, energy, transport and finance differ in what they protect, how fast harm arrives and who regulates them;
• identify dependencies and interdependencies that turn a local fault into a regional one;
• place your own work as an implementer within the obligations an operator carries.

Chapters 1–9 built general skills. From here the book applies them to critical services specifically. This chapter is orientation: the shape of the field, enough to understand why a technologist at FSTS must think about a pumping station, a hospital and a bus depot differently even when the servers look alike.

10.1 What makes a service critical

A service is critical when its disruption would seriously harm health, safety, security, economic activity or the functioning of society. Governments formalize this differently. The United States describes National Critical Functions — functions so vital that their disruption would have a debilitating effect — rather than only lists of sectors (CISA National Critical Functions). The European Union's NIS2 Directive sets cybersecurity risk-management and reporting obligations for entities in sectors of high criticality (Directive (EU) 2022/2555), and the CER Directive addresses the physical and wider resilience of critical entities (Directive (EU) 2022/2557). These texts change; check the current version and how your jurisdiction applies it. This book gives no legal advice.

For an implementer the practical meaning is simpler: the unit of harm is people and time, not data records or money alone. "41,000 people without reliable water information for six hours" is the kind of statement that should drive priorities.

10.2 How sectors differ

Lesson table; scroll horizontally to read all columns →

The differences change implementation choices. A patch on a hospital infusion-pump gateway needs clinical-engineering sign-off; a firewall change at a pumping station may need a site visit and an outage window; a depot kiosk can usually be rebuilt the same day. Treating them all with one IT change process either slows the safe changes or rushes the dangerous ones.

10.3 Dependencies and interdependencies

Critical services depend on each other: water needs electricity for pumps and telecoms for telemetry; hospitals need water, electricity and telecoms; everyone depends on a small number of suppliers. Rinaldi and colleagues' classic paper classifies interdependencies as physical, cyber, geographic and logical (Rinaldi, Peerenboom and Kelly, 2001). At FSTS, the most important interdependency is organizational: the same small team, the same jump host and the same suppliers serve all three operators. A single compromised FSTS administrator account touches water, health and transport at once.

10.4 The operator's obligations and your part in them

Operators of essential services typically carry obligations to manage cyber risk, report significant incidents within set times, maintain continuity plans and cooperate with authorities. Frameworks such as the UK NCSC Cyber Assessment Framework express these as outcomes to be achieved (NCSC CAF); CISA's Cross-Sector Cybersecurity Performance Goals offer a baseline of practices (CISA CPGs). An implementer rarely owns these obligations, but produces most of the evidence for them: asset lists, access reviews, logs, test results, incident timelines. If that evidence is late or wrong, the operator's report is late or wrong.

10.5 Worked example: one fault, three customers (synthetic)

At 02:10 the FSTS jump host fails a disk. Water operations loses remote administration of the relays but keeps telemetry (the relays still run). The hospital's clinical engineers cannot reach the infusion-pump gateway to load a drug-library update scheduled for 06:00. The depot cannot push a timetable change to kiosks. The same fault has three different consequences with three different deadlines. The on-call technologist who recognizes this calls Clinical Engineering first — because the 06:00 update has a patient-safety purpose — even though Water is the largest customer.

10.6 Practical activity: consequence and deadline table

For each Fallowmere customer, list three FSTS-run systems. For each system write: what people lose if it stops, how quickly that loss becomes harmful, who decides on emergency action, and which other system it depends on. Keep this table; Chapter 11 turns it into an inventory with dependencies.

For Fallowmere Community Hospital, one row might read: infusion-pump gateway; loss, drug-library updates cannot be loaded; harmful within hours if a scheduled update such as the 06:00 one is missed; Clinical Engineering decides; depends on the FSTS jump host. That row is why the jump-host failure in the worked example was escalated to the hospital before Water.

10.7 Common errors and limits

• Treating every system run by an IT team as having the same consequence.
• Measuring harm only in data or money.
• Ignoring shared people, tools and suppliers as dependencies.
• Quoting regulations from memory; their scope and deadlines change and differ by jurisdiction.
• Assuming the implementer has no part in the operator's obligations.

The jump-host failure shows the first and third errors together: one shared FSTS host had three consequences with three deadlines.

Measuring harm only in money would have ranked Water first that night, because it is the largest customer, and missed the 06:00 drug-library update.

Exercises — chapter 10

EX028 — Consequence in people and time. Objective: express harm in service units. Inputs: the Chapter 10 ("Worked example: one fault, three customers") scenario. Constraints: synthetic numbers only; state assumptions. Steps: for each customer write one sentence of the form "N people lose X for T, becoming harmful after D because…". Expected evidence: three sentences with assumptions. Rubric: 3 = three specific, plausible, assumption-labelled statements showing different deadlines, with the hospital's patient-safety deadline identified as the earliest; 2 = one generic; 1 = all in money; 0 = none.

EX029 — Shared dependency map. Objective: find interdependencies created by a shared service. Inputs: FSTS runs one jump host, one SIEM, one identity directory and one backup system for all three customers; Kell supplies water RTUs, BayTel carries water telemetry and hospital internet. Constraints: use Rinaldi's four types. Steps: (1) classify each dependency; (2) name the single failure with the widest effect; (3) propose one change to reduce it. Expected evidence: table and paragraph. Rubric: 3 = shared FSTS systems as cyber/logical, BayTel as a cyber/physical common carrier, staff as logical; identity directory or jump host compromise identified as widest; a practical change such as per-customer privileged tiers or a second carrier path for telemetry; 2 = classification weak; 1 = list only; 0 = none.

EX030 — Evidence you owe. Objective: connect daily work to operator obligations. Inputs: CISA CPGs or NCSC CAF (choose one; cite the version you read). Constraints: three outcomes or goals. Steps: for each, name the evidence an FSTS technologist produces for it, how often, and where it is kept. Expected evidence: table with citation. Rubric: 3 = three correctly cited outcomes/goals (for example asset inventory, MFA, log collection) each with specific, regularly produced evidence; 2 = evidence vague; 1 = no citation; 0 = none.

Chapter synthesis

A service is critical because of what its loss does to people, measured in people and time. Sectors differ in what they protect first and how fast harm arrives, so the same technical fault needs different responses. Shared services such as FSTS create interdependencies through people, tools and suppliers. Operators carry the legal obligations; implementers produce most of the evidence that shows they are met.