Integrate Microsoft Sentinel with Microsoft Defender for IoT

Investing in industrial Operational Technology (OT) / Internet of Things (IoT) security is critical now more than ever due to escalating cyber threats, increasing interconnectivity of systems, and the need to protect essential infrastructure and business continuity. Microsoft’s flagship OT security product, Microsoft Defender for IoT, when deployed with Microsoft’s cloud-native SIEM (Microsoft Sentinel/Defender XDR) creates the most effective OT security solution in the industry.

Why the rise in OT cyber threats?

Evolving Attack Landscapes: Cyberattacks targeting OT systems are growing in frequency and sophistication. In 2023, there was a 46% increase in cyber-extortion and ransomware attacks, with manufacturing being the top targeted industry (20%) due to the high stakes involved.

Manufacturing companies are a favorite target because they have production plants and facilities that create a rich attack surface. Manufacturers are also known for paying up when attacked because they simply can’t afford the downtime and disruption, that is, if the OT network can even be reliably reconstituted. (Source)

Convergence of IT and OT: The integration of IT and OT systems, referred to as IT/OT convergence, has expanded the attack surface. Most modern OT devices require ‘phone home’ access to vendor cloud services and usually transit enterprise IT networks for that connectivity. Malicious actors exploit the complications arising from this overlap, leading to risks that can halt production and result in catastrophic incidents.

This trend suggests that organizations that adopt a converged cybersecurity strategy (like that described in this article) by integrating Microsoft Sentinel with Microsoft Defender for IoT, will enjoy a competitive advantage. Thus equipped, organizations will have decreased risk exposure and increased multistage incident investigation workflow and automation capabilities.

Tip: Customers report that beyond the security protections provided by Defender for IoT, there are unexpected management benefits to the solution. In particular, insight is gained into what is really happening in the OT network plant, such as new device discovery and the mapping of network connections made by OT devices.

Microsoft Defender for IoT and Microsoft Sentinel/Defender XDR: Way better together

I have written about Microsoft Sentinel many times in my blog, and I’m quite confident in the complete Microsoft security stack—with the pillars of Microsoft Sentinel, Microsoft Defender XDR, and Microsoft Defender for Cloud. Without reservation I believe it is the single best investment an organization can make to protect itself.

Now joining that short list is Microsoft Defender for IoT, a hero in the Microsoft security toolkit that serves the needs of industrial networking equipment owners worldwide. The most targeted industries are (in descending order) Utilities, Manufacturing, Oil & Gas, Financial services, Government, and Healthcare (Source).

Microsoft has elevated and projected a bespoke OT security solution into a comprehensive cybersecurity ecosystem that is proven at hyperscale.

Figure 1 illustrates the main topic of this article. On the left are the Defender for IoT solution components and, connected at the upper right via Microsoft Sentinel/Microsoft Defender XDR, the cloud-native functions that extend and multiply the capabilities of Defender for IoT alone.

Figure 1 – Microsoft Azure and Defender apps and services that comprise the complete Microsoft security stack for OT security.

Note: The topic of this article is Microsoft’s OT / Industrial Control security solution known as “Defender for IoT”. There is an adjacent Microsoft offering, “Enterprise IoT (eIoT)” with focus on printers, scanners, cameras, Smart TVs, VoIP phones, and other purpose-built devices encountered in enterprise networks. This article does not cover the eIoT product whatsoever.

When to use the local sensor and Azure Defender for IoT portals

You have a choice of how to manage and administer your Defender for IoT deployment. Administration of sensors is split between the sensors’ local web portals and the Azure portal Defender for IoT page. Incident management is best handled mainly by Microsoft Sentinel.

Using local and web login to the Sensor only

The most basic mode of administering Defender for IoT is to use only the built-in web interface on each Defender for IoT sensor, either a hardware device or a virtual (VM) device. The sensor must have connectivity to Azure to operate, but it is not mandatory to use the Azure portal to administer a single Defender for IoT sensor.

This is not always the most satisfying way to use the product, even if you have only a single sensor. For example, the alerting and reporting capabilities of the sensor interface are very limited compared to those available in the Azure portal. Here are the tasks best suited to be run locally on the sensor:

• View everything the sensor sees in the Event timeline: All activity detected on the network wire by your Microsoft Defender for IoT sensors is recorded in the event timeline.
• Generate a comprehensive Risk Assessment report: After enriching the risk assessment report with your sensor’s backup and inbound edge firewall information, attractive downable PDF reports can be generated suitable to provide to auditors and stakeholders.
• Interact with the Device Map experience: OT device maps provide a graphic representation of the network devices detected by the OT network sensor and the connections between them. Figure 2 is an example of the device map filtered for a specific OT protocol:

