Control zone: the crossing point and the equipment¶
The engineering workstation is the threshold. It holds two network interfaces, each on a different zone: one NIC on the operational zone (10.10.2.30), one on the control zone (10.10.3.100). From here, every PLC, relay, actuator, and HMI on the control network is directly reachable.
The workstation’s file system holds the accumulated knowledge from two decades of operation. The file config\plc-access.conf contains the complete OT device inventory: every host, its IP address, its port, its protocol, its unit ID, and operational notes. Written originally in 2001, updated continuously ever since. Consulting that file is consulting the operator’s working map of the production network.
The HMI application at 10.10.3.10:1881 is a FUXA server. It serves its complete project configuration — the device map, the register addresses, the tag names, the Modbus unit IDs, the relationship between the HMI display and the underlying PLC memory — as JSON over an HTTP GET to /api/project. No credentials required. A participant who has reached the engineering workstation can download the entire project, which amounts to downloading the control system’s wiring diagram in machine-readable form.
The turbine PLC itself is the centre of the control zone. Over its operational lifetime, it has accumulated four protocol endpoints: Modbus TCP on port 502, IEC-104 on port 2404, OPC-UA on port 4840, DNP3 on port 20000. Each protocol was added at a different time. None was decommissioned when the next arrived. None of them has ever been given an authentication mechanism; the historical assumption was that physical proximity was the only access control that mattered.
The protection relays that guard the distribution feeders are a subtler attack surface. The undervoltage and overcurrent thresholds that cause them to trip are accessible over Modbus. Setting the threshold to a value the relay will never reach is operationally implausible — an operator watching the console would see nonsense — but setting it just slightly above the current operating point can trigger a trip that looks like a sustained fault rather than a remote command. The difference is in the trip log: overcurrent protection (cause code 2) looks like the relay did its job. Remote command (cause code 6) looks like an attack. The relay logs the reason in real time; how that trip is later interpreted depends on whether anyone is watching for the distinction.
The relay thread also reveals how protection itself can fail. A nuisance trip on one feeder cascades: load shifts to the second feeder. If the second feeder’s overcurrent threshold is set just as tight, the second relay trips as well. The system collapses not from a single well-placed command, but from a sequence of trips that look individually reasonable. The MQTT broker on the control network publishes those trips as they happen; any subscriber sees the relay topology in real time through the sequence of state changes.
Related runbooks¶
relay-ieds.md (to be linked when available — covers protection relay configuration, nuisance trip cascades, operationally implausible threshold combinations)
uupl-mqtt.md (to be linked when available — telemetry semantics, relay trip event topics)