Warmup Guide — OT Security Is Safety-Constrained Security

Zero-to-expert primer for Phase 10. It builds industrial control system (ICS) / operational technology (OT) security from first principles for an IT-trained engineer: why safety and availability outrank confidentiality, what PLCs/RTUs/HMIs/SCADA/historians/SIS actually are, the Purdue model and zones/conduits, the insecure-by-design industrial protocols (Modbus, DNP3, OPC UA, Profinet), passive-only assessment, consequence-driven risk, and safety-aware incident response. Assumes Phases 02, 06, 07, 09. Everything is simulated/lab-only — no active scanning, fuzzing, or writes to real industrial equipment, ever. By the end you should be able to explain why immediate isolation or patching can be dangerous, and prioritize OT risk by consequence, not CVSS.

Table of Contents

Chapter 1: The Inverted Priorities — Why OT Is Different

Zero background. OT (operational technology) is the computing that runs physical processes — water treatment, power generation, manufacturing, pipelines, transit. ICS (industrial control systems) are the OT subset that senses and controls those processes. The defining fact for a security engineer: the priorities are inverted from IT.

In IT, the classic triad is C-I-A (Confidentiality, Integrity, Availability) — usually in that order. In OT it flips to S-A-I-C: Safety first, then Availability, then Integrity, then Confidentiality. Why:

  • A control-system failure can injure or kill people and damage equipment or the environment. Safety is not a security property you can trade away.
  • Industrial processes must run continuously — a water plant or power grid can't take a maintenance window casually. Availability is paramount.
  • Leaking a sensor's temperature reading (confidentiality) is usually the least important concern.

Why this reframes every IT instinct. Your IT reflexes are often wrong here:

  • "Isolate the compromised host immediately" → in OT, cutting a controller off mid-process can cause a dangerous physical state. Isolation may have to wait for a safe process state.
  • "Patch the vulnerability now" → patching may require a plant shutdown, void a vendor warranty, or break a validated safety configuration. Patching can be more dangerous than the vulnerability.
  • "Scan the network to find assets" → active scanning can crash fragile decades-old devices, causing an outage or unsafe state. Discovery is passive (Chapter 6).

Misconception to kill now. "OT security is IT security on older hardware." It is safety- constrained security with inverted priorities, physical consequences, and a different risk calculus. Applying IT playbooks blindly (immediate isolation, IT patch SLAs) is dangerous and is a flagged mistake.

Chapter 2: The Physical Process and Consequence-Driven Risk

The process is the asset. Behind the network is a physical process with a state (a tank level, a turbine speed, a chemical dosage). Security exists to keep that process safe and available. You cannot reason about OT risk without reasoning about the process consequence of an action.

Consequence-driven risk (vs. CVSS). In IT you often prioritize by CVSS (exploitability + generic impact). In OT you prioritize by consequence × exposure: a "medium" CVSS bug on a PLC that controls a safety-critical process with a path from the enterprise network may be your top risk, while a "critical" CVSS bug on an isolated historian is lower. "Prioritize vulnerabilities by consequence and exposure, not CVSS alone" is a core evaluation item. The question is always: if this is abused, what does the physical process do, and who/what gets hurt?

Process state matters. The same action has different consequences depending on process state — isolating a controller is safe when the process is idle and dangerous mid-batch. "Ignoring process state" is a flagged mistake. Safety-aware decisions are state-dependent.

Misconception to kill now. "Rank by CVSS like always." OT risk ranking is consequence-first; a clever exploit that can't affect the physical process safely matters less than a simple one that can cause harm.

Chapter 3: The Equipment — PLC, RTU, HMI, SCADA, Historian, SIS

