Background · 4 Operational Technology & Embedded

ICS & IoT — Security Reference.

Where industrial control systems and IoT surface meet, where their threat models diverge, and the CSA-aligned reference for device, edge, network, cloud, and lifecycle.

ICS — Purdue model and protocols

Purdue levels. L0 sensors/actuators, L1 PLCs, L2 HMI/SCADA, L3 site control + historian, L3.5 DMZ, L4–L5 enterprise IT. Segmentation between levels = the single most important control.
Modbus TCP (port 502). No auth, no encryption. Any reachable client can read/write registers. modbus-cli or Python pymodbus for testing.
DNP3 (20000). Has Secure Authentication v5 in spec; almost never deployed. Most field equipment runs DNP3 plain.
Siemens S7 (102). S7CommPlus has auth + crypto; legacy S7Comm doesn't. Mixed fleets very common.
EtherNet/IP (44818). Allen-Bradley/Rockwell. CIP services exposed; no auth by default.
OPC UA (4840). Modern, supports cert auth and encryption. Often deployed with anonymous policy enabled "for testing".

ICS — engagement rules

Never scan blind. A standard nmap -sV can crash a PLC. Use protocol-aware tools (plcscan, nmap --script s7-info) at controlled rates only.
Maintenance window required. Active testing in production is a written off-line/handover step. Most clients will not authorize live active testing — passive only.
Passive baseline. Span port + Zeek with ICS protocol parsers. Inventory, vendor, firmware versions, anomalous external connections.
Test in a replica lab. Real PLCs + simulated I/O. Don't test active exploitation against the live process.

ICS — recurring findings

Flat L2 between IT and OT. A compromised workstation can speak Modbus to every PLC. Demand IT/OT segmentation gateway (CheckPoint 1570R, Cisco IE3000, Hirschmann).
Direct internet exposure. Shodan port:502 country:DE. Still finds PLCs every week.
Default web HMI creds. admin:admin on Schneider Magelis, Wonderware, B&R, Mitsubishi web HMIs.
Unpatched firmware. Vendor patches lag behind IT by years; field firmware lags vendor patches by years. Cumulative gap commonly 5+ years.
Remote support tunnels. Vendor support left a TeamViewer/AnyDesk hot for years. Find and document.

IoT — CSA-aligned audit layers

Device. Firmware extraction (binwalk, UART/JTAG/SPI dump), strings analysis for hardcoded creds, debug interfaces left enabled. fwup tool checks for signed firmware.
Edge. Local communication (BLE, Zigbee, Z-Wave, Matter/Thread). Pairing flow review, key storage, mesh isolation between rooms/tenants.
Network. WAN protocol (MQTT, CoAP, HTTP), TLS posture, cert pinning, mutual auth.
Cloud. Companion API — same web-app audit as any SaaS. AuthZ across user/device/admin roles. Most takeovers happen here.
Lifecycle. Update channel (signed? rollback-protected? attacker-disable-able?). End-of-life policy (does the cloud-side keep working after vendor sunsets the model?). Vulnerability-disclosure path.

Common IoT findings

Hardcoded creds in firmware. strings firmware.bin | grep -i 'pass\|user\|key'.
Cloud API trusts device-side identity claims. Spoof device ID in cloud request → access any user's data.
Unencrypted local mesh. Zigbee with default network key.
Companion app stores cloud token in plain SharedPreferences. Any malicious app on same Android device reads it.
No revocation. Stolen device, lost device — cloud has no way to invalidate the device's auth token without resetting the user.

Rule of thumbFor ICS, passive observation always; active testing only in a lab replica or under a written maintenance window with the plant operator standing by. For IoT, the cloud-side companion API is usually the path with the most impact and the least operational risk.

Related notes in this domain

From reference to evidence