This article is contributed. See the original author and article here.
Earlier today, we announced a new set of capabilities for Microsoft Defender for Endpoint that empower organizations to discover and secure network devices and unmanaged endpoints. This is especially critical in the new global hybrid working environment, which exposes the most challenging cybersecurity landscape we’ve ever encountered. This blog provides more information on the unmanaged endpoint discovery feature while an additional blog provides more information on how to configure the network device discovery feature.
The challenge – unmanaged endpoints
In recent years, the efficacy of Endpoint Protection (EPP) and Endpoint Detection and Response (EDR) platforms has continued to increase. With the rise of unified SIEM and XDR (extended detection and response) solutions, like Microsoft 365 Defender, the level of efficacy that our customers are benefiting from continues to improve. To fully utilize these solutions to defend your environment, it’s critical to have full visibility of all the devices in your organization. You can’t protect what you can’t see!
David Weston, Microsoft Director of Enterprise and OS Security, advises:
“The riskiest threat is the one you don’t know about. Unmanaged devices are literally one of your weakest links. Smart attackers go there first. With work-from-home, the threat has grown exponentially, making discovering and applying security controls to these devices mission critical.”
There have been many examples where unmanaged devices were exploited and led to a breach, such as the Equifax breach. In this case the breach originated via an unpatched vulnerability on an internet-facing server. This might have been easily addressed except for the fact that the server was unmanaged–no one knew it needed patching. Those responsible for the security profiles and policies of these devices were basically unaware of its existence.
Unmanaged endpoint discovery in Microsoft Defender for Endpoint
To address scenarios like this we’re adding unmanaged endpoint discovery to Microsoft Defender for Endpoint to help customers discover and secure unmanaged endpoints on their corporate network. This will help detect and report upon any device seen on a corporate network that can be onboarded and secured by Microsoft Defender for Endpoint.
As part of this new functionality, two forms of discovery are provided including Standard and Basic. For public preview all tenants will initially have Basic discovery configured which uses unicast or broadcast network events captured by the onboarded devices to discover unmanaged endpoints. Basic discovery uses the SenseNDR.exe binary for passive network data collection and no network traffic will be initiated. On May 10, unless otherwise configured by the tenant, we will automatically switch from Basic to our recommended form of discovery which is called Standard discovery. This is an active discovery method where managed devices actively probe the network to identify unmanaged devices. From here the interfaces on discovered devices are leveraged to collect threat, vulnerability and metadata used for device fingerprinting. Standard discovery builds a deeper more complete picture of the discovered devices than Basic mode and and allows for vulnerability assessments.
When you go to Microsoft 365 security console you will see two new tiles available. The first shows “Devices to onboard” and will present all devices seen in the last 30 days. We also check whether the device has been seen more than just once over a 3-day period. This prevents a recommendation appearing to onboard a device that was plugged onto the network once, then won’t be seen again.
The second tile is “Discovered devices in my network” and will be broken down into device types.
Once discovered, the devices will appear in the Device Inventory. Clicking the button to “View recently discovered devices” will take you straight to where we have a new set of filters available where you can apply criteria relevant to these new devices, as shown in the screenshot below:
This data is then used as part of the security recommendations within threat and vulnerability management. You can go to the Security recommendations section under Vulnerability management and type “Onboard” into the Search box to see discovered devices eligible for onboarding:
Once you know about these devices, you can start to onboard them into Defender for Endpoint. This empowers you to close the unmanaged endpoint gap in your environment which is an easy target for attackers. By using the remediation options presented as part of the Security Recommendations, you can open a ticket in Microsoft Endpoint Manager to remediate and onboard the device.
Advanced hunting has also been improved to allow you to query these devices and export data with whatever columns you like:
| where Timestamp > ago(7d)
| summarize arg_max(Timestamp, *) by DeviceId
| where OnboardingStatus == ‘Can be onboarded’
| distinct Timestamp, Device Name, DeviceId, OSPlatform, OSDistribution, OSVersion, ReportId
“Timestamp” and “ReportId” lets you run this as a custom detection. For example, you could write a rule to generate an alert whenever a device is connected to a certain subnet.
We have also exposed “Onboarding Status” in the API and in the connector for Azure Sentinel, to provide visibility into security tooling you might have in place.
You will see that endpoint discovery is enabled on your tenant through a banner that appears in Device inventory . This banner will be available until the automatic switch from Basic to Standard discovery occurs on May 10th, giving you the option to easily spot and switch over to Standard discovery as soon as you are ready.
If you don’t want Standard discovery to be automatically enabled on May 10, you also have the option to go to Device discovery in settings and select Basic discovery to ensure the automatic change doesn’t occur.
Although we recommend using Standard discovery, there may be conditions that justify applying controls to the discovery process. When Standard discovery actively probes the network, it uses two PowerShell scripts. These PowerShell scripts are Microsoft signed, and are executed from the following location:
C:ProgramDataMicrosoftWindows Defender Advanced Threat ProtectionDownloads*.ps
If you are using other security tooling in your environment, there is a possibility these scripts could cause alerts to be raised in those tools. To avoid this situation, we suggest adding the path the scripts are run from to the allow list within your tooling. We also provide customization capabilities around which devices will perform Standard discovery and thus run the scripts. When you enable Standard discovery, the default mode is that all managed Windows 10 devices perform this task. To change this you can leverage a tagging feature which enables you to restrict the execution of the Standard discovery process to only certain devices in your environment.
One caveat: we only recognize tags that have been applied to the device through the portal (or via the API). You cannot utilize tags that have been set via the registry on the device.
You may also have situations where devices are set up as honeypots or have certain networks where you have specific monitoring in place. You can exclude these from Standard discovery and can configure this through the Exclusions tab in Device discovery. There, you can specify either a specific IP address or a subnet to exclude from the Standard discovery mode, although we will still gather details of devices through the passive discovery available in Basic discovery.
Discovering the right devices
One important aspect to this functionality is ensuring it discovers the correct devices. You don’t want to take your laptop home and then see all your smart devices, TVs, gaming consoles, etc., showing up in the device inventory list. Not only does it clutter the inventory, but there are also privacy implications from discovering personal, at home devices.
The good news: there is built-in logic to prevent this, and a level of control to define what networks this discovery process runs against. The logic was designed to differentiate between corporate networks and non-corporate networks, to avoid discovery of private or public devices not controlled by the organization. Strict conditions are in place to ensure such devices won’t be discovered and presented in the portal.
The system differentiates between corporate and non-corporate networks by correlating common network interfaces identifiers among Microsoft Defender for Endpoint onboarded devices.
To add an extra layer of control, the following screenshot displays the Monitored networks tab within Device discovery settings which makes discovered networks visible and enables you to specifically whether to include or exclude them.
Disabling…if you really must!
Finally, if you decide that our new endpoint discovery capability isn’t for you, a switch is available in the Advanced settings page in the Microsoft Defender Security Center that allows you to disable the feature (under “Endpoints” in the settings in the Microsoft 365 security center) . While this isn’t recommended, we recognize some organizations may require due diligence to be performed before taking advantage of the feature.
We’re excited to offer you this new functionality and thank you for your interest in the unmanaged endpoint discovery feature. You will gain enhanced visibility of your estate, and the power to close down a vector of attack that attackers increasingly take advantage of.
We encourage you to join us in the public preview program. This program lets you test new features in their early phases and captures your feedback that will influence the final product. For those not already enrolled in the program, we encourage you to participate by turning on preview features.
Once enrolled, we welcome your feedback. More information about this feature and our broader range of unmanaged devices capabilities can be found in the Microsoft Defender for Endpoint product documentation.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.