Chapter 18 — Security architecture
Lesson map
Lesson 18 published. Map, example, EX035.
flowchart TD
N0["Learning outcomes and connection"]
N1["18.1 Layered OT architectures"]
N2["18.2 The DMZ and data brokering"]
N3["18.3 Zero trust in OT"]
N4["18.4 Remote access"]
N5["18.5 Monitoring architecture"]
N6["18.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX035"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["18.1 Layered OT architectures"]
N2["18.2 The DMZ and data brokering"]
N3["18.3 Zero trust in OT"]
N4["18.4 Remote access"]
N5["18.5 Monitoring architecture"]
N6["18.7 Practical activity"]
N7["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX035"]
[Learning outcomes and connection]
|
v
[18.1 Layered OT architectures]
|
v
[18.2 The DMZ and data brokering]
|
v
[18.3 Zero trust in OT]
|
v
[18.4 Remote access]
|
v
[18.5 Monitoring architecture]
|
v
[18.7 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX035]
Learning outcomes and connection
After this chapter you can (1) describe reference architectures for operational technology, including layered models and DMZs; (2) apply zero-trust principles where they fit OT and explain where they do not; (3) design remote access, logging and monitoring architectures; and (4) evaluate an architecture against consequence, not just control count. It builds on Chapters 11, 12 and 15 and prepares Chapters 26 and 27.
18.1 Layered OT architectures
OT architectures are commonly described in levels: physical process (level 0), sensors and actuators with basic control (1), supervisory control (2), site operations (3), a demilitarised zone, and enterprise (4–5). The model, which descends from the Purdue reference architecture and appears in the NIST OT guide, is a tool for placing assets and conduits, not a law. Modern systems blur levels: cloud-connected sensors, vendor remote services and field devices with direct cellular links.
At LRWA, the SCADA servers sit in the control zone, the RTUs in the field zone and the historian replica in the DMZ.
18.2 The DMZ and data brokering
The OT DMZ sits between control and enterprise networks. No direct traffic crosses it: enterprise systems talk to DMZ services (historian replica, patch server, remote-access gateway), which talk to control systems. A useful test: if any enterprise host is compromised, can it send a packet that reaches a controller? If yes, the DMZ is decorative.
At LRWA the flow review applied this test and failed: an enterprise reporting script reached a field RTU directly. Moving that data to the DMZ historian replica is how LRWA makes its DMZ real rather than decorative, and the test is repeated after every new conduit is added.
18.3 Zero trust in OT
Zero trust, as described in NIST SP 800-207, removes implicit trust based on network location; every access is authenticated, authorised and evaluated per session. In OT the principle is valuable for human and engineering access — named identities, strong authentication, just-in-time privilege, session recording — and for new devices that support it. It fits poorly where legacy controllers cannot authenticate at all and where control loops cannot tolerate a policy decision point in their path. The engineering answer is to apply zero trust at the boundaries you can (engineering access, data brokering, gateways) and use segmentation and monitoring around what cannot authenticate.
18.4 Remote access
Vendor and staff remote access is a leading entry path into OT. Architect it as: an access gateway in the DMZ; multi-factor authentication; named accounts; access approved per session; connections to a jump host, never directly to controllers; session recording; and automatic expiry. The Oldsmar water treatment incident was initially attributed to unauthorised remote access via desktop-sharing software; later statements, reported by WUSF Public Media (2023), indicated it was likely employee error. Either way, the case illustrates why uncontrolled desktop-sharing on operator workstations is an architectural weakness, and why early incident accounts should be held provisionally.
18.5 Monitoring architecture
Network security monitoring in OT is usually passive: copies of traffic from switch mirror ports or taps feed sensors that understand industrial protocols and baseline normal behaviour. Logs from servers, firewalls and gateways go to a collector in the DMZ or a dedicated security zone. Monitoring must not create new paths into control: sensors receive copies only, and management interfaces sit on a separate network.
At LRWA, the passive taps sit at the control zone switch and the LTE head-end, and their management interfaces are kept off the monitored network.
18.6 Worked example: TMRP target architecture (synthetic)
LRWA's target: enterprise — firewall — DMZ (historian replica, remote-access gateway with MFA, patch staging, log collector) — firewall — control zone (SCADA pair, engineering jump host) — field conduit over private LTE with application-layer authentication (gateways for legacy RTUs) — RTUs and local control panels with manual mode. Passive monitoring taps sit at the control zone switch and the LTE head-end. The architecture is evaluated against consequences: forged commands require compromising either a field gateway key or the SCADA servers; enterprise compromise yields historian replica data but no packet path to field devices; loss of LTE leaves sites in local automatic or manual mode with 24 h telemetry batteries.
18.7 Practical activity
Draw the target architecture in text or a simple diagram and annotate each conduit with the allowlist entries from Lab 5. Then apply the DMZ test of §18.2.
Mark each conduit with its direction and protocol, and show where the passive taps sit. For every allowlist entry, ask which zone initiates the connection and whether the DMZ test still passes if that zone is compromised. Then add the engineering path through the jump host and check that no rule lets an engineering workstation reach a field RTU directly, which was one of LRWA's three flow violations. A diagram that hides direction cannot show whether the DMZ actually works.
18.8 Common errors and limits
- DMZs with "temporary" direct rules.
- Zero trust claimed for systems that cannot authenticate.
- Remote access that bypasses the gateway (vendor modems, desktop-sharing tools).
- Monitoring sensors with management interfaces on the monitored network.
- Architectures judged by number of controls rather than consequences prevented.
At LRWA, the third and first errors are the most likely: a vendor wanting quick access to RTU-B for diagnostics, and a temporary direct rule added during an outage. The target architecture answers both with the DMZ access gateway and change control on every conduit.
Exercises — chapter 18
EX035 — DMZ test. Objective: test a DMZ design. Inputs: a proposed rule letting the enterprise ERP server write work-order status directly to the SCADA database over TCP/1433. Steps: apply the DMZ test; propose an alternative design that meets the business need. Expected evidence: analysis and design. Rubric: 3 = rule rejected with reason, alternative brokers data through the DMZ with the control side pulling or a one-way export; 2 = alternative still inbound; 1 = accepts rule; 0 = none.
EX036 — Remote access architecture. Objective: design vendor access. Inputs: the RTU-B vendor needs quarterly access for diagnostics. Steps: specify the access path, authentication, approval, monitoring and expiry; list the evidence that would show the design works. Expected evidence: specification and evidence list. Rubric: 3 = gateway, MFA, per-session approval, jump host, recording, expiry, and evidence (logs, test of denied direct path); 2 = no evidence; 1 = VPN directly into control; 0 = none.
Chapter synthesis
Use layered models to place assets and conduits, make the DMZ real by allowing no direct crossing, apply zero trust where systems can authenticate and segmentation where they cannot, put all remote access through a controlled gateway, monitor passively without creating paths, and judge the architecture by the consequences it makes hard to cause.
Continue studying — chapter 18 of 50
← Chapter 17 · Course chapter index · Chapter 19 →
Continue to the next authored lesson.