Splunk® Enterprise Security

Use Splunk Enterprise Security Risk-based Alerting

This documentation does not apply to the most recent version of Splunk® Enterprise Security. For documentation on the most recent version, go to the latest release.

Suppressing false positives using alert throttling

Risk incident rules when run frequently can generate an excessive number of risk notables that might be false positives. Alternatively, in some situations risk-based alerting might create too few risk notables. For example, an analyst who has classified a risk object as harmless, might see risk notables created by risk events associated with the same risk object. If the risk incident rules are not adjusted based on the search results or if the analyst ignores the alerts and has not included them in an allow list, an excessive number of risk notables might get created.

In such situations, setting dynamic throttling can help to suppress risk notables that are false positives. Dynamic throttling compares the results from the most recent search with the search results of a previously defined time frame and help to prevent duplicate notables.

You can suppress a new risk notable for any of the following conditions:

  • When a similar old notable was a false positive and occurred within a specific time period
  • An old notable had the same risk object, detection type, or threat object as the new notable

You must use throttling with discretion. Throttling settings can prevent some risk events from surfacing, even though they might be indicative of threat.

Suppress false positives using dynamic throttling

Follow these steps to configure dynamic throttling:

The following procedure is for illustrative purposes only. Fields and values that you use for throttling might vary.

  1. Modify the fields in the risk events into a common format, which helps to correlate and aggregate the search results. Risk events must contain the following fields:
    • Risk object: Refers to a user, system, host
    • Detection Type: Refers to the search name or the detection type.
    • Threat Object: Refers to the offender entity such as a malicious domain, file hash, and so on.
  2. Ensure that you add customized status for events in the Incident Review page as follows:
    • Closed-True Positive (101)
    • Closed -False Positive (102)
  3. In the Correlation Search Editor, set the throttling window to 6 hours and group fields such as:
    • source_count
    • mitre_tactic_id_count
    • mitre_technique_id_count
    • risk_object
    • risk_object_type
  4. Add a risk message to the risk incident rule to differentiate between risk events.

    | rex field="risk_message" "(?<risk_signature>.*) -.*"

    This adds a new field called risk_signature with risk messages as follows:

    • EDR - Found Bad Thing - "bad_process.exe" on system_name1/user_name1
    • DLP - Found Kinda Normal Thing - "file_name.csv" on system_name2/user_name2
    • DLP - Found Kinda Normal Thing - "other_name.csv" on system_name2/user_name2

    In this example, adding a risk message to the throttled fields creates risk notables only when DLP or EDR finds new risk events.

See also

For more information on throttling, see the product documentation:

Throttle alerts in the Splunk Enterprise Alerting Manual.

Define trigger conditions for the alerts in the Splunk Enterprise Security Tutorials.

Last modified on 28 April, 2023
Modifying risk incident rules based on the search results   Removing redundant alerts with the dedup command

This documentation applies to the following versions of Splunk® Enterprise Security: 7.1.0, 7.1.1, 7.1.2, 7.2.0, 7.3.0, 7.3.1, 7.3.2


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters