Learn how to use Microsoft Defender Device Groups to better manage your security deployment and assign right security controls. Device Groups are must to have and failing to configure them properly puts your deployment at risk.

If you remember back in the old days, IT administrators used Organizational Units (OUs) to group devices and then assign permissions and group policies at the OU level. OUs facilitate a good scope level for devices so that different teams can manage different set of devices.

In Microsoft Defender for Endpoint, we use Device Groups for the same reason. We define a criteria that defines the membership rule and then we apply settings and assign permissions at the device group level.

Read other parts here:

P1: Microsoft Defender for Endpoint – Architecture

P2: MS Defender for Security Strategy & Role of AI

P3: MS Defender for Endpoint – Threat and Vulnerability Management (TVM)

P4: MS Defender for Endpoint – Attack Surface Reduction ASR

P5: Microsoft Defender Antivirus Internal Mechanics

P6: Microsoft Defender Endpoint Detection & Response (EDR)

1. Device groups membership

Let’s start with the membership rules for device groups. You can define a membership rule that uses one or more of the following device attributes:

• Device name.
• Device domain.
• Device operating system.
• Device tag.

For example, we can create a device group called (London Devices) with a membership rule (Device Name contains LON) assuming we are using a naming convention that works for this scenario.

We can go a step further and use the AND operator. For example, we can have a device group called (London Windows 10 Devices) with a membership rule (“Device Name” contains “LON” AND “OS” = “Windows 10”)

There are couple of things to consider here:

• Applying changes to device group configuration may take up to several minutes.
• Devices that are not matched to any groups are added to the Ungrouped devices (default) group.
  •  You cannot change the rank of this group or delete it.
  • You can change the remediation level of this group.
  • You can define the Azure AD user groups that can access this group.

2. Device groups settings

Once a membership is defined, we can apply settings that are enforced to the device group, the same way we used to apply a group policy at the OU level in the old days. The setting that we can define at the device group level is the Remediation Automation Settings.

In the Automated Investigation and Remediation (AIR) section of this chapter, we talked about how Microsoft Defender for Endpoint can initiate automated investigation and remediate threats. However, you can specify the automation level that the AIR engine will use to automate remediations. There are four remediation automation levels:

• Full – remediate threats automatically.
• Semi – require approval for core folders remediation.
• Semi – require approval for non-temp folders remediation.
• Semi – require approval for any remediation.

For example, you might have an active phishing attack where users across your organization are receiving emails with a title of “Covid-19 new corporate policy” that has a malicious link. During your investigation, you started tagging devices with a COVID19 tag to identify compromised devices. You would then create a device group with a membership rule (Tag = COVID19) with a remediation automation setting = “Full – remediate threats automatically” to quickly stop the attack on compromised devices. 

3. Device groups permissions

After defining a membership rule and the remediation automation setting for a device group, the next thing is to define who can manage devices that are member of the device group. You do that by adding groups from Azure AD after they are assigned a role in the Microsoft Defender for Endpoint RBAC section. Later in this chapter, we will be covering the RBAC model where we can assign a permission level to the same Azure AD group. 

Keep in mind that Azure AD groups, Device Groups and RBAC are the three elements that define who (Azure AD group) can do what (permissions in RBAC) and where (device group).

Note: A device group is accessible to all users if you don’t assign any Azure AD groups to it.

4. Ranking a device group

There is a small problem that you might be facing when dealing with device groups. What if a device matches the membership rule for two or more device groups that might have different remediation automation settings?

To solve this small problem, a device can only be member of one device group. To facilitate this, device groups are assigned a rank. When a device is matched to more than one group, it is added only to the highest ranked group.

5. Filtering with device groups

Device groups can also be used to filter views in the Microsoft Defender for Endpoint portal. For example, in an investigation, you can filter the Devices list to just specific device groups by using the Group filter.

6. Manage Access to Microsoft Defender for Endpoint

There are two ways to access and consume the Microsoft Defender for Endpoint service:

•  by logging to the Microsoft Defender for Endpoint Security Centre portal through a browser.
•  to extend the Microsoft Defender for Endpoint service by leveraging the rich set of Microsoft Defender for Endpoint APIs. There are many scenarios for leveraging the APIs such as:

In the following sections, we are going to look at how to manage access to Microsoft Defender for Endpoint using the portal and the Microsoft Defender for Endpoint APIs.

