Troubleshooting Defender for Business

I wanted to create a single point, that I will aim to maintain over time, that provides a repository of troubleshooting tips, links and information on Microsoft Defender for Business.

[Updated 1 February 2022]

Information

– Microsoft Defender for Business documentation

Microsoft Defender is subset of the capabilities of Microsoft Defender for Endpoint.

– Microsoft Defender for Endpoint

– Microsoft Defender for Endpoint documentation

– What’s new in Microsoft Defender for Endpoint

– Minimum requirements for Microsoft Defender for Endpoint

Onboarding

Onboarding to the Microsoft Defender for Endpoint service

Onboarding using a local script

Onboarding using Intune device configuration policy

Onboarding using an Endpoint Security policy

– Most of the required files are in a directory:

C:\Program Files\Windows Defender Advanced Threat Protection

which is already present on Windows Pro and Enterprise devices.

– Look for events from WDATPonboarding in the Application logs in the Event viewer.

These event IDs are specific to the onboarding script only.

– Troubleshooting onboarding issues using Microsoft Intune

View the MDM event logs to troubleshoot issues that might arise during onboarding:

Log name: Microsoft\Windows\DeviceManagement-EnterpriseDiagnostics-Provider

– View agent onboarding errors in the device event log

Applications and Services Logs > Microsoft > Windows > SENSE

– Make sure that the diagnostic data service is enabled on all devices in your organization

– The Microsoft Defender for Endpoint sensor requires Microsoft Windows HTTP (WinHTTP) to report sensor data and communicate with the Microsoft Defender for Endpoint service.

– Services that should be running for Windows 10/11 device:

C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2111.5-0\MsMpEng.exe”

Service name = Microsoft Defender Antivirus Service

Service = WinDefend

C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2111.5-0\NisSrv.exe

Service name = Microsoft Defender Antivirus Network Inspection Service

Service = WdNisSvc

C:\Program Files\Windows Defender Advanced Threat Protection\MsSense.exe”

Service name = Windows Defender Advanced Threat Protection Service

Service = Sense

Note – SENSE is the internal name used to refer to the behavioral sensor that powers Microsoft Defender for Endpoint.

When the SENSE service starts for the first time, it writes onboarding status to the registry location HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status

C:\WINDOWS\system32\svchost.exe -k LocalServiceNoNetworkFirewall –p

Service name = Windows Defender Firewall

Service = mpssvc

– It may take up to one (1) hour for the onboarded device to appear in Device Inventory

– The status of the device will be switched to inactive after 7 days of failed contact

– Troubleshoot Microsoft Defender for Endpoint onboarding issues

Offboarding

Offboarding from the Defender for Endpoint service

Offboarding using a local script

Offboarding using Intune device configuration profile

Offboarding using an API and PowerShell

Offboarding using Power Automate

– If the device was offboarded, it will still appear in devices list. After seven (7) days, the device health state should change to inactive.

– Offboarded devices’ data (such as Timeline, Alerts, Vulnerabilities, etc.) will remain in the portal until the configured retention period expires.

– The device’s profile (without data) will remain in the Devices List for no longer than 180 days.

– Any device that is not in use for more than seven (7) days will retain ‘Inactive’ status in the portal.

– A new device entity is generated in Microsoft 365 Defender for reinstalled or renamed devices. The previous device entity remains, with an ‘Inactive’ status in the portal. If you reinstalled a device and deployed the Defender for Endpoint package, search for the new device name to verify that the device is reporting normally.

– Offboarding a device causes the devices to stop sending data to Defender for Business (preview). However, data received prior to offboarding is retained for up to six (6) months.

– Threat Vulnerability Management (TVM) will only collect and process information from active devices.

Connectivity

– Verify client connectivity to Microsoft Defender for Endpoint service URLs

– Defender for Endpoint Connectivity analyzer – https://aka.ms/mdeanalyzer

– The Connectivity Analyzer tool cloud connectivity checks are not compatible with Attack Surface Reduction rule Block process creations originating from PSExec and WMI commands. You will need to temporarily disable this rule to run the connectivity tool. Alternatively, you can temporarily add ASR exclusions when running the analyzer.

