Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: Snort 2.9.2 now supporting SCADA protocol checks - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Snort 2.9.2 now supporting SCADA protocol checks

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

Manuel Humberto Santander Pelaacuteez

185 Posts
ISC Handler
Thanks for the sample snort rules for the DNP3 protocol, however, I would like to point out that the last rule is in fact a duplicate of the previous rule.
John

4 Posts
Sorry! My mistake. I already corrected it. The DNP3 function is "Stop Applications", which is referenced inside snort as stop_appl. Thanks!
Manuel Humberto Santander Pelaacuteez

185 Posts
ISC Handler
The message of last rule is wrong, it should be "stop app" no "save config" :-)
Manuel Humberto Santander Pelaacuteez
1 Posts
thats just awesome news.

thanks for the article :')
joco

8 Posts
Don't forget to change the text of the message in the Stop app case also.
dave

21 Posts

Sign Up for Free or Log In to start participating in the conversation!