Chapter 8 — Security architecture basics
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes and connection"]
N1["8.1 Zones, conduits and the direction of trust"]
N2["8.2 Defence in depth and least privilege"]
N3["8.3 Management paths are part of the architecture"]
N4["8.4 Designing for operability"]
N5["8.5 Erosion: how architectures decay"]
N6["8.7 Practical activity: draw the management path"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["8.1 Zones, conduits and the direction of trust"]
N2["8.2 Defence in depth and least privilege"]
N3["8.3 Management paths are part of the architecture"]
N4["8.4 Designing for operability"]
N5["8.5 Erosion: how architectures decay"]
N6["8.7 Practical activity: draw the management path"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[Learning outcomes and connection]
|
v
[8.1 Zones, conduits and the direction of trust]
|
v
[8.2 Defence in depth and least privilege]
|
v
[8.3 Management paths are part of the architecture]
|
v
[8.4 Designing for operability]
|
v
[8.5 Erosion: how architectures decay]
|
v
[8.7 Practical activity: draw the management path]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes and connection
After this chapter you should be able to:
- read and draw a zones-and-conduits architecture for a service, including management paths;
- apply defence in depth and least privilege so that one failed control is not one failed service;
- design for operability: maintenance, emergency access and failure modes as part of the architecture;
- recognize the architectural shortcuts that erode separation over time.
Chapter 2 compared observed flows with declared conduits. This chapter is about the declaration itself: why LANTERN has the shape it has, and what an implementer must protect when building it. You will rarely design a whole critical system yourself, but you will make dozens of small decisions that preserve or quietly undo the design.
8.1 Zones, conduits and the direction of trust
In LANTERN, data flows up: stations → relay → historian → reports. Commands to stations do not flow through LANTERN at all; operators control stations from the separate control-room system. This is the most important property of the design. If the relay is compromised, an attacker can falsify or block telemetry — serious — but cannot command a pump through it. Every proposed change should be checked against this property: "does this create a path for commands, or for corporate systems, to reach the station zone?"
Segmentation of control networks from business networks, with controlled and monitored paths between them, is consistent guidance across OT security sources (NIST SP 800-82 Rev. 3; ISA/IEC 62443 overview). Firewalls implement this; NIST's firewall guidance recommends default-deny policies that permit only required traffic (NIST SP 800-41 Rev. 1).
8.2 Defence in depth and least privilege
Defence in depth means several independent controls so that one failure does not lead straight to harm. For a forged telemetry message to mislead an operator, it would have to reach the relay (segmentation), carry a valid authentication code (Chapter 15), pass validation (Chapter 3), and avoid alerts on implausible values (Chapter 19). Each layer must be independent: two controls that rely on the same password are one control.
Least privilege — giving each user and process only the access it needs — appears in Saltzer and Schroeder's classic design principles (Saltzer and Schroeder, 1975), together with fail-safe defaults and economy of mechanism. For an implementer these are concrete: the relay's service account cannot write to its own configuration; the historian account the relay uses can insert telemetry but not delete it.
8.3 Management paths are part of the architecture
Many diagrams show the data path and omit the management path: how administrators, backup systems, monitoring agents and suppliers reach each host. Management paths usually carry the most powerful access in the system. In LANTERN, administration reaches relays only from a management jump host in the corporate zone, with MFA; suppliers reach the jump host through a time-bound account (Chapter 7); monitoring receives logs pushed from the relays rather than logging in to them.
Lab 22's RLY-02, reaching public time servers, is a management path nobody drew.
8.4 Designing for operability
A secure design that operators cannot run will be bypassed. Ask for each control: how is it maintained? What happens at 03:00 when it fails? How does an engineer get emergency access, and how is that access recorded? What does the service do when the relay is down — do operators know that their historian view is stale? Design degraded modes deliberately: LANTERN's stations buffer 24 hours of readings locally, so a relay outage loses timeliness, not data; the operator display shows the age of every value.
8.5 Erosion: how architectures decay
Architectures erode through reasonable-sounding exceptions: a "temporary" firewall rule for a supplier, a dual-homed laptop used for configuration, a report server moved into the control zone "to make it faster", a shared administrator account for convenience. Each one is small; together they remove the separation. The defences are routine: conduits recorded with owner and expiry (Chapter 2), flow reviews, rule reviews, and refusing undocumented exceptions.
Fallowmere shows each kind. The corporate workstation talking Modbus to PS-04 is a dual-homed habit; the cellular modem Kell left on PS-07's PLC is a forgotten supplier exception that no flow record shows; and the request to send recommended setpoints from the historian to PS-07 would have been a reasonable-sounding exception reversing the direction of trust.
8.6 Worked example: a request that crosses zones (synthetic)
Water operations asks for the historian to send a weekly "recommended setpoint" file to PS-07's PLC, to automate an optimization. Checked against Chapter 8 ("Zones, conduits and the direction of trust"), the request breaks the most important property: it creates a path from the corporate zone to the station zone that carries control information. You do not refuse it outright; you return the design question to its owner with alternatives: an operator reviews the recommendation in the control-room system and applies it there; or the file goes to the control-room system, which validates and stages it for operator approval. Either preserves the direction of trust. Your role is to show the consequence and the alternatives, and to record the decision.
8.7 Practical activity: draw the management path
Draw LANTERN's zones and conduits from Chapter 2, then add every management path: administrator SSH via the jump host, supplier access, backup, monitoring, time, package updates. For each, record source, destination, protocol, authentication and owner. Mark any path that would let a single credential reach both the corporate and station zones.
In LANTERN the path to watch is the supplier route: Kell's time-bound account reaches the jump host, and the jump host reaches the relays. If that same account, or a shared opsuser credential, also opens the corporate file share, one stolen password crosses both zones. Mark the time-server path too, since Lab 22's RLY-02 was found using public time servers that no diagram showed.
8.8 Common errors and limits
- Diagrams that show data paths only.
- Treating two controls that share a credential, administrator or vendor as independent.
- Allowing a bidirectional path because the protocol "only reads".
- Designing for the normal day only, without degraded modes or emergency access.
- Accepting exceptions without owner or expiry.
Architecture limits what can happen; it does not show what does happen. Verification needs flows, logs and tests (Chapters 2, 19 and 23).
A Fallowmere example: the control cards for risk R2 (Chapter 18) would be less independent than they look if vendor session logging and the vendor account were administered by the same Kell login.
Exercises — chapter 8
EX022 — Check the direction of trust. Objective: evaluate change requests against the key design property. Inputs: three requests: (a) the relay pulls a new station allowlist from the historian every hour; (b) the SIEM sends an automated block command to the station firewall when it sees an attack; (c) the relay forwards telemetry to Halden Cloud for an analytics trial. Constraints: accept, reject or redesign each with one paragraph. Steps: evaluate each against Chapter 8's four design properties (direction of trust, least privilege, management paths, operability). Expected evidence: three paragraphs. Rubric: 3 = (a) redesign: configuration should flow from version control through change, not be pulled from a lower-trust zone; (b) redesign with care: automated blocking in an OT path needs operations agreement, safe failure and manual confirmation; (c) acceptable only as a new declared conduit with data-flow register entry (Chapter 12), contract and monitoring; 2 = two well argued; 1 = flat answers; 0 = none.
EX023 — Independence of layers. Objective: test defence in depth. Inputs: proposed layers protecting the relay: firewall managed by E. Strand; relay admin by E. Strand; HMAC key generated and stored by E. Strand on the relay; monitoring rules written by E. Strand. Constraints: do not assume bad intent. Steps: (1) identify the common dependency; (2) say what single event defeats all layers; (3) propose two changes that restore independence. Expected evidence: half page. Rubric: 3 = single person and single credential set; compromise or error of one account defeats all; changes such as separate admin roles, key held in a separate store with different custodians, monitoring rules owned and reviewed by the security team; 2 = partial; 1 = "add more controls"; 0 = none.
EX024 — Degraded mode. Objective: design operability. Inputs: the relay is down for four hours overnight. Constraints: consider operators, data and alerts. Steps: (1) describe what operators see; (2) what happens to data; (3) what alerts fire and who receives them; (4) what happens when the relay returns. Expected evidence: one page. Rubric: 3 = displays show stale age, not frozen values as current; stations buffer; station-silence and relay-health alerts reach on-call; return causes a backlog upload that needs headroom (Chapter 1) and does not trip replay checks wrongly; 2 = one aspect missing; 1 = generic; 0 = none.
Chapter synthesis
LANTERN's most important architectural property is the direction of trust: data flows up, commands never flow down through it. Protect that property in every change, keep layers truly independent, put management paths on the diagram, and design degraded modes and emergency access deliberately. Architectures decay through exceptions; record every one with an owner and an expiry, and check them.
Continue studying — chapter 08 of 30
← Chapter 07 · Course chapter index · Chapter 09 →
Continue to the next authored lesson.