– When the TelemetryProxyServer is set, in Registry or via Group Policy, Defender for Endpoint will fall back to direct if it can’t access the defined proxy.

Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus – Microsoft Defender Antivirus event IDs and error codes | Microsoft Docs

To generate the support information, type

MpCmdRun.exe -getfiles

After a while, several logs will be packaged into an archive (MpSupportFiles.cab) and made available in

C:\ProgramData\Microsoft\Windows Defender\Support

Extract that archive and you will have many files available for troubleshooting purposes.

The most relevant files are:

MPOperationalEvents.txt – This file contains same level of information found in Event Viewer for Windows Defender’s Operational log.

MPRegistry.txt – In this file you will be able to analyze all the current Windows Defender configurations, from the moment the support logs were captured.

MPLog-***.txt – This log contains more verbose information about all the actions/operations of the Windows Defender.

Onboarding Windows 10 devices to Microsoft Defender for Business using Endpoint Security

You can onboard Windows 10 devices to Microsoft Defender for Endpoint in a few ways:

1. Local script

2. Using Intune device configuration profiles

and what will be covered here:

3. Using Endpoint Manager Endpoint security policies

Navigate to:

https://endpoint.microsoft.com

and select Endpoint security from the menu on the left. Then select Endpoint detection and response. Finally, select the option + Create policy as shown above on the right.

Select the Platform as Windows 10 and later and for Profile, Endpoint detection and response as shown above.

In the next dialog, give the policy a suitable Name and Description.

As with the article on the onboarding process using Intune, I’d recommend setting the Expedite telemetry reporting frequency to Yes as shown above before proceeding.

As with any Endpoint policy, select the devices and/or users this policy will apply to. Generally, it is recommended that you apply these types of policies to device groups.

Proceed through the remaining screens until you end up on the Review + create as shown above. As with the Intune device configuration profile policy, if you look closely you will an option displayed which wasn’t shown during the policy creation process, Auto populate Microsoft Defender for Endpoint onboarding blob set to Yes. This is what will actually configure the targeted devices to connect to the Defender for Endpoint cloud service.

Press the Create button to complete the policy creation process.

If you now view the newly created policy, and unlike the Intune device configuration profile policy, you don’t see any mention of the Auto populate setting mentioned above. Makes it somewhat hard to troubleshoot for the uninitiated.

We can now monitor the deployment of the policy to devices via the Device status option in the policy options, as shown above. After a short wait, we see the policy has successfully been deployed to the machine in question.

Looking the Device inventory in the Microsoft 365 security center we now see the devices in question has been onboarded to Defender for Endpoint.

Both the Intune and Endpoint security approach are easy to implement with an almost identical policy, so which is better? There doesn’t appear to be any guidance from Microsoft on which policy to use, however Microsoft’s own wizards for Defender for Business implement onboarding via the Endpoint security approach shown here. In my brief experience, the Endpoint security approach also seems to be deployed faster to devices. I would also point out that Endpoint security is the more modern approach to device management and what Microsoft seems to be investing in currently. The only major draw back I can see is that Endpoint security policies currently only apply to the Windows platform.

Intune and Endpoint security approach are an indication of one of things Microsoft needs to fix I believe, because having two ways of doing the same thing in the same portal, without any warning of a potential clash makes things hard for those who have to maintain these environments. Given that the Endpoint security approach is the more modern, I expect it to be the winner in the long and suggest you only implement that policy for onboarding your Windows 10 devices for Microsoft Defender for Endpoint.

Offboarding devices from Microsoft Defender for Business using Power Automate

Recently, I wrote an article to make offboard from Microsoft Defender for Business easier:

Offboarding devices from Microsoft Defender for Business using an API with PowerShell

Because this offboarding process utilises an API we can use that with other services such as Power Automate.

Before devices can be offboarded, a list needs to be created that can be accessed by Power Automate. Refer to this article:

Get a list of devices from Defender for Business into a SharePoint list

for details about creating an inventory of devices saved to a SharePoint Online list.

