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?"
Actually, a lot of them: http://en.wikipedia.org/wiki/OLE_for_process_contr ol is a widely used protocol.
I know of many, many plant floor locations at some very large manufacturing facilities that still run NT4 on various devices. MS will release patches for these too, but only under quite special contracts.
It's kinda scary, really.
Yes, Frontline did a show about this a few years back.
I worked in Big Oil & PetroChem for 20+ years and confirm.
You'd have to have physical access to the control network and physical security is tighter than ever, at least here on the Gulf coast.
I work in a facility that produces a hazardous chemical and our systems are only firewalled from each other. HMI/SCADA Net ---- Firewall_1 ---- Business Network ---- Firewall_2 ---- Internet. I asked when I was hired if they had done penetration testing. They looked confused at first and then said "Don't worry about it..." I hope this is not standard in the industry... At least we have a physical emergency stop button...
I have worked in two industries: electric power (both hydro and nuclear) and communication satellites.
Technologies are similar to those used in consumer systems for a purely practical reason, there's cheap hardware available. But the safeguards built into any industrial system are totally unbelievable for anyone used to consumer systems, and possibly also for people in banking or other businesses.
I once counted the redundancy levels in a transformer protection system. There were 63 (yes, sixty three) different levels of protection for a humble transformer costing a mere $5 million. Imagine the protection around a $5 billion power plant.
Possible in theory, but in real life it's more likely that you would be able to drop a helicopter by ramping a car up a toll booth.
and at some point they're all connected to an outside connection.
Every customer my company has has a main site and a backup site. With redundancy in the main site as well (hot and standby servers, sans, etc). But most have remote clients that can connect to view data (corporate users) however maybe only 1 in 50 are actually tied in to the corporate domain. they're usually separate systems.
As far as the industry I've seen this in, oil & gas, as well as the water and waste water systems for a lot of medium size cities in north america. They also have a slew of international customers as well and the designs are pretty universal. How easy is it to break in and damage stuff? The software and protocols are all proprietary, and in fact most of the packets show up as "malformed" in wireshark. My guess is to really do damage they'd have to either be intimately familiar with the product (i.e. an ex-employee) or they'd have to find a way to take down the main site and backup site completely at once. These are always in geographically different locations.
In addition to that, the means of getting access the corporate intranet (talking Big Oil here) usually require two factor authentication (a RSA token type setup).
Unless there are unpatched vulnerabilities in the login system or vpn gateway, I'd reckon the chance of joe-cracker getting in that far are pretty slim.
That said, a disenfranchised employee with login credentials would be a possible risk.
I'm also in Oil and accounts are disabled about when an employee leaves from their final day (or is escorted out if fired). Also, most of these people don't have remote access ability on their accounts. The systems run firewalls, the SCADA networks are either air-gap from the main corp nets or if they are not as critical they are firewalled so that only certain machines can get there from here. Not to say they can't be cracked, but there are a hell of a lot of softer targets to go after.
Even smaller systems will often have web interfaces and mechanisms to send alerts via email etc as a way to call out supervisors/engineers/service personnel at night and allow them to fix stuff remotely without having to come in to the plant or make a flight etc..
Engineering is the art of compromise.
Just thought I might share, in regards to SCADA on Linux. Open Systems International, Inc. has a very nice SCADA system (aimed largely at electrical utilities but it can work for other SCADA applications) which is aimed at being as platform-agnostic as possible. Their software currently runs on AIX, HP-UX, Windows, and Linux as well as some others. This is done through platform-specific compiles of the software packages, but the software itself is the same across platforms, with the same APIs and interfaces and database formats, and is interchangable or can be used mixed-OS.
They also make a Remote Terminal Unit (RTU, a very common device in the electrical industry; it's the little computer that reads all the equipment at a substation and transmits it back to the utility) called OSIRIS, which is a Linux-based embedded device.
There's definitely Linux in the SCADA industry; it just doesn't get a lot of press.
Well, unless it's some proprietary VPN protocol, you could just use a different client program that wasn't as strict about not letting you do things like bridge it. As long as you have the key, there's not a whole lot to stop you.
But I think what the GP was getting at was the risk of somebody having a workstation in the plant, somewhere, that's connected to both networks. If you have two NICs, and have the process-control network plugged into one, and the regular internet-accessible LAN plugged into the other, it's trivial to "accidentally" bridge them together.
Alternately, they could both just get plugged into one router or switch, and suddenly there's a path between them. A lot of weird things could happen if the two networks run alongside each other and there's not constant vigilance to keep people from doing something stupid.
In my office, we have separate subnets for different work areas. It works pretty well in terms of minimizing broadcast traffic and keeping people from accidentally printing to printers at the other end of the office, etc. But every few months they'll end up getting accidentally bridged by someone in a conference room plugging a wire from each subnet (they have separate jacks in the conference rooms, so that people can access their own area's stuff) into a switch. There's not really any malice involved -- people just see an Ethernet cable running from the wall towards a switch and notice it's unplugged, and they have a tendency to just jam it right in there.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Normally you would have a control network (which includes control devices and HMI workstations) phisically isolated from the rest of your corporate LAN or intranet. If you have a process which is distributed over a wide area, you ideally will have dedicated links; if that is not possible, you would use VPNs to link the control networks using the untrusted corporate network.
Then you have the problem of management wanting to view in real time your process data. The scheme to protect your process will depend on the tools your HMI manufacturer has to put this information avaiable to others in your company. Many vendors provide industrial database servers and web servers for process visualization. One possible approach would be setting such servers on a DMZ between your control network and corporate intranet, and you would make sure only these servers can access data (in read only mode) from the control network. Additionally, you could have extra requirements to access these servers from the corportate network, so only designated people will have access to them.
I to read the Forbes article, but I can approach it from a unique view point.
... now they must become "ethernet enabled". Why ? Because they want to know what's coming off the assembly line, right now!
:-) why ? Cause that's all the poor little device's moto entry level Mac Classic CPU and handle while still running it's production process logic.
:-) . These companies can't totally blame there Control Process Engineers. Those guys know their control gear, not network security. They really need people whom have their feet planted firmly in both worlds.
For the past 5 years I have been doing research work on SCADA or control system security.
Some of the research findings are astounding. No one can die if a hacker port scans a printer and ruins your print job, but people can die if a hacker port scans some SCADA devices and knocks them offline.
Here's why;
Back in the good-old-days most of the SCADA/Control system networks were isolated, proprietary, and in general a real pain in the ass to get to let alone do anything with. With the Internet explosion, along comes a push from the Marketing departments, and management to integrate all system. The old days everything was serial
Law of supply and demand; customers demanded it, equipment vendors tried to supply it. Note; tried. Think about it people, you have equipment manufactures that have been living in there own little world for 30-40 years, now being asked to hook up to standard office style infrastructure, integrate and play well with others. Unfortunately, most equipment manufactures simply took their serial protocols from their proprietary network, wrapped the data frames up in TCP and called it an afternoon.
Serial style protocols with little to no authentication, traveling over a wire and hitting a device with as cheap an ethernet to serial converter as money can buy.
Yes folks there's nothing like doing a security audit and knowing you could launch a DoS attack on you clients network with a 9600 kbps modem
Companies/SCADA equipment users themselves are also to blame for the security shambles that SCADA/Control network. Along with in "integration push", came this novel thing called the web. And wouldn't it be nice to use a web-browser to check you production devices status, and control it? Problem being, this production device was design and manufactured before the web craze took off.
Side Note: One of the biggest differences between SCADA/Industrial networks and the office/admin style networks; Average equipment life in the SCADA network can easily be 15-20 years.
Try squeezing an embedded webserver onto a piece of equipment from the late 80's. Not much memory, storage, or processing power to play with. Somethings got to go; might as well be those pesky extra checks on the network data coming in
If you thought that the vulnerability window between Microsoft-bug fix and application of the patch was bad; at least it can now be measured in days, or months. In the SCADA environment, I've seen and heard deployment and fix estimates of several years.
Fortunately; a large number of the major SCADA equipment vendors have woken up and smelled the coffee.
Within the last 2 years, there's been an explosion of interest in actually fixing the problem,
in conclusion;
Is it as bad as Forbes makes it out to be ?
In some areas, it's better, in others, far worse.
Cheers
Yogi
See the article http://www.computerwire.com/industries/research/?p id=9681B83E-A348-42A5-9DA5-BEF13EE1A835 -- they maintain SCADA systems that may originally have been on a separate physical network have slowly bled connectivity to corporate networks and are now open to those who compromise those networks.
They also describe a Hewlett-Packard/SenSage software package to monitor in real time and also archive network events on SCADA networks -- allowing for real time alerts of ongoing crimes, or at least an archive of all activity related to external or insider bad activity. Historical analysis at all network levels (physical, computer, server process levels) is very important -- without it you can't find the perps or track how they compromised your network.