Writing exclusions can reduce the noise from False Positive alerts, but it can also come at the trade-off of ignoring True Positives, opening your organization up to risks that prevent Wirespeed from protecting you. Here are some examples of Exclusions and their risk trade-offs:

​
Dealing with Safe Executables

It’s possible to use Exclusions to prevent escalations or containment for known good applications. However, this requires a critical eye to be done effectively with a good risk trade-off.

​
A Simple Example

The following is an example to allow a specific version of a known good executable to run. In this case, the executable was a helper application for banking software. It has only one purpose and is published directly by the business bank, with no history of being abused by attackers. Ideally, files like this would be enriched by their hashes, such as the SHA256 hash in this case, but it wasn’t found in Reversing Labs’ library of over 40 billion files. The best solution would be to submit that file for analysis and inclusion in their repository of files, but that’s not often feasible, so a simple exclusion like this can be safe enough to avoid future false positive alerts: 
files.sha256@~=e7fc1d55726578f20d3336ed4391e4f7ee362ef77da3ccd4b5a38d18e31ccab5

​
Excluding Remote Management Tools

The following can deceptively appear to be similar to the example above, but it comes with opening your organization to risks that Wirespeed does NOT recommend: 
files.sha256@~=9cfd2c521d6d41c3a86b6b2c3d9b6a042b84f2f192f988f65062f0e1bfd99cab
The difference in this case is that hash is for ScreenConnect.WindowsClient.exe, which is the primary executable for the ScreenConnect product, a remote management and IT help tool, that also happens to be commonly abused by attackers who leverage social engineering to masquerade as your IT support to your users, tricking them into running this legitimate application, but pointed at their remote management instance so that they can conduct nefarious steps, which can often lead to ransomware. It is critical that you understand if an executable has a dual-use capability before you add it as an exclusion.

​
Excluding Live off the Land Tools

This is another deceptively simple exclusion that introduces significant risk: 
files.sha256@~=1f9ffc2227f8dea8b771d543c464cf8166c22a39420a5322b5892a640c4b34b6
This exclusion will ignore alerts from the Microsoft powershell.exe binary. This is of course an official binary, but adding exclusions for it allows attackers to execute all kinds of badness, from first stage malware to privilege escalation, even in some cases locking you out of your files in ransomware. Wirespeed highly recommends never adding exclusions for known Live of the Land Tools.

​
Using Processes Instead

Another approach to dealing with powershell might be to exclude a specific process that is acceptable, like this example, which is powershell retrieving the name of the DNS domain the computer is joined to, which is common for legitimate software to do (and also common for attackers orienting themselves within your environment, but probably OK to ignore since there would likely be other detections beyond this that are higher fidelity signal to indicate their presence): 
processes.command@="powershell $env:USERDNSDOMAIN"
Observe that the operator is @= and not @~=. Processes is an array (collection of many processes), so we need to use an array operator. The operator we chose requires every process to match “powershell $env:USERDNSDOMAIN”, unlike the following exclusion, which only needs a single process in the detection to match: 
processes.command@~="powershell $env:USERDNSDOMAIN"
In that example, the detection could contain other processes which are a much higher signal of attacker behavior, resulting in a false positive dismissal of an important alert. Exclusion logic is powerful, but must be precise. When in doubt, let Wirespeed handle these cases for you or reach out and ask for help via support chat.

​
Privacy VPNs

Allowing your organization to use Privacy VPNs when logging in can pose a significant challenge to detecting malicious logins. A better approach would be to prevent their use in your SSO and Authentication systems, such as Conditional Access Policies in Microsoft. However, if that’s not possible, here are some examples. Also, without creating Exclusions at all, Wirespeed will learn to trust specific attributes of cases as you mark them as malicious or benign. For example, a suspicious login case that is closed as benign causes Wirespeed to remember that IP address for 30 days. When a user gets a detection at that IP in the 30 days following, it becomes automatically closed as benign, and the clock is reset for another 30 days from that point for more logins. Further, to reduce impact on the security team from working escalations from Wirespeed, we highly recommend enabling Chat Ops to do this work for you. We will reach out to end users, ask them if they just logged in from an unusual location, authenticate them out of band (if enabled), and learn the safe locations … all without putting any burden on you.

