In-Depth: Microsoft Defender for IoT
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.
