Address SCADA Vulnerabilities Now

Wednesday, November 14, 2012 @ 06:11 PM gHale


Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
By Eric Byres
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, who 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.

RELATED STORIES
SCADA Basics: Integrity Over Availability
Impact of Shamoon on SCADA Security
SCADA Patches You Don’t Get
SCADA Security Basics: Insecure PLCs
SCADA Security Basics: Terminology

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?

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 disclosed today, including those made by Digital Bond.

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 chief executive 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 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.

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.

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.
Eric Byres is vice president and chief technology officer at Tofino Security. Click here to read the full version of the Practical SCADA Security blog and to download the white paper.



Leave a Reply

You must be logged in to post a comment.