Chapter 5 — Security literacy

Chapter 5 — Security literacy

Lesson map

Lesson 05 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["5.1 Core terms"]
  N2["5.2 Priorities in an essential service"]
  N3["5.3 Prevent, detect, recover"]
  N4["5.4 Reading public incidents"]
  N5["5.6 Practical activity: a control card"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["5.1 Core terms"]
  N2["5.2 Priorities in an essential service"]
  N3["5.3 Prevent, detect, recover"]
  N4["5.4 Reading public incidents"]
  N5["5.6 Practical activity: a control card"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX013"]

[Learning outcomes and connection]
    |
    v
[5.1 Core terms]
    |
    v
[5.2 Priorities in an essential service]
    |
    v
[5.3 Prevent, detect, recover]
    |
    v
[5.4 Reading public incidents]
    |
    v
[5.6 Practical activity: a control card]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes and connection

After this chapter you should be able to:

• use the core vocabulary — asset, threat, vulnerability, exposure, control, risk, incident, evidence — precisely and consistently;
• explain how security priorities in an essential service differ from those in an ordinary office: availability and safety of the physical service usually come first;
• describe a control by what it prevents, detects or helps recover from, and by the evidence that it works;
• read a public incident report for its lessons without turning it into a technique.

Chapters 1–4 were about computing. This chapter supplies the shared language you will use with operators, managers, auditors and suppliers for the rest of the book. Imprecise words cause real failures: "the PLC is secure" means nothing; "the PLC accepts writes only from the relay subnet, verified by a flow review on 3 October" means something.

5.1 Core terms

• Asset: anything of value to the service — a pump controller, a historian, a credential, a dataset, a person's knowledge.
• Threat: a potential cause of harm — a criminal group, a careless change, a flood, a failing supplier.
• Vulnerability: a weakness a threat could exploit — an unpatched flaw, a shared password, an undocumented path, an untested backup.
• Exposure: whether a threat can actually reach the vulnerability. An unpatched flaw on an isolated device is less exposed than the same flaw reachable from the internet.
• Control: a measure that reduces risk — technical (a firewall rule), procedural (a change approval) or physical (a locked cabinet).
• Risk: the combination of how likely harm is and how bad it would be, for the people who depend on the service. Chapter 13 makes this concrete.
• Incident: an event that actually harms, or threatens to harm, confidentiality, integrity or availability — or, in critical infrastructure, safety.
• Evidence: a record that lets someone other than you check a claim.

NIST's Cybersecurity Framework 2.0 organizes outcomes into Govern, Identify, Protect, Detect, Respond and Recover (NIST CSWP 29); it is a useful map of the territory, not a checklist to tick.

5.2 Priorities in an essential service

Office IT security is often described in terms of confidentiality, integrity and availability, with confidentiality first. In a water network, a hospital or a transit system, the order shifts. The first concern is usually that the physical service continues and that nobody is harmed; integrity of control and measurement data comes close behind (an operator acting on a false reading can cause harm); confidentiality matters — patient records, customer data, network diagrams — but is rarely worth an outage. NIST's OT guide discusses how these priorities differ for operational technology (SP 800-82 Rev. 3).

This has practical consequences for an implementer. A control that might stop a process (an automatic block on an operator workstation, a forced reboot to apply a patch) needs a different approval and timing in OT than in an office. A control that fails "closed" in IT may need to fail "open" in a safety-relevant system — and that choice must be made deliberately by people who understand the process, not by default in a vendor's configuration.

5.3 Prevent, detect, recover

Classifying controls by function helps you see gaps. Preventive controls stop something happening (authentication, segmentation, allowlists). Detective controls notice it happening (alerts, integrity checks, reviews). Corrective or recovery controls restore service (backups, spare equipment, manual operation procedures). A service protected only by preventive controls has no way to notice when they fail; one with only detective controls notices harm without being able to stop or undo it. Every important risk should have at least one control of each kind, and every control should have a stated piece of evidence that shows it works — not merely that it is configured.

5.4 Reading public incidents

Public incident reports are the best teaching material the field has, if read correctly. Read them for failed assumptions and lessons: what did the operator believe that was not true? CISA's advisory on the 2021 Oldsmar, Florida water treatment event described remote-access software, shared passwords and an internet-connected system as conditions to fix (CISA AA21-042A); a former city official later said the event was likely employee error rather than an intrusion (WUSF, 13 April 2023). Both accounts teach the same implementer lesson: remote access to a control system with shared credentials and weak logging makes it impossible to tell later what happened. Notice also the lesson about evidence — a first account can be revised.

5.5 Worked example: rewriting vague claims (synthetic)

An FSTS status report says: "LANTERN is secure. Firewalls are in place. Backups are done. Monitoring is active." Rewritten in this chapter's vocabulary, with evidence:

5.6 Practical activity: a control card

Pick one LANTERN control from Chapters 2–4 (for example, the message validator). Write a one-page control card: name; risk it addresses; type (prevent / detect / recover); where it is implemented; owner; how it could fail; evidence that it works; date of last evidence. You will extend these cards in Chapter 18.

For the message validator, a complete card reads: risk, forged, replayed or malformed station messages reaching the historian; type, prevent; implemented in the relay's input path; owner, FSTS Platform; could fail if the replay state is lost on restart or the allowlist lags a new station such as PS-11; evidence, Lab 3's three accepts, six rejects and two quarantines, plus the relay's reject counts; last evidence, the date of the most recent run.

5.7 Common errors and limits

• Using "secure" as a state rather than describing specific protections and their evidence.
• Treating confidentiality as the top priority in a control system and accepting outage risk to protect it.
• Counting controls instead of asking what each prevents, detects or recovers.
• Reading incident reports as how-to guides, or repeating a first account after it has been revised.
• Calling every event an incident, which exhausts responders; or calling nothing an incident, which delays response.

Three of these appear in this chapter's status report before it was rewritten. "LANTERN is secure" is the first error. "Firewalls are in place" counts a control without saying that one undeclared corporate→PS-04 path had to be closed under CHG-121. "Monitoring is active" hid that Rule B detected only 7 of 10 tests.

Exercises — chapter 5

EX013 — Term precision. Objective: use vocabulary correctly. Inputs: the sentence "The vendor account is a threat because the RTU is a risk with no control." Constraints: rewrite in no more than three sentences. Steps: (1) identify each misused term; (2) rewrite correctly using asset, vulnerability, exposure, threat and control. Expected evidence: rewritten text with a one-line note per correction. Rubric: 3 = vendor account identified as a vulnerability or exposure path (not a threat), RTU as an asset, risk described as likelihood and consequence, a concrete missing control named; 2 = mostly right; 1 = cosmetic changes; 0 = none.

EX014 — Prevent, detect, recover. Objective: see control gaps by function. Inputs: risk: "a configuration change at the relay causes station data to be dropped". Constraints: one control per function, implementable by FSTS. Steps: (1) propose a preventive, a detective and a recovery control; (2) give evidence for each that it works. Expected evidence: three-row table. Rubric: 3 = for example change approval with peer review (prevent), file-integrity alert and station-silence alert (detect), versioned configuration with tested rollback (recover), each with testable evidence; 2 = one weak; 1 = all preventive; 0 = none.

EX015 — Incident report reading. Objective: extract implementer lessons from a public source. Inputs: CISA AA21-042A and the WUSF article. Constraints: lessons only; no attack technique. Steps: (1) list three conditions the advisory recommended fixing; (2) state what the later account changes and what it does not; (3) write one LANTERN design rule each lesson supports. Expected evidence: half-page note citing both sources. Rubric: 3 = conditions such as remote-access software, shared credentials and internet exposure correctly drawn from the advisory; recognizes that the revision changes the attribution, not the value of the hygiene lessons; design rules are specific; 2 = one element weak; 1 = repeats the first account as settled fact; 0 = none.

Chapter synthesis

Precise vocabulary is a security control: it makes claims checkable. In essential services the continuity and safety of the physical service usually come first, which changes how controls are chosen, timed and allowed to fail. Describe every control by what it prevents, detects or recovers, and by the evidence that it works. Read public incidents for failed assumptions, and keep track of revisions.

Continue studying — chapter 05 of 30

← Chapter 04 · Course chapter index · Chapter 06 →

Continue to the next authored lesson.