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.
This issue extends to even basic items like write requests that cause things to turn on/off, increase speed, raise temperature, … Today you either allow everyone with logical access to issue these commands (good guys and bad guys) or block these requests for everyone with something like a Tofino Read Only Firewall.
Compensating Controls and Overall System Security
It is a common misconception that Digital Bond’s focus on the insecure by design protocols and field devices means we are anti-compensating controls or implementing any administrative and technical security controls. Most of our consulting involves analyzing just that. We even provide a prioritized list of what actions to take in the next 0-6 months and 6-18 months to most efficiently reduce risk. My guess is a lot of this is very similar to what Joel teaches in his class — that I hear is quite good.
Unfortunately we also have to tell owner/operator clients that if an attacker gets to the PLC’s it’s game over. It’s a staple in every report along with a recommendation to plan to replace these devices in the next 1-3 years. We selected the 1-3 year time frame because it is the average time frame, not expedited, for PLC replacement projects to roll out to the field sites in our experience.
The real crime is many owner/operators who are leaders in ICS security have replaced their PLCs in the last ten years with brand new, insecure by design models. Our first SCADA client we worked with in 2000, replaced their PLC’s in 2009. Much to their chagrin they were stuck choosing between insecure by design models. The ICS community keeps digging ourselves deeper into ICS insecure by design pit. The first step is to admit and get consensus that it actually is a problem that needs to be addressed by the critical infrastructure SCADA and DCS in the near term.