Forgot your password?
typodupeerror
Security IT

Researchers Find Slew of Flaws In SCADA Hardware, Software 110

Posted by Soulskill
from the a-slew-i-tell-you-a-slew dept.
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."
This discussion has been archived. No new comments can be posted.

Researchers Find Slew of Flaws In SCADA Hardware, Software

Comments Filter:
  • by Gothmolly (148874) on Saturday January 21, 2012 @09:17PM (#38777773)

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

    • by hairyfeet (841228) <bassbeast1968.gmail@com> on Sunday January 22, 2012 @02:06AM (#38778933) Journal

      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.

      • by rtb61 (674572)

        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 no

        • by hairyfeet (841228)

          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 deathmar

          • If you paid a few hundred dollars for a Linux license across a few thousand machines then I am sure the person taking your money would gladly provide you with patches for your 12 year old Debian machines, just like Microsoft does with XP.
      • Sorry. Your argument is invalid because of ponnies.

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

      • "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 w

  • by icebike (68054) * on Saturday January 21, 2012 @09:22PM (#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.

    • by Anonymous Coward on Saturday January 21, 2012 @09:48PM (#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: (Score:2, Insightful)

        by teridon (139550)

        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 usef

        • by JWW (79176) on Sunday January 22, 2012 @10:03AM (#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!!

          • by teridon (139550)
            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
          • 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?

        • by drinkypoo (153816)

          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.

    • by gman003 (1693318) on Saturday January 21, 2012 @09:51PM (#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?"

      • 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
        • 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 duri

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

            • by Fnord666 (889225)

              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.

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

      • "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 st

        • PLCs are the natural "evolution"(if you like) of Relay control logic. Which dates to pre WWII. That is why they use ladder diagrams.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      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 approa

    • by guruevi (827432) <eviNO@SPAMsmokingcube.be> on Saturday January 21, 2012 @10:42PM (#38778215) Homepage

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

      • by Mendy (468439)

        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.

      • Siemens? You have my pity sir. Siemens PLCs are terrible. No clue why they're so popular...

    • by FooAtWFU (699187) on Saturday January 21, 2012 @11:10PM (#38778339) Homepage
      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.

      • by mysidia (191772) *

        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, co

        • by makomk (752139)

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

          • by mysidia (191772) *

            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.

    • by deniable (76198) on Saturday January 21, 2012 @11:22PM (#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.)
    • 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

    • by tibit (1762298)

      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 h

  • 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!

  • by nurb432 (527695) on Saturday January 21, 2012 @09:31PM (#38777841) Homepage Journal

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

    • by sowth (748135)

      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.

  • by Joe_Dragon (2206452) on Saturday January 21, 2012 @09:48PM (#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.

    • by thegarbz (1787294)

      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

      • by DarkOx (621550)

        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.

        • by thegarbz (1787294)

          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)

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

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

    • by deniable (76198)
      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.
  • by Anonymous Coward

    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.

  • by Anonymous Coward on Saturday January 21, 2012 @10:23PM (#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: (Score:3, Funny)

      by deniable (76198)
      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.
  • 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 (Score:4, Insightful)

    by TubeSteak (669689) on Saturday January 21, 2012 @10:36PM (#38778191) Journal

    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.

    • by deniable (76198)
      Imagine an Apple / Microsoft security non-advisory but with real money and possible jail time involved.
    • 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...

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

    • by 0123456 (636235)

      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.

  • 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].
  • 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."

  • by Eyezen (548114)
    Next we'll find out its not a good idea to have a POTS connection to the US War Operations Plan Response system
  • 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
  • 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 f
  • by rat7307 (218353) on Sunday January 22, 2012 @04:12AM (#38779347) Homepage

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

  • 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 (Score:5, Informative)

    by gnalre (323830) on Sunday January 22, 2012 @05:19AM (#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

    • by naranek (1727936)

      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.

    • 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.
      • by gnalre (323830)

        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

  • 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 y

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

It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome

Working...