The must-have service-level configurations for Microsoft Defender for Endpoint

Introducing advanced features
 

Service-level configuration for Microsoft Defender for Endpoint are a set of configurations elements that are applicable tenant-wide (all devices enrolled in the tenant).

In order to find these settings, navigate to https://security.microsoft.com, scroll down on the left-hand side menu and select settings. Next up, choose Endpoints > Advanced features. There is also a direct URL for this page available at: https://security.microsoft.com/preferences2/integration.

Tamper Protection
 

Tamper Protection is the number one setting which should be enabled on every tenant. By default, a local administrator can disable Microsoft Defender Antivirus and thus bypass your security and monitoring. This should be avoided at all costs as this allows an attacker to fly under the radar.

Tamper Protection can be enabled in two different ways:

• Creating a policy in Microsoft Endpoint Manager which can be scoped to a specific group of devices.
• Configuring the advanced feature to enable this tenant wide.

If you are deploying Microsoft Defender for Endpoint for the first time, I recommend starting by enabling tamper protection in a scoped way through MEM. This allows you to validate the impact before it is deployed tenant-wide.

After the initial deployment, look into enabling the advanced feature to ensure all of your devices are protected. While the MEM policy is great, it only works for servers if you are managing them through tenant attach and doesn’t support Operating Systems like Android and iOS.

When trying to enable this policy, I do receive some pushback sometimes as customers like to disable Microsoft Defender during troubleshooting, to pinpoint if issues are related to Defender AV. While this is a valid argument, the risk of an attacker disabling the AV does not outweigh the benefits. To alleviate this issue, I recommend looking into the new troubleshooting mode which allows you to disable MDAV temporarily for three hours to allow for targeted troubleshooting
 

EDR in Block

EDR in block is one of these settings which is disabled by default, but provides a lot of value to an organization. By default, the EDR component of MDE is not able to block suspicious activity. This means malware can potentially remain running if the detection is made by EDR and not the Antivirus. To alleviate this issue, the EDR component can work together with AV to block malicious activity.

This is interesting in two different scenarios:

• If you are running a third-party antivirus, MDAV will run in passive mode by default. When enabling EDR in block, the antivirus will come into active mode to block a thre​​​​​​at and move back to passive mode after the block has been executed. This ensures the EDR system will run as optimally as possible, while keeping the interference with the primary AV as low as possible.
• When your active antivirus is Microsoft Defender, the recommendation is still to enable ‘EDR in block’ as it enables EDR detections to be blocked, if they were able to bypass MDAV.

While EDR in block mode can be configurated by using an Intune policy, setting up this tenant-wide is recommended as it ensures the setting is configured on all supported Operating Systems, independent if they are managed and targeted by the policy.

XDR Connections
 

One of the main strengths of Microsoft Defender for Endpoint is the connection to other products in the Microsoft 365 Defender stack and the ability to work together to protect your environment in multiple areas (Endpoints, Identities, Email and Cloud Applications). While the default configuration will share indicators across the Microsoft Security Graph API, there are a few connections which I recommend enabling. Configuring these connections will ensure the products exchange as much data as possible.

• Microsoft Defender for Identity (MDI) Integration
  • Enabling this connector enables user and devices in MDE to be enriched with data gathered through MDI.
  • One of the main advantages is that MDI events will show up in the timeline of an MDE device, which allows for a much nicer investigation experience for MDI alerts.
• Microsoft Defender for Cloud Apps
  • Configuring this setting enables MDE to send data to Microsoft Defender for Cloud Apps which will be used within the product to identify cloud application usage.
• Office 365 Threat Intelligence connection
  • The ‘Office 365 Threat Intelligence connection’ ensures data is shared between Office 365 mailbox data and Defender for Endpoint. The main advantage is that you will be able to track on which devices a malicious URL/attachment was opened. Having such an integration will speed up your investigation procedure enormously as it allows you to narrow down your scope and focus on what is important.

Automatically Resolving Alerts
 

This is the one configuration that might be debatable and will be up to personal preference. I like to keep the setting ‘automatically resolve alerts’ disabled. Why is that? Microsoft Defender for Endpoint has Automated Investigations, which will run after an alert is created. If the automated investigation is able to clean up the threat, it will automatically close the incident as the threat is remediated.

There are two main reasons why I don’t like to have this behavior active while running our SOC services:

• The first reason is simple, as a SOC provider, we do not put blind trust in Microsoft. We will always investigate the alert ourselves, independent of the result of the automated investigation. This allows us to ensure the entire malware is cleaned up and the device is safe.
• Even though the malware was fully cleaned, this does not mean that we want to dismiss the alert. Malware was able to end up on the endpoint one way or another and I want to validate that entry point and see if any additional actions need to be taken. Should we configure the spam filter more strictly? Should we have more user education on how to identify malicious file downloads?

Having this setting can be useful when the organization doesn’t have enough resources to monitor the incidents adequately. For these kinds of organizations, automatically closing alerts where the threat has been remediated can be useful

Limitations Of The Configuration

The main disadvantage of advanced features is the lack of an API to do the configuration. Historically, Microsoft 365 Defender has had a small number of API’s, which makes management at scale difficult. Unfortunately, this is no different for the advanced features. At the moment of writing, no API exists to retrieve the current values and update them.

This brings out two key issues:

• There is no way to change a setting at once across multiple environments, these configurations need to be done by logging into the portal manually.
• For other products, we have scripts running which will monitor the configuration and alert us when a misconfiguration has been identified. This kind of monitoring is not possible for advanced features.

The lack of API management opens the door for an attacker to update the configuration of your EDR tool and potentially blind you for certain targeted attacks.

This is feedback I have reported to the Microsoft product teams and I hope this limitation will be removed in the future, by allowing this configuration through the Microsoft 365 Defender API.

Keep An Eye Out

While there are a lot more configurations available, this blog focused on some of the misconfigurations I have observed and should be handled with priority. It is important to monitor these settings continuously and ensure you have them all in the state you desire.

When Defender adds new capabilities, new advanced features will show up. So, it is recommended to log onto the portal periodically to ensure your configurations are up to date.

Managed Detection & Response