Jake Brodsky and Joel Langill had comments in a blog post late last year, CoDeSys IDS Signatures Easily Avoided, stating that is unfair or wrong to focus on an insecure by design PLC issue. They believe we should be focusing on the overall system security and insuring this reduces risk to an acceptable level (my hopefully fair synopsis, read their comments). This approach is terribly wrong for two reasons, and I’ll address the first today.
Key Point: Do you want the insecure by design feature? then the attacker gets it too.
The crux of Project Basecamp is that almost all PLCs/controllers are insecure by design. The most important deficiency that needs to be addressed is they lack source and data authentication for even the most important requests or commands. An attacker with logical access can upload new firmware, modify ladder or application logic, issue write commands to modify the process. An attacker that can reach a PLC can completely compromise the availability and integrity of the process being monitored and controlled.
Reid’s CoDeSys “attacks” are a good example, but only one of many in Project Basecamp that showed similar issues with GE, Koyo, Schneider Electric, Rockwell Automation (see the S4 video), … Reid simply monitored legitimate commands from the HMI/Engineering Workstation and put those into a script. These commands could upload and download files to the PLC, amongst a wide variety of other things.
The only way to stop these attacks is to prevent legitimate use of the insecure by design feature, and most owner/operators will not accept. In fact taking away these insecure by design features introduces risk related to responding to operational issues, especially in geographically dispersed SCADA networks.
There is a simple and practical example of this. Most PLCs used to, and many still have, a physical key with a variety of position such as Run, Rem (Remote), and Prog (Program) as seen in the picture. The generic idea is when the keyswitch is Run mode the ladder or application logic cannot be changed. However it is very helpful to be able to change the logic in a remote PLC for troubleshooting a problem, and it costs $ and may be logistically difficult to send an employee out to insert and turn the physical key to a position that allows remote logic changes.
The owner/operator must make a decision.
- He can leave the PLC physical key switch in Run mode (even removing the physical key) and prevent remote changes in logic from good guys and bad guys.
- He can leave the PLC physical key switch in Remote mode (or other mode that allows remote programming) and allow good guys and bad guys that can access the device to be able to change the logic.