Chapter 5 — Critical infrastructure and sector security: tools and interpretation

Chapter 5 — Critical infrastructure and sector security: tools and interpretation

Lesson map

Lesson 05 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["5.1 The framework landscape"]
  N2["5.2 Reading an assessment"]
  N3["5.3 Metrics that drive decisions"]
  N4["5.4 Interpreting technical findings"]
  N5["5.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["5.1 The framework landscape"]
  N2["5.2 Reading an assessment"]
  N3["5.3 Metrics that drive decisions"]
  N4["5.4 Interpreting technical findings"]
  N5["5.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"]

[Learning outcomes and connection]
    |
    v
[5.1 The framework landscape]
    |
    v
[5.2 Reading an assessment]
    |
    v
[5.3 Metrics that drive decisions]
    |
    v
[5.4 Interpreting technical findings]
    |
    v
[5.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes and connection

After this chapter you should be able to:

• choose between the main public frameworks and baselines for an essential service and explain what each is for;
• read a self-assessment or maturity score critically: what it measures, who produced it, and what it cannot show;
• design a small set of programme metrics that drive decisions instead of decorating reports;
• interpret technical findings handed to you by engineers and suppliers well enough to ask the right follow-up questions.

The coordinator's "tools" are mostly documents and measures. Chapter 4 built the register; this chapter supplies the external yardsticks and the numbers that report on it.

5.1 The framework landscape

You will meet several overlapping references. Each has a distinct purpose:

The coordinator's rule: one primary structure (for example CSF 2.0) for the programme, with other references mapped to it, rather than four parallel spreadsheets. Regulatory requirements in your jurisdiction come first; frameworks help you meet them, they do not replace them.

5.2 Reading an assessment

An assessment result such as "Protect: 2.4 / 4" or "CPG coverage 71%" invites false confidence. Before you repeat it, ask five questions:

1. What was assessed? Which sites, systems and processes — and which were not?
2. Who assessed, how? Self-assessment by the system's owner, a peer, an independent assessor? By interview, document review or test?
3. What counts as "met"? A written policy, a policy in use, or a policy shown to work?
4. When? Assessments age quickly after reorganisations, supplier changes and incidents.
5. What decision does it support? If no decision changes depending on the number, it is decoration.

A self-assessment is valuable — it is cheap and builds understanding — but it measures what owners believe. Chapter 7 adds ways to obtain stronger evidence.

5.3 Metrics that drive decisions

Good programme metrics share three properties: they relate to a consequence or to a control that protects one; their owner can change them; and a threshold triggers a known action. Compare:

Counts of activity ("we blocked 40,000 attacks") are easily produced and rarely useful for decisions. Prefer measures of exposure, timeliness and coverage of the things that matter most.

5.4 Interpreting technical findings

Engineers, KVROC and suppliers send findings. You do not need to verify them technically, but you must ask questions that make them decision-ready:

• What is affected — which site, which function, which consequence level?
• How do you know — observed directly, inferred, or reported by a tool that may be wrong?
• What is the exposure — reachable from the internet, from the office network, only on site?
• What is the recommended action, by whom, by when, and what does it disrupt?
• Is there a public advisory? If so, link it; advisories such as CISA's water-sector alert on internet-exposed controllers with default passwords (CISA AA23-335A) help executives understand that a finding is not hypothetical.

5.5 Worked example: a CPG self-assessment (synthetic)

L. Ferreira completed a CPG checklist for Kestrel Water and reports "71% of goals met". The coordinator asks the five questions and finds: the assessment covered the corporate network and the treatment works but not the twelve stations; answers were "yes" if a policy existed; and it was done before HydroLogic's remote-access arrangement changed. Two "met" items — on multi-factor authentication for remote access and on revoking credentials of departing staff — have no evidence for supplier accounts.

She reports to the executive: "A self-assessment of corporate IT and the treatment works found most baseline practices in place on paper. It did not cover the stations, and two items that matter most for the stations — multi-factor authentication for remote access and timely removal of accounts — are unverified for suppliers. I propose a supplier-access review in May (Chapter 8) and to repeat the assessment including stations by September." The 71% stays in an appendix.

5.6 Practical activity

Take any public dashboard or annual-report statement about cybersecurity (for example "100% of staff trained"). Apply the five questions and rewrite it as a decision-ready statement, noting what you would need to know.

Write your rewrite in the same form as the coordinator's report on the CPG self-assessment: what was covered, how it was judged, what was left out and what decision follows. If the statement supports no decision, say so; that is a finding in itself. Keep the original figure, but put it after the context rather than at the front. Note the date of the statement and whether anything has changed since, such as a reorganisation or a new supplier.

5.7 Common errors and limits

• Running several frameworks in parallel without mapping.
• Choosing metrics because data is easy to get.
• Treating supplier marketing ("62443-compliant") as an assessment of your installation.

• Forgetting that frameworks and baselines are revised; cite version and date.

• Counting a goal as met because a policy exists, as the CPG self-assessment did, without asking whether it is in use or shown to work.

• Leaving out part of the service, such as the twelve stations, and still reporting one figure for the whole utility, or reporting percentages without scope and method.
• Repeating an assessment result to the executive before asking when it was done and what has changed since.

Exercises — chapter 5

EX021 — Choose a primary structure. Objective: select and map frameworks. Inputs: Kestrel Water must report to its regulator, buys OT systems from suppliers and has a board unfamiliar with security. Steps: propose a primary structure and how the CPGs and 62443 relate to it. Expected evidence: a short rationale. Rubric: 3 = regulatory requirements first, CSF 2.0 as programme structure for the board, CPGs as prioritised baseline mapped to it, 62443 used for supplier and procurement requirements; 2 = choice without mapping; 1 = "do all"; 0 = none.

EX022 — Interrogate a score. Objective: apply the five questions. Inputs: "Detect maturity 3.1/5, up from 2.6". Steps: write the five questions applied to this score and say what answer would make the improvement credible. Expected evidence: questions and criteria. Rubric: 3 = asks scope, assessor and method, definition of levels, date and decision supported; credible if same scope and method, independent or evidence-based, and linked to an observed outcome (for example detection of an exercise inject); 2 = questions only; 1 = accepts; 0 = none.

EX023 — Fix the metrics. Objective: design decision-driving metrics. Inputs: current monthly report: emails blocked, antivirus detections, policies approved, staff trained. Steps: replace with four metrics including owner and threshold action. Expected evidence: table. Rubric: 3 = metrics tied to consequence and control (for example level-5 risk hygiene, supplier account removal time, exposure of operational interfaces, exercise participation), each with owner and action; 2 = metrics without actions; 1 = cosmetic changes; 0 = none.

EX024 — Make a finding decision-ready. Objective: question a technical finding. Inputs: KVROC email: "Saw RDP from internet to hmi-02 last night, recommend blocking." Steps: write the reply. Expected evidence: reply. Rubric: 3 = asks which site and function hmi-02 serves, whether connection was successful, source and evidence, whether still exposed; asks who can block and what blocking disrupts (supplier access?); involves operations owner; treats as potentially urgent; 2 = asks some; 1 = "please block"; 0 = none.

EX025 — Report honestly. Objective: communicate an assessment's limits. Inputs: worked example 5.5. Steps: rewrite the executive message for the board in under 100 words. Expected evidence: message. Rubric: 3 = states coverage gap and unverified items plainly, gives plan and date, avoids the percentage as headline; 2 = mentions percentage first but includes limits; 1 = "71% compliant"; 0 = none.

Chapter synthesis

Frameworks and baselines are yardsticks: pick one primary structure, satisfy the law first, and map the rest. Read every assessment by scope, method, definition, date and decision supported. Measure exposure, timeliness and coverage of what matters, with owners and threshold actions. Make technical findings decision-ready by asking what, how known, how exposed, who acts and what it disrupts.

Continue studying — chapter 05 of 12

← Chapter 04 · Course chapter index · Chapter 06 →

Continue to the next authored lesson.