Re: Assessment tools/Scanners

[gshipley () neohapsis com (Greg Shipley)]

On Mon, 11 Oct 1999, Martin Roesch wrote:

> > Not sure what you are asking here - almost all of the commercial ID
> > products are looking for knowns, and knowns only.  They are
> > signature-based.....
>
> Allow me to interject for a second.  I wouldn't say that all commercial
> IDSs are necessarily straight jacketed into signature detection only,
> almost all of them have some sort of facility to perform anomaly
> detection as well.  Even Snort can do primitive anomaly detection, such
> as alerts on bad TCP flag combinations or looking for tiny fragments.  I
> think that the ability to develop anomaly detection schemes with a tool
> is pretty important, and you can do that with both NFR and Dragon (and
> to a lesser extent, Snort).  Sure, they provide the capability to look
> for set "patterns" in packets, but they can also be tuned to look for
> things you should *never* see.

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?

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.  :)

Dunno - this is an area where I think in theory works, in practice may be
kind of difficult....although I do realize that it IS working, to some
degree, in some products right now...
 

> > The advantage of the NFRs and Dragons of the world is that you can, fairly
> > easily, code up your own "sig" for an attack.  I know ISS RealSecure v3.2
> > has some of this flexibility, but not as flexible as, say, NFRs n-code.
> > Are there any products that do network-level statistical profiling, to
> > look for "unknown" attacks?  Not that I know of, but that's just me....
>
> This requires codifying the statistical "signature" of a new attack,
> which can be a fairly daunting task.  Questions like "what header fields
> do I keep track of?", "what are the characteristics of a
> post-buffer-overflow root shell session?", "how much traffic represents
> a valid statistical sample?", etc need to be answered before you can
> define a method of statistical analysis for intrusion/anomaly
> detection.  Doesn't CMDS try to do some sort of statistical analysis?

Yes, CMDS does, but not on the level you are thinking (and that WOULD be
cool).  CMDS does more based on log and event entries, rather then raw
network traffic.  I'd argue that if someone could pull off a
statistical-based analysis of raw network-traffic, that product would be
ground-breaking, but wow, talk about a task....

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.

> > every check.  And even then, make no mistake, you CAN mutate attacks to
> > the point that network-based ID will fail.
>
> Definitely, but the vast majority of script kiddies don't do this either
> because they're lazy or because they don't have the "skillz".  Whether

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.

Now you have the first generation of the attack...and then a 2nd and 3rd
generation down the road.  Now, if you ftp to one of ADM's sites you'll
see some new(er) bind exploit code.  This may be a poor example because of
the nature of the Bind attack (pardon my ignorance here, as I am NOT an
adequate coder of sigs), but you see where I am going, no?  I may be a
script kiddy, and my IDS vendor may have nailed that first attack, but if
the attack signatures are susceptible to mutation, we still have a problem
with script kiddies.

I guess what I'm trying to say is that we shouldn't under-estimate the
"script kiddie" generation.  If I'm a good script kiddie, I'll keep up
with the exploit script mutations - and they DO happen "in the wild."  
But I agree with you, a lot of this does pertain to your posture and what
resources you are willing to invest in network defense.

-Greg