Chapter 3 — Critical infrastructure and sector security: systems, data and dependencies

Lesson map

Lesson 03 published. Map, example, EX027.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["3.1 The five parts of a service"]
  N2["3.2 A gentle look at operational technology"]
  N3["3.3 Data and what could go wrong"]
  N4["3.4 Dependencies"]
  N5["3.5 Suppliers and remote access"]
  N6["Visual 3 — the clinic's dependencies synthetic"]
  N7["3.7 Practical activity"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX027"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["3.1 The five parts of a service"]
  N2["3.2 A gentle look at operational technology"]
  N3["3.3 Data and what could go wrong"]
  N4["3.4 Dependencies"]
  N5["3.5 Suppliers and remote access"]
  N6["Visual 3 — the clinic's dependencies synthetic"]
  N7["3.7 Practical activity"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]

[Learning outcomes and connection]
    |
    v
[3.1 The five parts of a service]
    |
    v
[3.2 A gentle look at operational technology]
    |
    v
[3.3 Data and what could go wrong]
    |
    v
[3.4 Dependencies]
    |
    v
[3.5 Suppliers and remote access]
    |
    v
[Visual 3 — the clinic's dependencies synthetic]
    |
    v
[3.7 Practical activity]
    |
    v
[Worked example] --> [Exercise EX027]

Learning outcomes and connection

After this chapter you will be able to:

• describe the five parts of an essential service: people, IT, operational technology, data and suppliers;
• explain in plain words what sensors, controllers, operator screens and SCADA do, and how OT differs from office IT;
• name the main kinds of data in a sector and what harm each could cause if lost, changed or leaked;
• tell upstream, downstream and shared dependencies apart;
• spot a single point of failure and a manual fallback in a simple description.

Chapter 2 set your boundaries. Here you learn to see a service clearly from the outside, which prepares the guided lab in Chapter 4.

3.1 The five parts of a service

Lesson table; scroll horizontally to read all columns →

Security problems can start in any part. Many start with people (a convincing email) or suppliers (a remote-access account), not with clever technology.

3.2 A gentle look at operational technology

You do not need to configure OT to understand it. A simplified picture of a water pumping station:

• Sensors measure things: water level in a tank, pressure in a pipe, chlorine concentration.
• Actuators do things: start a pump, open a valve, add chemical.
• A controller — often a PLC (programmable logic controller), a rugged small computer — reads the sensors and drives the actuators by simple rules ("if the tank is below 30%, start pump 2").
• An HMI (human–machine interface) is the operator's screen showing levels and alarms and letting them change settings.
• SCADA (supervisory control and data acquisition) is the wider system that collects readings from many sites into a control room.

NIST's guide to OT security describes these components and why OT differs from IT (NIST SP 800-82 Rev. 3). Three differences matter for a newcomer:

Lesson table; scroll horizontally to read all columns →

This is why Chapter 2 forbade "just checking": OT devices may be old and sensitive, and what they control is real.

3.3 Data and what could go wrong

Lesson table; scroll horizontally to read all columns →

Notice the middle column for operational data: a wrong reading can be more dangerous than a stolen one, because people make decisions on it.

3.4 Dependencies

No service stands alone. A dependency is something a service needs in order to work.

• Upstream dependencies are what your service needs: power, water, phones, internet, staff, supplies.
• Downstream dependants are those who need your service: patients, households, other services.
• Shared dependencies are used by many services at once: one phone network, one fuel depot, one software supplier. Their failure hits many services together.

A single point of failure is one thing whose loss stops the service because there is no alternative. A backup (a generator, a second internet line) or a manual fallback (paper appointment lists, operators reading gauges by hand) reduces the impact. But a backup is only as good as its own dependencies: a diesel generator needs fuel deliveries, which need roads and drivers. Chapter 4's lab makes this visible.

3.5 Suppliers and remote access

Many essential services let suppliers connect remotely to maintain software and equipment. That is useful — and it is a door. CISA's guidance for OT owners lists reducing internet exposure, changing default passwords and securing remote access among the primary mitigations (CISA, Primary Mitigations to Reduce Cyber Threats to Operational Technology). CISA's Cross-Sector Cybersecurity Performance Goals likewise set out baseline practices such as multi-factor authentication and asset inventory that apply across sectors (CISA CPGs). As a newcomer, you will not manage these accounts, but you should recognize the risk when you hear "the supplier logs in whenever they like with a shared password".

The 2021 ransomware attack on a U.S. pipeline company, described by CISA and the FBI in their advisory, is also a dependency lesson: an attack on business IT systems affected the operation of fuel supply that many others relied on downstream (CISA AA21-131A).

3.6 Worked example: what does the clinic depend on? (synthetic)

Sam is asked by H. Novak to list, for a staff meeting, what the clinic needs to open its doors. Sam walks through a normal morning and writes:

Lesson table; scroll horizontally to read all columns →

Sam marks three questions, not conclusions: Is LinkNet a single point of failure? Is there a paper fallback for MedBook? Who else knows the fridge alarm? These go to H. Novak — the owner — who decides what, if anything, to change.

Visual 3 — the clinic's dependencies (synthetic)

flowchart LR
    P[Grid power] --> C[Clinic]
    G[Diesel generator] -. backup for power only .-> C
    F[Fuel delivery] --> G
    N[LinkNet phones and internet] --> C
    W[Clean water] --> C
    M[MedBook appointment service] --> C
    S[Clinic staff] --> C
    C --> T[Patients and pharmacy]

Text alternative: power, LinkNet, water, MedBook and staff feed the clinic, which serves patients and the pharmacy. The generator is only a power backup and itself needs fuel delivery. A question mark remains over the other dependencies' backups; this sketch does not prove a real clinic would fail in the same way.

3.7 Practical activity

Choose a public essential service near you (or the Larkfield Water plant described above). Using only public information and common sense, draw a simple dependency sketch: the service in the middle, upstream dependencies on the left, downstream dependants on the right. Circle anything shared, star any possible single point of failure, and write one question you would ask the owner. Do not contact or probe the service.

Compare your sketch with Sam's clinic dependency table: did you remember people and suppliers as well as power and water? If you chose Larkfield Water, your sketch should show the clinic and households on the downstream side and should treat LinkNet as shared. Write your question for the owner so that it can be answered yes or no.

3.8 Common errors and limits

• Thinking only of computers and forgetting people, suppliers and buildings.
• Treating OT like office IT ("just restart it").
• Listing upstream dependencies but forgetting downstream people who are harmed.
• Assuming a backup works without asking what it depends on.
• Stating guesses as facts; in this chapter, a dependency list is a set of questions for the owner.
• Forgetting that one person can be a single point of failure, like the one nurse who knows the clinic's fridge alarm.
• Contacting a supplier or utility to check a dependency yourself, instead of passing the question to the owner.
• Limits: real OT architectures are far more varied than the simple picture in 3.2.

Exercises — chapter 3

EX027 — Five parts. Objective: classify service parts. Inputs: (a) the clinic's vaccine-fridge controller; (b) MedBook; (c) the nurse who knows the fridge alarm; (d) prescriptions; (e) LinkNet. Steps: assign each to people, IT, OT, data or suppliers. Expected evidence: five assignments. Rubric: 3 = a OT, b IT (and a supplier), c people, d data, e supplier; 2 = four; 1 = two or three; 0 = fewer.

EX028 — OT components. Objective: explain OT terms in plain words. Inputs: sensor, actuator, PLC, HMI, SCADA. Steps: give a one-line plain definition and a water-station example for each. Expected evidence: five lines. Rubric: 3 = all correct with examples; 2 = four; 1 = two or three; 0 = fewer.

EX029 — IT versus OT. Objective: compare. Inputs: section 3.2. Steps: give two differences and say why each matters for security. Expected evidence: two pairs. Rubric: 3 = two correct differences (continuity, physical consequence, lifespan) with security implications (changes need planning, harm can be physical, old devices may lack protections); 2 = differences without implications; 1 = one; 0 = none.

EX030 — Wrong reading. Objective: see integrity risk in OT. Inputs: the HMI at a water station shows the tank 80% full, but it is really 10%. Steps: describe what the operator might do and the possible consequence. Expected evidence: two or three sentences. Rubric: 3 = operator does not start pumps, tank runs dry, pressure or supply lost to customers including the clinic; notes that a manual check would reveal it; 2 = consequence without operator action; 1 = vague; 0 = none.

EX031 — Data harms. Objective: apply the CIA view to data. Inputs: "prescription records". Steps: describe one harm each if leaked, changed and unavailable. Expected evidence: three harms. Rubric: 3 = privacy harm/legal duty; wrong medicine or dose; patients cannot receive medicines; 2 = two; 1 = one; 0 = none.

EX032 — Upstream, downstream, shared. Objective: classify dependencies. Inputs: for Larkfield Water: (a) Larkfield Power; (b) households; (c) the chemical supplier; (d) the clinic; (e) LinkNet, also used by the clinic and bank. Steps: classify each. Expected evidence: five answers. Rubric: 3 = a upstream (shared), b downstream, c upstream, d downstream, e upstream and shared; 2 = four; 1 = two or three; 0 = fewer.

EX033 — Single point of failure. Objective: spot it. Inputs: the table in 3.6. Steps: name the item most likely to be a single point of failure and explain. Expected evidence: answer and reason. Rubric: 3 = LinkNet: no known backup and loses MedBook, phones and payments at once; noted as a question to confirm; 2 = correct item without caution; 1 = picks an item with a backup; 0 = none.

EX034 — Backup of a backup. Objective: trace backup dependencies. Inputs: the clinic generator with two hours of fuel. Steps: list what the generator depends on for a 24-hour outage. Expected evidence: list. Rubric: 3 = fuel delivery, which needs roads, a supplier and drivers, plus someone who knows how to run and test the generator; 2 = fuel only; 1 = "nothing"; 0 = none.

EX035 — Manual fallback. Objective: recognize fallbacks. Inputs: the MedBook dependency. Steps: propose one manual fallback and one condition for it to work. Expected evidence: fallback and condition. Rubric: 3 = a daily printed appointment list (or paper booking form) that is current, stored safely and that staff know how to use; 2 = fallback without condition; 1 = "fix MedBook"; 0 = none.

EX036 — Supplier door. Objective: recognize remote-access risk. Inputs: D. Brandt says "the pump supplier logs in from home whenever they want; everyone uses the same password". Steps: write a risk sentence and name two baseline practices from the cited CISA guidance that relate to it. Expected evidence: sentence and two practices. Rubric: 3 = cause-event-consequence sentence about unauthorized pump control; practices such as securing remote access, MFA, changing default/shared passwords, limiting internet exposure; 2 = sentence and one practice; 1 = practice only; 0 = none.

EX037 — Pipeline lesson. Objective: draw a dependency lesson. Inputs: CISA AA21-131A. Steps: explain in two sentences why an attack on one company's business systems mattered to many others. Expected evidence: two sentences. Rubric: 3 = pipeline fuel supply is a shared upstream dependency for many downstream users, so disruption spread beyond the victim; 2 = mentions disruption only; 1 = technical detail only; 0 = none.

EX038 — Questions, not conclusions. Objective: communicate uncertainty. Inputs: Sam's three questions in 3.6. Steps: rewrite one as a short message to H. Novak, marking what is known and assumed. Expected evidence: message. Rubric: 3 = polite, factual, separates known (no backup line listed) from assumed (that none exists), asks the owner to decide; 2 = good message without known/assumed split; 1 = states a guess as fact; 0 = none.

Chapter synthesis

An essential service is people, IT, operational technology, data and suppliers working together. OT senses and controls the physical world, must run continuously and can cause physical harm when it fails, which is why a wrong reading may be worse than a stolen one. Services depend upstream, serve people downstream and share dependencies with each other; single points of failure and backups that have their own dependencies are where trouble hides. A newcomer's dependency list is a set of good questions for the owner.