In-Depth

In-Depth: Microsoft Defender for IoT

• By Paul Schnackenburg
• 02/26/2024

It's no secret that I'm a fan of Microsoft's Defender family -- I'm using it to secure my clients and I've written articles on several members: Defender for Business, Identity, Threat Intelligence & External Attack Surface Management, and how they integrate to become more than the sum of their parts.

But one has been in the shadows of the others for some time, Defender for IoT. This is actually sort of two products in one, originally based on the acquisition of the company CyberX.

In this article I'll do a brief overview of Enterprise Internet of Things (EIoT) and Operational Technology (OT), and how you can use this Defender to protect both, as well as integrate everything into a single Security Operations Center (SOC) solution.

Through the Mirror into a Strange World
For Operational Technology, OT (sometimes referred to as Old Technology) is Industrial Control Systems (ICS), sometimes also referred to as Supervisory Control And Data Acquisition (SCADA) -- think of hardware and software detecting or causing changes in industrial equipment and processes. There are differences between those definitions, but to boil it down for this article, these are the systems that: monitor equipment on a factory floor; close or open valves and doors; and show screens to operators with values for pressure, temperature or how far along a particular process has progressed. These are also sensors and network connectivity in faraway places, keeping tabs on wind generator output and performance, or pressure on an oil rig, for examples.

As a longtime IT professional, I have been aware of OT, but in a recent project I've had reason to dive a bit deeper. What I've learned is fascinating (and a bit scary) -- these devices and the software that runs them are often old, with device lifetimes measured in decades, not years. The main focus for staff is safety of people and the production line, as opposed to cyber security. And because these systems often were air gapped from other networks (and the internet), security was not high on the priority list, something that's changing rapidly.

They often come with default credentials (easily found on the internet), have no capacity or option for running local agents for protection, sometimes can't be updated except by physically connecting them to a management workstation or inserting a USB stick, and often use proprietary protocols for communication. And unlike in an IT network, you can't do any active scanning on the network to discover or fingerprint devices, as they might crash resulting in downtime, safety issues or the need to send a technician to every remote location to manually reset each device.

There have been many high-profile attacks on OT networks -- several attacks using the Triton OT malware against oil refineries in the Middle East comes to mind. And of course there was the OG attack on an ICS system, Stuxnet, which was used to slow down Iran's nuclear weapons program by destroying centrifuges using custom malware. And most recently the U.S. has exposed the Chinese state-sponsored group Volt Typhoon and their infiltration of critical infrastructure systems, presumably in preparation for an invasion of Taiwan. There's even a MITRE ATT&CK matrix for ICS systems.

And that air gap isn't always as secure as people would like to think, with surprising connections being found in large environments. Most OT attacks start in the IT network and then move laterally into OT systems.

The traditional model for the layers in an OT network is the Purdue model, and while it's often regarded as somewhat outdated (originating before the "connect everything to the cloud for easy management" movement), it nevertheless assists in architecting these networks and placing sensors in the best locations (see below). It's got six layers (0-5) with the physical processes on level 0, sensors, analyzers etc. on level 1, control systems on level 2, operations systems on level 3 (and DMZs on level 3.5 if you have them), and IT networks on level 4 / 5.

Then we have Enterprise Internet of Things (EIOT), which is all the other "stuff" connected to enterprise networks apart from servers, laptops and smartphones. These are printers, surveillance cameras, switches, temperature sensors, HVAC systems, smart TVs, projectors, VOIP phones and the occasional consumer IoT devices such as an Amazon Echo in someone's office. And these can often be a springboard for attackers, the canonical example here being the (unnamed) casino in the U.S. which had its high roller database stolen by an attack that started with the compromise of a temperature sensor in the lobby fish tank.

More recently LastPass was compromised by an attacker, starting with an out-of-date Plex media software package in a DevOps engineer's home network, followed by the installation of a keylogger on a home computer. That attack still has fallout with customers' master passwords being brute forced, and there are some reports of crypto currency being stolen after wallet credentials are found in password vaults.

