Minimize Alerts with Multi-Attribute Whitelisting
SIEM
By Brian Robertson, Sr. Product Marketing Manager and Kumar Ramanathan, Product Manager
SIEM serves as a keystone tool in the battle to detect, investigate, and remediate threats by providing deep visibility into all systems under an organization’s protection. The downside to this expansive visibility is that SIEM has the potential to deliver an insurmountable number of alerts, many that prove to be false positive, insignificant, or in some cases an acceptable exception to a policy. Securonix has historically leveraged whitelists, among many other features, to minimize the number of alerts triggered by these exceptions to the rule.
Whitelisting works like this. Alerts are driven by policy violations. To create a policy, you configure rules that define the conditions and/or actions that constitute a violation. Often you define actions that allow you to specify the conditions that must be met, such as a user’s department or the execution of a previous high-risk action. You then define an added action that must be performed by the entity to trigger the violation. For example, a condition might check for transactions that are blocked by a firewall. The action can be to perform additional analytics such as checking the data against third-party intelligence, or it could be to log the event as a policy violation. A policy violation alert is then triggered every time a condition set within the policy is violated. However, as stated above with many rules there are exceptions. To define these exceptions Securonix uses whitelists that tell the SIEM if a certain user, IP address, resource group, or other attribute is seen violating a policy to allow it.
Figure 1: Organizations can select attributes such as an IP address, username or email to add to a whitelist.
Securonix has allowed users to define one attribute to a whitelist. However, when trying to create more granular exceptions a single attribute may not be sufficient. For example, an organization defines a policy that employees cannot access data systems from outside of the primary countries in which the organization operates. If an employee does access the system a violation alert will trigger. In this example, let’s say an employee is hired in Italy and needs to access a protected system. This is an approved action by the organization, but the policy created would trigger a policy violation alert every time the employee accesses the system. To resolve this, you don’t want to whitelist just that employee, because that will allow him to access the sensitive system from anywhere in the world. You also don’t want to whitelist the whole country of Italy, because you want to make an exception for a specific employee. In this example you would want to whitelist the employee plus Italy to make sure you do not get an alert for that employee when he accesses the system.
With a single attribute whitelist you can not do this. That is why Securonix is introducing multi-attribute whitelisting. Securonix SIEM users will be able to define or modify functionality or a specific policy with up to three attributes within a whitelist directly from a violation notification. This multi-attribute whitelist capability will be available to all users by default in the Sept R4 build for Securonix Next-Gen SIEM and Unified Defense SIEM. Please view the video below to see how you can create a multi-attribute whitelist.
Securonix Unified Defense SIEM allows users to choose up to three attributes to add to a whitelist.
When a violation notification is triggered, users can create a whitelist that maintains the context of that violation including account name, IP address, resource group information, email address, and other information. Users can select up to three of these attributes to define within the whitelist. By doing so you can reduce the number of alerts created by approved exceptions.