Address SCADA Security Vulnerabilities NOW, Not Later (plus CoDeSys White Paper)

Submitted by Eric Byres on Thu, 2012-11-08 10:28

Who is responsible for fixing the thousands (some say 100,000) of vulnerabilities that exist in PLCs, DCS, RTUs and other automation devices that are in use in facilities around the world?

On the one hand, we have the position of Dale Peterson at Digital Bond. Dale ardently argues for (and takes) aggressive measures to pressure ICS vendors into making their products more secure. Through their 2012 Project Basecamp and subsequent disclosures, Digital Bond publically released vulnerability details for a large number of controllers.

At the same time, they provided matching attack software, software that could cause serious operational failures at hundreds of critical infrastructure sites around the world. Are these disclosures effective and justified pressure tactics? Or are they irresponsible acts that could harm people, companies and economies?

Vendors Need to take Responsibility for Security

Certainly SCADA and ICS vendors need to take responsibility for creating secure control products. As we discussed in earlier blog articles some vendors have really stepped up to the plate. Others have been terrible - their customers need to find a better supplier.

However, I strongly disagree with Dale’s tactics. By releasing exploit code, he is punishing the very people he claims to be helping. Rather than publishing free software for attacking controllers, it is far better to provide operators with immediate solutions to the many vulnerabilities that are being disclosed today, including those made by Digital Bond.

Operators of industrial facilities today must face the challenge of an escalating cyber threat landscape that includes increasing numbers of vulnerability disclosures.

But the Real World needs Real Solutions Today

Let’s be clear. I agree with Dale's comment that "every critical infrastructure owner/operator who is deploying field security devices should be simultaneously demanding their vendor provide a plan to add security to their PLC or RTU". That is the right way to fix things in the long run.

Unfortunately users have to deal with the real world, a world that has real constraints on available resources. Even if automation vendors assign 100% of their development and Quality Assurance teams to making all of their control products secure, it will be several years before these devices show up on the market. And unfortunately security isn't the only demand on a vendor's resources.

Unless a company wants to lose its customers (and the CEO lose his job) any successful company needs to balance those many demands from customers. Security will be one of many features in next generation controllers, and it will take time.

Then there is the end user. Just because a PLC might only cost $1000 (or even $10,000) doesn't mean that is the cost of replacement. In fact, CPU hardware is typically a small fraction of the cost of a project. Back when I was actively designing control systems, a project using a $10,000 CPU typically involved $100,000 to $300,000 of design and commissioning. Replacing a control system could quickly end up requiring weeks of down time and many hundreds of thousands of dollars in project costs.

Projects this size don't get approved overnight - it can take years. For something with a Return on Investment (ROI) as ill-defined as security, a project with only security benefits may never get approved. Sad, but true.

So what is the controls engineer supposed to do while he or she waits for the vendor to release the secure RTU, PLC or DCS? And then when he/she waits several more years to get their project approved?

This is where field devices like the Tofino Security Appliance come in. They are not intended to be the perfect long term solution. They are a solution that will work today. Plus they cost only a few thousand dollars, a price that most engineers can get approved.

CoDeSys Vulnerabilities and Exploit Tools are released by Digital Bond

On October 25, 2012, Reid Wightman published two tools pertaining to vulnerabilities associated with a Wago IPC device that were released earlier in the year as part of Digital Bond’s S4 Project Basecamp. The tools target the CoDeSys Control Runtime that is part of the device, and exploits vulnerabilities that can affect its availability and integrity.

While currently we are unaware of malware or cyberattacks that take advantage of the CoDeSys vulnerabilities, or the tools released by Digital Bond, their potential for serious damage is high. That is because the CoDeSys Runtime is embedded in more than 200 PLCs and industrial controllers.

Critical infrastructure facilities, such as this electrical station, could have production impact, go offline, or have an environmental or safety incident if it is the target of an attack that uses exploit tools released by Digital Bond.

Good Security Today is Better than Perfect Security in the Future

Instead of publishing exploit code, SCADAhacker.com and the team at Tofino Security worked together to create a White Paper that analyzes the CoDeSys vulnerabilities. The paper then details a number of practical compensating controls that will help operators mitigate risk today.

The White Paper is available at the end of this blog. When you download it, you will also receive:

  • a number of free SNORT rules that run on Suricata Intrusion Detection System (IDS) engines (included in the White Paper document)
  • a link to two Tofino Security Profiles that protect ICS devices from the threat of malware that uses the CoDeSys vulnerabilities.

