Tuning anomaly rules

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

This activity involves assessing the output of the Splunk User Behavior Analytics (UBA) Anomaly models and identifying anomalies that are either inaccurate or irrelevant to the customer organization. This is an iterative task, with each successive tuning activity further refining the output of the UBA platform. It is expected that over time the number of anomalies requiring tuning will reduce as the anomaly rules are further adjusted to meet organizational needs. This procedure is valid as of UBA version 5.3.0.

This article is part of the Splunk User Behavior Analytics Owner's Manual, which describes the recommended ongoing maintenance tasks that the owner of a UBA implementation should ensure are performed to keep their implementation functional. To see more maintenance tasks, click here to see the complete manual.

Why is this important?

Anomaly rules are used to adjust the results of the anomaly models and alter the subsequent anomalies that are generated by UBA. Two types of anomaly rules can be configured by a user: Anomaly Action Rules and Anomaly Scoring Rules.

Anomaly Action Rules can be used to add anomalies to a watchlist, change the score of an anomaly, or delete an anomaly. A set of filter conditions determines which anomalies an anomaly action rule will operate on.
Anomaly Scoring Rules can be used to adjust the scoring for all anomalies generated from a specific anomaly model. You can adjust the specific scoring rules for each anomaly model or you can adjust the overall base score range for an anomaly model. These adjustments apply to all anomalies that are generated from that model.

Customizing the output of the UBA anomaly models is an important ongoing activity that is required to ensure that the anomalies and threats discovered by UBA are accurate and relevant to the customer environment that it protects. UBA also has upper limits on the number of anomalies and threats that can be present at any one time, and proper tuning assists in meeting these limitations.

Schedule

Every two weeks

Prerequisites

An admin account is required to access the anomaly rule interface and configure anomaly rules.

Notes and warnings

Anomalies do not have to be true-positive detections to be accurate. UBA identifies anomalies relating to benign behavior by design and these types of anomalies should not be tuned out ot the system. Only tune-out anomalies for inaccuracy if the detection appears to have not run correctly. If the anomaly model appears to have run correctly but the anomaly just isn't related to a malicious action, that anomaly should not be tuned out and should remain in the system.
It is possible to over-tune a UBA environment to a point where functional anomalies are no longer raised properly. To this end, it is recommended that a conservative approach to tuning is taken, with minor adjustments made at each task iteration until the desired anomaly state is reached.
This activity requires consultation with different members of the security operations team to reach consensus on which anomalies need tuning. It is recommended that this is conducted as a group or collaborative activity.
This activity describes a basic ‘Anomaly Type’ tuning process, with rule score suppressions. Over time, as maturity with the UBA product increases, more advanced tuning techniques can be used in each tuning activity iteration. For information on all tuning options, refer to Customize anomaly scoring rules.
For a UBA deployment less than 10 nodes, it is not recommended to exceed more than 1 million anomalies. If your deployment is reaching this threshold, consider conducting more aggressive tuning.
For a UBA deployment of 10 nodes or more, it is not recommended to exceed more than 1 million anomalies. If your deployment is reaching this threshold, consider conducting more aggressive tuning.
It is expected that after the anomaly action rules are defined the threats listed in UBA will change during the next overnight threat calculation period.

Procedure

If you prefer to follow along with this procedure in video format, click here to jump to the bottom of this page.

Step 1: Identify anomalies to be tuned

On the main page of your UBA environment, in the menu bar at the top right of the page, click Explore, then select Anomalies from the drop-down menu.
On the Anomalies Table page, review the list of anomalies with the operational security team that triages events from UBA. In this review, the goal is to identify 2-3 anomaly types that should be tuned. This is an individual assessment process for each customer, but consider the following categories when identifying anomalies to tune:
- Anomalies that are over-represented in number compared to other anomalies. This can be assessed by looking at the number listed next to each anomaly type in the left hand panel of the page. If there is a category that has significantly more anomalies than the other types, this might be a candidate for tuning.
- Anomalies that are not desirable or concerning to the business. Each organization has different goals for security detection, and not all organizations will care about every type of anomaly. If an anomaly type is present that is not a point of concern for the business, either due to the individual behavior being accepted or the behavior not presenting a risk to the business, this anomaly type might present a good candidate for tuning.
- Anomalies that frequently appear in false positive threats. If there is a type of anomaly that frequently appears in UBA threats that are categorized as ‘False Positives’ by the security operations team, that anomaly type might present a good candidate for tuning.
With a list of Anomaly types to be tuned identified, proceed to the next step of the activity.

Step 2: Identify tuning methods

On the Anomalies Table screen, in the menu bar on the left hand side of the screen, select the third icon down to go to the Anomaly Rules page.
On the Anomaly Rules page, first review the existing rules to see if any of them apply to anomaly types that have been selected for tuning in this activity. If an existing rule is already configured relating to an Anomaly Type that has been identified in this tuning activity, edit that existing rule and further increase the scoring suppression within the rule, rather than creating a new rule.

Information on configuring anomaly action rules can be found in Take action on anomalies with anomaly action rules.
For each Anomaly Type that is not represented by an existing rule, perform the following steps:
1. In the top right corner of the page, click New Anomaly Action Rule.
2. On Step 1 of the New Anomaly Action Rule panel, select the rule action.
  1. For Anomaly Types that are over-represented compared to other anomalies, or where the Anomaly Type was frequently included in False Positive threats, it is recommended to use a Change Anomalies Score action. It is best to begin with a relative score adjustment subtracting 1 from the overall anomaly score. This can be further tuned in subsequent activities if required.
  2. For Anomaly Types that are not of interest to the business, use a Delete Anomalies action. Note that this will prevent this type of Anomaly from being raised, so use it sparingly. It is recommended to select Move to Trash as the deletion method so that anomalies can be recovered later if required.
3. On the same panel, select a Rule Scope:
  1. Apply to Future Anomalies applies the rule to any future anomalies that are generated.
  2. Apply to Future and Existing Anomalies applies the rule to future anomalies, and re-computes existing anomalies with the rule applied.
4. On the bottom right of the New Anomaly Action Rule panel, click Next.
5. On Step 2 of the New Anomaly Action Rule panel, click Anomaly Type on the gray section to the left, and select the desired anomaly type from the list on the right of the panel.
6. On the bottom right of the New Anomaly Action Rule panel, click Next.
7. On Step 3 of the New Anomaly Action Rule panel, enter a meaningful Rule Name and Rule Description into the respective panels. It is best practice to include the creation date in the rule description to assist the review process in further tuning iterations.
With all Anomaly Types for this round of tuning addressed, this activity iteration is now complete.