Chapter 16 — Security architecture

Lesson map

Lesson 16 published. Map, example, EX032.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["16.1 Principles that last"]
  N2["16.2 A layered reference architecture"]
  N3["16.3 Defence in depth and zero trust"]
  N4["16.4 Remote access"]
  N5["16.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX032"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["16.1 Principles that last"]
  N2["16.2 A layered reference architecture"]
  N3["16.3 Defence in depth and zero trust"]
  N4["16.4 Remote access"]
  N5["16.6 Practical activity"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX032"]

[Learning outcomes and connection]
    |
    v
[16.1 Principles that last]
    |
    v
[16.2 A layered reference architecture]
    |
    v
[16.3 Defence in depth and zero trust]
    |
    v
[16.4 Remote access]
    |
    v
[16.6 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX032]

Learning outcomes and connection

After this chapter you can (1) apply classic design principles — least privilege, fail-safe defaults, economy of mechanism, complete mediation, separation of privilege; (2) describe a layered reference architecture for a critical-service operator from enterprise to field; (3) explain defence in depth and zero trust and their limits in operational technology; and (4) design secure remote access for vendors. It builds on Chapters 7, 11 and 13 and prepares Chapter 21 (system models) and Chapter 24 (controls).

16.1 Principles that last

Saltzer and Schroeder's 1975 principles still frame security architecture (Saltzer and Schroeder): economy of mechanism (keep it simple enough to verify); fail-safe defaults (deny unless allowed); complete mediation (check every access); open design (security should not depend on secrecy of the design); separation of privilege (require more than one condition — two people, two keys); least privilege; least common mechanism (minimise shared components); and psychological acceptability (if it is too hard to use, people bypass it). Each is a lens for reviewing a design: "what here is not mediated? what is shared? what will operators bypass at 03:00?"

16.2 A layered reference architecture

Critical-service operators commonly separate: the enterprise zone (email, office, business systems); a DMZ for data exchange (historian replicas, patch servers, remote-access jump hosts); operations/control (SCADA servers, HMIs, engineering workstations); field (controllers, RTUs, protection relays); and safety systems that act independently to prevent harm. Traffic between layers passes through conduits with explicit rules (Chapter 7). NIST's OT guide and the ISA/IEC 62443 series describe such architectures (SP 800-82 Rev. 3; ISA/IEC 62443). The point is not the drawing but the property it should guarantee: no direct path from the internet or email to anything that controls a physical process.

16.3 Defence in depth and zero trust

Defence in depth layers independent controls so one failure is not catastrophic: segmentation, hardening, authentication, monitoring, backups, manual fallback. Its weakness is common mode: layers that share an administrator account or a management server fall together. Zero trust removes implicit trust based on network location; every request is authenticated and authorised per resource (NIST SP 800-207). In enterprise IT it is a strong direction. In OT, many devices cannot authenticate individual requests, so zero-trust ideas apply mostly at the boundaries — users, engineering workstations, remote access — while segmentation protects the devices that cannot help themselves.

16.4 Remote access

Vendors and engineers need remote access; uncontrolled remote access is one of the most common paths into OT. A defensible pattern: access terminates on a jump host in the DMZ, never directly in the control zone; phishing-resistant multi-factor authentication; per-session approval by the operator on shift for vendors; time-limited accounts; session recording; and an off switch the control room can use. Each element answers a specific failure.

CPN's redesign uses every element: a DMZ jump host, vendor accounts enabled per ticket for up to four hours, phishing-resistant MFA, recorded sessions and a control-room switch. What it cannot stop is misuse inside an approved four-hour vendor session.

16.5 Worked example: CPN's remote access (synthetic)

This case is synthetic. CPN's current design: the internet-facing VPN-G gateway (Chapter 5) places users directly on the control network; three vendors have permanent accounts; passwords only. Redesign: VPN-G upgraded and moved to terminate on a DMZ jump host; vendor accounts disabled by default and enabled per ticket by the control-room supervisor for up to four hours; phishing-resistant MFA for staff; sessions recorded on a server the vendors cannot reach; a physical switch in the control room that disables the remote-access conduit. Residual risk, stated: an approved vendor session is still trusted during its window; recording supports detection and accountability but does not prevent misuse in real time.

16.6 Practical activity

Draw the Calder Water architecture from Chapter 7 with its zones and the three allowed conduits. Annotate each conduit with the principle it serves and the control enforcing it. Mark the one component whose compromise would hurt most and explain why.

In CW's architecture each conduit serves a principle: the corporate-to-DMZ HTTPS view applies least privilege, the DMZ collector's OPC UA read applies complete mediation at the conduit, and the SCADA-to-field Modbus polling relies on fail-safe defaults by denying everything else. The SCADA server is a strong candidate for the component whose compromise hurts most, because it can both see and command every field controller.

16.7 Common errors and limits

• Architecture diagrams that show intended, not actual, connections.
• "Dual-homed" machines that bridge zones and bypass the conduit.
• Layers that share administrators, credentials or management tools.
• Applying zero trust slogans to devices that cannot authenticate.

In CW's case, the Lab 4 RDP connection from corporate directly into control is the first error: a path the diagram does not show. A dual-homed engineering laptop is the usual cause. CVH's management server that administers firewalls, endpoint protection and backups with one account (EX032) is the third. The fourth applies to RTUs and PLCs.

Exercises — chapter 16

EX031 — Principle review. Objective: use principles as review lenses. Inputs: CPN's original remote-access design in this chapter's worked example. Steps: name four Saltzer–Schroeder principles it violates and how. Expected evidence: four principle–violation pairs. Rubric: 3 = four correct (least privilege, fail-safe defaults, complete mediation, separation of privilege, or least common mechanism) with specific explanation; 2 = three; 1 = one or two; 0 = none.

EX032 — Common mode. Objective: find hidden shared dependencies. Inputs: CVH has segmentation firewalls, endpoint protection and backups — all administered from one management server using one domain-administrator account. Steps: explain the common-mode risk and propose two changes. Expected evidence: explanation and changes. Rubric: 3 = compromise of the account/server disables all three layers; changes such as separate admin tiers/credentials and offline backups; 2 = one change; 1 = vague; 0 = none.

Chapter synthesis

Architecture turns principles into enforced properties: no direct path from the internet to anything that moves the physical world. Layer independent controls, watch for common modes, apply zero trust where devices can participate and segment where they cannot, and treat remote access as the most important conduit to design well.