Chapter 20 — Critical infrastructure and sector security: engineering context

Chapter 20 — Critical infrastructure and sector security: engineering context

Lesson map

Lesson 20 published. Map, example, EX039.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["20.1 What makes infrastructure critical"]
  N2["20.2 Sectors as engineering systems"]
  N3["20.3 Interdependency"]
  N4["20.4 Learning from documented incidents"]
  N5["20.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX039"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["20.1 What makes infrastructure critical"]
  N2["20.2 Sectors as engineering systems"]
  N3["20.3 Interdependency"]
  N4["20.4 Learning from documented incidents"]
  N5["20.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX039"]

[Learning outcomes and connection]
    |
    v
[20.1 What makes infrastructure critical]
    |
    v
[20.2 Sectors as engineering systems]
    |
    v
[20.3 Interdependency]
    |
    v
[20.4 Learning from documented incidents]
    |
    v
[20.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX039]

Learning outcomes and connection

After this chapter you can (1) describe how critical infrastructure is defined and organised into sectors, and the regulatory landscape engineers work within; (2) characterise sectors by their physical processes, consequence units and technology; (3) describe interdependencies between sectors; and (4) learn from documented incidents at the level their public sources support. It is the bridge from foundations (Chapters 1–19) to the field chapters (21–50).

20.1 What makes infrastructure "critical"

Governments designate as critical the assets, systems and networks whose incapacity would seriously harm security, the economy, public health or safety. The United States identifies sixteen critical infrastructure sectors and, more recently, a set of National Critical Functions that cut across organisations. The European Union's NIS2 Directive (2022/2555) sets cybersecurity obligations for essential and important entities, and the CER Directive (2022/2557) addresses the resilience of critical entities more broadly. Sector rules add detail: NERC CIP standards for North American bulk electric systems, the America's Water Infrastructure Act 2018 risk assessment requirements for US community water systems, DORA (2022/2554) for EU finance, and the HHS Healthcare and Public Health Cybersecurity Performance Goals. These change; cite version and date and re-verify.

20.2 Sectors as engineering systems

Each sector has a physical or service process, a consequence unit and characteristic technology.

The table is a simplification for engineering orientation; each row is a career.

20.3 Interdependency

Rinaldi, Peerenboom and Kelly (2001) classify interdependencies as physical, cyber, geographic and logical. Water needs electricity for pumping; electricity restoration needs communications; hospitals need water, power and communications; nearly everything needs accurate time. Interdependency turns local failures into regional ones and turns shared suppliers into common causes. The July 2024 faulty CrowdStrike update, which Microsoft estimated affected about 8.5 million Windows devices (Microsoft, 2024), was not an attack, but it disrupted airlines, hospitals and other services at once through a shared software dependency.

20.4 Learning from documented incidents

Public incident reports are valuable and partial. Use them at the level of their sources. The Colonial Pipeline incident in 2021 involved ransomware on business IT; the company shut down pipeline operations as a precaution — a reminder that dependency of operations on IT systems (billing, scheduling) can halt physical service without any OT compromise. The 2015 Ukrainian grid attack used remote access to operate breakers and damaged recovery capabilities. The 2017 WannaCry outbreak disrupted NHS services in England. Each has documented details and open questions; where early accounts were revised, as at Oldsmar, cite both.

20.5 Worked example: placing LRWA in context (synthetic)

LRWA is a water utility with a hospital among its critical customers. Its consequence unit is people-hours without safe water, weighted for vulnerable users; St Brenna's on-site storage gives about four hours of buffer. Its interdependencies: electricity (pumping, treatment), communications (LTE telemetry), chemical supply (chlorine) and time (log correlation). Its regulatory context is assumed to include a risk-and-resilience assessment duty similar to AWIA. The TMRP's scope is defined by these: the programme is not "secure the SCADA" but "keep safe water flowing to people under credible adverse conditions, including attack".

20.6 Practical activity

Choose one sector other than water. From public sources only, build its row of §20.2 in more detail: three consequence units, three typical technologies, two key regulations with version and date, and one documented incident with its source.

Keep the profile at the level of your sources. For each regulation, give the version, the date you consulted it and the entities it covers. For the incident, state only what the cited report says, and note any later revision, as with Oldsmar. Then compare your sector's consequence unit with LRWA's people-hours without safe water, and note one interdependency your sector shares with water, such as electricity, communications or time.

20.7 Common errors and limits

• Treating "critical infrastructure" as a technology category rather than a consequence category.
• Regulations quoted without version or date.
• Incident narratives repeated beyond what sources support.
• Ignoring IT dependencies of physical operations.
• One-sector thinking in an interdependent world.

LRWA's own context shows why these matter. Its critical status comes from St Brenna's and its other customers, not from the technology it runs. Its operations depend on electricity, LTE, chlorine supply and accurate time, so analysing water in isolation would miss the hidden feeder dependency found earlier. Any regulatory duty it relies on must be cited with a version and a date.

Exercises — chapter 20

EX039 — Sector profile. Objective: profile a sector from public sources. Inputs: §20.6. Steps: produce the profile with citations. Expected evidence: one page. Rubric: 3 = accurate, cited, consequence units measurable, incident described within its sources; 2 = one uncited claim; 1 = generic; 0 = none.

EX040 — Shared dependency. Objective: reason about common causes across sectors. Inputs: the July 2024 CrowdStrike outage as described by Microsoft. Steps: explain in 200 words why a non-malicious software update produced cross-sector disruption, what engineering property it reveals, and one design practice that limits such events. Expected evidence: text. Rubric: 3 = shared dependency/common cause, privileged auto-updating component, staged rollout or diversity as practice, claims within sources; 2 = practice generic; 1 = calls it an attack; 0 = none.

Chapter synthesis

Critical infrastructure is defined by consequence. Sectors differ in process, consequence units and technology but share interdependency on power, communications, time and common suppliers. Work within regulations by version and date, learn from incidents only as far as their sources go, and define every security programme by the service and people it protects.

Continue studying — chapter 20 of 50

← Chapter 19 · Course chapter index · Chapter 21 →

Continue to the next authored lesson.