Evaluating Or Testing Utility SCADA Security?

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

Comments

Don't put it on the Internet!

[Anonymous Coward]

Seriously keep it on it's own separate network.

Re:Don't put it on the Internet!

[j35ter]

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

Re:Don't put it on the Internet!

[Bigjeff5]

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:Don't put it on the Internet!

[Anonymous Coward]

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.

Re:Don't put it on the Internet!

[Anonymous Coward]

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

SCADA and Security are not yet integrated

[PureFiction]

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

Re:From what I understand

[NewbieProgrammerMan]

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.