For Secure & Robust ICS

PLC’s: Insecure By Design v. Vulnerabilities

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.

Comments

I cannot help to be reminded of the fairy tail about the Emporer and his new clothes. While everybody can see that he’s naked, few are able to speak out. Chances are that several years from now, people will find it quite bizarre that we wasted a decade with security by obscurity and being shy to talk terms when we might need every single week to secure our systems before the storm comes in. Good job, Dale.

We all know that PLCs are vulnerable, and with them many other control devices. Specifically Siemens has a hard time here with a sequence of vulnerabilities exposed and an often weak response. However it also has a considerable taste of Siemens bashing. I believe when we would examine HIMA, Allen Bradley PLCs more closely we find similar issues.

We know from experience with other PLC’s in our lab that you are right, and we have a project in the works to dig deeper into these systems at some consistent level of assessment.

The real problem with Siemens is their response to the vulnerabilities. We have covered their failures ad nauseum on this blog with failing to tell customers about Stuxnet fingerprinting and PLC impact, failing to fess up that the 300 and 400 had the same “replay vulnerability” until the researcher forced their hand, and total lack of candor at the Siemens Automation Summit. They repeatedly lied and misled the customers, and in our experience other vendors do not all do that.

Underlying what Dale, Dillon, and Ralph (among others) have shown about PLC security is a very subtle but very important distinction:

What is an appropriate design point for PLC security?

Must we design these things to survive direct malice from the public? Or can we assume a level of trust?

Mind you, no matter how these questions are answered, Siemens’ response was pathetic, misguided, and it failed to deal with the issues. But that said, we need to have a very careful and thoughtful discussion about performance and security trade-offs and the merits and values of each.

If we do not secure PLC gear, can we find ways to secure the HMI and networks so that the PLC is not likely to be attacked?

These are the ultimate questions of this issue. They are fundamentally engineering concerns. The process is what is at stake here, NOT THE PLC. Different applications may arrive at different answers.

Two sides of the same coin:
Heads – ICS are vulnerable
Tails – ICS are not built to withstand malicious attack

Design basis changes aren’t often remedied with a simple patch. To be blunt and as painful as it sounds we instinctively know a new generation of ICS equipment is needed as deperimeterization appears to be irreversible.

In the short term when there is a lot at stake for industrial safety we see specialized SIS bolstered by good procedure. Shouldn’t the best practices for secure ICS come from prioritized cyber effort on SIS rated equipment?

Bryan, let’s face it: Not only do we know this by gut feeling but also from intellectual analysis. It is starting to puzzle me that the component vendors don’t see the market opportunity and say ok our legacy products were never designed for security because you, the customer, didn’t demand it, so here’s some cool new stuff that you can purchase for a premium — rather than hey don’t worry about your installed base because we’re proactive holistic.

Your well made argument about SIS holds some irony because even though the boxes with the yellow stickers were never designed with security in mind they offer several of the features that we miss so much in basic production control systems. It appears to me that not only can safety learn from security but also the other way around. “And that’s all written in my book.” OMG, I’m beginning to talk like Joe! ;-)

Very good post Dale – backed up with some great comments/perspective. Given progress to date, we can expect sorting out what is baked in “good enough” for various pieces and parts to play out for some time. Nearer term, responsible owners and operators increasingly will need to ramp up coherent, agile defense-in-depth to combat these type of issues- “onion skins” of increasingly well managed security layers around and within inherently vulnerable functions/substrate.. at the same time, striving for compliance margin as regulatory scope and rigor expands and businesses press into newer opportunities/technologies (smartgrid, renewables, etc.). Control Engineering had a good article recently on this topic (link below), using personal health analogy help drive key points home- security being an emergent quality of doing a number of things right. The good news for folks in the business (industry, vendors, regulators- trifecta opportunity for the talented), is that we’re really just getting started on a journey that looks like quite the growth opportunity for some time!

Ralph, the reason nobody is building it is because so few people actually know what to ask for. We still don’t know how to manage those keys properly.

And more than that, we don’t have the protocols to securely read and command these units. You’re talking about an entirely new generation of devices. It’s easy to gloss this over and say that it is possible, therefore we must do it. The problem is that we do not have the management or social models to make this work well.

Moving the latter two things is not nearly as easy as building a new device. That’s why you don’t see PLC manufacturers scrambling to build this new generation of devices.

1. Designing appropriate protocols is something that domain experts can do within a couple of weeks. The most prominent reason why this doesn’t happen is that the industry has become obsessed with agreeing on a “standard” before implementing anything, rather than coming up with a good engineering solution that eventually becomes a de-facto standard (such as Modbus and even TCP/IP).

2. The management and social models are there since decades. They are called quality management. Once that we treat cyber features as quality characteristics, the whole FUD nebula and PH fog (PH = proactive holistic) vanishes. Isn’t it bizarre that every maintenance engineer and plant planner knows that IP protection class or SIL level must be specified, while at the same time knowing/demanding nothing about authentication characteristics or network resilience? A controller with unknown network resilience, for example, IS equivalent to a controller with unkown IP protection class. As another example, during a briefing on cyber security policies for contractors a senior manager of a petrochemical corporation had the insight: Well, it IS quite bizarre that we even audit our logistics contractors’ tank trucks but do nothing in respect to the control system contractors that access our critical systems daily.

Dale's Tweets

About Us

Digital Bond was founded in 1998 and performed our first control system security assessment in the year 2000. Over the last sixteen years we have helped many asset owners and vendors improve the security and reliability of their ICS, and our S4 events are an opportunity for technical experts and thought leaders to connect and move the ICS community forward.