Slashdot Mirror
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?"
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.
I do not respond to cowards. Especially anonymous ones.
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.
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.)
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)
--- For a good time mail uce@ftc.gov
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.
Lots of things in life "should" be, but often aren't.
Such is laziness.