SCADA Problems Too Big To Call 'Bugs,' Says DHS

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.'"

Comments

Call them whatever you want

[elrous0]

"Bugs," "security vulnerabilities," "design flaws"--really doesn't matter. They can still blow up an Iranian centrifuge. And I'm pretty sure that means they can blow them up in other countries too, along with just about anything else that depends on a PLC. Stuxnet, as well-intentioned as it may have been for Israeli and U.S. interests, was a wake-up call that goes way beyond any petty Persian pissing contest.

Re:Call them whatever you want

[Anonymous Coward]

"Bugs," "security vulnerabilities," "design flaws"

it matters to beaurocrats, unfortunately.

the categorization of these flaws, and whether they are a "bug" or not, can determine by law or policy who is on the hook for the $$$ required to fix the flaw.

Some background - 747s and online SCADA systems

[djkitsch]

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

Re:Some background - 747s and online SCADA systems

[LWATCDR]

Maybe you should not believe everything that you read.
"Nearly all SCADA systems are online. The addition of a simple NAT device is NOT a control. Most of these systems are horribly patched and some run DOS, Win 95, Win 98 and even old Unixs. Some are on outdated versions of VMS. One I know of is on a Cray and another is on a PDP-11."

Ummm a SCADA control on a CRAY? Really> Where?
PDP-11 maybe but a CRAY?
Also the system you mentioned can not be changed while in flight. Maybe it could be bypassed but then maybe not. The system is not a flight system. In flight it just recordes the information it can not change the settings. Makes good press but not really the problem people think it is.

The real issue source of all our problems is that all our systems are no online. Even something as simple as a picture viewer needs to be checked for security issues today. Scada systems used to depend on physical security they where air gaped. The problem is that we now use COTS hardware so it is so easy bridge networks that it happens all too often.
About the only network I would bet on being not bridged would be on a nuclear submarine at depth unless the ELF system is on the network but man that would be one slow hack.

Re:Some background - 747s and online SCADA systems

[__aaqvdr516]

I can only speak for US Navy Submarines. There are no connections to any reactor systems to any network of any kind.

I don't care about SCADA. Vulnerabilities, I do.

[AtariDatacenter]

SCADA? I don't care about. Not directly. But the problem is that once the government says, "These aren't vulnerabilities or security holes. These are design issues." The problem is that you've set the example, and other software vendors are going to follow.

Example: "The denial of service attack against your application is not a security vulnerability, it is just a design issue that everything locks up for a while if it gets an incoming packet, and tries to resolve the IP address against its authoritative DNS server while that is DNS server is offline. We only do security fixes on old products / old releases. Sorry."

"Design issue, not a security vulnerability" is not a distinction you want easily drawn. Others will follow a government example if it is an easy out.

The problem in a nutshell

[dkleinsc]

Making code secure is expensive. When these systems were designed, they were not going to be connected to any outside system, and thus were not designed securely because in order to do anything really bad you'd need to physically access the machine, which meant getting past security guards, cameras, etc without anybody noticing. Nobody could justify the expense of doing things right the first time.

Then somebody with no technical background comes along and says "Why can't we manage this system from our office desktops?"

Argh

[Anonymous Coward]

We do SCADA systems in the States. We subscribe to several polices regarding SCADA networks:
1) DO NOT connect your SCADA network to the Internet
2) if you must connect for remote-access, use a patch cord that you ALWAYS unplug afterward.
3) DO NOT use your SCADA machines for desktop business purposes - especially on the Internet!
Argh, the crap that appears in the media. For example, you cannot "infect" a PLC. Why? They don't run Java (or script), or any language recognizable by the Internet community. They don't even run executables, in the sense that PCs do. Their programming is done in a specialized, proprietary language that requires a specialized IDE to manipulate. Write you own? Sure, if you have thousands upon thousands of man-hours handy. Do an open source IDE? Within 24 hours of posting your project somewhere, the manufacturer will be knocking at your door. PLCs are very, very proprietary, and they makers want them to stay that way.
Stuxnet infected a PC, causing it to change the signals it was sending to motor speed controllers, thus fouling up a process. Which is why you keep your SCADA PCs as far away from the Internet as you possibly can.

Re:Argh

[elrous0]

The Iranians had the same policies. Didn't stop Mossad or whoever from putting it on some Russian contractors' thumb drives and infecting them that way. Not so much of a worry unless you're a high value target. But the problem is that a lot of industrial systems ARE pretty high value targets.

Re:Argh

[Zerth]

For example, you cannot "infect" a PLC. Why? They don't run Java (or script), or any language recognizable by the Internet community. They don't even run executables, in the sense that PCs do. Their programming is done in a specialized, proprietary language that requires a specialized IDE to manipulate.

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

[Anonymous Coward]

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.

Re:I don't care about SCADA. Vulnerabilities, I do

[Anonymous Coward]

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:I don't care about SCADA. Vulnerabilities, I do

[CobaltBlueDW]

Personally, I think design flaws is a much more damming claim to make about your product than a bug report. A bug is a low implementation level issue/oversight. A design flaw means your product is rubbish from the ground-up. I would MUCH rather someone say my software had a bud than that there were design issues. I doubt this is going to be a trend that catches-on. The only way I think it could possibly help a company to make such a damming claim would be if it took the words vulnerability or security off the table, which have a much worse connotation. --Although, design flaws create vulnerabilities and security concerns, so even that doesn't seem likely, IMHO.

also how much code is tacked on to older code

[Joe_Dragon]

also how much code is tacked on to older code makeing it so that lot's of hacks and other security holes more likely?

Now who want's to pay to rewrite the system from the ground up to make it secure or do you want to do it cheap and just patch over the bad design?

WTF, DHS is now cyber-security?

[Runaway1956]

When I look at DHS, I can't find a single area in which they are competent. They can't seal the border, they can't ensure that terrorists are denied entry to our aircraft, they can't intercept a terrorist. What in hell CAN they do? Suddenly, they are in the business of issuing cyber security warnings?

The one and only thing that they MIGHT be able to do correctly, is to tell business to observe best practice advice from the professionals. Beyond that - I expect nothing.

Oh yeah, if they can grasp the concept, they might push the idea of strict air gapping.

In other words -Too hard -don't want to think...

[hguorbray]

We'd rather get back to feeling up 5 year olds and people's Afros rather than address an infrastructure and industries that are highly vulnerable to malicious hacking that could affect the safety and well being of thousands.

They're so paranoid about 3 oz of liquid -what about industrial controls at a petrochemical or other large chemical plants in which thousands of gallons of chemicals could be blown up or caused to release hazardous materials?

I'm just sayin'

Re:Correct me if I'm wrong...

[AK Marc]

If you design a car with a gas tank that dislodges from the filler neck in a crash, spilling fuel in the case of a moderate crash, turning a survivable minor injury crash into a life-threatening incident, then you designed it wrong. If you purposefully design it to keep the filler neck attached for all crashes, but a part sourced for it did not meet specifications, resulting in inadvertent detachment, then you have a "bug" that was most certainly not a design flaw, but a build (coding) flaw.

One is a purposeful choice to make an inferior product to save time/money. The other is a properly designed product with an unintentional flaw. Sadly, deliberate negligence is tolerated (and seemingly encouraged), while unintended flaws are punished more harshly. But that's government security for you. Appearance is much more important than effect.