# Purdue Model & OT Segmentation — Microsoft Defender for IoT Source: https://ai.techclick.in/blog_microsoft_defender_iot_purdue_model Markdown: https://ai.techclick.in/blog_microsoft_defender_iot_purdue_model.md Publisher: Techclick Infosec Pvt Ltd Learn how Microsoft Defender for IoT uses the Purdue model (Levels 0–5 plus the Level 3.5 IT/OT DMZ) to auto-map OT devices, detect segmentation violations, and make network segmentation the backbone of ICS/OT security. Purdue Model & OT Segmentation — Microsoft Defender for IoT student learning map A visual study map for Purdue Model & OT Segmentation — Microsoft Defender for IoT showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Purdue Model & OT Segmentation — Microsoft... Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The Purdue Reference Model — six... 4. Practice ② How Defender for IoT auto-maps... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people treat the Purdue model as a dusty diagram in a compliance document — a box you tick for an audit. In practice, the Purdue model is a live security boundary . Every unexpected communication that jumps from a PLC at Level 1 to a corporate host at Level 4 is a potential lateral-movement path to your physical process. Microsoft Defender for IoT makes the model actionable : it auto-assigns every discovered device to a Purdue level, builds a baseline of legitimate inter-level traffic, and raises a Policy Violation alert the moment something crosses a boundary it shouldn't. Understanding the model is not just theory — it is how you read alerts, route them to the right team, and explain risk to management in plain terms. ## ① The Purdue Reference Model — six levels and the DMZ The Purdue Reference Model (PERA) was originally developed for manufacturing and has become the standard framework for structuring ICS/OT networks. It defines six numbered levels. Level 0 is the physical process: sensors, actuators, motors, and valves that touch the real world. Level 1 holds the controllers — PLCs , RTUs, and safety systems — that execute control logic. Level 2 is supervisory: HMIs, SCADA servers, and engineering workstations where operators monitor and command in real time. Level 3 covers site operations: recipe management, production scheduling, and historians that coordinate multiple process cells. Above the OT stack sits a critical addition to the original model: the Level 3.5 IT/OT DMZ . This is a buffer zone — hosting jump servers, patch servers, and historian proxies — that controls exactly what data flows between OT (Levels 0–3) and enterprise IT. Level 4 is the site enterprise network (file servers, email, ERP, Active Directory). Level 5 is the corporate WAN and internet edge. The key insight is direction of risk: threats from IT move down toward controllers and physical processes if barriers are absent. A flat network where a laptop at Level 4 can reach a PLC at Level 1 directly is a single phishing email away from a process disruption — which is why every level boundary is a security control, not just an architectural label. Legend Purdue level band (L0–L5) level detail text diagram heading canvas / background Figure 1 — Purdue Levels 0–5 + DMZ Each level is a security boundary. The Level 3.5 DMZ is the critical IT/OT buffer that prevents direct connectivity between enterprise IT and OT controllers. - Purdue Levels 0–5 + DMZ L5 Enterprise WAN Corporate WAN, internet edge, cloud L4 Site IT Network ERP, AD, email — enterprise IT L3.5 IT/OT DMZ Jump servers, historian proxies, patch servers L3 Site Operations Historians, recipe mgmt, scheduling L2 Supervisory HMIs, SCADA servers, eng. workstations L1 Controllers PLCs, RTUs, safety systems (SIS) Each level is a security boundary. The Level 3.5 DMZ is the critical IT/OT buffer that prevents direct connectivity between enterprise IT and OT controllers. Figure 2 — Why flat OT/IT networks fail Without level boundaries, a single phishing email on a corporate laptop can reach a PLC directly — the Purdue model and DMZ break that chain. Why flat OT/IT networks fail Phishing email hits Level 4 laptop Lateral move no firewall to OT Reaches PLC Level 1 controller Process impact shutdown or sabotage Without level boundaries, a single phishing email on a corporate laptop can reach a PLC directly — the Purdue model and DMZ break that chain. Quick check · Q1 of 10 · Remember Which Purdue level contains PLCs, RTUs, and safety instrumented systems? a) Level 0 — physical field devices such as sensors and actuators b) Level 1 — controllers that execute control logic c) Level 2 — supervisory HMIs and SCADA servers d) Level 3 — site operations and historians Correct: b. Level 1 is the controller layer — PLCs, RTUs, and safety systems (SIS) execute control logic to drive Level 0 actuators. Level 0 holds sensors and actuators; Level 2 holds HMIs and SCADA; Level 3 holds historians and scheduling systems. 👉 So far: Purdue Levels 0–5: field devices → controllers → supervisory → site ops → IT/OT DMZ (3.5) → enterprise IT → WAN. Each boundary is a security control, not just an architectural label. ## ② How Defender for IoT auto-maps every device to its Purdue level Microsoft Defender for IoT does this without touching a single OT device. The OT network sensor connects to a SPAN/mirror port or TAP on the OT aggregation switch. It captures a copy of all traffic and performs DPI — inspecting OT protocol payloads, identifying device types (PLC, RTU, HMI, historian, engineering workstation), the protocols each device speaks (Modbus, DNP3, Siemens S7, OPC UA, EtherNet/IP and more), and the communication patterns it exhibits. From this evidence the sensor infers the Purdue level and populates it in the device inventory . ### Sites, zones, and the inventory view In the Azure or Defender portal every discovered device appears with its Purdue level alongside vendor, model, firmware version, IP address, MAC, open protocols, and risk score. Sites and zones — named groupings you create in Defender for IoT — map to physical plant areas and Purdue layers, so a Vadodara plant operator sees only Level 1–2 devices in their zone while the central SOC sees everything. The sensor's behavioral self-learning baseline — built passively over the initial learning period — captures which devices legitimately communicate at which levels, giving the system a map of normal before it starts alerting on deviations. Figure 3 — Defender for IoT: device-to-level mapping The OT sensor passively infers Purdue levels from DPI and communication patterns — no agent required on any OT device. Defender for IoT: device-to-level mapping OT Sensor (DPI) SPAN / TAP port L0 Field Devices L1 PLCs/RTUs L2 HMI/SCADA L3 Historians L3.5 DMZ hosts L4 IT hosts The OT sensor passively infers Purdue levels from DPI and communication patterns — no agent required on any OT device. 🏭 Level 1 — Controllers tap to flip PLCs, RTUs, and safety systems. They execute control logic from Level 2 and drive Level 0 actuators. Disrupting Level 1 means losing control of the physical process. 🛡️ Level 3.5 IT/OT DMZ tap to flip The buffer zone between OT (Levels 0–3) and IT (Levels 4–5). Hosts jump servers, historian proxies, and patch servers — the only authorized crossing point between the two worlds. 🔍 Policy Violation Engine tap to flip One of Defender for IoT's five detection engines. Fires when network traffic crosses a Purdue level boundary that is not in the approved baseline — the primary segmentation-violation detector. 🗺️ Sites & Zones tap to flip Named groupings in Defender for IoT that align to physical plant areas and Purdue levels. Each sensor is assigned to a site and zone, scoping device inventory and alert routing to the right team. Level 3.5 is the interview answer Interviewers love asking 'what sits between OT and IT?' The answer is Level 3.5 — the IT/OT DMZ. Name what it hosts (jump servers, historian proxies, patch servers) and why it exists: to prevent any direct routable path from enterprise IT to OT controllers. Defender for IoT monitors this zone like any other. Quick check · Q2 of 10 · Understand How does Microsoft Defender for IoT assign a Purdue level to a newly discovered OT device? a) An administrator manually enters the level in the device inventory b) An agent installed on the OT device reports its own level to the cloud c) The OT sensor uses passive DPI — inspecting protocols, device type, and communication patterns — to infer the Purdue level d) Defender for IoT polls each device via SNMP to ask its role Correct: c. Defender for IoT is fully agentless and passive. The sensor captures a copy of network traffic from a SPAN/mirror or TAP and infers device type, Purdue level, and attributes from DPI of the protocols and communication patterns — no agent or active polling is needed, which is critical for fragile OT devices. 👉 So far: Defender for IoT assigns Purdue levels passively — DPI on SPAN/TAP traffic identifies device type and protocols with no agent on any OT device. Sites and zones align inventory and alerts to the Purdue hierarchy. ## ③ Detecting cross-level and segmentation violations Once the baseline is established, Defender for IoT's Policy Violation detection engine fires whenever traffic crosses a Purdue boundary that is not in the approved baseline. Classic examples: a Level 1 PLC sending packets directly to a Level 4 corporate host; a Level 0 sensor communicating to an internet IP (Level 5); a newly connected laptop bypassing the Level 3.5 DMZ jump server. Each event generates an alert with the source device, destination, protocol used, and the Purdue levels involved — giving the analyst exactly what they need to confirm whether this is an authorized maintenance path or an active threat. The Anomaly engine adds a second layer: even if no explicit policy rule covers a specific pair of devices, a new cross-level communication channel that was absent from the learning-period baseline is flagged as anomalous. The combination of policy rules and learned-baseline deviations means Defender for IoT catches both known-bad patterns and novel segmentation events. The alert queue in the Defender portal is filterable by Purdue level, site, and zone — so the OT team at a specific plant can triage their level-boundary violations without noise from elsewhere in the estate. Figure 4 — Cross-level alert: authorized vs violation Both events look like a PLC communicating with an IT host — only the path through the DMZ makes it authorized. Cross-level alert: authorized vs violation Authorized (DMZ path) PLC (L1) → historian (L3) Historian proxy in DMZ (L3.5) Read-only data to IT side (L4) No direct L1-to-L4 connection No alert raised Violation (bypass) PLC (L1) connects directly to AD No DMZ hop Policy Violation alert fires Device flagged as new actor Analyst investigates immediately Both events look like a PLC communicating with an IT host — only the path through the DMZ makes it authorized. 'It is just an anomaly' miss The Anomaly engine flags deviations from the learned baseline, but the engine explicitly responsible for Purdue boundary enforcement is the Policy Violation engine. In an interview — or a real alert investigation — call out the Policy Violation engine by name when discussing cross-level traffic. Conflating the two suggests you haven't read the alert taxonomy. ### ▶ Watch a cross-level segmentation violation get detected Follow a rogue direct connection from a PLC to a corporate host — and see exactly how Defender for IoT catches it. Press Play for the detection path, then Break it to see what happens when the DMZ is bypassed silently. ① PLC connects A Level 1 PLC initiates a TCP connection to a corporate AD server at Level 4. This is a direct cross-level connection — no DMZ jump server in the path. ▼ ② Sensor captures The OT network sensor on the SPAN port captures the packet exchange. Its DPI identifies the source as a known PLC (Level 1) and the destination as a corporate host (Level 4). ▼ ③ Policy check The Policy Violation engine compares this communication pair against the approved baseline and the Purdue segmentation policy. This pair is not authorized — it bypasses Level 3.5. ▼ ④ Alert raised A Policy Violation alert is raised in the Defender portal: source PLC, destination AD server, protocol, Purdue levels crossed, and 'new actor' flag. The OT team is notified immediately. Press Play to step through the cross-level detection. Then press Break it to see the silent-bypass failure. ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply A Defender for IoT alert shows: 'PLC (Level 1) → corporate AD server (Level 4), direct connection, new actor'. What is the most likely explanation? a) A segmentation bypass — a direct cross-level connection that skips the Level 3.5 DMZ b) Normal historian replication through the authorized DMZ proxy c) A firmware update being pushed from the patch server d) Expected SCADA supervisory traffic at Level 2 Correct: a. A direct Level 1-to-Level 4 connection that bypasses the Level 3.5 DMZ is a segmentation violation. Authorized data flows from OT to IT pass through the DMZ — jump servers or historian proxies — and would not appear as a direct PLC-to-AD connection. The 'new actor' flag confirms this is not a known, baselined path. 👉 So far: The Policy Violation engine fires on unauthorized cross-level traffic. The Anomaly engine adds coverage for new cross-level paths not seen during baseline. Together they make segmentation violations visible in real time. ## ④ Segmentation as the primary OT compensating control OT devices live on a different patching timeline from IT. A PLC firmware update typically requires a planned maintenance window, process shutdown, vendor testing, and sign-off from the plant engineering team — a cycle that can take months. During that window the device runs with a known vulnerability. In IT, you patch within days; in OT, compensating controls are mandatory. Network segmentation is the most powerful one: if a vulnerable PLC at Level 1 cannot be reached from the enterprise network at Level 4, the attack surface is drastically reduced even before the patch arrives. ### The DMZ pattern in practice The Level 3.5 IT/OT DMZ is the implementation of that compensating control. Jump servers in the DMZ enforce authenticated, logged remote access to OT. Historian proxies extract read-only data to the IT side without allowing any inbound path. Patch servers stage and validate OT updates inside the DMZ before they cross down. Unidirectional security gateways (data diodes) can enforce a hardware-level one-way data flow for the highest-security zones. Defender for IoT monitors this DMZ like any other zone — it maps devices there to Level 3.5, tracks communication through it, and alerts on any direct OT-to-IT path that bypasses it. When Priya Nair at Chemind Process Industries sees a Level 1 PLC communicating directly with a Level 4 AD server, the Defender for IoT alert tells her exactly where the bypass is and which device is the new actor — so she can close the gap before an attacker exploits it. Figure 5 — OT compensating-control chain When patching a PLC takes months, segmentation and monitoring are the active controls that reduce risk in the meantime. OT compensating-control chain CVE found PLC firmware vulnerable Patch delayed window months away Segment it firewall at L3.5 DMZ Monitor it Defender for IoT alerts Patch + verify maintenance window When patching a PLC takes months, segmentation and monitoring are the active controls that reduce risk in the meantime. Priya Nair at Chemind Process Industries, Vadodara faces this A Defender for IoT alert fires: 'PLC (Level 1) is communicating with corporate AD server (Level 4) — cross-level Policy Violation, new actor detected'. Likely cause A maintenance technician plugged a laptop directly into the process network switch for a local firmware check, bypassing the Level 3.5 jump server. The laptop had a live AD connection, creating a direct L1-to-L4 path. Diagnosis In the Defender portal, open the alert — source is the PLC IP (Level 1), destination is a corporate AD server (Level 4), no DMZ hop in the communication path. Check device inventory — the laptop appears as a newly discovered, unclassified device with no prior baseline entry. Defender Portal ▸ Alerts ▸ Policy Violation + Device Inventory ▸ New Actors Fix Isolate the laptop from the process network switch. Enforce firewall rules at the Level 3.5 DMZ to block all direct OT-to-IT paths. Require all remote and local maintenance access to go through the authorized DMZ jump server. Re-baseline Defender for IoT for that zone. Verify Alert clears; the device map no longer shows a direct edge between Level 1 and Level 4. A controlled retest via the jump server shows the authorized path flows without triggering a violation alert. Check the path, not just the alert A segmentation violation alert is only resolved when you confirm the communication path is closed — not when the alert is acknowledged. In Defender for IoT, verify the device map no longer shows the unauthorized cross-level edge and that a controlled retest does not re-trigger the Policy Violation alert. Quick check · Q4 of 10 · Evaluate A critical CVE is published for a widely deployed PLC model in your plant. The vendor says the patch will not be ready for three months. What is the best immediate OT security response? a) Wait for the patch — there is nothing else to do b) Disable the PLCs until the patch is available c) Deploy endpoint agents on each PLC to monitor for exploitation d) Apply compensating controls: tighten network segmentation at Level 3.5, confirm Defender for IoT is monitoring cross-level traffic, and document the risk formally Correct: d. OT patching is slow by necessity. The standard response is compensating controls: enforce segmentation so the vulnerable device cannot be reached from IT networks, verify Defender for IoT is alerting on any anomalous traffic to or from those PLCs, and formally document the accepted risk until the patch window. Disabling PLCs stops production; waiting silently leaves risk undocumented. 👉 So far: When patching a PLC takes months, compensating controls are mandatory. Enforce segmentation at Level 3.5, monitor cross-level traffic with Defender for IoT, and formally document accepted risk until the patch window. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What are the Purdue model levels and what lives at each? Why is the Level 3.5 DMZ considered essential in OT security? How does Defender for IoT know a device is a PLC at Level 1 rather than a server at Level 4? Which detection engine is primarily responsible for cross-level segmentation violation alerts? What are sites and zones in Defender for IoT and why do they matter? Why is network segmentation considered the primary compensating control in OT security? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which Purdue level is described as the 'IT/OT DMZ' and acts as a buffer between OT and enterprise IT? a) Level 2 — supervisory control b) Level 3.5 — the IT/OT demilitarized zone c) Level 4 — enterprise network d) Level 0 — field devices Correct: b. Level 3.5 is the IT/OT DMZ — a standard addition to the original Purdue model. It hosts jump servers, historian proxies, and patch servers that control and log all data exchange between the OT stack (Levels 0–3) and enterprise IT (Levels 4–5). Q6 · Understand Why does Microsoft Defender for IoT use passive DPI on a SPAN port rather than installing agents on PLCs? a) Agents are cheaper but less accurate b) SPAN ports are only available in cloud environments c) PLCs and RTUs are fragile, cannot tolerate additional software loads, and must not be disturbed — passive monitoring has zero operational impact d) Active polling gives faster results than passive DPI Correct: c. OT devices like PLCs and RTUs run proprietary firmware, often have no spare compute resources, and any unplanned interaction (a network probe, an agent install) can cause a process disruption. Passive DPI on a SPAN/mirror port captures a copy of traffic with zero interaction with the OT device itself — the core 'agentless' principle of Defender for IoT. Q7 · Apply In Defender for IoT, a device shows Purdue Level 2 in the inventory. What type of device is it most likely to be? a) A field sensor measuring temperature b) A PLC running ladder logic c) An HMI or SCADA server used by operators to monitor and command the process d) A corporate email server Correct: c. Level 2 is the supervisory layer — HMIs (Human-Machine Interfaces), SCADA servers, and engineering workstations sit here. They receive data from Level 1 controllers and provide the operator interface. Field sensors are Level 0; PLCs are Level 1; email servers are Level 4. Q8 · Analyze An alert reads: 'Device A (Level 3) communicating with Device B (Level 1) using an unexpected protocol — new communication pair, not in baseline'. Which two detection engines most likely contributed to this alert? a) Malware engine and Operational engine b) Protocol Violation engine and Operational engine c) Discovery engine and Malware engine d) Policy Violation engine and Anomaly engine Correct: d. The Policy Violation engine fires when a communication pair crosses a Purdue boundary outside the approved policy. The Anomaly engine fires when a new communication pair appears that was absent from the learning-period baseline. Both are triggered here: the level crossing is a policy issue; the unseen pair is an anomaly. Protocol Violation would fire separately on the unexpected protocol, but the boundary-crossing and baseline-deviation are owned by Policy Violation and Anomaly. Q9 · Evaluate A plant engineer proposes removing the Level 3.5 DMZ to simplify the network and allow direct historian replication from Level 3 to the Level 4 data warehouse. What is the strongest objection? a) Removing the DMZ creates a direct routable path from enterprise IT to OT controllers, eliminating the primary compensating control against lateral movement from a compromised IT host b) Defender for IoT cannot monitor networks without a DMZ c) It will slow down historian replication significantly d) The DMZ is required only for compliance audits, not for real security Correct: a. The Level 3.5 DMZ is the architectural barrier that prevents a compromised enterprise IT host from reaching OT controllers directly. Without it, a single compromised laptop or server at Level 4 has a routable path all the way down to PLCs at Level 1. Historian replication can be handled by a read-only proxy in the DMZ without removing the barrier. Q10 · Evaluate An OT security manager wants to confirm that Defender for IoT's Purdue-level mapping is accurate for all 400 devices in the plant. What is the most effective validation approach? a) Manually walk the plant floor and compare physical labels to the inventory b) Run a Nmap scan across the OT network to enumerate devices c) Compare the Defender for IoT device inventory — filtered by Purdue level and zone — against the plant's engineering documentation and known device list, then investigate any unrecognised or mis-levelled entries d) Trust the auto-mapping and make no changes — the sensor is always accurate Correct: c. The correct validation is to compare the auto-discovered device inventory against authoritative plant engineering documentation. Filter by site, zone, and Purdue level in the Defender portal, identify any unrecognized devices (potential rogue/shadow devices) or mis-levelled entries (e.g. a device classified as Level 2 that engineering records show as Level 1), and investigate each discrepancy. Nmap would be an active scan — dangerous in OT; relying blindly on auto-mapping misses rogue devices. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one sentence: why is the Purdue model a security tool, not just an architecture diagram? Then compare with the expert version. Compare with expert answer Expert version: The Purdue model is a security tool because every level boundary is a firewall enforcement point and an alert trigger — Microsoft Defender for IoT maps each discovered device to a level, builds a baseline of legitimate inter-level traffic during the learning period, and raises a Policy Violation alert the moment any device communicates across a boundary outside that baseline. The model also defines exactly where compensating controls belong: the Level 3.5 IT/OT DMZ hosts the jump servers, historian proxies, and patch servers that make controlled OT-to-IT data exchange possible without any direct routable path between PLCs and enterprise IT systems. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Defender for IoT at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Purdue Reference Model (PERA) A hierarchical framework for structuring ICS/OT networks into Levels 0–5 separating physical process, control, supervisory, operations, and enterprise IT layers — each boundary a security control. Level 3.5 IT/OT DMZ A demilitarized zone between OT (Levels 0–3) and enterprise IT (Levels 4–5), hosting jump servers, historian proxies, and patch servers to prevent any direct routable path from IT to OT. PLC (Programmable Logic Controller) A ruggedized industrial computer at Purdue Level 1 that executes control logic to drive Level 0 actuators such as motors and valves. Segmentation violation A network communication event that crosses a Purdue level boundary without authorization, indicating a configuration error or potential attacker lateral movement. Policy Violation engine One of Defender for IoT's five detection engines. Fires on traffic that crosses a Purdue boundary outside the approved baseline — the primary detector of cross-level segmentation violations. Passive DPI Deep packet inspection performed on a copy of network traffic via SPAN/mirror or TAP — zero interaction with OT devices, so no operational impact on fragile controllers. Sites and zones Named groupings in Defender for IoT that align to physical plant locations and Purdue levels, scoping device inventory, alert routing, and RBAC to the right team. Compensating control A security measure applied in place of a direct fix (such as a patch) when that fix is impractical. In OT, network segmentation is the primary compensating control for unpatched devices. Behavioral self-learning The sensor's baseline-building phase that maps normal OT device communication patterns across Purdue levels. Deviations after the learning period trigger Anomaly alerts. #### 📚 Sources Microsoft Learn — Microsoft Defender for IoT: Purdue model and OT network segmentation . learn.microsoft.com/en-us/azure/defender-for-iot - Microsoft Learn — OT network sensor overview and device inventory . learn.microsoft.com/en-us/azure/defender-for-iot/organizations/how-to-manage-device-inventory-for-organizations - Microsoft Learn — Defender for IoT detection engines and alert types . learn.microsoft.com/en-us/azure/defender-for-iot/organizations/concept-key-concepts - NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security . nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf - IEC 62443 — Security for industrial automation and control systems (IACS) . iec.ch/standards/iec-62443 - Microsoft Security Blog — OT/ICS threat landscape and Microsoft Defender for IoT . microsoft.com/en-us/security/blog ### What's next? Got the Purdue model and segmentation covered? Next, go deep on the five detection engines — Protocol Violation, Policy Violation, Malware, Anomaly, and Operational — and how behavioral self-learning moves Defender for IoT from baseline to alert. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt