OT-Sicherheit in der Praxis: Die 5 Critical Controls für OT-Netze

Fernzugänge sind in der Praxis eine der größten Schwachstellen. Ein wiederkehrendes Bild aus den Assessments:

„Mein persönliches Highlight ist immer, dass ich bei jedem dritten Kunden irgendwo in der OT eine TeamViewer-Session finde, aber nicht das Professional, sondern das Consumer-TeamViewer, das da einfach offen mitläuft. Das sind so schöne Einfallstore, die man findet." Olli Herterich, Solution Architect, Dragos

Solche „schönen Einfallstore" sind für Angreifer leicht nutzbar. Fernzugriffe gehören zertifiziert, kontrolliert und auf das Nötigste beschränkt.

OT-Umgebungen sind oft alt und tragen viele Schwachstellen. Patchen ist häufig nicht möglich oder nicht sinnvoll. Der pragmatische Weg ist eine risikobasierte Priorisierung nach dem Muster Now / Next / Never:

• Now: Schwachstellen mit bekannter aktiver Ausnutzung, ohne benötigte Credentials, mit echtem Impact auf die Automatisierung.
• Next: relevant, aber weniger dringlich – geplant abarbeiten.
• Never: kaum erreichbar oder ohne relevantes Risiko; bewusst zurückstellen und dokumentieren.

Wichtig: Statt zu patchen, lässt sich das Risiko oft anders mitigieren, etwa indem man den von der Schwachstelle genutzten Port/Dienst abschaltet oder streng auf die Geräte begrenzt, die ihn wirklich brauchen. Ein Beispiel aus dem Vortrag: Nutzt eine Schwachstelle TCP-Port 102 (typischer S7-Kommunikationsport), ist entscheidend, wer überhaupt Zugriff auf diesen Port hat; ein ganzes /16-Netz ist hochkritisch, eine einzelne Workstation deutlich weniger.

