Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Snort 2.9.2 now supporting SCADA protocol checks

Published: 2012-01-08
Last Updated: 2012-01-10 13:53:36 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
5 comment(s)

One of the major concerns of a public utility security issues applicable to securing SCADA systems of energy, gas and water supply. Manufacturers have responded slowly to this challenge and we can see traffic assurance deployments like HP with its TippingPoint IPS and Fortinet. The complex point of these solutions is that their cost is quite remarkable and some of them do not have enough functionality.

Fortunately, the Sourcefire guys began to include support for SCADA protocols within Snort from version 2.9.2 and started with the electrical substations protocols DNP3 and Modbus.

Check out one of my previous SCADA diary for basic definitions. I made some test myself with this functionality and I found very useful the following features to increase the valuable alerts within the SCADA Network:

  •  Check for broadcast messages: DNP3 protocol talks to each device within the system and perform specific functions on it. Broadcast messages can be dangerous specially if they have a "turn off" command to all the Remote Terminal Unit (RTU) that controls its own energy substation. You can check this with the following snort rule:

alert tcp any 20000 -> any any (msg:"All RTU being contacted using DNP3"; dnp3_ind:all_stations; sid:1;)
 

  • Check for write or delete operations not being sent by the master station: We definitely don't want someone else to write or delete to the RTU on behalf of the official Human-Machine Interface (HMI). The following snort rule can be used to check this behavior, assuming that HMI ip address is 1.1.1.1:

alert tcp !1.1.1.1 any -> any any (msg:"Someone trying to write or delete to RTU"; dnp3_func:write,delete_file; sid:1;)
 

  • Check for "save configuration" commands not being sent by the master station: If someone writes to the RTU and then tries to save the configuration on behalf of the official HMI, could already have control of the RTU devices and make sure we no longer can send commands to them. The following snort rule can be used to check this behavior, assuming that HMI ip address is 1.1.1.1:

alert tcp !1.1.1.1 any -> any any (msg:"Someone trying to save the configuration of a RTU device"; dnp3_func:save_config; sid:1;)
 

  • Check for "stop applications" commands not being sent by the master station: This is very dangerous if sent broadcast to all RTU. The following snort rule can be used to check this behavior, assuming that HMI ip address is 1.1.1.1:

alert tcp !1.1.1.1 any -> any any (msg:"Someone trying to stop the applications of an RTU device"; dnp3_func:stop_appl; sid:1;)
 

I would include a couple of special wishlist to the Sourcefire guys to include in next versions: IEC60870-5 and Bristol Standard Asynchronous Protocol (BSAP), used in water supply SCADA systems.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Keywords:
5 comment(s)
Diary Archives