Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SCADA Systems a Target for Hackers?

CowboyNeal posted about 7 years ago | from the isn't-everything-already dept.

Security 189

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?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Hacking SCADA makes sense (3, Funny)

EmbeddedJanitor (597831) | about 7 years ago | (#20338771)

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.

Re:Hacking SCADA makes sense (0)

Anonymous Coward | about 7 years ago | (#20338825)

How many manufacturing plants have automated systems with PC boards running XP and managed by a 2003 domain controller? What are the odds that it isn't hooked up to the internet? Probably not a lot.

Large scale SCADA often uses the internet (2, Informative)

EmbeddedJanitor (597831) | about 7 years ago | (#20339423)

Sure, many small-scale SCADA systems (factory control, building automation etc) will have private networks. Many larger ones (power reticulation, traffic control etc) cover a huge area and will often use internet to hook up remote sensors/actuators.

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

Re:Large scale SCADA often uses the internet (1)

TooMuchToDo (882796) | about 7 years ago | (#20339635)

Anything wide area should be VPNd back to a central concentrator, and should not run over the public internet.

Re:Large scale SCADA often uses the internet (3, Insightful)

ZorinLynx (31751) | about 7 years ago | (#20339709)

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

Such is laziness.

Re:Large scale SCADA often uses the internet (5, Interesting)

tropicdog (811766) | about 7 years ago | (#20340019)

I've got a little story to share, a real world, actually happened example. Just a few years ago I was working as desktop support at a manufacturing plant. Facilities maintenance decided to place a web cam on top of the building so anyone could "check the weather." This was part of some project where environmental status of different parts of the facility was available through an internal website.
Who knows why they thought this was necessary but, they did it anyway without much consultation with the IT department. [red flag #1]
They published their little website where you could check out the air conditioner status and temperature of the various parts of the building and view the webcam. To see the webcam you had to logon with a specific username/password combination which they announced to everybody via email. [red flag #2]
Curious, I checked out the site and looked around. I found that the webcam had a different URL than the rest of the site so, being curious, I shortened the URL down one level at a time and ended up at a system administration logon page. [bad sign #1]
Surely the username/password for the webcam wouldn't work there so I tried it and promptly logged onto the facility controls console. [bad sign #2]
Surely I would only have limited or read only access so I checked out some of the features and areas of the console. I was able to access everything from heating/cooling, water, lighting and the factory waste handling system controls. [very bad sign #3]
Again, surely I had read only access so I tested one of the settings for the air system in our area of the building. I incrimented the value by 1 and clicked "save". It accepted my change. I changed the value back to it's original setting and saved it again. [VERY bad sign #4]
At this point I notified my supervisor that there may be a problem and showed him what I was able to do with the username/password that everybody in the company now had. A hasty meeting was called that day with myself and the head of facility management. I told him what I had found and we had a meeting with the vendor who installed the systems the next day.
In between the meetings, I checked out some more features of the controller system and found that I could ssh into it with the same password and username. 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.
The installer was a typical heating/cooling installer type of guy. [red flag #3]
Computers obviously weren't his area of expertise. I understand that the company has people who "should" know about these sort of security measures, their developers. Why they sent a mechanical type of guy when they were told what our concerns were, I don't know. [red flag #4]
The scary and probably typical reaction I got from the vendor's installer was that there wasn't much of a problem because nobody in the factory would surely think of shortening a URL and find the main systems control login. [big red flag #5]
I finally got my point across and the vendor agreed to work with their developers to figure out a more secure setup. Fortunately the facility manager fully understood the consequences and wouldn't accept the vendors attempts at suggesting that it wasn't an issue.
Most everybody would think that simply changing the password would do the trick but 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. To access the published webcam that was tied into this mess, you had to use the same credentials, otherwise none of this little setup of theirs would work and the administrative console would loose it's ability to monitor and control the factory systems. Brilliant! Absolutely genious.
Well, at the end of it all, apparently their developers had some sort of actual CLUE and were able to change the aforementioned "hard-coded" password to something else and allow a non-root level account to access the webcam.
The threat from the Internet was minimal as any access was forced through VPN but, being on the internal network, the whole facility was vulnerable. And I haven't mentioned so far but the "internal" network could actually have been anybody from company facilities around the globe.
The "Disgruntled employee" was the most likely attacker and fortunately once the vulnerability was pointed out, those in management recognized the threat for what it was and quickly took action.

Re:Hacking SCADA makes sense (1)

A non-mouse Coward (1103675) | about 7 years ago | (#20338887)

Exactly why this has become a major research topic [] at universities.

Re:Hacking SCADA makes sense (3, Interesting)

Svartalf (2997) | about 7 years ago | (#20339379)

Forget manufacturing plants...

What if you could easily reproduce the East Coast Blackout of 2003 at will?

Hacking SCADA systems can do that for you...

Heh... What I could tell people...

It wasn't in Die Hard 4 (0)

QuantumG (50515) | about 7 years ago | (#20338793)

So it must be secure.

Re:It wasn't in Die Hard 4 (1)

jimbug (1119529) | about 7 years ago | (#20339251)

way to ruin the article's credibility in one shot. now what am i going to do for the next 30 minutes until another article gets posted?

Re:It wasn't in Die Hard 4 (0)

Anonymous Coward | about 7 years ago | (#20340781)

Oneok and it's parent companies are too cheap to upgrade and some sites use dial up for their scada instead of vpn connections. I'm guessing a couple of wireless connections also maybe. They use sprint I think for their dialup issues. HAHA!

My view.. (5, Insightful)

The Living Fractal (162153) | about 7 years ago | (#20338813)

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:My view.. (1)

eekygeeky (777557) | about 7 years ago | (#20338899)


how do the fellows operating the SCADA use it? from a desktop computer via client or dedicated machines?

Re:My view.. (2, Funny)

Short Circuit (52384) | about 7 years ago | (#20339249)

  1. Start->Connections
  2. Right-click "Local Area Connection"
  3. Click "Bridge connections" ...

Of course, you'd have to be any of clueless, foolish, or malicious to do that...

Re:My view.. (1)

AJWM (19027) | about 7 years ago | (#20339435)

The VPN client I use to get into work will immediately break the connection if you try that.

It also drops it if you try to PPTP tunnel through it. (Heck, sometimes it annoyingly drops for no particular reason at all, especially if I'm doing wireless with a less than 100% signal).

To get to the VLAN which lets me connect to the RILOs (through which I can remotely power off servers, among other things), I VPN to the corporate network, ssh to a dedicated security server, ssh from there to another server which guards the subnets for the servers I manage (on private IPs), and from there to one of the servers in that subnet which can actually talk to the VLAN the RILOs are connected to.

So, yeah, I can power them off and on remotely from the internet, but it's not exactly easy. And if I don't have my SecureKey (and its password) I don't even get past the first step.

Re:My view.. (3, Informative)

Kadin2048 (468275) | about 7 years ago | (#20339533)

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.

Re:My view.. (2, Informative)

Garabito (720521) | about 7 years ago | (#20339983)

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.

Re:My view.. (5, Interesting)

Doppler00 (534739) | about 7 years ago | (#20338903)

Are you absolutely sure? Doesn't the SCADA system connect to the internal corporate network somewhere? Don't managers want to see live plant operation data from their offices? At least the SCADA systems I've worked with have had a connection to the corporate network at some point. Usually through a dedicated SCADA system. I think in the end though, hackers don't want to actually have to buy the hardware they would need to test their methods out and if your corporate network has already been compromised, you're screwed anyway.

Re:My view.. (1)

OSU ChemE (974181) | about 7 years ago | (#20339355)

Speaking only from my past experience with one company, yes, the managers like to see the live plant operation data from their office, but it was view only. Only the terminals in the plant could actually change anything. Not saying this couldn't be spoofed or hacked in some way, but as you said, if they get that far, you're boned anyway.

Re:My view.. (2, Funny)

QuantumG (50515) | about 7 years ago | (#20338939)

Cool. How do you get data from the SCADA system to the back office? Say, to import into Excel and do some performance analysis or something?

Removable media and sneaker net?

I bet I could make a virus that could hop that.

Re:My view.. (2, Informative)

Anonymous Coward | about 7 years ago | (#20338969)

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.

Re:My view.. (2, Informative)

JonathanR (852748) | about 7 years ago | (#20339275)

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.

Re:My view.. (2, Informative)

GIL_Dude (850471) | about 7 years ago | (#20339323)

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.

Re:My view.. (2, Funny)

klenwell (960296) | about 7 years ago | (#20339737)

That said, a disenfranchised employee with login credentials would be a possible risk.

Just be sure to confiscate their eyeballs before they leave the company.

Re:My view.. (1, Informative)

Anonymous Coward | about 7 years ago | (#20339029)

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

Re:My view.. (4, Insightful)

Anonymous Coward | about 7 years ago | (#20339215)

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!

Re:My view.. (1)

bl8n8r (649187) | about 7 years ago | (#20339225)

If your HMI wire is connected to a layer 1 device that is connected to a wire connected to the internet, you are at risk.

Re:My view.. (4, Interesting)

gsogeek (1146905) | about 7 years ago | (#20340257)

I worked as an intern for a municipal government IT department a while back, and had to do a site visit to a water filtration/pumping station. While I was there, I wandered down to one of the areas where the machines were that ran the pumps, valves, and other sundry devices. I found the workstation where two computers had been installed, one on the network to allow employees access to email, the intranet, and the internet. Beside it was another computer, which controlled the SCADA system for the plant and had root access to the entire city's water and sewer SCADA system. The plant manager assured me that they were totally seperate, and never the two should mix. Well, imagine my shock and surprise when I walked past the desk and tripped over a bright yellow patch cable that ran from the second (standby) network card into a small hub, that also fed the public terminal and then went to the internet port on the wall. I made a few notes, checked a few log files, then went and told the manager that the hub had to go and went back to the main IT office and reported. The answer I got? "So what? What could someone do with that?" As a demonstration, I took my noted, typed a few commands, and put a few nice words on top of the Wunderware logo on the terminal, then told the plant manager, who was still saying this was impossible, to check the screen. Turns out, an employee in the plant decided it was too much trouble to go between the computers, took the hub from a conference room upstairs, and made the connection. I wonder what might have happened if I opened that Cl2 valve or maybe closed a high pressure sewage line at the treatment facility? The weakest link in these systems is not the SCADA systems themselves, so to speak, but the people that use them daily, and managers that don't bother to look at the equipment on a regular basis, just to make sure it still looks like that nice drawing in the office.

Re:My view.. (2, Interesting)

gnalre (323830) | about 7 years ago | (#20340877)

Nice idea in theory, but there's always a push to allow such systems to be accessed remotely for example performance monitoring. By saying never you are ignoring commercial imperatives. It is better by acknowledging it will happen and put in the infrastructure and practices which will make it as safe as possible.

For example we deal with ship control systems, which you may think are about as isolated as you can get. But there is a big push to allow remote access for such things as predictive maintenance, performance monitoring, fault diagnosis(difficult to send an engineer to a platform a 1000 miles from land). Therefore we have been as paranoid as possible when designing the access, but its a tough job to second guess hackers(in the evil sense of the word)

NT4 On The Plant Floor (2, Informative)

nuxx (10153) | about 7 years ago | (#20338861)

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.

Re:NT4 On The Plant Floor (1)

Doppler00 (534739) | about 7 years ago | (#20338955)

I've worked on a system like that before. The thing is, after you build a $2 million dollar facility and it's been running smooth for 10 years, you are reluctant to spend any more money to upgrade the control system just because Microsoft says it won't support you anymore. Most industrial I/O hardware can function for 10 to 20 years before it ever needs to be replaced. Heck, I would say indefinitely for the most part since most industrial systems have passive cooling mechanisms. I have rarely seen I/O logic fail, it's usually just a main DC power supply and those will never become obsolete or hard to find.

Re:NT4 On The Plant Floor (1)

SpaceLifeForm (228190) | about 7 years ago | (#20339473)

I believe you just made a strong case for using FLOSS.

Re:NT4 On The Plant Floor (3, Informative)

Doppler00 (534739) | about 7 years ago | (#20339497)

Naw, it would be the same problem. Just imagine being stuck on a Linux distribution 10 years old. Who's going to support you there? You'll be immediately told to upgrade to the latest and greatest fix your problems, but then your software may not function anymore. What's worse, is that I am not aware of any popular open source programs for industrial control systems.

Re:NT4 On The Plant Floor (2, Insightful)

Nimey (114278) | about 7 years ago | (#20339755)

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.

Re:NT4 On The Plant Floor (3, Informative)

masdog (794316) | about 7 years ago | (#20340153)

But depending on the size of the facility, a programmer might not be cost effective. Your average IT guy might not have the skill-set to right Linux kernal patches, and even if you're a small facility in a large corporation, you might not have the same software running your SCADA system as any other plant.

Re:NT4 On The Plant Floor (1)

Nefarious Wheel (628136) | about 7 years ago | (#20340569)

A lot of SCADA is still controlled by VMS systems. You can still buy them from HP. You can put off patches or upgrades until they scrap the refinery, and there's not a lot of activity among the script kiddies for DCL hacks. KESU rules.

Re:NT4 On The Plant Floor (3, Insightful)

Cassini2 (956052) | about 7 years ago | (#20339077)

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.)

NT4? Luxury! (1, Interesting)

Anonymous Coward | about 7 years ago | (#20339539)

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

how about iRMX (1)

plisskin (979687) | about 7 years ago | (#20339715)

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)

Pretty old news (1)

jofny (540291) | about 7 years ago | (#20338895)

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.

Re:Pretty old news (4, Insightful)

Doppler00 (534739) | about 7 years ago | (#20338989)

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:Pretty old news (1)

jofny (540291) | about 7 years ago | (#20339353)

Thats not particularly more challenging than any other network attack. Yes, you have to have some basic idea of how the system works to break in...whatever the system is. But doing damage can consist of something as simple as causing rotors to repeatedly and rapidly change directions till the system overheats and catches fire (yes, Ive seen video of this being done intentionally)

Security through obscurity (1)

mangu (126918) | about 7 years ago | (#20339409)

Let's say someone is able to hack in. Sending random data will only cause a redundant system to take over because it assumes a failure has happened.

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.

Safety systems protect against mistakes not malice (1, Insightful)

Anonymous Coward | about 7 years ago | (#20339419)

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...)

Re:Safety systems protect against mistakes not mal (1)

masdog (794316) | about 7 years ago | (#20340183)

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.

Re:Pretty old news (4, Insightful)

putaro (235078) | about 7 years ago | (#20339569)

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.

Re:Pretty old news (0)

Cyberax (705495) | about 7 years ago | (#20338993)

Actually, it was done:,1000000121,3914 7917,00.htm [] - US sabotages software for pipeline controllers in USSR.

Re:Pretty old news (1)

FooAtWFU (699187) | about 7 years ago | (#20339047)

That wasn't a "hack" of existing SCADA systems; no one exploited weaknesses in a software system to gain unauthorized access and cause bad things to happen. They just gave the Soviet spies defective-by-design software to steal, the Soviets ran it, and things went... defective.

A neat special case of social engineering, sure, but not "hacking".

Re:Pretty old news (0)

Anonymous Coward | about 7 years ago | (#20339401)

That fun little Spy Story of Thomas Reed's was rather likely embellished.

We did deliberately transfer some faulty hardware designs as part of the Line X counterintel, but the only source crediting the CIA in the pipeline explosion is Reed, promoting his book.

Tor like oatmeals! (-1, Offtopic)

Anonymous Coward | about 7 years ago | (#20338931)

Tor like oatmeals!

Re:Tor like oatmeals! (0)

Anonymous Coward | about 7 years ago | (#20339743)

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.

And they thought Bophal was bad... (0)

Anonymous Coward | about 7 years ago | (#20338949)

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.

Re:And they thought Bophal was bad... (1)

Doppler00 (534739) | about 7 years ago | (#20339013)

Well if it's an interlock safety system, vs. a SCADA system, it has no business being on the plant network. It should be programmed once and then operated in place.

Re:And they thought Bophal was bad... (1)

CyberZen (97536) | about 7 years ago | (#20339523)

Too true. And, usually, safety interlocks that prevent disasters like the grandparent describes don't rely on software; they operate at a mechanical or electrical level.

Amazing (3, Funny)

dbcad7 (771464) | about 7 years ago | (#20339005)

A "system integrator" working on his "sophisticated systems".. I was truly impressed until the lame a$$ question.

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.

SCADA Systems are designed to be Failsafe (5, Interesting)

Cassini2 (956052) | about 7 years ago | (#20339007)

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.

Re:SCADA Systems are designed to be Failsafe (0)

Anonymous Coward | about 7 years ago | (#20340407)

My concern isn't about SCADA specifically. The PLCs themselves generally have no security either, at least not on any plant I've seen. Assuming you could get traffic into the control network, you could get comms to any PLC you want and change variable (tag) values. Imagine the havoc THAT could wreak!

Re:SCADA Systems are designed to be Failsafe (0)

Anonymous Coward | about 7 years ago | (#20340861)

I personally think that people are going about things the wrong way with SCADA systems and from comments posted the solutions need to be 180 of current practice.

Rather than low complexity application specific designs that have no security or tolerance for errors...

Lets holster those soldering irons and get some high complexity common control systems togeather with some kind of PKI / crypto infustructure and reasonable network behavior (CRC's, buffering, jitter, congestive backoff, prioritized messaging)

This way it doesn't matter if someone bridges the control network with Internet or there is a broadcast storm or high traffic. The system still stand a reasonable chance of staying alive and doing useful work without compromise.

And a more horizontal market will ensure higher component quality all around.

As far as the windows constant update comment, its like sticking your head in a toilot and complaining that you just got wet.. Duh?! Microsoft actually makes it easy for you to manage what patches are applied and gives you the opportunity to run a central patch management system for your entire windows network. There is no need to have your operation suffer on the second tuesday of the month on account of IE, office and XML parser updates that have absoultely nothing to do with your mission.

BTW the last time I installed Fedora 7 the first thing that popped up was a message saying that some 170 updates were avaliable..

Its *not* the technology its the stupid people who implement it incorrectly and go crying because it doesn't work right.

I call bullshit -- Die Hard 4 is FICTION!!! (4, Informative)

mangu (126918) | about 7 years ago | (#20339031)

I have worked with SCADA systems for the last 28 years, since I left college with an EE degree.

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.

Re:I call bullshit -- Die Hard 4 is FICTION!!! (1)

QuantumG (50515) | about 7 years ago | (#20339159)

Says you. The great thing about these kinds of arguments is that *no-one* is qualified to say whether or not it is possible, because no-one tests this stuff. And, if anything, that was the message of the film.

Testing (1)

mangu (126918) | about 7 years ago | (#20339233)

no-one tests this stuff

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

Re:Testing (1)

QuantumG (50515) | about 7 years ago | (#20339253)

Riiight. You secure national infrastructure do you?

Re:Testing (1)

mangu (126918) | about 7 years ago | (#20339299)

You secure national infrastructure do you?

Yes, I do. Just this week I signed a revision of an NDA (Non Disclosure Agreement) requested by the US Department of State to conform with a new interpretation of the ITAR (International Trade in Arms Regulation). Any other questions?

Re:Testing (1)

QuantumG (50515) | about 7 years ago | (#20339367)

Seeing as you've opted to make yourself pseudo-anonymous, I can't confirm anything you're saying.

Re:Testing (1)

mangu (126918) | about 7 years ago | (#20339491)

I can't confirm anything you're saying.

You could start by looking at some professional systems. Search for "testing" at their site [] .

Re:Testing (1)

dbIII (701233) | about 7 years ago | (#20340849)

Don't worry about it - this guy has just decided he can have some fun with you. If you look at his posting history you will see he does a lot of "playing the man and not the ball" offtopic comments until the other poster gives up in disgust or boredom.

Re:Testing (1)

dbIII (701233) | about 7 years ago | (#20340869)

Seeing as you've opted to make yourself pseudo-anonymous, I can't confirm anything you're saying.

Trolls engage in social engineering now? These are dark times.

As for me - from my name I'm really an obsolete piece of database software.

Re:Testing (1)

(negative video) (792072) | about 7 years ago | (#20340077)

Funny, I've been testing this stuff for the last 28 years.

You can't test in information security. It has to be done by design and analysis, at all levels of abstraction, from metastable digital latches to number theory.

Anyhow, since no one has been able to get into any of my systems yet, the score is still 1x0

In a way that you recognized.

How about Martrix? (4, Funny)

jsse (254124) | about 7 years ago | (#20339327)

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.
I saw Tiffany drove a bike into the security station, blew up everything in her path then bought down the entire power-grid by with a single ssh nuke. She did it all in less than 5 minutes.

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.

Re:How about Martrix? (1)

catmistake (814204) | about 7 years ago | (#20339713)

Breakfast at Trinity's?
"I saw Tiffany drove"
"I saw Trinity drive..."

Re:How about Martrix? (1)

ookabooka (731013) | about 7 years ago | (#20339855)

The exploit she used was a real one. Check it out:

Wow, what an awesome opportunity for a shameless p (1, Interesting)

Anonymous Coward | about 7 years ago | (#20339041)

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 run on windows (1)

acadien (760879) | about 7 years ago | (#20339045)

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 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)

Re:Many SCADA run on windows (2, Informative)

Mousit (646085) | about 7 years ago | (#20339515)

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.

Re:Many SCADA run on windows (1)

fizzywhistle (1111353) | about 7 years ago | (#20340475)

Siemens has/had a Linux based SCADA, its called PCS OSx (don't ask). It was developed by Texas Instruments and was originally a SCO Unix based system but they switched to Linux just before they canceled the product line (old TI line of PLCs). It wasn't developed out of Germany but was somewhat successful in the US so it got canned. Its a decent SCADA actually though nowhere as easy to use as WonderWare's or even Intellution's (shudder). You might as well give up on a Linux SCADA from Siemens, too much of their structure is built upon MS (as in every tool and library) not the kind of thing you just up and change.

Air-Gap (1)

Detritus (11846) | about 7 years ago | (#20339059)

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.

Well I build them... (3, Informative)

Anonymous Coward | about 7 years ago | (#20339257)

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.

Hacker Vs Cracker Hurf Durf!!! (0)

Anonymous Coward | about 7 years ago | (#20339305)

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.

who here works at (1)

mikerubin (449692) | about 7 years ago | (#20339321)

the big beer company in St Louis ?

Re:who here works at (1)

scottv67 (731709) | about 7 years ago | (#20339869)

who here works at the big beer company in St Louis?

They make beer in St. Louis? That's news to me...

But of course! (3, Insightful)

WheelDweller (108946) | about 7 years ago | (#20339335)

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)

Simple attacks are best (1, Insightful)

Anonymous Coward | about 7 years ago | (#20339549)

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.

5 minutes to compromise/ no leet sk1llz required (0)

Anonymous Coward | about 7 years ago | (#20339865)

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

My experience (2, Insightful)

pionzypher (886253) | about 7 years ago | (#20339619)

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:My experience (1)

crossmr (957846) | about 7 years ago | (#20340411)

view only still means a connection of some sort... unless you go with some kind of streaming 1 way technology.

MS has a denial of service attack on accounts? (1)

Lost Penguin (636359) | about 7 years ago | (#20339895)

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

Re:MS has a denial of service attack on accounts? (1)

crossmr (957846) | about 7 years ago | (#20340463)

That depends on the security settings in the group policy. 3 failed logins in the default. It can be many or none or that feature can be disabled.

IBM/ISS has security services for SCADA (0, Redundant)

yorugua (697900) | about 7 years ago | (#20340135) 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.


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

Script Kiddies + SCADA... (3, Funny)

CompMD (522020) | about 7 years ago | (#20340287)

im in ur power plant retractin ur control rods

Easy as pie (1, Interesting)

Anonymous Coward | about 7 years ago | (#20340295)

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.


I develop scada software... Forbes is FUD (1)

CokeJunky (51666) | about 7 years ago | (#20340385)

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 .)

I secured SCADA systems - it's NOT all FUD (1)

cheros (223479) | about 7 years ago | (#20340605)

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 :-).

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 /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..

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.

Re:I develop scada software... Forbes is FUD (1)

SmarterThanTheAverag (1146927) | about 7 years ago | (#20340851)

Well I've done security audits for these systems and well lets see here: >>> The long story short is that most of these installations are physically protected from intrusion. Dude; I've done security audits on pipe-lines and electric power grids. Just because a substation in the middle of time-buck-two has a lock on the door doesn't mean the lock actually gets used. >>> First rate firewalling, ... A huge percentage of firewalls deployed even by pros have at least 1 large error in them. ( sourcePath=/dl/mags/co/&toc=comp/mags/co/2004/06/r 6toc.xml&DOI=10.1109/MC.2004.2 [] ) And you obviously haven't developed SCADA software long-enough to realize that on the average Plant-floor, the knowledge required to properly construct and deploy a firewall just isn't there. The rift between the "Scada Engineering" crowd and the "IT" crowd is larger than you think. >>> and in most cases, complete seperation of internet and operations systems are in place. Oh wow ... not directly connected to the Internet. Hmmm, that's a tough one, Not! On average, I've found in security audits on site, 50% more network access/entry points than what the companies security officer knew about. And separation between Control and Enterprise network, you're blessed if you have a Cisco Firewall as protection. (Until the 3am Engineer puts in the remote dial-in modem completely screwing over your cooperate security ) >>> Physical alarms and access controls, id badges, Amazing how you can audit the physical access controls, simply with kind-words and a smile. (Thank you Mr Mitnick) >>> and real security guards do the rest. Yeah, 15 to 20 security guards, one some facilities covering 10 square miles. >>> I am not naive enough to suggest that any such situation is 100% perfect, Good, shows you may have learned something while "Developing Scada Software" >>> but at the very least, we are not talking about script kiddies. The problem that I've found, is that we're not even putting in enough to stop the script-kiddies. When a simple port-scan of a Scada device may "brick it" (Brick It: send it back to manufacture to get replaced) think what even script-kiddies can do. >>>If someone has a real reason or agenda to break into these systems, and enough money and skillful crackers, they will get in. You don't need money, nor skillful crackers. In the last stages of the "World Wide War-drive" effort of a year or two back, they started to get Wireless Scada networks being reported. :-) >>> For example, WiFi ethernet networks are almost never used in these types of systems Dude, they don't have to be used directly on the Control-Network. With the number and types of connections between Control Network and enterprise growing, the hacker just needs to find 1. I've see and heard first hand accounts of Security professionals doing security audits on the Enterpise network and finding themselves with access to control network gear. One particular chap, did an audit of a Cookie factory's Office network, and his scanner tool found a hole in the Control network firewall that resulted in 1million in wasted cookie dough. Now wireless use on these systems; have you had your head in the sand for the last year or 2 ? Get real! It's the typical flood of technology again, easy of use before any thought of the security implications. >>> -- 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. Please don't challenge the Pringle-can boys. I can hear them rushing down to Radio-Shack now. >>> Furthermore, scada systems have some intelligence on the terminal ends: Have you run even a basic security scanner against on of these types of devices. I Have. It's my job, and the results are scary. Nothing like hard-crashing a device simply by port-scanning it. Or more worrisome than finding buffer overflow exploits in the embedded web-servers of these devices that permits you to execute code. These devices aren't that intelligent, partly due to the fact the their expected lifespan can easily be 15 years. New devices, latest generation system, yes they got more brains, and ability. But from my expereince more brains and abilities usually equals more vulnerabilities. >>> 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. For a Certified Safety system, yes. For the typical Programmable Logic Controller not a chance. There are PLCs out there that can be "bricked" with a single bad packet. Bricked = replace with new one ( power-cycle and firmware load can't recover them ) . >>>> 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. Nice point, until you realize that the Physical disruption is opposite of what is actually going on. These systems are getting more and more integrated and enmeshed into the standard corporate networks that access is almost a given. For example, while doing a security audit of a network a colleague found himself not even in the clients network, but on a scada network that the client's scada network was VPN connected to. It's not just your companies security you need to worry about, but also the security of the companies that your connected to. >>>> 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 .) Dude, have a look at this Symantec white paper ( /articledisplay.asp?id=1823 [] ) Then tell everyone again that is was taken into account.

This has been done for years (2, Interesting)

billsf (34378) | about 7 years ago | (#20340533)

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.


Don't hack the SCADA, hack the PLC (1, Interesting)

Anonymous Coward | about 7 years ago | (#20340551)

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.

System Integration can kill ... (2, Informative)

SmarterThanTheAverag (1146927) | about 7 years ago | (#20340565)

I to read the Forbes article, but I can approach it from a unique view point.

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 ... now they must become "ethernet enabled". Why ? Because they want to know what's coming off the assembly line, right now!

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 :-) 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.

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 :-) . 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.

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.




What I like is the 1 packet kill.. (1)

cheros (223479) | about 7 years ago | (#20340639)

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 ..
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>