Slashdot Mirror


New Siemens SCADA Vulnerabilities Kept Secret, Says Schneier

From the article: SCADA systems -- computer systems that control industrial processes -- are one of the ways a computer hack can directly affect the real world. Here, the fears multiply. It's not bad guys deleting your files, or getting your personal information and taking out credit cards in your name; it's bad guys spewing chemicals into the atmosphere and dumping raw sewage into waterways. It's Stuxnet: centrifuges spinning out of control and destroying themselves. Never mind how realistic the threat is, it's scarier." What worries Bruce Schneier most is that industry leader Siemens is keeping its SCADA vulnerabilities secret, at least in part due to pressure from the Department of Homeland Security .

119 comments

  1. Read it before by ge7 · · Score: 1

    Uh oh, this story looks exactly like this story.

    1. Re:Read it before by McGiraf · · Score: 2

      Uh oh, this comment looks exactly like this comment.

    2. Re:Read it before by avgjoe62 · · Score: 1

      That was fun! Can we do it again?

      --

      How come Slashdot never gets Slashdotted?

    3. Re:Read it before by Chris+Mattern · · Score: 2

      Sure! "It's just a jump to the left, and then a step to the riiight..."

    4. Re:Read it before by ShadoHawk · · Score: 1

      "Put your hands on your hips!"

  2. I find the idea by Chrisq · · Score: 0

    I find the idea of Iranian centrifuges spinning out of control and destroying themselves comforting rather than scary. Its a shame teh same hasn't happened to Pakistan.

    1. Re:I find the idea by smelch · · Score: 2

      Yeah, well how would you like incubators for human babies to start spinning out of control and destroying themselves?

      I'm not so worried about what terrorists might do in a cyber attack, I'm worried about the trolls.

      --
      If I can just reach out with my words and touch a butthole, just one, it will all be worth it.
    2. Re:I find the idea by Black+Parrot · · Score: 1

      Yeah, well how would you like incubators for human babies to start spinning out of control and destroying themselves?

      Do incubators spin?

      --
      Sheesh, evil *and* a jerk. -- Jade
    3. Re:I find the idea by smelch · · Score: 1

      You mean incubators for babies aren't the same as the incubators in Jurassic Park?

      --
      If I can just reach out with my words and touch a butthole, just one, it will all be worth it.
    4. Re:I find the idea by Gilmoure · · Score: 2

      We're incubating troll babies?

      WAH?

      --
      I drank what? -- Socrates
    5. Re:I find the idea by countertrolling · · Score: 1

      You all keep on pissing and moaning about Iranian nukes, while part of the new Saudi arms deal is to protect future Saudi nuclear ambitions.. which, by the way, also involves Pakistan (had to use google cache to get the whole article)

      And what did this clown ever do to deserve all those medals?

      --
      For justice, we must go to Don Corleone
    6. Re:I find the idea by drinkypoo · · Score: 1

      Yeah, well how would you like incubators for human babies to start spinning out of control and destroying themselves?

      Not really an issue here on earth, maybe on a space station it would be a consideration. Or were you thinking of Fetus Harvesters?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    7. Re:I find the idea by torgis · · Score: 3, Funny

      Spinning Incubator Babies would be a really excellent name for a rock band.

    8. Re:I find the idea by Black+Parrot · · Score: 1

      Spinning Incubator Babies would be a really excellent name for a rock band.

      Spin, Baby, Spin!

      --
      Sheesh, evil *and* a jerk. -- Jade
    9. Re:I find the idea by thePowerOfGrayskull · · Score: 1

      Only those manufactured by Rhetorical Devices Inc.

    10. Re:I find the idea by kmoser · · Score: 1

      It would be made up of former members of Scraping Foetus Off The Wheel.

  3. If it did cause an accident... by AmiMoJo · · Score: 3, Insightful

    Seems like Israel and the US are playing a dangerous game here. Say that Stuxnet caused an accident that released radioactive material into the environment...

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    1. Re:If it did cause an accident... by Lehk228 · · Score: 2

      the whole thing would have been denied and covered up instead of bragged about.

      --
      Snowden and Manning are heroes.
    2. Re:If it did cause an accident... by MRe_nl · · Score: 2, Interesting

      The Japanese nuclear plant in Fukushima ran on Siemens computers that the Stuxnet worm was programmed to infect- in fact the virus was found in Fukushima systems last year.
      Makes you wonder why the cooling system wasn't functioning. Maybe the tsunami caused failures which Stuxnet made the reactors unable to handle.
      Failures at four other plants in Japan, German and South African reactors shut down.
      Using Siemens systems as well?

      --
      "Kill 'em all and let Root sort 'em out"
    3. Re:If it did cause an accident... by rubycodez · · Score: 2

      Quit reading tin hat nonsense sites. Have you seen the 1970s systems that control those GE Mark I's? No virus exists for those old things

    4. Re:If it did cause an accident... by gl4ss · · Score: 1

      neglible amounts, if any. the real why it would end up in atmo would have been the faults of the engineers working at the plant. if you don't know how to build control systems, you shouldn't be building a nuke in the first place.

      anyhow, scada networks, because of how practically all of them are designed, should be separated from untrusted networks anyways, and preferably all control going through some bridge that wouldn't pass "wrong" things - better yet, all control should pass through a human - but this depends on the specific use, really, as we don't have android typists acting as super firewalls(like in gits), who would want to type some textile pattern? nobody. you should treat them like your one-wire whatever networks, or like your local usb running on your table - if some attacker has access to that then what surprise it is that he can make the keyboard type "format c:".

      of course there should be SOMEONE who knows what the machines should be doing, how and why. like the plant manager, chief engineer and etc, too bad good guys to fill those spots don't grow on trees... but that is not news.

      --
      world was created 5 seconds before this post as it is.
    5. Re:If it did cause an accident... by Yvanhoe · · Score: 2

      Of course you have the sources for that ?

      From what I understand, stuxnet was targeting unrichment facilities, which is very different from what Fukushima is.

      --
      The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
    6. Re:If it did cause an accident... by Svartalf · · Score: 4, Informative

      Stuxnet doesn't "target" anything other than Windows SCADA systems (which should cause concern when you see those three words together...), notably those from Seimens. Anywhere you've got one of those SCADA systems, you've got a possibility of Stuxnet. It's just that Iran was using them for their process control systems for the enrichment plant.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    7. Re:If it did cause an accident... by PremiumCarrion · · Score: 1

      If there was an accident surely all the danger would be in Iran. Why would Israel and the US be playing a dangerous game?

    8. Re:If it did cause an accident... by Anonymous Coward · · Score: 0

      It would be blamed on "TEH TERRORISTS" of course. Maybe added for a "cyber" to appeal to the true retards of incompetence.

      Logic of the egomaniac retard: "You have attacked my fist with your face! So I will punish you for it, by punching your face even harder!"

    9. Re:If it did cause an accident... by dachshund · · Score: 3, Interesting

      Stuxnet doesn't "target" anything other than Windows SCADA systems (which should cause concern when you see those three words together...), notably those from Seimens. Anywhere you've got one of those SCADA systems, you've got a possibility of Stuxnet. It's just that Iran was using them for their process control systems for the enrichment plant.

      Stuxnet targets a Siemens centrifuge controller that's programmed by an (air-gapped) Windows machine. Unfortunately this same basic pattern repeats itself all over the place.

      For any given SCADA system --- regardless of manufacturer --- you're extremely likely to see it connected to a modern PC, typically a windows machine. Even if the Windows machine is just running a terminal program, it's connected.

      What Stuxnet showed us is that these Windows boxes are a critical vulnerability, even if they're just an ingredient in the programming chain, even if the box is separated by an air gap. I'm sure Israel/US would have found a way to those centrifuge controllers, but without the Windows infection vector it would have been a whole hell of a lot more difficult.

    10. Re:If it did cause an accident... by heathen_01 · · Score: 1

      Yes, they should have been using macs. They don't get viruses.

    11. Re:If it did cause an accident... by kvvbassboy · · Score: 1

      What? If it is connected to a Linux machine, they will program Stuxnet to work with Linux. Or are you implying that non-Window machines are invulnerable?

    12. Re:If it did cause an accident... by turing_m · · Score: 1

      I think he meant in terms of danger to people's lives, not blowback.

      --
      If I have seen further it is by stealing the Intellectual Property of giants.
    13. Re:If it did cause an accident... by cavreader · · Score: 1

      I'm sorry but I must have missed the proof that the US or Israel was responsible for Stuxnet. But of course actual facts are old fashion and can be quite problematic when the don't support your world view.

    14. Re:If it did cause an accident... by TubeSteak · · Score: 3, Informative

      Stuxnet doesn't "target" anything other than Windows SCADA systems (which should cause concern when you see those three words together...), notably those from Seimens.

      You might want to do a little more research on the matter.
      Stuxnet's code has been picked apart: the trojan was designed to infect SCADA systems, but only to attack very specific hardware configurations.

      Stuxnet's payload was designed to (1) spin the uranium centrifuges used by Iran at certain known-to-be-destructive RPMs,
      (2) lie to the monitoring software which was supposed to prevent out of bounds conditions and set off alarms if they occur,
      and (3) should 1 & 2 not ruin the centrifuges, Stuxnet would go dormant and reawaken to try (1) and (2) again.

      Stuxnet is completely harmless unless you happen to attach the exact same hardware the Iranians had plugged into their SCADA controllers.
      Just to be very clear: Stuxnet's payload was specifically crafted to attack the known configuration of Iran's uranium centrifuging program

      --
      [Fuck Beta]
      o0t!
    15. Re:If it did cause an accident... by Antimatt3r · · Score: 1

      Actually Stuxnet does have a target. Each Siemen system has a unique serial number. Stuxnet only manipulated systems with certain serial numbers and it so happens that these serial numbers only existed in Siemens systems in Iran.

    16. Re:If it did cause an accident... by omglolbah · · Score: 1

      Most of the oil rigs in the North Sea and the land plants supporting them are programmed using windows XP machines.
      Some of the rigs also have HMI systems (800xA by ABB) that run on win2003 servers.

      There really are no modern control systems that do not have a windows component.. not if they have the feature-set required by most customers.

      It isnt remotely perfect, but the options to avoid it are extremely limited.

    17. Re:If it did cause an accident... by Wintermancer · · Score: 1

      Jus en Bello.

      In the event that a cyber attack did cause collateral damage (unlikely, in this case, but maybe not for future ones), whomever is pressing the launch button better be in uniform.

      Why? Military operations against actual targets are legitimate acts of military aggression. The Laws of Armed Conflict (LOAC) are the legal basis for determining whether an act is legitimate act or a war crime.

      This is why we don't prosecute fighter pilots for targeting a bus with a JDAM, that is known to be carrying Al Queda operatives along with their wives and children (this is a gross oversimplification, but you get the point). Civilian casualties are regrettable, but kinetic operations are not going to be shelved on that basis alone. If a civilian pulled the trigger to release that JDAM, they would be guilty of murder. Same thing applies to cyberwarfare operations.

      Welcome to the future.

    18. Re:If it did cause an accident... by sjames · · Score: 1

      Government officials care only about their own lives and those of their friends and family. That's why we can have wars. Note that the draft exemptions are generally met by the family of anyone who is involved in mandating a draft.

    19. Re:If it did cause an accident... by Anonymous Coward · · Score: 0

      What he is saying is that a hardened GNU/Linux or BSD system is a harder target. Not that they are invulnerable. The bugs in a free platform can be fixed whereas not so in a non-free environment like Microsoft Windows or Mac OS X. GNU/Linux also doesn't have the vectors in which these viruses come in on. You can disable the installation of software from outside of a main secured repository which you control. Sticking in a flash drive would not likely have been a vector. That isn't to say that there aren't any bugs in GNOME's nautilus file manger. What we're saying is a SECURED environment wouldn't let a user open nautilus the first place. You don't have auto-run on by default and macros are off. Just about every kind of scripting is off for that matter. You can also place programs you need to run behind a walled garden so that in the event of a vulnerability it is much more difficult to escape.

    20. Re:If it did cause an accident... by lennier · · Score: 1

      Civilian casualties are regrettable, but kinetic operations are not going to be shelved on that basis alone.

      Wow, that's cold.

      It's easy for you to say that when it's not your wife and children on that bus. If they were, you might have a different view on whether or not merely being a uniformed cog in an industrial death machine should allow "regrettable" murders to be shrugged off as if they were heavy rainfall.

      Funny thing is, I thought I was taught in high school that the "can't prosecute me, I was just following orders, sir" defence was smashed apart at Nuremberg. Apparently that wasn't the case?

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    21. Re:If it did cause an accident... by Anonymous Coward · · Score: 0
    22. Re:If it did cause an accident... by dachshund · · Score: 1

      Yes, they should have been using macs. They don't get viruses.

      But in all seriousness, the question I would ask is: how many known USB drive infection and privilege escalation vulnerabilities can you download for a 1-year-unpatched* Mac right now. How many can you download for the same Windows machine? In each category many have already been weaponized? How many of these can be tied together with widespread malware vectors that will get them near the machine to be infected?

      Of course many of the same vulnerabilities exist for the Mac and for Linux. The difference is that they haven't been discovered, widely publicized and weaponized. You could do all of these things given the resources --- e..g, if you were a nation state.

      But if you're not a nation state, then the availability of cheap exploits is what makes Windows machines such a terrifyingly weak link in the security chain, and something you can attack remotely on a relative shoestring. The fact that it's not being done is simply an illustration that the people who know how to do this stuff are not the same people who want to kill Americans. Right now.

      * A generous description of many of these air-gapped SCADA machines.

  4. Sometimes a SCADA hack is a good thing by Anonymous Coward · · Score: 3, Funny

    How do you think Reese's initially got chocolate in their peanut butter?

  5. Call me naive or something, but... by Pecisk · · Score: 2

    ...simply good old network security with hardened OSes (Linux, BSD, OS X) with seriously turned off all other services, firewalls and proxies with filtering won't do a trick?

    Who is running industrial systems with direct contact with Internet anyway?

    --
    user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
    1. Re:Call me naive or something, but... by Anonymous Coward · · Score: 1

      ...simply good old network security with hardened OSes (Linux, BSD, OS X) with seriously turned off all other services, firewalls and proxies with filtering won't do a trick?

      Who is running industrial systems with direct contact with Internet anyway?

      Stuxnet infected the Iranian nuclear plan through USB.

    2. Re:Call me naive or something, but... by Anonymous Coward · · Score: 0

      Stuxnet got on the centrifuge controllers from USB sticks.

    3. Re:Call me naive or something, but... by Anonymous Coward · · Score: 0

      Who is running industrial systems with direct contact with Internet anyway?

      Not the Iranians. They ran a proper air-gap separation between their enrichment systems and the Internet.

      Not that it made any difference to the CIA and Mossad.

    4. Re:Call me naive or something, but... by Lehk228 · · Score: 1

      iirc the wild form of stuxnet was not the same as the one that hit iran, theirs was placed by a spy, not spread "naturally"

      --
      Snowden and Manning are heroes.
    5. Re:Call me naive or something, but... by Pecisk · · Score: 1

      And excuse of sticking USB without security protocol (can't execute stuff from USB drives) is...? Still similary stupid to connecting boxes to Internet.

      --
      user@ubuntubox:~$ stfu This server is going down for shutdown NOW!
    6. Re:Call me naive or something, but... by wiredog · · Score: 2

      Many systems are remotely accessible, just not over the internet, and no one thought that heavy security would be needed. Even though those networks were getting compromised back in the 60's.

      Just pulling the cable when remote access isn't needed is a highly effective, and often neglected, security practice.

    7. Re:Call me naive or something, but... by newdsfornerds · · Score: 0

      It won't do the trick because the vested interests wouldn't get paid as much. What are you, a commie? jk

      --
      Damping absorbs vibrations. Dampening is caused by moisture.
    8. Re:Call me naive or something, but... by jimicus · · Score: 4, Insightful

      I'm not sure it would have done much good. The general consensus of opinion is that this was a case of a determined attacker with a lot of resources, not some nutter on the Internet with a copy of the latest Virus Generator Toolkit (TM).

      How much weight we should give that opinion is something I'm not going to discuss.

      In any case, you think a determined attacker is going to be put off by a small thing like that? Hell, if it boils down to it you either organise double agents to apply for jobs at the target site or you target someone who already works there with a brown envelope full of unmarked, non-sequential notes. The latter is high risk, but find the right person, someone who's in debt up to their eyeballs and has been keeping it from their family for some time perhaps, and away you go.

    9. Re:Call me naive or something, but... by Anonymous Coward · · Score: 0

      This typically is not a problem of systems being Internet connected. The Iranian systems, for instance, were not. They operated on a closed network, but the human factor was exploited in order to infect. As others have pointed out, even without Internet connectivity, there is always some means of external access as various systems are geographically diverse and the need for communication is present. Any time there is any form of outside connectivity, there is vulnerability. The crux of the problem is that these systems were never built with security in mind. It's an afterthought. The efforts now revolve around retro-grade securing. What is needed is a complete redesign that includes security and filtering at every level, including out at the most remote piece of field hardware connected to the system.

    10. Re:Call me naive or something, but... by Maximum+Prophet · · Score: 1

      no one thought that heavy security would be needed

      Who is this imaginary "no one", that never thinks anything could go wrong? I and all my friends who grew up watching "War Games" are always thinking about how things could go wrong.

      It always seemed to me that what "no one" is thinking is not that bad things can happen, but "I'll put in just enough security so that the failure won't happen until after I retire."

      --
      All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
    11. Re:Call me naive or something, but... by Charliemopps · · Score: 0

      Imagine a power plant that takes little to no intervention throughout the year. At most the engineer(s) only need to make adjustments when changing out fuel rods or during an emergancy. Now imagine the engineers that make these changes make $200k+ a year and your company has 10 such reactors. Introduce the internet and... profit!!!

    12. Re:Call me naive or something, but... by Black+Parrot · · Score: 2

      Just pulling the cable when remote access isn't needed is a highly effective, and often neglected, security practice.

      I tried that, but my screen went black.

      --
      Sheesh, evil *and* a jerk. -- Jade
    13. Re:Call me naive or something, but... by cshake · · Score: 1

      I'd imagine it would be because the company that makes the machines that you're controlling only make drivers and control software for their own special computer systems that you have to buy from them. The advantage there is that if any part of the system goes wrong, from computer to end product, you have a single point of contact to get support from.
      I think the mistake that many people on /. make is thinking that everyone is a 'computer guy', where in reality the people running these computers just know how to work the interface itself and not anything below the hood, so calling external support is very valuable.

      And I bet a random *nix box that your friend in IT sent you wouldn't pass their ISO xxxxx certification.

      As for internet connection, they must all be hooked up to an internal network at least for logging and alerting other systems in case of problems, but having that network also connected to the web is beyond me.

    14. Re:Call me naive or something, but... by Anonymous Coward · · Score: 0

      ...simply good old network security with hardened OSes (Linux, BSD, OS X) with seriously turned off all other services, firewalls and proxies with filtering won't do a trick?

      Who is running industrial systems with direct contact with Internet anyway?

      Stuxnet was USB-loaded...

    15. Re:Call me naive or something, but... by Anonymous Coward · · Score: 0

      Reality. To everyone who says they don't get it on the internet. Reality.

      These PLCs are expensive little pieces of hardware. The "engineers" (they are not engineers by training or trade, but that's the title unless you're in Canada) that know how to program and configure them start at about 90 an hour unless you own them as an FTE, which of course--the large corps do.

      Depending upon the solution purchased they may either integrate solely with a specific version of windows, or solely with a specific piece of hardware that transmits data over bluetooth/microwave/radio/cellular/segregated IP or one of the 'wire' protocols developed for collection and control. This box will push either to a proprietary webpage over an unknown network, or wire the data back home by any number of protocols you can imagine. They *really* like FTP push.

      If you're using a MUCH more power intensive system than many, these may even talk directly over the internet--in particular, the cellular solutions are dramatically cheaper this way. With modern hardware, you can get PPTP and L2TP support, although it's easier to just use TLS and a heavily firewalled webserver that only tolerates a single port. Some people are so cheap they'll just use a self signed key that expires in 20 years... you can recognize it in the client as long as it doesn't change...

      Command and control can happen over a wholly RESTful architecture, which means your programmers are now...a dime a dozen in India if you have a versatile embedded solution.

      But I mean...those are what I call "cheap" trade offs. People cutting corners with cost and willingly trying to make "reasonable" security compromises that frankly still have questionable judgment, but you can easily conceive of situations where it is appropriate.

      There's much scarier unreasonable ones...

      To see a real example, google for Scott Lunsford...who gave a presentation at Defcon IIRC about 2006 or so (IIRC)--the man successfully penetrated a nuclear power plant. And...it was easy. Now, ignore that "in your network" the person that screwed up would have been fired. That you scan for these machines and rogue AP's... I'll let you blissfully ignore the coming ipads, androids, iphones and consumer hardware that your managers will be demanding hookup in the next few years... call that point temporarily conceded.

      The point...and the business utility of Scada systems--demands connection to ... the internet. It's that "information wants to be free" meme. Your devices report in--the data is aggregated in a reporting system, a database, a file server. Your accountants, engineers, field officers all want access to it--summaries, supports, statistics, trends, correlation analysis, pretty charts generated in Excel. The most successful marketing we had was directly to C-level or higher (board itself).

      Now, you can carefully craft and architect a one way data flow. And for 90% of the "pure monitoring" it may be sufficient. But that other 10%--you get huge value from remote control. And of course, some markets are all about nothing but control and feedback. And SCADA, like anything benefits from economy of scale and standards--it can be cheaper to put the same multifunction device out in the floor with 4 or 40 different feeds than it is to train your team in ten custom appliances. And of course, requirements may change after installation--better to have that remote control turned on, or at the absolute most have a way to push an OTA update to enable it.

      From there, you should see why it's inevitable these are on the Internet. Nobody wants to get up, walk from their reporting station over to the "control terminal" on a separate network that corporate had to invest extra money in. Extra wiring, extra computers, extra os licenses, extra control software license, extra training, desk space, power....

      Windows is secure enough to run their accounting, domain service, file sharing and protect their CAD. And Internet Explorer is secure enough to control the chemicals and pressures of their industrial process....

      Scary? Yeah--it fucking terrifies me. But I wrote some of it, and it's no more or less negligent than the rest of business as usual.

    16. Re:Call me naive or something, but... by Anonymous Coward · · Score: 0

      Several large utility companies

    17. Re:Call me naive or something, but... by nnull · · Score: 1

      Quite a lot of people lately. Management wants to see their production on their office computers. They're easy to network and of course easy to hack. Siemens is not the only one vulnerable here, *cough* Schneider *cough* Schweitzer *cough* ABB...

    18. Re:Call me naive or something, but... by wiredog · · Score: 1

      Why would you need heavy security for something that is air-gapped? If the Bad Guys (TM) get physical access you've lost anyway! We didn't even require passwords for access, because the keyboard was locked in the control cabinet. The only time it was networked was when someone hooked up a modem so it could be remotely debugged or upgraded. After which the modem was disconnected.

    19. Re:Call me naive or something, but... by thegarbz · · Score: 1

      Who is running industrial systems with direct contact with Internet anyway?

      Here's a thought, why does it matter? So far there has been only one demonstrated attack on a SCADA system, and that attack didn't use the internet as its vector.

      SCADA systems benefit greatly from being connected to the world, but not directly. There should be many tiers of security both virtual and physical. It is the physical security here that was lacking. The best airgap in the network doesn't help you if one of your underlings plugs an infected USB stick into a machine on the process control network.

  6. Secure the perimeter by elh_inny · · Score: 0

    I would leave exposed SCADA interface in the open, after Stuxnet it should be clear that securing SCADA interfaces should be done on a higher level - by putting it in a different VPN etc.
    Whether the vulnerabilites are public or not doesn't change the fact that a given setup is secure or insecure by design...

    1. Re:Secure the perimeter by drinkypoo · · Score: 2

      Now imagine the scenario where you have windows machines on the same network as your SCADA devices because the tools you've bought or built work this way. Someone attaches an unauthorized device to your network and fail, fail.

      Now, I think we can probably agree that you can and should take steps to prevent something like that from happening, but there is the issue of getting from point A, where your network is insecure, to point B, which requires at least buying or developing a whole bunch of new software. This is non-trivial and it costs a lot of money so a lot of operators probably weren't even looking at it until recently.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Secure the perimeter by Black+Parrot · · Score: 1

      Now imagine the scenario where you have windows machines on the same network as your SCADA devices because the tools you've bought or built work this way. Someone attaches an unauthorized device to your network and fail, fail.

      Aren't those development tools rather than run-time tools? If so, isolate your system and get serious about how you allow stuff to be moved over to it.

      --
      Sheesh, evil *and* a jerk. -- Jade
    3. Re:Secure the perimeter by Interfacer · · Score: 4, Informative

      Not really. The process control is done on real-time controllers, but visualization is usually on windows machines. Data historians, configuration databases, OPC servers, etc are often Windows servers. Add to that that hotfixes and service packs have to be vendor approved before putting them on the live system. This means that those systems often run whatever was approved at the time of installation, which can be years out of date.

      Many SCADA and DCS systems are also horribly insecure, have default or hard coded administrative passwords, etc. What doesn't help is that they are often managed by people who are good at the actual process stuff, but not necessarily at security or system administration.

  7. Duh? by trifish · · Score: 1

    What worries Bruce Schneier most is that industry leader Siemens is keeping its SCADA vulnerabilities secret

    If you want to prevent the bad guys from exploiting a vulnerability, then don't... um... tell them about the vulnerability? But do tell the affected parties about it.

    1. Re:Duh? by Anonymous Coward · · Score: 1

      Yeah, security by obscurity. That works great. Keeps the world safe.

    2. Re:Duh? by nedlohs · · Score: 5, Insightful

      or fix it, that works really well too.

    3. Re:Duh? by markus_baertschi · · Score: 4, Insightful

      That is exactly what will not happen.

      The ones who should tell their Customers about the problem is Siemens. But they will play the problem down because it might affect the sales of the next batch of stuff.

      The evil hacker will just buy a bunch of systems, analyze it and find the vulnerabilities. This completely independent of the disclosure. Stuxnet was developed before this disclosure and I think the vulnerabilities used by Stuxnet are still there.

      This is why security by obscurity does not work in the real world.

    4. Re:Duh? by chaos.squirrel · · Score: 2

      If you want to prevent the bad guys from exploiting a vulnerability, then don't... um... tell them about the vulnerability? But do tell the affected parties about it.

      I think nuclear power plants and the like warrant something a bit more than security through obscurity...

    5. Re:Duh? by betterunixthanunix · · Score: 1

      Except that the bad guys have already been made aware of the vulnerability, since Stuxnet is out there for anyone to analyze. Do you think the Iranians have not been picking apart Stuxnet and trying to figure out how they can use it?

      --
      Palm trees and 8
    6. Re:Duh? by Svartalf · · Score: 1

      That's specifically not what they're doing...telling the affected people about it. They're keeping that information to themselves- because it might reveal the exploits in question. As for not disclosing because the bad-guys might figure it out...heh...keep fooling yourselves folks. The bad-guys almost always KNOW about them- it's why they call 'em "0-dayz".

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    7. Re:Duh? by Svartalf · · Score: 1

      The evil hacker will just buy a bunch of systems, analyze it and find the vulnerabilities. This completely independent of the disclosure. Stuxnet was developed before this disclosure and I think the vulnerabilities used by Stuxnet are still there.

      This is why security by obscurity does not work in the real world.

      Most definitely. Comments about someone not being able to afford to buy the devices not withstanding, it is very much what someone would do if they were to attack a system or come up with a new Stuxnet type piece of malware. Someone always has the wherewithal and resources to accomplish this sort of thing.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    8. Re:Duh? by thePowerOfGrayskull · · Score: 1

      And yet obscurity is a valuable tool in security. Absolutely it should not be the only tool - but discarding it completely is like saying we should discard firewalls because firewalls can't stop all attack vectors. They are all tools, and none is sufficient security on its own - but many different tools used in conjunction can make for a formidable defense.

    9. Re:Duh? by thegarbz · · Score: 1

      That is exactly what will not happen.

      The ones who should tell their Customers about the problem is Siemens. But they will play the problem down because it might affect the sales of the next batch of stuff.

      Speaking of real world this is something that doesn't happen on a typical control systems vendor. Your typical vendor releases pages of errata. Your typical vendor knows what you have purchased and your typical vendor typically comes running in with a fix be it hardware or software, or a temporary workaround while they are coming up with the fix.

      This has happened to us on many occasions. One instance a certain series of commands issued on the display graphic would cause an alarm manager to stop responding. We were told what was the problem was and a few days later someone came from the vendor with a software patch. A more extreme case from the same vendor was when a hardware fault was found in a batch of cards. The fault could in a remote circumstance cause an output to drop to it's failsafe state. The vendor replaced some 13 of the cards on site.

      This is exactly why we stay with the vendor. Failure of equipment doesn't have anywhere near as much influence as what gets done to manage that failure.

  8. DHS probably wants the security holes by Anonymous Coward · · Score: 4, Insightful

    Actually it's probably the CIA, NSA and other TLA's that truly want the security holes. They're just using the DHS as the mouthpiece to convince the companies to keep quiet and not plug the holes. After all, without those holes, Stuxnet (and likely other woms/viruses/trojans) wouldn't be as effective as they apparently have been.

    1. Re:DHS probably wants the security holes by fuzzyfuzzyfungus · · Score: 4, Insightful

      I'm not so sure: Obviously, assorted sinister TLAs are happy to exploit available holes; but all but the really stupid ones have to realize that they don't exactly live in a unipolar world when it comes to writing viruses, and that the US(and its assorted western buddies) have a lot to lose in an atmosphere of general SCADA-smashing.

      If all SCADA systems become deeply vulnerable, who loses more? Industrial or post-industrial societies with high levels of complexity that could be on the edge of collapse with a few days of supply chain disruption, or the dusty low-GDP countries of the world where disenfranchised hackers, cheap laptops(and/or exploits provided by friendly powers using them as proxies) are still easily available?

    2. Re:DHS probably wants the security holes by jonwil · · Score: 1

      If the CIA etc really wanted to infect these things, why wouldn't they just infect the machines at the factory then use a front company to sell them to IRAN or whoever on the cheap.

      I remember seeing a JAG episode once where the spooks deliberatly allowed some bad guys to steal an F-14 and extract its control software (knowing that the software was to be given to IRAN for an upgrade of its F-14s and knowing that the software was deliberatly defective) and I see no reason it couldn't happen in the real world.

    3. Re:DHS probably wants the security holes by Jaysyn · · Score: 1

      Didn't the CIA do something like this to the USSR concerning oil pipeline control software?

      --
      There is a war going on for your mind.
    4. Re:DHS probably wants the security holes by HeckRuler · · Score: 1

      There's another layer here. Having vulnerabilities allows TLAs to do sneaky things, empowers them, and helps them do their job. And you're right, those things cut both ways. But, having them cut both ways ALSO empowers the TLAs. They all got a big budget boost in the aught years. Security was suddenly a really important thing.

      So what the TLAs want isn't always their intended purpose.

  9. Security by Anonymous Coward · · Score: 0

    Whatever comes out of this, I don't want to be the one with Siemens in my face.

  10. Responsible Disclosure by Aladrin · · Score: 2

    Last I checked, 'responsible disclosure' meant giving the company time to fix the vulnerabilities before you released the info to the public.

    Am I missing the part where we've gone beyond that point?

    --
    "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
    1. Re:Responsible Disclosure by Anonymous Coward · · Score: 0

      Am I missing the part where we've gone beyond that point?

      Yes. If you follow the links from Schneier's article, the researcher talks about testing the proposed fix from Siemens and breaking it wide open in 45 minutes. They're also making noise about these hacks requiring "special laboratory conditions and unlimited access to the protocols", which to Siemens means you can buy a SCADA controller and plug it in to your local network. In other words, they can't fix the problems and are already using marketing tactics to blunt the impact of the bugs.

    2. Re:Responsible Disclosure by DMUTPeregrine · · Score: 1

      Responsible disclosure meant giving the company time to fix the vulnerabilities before you released the info to the public.
      So the companies stalled and never fixed the vulnerabilities, tried to sue the researchers, etc.
      Responsible disclosure came to mean giving the company a set amount of time to fix the vulnerabilities before you released the info to the public.
      So the companies kept threatening researchers, called the grace period "extortion" and such, stalled for more time to "test", and didn't fix the vulnerabilities.
      Responsible disclosure died, and full disclosure took its place. The researcher's ethical responsibility is not to the company with the flawed product, but to the customers. Having all the details of a vulnerability is pretty much always useful for mitigating that vulnerability until a fix is released, and having the vulnerability publicly known motivates companies to actually fix the flaw. Thus, full disclosure is reasonable.
      Some companies DO fix vulnerabilities when informed of them. With these it is reasonable to provide the grace period. If you do not know, it is reasonable to provide a grace period. 90 days is typical. If a company refuses to fix the flaws within the time, they forfeit their future grace periods.

      --
      Not a sentence!
    3. Re:Responsible Disclosure by Anonymous Coward · · Score: 0

      Well, what's exactly "responsible" about risking human lives by giving a vendor time to fix a bug instead of telling everyone, "hey, that machine over there can be hijacked and kill you"? I can sort of see the point of not releasing outright exploit code, even if it seems that's the only way some people will actually believe your claim, but it's rather funny how when actual human lives are on the line how much "responsible disclosure" doesn't seem very responsible at all. The only "responsible" thing to do is to inform as many people as early as possible that X is dangerous so people can stop using X; and if the vendor of X won't acknowledge the problem, even going as far as trying to block you telling people about the problems with X, then full disclosure seems a near necessity to convince people that X really is dangerous. Anything less seems rather irresponsible, like knowing about any other faulty product and sitting idly by as people are possibly hurt.

  11. NO!!!!! by SirTreveyan · · Score: 2

    It was peanut butter in their chocolate

    --

    SELECT * FROM User WHERE Clue > 0

    0 rows returned

    1. Re:NO!!!!! by sexconker · · Score: 0

      It was peanut butter in their chocolate

      Actually, no.

      The Reese's family made peanut butter cups and other confections. No chocolate, just creamy little cups (about the size of a caramel, or today's "mini" Reese's) of peanut butter and some stuff to make it hard on the outside.

      It was an accident when someone poured chocolate sauce into the the wrong reservoir, resulting in peanut butter cups with swirls of chocolate. Reese's family sold the recipe to Hershey's after his death. (This wasn't a slimy cash-in by his family - Reese had worked with Hershey before, and had great respect for him. Hershey inspired Reese to open his own candy shop, which exclusively used Hershey's chocolate.)

    2. Re:NO!!!!! by SirTreveyan · · Score: 1

      Jezzz...evidently you don't remember the commercials Reese's used to run all the time. Don't take things so serious.

      --

      SELECT * FROM User WHERE Clue > 0

      0 rows returned

  12. Perfect example by return+42 · · Score: 1

    Sounds like exactly the sort of thing Wikileaks exists for.

  13. No mention of anyone but Siemens? by Anonymous Coward · · Score: 0

    Seems odd to me that there is a lot of talk about Siemens but not Rockwell (by far the more popular PLC here in the US) nor Wonderware (a more popular SCADA platform in the US than Siemens), nor any talk of GE products (with higher market share in the power including nuclear market segments, again limited to in the US).

  14. Lifetime of a bug/hole by Tei · · Score: 1

    Hole/bugs lifetime is forever. If you find a bug or a hole, and you choose to ignore then, it will not go away. It will be there waiting for his moment to ruin your morning. Maybe bug/holes are not as important as people dedicated to the racketeer industry think. So if you can't fix then on the morning, you can fix then after the tea, if you fix then today.

    --

    -Woof woof woof!

  15. Industrial Control Systems by Anonymous Coward · · Score: 0

    Keep it internal and put an 'air' wall between the systems and the internet.
    By 'air' wall I mean disconnected from the internet. Only a fool would connnect say a reactor control system to the internet.
    However; we've seen the results of a fools work before...
    Remember what Murphy says:
    "Anything that can go wrong will go wrong and; at the worst possible time."
    Just ask the Japanese.

  16. Open Secret by adavies42 · · Score: 5, Informative

    I did my master's thesis on SCADA security. tl;dr: there isn't any. We're talking about an industry that uses unencrypted radio links in their control systems....

    --
    Media that can be recorded and distributed can be recorded and distributed.
    -kfg
    1. Re:Open Secret by Anonymous Coward · · Score: 1

      Believe me I know all about it, as I'm a guy that designs and puts those links in. I've been making a big push with the uppers for more secure links and it is starting to get in now. Licensed bands with AES etc. Previously it would all be modpacs or Canopy links. We're starting to move to licensed stuff with AES now, but damn near everything in this area was already done like this. Anyone could pretty much get on the network with the right know how. Most of the stuff is the water control systems for the cities/towns.

    2. Re:Open Secret by Svartalf · · Score: 2

      Heh... They're "thinking" about using crypto on things like the radio links. They're "concerned" about things like "latency" (Here's a hint, if you're worried about injecting a 1-2 character's worth of transmission time delay at 9600 baud, you're doing it wrong.) so the industry's been reticient at trying to at least lock down some aspects of the remote links. Biggest problem is the downtime of some systems in addition to the overall expense of things while they retrofit to higher data rates, end-to-end crypto (and not the security mode of DNP3 and other SCADA device protocols...), and security monitoring. Most of the "smart grid" security model's been predicated on security through obscurity and authenticated command and control with data being plaintext in most cases because that's the "least expensive" solution to the "problem".

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    3. Re:Open Secret by Anonymous Coward · · Score: 1

      Wait a second. Unencrypted *radio* links? Seriously? I sure hope it's for controlling the ice cream and chocolate factories of the world and not something important.

    4. Re:Open Secret by Anonymous Coward · · Score: 0

      Worked on embedded hardware mostly measuring but with some control over oil pipelines. Security concerns were pushed to the way far back burner. "It's never going to be plugged into the Internet".

      Embedded work was simply different. There was no processing power or complexity to allow for this sort of thing. The ONLY I/O for these things used to just be their serial port.

      That's changed and the industry is feeling the pains of scope change.

    5. Re:Open Secret by Myrcurial · · Score: 1

      Master's Thesis on SCADA Sec? Really? Published anywhere?

      SCADA security isn't. I'm sorry but it's true. And the entire "security industry" is talking just like all the slashtards commenting.

      Doing security right in this environment is non-trivial. The SCADA/ICS vendor community isn't providing it because SCADA/ICS customers aren't asking for it. The downside of course is that the SCADA/ICS customer is NOT the individual who is going to suffer when the screwups happen. The SCADA/ICS vendors and customers have externalized the costs of failure on the general public and no country-scale government is actually doing anything other than paying lip-service to the idea of dealing with aging/insecure infrastructure.

      If you want to see more - have a look at the talk I did at DEF CON 18 - it covers the situation nicely.

    6. Re:Open Secret by rabtech · · Score: 1

      Long ago, I worked as an IT admin for a grocery company that owned it's own bakery, ice cream, drink, etc plant. The "industrial control systems" I saw in use were the worst engineered pieces of junk I've ever encountered. I am talking unpatched Windows 95 systems running a crappy VB 4 UI, that talked to a poorly written VxD to control the ice cream mixer, which was a massive piece of equipment that could easily kill someone standing too close to it.

      I just got one of those TI $4 embedded development kits and while I applaud them for trying to draw in hobbyists and small companies, the SDK is a serious piece of crap. You might as well just write pure assembly... The C code is a mishmash of indecipherable macros and #defines that seriously look more like assembly than C. Forget about any kind of abstraction.

      From what I hear from my friends (one of whom used to program for defense embedded systems), it is all like that. Terrible platforms, terrible code, security through obscurity (if that), etc.

      The fact that stuxnet was able to exist? The fact that the video signals from some of our drones are broadcast unencrypted over the air? None of it is shocking in the least. It makes Microsoft IIS circa 1997 look positively secure and well-written by comparison.

      --
      Natural != (nontoxic || beneficial)
    7. Re:Open Secret by russotto · · Score: 1

      From what I hear from my friends (one of whom used to program for defense embedded systems), it is all like that. Terrible platforms, terrible code, security through obscurity (if that), etc.

      There's no practical way to defend the embedded system from the device which programs it. So while it's true that the tools use to program embedded systems are often primitive, it has little to do with attacking them.

      The fact that the video signals from some of our drones are broadcast unencrypted over the air?

      IIRC, that was due to
      A) A shortage of hardware in the field to decrypt the encrypted video and
      B) A lack of enemy capability to exploit the unencrypted video.

    8. Re:Open Secret by dargaud · · Score: 1

      I do control/command systems as well and there are many reasons why there's few if any security. One of them is that in the (rare) case of a reboot, you want the system back online automatically as quick as possible. You don't want to wait until 9am when the first employee who knowns the password can type it in... hence no passwords. Note: I'm NOT saying it's a good thing !

      --
      Non-Linux Penguins ?
    9. Re:Open Secret by adavies42 · · Score: 1

      Master's Thesis on SCADA Sec? Really?

      Yes, the cite would be something like

      Davies, Aaron G. "A Toolkit for Intrusion Detection in a SCADA Environment." MA thesis. University of Louisville, 2005.

      Published anywhere?

      Astonishingly, yes, at least if you count ProQuest. Not that I'd bother reading it (or at least anything but the background material) if I were you--it was basically about hooking up a SCADA emulator to Snort and an alert correlator to make a testbed you could deploy potential attacks against to see if your filter configuration worked. I have no idea if anyone ever did anything with it; I can't find any evidence that anyone's ever cited it, anyway.

      --
      Media that can be recorded and distributed can be recorded and distributed.
      -kfg
    10. Re:Open Secret by thegarbz · · Score: 1

      As the person on site somewhat responsible for managing encryption keys for wireless telemetry and wireless process control systems on my site I call bullshit. Either that or you did your thesis in the 80s oldtimer.

  17. anonK by Anonymous Coward · · Score: 0

    Antivirus went nuts trying to open the first link. xss
    http://jurelia.co.be/games/mario.jar a variant of Java/Agent.BP trojan
    2 of those followed by an ip address trying to dl an avi.

    1. Re:anonK by ledow · · Score: 1

      Seeing as you're the only one commenting on this, and I can't see it either, it's probably YOU that's infected, or you clicked something you didn't mean to.

      Hell, there aren't even any banner ads on that page at all.

  18. computer systems that control the real world? by doperative · · Score: 1

    "SCADA systems -- computer systems that control industrial processes -- are one of the ways a computer hack can directly affect the real world".

    Only if you connect the SCADA systems directly to the Internet and run them on top of Windows. Instead of running them behind a secure VPN connection running on embedded hardware.

    1. Re:computer systems that control the real world? by PPH · · Score: 1

      The problem with such systems is that they can be 'infected' through the programming platform. In the case of Stuxnet it was the PCs used to program the PLCs that were infected. And one of the vectors of infection was the use of infected USB flash drives on these (Windows) systems. Programming PLCs is often done through a direct cable connection, so while keeping industrial control systems off 'The Internet' may be a good idea, it isn't sufficient to prevent such an attack.

      --
      Have gnu, will travel.
    2. Re:computer systems that control the real world? by geekoid · · Score: 1

      This types of attacks should happen regardless of the OS.

      These are specifically targeted attacks, the manly take advantage of human trust.

      And yes, the SCADA systems need to be isolated, and then need to only allow access from specific machines.

      OTOH, that level of security is expensive, and for some reason everyone thinks infrastructure programs don't cost money. and all money the government gets is 'waste'.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
  19. backdoor by Anonymous Coward · · Score: 0

    Somehow I'm thinking that "vulnerability" is the new word for "backdoor".

  20. UR doin it rong! by wiredog · · Score: 1

    Pull the other cable.

    Not that one! You'll go blind!

  21. Hyperbole. "Out of control... destroying" by Anonymous Coward · · Score: 1

    "spinning out of control and destroying themselves"

    The image the author creates is of a machine spinning at such velocity it explodes in a shower of fragments. While that makes for great copy, it's hardly what happened. In reality, Stuxnet caused the affected centrifuges to alter their rotational speed by only a few percent, which resulted in lower material rendering in the cascading purification process. This result has several advantages to a "self-destructing" centrifuge. 1) a destroyed centrifuge is an obvious problem which would trigger immediate investigation, while a "drifting" (and misreported) spin rate is not easily discovered 2) an undetected problem tends to pollute product quality and lead to doubts and investigations of all areas of the manufacturing process -- wasting time and expert resources diagnosing the root cause
    I think you get the point.

  22. They shuod keep then secret by geekoid · · Score: 1

    there should also be strict government oversight to ensure the vulnerabilities are being fixed.

    --
    The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    1. Re:They shuod keep then secret by VortexCortex · · Score: 1

      there should also be strict government oversight to ensure the vulnerabilities are being fixed.

      ... And that the fixes don't make it to other governments. See: VUPEN's alleged Chrome exploit.

      VUPEN released a video of the exploit in action to demonstrate a drive-by download attack that successfully launches the calculator app without any user action.

      The exploit shown in this video is one of the most sophisticated codes we have seen and created so far as it bypasses all security features including ASLR/DEP/Sandbox (and without exploiting a Windows kernel vulnerability), it is silent (no crash after executing the payload), it relies on undisclosed (0day) vulnerabilities discovered by VUPEN and it works on all Windows systems (32-bit and x64).

      VUPEN, which sells vulnerability and exploit information to business and government customers, does not plan to provide technical details of the attack to anyone, including Google.

      Guess it depends on who you think the "bad guys" are. I say, show the world and let the good 'n malicious duke it out -- hint: Bug fixes are often easier to code than full exploits.

  23. Call Jack Bauer by LittlePud · · Score: 1

    Someone has been watching too much 24 Season 7.

  24. Show that things are a-ok on the comfy VB forms by ThatsNotPudding · · Score: 1

    meanwhile, the processes race towards disaster. I assume this is what the Iranians experienced.

  25. On the other hand... by Kamiza+Ikioi · · Score: 1

    ... I can see not publicizing vulnerabilities. We don't, for instance, want our military publicly posting our vulnerabilities. Because, they sure as anything aren't going to ask for public patches. Public disclosure only really works if someone in the public can help. On the other hand, if you are running legacy systems in any number of unknown locations, you can't apply the patches anyways.

    We always talk about how bad obfuscation is as a security vector. However, it is a vector. Knowledge of a thing can be its greatest weakness. For instance, publicizing how a company's internal network is setup can help an attacker greatly. But, hiding it can increase security. It's soft security, but it's better than no security.

    --
    I8-D
  26. Full disclosure is better by Anonymous Coward · · Score: 0

    Giving them time to fix the vulnerabilities only works with companies that are enlightened enough (and responsible enough) to use that time to try and fix the vulnerabilities. Many companies won't bother and will just use that time to demonize you and/or threaten you with lawyers etc.

    It's been tried in the past, and usually nothing short of full disclosure will get these companies off their asses to actually fix the problems.

  27. shudder by Anonymous Coward · · Score: 0

    Supporting businesses that use SCADA systems, we've become very aware of the fact that Stuxnet isn't just a risk of passively awful events like pollution, or even awful pollution - there are genuine risks of explosions and people quite litterally dying immediately after a developer pushes a bad change. Malicious code going to scada systems is the sort of thing they make Bruce Willis movies about. If you aren't terrified when you read about SCADA systems attacks - you haven't grasped the full implications.

    Credit where it's due, for all that Siemens did a piss poor job of securing their product before Stuxnet - they are actually really helpful, really communicative and generally handling the issues fairly well. Fixing the problem in a secure, robust, change controlled way, with the kind of risk that goes along with any change to these systems - is neither fast, cheap or easy. It's hard to look at Siemens response to Stuxnet and say 'here's something they could do better/instead'. But it's still unbelievable how exposed they were before Stuxnet shone a light on this shit.

  28. More information about the reported weaknesses by Dirk+Gebert · · Score: 1

    Hi, I’m Dirk Gebert, system manager for security for Siemens Industrial Automation Systems. I’m on the team working on the topic mentioned in this article. We are posting updates on this website: http://www.siemens.com/industrialsecurity. Let me know if you have questions that are not answered there.