Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: [ISSForum] Policy Fine Tuning
From: Go_ISS (greensandgmail.com)
Date: Sat Apr 23 2005 - 22:25:10 CDT
It's great you're doing fine tuning on your sensors -- people often
don't realize how much it improves how well security products work
(since otherwise you can't easily tell the benign data from the real
security risks, and ultimately just end up slowing down your database
with all the extra data you don't need).
I'm a little more familiar with Network Sensors, so I'll make a few
suggestions for those, but it should still apply to the Networking
component of your Server Sensors.
The idea behind tuning your policies is to make it fit your
environment. Before starting any policy tuning, be sure your sensors
are upgraded to the highest XPU level to ensure you can see all of the
Many people like to start with a fairly large policy such as "Attacks
and Audits" or "Attack Detector". These two policies are different in
that the "Attacks and Audits" policy simply has every event enabled,
and the "Attack Detector" policy only has the Attack events enabled.
This can be useful since many people aren't interested in seeing the
low priority audits that occur on the network all the time (such as
people accessing webpages, people communicating through instant
messaging services, and other normal network activity).
Starting with Attacks and Audits is possibly the best option if you
are interested in seeing some of the Audits on your network; if you
are on a fairly busy network segment, just be sure to keep a careful
watch on the data coming in so you don't fill up your database with
spurious audits. Unless you work for a bank (which by law have
special requirements to keep certain data, even if it's useless data)
and you are the security admin, you generally only want to record the
events which you plan to examine. When an event is recorded to the
database, all the details of the event are also recorded (such as
event time, source, destination, and any other data relevant to the
particular event type); after several million events, this can not
only make your database unwieldy, difficult to maintain, and very
slow, but it will make it very difficult for you to tell the real
security risks apart from the benign traffic.
Here's the basic tuning process:
1. Derive a new policy from "Attack Detector" or "Attacks and Audits"
2. Apply the new policy to one or more of your sensors.
3. Watch the events coming in and note anywhere you see an especially
large number of events. Your environment may contain devices which
use software to control or discover information on the network -- this
may be normal traffic for your environment but detected as an attack
by the sensors (since in another environment, that sort of traffic may
indeed be an attack). (see explanation below)
4. Tune out the events in the policy (see explanation below)
5. Go back to step #2 and repeat until the only events you see in
your console are actually events you want to examine (i.e., the events
that might actually be real attacks on your network).
So, how do you tell which events are numerous? There are a number of
different ways to do this. Perhaps the easiest is to go into your
console and select the Analysis View of "Event Analysis - Event Name".
This will show you events and event counts. Examine each event type
one at a time from order of most number of events fired to least
number of events fired. If you decide "I don't feel like examining
this event because I don't actually care about it" (for example,
events about people accessing webpages and other audit events), then
you should probably disable the event in your policy. Once you've
disabled the events you definitely don't care about, look at the new
set of events and determine "What caused each of these events?" You
can figure that out by looking at the source and destination of each
event and if you see it is something internal to your network, try to
find out if maybe one of your computers has a piece of software which
is generating the traffic which is causing the event to fire. If you
figure that out and determine the software is part of the normal
functioning of your network, create an event filter in your policy for
that particular event (only applies to Network Sensors I believe).
You can access the event filters by clicking on the Event Filter tab
along the bottom of the policy editor window. The event filters will
allow you to tell your policy to ignore events of a particular type
when they come from a particular source and/or are going to a
particular destination. Once you have the event filter set up, the
event will not fire or send any responses for that particular source
and/or destination. Event filters can be a very powerful tool for
tuning out the benign traffic on your network that would otherwise
appear to be attacks. This way, you can still see the attacks of that
type when they are coming from other hosts that you know should not be
firing the events. If you do not do this, the real attacks could be
lost among the hundreds of events that come from valid sources!
When you're examining events, you may also want to look at how many
events each sensor is firing compared to the others. You can do this
with the "Event Analysis - Sensor" view. This will show you each
sensor you have and how many events were fired by each. If you notice
one of your sensors firing considerably more events than the others,
then you may want to tune a separate policy for that sensor
- If you have enabled an event in order to have a certain response
fired for that event (such as an email sent to you, or you want to
have the event blocked), but otherwise don't care about the contents
of the event, you can uncheck the "LOGDB" and "DISPLAY" responses in
the policy for that event. This will still cause the response to be
fired, but you will not have to look at the event in your console (and
even better, it will not take up the precious space in your database).
For example, say your company policy does not allow the use of
instant messaging applications. You want to use the sensors to RSKill
or block/drop events that have to do with instant messaging to help
enforce your company policy, however, you don't actually care who sent
the message or what it was about. In this case, leave the RSKill or
drop/block responses turned on, but turn off the "DISPLAY" and "LOGDB"
responses in the policy; the event won't be saved in the database
every time someone tries to send a message, but the RSKill or
drop/block response will still take effect.
- Some events have Advanced Tuning parameters associated with them to
help you tune the parameters specifically for your environment. Be
careful using these since misconfiguring the advanced parameters can
cause the events to fire too often or not often enough. The updated
list of Advanced/PAM Parameters can be found in Knowledgebase Article
(see the pam.zip attached to the KBA)
- I don't recommend it, but you can set up Event Propagation. I won't
go in to it too much, but it requires turning off Advanced Event
Consolidation, and most likely you would have to configure it for
every single enabled event to get it just the way you wanted it.
Event propagation just allows you to record an event for each x number
events that fire within a given period of time.
Hope this helped you out a little. Good luck, and remember -- one of
the biggest parts of security is the process. The more you tune your
policies the better use you'll get out of the products.
ISSForum mailing list
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo/issforum
To contact the ISSForum Moderator, send email to mod-issforumiss.net
The ISSForum mailing list is hosted and managed by Internet Security Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.