If you're looking to the NIDS/NIPS to actually block, this "SIM
proxy-tuning" approach simply won't work. By the time the alarm gets to the
SIM and propagation delay is figured in, it's far too late to block or take
automated action.
The real value of an inline technology is its ability to block on a
packet/socket/flow basis. As such, said inline system must be tuned directly
to do so accurately.
However if automated action isn't your style and your SIM is capable of
sustaining the volume of data an untuned NIPS/NIPS will yield, perhaps
tuning at the SIM and ignoring the sensor itself makes sense. I like the
idea of having all the alarm data available and filtering at the SIM layer
rather than turning the alarm/alert off altogether at the NIPS/NIPS.
On 6/10/05 4:17 PM, "Gary Halleen" <ghalleen@cisco.com> wrote:
I'm seeing many organizations now tuning not on the IDS, but on the SIM
product they're using for monitoring them.
Gary
-----Original Message-----
From: Drew Simonis [mailto:simonis@myself.com]
Sent: Friday, June 10, 2005 6: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.
--------------------------------------------------------------------------
--
Adam Powers
Director of Technology
Lancope, Inc.
c. 678.725.1028
f. 770.225.6501
e. apowers@lancope.com
StealthWatch by Lancope - Security Through Network Intelligence?
--------------------------------------------------------------------------
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.
--------------------------------------------------------------------------