The summary of the Flow to do this device offboarding process is shown above.

Once the Flow has been triggered I grab the Azure AD application credentials from the Azure Key Vault. I’ve covered off how to create an Azure AD application here:

https://blog.ciaops.com/2019/04/17/using-interactive-powershell-to-access-the-microsoft-graph/

and using a PowerShell script I wrote here:

https://blog.ciaops.com/2020/04/18/using-the-microsoft-graph-with-multiple-tenants/

Getting the Azure AD application credentials into an Azure Key Vault can be done manually or by using this scripted process I’ve covered previously:

Uploading Graph credentials to Azure Key Vault

Once they are in the Azure Key Vault they are easy to access securely using the Flow action Get secret as shown above.

Next comes the Get items action as shown above. This filters the list of devices using a column called Offboard and returns items that have this as Yes (or = 1 for Power Automate).

A new variable is then created and the initial API offboarding URL is saved into it. This will later be appended with the actual device number that is being offboarded which is required by the API.

For each item that was returned from the filtered list of devices (i.e. those that been selected to offboard),

the offboarding API URL needed to be extended to include the unique Device ID from the returned results and the string /offboard.

Thus URL now needs to be ingested by the HTTP action as shown above. It is important that the body contain the following JSON:

{
“Comment”: “Offboard machine by automation”
}

This was taken from the documentation:

Offboard machine API

The other access parameters come from Azure AD application that were extracted from Azure Key Vault earlier on in the Flow.

Because the return from the HTTP action can vary, we now need to have a Switch action as shown above.

In the top right hand corner of the Switch action, select the ellipse (three dots) and then Configure run after from the menu that appears.

Because the result from the HTTP action could be 400 (i.e. failure or BadRequest) we still want the Flow to proceed. If the Switch action is not used the Flow will fail like so:

Using the Switch action and selecting both the is successful and has failed options shown above, will allow the Flow to continue on.

If the HTTP action does return a BadRequest, the left hand side Case condition is met. For any other return, the right hand side Case condition will be executed.

In the case of a return status code = 400, the body of the returned JSON will be parsed and the field Result will updated in the device list for that item with the Message information taken from the JSON results.

In the case of any other return code the following will be executed:

Once again, there could a variety of different returned status codes from the HTTP action, however here I’ll just have a single condition to see if it is successful (status code = 201) and for anything else the results will be updated to the Result field for the device in question.

The last action required, after the Switch, is to reset the URL variable back to the original string in case there are other devices that have been selected to offboard. Failing to do this will result in an incorrect API URL for every device after the first match.

What this offboarding process looks like in practice would therefore be to select which devices to offboard from the SharePoint list, by setting the Offboard column to be Yes, as shown above.

Once the offboard Flow has been run, the results for those selected devices are found in the Result column and Offboard column has been reset to be No for each of these, as shown above.

If you set the Offboard column to Yes again for this device and re-rerun the offboarding Flow,

the Flow runs successfully, even though a base request resulted during the HTTP action and the information from that is captured and stored in the Result field as shown above.

There are edge case conditions this Flows doesn’t accommodate. This is normally due to the correct information not being fully populated in the portal. This typically happens in the short period you create or add add a device to Defender for Endpoint. It is simple enough to add these checks in the Flow, but for the sake of simplicity that are not included here.

This whole process again demonstrates the flexibility and capability combining APIs with Power Automate can provide. Remember, you can set this whole process up to work across multiple tenants, it doesn’t have to be restricted to just the tenant you are on. Using Power Automate allows you to easily extend a solution to maybe include email notifications, updates into a Microsoft Team and more.

So these are some ways you can offboard devices from Microsoft Defender for Business:

Via a local script

Using Endpoint Manager and Intune

Using PowerShell

and using Power Automate as detailed here.

Get a list of devices from Defender for Business into a SharePoint list

One of great things about an API is that it can be used in many places. I showed how to:

Offboard devices from Microsoft Defender for Business using an API with PowerShell

and I can do something similar with the Power Platform.