The OT "endpoints" you must recognize:

  • PLC (Programmable Logic Controller) — a ruggedized industrial computer running control logic — classically ladder logic, a graphical programming language drawn like relay-wiring diagrams so electricians could read it — that reads sensors and drives actuators in real time. The workhorse of automation. Often decades old, no authentication, fragile to unexpected input.
  • RTU (Remote Terminal Unit) — like a PLC but for remote/distributed sites (pipelines, grid substations), communicating telemetry back to a central system.
  • HMI (Human-Machine Interface) — the operator's screen/controls for monitoring and adjusting the process (often a Windows box running vendor software — and thus an IT-style attack surface into OT).
  • SCADA (Supervisory Control and Data Acquisition) — the supervisory system that aggregates many PLCs/RTUs, presents the HMI, and issues commands across a wide area.
  • Historian — a time-series database recording process values (the data many people want to push to the cloud — Chapter 10).
  • Engineering Workstation (EWS) — where engineers program the PLCs; compromise of an EWS is catastrophic because it can rewrite control logic.
  • SIS (Safety Instrumented System) — an independent system whose sole job is to bring the process to a safe state if something goes wrong (e.g. an emergency shutdown). The SIS is the last line of defense for human safety and is kept separate from the control system precisely so a control compromise can't disable safety. (The TRITON/TRISIS malware targeting an SIS is the cautionary tale — an attacker going after the safety system itself.)

Misconception to kill now. "It's just a PLC, a small computer." A PLC drives physical actuators; making it do the wrong thing has physical, sometimes lethal, consequences — and it typically has no authentication, so network reachability ≈ control.

Chapter 4: The Purdue Model, Zones, and Conduits

The Purdue model — a communication aid, not physical truth. The Purdue Enterprise Reference Architecture organizes OT/IT into levels:

Level 4/5  Enterprise IT (ERP, business, internet)
  ─────── Industrial DMZ (the controlled crossing) ───────
Level 3    Site operations (historians, EWS, SCADA servers)
Level 2    Supervisory control (HMI, SCADA)
Level 1    Basic control (PLCs, RTUs)
Level 0    The physical process (sensors, actuators)

The model's value is a shared vocabulary for "how far from the physical process is this, and what should be allowed to talk to it." But it's a reference, not reality — "treating Purdue levels as physical truth" is a flagged mistake; real plants have flat networks, shortcuts, and direct enterprise-to-control paths the diagram hides.

Zones and conduits (ISA/IEC 62443). The actionable model: group assets with similar security/safety requirements into zones, and allow communication only through defined conduits with explicit policy — deny-by-default segmentation (Phase 06/07) applied to a plant. The OT Zone and Conduit Policy Validator lab makes you encode this: segmentation rules must correspond to approved operational flows, not arbitrary "reachability."

Misconception to kill now. "The Purdue diagram shows the segmentation." The diagram shows the intent; your assessment must find the actual flows (passively) and reconcile them with the zones.

Chapter 5: The Insecure-by-Design Protocols

The core problem. Industrial protocols were designed decades ago for reliability on trusted networks, with no authentication, no integrity, no encryption. On the wire, a command to open a valve looks identical whether it came from the legitimate SCADA or an attacker — because there's no way to tell. You cannot "fix" the protocol; you compensate with segmentation and monitoring.

  • Modbus (Modbus/TCP) — the simplest and most common: read/write registers and coils. No auth, no encryption — anyone on the network who can reach a Modbus device can read sensors and write commands. The training-capture analysis lab annotates normal Modbus.
  • DNP3 — used in electric/water utilities, more featureful (events, time sync); historically unauthenticated, with a "Secure Authentication" extension rarely deployed.
  • OPC UA — the modern protocol that does support authentication, signing, and encryption — but only if configured correctly (often deployed in an insecure "no security" mode for convenience). OPC UA done right is the migration target.
  • Profinet — industrial Ethernet for real-time automation; similar trust assumptions.

The deployment options. Since you can't authenticate the legacy protocols themselves, you wrap them: segmentation (Chapter 8), unidirectional gateways (data diodes) for one-way flows like historian→cloud, allowlisting of source/destination/function codes, and passive monitoring for anomalous commands.

Misconception to kill now. "Just turn on TLS / require auth." Most installed protocols can't — auth/encryption don't exist in Modbus and aren't deployed in DNP3/OPC UA legacy configs. The control is architecture (segmentation, diodes, monitoring), not protocol crypto you can't add.

Chapter 6: Passive-Only Assessment

