⏳ (15 minutes)

Architecture Review

In our architecture review, you may have noticed the safety system lives in the OT DMZ. That placement forces us to poke controlled holes from the DMZ into the Cell, which complicates DMZ hardening because we must allow the safety box to communicate with the Cell PLC securely. Let’s examine what this system actually does, and then evaluate a better approach to securing it.

<aside> <img src="/icons/chemistry_blue.svg" alt="/icons/chemistry_blue.svg" width="40px" />

Lab 2.3 Activities

</aside>

Explore the Safety System (hands-on)

1. Access the box
   • From the Site VM, open Remmina → connect to 10.20.0.99:5900 → log in as ot / otpass.
2. Observe its capabilities
   • Double-click Trip to Safe State → it sends Modbus/TCP writes to the Cell PLC to assert a conservative safe state (stop/hold/divert).
   • Double-click Reset Safe State → it clears those writes and returns the process to normal.
3. Map the trust paths
   • Current path: DMZ → Cell (TCP/502 writes).
   • Outbound telemetry: Cell → Historian/HMI (reads/visualization).
   • Note: the safety workstation is originating control from the DMZ.

Guided Analysis

• Security implication: Any host in the DMZ that can write to the Cell increases blast radius, a DMZ compromise could trigger trips or clear them.
• Operational implication: Safety logic is a Cell-level function, locating it outside the Cell adds dependency on firewalls, NATs, and routing for time-critical actions.
• Policy implication: DMZ should be broker/monitor territory (read-mostly), not a command origin into the Cell.

Likely Better Pattern

Relocate the safety system into the Cell network, then invert the data flows:

• Cell-local control: Safety box stays inside the Cell; Modbus writes remain in-cell only.
• Upward visibility: Export read-only telemetry to the DMZ/Corp (HMI, logs, alerts).