First step in that process is to get a list of Microsoft Defender for Endpoint devices and put them into a pre-existing list in SharePoint. For that I use the above Flow.

Once the Flow has been triggered I grab the Azure AD application credentials from the Azure Key Vault. I’ve covered off how to create an Azure AD application here:

https://blog.ciaops.com/2019/04/17/using-interactive-powershell-to-access-the-microsoft-graph/

and using a PowerShell script I wrote here:

https://blog.ciaops.com/2020/04/18/using-the-microsoft-graph-with-multiple-tenants/

Getting the Azure AD application credentials into an Azure Key Vault can be done manually or by using this scripted process I’ve covered previously:

Uploading Graph credentials to Azure Key Vault

Once they are in the Azure Key Vault they are easy to access securely using the Flow action Get secret as shown above.

The next step is to delete devices I already have in the list in SharePoint because I want only current devices to be brought in. To achieve this, I get all the items from my destination SharePoint list using the Get items action. Then, using the Apply to each action and the Delete item action inside that loop, existing entries will be removed so I have a clean list.

I’ll now use the HTTP action to execute an API call to the Defender environment as shown above. The API endpoint URI to get a list of devices in Defender for Endpoint is:

https://api.securitycenter.microsoft.com/api/machines

Access is granted via Active Directory Auth and the Authority is https://login.microsoftonline.com. You also need to use the credentials of the Azure AD application obtained previously from the Azure Key Vault, as shown above. Ensure that the Audience is https://api.securitycenter.microsoft.com/.

The output of this API request will be a JSON file so we now use the Parse JSON action to obtain the fields needed. To understand what the JSON looks like and insert a copy into this action look at the Microsoft documentation here:

List machines API

which provides a response sample that you can use.

The last action in the Flow is to take the parsed JSON output and enter those details into the pre-existing SharePoint list that you need to create to house this information.

I’ve kept the destination list simple, as you can see above. Basically, the final Apply to each action places each device and its information as a row into the destination SharePoint list.

If I now run this Flow, I see it runs successfully.

Looking at my SharePoint list I see I have a new list of items as expected.

If you weren’t aware, the ‘eyelashes’ on an entry in SharePoint indicate it is new.

Now I have copy of all the machines in my Defender for Endpoint in a SharePoint list. You will also see that my SharePoint device list contains an additional ‘Offboard” column that I am going to use when I implement another Flow to offboard devices from Defender for Endpoint, much like I did with PowerShell previously.

You can also easily extend the operation across multiple tenants if I want using Azure AD applications in each.

The great thing about using the Power Platform and APIs is that for many, it is much easier to get the result they want rather than having to write code like PowerShell. Also, the Power Platform environment has many capabilities, such as sending emails, adding extra metadata, etc. that are much easier to do than using PowerShell. Once the Defender for Endpoint device list is in SharePoint there is really no end to what could be done.

With that in mind, stay tuned for an upcoming post on how to use what’s been done here and another Flow to actually offboard devices from Defender for Endpoint.

Offboarding Windows 10 devices from Microsoft Defender for Business

In a recent article I covered off how to:

Onboard Windows 10 devices to Microsoft Defender for Business

Two easy methods of onboarding Windows 10 devices to Defender for Business

Now we need to know how to offboard Windows 10 devices from Microsoft Defender for Business.

The first place to start is to review this article from Microsoft:

Offboard devices from the Microsoft Defender for Endpoint service

It details the following points:

– The status of a device will be switched to Inactive 7 days after offboarding.

– Offboarded devices’ data (such as Timeline, Alerts, Vulnerabilities, etc.) will remain in the portal until the configured retention period expires.

– The device’s profile (without data) will remain in the Devices List for no longer than 180 days.

– In addition, devices that are not active in the last 30 days are not factored in on the data that reflects your organization’s threat and vulnerability management exposure score and Microsoft Secure Score for Devices.

– To view only active devices, you can filter by health state, device tags or machine groups.

