System architecture for OT system monitoring

The Microsoft Defender for IoT system is built to provide broad coverage and visibility from diverse data sources.

The following image shows how data can stream into Defender for IoT from network sensors and partner sources to provide a unified view of IoT/OT security. Defender for IoT in the Azure portal provides asset inventories, vulnerability assessments, and continuous threat monitoring.

Diagram of the Defender for IoT OT system architecture.

Defender for IoT connects to both cloud and on-premises components, and is built for scalability in large and geographically distributed environments.

Defender for IoT systems include the following components:

  • The Azure portal, for cloud management and integration to other Microsoft services, such as Microsoft Sentinel.
  • Network sensors, deployed on either a virtual machine or a physical appliance. You can configure your OT sensors as cloud-connected sensors, or fully on-premises sensors.
  • An on-premises management console for cloud-connected or local, air-gapped site management.
  • An embedded security agent (optional).

OT network sensors

OT network sensors discover and continuously monitor network traffic across your OT devices.

  • Network sensors are purpose-built for OT networks. They connect to a SPAN port or network TAP and can provide visibility into risks within minutes of connecting to the network.

  • Network sensors use OT-aware analytics engines and Layer-6 Deep Packet Inspection (DPI) to detect threats, such as fileless malware, based on anomalous or unauthorized activity.

Data collection, processing, analysis, and alerting takes place directly on the sensor. Running processes directly on the sensor can be ideal for locations with low bandwidth or high-latency connectivity because only the metadata is transferred on for management, either to the Azure portal or an on-premises management console.

Cloud-connected vs. local sensors

Cloud-connected sensors are sensors that are connected to Defender for IoT in Azure, and differ from locally managed sensors as follows:

When you have a cloud connected sensor:

  • All data that the sensor detects is displayed in the sensor console, but alert information is also delivered to Azure, where it can be analyzed and shared with other Azure services.

  • Microsoft threat intelligence packages can be automatically pushed to cloud-connected sensors.

  • The sensor name defined during onboarding is the name displayed in the sensor, and is read-only from the sensor console.

In contrast, when working with locally managed sensors:

  • View any data for a specific sensor from the sensor console. For a unified view of all information detected by several sensors, use an on-premises management console. For more information, see Manage sensors from the management console.

  • You must manually upload any threat intelligence packages to locally managed sensors.

  • Sensor names can be updated in the sensor console.

What is a Defender for IoT committed device?

Defender for IoT can discover all devices, of all types, across all environments. Devices are listed in the Defender for IoT Device inventory pages based on a unique IP and MAC address coupling.

Defender for IoT identifies single and unique committed devices as follows:

Committed / Not committed Description
Committed devices Committed devices include:
IT, OT, or IoT devices with one or more NICs, including network infrastructure devices such as switches and routers

Note: A device with modules or backplane components, such as racks or slots, is counted as a single device, including all modules or backplane components.
Not committed devices The following items aren't considered as committed devices:
Public internet IP addresses
Multi-cast groups
Broadcast groups
Inactive devices

Network-monitored devices are marked as inactive when there's no network activity detected within a specified time:
- OT networks: No network activity detected for more than 60 days
- Enterprise IoT networks: No network activity detected for more than 30 days

Microsoft Defender for Endpoint (For customers with Microsoft Defender for Endpoint Plan 2): For subscriptions onboarded for Enterprise IoT networks, endpoints already managed by Defender for Endpoint are not considered committed devices.

Analytics engines

Defender for IoT sensors apply analytics engines on ingested data, triggering alerts based on both real-time and pre-recorded traffic.

Analytics engines provide machine learning and profile analytics, risk analysis, a device database and set of insights, threat intelligence, and behavioral analytics.

For example, the policy violation detection engine alerts users of any deviation from baseline behavior, such as unauthorized use of specific function codes, access to specific objects, or changes to device configuration. The policy violation engine models industry control system (ICS) networks as deterministic sequences of states and transitions - using a patented technique called Industrial Finite State Modeling (IFSM). The policy violation detection engine creates a baseline for industrial control system (ICS) networks. Since many detection algorithms were built for IT, rather than OT, networks, an extra baseline for ICS networks helps to shorten the systems learning curve for new detections.

OT network sensors include the following analytics engines:

  • Protocol violation detection engine: Identifies the use of packet structures and field values that violate ICS protocol specifications, for example: Modbus exception, and initiation of an obsolete function code alerts.

  • Industrial malware detection engine: Identifies behaviors that indicate the presence of known malware, such as Conficker, Black Energy, Havex, WannaCry, NotPetya, and Triton.

  • Anomaly detection engine: Detects unusual machine-to-machine (M2M) communications and behaviors. By modeling ICS networks as deterministic sequences of states and transitions, the platform requires a shorter learning period than generic mathematical approaches or analytics originally developed for IT rather than OT. It also detects anomalies faster, with minimal false positives. Anomaly detection engine alerts include Excessive SMB sign-in attempts, and PLC Scan Detected alerts.

  • Operational incident detection: Detects operational issues such as intermittent connectivity that can indicate early signs of equipment failure. For example, the device might be disconnected (unresponsive), and Siemens S7 stop PLC command was sent alerts.

Management options

Defender for IoT provides hybrid network support using the following management options:

  • The Azure portal. Use the Azure portal as a single pane of glass to view all data ingested from your devices via network sensors. The Azure portal provides extra value, such as workbooks, connections to Microsoft Sentinel, and more.

    Also use the Azure portal to obtain new appliances and software updates, onboard and maintain your sensors in Defender for IoT, and update threat intelligence packages.

    Screenshot of the Defender for I O T default view on the Azure portal.

  • The sensor console. You can also view detections for devices connected to a specific sensor from the sensor's console. Use the sensor console to view a network map, an extensive range of reports, forward information to partner systems, and more.

    Screenshot that shows the updated interface.

  • The on-premises management console. In air-gapped environments, you can get a central view of data from all of your sensors from an on-premises management console. The on-premises management console also provides extra maintenance tools and reporting features.

Next steps

For OT environments, understand the supported methods for connecting network sensors to Defender for IoT.

For more information, see: