Eric, 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 events. 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 individually. More Tips: - 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 #2190: http://iss.custhelp.com/cgi-bin/iss.cfg/php/enduser/std_adp.php?p_faqid=2190 (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 [email protected] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo/issforum To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] The ISSForum mailing list is hosted and managed by Internet Security Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
