Applies to Product:

USM Appliance™

LevelBlue OSSIM®

USM Appliance uses policies to configure how events are processed. Policies define one or more conditions that are evaluated for each incoming event to determine whether the associated action is triggered. Policies play a critical role in the management of effective incident response, and influence many aspects of LevelBlue USM Appliance. Policies use conditions to determine which events are processed by the policy, and consequences to define what will happen when events match the specified conditions.

USM Appliance handles events based primarily on the policies users create to alter its default behavior. By default, events are collected for processing and storage by the USM Appliance Server.

Common Examples of Policies in USM Appliance

There are many ways you can use policies to manage and control event processing within USM Appliance, depending on user, company, and work flow needs. Some practical applications for policies are.

• Send an email notification — You can create a policy to automatically trigger an email to administrators or others whenever a high-risk alarm occurs. For more details, see Tutorial: Create a Policy to Send Emails Triggered by Events.
• Increase the importance of specific events — For a specific IP address or a specific port, you can use policies to generate an alarm whenever events occur that include the IP address of that port, without writing a correlation rule.
• Perform risk assessment and correlation without storing events in the USM Appliance Server — You can avoid storing certain events — such as firewall events you used for correlation on the Server, or instances where the events are no longer needed for correlation — to save space. In some cases, storing them in the USM Appliance Logger long-term for compliance, forensic analysis, or other purposes may work better. For example, see Tutorial: Create a Policy to Discard Events.
• Store events in the USM Appliance Logger without correlating them — In general, you should always allow correlation of events. One exception to this rule might be your security team's use of a honeypot. If you have a honeypot in your network, you do not need USM Appliance to generate alarms for it; you know it will be attacked. Most likely, you would be looking at the logs only as your time permits, because this would be a research project.
• Correlate events and forward them to another USM Appliance Server without storing them — In larger, distributed deployments, you can tier USM Appliance components to improve performance. For example, you can correlate events on a child server and forward them to a higher level USM Appliance Server, or Federation Server, for additional correlation or for storage.
• Reduce false positive alarms — As you collect more events from different external systems, you may run into a scenario that is causing the USM Appliance Server to generate more alarms than you want. You can use policies to filter the events to reduce the number of alarms that are created.