Beta

Slashdot: News for Nerds

×

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!

Researchers Find Slew of Flaws In SCADA Hardware, Software

Soulskill posted more than 2 years ago | from the a-slew-i-tell-you-a-slew dept.

Security 110

Trailrunner7 writes "At the S4 security conference this week, 'Project Basecamp,' a volunteer-led security audit of leading programmable logic controllers (PLCs), performed by a team of top researchers found that decrepit hardware, buggy software and pitiful or nonexistent security features make thousands of PLCs vulnerable to trivial attacks by external hackers that could cause PLC devices to crash or run malicious code. 'We were looking for a Firesheep moment in PLC security,' Peterson told the audience of ICS security experts. They got one. 'It's a blood bath mostly,' said Wightman of Digital Bond. 'Many of these devices lack basic security features.' While the results of analysis of the various PLCs varied, the researchers found significant security issues with every system they tested, with some PLCs too brittle and insecure to even tolerate security scans and probing."

cancel ×

110 comments

unreviewed code is buggy? (5, Insightful)

Gothmolly (148874) | more than 2 years ago | (#38777773)

So you're saying closed source, only-validate-functionality, stale code has security holes?

Re:unreviewed code is buggy? (0)

Anonymous Coward | more than 2 years ago | (#38777833)

This is what happens when you hire vampires to do your programming. What were they thinking? And they're surprised when it turns into a bloodbath?

Re:unreviewed code is buggy? (4, Insightful)

hairyfeet (841228) | more than 2 years ago | (#38778933)

Are you forgetting the 6 year old Debian bug? the KDELook bug that lasted for over a year before caught? the hacked Quake 3 that lasted in the repos for a year and a half? The "many eyes makes bugs shallow" is a fallacy because it (incorrectly ) assumes that you have enough eyes that have the required skillset and that those eyes are doing NOTHING but searching said code, literally millions and millions of lines in just your average distro, for bugs. Then of course they have to be scanning ALL updates, patches, changes, for any possible vectors. Do the math friend and you'll find you'll have to clone about a million top level programmers just to keep up! I'd frankly be amazed that there is even 10% of the code in your average distro being checked by eyes other than the ones that actually wrote the thing. Just look at how much cruft and dead code the LO guys are finding in the OO.o codebase and that is one of THE most popular programs in the entire FOSS ecosystem!

In the end there is good and bad code in EVERY format from BSD and GPL to proprietary, it all comes down to the skills of the programmers and how seriously security is stressed in that company. There is nothing "magical" about FOSS that instantly makes it immune to bugs, nor does it give coders the power to instantly write non buggy code. Hell I could paste this post with links to Linux hacks, starting with kernel.org [slashdot.org] on down, but what's the point? Sadly perception bubbles and flag waving have replaced serious debates here which is why the numbers have been plummeting for nearly 2 years now. i hate to agree with him but old Mikey 500 accounts is right "Slashdot = Stagnated". I mean look at your own post that got a +5 for a simple variation of the classic "Use Linux!" troll. Its like the old Mel Brooks joke "all go to hell except cave 76!" and treating companies and licenses like ballclubs to root for.

Kinda sad that supposedly well educated geeks have ended up no better than those we laugh about cheering for reality TV stars, only we replace the Kardashians and Survivor for Google, Apple, MSFT, and the GPL.

Re:unreviewed code is buggy? (0)

Anonymous Coward | more than 2 years ago | (#38779073)

Unfortunately we really don't know. Is Windows XP completely secure now, it's been around for a decade? So while you can point out flaws in OSS that span 6 years, it doesn't mean anything, since we don't know how long bugs persists in proprietary code.

Re:unreviewed code is buggy? (1)

rtb61 (674572) | more than 2 years ago | (#38779119)

So what your saying is the Debian bug still hasn't been solved, OMG. So what's that six years and counting. Perhaps what your saying is many eyes still sometimes take time to resolve bugs, well, everyone expects that.

The flip side with closed source code is often the bugs get found when they get exploited. So how many times was the Debian bug exploited. Also in closed source code, how many times was a bug found and left unrepaired for years.

Here's a fun windows 96 bug, their write-behind caching was notoriously un-reliable, using windows update they supplied a fix. Do you know what is was? They disabled it, a feature they marketed and sold didn't work and to fix it, they simply and cheaply turned it off.

Now that is the big difference between closed source proprietary code and open source code. Cost to repair code and willingness to do so. In one case if it eats into profits they simply wont do it of if they do, they do a cheap nasty fix that leads to other problems. In the other case, amongst the many eyes, for popular products, there is always someone who wants publicity for fixing the bug as there is a good chance it will lead to a job or for a company it will help to promote their inhouse skills and abilities or there is a company threatened by that bug or there is a government department in one of the many countries who use it that considers it a security threat or there is a university who does research using that code or even on that code (do you get the picture yet).

Closed source only one set of eyes to discover and 'FIX' (there is bunch of other eyes but they discover and 'EXPLOIT', never heard of 'stuxnet'), versus many sets of eyes to discover and 'FIX'. Of course there are still those want to exploit open source bugs but in large government settings to exploit a bug means you must leave your own systems unrepaired and unprotected, kind of a real catch 22 there.

Re:unreviewed code is buggy? (1)

hairyfeet (841228) | more than 2 years ago | (#38782631)

What's Windows 96? Never heard of that. And frankly we don't KNOW how many bugs are being exploited in Debian, just as we don't KNOW how many bugs are being exploited in Windows 7. BTW XP? Its 12 years old now, let it go, okay? FOSSies have a raging hard on for that ancient thing but its legacy code that MSFT has been nice enough to continue providing patches for. Where is the 12 year old Debian i can still get patches for? that's right, it doesn't exist and i have NO CHOICE but jump on the upgrade deathmarch or be left unsupported. this is why I can't hand Linux out to customers, a frankly shitty lousy 3 years of support MAX and that is if i were to build my entire business around LTS, only to see when the 3 years is up the upgrade take a dump on the drivers.

You see EVERYONE has problems, Linux guys can't write a driver worth a shit, nor can they figure out how to make upgrades work, MSFT hasn't figured out how to force Windows updates on pirates which BTW the vast majority of zombie Windows boxes? pirated Windows which has had the updates killed to prevent WGA. And nobody cares how many eyes COULD look at the code all that matters is how many eyes that have the SKILLS DO look at the code and as i showed, and i'd be happy to wallpaper the post with links to Linux hacks, just ask, the "many eyes" bullshit is just that. For it to work you have to have AAA coders wasting thousands of man hours going through that shit on their own time and even a tiny bit of thought would tell you that's bullshit, AAA coders aren't gonna waste their free time doing your crap, they have money and lives to worry about. I could end with a 'get a damned job you lazy hippie" but its just too easy, so I won't. Instead i'll just say "have a nice day" because that's what kind of guy I am.

Re:unreviewed code is buggy? (1)

alexborges (313924) | more than 2 years ago | (#38783671)

Sorry. Your argument is invalid because of ponnies.

Well, and the fact that we are talking about PLC's, not full desktop operating systems.

Re:unreviewed code is buggy? (2)

Zero__Kelvin (151819) | more than 2 years ago | (#38785569)

"Are you forgetting the 6 year old Debian bug? the KDELook bug that lasted for over a year before caught?

Yes. When we said there are never any bugs in Open Source software we forgot those two. ( ... and just to be clear, we didn't really say that despite your efforts to imply that we did)

"... the hacked Quake 3 that lasted in the repos for a year and a half?

We Open Source developers are a weird lot. We focus more on security when we are producing products that will control nuclear power plants than when we do when working on games.

"The "many eyes makes bugs shallow" is a fallacy because it (incorrectly ) assumes that you have enough eyes that have the required skillset and that those eyes are doing NOTHING but searching said code, literally millions and millions of lines in just your average distro, for bugs."

It assumes no such thing. It merely correctly asserts that 1000 qualified software engineers looking at code is better than 10 of the same looking at code. It's really not rocket science.

"Kinda sad that supposedly well educated geeks ..."

What is really sad is a troll actually calling itself hairyfeet and expecting nobody to notice.

These things were too successful. (5, Insightful)

icebike (68054) | more than 2 years ago | (#38777801)

Most of these PLCs were simply too successful for their own good. Many of these designs were created in the 70s with no real intent of ever having then live in an on-line environment, but rather to be isolated in machinery as simple as pumps, motors, and simple stand along controllers for a variety of machines.

The problem lies not with the PLCs but the questionable decision to wire these things into the network.

Some of these things are extremely simple controllers. Others, like the mentioned D20 ME [ge-energy.com] are micro computers onto themselves. These devices are built from a long line of simple process controllers, which grew to their current state from simply hanging more and more interfaces, better processors, and a mountain of legacy software, onto what started life as a very simple device.

None of them were ever intended to be put directly on the wild and wooly net, even when the did contain Ethernet ports, modems, and radios. Everyone assumed these were on their own in-plant network and that no one would hook them up to even their general purpose lan, let alone to computers accessible to the internet.

Anything less successful would have been replaced by a total redesign and rewrite from the ground up.

Re:These things were too successful. (0)

Anonymous Coward | more than 2 years ago | (#38777859)

Most of these PLCs were *never* meant to be run on the internet...

They were mostly glad to even get them to talk to each other much less passwords and encryption in some 8 bit processor. They were glad it just worked at all.

The newer ones are quite powerful but still emulate the older stuff as the things they are hooked up to cost millions of dollars a crack. You cant just 'oh lets replace the whole thing with something newer'. You just dont have the money anymore for it...

But also given that there is a huge swath of 'default passwords'. People plugging it in not really caring just glad they dont have to drive 200 miles in the middle of the ozarks to some plant on the top of some hill somewhere to look at it.

dident some of them have dial in only and you need (1)

Joe_Dragon (2206452) | more than 2 years ago | (#38778169)

dident some of them have dial in only and you needed to war dial to find them and likely get very little info on what you found. But with a IP you can find some thing and get alot more info on the hardware just by running some commands / looking at what software is on the IP that that has a open port.

Re:These things were too successful. (0)

Anonymous Coward | more than 2 years ago | (#38777937)

Absolutely. Critical hardware should be physical access-restricted, and allowing any sort of access to it through a computer is foolish. It amounts to thinking that out of the millions of internet users worldwide, nobody will have the skills or desire to sabotage it. Wrong! Say what you will about the Iranian government and its evil, but they at least had the sense to leave an insider with physical access to the uranium enrichment plant the only way to sabotage the centrifuges (if I recall correctly). It took several governments great effort to devise a crafty worm, which probably infested an employee's USB drive and then got plugged into the offline network within the plant.

If Iran can do this with a top-secret facility, we should have been able to do this with public infrastructure ten or more years ago. It's a hubris issue. And it costs money to change anything. If the US did this, it would be money well spent.

Re:These things were too successful. (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38777947)

I program, install and commission PLCs in high security facilities, including prisons. We mostly use them for door control, interlocking and some low-level interfacing to other systems for which we don't have a high-level interface.

I do not believe that the responsibility for security should rest with a relatively cheap, simple bundle of IO and a processor programed in ladder logic. The security should be in preventing access to the SCADA/security network to which these controllers are attached. These things aren't servers, it's hard to imagine a reason for having them anywhere near the WWW. In our high security sites we usually have an air gap enforced by a physical barrier (two layers of four metre high razor tape fence) which is regularly broken by people disregarding policy and carrying in USB memory sticks. This is a potential attack vector, assuming whomever wrote the attack program had intimite knowledge of how the PLCs were programed. Most network security barriers are overcome in time as new vulnerabilities are discovered. Given the commission-and-hands-off nature of PLCs, rolling out updates to patch theoretical vulnerabilities is going to be a VERY hard sell, considering any change to the PLC usually requires re-commissioning every field device attached to it.

Re:These things were too successful. (0)

Anonymous Coward | more than 2 years ago | (#38778171)

P.S. Posting as AC as I'm uncertain how my employer would react to me providing that info.

Re:These things were too successful. (1, Insightful)

teridon (139550) | more than 2 years ago | (#38779889)

The security should be [...] an air gap enforced by a physical barrier [...] [but this is] regularly broken by people disregarding policy and carrying in USB memory sticks.

You admit the fatal flaw, but still think physical security is enough? Even when it appears that all it takes to defeat your "security" is one retarded, or corrupt, security guard?

You might as well cover your ears and scream "LA LA LA I CAN'T HEAR YOU". Obviously these PLCs need to be connected to a network of some kind to be useful. But even when that network is physically secure, those PLCs and their associated IT systems need to be secure against known attacks.

Re:These things were too successful. (3, Insightful)

JWW (79176) | more than 2 years ago | (#38780557)

Quick question. So you're saying that they need to secure the system from the guards so that they can't use it to open the cell doors? Wouldn't it be assumed that the guards already have the implicit capability to open the cell doors?

I love how security discussions almost always evolve into someone arguing that some particular actor in the system needs to be prevented from doing something that is actually part of their job!!

Re:These things were too successful. (1)

teridon (139550) | more than 2 years ago | (#38782691)

OK, that's fair, I wasn't clear.  Obviously the guards should be able to operate the functions required for their job.

I was trying to say that you can't assume malicious software doesn't exist on your network; i.e. you cannot leave out basic security controls just because the thing is on a ostensibly private network.  No software should be able to open a door by, say, sending a simple ASCII string on the right port (I've seen that kind of stupid crap in other software).  Why not specify that you need two-factor authentication to open a door?  That would at least prevent attacks any kindergartner could perform.

guard doesn't need to be complicit (1)

Chirs (87576) | more than 2 years ago | (#38782783)

I'm assuming the guards are carrying personal data (files, movies, music, etc.) on those USB sticks. All it would take is someone getting into a guard's computer and dumping a virus onto the USB stick. The unsuspecting guard carries it past the physical protection, loads it into the private network, and the virus then infects the isolated network.

Come to think of it, isn't this how the centrifuges were attacked with stuxnet?

Re:These things were too successful. (1)

drinkypoo (153816) | more than 2 years ago | (#38782663)

Physical security is enough, but theirs isn't. Epoxy in any USB ports that can't be disabled is the canonical response to this particular problem. Smarter is to use an enclosure that simply prevents access to them, or removal of the keyboard from its port, et cetera. A determined attacker could still cut the keyboard or mouse cable in order to connect their own device, but even if you use USB you can still prevent driver installation so the worst they could do is inject custom keycodes or mouse events.

Re:These things were too successful. (4, Insightful)

gman003 (1693318) | more than 2 years ago | (#38777959)

Agreed. My father actually works for a major company that makes these (among other things - he works in a different department, but uses the things in his line of work). I told him earlier about a story from here about a major flaw in a city's usage of it. His *first* *response* was something along the lines of "what moron decided to plug that thing into a network in the first place?".

The systems were designed and are still designed to be fully isolated from intruders. The authentication is mostly there as an afterthought, to keep the site janitor or a secretary from logging in and seeing what happens when they push the big shiny buttons. The city in question most likely hadn't even changed the password from stock, as it was still three characters long.

Remote login shouldn't ever be permitted, because it shouldn't ever be necessary. A trained operator is always on-site, in many cases because a trained operator is legally required to be on-site 365 days a year.

Yeah, a lot of the blame should fall on the people making these - they should have wisened up to security requirements ten years ago. But part of the blame goes to the people who said "sure, let's plug this into the Internet! What could *possibly* go wrong?"

Yes, keep it "offline" (3, Interesting)

dinodriver (577264) | more than 2 years ago | (#38778521)

I agree. I work for a water utility and making any changes to our system requires us to physically report to the locked, alarmed office and access (through password login) a scada computer terminal, or to report to the facility in question and log in there. I often wish I could at least access current complete "read only" system data on my phone or computer so that when I'm paged by the system and it reports that a fault has occurred (example could be as simple as "pump #1 failed to start") I could see how crucial it is for me to respond or if it's something that could wait till morning. But we so far have avoided the slippery slope of remote access and so I have to respond physically and access the situation. (and to avoid responding to less than crucial problems, we just set the system to only call out on serious issues and just log the others for review during business hours).

Re:Yes, keep it "offline" (0)

Anonymous Coward | more than 2 years ago | (#38778569)

There would be a market opportunity for a true read-only network interface with guaranteed security, if someone hasn't invented one yet. Any takers?

Serial printer port (1)

fleebait (1432569) | more than 2 years ago | (#38779389)

Nothing new. It's called a two wire serial printer port -- can even drive a 300 baud modem.

Re:Serial printer port (1)

TheTurtlesMoves (1442727) | more than 2 years ago | (#38779597)

If you are really paranoid, you can add a optical isolator to ensure data can go just one way.

Re:Serial printer port (1)

Anonymous Coward | more than 2 years ago | (#38779817)

The market opportunity is in making a product that can be switched in place of an ethernet link with as little work as possible, and in marketing the hell out of it as the "best possible" secure solution. Preferably the interface should also be very fast, so that you can pass all the raw data you could possibly need into a database on the other side of the link. Otherwise you have a bottleneck that may need special processing on both sides of the link.

Re:Yes, keep it "offline" (1)

papafox_too (883077) | more than 2 years ago | (#38779343)

I agree. I work for a water utility and making any changes to our system requires us to physically report to the locked, alarmed office and access (through password login) a scada computer terminal, or to report to the facility in question and log in there. I often wish I could at least access current complete "read only" system data on my phone or computer so that when I'm paged by the system and it reports that a fault has occurred (example could be as simple as "pump #1 failed to start")

You are kidding yourself. Your work network is still vulnerable, even though it's isolated.

One of the great security lessons is that an isolated TCP/IP network is an impossibility. DoD found that out when they found malware on secret classified networks. The Iranians found it out when Stuxnet successfully attacked the internal process control network at the Bushehr nuclear facility. DoD classified networks have been penetrated by workers whose laptops are connected to the classified network at work during the day and the internet at home during the evening. The network at the Bushehr facility may have been penetrated by Stuxnet by an infected USB key.

It doesn't matter if the network has remote access or not - malware will still be able to penetrate.

Re:Yes, keep it "offline" (1)

Runaway1956 (1322357) | more than 2 years ago | (#38779479)

There is still a huge difference. A system that is connected directly to the internet provides a target to every pimple faced kid in the world, provided he has a computer and the will to futz around, searching for a vulnerability.

That air gapped system requires much more skill, patience, and dedication, along with some kind of feedback, than zit-face can possibly muster.

Re:Yes, keep it "offline" (0)

Anonymous Coward | more than 2 years ago | (#38782621)

yeah like a engineer putting a "found" USB key into one of the water protection systems. The malware activates because it does not find antivirus software on the machine. Why doesn't it have antivirus software? Because the network is isolated.

True story.

Re:Yes, keep it "offline" (1)

Fnord666 (889225) | more than 2 years ago | (#38783043)

That air gapped system requires much more skill, patience, and dedication, along with some kind of feedback, than zit-face can possibly muster.

Exactly. This means that the only attacks you will get will be something like Stuxnet. It will be specifically targeted at your system and it will not be displaying a laughing face on your monitor. It will probably reverse the pump that sends fresh potable water into the sludge tanks.

Re:These things were too successful. (1)

silas_moeckel (234313) | more than 2 years ago | (#38778559)

You get all sorts of stupidity with this sort of thing. I know a city who put this all on there network. It's actually stopping them from getting off a bridged network as there security plan was static IP's on a different address range. This stuff is old and does fun things like arp constantly.

Re:These things were too successful. (2)

Runaway1956 (1322357) | more than 2 years ago | (#38779467)

"Yeah, a lot of the blame should fall on the people making these - they should have wisened up to security requirements ten years ago."

Ask yourself, what percentage of PLC's in use today are newer than ten years? Crap - I'm using PLC's that are 30 years old! If I actually researched our stuff, I might find that some are even older. (When WAS the PLC invented, anyway?) To make things even worse, manufacturers of new machines are using technology that is 3 to 10 years old. In the same machine, we have stuff that was patented as long ago as 20 years, software that was copyrighted a mere 6 years ago, chips that interchange with 20 year old machines. That hundred thousand dollar machine is a mismatched conglomeration of new and old technology. And, if we had demanded state of the art security to be built in, it would probably have cost double what we paid!

Re:These things were too successful. (0)

Anonymous Coward | more than 2 years ago | (#38778113)

I've worked in software development for these sorts of systems for about a decade or so. When I peak under the covers of some of the code that exists in these systems I cringe. I could have told you 9 years ago that the security in the systems I have worked on is essentially non-existent.

Marketing drives development. Security doesn't sell products (that will hopefully change). Worse it's easy to claim a product is secure when it is not, and most customers will not know the difference. Features sell, backwards compatibility is essential (as parent stated, many existing systems would cost 10's of millions to replace, and potentially far more in plant downtime / lost productivity). What we end up with is feature on top of feature, all on top of 30 years worth of code not designed to be secure. Customers want more connectivity these days. They want to be able to check the status of a plant from a smartphone. The saving grace for many of the systems I've seen is that they are well firewalled (many are NOT air-gapped these days). The IT staff running the systems which I have been involved with have been quite competent. They have a hard outer-shell, but are far too squishy on the inside for my liking.

Re:These things were too successful. (3, Informative)

mysidia (191772) | more than 2 years ago | (#38778427)

Worse it's easy to claim a product is secure when it is not

A product is not "secure" or "insecure"

A deployment where a product is used is secure or insecure.

A deployment of a product can be highly secure in its expected deployment scenario, but the deployment horribly insecure if you plug it into an outside network which contains unmanaged devices.

There may be flaws in a TCP stack (For example), that could be exploited if an unmanaged device were allowed to produce arbitrary communications, but the deployment can be secure when all devices are managed, and there is no operator console command to generate the invalid packet, without physical access to plug a laptop into the cordoned off network.

Re:These things were too successful. (4, Interesting)

DarkOx (621550) | more than 2 years ago | (#38780123)

Right security is about people. I agree not every single device needs to be hardened like a fort. I think this is actually a trap many security folks, especially geeks fall into. Its wrong because it ends up frustrating everyone else, and they start not cooperating, circumventing security controls and opening wide holes than existed in the first place.

The most important thing is that everyone understands what things are. If its well known that say some industrial control app is thin on input validation, does simple clear text unauthenticated communications with other devices, and has a configuration interface with a password dialog easily bypassed by rigging up a specific query string, all that might be okay. There might even be very solid reasons for it. It keeps the code base small, easily understood, might offer performance advantages on limited hardware, etc. Hardware hardened for industrial applications is often limited and expensive. You might ask why even bother with the login screen if its so easy to defeat, well its a lock for honest people, it might help oh This is Isle 3A bay 15, I am supposed to be making this change on 3B-15, oops sort of mistakes.

Clearly such devices are designed for use on closed networks, as long as everyone understands that there is no reason to make things harder for people. Its when usb sticks and laptops start getting plugged in, or someone connects it to a larger network you see problems. Manufactures need to be upfront about these things being designed for a specific ecosystem. "Yes it password protected, but its human interface feature not a security control..."

Re:These things were too successful. (1)

ArsenneLupin (766289) | more than 2 years ago | (#38784669)

They have a hard outer-shell, but are far too squishy on the inside for my liking.

This is true of many corporate systems, not just SCADA. How many companies have companyname123 or some variation as their password on their internal systems? They still don't get hacked (usually), because their external firewalls. Access from outside is not possible, except through VPN for which you need a physical token.

... but all hell breaks loose if some smart guy manages to breach this outer shell (via spear phishing, USB keys, a rogue employee/consultant or whatever...)

Re:These things were too successful. (3, Informative)

Anonymous Coward | more than 2 years ago | (#38778117)

Then there is Allen-Bradley with their Micro-VAX blade plugin to network and perform serious device control... The fact is, is that a lot of these devices ARE intended to be networked these days, but they are still built with a 70's and 80's non-networked mindset. My opinion, having written a LOT of software for integrating PLC's into complex manufacturing control systems for companies and organizations ranging from General Motors to Honeywell to Motorola to Rockwell to the US Navy, is that the best approach is to keep the controllers separate from the network systems, and use embedded PC's with I/O capabilities (PC-104 devices are very nice these days, running Linux or QNX) to trigger the PLC's when an external event warrants it, such as changing the recipe or route for some product.

Re:These things were too successful. (4, Interesting)

guruevi (827432) | more than 2 years ago | (#38778215)

On the other hand even if they were separated from the internet, they were intended to have some sorts of communication between a base (such as an office) and a remote station. I purchased a set of 33.6k programmable modems (Telindus Aster 5) once that were set up to dial in automatically into a specific location with passwords etc. pre-programmed. How easy do you think it would've been for anyone else to dial-in to those systems if they knew any of the details?

The matter of fact is that until the last 5 years none of these system makers thought about any security even though the techs in the field knew how their systems were going to be set up at the customer. I've worked with Siemens several times (both with their PLC side and their medical instruments side) and every single time I had to provide the additional security on my (or my clients) network even though it was never planned for, requested by them or even had come up in the negotiations when these things were purchased.

And to give you a reason why I think they should plan for it: Windows XP SP1 is what they not only use on their own systems but also set as a requirement for developers to use with their SDK's (together with some custom packages and Visual Studio 6).

Re:These things were too successful. (1)

Mendy (468439) | more than 2 years ago | (#38780845)

And to give you a reason why I think they should plan for it: Windows XP SP1 is what they not only use on their own systems but also set as a requirement for developers to use with their SDK's (together with some custom packages and Visual Studio 6).

From my experience this is because the changes to DCOM security in SP2 break how they've written their applications. You can get it to work by fiddling in dcomcnfg yourself but this didn't seem to be something the Siemens guys had tried.

Re:These things were too successful. (4, Insightful)

FooAtWFU (699187) | more than 2 years ago | (#38778339)

While it is indeed laughable and sad that these unprepared devices were attached to the Internet, it is also worth highlighting that being detached from the Internet is not itself a pancaea. Stuxnet was able to damage Iranian uranium centrifuges without those centrifuges ever being attached to the Internet.

But yes, detaching them further is a very good plan.

Re:These things were too successful. (1)

mysidia (191772) | more than 2 years ago | (#38778453)

While it is indeed laughable and sad that these unprepared devices were attached to the Internet, it is also worth highlighting that being detached from the Internet is not itself a pancaea.

In addition to being detached to the internet, the use of USB addon devices should be disabled on all SCADA operator consoles and other SCADA network connected devices. And they must not have connectivity to the same network or storage volume as _any_ other device that has internet access, USB thumb drive access, connectivity to any network that has or has outside connectivity directly or indirectly; or that contains any hard drive or storage media that has EVER been attached to a network-connected device since the last time that media was completely formatted with a SCSI/ATA secure erase.

In other words: no data path from outside network to SCADA network, neither a network datapath, nor a sneakernet data path.

Re:These things were too successful. (1)

makomk (752139) | more than 2 years ago | (#38779691)

In other words: no data path from outside network to SCADA network, neither a network datapath, nor a sneakernet data path.

Of course, this would make any kind of remote monitoring impossible...

Re:These things were too successful. (0)

Anonymous Coward | more than 2 years ago | (#38780215)

... unless you had something like RS232, full duplex RS485, 10baseT, 100baseT, ...
which can all work with only data lines for one direction connected...

Re:These things were too successful. (1)

ArsenneLupin (766289) | more than 2 years ago | (#38784711)

... unless you had something like RS232, full duplex RS485, 10baseT, 100baseT, ... which can all work with only data lines for one direction connected...

... but then that RS485 would no longer be full duplex would it?

Re:These things were too successful. (1)

mysidia (191772) | more than 2 years ago | (#38786649)

Of course, this would make any kind of remote monitoring impossible...

Not impossible. Build a private circuit from the site to be monitored to an operator console at a remote secure location; use a dedicated firewall on the monitored station side of the private circuit that only allows unidirectional encrypted traffic required to feed information into the remote monitoring station.

Re:These things were too successful. (4, Interesting)

deniable (76198) | more than 2 years ago | (#38778387)

I used to work with PLCs driving mining equipment. We knew ten years ago that these things weren't secure and shouldn't be accessible. Thankfully, we just built the machines and plugged them into their network. Their security guys are probably on medication by now. They got over-ruled when middle management types 'needed' to have the office and plant networks hooked together for easy overview or stats reporting or whatever the excuse of the week was. (Giving them what they asked for in a secure fashion wasn't the point, they wanted the access.)

Re:These things were too successful. (0)

Anonymous Coward | more than 2 years ago | (#38778533)

That is very true. Here's one example. Many power plants now use historians running on Windows Server, which is typically located on a separate server hooked into the company LAN for remote access by company employees. The interfaces must connect to a HMI drop or switch to collect information from the data highway that is part of the distributed control system of the plant. If the installers are smart, they installed a hardened firewall that only allows communication protocols through only a few ports. But this is not always done and I've seen several where the plant's control system is basically wired into the company LAN. Probably violating NERC security requirements.

Of course, shutting off a single power plant is not going to cause a major systemwide blackout assuming the high voltage electrical protection was designed correctly. But it shows an example of new network technology interfacing with internal systems not intended to be hooked into the wider network. Many of these control systems are still in flavors of Unix and probably full of holes. Not to mention the PLCs controlled by them.

Re:These things were too successful. (1)

jmauro (32523) | more than 2 years ago | (#38782787)

shutting off a single power plant is not going to cause a major systemwide blackout assuming the high voltage electrical protection was designed correctly

Brave [msn.com] assumption. [wikipedia.org] .

Re:These things were too successful. (0)

Anonymous Coward | more than 2 years ago | (#38778963)

Now with ProfiNET becoming more popular and replacing Profibus, expect these systems to be linked up to the LAN more and more often. I've already ran into projects where the big boss wants to see how the system/machine is running in his office, so he asks them to hook the whole thing up to their office lan (Yeah you can imagine what kind of problems that causes to real time communication), running the entire program on his laptop. It's extremely easy to do this. These programs all run in Windows, especially Siemens PLC's and SCADA systems, rarely have I ever seen anything custom built running nix.

And now with these new safety PLC devices coming into the market with Ethernet ports on them, I question their designs and what dangers it may actually pose to the safety functions of these machines.

Re:These things were too successful. (1)

Runaway1956 (1322357) | more than 2 years ago | (#38779439)

You've nailed the problem, right there. SCADA was never meant to be online. It hardly matters that some chips were designed before there was an internet - even the newest aren't meant to be online. Having an infrastructure network accessible from the internet is moronic. It is merely stupid to have an outdated operating system with inadequate security connected to the internet, but positively moronic to connect your SCADA.

Someone needs to send a news letter to all of the corporate and government idiots who believe otherwise.

I worked the D20 (0)

Anonymous Coward | more than 2 years ago | (#38779669)

I worked the D20. It really is 15-year old hardware/software that continues to be used because of its installed base and GE sales team rather than its technical merits. A rewrite will never happen because the people who originally built it have all been outsourced by incompetant maintenance teams in India. More likely GE will acquire a superior product then re-brand it. I'd vote for virtualized D20's that can run existing configurations on new hardware.

Re:These things were too successful. (1)

tibit (1762298) | more than 2 years ago | (#38786881)

I don't see a big deal here: you want it on the network, you put a gateway that encrypts the connection, verifies the certificates of the accessing party, etc. Like any tiny linux-running internet-enabler gizmo would do, when properly configured, even using nothing more than ssh. There's nothing inherently bad about those PLCs, it's the dumb implementers who have no clue. If you integrate solutions that involve networking, get someone with a clue in that area. Most industry "specialists" who deal with PLC have little clue about internet, network safety, etc. They have a different skillset: they know the quirks of various PLCs, I/Os, they know various industrial networking protocols (those have nothing to do with internet, many don't even use ethernet), and so on.

At least not remote login ready (1)

Billly Gates (198444) | more than 2 years ago | (#38777813)

Especially the ones that require IE 6 to remotely manage. I mean in that kind of environment complete pre SP 1 XP with no firewall unpatched that uses unsigned active X controls... or not what could possibly go wrong!

run malicious code (2)

nurb432 (527695) | more than 2 years ago | (#38777841)

Cool, sort of like having access to an industrial 3d printer. Tho picking up your finished products might be tough.

Re:run malicious code (2)

sowth (748135) | more than 2 years ago | (#38777939)

No problem. Since Hollywood is going bankrupt from "rampant piracy," you can probably hire the Oceans Eleven team to pick up your stuff for dirt cheap.

Re:run malicious code (0)

Anonymous Coward | more than 2 years ago | (#38778565)

just make sure it has wheels and you can drive it off :-)

Wait... Software has flaws? (-1)

Anonymous Coward | more than 2 years ago | (#38777863)

Put the Hearse in reverse!!!!

USB (0)

Anonymous Coward | more than 2 years ago | (#38777891)

Disable autorun for USB devices too!

Awww! (3, Funny)

PPH (736903) | more than 2 years ago | (#38778205)

We just got a great deal on some barely used USB sticks from Iran. Only plugged into their centrifuge controllers once.

Alot of the stuff comes from a dos / win 3 / 9X (2)

Joe_Dragon (2206452) | more than 2 years ago | (#38777949)

lot of the stuff comes from a dos / win 3 / 9X mine set likely loaded with hacks and out stuff to keep them going so to get real security they may need to be rebuild from the ground up.

Re:Alot of the stuff comes from a dos / win 3 / 9X (1)

thegarbz (1787294) | more than 2 years ago | (#38779991)

That's the interfaces themselves. They have no reason to be secure against a software attack as they should be 100% phsyically secure. The actual code in the PLC has nothing in common with DOS or early Windows, these things don't run operating systems, they are embedded systems as embedded systems should be, really quite simple. This is also why they lack security features.

But really what would a ground up re-write accomplish anyway? You close some security holes made by constant patchwork, and open a shit load more through bugs. No software is secure to endless scrutiny, not open source, not closed source. Eventually someone will find an attack vector, and then what?

We have PLCs on site with known bugs. One of them has had about 130 pages of critical bugs reported by the vendor. Between licensing agreements, software incompatibilities, and all that really sweet stuff we have managed to plan to completely rip out and upgrade the old system which will eliminate those bugs. .... In 2017.

Re:Alot of the stuff comes from a dos / win 3 / 9X (1)

DarkOx (621550) | more than 2 years ago | (#38780141)

Actually lots of this stuff is hardened x86 machines running DOS, and some Windows 3.x and 4.x (Windows '95 '98 etc) stuff as well.

Re:Alot of the stuff comes from a dos / win 3 / 9X (1)

thegarbz (1787294) | more than 2 years ago | (#38780263)

If by lots you mean a few special purpose tool rather than the 4 or 5 big companies who control most of the worlds industry then sure.

There's no arguing that some of them run some form of x86 instruction set, but they have very little in common with a PC, and if anything more of them have a background that is Unix based rather than DOS. I'm sure there's some small name RTUs that have some system like that, but the big names like Allen Bradley, Foxboro, Honeywell and (the guys who started this security mess) Siemens, have nothing in common with PCs at all other than needing one for administration.

two decades old = lack of funds to update or PHB (1)

Joe_Dragon (2206452) | more than 2 years ago | (#38777961)

two decades old = lack of funds to update or PHB who think if it's running now we don't need to update them or ones who say we don't need on staff IT outsource it and the outsourcing puts them on web so they can do remote admin or maybe the IP part was to be on the inside network only and some one put it on the web maybe becomes they don't know what they are doing or maybe so some can remote admin it.

Non IT engineers running the show may be at falt (1)

Joe_Dragon (2206452) | more than 2 years ago | (#38777999)

Now there are a lot of places where engineers (non IT) run the a lot of hardware and keep IT out of it and over time more and more has moved to IP / windows / + outside venders and what you get is people who may know what they are doing with the hardware but not the under laying IT side. golf courses meeting with mangers do not help as then you can end up getting some piece of software dumped on you that may not even work that well.

Re:Non IT engineers running the show may be at fal (1)

deniable (76198) | more than 2 years ago | (#38778401)

It's also the engineers who have moved / been moved into management or sales. If they weren't senior, they'd be out the back accounting for bolts. As it is, we had enough trouble convincing them that a good lawyer can't find a loophole in the laws of gravity and thermodynamics.

Re:Non IT engineers running the show may be at fal (0)

Anonymous Coward | more than 2 years ago | (#38782771)

YES!

The engineers that use this equipment don't want anyone looking over their shoulders. They tell management that everything is fine all the while keeping it patched together with duct tape. If IT does want to get involved the engineers run to their management, screaming. "The IT guys will stop us from producing X. Do you want the IT department involved with our production?" Typically the engineers who use the SCADA systems report up through different executives. The executive responsible for producing the product tells the CEO, "If IT gets involved I'm no longer being hold solely responsible for producing X. What do you want to do?" The CEO will alway choose the devil he knows.

So the SCADA systems continue to run on Windows 95, Windows NT, Windows XP, and in most cases unpatched versions, lacking anti-virus, with no Intrusion Detection, nor logging, nor monitoring, or robust authentication, or in some case personally identifiable authentication.

It's just like the airlines prior to 9/11. For years security experts were calling out the huge gaping holes associated with air travel. Simple changes that would have made 9/11 impossible, but nothing was done because it was too hard, too costly, too much work. Bottom line, no one wanted to be bothered.

The SCADA industry will have their 9/11 and then there will be Department of Homeland Security agents sitting in Waste water treatment plants, nuclear power plants, water plants, chemical plants, and prisions.

Why is this News? (0)

Anonymous Coward | more than 2 years ago | (#38778017)

Did they get a grant for this? Almost anyone who works in this field and knows what a TCP/IP port is could produce a overwhelming list of security flaws.

So now we'll see network segmentation proposals "Don't put controls on you corporate network". Stuxnet proved that was useless.

You don't get a budget for preventing a possible problem, so until there are some comprehensive exploits nothing will happen. Problem is, that those exploits could take down the power grid, or water/waste water or almost any major utility.

And this is news? (1)

Anonymous Coward | more than 2 years ago | (#38778061)

Wait until they get to analyze the GPU processing...

No security at all. DMA in/out to any address desired. Assumptions made about the runtime library loaded with the application, assumptions made about memory handling, assumptions made about I/O.

Completely Irresponible (3, Interesting)

Anonymous Coward | more than 2 years ago | (#38778137)

This series of zero-day public disclosures is an abhorrent act that violates most any professional or ethical code out there.

As these vulnerabilities impact devices which are known to be networked, as well as being in control of critical infrastructure, these "researchers" have at their disposal US-CERT/ICS-CERT, as well as direct contacts with the vendors in question.

They chose to turn this into a marketing stunt to sell tickets to their conference and to attempt to sell consulting services to the control systems industry. Luckily, I see this, and I will NEVER recommend that Rapid7, Dale Peterson, Digital Bond, Dillon Beresford, Jacob Kitchel, Tenable Network Security, or Ruben Santamarta be allowed near ANY critical systems.

These individuals have shown their true colors. The vendors WANT to play along, they WANT to increase security. Instead, these fools did a complete end-run around them and just dropped EXPLOIT CODE into the hands of everyone in the world. These "researchers" clearly do not care about the users of these systems, just the $$ they can milk out of the newly instilled fear.

Re:Completely Irresponible (2, Funny)

deniable (76198) | more than 2 years ago | (#38778405)

Very funny. We've all known these things are vulnerable for more than a decade and nobody has done anything about it. The shame of these researchers is not divulging the information but in picking such low-hanging fruit. This is like discovering holes in Outlook 97.

Evil electrons provoked by evil magnetic pulse. (0)

Anonymous Coward | more than 2 years ago | (#38778173)

Under the Electro-Magnetic-Pulse (EMP), they (the SCADA hardwares/softwares) failed to pass the certification of reliability of this life-critical complex system.

JCPM

Correction Facilities PoC hack (video) (1)

siberian (14177) | more than 2 years ago | (#38778185)

At a recent convention some researchers demonstrated a proof of concept hack they developed that allowed them to control many aspects of correctional facilities. Things like, oh you know, opening cell doors but showing them as closed on the guard terminals. Things like that.

Interesting preso : http://www.youtube.com/watch?v=C7O7HxHSHE0

One more quote (3, Insightful)

TubeSteak (669689) | more than 2 years ago | (#38778191)

The wired.com article has this choice quote
http://www.wired.com/threatlevel/2012/01/scada-exploits/ [wired.com]

"I didn't want a vendor to jump out in front of the announcement with a PR campaign to convince customers that it wasn't an issue they should be concerned with," Wightman said.

I can't imagine the type of two faced dickery it would take to spin weaponized exploits as something not to be concerned with.

Re:One more quote (1)

deniable (76198) | more than 2 years ago | (#38778413)

Imagine an Apple / Microsoft security non-advisory but with real money and possible jail time involved.

Re:One more quote (1)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#38778441)

I can't imagine the type of two faced dickery it would take to spin weaponized exploits as something not to be concerned with.

Which is why the world has lobbyists and advertisers to handle the job...

Re:One more quote (0)

Anonymous Coward | more than 2 years ago | (#38778619)

When page one of the manual says:

"don't connect to any network that has the POSSIBILITY of being insecure in ANY WAY"

It's easy to say:

"There's nothing to be concerned about, as long as the implementer's have RTFM!"

rockwell enbt (0)

Anonymous Coward | more than 2 years ago | (#38778225)

i just restarted an entire brewery because the ethernet card cpu utilization was up at a wopping 73% which is too high and causing intermittent messaging to other plcs. 78% is high right?

Again, Rule #1 would prevent problems (1)

geekprime (969454) | more than 2 years ago | (#38778435)

Rule #1 being that you do not connect control systems to the internet.
I don't care how good the hacker is, he can't overcome an airgap. Which leads to,
Rule #2 Train your people well enough not to fall for helping him.

Re:Again, Rule #1 would prevent problems (1)

0123456 (636235) | more than 2 years ago | (#38778471)

Rule #1 being that you do not connect control systems to the internet. I don't care how good the hacker is, he can't overcome an airgap.

He can if those systems are connected to a Windows PC and someone plugs in a USB key so they can watch their pr0n while they work.

Re:Again, Rule #1 would prevent problems (0)

Anonymous Coward | more than 2 years ago | (#38778523)

Isn't that why you epoxy those USB hole things shut?

Saw a similar thing at GrrCON (1)

bannable (1605677) | more than 2 years ago | (#38778541)

Chris Roberts gave a presentation on a very similar issue at GrrCON and other places this year.

GrrCON video of his presentation can be found here [youtube.com] .

But GE operates to 6 Sigma Quality (1)

BoRegardless (721219) | more than 2 years ago | (#38778657)

So...GE makes jet engines and PLC controllers both to 6 Sigma. How come I don't feel as good about flying now?

Wikipedia: "Six Sigma originated as a set of practices designed to improve manufacturing processes and eliminate defects, but its application was subsequently extended to other types of business processes as well. In Six Sigma, a defect is defined as any process output that does not meet customer specifications, or that could lead to creating an output that does not meet customer specifications."

WOPR (2)

Eyezen (548114) | more than 2 years ago | (#38778719)

Next we'll find out its not a good idea to have a POTS connection to the US War Operations Plan Response system

I'm just sayin (1)

axlr8or (889713) | more than 2 years ago | (#38779095)

2 brittle to be tested is part of security. I used to work on ATV's and one thing I found is that some companies do stuff like fill their electronics up with busted up glass and silica gel and rtv to be sure you don't get to see the electronics inside without destroying the unit. I'm talking about you overpriced Denso

Oops, pull those ethernet cables (1)

AbrasiveCat (999190) | more than 2 years ago | (#38779117)

I guess that is what I'll be doing Monday. Pulling the Ethernet cables on the controllers I have control on. It was nice to be able to check on the function on my PLCs over the "local" net, but it is time to play safe rather than sorry and disconnect them. (I had even been playing with a function last week where I ended up thinking, "ah it should do that. Someone could take this thing over(?)") Task two Monday. Send a email to my PLC company and see what they think. Task three, talk to our cyber security folk.

The times are (slowly) changing (2)

rat7307 (218353) | more than 2 years ago | (#38779347)

A lot of newer DCS gear is starting to have process firewalls being build in to the hardware at the controller layer. Also a change I've seen of late is that a lot of vendors software no longer runs ABSOLUTELY EVERYTHING at a privileged level as has been done in the past!!!

This should reduce the attacks on the PLC devices themselves, however the protection of the SCADA/DCS Servers (usually Windows Based) relies on GOOD system administration and knowledge about possible attack vectors..

Anything that straddles a corporate and process network NEEDS to be hardened, however more often than not this is the weak point (Process historians and other servers that provide end-user data are the biggest risk)

I've seen windows 2000 machines that are on both networks running 2000 SP1 and no later security patches THIS YEAR (Not a practice recommended by the vendor either, this was a customer who 'knew better').... lets also mention that it also had a VERY easy to guess Admin password!

Tis a scary world.

Most vendors have best practices for keeping nasties off the process networks, it's usually the customers who compromise to make their own life easier. Usually decisions made by the onsite IT people who, lets be honest, have NO idea about how/what a process system does. I work across many large sites and in general the IT people do not understand what is required and tend to be the ones who punch the massive holes in the firewalls to get things to work.

The vendors (I work for one) are now catching up by hardening things better at the hardware and software levels, but it's the legacy stuff that scares the bejeezus out of me!!!

well duh... (1)

FrozenFood (2515360) | more than 2 years ago | (#38779449)

well what do you expect? these devices use microcontrollers and are limited by size of memory in the chips. its not allways possible to secure to the Nth degree, so one must analyse the risk of the hardware provided. dont connect them to a public network. at most. connect the ethernet to a windows PC that can recive emails, but is not connected to the company LAN.

PLC hardware must remain hardware modules from 20 years ago, so its no good putting in the latest and gratest microcontroller in every year, if it breaks compatabilty for that RS232 card the company made 20 years ago.

in other news, dont send unterminated strings over TCP ethernet, i.e. without carriage return, to a toshiba robot. It will crash the controller in the robot and stop the process.

in further news, dont fill up your gas tank with water, dont hit your spouse and dont drive on your sidewalk.

1980s/1990s code (1)

pitzG (2551988) | more than 2 years ago | (#38779465)

In the products I've seen (including some of the source code), they were loaded with factory backdoors, sloppy coding, and many designs hadn't been updated since the mid 1990s.

Certainly doesn't help that a lot of the operators of these devices hire the cheapest engineers or techs they can find, usually without a good computer eng background.

SCADA are not PLC's (4, Informative)

gnalre (323830) | more than 2 years ago | (#38779541)

Ok, firstly SCADA and PLC's are two different things. SCADA is the HMI control system and PLC's are the parts that actually talk to the physical devices. While sometimes they are in the same box usually they are totally different devices. Secondly PLC's can be anything from windows PC's to low level simple processors. However they have one overriding concern and that is real time control of the plant hardware. This is why PLC's are hard to secure. Often they have not the power to run encryption algorithms required for security.

But they should not need to. Almost all of them are bespoke running closed simple OS, using proprietary languages. More importantly they should all isolated both behind physical security and network within a DMZ. That's not to say security cannot be improved, however these are not your PC's connected to the internet.

SCADA machines are more problematic Generally they are standard PC's running windows(Often quite an old version of windows). The very generic nature of the hardware and OS is its biggest weakness. As are their users. One of the problems we have encountered is viruses being stuck on PC's via USB sticks brought in from outside. We have even found games installed by bored users. So why not put antivirus software on them you may ask? Well the problem there is finding AV software which does not affect the operation of the SCADA software. Secondly is maintaining updates. To do that is either a manual process(not really feasible) or connect them to a central server or internet. This introduces an attack vector of its own.

STUXNET is always highlighted when these conversations come up, but this is misleading. If reports are to be be believed this was perpetrated by national agencies with all the resources that implies. No system is totally secure in that situation, the best you can hope for is to detect and delay. However most systems will never come under such a coordinated attack. Saying that it has concentrated the PLC industries mind on security, so thats not a bad thing, but we are no where near the Armageddon scenario that such articles seem to hint at

Re:SCADA are not PLC's (2)

naranek (1727936) | more than 2 years ago | (#38780207)

Nice post. Sorry I modded it flamebait.

I'm reading slashdot in a bus on a bumpy road and my finger slipped. So basically I'm posting to remove the mod. Ignore me. K thx bye.

Re:SCADA are not PLC's (1)

gnalre (323830) | more than 2 years ago | (#38781825)

LOL

Re:SCADA are not PLC's (1)

NevergoldMel (1210176) | more than 2 years ago | (#38782149)

I'm somewhat lost as to this "difficulty" finding AV software that won't interfere with the scada system. The only problem I've experienced was when I was supplied with a "security suite" instead of an AV package.

Re:SCADA are not PLC's (0)

Anonymous Coward | more than 2 years ago | (#38782797)

I'm somewhat lost as to this "difficulty" finding AV software that won't interfere with the scada system.
The only problem I've experienced was when I was supplied with a "security suite" instead of an AV package.

The problem is also maintaining updates.

Re:SCADA are not PLC's (1)

gnalre (323830) | more than 2 years ago | (#38785309)

It introduces another unknown in the system and can introduce unwanted side affects. We have found software whitelisting is generally more applicable to these sort of systems than traditional AV

Re:SCADA are not PLC's (0)

Anonymous Coward | more than 2 years ago | (#38787979)

I'm somewhat lost as to this "difficulty" finding AV software that won't interfere with the scada system.

No, the difficulty is PROVING THAT IT DOESN'T, for each and every update.
This means hours of system regression testing, which is mandatory for a mission critical system where downtime can cost millions.

PLCs were NEVER supposed what they are today (1)

Opportunist (166417) | more than 2 years ago | (#38779637)

PLCs come from the ages when "networking" was some wet dream of the die hard geeks (yes, both of them), when it was already a semi-miracle if things worked the way they should. Also the ages when speed was essential, room for the logic was scarce and generally .... fuck, you were happy you could cram the crap into the PLC at all without having to buy another expensive piece of hardware!

We're talking about ancient technology here. Sadly, it has never seen much of an upgrade. Compatibility, we love and hate you. Security took a back seat there because, hell, those things were expensive enough as it is!

And now add that these machines sell even if they're insecure and that security is a cost but no revenue factor and you know why this is anything but a surprise.

Biggest problem at my former plant (0)

Anonymous Coward | more than 2 years ago | (#38779955)

The biggest problem at my former plant is that management saw our SCADA system as a remote automation system. Instead of hiring night people, we all took turns monitoring from home in our free time. That's right, you work a full day, then have to monitor from home!

So what's the first thing they did with the million dollar SCADA system? Hook it up to the internet. Not change the passwords from defaults, those are still the same, not patch windows with the SCADA manufacturer's recommended patches, they're still running stock Server 2003.

HW Engineers Should Not Design SW (1)

billybob_jcv (967047) | more than 2 years ago | (#38780793)

I've seen it a million times and it's always a disaster. Just look at the user interfaces for the vast majority of appliances & peripherals - ghastly...
 

ONCE AGAIN... (0)

Anonymous Coward | more than 2 years ago | (#38783153)

ONE MORE TIME:
You DO NOT put your PLCs or SCADA networks in connection with the Internet. Period.
These devices are made for control, not security. If you are that much of an idiot, you deserve what you get.
There are many great read-only solutions, if you need to see what your plant is doing from a ways away.
The alternative? "Security Hardened" PLCs, whose price will double or quadruple. "Secure" SCADA software , which will be even more pricey than it already is. The control world, and the office worlds are TWO DIFFERENT WORLDS, and woe to he who will try to join them.
Since hackers have demonstrated that NOTHING is really secure, the only real security is this:

DO NOT CONNECT YOUR CONTROL NETWORK TO THE INTERNET.

If you really need to, for example, to allow short-time access for engineers or programmers, then unplug the connection afterward. No hacker can make electrons jump a gap in a wire. That's it, those are the facts.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Create a Slashdot Account

Loading...