SCADApedia
AAA  AAA 

Quickdraw Update

It’s about time for another update on the Quickdraw project, Digital Bond’s passive log generator project.  So far most of the work has been research with the equipment in the lab and writing C code for Snort.  This post is broken up into two pieces, first about what I’ve learned about how equipment talks and second about the code I’ve been writing.

Quickdraw is all about tracking network communication to generate logs for user transactions with “security implications”, which of course correlate to the security events that we’ve defined (and always looking for feedback).  We’re trying to do this by observing the network traffic flowing on the wire.  Normally, we associate well-known SCADA protocols when it comes to device communication, but the use of telnet and FTP, as well as other proprietary protocols, are often used for device configuration and management, like firmware updates and file transfers.  Every (modern) device I’ve encountered so far supports multiple control protocols, uses the IT-ish server protocols like FTP/Telnet/HTTP and has multiple ways to achieve the same functions.  Just sorting out all the ways there is to upload a file can be a workout.

On the plus side, we can use Snort to monitor all sorts of protocols and we can leverage a lot of what currently exists for the IT-ish protocols while adding support for the SCADA-specific material as we need it.  I bit off the first technical chunk of SCADA-specificness and started developing a DNP3 preprocessor and DNP3 detection plugin.  Digital Bond has already developed a set of Snort signatures for this protocol and addressing the limitations we’ve observed was a good starting point for advanced functionality needed for Quickdraw.  We chose DNP3 because its more complex state interactions than MODBUS, simplier than other protocols like EthernetIP and we have experience with the protocol already.

The preprocessor performs a number of tasks, like processing link and transport headers, performing message reassembly and identifying protocol errors and anomalies in these lower layers.  The DNP3 preprocessor also tracks transaction state for solicited request/respone and for unsolicited response/confirmation pairs.  This allows us to generate events that require information from both sides of the transaction, like an unsupported function code or accessing an unknown data point, that currently can’t be identified using Snort signatures alone.

The DNP3 preprocessor passes reassembled DNP3 application objects to the detection engine.  We’re planning a DNP3 detection plugin aid in rule development and to provide access to the DNP3 user objects for inspection.  The goal for this feature is to allow specific application integration using Snort’s rule syntax.  Application-specific rules developed using Snort’s signature language will be configurable by the end user.  We’re also experimenting with providing state collected by the preprocessor to the detection plugin to further enchance the rules one can write.

While a lack of development documentation (a classic complaint of Snort and open source code in general) has been a challenge while learning the APIs and capabilities, so far no major limitation of the Snort platform has been encountered during implementation.  Perhaps the greatest challenge in using existing code as examples of how to use the framework is that with the time-proven performance comes the crufty legacy code and several ways of achieving the same functionality (sort of like controllers :) .  Currently I’m exploring Snort’s capabilities to share information between a preprocessor and a detection plugin so that a preprocessor can do the heavy lifting of parsing headers and tracking state, and a detection plugin can implement quick checks in the rule syntax.  I hope that sharing information will help Quickdraw to be both high-performance and user configurable.  Overcoming this hurdle will likely be one of the more technical challenges of using Snort as a platform for Quickdraw and I’m looking forward to sharing my solutions as the project progresses.  As always, feedback, comments and ideas are most welcome.

Comments

Comment from Neumann
Time: November 13, 2008, 7:47 pm

It’s interesting that you are investigating the use of the Snort engine to preprocess. As an aside I run a secure lab at the University and we have attack-defend sessions. One of the main IDS is snort the students are well-versed in the engine’s limitations as a heuristic detector but the ability to have customizable rules is what makes snort so powerful. Let me how the project progresses and see if if I can help you sanitize your data at the lab

Write a comment