Chapter 5 — Critical infrastructure and sector security: design alternatives | Postgraduate 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 05 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["5.1 Starting from consequence"]
  N2["5.2 Principles that generate alternatives"]
  N3["5.3 Designs as graphs"]
  N4["5.4 Designs as operable systems"]
  N5["5.6 Practical activity: paths and chokepoints"]
  N6["5.7 Choosing and recording"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["5.1 Starting from consequence"]
  N2["5.2 Principles that generate alternatives"]
  N3["5.3 Designs as graphs"]
  N4["5.4 Designs as operable systems"]
  N5["5.6 Practical activity: paths and chokepoints"]
  N6["5.7 Choosing and recording"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]

[Learning outcomes and connection]
    |
    v
[5.1 Starting from consequence]
    |
    v
[5.2 Principles that generate alternatives]
    |
    v
[5.3 Designs as graphs]
    |
    v
[5.4 Designs as operable systems]
    |
    v
[5.6 Practical activity: paths and chokepoints]
    |
    v
[5.7 Choosing and recording]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes and connection

After this chapter you should be able to:

Generate genuinely different architectural alternatives for a security problem in an essential service, starting from consequences rather than products.
Represent alternatives as graphs of permitted paths and compare them by paths, chokepoints and the barriers on each path.
Evaluate each alternative as an operable system: failure modes of the security controls themselves, break-glass access, maintainability and the workforce that must run it.
Combine security, operability and cost evidence into a recommendation, using the decision methods of Chapters 1 and 4.
Record the choice in an architecture decision record.

Chapter 4 quantified risk; this chapter shows where design choices change it. Chapter 6 then tests whether a chosen design works as claimed.

5.1 Starting from consequence

Architecture reviews often start from a product ("should we buy a data diode?") or a pattern ("we need zero trust"). A specialist starts from the consequence to be prevented and works backwards to the digital paths that could cause it. Consequence-driven, cyber-informed engineering, developed at Idaho National Laboratory, formalizes this: identify the functions whose failure would be intolerable, map the systems and dependencies that could cause it, and choose engineering mitigations — including non-digital ones such as mechanical limits — that remove or bound the consequence (INL, CCE; Bochman and Freeman, 2021). For Merrow Water's Hollin works the intolerable consequence is an unsafe chlorine dose reaching customers; the design question is how remote access to the dosing controller should work, if at all.

The non-digital mitigation deserves first place in the option set. A dosing pump sized so that it physically cannot exceed a safe dose, or an independent analyser that trips dosing at a hard limit, bounds the consequence whatever happens to the network. Digital controls are then chosen to reduce the frequency of attempts on what remains.

5.2 Principles that generate alternatives

Classic design principles still generate good alternatives: economy of mechanism, fail-safe defaults, complete mediation and least privilege (Saltzer and Schroeder, 1975). IEC 62443 applies them to control systems through zones (groups of assets with common security requirements) and conduits (the controlled communication between zones) (ISA overview). Zero-trust architecture moves enforcement from network location to per-session decisions on identity, device and context (NIST SP 800-207). Cyber-resilience engineering adds techniques — segmentation, non-persistence, diversity, redundancy, substantiated integrity — aimed at operating through compromise rather than only preventing it (NIST SP 800-160 Vol. 2 Rev. 1). Each principle points to a different design; using several deliberately produces alternatives that differ in kind.

5.3 Designs as graphs

A simple, powerful representation: nodes are systems, directed edges are permitted connections, and each edge carries the barrier an intruder must defeat to use it. Three measures then compare designs:

Number of paths from plausible entry points to the consequence-bearing asset. Fewer is better, but only with the next measure.
Smallest chokepoint set — the fewest nodes whose removal (or perfect defence) cuts every path. A single, strong chokepoint is easier to defend, monitor and evidence than several weak ones; it is also a single point of failure for legitimate operations (§5.4).
Barrier strength along each path — a path whose edges after initial entry carry no barrier ("none") lets one foothold become control.

The graph should include the unexpected paths that real environments contain: historian connections, backup links, vendor modems, cloud monitoring agents. Many architectural weaknesses are not in the intended design but in the path someone added later for convenience. Graph analysis does not prove security; it makes assumptions explicit and countable.

5.4 Designs as operable systems

A design that is secure on paper can fail operations. For each alternative ask:

What happens when the security control fails? If the access broker is down during a night-time emergency, how does an engineer reach the controller? A break-glass path — sealed credentials, physical presence, a recorded and alarmed emergency route — must exist and be tested, or operators will build their own.
Who runs it? A design that needs skills the organization does not have, or a supplier it cannot hold to account, will degrade.
How is it changed? Every exception to a rule is a new edge in the graph; designs that make legitimate work easy reduce pressure for exceptions.
What does it cost over its life? Licences, staff, testing, renewals.
What does it do to monitoring? One-way data flows can protect a control network while still letting the business see process data; they also limit remote diagnosis.

5.5 Worked example: three remote-access designs at Hollin (synthetic)

Merrow Water has three candidate designs for remote access to Hollin's control network:

D1 flat VPN — today's arrangement: vendor and staff VPN lands directly in the control network; the historian is reachable from the corporate network.
D2 VPN plus jump host — MFA on the VPN; all interactive access through a hardened jump host; the historian moved to a DMZ.
D3 brokered access with one-way historian — remote access only through an access broker requiring MFA and per-session approval, sessions recorded and time-boxed, landing on one engineering workstation; the historian replicates out to the DMZ through a one-way link; the dosing controller's key switch is left in RUN, which (on this synthetic controller) blocks program downloads.

Two entry points are modelled: the internet and a phishing email reaching a corporate PC.

5.6 Practical activity: paths and chokepoints

# Lab 5 - comparing three remote-access architectures as graphs (offline, standard library only)
# Synthetic: paths from the internet to the dosing PLC at Merrow Water's Hollin works under three designs.
# An edge is a permitted connection; its label is what an intruder must defeat to use it.
from itertools import combinations
DESIGNS = {
 "D1 flat VPN": {
   "internet": [("vpn", "password")],
   "vpn": [("hmi", "none"), ("eng-ws", "none"), ("historian", "none")],
   "corp-pc": [("vpn", "none"), ("historian", "password")],
   "eng-ws": [("plc", "none")], "hmi": [("plc", "none")], "historian": [("hmi", "none")],
   "email": [("corp-pc", "user click")], "plc": []},
 "D2 VPN + jump host": {
   "internet": [("vpn", "MFA")],
   "vpn": [("jump", "password")], "corp-pc": [("jump", "password"), ("historian-dmz", "password")],
   "jump": [("hmi", "password"), ("eng-ws", "password")],
   "historian-dmz": [("historian", "none")], "historian": [("hmi", "none")],
   "eng-ws": [("plc", "none")], "hmi": [("plc", "none")], "email": [("corp-pc", "user click")], "plc": []},
 "D3 brokered access + one-way historian": {
   "internet": [("broker", "MFA + per-session approval")],
   "broker": [("eng-ws", "recorded session, time-boxed")],
   "corp-pc": [("broker", "MFA + per-session approval")],
   "historian": [("historian-dmz", "one-way")],  # data leaves OT only; nothing flows back
   "eng-ws": [("plc", "PLC key switch in RUN blocks writes")], "hmi": [("plc", "none")],
   "email": [("corp-pc", "user click")], "historian-dmz": [], "plc": []},
}
ENTRY, TARGET = ["internet", "email"], "plc"
def paths(g, node, seen):
    if node == TARGET: yield [node]; return
    for nxt, _ in g.get(node, []):
        if nxt not in seen:
            for rest in paths(g, nxt, seen | {nxt}): yield [node] + rest
def reachable(g, removed):
    stack = [e for e in ENTRY if e not in removed]; seen = set(stack)
    while stack:
        n = stack.pop()
        for nxt, _ in g.get(n, []):
            if nxt not in seen and nxt not in removed: seen.add(nxt); stack.append(nxt)
    return TARGET in seen
for name, g in DESIGNS.items():
    ps = [p for e in ENTRY for p in paths(g, e, {e})]
    inner = sorted({n for n in g if n not in ENTRY + [TARGET]})
    cut = next(c for k in range(1, len(inner) + 1) for c in combinations(inner, k) if not reachable(g, set(c)))
    free = [p for p in ps if all(lbl == "none" for a, b in zip(p, p[1:]) for nxt, lbl in g[a] if nxt == b and a not in ENTRY)]
    print(f"{name}: {len(ps)} paths; smallest chokepoint set {list(cut)}; "
          f"paths with no barrier after the first hop: {len(free)}")
    for p in ps:
        bars = [lbl for a, b in zip(p, p[1:]) for nxt, lbl in g[a] if nxt == b]
        print("   ", " -> ".join(p), "|", ", ".join(bars))

Expected output:

D1 flat VPN: 7 paths; smallest chokepoint set ['corp-pc', 'vpn']; paths with no barrier after the first hop: 6
    internet -> vpn -> hmi -> plc | password, none, none
    internet -> vpn -> eng-ws -> plc | password, none, none
    internet -> vpn -> historian -> hmi -> plc | password, none, none, none
    email -> corp-pc -> vpn -> hmi -> plc | user click, none, none, none
    email -> corp-pc -> vpn -> eng-ws -> plc | user click, none, none, none
    email -> corp-pc -> vpn -> historian -> hmi -> plc | user click, none, none, none, none
    email -> corp-pc -> historian -> hmi -> plc | user click, password, none, none
D2 VPN + jump host: 5 paths; smallest chokepoint set ['corp-pc', 'jump']; paths with no barrier after the first hop: 0
    internet -> vpn -> jump -> hmi -> plc | MFA, password, password, none
    internet -> vpn -> jump -> eng-ws -> plc | MFA, password, password, none
    email -> corp-pc -> jump -> hmi -> plc | user click, password, password, none
    email -> corp-pc -> jump -> eng-ws -> plc | user click, password, password, none
    email -> corp-pc -> historian-dmz -> historian -> hmi -> plc | user click, password, none, none, none
D3 brokered access + one-way historian: 2 paths; smallest chokepoint set ['broker']; paths with no barrier after the first hop: 0
    internet -> broker -> eng-ws -> plc | MFA + per-session approval, recorded session, time-boxed, PLC key switch in RUN blocks writes
    email -> corp-pc -> broker -> eng-ws -> plc | user click, MFA + per-session approval, recorded session, time-boxed, PLC key switch in RUN blocks writes

Interpretation. D1 has seven paths; on six of them nothing stands between the first foothold and the controller. Its smallest chokepoint set is two nodes. D2 removes all barrier-free paths and adds MFA, but the graph exposes a flaw the design document did not mention: the path corp-pc → historian-dmz → historian → hmi → plc. Moving the historian to a DMZ while leaving a connection from the DMZ into the control-zone historian recreates a route around the jump host. This is exactly the kind of convenience edge that §5.3 warned about; EX021 fixes it. D3 has two paths, both through one chokepoint (the broker), each crossing several strong barriers. On security grounds D3 is clearly best.

On operability grounds, D3's single chokepoint is also its weakness. If the broker or its identity provider fails during an emergency, no remote path exists; the design therefore needs a tested break-glass route, which is itself a new edge to model and protect. The key-switch barrier is only real if operating procedures keep switches in RUN and a site visit is acceptable for program changes. A complete recommendation would add these to the cost and to the graph.

5.7 Choosing and recording

Bring the evidence together with Chapter 1's methods: a scenario table for each design (incidents prevented, operational costs of slower access, broker-outage scenarios) and the distributional check from Chapter 4 (does a design make remote sites harder to support?). Then write an architecture decision record (ADR): context, the consequence addressed, alternatives considered with their graphs, decision, consequences (including new risks such as broker dependence), the break-glass design, the evidence that will show the design is working (Chapter 6), and a review trigger. An ADR is a decision record (§1.8) specialized for designs; its value is that the next engineer who wants to add a convenient edge can see why it was not there.

5.8 Common errors and limits

Starting from a product or slogan rather than the consequence.
Omitting non-digital mitigations that bound the consequence outright.
Drawing the intended design and missing the paths added later.
Counting controls instead of examining barriers along each path.
Celebrating a single chokepoint without designing for its failure.
Ignoring who will operate the design and how exceptions will be handled.
Writing no decision record, so the next change silently undoes the design.

Graphs are only as complete as the inventory behind them, and barrier labels are judgements of strength, not measurements. Use them to compare designs and expose assumptions, then test the chosen design (Chapter 6).

Exercises — chapter 5

EX021 — Fix D2. Objective: remove an unintended path and re-evaluate. Inputs: Lab 5. Constraints: change only the historian links in D2 so that data flows one way from the control-zone historian to the DMZ copy, as in D3. Steps: (1) edit and rerun; (2) report paths and smallest chokepoint set for D2; (3) compare D2-fixed with D3 in two sentences. Expected evidence: edit, output and comparison. Rubric: 3 = edit correct, D2 now four paths with chokepoint jump, comparison notes D2's remaining password-only hops versus D3's per-session approval and recording; 2 = numbers right, comparison thin; 1 = not run; 0 = none.

EX022 — A new edge. Objective: evaluate a convenience proposal. Inputs: D3; Corvane proposes a cloud monitoring agent on the engineering workstation that keeps an outbound connection to Corvane's cloud "for diagnostics". Constraints: model it as an edge internet → eng-ws with barrier "vendor cloud account". Steps: (1) add the edge and rerun; (2) report paths and chokepoints; (3) propose an alternative that meets the diagnostic need. Expected evidence: output and proposal. Rubric: 3 = recognizes that the chokepoint set changes because a path now bypasses the broker, proposes an alternative (for example diagnostics exported through the one-way historian, or agent on a DMZ host), states residual risk; 2 = output right, alternative weak; 1 = accepts the edge as outbound-only therefore safe; 0 = none.

EX023 — Break-glass design. Objective: design for failure of the chokepoint. Inputs: D3. Constraints: must work when the broker and identity provider are down; must not become a routine path. Steps: (1) design the break-glass route; (2) add it to the graph; (3) specify alarms, records and test frequency. Expected evidence: design and updated path list. Rubric: 3 = physical or sealed-credential route with alarms and after-use review, modelled as an edge with its barrier, tested on a schedule; 2 = no testing; 1 = shared standing password; 0 = none.

EX024 — Choose with evidence. Objective: combine security and operability. Inputs: D1, D2-fixed, D3 with break-glass; synthetic annual costs £20k, £70k, £110k; your judgement of scenario losses using Chapter 1's format. Constraints: at least three scenarios including broker outage during an emergency. Steps: (1) build the table; (2) apply EV and minimax regret; (3) state the threshold that would change your recommendation. Expected evidence: table and recommendation. Rubric: 3 = scenarios plausible and include operational downsides of D3, both rules applied correctly, threshold explicit; 2 = one rule only; 1 = security only; 0 = none.

EX025 — Architecture decision record. Objective: record the design choice. Inputs: your EX024 recommendation. Constraints: one page; all elements of §5.7. Steps: write the ADR. Expected evidence: ADR. Rubric: 3 = consequence-first context, alternatives with graph evidence, new risks and break-glass, verification evidence and review trigger; 2 = one element missing; 1 = product description; 0 = none.

Chapter synthesis

Design from the consequence backwards, and put non-digital limits first. Use established principles — least privilege, complete mediation, zones and conduits, per-session decisions, resilience techniques — to generate alternatives that differ in kind. Represent designs as graphs of permitted paths and compare paths, chokepoints and barriers, including the convenience edges real environments accumulate. Evaluate each design as an operable system, designing for failure of its own controls. Choose with the decision methods of earlier chapters and record the choice in an ADR so that it survives the next change request.