Re: [logs] intrusion detection and log analysis [was: book advice]

bet@private

2003-11-04T02:45:00 Tina Bird:
> On Mon, 3 Nov 2003, Eric Johanson wrote:
> > Sorry for the IDS rant.  I'm sure ya'll have heard it before.  My only
> > real exsposure to IDS is via snort.
> >
> > It works on 'blacklists' of known bad data, or stuff that 'looks bad'.

That's a feature, not a bug:-).

Seriously, there's use in the world for both signature-based
monitoring and various styles of anomaly detection. Snort can
actually do both; its plugin architecture provides the platform for
doing anomaly detection, and its signature engine works well too.

Anomoly detection has the potential to detect heretofore completely
unknown types of attacks. On the other hand, signature-based
detection has the advantage that it's built on a knowlege base, so
the alert specifies what the attack was, and can be linked to a
database of detailed descriptions.

> > I suspect we'll start seeing products in a few years that are
> > focused on 'whitelisting' traffic.  Anything that doesn't match
> > this pattern, kill it.

Sounds like an application proxy firewall, to me:-).

> > While this is a pain with lots-o-crappy protocols, it is possible.  Does
> > anyone know of a product that functions this way?

All the firewalls I build.

IDSes add information collection for failed attacks to the mix,
plus they can offer some help in detecting attacks through those
lots-o-crappy protocols. IDSes can play a role very analogous to
their kin, virus scanners. For example, good email servers for
user bases that use vulnerable MUAs will weed out all but a short
whitelist of MIME types, but since that short list usually ends
up having to allow some document types that allow arbitrary code
execution when loaded, you end up having to add virus-scanning
anyway. In the same way, if you have to allow scary protocols, or
let people use scary clients, an IDS can at least give you a clue of
something bad is happening.

> there are a couple of IDS vendors that claim to do this -- they
> tend to call themselves anomaly detection systems rather than
> intrusion detection systems -- and i've yet to be convinced about
> any of them. the only one i can think of is lancope, but rodney
> probably knows better than i do. the statistical issues are huge,
> because you've got to be able to characterize normal traffic in
> real time with huge numbers of packets.

I've seen one that really convinced me: Mazu Networks
<URL:http://www.mazunetworks.com/>. Their tool is a lot more than an
anomaly-detecting IDS, but that subset of its functionality is
pretty impressive, at least on paper. They're dear enough that I've
never seen one in operation.

> > The other big problem I see with IDS systems is the SNR.  Most
> > are soo noisy, that they have little real-world value.

I know of at least 3 ways to deploy IDS sensors; the problem of lots
o' noise sort of drives these approaches.

You can deploy an IDS sensor just _inside_ a good tight firewall.
Very little tuning will be needed there. There will be a few sigs
you have to disable, provoked by questionable traffic that turns out
to be legit but has sigs written for it because some folks think it
tasteless, or at least tacky. But in my experience that can be as
little as 3-5 sigs out of a database of thousands. After a few weeks
of tuning, disabling noisy alerts, you can refine the traffic until
it gets quite valuable.

You can deploy an IDS sensor outside the firewall, exposed to the
world, and collect stats to help track the climate of the internet,
over time, and collect traces that can be interesting to analyze.
IDSes deployed this way played a crucial role in the early analysis,
that started within minutes of the first release, of Nimda.

And it's possible to deploy an IDS sensor outside the firewall,
rigged to generate alarms about interesting attacks. For some
reason a lot of people think that's how IDSes should be deployed,
but it's far and away the hardest, the most labor-intensive. Not
only does it take a _lot_ of tuning and refining to get quality data
out of such a deployment, it also takes much more active ongoing
maintenance.

-Bennett