Creating allow lists to reduce noisy alert volume

Use allow list and deny list rules to determine which alerts generated by Splunk Enterprise Security are worth investigating when you monitor your security environment using risk-based alerting (RBA).

For example, you use the detection Windows MSHTA Child Process to identify commonly exploitable child processes spawning from "mshta.exe" (Microsoft's HTA Script Launcher).

When you run the following search on the past 24 hours, you might get numerous alerts:

| where like(parent_process_name, "%\\\\mshta.exe") AND (process_name="powershell.exe" OR process_name="cmd.exe" OR process_name="scrcons.exe" OR process_name="colorcpl.exe" OR process_name="msbuild.exe" OR process_name="microsoft.workflow.compiler.exe" OR process_name="searchprotocolhost.exe" OR process_name="cscript.exe" OR process_name="wscript.exe")

Instead of rejecting all the alerts, you can identify the alerts that provide the most value by identifying fields that you can group together using a search that uses the BY clause as follows:

index=EDR parent_process_name="mshta.exe" | stats count dc(src) as sources dc(users) as users BY cmdline | sort - cmdline

These searches help you to separate the regular business traffic from the alerts, which you can add to an allow list.

Use allow lists sparingly and only when the alert volume is so high that it obscures the value that might be gained from the security detection. Additionally, be very specific when adding files, users, and so on to an allow list so that you can still observe activity that might deviate from the usual pattern.

From the above search, let's consider the following noisy command line: cmd.exe MaintenanceCheck.bat from a service account that runs regular maintenance activity in the server environment multiple times in a day.

You can ignore the alerts generated from this noisy command line by creating an allow list with a specific combination of command line, user, or source category.

Now, while investigating the list of noisy command lines, you observe that they do not pertain to a single user. Instead, you notice that the activity results from a service desk personnel running a check on user machines, when they report issues within their system.

You have the option to add these activities to an allow list . If the alert volume is not substantial, you can also reduce the risk score to 0 to prevent these events from creating risk notables.

If a risk notable creates alerts due to other suspicious traffic, analysts can view the login attempts by the service desk logging on the user workstations and dismiss the alert due to the additional context provided.

See also

For more information on using allow lists, see the product documentation:

Include or exclude specific incoming data