If you've been following this blog for a while, you might have noticed that Lurene only shows up when there is evil to be done. This is why she is here; she's really, really good at it. She is also the analyst team lead and makes sure we are all keeping the fuzzers running, studying emerging exploit techniques and generally getting up to no good.

But recently, in talking to some folks, we've become aware that there are some edge-case detection things that folks are looking for solutions for. So we're (trying) to break off some time to do some research on weird detection needs some of you have. Most of these seem to be CPU intensive efforts where it would be difficult to keep the Snort engine running at line speed. Some involve processing traffic in a different way or generating a batch of rules up front after some specific calculations.

These requests come mostly from organizations with an established security team with excellent reverse engineering and forensics skills, looking for help with problems specific to their environment and the threat it faces. But I would think there are a lot of you out there that might want to leverage Snort and its optimized search engine, rules language and SO capability to do very specific detection, where you aren't as concerned about overall performance.

My recommendation, if you wanted to work on edge case detection, would be to use the SO rules language (blog posts coming soon, I swear) and place them on a dedicated IDS sensor. Use the optimizations in snort: fast-pattern matching, normalized, decoded buffers and the snort rules language as a start, and then add to that using C. Prototype your detection and don't worry about performance impact.

With the caveat that you may never see one line of code from us on these items, here are some of the things we're kicking around:

• File parsing in Snort
  
• Writing rules directly into the detection structures based on specific detection needs
  
• Looking at detection under various assumptions (no frags, no reassembly needed,etc..)
  
• Working on the ability to shunt traffic offline for "near real-time" detection (for heavy duty detection that would never be able to happen at line speed)
  
  So here's what I want to know: If you didn't have to worry about line speed, false positives, false negatives, reassembly, throughput, buffering or any of the other factors that impact the balance between detection and performance, what would you do? What would you want to see?

Drop us a note at research@sourcefire.com, or leave a comment below. If necessary, our pgp key can be found here: http://www.snort.org/vrt/vrt-pgp-public-key/