Best practices for using detection filters to stop unwanted findings

Overview

Blumira is focused on creating high-fidelity detections to keep organizations from feeling alert fatigue, but there are legitimate reasons to tune a detection to better fit use cases specific to your organization. Expected administrative activity or approved vulnerability scanning are good use cases for Blumira’s detection filters.

If you decide to filter Blumira's detections, it is important to consider exactly what activity you are attempting to filter and not filter out so much that actual malicious activity is not detected and alerted on. Detection filters should be used when legitimate organizational processes are triggering repetitive alerts, or “noise”, that are not useful for you or your team.

Reference: See Using detection filters for steps to add and manage filters in Findings (Reporting > Findings).

Here are other examples of good opportunities for using detection filters to stop unwanted findings:

• A network vulnerability scanner is set up on a specific server and continuously scans your environment and is mistaken as malicious network scanning.
• An internally developed PowerShell script that is running on a schedule on all your endpoints is mistaken as a malicious script.
• System administrators are running approved remote commands to managed endpoints and are mistaken for malicious activity.
• Users logging in from countries outside of the U.S. during approved and expected international travel are mistaken as threats.

Recommendations

Recommended: Apply the principle of least privilege when creating detection filters for Blumira's findings. This means providing the filter(s) with enough information (conditions) to silence only the specific, allowed behavior and no less. The more specific you are, the less likely it is that you will accidentally filter out actual malicious behavior.

Be as specific as possible with your detection filters so that you stop alerting for expected activity but continue to see and respond to the unexpected.

Example: If a user, ("jake" in the example below) is approved to run a PowerShell script ("New-LocalUser -Name") and you no longer want to see a related finding for "Indicator: T1136.001 - Create a new user in PowerShell", add a filter to the finding and include these conditions: 

• the username of the approved user
• the specific PowerShell command used

With these conditions, the finding will not be triggered for this specific, expected activity, but Blumira will still alert you and your team if a different user performs the same activity and/or they use a different method.
Tip: If other administrators are approved to use this same command, select the IN operator and provide additional usernames.

Recommended: Use generalized detection filters only after investigating and confirming an activity is approved and legitimate across the full range of possibilities at that address, device, etc. Using detection filter values or conditions that are too generic risks significantly reducing detection visibility.

In some cases, it may not be possible to be specific with your detection filter, and you may need to filter a single condition, such as a user or an IP address.

Example: Vulnerability scanning servers set off various alarms because the purpose of that software is to reach out to the network and test systems for vulnerabilities. In these instances, the user is not always the same or even part of the detection and the only constant is the IP address of your vulnerability scanner. In this case, it may be appropriate to create a detection filter that includes only the IP address with no other conditions. First, ensure that you have investigated and confirmed that the activity is approved and legitimate, then create the filter in Blumira.

Tip: Currently, IP ranges are only supported when using the Contains operator. If you need to filter an entire range from triggering a finding from the dst_ip addresses in the 192.168.1.0-192.168.1.255 range (192.168.1.0/24), you can use the Contains operator and type “192.168.1.” in as the value. Ensure the period is added after the 1 in the range, or the filter will exclude the 192.168.100-119, 192.168.120-129, etc. ranges as well.

Additional Tips

Do the following when using detection filters:

• Create your filters to be as specific and unique as possible and match only the behavior that you are trying to filter.
• Use naming conventions. For example, if your team has internal scripts, apply a normal naming convention so that it is easy to identify legitimate scripts and also easy to create a detection filter for them.
• Tune often. If a detection has triggered twice on the same source and you've confirmed it as legitimate activity consider tuning. This will help malicious behavior stand out quickly.
• Recognize when tuning may not be the right option and disabling the detection is the better choice. You would not want to detect on Teamviewer use if that is the tool your help desk uses for all remote support tasks, so disabling the rule may be the best approach for you.
• Investigate before tuning. Tuning a detection without confirming the intent or source of the issue may allow threat actors additional cover to act in your environment.
• Choose the most appropriate operator in each filter. 
  • Use the IN operator to include more than one value.
  • Use the EQUALS operator for exact matches.
  • Use the Contains operator for partial values within a range, such as for multiple IP addresses.
• Reach out to Blumira Support for help if you have any questions on specific detection filter entries.

Do not do the following when using detection filters:

• Filter out entire operating system directories (e.g., folders such as AppData, User, Home, ProgramFiles, Downloads, Desktop, and any other built-in directories).
• Exclude large IP address ranges.
• Exclude Windows Event IDs. Excluding Windows Event IDs will significantly reduce detection visibility.
• Filter out entire Active Directory Domains. If this is the only filter you have on a detection, it will silence it for your entire organization.
• Create filters based on core components of the detection. For example, if you are creating a filter for the detection “Public IP connecting to Internal network via RDP Detected”, do not filter out port 3389 (RDP).