Defender for IoT Deployment Models: Which One Works for You?

Defender for IoT bridges the gap between the Defender suite with all of its insights, recommendations and alerting we know and love to the vast unknowns of the OT and IOT space.

There are two primary types of “installations” for this product. One is very “light-weight” and easy to get up and running, while the other takes some more effort and planning but in return provides more insight and value.

Architecture overview

As you can see in the above image, the product “Defender for IOT” relies on SPAN traffic from switches. To simplify; this means that network-switches duplicate the data they send to a port where we have a physical sensor installed (marked blue below the line in the image above) that reads out all relevant data that passes through and “chews” it into alarms for Defender. This “OT network Sensor” is the “heavy-weight” installation, if you will.

Comparatively, the “light weight” configuration is using Defender for Endpoints “Device Discovery”, aka the “Enterprise IoT network sensor” uses the endpoints where you have Defender installed to chart out the network using active queries, and lists OT or IoT devices in your network.

As you might have noticed, you can theoretically go “light-weight” or “heavy-weight” on both OT and IoT. To understand this better, lets do a quick diff, and then jump into some examples!

Endpoint Agent or full sensor and SPAN setup?

The differences between these setups are quite large.

The Enterprise IoT security using the Defender for Endpoint agents to scan the network provides you with:

• Device types, names and manufacturer
• Firmware
• Vulnerabilities in IoT devices
• Discover legacy protocols (telnet, vnc with no auth, SNMP V1 and V2)

Enterprise IoT can also notify you of OT devices in your network, but gives limited security insights compared to the full “heavy-weight” OT network sensor.

The OT network sensor uses SPAN from network equipment to provide you with:

• Device inventory (name, ip, mac, vlan, firmware, site)
• Alerting based on common and OT protocol specific detections
  • Both for Security and for operational issues
• PCAPs from alerts for deeper investigations
• Vulnerabilities tied to firmware
• Learning a baseline of your OT network
• Network Map provides an interactive illustration of communication
• Find misconfigurations or errors in protocols
• Threat intelligence for OT
• Full on-prem or cloud managed deployment models

Typical Office IoT

These companies usually don´t have much OT, and a varying degree of IOT.

Perhaps you´ll find some:

• Printers
• Meeting room systems
• HVAC systems
• Access Control Systems
• Cameras
• Networking equipment
• Other knick-knacks (fridge, coffee machines, etc)
• Perhaps more? They dont really know just yet…

In this case the company network is flat, and all the devices in the network can talk to each-other. In this usecase, we can simply use Defender to chart out the IoT devices in the network. This can be done using a trial for “Defender for “Enterprise IoT Security” or if the company has E5, then it´s included! Simply turn it on in the Defender portal and see what risks you can find in the Microsoft Security Portal Device Inventory under IoT/OT or Network devices.

Production facility

Hold on to your hats, this section might get out of hand…

Imagine a company with a production facility. Its off-site from the main office, it has its own IT rig, and OT to automate, maintain and secure most of the production line. They have:

• Robot arms for many different purposes
• Conveyer belts
• CNC machinery
• Cranes
• Generators
• Ventilators, valves,
• etc…

All of these systems are delivered and managed by different partners. And very often we find that these partners dont do IT security. Some of them do, but price it far out of reach for the regular SMB customer. They dont want any agents on their OT computers, they dont want any scanning performed as it might impact some of the PLC devices that are network connected, and we are left slightly blind. Maybe we get some device names and mac-addresses in the firewall at best…

This is where the “Heavy-weight” configuration hits the nail on the head! By sniffing the network traffic from the switches it can continuously digest everything that is happening on the proprietary OT protocols (Supported protocols). Defender for IoT also builds a baseline during the first 30 days of “expected traffic”. Any anomalies detected after this will be flagged as alerts, that can then be managed and muted in the Azure Portal.

The prerequisites for a quality “heavy-weight” installation:

There are some “gotchas” for running this type of installation. Defender for IoT´s quality depends 110% on the contents of the network traffic. If the switches lacks compute power, this might impact the SPAN quality or network quality over all. If the PLCs dont chat much on the network, you wont see much either. And last but not least depending on the switch architecture and where your sensor(s) are placed!

If you place your sensor on a switch high up in the network-hierarchy, as in my illustration above, you are probably missing out on layer 2 traffic. Illustrated in the lower left corner in the image above (red arrow).

This could be alleviated by using ERSPAN (encapsulated remote SPAN), where you remotely send SPAN through the network stack from more/all of your switches to your sensor with multiple interfaces. However, that would mean that the network needs to have sufficient capacity to carry that load up to the sensor. Also your switches have other support ERSPAN.

So the choices are:

• One sensor for each switch (full coverage)
• One sentral sensor with ERSPAN from all switches (full coverage)
• Sensors in critical locations, selected switches and entry/exit (selective coverage)
• One sensor on entry/exit (limited coverage, minimal Layer 2 traffic)

You could also force network traffic up through the firewall, thereby making everything pass the sensor, but this would mean a big load on the network and possibly increased delay. From experience, not all OT systems handle this gracefully…

Sensor hardware

You could run this sensor virtually, but we usually opt for the physical sensors as our OT customers rarely have any hypervisors on their OT sites.

Microsoft has a list of supported servers and workstations that function well natively installed with Defender for IoT (Linux Appliance). See the list of supported hardware here.

For labbing and testing it out, just spin up a Virtual Machine with this appliance, and try uploading PCAP files directly to the sensor to populate some data. You can even try with some PCAP data from your own environment to test it out!

Controlling the appliance

The easiest way to go about this is to create a cloud managed appliance. This way it is licensed and connected directly to Azure and pipe its alerts there. It then natively integrates with Defender XDR and feeds data into the XDR correlation engine. The Azure portal also streamlines the sensor configurations (NTP servers, VLAN names, subnets, etc…) and can remotely update both OS and Threat Intelligence.

Alerts from Defender for IoT can be managed from the Defender for IoT Azure panel as of now, or integrated with Sentinel.

But if you want to run the sensor in full “on-prem” mode you can. However, the on-premises console that used to exist to manage multiple sensors has been retired, so your best bet for a on-premise configuration is probably to utilise one big sensor to pull all your data into for a single-pane of glass experience in the built-in sensor admin panel.

Conclusion – which model is right for my business?

To summarize, Defender for IoT is a product thats “slept on” (not appreciated enough) given its low barrier to entry in terms of pricing and the insight it gives into what many consider to be a big blind spot in their infrastructure. Setting up the “heavy-weight” configuration does take some planning and effort to complete, but carries some great value for SMBs.

In my opinion, for small companies with only IoT equipment, starting off with the “light-weight” installation of the “Enterprise IoT Security” is the way to go to quickly chart out some easy-to-fix vulnerabilities.

However, if you are a business that manages factories, warehouses or other OT-heavy industries, the “heavy-weight” installation of an OT sensor should be considered. Especially if your network infrastructure for the site is solid and can provide proper data for the sensor to read from, this could be a quick win with great value.

Start a free trial and try it out today, be it the “light-weight” or the “heavy-weight” configuration. Whatever floats your boat!