Good points, Jeremy.  I agree that having a specification for follow-up traffic would be a great feature.  I also strongly agree that flows are an integral part of any NSM setup.  <br><br>As an example, running a list of known-bad IP's against last week's flows can be really great way of finding infected hosts that have evaded IDS.  It follows then that the infected machines I find that way are usually the most sophisticated and novel hacks.  Studying those incidents leads to the creation of new signatures, which feeds back into the IDS net.  Supporting that process as much as possible is a worthwhile goal for this project.<br>

<br>I feel I must give a word of caution regarding the pursuit of network behavior anomaly detection.  I would instead suggest that this group focuses on providing ways to define things which are absolute, and not subjective in any way.  A system which can spew out info like "these 4 hosts downloaded files which have an average .src entropy higher than 7" would be more valuable than a system which tried to guess at which 4 hosts were not acting like the other hosts on the network.  Obviously, if your system can pinpoint interesting things, you are close to identifying odd traffic patterns.  The key difference I am trying to point out is that I think it's less useful to spend time identifying how many or what percentage entropy is "odd" than it is in creating new ways of measuring something like file entropy.<br>
<br>--Martin<br>
<br><div class="gmail_quote">On Thu, Nov 6, 2008 at 1:03 PM, Jeremy Hewlett <span dir="ltr"><<a href="mailto:jh@dok.org" target="_blank">jh@dok.org</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;">

Greets all,<br>
<br>
After having an impromptu conversation with Jonkman about IDS features, we<br>
decided I should post some of my thoughts here and see what you guys think.<br>
<br>
One of my long-standing irritations with IDS is a lack of ability to know<br>
what else occurred after an alert was tripped. So, to that end, I've listed<br>
out my thoughts in order from easy implementation to harder to implement.<br>
<br>
Currently within Snort we can enable tagging on a rule so that we may<br>
follow streams/packets after an event. This is often useful to me, in the<br>
very least, to ascertain if an attack succeeded. Unfortunately, the act of<br>
enabling tagged packets is tedious (but scriptable) task if I have more<br>
than a handful of rules I want to modify. A method of globally setting a<br>
tag definition that would apply to (groups of? all?) rules would be the<br>
preferable way to accomplish this.<br>
<br>
The second, but related thing I'd like to see is a method of recording IP<br>
flows. I find this type of thing useful for statistical analysis, the IDS<br>
already has this information available to it, and it mostly solves the<br>
issue of not knowing what traffic (if any) occurred after an attack. It's<br>
actually better because it doesn't necessarily require a rule being tripped<br>
first... which leads me to my third point.<br>
<br>
Anomaly detection / ability to learn normal network behavior. I'm sort of<br>
disillusioned with rule-based IDS, especially now that targetted attacks<br>
are becoming more prominent. An ability for an IDS to learn a network and<br>
recognize bad/unusual/odd traffic patterns and payloads would be a huge<br>
boon. This also fits in well with PassiveAppOSIdentification that I saw<br>
already listed on the OpenInfosec feature list.<br>
<br>
Anyway, those are my thoughts. I tried to keep it brief, so let me know<br>
if I need to expand on anything.<br>
<br>
_______________________________________________<br>
Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org" target="_blank">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>
</blockquote></div><br>