Microsoft Defender for IoT — OT Protocols, DPI & Alert Tuning

① Why OT protocol DPI is not optional

When a Modbus TCP packet arrives at your historian, the TCP header tells you it came from a Rockwell PLC on port 502 — but it tells you nothing about whether the packet is reading a temperature sensor or writing the setpoint of a reactor. Deep packet inspection (DPI) at the application layer is what extracts that meaning. Microsoft Defender for IoT's OT sensor receives a mirror of all OT traffic via a SPAN/TAP and parses each packet to the protocol level.

The parsed fields feed Defender for IoT's five detection engines: the Protocol Violation engine flags packets that deviate from the protocol specification; the Policy Violation engine flags forbidden function codes or addresses; the Anomaly engine detects deviations from the learned baseline; the Malware engine matches industrial malware signatures; and the Operational engine catches operational issues such as unexpected reboots or firmware changes. Without DPI to extract those fields, all five engines would be blind to the actual OT commands being issued.

② The OT protocol library — from Modbus to IEC 61850

Defender for IoT natively parses over 100 OT/ICS protocols. The most interview-critical ones: Modbus TCP/UDP (function codes, coil/register read/write — the most widely deployed fieldbus); DNP3 (data objects, integrity polls, unsolicited responses — dominant in energy/SCADA); Siemens S7/S7Plus (read/write parameters, system info for S7-300 to S7-1500 PLCs); EtherNet/IP (CIP) (CIP services, identity, I/O connections — Allen-Bradley/Rockwell); BACnet (object reads/writes, device discovery — building automation/HVAC); OPC DA & OPC UA (session setup, node reads/writes, subscriptions — historian connectivity); IEC 60870-5-104 (ASDU types, cause of transmission — substation SCADA, very common in Indian power utilities); IEC 61850 MMS/GOOSE (virtual file system, protection relay messaging — modern substations); and Profinet (DCP device discovery, cyclic IO, alarms — Siemens factory automation).

Extending the library with the Horizon SDK

For proprietary or niche vendor protocols not in the built-in library, the Horizon open development environment (ODE) SDK lets vendors, integrators or customers write sandboxed protocol dissectors and deploy them to the sensor without interrupting traffic capture. A Horizon plugin defines how to identify the protocol, which fields to extract, and what alert conditions apply — giving the same DPI depth as a built-in protocol.

③ Learning mode — building the baseline that makes alerts meaningful

On first deployment the OT sensor enters Learning mode (also called the learning period or training period). During this phase it observes all traffic passively and builds a baseline capturing: which devices communicate with which (communication pairs); which protocols and function codes are in use; normal traffic volumes and timing; and expected parameter ranges (e.g., the Modbus register addresses a given PLC normally reads). No anomaly alerts are raised during learning mode — the sensor is only accumulating knowledge.

Once traffic patterns have stabilised — typically after several days to a couple of weeks, depending on how long it takes the plant's process cycle to repeat — the sensor transitions to Operational mode. From this point, deviations from the baseline trigger alerts. A Modbus write to a register that was never written during the learning period, a new device appearing on the network, or a DNP3 session at 10× normal rate will all surface as alerts. The length and cleanliness of the learning period directly determines alert quality: a baseline contaminated by commissioning activity or a scheduled outage will produce false positives in production.

④ Tuning alerts so the SOC stays sane

Even with a clean baseline, production OT environments generate alert noise that needs active management. Defender for IoT provides several tuning levers. Exclusion rules whitelist specific communication pairs, function codes or address ranges that are known-benign in your environment. Custom alert rules let operators define conditions based on protocol fields (e.g., 'alert if any device issues a Modbus write to coil 0x00FF outside business hours'). Acknowledgement and suppression removes known-benign alerts from the queue while preserving the audit trail.

Sites and zones enable policy scoping: a firmware-upload function code that is normal in the engineering workstation zone can be a Policy Violation alert in a Level 0 field device zone. This per-zone granularity eliminates the all-or-nothing problem that plagues flat alert policies. Finally, the Microsoft Sentinel integration via the native data connector enables SOAR playbooks to auto-enrich OT alerts with IT context (is this source IP a known maintenance laptop?), auto-suppress confirmed benign patterns, and route high-severity OT incidents to the IT SOC in the same queue as IT alerts — closing the loop between OT visibility and SOC response.