This is the second in a series of articles on security features in the next generation of PLC’s that will mark the end of Insecure By Design. A panel at S4xEurope will highlight Secure PLC’s, and the event includes other sessions on PLC integrity and ICS secure protocols. It’s time to plan for your next ICS, or even accelerating upgrade plans, to be securable.
A simple and devastating attack on an Insecure By Design ICS device is to upload bad firmware. Not only will this stop the device from working properly, but it can also overwrite the firmware upload feature and require the asset owner to replace all of the affected devices. Do you have 100% sparing on your PLC’s and other embedded devices? This went from Project Basecamp theory to reality in the recent Ukrainian attack where serial-to-Ethernet gateways were purportedly bricked.
Code signing generates and appends a digital signature to the software or firmware, and a device can verify the signature to insure the authenticity of the author of the code and that the code has not been altered in transit. It’s basic and has been needed for years. Fortunately it is one of the near universal features in the NextGen PLC. The new Modicon M580 from Schneider Electric is a good example.
All Modicon M580 processor firmware is digitally signed by Schneider Electric, and the corresponding public key to verify this signature is loaded in memory that cannot be altered. The digital signature of the firmware is verified before the firmware is accepted and loaded into the M580. UPDATE: The word processor was added as the 4th word of this paragraph. There are still some M580 modules, like motion I/O modules, that have firmware that is not signed.
The digital signature is also verified whenever the PLC starts, a secure boot feature.
The Unity Pro software and DLL’s provided by Schneider Electric are also digitally signed so their authenticity can be verified. These are run on a Windows PC so the public key cannot be hard coded into the computer as in the PLC, but this is still an effective security control.
After rereading the two paragraphs above it would be easy to underestimate the importance of this code signing feature. It takes away an easy way to brick the device; it takes away an easy way for an adversary to load his own attack code on the device (a trick we have used in a number of projects); and it makes counterfeiting hardware and software more difficult.
Beyond the code signing there are other security features enforced on the PLC to prevent unauthorized changes to applications (the logic or program run by the PLC):
- A password can be set for each application. The password is stored and must be provided to the PLC whenever an application change is sent.
Note: Many older engineering work stations (EWS) applications have a deceptive “security feature” where it required a password to make a change, but the password was only verified at the EWS, not at the PLC. So the attacker would simply communicate directly with the PLC to deploy his changes. Avoiding the EWS and developing scripts to communicate directly with the PLC is a staple in Reid’s arsenal.
- A memory protect option prevents remote changes to the application and memory card
- The M580 can be configured to prevent remote commands from changing the CPU Run / Stop status
- PLC access can be set to traditional Modbus Read/Write, Function Code 90 Read/Write, or Function Code 90 Full Control
- There are additional access control features enforced in the PLC to restrict access and capabilities down to the Function Block granularity
There is a lot more to come on the Modicon M580 security including limiting the attack surface, secure EWS to PLC comms, and secure ICS protocols. And the good news is not limited to Modicon PLC’s; the next PLC we will cover is Rockwell Automation’s ControlLogix.