6.1 Manage portal access

For different security teams to get access to the Microsoft Defender for Endpoint portal, they must be assigned the right permissions. There are two permissions models that you can choose from:

• Basic permissions model: which is a good fit for small and medium organizations.
• RBAC or Role Based Access Control: recommended for enterprises to facilitate more granular permissions.

6.1.1 Basic Permissions

If you need only the ability to assign Full Access and Read Only Access to users in your organizations, then this is the right model for you. It is also the default permission model for Microsoft Defender for Endpoint portal access.

• Full Access: You can assign users a full access permission by adding them to one of the following Azure AD built-in roles:
  • Global Administrators
  • Security Administrator

Note: You should limit the number of users who are assigned to the Global Administrators group as a security best practice.

• Read-Only Access: you can assign users a read-only access by adding them to the Security Readers Azure AD built-in role. Users with read only access can log in, view all alerts, and related information.

6.1.2 RBAC Model

A more granular way to assign permissions to the Microsoft Defender for Endpoint portal is using the RBAC model. It is convenient for organizations that have different teams managing different set of devices. Consider an organization that has offices in London and UAE. Each office has an assigned security team that is responsible for devices on that office only, while a global security team manages all devices in the organization. With RBAC, you can assign permissions to the right security team for a defined scope of devices.

To facilitate such permission model, RBAC requires defining three things:

• Who: which is a group defined in Azure AD.
• What: a pre-defined permission level in the Microsoft Defender for Endpoint portal.
• Where: the scope of assigned permissions using Device Groups.

Let’s not forget that as a security recommendation, you should consider the principle of least privilege which means assigning people only the rights they need to do their job. 

Roles or permissions (the What part) are pre-defined in the Microsoft Defender for Endpoint and we can only expect the list of roles to expand in the future. Here are some examples of the built-in roles:

• View data
  • Security operations – View all security operations data in the portal.
  • Threat and vulnerability management – View threat and vulnerability management data in the portal.
• Active remediation actions
  • Security operations – Take response actions, approve, or dismiss pending remediation actions, manage allowed/blocked lists for automation and indicators.
  • Threat and vulnerability management – Exception handling – Create new exceptions and manage active exceptions.
  • Threat and vulnerability management – Remediation handling – Submit new remediation requests, create tickets, and manage existing remediation activities.
• Alerts investigation – Manage alerts, initiate automated investigations, run scans, collect investigation packages, manage device tags, and download only portable executable (PE) files.
• Manage portal system settings – Configure storage settings, SIEM and threat intel API settings (applies globally), advanced settings, automated file uploads, roles, and device groups.
• Manage security settings in Security Center – Configure alert suppression settings, manage folder exclusions for automation, onboard and offboard devices, and manage email notifications, manage evaluation lab.
• Live response capabilities – (basic and advanced).

Example: Enabling RBAC and configuring a role assignment

Both Roles (permission levels) and Device Groups are linked together using an Azure AD group. Let’s look at example on how all this work together. We have an organization with two offices, one in London and one in UAE. Each office is managed by a separate local security team while a global security team is managing all devices. 

Our goal is to assign permissions so that each local security team can manage devices in their corresponding office, and a global security team can manage all devices. First, we will create three Azure AD groups:

• LON Security Team
• UAE Security Team
• Global SOC Team

We then will add users to the right group. Next, let’s go to the Microsoft Defender for Endpoint portal > Settings > Permissions > Roles. 

By default, basic permission model is activated. To enable RBAC, we will click Turn on roles.

Now, let’s add a new role by clicking Add Item. Here we can define a name for the role (for example “LON SecOps”), assign one or more permissions, and clicking Next.

In the Assigned users group page, we will search for our Azure AD group (LON Security Team) and add it. That’s it, we have created our first RBAC role. Next is to scope that assignment to a device group.

Now, lets go to Settings > Permissions > Device Groups. By clicking Add device group, we can give the device group a Name(LONDON Devices), an Automation level to define the behaviour of the AIR engine, and a Membership criteria (Name Starts with LON). 

To verify the correct devices will be added to this device group, you can click Preview members.

Finally, in the User Access page, we will search and add both Azure AD groups (LON Security Teams) and (Global SOC Team). 

