Chapter 21 — Critical infrastructure and sector security: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes and connection"]
N1["21.1 Interfaces are agreements"]
N2["21.2 Responsibility matrices"]
N3["21.3 Supplier integration"]
N4["21.4 Incident handling meets continuity"]
N5["21.6 Practical activity: interface agreements"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["21.1 Interfaces are agreements"]
N2["21.2 Responsibility matrices"]
N3["21.3 Supplier integration"]
N4["21.4 Incident handling meets continuity"]
N5["21.6 Practical activity: interface agreements"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]
[Learning outcomes and connection]
|
v
[21.1 Interfaces are agreements]
|
v
[21.2 Responsibility matrices]
|
v
[21.3 Supplier integration]
|
v
[21.4 Incident handling meets continuity]
|
v
[21.6 Practical activity: interface agreements]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes and connection
After this chapter you should be able to:
- integrate a technical service with the people and organizations around it: operators, the security monitoring centre, suppliers and emergency planners;
- define interfaces — what is handed over, in what form, how fast and to whom — not only data formats;
- write a responsibility matrix for a shared service and test it with a scenario;
- connect the service's incident handling with the operator's continuity and emergency plans.
LANTERN by now is a working technical service. A service is integrated when everyone who depends on it, or on whom it depends, knows what to expect and what to do. Most failures at this stage are not technical: an alert nobody owns, a supplier who was never told about a change, an operator who did not know that the dashboard could be stale.
21.1 Interfaces are agreements
For each neighbour, write down the interface as an agreement:
- Water operations — what LANTERN provides (telemetry to the historian within 60 s, with value age shown), what Water provides (station commissioning requests, engineering exports, process-relevant approvals), how alerts that affect the process reach the control room, and how Water reports a suspected telemetry problem.
- FSTS security monitoring (SOC) — which logs and alerts LANTERN sends, in what format, with what first actions; how the SOC escalates to the LANTERN on-call; what the SOC may do without asking (for example, disable a supplier account) and what it must not (for example, block station conduits).
- Suppliers (Kell, Arlen, BayTel, Halden) — how they are told about changes that affect them, how they report problems and vulnerabilities, how their access works (Chapter 7), what notice they give of their own changes.
- Emergency planning — how a LANTERN outage or compromise is reflected in Water's and the hospital's continuity plans.
21.2 Responsibility matrices
A RACI matrix records for each activity who is Responsible (does it), Accountable (owns the outcome — exactly one), Consulted and Informed. Test it with a scenario: walk through "relay compromised at 02:00" and check that every step has exactly one accountable role, that nobody needs to be consulted who cannot be reached at 02:00, and that the people who must act on the physical process are informed early.
Walking "relay compromised at 02:00" through Fallowmere's draft exposed the problem the worked example describes: nobody was Accountable for telling Water operators to distrust telemetry.
21.3 Supplier integration
Suppliers are part of the service. Their remote access is a path into it; their software updates are changes to it; their outages are your outages. Integration means: their access through the declared path; their change notices into your change calendar; their security advisories into your vulnerability routine (Chapter 16); and contract terms that require notification of incidents affecting you. CISA's Secure by Design initiative encourages manufacturers to take ownership of customer security outcomes (CISA Secure by Design); as a customer, ask suppliers how they meet such expectations and record the answers.
21.4 Incident handling meets continuity
An incident in LANTERN is handled by FSTS's incident process, but its consequences are managed by Water's and the hospital's continuity and emergency arrangements. The integration point is a short list of triggers: conditions under which FSTS tells Water "assume telemetry is unreliable — switch to manual readings at stations" or tells the hospital "assume the clinical gateway is unavailable — use the paper drug-library procedure". Triggers must be pre-agreed and exercised (Chapter 28), because at 02:00 nobody should be negotiating what "unreliable" means.
21.5 Worked example: a RACI that failed its test (synthetic)
The draft RACI for "suspected compromise of a relay" lists: FSTS on-call — R; FSTS Security lead — A; Water operations — I; SOC — C; Kell — I. Walking the scenario reveals three problems. First, the decision to tell Water operators to distrust telemetry has no accountable role: FSTS Security cannot judge the process impact, and Water is only Informed. Fix: Water duty manager Accountable for the operational response, FSTS Security lead Accountable for the technical response, with a named trigger for the hand-off. Second, Kell is only Informed, but if the compromise came through the vendor path, Kell's account must be disabled at once and Kell consulted about their own exposure. Third, the SOC is "Consulted" but in practice detects most incidents; it should be Responsible for the first triage steps.
21.6 Practical activity: interface agreements
Write a one-page interface agreement between LANTERN and Water operations covering: what each side provides, service levels (timeliness, value age display), alert routing, how a suspected telemetry problem is reported, the triggers for "telemetry unreliable", and review frequency.
Make the triggers measurable: for example, "telemetry unreliable" is declared when relay MAC failures exceed a stated rate across more than one station, when two or more stations show clock offsets like PS-09's 422 seconds, or when FSTS suspects compromise of a relay. State who declares it (the Water duty manager, on FSTS advice), how the control room is told, and that it is exercised annually.
21.7 Common errors and limits
- Treating integration as data formats and APIs only.
- RACI matrices with several accountable roles, or none.
- Suppliers outside the change and vulnerability processes.
- Continuity plans that assume the IT service is either fully up or fully down, with no "up but untrustworthy" state.
- Triggers defined but never exercised.
The first draft RACI shows the second error: no role was accountable for the operational response.
Kell's exclusion from the draft RACI's consulted roles shows the third: a supplier whose account may be the path in was only to be informed.
Exercises — chapter 21
EX061 — Repair the RACI. Objective: fix a responsibility matrix. Inputs: the Chapter 21 ("Worked example: a RACI that failed its test") draft. Constraints: exactly one A per activity; split activities if necessary. Steps: write the repaired matrix for activities: detect and triage; contain at relay; disable vendor access; decide operational response; notify regulators if required; restore service. Expected evidence: matrix. Rubric: 3 = one A per row; SOC R for triage; FSTS Security A for technical containment; Water duty manager A for operational response; regulatory notification A with the operator's designated role, not FSTS; Kell C on vendor access; 2 = one row wrong; 1 = multiple A's remain; 0 = none.
EX062 — Define a trigger. Objective: make "telemetry unreliable" precise. Inputs: LANTERN's alerts from Chapter 19 and validation outcomes from Chapter 3. Constraints: measurable conditions; must not fire on ordinary single-station faults. Steps: (1) write the trigger conditions; (2) say who declares it and who ends it; (3) say what Water does when it is declared. Expected evidence: half page. Rubric: 3 = conditions such as confirmed unauthorized change on a relay, MAC failures across several stations, or relay integrity failure; declared by FSTS Security lead with Water duty manager; Water switches to manual readings and sampling; end condition requires verified clean state; 2 = conditions vague; 1 = "when it seems wrong"; 0 = none.
EX063 — Supplier questions. Objective: integrate a supplier. Inputs: Kell Instruments. Constraints: six questions; each tied to a LANTERN process. Steps: write the questions and the process each feeds. Expected evidence: list. Rubric: 3 = for example how Kell notifies vulnerabilities (Chapter 16), how their staff's access is controlled and revoked (Chapter 7), their incident-notification commitment (this chapter), how firmware is signed (Chapter 27), support end dates (Chapter 11), SBOM availability (CISA SBOM); 2 = four or five; 1 = generic; 0 = none.
Chapter synthesis
A service is integrated when every neighbour — operators, the SOC, suppliers, emergency planners — has an agreed interface: what is provided, how fast, to whom, and what happens when it fails. Test responsibility matrices with scenarios until each activity has one accountable role. Bring suppliers into change, vulnerability and incident processes. Agree and exercise the triggers that connect a technical incident to the operator's continuity plans, including the state "up but untrustworthy".
Continue studying — chapter 21 of 30
← Chapter 20 · Course chapter index · Chapter 22 →
Continue to the next authored lesson.