In essence what this means is that although you offboard a device a lot of information about that device will remain in the portal. Also, even after offboarding a device, if you look in the Endpoint portal, at first glance the device still appears to be there. The reality is that offboarding a device doesn’t make it ‘disappear’ from the portal immediately. This means we’ll need to use another method to verify that the device has actually been offboarded.

The easiest way is to look in the following registry key on the machine:

HKLM:\Software\Microsoft\Windows Advanced Threat Protection\Status

and examine the value of the key:

OnboardingState

If that is set to 1, as shown above, then the device is still considered connected to Microsoft Defender fo Endpoint. Thus, to confirm the device has been offboarded, we need to check that this value is 0.

You’ll also need to have a license for Intune/Endpoint Manager to enable this process from a centralised location.

Although not completely necessary it is best practice to have the integration between Microsoft Endpoint Manager portal and Defender for Endpoint enabled. Visit:

https://endpoint.microsoft.com

As shown above, here, navigate to Endpoint Security, then Microsoft Defender for Endpoint. Ensure that the option Connection status is enabled. If it isn’t then take a look at my previous onboarding article that shows you how to enable this.

Next, navigate to:

https://security.microsoft.com

You should see the screen above. Scroll down this page.

Select Settings as shown above and then Endpoints from the options that appear on the right.

From the menu on left scroll down and select Offboarding. On the right then select Windows 10 and 11 as the operating system. Then select Mobile Device Management / Microsoft Intune. With these selections made a Download package button should appear. Select this to download a zip file that contains a file called WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding

For security reasons, the package used to Offboard devices will expire 30 days after the date it was downloaded. Expired offboarding packages sent to a device will be rejected. That expiry date will be contained in the filename.

Navigate back to Microsoft Endpoint Manager and select Devices | Configuration profiles, then Create Profile.

Select Windows 10 and later for the Platform and Templates from the Profile type.

Select Custom from the list and then Create.

Give the policy a name and description and select Next to continue.

Select the Add button.

Enter the following details into the fields that appear on the right as shown above:

Name = <unique name>

OMA-URI = ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Offboarding

Data type = String

Value = <contents of the unzipped file WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding downloaded from Defender for Endpoint portal>

The WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding file can be opened with Notepad and should look like the above.

Press the Save button to continue.

The Configuration settings page should now look like the above with the single entry you just configured.

Press the Next button to continue.

You now need to select which items this policy will apply to. In general, you are not going to be offboard all your devices at the same time from Defender for Endpoint. What we need to do then is target a specific group of devices.

A good approach to achieving this is to create a dedicated device group, with only the devices you wish to offboard with this policy. I detailed how to create such a group in Azure AD here:

Create a dynamic group in Azure AD

In this case, the dynamic group is called To be retired and I will assign it to the Intune policy as shown above.

Continue to select Next and then Create to complete the policy creation process.

If you select the Device status option as shown above, you’ll see whether the policy has been successfully applied to the devices. How long this takes will depend on when the devices ‘check in’ to get the policy.

As mentioned initially, there is no easy way to confirm that the device has successfully been offboarded unless you look at the registry key:

HKLM:\Software\Microsoft\Windows Advanced Threat Protection\Status\OnboardingState

and ensure that it is equal to 0. To assist with this I have created this free PowerShell script:

https://github.com/directorcia/Office365/blob/master/mde-offboard-check.ps1

That will show you the onboarding status as shown above.

Also, remember that the device will continue to be displayed in the Defender for Endpoint unless you use a display filter. Offboarding causes the device to stop sending sensor data to the portal but data from the device, including reference to any alerts it has had will be retained for up to 6 months.

If you want to offboard more devices you simply need to add them to the group you configured the offboarding Intune policy is assigned to. Remember, that after 30 days you’ll need to go and download a new offboarding package from the Defender for Endpoint console and upload the contents of the new WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding file to the offboarding Intune policy to allow devices to be successfully offboarded going forward. However, you can leave the policy in place and simply update it as and when needed.

Two easy methods of onboarding Windows 10 devices to defender for Business

I recently detailed a way to use Endpoint Manager and Intune to onboard Windows 10 devices to Microsoft Defender for Business:

