No security tooling is perfect, and a security product might even flag certain types of behavior as suspicious when they are benign. Security tooling requires constant tweaking and it’s important to stay on top of things. Exclusions are created regularly and they should be maintained properly. As usual in the Microsoft ecosystem, there are multiple ways to execute these tasks.

Why Exclusions are Important

Two reasons exist why you should invest time to manage exclusions:

• Keep focus
  • By continuously tweaking detection rules and adding/removing exclusions, you can minimize the impact of generated events. With a lower number of incidents, you can better focus on the incidents that might be an actual threat.
• Avoid end-user impact
  • As a security analyst, you must balance security and user productivity. It’s important that users don’t hold any grudges against the security team, because you want to encourage users to escalate suspicious behavior and to follow all required training.
  • By tweaking exclusions, you avoid unwanted annoyances for users by ensuring legitimate programs or files are not quarantined by the antivirus.

Where to Add Exclusions

Within the Microsoft security stack, there are multiple locations to add exclusions. You can add them within a specific product (Defender for Endpoint, Identity, Entra ID Protection) or in a more generic location like Microsoft Sentinel.

Your decision will depend on whether this is a built-in rule (like a Defender detection) or a custom rule generated by Kusto Query Language (KQL).

If it’s a custom rule, I recommend updating the KQL first. The reasoning is that it’s often easier to add a simple exclusion in KQL that accurately identifies malicious behavior. I am a strong believer in avoiding the creation of an incident if it’s possible. This means that I prefer to not generate an incident only to find that it can be immediately closed. This approach allows you to keep focus (because no unnecessary incidents need to be handled) and you have a clearer way to report on open/closed incidents. If many incidents are closed automatically after a short period, metrics can be skewed which makes reporting to senior management more difficult.

Besides that, your preferred method will depend on the maturity of your environment and requirements in terms of an audit trail. You can choose to execute every change using a CI/CD process or manual in the specific tool.

In a mature environment, every exclusion should be discussed and accepted before implementation. This is why I recommend pushing exclusions using a CI/CD tool that integrates a four-eyes principle, like Azure DevOps. By using CI/CD in Azure DevOps, we can configure that approvals are required before the changes are pushed. In practical terms, the exclusions must be accepted by at least one other approver.

Unfortunately, APIs are lacking in the Microsoft Security stack. There aren’t any APIs available to add alert tuning rules in Defender XDR or excluded entities in Defender for Identity (MDI). If you want to use automation to push exclusions, limited options exist. The only product that has broad API support is Microsoft Sentinel. Microsoft Sentinel is built on top of the Azure Management API and has an API for almost every function. There is even a native feature for a CI/CD integration in Microsoft Sentinel.

By integrating every change for Microsoft Sentinel into CI/CD, we can ensure there is an audit trail for every change and (multiple) approval(s) are needed from a different level of authority.

If we go down this route, we cannot use some of the native features like excluded entities in MDI. It is unfortunate because we cannot avoid an incident from being created. These incidents must be closed immediately (which goes against the recommendation I made earlier). Additionally, closing incidents at the source decreases the chances that the product itself takes an automated action (like Defender’s Automatic Attack Disruption). To me, these downsides are outweighed by the benefits of a CI/CD integration. However, the approach adds a lot of overhead and is not feasible for every organization due to the added complexity.

How Specific Should You Be?

Besides the location of an exclusion (whether it’s in Microsoft Sentinel or Defender XDR), you need to think about how specific you want to make the exclusion. Let’s tackle this question by walking through a sample situation.

In this scenario, a customer ServiceNow (an ITSM tool) environment triggered an incident each night during a scheduled backup. While creating the exclusion, we had a discussion about what parameters we wanted to include:

• The command line that executes the backup
• The server name
• The software name (ServiceNow)
• The software version

In an ideal scenario, you should make the exclusion as specific as possible to avoid any false negative incidents. To do this, you would add all of the points mentioned above. But in a real-world scenario, you must ensure you do not need to tweak exclusions continuously (for instance, following this installation of a new software version). In this case, I recommended not to include the software version, as it would break the exclusion in the future. The counterargument is that a version upgrade means the backup process happens in a different way and could mean the false positive doesn’t happen again. This counterargument is something I would cover with periodic reviews.

Periodic Reviews

Independently of where you add exclusions, it is important to document each exclusion properly and to execute regular reviews. During a review, you should verify whether the exclusion is still valid and the risk is still accepted (do the benefits of the exclusion hold up against the risk of not generating that type of incident). During reviews, I often see that the behavior has changed, or a certain object (machine or user) is retired, meaning there is no need for that specific exclusion anymore.

If you remove unnecessary exclusions, you avoid potential overhead and are sure all exclusions are still current.

There should be a regular cadence for reviews. What cadence you use depends on the organization. Once a month means you can follow exclusions closely, but the execution of such a frequent review requires a big effort. I generally recommend a review every 3 months. This still allows for four reviews each year, while not placing too much additional load on the team.

Creating a Process

Managing exclusions is not a task that should be underestimated. It is important that every organization thinks about the process and how they want to organize it. At a minimum, the following decisions should be made:

• Where are we adding exclusions?
• How are exclusions scoped?
• Who will review the exclusions and in what cadence?

Within the Microsoft stack, there are multiple ways to add exclusions and it’s important that everyone chooses their own procedure and sticks with them. Exclusion handling is a really important process in Security Operations and should be treated as such.