Verteidigung beginnt mit Sichtbarkeit: Wer ist im Netz und wie kommuniziert er? Auf Basis der Asset-Daten werden Schwachstellen zugeordnet und Angriffe erkannt. Ein wichtiger Punkt aus dem Vortrag ist die Unterscheidung zwischen dem, was aktuell passiert und dem, was passieren kann: Reines Traffic-Monitoring zeigt nur den Ist-Zustand. Ein Network-Access-Modeling-Ansatz (im Vortrag: die Lösung „NP-View") modelliert zusätzlich die möglichen Kommunikationspfade über Ports und Firewalls und macht so „overpermissive" Regeln sichtbar, die man enger ziehen sollte. Ergänzt wird das durch Threat Detection und durch Playbooks, die von Incident-Respondern gepflegt werden und Schritt für Schritt vorgeben, wie ein Verdachtsfall zu untersuchen ist.

Gerade Teams, die OT-Security erst aufbauen, müssen nicht alles von Tag 1 selbst können. Nachfolgend finden Sie mehrere Bausteine, die sich kombinieren lassen:

• Managed Threat Hunting (im Vortrag „OT Watch"): proaktive Threat-Hunts im Kundennetz, inklusive Unterstützung bei Triage und Response, wahlweise als regelmäßiger Service oder als 24/7 Managed Protection.
• OT-spezifische Threat Intelligence (im Vortrag „WorldView"): regelmäßige Reports zu aktuellen Angriffen, Schwachstellen der Automatisierungshersteller (z. B. Siemens, Rockwell) inkl. Bewertung der Auswirkungen und Mitigationen.
• Incident Response als Retainer: vorab gebuchtes Stundenkontingent, das sich auch für Readiness/Risk/Vulnerability-Assessments, Architektur-Reviews, Tabletop-Übungen oder Pen-Tests nutzen lässt. Plattform-Kunden haben laut Vortrag einen SLA (Responder aktiv binnen 4 Stunden, vor Ort binnen 48 Stunden).

Ein wiederkehrender Praxis-Hinweis: Nicht jedes Risiko geht vom gezielten Angreifer aus. Auch versehentliche Fehler (z. B. ein gezogenes Netzwerkkabel) zählen dazu. Besonders kritisch ist die häufige OT-Backup-Lücke: Während die IT gute Backup-Policies hat, fehlt sie für Produktions- und Maschinen-Software oft.

KI wird auch in der OT-Security zum Thema. Im Vortrag wird ein neu vorgestellter KI-Agent beschrieben, der auf kuratierten, menschlich erzeugten Daten (Threat-Intelligence-Reports, Service-Daten) statt auf beliebigen Internetquellen arbeitet. Nur mit belastbaren Daten liefert ein KI-Agent verlässliche Analysen, etwa um eine Notification einzuordnen oder zu prüfen, ob eine aktuelle Kampagne das eigene Netz betrifft. Für regulierte Umgebungen (Militär, kritische Infrastruktur) bleibt der Betrieb bewusst On-Prem und offline möglich.

Der zweite Hebel ist die IT/OT-Integration: OT-Monitoring wird mit Netzwerk-Enforcement gekoppelt. Im Vortrag geschieht das über die Integration von Dragos mit Fortinet (u. a. FortiGate, FortiManager, FortiSOAR, FortiAnalyzer, FortiSIEM). So lassen sich Assets abgleichen und auf Basis von Regeln automatische oder halbautomatische Policies auslösen: Der Analyst muss die Regel nicht mehr manuell bauen, sondern nur noch freigeben. Das bringt Geschwindigkeit, ohne die Kontrolle abzugeben.

Der häufigste Fehler ist, mit Produkten zu beginnen. Der empfohlene erste Schritt ist Risikomanagement, idealerweise mit einem Partner zusammen. Kern ist der „Risikoappetit": Das Unternehmen legt fest, wie viel Risiko es tragen will. Denn mehr Security ist nicht automatisch besser. Falsch gesetzte Sicherheitsmaßnahmen können selbst zum Störfaktor für die Produktion werden. Der klassische Ablauf:

1. Strukturanalyse: vorhandene Netzwerkdiagramme und Informationen zusammentragen.
2. Asset-Überblick: der wichtigste Schritt. Für ein CMDB-fähiges Asset-Management braucht es OT-spezialisierte Werkzeuge; die Tiefe (nur IP/MAC/Hersteller vs. vollständiges Inventar) ist bewusst zu wählen.
3. Sicherheitsziele & Klassifizierung: meist entlang IEC 62443 (OT-Security-Standard) mit seinen Schutzniveaus; ergänzt um eine Bedrohungsmodellierung (Werte z. B. 0–100 je Gerät).
4. Maßnahmen & Wirksamkeit: passende Controls auswählen und ihre Wirksamkeit nachweisen. Gerade unter NIS2 reicht „wir haben eine Firewall" nicht aus.
5. Umsetzen & auditieren: phasenweise implementieren und mit internen/externen Audits gegenprüfen. Referenzrahmen stellt u. a. ISO 31000 und IEC 62443 dar.

In der Praxis fehlt häufig noch die Trennung: Die Perimeter-Firewall wird genutzt, ein VLAN mit „OT" beschriftet und der Produktion überlassen. Besser ist eine echte Trennung mit einer DMZ. Der Clou bei der Datenlogik: Statt die IT in die OT greifen zu lassen, stellt die OT ihre Daten in einem gelagerten System bereit, aus dem sich IT/Business bedienen (z. B. für Einkauf, Logistik oder Predictive Maintenance). Auch die Fernwartung, die oft ein Wildwuchs aus vielen VPN-Servern ist, gehört in einen geschützten Bereich. Dabei ist Zusammenarbeit nötig:

Der teuerste Fehler ist ein flaches Netz, in dem die Produktionszellen frei miteinander kommunizieren. Dringt ein Angreifer in eine Zelle ein, versucht er sich seitwärts auszubreiten. Das ist der Super-Gau, der regelmäßig in der Presse steht. Als Beispiel nennt der Vortrag den mehrwöchigen Produktionsausfall bei Jaguar (Land Rover) Ende 2025. Die Gegenmaßnahme ist (Mikro-)Segmentierung: Jede Zelle wird isoliert, sodass im schlimmsten Fall nur ein Prozess stoppt, nicht die ganze Produktion.

Je tiefer man in die OT kommt, desto schwieriger wird Security. Hier setzen mehrere praktische Bausteine an (im Vortrag am Fortinet-Portfolio gezeigt, das Prinzip gilt allgemein):

• Rugged-Hardware: robuste Geräte für raue Produktionsumgebungen (neben Standard- und virtuellen Appliances).
• Security auf Port-Level (FortiLink-Prinzip): Der Switch wird vom reinen „Durchreicher" zum Security-Device. Datenverkehr läuft über die Firewall und erhält so Funktionen wie Intrusion Detection direkt am Switch-Port.
• Deep Packet Inspection: Befehle und Werte werden geprüft. Beispiel: Eine Brauerei erlaubt nur Füllmengen von 330/500 ml; ein Befehl mit „335" wird geblockt, weil er den Vorgaben widerspricht.
• Virtuelles Patchen: Wo Anlagen 24/7 laufen und nur ein Wartungsfenster pro Jahr haben, erkennen IDS/IPS-Signaturen Ausnutzungsversuche und unterbinden die Kommunikation. Der eigentliche Patch kann später eingespielt werden.
• Sichere Fernwartung (PAM): Eine Secure-Remote-Access-/PAM-Lösung weist Nutzern gezielt Privilegien zu, routet bis auf die benötigte Applikation und zeichnet Sitzungen auf. Das wird unter NIS2 ausdrücklich gefordert.

Vereinfacht deckt Dragos die Detection ab, Fortinet Reaktion, Enforcement und Reporting. Über die Integration (u. a. FortiAnalyzer, FortiSIEM, FortiManager, FortiSOAR, FortiGate) lassen sich Assets abgleichen und auf Basis von Regeln automatische oder halbautomatische Policies auslösen: Der Analyst muss die Regel nicht mehr manuell bauen, sondern nur noch freigeben. FortiSOAR-Playbooks verarbeiten die Dragos-Informationen weiter. Umgekehrt kann Fortinet auch Datenlieferant für Dragos werden: Im Praxisfall einer spanischen Umspannstation (Substation) wird der Kollektor eingespart, indem Switch und FortiGate den relevanten Traffic per VXLAN over IPsec in ein Rechenzentrum spiegeln. Der Betreiber definiert dabei genau, welche Daten übergeben werden.