.gif)
REMINDER: S4 Call for Papers closes on September 18th.
Last week I introduced our Project Basecamp – Hacking PLC’s. This will be the Digital Bond paper at S4. There have been a number of questions of what we are doing, why we are doing it, what disclosure process we will follow … I’ll start with the why in this entry, and there is a technical answer and an ICS security community answer to that question.
The technical answer is easy; it’s a very cool project. We have the equipment in our lab so why not share it with some talented researchers, focus them on at least eight different PLC vulnerability classes, and let them collaborate on attack methodologies. We expect to get some good comparison data on vulnerabilities and build up a knowledge base on attacking PLC’s. And since the work has started I can tell you, not surprisingly, that some of the PLC’s are better from a security perspective than others.
However, in all honesty, the genesis of the Project Basecamp is an anger and frustration that we have made little progress in PLC and other field device security in the last, lost decade. Frustration that our clients can’t even purchase a reasonably secure PLC or RTU today. Frustration that even after Stuxnet and Beresford the issue fades away.
Many have said that Digital Bond and a couple of others have been too tough on Siemens, and this is a problem that all PLC’s have. Just the opposite is true. The ICS security community, automation press, Siemens customers, … have all been much too easy on Siemens. The Stuxnet and Beresford vulnerabilities in the S7 PLC are still there!
Let me repeat that … the Stuxnet and Beresford vulnerabilities in the S7 PLC are still there!
Nothing has changed. I cannot understand why everyone who covers this industry and every customer who uses Siemens S7 PLC’s is not asking Siemens hard questions like we posted earlier every chance they get. Are we really as a community going to shrug our shoulders and go another ten years like this?
This really hit me hard at the post Black Hat press conference where our industry experts said this was not a Siemens problem, this is a problem with all PLC’s/RTU’s, it has existed for a long time, we all know about it. How true and how sad that is. Congratulations. We all knew about it, but this is a huge failure by the ICS security community.
In July I went on a day hike with Ralph where he told me if things don’t change he won’t be doing ICS security at the end of this decade. I feel the same. If we can’t make progress on this basic and critical security issue it is not worth wasting time on ICS security.
By no means am I, or Digital Bond as a company, blameless for the lost decade. The prime example is when we demonstrated any attacker’s firmware could be easily loaded on the Rockwell Automation ControlLogix Ethernet card in January 2009 at S4. We played by the implied rules, kept in it the community, tried to avoid any sensational press, and nothing changed.
To the best of my knowledge, this simple to exploit, insecure by design feature is still there. Any attacker with logical access can have complete control of an ICS with ControlLogix. Fail. Not only for Rockwell Automation but also for all their customers and Digital Bond.
Long time readers of this site have probably noticed a more strident tone since Stuxnet. This project is an extension of that tone and an effort to highlight the issue in a more effective way so that customers demand a solution. We don’t know if it will work, but we do know the way we have approached the problem in the past didn’t work.
Finally, we hope that there is some good news to report about some of the devices tested. Many of the vendors making the SCADA and DCS applications that run on servers and workstations have made great progress on security. There are SCADA and DCS we recommend from a security perspective. And we hope that in the near future there are one or more PLC/RTU/IED vendors that step up on security. Vendors that we can hold out as examples for the rest of the industry and recommend to our clients who care about security.
I don’t think it is the toughness towards any vendor that is the issue here but it is the lack of appreciating the basic security task that is the issue here.
The fact that the president of the US isn’t bullet proof doesn’t mean he / she isn’t protected. There are many other compensating security controls. Don’t blame the vulnerable element for not being protected. Everyone in process IT security knows PLCs are vulnerable and need additional security controls for a proper defense.
Stuxnet never targeted the PLC it merely used it to execute the altered code. The attack and exploit was the engineering program / PC. The direct PLC attack would never have had the same level of sophistication as the clever way it was done using the engineering PC and trying to stay under the radar for as long as possible.
A layered protection can compensate for the vulnerabilities of the PLC, so architecture is the key element here. OK it is nice if we wouldn’t have to worry about the PLC, but since we know its weakness we can create countermeasures.
Stuxnet learned us a lot, but not that PLCs are vulnerable. It learned us the importance of detection of a security breach, it learned us that what was theory before could become reality, and it learned us that we focused too much on the perimeter. Much of this led to architectural improvements.
Siemens learned us the importance of good communication, learned us about irresponisible behavior of Siemens engineers joking with equipment that can have a direct impact on people’s safety, emphasized the importance of security as an integrated part of the design process (threat modeling, static code analysis, fuzzing, etc.), and shows us the security companies developing business around the “blame it to the vendors” theme, carefully preventing mentioning the various shortcomings their target customers the end user community can be blamed for.
I think it is all a bit more complicated than often communicated.
@sihoko
Re: “carefully preventing mentioning the various shortcomings their target customers the end user community can be blamed for.”
Yep. Digital Bond has never tried to help owner/operators improve their posture — because there is no need to: the systems will break if you try secure them.
@Plantae
I don’t know your role in ICS, but we see systems without AV, Without prper patching, without prpoer network segmentation, without back-ups… Just follow the security world and you can add more…. Firewall configuration, containment / disconnection, AV signature updates ………, and this just about technical controls.
Nothing to do with vendors, but very basic ….
We assess many ICS a year, so believe me vendors can and must improve but let us not forget the many owner /operators that must take their responsibility too.
A couple of comments:
- you already mention that yourselves and other reputable companies test and inform vendors, I know that some vendors do patch and other do not. Maybe the reason vendors do not resolve the vulns is that they do not have the knowledge, will or the governance inside their companies to resolve these issues.
- Is it not better to assure that the vendors are embedding security in the products, so that the end user can rely on them. Should not the end users be demanding secure products from their vendors, rather than us (biased) ICS security professionals.
- There are already some mechanisms out there for the end users to get their vendors security approved. I know of a vendor that has vastly improved the security of their product due to their customer saying, fix this or you are gone.
Putting out the vulns into the open world and scaring the vendors, just puts them in defense mode, and honestly, I think it damages DB reputation.
@JHS
Embedding security security in the products is exactly what ISAsecure does with their certifications, it is not just testing but also an audit of the development processes.
I think responsible vendors always solve the vulnerabilities, but you have to take into account that during the period between the discovery of a vulnerability and the availability of the patch, basically the black risk / gray risk story, the group knowing about the vulnerability must be as small as possible. Otherwise the black hats would have a field day.
Certification helps, ISAsecure is the most strict certification available today. Vendors are following this path.
Wurldtech APC, though with many flaws, is a step in the direction of improving project and lifecycle services.
So things are happening. Both vendors and end users improve. My only remark is that both vendors and end users must improve. But I often see a biased focus on vendors, where I experience the biggest gap with the end users.
Sihoko,
No argument from me that the vast majority of ICS owner/operators need to step up their security efforts and that the most dramatic improvement in their security posture will be through their own initial efforts rather than a better vendor product.
However there are a minority of ICS owner/operators trying hard to secure their systems. Some have been at it for over five years and have quite mature programs. They are stuck with no good security choices in some cases, especially in field devices. We are blessed that we work with those who care about security … because they are the ones who spend money on ours and other services.
For them, the vendor is the biggest problem. I also have a real hard time when an owner/operator has a once every 15/20 year chance to upgrade their field devices and can’t get even basic security features. They will now have to live with this for a long time, even after they begin to care about security in the future.
Dale
Dale,
We are in agreement, I can only oversee EMEA and have worked with many owner / operators that did a great job. Well organized and properly secured. And for those more secure equipment will help them.
Never the less security remains a moving target, so my guess is systems in 10 years from now will still have vulnerabilities, we probably just raised the bar a bit for the attackers. But a targeted attack will still have good chances to succeed, independent from the security assurance level of the field devices. Once your attack can penetrate into level 1 you already have made quite an achievement.
My problem is that fir many systems reaching level 1 is not more difficult then penetrating level 3.
Sorry response wasn’t ready … Thick fingers on an iPad.
Therefore my emphasis is on architecture not so much resilience of PLCs. I believe that if I can gain access to the level 1 network segment I don’t really care how well protected the PLC is, the system is in serious trouble when you have abreach at that level.
But I understand the public wants spectacle, blood, casualties, ….. so you need to provide this by hacking PLCs. Great, but not really a challenge.