<snip>
For example, if there are no webservers on a segment, I might
not be as inclined to use sigs that check for Apache exploits
</snip>
The logic here is that you don't have a lock for the key being used.
But the information that you're still being attacked is still very
useful, even if the attack on the current segment will fail, because
then you can use that info to block your hypothetical attacker from
segments that DO have Apache. If you ignore or tune out this
information you'll be reacting and behind the 8 ball when the attacker
finds those web servers, expensive and annoying, instead of having dealt
with him up front before any damage can be done when you had the chance.
Just a different perspective on the problem, but then I am a SIM vendor
(as is Anton, of course...)
FWIW
Phil Hollows
Please note my updated contact information: OpenService is now at
www.openservice.com
VP Security Products
OpenService, Inc.
www.openservice.com
Blog: www.openservice.com/blogs
-----Original Message-----
From: Drew Simonis [mailto:simonis@myself.com]
Sent: Friday, June 10, 2005 9:02 AM
To: Anton A. Chuvakin; focus-ids@securityfocus.com
Subject: Re: on NIDS/NIPS tuning
All,
I was thinking about some issues with IDS alerts (their volume, etc)
and
realized I could use some help from the list. It might also be a fun
discussion item.
So, here it is: how many folks who buy/download a NIDS/NIPS actually
tune
it? Long time ago when I was asking this question the previous time, I
was
scared to learn that lots of people do not tune their NIDSs. Is it any
better now?
I know that, in my experience, many orgs don't tune at all. The fear is
that they might do it wrong and thereby miss some important event. IMO,
this is a stupid way of thinking, but I bet it isn't as rare as it
should
be.
In other cases, people do not tune and rely on a correlation engine or
MSS
to filter the events. This is better, but really just moves the tuning
to
a different level.
Personally, I tune sigs and also tailor the sig sets to the devices
being
monitored. For example, if there are no webservers on a segment, I
might
not be as inclined to use sigs that check for Apache exploits. I've
never
really measured the impact on the system vs. the administrative cost of
doing this, however, so it is quite possible I am wasting time for a
negligable benefit.
On the tuning side, I believe that filters and exclusions should be part
of the incident response lifecycle. If I am alerted to an event by an
IDS,
I investigate and discover that the event was benign or did not take
place,
a filter should result, and thus be properly documented.
-Ds
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
------------------------------------------------------------------------
--
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------
--
--------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
--------------------------------------------------------------------------
