Adjust the risk threshold to avoid high alert volume
Use risk-based alerting to set an accurate risk threshold so that you can avoid missing crucial alerts and not generate a high volume of notables.
You can identify the appropriate risk threshold for your security environment based on the probability or the likelihood that a risk event is malicious. You can also set the risk threshold based on the criticality or importance of an asset or identity and the extent of damage that might result from a risk event.
Risk based alerting generates risk notables only when you reach a risk threshold. Each risk notable has a risk score and a user or host that helps to isolate the threat. The key is adopting a static approach that evolves with changing conditions when setting the risk threshold.
For example, an analyst might receive a high volume of notables that include the following threat object types:
- Suspicious CMD Execution through WMI
- Business Email Compromise (BEC)
- Domain Generation Algorithm (DGA)
- Malware Detected
The analyst might ignore notables related to Suspicious CMD Execution through WMI and Domain Generation Algorithm because they think that they do not represent adequate risk.
Set the appropriate risk threshold using the following methods:
- Tag metadata to rate risk events based on historical alert volume.
Threat hunting and security investigations often rely on analyst experience and metadata tagging is based on the analyst's assessment of the risk event, which is constantly evolving and is context sensitive.
- Adjust risk modifiers to assign a higher or lower risk score to the risk event.
- Adjust risk threshold based on model count, MITRE ATT&CK tactic count, or the confidence level associated with a risk event
Example: Adjust the risk threshold
Example 1
An analyst sets a risk threshold of 100. The risk incident rule generates the following four risk events when the sum of risk scores is over 100 because the aggregate or total risk score of these four risk events is 108.
(risk_score_sum "108" > threshold "100")
- Risk event 1 has a risk_score of 60.
- Risk event 2 has a risk_score of 20.
- Risk event 3 has a risk_score of 8.
- Risk event 4 has a risk_score of 20.
The analyst knows that risk event 1 is a false positive because it refers to a suspicious power shell event, which points to a known administrator script that routinely runs in the environment. The analyst knows that risk events 2 and 4 are similar, although they generate different alert types. Risk event 2 indicates Domain Generation Algorithm (DGA) and risk event 4 indicates potential C2 traffic, both of which pertain to the same domain. The analyst also knows that risk event 3 is informational and can be safely ignored.
The analyst adjusts the inflated risk threshold.
Example 2
An analyst sets a risk threshold of 100. The risk incident rule generates 10 risk events, each with a score of 20. The aggregate risk score of the risk events is 100, which exceeds the risk threshold.
(risk_score_sum "100" > threshold "100"
The analyst knows that these 10 events are a result of outgoing SMP traffic, which is harmless and adjusts the risk threshold.
Example 3
Risk thresholds can constantly evolve based on the model count dc(search_name)
, which is the number of detection types in a notable. The analyst can also change the risk threshold based on the MITRE ATT&CK tactic count dc(tactic)
, which is the number of tactics in a notable. You can increase the risk threshold when a risk notable contains more than one detection type and tactic, which is | where modelCount > 1 AND tacticCount > 1
.
Additionally, the analyst can also adjust risk thresholds based on the changing confidence level associated with risk events. For a high confidence risk notable, the analyst can lower the risk threshold. For a low confidence risk notable, the analyst can increase the risk threshold.
eval threshold = case ( match (confidence, "high"), 80, match (confidence, "medium'), 100 1==1, 200)
See also
For more information on adjusting risk modifiers, see the product documentation:
Removing redundant alerts with the dedup command | Create a risk message to add context for investigations |
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
Feedback submitted, thanks!