OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: how to do intrusion detection right

Re: how to do intrusion detection right

Paul D. Robertson (probertsclark.net)
Wed, 15 Apr 1998 19:14:50 -0400 (EDT)

On Wed, 15 Apr 1998, Marcus J. Ranum wrote:

> Paul D. Robertson wrote:
> >1.3) The more adept ones will filter the alerts through some sort of
> > engine to decide which ones reach their pager. In some environments
> > this could be a very good thing.
> >
> >1.4) Others will learn which alerts mean "hit erase" and which ones mean
> >"grab the Palm Pilot and ssh in".
>
> In other words, the administrator will apply site policy to the IDS
> by building a filtering layer on top of its alert mechanism. That will
> be based on the administrator's knowledge of site policy and local
> risk/threat posture.
>
> We're 100% agreed. But what what I am saying is that the IDS should
> be able to permit that tuning directly, by getting that information
> from the administrator so the IDS can tailor its behavior to what
> it has been told is acceptable/unacceptable/interesting about the
> network it's watching.

Right, but what I'm saying is that, and I failed to clearly state it
because I was too busy making witty 6 year-old comments ;), is that this is
better done at the administrator level in some cases. A learning admin
needs to be able to learn what's "good" and "bad", and as a network
changes, the IDS' filters won't get updated, the human ones may. While
certainly there are people who will lose their tolerance over time and
hit "delete" every time, there are also people who will want to adjust
their thresholds in real-time. This may or may not be possible at the
IDS (How much change do you expect on a security-critical machine, I like
little because it makes changes auditable). While it may run counter to
what's ultimately marketable, I would really prefer to set my own
thresholds and adhere to them. If I knew a new attack came out this
morning, and I was off-site, there may be an alert that I'd now want that
was in the "hit delete" catagory last night.

I tend to syslog *.debug quite often, and then grep those logs for what
I'm really after because I can always go back if I have the data, but if
I never log it, its lost forever. I consider some alerts to be in the
same vein, and my tolerence is probably farily high for a little
inconvenience because I think the risk/reward scenerio is higher than
doing it the other way around. If I'm never alerted, I don't know
something happened.

Now if your system follows BUGTRAQ, *security, comp.security.*, etc.
changes its thresholds, I'm ready to buy. Until then I prefer to do most
of my filtering manually. But then I handle e-mail the same way, I've
got procmail, but it's only used for the corsest functions, not for
everyday sorting.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
probertsclark.net which may have no basis whatsoever in fact."
                                                                     PSB#9280

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:10:47 CDT