When you first start using USM Anywhere, it is a good idea to let it run for a few days to determine which eventsAny traffic or data exchange detected by AlienVault products through a Sensor, or through external devices such as a firewall. and alarmsAlarms provide notification of an event or sequence of events that require attention or investigation. you can consider "noise" and which ones to investigate further. By noise, we mean false positivesA condition that is flagged as a vulnerability or weakness that is not actually a concern. This may be caused by other mitigating conditions (such as additional security technology) or inefficient tuning on detection technology. that obscure true positives.
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 orchestration and suppression rules that tell USM Anywhere what is important or not. Alarms are also created from correlation rulesA correlation rule correlates incoming events based on previously defined relationships defined in the correlation directive, associating multiple events, of the same or different event types, from the same data source., which are created by the AT&T Alien Labs™ Security Research Team.
See Rules Management for more information.
To be able to tune the system, you need to create a baselineEstablishing snapshot of monitored system and networks with level of alarms and events generated during a period that represents normal system and network behavior. 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 these 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 rule properly assessed?
- Which events have value for reporting?
- Who should receive notificationCommunication of an important event, typically through an email message or other desktop display. In USM Appliance, notifications are typically triggered by events, policies, and correlation directives, and in USM Anywhere, they are typically triggered by notification rules or directly from alarms. 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 taxonomyTaxonomy is a classification system for security events. AlienVault open source security event taxonomy is a classification system based on 20 main categories and 240 subcategories.. Because AlienVault releases new signatures frequently, this decision making process will be a recurring event.
Filtering Out the Noise
You may want to identify and filter out right away some false positives. One example might be an alarm indicating scanning of hostsReference to a computer on a network. 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 Anywhere 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 these steps:
- Create an orchestration rule that prevents USM Anywhere from processing new events from the source. For example, let's say that USM Anywhere properly detected vulnerabilityA known issue or weakness in a system, procedure, internal control, software package, or hardware that could be used to compromise security. scanning coming from an internal scanner but such events do not interest you, because the internal vulnerability scanner is controlled by your environment. See Orchestration Rules for more information.
- If not interested in specific alarms, you can do:
- Reconfigure the external data source to not send such events.
- Use a rule to discard such events.
- Modify or remove the rule.