Module 1 · IoT & OT Security Fundamentals 🔒

IoT (Internet of Things) and OT (Operational Technology) cover the security of physical-world systems — connected sensors, industrial controllers, smart-home gear, medical devices, vehicles, and the SCADA systems that run critical infrastructure. The threat model differs from IT in fundamental ways and the consequences of compromise are often physical. This module sets up the mental models — IT vs OT, the Purdue model, and the IoT/OT threat landscape in 2026.

IoT vs OT — the distinction

• IoT: consumer and commercial connected devices. Smart bulbs, doorbells, thermostats, building HVAC, fleet vehicles. Designed for connectivity from day one. Lifecycle: 3-7 years
• OT: industrial control systems. PLCs, DCS, SCADA, MES. Originally air-gapped; increasingly connected. Lifecycle: 15-30 years. Compromise can stop power grids, contaminate water, halt manufacturing

The skills overlap; the consequences and constraints differ. A pentester moving from IT to OT must unlearn habits — “let me try a port scan” can crash a 30-year-old PLC controlling a turbine.

The Purdue Enterprise Reference Architecture

LEVEL 5  Enterprise Network         (corporate IT, internet-connected)
─────────────────────────────────────  IT/OT BOUNDARY (DMZ)
LEVEL 4  Site Business Network       (plant IT, ERP, MES)
─────────────────────────────────────
LEVEL 3  Site Operations             (engineering workstations,
                                      historian, batch management)
─────────────────────────────────────
LEVEL 2  Supervisory Control         (HMI, SCADA servers)
─────────────────────────────────────
LEVEL 1  Basic Control              (PLCs, RTUs, controllers)
─────────────────────────────────────
LEVEL 0  Process / Field Devices    (sensors, actuators, motors)

Defenders aim to keep level 0-3 isolated from internet (level 5). Attackers aim to traverse downward — get into corporate IT (level 5), pivot through the DMZ to plant IT (level 4), reach supervisory (level 2), and control the process (level 1). Mature defenders maintain hard boundaries between each level.

Why OT is hard to defend

• Long lifecycle, no patches. A PLC installed in 2003 may still be running. Vendor abandoned support in 2015. No patches for known CVEs
• Availability over confidentiality. Stopping a PLC for a security update may halt production worth millions. Maintenance windows are quarterly at best
• Proprietary protocols. Modbus, DNP3, OPC-UA, Profibus, EtherCAT — many lack auth or encryption by design
• Safety constraints. Triggering an interlock can cost lives. Pentest tools that “just probe” can trigger emergency shutdowns
• Limited observability. Many OT environments don’t have IT-style logging or SIEMs. Detecting compromise is hard

IoT-specific challenges

• No built-in security. Default passwords, hardcoded credentials, no update mechanism
• Weak authentication. Cloud APIs that trust device-supplied identity claims
• Insecure firmware. Buffer overflows, command injection, debug interfaces left enabled
• Long supply chain. Generic Chinese firmware re-skinned by hundreds of brands; one vulnerability affects all
• Privacy at scale. Sensors collecting personal data, transmitting in cleartext

The threat landscape in 2026

• Nation-state interest in critical infrastructure. Volt Typhoon (PRC) activity against US infrastructure, similar campaigns against European and Indian utilities
• Ransomware crossing into OT. Colonial Pipeline (2021) showed attackers don’t need to encrypt OT; encrypting IT and affecting OT operations is enough leverage
• IoT botnets. Mirai descendants continue; consumer devices used for DDoS, residential proxies, click fraud
• Connected vehicles. CAN bus exploitation, telematics-API abuse
• Medical device security. FDA mandating SBOM and post-market vulnerability monitoring as of 2023

Notable real-world OT incidents

• Stuxnet (2010) — first widely-known OT attack; sabotaged Iranian centrifuges via Siemens PLCs
• BlackEnergy / Industroyer (2015-2016) — Ukraine power grid attacks
• Triton/Trisis (2017) — targeted safety instrumented systems at a Saudi petrochemical plant
• Colonial Pipeline (2021) — IT ransomware; OT halted as precaution; US fuel-supply disruption
• Various water utilities (2023-2025) — opportunistic attacks against US, European, Indian water plants exploiting exposed PLC interfaces

Each one drove regulatory and operational changes. The pattern: IT/OT boundary becomes the highest-stakes defensive layer.

Discovery — finding the OT/IoT surface

For a defender or auditor:

• Asset inventory: usually wildly incomplete. Tools: Claroty, Nozomi, Dragos for OT-aware passive discovery
• Network capture: SPAN port copy of OT traffic; identify protocols and devices passively (no active probing)
• Shodan + Censys for internet-exposed OT/IoT — finds the devices that should not be on the internet but are
• Vendor portals + serial numbers for firmware versions and known CVEs

Common findings on first-pass IoT/OT assessments

• Internet-exposed PLCs / SCADA HMIs — 2024 ICS-CERT counts thousands
• Default credentials in production
• Old VPN appliances bridging IT to OT with weak auth
• Engineering workstations on Windows 7, no patches, used to program PLCs
• OT remote-access tools (TeamViewer, AnyDesk) installed for vendor support, with weak passwords
• Wireless rogue devices on OT network from contractors
• USB-based malware introduction (autorun on engineering workstations)

The defender’s playbook (high level)

1. Inventory. You can’t protect what you can’t see. Passive discovery first; never active scan blind
2. Segmentation. IT/OT DMZ; no flat networks. Firewalls between Purdue levels
3. Restrict remote access. Vendor remote access through a hardened jump host with MFA, recorded sessions, time-bounded
4. Patch what’s patchable. Engineering workstations, HMIs, network equipment. Accept that PLCs may stay unpatched
5. Monitor. OT-aware anomaly detection (Claroty, Nozomi, Dragos). Behavioral baselines specific to industrial protocols
6. Plan response. What if a controller is compromised? Manual override, safe-state, supplier on-call

What the next modules cover

Module 2 covers IoT-specific testing — firmware extraction, binary analysis, default credential discovery, mobile companion apps. Module 3 dives into industrial protocols (Modbus, DNP3, OPC-UA) and their attack surfaces. Module 4 covers OT security testing methodology — what’s safe vs unsafe in a live environment.