Figure 2 – Defender for IoT Device map in the web interface of an individual sensor, filtered to Rockwell OT protocols.

Tip: During the sensor deployment process, you may need to logon locally to the sensor device for these reasons:

• Assign an IP address during Initial sensor installation and boot-up if you are not using the default address of the sensor.
• Setting the time manually in the Debian Linux OS of the sensor. When applying a sensor configuration from an engineering workstation, via the sensor’s web interface and the sensor activation file downloaded from the Azure portal—this requires a strict time sync.

Using Defender for IoT in the Azure portal

Defender for IoT sensors require outbound connection to the Azure portal, so there will always be Azure portal resources available for Defender for IoT deployments. For anyone with more than a single sensor, and for anyone wanting to take advantage of the of the additional management features available only in the Azure portal, it’s a ‘no-brainer’ to leverage the cloud for sensor administration in addition to the local device web interface(s).

This article previously explained why some tasks are best run on the local sensor device; then next we will cover using Microsoft Sentinel in the Azure portal for Defender for IoT incident management, automation, and visualization activities. That leaves us with this list of tasks best suited to be run in the Azure portal -> Defender for IoT space:

• Alert review for possible promotion to Analytic Rule (or Custom Detection) in Microsoft Sentinel/Defender XDR.
  • Microsoft Sentinel initially includes about fifteen (15) specific Defender for IoT detections which are most significant to OT security teams.
  • It is not the design that every possible Defender for IoT alert will generate a Microsoft Sentinel incident, rather only those Defender for IoT alerts of actionable security relevance that have matching Microsoft Sentinel Analytics rules will generate incidents.
  • This reduces noise and alert fatigue by OT administrators.
  • Periodically review the ‘raw’ alerts stream in Defender for IOT to possibly select notable alerts for promotion to Analytics rules or Custom detections.
  • Later in this article, in the section “Investigate and detect threats for IoT devices” learn a quick way to create new Azure Monitor alert rule or Microsoft Sentinel analytics rule from the raw Defender for IoT alert stream without leaving the Microsoft Sentinel console.
• Alert suppression rules: While it is recommended to use Microsoft Sentinel for OT incident management, Defender for IoT alert suppression rules are best created in the Defender for IoT Alerts space.
• Recommendations: Microsoft Defender for IoT’s security recommendations summarize network security posture across unhealthy devices in your network.
• Workbooks: Azure Monitor workbooks provide graphs, charts, and dashboards that visually reflect data in Microsoft Defender for IoT. (In addition to a primary Defender for IoT workbook resource in Microsoft Sentinel.)
• Firmware analysis: Upload OT device firmware images for analysis to identify embedded security threats, vulnerabilities, and common weaknesses that may be otherwise undetectable.
• Sites and sensors management: This is where you create Defender for IoT sites, generate activation files for sensors, view overall sensor status at all sites, as well as push out standardized sensor configuration settings.
• Device inventory: Everything related to details about discovered devices, such as manufacturer, type, serial number, firmware, and more. Device details can be edited here, as demonstrated in Figure 3.

Figure 3 – Device inventory in Defender for IoT console (Azure portal) allows for modification of any discovered device properties.

Integrate Defender for IoT with Microsoft Sentinel

Essentially, integrating Microsoft Defender for IoT with Microsoft Sentinel/Microsoft Defender XDR enhances security operations by providing comprehensive visibility, improving threat detection, automating responses, and extending incident management across IT and IoT environments, thus achieving optimal IT-OT convergence.

Specific step-by-step instruction for using the integration features are here: https://learn.microsoft.com/en-us/azure/defender-for-iot/organizations/iot-advanced-threat-monitoring

The rest of this article will explain the integration and provide use cases for all the added features and capabilities you achieve with using Microsoft Sentinel as your primary IoT incident investigation space. Refer again to the lower right portion of the diagram in Figure 1 which visualizes the value add of the integration.

Connect Microsoft Defender for IoT with Microsoft Sentinel

When you connect Microsoft Defender for IoT to Microsoft Sentinel, you ‘snap into’ a sophisticated and mature cybersecurity incident management plane. Incident investigation features added above and beyond what’s available in Defender for IoT alerts alone include: incident tags, incident comments, pre- and post-incident enrichment, graphic dynamic investigation spaces, analytic rules (custom detections), automation rules, playbooks (Logic apps) and a bespoke workbook.

