Up
Previous Next

Sheriff CSM™

Policy Management

Sheriff CSM 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 Sheriff CSM to determine which events are processed by the policy, and consequences to define what will happen when events match the specified conditions.

Sheriff CSM 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 Sheriff CSM Server.

Common Examples of Policies in Sheriff CSM

There are many ways you can use policies to manage and control event processing within Sheriff CSM, 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 Sheriff CSM 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 Sheriff CSM 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 Sheriff CSM 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 Sheriff CSM 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 Sheriff CSM Server without storing them — In larger, distributed deployments, you can tier Sheriff CSM components to improve performance. For example, you can correlate events on a child server and forward them to a higher level Sheriff CSM 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 Sheriff CSM 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.