Freely subscribe to our NEWSLETTER

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 responsibilty 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!