In one of the biggest changes to Microsoft Defender for Endpoint (MDE) in its product history, you no longer need a separate management engine to configure endpoint settings.

In this blog, we’ll look at what that change is, why it was necessary, initial impressions, and what you might want to do next.

Table of Contents

Historic management architecture needed simplifying

MDE (and it’s Windows client, Microsoft Defender Antivirus (MDAV)) always stood out from the crowd of endpoint protection platforms as being, well, a bit weird in terms of management architecture. With most platforms, you get a central admin console which pushes out endpoint settings. Think scan schedules, quarantine rules, exclusions, CPU throttling, etc. MDE/MDAV, on the other hand, instead relied on an external management tool such as Intune (MDM), Configuration Manager, or Group Policy.

This caused confusion in a few ways:

  • Settings that achieved the same thing had different names in different management engines. For example, Configuration Manager and Intune refer to the exact configurations differently. This made know exactly what to choose difficult.
  • How did you know which management tool to use? Suppose you have all three options. Which is better?
  • Over time, settings were added to one management tool but not others. Intune, as you might expect, was the general direction of travel.
  • The narrative of extended detection and response (XDR) was centralized incident response… but we’re juggling all these different systems!

As a half-way step to centralizing management and not having all these different ways, Microsoft introduced Security Management for MDE. This capability, also known as MDE Attach, allowed you to manage non-Intune devices in the Endpoint Security blade of the Intune admin centre. For example, you could manage server settings. To begin with, there was the requirement for these devices to either by hybrid Azure AD joined or Azure AD joined, which was a requirement to build the trust relationship with the service but not ideal.

But now, we can see the real direction of travel: no need for Intune, no need for GPOs, and no need for Azure AD joins.

Centralized management, all in Microsoft 365 Defender portal

Intuitively, you can now manage antivirus settings in security.microsoft.com. This is the Microsoft 365 Defender portal, also sometimes called the Security Centre.

Heading to Endpoints | Configuration management | Endpoint security policies, you’ll now find your existing Intune policies, and the ability to create news natively in the Microsoft 365 Defender portal.

At time of writing, during preview, you can only create Antivirus policies (no ASR, for example) in the portal, but it’s clear where things are heading. Expect the remaining policy types to become available over time.  You can click Create new policy to start a new policy (which are still applied to AAD groups; not device groups like a lot of Defender portal settings) or you can even edit an Intune-created policy in the portal, as depicted in the next screenshot.

In the first screenshot, you’ll note there are different Policy types and Policy categories. As explained, we can only create Antivirus profiles for now, but you can click into non-Antivirus policies and view their settings and deployment status. So far I’ve found it a bit buggy. For example, I can see all the settings in an ASR policy, but only Controlled Folder Access in the per-settings client status.

BitLocker also doesn’t show all settings and how they’ve applied (successfully or not), but you can see the image below for an example of how useful this will be after preview: a security engineer can very quickly see settings and their status without fumbling through Intune and figuring out which policy to check (and note they can quickly pivot to Intune if needed using View in Intune.

It’s all very exciting for us Defender geeks who’ve been desperate for a long time for a single pane of management.

What’s next, and important considerations

The introduction of this centralized management location in the Microsoft 365 Defender coincides with the announcement of the removal of the prerequisite that Security Management for MDE/MDE Attach (the precursor to this, as explained earlier in the article) no longer requires hybrid Azure AD join or Azure AD join.  All of this is great news: HAADJ and AADJ, if not already in place, introduced yet another thing to consider in MDE deployments – so the simplification is good.

Importantly, if you previously used Security Management for MDE with Intune, you may have targeted policy to dynamic Azure AD groups  – these will need changed if you used the attribute managementType to build groups for either MDEManaged or MDEJoined.

In line with this announcement, these tags are being replaced by just MicrosoftSense. Looking back up at the screenshots, you’ll see mdm and microsoftSense as the values in the Target column: mdm being driven by the MDM service on the device; microsoftSense being driven by the MDE service itself, independently of MDM (though the provisioning of a new microsoftSense policy is also applicable to MDM.

Therefore, update your dynamic Azure AD groups to use the new microsoftSense and the deviceType values that match your requirements (eg WindowsServer).

If you want to dig deeper into Microsoft 365 Defender configuration…

… do I have the book for you! Mastering Microsoft 365 Defender is my new book, written along with Viktor Hedberg. We go wide across all of Microsoft 365 Defender, including MDE, but also Defender for… Office 365, Identity, Cloud Apps, and Microsoft Defender Vulnerability Management. You’ll find a ton of guidance on which settings to use and why, as well as general design choices and using M365D to respond to threats.  You can preorder/buy it here: packt.link/Ru.

Follow the blog, campbell.scot, as well as following me on Twitter (@rucam365) and LinkedIn (linkedin.com/in/rlcam) to keep up to date with more changes to Microsoft 365 Defender.  As the product never stays still, any changes you need to know about from the book, I’ll try to keep you updated!

Tags:
Last updated on October 6, 2023