Was ist ein SOC für OT? Security Operations für die Betriebstechnik

Was macht ein SOC für OT?

Ein SOC für OT erfüllt dieselben vier Aufgaben wie jedes Security Operations Center – sehen, erkennen, reagieren, verbessern. Der Unterschied liegt in der Umgebung: Die „Endpunkte“ sind hier speicherprogrammierbare Steuerungen (SPS), Fernwirkstationen (RTU), Bedien- und Beobachtungsstationen (HMI), Engineering-Workstations und Historians in Leittechnik und Produktionsnetz.

1. Transparenz. Ein Inventar der OT-Assets, ihrer Firmware-Stände und Kommunikationsbeziehungen aufbauen und pflegen – größtenteils aus passiv mitgelesenem Netzwerkverkehr.
2. Angriffserkennung. Verhalten erkennen, das auf einen Angriff oder eine gefährliche Änderung hindeutet: eine neue Engineering-Verbindung zu einer SPS, ein unerwarteter Programm-Download, ein Schreibzugriff auf sicherheitsrelevante Parameter oder ein bekanntes ICS-Schadsoftwaremuster.
3. Reaktion. Alarme mit Prozesskontext bewerten, an die Leitwarte eskalieren und Eindämmungsmaßnahmen abstimmen, die weder Menschen noch Produktion gefährden.
4. Verbesserung. Erkenntnisse in Segmentierung, Fernwartungsregeln, Detektionsregeln und das Risikoregister des Betreibers zurückführen.

Damit ist ein OT-SOC der operative Kern der OT-Sicherheit: Es liefert die kontinuierliche Angriffserkennung, die Normen und Gesetze für kritische Betriebstechnik verlangen.

Welche Systeme überwacht ein OT-SOC?

Der Überwachungsbereich wird meist anhand des Purdue-Modells beschrieben. Ein OT-SOC konzentriert sich auf die Ebenen 1 bis 3 und die industrielle DMZ – dort, wo Angriffe auf Steuerungs- und Prozessleittechnik im Netzwerk sichtbar werden.

Typische Datenquellen sind:

• Passive Netzwerksensoren an SPAN-Ports oder Netzwerk-TAPs zwischen den Ebenen 1–2 und 2–3 sowie an der industriellen DMZ. Sie dekodieren industrielle Protokolle wie Modbus/TCP, S7comm, PROFINET, EtherNet/IP, DNP3, IEC 60870-5-104, IEC 61850 und OPC UA.
• Protokolle Windows-basierter OT-Systeme – Bedienstationen, Engineering-Workstations, Historians und Domänencontroller der OT-Domäne.
• Firewalls, Datendioden und Fernwartungs-Gateways, die die Conduits zwischen den Zonen absichern (in der Terminologie der IEC 62443).
• Änderungs- und Instandhaltungsinformationen aus dem Betrieb, damit ein geplanter SPS-Download nicht als Angriff gewertet wird.

Worin unterscheidet sich ein OT-SOC von einem IT-SOC?

Die Werkzeuge sehen ähnlich aus – SIEM, Fallmanagement, Threat Intelligence –, doch die Prioritäten sind umgekehrt. In der IT steht meist die Vertraulichkeit an erster Stelle, und ein infiziertes Notebook wird innerhalb von Minuten isoliert. In der OT haben Anlagensicherheit und Verfügbarkeit Vorrang: Wer die falsche Steuerung vom Netz nimmt, kann eine Produktionslinie stoppen oder einen gefährlichen Zustand herbeiführen.

Ausführlich behandeln wir die Unterschiede im Vergleich IT-SOC vs. OT-SOC.

Was erkennt ein OT-SOC?

Gute Angriffserkennung in der OT kombiniert drei Ansätze: Baselines für Assets und Verhalten (wer kommuniziert normalerweise wie mit wem), bedrohungsorientierte Use Cases, die auf MITRE ATT&CK for ICS abgebildet sind, und bekannte Indikatoren aus ICS-spezifischer Threat Intelligence. Beispiele für besonders wertvolle Use Cases:

