Re: Assessment tools/Scanners

[roesch () clark net (Martin Roesch)]

Greg Shipley wrote:
> Ok, sorry about that - let me clarify: they are all "signature based."  I
> guess we are sort of debating semantics here - and I guess it depends on
> your definition of "knowns" and "anomaly detection."  We could build an
> entire IDS suite that checks for RFC-compliant packets and protocols, and
> yes, it would have its use (although we'd probably spend most of our time
> clearing out alerts generated by MS products), but I'm not sure if this is
> going to achieve the desired affect.  I'd argue you would have a higher
> success rate of "anomaly detection" by correlating log data and using
> statistical analysis (behavioral ID, user profiling, etc.) techniques, no?

Well, as Dug Song notes, anomaly detection based on statistical methods
is tricky business and dependent on thresholds.  Thresholds as a
detection methodology are the hackers best friend. :)  Doing RFC
compliance checks isn't going to fly in a world where people continue to
buy network operating systems from Microsoft.

> Most of the current ID products that I know of still work off of fixed
> sigs.  So you have things like LOKI and BO2k that can cruise through ICMP,
> and in theory, you could flag those packets as an anomaly.  But I've also
> seen NT spew some flat-out AMAZING stuff in NATted environments, which I'm
> sure would set off a billion alarms as well.  This could be really
> interesting, and really messy, at the same time.  :)

Snort works completely off of fixed sigs but can still detect some sorts
of anaomalous behavior.  For instance, you can load it up with invalid
TCP flag combinations, out of range ICMP types and codes, or even do
really simple stuff like tell it which addresses don't exist and which
ports are closed on your entire network and have it squawk anytime it
sees stuff going where it shouldn't.

> My (attempted) point is that by allowing for customization, you give the
> user/client some power.  Does the average org have the skills to code a
> new sig?  Absolutely not - and that's been one of my complaints with NFR -
> lack of a large groups of sigs (which will most likely be solved with
> those new L0pht sigs).  But at least by giving that level of flexibility
> those organizations that do have the staff, or those that feel this is
> important, can code things up on their own - they are not at the mercy of
> the IDS vendor.

I agree completely.  Products that don't have the facilities to make
changes to existing sigs or add new sigs are a PITA. :)

> Sure, sure, but you do get the propagation factor.  Take a look at the
> Bind attacks, for example.  You had the initial scripts that evolved out
> of the BUGTRAQ postings.  Then you had a BSD/Linux based exploit (and I'm
> not kidding) that actually had a menu.  Then you get a crew like ADM, that
> may have written some exploit code initially, but went back and RE-wrote
> them.

Right, and as the IDS vendor you have to be anal about updating your
sigs, which kind of gets you into the mentality of the anti-virus
market. <shudder>  There are some efforts underway to make signature
developement a community project for systems that use them.  Check out
http://www.whitehats.com for one such effort.

     -Marty

-- 
Martin Roesch
roesch () clark net
http://www.clark.net/~roesch