Chapter 34 — Critical infrastructure and sector security: integration | Engineering Critical infrastructure and sector security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 34 published. Map, example, EX067.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["34.1 Incremental integration"]
  N2["34.2 Emergent behaviour"]
  N3["34.3 Operations integration"]
  N4["34.4 Organisational interfaces"]
  N5["34.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX067"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["34.1 Incremental integration"]
  N2["34.2 Emergent behaviour"]
  N3["34.3 Operations integration"]
  N4["34.4 Organisational interfaces"]
  N5["34.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX067"]

[Learning outcomes and connection]
    |
    v
[34.1 Incremental integration]
    |
    v
[34.2 Emergent behaviour]
    |
    v
[34.3 Operations integration]
    |
    v
[34.4 Organisational interfaces]
    |
    v
[34.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX067]

Learning outcomes and connection

After this chapter you can (1) plan system integration incrementally with interface tests; (2) integrate security controls with operations — alarms, procedures, monitoring and incident response; (3) manage organisational interfaces with vendors, carriers and other utilities; and (4) recognise emergent behaviour that appears only when components combine. It follows Chapters 31–33 and prepares Design Studio II (Chapter 35).

34.1 Incremental integration

Integrate in small increments with interface tests at each step: gateway with RTU; gateway with SCADA; SCADA with historian replica; monitoring sensors with the log collector. Each step uses the interface control document (Chapter 16) as its test specification. When an integration test fails, the interface specification tells you which side is wrong — or reveals that the specification was ambiguous.

TMRP's order follows the interface control documents: gateway with RTU at PS2 first, then gateway with SCADA, then the DMZ replica.

34.2 Emergent behaviour

Combining correct components can produce incorrect systems. Examples: an authentication gateway that buffers messages during link loss and then releases a burst on reconnection, flooding the SCADA poller; failover of the SCADA pair that resets replay counters; an anomaly detector that flags every gateway retransmission as an attack. Integration testing must include whole-system scenarios — link loss and recovery, failover, maintenance mode — not only interface conformance.

TMRP met the first example in integration testing, as the worked example below describes. Each needs a scenario test.

34.3 Operations integration

A control is not integrated until operations can use it: alarms with clear meaning, priority and response procedures; dashboards that show security state alongside process state; playbooks linking security alarms to operational decisions (switch to local manual? call the duty manager?); and training. Alarm management practice — rationalising alarms so each requires an operator action — matters because floods of meaningless alarms hide real ones.

At LRWA, the playbook for an unexpected setpoint change is how gateway alarms reach operational decisions. Each new alarm is rationalised before release.

34.4 Organisational interfaces

Infrastructure security depends on organisations you do not control: the LTE carrier, RTU vendor, integrator, electricity distributor, neighbouring utilities for mutual aid. Make interfaces explicit in contracts and agreements: notification duties for incidents and vulnerabilities, access conditions, support response times, and joint exercises. An incident at the carrier is your incident too.

For LRWA, the LTE carrier is the clearest example, since TMRP's whole field conduit runs over its network. The contract should set notification times and joint exercises with measurable terms.

34.5 Worked example: the reconnection burst (synthetic)

During integration testing, the team disconnects the LTE head-end for 30 minutes. On reconnection, each of 42 gateways releases 180 buffered readings at once. The SCADA front end, sized for steady state, queues the burst; priority alarms are delayed by over two minutes, violating R7. Lab 13's queueing model explains why: utilisation above 0.9 makes delay explode. Fix: gateways forward only the latest value and any alarms immediately, then backfill history at a limited rate to the historian, not the SCADA poller. The fix is recorded as an interface change (ICD revision) and a regression test.

34.6 Practical activity

Design an integration test that combines SCADA failover with replay protection, stating the expected behaviour, the observations and the pass criterion.

Describe the sequence: one SCADA server fails over to its partner while gateways keep sending authenticated messages. The expected behaviour is that the receiving side continues to reject replays after failover, which means the last accepted counter for each station must be shared or persisted. Observe whether any old message is accepted and whether alarms still arrive within 60 seconds. The pass criterion is zero accepted replays and no gap in alarm delivery.

34.7 Common errors and limits

Integration "big bang" at the end.
Interface tests only, no whole-system scenarios.
Security alarms without operational procedures.
Contracts silent on incident notification and vulnerability disclosure.
Treating emergent problems as one component's bug rather than an interface issue.

The reconnection burst shows the second and last errors: each component passed its interface tests, yet together they delayed alarms, and the fix was an interface change, not a single bug. Integration at LRWA proceeds one interface at a time. Each step has its own interface test.

Exercises — chapter 34

EX067 — Burst arithmetic. Objective: quantify the reconnection burst. Inputs: 42 gateways × 180 readings released within 10 s; SCADA front end processes 50 messages/s. Steps: compute the time to drain the burst assuming it all arrives at once; compute the time a priority alarm at the back of the queue waits; compare with R7. Expected evidence: numbers. Rubric: 3 = 7,560 messages / 50 per s = 151.2 s, violates 60 s, explains priority queuing or latest-value fix; 2 = arithmetic right, no fix; 1 = wrong arithmetic; 0 = none.

EX068 — Carrier agreement. Objective: specify an organisational interface. Inputs: the LTE carrier contract. Steps: list six security-relevant clauses with measurable terms. Expected evidence: list. Rubric: 3 = incident notification time, vulnerability disclosure, maintenance notification, restoration priorities, access logging, joint exercise, with numbers; 2 = no numbers; 1 = generic; 0 = none.

Chapter synthesis

Integrate incrementally with interface tests and whole-system scenarios, because emergent behaviour appears only in combination. Integrate controls into operations through meaningful alarms, playbooks and training. Make organisational interfaces explicit and measurable; your security depends on organisations you do not control.