Forgot your password?
typodupeerror
Security IT

Evaluating Or Testing Utility SCADA Security? 227

Posted by Soulskill
from the i-hear-stuxnet-has-a-nice-admin-suite dept.
EncryptedBit writes "I am a local elected official involved in bringing new water and waste water treatment plants online in a small town. The new plants will incorporate SCADA, which can be used to change operational aspects at the plants, up to forcing a shutdown or changing operational parameters. Can any Slashdotters recommend ways to make sure it is secure? Any testing recommendations? The operational engineers are oblivious to security and SCADA is a new factor, so this concerns me. Any pointers would be appreciated."
This discussion has been archived. No new comments can be posted.

Evaluating Or Testing Utility SCADA Security?

Comments Filter:
  • by Anonymous Coward on Saturday November 06, 2010 @04:51PM (#34149006)

    Seriously keep it on it's own separate network.

    • Re: (Score:2, Interesting)

      by mattt79 (1005999)
      ++ Absolutely correct!! SCADA should be considered a Level II control system, and subject to the same degree of security as the devices that are actually controlling the valves!
      • by aaarrrgggh (9205)

        That is easier said than done sometimes, and unfortunately it doesn't solve the whole problem. Solid layer-1 through 3 network security is extremely important, and needs to be very thurough.

        But resolving the details isn't easy. How do you prevent a technician serving one piece of equipment on the network from accessing other network-connected equipment? How do you counter factory backdoors?

        And... how do you do all of this without an IT staff dedicated to it?

        • Air gap.

          • by aaarrrgggh (9205)

            Original scenario: Vendor technician connects laptop to second Ethernet port of their equipment's management card when doing quarterly PMs. Now what?

            Mor common case: Even companies that should know much better (AT&T comes to mind) use Ethernet as the sole connection point to some of their SEL protection relays. It might be on a VLAN, but it is far from an air gap, and there isn't a dedicated workstation to connect a browser to just that VLAN.

            With RS485, it was easy to keep some semblance of an air gap

    • totally agree - no amount of convenience is worth the security risk !

      • Not in total agreement with this. Better to be able to monitor, and most SCADA endpoints can override messages that want to send settings outside safe operational parameters. You might try Logica - they have a very good SCADA team (I used to work for them).
    • Re: (Score:3, Funny)

      by mail2345 (1201389)

      But I want to be able to blame "hackers" when I mess up.

      • by oiron (697563)

        Ha! Something as pedestrian as not having an Internet connection doesn't stop them evul hackrz!

    • by j35ter (895427) on Saturday November 06, 2010 @05:14PM (#34149160)
      Just keep away from Simatic and Wonderware! Better yet, keep away from ANY kind of winXP implementation. Oh yeah, don't forget to *physically* lock all USB ports and external media. Of course, you should make sure that there is no network connectivity with the outer world. And I mean none! No multihomed machines, no VLAN's etc. And, of course, if you see all alarms going off at once...run :)
      • by denobug (753200) on Saturday November 06, 2010 @09:05PM (#34150900)
        Wonderware InTouch happens to be one of the most popular flavor of local supervisory system platform. There are very few supervisory system NOT implemented with Windows platform. Even DCS nowadays runs on them as well.
      • Re: (Score:3, Insightful)

        by thegarbz (1787294)
        Typical slashdot answer. When most of the worlds popular SCADA implementations are run on a windows based system, and many which are not currently are slowly moving that way, what are you left with? Keep it on it's own network completely isolated depending on the plant may also run afoul of laws requiring off-site historical databases. It'll also anger ops engineers no end when they can't easily aggregate and manipulate the historian data on there computers which gives you another problem, do you let an ext
    • by Bigjeff5 (1143585) on Saturday November 06, 2010 @05:18PM (#34149198)

      Good safe practice for separating a process control network from the internet is something like: internet > corporate network > buffer network > process network. Completely separating it is not advisable, because it can actually make it harder to administer and protect (updates, antivirus, etc). It's an option though if you are diligent with sneakernet updates and whatnot.

      The network your SCADA system runs on should never, ever have direct access to your corporate network or the internet, your buffer network should never have direct access to the internet, and your corporate network should never have direct access to your process network. Be stingy about what you allow through the firewalls at each layer.

      Basically when you need SCADA data outside the process network, you send it to the buffer network, and from there it is accessed from the corporate network. All controls should only be managed from the SCADA network (i.e. don't set something up so that it can be managed from the corporate network).

      Separation is key. As others have said, SCADA networks need a lot of open access to the various systems they control in order to function efficiently, so within the network things have to be practically wide open. The only real option is to protect yourself with layers to make it nearly impossible for anything you don't want to access the system.

      • Re: (Score:2, Insightful)

        by Mysteray (713473)

        Completely separating it is not advisable, because it can actually make it harder to administer and protect (updates, antivirus, etc).

        Yeah, it might make it a little harder to work with sometimes.

        TOO FLIPPING BAD!

        Get your lazy ass off out of your chair and maintain the low-level infrastructure like it needs to be. Sometimes the infrastructure needs a guy with a truck, a wrench, and even a firmware update to match.

        There's absolutely no reason industrial control processes should be accessible to the same we

        • by bjwest (14070)

          But but but.... I have the god given, constitution granted inalienable right to play Farmville, have my desktop covered with widgets and surf the web while at work! By god, I'm an 'merican!! What the hell do you expect me to do while I'm at work, WORK?!? I don't get paid to stare at those blinking pixels and dial thingamabobs all damn day.

          • Re: (Score:3, Funny)

            by darkpixel2k (623900)

            But but but.... I have the god given, constitution granted inalienable right to play Farmville, have my desktop covered with widgets and surf the web while at work! By god, I'm an 'merican!! What the hell do you expect me to do while I'm at work, WORK?!? I don't get paid to stare at those blinking pixels and dial thingamabobs all damn day.

            I think you're confusing us "'mericans" (people residing on the American landmass) with a uniquely retarded subset of those people called 'Government Employees'.

            • But but but.... I have the god given, constitution granted inalienable right to play Farmville, have my desktop covered with widgets and surf the web while at work! By god, I'm an 'merican!! What the hell do you expect me to do while I'm at work, WORK?!? I don't get paid to stare at those blinking pixels and dial thingamabobs all damn day.

              I think you're confusing us "'mericans" (people residing on the American landmass) with a uniquely retarded subset of those people called 'Government Employees'.

              Nah, he's just in denial that the government functionaries in his country are just as damaged.

        • I don't think they should even have the ability to have a browser. You need something dumb enough to meet your needs and thats it. I would buy a system that runs on solaris. It's a SCADA system not a personal computer. You don't even have to air gap it. It should be considered a device and not a computer then. You can send the DAQ information to the computer and have a seperate terminal for control.
          • Re: (Score:3, Insightful)

            by Mysteray (713473)

            While there are some truly compelling advantages to KISS/dumb systems, there's usually no reason that the system has to have a painful interface. The UIs for medical equipment, for example, are highly polished and tested for ease-of-use. It's just IMHO dangerously stupid to put plug-n-play networking, USB, or Wifi on a drug infusion pump.

            If plug A fits into socket B, somebody's going to plug it in. Drop some infected USB drives in the parking lot, somebody's going to stick one in a USB port behind your fire

      • Re: (Score:3, Insightful)

        by j35ter (895427)
        IMHO the standard multi-layered network security approach does not always satisfy the security needs of a process management system.

        you really don't want your windows machines to update themselves: NO NO NO NEVER!!!
        Just imagine the operators' dumb face when WinXP goes into a restart during some critical operation, this could seriously ruin a plant managers Tuesday!

        One important aspect is the internal security, people are lazy, and if you allow the to use a USB drive somewhere (management demands repo
      • Can you clarify what a buffer network is, and why it would help?
      • Good safe practice for separating a process control network from the internet is something like: internet > corporate network > buffer network > process network. Completely separating it is not advisable, because it can actually make it harder to administer and protect (updates, antivirus, etc). It's an option though if you are diligent with sneakernet updates and whatnot.

        That's absolutely a recipe for disaster.

        Nothing on the SCADA system should connect to anything, on any other network, using

    • by Anonymous Coward on Saturday November 06, 2010 @05:21PM (#34149210)

      As a security expert who has audited SCADA systems, I must amend the above remark. If you ask them, "I'm here for security, is it connected to the Internet?", they will say "no". If you instead ask them, because you are concerned, "in an emergency, how an administrator can access it remotely", then will tell you the series of systems that will allow you to connect in- firewalls, vpns, and usually a last hop Citrix remote desktop session to the SCADA software itself, which is often Siemens, and is run in a VM. When you tell them to take it off the Internet, they will put your request in change control, and find a way to get rid of you, or if you're a politician, to buy you out. Usually the people running these things have no ability to think adversarially, so they consider something that is several levels removed from the Internet to not be Internet connected, even though it is. They may even tell you that it has its own leased network, run over Frame Relay leased from a telco, which is quite common. This is also internet connected, as the ISP can get pwned, and the frame relay stuff has a management network that is on the ISP's LAN. I've done security for a Fortune 50 ISP as well.

      The short answer is, every SCADA system in the Americas is Internet connected, and no one has the balls to tell them to stop. They will only hire people to audit them who will put on kid gloves and play by their rules, and they refuse to take advice from their vendors, who they pay to be compliant. A security consultant lecturing a SCADA client on security measures is like a temp secretary lecturing a CEO on spelling. It's an event that always ends in a raised eyebrow and a prompt firing.

      Every nuclear reactor in the united states is internet connected. I've seen them. I'm certain. Being a whitehat pen tester these days is like being a turned out whore- you know you're not helping anyone but it's too late to go back.

      Posted anonymously for obvious reasons.

      • by Anonymous Coward on Saturday November 06, 2010 @05:28PM (#34149252)

        I almost forgot. Don't ask them, "is your network secure", because they will say yes, even though there's no such thing as a secure network. The appropriate question is, "how defensible is your network" and "what is your dwell time", i.e., what do you have in place to stop intrusions and how long do hackers usually last on your network. But the best question to start with is "what's your incident response budget", which they will brag about, i.e. how much money they spend on getting hackers removed when they're owned. Start there, get them to tell stories about the last time they got hacked. Then you don't have to listen when they start telling you about how they're "secure".

      • Re: (Score:2, Insightful)

        by noidentity (188756)

        Usually the people running these things have no ability to think adversarially, so they consider something that is several levels removed from the Internet to not be Internet connected, even though it is.

        Indeed, everything is connected to the Internet. It's always just an Ethernet cable away. Send the right commands over a phone line, and that cable will be connected for you.

      • by EdIII (1114411)

        is like being a turned out whore- you know you're not helping anyone

        A very interesting and insightful post. However, I have to strongly disagree with this analogy. A turned out whore is providing a valuable service.

      • Re: (Score:3, Insightful)

        by KUHurdler (584689)
        Seriously, the original poster needs to hire someone that is an industry expert in Utility Communications [blackandveatch.com]. Disclaimer: I work for this division, but we do this stuff every day and it's not the kind of thing you want to try doing on your own. In the worst instances, there are no second chances.
        • Re: (Score:3, Interesting)

          http://www.blackandveatch.com/Markets/Telecommunications/Utility_Automation/Default.aspx I stopped reading there.

      • by Anonymous Coward on Saturday November 06, 2010 @07:53PM (#34150256)

        I've also done SCADA system security on the water plants of nuclear reactors, and can confirm that all the ones I've seen have been connected to the Internet. One time I saw a Junxion box and a AP just plugged into the core switch for the control network. It wasn't that crazy given that the Junxion box had its power supply in the manager's office and you can't get within miles of the place without having rifles shoved in your face, but it was still pretty surprising to see it.

        Another site uses default passwords for everything and they have a dial-up modem which drops you right into a login prompt on one of the control hosts. You have to call them to get them to plug it in first, though, so they haven't had any problems. Unlike in Hackers, they don't plug it in for any schmuck who asks; you have to give a CAC ID and it has to match the schedule maintenance roster, otherwise the FBI gets called.

        The really important stuff isn't really under control of a computer though, it's all in some PLC somewhere and there's only one guy who understands the control logic anyway. I'm not too worried about someone breaking into those networks. If anyone tried to do anything bad, it's much more likely that they're just going to break something unintentionally while learning how the system works and trigger an investigation, not create a meltdown.

      • by crossmr (957846) on Saturday November 06, 2010 @09:04PM (#34150894) Journal

        The short answer is, every SCADA system in the Americas is Internet connected, and no one has the balls to tell them to stop

        That's incorrect.
        I used to build SCADA systems and we often included a separate "work terminal" that was connected to the corporate network for workers to access anything outside they needed. It was not connected to SCADA and the SCADA system was not connected to the main corporate network or the internet.

      • Re: (Score:3, Interesting)

        by thegarbz (1787294)
        Did you miss the obvious problem with your one statement? "In an emergency". I'm not sure what you define as remote administrations but those same type of terminals we have are read only, and yes you need to jump through all those hoops. But "In an emergency" events have occurred several times on the site. The ability for experts located in another country (wonders of the multinational enterprises) to help debug live has saved us from turning our site into a big hole in the ground several times. The number
    • by mjwalshe (1680392)
      and physically disable the usb ports
    • Keep all computers off that network that are allowed on ANY OTHER NETWORK. The ONLY possible exception should be a single billing type system, where it pushes data from scada to the billing system (with the pushing system not allowed to have anything else on it). Also, all systems on the SCADA network should not have a single wifi on them.
    • by antdude (79039)

      Seriously, no apostrophe. It's = It is. :P

    • Re: (Score:2, Interesting)

      As someone who used to deal with SCADA systems all the time, I shudder whenever I hear the words "security" and "SCADA" in the same sentence.
      Back in the bad old days - when SCADA was driven by OPC - you had to turn off security just to get things like DCOM to work properly. It was scary and wrong, but you had very little choice. Talking to friends in the industry it doesn't seem to have gotten any better.
      The real problem stems from engineering departments losing political clout within business that are
    • by Peeteriz (821290)

      Some connection to the internet is inevitable - SCADA's are usually used for distributed data, and having separate long-distance physical lines everywhere is not cost-efficient at all.

      So there is often some connection to the internet required, even if it's just VPN piggybacking over a hundred standard net connections in different places.

  • by Runefox (905204) on Saturday November 06, 2010 @04:54PM (#34149026) Homepage

    There isn't much to do with SCADA regarding security - The systems themselves are inherently insecure, the extent of it reaching only so far as default passwords that are scarcely ever changed and the requirement to have a compatible console. If you're connecting these devices to the internet in any way, then you're opening yourself up for a world of hurt. The best security is physical security, with no link to the outside world except in closed, site-to-site communications. I'm by no means an expert, but having heard experts speak about the subject and with some limited experience of my own, there really doesn't seem to be any better way the way things are.

    • Re: (Score:3, Informative)

      by Da_Biz (267075)

      The systems I work on feed data to our SCADA systems. The entire network is completely walled off from the Internet, and even connectivity to our internal (non-operations) network is mediated by extremely secure bastion hosts.

      I can understand that there may be a need for some access (e.g., system pages an operator to send a warning or emergency message), especially as this is a small town. Keep these sorts of connections absolutely to a minimum, and wrap several layers of security around it.

      • Re: (Score:3, Insightful)

        by postbigbang (761081)

        "Bastion hosts" are an oxymoron. Every device on a network needs the best self-protection set at the highest possible standard. Layers of security are only incrementally effective. It takes only one bot to bring you down. Firewalls, although they sound impressive, are ineffective when users plug in infected flash drives, or other media. You have to distrust every device on your network without exception-- even routers and switches can be broken into using fuzzing techniques. Continually hack yourself, ethic

        • by Jeremi (14640)

          You have to distrust every device on your network without exception-- even routers and switches can be broken into using fuzzing techniques.

          I always thought that for the truly paranoid, the trick is to make sure that it is physically possible for information to flow into the "secured" system from the outside world. For example, make it so that the only connection between the secured system and the Internet-facing gateway is a serial cable, and the TX line on the serial cable has been physically severed.

          • Even Rotts like a juicy steak now and then.

            The air gaps seem simple, until someone connects a back door from their phone, wakes up some long sleeping daemon, and then the link is complete.

            Hacking yourself is the best way, with the best tools you can get... frequently.

      • by sjames (1099)

        Outbound notifications can be handled by a serial connection with the inside hosts Rx line cut so that it can ONLY send outbound communications.

    • by NewbieProgrammerMan (558327) on Saturday November 06, 2010 @05:54PM (#34149380)

      There isn't much to do with SCADA regarding security - The systems themselves are inherently insecure...

      As somebody that worked at a SCADA software company for a few years, and saw (1) the skill level of the core development team and (2) what customers did with our systems, I heartily endorse this viewpoint.

    • You don't necessarily need an airgap. You just need the network so that you can read SCADA status info and alert based on that.

      http://www.stearns.org/doc/one-way-ethernet-cable.html [stearns.org]

      Be able to read from WAN->SCADA, but never be able to write.

  • 0x00000047, 0x000008C4, and 0x00000A08 All hold awful vulnerabilities, make sure no one has access to them.
  • ...I will say that training is going to be your biggest hurdle. But I'm sure you know this. Water and waste water technicians are, in my experience, terrified of technology. This manifests as an unwillingness to use technology and a hostility when forced to do so.

    Other than that, treat it as you would any other service that could potentially kill people, or more importantly, lose your next election ( I know how politicians think ); Lock down the subnet, do not provide access to this remotely on equipment

  • by RedLeg (22564) on Saturday November 06, 2010 @05:06PM (#34149108) Journal

    It's simple......

    Do NOT, under any circumstances, connect the SCADA systems, including workstations which can control or monitor them, to anything which touches or has access to the Internet. Make SURE that your control and monitor workstations have current AV in place. Do NOT connect them to the net to update the AV, figure out how to do it with sneakernet.

    Further, make SURE you use RFC 1918 addressing for the SCADA systems so that they are not readily routable to the 'net.

    Map the interfaces, and have a AAA (Authentication, Authorization and Accountability) strategy for each. Log EVERYTHING.

    If you use a carrier to link remote sites into a WAN, make them prove to you that their pipes are clean and secure.

    Have Fun......

    Red...

    • Re: (Score:3, Interesting)

      by Jah-Wren Ryel (80510)

      Do NOT, under any circumstances, connect the SCADA systems, including workstations which can control or monitor them, to anything which touches or has access to the Internet.

      When that's not possible due to management pressure, there are options that are better than just giving in and connecting systems up to the internet.

      The simplest of such options is a "data diode" -- its a device that physically only permits data to flow in one direction. For example, optical network connections have a transmit fibre and a receive fibre. A data diode would physically connect just one fibre.

      Implementing a data diode - say to run your monitoring software on an internet connected PC so as to

      • With rare exceptions, all network protocols require two-way traffic. So this idea of a "data diode" is not possible to implement in practice. People who claim otherwise are trying to sell you snake oil.
        • With rare exceptions, all network protocols require two-way traffic. So this idea of a "data diode" is not possible to implement in practice. People who claim otherwise are trying to sell you snake oil.

          I suggest you do some research. Data diodes tend to be application specific and the good ones "know" enough of the protocols involved in order to spoof the necessary handshaking.

        • by RogL (608926)

          With rare exceptions, all network protocols require two-way traffic. So this idea of a "data diode" is not possible to implement in practice. People who claim otherwise are trying to sell you snake oil.

          Who said anything about a network protocol?

          A "data diode" receiver just needs to monitor an optical sensor, which could be pulsed at a fixed clock rate to provide a baseline. Monitor the on/off/brightness-level of your optical sensor, you can then write the output to a file. No need for a 2-way protocol.

          An example demonstrates the practicality of this:

          Timex DataLink watch: early models fed data to the watch by flashing bars of light on your monitor, while holding the watch's optical sensor in front of the

    • Re: (Score:3, Interesting)

      by jeff4747 (256583)

      Make SURE that your control and monitor workstations have current AV in place. Do NOT connect them to the net to update the AV, figure out how to do it with sneakernet.

      Oblig XKCD [xkcd.com]

      If you're putting AV on it, you're doing it wrong.

    • If you use a carrier to link remote sites into a WAN...

      ... run your own encrypted vpn connection over the link. Then you don't care if the wire is ever hacked into.

  • This answer assumes you're in the US. If not, replace the relevant government agency with your own government.

    Since your engineers are 'oblivious about security', you're going to have to hire somebody to evaluate your system. NSA should be able to point you towards government contractors that do this kind of thing. You could try DHS since they're supposed to help civilian infrastructure such as your operation, but their "cyber" operation isn't really set up yet.

    No, it won't be cheap. You'll have to bala

  • by symes (835608)
    You'll certainly might get some good tips here on slashdot for free, but really, you might want to think about getting local expertise... your next post "our town's waste and water services have been maiciuously hacked, please help, we're up to our ears in ****" might not filter to the front page.
  • Your internal systems need to be on their own network as others have said. Otherwise, you'll be owned. However, if you have a need to share data "publicly", you can create a data diode to a public server. It involves either a very expensive piece of hardware, or soldering a switch so there is no way to communicate to the main plant computer. Then the plant server communicates to the public server via UDP, and you can use OPC (or whatever you like) to retrieve data. If you have some idiot that wants to
  • The operational engineers are oblivious to security

    Its like saying Our bus drivers are oblivious to road safety. If they don't know how to do their jobs then you are screwed.

    Put an air gap between your SCADA system and the internet.

  • Is anyone else terrified by the fact that this question even had to be asked?

    • Re: (Score:3, Interesting)

      I find the fact that it is being asked commendable: if TFS is to be trusted, an elected official is attempting to learn more about security to make sure he can oversee a project properly. That sounds just ducky to me, and well above the status quo.

      Now, the fact that said official appears to have strong reason to distrust his engineers, and no ready internal supply of expertise, suggests that any script-kiddie with a copy of Telnet and 10 minutes will be able to quite literally put some poor town up shit
  • I recently went to a Belgian OWASP meeting where Justin Searle talked about "Attacking and Defending the Grid".
    This guy knows what he's talking about. Among other things, he also mentioned SCADA vulnerabilities.

    I recommend you contact him or his company for professional advice (I am in no way affiliated with him or his company - just thought you might be interested)

    If you google for the subject of this reply in combination with "OWASP", you'll find more info about the talk.

  • VPN (Score:3, Informative)

    by AmericanInKiev (453362) on Saturday November 06, 2010 @05:41PM (#34149320) Homepage

    I'm working with an international firm on Scada - we use a VPN to provide a secure private network.

    • Re: (Score:2, Insightful)

      by jeff4747 (256583)

      we use a VPN to provide the illusion of a secure private network.

      FTFY

      • by thegarbz (1787294)
        Did you ask them about their implementation? VPN is like any system as secure as you wish to make it.
  • by PureFiction (10256) on Saturday November 06, 2010 @05:44PM (#34149346)

    SCADA systems are not designed, implemented, or operated with network and application level security concerns in mind.
      (Usually. The exceptions know who they are :)

    Your compensating control is physical security to limit access to SCADA elements and programming. It costs more, but you have no sane alternative.

    And before you get too cocky about that restricted air gap, consider Stuxnet turning such a strength into a weakness for exploit. At some point SCADA systems will be security conscious; that day is not today...

    • by thegarbz (1787294)

      And before you get too cocky about that restricted air gap

      This is the fundamental problem right here. The kind of mind that thinks airgap and be done with it is usually the kind of mind that doesn't think about security, and will fall for exactly the likes of Stuxnet. This illusion that everything is fine because there's no internet can often be worse than a well designed remote access system built from the ground up with security in mind. They do exist and the ability to remotely see what is going on can pull you out of the shit, or put you in the shit depending

      • Re: (Score:3, Insightful)

        by ScrewMaster (602015) *

        And before you get too cocky about that restricted air gap

        This is the fundamental problem right here. The kind of mind that thinks airgap and be done with it is usually the kind of mind that doesn't think about security, and will fall for exactly the likes of Stuxnet. This illusion that everything is fine because there's no internet can often be worse than a well designed remote access system built from the ground up with security in mind. They do exist and the ability to remotely see what is going on can pull you out of the shit, or put you in the shit depending on how it's implemented.

        The fundamental problem is that good security is a process, not a state, and you cannot have good security by any fire-and-forget solution.

  • make sure it is secure

    Here is the most important thing to know: security is a process not a project. No systems ever "achieve" security. Rather, better-protected systems beat the attackers by having well-thought-out-and-executed security processes.

  • Seriously ? Were all doomed, man ...
  • There are a variety of good posts here (among the chaff). The post by @bigjeff5 and the anonymous coward post amendment. For standards and an understanding of the risk metrics Sandia labs has a great set of documents for SCADA security http://www.sandia.gov/ccss/ [sandia.gov] , never mind all the FUD. You'll have to decide on whether you want a best in class, good enough, or what you can afford and wherever the three vectors meet at a solution. Technically there is no reason for SCADA to be a risk. Experience though tel
  • If you don't understand the issues well enough to do an audit yourself, insist on an outside audit by a company that does, *and* does not sell any security products or services themselves.

    Asking Slashdot is just going to get you a whole lot of uninformed suggestions from mostly well-meaning people with the occasional good suggestion buried in the noise. But you don't know enough about the subject to know which ones are the good suggestions and which are not.

  • First advice: do not connect the network that runs the SCADA systems to the Internet or to any network that connects to the Internet. Leave an air gap between your control systems and the outside world. It's OK to network them, but make it an isolated, stand-alone network. It's much harder to attack a network when getting access to it requires physically going to one of your offices or plants. It may make it less convenient, but remember you're making it less convenient for the bad guys too and the conseque

  • One useful consequence of the Stuxnet Trojan is to provide a concrete example of how SCADA networks can be exploited. Knowing the details of how Stuxnet works can inform you of how to perform a comparable variety of penetration tests on your own network.

    You will then have a measure of how vulnerable your network is to Stuxnet in particular. It's only a circumstantial indicator of how vulnerable your network is generally, which is why I'm not in favor of pen testing except as part of a more comprehensiv
  • The U.S. Government fully understands the need for isolation and just how impossible it really it. There are niche companies out there that make systems that comply with specific DCID 6/3 requirements to make the system match a Protection Level. They use mandatory access control with Solaris 10 Containers, Trusted Solaris/Irix before that, and SELinux nowadays.

    Here's their problem though. In order to be effective, an organisation must clearly know what must come in or out, network wise. It is difficul

  • The town I work for has a SCADA system for it water treatment plants and lift stations. A lift station pumps sewage to the wastewater treatment plant. SCADA (at least in my town) has two main components. The first component is a control station which is a Windows XP SP2 PC. A read-only monitoring terminal is also a Windows XP SP2 PC. The second components are several small boxes inside cabinets to which various sensors and radio links are attached. Each lift station, water treatment plant, pump house,

  • You need to hire a control system or SCADA engineer to assist you to evaluate the overall requirement.

    Depending on your operation you might just need a isolated network to more sophisticated requirement. You mention that you are in a small town and runs a small water treatment plant, so that tells me that a. you have a smaller size facility with only a few components (versus big facility for a big city), and b. seems that this is your only facility to operate, or one of very few. The requirement depends

  • This is Slashdot. There are many self styled experts here. Some know what they're talking about. Many do not. Tread with care.

    I am a registered professional engineer with 25 years of experience integrating, fixing, and designing several generations of SCADA and plant control systems for a large water and sewer utility. I not only design and build these things, I live with my creations through the entire life-cycle. If it does anything unexpected, they call me; no matter how old it is. I have worked on ever

    • by Animats (122034)

      This is Slashdot. There are many self styled experts here. Some know what they're talking about. Many do not. Tread with care.

      Right.

      You have some things going for you here. First, your problem is controlling water and sewerage plants. Those don't need to be connected to external systems. In contrast, power grid control systems do, because there are financial systems which interconnect to the operational systems. (Read PJM 101 [pjm.com] to get a sense of what that's like for the nation's biggest power grid.)

  • The University of Idaho has a research lab dedicated to this. They have SCADA systems set in a lab. There's a grad class in the subject you can take via video. And there are quite a few papers they have helped published. Search the IEEE document library for some good info.

  • Howdy, The only way to secure it is with an Air Gap. A PC with a CDROM drive as the final "non-connection" to the internet. The problem with that is that the vendor will not like it, since they like to keep their grubby fingers inside your system remotely, so that they can see what you are doing and upload fixes easily. The last thing they want to deal with is a air gap CDROM.
  • Every computer system that was ever designed, every software that was written was done to share information, not to secure it. That is until recently. It wasn't until we built all these systems and got them all working that we then went 'aw CRAP, what about security...'
    The internet was designed by engineers. Software was written by engineers. They both shared the same flaw. Engineers build things. Nearly every engineer I've met operates on the principle of "If it ain't broke, don't take it apart and find

  • Simply put..

    A. Do not under any circumstances connect this thing to the internet. no if, ands or buts about it.

    B. If outside access is required it is by call-back ONLY.

    C. EVERYTHING is logged, 100% no exceptions. Every keystroke, every entry, every response, every everything, and the logging is hard connected and encrypted.

    D. Nothing is interconnected to your main business network. Place secure terminals that boot from the SCADA network that have NO media devices in them, no USB, No DVD/CD drives, no seria

Wernher von Braun settled for a V-2 when he coulda had a V-8.

Working...