Install the Microsoft Defender for IoT solution

After installing the Defender for IoT solution from the Microsoft Sentinel Content hub, the following content is available to install into the specific Microsoft Sentinel instance (seen in Figure 5):

• 1 Data connector
• 15 Analytic rules
• 1 Workbook
• 7 Playbooks (Logic apps)

Figure 4 – Managing the Microsoft Defender for IoT solution from the Microsoft Sentinel Content hub.

1. Begin with installing the Data connector. Authorizing the connection requires that the user logged into the Azure portal is a Security Administrator or Owner of the Entra ID tenant associated with the Azure subscription.
2. Next enable all the Analytic rules except for ‘Create incidents based on all alerts generated in Microsoft Defender for IOT’. Enabling that rule will cause duplicate incidents to be created for all the alerts that Microsoft Sentinel Analytics rules were pre-created for.
3. Always install the ‘Microsoft Defender for IoT’ workbook by saving it to your subscription.
   • Open the saved workbook, select the Subscription and Workspace information, then save the workbook.
   • Push the Share button in the workbook ribbon to generate a unique URL to share with teammates.
4. Of the seven (7) available playbooks, I recommend install these three (3) for evaluation purposes:
   1. AD4IoT-AutoAlertStatusSync
   2. AD4IoT-AutoTriageIncident
   3. AD4IoT-AutoCloseIncidents

Investigate and detect threats for IoT devices

Microsoft Sentinel detects threats out-of-the-box with Defender for IoT data using Analytic rules. The packaged analytic rules contained in the Microsoft Sentinel Content hub Defender for IoT solution (seen in Figure 5) cover all critical security situations and are a great starting point for detection of threats. Over time, you may elect to add additional Analytic rules based on what Defender for IoT events you are seeing in your environment.

Figure 5 – Microsoft Sentinel Analytic rules from the Content Hub – Defender for IoT solution.

Augmenting your Active Analytic rules

As previously mentioned, a periodic review of the raw Defender for IoT alert stream in the Defender for IoT pages of the Azure portal may reveal some alerts that the OT security team wants to create Microsoft Sentinel incidents for.

• Alerts selected for Analytics rule creation should be of a priority that warrants beginning immediate investigation by security team members.
• Examples of lower-priority Defender for IoT alerts that don’t have Out-of-the-box corresponding Analytics rules are ‘EtherNet/IP CIP Service Request Failed’, ‘Controller Stop’, and ‘Device is Suspected to be Disconnected (Unresponsive)’.

A more efficient way to review the raw Defender for IoT alert history for possible new Analytics rules may be to run this KQL query in the Log viewer of Microsoft Sentinel:

SecurityAlert
| where ProviderName == "IoTSecurity"

As seen in Figure 6, this query will return all Defender for IoT alerts, including those for which there are no pre-existing Microsoft Sentinel Analytic rules. The advantage of viewing raw alerts in this fashion is that promotion of selected Defender for IoT alerts to Azure Monitor alerts or Microsoft Sentinel Analytic rules is assisted and accelerated.

Figure 6 – Selecting a Defender for IoT alert from which to create an Azure Monitor alert or a Microsoft Sentinel analytic rule.

If you identify a Defender for IoT alert in this list that you want to create an corresponding active alerting artifact for:

1. Select the Defender for IoT alert in the Results list (‘EtherNet/IP CIP Service Request Failed’ in this example).
2. Push the three dots “ellipse” button in the upper right of the Log viewer and select New alert rule.
3. Then select either Create Azure Monitor alert or Create Microsoft Sentinel alert as desired.

Tip: Consider creating Azure Monitor alert rules that email or otherwise directly notify cognizant staff when low priority OT events are received, leaving Microsoft Sentinel Analytic rules that create security incidents exclusively for actionable, relevant, and urgent OT security events.

Investigate Defender for IoT incidents

The main reason to perform the Defender for IoT to Microsoft Sentinel integration is for the superior incident handling capabilities of Microsoft Sentinel. From the moment a Microsoft Sentinel incident is created, automation rules go to work pre-investigating the incident to possibly auto-close the incident, add incident tags (see Figure 7), change incident priority, pre-assign incident responsibility to specific teams or individuals, or enrich the incident comment history with date useful for incident triage.

Figure 7 – Defender for IoT alerts in the Microsoft Sentinel incidents view, ready to investigate.

Upon opening an incident in the Sentinel console, an OT admin or OT SOC operator has a rich palate of investigative tools and techniques available to rapidly assess the true security significance of the suspicious and/or anomalous activity that the incident was generated from.

