During the last few years, I worked with a couple of customers who struggle with getting control over their corporate networks. Even though we all know corporate networks should be managed well with all the correct security controls like segmentation, Network Access Control implementations, and zero-trust designs, a lot of organizations keep struggling with knowing what devices are present on legacy network segments.

There are a couple of great network scanning and documentation solutions out there that can help organizations in getting insights into their networks. Although these dedicated network scanning solutions have many more features than what we are going to discuss in this post, I hope to inspire people you do not always need an expensive fancy network scanning solution to know what exists on your network. In this post I want to show you how we can get better network insights with just a couple of MDE onboarded devices with Device Discovery enabled, a sentinel workbook, and a list of your network segments described in a watchlist. Using this, I am confident you will have better insights into your network compared to what Device Discovery provides out of the box.

Device Discovery is a feature in Defender for Endpoint that helps you discover unmanaged devices on your corporate networks without the need for extra appliances. This feature uses your onboarded devices to probe and scan your corporate networks and search for enterprise endpoints, network appliances, and IoT devices.

There are two modes in which device discovery can run, being basic and standard discovery. In essence, the basic discovery mode will passively collect events in the network without initiating network traffic, while the standard mode will initiate traffic to actively find devices on a network. To have the best results during device discovery, the standard mode is recommended.

Since it is not the purpose of this blog post to rewrite the Microsoft learning pages, I like to refer to Microsoft learn which you can follow on how to set up device discovery in MDE. I mainly want to focus on how we can improve the visibility of Device Discovery, so it can be more useful. 

It is important to set expectations right first. Device Discovery is not a vulnerability scanning feature for remote devices (unless you configure authenticated scans, but that is for another post ?). It purely analyzes traffic on the network to find devices on the same subnet as the onboarded devices and provide more context. This means that if you want to have insights into a network, you need at least one MDE onboarded device on the subnet in question. Device discovery analyzes the following protocols to gather information on the neighbor network devices: ARP, FTP, HTTP, HTTPS, ICMP, LLMNR, NBNS, RDP, SIP, SMTP, SNMP, SSH, Telnet, UPNP, WSD, SMB, NBSS, IPP, PJL, RPC, mDNS, DHCP, AFP, CrestonCIP, IphoneSync, WinRM, VNC, SLP, LDAP

An important caveat is that only certain operating systems are supported to perform device discovery: Windows 10 version 1809 or later, Windows 11, Windows Server 2019, or Windows Server 2022. I do not think this will pose an issue for most organizations, although it can be very annoying when you have a specific subnet with almost exclusively MAC OS, Linux, or legacy devices. Keep this in mind, because for these networks you will not be able to rely on device discovery to have insights. Although you are theoretically able to deploy a device with supported OS in these networks purely for using Device Discovery. 

How frequently does device discovery run? Well, this is not something you can configure yourself. According to the Microsoft learn pages: "Devices will actively be probed when changes in device characteristics are observed to make sure the existing information is up to date (typically, devices probed no more than once in a three-week period)". This means you will have to trust on Device Discovery to be able to detect changes in device characteristics to probe a device. I would rather like an option to forcefully schedule an extra probe on top of the automatic detection, to be more sure a scheduled 'full probe' is executed frequently. 

Another caveat is when wireless client isolation is used on a network. Most network vendors have the ability to isolate Wi-Fi devices from each other, even though they are connected to the same SSID and network. When this is enabled, device discovery will also not work, since the MDE onboarded devices will not be able to analyze traffic from other devices.

The biggest problem I have with the 'Devices' view in Defender XDR, is the limited ability to filter on certain properties, and the missing context of the subnets devices are connected to. To address these two main issues, I started creating a workbook in Microsoft Sentinel to create my own visualization of the device discovery data, mainly focused on the discovered unmanaged devices of the network. The main dependency for this workbook to work is that you will need to ingest Defender XDR DeviceInfo and DeviceNetworkInfo table to Microsoft Sentinel.

A second dependency for the workbook to work well, is that you will need a sentinel watchlist with the alias named 'networks', which consists of a list of the subnets that exist in you organization. This watchlist will be used to get you the context of to which subnet a device is part of. The CSV I used for this watchlist is the following:

Location;Segment;SegmentType;VlanID;Firewalled;Name;Description;IPStart;IPEnd;NetworkAddress;Prefix;Gateway

For which the following properties are required:

• Name - Represents the name of the subnet, and should ideally be unique (but not necessary)
• Network Address - The network address of the subnet in question, and should ideally be unique (but not necessary)
• Prefix - The prefix of the subnet in question, which will be used to compose the correct subnet mask

All the other properties can serve for extra context to enrich the data in the workbook even further.

There are 8 usable parameters in the workbook which can be used to filter the data set:

• First Seen - This filter can be used to filter how far you want to go back in the data set.
• Include known vendors - This filter creates a list of all the Vendors found by device discovery, which you can use to filter the data set. Use it to for example only see unmanaged Apple devices.
• Only flag unassigned group - In Defender XDR you are able to group managed and unmanaged devices in groups. When you set this filter to 'True', you will only see devices which are not included in a device group.
• Include join type - You can set this filter if you would like to include or exclude devices from a specific join type
• Exclude excluded devices - Although the name of the parameter sounds a bit weird, this parameter lets you choose if you would like to see devices that are excluded from Device Discovery or not. Device discovery will always have information of an excluded device one time, whether it is excluded or not.
• Include device category - This parameter created a list of the device categories found by Device Discovery. These are also the categories you will find in de 'Devices' view in Defender XDR, being 'Endpoint', 'Network Device', or 'IoT'.
• Include networks - This parameter creates a list of the network names found by device discovery, which will in most cases be the domain name of the network. One network in this filter can consist of multiple subnets.
• Networks (watchlist) - This is the filter based on the networks watchlist we spoke earlier about. When you want to filter devices present in a certain subnet, you can use this filter.

In the above screenshot, you can see the overview graphs I added to the workbook. The goals of these is to give you a better idea of the onboarding state of your environment, but also to give an idea where the unmanaged devices live and what kind of devices these are.

• At the top left you find an overview showing the onboarding state based on the configured filters, quickly showing how many unmanaged devices are found.
• At the top right, you will find in which subnets of your network the unmanaged devices live.
• At the bottom, you see the unmanaged devices counted by vendor, connected network, and device category. This can help in understanding what kind of devices these unmanaged devices are.

In the above screenshots, you can see what the detailed view looks like. This view can be used to get more specific information regarding the unmanaged devices found by the filters you configured. It is important to note that one unmanaged device can be found multiple times in this view. This is because we aggregate the first and last time a device was seen, based on all the properties you can find in the view. This means that if -for example- a device has two NIC's resulting in two IP and MAC addresses bound to the device, you will find the device two times in this view.

You will notice that the DeviceName, DeviceId, and IP address is a clickable link. When you click on the DeviceName or DeviceId you will be redirected to the Device page in Defender XDR:

When you click on the IP address, you will be redirected to the IP address page in Defender XDR:

I did not add the workbook to the Sentinel GitHub repository yet, since I think the workbook still needs some extra features before in is ready to go to the Content Hub of Sentinel. Either way, if you already want to test out the workbook you can find it here:

		
Code loading...
      	
    

Make sure to let me know what you think of it, and what you are still missing ?.

• Add subnet context for managed devices as well
• Add priority when an unmanaged device was found on a server subnet
• Create detection rules to flag certain scenarios