A colleague (and former student) of mine, part of the team securing public hospitals and centers across Queensland (population about 5.5 million), refuse to call these devices IoT, and always inserts an S for "S%^*" Things. I think he's absolutely right, based on their poor security, and it makes sense why they're not allowing them in a hospital setting. That's not the case in most businesses though -- so what can you do?

Toss a Coin to Your Defender
Defender for IoT is a two-part solution -- let's start with the OT sphere. This is a service in Azure, supported by sensors that you install on-premises. These are hardened Linux appliances with a web GUI that you can either buy pre-configured from Arrow Electronics, install on your own hardware, or run as VMs on Hyper-V or VMware. It used to be based on Ubuntu, but versions after 23.2 run on Debian 11. Pricing is based on number of devices you're monitoring per site.

This sensor is passive (active scanning on OT networks is dangerous as mentioned above, although Run Zero is having some success), only reading data from a SPAN or RSPAN port on switches or using a TAP. From this captured network data, it'll identify devices on the network, and their connectivity to other devices (inventory). It'll also create network diagrams, which can be arranged according to the Purdue model.

A sensor can either be online and able to upload data to Azure (directly or via proxies), or offline and only managed locally. For the latter you'll also have to update it with new detections and versions manually. There is an on-premises console to which you can connect multiple sensors, but it's being retired and won't be available after Jan. 1, 2025.

For each device it'll identify the make and model, firmware version and any associated CVEs. It'll also raise alerts based on:

• Policy violation -- new device / new configuration on a device / firmware change
• Protocol violation -- packet or field structure not matching the protocol specification
• Operational alert -- a device or interface is stopped for example
• Malware alert -- malicious network traffic
• Anomaly alert -- deviation from what the engine has learnt is normal

There's also a list of recommendations, like Secure Score in other Defender products, that gives you a list of actions to take to improve your OT security posture and remedy vulnerable devices and attack paths.

In Azure you can use workbooks to build custom dashboards, and there are built-in reports that can be exported. Defender for IoT can be integrated with Microsoft Sentinel (as well as third-party SIEMs) to achieve a single SOC monitoring all security issues in a business. This is an important concept because OT and IT networks are different, and while attackers can move between them, the effort required to integrate the monitoring and alerting is only half the battle. You have to follow up with training of SOC analysts to recognize the nuances in OT alerts and understand the right remediation actions to take when there is an incident.

On the EIoT side of the house, Microsoft has recently moved the service from Azure into the Defender XDR portal. If you have Microsoft 365 E5 / E5 Security you get five devices per user license for free (but not with A5 in the education space ☹), with add-on packages available if you have more devices than that. The number of devices is pooled across all your users, so 100 users gives you up to 500 overall devices monitored. The sensor is all your Defender for Endpoint P2 devices, which will scan the local network where they're located and inventory all the IoT devices. If you have a subnet where no such device is connected, there is a sensor you can download and deploy. A common question is what happens when people work from home, and there are some smarts to filter out personal devices and only show devices connected to corporate networks.

This part of Defender for IoT is fully integrated into the XDR portal, with alerts showing up in the central incident queue, and the data being available for querying using KQL. This makes a lot of sense. If an attacker gains a foothold on an IoT device and then tries to move laterally to computer devices, you don't want that alert showing up in a different console, requiring the analyst to manually correlate between the two.

Conclusion
If your organization has gone all in on Microsoft's security suite, and has deployed Defender for Endpoint P2, turning on EIoT monitoring is as simple as enabling a single slider. This is a no-brainer and gives you visibility into all those other devices connected to your networks, and their vulnerabilities. I guarantee you that you'll be surprised at how many there actually are.

On the OT side, Microsoft has strong competition from many other vendors in this space, but Defender for IoT's strength lies in the integration -- being able to monitor all assets and build a SOC that monitors, alerts and remediates security issues across your estate is extremely valuable. There's a 60-day trial for up to 1,000 devices available so you can easily try it out.