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?"
Being able to blow up physical devices is a lot more spectacular than playing with numbers in bank accounts which can be resotred from backups.
Engineering is the art of compromise.
So it must be secure.
How we know is more important than what we know.
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.
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, SCADA systems are vulnerable to attack. Yes, they use old technology and rely on obscurity to keep them safe. Yes, theyre - to a large extent - hooked up in various fashions to the internet. Yes, you can cause big machines to do bad things this way that cause them to screw themselves up physically or hurt people nearby. The more interesting question here is why no one has seen (or at least admitted to have seen) an actual attack.
Imagine what would happen if the safety systems at a -insert toxic inhalation hazard here- facility in a major metropolitan area were disabled? Who needs to even enter the United States to cause destruction... Homeland Security is so worried about people getting physical access to these facilities that they going to miss this attack method.
I'll answer though ... Just hide away until after Armageddon is over, I'll find you.. don't worry... really, just wait til I say it's safe to come out.
waiting for ad.doubleclick.net
Generally, SCADA systems are not trusted. All systems have failsafe hardwired I/O that is designed to shutdown on failure. Unfortunately, the shutdowns can cost money.
I just got through getting a cell working after an extensive blast of repetitive downtime. I never did work out what exactly caused the failure, however high on my list of suspects is a router that may have been dropping packets due to excessive network load. When the router shutdown, the PLCs shutdown too. I'm just not clear on what caused all the excessive error packets on the network ... I have lots of theories, but no evidence.
These SCADA networks are designed to be operated in a fairly secure environment. They can't withstand errors or high network load. Botnet attacks, virus outbreaks, or someone hacking in can cause trouble. However, mostly I worry about much more mundane causes of downtime.
Microsoft Windows updates, particularly XP SP2, are notorious causes of SCADA system problems. Automatic installation of anti-virus software that triggers system reboots causes system to shutdown unexpectedly. Employees installing CPU-intensive screen-savers also cause headaches. Unexpected system changes result in unexpected system shutdowns. These unexpected shutdowns are what cause the economic disruptions.
Personally, I wonder how much longer we can deploy Microsoft Windows as a SCADA platform. Fast, simple and straightforward are key system goals for SCADA applications. Vista, which effectively requires networking, is a step in the wrong direction. Linux is much more secure, and can easily be set up with read-only partitions. Read-only memory seems to make the systems much more stable, as every reboot always reloads a secure, known-correct program image.
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.
I happen to be a developer who is working to protect SCADA systems.
Because the systems are what they are, we are protecting them by putting protective devices in front of them -- either sitting behind a device on the phone line or sitting behind a protective router. Then, the lack of security in SCADA devices will be largely irrelevant, since you can't hack a device you can't access. It would be a matter of hacking into our devices, which are designed with a bit more security in mind.
I dread the idea of seeing our company name showing up in some hacker conference, but I'm kinda eager for some black-hat-vs-white-hat action.
Many SCADA system run on Windows, while some older DCS (distributed control system) run on UNIX or QNX. National Instruments have a version that runs on linux. There is also automationx.ca that supposedly have a SCADA system that runs on Linux. None of the other popular choice; Rockwell, Siemens, GE, Omron have a HMI that runs on Linux or other os that windows. If something ever comes to Linux it will most likely be from Siemens, as they are German and more open to SUSE. Regardless the windows part on a SCADA system is the supervisory and data acquisition, the actual control is normally done by a PLC. Someone can hack the PC-HMI and change the control setpoint, (ie start water pump No 1 when level is at 45m instead of 44m) safe operational upper and lower limits can be hard coded into the PLC (including interlocks) this filters out a lot of hackers since they need to get into the PLC.
GG PENG (Electrical and Computer)
They're safe as long as they are isolated from public networks. The problem is that there is a huge temptation to use the Internet to enable remote monitoring and control, as it is much cheaper and simpler than extending a private network and installing dedicated workstations at remote locations. Many managers will ignore security concerns when they see an opportunity for large cost savings.
Mea navis aericumbens anguillis abundat
Funny, I've been testing this stuff for the last 28 years. Well, perhaps I'm a no-one. Anyhow, since no one has been able to get into any of my systems yet, the score is still 1x0
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.
Look at the posts above me, has it happened yet? Has some basement dwelling fuckwit suffering from assburgers syndrome scrawled out some idiotic post about how "Its not hacker its cracker" yet? Because you know someone will.
the big beer company in St Louis ?
I sat down to write a new sig tonight and all I did was make the chair warm.
63 levels of protection doesn't give me more assurance sorry.
But since your mentioned the plant hires Transformers for protection or something, I do believe these alien robots could stand some chance.
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
In order to cause any damage, a cracker would need expertise in fields from IRIG-B time codes to Buchholz relays. If you know that much, you'll get so many million$$$ working legally that you won't bother to do any cracking.
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...)
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.
> I know of many, many plant floor locations at some very large manufacturing facilities that still run NT4 on various devices.
We're running DOS here. Yes, DOS. Version 6.3, I think... I haven't really bothered to check.
It does make them hard to hack (or access...) remotely, though.
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.
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. ;)
I'll believe in corporations having personhood when Texas executes one... - advocate_one
I know of several sites worldwide that use even older OS's. I have seen and worked with iRMX systems running or monitoring power generation facilities, oil/gas, transportion, water distribution, etc. The latest versions of iRMX support telnet and ftp so it is possible to remotely access these computers. However, I image the number of virii is virtually nil and like some others have mentioned, SCADA networks are usually disconnected from the rest of the Internet. I haven't personally seen one that is. Plus the OS is pretty rock solid, especially when using well tested and debugged (read: old) software. As a side note, I couldn't get FileZilla to work with the iRMX ftp server because it didn't understand the logical file attachments (like :home: or :c: or whatever)
I was h4x0rng dis baddass systim... got in through an unpublished vulnerability, and using escalation techniques... I was able to gain access to the
rot account. Once you gets rot access... dey are p0wnD.
It takes five minutes to hack a seriously secured system, you compromise one of the insiders with a kidnapped relative and give em a ring on their cellphone. If you are talking state sponsored (or dedicated radical org or whatever) asymmetrical warfare, this is how it will happen, and simultaneously, in a lot of places all at or near the same time, along with line and node sabotage, physical sabotage. Not all the targets will crack with the blackmail extortion attempt, but enough of them will. If the other guys want you to go down badly enough, you most likely will. The only way to even think about beating that is for you and your extended family to all live completely on site at your place of employment behind huge walls with armed guards 24/7/365. You have to airgap *your whole family* to beat that attack. Gonna do it? Does any corp do that yet?
I'm sure you guys thought of that one, and you know it would be pretty effective. Pretty simple warfare "force multiplier" 101 stuff I would think. The dotgov does it on a small scale with embassies and milbases, but trying to get to that level of protection for an entire nation and all the critical infrastructure just ain't happenin anytime soon.
As to 911 and boxcutters, I really doubt it. Looked a lot like target drone jinking in the vids, ie, remote controlled. And that pentagon crap, no giant wing marks on the walls..bzzt..gov explanation is bogus, fullstop. they ain't changing physics here. Even if they folded up and vaporized on impact, you'd see some marks on the walls, and there ain't any. Think again who got fooled and why. Think "who profits" for any crime.
With Microsoft's "security", you only need a user account name to deny use of a user's system.
3 failed log in attempts lock out the legitimate user, even if the account is presently logged in!
Say, your buddy is working under a certain user name, try that name 3 times with the wrong password and his account will lock, outlook goes nuts.
Outlook then asks for a password because the mail server (Exchange) denies SMTP access, the user tires to reboot to "fix it" and cannot log in till his account is reset. This is only funny till someone uses scripts to lock out about 500+ accounts, the Admin will be busy......
And you never "really" get access.....
LOL
I am the unwilling control for my Origin.
http://www.iss.net/solutions/regulatory_complian ce/scada_programs.html
warning: marketing speech ahead..!!
Solution Packages for SCADA Security Compliance
SCADA Quick Start Program
The ISS SCADA Quick Start Program results in a thorough understanding of best security practices for your organization, and the development of detailed project plans for meeting the requirements.
Moderators:
Members of ISS X-Force Professional Services; A worldwide, elite team of security professionals, specializing in ISS adaptive network security tools and methodologies, as well as distributed computing system and network security.
Benefits to Participants:
* Access to industry-leading knowledge about best security practices for SCADA systems, and risk assessment methodologies, based upon research by the ISS X-Force Intelligence team; ISS' leading group of over 40 security experts, dedicated to proactive counter-intelligence, research, development and public education against online threats.
* Rapid availability of customized implementation documentation that organizations can begin to use immediately, including a tailored project charter document, SCADA compliance road map and detailed project plan for implementing SCADA Security Standards in their organizations.
* Save months of research time by utilizing security experts who have market leading risk management and industry-best practices expertise.
Program Details:
* 2 Days of Training - SCADA Security Standards and Introduction to Security Management
* 2 Day SCADA Strategy Workshop
* 1 Day Risk Assessment Consultation
* Free 60-day trial of the ISS X-Force Threat Analysis Service
* Free Technology Best Practices Configuration Guide
The key word there is informed. Your average script-kiddie or nationally sponsored hacker may be able to break in, but unless they know the system they're hacking and how to control it, they're next-to-useless in doing any damage. The biggest threat will come from someone inside the company who knows the systems and how to insert malicious codes into them. They won't need remote access because they can load that code from the terminal.
My Sysadmin Blog
im in ur power plant retractin ur control rods
SCADA systems are incredibly vulnerable. Anyone who "Calls Bullshit" or whatever else they'd like to say just doesn't know what they're talking about. SCADA systems _have_ been compromised. Comrpromising them is _easy_ if you can get access to the network, as 99% of the protocols are clear text, snoop the wire for a while to decode the protocol, then do some simple replays to take control. Or easier yet, just take control of the HMI. If you do it right no one will even know.
Or too impatient for that? Try attacking one of the wireless SCADA networks, yes, critical infrastructure like gas pipelines running over "wireless."
So far the biggest thing that has kept them secure is people in the mainstream hacking community simply haven't known they exist. But that's changed. Keeping SCADA systems seperate from "Corporate" systems isn't easy for most utilities as they simply don't have the money to invest in dual infrastructure, or they don't know what they're doing so don't, or management (as usual) as full of nitwits so wont trump up the cash...
DHS has a Control Systems Cyber Security program which may have interesting reading for the curious, also see INL labs which do a lot of work on hacking SCADA systems, and NIST has some big put-you-to-sleep style doco on standards around SCADA security.
Cheers
e
The long story short is that most of these installations are physically protected from intrusion. First rate firewalling, and in most cases, complete seperation of internet and operations systems are in place. Physical alarms and access controls, id badges, and real security guards do the rest.
.)
I am not naive enough to suggest that any such situation is 100% perfect, but at the very least, we are not talking about script kiddies. If someone has a real reason or agenda to break into these systems, and enough money and skillful crackers, they will get in.
For example, WiFi ethernet networks are almost never used in these types of systems -- that doesn't have the engineering necessary for this kind of data. Instead, proprietary solutions with microwave dishes, and other forms of FCC/CRTC licensed data radios are used. While proprietary != secure, it does mean that a wardriver looking for an open access point isn't equiped to mess with these systems.
Furthermore, scada systems have some intelligence on the terminal ends: hard wired or epromed/flashed programs running that usually have safety cutouts that prevent the hardware from doing something bad by dropping into a safe state.
I won't go on boring everyone with the details, but what it comes down to is that the systems are sufficiently complex that it is cheaper, easier, and more effective to physically disrupt them, so there is not much point hacking or cracking them.
In any case, in the automation world, this was news about 2 months ago, and taken into account in plant operations (mostly by noticing that the physical security and networking configurations prevent the attacks from the outside to begin with) without the kind of panic that Forbes is trying to fob out the unsuspecting C.O's (thats a regex
More Caffeine. NOW
The right way: As simple as will get the job done. Its been used on the space shuttle since the beginning. When you hear the three computers agree, this is three 1802, a 1MHz 8-banger that was approved for this 30 years ago. The other "certified perfect" piece of hardware is the i486. Sure a few more may have been added, but nothing 'hi-tech'.
What kind of line speed does it take to say, control the dijkes. This is not the place to say _exactly_ how its done, but I'm not afraid of a break. Trains are the other extreme, you need a real computer. The embedded boxes that take the measurements are simple in design, a PIC or 1802, a world favourite in payphones.
Going on the net can't be all that bad, but as one writer noted, thoughtlessly designed systems lock out the rightful user. Of course, never run ssh on port 22 and if life is on the line, a telephone backup must be used. "Fuzzing" is over rated, sure it crashes poorly designed systems, but well designed systems would have to be flooded quite fast to prevent a 'distress signal'. (Upstream the networks are well monitored.) I will always remember the first security lesson from a German professor: Rule No.1 NO Microsoft products!
My biggest fear is the possibility (actually quite easy) of spoofing an IP of a rightful owner. These addresses must either be secrets or rotated often, preferably both. Still a dedicated network, where management can only look and then pick up the phone is almost mandatory if human life is at stake. True fast hopping radio can be most secure, stealth and 'unjamable'. Fibre is secure too.
It is rather remarkable with this publicly known for years and even popular music (figure out that yourself) telling how to do it, it hasn't been a problem. Broadcast and cable is totally vulnerable, though breaches rarely occur. It is rather commonplace to control a TV sender through a DTMF telephone: Would you know what to do if you got in? In a real war, things could go from bad to worse. Social engineering would be a primary tool. (Could anything be easier to social engineer than the military?) Loose lips do bad things. Its all about logic to do it right. Its scary to see sysadmins use Windows for stupid reasons like: "It works best on my laptop". Then don't use it for anything else!
It is so often when doing a security audit, you hear: "I let my kids play games and surf the web". On company computers that do important things. Damn. Don't use Windows and keep your computer to yourself.
BillSF
Most automation systems have a PLC controlling the hardware. The SCADA is just the UI to the control system.
A PLC is a (generally) unprotected, unencrypted proprietary ethernet connected box. The only protection is that it is proprietary, but that protection has been diminished now that most are connected to Ethernet.
The interlocks etc that people are talking about above often actually reside in the PLC. You don't need a password to manipulate the memory in a PLC. Just a write command using the standard protocol for the PLC will do it.
SCADA PLC Hardware
The major manufacturers have not bothered to protect access to their PLC's, and with the recent Ethernet revolution in control systems, this makes them very vulnerable.
The majority of control systems I have seen are completely unprotected once you get onto the LAN. Unfortunately there is an attitude that it will never happen to us.
I have no experience in big oil or in power stations, but I have seen this problem in some airport operations, and industrial automation in general.
Hardened automation devices are just not demanded of PLC manufacturers by their customers, as they are not aware of the risks.
Disclaimer: I've been out of the industry for a couple of years, but the industry is very slow moving, so I doubt much has changed.
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
Sorry to disappoint you, but it's not FUD, just after the facts. I have been providing the security knowledge behind securing one of the biggest companies that was exposed, and they then started to drive SCADA security globally (the person talking the most about it is an engineer himself, just wasn't that clued up on security then :-).
/fallback/. The normal operating platforms sitting above that layer are either Unix based or Windows. It took several months of talks and testing to allow virus checking and TIMELY patching onto those platforms. I can understand that, these systems tend not to be allowed downtime so anything you roll out on a global basis has to be examined very carefully - the profit margins allow for that, but -more importantly- the code is part of a facility where liability charges very much apply. In that context the choice for Windows must have given some people headaches..
First, it is 100% true that the backup mechanisms typically don't use IP yet for connectivity, but look at the trend. I would personally advise anyone to avoid IP in failsafe, but -as with the use of Windows- it takes but one idiot not quite awake and you have a problem.
Secondly, that is
Thirdly, this wouldn't have been a huge problem if some, ahem, "less inspired" people hadn't hooked up SCADA platforms to the global corporate LAN. Yes - I kid you not, from a shack in Bogota you could mess with a plant in the US. One virus in Japan would be ignored by corporate systems but could go and make a mess of some operation in Alaska that couldn't patch as it needed compliance, and not all SCADA systems live at a place where you can get to without some hiking..
If you combine the "we want anti-virus somehow" with "you friggin' well install a firewall ASAP" and look at the volume required for a global company, you can't go with 100% perfect solutions, especially if you don't have the staff to manage such a beast. Voila - you have just discovered how the Symantec boxes came to be. Perfect? No, I don't like someone remoting onto my network into critical devicex, but you either get some monitoring up or fly totally blind, and adding virus scanning to the network filtering kept a middle route between leaving the compliant systems alone and still protect them from virus and trojan infections. This SQL virus (forgot the name) brought that home pretty clearly.
So, in summary, Forbes wasn't entirely talking out of the wrong orifice (makes a change), it's just not really news (we did this 4..5 years ago). Must be a slow month.
Insert
What I found particularly impressive is that some SCADA devices can be killed with one single packet. Just one (1, uno). And it gets killed in such a way that it:
..
(a) end up in an indeterminate position (i.e. you don't know HOW it's going to fail, only that it will)
(b) is non-recoverable, i.e. it's not just a matter resetting the thing, you have to rebuild it from the ground up.
Shocking stuff. And this kit controls our plants, sewage facilities, oil platforms, power stations
Insert
There MUST be NO network connectivity between the production systems and the Internet. If you really NEED a gateway, put a wetware firewall, reading off one screen, typing on a keyboard attached to the other. Then apply physical protection of the internal network. Employees inside might have a network access, say, on laptops with wireless, but the production network should be totally isolated.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Your own employees! You're right of course, that the networks should be separate. However, a real danger of connecting your process control sytems to the 'office' intra/internet is that you:
1. Immediately introduce an extra dimesion of complexity in support and debug. A NIC goes nuts in accounts? Someone connects some unauthorised hardware? Someone decides to repatch in the cable cabinet? Bang goes your process, (sometimes literally 'bang')
2. Open the door to the exec. who - in trying to show-off the 'transparent factory' process reporting and control, manages to open the dump valve on a large tank full of dangerous chemicals. "Look, this dial is moving...that's in reeeal time, folks"! Urh, what's that siren? True story. Fortunately the containment wall did its job for once. The tech was sacked, since he 'should have better-protected access to that function', (which is true, tho' as always, the Exec had demanded 'full access'...)
So yeah, lock it off TIGHT
"In January of 2003, SCADA system computers infected with the Slammer worm caused a blackout at the Davis-Besse power plant in Ohio", Forbes
'The Slammer worm penetrated a private computer network at Ohio's Davis-Besse nuclear power plant in January and disabled a safety monitoring system for nearly five hours '
"Seven months later, another computer virus was widely suspected of preventing the detection of power loss at a plant providing electricity to parts of New York State", Forbes
'TRANSCRIPTS of telephone conversations between utility operators prior to last month's power blackout in the US and Canada '
"Seven months later, another computer virus was widely suspected by security researchers of leading to a power loss at a plant providing electricity to parts of New York State, despite the Nuclear Regulatory Commission's argument that no evidence of virus-involvement was found"
'The task force responsible for investigating the cause of the Aug. 14 blackout that crippled most of the Northeast corridor of the U.S. and parts of Canada concluded that a software failure at FirstEnergy Corp. may have contributed significantly to the outage'
'On the day of the blackout, Blaster degraded the performance of several communications lines linking key data centers used by utility companies to manage the power grid, the sources confirmed'
davecb5620@gmail.com
"For example we deal with ship control systems, which you may think are about as isolated as you can get"
... please pause the war while we coldboot the warship and a lot of boxes running mutually interlocking RPC calls can't be that isolated.
Hopfully not this one
was: Re:My view..
davecb5620@gmail.com
'Facilities maintenance decided to place a web cam on top of the building so anyone could "check the weather."'
..
"I was able to access everything from heating/cooling, water, lighting and the factory waste handling system controls"
..
..
Fair enough
Good Grief
"The system ran a very stripped down Linux kernel and only had a few applications but I was able to add or remove or edit files from any directory on the system. So basically, the webcam username/password was effectively root on the whole system"
Ah, its that communist, hobbyist, hacker tool of the Taliban and Lintards everywhere
"apparently their setup was hard coded to only accept the one username and password for the whole system! At least that's what we were told at our meeting"
So, appariently, you could control heating/cooling, water, lighting and waste handling from a webcam applet, the entire plant only ran on a stripped down Linux kernel and no one could figure out how to add new users.
Also a webcams control applet resides in the camera itself, so to access 'everything' there would have to be another webserver somewhere, unless they were running the entire plant from the webcam on the roof. And also the username/password for the camera resides - in the self same camera. Why would you need the same username/password 'hard-coded' elsewhere. Please explain. Finally tell us the name of this plant and who supplied the equipment. You can tell us, we can keep a secret.
was: Re:Large scale SCADA often uses the internet
davecb5620@gmail.com
I spent a brief period developing HMI boxes for controlling big metal-processing machines. Our customers liked to keep the control systems as tightly coupled to the machinery as possible and would get very nervous at even the *suggestion* of some kind of remoting. These big machines emit a good bit of EM-interference which could have a significant impact on communications equipment, not to mention the fact that they really didnt like the idea of someone operating the machine not being in front of it.
...
In the end we were able to persuade them to go with a limited remote terminal based on a CAN network. Their initial safety concerns were allayed when we told them its the same networking protocol that controls the Brakes in their Mercs
Now, that was just about acceptable, but to even have these machines with the *capability* of being controlled over the ethernet, (perhaps) and then HTTP across the www is tantamount to irresponsibility. It would be a slip-up on the part of everyone in the development chain: Engineers, Buyers, Managers, and even the Operators if they know about it!
"... always going forward 'cause we cant find reverse! "
"NT4 was a nice operating system for SCADA applications. It was built in a time where Microsoft cared about security"
NT security rating only applied to a stand-alone version on specific hardware and no network support.
'Because of Davis-Besse's widespread use of vulnerable Microsoft software, the worm jumped to the plant network and crashed the Safety Parameter Display System, keeping it offline for eight hours," Paller testified'
was: Re:NT4 On The Plant Floor
davecb5620@gmail.com
when will people learn - perimeter security is necessary but NOT sufficient. the slightest chink in the armor and the entire thing is vulnerable.
I agree that for larger systems you would have this redundancy, but I believe the opposite is true for most operations. The very lack of redundancy is the reason facilities continue to use legacy equipment and refuse to patch it out. I don't know how many patches I've had to back out of our test environments because they simply broke one of our fragile SCADA units. Lastly, the life of these systems is much longer than a normal business PC. When we do our build-outs we assume a ten year minimum life for the software and hardware, thus security protocols simply become obsolete at the workstation. For these reasons, we always separate the business and process networks. The only place they can possibly cross over is through the use of pHistorian that communicates with our SQL Server for data retention and analysis. -Kurt
I was in this business for awhile and my PHB wanted something installed that did exactly what the article described. Fortunately, the technology didn't exist then. Was this in Central California by any chance?
Yes, this is a very very real problem.
Not because of the SCADA systems, per se, but because of the incompetence of those installing and using them.
I sell SCADA systems. They are a very small part of my business but, since I see the "guts" (controls and instrumentation) of many many plants - I can definitively tell you this is a real issue and it needs to be addressed. Control systems for plants are not nearly secure as I would have thought 2-3 years ago. Instead of getting better, the problem is actually getting worse. Again...not because of the tools, but because of the people using/installing them. With respect to "computer systems", there is so little expertise in security at the plants, that it becomes dangerous. This thread has countless examples of that and I could add about 20-30 more that would make you shudder.
I used to think it would be difficult to "hack a plant" because most of the plant controls utilize a 4-20ma signal for controlling their instruments (valves, pumps, transmitters, etc). Sooo...unless you were a master of hacking PLC's and 4-20ma signals (for which you need a special modem), there wasn't much risk. SCADA is the missing link. SCADA systems speak both PC Computer (TCP/IP, modbus, etc) as well as 4-20ma signaling. If you root a SCADA box, you root all of the controls and loops attached to that unit. Scary stuff. And the plants, for the most part, don't even realize this is the case. They WAY underestimate the risk.
can't post my real name. It should be obvious why.
LOL, I love how everyone thinks they kick ass at designing security.
I work in the security field too and I know it's incredibly damn near impossible to make something truly secure.
Trust me, your stuff is weak and poorly designed.
I'm a longtime SCADA system engineer,
Here a few security best practices and obvious thoughts.
* If you use Ethernet, isolate the network. Many PLC's flat out can't function under high loading on a 100Mbit network, and the security concerns are obvious.
* SCADA stands for Supervisory Control And Data Acquistion. That means that you never rely on SCADA for a emergency stop. Any machine that has any potential danger to life or limb has physical fail safes, and you never have a control that can only be done in SCADA. If your plant isn't safe or functional with the SCADA turned off, you don't have a SCADA system; you have a PC/Windows based PLC and you deserve the problems that will result.
* Protect your PLC's from both physical and network tampering. Many new PLC's support some form of remote programming. Turn that off. Make sure your PLC housing is physically secure, and alarmed when opened. Don't leave the auto/manual and/or local/remote mode key in the PLC. Alarm when a PLC goes into manual or local.
In 95% of the SCADA network's I've worked on or installed the only two possible attacks were data theft (You've stolen my Boiler pressure!), and denial of service. Denial of service is addressed above, data theft is always a risk but the cost of that risk varies greatly.
is there a data historian in your SCADA system? Does it use some type of master-slave setup to replicate data into the corporate environment so that the bean counters can verify efficiency, production, or whatever metric they want to look at? Do you have RTUs or PLCs with unsecured dial in access? Is there wifi on the plant floor? Does your HMI use a web based help system?
Fly Fish? Participate in our forum
LOL
Actually, I know some weaknesses, and we are working to improve the security.
We've already had two security evaluations from independent sources, and we have Idaho National Labs and another third party analyzing it for weaknesses, too.
We don't assume we're perfect, and we're more than willing to continue improving the security and learning what we need to as time goes on.
I've had some fights along the way (it's amazing how easy it is for people to slip into believing in security through obscurity, even those who should know better), but the fact is, real security has won all but one of them. And that last one? It will be obviated in the very near future, anyway.
Unfortunately, I'm not a security expert, but the burden falls on me... Applied Cryptography is my Bible, and Schneier's monthly newsletter is required reading.
I work for a government lab that tests this very type of thing, performing in house assessments on SCADA systems, in plant assessments and we play with what if scenarios, and all I can add knowing what I know and having seen what I have seen is that it is a miracle that there has not been a major SCADA cyber event.
Fly Fish? Participate in our forum
And for those of you who are curious, no, it doesn't run on Linux. All of the control systems are Windows based and run on Server 2003 Standard. I'm 99% certain it comes from either Honeywell or Siemens.
Also, while I'm here, I'd like to point out that the NERC CIP standards, which are being mandated for power companies in the very near future, are intended to address many of these issues that have been brought up. The industry hasn't been sleeping, and with FERC taking over the standard and having audit and penalty authority, all NERC members are beginning to take security seriously. Chances are, if you're reading this in the continental USA or Canada, your power is being supplied by a NERC member.
NERC CIP standards: http://www.nerc.com/~filez/cip.html
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.
Kind of bogus really - a person can hack field devices that run using widely published standard protocols which have been in use since the 1970's. And that's news. Maybe to the idiot who wrote the article.
Why would anyone want to spoof a SCADA system when they could just take a pair of wire cutters and destroy the equipment? A person could just use their pickup truck to destroy every piece of electronic equipment they see while driving in the country. Some of those are SCADA devices.
The "man in the white pickup truck" is the nightmare scenario for any SCADA system...
"that caused the database to overflow and crash all LAN consoles and miniature remote terminal units
davecb5620@gmail.com