Incident tags are your friend

Incident tags, either added by automation or manually by analysts, are both easy to spot and easy to read in the console, conveying meaning to subsequent viewers of the incident. Tags are also very important as they provide a means for automation rules to pass information to one another for distributed, modular incident post-processing. An example workflow:

1. Lower numbered Automation rules examine incident content and assign tags as appropriate.
2. Higher numbered rules fire given the presence of certain tags, launching incident enrichment queries that pre-fetch data and append to the incident comment history.
3. Highest numbered rule either creates an incident ticket in the ITSM system or automatically closes the incident based on the tags and enrichment data.

The Microsoft Sentinel incident Investigation space

Figure 8 demonstrates the usefulness of the Microsoft Sentinel graphical incident investigation space. Right-clicking on objects in the display field cause context-sensitive floating dialog boxes to appear, pre-configured with logical ‘next-query’ options, like ‘Show related alerts’.

Figure 8 – Investigation of a Defender for IoT incident in Microsoft Sentinel reveals alerts correlated across incidents.

When related entities, incidents, and alerts are discovered, they are added to the display with dynamic connectors to the related elements. This capability exploits the human operator’s ability to use his or her vision to detect patterns and relationships more rapidly than reading charts or lists.

Visualize and monitor Defender for IoT data (Workbooks)

While very useful visualization tools (workbooks and dashboards) exist in both the local sensor web interface and the Defender for IoT page in the Azure portal, your best Microsoft Defender for IoT workbook is found in Microsoft Sentinel. Figure 9 shows the top frame of the workbook, with the primary workbook tabs highlighted.

Figure 9 – Navigate the various tabs of the Microsoft Defender for IoT workbook in Microsoft Sentinel.

Each of these tabs is an immediate deep dive into the most valuable features of the solution.

Overview

Starting with the Overview tab, seen below in Figure 10. The Overview tab cleanly illustrates your OT estate security health in the primary dimensions of Devices, Incidents, and Vulnerabilities (CVEs).

Figure 10 – The Overview tab of the Microsoft Sentinel workbook for Defender for IoT.

Device Inventory

The main feature of the Device Inventory tab of the workbook (see Figure 11) is a sortable, searchable, filterable list of all OT discovered devices and computers with immediate drill down into CVEs and security recommendations that exist for any selected device. Other charts summarize active devices by Purdue level, Protocol, and Vendor.

Figure 11 – The Device Inventory tab of the Microsoft Sentinel workbook for Defender for IoT.

MITRE ATT&CK for ICS

The MITRE ATT&CK for ICS tab grounds the findings in your environment to their corresponding ICS tactics classification. Tactics represent the “why” of an ATT&CK technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. For more information on the MITRE ATT&CK matrix for ICS networks, see https://attack.mitre.org/tactics/ics/.

Figure 12 – The MITRE ATT&CK for ICS tab of the Microsoft Sentinel workbook for Defender for IoT.

To see which devices in your environment are included in the non-zero devices count (where the tactic banner is red):

1. Click on the little Log analytics icon above the tactic of interest. This will open the query in the log viewer.
2. Delete the last two lines of the KQL query, which will look similar to this:

| summarize count()
| extend Link = strcat("https://collaborate.mitre.org/attackics/index.php/<tactic>")

1. Change the Time Range from Custom to last 7 days.
2. Push the Run button and observe the corresponding results.

Vulnerabilities

The Vulnerabilities tab of the workbook provides your team with quick definitive answers on what devices and components are vulnerable to threats defined via CVEs. Figure 13 illustrates these three (3) analysis tiers:

• CVEs: Select a CVE, see the list of Affected devices
• Vulnerable Devices: Select a device, see the list related CVEs
• Vulnerable Components: Select a component, see the list of Affected devices.

Figure 13 – The Vulnerabilities tab of the Microsoft Sentinel workbook for Defender for IoT.

Tip: This data is highly exchangeable with other threat management applications via REST API query of Azure Resource Graph (ARG) data. See the section “Additional reading” at the end of this article for more information.

Automate response to Defender for IoT alerts

To get you started with Automation in your Defender for IoT deployment, there are several Playbooks provided, which are Azure Logic apps, that with minimal configuration provide valuable services. Figure 14 shows three (3) selected Defender for IoT playbooks staged to be run by Automation rules Order 101, 102, and 103.

Figure 14 – Automation rules for Defender for IoT incidents in Microsoft Sentinel.

Those three (3) playbooks and how to use them are detailed here:

