9.4 Control-System Cybersecurity

Control-system cybersecurity on the PE exam is a public-safety and availability topic, not an invitation to imitate office IT. Knowledge area 2.G asks for management systems, risk assessments, security-level verification, MOC, monitoring, and protections. The job is to keep the process controllable and the SIS trustworthy. This section teaches defensive design and governance only. It does not describe attacks, payloads, or procedures for breaking into a system.

IEC 62443 (ISA/IEC 62443) is the usual professional language for industrial automation and control system (IACS) security: zones, conduits, foundational requirements, and security levels. For PE Control Systems 2027 study, treat those ideas as engineering practice. Do not assume the 62443 text is a supplied exam standard unless that year's NCEES design-standard sheet lists it. Answers should still sound like a licensed engineer: segment the system, limit privilege, verify the installed level against the target, and change it under MOC.

Management system, risk assessment, and security-level verification

A security management system is the governance wrapper: named roles (who may download, who may open a conduit), an asset inventory that includes controllers and not only PCs, a risk-assessment cadence, training, incident handling, audit, and MOC that covers cyber the same way it covers a bypass. Buying a firewall SKU is not a management system.

Risk assessment groups assets that share security needs into zones and names the allowed paths between them as conduits. A BPCS zone, an SIS zone, a site operations zone, and an enterprise zone should not be one flat network. The assessment sets a target security level (what the zone must achieve) based on consequence—safety, environmental, production—not based on whatever default the vendor shipped. Security-level verification then compares achieved architecture (what is installed and configured) with that target. Verification is evidence: allow-lists, account reviews, backup restore tests, remote-access logs, patch status. It is not a penetration hobby and it is not a SIL calculation; SIS integrity and IACS security interact, but a security-level claim does not replace IEC 61511 work.

Typical defensive patterns (Purdue-style levels as practice, not as a religion):

• Field and basic control (levels 0–1) do not initiate sessions toward the enterprise.
• Supervisory HMI and engineering (level 2) talk to controllers through designed conduits, not through ad hoc laptops.
• Site operations and historians sit behind a DMZ or equivalent brokered path, not on both process and business LANs at once.
• Enterprise users consume a replica or a brokered view, not a second network card in the process switch stack.

Protections, least privilege, remote access, backup

Protections enforce the architecture: allow-listed firewalls on conduits, unused services disabled, unique accounts, least privilege (operator logins do not get engineering download rights; service accounts are not domain-wide admins on controllers), physical access control to cabinets, portable-media policy, and SIS kept as independent as the design claims. Least privilege is also a FAT item: prove that the operator account cannot change firmware.

Remote access, when the plant needs vendor support, is a designed conduit: a jump host or equivalent broker in a DMZ, multi-factor authentication, time-bounded accounts, session logging, and a person who can revoke access when the call ends. Direct inbound paths to controllers from the public internet, or a standing vendor path that nobody reviews, are not 'support.' They are unmanaged conduits.

Backup and restore are protections for availability, including after ransomware or a bad download. A backup that has never been restored is a hope. Practice restore on an offline replica; keep an offline or otherwise protected copy of configurations, not only a virtual-machine snapshot of an HMI; include controller images, not only Windows boxes. Restore time belongs in the same conversation as MTTR in the capacity section.

Patching versus availability

Office IT can often patch a laptop the day a bulletin lands. A running compressor DCS cannot. An untested operating-system or firmware change can itself stop a scan, break a driver, or fail a redundant switchover. The professional sequence is: inventory what you run, read the vendor applicability note, test on a replica or in a windowed FAT-like regression, schedule a maintenance window, and until then apply compensating monitoring and access restriction on that zone. Refusing all patches forever is also a risk; the point is that availability is a security requirement in IACS (resource availability in 62443 language), so the patch is a change, not a reflex.

MOC and monitoring versus protection

Firewall rule changes, new remote users, new historian interfaces, and firmware are MOC—the same discipline as a clamp or a bypass. If operations can add a business-network jack 'temporarily' to a process switch, your zone drawing is fiction.

Monitoring watches the conduits and accounts you already allowed: failed logins, new devices, backup-job failures, unusual engineering downloads, time-sync loss. Protection is what prevents the path. Monitoring without protection is a camera on an unlocked door. Protection without monitoring means you do not know when a rule failed or a new dual-homed host appeared. The exam will offer a log collector as a substitute for a zone firewall. It is not a substitute.

Worked example — dual-homed historian

A process historian is installed with one network interface on the BPCS network and one on the business LAN, no firewall, and wide file or OPC sharing so that accountants can 'just grab tags.' The intent is convenience. The architecture is a dual-homed host: a single computer that is a member of two zones at once. That host is a conduit, and it is not a designed, allow-listed conduit. A compromise on the business network can use the historian as a path onto the process network because the machine is already attached to both. You do not need an exotic technique for that to be a bad design; you need only one poorly governed host.

Defensive alternatives: put the historian (or a replica) in a DMZ; replicate outbound through a brokered, allow-listed conduit to a business-side copy; do not dual-home; use unique least-privilege accounts; monitor that conduit for unexpected connections; and run the interface change through MOC. A read-only business replica plus a locked-down process collector is slower to wire than a second NIC. It is the design that matches zone-and-conduit practice.

Exam traps: treating IEC 62443 as if it were automatically a supplied NCEES standard; treating a dual-homed historian as a networking convenience; treating logs as a replacement for segmentation; patching a live compressor controller the afternoon the bulletin arrives without a window.