Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Is there a way to monitor the way the SCADA systems behave 'during pen-testing or security audit', and find out the implications of just port scans and/or monitor the state of activity while sending a payload ? Is it possible for a device to get faulty because of a SCADA Security Audit ?

share|improve this question
4  
This might be a little too vague. There are many different types of SCADA systems out there, and they all behave differently. –  SteveS Apr 28 '11 at 18:50
    
If all devices just have a password set on them, you are doing better than a lot of SCADA systems! Given that even a simple pressure sensor may need to be read from 3 or 4 different software systems password management is complex. Also watch out for network load, as you may be hitting RS232 links, so putting any more packets on the network could overload the system. –  Ian Ringrose Jul 6 '11 at 15:28
add comment

4 Answers

up vote 2 down vote accepted

SCADA devices are prone to the same common vulnerabilities—such as enumeration, password cracking, network eavesdropping, and denial of service—that are found in any other types of network devices.

I think it is pretty common to deploy health monitoring systems for your systems so you can pick up on unusual things happening on your SCADA network.

Your SCADA systems can deffinitly fail and break during a pentest. The outcomes of a pentest can be so many, and even if you do crash a PLC or other equipment that is also infact a security issue (denial of service). What happens if a long fuzz string hits your PLC and it breaks down?

If I were you I would treat your SCADA network like any other network. With this comes the worrying of taking something down, breaking data, and so on.

This video shows a staged SCADA attack on a power grid: http://www.youtube.com/watch?v=fJyWngDco3g

share|improve this answer
add comment

Pentesters / "Auditors" should keep a full packet capture of everything their tools put on the wire and this should be available to you as a client. Use this if something does happen to crash, is identified incorrectly, etc. to pinpoint the (mis)behavior of the systems under test.

Also, start basic and manual before assaulting the system with all kinds of traffic. (things can go bad quickly and you'll have no idea what caused it until you dig through the captures) This means passively identify ports in use, then start by sending simple connects/SYNS rather than a full on nmap fingerprint/service scan, etc. (tools are unlikely to have useful signatures to identify the equipment anyway)

Consider getting the data by other channels as well. For example, many devices support a standard SNMP MIB which will yield you information about model, tcp/udp ports, route table, etc. If you can recover this information with standard SNMP queries then you don't need to scan all 65000+ ports.

Disregard Rook's reply to your comment. Though many software components of control systems do run on Windows and *nix systems now, there is still plenty of risk to crashing/corrupting the applications on these systems, not to mention the embedded devices that make up the field of the control system which are even more notorious for not taking kindly to scanning or testing. Plenty of examples of both to back this up, even when running on modern operating systems.

TL;DR: There are always more passive / hands-off testing approaches you can fall back to in order to accomplish your testing task and get coverage of the control system. Be creative and cooperate with the client or test team.

share|improve this answer
add comment

The single most important rule when testing production SCADA systems is never test production SCADA systems if there is a risk of taking down any critical service, or spilling an oil pipeline etc. Always use a test environment.

If however you have to test in live, the best rule to adhere to is to ask for confirmation of every step - written confirmation, from the system engineer. This does make a proper test very cumbersome and expensive,but dramatically reduces the risk of you doing something fatal.

And if it is expensive enough, perhaps for next year's test you might get a test environment...

share|improve this answer
add comment

A SCADA system is just a large distributed network that is usually over IP. SCADA systems are very reliant on a database, and SQL is a common choice. The same rules apply for any pen test against a network. A SCADA system needs a firewall to block incoming connections. An IDS such a snort is still helpful in maintaining a secure network. SCADA systems can have web interfaces and a Web Application Firewall such as mod_secuirty (as a reverse proxy) is helpful.

The only gotcha with SCADA is that they are usually LARGE. As in computer systems for moving electricity across an entire country. So for physical penetration tests you need to look at gaining physical access to the network by looking at individual nodes in the SCADA system. Break out your hacksaw and a wire crimper :D.

share|improve this answer
    
I believe that did not answer the question. I would like to know if there are proven practices and methods to conducting pen-testing devices without crashing them ... –  Legolas Apr 29 '11 at 3:41
    
@Legolas I have been pen testing for years and i have never accidentally crashed a system. A port scan will never crash a system. SCADA's are built on windows or Linux and you have nothing to worry about. Also this is a ridiculous question to ask. –  Rook Apr 29 '11 at 15:23
6  
you'd think so, but you'd be very wrong. as an example I have had a simple nmap scan crash a reverse proxy in such a way it couldn't be restarted. a cold power cycle didn't even work. Problem was down to faulty network card that got triggered by the scan. Nothing we could have expected. Always plan for the target to have unexpected problems. Also many SCADA systems were not built on Windows or Linux. Lots of legacy kit out there. –  Rory Alsop May 1 '11 at 7:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.