The select set of IPS/IDS events should be based on internal
environmental information as much (or more) than external information.
Here's some factors to consider:
Risk Assessment:
The most important factor in choosing IPS and IDS events is
understanding what you are protecting and what it could cost you if
one of your systems is compromised. For example, one may be willing to
invest quite a bit of time and money to protect a database server
containing all customer's credit card info. On the other hand spending
the same amount to protect an ephemeral virtual machine used as a web
kiosk would be a waste.
A good risk assessment will identify critical systems and critical
services. A critical system will skew the selected set towards more
enabled events. A critical service will likely skew the set towards
fewer events enabled in a blocking mode as the risk of disrupting the
service may out weigh the benefit of stopping some attack attempts.
Staff:
All IDS alerts need to be processed by a human at some point. If IDS
alert logs are simply deleted and never processed then why bother?
Even IPS events should be reviewed by someone, however, the tolerance
for late review is much greater.
Likewise the expertise of the staff will change the set of IDS/IPS
events that would be enabled. For example, an expert staff with
available time may be able to process protocol anomaly alerts while a
novice staff or one strapped for time may only have time to
concentrate on vulnerability or exploit alerts.
The Events:
Once the first two items are understood then selecting the actual
events is a bit easier. The first step is to enable all events for any
service provided by a critical server. Then based on the criticality
of the service and the severity of the event (and the chance of false
alerts) decide whether it should be enabled as blocking or not. If the
alerts triggered by this set of events begins to overwhelm the
security staff then lower severity events may need to be disabled. On
the other hand, if the work load is light enough maybe it is time to
expand the IPS/IDS deployment to also protect medium value systems.
You may note that one of the factors I did not list is the actual
capacity or ability of the IPS device itself. Chances are that if you
factor in the capacity of the security staff you will rarely overload
the capacity of the hardware. Of course, if you do then you need a
better IPS.
-J
On Dec 8, 2007, at 8:16 AM, Ravi Chunduru wrote:
i understand from several emails in this list is that UTM or IPS
devices enable only subset of signatures for detection as well as
blocking - it is being termed as 'sane IPS', 'out-of-box IPS' ,
recommended etc..
is there any criteria (standard or non-standard) used in categorizing
signature as 'recommended'? is it based on CVE priority?
Thanks
Ravi
------------------------------------------------------------------------
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.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw
to learn more.
------------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
