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 und in OT-Umgebungen bleiben Angreifer regelmäßig monatelang unbemerkt.
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, oder 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 hängt an einem Spiegelport und liest ausschließlich mit. Kein Rückkanal, keine aktiven Abfragen, kein Eingriff in den Prozess. Das ist die Antwort auf den ersten Einwand und sie muss technisch belegbar sein, nicht behauptet.
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 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 öffentlich analysierter Schadsoftware für industrielle Steuerungen, deren Vorgehen dokumentiert und in Detektionsszenarien übersetzbar ist.
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.
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 zuverlässig, wo 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.
Wann ein SOC-Aufbau der richtige Schritt ist
Drei Anlässe führen üblicherweise hierher. Der erste ist die Detektionspflicht: NIS-2 und das IT-Sicherheitsgesetz verlangen von Betreibern kritischer Infrastrukturen Systeme zur Angriffserkennung und 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 mehrere Security Operations Center im Verkehrs- und Logistiksektor aufgebaut, seit 2019 im Betrieb, mit Use-Case-Entwicklung als eigenem Team, Onboarding zahlreicher Mandanten und IT- wie OT-Datenquellen in denselben Auswertungen. Gearbeitet wird auf beiden gängigen Plattformen, weil die Wahl beim Kunden liegt. 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 die Forschungsseite: In einem vom Bund geförderten Verbundvorhaben haben wir Angriffserkennung für Fahrzeugbusse und Diagnoseprotokolle entwickelt, ein Security Event Center für den Einsatz an Bord und das gängige Taktik- und Technikmodell um Domänen erweitert, die es nicht abdeckte. 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
Nein, wenn sie passiv am Spiegelport hängt und keinen Rückkanal hat. Das ist technisch belegbar und der erste Punkt, den wir mit der Anlagenverantwortung klären.
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.