Sure, you need Tofino products to use the Security Profiles, which means revenues for my company. But you can use the SNORT signatures for free. Whether you want to use the free solution or the commercial one is a decision that each potentially affected organization can make.

Providing this White Paper and related tools is part of our belief that providing good advice, training and practical solutions are the ways to assist operators today. Actions that threaten both the availability and integrity of national infrastructures around the world are not.

Good security today is better than waiting for perfect security five years from now!

Related Content to Download

White Paper - "Analysis of 3S CoDeSys Security Vulnerabilities for Industrial Control System Professionals"

 

Download this White Paper and find out:

  • What the 3S CoDeSys vulnerabilities are and what an attacker can do with them
  • How to find out what control/SCADA devices are affected
  • The risks and potential consequences to SCADA and control systems
  • The compensating controls that will help block known attack vectors

BONUS- you will also receive two Tofino Security Profiles that can be used to mitigate the CoDeSys vulnerability by permitting standard engineering functions but blocking malicious packets

 White Paper Version 1.1, released Nov 21, 2012:

  • Clarifies who the affected vendors are
  • Includes an analysis of Nessus plug-ins

Links Related to CoDeSys Vulnerability

How to check if your controller is affected:

Other Related Links

 

 RSS Feed Subscribe to the "Practical SCADA Security" news feed

Author Eric Byres

Comments

4
Submitted by Ron Southworth on Fri, 2012-11-09 07:24

Hi Eric,

What a great posting!

I totally agree with what your key messages are. Everyone in the security space has to earn a living from what we do so some " advert content " has to come in to play somewhere in what we put up in cyber space, you can debate over what is socially acceptable in any given forum and I think your balance is better than most Eric.

I think that it should also be a given that the vendor community has to eek out a crust as well so hitting folks with a 2*4 only goes so far - at some point awareness education and training have to come into play.

I also understand that Dale is endeavouring to get vendors and owners and operators alike to take this security stuff more seriously. As you have said some vendors are on a journey and others are less than helpful and ultimately they will go the way of the dodo.

I don't agree with anyone just publicly identifying any vulnerability without them equally offering up how folks mitigate these problems till they can be designed out.

We are after all talking about gizmo's that keeps lights on, clean safe water coming from a tap and glazed doughnuts with the right amount of jam in them kinda stuff.

Not my office email is off line here. Dale knows this....

Please keep offering mitigation strategies mixed with your product creation capabilities ! It is a step in the right direction.

I hope Dale starts to offer or at least starts talking about how to mitigate these risks with practical and end user useable techniques.

Like some of your postings lately al, good for getting folks talking bout stuff. Are we getting the right audience(s) talking about the the right things ? That is where we are missing the mark. Well that is what I am experiencing and seeing.

Keep smiling

Ron Southworth

Submitted by Ruslan Stefanov on Fri, 2012-11-09 12:12

Discussion whether to disclose vulnerability details or not is the matter of The Way to the secure ICS future. Will this Way be revolutionary (more risky and faster) or evolutionary (less risky and slower)? If you choose Dale's approach than you are security revolutionary. If you like Eric's position than you are moderate reformer. The less vulnerabilities are corrected the more Tofino Firewalls are needed.
But destination point of The Way mostly the same: few vendors are presented on the market with good, secure, more expensive ICS devices.
As for me I'd like to be revolutionary because I don't want to wait when my customers will understand threats and decide to spend much more funds for security.

Submitted by ZyberZorro (not verified) on Mon, 2012-11-12 14:33

Why is the use of Snort IDS seen as news? ICS vendors are already using IPS for some time, IPS combines the detection of a security breach with the action to block propagation of the security breach. Malware propagation is so fast that by the time Snort has detected it, the malware has spread through the system.

Additionally IPS offers protection. Aren't we looking back in history here? First IPS application was introduced over two years ago to protect the inner boundaries of the ICS.

Submitted by Joel Langill on Fri, 2012-11-16 18:01

Most vendors are not using IDS for intra-network analysis and detection; they limit it to only monitoring boundaries. This is not a strong position, because it needs to be used as an early warning and detection mechanism within a given security zone.

You should take a look at Sophia and see the value it provides. This is nothing more than a fancy GUI on top of a basic IDS type engine. A lot can be gained when you use an IDS along with network fingerprints to provide detection of malware within trusted networks.

As for you comment about spreading ... this is one of the many reasons why ISA99 zones need to be established based on relative risk and security profiles. The idea is that if an infection enters one zone then it is likely to infect multiple hosts within that zone, but it should not be easy for the malware to spread outside of that particular zone.

Thanks for the comments and your valued input.

Add new comment