Die Trennung zwischen IT und OT war lange Zeit eine Sicherheitsmaßnahme, die physisch und prozessual umgesetzt wurde. Produktionsanlagen waren isoliert, Änderungen waren selten und Fernzugriffe die Ausnahme. Die Realität heute sieht anders aus: Fernwartung, standortübergreifende Produktionssteuerung, Datenflüsse in MES und ERP sowie Cloud-basierte Auswertung von Maschinen- und Qualitätsdaten haben die OT in die Wertschöpfungs-IT integriert. In vielen Werken existieren heute Mischformen aus klassischen Zellen, Industrial Ethernet, Edge-Gateways und virtualisierten Servern für Steuerungsnahes. Genau hier beginnt die neue Angriffsfläche.

Für Security-Teams bedeutet das: OT ist nicht mehr ‚ein separates Netzwerk‘, sondern ein Teil der unternehmenskritischen digitalen Lieferkette. Wer moderne Resilienz erreichen will, muss Schwachstellenmanagement, Sicherheitsbetrieb und Incident Response über diese Grenze hinweg denken.

Dass OT-Security in vielen Organisationen hinter IT-Security zurückfällt, hat häufig strukturelle Gründe:

1. Zuständigkeiten und Prioritäten: Produktion, Engineering und IT verfolgen unterschiedliche Ziele. Verfügbarkeit schlägt Veränderung, stabile Prozesse schlagen schnelle Updates. Das ist rational, erzeugt aber Reibung, wenn Security wie in der IT mit Patch-Rhythmen und Standard-Hardening argumentiert.
2. Technische Hürden: OT-Assets sind heterogen, Lebenszyklen sind lang und Protokolle sind speziell. Ohne passive Netzwerksicht und Asset-Inventarisierung bleiben zentrale Informationen unsichtbar. Dabei kann es sich etwa um unbekannte Steuerungen und Engineering Stationen, reale Kommunikationsbeziehungen in der Produktion sowie um Abweichungen vom Normalbetrieb handeln, die auf Manipulation oder laterale Bewegungen hindeuten.
3. Fehlender Kontext im SOC: Selbst, wenn Security-Events vorhanden sind, fehlen dem SOC oft Expertise hinsichtlich der OT und ihrer Bedeutung. Ein ungewöhnlicher Schreibzugriff auf einen Engineering-Host ist in der IT zunächst nur ein Vorfall. In der OT kann er ein Produktionsstillstand in Vorbereitung sein.

Maschinen als Teil der Angriffskette

Angriffe auf Produktionsumgebungen beginnen meist banal, wie die folgenden, beispielhaften Szenarien zeigen:

• Szenario 1: Phishing als Türöffner, OT als Impact
  Ein Mitarbeitender klickt auf einen Link, Credentials werden abgegriffen oder ein Gerät wird kompromittiert. Der Angreifer bewegt sich lateral, sammelt Privilegien und sucht nach Systemen, die den Übergang in produktionsnahe Bereiche ermöglichen: Jump Hosts, Remote Access Server, Historian-Datenbanken, Engineering Workstations. Ab diesem Moment sind klassische IT-Signale für das Team des Unternehmens zwar sichtbar, aber die OT-Ziele liegen oft außerhalb des Sensorfelds. Hier entscheidet die Netzwerktelemetrie in den OT-Segmenten, ob die Bewegung früh erkannt wird.
• Szenario 2: Manipulation statt Zerstörung
  In der OT ist eine zunächst unauffällige Vorgehensweise für die Angreifer oft wertvoller als sofortige Verschlüsselung. Sie verändern Parameter, beeinflussen Rezepturen oder stören Messketten. Das Ergebnis ist nicht zwingend ein sofortiger Stillstand, sondern die Erzeugung von Ausschuss, Qualitätsabweichungen oder versteckten Prozessrisiken. Solche Muster lassen sich nicht allein über Endpoint-Signaturen erkennen. Entscheidend sind Abweichungen im Kommunikationsverhalten und in OT-Protokollen, kombiniert mit Kontext aus Identitäten und Change-Fenstern.
• Szenario 3: Laterale Bewegung in Richtung Safety
  Der öffentlich bekannte ‚Triton‘- beziehungsweise ‚Trisis‘-Vorfall hat gezeigt, dass Angreifer in der Lage sein können, sogar Safety-Instrumented-Systeme ins Visier zu nehmen. Das ist zwar kein weit verbreitetes Szenario, aber es ist ein Lehrstück für die Sicherheitsarchitektur: Wenn Angreifer lange genug unentdeckt bleiben, erreichen sie auch hochkritische Zonen.

