Chapter 1 — Security foundations for practitioners

Lesson map

Lesson 01 published. Map, example, EX001.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["1.1 What an essential service is"]
  N2["1.2 Consequence first"]
  N3["1.3 The coordinator's job"]
  N4["1.4 The vocabulary of risk"]
  N5["1.5 Frameworks as maps"]
  N6["1.7 Practical activity"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["1.1 What an essential service is"]
  N2["1.2 Consequence first"]
  N3["1.3 The coordinator's job"]
  N4["1.4 The vocabulary of risk"]
  N5["1.5 Frameworks as maps"]
  N6["1.7 Practical activity"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]

[Learning outcomes and connection]
    |
    v
[1.1 What an essential service is]
    |
    v
[1.2 Consequence first]
    |
    v
[1.3 The coordinator's job]
    |
    v
[1.4 The vocabulary of risk]
    |
    v
[1.5 Frameworks as maps]
    |
    v
[1.7 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX001]

Learning outcomes and connection

After this chapter you should be able to:

• explain what makes a service "essential" and why its security is judged by consequence to people, not by damage to computers;
• describe the coordinator's job and distinguish it from the engineer's, the security analyst's and the executive's;
• use the core vocabulary of risk — asset, threat, vulnerability, likelihood, consequence, risk owner, risk appetite — precisely enough that colleagues can act on your sentences;
• place your work inside a recognised framework (the six functions of the NIST Cybersecurity Framework 2.0) without mistaking the framework for the work.

This chapter assumes only security basics. Everything later in the book builds on the distinctions made here.

1.1 What an essential service is

An essential service is one whose interruption harms people, the economy or public order quickly and at scale: drinking water, electricity, healthcare, transport, payments, emergency communications. Governments list them differently. The United States groups sixteen critical infrastructure sectors (CISA, Critical Infrastructure Sectors) and describes the underlying national critical functions — for example "supply water" or "provide medical care" — that cut across sectors (CISA, National Critical Functions Set). The European Union's NIS2 Directive names sectors of "high criticality" and places duties on essential and important entities, including on their management bodies (Directive (EU) 2022/2555).

The useful idea in all these lists is the same: the thing to protect is a function delivered to people, not a building or a server. Kestrel Water does not exist to run computers; it exists so that 180,000 people can drink safe water at adequate pressure every hour of every day. Its computers matter to the extent that the function depends on them.

1.2 Consequence first

In an office, the classic security triad is often recited as confidentiality, integrity and availability, in that order. In an essential service the order of concern usually changes. NIST's guide to operational technology security notes that OT systems directly affect the physical world and that their priorities — human safety, availability and integrity of control — differ from typical IT priorities (NIST SP 800-82 Rev. 3).

For a coordinator this has a practical meaning. When you rank a problem, ask in this order:

1. Could it hurt someone? (wrong chemical dose, loss of pressure to a hospital, a worker exposed to a moving pump);
2. Could it stop the service, and for how long, for how many people?
3. Could it make the service untrustworthy — operators no longer sure the screens show the truth?
4. Could it expose information — customer data, network designs, vulnerability reports?

A data breach of the billing system is serious and may carry legal duties, but a silent change to a chlorine setpoint is a different category of problem. A coordinator who cannot explain that difference in one sentence to a board will see money go to the wrong place.

1.3 The coordinator's job

Kestrel Water's chief operating officer, E. Varga, wrote the role description for the new post. Its core is three verbs: connect, decide-enable and evidence.

• Connect. Operations, IT, engineering, customer services, communications, suppliers and the executive all hold part of the picture. The coordinator makes sure the parts meet: the right people know about a risk, a change or an incident in time.
• Decide-enable. The coordinator rarely makes the important decisions. The operations manager decides whether to run a station manually; the chief executive decides what to tell the public. The coordinator makes sure the decision has an owner, the information it needs, a deadline, and a record.
• Evidence. The coordinator can show, to a board, auditor or regulator, what was decided, why, and whether it was done.

The coordinator is not the engineer who reconfigures the firewall, the analyst who reads the logs, or the executive who accepts the risk. Confusing these roles is the most common failure of new coordinators: they either try to do the technical work themselves (and lose sight of the programme) or make decisions that belong to someone with authority over the service (and are later overruled or blamed).

1.4 The vocabulary of risk

Precise words save hours in meetings. The following definitions follow common usage in NIST SP 800-30 Rev. 1, simplified for practice:

• Asset — anything the service depends on: equipment, software, data, people, suppliers, buildings.
• Threat — a circumstance or actor with the potential to cause harm (a criminal group, a careless update, a flood).
• Vulnerability — a weakness a threat could exploit (a supplier account without multi-factor authentication).
• Likelihood — how probable it is that the harm happens in a given period, given the controls that exist.
• Consequence (or impact) — what happens to the service and to people if it does.
• Risk — the combination: a statement of what could happen, how, how likely and how bad.
• Risk owner — the person with authority and budget to decide how the risk is treated. Usually a manager of the affected service, not the coordinator.
• Risk appetite — how much risk the organization's leadership is willing to accept in pursuit of its objectives, stated in advance.
• Treatment — reduce, avoid, transfer (for example insurance or a contract) or accept the risk.

A well-formed risk statement has a cause, an event and a consequence: "Because the pump supplier's remote account has no second factor, an attacker with the supplier's password could log in to station controllers and change pump setpoints, causing loss of pressure to up to 20,000 customers including the hospital." Compare "vendor access risk", which nobody can own or treat.

1.5 Frameworks as maps

The NIST Cybersecurity Framework 2.0 organises outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover (NIST CSWP 29, The NIST Cybersecurity Framework 2.0). Version 2.0 added Govern, which covers strategy, roles, policy, risk management and supply-chain risk — most of what this book is about. The UK's Cyber Assessment Framework, written for operators of essential services, is organised around objectives such as managing security risk and minimising the impact of incidents (NCSC, Cyber Assessment Framework).

A framework is a map of outcomes. It tells you what a good programme achieves, not how your utility should achieve it, and certainly not that you have achieved it. Chapter 5 shows how to read framework-based assessments without being fooled by them.

1.6 Worked example: the first week (synthetic)

On her first day the new coordinator receives three requests:

1. The IT department asks her to "sign off" a new antivirus product for the control-room computers by Friday.
2. The board audit chair, T. Lindqvist, asks for "our cyber risk score" for next month's committee.
3. The operations manager, A. Mensah, mentions that a pump supplier "sometimes logs in from home" to fix station KW-07.

A weak response treats them as three tasks. A coordinator's response sorts them by consequence and by who owns the decision:

Lesson table; scroll horizontally to read all columns →

The third item, raised casually, is the most consequential. Coordinators learn to hear risk in conversation.

1.7 Practical activity

Pick an essential service you know (your own employer, or a public one described in a news report). Write, in no more than one page: the function it delivers to people; three things it depends on; and one well-formed risk statement with cause, event and consequence. Mark which parts you know and which you assume.

Then hand the page to a colleague and ask them to name the risk owner from your statement alone. If they cannot, the consequence or the affected service is probably too vague. Compare your function with the Kestrel Water sentence about safe water at adequate pressure for 180,000 people: it names who is served and what they need.

1.8 Common errors and limits

• Treating "security" as the IT department's property. In an essential service, operations owns the consequence.
• Writing risks as nouns ("ransomware", "insider") instead of statements someone can own.
• Asking for a single risk score. Scores hide which service, which people and which decision.
• Mistaking a framework profile for evidence that controls work.

• This chapter simplifies: real risk methods (Chapter 4) need calibration, data and judgement, and laws differ between countries.

• Signing off a change that belongs to someone else, as the coordinator avoided with the antivirus request for the control-room computers.

• Treating a casual remark, such as a supplier who sometimes logs in from home, as small talk rather than a candidate risk.

Exercises — chapter 1

EX001 — Rewrite risks. Objective: produce ownable risk statements. Inputs: the register entries "ransomware", "old PCs" and "supplier access". Steps: rewrite each as a cause-event-consequence statement set at Kestrel Water. Expected evidence: three statements. Rubric: 3 = each has a cause, an event and a service consequence measured in people or time, and names the affected function; 2 = one lacks a consequence; 1 = still generic; 0 = none.

EX002 — Order of concern. Objective: apply consequence-first ranking. Inputs: four events: (a) billing database copied by an intruder; (b) operator screens at KW-03 freeze for 40 minutes; (c) chlorine setpoint at KW-05 changed without approval; (d) internal network diagram emailed to a wrong address. Steps: rank them and justify. Expected evidence: ranking with one sentence each. Rubric: 3 = (c) first on safety grounds, (b) second for loss of view and potential loss of control, then (d) and (a) with reasoning about who is harmed and how; notes that legal duties may still make (a) urgent; 2 = correct top two only; 1 = ranks (a) first without reasoning; 0 = none.

EX003 — Role boundaries. Objective: separate coordination from authority. Inputs: the antivirus request in 1.6. Steps: write the email you would send to IT and to A. Mensah. Expected evidence: two short messages. Rubric: 3 = declines sole sign-off, names the decision owner, asks for supplier compatibility, a non-production test and a rollback plan, proposes a date; 2 = correct owner without test request; 1 = signs off; 0 = none.

EX004 — Map to CSF 2.0. Objective: use a framework as a map. Inputs: the three requests in 1.6. Steps: assign each to one or more CSF 2.0 functions and explain. Expected evidence: three assignments. Rubric: 3 = antivirus → Protect (and Govern for decision rights); risk score → Govern; supplier logins → Govern (supply chain) and Identify/Protect; notes that a function label is not evidence; 2 = labels without reasons; 1 = one label; 0 = none.

EX005 — Hear the risk. Objective: spot risk in conversation. Inputs: the remark "the night shift keeps the station door propped open because the badge reader is slow." Steps: write a risk statement, name a likely owner and one question you would ask before proposing any fix. Expected evidence: statement, owner, question. Rubric: 3 = statement links physical access to control equipment and consequence; owner is the station or operations manager; question respects why staff do it (for example, how slow, and is the door needed for emergency exit?); 2 = no question; 1 = blames staff; 0 = none.

Chapter synthesis

An essential service is a function delivered to people, and its security is measured by consequence: safety, continuity, trustworthiness, then confidentiality. The coordinator connects the people who hold parts of the picture, makes sure decisions have owners and records, and keeps evidence. Precise risk statements and a framework used as a map — not as proof — are the first tools of the job.