• T0843 Program Download auf eine SPS außerhalb eines Wartungsfensters.
• T0836 Modify Parameter an Sollwerten oder Alarmgrenzen.
• T0855 Unauthorized Command Message, etwa ein Stopp-Befehl von einem unerwarteten System.
• T0886 Remote Services, genutzt von einem Dienstleisterkonto zu ungewöhnlicher Zeit.
• T0846 Remote System Discovery – Netzwerk-Scans innerhalb des Steuerungsnetzes.

Wie funktioniert Incident Response in der OT?

Die Vorfallsbehandlung folgt in der OT demselben Zyklus wie in der IT – vorbereiten, erkennen, eindämmen, bereinigen, wiederherstellen, lernen –, aber jeder Schritt wird mit den Verantwortlichen für den Prozess abgestimmt. Das DFIR-Rahmenwerk des NIST für OT (NISTIR 8428) ist dafür eine nützliche Referenz.

In der Praxis heißt das: eine benannte Ansprechperson in der Leitwarte für jeden Standort, vorab vereinbarte Eindämmungsoptionen je Zone (zum Beispiel den Fernwartungszugang zu schließen, statt eine Steuerung zu isolieren), ein Kommunikationsweg außerhalb der betroffenen Netze und geprüfte Sicherungen von SPS-Programmen und Konfigurationen.

Welche SOC-Modelle gibt es für die OT?

Forschende von SINTEF und NTNU unterscheiden fünf Modelle: ein integriertes IT/OT-SOC, ein dediziertes OT-SOC, ein internes SOC, ein ausgelagertes (Managed) SOC und ein herstellerbetriebenes SOC des Automatisierungslieferanten. Viele Organisationen kombinieren diese Modelle, etwa ein internes IT-SOC mit einem Managed Service für die OT-Angriffserkennung. Welche Variante passt, hängt von der Zahl der Standorte, der verfügbaren OT-Expertise und den regulatorischen Pflichten ab.

Welche Gesetze und Normen verlangen OT-Monitoring?

• § 31 Abs. 2 BSIG verpflichtet Betreiber kritischer Anlagen seit dem NIS2UmsuCG zum Einsatz von Systemen zur Angriffserkennung (SzA); die Pflicht bestand zuvor nach § 8a Abs. 1a BSIG a. F. seit dem 1. Mai 2023. Details: § 31 BSIG – Angriffserkennung in der OT.
• § 30 BSIG verlangt von besonders wichtigen und wichtigen Einrichtungen Risikomanagementmaßnahmen, darunter die Bewältigung von Sicherheitsvorfällen; § 32 BSIG regelt die Meldefristen von 24 Stunden, 72 Stunden und einem Monat.
• NIS2 (Richtlinie (EU) 2022/2555) ist die europäische Grundlage dieser Pflichten.
• IEC 62443-3-3 enthält Systemanforderungen zu Audit-Logs und kontinuierlicher Überwachung (SR 6.1 und SR 6.2).
• NIST SP 800-82 Rev. 3 empfiehlt kontinuierliches Monitoring und eine OT-spezifische Incident-Response-Fähigkeit.

Wie starten Sie mit einem SOC für OT?

1. Zuständigkeiten klären zwischen IT-Sicherheit und Betrieb – einschließlich der Frage, wer über Eindämmungsmaßnahmen entscheidet.
2. Das Netz kartieren nach Purdue-Ebenen sowie Zonen und Conduits gemäß IEC 62443 und die Sensorstandorte festlegen.
3. Passives Monitoring einführen, zuerst an den kritischsten Conduits, und dabei das Asset-Inventar aufbauen.
4. Erste Use Cases definieren (10–20), abgebildet auf MITRE ATT&CK for ICS, mit Reaktions-Playbooks je Standort.
5. Ein Betriebsmodell wählen – intern, Managed oder hybrid – und es in einer Tabletop-Übung mit der Leitwarte testen.