Chapter 26 — Critical infrastructure and sector security: architecture alternatives

Chapter 26 — Critical infrastructure and sector security: architecture alternatives

Lesson map

Lesson 26 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["26.1 Centralised and distributed control"]
  N2["26.2 Redundancy patterns"]
  N3["26.3 Diversity"]
  N4["26.4 Unidirectional flows and local autonomy"]
  N5["26.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["26.1 Centralised and distributed control"]
  N2["26.2 Redundancy patterns"]
  N3["26.3 Diversity"]
  N4["26.4 Unidirectional flows and local autonomy"]
  N5["26.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX051"]

[Learning outcomes and connection]
    |
    v
[26.1 Centralised and distributed control]
    |
    v
[26.2 Redundancy patterns]
    |
    v
[26.3 Diversity]
    |
    v
[26.4 Unidirectional flows and local autonomy]
    |
    v
[26.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes and connection

After this chapter you can (1) compare architectural patterns for critical systems — centralised versus distributed control, redundancy schemes, diversity, unidirectional flows, local autonomy; (2) analyse each pattern's failure and attack behaviour; (3) quantify trade-offs using availability, latency and cost models from earlier chapters; and (4) document architectural decisions with their consequences. It develops Studio I's selected concept and prepares Chapter 27.

26.1 Centralised and distributed control

Centralised control (one SCADA directing simple field devices) gives operators a single view and makes coordination easy, but concentrates both failure and attack. Distributed control (capable field controllers that run locally and accept supervisory targets) degrades gracefully when the centre or network is lost, at the cost of more devices to secure and configure. Most resilient designs are hierarchical: local control maintains safe operation autonomously; the centre optimises and coordinates.

TMRP's choice, the hierarchical C2, keeps local automatic control at every station.

26.2 Redundancy patterns

• Hot standby: a second unit running and ready to take over automatically (SCADA server pairs).
• Cold standby: a spare that must be started or installed (spare RTUs on a shelf).
• N+1: one more unit than needed (three pumps where two meet demand).
• k-out-of-n voting: used in safety systems (2-out-of-3 sensors) to tolerate one faulty or falsified input.

Each pattern must be judged against common causes (Chapter 7): two identical servers with identical software are redundant against hardware failure and not against malware.

26.3 Diversity

Diversity — different technologies, vendors, paths or teams — reduces common causes. It costs more and increases the skills needed, and can add attack surface. Use it where a common cause would be unacceptable: a second communication path via a different carrier and different power; a hard-wired safety trip independent of software; a manual gauge an operator can read when all electronics are suspect.

At LRWA, the case for diversity is clearest on the telemetry path, where a second carrier on separate power would remove the shared feeder F1 dependency, and at Hollin Hill, where a manual level gauge gives operators a reading they can trust when all electronics are suspect.

26.4 Unidirectional flows and local autonomy

Unidirectional gateways enforce outward-only data flow physically; they remove a whole class of inbound attacks on the protected side but also remove remote control through that path. Local autonomy — the ability of a site to run safely without the centre — is a resilience pattern that also limits attack consequence: a compromised centre can disrupt optimisation but should not be able to drive a site outside safe limits if those limits are enforced locally (R3).

TMRP's C3 option takes this to its limit for monitoring.

26.5 Worked example: three TMRP architectures compared (synthetic)

The table makes the residual risk of C2 explicit: a compromised SCADA centre can still issue authenticated commands within local bounds. That residual is accepted on the basis of monitoring, two-person approval for bulk setpoint changes, and local bounds that keep the process safe.

26.6 Practical activity

Write an ADR selecting between C2 and C3 for PS4 specifically (the hospital feed), considering that PS4's setpoints change rarely.

Start from the comparison table and from what makes PS4 special: it feeds St Brenna's directly and its setpoints change rarely. Weigh the security of removing remote setpoint writes against the cost of sending a technician for each change, especially at night with one operator on duty. State what would make you revisit the decision, such as more frequent setpoint changes. The defense in Chapter 50 later refers to an ADR with exactly this local-only option for PS4.

26.7 Common errors and limits

• Redundancy without diversity, claimed as resilience against attack.
• Diversity everywhere, overwhelming maintenance capability.
• Centralisation for convenience without local safe limits.
• Ignoring the operational cost of architectures that remove remote control.
• Architectural comparisons without numbers where numbers are available.

TMRP's table avoids the last error by putting numbers where they exist, such as communications unavailability with a common-cause factor, and by stating the staffing cost of C3 plainly. It also accepts C2's residual openly instead of claiming its redundancy protects against attack.

Exercises — chapter 26

EX051 — Voting against falsification. Objective: analyse 2-out-of-3 voting. Inputs: three level transmitters at Hollin Hill; median selection. Steps: explain what one falsified transmitter can and cannot do; what an attacker controlling the common RTU that reads all three can do; and how to restore independence. Expected evidence: half page. Rubric: 3 = median tolerates one falsified input, common RTU defeats voting, independence via separate I/O or controller; 2 = common-RTU point missed; 1 = generic; 0 = none.

EX052 — PS4 architecture decision. Objective: write a decision record. Inputs: §26.6. Steps: write the ADR with context, options, decision, consequences and revisit conditions. Expected evidence: ADR. Rubric: 3 = decision justified by PS4's criticality and rare setpoint changes (C3 or C2 with local-only setpoint writes defended), consequences including operating cost, revisit triggers; 2 = weak consequences; 1 = no options; 0 = none.

Chapter synthesis

Choose architecture by how it fails and how it can be attacked. Hierarchical control with local safe limits combines operability with graceful degradation. Redundancy protects against independent failures, diversity against common causes; unidirectional flows remove inbound attack paths along with remote control. Quantify where you can and document the residual risk you accept.

Continue studying — chapter 26 of 50

← Chapter 25 · Course chapter index · Chapter 27 →

Continue to the next authored lesson.