AD4IoT-AutoAlertStatusSync: This playbook updates alert statuses in Defender for IoT whenever a related alert in Microsoft Sentinel has a Status update. This playbook is invoked automatically every time a Microsoft Sentinel incident status is changed, such as from “New” to “Active” or “Closed”. (Automation rule 101)

AD4IoT-AutoTriageIncident: SOC and OT engineers can stream their workflows using the playbook, which automatically updates the incident status, severity and/or tags based on the devices involved in the incident and their importance.

• This playbook updates the incident to include the tag “High Importance Device Auto Update” when the incident includes an entity of the “OT Device” type.
• This is a starter/demonstration incident enrichment automation. By default, the playbook also changes the incident status to “Active” and changes the incident severity to “High”, although in production I recommend you disable those two actions, leaving just the tagging.
• This playbook is invoked automatically every time a Microsoft Sentinel incident is created. (Automation rule 102)

AD4IoT-AutoCloseIncidents: Maintenance activities such as updating firmware and restarting devices generate alerts in Microsoft Sentinel which distracts the SOC team from handling the real problems. This playbook allows to input the time period in which the maintenance is expected and the asset(s’) IP(s). The playbook requires a watchlist which includes all the IP addresses of the assets on which alerts will handled automatically. This playbook parses explicitly the IoT device entity fields. For more information on creating the watchlist, see https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/AD4IoT-AutoCloseIncidents.

Follow these steps to use:

1. Update the IP address entries in the watchlist “IoT Maintenance Window IP Addresses” to include the devices undergoing maintenance.
2. Enable the Automation Rule “Defender for IoT auto close incidents (maintenance window)” (Automation rule 103) and change the Rule expiration date/time to coincide with the end of upcoming the maintenance period.
3. This playbook is invoked automatically every time a Microsoft Sentinel incident is created until the expiration date/time is reached.
4. If the incident(s) contain only IPs that match entries in the watchlist, the incidents will be automatically closed.
5. Disable the Automation Rule after its use for a specific maintenance period.

Watchlists

Figure 15 illustrates another feature-add of Microsoft Sentinel to Defender for IoT, which is the Watchlist: an ad-hoc collection of entities using by playbooks during automated alert investigation and enrichment. You will pre-create this watchlist and populate it with the IP addresses of devices to have all alerts automatically closed during a maintenance window by the Auto close incident playbook.

Figure 15 – The Watchlist used by the Auto close incidents playbook.

Tip: Watchlists can be populated by importing a CSV file. This supports a scenario where automation always checks a watchlist with a certain name, but the actual watchlist is dynamically created from in input file that may contain thousands of entities, then zeroed out after maintenance is completed.

Migration to the Defender portal

This article focuses on using Microsoft Defender for IoT with Microsoft Sentinel in the Azure portal (portal.azure.com), which is the ‘classic’ experience with years of production wins for customers. Microsoft started last year to transition Microsoft Sentinel and Microsoft Defender for IoT to the Defender portal (security.microsoft.com) to further unify all Microsoft security pillars into a ‘single portal’ user experience.

We can expect that in the coming year, more and more Microsoft Sentinel and Microsoft Defender for IoT functions will migrate to the Defender portal—until there is no need to use the previous Azure portal experience for either product. The good news is that there is no lost investment no matter where you start on the Azure portal-to-Defender portal journey. To learn more, consult these links:

• Microsoft Sentinel in the Microsoft Defender portal
• What is Microsoft Defender for IoT in the Defender portal (Preview)?

Additional reading

Something worthy of pointing out from the diagram in Figure 1 is the “API Connections” item. This represents your capability, once you start leveraging the Microsoft cloud for OT and IT security, to exploit the hyper-scale economic efficiencies of that cloud. This is a strategic opportunity to gain competitive advantage in any industry.

These efficiencies include the full open-source disclosure of the Azure and Defender API schemas and robust ways to interact with the solution: Azure portal, Azure CLI, Azure PowerShell, Azure Cloud shell, and Azure API. Third-party and proprietary security applications can and do utilize Azure REST API commands to push and pull data easily and at will for an infinite variety of applications.

Figure 16 transparently discloses the raw data for a Defender for IoT alert (“Excessive Login Attempts”) as it is stored in the Azure Resource Graph (ARG), ready to be queried by any system via Azure API.

Figure 16 – A Defender for IoT alert of Excessive Login Attempts as viewed in the Azure Resource Graph.

#MVPBuzz #DefenderForIoT #OTSecurity #ICSSecurity #IoT #MicrosoftSentinel #SIEM #CloudSecurity #DefenderXDR