Chapter 15 — Security fundamentals

Chapter 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX029.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["15.1 The properties"]
  N2["15.2 Threat, vulnerability, risk"]
  N3["15.3 Controls and principles"]
  N4["15.4 Frameworks"]
  N5["15.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX029"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["15.1 The properties"]
  N2["15.2 Threat, vulnerability, risk"]
  N3["15.3 Controls and principles"]
  N4["15.4 Frameworks"]
  N5["15.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX029"]

[Learning outcomes and connection]
    |
    v
[15.1 The properties]
    |
    v
[15.2 Threat, vulnerability, risk]
    |
    v
[15.3 Controls and principles]
    |
    v
[15.4 Frameworks]
    |
    v
[15.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX029]

Learning outcomes and connection

After this chapter you can (1) define confidentiality, integrity and availability and explain why their priority differs in infrastructure; (2) describe threats, vulnerabilities, risk and controls and relate them in a risk assessment; (3) apply design principles from the security literature; and (4) map a system's controls to a recognised framework. It integrates Chapters 1–14 and prepares the security architecture and identity chapters (18–19) and the sector chapters (20 onward).

15.1 The properties

Confidentiality limits who can read information; integrity ensures information and systems are not altered without authorisation; availability ensures timely, reliable access. In enterprise IT, confidentiality often leads. In infrastructure, the physical process ranks first: integrity and availability of control, then safety, then confidentiality — though confidentiality of network designs and credentials protects the others. Avizienis et al. (2004) place security alongside reliability, safety and maintainability as attributes of dependability; their taxonomy of faults, errors and failures is used throughout this book.

15.2 Threat, vulnerability, risk

A threat is a potential cause of harm (an actor with capability and intent, or a natural hazard); a vulnerability is a weakness that a threat can exploit; risk combines likelihood and consequence. NIST SP 800-30 Rev. 1 describes risk assessment as identifying threat sources and events, vulnerabilities, likelihood and impact. In infrastructure, start from consequence: what are the worst things that could happen to the service and to people? Idaho National Laboratory's Consequence-driven Cyber-informed Engineering (CCE) method begins this way, asking which functions' loss or misuse would be unacceptable and working backward to what an adversary would need.

15.3 Controls and principles

Controls are preventive, detective, corrective or compensating, and technical, procedural or physical. Design principles from Saltzer and Schroeder (1975): economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism and psychological acceptability. Add defence in depth (layers whose failures are independent) and assume breach (design so that a compromise of one layer is detected and contained).

In TMRP's design, local manual mode with a physical key switch is an example of separation of privilege, and the independent chlorine analyser is a detection layer outside the systems it watches.

15.4 Frameworks

Frameworks give structure and a common vocabulary. The NIST Cybersecurity Framework 2.0 organises outcomes as Govern, Identify, Protect, Detect, Respond and Recover. The NIST SP 800-53 Rev. 5 catalogue lists controls; ISA/IEC 62443 specifies requirements for industrial automation systems and components, with security levels; the UK's NCSC Cyber Assessment Framework is outcome-based for essential services. A framework is a checklist of outcomes, not evidence that a design achieves them.

15.5 Worked example: the first TMRP risk table (synthetic)

Each row names a consequence in service terms first. The table is a hypothesis to be refined in Chapters 23 and 27.

15.6 Practical activity

Map each proposed control in §15.5 to one CSF 2.0 function and one SP 800-53 control family, citing the documents.

For each row of the TMRP risk table, choose the CSF function that best describes the proposed control's main purpose, and note where a control serves two. Authenticated telemetry is mainly protective, the independent analyser alarm is mainly detective, and tested offline backups support recovery. Cite the framework documents with their versions. Then write one sentence for each row explaining what the mapping does not tell you, because a correct mapping is still not evidence that the control works at LRWA.

15.7 Common errors and limits

• Copying enterprise priorities into OT.
• Risk registers that list vulnerabilities without consequences.
• "Defence in depth" layers that share a single point of failure.
• Treating framework mapping as proof of security.
• Likelihood scores with no stated basis.

The first TMRP risk table avoids these by naming each consequence in service terms first, so every vulnerability is tied to a harm, and by treating its likelihoods as hypotheses to refine in later chapters. Its layers are checked for shared dependencies before being called independent.

Exercises — chapter 15

EX029 — Principle audit. Objective: apply design principles. Inputs: Lab 8 and the pump state machine of §9.5. Steps: for each, identify two Saltzer–Schroeder principles applied and one violated or not addressed, and propose a fix. Expected evidence: table. Rubric: 3 = principles applied correctly with a credible gap (e.g., Lab 8 key hard-coded violates separation/least privilege; open design is respected by HMAC); 2 = one misattribution; 1 = names only; 0 = none.

EX030 — Consequence-first scenario. Objective: start from consequence. Inputs: LRWA's service. Steps: identify two unacceptable consequences, and for each, the functions an adversary would need to misuse and the cheapest engineering control that would make the consequence physically impossible or bounded. Expected evidence: half page. Rubric: 3 = consequences in service terms, functions specific, at least one engineered physical bound (e.g., mechanical overpressure relief, hard-wired chlorine pump limit); 2 = controls all digital; 1 = generic; 0 = none.

Chapter synthesis

Infrastructure security protects a physical service: integrity and availability of control and safety lead. Start from consequence, then threats and vulnerabilities, then controls. Apply enduring design principles, layer defences whose failures are independent, assume breach, and use frameworks as structured checklists — not as evidence.

Continue studying — chapter 15 of 50

← Chapter 14 · Course chapter index · Chapter 16 →

Continue to the next authored lesson.