Hello,

Today I want to discuss some lessons learned from a Windows Defender for Endpoint setup.

Before going into the details, let’s start with the basics. Windows Defender for Endpoint ( we’ll call it DFE from now on ) is a component of the Defender Suite that focuses on discovery and remediation of the possible threats on the endpoints.

The following link provides a high-level overview : Microsoft Defender for Endpoint | Microsoft Learn

Now let’s see what we have discovered :

Start with audit mode

You can onboard the devices and enable most functionalities in audit mode. Get to know the reporting options in the Defender Console so your team can verify where the information can be found about what could be broken when we enable “block” mode.

Setup roles and scopes

The Defender suite has many components and sensitive information or actions can be performed depending on the provided role. Make sure that you create / enable the correct roles and map the correct groups to them.

Also remember : as soon as you have enabled the Defender RBAC model your Azure AD gobal reader role no longer has access. See Microsoft 365 Defender Unified role-based access control (RBAC) | Microsoft Learn

Define your blocking baseline.

The DFE contains a multitude of rules that can be enabled in blocking mode. Each of the rules offer additional protection for a kind of threat. Verify which rules are applicable in your specific environment and don’t go for the “we’ll activate them all approach” : )

We aligned the DFE rules with the latest version of the Microsoft Baseline. These baselines define a starting point for which rules could be set to block.

See : Settings list for the Microsoft Defender for Endpoint security baseline in Microsoft Intune – Microsoft Intune | Microsoft Learn

Define your exceptions

Of course we will need some exceptions. We all have legacy in the environment and these components will more likely be blocked by some of the rules. But we need to think this through.

How many exceptions lists will we define ? If we have a couple developers which require an exception will we apply it to the general population ? Make sure you define something that fits your specific situation.

In our case we defined 2 exception lists. One general and one specific. The specific contains the general exceptions + some specific defined and we handle a case by case approach for defining the exception as general or specific. An arbitrary number like 500 devices could also be used. More than 500 endpoints –> general.

Also besides the technical setup you need to define a process for these exceptions , involve operational security and provide feedback to the application owner about the reason why the app was blocked. Again a case by case approach is required and most of the time there will be no easy solutions for fixing the root cause but creating awareness is always the first step.

Be cautious on the rollout

Despite the preparation you will still need to be cautious with the rollout plan. Chance that you effectively block some users from doing their day to day job is realistic. Involve service-desk and change office in defining the end user change and make sure you have a clearly defined , easy-to use rollback process in case of emergency. In our case the service-desk has the option to revert the device of specific users back in audit mode by modifying the group membership in Active Directory.

Ok , now that you have done all that it’s time to sit back, relax and watch the endpoints step up their protection !