|Applies to Product:||USM Appliance™||AlienVault OSSIM®|
When you first start using USM Appliance, it is a good idea to let it run for a few days to determine which events and alarms you can consider "noise" and which ones to investigate further. By noise, we mean false positives that obscure true positives, or events that may indicate truly malicious behavior.
Because no system is perfect, you must ensure that you have actionable alarms and useful reports — not hundreds of things to review. What you learn from the baseline collection and the evaluation of those events helps you create policies that tell USM Appliance what is important — or not.
To be able to tune the system, you need to create a baseline for what constitutes normal behavior in your network. This is called baselining. The alarms and events generated during this initial period represent currently normal behavior, in other words, a snapshot in time. Of course, there may be things you want to filter out right away. But in general, you should resist the temptation and wait until you have had a chance to observe any patterns in your network.
After you collect these data points, you need to start making decisions about them, based on the following criteria:
- Which events have value and applicability to my system?
- Which events have to do with network policy and therefore are not potential threats?
- Was the risk properly assessed?
- Which events have value for reporting?
- Who should receive notification when this event occurs?
Answering these questions for the first time is best done in a group setting with the relevant stakeholders. In subsequent iterations of this process, usually only the analysts participate, because the fundamental questions for each event can be applied through taxonomy. Because AlienVault releases new signatures frequently, this decision process should be repeated at regular intervals.
Filtering Out the Noise
Some false positives you may want to identify and filter out right away. One example might be an alarm indicating scanning of hosts in the network. Such activity can be completely legitimate if performed by an internal network mapper. On the other hand, it may be currently benign, but may also be a precursor to a real attack. USM Appliance treats both events equally.
If you examine an alarm and you determine that the event that triggered it was noise, not a real threat, consider taking the following steps:
- Create a policy that prevents USM Appliance from processing new events from the source. For example, let's say that USM Appliance properly detected vulnerability scanning coming from an internal scanner but such events do not interest you.
- If not interested in specific alarms, you can do the following:
- Reconfigure the external data source not to send such events.
- Use a policy to discard such events.
- Disable the correlation rule.
Creating New Policies
You may also want to create a policy to reduce the number of false positives. For example, you might create a policy that USM Appliance no longer processes events from the specific host that is the source of false positive events.
Let's say that USM Appliance properly detected vulnerability scanning coming from a vulnerability scanner inside of your system. If you have no interest in such events, because your environment controls the vulnerability scanner, you can create a policy that excludes events coming from it, so that the USM Appliance Server does not process them.
After performing either or both of these tasks, you should delete all occurrences of the alarm from USM Appliance. For information on how to do this, see Reviewing Alarms as a Group.
Tuning Correlation Rules
Tune your correlation rules, if needed, to adjust priority or reliability, or both, to change risk level. If the risk is value lower than 1, USM Appliance does not generate an alarm.
One example in which you might do this would be a correlation rule that detects instant messaging. If your company security policy allows instant messaging, you do not need to receive warnings about such events.
If the alarm was a false positive, in other words, it was triggered by traffic that should not have done so, you must customize the correlation rule that triggered the alarm. After you have customized the rule, label the existing alarm as a false positive, and close it. (For details, see Reviewing Alarms as a Group.)