Background · 4 Operational Technology & Embedded

ICS & IoT — Sicherheitsreferenz.

Wo sich ICS und IoT-Flächen treffen, wo ihre Bedrohungsmodelle auseinanderlaufen und die CSA-orientierte Referenz für Device, Edge, Netzwerk, Cloud und Lifecycle.

ICS — Purdue-Modell und Protokolle

Purdue-Levels. L0 Sensoren/Aktoren, L1 PLCs, L2 HMI/SCADA, L3 Site-Control + Historian, L3.5 DMZ, L4–L5 Enterprise-IT. Segmentierung zwischen Levels = wichtigste Einzelkontrolle.
Modbus TCP (Port 502). Keine Auth, keine Verschlüsselung. Jeder erreichbare Client kann Register lesen/schreiben. modbus-cli oder Python pymodbus zum Testen.
DNP3 (20000). Hat Secure Authentication v5 in der Spec; fast nie deployed. Meiste Field-Equipment läuft DNP3 plain.
Siemens S7 (102). S7CommPlus hat Auth + Crypto; Legacy-S7Comm nicht. Mixed-Flotten sehr häufig.
EtherNet/IP (44818). Allen-Bradley/Rockwell. CIP-Services exponiert; default keine Auth.
OPC UA (4840). Modern, unterstützt Cert-Auth und Verschlüsselung. Oft deployed mit Anonymous-Policy aktiv "zum Testen".

ICS — Engagement-Regeln

Nie blind scannen. Ein Standard-nmap -sV kann einen PLC crashen. Protokoll-bewusste Tools nutzen (plcscan, nmap --script s7-info), nur kontrolliert.
Wartungsfenster erforderlich. Aktives Testen in Produktion ist ein schriftlicher Off-Line-/Handover-Schritt. Die meisten Kunden autorisieren kein Live-Active-Testing — nur passiv.
Passive Baseline. Span-Port + Zeek mit ICS-Protokoll-Parsern. Inventar, Vendor, Firmware-Versionen, anomale externe Connections.
Im Replica-Lab testen. Echte PLCs + simulierte I/O. Aktive Exploitation nicht gegen live Prozess testen.

ICS — wiederkehrende Befunde

Flat L2 zwischen IT und OT. Eine kompromittierte Workstation kann Modbus zu jedem PLC sprechen. IT-/OT-Segmentierungs-Gateway fordern (CheckPoint 1570R, Cisco IE3000, Hirschmann).
Direkte Internet-Exposition. Shodan port:502 country:DE. Findet noch jede Woche PLCs.
Default-Web-HMI-Creds. admin:admin auf Schneider Magelis, Wonderware, B&R, Mitsubishi-Web-HMIs.
Ungepatchte Firmware. Vendor-Patches hängen IT um Jahre hinterher; Field-Firmware hängt Vendor-Patches um Jahre hinterher. Kumulative Lücke häufig 5+ Jahre.
Remote-Support-Tunnels. Vendor-Support hat TeamViewer/AnyDesk jahrelang offen gelassen. Finden und dokumentieren.

IoT — CSA-orientierte Audit-Schichten

Device. Firmware-Extraktion (binwalk, UART-/JTAG-/SPI-Dump), Strings-Analyse für hardcodierte Creds, aktiv gelassene Debug-Interfaces. fwup-Tool prüft auf signierte Firmware.
Edge. Lokale Kommunikation (BLE, Zigbee, Z-Wave, Matter/Thread). Pairing-Flow-Review, Key-Storage, Mesh-Isolation zwischen Räumen/Mietern.
Netzwerk. WAN-Protokoll (MQTT, CoAP, HTTP), TLS-Posture, Cert-Pinning, Mutual-Auth.
Cloud. Companion-API — gleicher Web-App-Audit wie jedes SaaS. AuthZ über User-/Device-/Admin-Rollen. Die meisten Takeovers passieren hier.
Lifecycle. Update-Kanal (signiert? Rollback-protected? vom Angreifer deaktivierbar?). End-of-Life-Policy (funktioniert die Cloud-Seite weiter, nachdem Vendor das Modell sunsetet?). Vulnerability-Disclosure-Pfad.

Häufige IoT-Befunde

Hardcodierte Creds in Firmware. strings firmware.bin | grep -i 'pass\|user\|key'.
Cloud-API vertraut Device-seitigen Identity-Claims. Device-ID im Cloud-Request spoofen → Zugriff auf Daten beliebiger User.
Unverschlüsseltes Local-Mesh. Zigbee mit Default-Network-Key.
Companion-App speichert Cloud-Token in plain SharedPreferences. Jede malicious App auf gleichem Android-Device liest ihn.
Keine Revocation. Gestohlenes Gerät, verlorenes Gerät — Cloud hat keinen Weg, den Device-Auth-Token zu invalidieren ohne den User zu resetten.

FaustregelFür ICS immer passive Beobachtung; aktives Testen nur in Lab-Replika oder unter schriftlichem Wartungsfenster mit dem Plant-Operator daneben. Für IoT ist die Cloud-seitige Companion-API meist der Pfad mit dem meisten Impact und dem geringsten operativen Risiko.