I disagree that this is out-of-scope.  I think that this falls well within the detection engine's purview,
as evidenced by the fact that we've all been using flowbits in Snort
for a long time now.  It's the detection engine's job because we
need to be able to write rules which have some correlative properties,
and as far as I know, we're writing the rules for the detection
engine.  The extra properties that frameworks like OSSIM have allowed
for are intellectual property to be shared just like the Emerging
Threats detection rules.  Sharing with the community that "pattern X is malicious" is helpful, but it's even more helpful to share with the
community that "pattern X in context Y" is malicious. <br><br>In order to accomplish this, I think we want our engine to provide contextual traffic immediately surrounding the incident.  I find that the Sguil-style full capture is by far the most effective, but I recognize that it is impossible to do that in lots of environments for various technical and legal reasons.  Something like an improved version of Snort's "session" and 'tag" keywords for rules would probably go a long way towards this goal.  <br>
<br>As an example, one of my favorite command line switches for the venerable grep program is "-C <number>" which means return plus and minus n lines of the file from the match. This establishes the context of the match in the document you are searching so you have some idea as to what it meant in that particular part of the doc.  This is exactly the same requirement we have when grepping network traffic, but most current tools provide no way of seeing the traffic immediately preceding the sought event.  This is obviously because you have to record everything since you don't know ahead of time what you'll be looking for.  However, if you only save a few seconds or minutes prior to the current time, this is not as daunting as it sounds.  As I've previously mentioned, Bro and Timemachine do this already, and they do it very effectively.  Timemachine writes traffic to RAM/hard disk and Bro can query it to get some context.  When Bro queries Timemachine for traffic still in RAM, it gets the results in milleseconds.  The queries are built right into the Bro signatures.  Our engine could have rules that specify prior events right in the rule, which opens to door to a much more flexible system and rules that can specify a dynamic event hierarchy.  For instance: <br>
<br>Look for event X<br>If found, look for event Y in the traffic up to five seconds before event X.  <br>If found, begin looking for event Z for the hosts referred to in event X for the next five minutes.<br><br>A real-life example would be something like this:<br>
<br>Look for the possible Trojan check-in URI pattern "x=digits&y=digits"<br>If found, check if the source host downloaded any EXE or PDF files in the last five seconds.<br>If found, check to see if the source host makes any POSTs or requests any EXE's for the next ten seconds.<br>
<br>Bro already allows for this, and if we're going to be creating a "next-gen" detection engine, we need to at least match this capability.  So from a signature structure perspective, we're looking at a basic content match sig which contains an array of signature ID's that should match prior traffic and an array of signature ID's that should match subsequent traffic.  So, it's a lot like Snort's flowbits except you can specify boolean operators on arrays of flowbits, instead of just one flowbit.  Depending on how we make the signature syntax, maybe you could even include the other sigs as partial sigs inlined into the main sig so that everything is contained in just one signature.  Something like:<br>
<br>content:"this"; content: "that"; prior: 5 minutes; content "the other thing"; subsequent: 30 seconds;<br><br>Or as references to other sigs:<br><br>content:"this"; sig_sid:1001; prior: 5 minutes; sig_sid:1002; subsequent: 30 seconds;<br>
<br>If the match for "that" is extremely common, then you wouldn't want to search for it all the time, you'd only want to search for it when you know something interesting has occurred, retroactively.  Additionally, instead of white and black matching, maybe these auto-adjust the signature's fidelity rating:<br>
<br>content:this"; (sig_sid:1001; prior: 5 minutes; fidelity:+5) (sig_sid:1002; subsequent: 30 seconds; fidelity: +10)<br><br>I think that it's important to put the fidelity modifiers right into the signature instead of forcing everyone to figure that out on their own.  If you leave that information out of the signature, then it's much harder for the community to contribute improvements to those properties.  Naturally, there will be org-specific modifications necessary like any rule, but if the signature creator has the chance to say up front that the signature is a better match in a given context, I think that's a major leap forward.<br>
<br>--Martin<br><br><div class="gmail_quote">On Sun, Mar 1, 2009 at 9:43 AM, Matt Jonkman <span dir="ltr"><<a href="mailto:jonkman@jonkmans.com">jonkman@jonkmans.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I definitely like this too. But it's way into post processing. Out of<br>
our immediate scope.<br>
<br>
But what information could the engine provide to help the event manager<br>
make these decisions? Surely there's something it could help with?<br>
<br>
Maybe on the behavioral note the engine could start full captures or<br>
something when suspicious things happen so the analyst would immediately<br>
have more context?<br>
<font color="#888888"><br>
Matt<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
> First of Kevin's ideas:<br>
><br>
> Ossim (<a href="http://www.ossim.net/" target="_blank">http://www.ossim.net/</a>) has an interesting use of the reliability<br>
> of the sig, the priority of the host and some other things to assign a<br>
> risk to the attack. Using a similar system individual signatures can be<br>
> given a reliability which could mean sure fire attacks are flagged<br>
> immediately while unreliable signatures are not flagged immediately<br>
> until other factors are met. For instance under ossim you can basically<br>
> say (in an xml directive) if there are these snort sids it is a<br>
> reliability of 3 and if these snort sigs appear +2, if it persistent<br>
> (for a set time) +1 and if a web page error message appears +1 and so<br>
> on. Using such a system could mean false positives can automatically<br>
> lowered while making more reliable attacks against priority resources<br>
> and the events related to that attack available to the analyst (being<br>
> able to define the priority of an asset such as a server farm in<br>
> comparison so the secretary's desktop would be useful). Also things like<br>
> if the attack was blocked by IPS or even a firewall if the logs are<br>
> available that the attack was mitigated the risk level can be reduced.<br>
><br>
><br>
<br>
--<br>
--------------------------------------------<br>
Matthew Jonkman<br>
Emerging Threats<br>
Phone 765-429-0398<br>
Fax 312-264-0205<br>
<a href="http://www.emergingthreats.net" target="_blank">http://www.emergingthreats.net</a><br>
--------------------------------------------<br>
<br>
PGP: <a href="http://www.jonkmans.com/mattjonkman.asc" target="_blank">http://www.jonkmans.com/mattjonkman.asc</a><br>
<br>
<br>
_______________________________________________<br>
Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
</div></div></blockquote></div><br>