Industrial Cybersecurity for Canadian Manufacturers

The Purdue Model provides the foundational framework for understanding OT network architecture: physical production devices (Level 0-1), local control systems and PLCs (Level 2), site-level supervisory systems (Level 3), and manufacturing operations management (Level 3.5) sit below the demilitarized zone that separates them from the enterprise IT network (Level 4) and the internet (Level 5). In a properly segmented manufacturing environment, traffic crossing from Level 3 to Level 4 is strictly controlled, logged, and mediated by a firewall or data diode. In practice, many Canadian manufacturing facilities have eroded these boundaries over time — an engineer installs a direct VPN for remote equipment access, an MES vendor needs a persistent connection, a new ERP integration bypasses the DMZ — until the architectural separation exists only in the network diagram, not on the wire.

Legacy PLCs and HMIs present a specific challenge that cannot be resolved through patching alone. Programmable logic controllers deployed 10–15 years ago running Windows XP or Windows CE cannot receive security updates because the operating system is end-of-life and the hardware cannot run a supported OS. HMI workstations sitting on the plant floor, often running unpatched Windows 7, are regularly observed with shared accounts, no screen locks, and USB ports that operators use to transfer production recipes via thumb drives. Replacing this equipment requires capital planning, production downtime scheduling, and re-validation of the process — a 12–36 month project for a complex facility. In the interim, compensating controls — network isolation, application whitelisting, removing unnecessary services, monitoring for anomalous engineering command traffic — are the practical defense.

Remote access for equipment vendors is a non-negotiable operational reality for most manufacturers. A CNC machine manufacturer's service technician needs to read diagnostic data and push parameter updates without traveling to the facility. A robotics OEM needs to observe production anomalies during real-time operation. Managing this access securely requires a privileged access management solution that issues time-limited, session-recorded credentials tied to specific equipment, rather than permanent VPN accounts that vendors retain after their service engagement ends. The CCCS's guidance on OT remote access recommends that vendors never be given direct network access — instead, access should be mediated through a jump server with full session recording, and should require both the vendor's authentication and an internal employee approval step before the session is established.

Anomaly detection in OT environments works on fundamentally different principles than IT security monitoring. Network packet inspection and EDR agents cannot be deployed on a PLC running a proprietary RTOS. Instead, OT anomaly detection works by passively monitoring engineering protocol traffic — reading Modbus function codes, DNP3 commands, and EtherNet/IP messages — and learning the baseline of normal engineering activity: which controllers send commands to which devices, at what frequency, with what parameter ranges. Deviations from this baseline — a new device appearing on the network, an engineering command being sent from an unexpected source, a parameter setpoint outside its historical range — trigger alerts. Tabletop exercises for production shutdown scenarios should specifically test whether the OT security monitoring platform continues to operate and alert during an IT network compromise, and whether the incident response team can isolate the OT network from the IT network without disrupting physical production control — a capability that must be pre-designed into the architecture, not improvised during an incident.