Can The Pig Sling? Implementing Quickdraw in Snort
Quickdraw is a software tool currently under development with funding from the Department of Homeland Security to passively analyze network communication between components of a SCADA system, track user transactions and log Security Events that could impact the system. The last post on Quickdraw outlined some high-level ideas about Security Events. This post explores some ideas on how we intend to go from network packets captured off the wire to high-level, context-sensitive log messages.
It seemed from the team’s experiences that the problem Quickdraw is trying to solve is similar to that of an IDS system, with Snort naturally the system coming first to our minds. Network traffic collection, protocol reassembly, transport state management, contenting matching and a log output system are all requirements shared by both Snort and Quickdraw. There’s enough overlap that some effort was spent exploring if Quickdraw could be implemented in Snort’s framework.
A Security Event is a more semantically rich object than an intrustion alert, composed of information that is collected and interpreted as application protocol tranactions are executed. The Flowbits module facilitates some basic protocol state tracking but with no means for capturing and managing the session data from the protocol stream. A Snort plugin to support this funtionality will be developed to not only allow Quickdraw to correlate response messages from devices with the specific user actions that initiated it but to manage session data during the transaction. This will allow the user to define context-aware log messages using data extracted in the familiar Snort rule syntax. We’ll be able to create some neat log messages like “Register 10 was modified by FooUser” and “Unspported Function Code 255 was accessed” and start exploring the capabilities of Snort as an Application Protocol-aware NIDS.
Other technical issues exist as well unique to working with SCADA protocols. Like DNP3 and MODBUS/TCP, many TCP/IP-based SCADA protocols are simply enscapsulations of the serial-based protocol in a TCP or UDP packet. This includes a large amount of redundant information for link and transport management (such as the venerable “transport function” of DNP3) that Snort simply views as the packet payload. The development of preprocessor modules to perform decoding and reassembly for SCADA protocols will also be likely to simplify rule development and maintain Snort’s performance.
Ben Feinstein’s Snort plugin development presentation at DefCon, which Daniel made mention of in his post, comes well timed as an example of using Snort’s facilities with advanced application protocols and I think lends some support that Snort is up to the challenge of Quickdraw.
Any thoughts on using (abusing?) Snort as a security log generator? Are there any other IDS or similar platforms that are better suited for deployment in your organization? Who has already deployed Snort in their SCADA environments? Please leave a comment!
Author: Frank Marcus
Posted: August 11th, 2008 under Quickdraw.
Comments: 3
Comments
Comment from Erik Hjelmvik
Time: August 12, 2008, 3:00 am
I definitely like the ideas for this project, so I’ll share some of my ideas on this topic with you.
You point out that the security events you are looking for are more complex than just a normal snort signature, since you actually have to parse the protocol (be it DNP3, MODBUS/TCP, IEC 61850, IEC 60870-104 or whatever). Because of this I would strongly suggest that you look at Bro IDS http://www.bro-ids.org/ rather than Snort. Snort isn’t really designed to parse protocols, but Bro is.
Something I also think you should consider is to actually store a piece of network traffic to a pcap file when serious alerts are triggered. It can be a good idea to have a packet buffer which allows you to store all sniffed traffic between, for example, 10 minutes before the alert and 10 minutes after the alert. The captured data might be very useful as forensic evidence later on.
Good luck with your Quickdraw software!
Comment from Jason
Time: August 12, 2008, 1:48 pm
I think this is the need SnortSP is actually trying to address. The “Snort Security Platform” gives you all the required stuff like reassembly and packet acquisition. Snort 2.8 is just an analysis engine built on top of SnortSP. So its really a framework to facilitate the writing of network monitoring applications.
Comment from Frank Marcus
Time: August 14, 2008, 2:44 pm
Jason,
Yes, you’re right. I’m excited about SnortSP because it fixes so many of the difficulties one finds when trying to extend Snort. I’m really looking forward to the the pluggable protocol decoding framework and the data acquisition API. since these are major bits of functionality needed by Quickdraw for which there is no analog at all in Snort 2.8.x. The multithreaded architecture of SP that will help on some of the performance issues that will probably limit the initial version of Quickdraw, especially for the heavier, slower state tracking stuff.
Since SnortSP is being designed with backwards compatibility in mind, I hope the plugins and preprocessors that are written to support Quickdraw’s functionality will port easily to the new framework. However, prime time for SnortSP is still a ways away and deployment in production environments even further. I don’t doubt you’ll see Quickdraw on SnortSP once the platform sees its initial full release and adoption in our community.
Erik,
You’re right on with Bro. I used it a few years ago when I was still in school for a project and I really like the event abstraction that Bro has (in addition to the more extensible decoding framework). There’s a couple reasons we didn’t go with Bro - most of Digital Bond’s non-commercial IDS expertise is in Snort, we’ve released and maintained a set of Snort IDS signatures that have been pretty successful, and Snort seems to be more accessible to the operator audience we’re targeting.
I’m happy to be wrong here - Bro is a better technical fit for Quickdraw but we weren’t sure that it is used widely enough in SCADA and Process Control to make deployment comfortable.
Write a comment