SCADA Problems Too Big To Call 'Bugs,' Says DHS 92
chicksdaddy writes "With the one year anniversary of Stuxnet upon us, a senior cybersecurity official at the Department of Homeland Security says the agency is reevaluating whether it makes sense to warn the public about all of the security failings of industrial control system (ICS) and SCADA software used to control the U.S.'s critical infrastructure. DHS says it is rethinking the conditions under which it will use security advisories from ICS-CERT to warn the public about security issues in ICS products. The changes could recast certain kinds of vulnerabilities as 'design issues' rather than a security holes. No surprise: independent ICS experts like Ralph Langner worry that DHS is ducking responsibility for forcing changes that will secure the software used to run the nation's critical infrastructure. 'This radically cuts the amount of vulnerabilities in the ICS space by roughly 90%, since the vast majority of security "issues" we have are not bugs, but design flaws,' Langner writes on his blog. 'So today everybody has gotten much more secure because so many vulnerabilities just disappeared.'"
Some background - 747s and online SCADA systems (Score:5, Interesting)
Some extra info popped up online just a few days ago - a SCADA consultant posted this a few days ago. It's slightly terrifying, though someone with more SCADA experience than me would have to verify its accuracy:
For those who do not know, 747's are big flying Unix hosts. At the time, the engine management system on this particular airline was Solaris based. The patching was well behind and they used telnet as SSH broke the menus and the budget did not extend to fixing this. The engineers could actually access the engine management system of a 747 in route. If issues are noted, they can re-tune the engine in air.
The issue here is that all that separated the engine control systems and the open network was NAT based filters. There were (and as far as I know this is true today), no extrusion controls. They filter incoming traffic, but all outgoing traffic is allowed. For those who engage in Pen Testing and know what a shoveled shell is... I need not say more.
More here: https://www.infosecisland.com/blogview/16696-FACT-CHECK-SCADA-Systems-Are-Online-Now.html [infosecisland.com]
Re:I don't care about SCADA. Vulnerabilities, I do (Score:2, Interesting)
Trust me, almost everything you have come to depend on in terms of outside resources or outside facilities, directly or indirectly, involves SCADA. Almost. Intelligent cars use unencrypted, unsecure Ethernet connections, often with some form of unsecure wireless connection in there somewhere. That's not SCADA, merely designed just as badly.
Society is riddled with interdependencies. If you thought Red Hat packages could put you through dependency hell, you've not looked too closely at the systems in the real world much. Those are infinitely worse, frequently unmaintained and it's a minor miracle that civilization hasn't been put back to the stone age. Yet. Unless some serious effort is put in, the effort of keeping semi-decayed interlocking systems even vaguely in operation will become infeasible. Left as-is, it WILL eventually become more practical to hard reset civilization than to fix the cumulative errors.
Finally, "design issues" ARE bugs. They may be bugs in the design, but they're still bugs. It's not that the distinction should not be easily drawn, it should never be drawn at all. A bug is a bug is a bug. If a compiler messes up your code, it may not be a bug in your code but it's still a bug. A compiler bug. If a CPU fails to execute code correctly, it may not be a software bug but it's still a bug. A silicon bug. In this case, we have a design bug, but it is STILL a bug.
Re:Argh (Score:4, Interesting)
PLC IDEs are pirated in the industry all the time(several on TPB right now), so don't expect that to stop anyone outside the industry from writing malicious PLC code, let alone a disgruntled employee who has legitimate access. And anyone who is willing to decompile code taken from a decapped ROM is more than able to buy a broken PLC on ebay and fix it into a testbed.
Everyone else will just download the exploit from that guy.
Re:Argh (Score:2, Interesting)
Mod parent up. As someone who is working in development of SCADA systems at a large company, I tell that every customer I meet. We have it in the manual, we take it into account in projects:
SCADA systems don't belong on the internet. Not the PLCs, not specialized controllers (motion etc.), not the HMI systems or data loggers either.
In addition to using a cable you can simply unplug, we would typically recommend a VPN router thing between the SCADA system and the internet (cheap or not so cheap, doesn't really matter); apart from protection from viruses etc. the protocols for data transfer aren't really encrypted in most cases and industrial espionage is a concern as well.
Some customers still ignore that though - I just checked a couple of IP addresses I received for remote access in recent months, and yes, there are some of our controls available on the internet (not even password protected in at least 2 cases). Luckily, they're not that easy a target ($$$ to get an exploit on the proprietary system) and at least these are not in critical industries. Still, the stupidity of some customers is astonishing, and it's certainly a safety issue (I'm talking about physical safety here, machine parts could be moved when they are not supposed to move).
But it gets even worse sometimes: Even if a system was technically safe, people need to care about safety. I've recently been at an automotive supplier where employees were surfing the internet with IE5 on a robot control (essentially an old Windows NT based PLC with remote maintenance access over the internet). They had a dozen viruses installed there, some porn popups opening every few minutes, and NO ONE CARED. And that thing was primarily responsible for moving a number of big freaking robots on a production line.