Defending the Purdue Model: GE and Bachmann Approaches to ICS Cybersecurity
Industrial control system (ICS) cybersecurity starts with knowing what is connected to what. This engineer-focused review draws on the Instrumentation Tools ICS cybersecurity training material and turns defense in depth into questions a plant team can act on. Validate every proposed change against your site architecture, vendor guidance, safety requirements, and change-control process.
Why is OT security different from office IT security?
A plant security change can affect a physical process. Availability, integrity, safety, and confidentiality all matter; their priorities depend on the process and risk assessment. Schedule patches and reboots with operations, test them where possible, and plan a rollback. Legacy protocols may have limited native security, so compensate with access controls, monitoring, and network boundaries.
How does the Purdue Model help with segmentation?
The Purdue Model is a useful map of field devices, controllers, supervisory systems, site operations, and enterprise services, not a substitute for an actual network inventory. Define zones and conduits from real data flows and risk, then restrict traffic between them with appropriate controls. An OT DMZ can broker selected exchanges between enterprise and control networks. Do not assume every historian or controller communicates in one direction: document the required flows before blocking or allowing them.
When reviewing a system with a GE IS420UCSBH1A controller module or a Bachmann MPC240/K M1 controller module, confirm the installed firmware, supported interfaces, and actual topology. A product listing alone does not establish OPC UA or edge-gateway capabilities.
What makes an OPC UA connection trustworthy?
Where OPC UA is supported, review endpoint security modes and policies, trust lists, certificate lifecycle, user authentication, and least-privilege roles. Prefer signed and encrypted sessions where supported and required by the design; remove insecure endpoints only after checking dependent clients and planning the cutover. Log access and review unexpected connections, while keeping controller performance and vendor compatibility in view.
What should secure remote support look like?
Use an approved, time-limited route through a managed gateway or jump host, with named accounts, multifactor authentication where supported, access approval, and appropriate logging. Restrict what the vendor can reach. Avoid direct internet exposure of control equipment and test the emergency support procedure before it is needed.
Where should a zone assessment begin?
- Build a current asset and network-flow inventory using approved methods; favor passive discovery where active scanning could disturb equipment.
- Map devices and necessary communications into zones, identifying undocumented crossings.
- Prioritize exposures by process impact and exploitability rather than age alone.
- Design and test segmentation changes before deploying them during an approved maintenance window.
- Harden supported protocols, accounts, and remote access against the vendor and site baselines.
- Monitor relevant events and rehearse recovery from verified, protected backups.
How does recovery complete defense in depth?
Keep versioned controller projects, configuration backups, and a tested restoration plan. Protect backup access, verify that files can be restored on a safe test system, and train technicians not to share accounts or connect unmanaged laptops. Review alerts on a schedule suitable for the plant, and coordinate any incident response with operations.
Takeaway: Use the Purdue Model to start the conversation, then defend the real plant network with documented zones, hardened services, controlled remote access, and tested recovery.
Author: Zheng Haifeng, industrial automation engineer.