To complete our scenario, we will also create a device group called (UAE Devices) with a membership rule (Device Name starts with UAE) and assign both (UAE Security Team) and the (Global SOC Team) Azure AD groups to that device group.

And we will create two RBAC roles:

• UAE SecOps role – with assigned user groups = UAE SecOps group
• Global SecOps role – with assigned user groups = Global SecOps group.

This means:

• (LON Security Team) Has the permissions we’ve defined for them in the RBAC role page.
• (LON Security Team) has their permissions scoped a device group called (LONDON Devices)
• (UAE Security Team) Has the permissions we’ve defined for them in the RBAC role page.
• (UAE Security Team) has their permissions scoped a device group called (UAE Devices)
• (Global SOC Team) has permissions we’ve defined for them in the RBAC role page.
• (Global SOC Team) has their permissions scoped to both device groups.
• The device group (LONDON Devices) has an automation level set to Full – remediate threats automatically.

Note: For more advanced example on how to delegate access to the Microsoft Defender for Endpoint portal, check out Microsoft publication here.

Device Tages

While device groups in Microsoft Defender for Endpoint help you group devices for policy and permission assignments, they don’t help in prioritizing our responses to threats and alerts. If you have device groups configured per office (London office and UAE office), how would you prioritize responding to alerts on high value assets (executive machines for example)?

What if you are hunting for threats and you want to scope your hunting to high value machines such as domain controllers or internet facing machines? Device groups might not be the right answer in many cases.

There is a need to logically group devices for various reasons. Why should security operations center (SOC) analysts treat all devices as equal? How can your SOC teams triage alerts more efficiently? And how can you proactively hunt for threats more effectively by focusing on high value assets?

Device tagging is how you can create a logical group affiliation, and a dynamic list to create more effective filters in the Microsoft Defender for Endpoint portal and to scope your views and hunting to specific group of devices.

There are different ways to assign a tag to a device in Microsoft Defender for Endpoint:

• Using the Microsoft Defender for Endpoint Security Center portal.
• By setting a registry key on the device itself.
• Using the Microsoft Defender for Endpoint API.

To create a device tag from the portal, navigate to the device page, and choose Manage tags from the upper navigation bar.

To create a device tag using a registry key, use the following registry key entry:

• Registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging\
• Registry key value (REG_SZ): Group
• Registry key data: Name of the tag you want to set.

To create a device tag using the Microsoft Defender for Endpoint APIs, you can call the API directly as documented in Microsoft official documentation here, or you can use Microsoft Power Automate or Logic App.

Once devices are tagged, you can then filter devices using different tags that you have defined. This helps you focus your attention to a logical group of devices that might have higher asset value.

High value asset tagging

Another similar feature to tagging is high value asset tagging. Think about this as a special tag that you assign to a machine and has three possible values (Low, Normal, and High). The special thing about this tag is that it affects the weight of the Threat and Vulnerability Management exposure score calculation. Meaning that machines marked as “high value” will receive more weight in the exposure score calculation.

One of the possible scenarios of using this feature is to help you differentiate between asset priorities and how fast you respond to threats on high value assets. You can start by assigning a high value asset tagging to domain controllers, internet facing machines, executive machines, and other devices you consider as a high value assets.

To tag a machine with a high value asset, navigate to the Device Page, and click on Device Value from the upper navigation bar. 

In the Device Value page, pick on of the possible device values:

• Low
• Normal
• High

About this Microsoft Defender for Endpoint Blog Series

During the years, I have worked with many security and Infrastructure services, and I usually don’t find good information in the web on how a product or service works. For me to master a service, I need to learn how it thinks, the internal mechanics, and even how the product group who designed it really thought about different features.

So, I started blogging years back to reflect my understanding and help others find useful information that is not found elsewhere on the internet (at least in one place) and direct from my experience.

This blog series is written after careful consideration and will help you imagine how Defender for Endpoint works from the bottom up. I rarely have time to blog these days, so I might not update the blog on new features. However, the content here will give the information you need to build on top.

CREDITS Big thanks to my friend and fellow Microsoft MVP and RD: Ahmad Nabil who helped me put such content and the Microsoft 365 Security for IT PRO book family who helped in reviewing and editing this chapter. Newer version of the book is available here with updated content and valuable content about other Microsoft 365 security services. Download the new book here.