defender-for-iot

Name: defender-for-iot
Author: vinayaklatthe

161stars34forks

How to install defender-for-iot?

vinayaklatthe/microsoft-security-skills/defender-for-iot

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill defender-for-iot

Installs into the current project.

Summary

Guidance for Microsoft Defender for IoT — agentless OT/ICS network detection and response for industrial environments, plus enterprise IoT (EIoT) protection integrated with Defender XDR. Covers OT sensor deployment (physical/virtual, SPAN/TAP), Purdue model alignment, on-premises

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Defender for IoT
2
3	Defender for IoT delivers agentless network detection and response for two distinct
4	estates that legacy endpoint tools miss:
5
6	- OT / ICS (operational technology, SCADA, PLCs, industrial networks).
7	- Enterprise IoT (EIoT) — printers, cameras, VoIP phones, smart-building devices on the
8	corporate network — discovered and protected via the Microsoft Defender for Endpoint
9	sensor and surfaced in Defender XDR.
10
11	## When to use
12	Securing factory, utility, healthcare, or building-automation networks; or extending
13	visibility to unmanaged "things" on the enterprise LAN that cannot run an endpoint agent.
14
15	Do not use this skill for IoT Hub / IoT Central data-plane security, Azure Sphere
16	firmware design, or workstation/server EDR (`defender-for-endpoint`).
17
18	## OT vs Enterprise IoT — pick the right path
19
20	\| Estate \| Path \| Sensor \|
21	\|---\|---\|---\|
22	\| Plant networks, ICS, SCADA, PLCs (Levels 0–3 Purdue) \| Defender for IoT — OT \| Dedicated OT network sensor (physical or virtual VM) attached to SPAN/TAP \|
23	\| Corporate LAN unmanaged devices (printers, cameras, VoIP) \| Defender for IoT — EIoT \| Existing MDE sensors on Windows endpoints; no separate appliance \|
24
25	> Rule of thumb: if it speaks Modbus / DNP3 / S7 / EtherNet/IP, you need an OT sensor.
26	> If it's an IP camera on the office VLAN, EIoT via MDE is enough.
27
28	## Approach
29
30	### OT estate
31
32	1. Network mapping by Purdue level first. Identify Level 0/1 (controllers, sensors),
33	Level 2 (SCADA HMI), Level 3 (operations management). Sensors monitor traffic between
34	levels and east-west within Level 2/3.
35
36	2. Pick sensor placement. One sensor per OT site, attached to a SPAN port that mirrors
37	the core OT switch. Aggregate multi-site sensors into a cloud-connected model
38	(preferred for new deployments) or the legacy on-prem management console (for
39	air-gapped sites).
40
41	3. Deploy passively. OT sensors are fully passive — no probing, no active scans.
42	This is non-negotiable in safety-critical environments. Confirm with plant ops before
43	any port turn-up.
44
45	4. Build the asset inventory. Within 14 days the sensor builds a baseline of devices,
46	firmware versions, and protocol relationships. Validate the baseline with the OT team
47	before enabling alerting.
48
49	5. Enable alerts. Categories: malware, network anomalies, protocol violations,
50	operational (e.g. unauthorized PLC programming change). Tune to plant context — many
51	"anomalies" are legitimate maintenance windows.
52
53	6. Stream to Sentinel. Use the Defender for IoT data connector. Build OT-specific
54	workbooks and playbooks (e.g., auto-ticket on unauthorized PLC reprogram).
55
56	7. Vulnerability program. Sensor identifies device firmware → matched to known CVEs.
57	Do not push patches via the same channel as IT — coordinate with OT change windows.
58
59	### Enterprise IoT estate
60
61	1. Already have MDE deployed? EIoT is a license toggle on top of MDE — enable in
62	Defender XDR settings. Devices on the LAN segment seen by an MDE-enrolled endpoint get
63	discovered.
64	2. Review the device inventory in security.microsoft.com → Assets → Devices, filtered
65	to Device type = IoT.
66	3. Group and tag by function (printers, cameras, VoIP, building automation). Apply
67	network access policies (NAC / NSG / firewall) per group.
68	4. Vulnerability findings + threat alerts flow into Defender XDR alongside endpoint
69	detections.
70
71	## Guardrails
72	- OT sensors must be passive. Never enable active probing in production OT — risk of
73	PLC reset / safety-system trip.
74	- Coordinate with OT operations before any deployment change. Changes to switches,
75	VLANs, or SPAN configuration require an OT change window.
76	- Don't ship OT alerts straight to the IT SOC without context. OT analysts and IT
77	analysts triage differently. Either build OT-aware playbooks or route to an OT SOC.
78	- **EIoT requires MDE on at least one endpoint per network

