SCADA Systems a Target for Hackers?

superstick58 writes "As a system integrator, I am often providing control solutions that utilize sophisticated Ethernet networks and as they say in the biz 'link top floor to shop floor.' Forbes has an article about the security issues that exist in SCADA systems. When I look back at some of the systems I have put in which include direct I/O control over ethernet and distributed HMI monitoring, if I can get access from the internet, it would be easy to bring down power for a plant or at the very least make operators in the building very uncomfortable. How vulnerable are the manufacturing centers of the world?"

My view..

[The Living Fractal]

I work in Big Oil. We have SCADA systems, we have an HMI to control the facilities, and it's all ethernet based. But the network is on a completley different wire than our internet-accessible network. You can't connect to the internet from our control network -- the wire simply doesn't exist.

And it shouldn't. They should stay separate. Period.

Re:Pretty old news

[Doppler00]

Well, lets say you are able to hack in. Would a bad guy know what to do with all those buttons and knobs without actually seeing the outcome from behind his computer screen? They would also need to retrieve a copy of the plant process diagram somehow, study it, and come up with a devious scheme to make the robots do something catastrophic. And a good safety system would have so many redundant independent interlocks, both physical and electronic, that it would be difficult to do any irreparable harm.

Re:NT4 On The Plant Floor

[Cassini2]

NT4 was a nice operating system for SCADA applications. It was built in a time where Microsoft cared about security. One of NT4's design goals was Military security ratings. I liked the feature where you could tell the system to only run 9 different preset executables. It made it really tough to crack (until ActiveX and Internet Explorer came out.)

Re:My view..

[Anonymous Coward]

Wow. Must be nice to have all your equipment on one site, or spread out along a pipeline that you own.

Some SCADA systems control diverse infrastructure scattered across areas bigger than any US state. As far as comms go, it's PSTN or nothing for places like that. Hard to keep your network scrupulously separated when you have to dial in to the remote sites!

But of course!

[WheelDweller]

SCADA systems, until recently, weren't build with security in mind; kinda like running everyting 'root' because you have a decent firewall. I used to program them; imagine blowing open a 3', 500psi natural gas pipeline?

SO MUCH MORE fun than hanging up an airport for hours, now isn't it?

Though, I'm not sure how far they'd really get...all these devices are different...kinda like Linux boxes. What works on a Vax with a communications network to controllers will be different from site to site...and they'd need to get the nomenclature from the inside. It would still be non-trivial, and the 'testing' to learn the system might tip off the Feds.

It's like the first time someone mentioned blowing up buses/trains; if there are people involved and a spectacular media coverage, it's a target. (Shouldn't be a big surprise, actually)

Safety systems protect against mistakes not malice

[Anonymous Coward]

You can make all the interlocks you want - and they'll probably protect you against mistakes and idiocy pretty well if they're implemented properly.

But you can't protect systems against informed malice.

(and never forget, when you idiot-proof something, God will just create a more ingenious idiot...)

Simple attacks are best

[Anonymous Coward]

For a few years I worked for the federal government doing electronics at airports. My cow-irkers and I spent a fair amount of time worrying about security issues. We were able to dream up lots of sophisticated attacks that would bring the aviation industry to its knees. We could have carried out those attacks. The trouble was that we were the only ones who could have done it. All of the attacks relied on at least one piece of information that no outsider could have accessed.

It became obvious to us that we didn't have to worry about the sophisticated attacks. As one of my buddies pointed out, it was far easier to plant a bomb in the middle of a runway than it was to carry out the attacks that we dreamed up. Protecting against the sophisticated attacks was relatively simple.

We remembered the war in Viet Nam (too bad a certain president didn't) and knew how much damage the Viet Cong could do with a few shit covered sticks. We became convinced that we had to worry about simple low tech attacks. What worried us was that we had no idea what those attacks would be. This was twenty years before 911. We had no concept of suicide bombers and terrorists using box cutters to take over airplanes were far beyond what we could imagine.

Re:Pretty old news

[putaro]

I don't know about that. Yes, taking control of the network and making things do what you want would require a lot of knowledge. Lots of hackers just like to "mess around" though and doing something that they think is l33t, like running a Quake server on a nuclear power plant network, could cause a lot of problems. These kinds of systems are not usually designed with a lot of redundancy at the software level. The people who build those kind of things just don't understand how to manage those kinds of things in software.

Case in point. Long ago I worked for a supercomputer manufacturer. Our system had a nifty temperature sensing and power control system that was all controlled from a small front end system, a 286 running Microport Unix. We could also do things like boot the system from that console and dial in to do remote diagnostics. I was working with a customer and he needed a patch so I started uploading it to main system via the modem link and a pass-through from the console into the main system (must have been Kermit). Things are moving along and then the main system crashes. For some reason it's overheating. OK, that's weird, we reboot and I start the upload again. System crashes again. About the third time we start putting two and two together and I go off and do some sleuthing around to figure out why that might cause a problem.

Well, it turns out that the hardware guys have the whole temperature and power control system running over an RS-232 line. Using a protocol that they designed that has no checksums, no framing, no resynchronization. And, a 286 running Microport is just not fast enough to handle two 9600 baud streams of data simultaneously and it starts dropping characters. Drop a few characters out of this unframed, unchecksummed data stream and it starts getting fan speed values (or whatever) mixed up with its temperature values and the control software thinks that the machines is melting down and turns it off - fast.

Our hardware guys were not stupid. They just weren't familiar with communications protocols, didn't bother to consult with the folks on the software side who were, and it had always worked in the lab and the field. I'm quite certain there are any number of pieces of software and hardware running around out there that would be very vulnerable to an unexpected change in the environment and the cascading effects would be incalculable.

Even if you do have safety protocols and interlocks in place, just shutting things down has costs. If you shut down a nuclear power plant, how much does it cost to bring it back on line? If you shut down a factory floor, how much does it cost you to not be producing, how much product will be spoiled and how much clean up will you have to do?

The risks are non-trivial and people believe that there networks are secure when in reality, someone probably installed a wireless access point somewhere or has a router bridging things (so that managers can look at "view only" data as one poster mentioned above) that just opens everything up.

My experience

[pionzypher]

Our SCADA systems were located on an isolated network. Recently though the company has been moving in the same direction (top floor -> shop floor). The key for us has been that those components that are accessible from the corporate side are view only. Control of critical systems should ALWAYS be on an isolated network, whatever the plant super or whoever else thinks. If a suit feels like changing some part of the process, they should have to walk their happy asses down and change it on the floor system. That gives the operators a chance to bitch at him for making unnecessary changes anyway. ;)

Re:Large scale SCADA often uses the internet

[ZorinLynx]

Lots of things in life "should" be, but often aren't.

Such is laziness.

Re:NT4 On The Plant Floor

[Nimey]

The source is open, so you can hire a programmer to maintain the software. Not necessarily so with commercial s/w, especially if the vendor doesn't want to support your version any longer.