[Discussion] Features suggestion

[Martin Holste]

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.

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.

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.

--Martin

On Thu, Nov 6, 2008 at 1:03 PM, Jeremy Hewlett <jh at dok.org> wrote:

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