Lab 02 — OT Zone and Conduit Policy Validator

Difficulty: 3/5 | Runs locally: yes

Pairs with the Phase 10 WARMUP Chapters 4, 8 (the Purdue model, zones & conduits, the industrial DMZ) and the HITCHHIKERS-GUIDE ("Conduit Review"). Use only simulated architecture data.

Why This Lab Exists (Purpose & Goal)

Industrial protocols (Modbus, DNP3) were designed for trusted networks and have no authentication — on the wire, a command to open a valve looks identical whether it came from the legitimate SCADA or an attacker who reached the control segment. You cannot fix the protocol; you compensate with architecture — controlling what can talk to what. The goal of this lab is to build the validator that enforces an industrial flow matrix: which zones may communicate, through which conduits, for which approved operational purpose.

The Concept, In the Weeds

The ISA/IEC 62443 model groups assets with similar security/safety requirements into zones and allows communication only through defined conduits — deny-by-default segmentation (the Phase 06/07 idea) applied to a plant. The rules the validator enforces:

PLCs may communicate only with approved HMIs/historians — not arbitrary peers.
Enterprise users must traverse a jump service — no direct IT-to-control path; everything crosses the industrial DMZ through a brokered, authenticated, logged hop.
Internet-to-control paths are forbidden — the single most important OT network rule.
Safety-system flows require explicit engineering justification — the Safety Instrumented System is the last line of defense for human safety (kept independent so a control compromise can't disable it), so any flow touching it is scrutinized.

The deep point: segmentation rules must correspond to approved operational flows, not arbitrary reachability. And the Purdue model is a communication aid, not physical truth — real plants have flat networks and shortcuts the diagram hides, so the validator checks the actual declared flows against the zone model rather than trusting the diagram.

Why This Matters for Protecting the Company

For critical infrastructure and manufacturing, the worst-case outcome is not data theft — it is physical damage, environmental release, or loss of life (Stuxnet, the Ukraine grid attacks, the Oldsmar water incident). Because the endpoints and protocols can't be hardened much, architecture is the primary control, and the industrial DMZ (no direct IT→control path, brokered access, one-way data flows) is the single highest-value defense. A validator that enforces the zone-and-conduit policy — and rejects internet-to-controller bypass, any/any rules, and unjustified safety-system flows — is how a company keeps its physical processes safe from network-borne attacks. This is the control that stands between an IT breach and a physical catastrophe.

Build It

Implement the validator over an industrial flow matrix: PLCs communicate only with approved HMIs/historians; enterprise users traverse a jump service; internet-to-control paths are forbidden; safety-system flows require explicit engineering justification.

LAB_MODULE=solution pytest -q

Secure Implementation Patterns

The validator — deny-by-default flows with safety scrutiny (mirrors solution.py):

def validate(flows: list[dict]) -> tuple[str, ...]:
    findings = []
    for i, flow in enumerate(flows):
        src, dst = flow.get("source"), flow.get("destination")
        if src == "internet" and dst in {"control", "safety", "plc"}:
            findings.append(f"{i}:INTERNET_TO_CONTROL")          # the cardinal OT rule
        if src == "enterprise" and dst in {"control", "plc", "hmi"}:
            findings.append(f"{i}:BYPASSES_JUMP_DMZ")            # IT must traverse the industrial DMZ
        if dst == "safety" and not str(flow.get("justification", "")).strip():
            findings.append(f"{i}:UNJUSTIFIED_SAFETY_FLOW")      # any flow to the SIS needs engineering sign-off
        if flow.get("write") and not flow.get("owner"):
            findings.append(f"{i}:WRITE_WITHOUT_OWNER")          # an unowned write function is a finding
        if flow.get("protocol") in {None, "", "*"}:
            findings.append(f"{i}:UNBOUNDED_PROTOCOL")           # any/any rules are forbidden
    return tuple(sorted(findings))

A well-formed conduit row carries everything the validator needs to approve a flow rather than merely allow reachability:

- source: historian        # role, not just an IP
  destination: cloud
  protocol: mqtt-tls        # bound, not "*"
  direction: out           # one-way (data out, no control in)
  write: false
  owner: ops
  justification: "analytics export via the secure gateway, buffered, fail-safe"

Production practices to carry forward:

No internet→controller path, ever; enterprise→OT only through a brokered, authenticated jump in the industrial DMZ.
Segmentation rules map to approved operational flows, not arbitrary reachability — and the Purdue model is a communication aid, so validate the actual flows, not the diagram.
One-way data out (diode/outbound-only) to historians/cloud; the cloud can never send control inward.
Architecture is the compensating control for unauthenticated protocols you can't fix — pair it with passive monitoring for anomalous commands.

Validation — What You Should Be Able to Do Now

Distinguish control, monitoring, safety, and enterprise zones and design conduits for approved operational flows.
Explain why the industrial DMZ (no direct IT→control path, brokered access, one-way data) is the primary OT control given unauthenticated protocols.
Treat the Purdue model as a communication aid and validate actual flows against it, not the diagram.

The Broader Perspective

This lab teaches compensating controls — when you can't fix the root weakness (an unauthenticated protocol you can't replace), you reduce exposure and consequence through architecture instead. That is one of the most important strategic skills in security: the ideal fix is often impossible (legacy systems, vendor constraints, safety validation), and the mature engineer reaches for segmentation, monitoring, and least-exposure rather than giving up or forcing a dangerous change. The zone-and-conduit discipline is the OT expression of the same deny-by-default segmentation you've now applied from the Phase 00 lab range through cloud networks — only declared, justified flows exist — with the stakes raised to physical safety.

Interview Angle

"How do you secure unauthenticated industrial protocols?" — You can't add auth to them, so you control architecture: zones and conduits (only approved flows), an industrial DMZ (no direct IT→control path, brokered jump access), one-way data flows (diodes) outbound to historians/cloud, and passive monitoring for anomalous commands. Architecture is the compensating control.

Extension (Stretch)

Add detections for conduit-policy violations and protocol misuse (a write from the wrong zone, a setpoint outside the process envelope), tested against simulated traffic only.

References

Phase 10 WARMUP Chapters 4, 8; ISA/IEC 62443; NIST SP 800-82; CISA ICS advisories.

Security Engineer