Diese Muster sind in ‚MITRE ATT&CK for ICS‘ als Techniken und Taktiken systematisiert. Damit können SOC-Teams Use Cases entlang nachvollziehbarer Angriffspfade entwickeln, statt Detektionslogiken isoliert oder nach Bauchgefühl aufzubauen.

Grenzen klassischer SOC-Umgebungen

Microsoft-basierte SOC-Umgebungen sind in der IT oft sehr gut aufgestellt: Identitäten, Endpoints, E-Mail-Security und Cloud-Workloads lassen sich zentral überwachen und mit Korrelationen und Automatisierung bearbeiten. Der blinde Fleck entsteht dort, wo OT-Kommunikation stattfindet.

Es gibt drei typische Lücken:

• Viele OT-Geräte tauchen nicht als verwaltete Endpoints auf (Asset-Sicht).
• Industrielle Protokolle und zyklische Kommunikationsmuster werden ohne OT-Netzwerküberwachung nicht interpretiert (Protokoll-Sicht).
• Ein Ereignis bekommt erst dann Priorität, wenn es in OT-Bedeutung übersetzt wird (Kontext-Sicht).

Die Schlussfolgerung daraus ist nicht, das Tool zu ersetzen. Stattdessen sollte die vorhandene SOC-Logik um OT-Sichtbarkeit erweitert werden.

Ein hybrides SOC ist keine Tool-Sammlung. Es ist vielmehr ein Betriebsmodell, das Telemetrie zusammenführt, korreliert und handlungsfähig macht. In der Praxis hat sich eine Schichtenarchitektur bewährt:

1. IT-Schicht: Identitäten, E-Mail, Endpoints: Hier entstehen die meisten ‚Initial Access‘-Signale. Identity-Anomalien, verdächtige Mail-Klickpfade, Endpoint-Alerts und Privilege Escalation sind die Frühindikatoren.

2. Infrastruktur-Schicht: Server, Netzwerk, Remote Access: Diese Schicht bildet den Übergang in produktionsnahe Systeme ab: Virtualisierung, Jump Hosts, VPN-Gateways, Bastion-Hosts und zentrale Dienste wie DNS.

3 . OT-Schicht: Passive Sensorik und Netzwerküberwachung: In OT-Segmenten ist passive oder auch ‚agentless‘ Überwachung oft der praktikabelste Einstieg. SPAN-Ports oder TAPs liefern Verkehrsmuster, aus denen sich Assets, Kommunikationsbeziehungen und Protokollnutzung ableiten lassen. Entscheidend ist, dass OT-Events in ein SOC-fähiges Format überführt werden.

4. Korrelation und Priorisierung im SOC: Hier entsteht der Mehrwert: Ein einzelner Alarm ist selten entscheidend. Entscheidend ist vielmehr die Kette. Beispiele für eine belastbare Korrelation sind:

• kompromittierte Identität in M365
• Anmeldung auf Jump Host außerhalb üblicher Zeiten
• neuer Netzwerkfluss vom Jump Host in ein OT-Segment
• Zugriff auf Engineering-Station oder SPS-nahen Server

So ergibt sich aus mehreren Einzelsignalen das Gesamtbild eines zusammenhängenden Angriffsszenarios und ein klar priorisierter Vorfall.

In hybriden Umgebungen ist also die Entscheidungsrelevanz von Alerts die zentrale Kennzahl, nicht deren bloße Menge. Ein sinnvoller Ansatz ist daher, Use Cases so zu bauen, dass sie OT-Kontext liefern: Welche Anlage, welche Linie, welches Zeitfenster, welche erlaubten Kommunikationsbeziehungen sind involviert? Erst auf dieser Basis kann ein Analyst priorisieren, statt zu raten.

Modularer Schutz

Der Autor: Tizian Kohler ist Head of Security des IT-Beratungsunternehmens Adlon. © Adlon

Produktionsverantwortliche akzeptieren Security-Maßnahmen, wenn sie zwei Kriterien erfüllen: geringe Eingriffsrisiken und klarer Nutzen. Ein modularer Ansatz unterstützt das:

• Passives Monitoring und Asset Transparenz als Basis, ohne Produktionsstillstand.
• Segmentierung, Remote-Access-Härtung und Use-Case-Korrelation als nächste Stufe.
• Priorisierung über Ketten reduziert die Alarmflut.
• Playbooks können IT- und OT-Schritte verbinden, zum Beispiel Identität sperren und gleichzeitig OT-Zugriffspfade isolieren.

Sobald OT-Events gemeinsam mit Identity- und Endpoint-Signalen in einem einheitlichen Entscheidungsfluss verarbeitet werden, reduziert sich in hybriden SOC-Setups die Reaktionszeit. Entscheidend ist die gemeinsame Priorisierung.

Redaktion: Inka Krischke