Microsoft Defender for IoT sensors have limited out-of-the-box capabilities to integrate their data into Azure Sentinel. Today the sensor platform supports only sending alerts to Sentinel, which is limiting since a modern SOC must have the ability to correlate any relevant sensor data that occurred around the alerts with other sources to form a complete investigation. This post explores our ability to utilize the Defender for IoT sensor API, which arms our data-driven SOC with advanced detection, automation, and investigation capabilities for OT environments.
Enabling Security for IT and OT Convergence
Digital transformation is actively merging IT technologies into OT networks. When we discuss attack vectors on an OT network, most attacks will start with traditional IT assets. This fact is supported by the latest MITRE ATT&CK framework for Industrial Control Systems, as you’ll find that the majority of MITRE techniques in the Initial Access tactic family will involve an IT asset. Simply put, while the OT network may be the final target for an adversary, we see the attacks coming through traditional IT firewalls, networks, and endpoints. This drives the need for modern SOCs to have a converged view of both IT and OT security data. With the ingestion of OT monitoring data from Defender for IoT into Azure Sentinel, it enables a SOC to view the whole attack chain by utilizing all security solutions under the Microsoft 365 security suite and third-party security providers. 
Ingesting the Data
As a cloud-native SIEM, Azure Sentinel often requires a different approach to gathering data from on-premises solutions. It would be easy to access the Defender Sensor API by opening firewall ports and exposing those systems to the internet. However, it would be unacceptable to create exposure to accomplish log ingestion, especially considering that these sensors often reside in highly sensitive environments such as critical infrastructure. Luckily, Microsoft has a variety of technologies that aid with on-premises data collection while maintaining the overall network security posture. In our implementation, we utilize an Azure Function App and a Hybrid Connection to connect to the on-premises Sensor API, which allows us to securely gather data from the API without the need to modify firewall configurations or create VPN tunnels. 
A simplified approach that would not require any customized scripting would be to utilize an Azure Logic App with an on-premises data gateway. However, our use of Azure Function Apps allows us to create a more reliable ingestion workflow with robust error handling and event filtering. Function Apps also provides us options for data normalization and transformation before receiving the data into Azure Sentinel.
Understanding the Data
The Defender for IoT Sensors has the following API Endpoints available for event and reporting data. Each sensor will need to be independently queried for data.
| /api/v2/devices | Description: Lists all devices that the Defender for IoT sensor has detected SOC Use Cases: – Centralized Device Inventory with other sources such as Active Directory, Firewall logs, Defender for Endpoint, etc., which helps correlate entities across various log sources. – Further inventory enrichment with the use of Microsoft Sentinel Watchlists allows for additional SOC automation and gives the analyst further context for entity investigation. o Ability to enrich inventory with FIPS 199 system categorization. o Add additional fields to device inventory such as system owner, contact, operational context. Sample Data: “vendor”: “INTEL CORPORATE” “name”: “DESKTOP-HLS7Q4K” “hasDynamicAddress”: false “firmware”: null “id”: 33 “macAddresses”: “10:f0:05:91:3b:47” “authorized”: true “ipAddresses”: “192.168.1.222” “engineeringStation”: false “type”: “HMI”, “operatingSystem”: “Windows 10”, “protocols”: “addresses”: [ ] “id”: 1271525860 “name”: “MDNS” “addresses”: [ ] “id”: 5 “name”: “HTTP” “scanner”: true |
| /api/v2/devices/connections | Description: Lists network connections seen between devices by the Sensor *This data needs to be correlated with the sensor inventory data to become functional. Sample SOC Use Cases: – Detections on unusual network connections between devices. – Populate Sentinel entity behavior analysis dashboards with recent connectivity data. – Network connectivity mapping diagrams and better understand entity relationships. Sample Data: “secondDeviceId”: 36 “discovered”: 1631556177000 “firstDeviceId”: 24 “lastSeen”: 1632307158438 “ports”: 80 “protocols”: “commands”: [ ] “name”: “HTTP” |
| /api/v2/alerts | Description: Lists alert data that the Defender for IoT sensors detected Sample SOC Use Cases: – Threat intelligence indicators within Azure Sentinel to enrich sensor alerts. – Automation rules or Azure Sentinel functions for further alert tuning and data enrichment. – Sentinel Playbooks for incident/alert automation. Sample Data: “engine”: “Malware” “severity”: “Major” “title”: “Connection Attempt to Known Malicious IP” “additionalInformation”: null “sourceDevice”: 23 “destinationDevice”: 2 “time”: 1631575083000 “message”: “A source attempted to connect to an IP address that was previously published as a malicious IP. Source 192.168.1.96 attempted to connect to destination 72.21.91.29, a published malicious IP which known as ‘a malicious IP'” “id”: 69 |
| api/v2/events | Description: Lists events that are reported in the IoT Sensor event Timeline. Sample SOC Use Cases: – Utilize threat intelligence indicators within Azure Sentinel to enrich event data and create custom alerting. – Create custom detections around specific events (Example: PLC Program Update – Outside Maintenance Window) – Populate Sentinel entity behavior analysis dashboards with recent event data. – Correlate and enrich data from other log sources in Azure Sentinel (M365 or third party) Sample Data: “severity”: “NOTICE” “title”: “PLC Program Update” “timestamp”: 1632312584000 “content”: “Program update detected, sent from 10.2.1.25 to 10.2.1.14” “owner”: null “type”: “PROGRAM_DEVICE” |
| /api/v2/reports/vulnerabilities/devices | Description: This API reports vulnerability assessment results for each device Sample SOC Use Cases: – Custom detection rules for vulnerabilities. – Custom detection rules for unusual / newly seen network ports. – Populate Sentinel Entity behavior analysis dashboards with newly detected vulnerabilities. – Custom dashboards for viewing vulnerability data. Sample Data: “name”: “IED10” “ipAddresses”: “10.2.1.10” “securityScore”: 100 “vendor”: “ABB Switzerland Ltd, Power Systems” “firmwareVersion”: null “model”: null “operatingSystem”: “name”: “ABB Switzerland Ltd, Power Systems”, “type”: “abb” “version”: null, “latestVersion”: null “vulnerabilities”: “antiViruses”: “McAfee” “plainTextPasswords”: “password”: “123456” “protocol”: “HTTP” “lastSeen”: 1462726930471 “strength”: “Very Weak” “remoteAccess”: “port”: 5900 “transport”: “TCP” “clientSoftware”: “VNC” “client”: “10.2.1.20” “isBackupServer”: true “openedPorts”: “port”: 80 “transport”: “TCP” “protocol”: “HTTP” “isConflictingWithFirewall”: false “isEngineeringStation”: false “isKnownScanner”: false “cves”: “id”: “CVE-2015-6490” “score”: 10 “description”: “Frosty URL – Stack-based buffer overflow on Allen-Bradley MicroLogix 1100 devices before B FRN 15.000 and 1400 devices through B FRN 15.003 allows remote attackers to execute arbitrary code via unspecified vectors” “isUnauthorized”: false “malwareIndicationsDetected”: true |
Once the Data is Ingested into Azure Sentinel, we utilize KQL functions to parse the data into more useful columns; this also includes joining the device inventory data with the other tables for better context. 
Conclusion
There is no question that implementing an OT/IoT security solution provides critical detective controls currently missing from most environments, especially with the rise of prominent threat actors that are specifically targeting these exposures. Full integration of Defender for IoT into Sentinel can unlock powerful opportunities for correlation, threat intelligence, automation, and increase visibility across the IT and OT environments while maintaining the different approaches that an OT network requires for monitoring. While Azure Sentinel is cloud native and has some added architectural requirements for securely integrating with on-premises APIs, we can implement repeatable, secure, low cost, and low management overhead solutions to enable the modern SOC.
Caleb Freitas is a Managed Sentinel security architect.