Onboarding Windows 10 devices to Microsoft Defender for Business

I’ve now extended that to include this video:

https://www.youtube.com/watch?v=UM-WZjHgy88

that shows that method plus using a local script. Using a local script is a good backup method to use if you are in a hurry or have issues with a device in your environment not receiving the policy.

The extra value that many have missed with Microsoft Defender for Business

If you haven’t heard, Microsoft has announced a new version of Defender for Endpoint called Defender for Business. Even better, its going to include Defender for Business in Microsoft 365 Business Premium for free:

“Included as part of Microsoft 365 Business Premium”

This is great news, and the feature set is amazing and all for free, BUT I think most people have overlooked what I would consider the best feature of the new Defender for Business.

Most traditional Managed Service Providers (MSPs) manage endpoints (devices) using a Remote Management and Monitoring tool (RMM) that they need to install on devices, typically only on PCs and not mobile devices like iPhones. Such RMM tools, from third parties, have been subject to successful supply chain attacks as well.

What most have over looked with Defender for Business is that the agent it installs on devices (including iOS and Android I will add) acts in many ways like an RMM agent but provide far more functionality.

An example of why is if you have a look at the free data sources for Azure Sentinel you’ll notice the following:

SecurityIncident – Free

SecurityAlert – Free

DeviceEvents- Paid

DeviceFileEvents – Paid

DeviceImageLoadEvents – Paid

DeviceInfo – Paid

DeviceLogonEvents – Paid

DeviceNetworkEvents – Paid

DeviceNetworkInfo – Paid

DeviceProcessEvents – Paid

DeviceRegistryEvents – Paid

DeviceFileCertificateInfo – Paid

The point is not whether they are free or not, the point is that the Defender for Business is capturing all that device information and feeding it into a centralised cloud dashboard (Sentinel).

Remember, that one of the key things about Sentinel is that you can create customised reports and queries based on the data you ingest. In my case, as an example,

I’ve created multiple custom dashboards from this data to report things like device CPU usage and disk space (above), much like a third party RMM tool BUT WITHOUT the need for a third party RMM tool!

This is because that log data from the device is now available in a centralised location where it can be reported, queried and displayed just about any way you wish!

The Defender for Business agent on devices also makes Microsoft Defender for Cloud Apps (new name for Microsoft Cloud App Security), especially Cloud App Discovery, even more powerful because it now has much greater visibility into the applications and their traffic than before thanks to the Defender for Business agent. Per Set up Cloud Discovery:

Microsoft Defender for Endpoint integration: Cloud App Security integrates with Defender for Endpoint natively, to simplify rollout of Cloud Discovery, extend Cloud Discovery capabilities beyond your corporate network, and enable machine-based investigation.

On its own, Cloud App Security collects logs from your endpoints using either logs you upload or by configuring automatic log upload. Native integration enables you to take advantage of the logs Defender for Endpoint’s agent creates when it runs on Windows and monitors network transactions. Use this information for Shadow IT discovery across the Windows devices on your network.

Without doubt, Defender for Business has massively improved the security capabilities for Microsoft 365 Business Premium with its inclusion. However, I would contend that it has achieved just as much with the reporting capabilities now available, especially when combined with Cloud App Discovery (which is included in Microsoft 365 Business as well) and Microsoft Sentinel.

The way I see it, Microsoft has just provided TWICE the capability and value by adding Defender for Business to Microsoft 365 Business Premium, yet I don’t think many appreciate that yet.

All the Defenders–Update 2

knight

This is an update to the last update about Defender products here:

All the Defenders – Updated

To start off with there are products that are considered ‘Window Defender’ products, although I see the Windows and Microsoft brand intermingled regularly. Here is a list of specific ‘Windows Defender’ products, typically tied to Windows 10 devices, and typically only available with Windows 10 Enterprise but not always:

Windows Defender Application Control – WDAC was introduced with Windows 10 and allows organizations to control what drivers and applications are allowed to run on their Windows 10 clients.

Windows Defender Firewall – By providing host-based, two-way network traffic filtering for a device, Windows Defender Firewall blocks unauthorized network traffic flowing into or out of the local device.