​
How NOT to create an Exclusion for Privacy VPNs

The following exclusion is very loose and opens your organization up to significant risk, by simply ignoring (excluding) any detection or alert associated with NordVPN. This logic goes beyond just Login detections and could potentially exclude malware cases involving an IP address from NordVPN, as well as any user in your entire organization. Attackers use NordVPN, too, so this exclusion is NOT recommended. 
ips.metadata.privacy.service="NordVPN"

​
Slightly Better

By adding the Login category, this exclusion will now no longer apply to other types, such as Execution (malware) or Invocation (cloud control plane). It is still quite loose and not recommended, because it allows any user, and it’s probable an attacker using NordVPN at some point could steal credentials or sessions and login with them from that provider, hit this exclusion rule, and there would be no alert: 
category="IDENTITY__LOGIN" AND ips.metadata.privacy.service="NordVPN"

​
Specific Users

Building on the above, if we add another AND clause, wrap it in parentheses, and specify the email addresses of the specific users we expect to be using NordVPN, then we get an even tighter rule. It still comes with the risk that an attacker could steal the credentials for these particular users and attempt to login with them, though: 
category="IDENTITY__LOGIN" AND ips.metadata.privacy.service="NordVPN" AND (directory.email="tim@taco.company" OR directory.email="jake@taco.company")

​
A Very Tight Example

This example builds on the one before, but further restricts it to Austin, Texas. As a result, the likelihood of an attacker being able to steal credentials for the named users, use this specific privacy VPN, from this specific city and region, really reduces the odds of missing a true positive. It’s still preferable to block privacy VPNs in authentication settings or let ChatOps handle this for you, but if those aren’t good options for some reason, this is available: 
category="LOGIN" AND ips.metadata.privacy.service="NordVPN" AND (directory.email="tim@taco.company" OR directory.email="jake@taco.company") AND ips.metadata.city="Austin" AND ips.metadata.region="Texas"

​
Dealing with Shared Accounts

This is an example for how to craft an exclusion for a specific user account that is shared and logged in at various locations. It comes with serious risk trade-offs, though. It is ALWAYS best to follow security best practices, have good hygiene, use strong authentication (MFA), and NOT SHARE ACCOUNTS. But sometimes the security team gets overruled by the business, so this is an example for how to deal with that scenario. First, this Exclusion is restricted to the Login category, so it’s not wide open for things like malware reaching out to a location that we observe, or a user making suspicious changes in your AWS or Azure cloud control plane (Invocation). Second, this Exclusion is restricted to several U.S. states: California, Arizona, Washington, Oregon, and Nevada. Not the best, but in this particular case, there is a business reason for it. Third, to compensate for the wide logic of the several U.S. states, any matching IP addresses must not have any of the privacy flags set on them: VPN, Proxy, TOR, Relay, or Hosting Provider. While no dataset is perfect, we have an excellent geographic enrichment that we apply to every single IP address we touch. The result of this logic will restrict to only IPs that physically reside at businesses and homes in those U.S. states. Data Center IP addresses (except for small private data centers that belong to specific businesses, not co-locations or cloud providers) will not match the logic. The result is an attacker must physically be located in those states. Most (not all) financially motivated criminal actors will likely use hosted infrastructure to put a layer between you and their identification and attribution. So while this is not preferred (it’s always better to avoid this situation), this is a way to handle this scenario more safely than others. 
category="LOGIN" AND directory.email="shared-user@taco.company" AND (locations.state="California" OR locations.state="Arizona" OR locations.state="Washington" OR locations.state="Oregon" OR locations.state="Nevada") AND ips.metadata.privacy=false)