Why active scanning is forbidden. An IT pentester's reflex — Nmap the subnet, fuzz the service — can crash a PLC (many fail on unexpected packets) and cause an outage or unsafe physical state. In OT, discovery is passive by default: you listen to traffic (span/tap a switch port, analyze supplied pcaps) and infer the environment without sending anything to the devices. "Active discovery by default" and "active scanning/fuzzing/writes to real equipment" are hard-forbidden.

What passive gives you. From captured traffic you infer: which devices exist (by address and protocol behavior), their roles (a device answering Modbus reads is likely a PLC/RTU), the flows (who talks to whom), and sometimes firmware/version fields — all without touching the devices.

The tradeoff — passive has blind spots. Passive monitoring only sees what talks during the capture window; a quiet device or an offline path is invisible. Your inventory must make these blind spots explicit (Chapter 7).

Misconception to kill now. "I'll just do a quick scan to map it." A "quick scan" can take a water plant offline. Passive only — and where active is unavoidable, it requires control-engineer approval, a maintenance window, and failure analysis.

Chapter 7: Asset Inventory with Confidence and Blind Spots

You can't protect what you can't see — but in OT you must build the inventory carefully. The Passive OT Asset Inventory lab (and required build work) makes you write a normalizer that consumes only supplied synthetic records/pcaps and produces an asset inventory with stable identities, recorded confidence, and source, exporting a zone/conduit review table.

The data-quality problems you must handle (the lab's test cases):

  • duplicate addresses (DHCP reuse, NAT) — the same address may be two assets over time;
  • changed firmware labels — a device updated mid-capture;
  • clock skew (Phase 09) across sources;
  • missing fields — partial observations;
  • conflicting observations — two sources disagree.

The deliverable records confidence per asset and makes blind spots explicit — "inventory confidence and passive-monitoring gaps are explicit" is a measure. An OT inventory that claims certainty it doesn't have is dangerous because segmentation and response decisions depend on it.

Misconception to kill now. "The inventory is the list of assets." It's a list of observations with confidence and gaps. Overstating completeness leads to segmentation rules that miss real flows.

Chapter 8: Segmentation, the Industrial DMZ, and Remote Access

The primary OT control is architecture. Since you can't harden the endpoints or protocols much, you control what can reach them:

  • Industrial DMZ (iDMZ). A DMZ (demilitarized zone — a buffer network placed between two trust levels so neither side talks to the other directly) sitting between enterprise IT (Level 4/5) and OT (Level 3 down). No direct IT→OT traffic; everything crosses through brokered services in the iDMZ (a historian replica, a jump host). This is the single most important OT network control.
  • Jump hosts / brokered access for any human or vendor reaching into OT — authenticated, logged, session-recorded, and time-bounded.
  • Unidirectional gateways (data diodes) for flows that should be one-way (process data out to the historian/cloud, nothing back in) — hardware-enforced so a compromised enterprise side cannot send commands inward.
  • Allowlisting of approved source/destination/protocol/function — segmentation rules must map to approved operational flows (Chapter 4).

Remote vendor access — a top risk. Vendors often need remote maintenance access to equipment they support; this is a frequent intrusion vector (a third-party path straight into control). Review it: brokered through the iDMZ/jump host, MFA, least privilege, time-boxed, logged, and not a persistent VPN into the control zone.

Misconception to kill now. "We have a firewall between IT and OT." A single firewall with broad rules isn't an iDMZ; the control is a brokered buffer where no IT host talks directly to a controller, plus diodes for one-way flows.

Chapter 9: Vulnerability Management with Unpatchable Systems

The reality: you often can't patch. OT devices may be unpatchable (vendor no longer supports them, patching requires a validated re-certification, or a shutdown the business can't take). A 20-year asset life is normal. So vulnerability management can't be "patch within SLA" — blind IT patch SLAs are a flagged mistake.

Compensating controls instead. When you can't patch, you reduce exposure and consequence: tighten segmentation so the vulnerable device isn't reachable from the path that matters, add monitoring/detection for the exploit behavior, restrict the protocol/function, maintain recovery images, and coordinate with the vendor for a supported fix or a maintenance-window plan. The Vulnerability plan lab weighs criticality, exposure, consequence, compensating controls, and outage/vendor constraints together.

