Controller Hardening

What a controller can and cannot do

Programmable controllers were designed to be easy to reach. Their protocols assume a trusted network, many of them accept a program download from anyone who can send the right packets, and a controller from fifteen years ago may have no concept of a user at all. Newer platforms add real controls: signed firmware, authenticated protocols, role-based access, and integrity checks. Hardening is the work of using whatever the controller has, and surrounding it with network controls for whatever it lacks.

The controller is also not the most likely target. The engineering workstation that holds the programming software and the project files can change any controller it reaches, and it is a Windows machine with a browser. Hardening that starts at the controller and forgets the workstation has locked the vault and left the key on the counter.

Hardening measures

Mode and change monitoring

Two things about a controller are worth alarming in SCADA at all times: its mode, and whether its program has changed. A controller that leaves RUN when no one is scheduled to work on it, or whose program checksum changes, is either being maintained without a change record or is under attack, and both deserve a call. Most platforms expose mode, a program checksum or change counter, and the time of last edit as readable status. Log them, alarm on change, and compare the checksum to the last approved backup.

Programming for security

Hardening is not only configuration. How the program is written determines what an attacker who reaches the controller, or the HMI that writes to it, can actually cause. The community-maintained Top 20 Secure PLC Coding Practices collects the useful ones; the following apply to almost every water and wastewater program.

• Validate every input and every written setpoint against a physical range. A chemical feed setpoint of ten times the maximum is rejected in logic, not obeyed.
• Keep operational logic in the controller, not the HMI. The HMI writes a setpoint or a command; the controller decides whether to act on it and enforces the limits and interlocks itself.
• Restrict HMI writes to a defined set of tags. Nothing outside the command and setpoint list is writable from the network, and the program does not read commands from tags that are not on the list.
• Use plausibility checks between related signals: a pump that shows running with zero current, a flow with the valve closed, a level that changes faster than the well can. Alarm the disagreement.
• Alarm on mode change, on program change, on a hard stop, and on a restart. Count restarts and alarm the count.
• Do not leave forces, test bits, or simulation modes in a production program. If a simulation mode is needed, make it visible on every HMI screen while active.
• Log significant events in the controller with timestamps, not only in SCADA, so an investigation has a record that survives the SCADA server.
• Fail to a safe state on loss of communication. The controller runs the process on its own; a lost HMI does not leave a valve where an attacker left it.

Controllers with no security

A large share of the installed base cannot be hardened much: no credentials, no services to disable, a protocol that accepts any command. The controls for these are around the controller.

1. 01A firewall or a managed switch with an access list directly in front of the controller, allowing the SCADA master and the engineering zone only, on the protocol ports only.
2. 02Deep packet inspection on the conduit where it is available, so that the firewall can allow reads and block writes or program downloads from anything other than the engineering workstation.
3. 03Keyswitch in RUN, which most of these controllers do have.
4. 04A program integrity check from the engineering side: a scheduled upload compared with the approved backup.
5. 05A replacement plan. A controller that cannot be secured and cannot be isolated is a risk with a date on it.

The engineering workstation

The machine that programs the controllers is the most powerful device on the control network. It should be a dedicated machine, never the same laptop used for email and the web, in its own zone with a logged conduit to the control zone, with its own named accounts and MFA, with the programming software kept current, with removable media controlled, and with the project files backed up to a store the workstation cannot silently overwrite. An integrator laptop that programs many customers is a shared conduit between all of them; the on-site access rules on the vendor remote access page apply to it.