OT-SOC aufbauen: Angriffe in der Leittechnik erkennen
Wir bauen Ihr OT Security Operations Center auf: passive Sensorik an den richtigen Stellen, Use Cases für industrielle Protokolle, Playbooks für die Reaktion ohne Produktionsstopp. Den Betrieb übernimmt danach Ihr Team.
Sie würden nicht merken, wenn jemand im Netz ist
Firewalls, Segmentierung und gehärtete Zugänge verkleinern die Angriffsfläche. Lückenlos ist keine davon. Wer aber nicht erkennt, dass jemand im Netz ist, kann nicht reagieren.
Ein vorhandenes IT-SOC schließt diese Lücke nicht. Es erkennt Schadsoftware auf einem Server und eine Anmeldung aus dem falschen Land. Es erkennt nicht, dass über ein Fernwirkprotokoll ein Schaltbefehl kommt, zu einer Zeit, zu der niemand schaltet. Und es erkennt nicht, dass auf dem Prozessnetz ein Gerät antwortet, das dort nie eingebaut wurde. Solche Ereignisse sind protokollkonform. Auffällig werden sie erst vor dem Hintergrund des Normalbetriebs und den kennt ein IT-SOC nicht.
Drei Punkte, an denen ein OT-SOC scheitert
Nicht die Plattform ist das Schwierige, sondern diese drei und sie fallen alle in die Aufbauphase.
Sichtbarkeit ohne Eingriff
Monitoring darf den Prozess nicht berühren. Jede Diskussion über OT-Sensorik beginnt mit der Sorge, dass das Werkzeug selbst zur Störquelle wird. Ohne belegbare Antwort darauf kommt kein Projekt an der Anlagenverantwortung vorbei.
Use Cases, die es fertig nicht gibt
Für IT-Umgebungen liefern Hersteller Regelsätze mit. Für ein Umspannwerk, eine Fertigungszelle oder eine Stellwerksumgebung nicht. Wer keine eigenen Use Cases entwickeln kann, betreibt ein SIEM, das Logs sammelt und nichts erkennt.
Reaktion ohne Stillstand
Ein IT-Playbook isoliert das betroffene System. In OT bedeutet Isolation womöglich Produktionsstopp oder Versorgungsunterbrechung. Die Frage ist nicht, wie man abschaltet, sondern wie man eingrenzt, ohne abzuschalten.
Sichtbarkeit passiv herstellen
Die Sensorik liest ausschließlich mit. Kein Rückkanal, keine aktiven Abfragen, kein Eingriff in den Prozess. Wo das Signal abgegriffen wird, gehört trotzdem geprüft. Ein Spiegelport läuft über die CPU des Switches und kann unter Last selbst zur Störquelle werden. Ein passiver TAP koppelt das Signal physikalisch aus und hat diese Eigenschaft nicht. Deshalb legen wir für jeden Übergang vorher fest, was über einen TAP läuft und was über einen Spiegelport. Die Last des Switches halten wir dabei fest.
Aus dem Mitschnitt entsteht zuerst eine Baseline: welche Geräte miteinander sprechen, über welche Protokolle, in welchem Rhythmus. Erst darauf lässt sich eine Anomalie überhaupt definieren. Dazu kommen die Logs der Übergänge zwischen IT und OT, weil dort die Wege verlaufen, die in der Praxis genutzt werden.
Use Cases aus drei Quellen
Erstens aus MITRE ATT&CK for ICS, dem Taktik- und Technikmodell für industrielle Umgebungen: Zugriff über Fernwartung, Manipulation von Steuerbefehlen, Unterdrücken von Meldefunktionen. Wir bilden diese Techniken auf konkrete Regeln ab und messen, welcher Teil davon in Ihrer Umgebung überhaupt erkennbar wäre.
Zweitens aus dokumentierter OT-Schadsoftware. Industroyer manipuliert Schutzrelais über IEC 60870-5-104 und IEC 61850. TRITON greift Triconex-Safety-Systeme über ein proprietäres Protokoll an. PIPEDREAM ist modular gegen verschiedene Steuerungsplattformen einsetzbar. Jedes dieser Vorgehen lässt sich in Detektionsszenarien übersetzen.
Drittens aus unserer eigenen Prüfpraxis. Wir wissen, welche Angriffswege in OT-Umgebungen funktionieren und welche Spuren sie hinterlassen, weil wir sie selbst gegangen sind. Diese Quelle hat kein Hersteller.
Ein Use Case, von vorn bis hinten
Über Use Cases lässt sich viel schreiben. Überzeugend ist einer, der vollständig dasteht. Er nennt Auslöser, Quelle und Schwellwert. Dazu die Fehlalarme aus dem Betrieb und die Reaktion, die darauf folgt. Dieser hier fängt einen Befehl, der protokollkonform ist und trotzdem nicht sein darf.
| Feld | Inhalt |
|---|---|
| Auslöser | Ein Schreibbefehl auf eine Steuerung außerhalb der freigegebenen Schaltzeiten |
| Datenquelle | Passiver Mitschnitt am Übergang zur Prozessebene, ausgewertet durch das OT-IDS |
| Erkennungslogik | Funktionscode mit Schreibwirkung, Zielgerät aus der Zone Prozess, Zeitpunkt außerhalb des hinterlegten Fahrplans, Quelle nicht in der Liste der freigegebenen Engineering-Stationen |
| Schwellwert | Ein einziges Ereignis. Bei diesem Muster ist eine Häufung kein besseres Signal, sondern ein späteres |
| Typische Fehlalarme | Wartungsarbeiten ohne eingetragenes Fenster, ein Ersatzgerät mit alter Adresse, ein Testlauf nach einem Umbau |
| Reaktion | Leitwarte anrufen und fragen, ob gerade jemand schaltet. Erst danach Netzweg und Quelle prüfen. Kein automatisches Blockieren, weil ein Eingriff in ein Prozessnetz selbst zur Störung wird |
| Abdeckung | MITRE ATT&CK for ICS, Technikgruppe Manipulation des Prozesses |
Solche Regeln entstehen aus drei Quellen. Aus MITRE ATT&CK for ICS, aus dokumentierter Schadsoftware wie Industroyer, TRITON und PIPEDREAM. Dazu aus der eigenen Prüfpraxis, weil wir wissen, welche Spuren ein Angriffsweg hinterlässt. Getestet wird jede Regel vorher an eigener Hardware im Labor. Was dort nicht anschlägt, geht nicht in den Betrieb.
Playbooks, die den Betrieb kennen
Erkennung ohne Reaktion ist ein teures Protokoll. Die Playbooks beantworten deshalb die Fragen, die in IT-Playbooks fehlen: Lässt sich das betroffene System eingrenzen, ohne die Produktion zu stoppen. Wer entscheidet das, in welchem Zeitfenster. Wer muss wann informiert werden, intern und gegenüber der Aufsicht.
Geübt wird das vorher. Eine moderierte Notfallübung mit verteilten Rollen zeigt, an welcher Stelle der Prozess hakt. Solche Übungen führen wir auch in bestehenden Security Operations Centern durch.
Was Sie am Ende haben
Eine Fähigkeit, die bei Ihnen bleibt.
Sichtbarkeit
Ein Asset- und Kommunikationsbild Ihrer OT-Umgebung, erhoben über passive Sensorik. Sie wissen, welche Geräte miteinander sprechen, über welche Protokolle und in welchem Rhythmus.
Erkennung
Getunte Detektionsregeln und Use Cases, zugeschnitten auf Ihre Umgebung und Ihre Bedrohungslage, versioniert und gegen ihre Abdeckung gemessen.
Handlungsfähigkeit
Playbooks für die häufigsten Szenarien, ein geübtes Team und geklärte Eskalations- und Meldewege. Wir bauen auf, Ihr Team betreibt.
Systeme zur Angriffserkennung, kurz SzA
§ 31 Absatz 2 BSIG verlangt von Betreibern kritischer Anlagen Systeme zur Angriffserkennung. Der Nachweis gegenüber dem BSI steht in § 39 BSIG und ist alle drei Jahre fällig. Die Pflicht kam mit dem IT-Sicherheitsgesetz 2.0 und steht seit dem NIS2-Umsetzungsgesetz an dieser Stelle. Gemeint ist keine Produktkategorie, die sich kaufen lässt, sondern die Verbindung aus Sensorik, Auswertung, Regeln und der Reaktion darauf.
Ein IT-SIEM allein genügt dafür nicht. Es löst Modbus, S7comm oder IEC 60870-5-104 nicht auf und kennt den Normalbetrieb der Anlage nicht. Ohne den ist ein gültiger Befehl zur falschen Zeit unauffällig. Erkennung in der OT setzt deshalb auf einem OT-IDS auf, das die Industrieprotokolle liest. Dazu kommt Anomalieerkennung gegen eine Baseline, die den eingeschwungenen Zustand beschreibt.
| Was ein Prüfer sehen will | Woraus es entsteht |
|---|---|
| Welche Bereiche überhaupt beobachtet werden | Das Zonenmodell und die Liste der Übergänge, an denen mitgelesen wird |
| Womit beobachtet wird | Sensorik, Anbindung an das SIEM, Nachweis der Rückwirkungsfreiheit |
| Was als auffällig gilt | Die Use Cases, mit Auslöser, Datenquelle und Reaktion |
| Was tatsächlich erkannt wurde | Auswertungen aus dem Betrieb, nicht aus der Planung |
| Wie darauf reagiert wurde | Playbooks und die Protokolle abgearbeiteter Fälle |
| Dass es geübt ist | Der Bericht einer Übung mit verteilten Rollen |
Der Nachweis ist damit vor allem eine Dokumentationsaufgabe. Was die Aufsicht verlangt, entsteht als Nebenprodukt eines Aufbaus, der ohnehin geordnet läuft. Zur Reaktion gehört auch der Fall, in dem es ernst wird, also Incident Response mit einer Forensik, die mit Anlagen umgehen kann, die nicht abgeschaltet werden dürfen.
Wann ein SOC-Aufbau der richtige Schritt ist
Drei Anlässe führen üblicherweise hierher. Der erste ist die Detektionspflicht. § 31 Absatz 2 BSIG verlangt von Betreibern kritischer Anlagen Systeme zur Angriffserkennung. Der Nachweis gegenüber dem BSI steht in § 39 BSIG und ist alle drei Jahre fällig. Die Nachweispflicht bezieht die Automatisierung ausdrücklich ein.
Der zweite ist ein bestehendes IT-SOC, das um OT-Fähigkeiten erweitert werden soll. Die Schicht steht, die Prozesse stehen, aber IEC 60870-5-104, IEC 61850 mit MMS und GOOSE oder Modbus laufen an den vorhandenen Regeln vorbei. Hier geht es um Sensorik und Use Cases, nicht um den Aufbau einer zweiten Organisation.
Der dritte ist die Frage, ob überhaupt jemand im Netz ist. Wer sie nicht beantworten kann, fängt sinnvollerweise mit einem Assessment an: Es liefert die Anlagen- und Kommunikationsübersicht, auf der ein SOC-Aufbau aufsetzt.
Der Betrieb bleibt bei Ihnen
Wir haben Security Operations Center im Verkehrs- und Logistiksektor aufgebaut, seit 2019 im Betrieb. Dazu gehörten die Use-Case-Entwicklung als eigenes Team, das Onboarding von Mandanten und IT- wie OT-Datenquellen in denselben Auswertungen. Gearbeitet wird auf Splunk, Elastic und Microsoft Sentinel. Auf der Sensorikseite kommen Claroty, Nozomi Networks, Microsoft Defender for IoT und OMICRON StationGuard dazu. Welche Plattform es wird, entscheidet der Kunde. Zwei Beispiele finden Sie unten auf dieser Seite.
Regeln testen wir vorher an eigener Hardware. Im Labor stehen eine Modellstadt mit echter Fernwirk- und Stationstechnik, eine Siemens-Fertigungszelle und ein Zugmodell. Was dort nicht anschlägt, geht nicht in den Betrieb.
Dazu kommt die Forschungsseite. Im bundesgeförderten Verbundvorhaben FINESSE haben wir Angriffserkennung für Fahrzeugbusse und Diagnoseprotokolle entwickelt, dazu ein Security Event Center für den Einsatz an Bord. MITRE ATT&CK haben wir um Domänen erweitert, die es nicht abdeckte. Diese Erweiterung heißt VATT&EK. Die Ergebnisse sind bei ACM und IEEE veröffentlicht.
Wie ein Aufbau konkret beginnt
Beginnt mit der Frage, was überhaupt sichtbar ist.
Erstgespräch
Wir klären Umfang, vorhandene Datenquellen und regulatorische Randbedingungen. Falls noch kein Assessment vorliegt, sagen wir das offen: Ohne Asset-Inventar und Topologie fehlt die Grundlage für Sensorplatzierung.
Sichtbarkeitsprüfung
Ein passiver Mitschnitt an einem definierten Übergang zeigt, was heute erkennbar wäre und was nicht. Ergebnis ist eine Lückenliste, keine Produktempfehlung.
Sensorik und Datenquellen
Auswahl und Platzierung, Anbindung der Firewall-Logs an den IT/OT-Übergängen und der Telemetrie aus Engineering- und Leitsystemen.
Use Cases und Playbooks
Entwicklung, Test gegen die Baseline, Tuning. Parallel die Reaktionsprozesse und eine Übung, in der sie einmal durchlaufen werden.
Übergabe
Ihr Team betreibt, wir begleiten die ersten Wochen und schärfen nach, wo False Positives auftreten.
Was vor einem SOC-Aufbau gefragt wird
Das hängt davon ab, wo mitgelesen wird. Ein passiver TAP koppelt das Signal physikalisch aus und wirkt nicht auf den Prozess zurück. Ein Spiegelport läuft über die CPU des Switches und kann unter Last selbst stören. Wir klären für jeden Übergang vorher mit der Anlagenverantwortung, was wo angeschlossen wird.
Es ist eine gute Grundlage, deckt aber die OT-Ereignisse nicht ab. Der übliche Weg ist die Erweiterung um OT-Datenquellen und OT-Use-Cases, nicht der Aufbau eines zweiten SOC daneben.
Nein. Wir arbeiten auf den gängigen Plattformen. Die Entscheidung gehört zu Ihnen. Sie ist nicht der schwierige Teil.
Ihr Team. Unser Ziel ist ausdrücklich nicht, den Betrieb zu übernehmen, sondern Sie in die Lage zu versetzen, Ihre Infrastruktur selbst zu überwachen.
In der Regel ja. Es liefert Asset-Inventar und Netzwerktopologie, ohne die Sensorplatzierung Raten ist.
Zertifizierungen und Mitgliedschaften.
Sprechen Sie mit uns.
Ein erstes Gespräch dauert in der Regel 30 Minuten. Wir schauen uns Ihre Ausgangslage an und sagen offen, ob wir der passende Partner sind.