The prioritization (Chapter 2 restated). Rank by consequence × exposure, factoring the cost and risk of the remediation itself (a patch that requires a plant shutdown has its own availability/safety cost).

Misconception to kill now. "It's vulnerable, patch it." Patching in OT can require an outage, break a safety validation, or void warranty — and may be higher risk than the vuln. Compensating controls are frequently the right answer.

Chapter 10: Cloud-Connected Industrial Systems

The modern driver. Businesses want plant data (from historians) in the cloud for analytics/ML — a real value, but it bridges the once-isolated OT network to the internet (Phase 07). The Cloud-connected threat model lab maps the trust boundaries: device → gateway → cloud → operator → supply chain.

The safe pattern. The connection must be outbound and one-way for data (diode/gateway, Chapter 8), least privilege, authenticated, buffered (so a cloud/network outage doesn't disrupt the process — the plant keeps running locally), and failure-safe (if the link or cloud fails, the process is unaffected and degrades safely). "Cloud connection uses least privilege, buffering, authentication, and failure-safe behavior" is a measure. The cardinal rule: the cloud must never be able to send control commands into the process — data flows out, control stays local.

Misconception to kill now. "Connect the historian to the cloud like any database." A naive two-way connection creates an internet→control path; the safe design is one-way, buffered, and incapable of issuing control.

Chapter 11: Safety-Aware Incident Response

IR with a safety officer in the loop. OT incident response (Phase 09, re-prioritized) adds a safety authority: many response actions require control-engineer and safety-officer approval because isolating or shutting down can cause a dangerous physical state. The Safety-Aware OT Response Decision Engine lab encodes exactly this — response decisions carry decision authority and fallback/manual-operation requirements.

Manual operation readiness — the OT-specific lifeline. A key containment option unavailable in IT: revert to manual/local operation (operators run the process by hand) so you can isolate the compromised digital control without stopping the physical process unsafely. "Manual-operation readiness" is a required capability.

The joint decision table (the capstone deliverable). A table stating which actions require control engineer, safety officer, operations, vendor, legal, and executive approval. Response is a multi-stakeholder decision, not a unilateral security call — "excluding operators" is a flagged mistake; the operators know the process state and the safe sequence.

Misconception to kill now. "Contain the threat by isolating the system." In OT, isolation can be unsafe; the decision belongs jointly to security, control engineering, and safety, and often the answer is "switch to manual operation first, then isolate."

Chapter 12: Detection in OT

Detection fits OT well because OT traffic is predictable: the same devices, the same protocols, the same periodic polling. That regularity makes anomaly detection powerful — an unexpected write command, a new device, a connection that violates the zone/conduit policy, or an out-of-range process value stands out against a stable baseline.

Two detection types (the Detection lab):

  • Protocol misuse — a function code or command that shouldn't occur (a write on a read-only flow, an engineering command from the wrong source).
  • Architecture-policy violation — traffic that crosses a conduit it shouldn't (the zone/conduit model from Chapter 4 as a detection, not just a firewall rule).

Detections are passive (monitoring, never injecting) and tested against synthetic protocol misuse — the Phase 09 detection-as-code discipline applied to industrial traffic, with MITRE ATT&CK for ICS as the coverage map.

Misconception to kill now. "OT is hard to monitor." OT is in some ways easier — the predictability that makes it fragile also makes deviations obvious. The constraint is that detection must be passive and safety-aware.

Lab Walkthrough Guidance

All fixtures are simulated; no active interaction with real equipment. Build order:

  1. Lab 01 — Passive OT Asset Inventory. The required build: normalize supplied synthetic records/pcaps into assets with stable identity, confidence, and source; export a zone/conduit table; handle duplicate addresses, changed firmware, clock skew, missing fields, and conflicts (Chapter 7).
  2. Lab 02 — OT Zone and Conduit Policy Validator. Encode zones/conduits and validate that flows correspond to approved operations (Chapters 4, 8).
  3. Lab 03 — Safety-Aware OT Response Decision Engine. Encode response decisions with safety authority, decision owners, and manual-operation fallback (Chapter 11).
pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v

Success Criteria

You are ready for Phase 11 when you can, without notes:

  1. Explain the S-A-I-C priority inversion and how it changes IT instincts.
  2. Explain why immediate isolation or patching can be dangerous and what to do instead.
  3. Identify PLC/RTU/HMI/SCADA/historian/EWS/SIS and why the SIS is kept independent.
  4. Distinguish control, monitoring, safety, and enterprise zones, and design conduits for approved flows.
  5. Explain why discovery is passive and why the inventory must record confidence and blind spots.
  6. Prioritize OT vulnerabilities by consequence × exposure (and remediation cost), not CVSS alone.
  7. Design a safe cloud connection (one-way, buffered, authenticated, failure-safe, no inbound control).
  8. Lead a safety-aware incident decision with the right approval authorities and a manual-operation fallback.

Common Mistakes

  • Active discovery/scanning by default (can crash devices / cause unsafe state).
  • Applying blind IT patch SLAs to unpatchable, safety-validated systems.
  • Treating Purdue levels as physical truth instead of finding the real flows.
  • Ignoring process state when deciding isolation/containment.
  • Deploying inline controls (diodes, firewalls) without failure analysis.
  • Excluding operators/control engineers/safety from response decisions.
  • Ranking risk by CVSS alone instead of consequence × exposure.

Interview Q&A

Q: Secure remote vendor maintenance access to OT. A: No persistent VPN into the control zone. Broker access through the industrial DMZ via a jump host with MFA, least privilege scoped to the specific equipment, time-boxed sessions, full logging/ session recording, and approval workflow. The vendor never talks directly to a controller; access is on-demand and revocable, and any changes follow change control with control-engineer sign-off.

Q: Respond to suspicious HMI behavior. A: Treat it carefully — the HMI controls the process. Preserve evidence passively, engage the control engineer and safety officer to assess process state, and decide containment jointly: isolating or rebooting the HMI mid-process could be unsafe, so the option may be to switch to manual/ local operation first. Don't announce attribution; scope what the HMI did via passive logs; weigh blast radius and safety in every action.

Q: Connect a plant historian to cloud analytics safely. A: One-way only — process data flows out through a unidirectional gateway/diode or an outbound-only, authenticated, least-privilege connection; the cloud can never send control inward. Buffer locally so a cloud/network outage doesn't disrupt the process, and design failure-safe so a link failure leaves the plant running and degrading safely. Threat-model device→gateway→cloud→ operator→supply-chain boundaries.

Q: Handle an unpatchable PLC with a known vulnerability. A: Patching may be impossible or require an unsafe outage, so I rank by consequence × exposure and apply compensating controls: tighten segmentation so the path that matters can't reach it, add passive detection for the exploit behavior, restrict protocol function codes and source/destination, keep a recovery image, and coordinate with the vendor for a supported fix during a planned maintenance window. The remediation's own outage/safety cost is part of the decision.

Q: Negotiate containment with operations. A: I bring the security concern and the consequence analysis; operations and control engineering bring the process state and safe-sequence knowledge; the safety officer holds veto on anything affecting safety. Together we pick the action with acceptable blast radius — often manual operation plus targeted isolation rather than a blunt shutdown. The decision is documented with authorities and fallbacks; it's never a unilateral security call.

References

Standards and guidance

  • NIST SP 800-82 (Guide to OT Security).
  • ISA/IEC 62443 series (zones/conduits, security levels, secure development for IACS).
  • CISA ICS / OT advisories and the ICS-CERT recommended practices.
  • MITRE ATT&CK for ICS (techniques and detection mapping).

Protocols

  • Modbus, DNP3, OPC UA, and Profinet specifications and vendor secure-deployment guides.
  • Wireshark industrial protocol dissectors.

Case studies

  • Stuxnet (centrifuge sabotage); the Ukraine power-grid attacks (2015/2016); TRITON/TRISIS (safety-instrumented-system malware); the Oldsmar water-treatment incident.
  • Robert M. Lee / Dragos and SANS ICS security writings.