Windows Defender Exploit Guard – Automatically applies a number of exploit mitigation techniques to operating system processes and apps.

The four components of Windows Defender Exploit Guard are:

Attack Surface Reduction (ASR): A set of controls that enterprises can enable to prevent malware from getting on the machine by blocking Office-, script-, and email-based threats
Network protection: Protects the endpoint against web-based threats by blocking any outbound process on the device to untrusted hosts/IP through Windows Defender SmartScreen
Controlled folder access: Protects sensitive data from ransomware by blocking untrusted processes from accessing your protected folders
Exploit protection: A set of exploit mitigations (replacing EMET) that can be easily configured to protect your system and applications

Windows Defender Credential Guard – Uses virtualization-based security to isolate secrets so that only privileged system software can access them.

Windows Defender System Guard – Reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It’s designed to make these security guarantees:

Protect and maintain the integrity of the system as it starts up
Validate that system integrity has truly been maintained through local and remote attestation

In contrast, here are the ‘Microsoft Defender’ products many of which have been re-branded lately:

Microsoft 365 Defender – (over arching service which includes other Defender services) is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications to provide integrated protection against sophisticated attacks.

Microsoft Defender for Office 365 – (previously Office 365 ATP) Safeguards your organization against malicious threats posed by email messages, links (URLs), and collaboration tools.

Microsoft Defender for Identity – (previously Azure ATP) Cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

Microsoft Defender for Cloud – (previously Azure Defender) Provides security alerts and advanced threat protection for virtual machines, SQL databases, containers, web applications, your network, and more. It includes:

Microsoft Defender for Endpoint – (previously Defender ATP) an enterprise endpoint security platform designed to help enterprise networks prevent, detect, investigate, and respond to advanced threats especially on user devices like desktops, laptops and mobiles.

thumbnail image 3 captioned Comparison between Microsoft Defender for Endpoint P1 and P2 capabilities. Microsoft Threat Experts includes Targeted Attack Notifications (TAN) and Experts on Demand (EOD). Customers must apply for TAN and EOD is available for purchase as an add-on.

thumbnail image 10 captioned Microsoft Defender for Endpoint P1 capabilities are offered as a standalone license or as part of Microsoft 365 E3.

There is a Microsoft for Defender P1 and P2 plan. information on the comparison of the two plans can be found here – Compare Microsoft Defender for Endpoint Plan 1 (preview) to Plan 2.

Microsoft Defender for Business – A new endpoint security solution that’s coming soon in preview. Microsoft Defender for Business is specially built to bring enterprise-grade endpoint security to businesses with up to 300 employees, in a solution that is easy-to-use and cost-effective. See Introducing Microsoft Defender for Business for more information.

Microsoft Defender Smart screen – Microsoft Defender SmartScreen protects against phishing or malware websites and applications, and the downloading of potentially malicious files.

Microsoft Defender Antivirus – Brings together machine learning, big-data analysis, in-depth threat resistance research, and the Microsoft cloud infrastructure to protect devices in your organization.

Microsoft Defender Application Guard – helps to isolate enterprise-defined untrusted sites, protecting your company while your employees browse the Internet.

Microsoft Defender Security Center – is the portal where you can access Microsoft Defender Advanced Threat Protection capabilities. It gives enterprise security operations teams a single pane of glass experience to help secure networks.

Microsoft Defender Browser Protection – a non Microsoft browser extension helps protect you against online threats, such as links in phishing emails and websites designed to trick you into downloading and installing malicious software that can harm your computer.

Microsoft Defender for Cloud Apps – (previously Microsoft Cloud App Security) is a Cloud Access Security Broker (CASB) that supports various deployment modes including log collection, API connectors, and reverse proxy. It provides rich visibility, control over data travel, and sophisticated analytics to identify and combat cyberthreats across all your Microsoft and third-party cloud services.

So, as you can see, there are quite a lot of ‘Defender’ products out there from Microsoft.

For now, just be careful to investigate what is actually meant when it says ‘Defender’ in the Microsoft space!