While significant progress has been made in securing ICS workstation and server components over the last ten years, almost no progress has been made in securing PLC’s and other field devices. Now with researchers / hackers of all hat colors, as well as more malicious threat actors, turning their attention to ICS, we are beginning to see a raft of PLC vulnerabilities. I had a post yesterday covering what is known about the Beresford vulnerabilities in Siemens S7 PLC’s.
Many PLC and other ICS vulnerabilities get no better than a shoulder shrug from the ICS community because there are much easier ways to compromise the system than an exploit. The SCADA and DCS are insecure by design and currently don’t require an exploit to affect the process in disastrous ways.
Let’s try to break this down in an organized way.
Insecure By Design
I can’t remember who coined this term, but it is accurate, descriptive and easily understood. And it applies to almost all PLC’s and other field devices. Even the latest and most expensive models you can buy today.
If you have logical access to a PLC you can:
- Read, write and otherwise access the tags/points. Write commands change the process, i.e. open or close valves, raise temperatures, turn things on or off. It is how operators control the process. These are ICS protocols that are insecure by design.
Note: Correcting protocol vulnerabilities is difficult because the protocol is often not under a specific vendor’s control and has been pushed out to a committee. Secure DNP3 is a great, and one of the very few, examples of a protocol committee integrating security into their protocol. Hoping for the day when this is easily available for purchase.
- Modify the ladder logic / program. This is the engineering that contained the logic to control the process. Some vendors offer access control security features around this. Besides the physical key lock, they are rarely effective.
- Modify the vendor firmware in the PLC because of the unauthenticated upload/download vulnerability known as Boreas. More than two years after proof-of-concept demonstration of this attack, it is still very common.
These are the big three, but there are more.
So why would an attacker worry about looking for and exploiting vulnerabilities when he can just use the PLC features to attack the critical infrastructure? The key is for an attacker to gain logical access to the ICS and then just decide if he wants to crash things or more cleverly affect the process.
Vulnerabilities
Vendors who did not worry about adding security to the PLC very likely did not worry about secure coding or other areas of a security development lifecycle. The result is it is very easy to find vulnerabilities in field devices.
So should we even worry about vulnerabilities while PLC’s are insecure by design? The answer is YES, as long as we rationally consider how a vulnerability affects the risk. Some examples:
- Poor protocol stacks causing crashes / denial of service – There have been numerous examples where network mapping, a new application with broadcast, or other network data causes key systems to crash. Most of these denial of service results have not been due to malicious causes. This is one area where PLC’s have made some progress due to the protocol stack testing from Wurldtech’s Achilles, Mu Dynamics and the new ISASecure certification.
- Unnecessary software increasing the attack service – many PLC’s have web and ftp servers, snmp, telnet and other services available on them. They have sample programs, vendor debugging code and more. A lot of this code is not maintained and was freeware or very old and cheap. The quality reflects this. Researchers and attackers will easily find vulnerabilities in this code. It should be removed.
- Backdoors
Researchers should continue to pound on these PLC’s, find vulnerabilities and disclose them as they feel appropriate. By no means should they stand down. Just don’t overestimate the impact of the findings.
Note: The large number of vulns found in free demo HMI are a great example of “SCADA vulns” that have minimal impact on the critical infrastructure.
Conclusion
It is going to take a long time to dig out of the hole we have with insecure by design and poor secure development practices. If the community gets obsessed with each vulnerability we will spin our wheels with little progress.
Loyal blog readers may think we have contributed to this obsession with vulnerabilities, but the reason we are harping on this is to try to educate owner/operators to demand a response from the vendor. Specifically a three-pronged vendor response:
- Integrate security features into the PLC that address a reasonable threat model. Share the threat model with customers and provide timeline when the features will be available.
- Integrate security into the development lifecycle. Tell us what you will do and do it. Customer should be able to audit the SDL at FAT/SAT. Things like security coding practices and training records to those practices, security in QA test plans and results, …
- Have a security vulnerability disclosure process for customers that is honest and detailed. Give the customers the information so they can assess the risk impact during what will be difficult years until better solutions are available and deployed. It will be ugly information at time, but stop hiding it.
Owner/operators need more specifics and action from the vendors and less pass-the-buck marketing spin like proactive holistic security. Vendors need to focus on securing what vendors control, the product.
Image by Hermes