It’s been a little while since we’ve had a Quickdraw update, and I wanted to fill everyone in on how we’re doing and the approach we’re using.

As we’ve described before we’re basing the project on the snort 2.8.x tree, and we could do much of the processing and alerting using only the snort rule language itself, but not only would it be horribly inefficient, but it would also be impossible to maintain, so we’ve went with a preprocessor model.

So we’ve created preprocessors to do all the “heavy lifting.”  While the Quickdraw project is about supporting specific field devices we’ve taken a bit higher level view to begin with and created preprocessors for each of the protocols that these devices support.  These preprocessors go through and organize all the bits and bytes on the wire into a nice data structure that we can examine later.

Now it looks like we could do everything we need from these preprocessors, but since the Quickdraw project is designed to support devices and not protocols (with good reason since specifications are often treated as little more than suggestions) we have to have some logic to figure out just what is going on with each particular type of device.  This is where our detection plugins come into play.  By adding these to the snort source tree we expand the rule language that snort uses, and add our own keywords, allowing us to check numerous conditions before making a decision, and then outputting in whatever style we wish.

Here is an example of the rule language and the output:

alert tcp any 44818 -> any any (msg:”(Event 45) Reboot or Restart”; cip_service:5; category:availability; sid:99999111; rev:1;)

11/12-19:15:08.104614 [**] (Event 45) Reboot or Restart: SUCCESS [**] Category: Availability [**] Controller IP: 192.168.10.105, Client IP: 192.168.10.120 [**] User ID: none [**] ENIP/CIP service 05, ENIP handle 0x11020100 [ C:0x20 I:0x0072 C:0x24 I:0x0001 ] [**] Signature: [1:99999111:1] [**] [Priority: 0] {TCP} 192.168.10.120:44818 -> 192.168.10.105:1102

As you can see, there’s already a huge amount of “power” available with being able to write rules at such a high level while still having access to all the information in the stream.  This will not only be a benefit to the Quickdraw project, but should also allow for expansion and greater accuracy in future IDS signature sets.  Ethernet IP (still a terrible name), and CIP are completed, DNP3 is well under way, and I should be checking the modbus preprocessor into the source tree later this week.