Threat Hunting in OT und IoT: Wenn die Regeln nicht mehr gelten

Ich habe in Projekten mit klassischer Enterprise-IT gearbeitet. Windows-Domänen, Active Directory, Exchange, Endpoint-Protection auf jedem Gerät. Threat Hunting dort ist herausfordernd, aber das Fundament steht: Logs, EDR-Telemetrie, SIEM-Regeln.

Dann gibt es OT- und IoT-Umgebungen. Und dort gelten andere Regeln.

Was anders ist

In der klassischen IT läuft auf jedem Endpunkt ein Agent. Der Agent schreibt Logs. Die Logs landen im SIEM. Das SIEM triggert Regeln. Threat Hunter untersuchen Anomalien.

In einer IoT-Umgebung läuft auf dem Endpunkt kein Agent. Manchmal läuft dort ein minimales Linux-Derivat aus dem Jahr 2012. Manchmal ist es proprietäre Firmware, die seit dem Einbau nicht angefasst wurde. Manchmal ist es ein Embedded-System, das schlicht keinen Logging-Stack hat.

Das bedeutet: Die Sichtbarkeit, auf der klassisches Threat Hunting aufbaut, existiert nicht. Wer versucht, IoT-Geräte wie Windows-Endpoints zu behandeln, wird scheitern.

Das eigentliche Problem: Sichtbarkeit

Ein Paper der Universität Kelaniya (2024) beschreibt proaktives Threat Hunting in IoT-Ökosystemen als Notwendigkeit, nicht als Option. Die Kernthese ist einfach: IoT-Geräte sind zu zahlreich, zu heterogen und zu schlecht geloggt, um reaktiv zu arbeiten.

Was das bedeutet:

Netzwerk-Sicht statt Endpunkt-Sicht. In IoT-Umgebungen ist der Netzwerkverkehr oft das einzige verlässliche Signal. Ein Gerät, das plötzlich auf externe IP-Adressen verbindet, die es nie kontaktiert hat. Ein Protokoll, das auf einem Port läuft, der für das Gerät untypisch ist. Kommunikation zwischen Geräten, die im Normalfall nicht miteinander sprechen.

Baseline ist alles. In der Enterprise-IT gibt es Erfahrungswerte, was normales Verhalten ist. In IoT-Umgebungen muss diese Baseline erst aufgebaut werden. Schritt eins ist zu verstehen, was das Netzwerk im Normalzustand tut, bevor man nach Anomalien sucht.

CVSS reicht nicht. Ein CVSS-Score sagt dir die Schwere einer Schwachstelle. Er sagt dir nicht, ob das Gerät in deiner Umgebung erreichbar ist, ob es aktiv angegriffen wird, oder ob die Schwachstelle für dein spezifisches Threat-Profil relevant ist.

Was Threat Hunter in OT/IoT brauchen

Asset-Inventar zuerst. Man kann nicht jagen, was man nicht kennt. In vielen Umgebungen ist allein die Frage "Welche Geräte sind im Netzwerk?" schwer zu beantworten. Nmap-Scans auf OT-Geräten sind riskant. Passive Netzwerküberwachung ist hier oft der sicherere Ansatz.

Protokollkenntnisse. IoT und OT nutzen Protokolle, die in der klassischen IT unbekannt sind: Modbus, DNP3, BACnet, MQTT, CoAP. Ein Threat Hunter, der diese Protokolle nicht kennt, kann keine Anomalien darin erkennen. Ein falsch konfigurierter Modbus-Query kann einen industriellen Controller zum Absturz bringen.

Segmentierung als Kontrollpunkt. Wenn Geräte in segmentierten Netzwerkzonen liegen und jede Zonengrenze überwacht wird, entsteht automatisch Sichtbarkeit, die auf Gerätebene fehlt. Die Segmentierungsgrenze wird zum Hunting-Punkt.

Verhaltensbasiert statt signaturbasiert. Es gibt keine Antiviren-Signaturen für Firmware-Manipulation. Aber es gibt Verhaltensabweichungen. Ein Steuerungsgerät, das plötzlich DNS-Anfragen stellt, obwohl es das nie getan hat, ist ein Signal, auch wenn keine Signatur dazu existiert.

Die Herausforderung mit dem Patchzyklus

Ein Problem in OT/IoT, das Threat Hunter kennen müssen: Patches werden oft nicht eingespielt. Nicht aus Nachlässigkeit, sondern aus Gründen.

Ein industrieller Controller läuft in einem 24/7-Prozess. Jedes Update erfordert einen Wartungsstopp, Freigaben durch mehrere Abteilungen, Tests in einer Testumgebung, die oft nicht existiert. Das Update eines medizinischen Geräts erfordert erneute Zertifizierung. Das Update einer Anlage mit proprietärer Firmware erfordert den Hersteller.

Das bedeutet für den Threat Hunter: Die Annahme, dass bekannte Schwachstellen gepatcht sind, gilt hier nicht. Threat Hunting in OT/IoT muss davon ausgehen, dass Schwachstellen existieren, die nicht behoben werden können. Der Fokus verschiebt sich auf Erkennung statt Prävention.

Was bleibt gleich

Trotz aller Unterschiede: Die grundlegende Logik des Threat Huntings bleibt. Hypothese formulieren, Signal suchen, Anomalie untersuchen, Ergebnis dokumentieren.

Auch der OODA Loop gilt hier. Der Unterschied ist, dass Orient in OT/IoT-Umgebungen mehr domänenspezifisches Wissen erfordert. Ein Threat Hunter ohne Prozessverständnis kann nicht einschätzen, ob ein Verhalten in einer Produktionsanlage normal oder gefährlich ist.

Ich sehe das so

IoT- und OT-Umgebungen sind kein Sonderfall, der irgendwann gelöst sein wird. Sie sind der wachsende Normalfall.

Wer heute nur in klassischen IT-Umgebungen jagt, wird mittelfristig blinde Flecken haben. Die Grundprinzipien übertragen sich, aber die Werkzeuge, die Protokolle und das nötige Domänenwissen nicht.

Der erste Schritt ist Sichtbarkeit. Der zweite Schritt ist Baseline. Der Rest folgt aus dem, was man findet.