People who liked this also viewed

6 picks

Type

defender-for-iot

161stars34forks

View on GitHub

How to install defender-for-iot?

vinayaklatthe/microsoft-security-skills/defender-for-iot

$npx -y skills add vinayaklatthe/microsoft-security-skills --skill defender-for-iot

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microsoft Defender for IoT
2
3	Defender for IoT delivers agentless network detection and response for two distinct
4	estates that legacy endpoint tools miss:
5
6	- OT / ICS (operational technology, SCADA, PLCs, industrial networks).
7	- Enterprise IoT (EIoT) — printers, cameras, VoIP phones, smart-building devices on the
8	corporate network — discovered and protected via the Microsoft Defender for Endpoint
9	sensor and surfaced in Defender XDR.
10
11	## When to use
12	Securing factory, utility, healthcare, or building-automation networks; or extending
13	visibility to unmanaged "things" on the enterprise LAN that cannot run an endpoint agent.
14
15	Do not use this skill for IoT Hub / IoT Central data-plane security, Azure Sphere
16	firmware design, or workstation/server EDR (`defender-for-endpoint`).
17
18	## OT vs Enterprise IoT — pick the right path
19
20	\| Estate \| Path \| Sensor \|
21	\|---\|---\|---\|
22	\| Plant networks, ICS, SCADA, PLCs (Levels 0–3 Purdue) \| Defender for IoT — OT \| Dedicated OT network sensor (physical or virtual VM) attached to SPAN/TAP \|
23	\| Corporate LAN unmanaged devices (printers, cameras, VoIP) \| Defender for IoT — EIoT \| Existing MDE sensors on Windows endpoints; no separate appliance \|
24
25	> Rule of thumb: if it speaks Modbus / DNP3 / S7 / EtherNet/IP, you need an OT sensor.
26	> If it's an IP camera on the office VLAN, EIoT via MDE is enough.
27
28	## Approach
29
30	### OT estate
31
32	1. Network mapping by Purdue level first. Identify Level 0/1 (controllers, sensors),
33	Level 2 (SCADA HMI), Level 3 (operations management). Sensors monitor traffic between
34	levels and east-west within Level 2/3.
35
36	2. Pick sensor placement. One sensor per OT site, attached to a SPAN port that mirrors
37	the core OT switch. Aggregate multi-site sensors into a cloud-connected model
38	(preferred for new deployments) or the legacy on-prem management console (for
39	air-gapped sites).
40
41	3. Deploy passively. OT sensors are fully passive — no probing, no active scans.
42	This is non-negotiable in safety-critical environments. Confirm with plant ops before
43	any port turn-up.
44
45	4. Build the asset inventory. Within 14 days the sensor builds a baseline of devices,
46	firmware versions, and protocol relationships. Validate the baseline with the OT team
47	before enabling alerting.
48
49	5. Enable alerts. Categories: malware, network anomalies, protocol violations,
50	operational (e.g. unauthorized PLC programming change). Tune to plant context — many
51	"anomalies" are legitimate maintenance windows.
52
53	6. Stream to Sentinel. Use the Defender for IoT data connector. Build OT-specific
54	workbooks and playbooks (e.g., auto-ticket on unauthorized PLC reprogram).
55
56	7. Vulnerability program. Sensor identifies device firmware → matched to known CVEs.
57	Do not push patches via the same channel as IT — coordinate with OT change windows.
58
59	### Enterprise IoT estate
60
61	1. Already have MDE deployed? EIoT is a license toggle on top of MDE — enable in
62	Defender XDR settings. Devices on the LAN segment seen by an MDE-enrolled endpoint get
63	discovered.
64	2. Review the device inventory in security.microsoft.com → Assets → Devices, filtered
65	to Device type = IoT.
66	3. Group and tag by function (printers, cameras, VoIP, building automation). Apply
67	network access policies (NAC / NSG / firewall) per group.
68	4. Vulnerability findings + threat alerts flow into Defender XDR alongside endpoint
69	detections.
70
71	## Guardrails
72	- OT sensors must be passive. Never enable active probing in production OT — risk of
73	PLC reset / safety-system trip.
74	- Coordinate with OT operations before any deployment change. Changes to switches,
75	VLANs, or SPAN configuration require an OT change window.
76	- Don't ship OT alerts straight to the IT SOC without context. OT analysts and IT
77	analysts triage differently. Either build OT-aware playbooks or route to an OT SOC.
78	- **EIoT requires MDE on at least one endpoint per network

People who liked this also viewed

6 picks

Type