Im Ot Bereich: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Purple Teaming im OT-Umfeld folgt anderen Regeln als in klassischen Enterprise-Netzen. In Produktionsanlagen, Energieversorgung, Wasserwerken, Logistiksystemen oder Fertigungsstraßen steht nicht die maximale technische Tiefe eines Angriffs im Vordergrund, sondern die kontrollierte Verbesserung von Erkennung, Reaktion und Resilienz unter strikten Betriebsgrenzen. Wer OT wie ein normales Windows-Netz behandelt, erzeugt schnell Störungen, Prozessunterbrechungen oder im schlimmsten Fall Sicherheitsrisiken für Menschen, Umwelt und Anlagen.

Der Kern von Purple Teaming besteht darin, offensive und defensive Perspektiven in einem abgestimmten Ablauf zusammenzubringen. Im OT-Bereich bedeutet das: Angriffswege werden nicht nur simuliert, sondern gegen reale technische und organisatorische Restriktionen geprüft. Dazu gehören Legacy-Protokolle, proprietäre Steuerungen, unvollständige Asset-Transparenz, fehlende Agentenfähigkeit, lange Patchzyklen und hochsensible Prozessabhängigkeiten. Genau deshalb ist Purple Teaming in industriellen Umgebungen vor allem eine Disziplin der Präzision.

Ein sauberer OT-Purple-Teaming-Ansatz beantwortet drei Fragen gleichzeitig: Welche Angriffswege sind unter realen Bedingungen plausibel, welche Signale entstehen dabei tatsächlich in den vorhandenen Datenquellen, und welche Gegenmaßnahmen lassen sich umsetzen, ohne die Verfügbarkeit zu gefährden? Diese Kombination trennt belastbare Übungen von Showcases. In der Praxis scheitern viele Vorhaben nicht an fehlenden Tools, sondern an falschen Annahmen über das Zielsystem.

OT umfasst typischerweise mehrere Ebenen: Enterprise-IT, DMZ, Historian, Engineering-Stationen, HMI, SCADA, PLC, RTU, Safety-Systeme und Feldgeräte. Ein Angreifer bewegt sich selten direkt auf die SPS. Häufig beginnt der Pfad in der IT, etwa über kompromittierte Benutzerkonten, Fernwartungszugänge oder schlecht segmentierte Übergänge. Purple Teaming muss diese Übergänge sichtbar machen und darf sich nicht auf die letzte technische Stufe fokussieren. Wer nur SPS-Kommandos simuliert, aber den Weg dorthin ignoriert, trainiert am eigentlichen Risiko vorbei.

Im Unterschied zu reinem Red Teaming ist das Ziel nicht, möglichst unbemerkt maximal weit zu kommen. Stattdessen werden Hypothesen getestet: Erkennt das Monitoring eine ungewöhnliche Verbindung vom Engineering-Host in ein selten genutztes Zellnetz? Fällt eine Änderung an Projektdateien auf? Werden neue Sessions auf industriellen Protokollen korreliert? Wie reagiert das SOC, wenn IT- und OT-Indikatoren zusammen betrachtet werden? Der methodische Unterbau ähnelt dem aus Methodik und Workflow, muss aber im OT-Bereich deutlich restriktiver umgesetzt werden.

Ein weiterer Unterschied: In OT ist Erfolg nicht gleichbedeutend mit Exploitation. Bereits das kontrollierte Nachstellen eines Kommunikationsmusters, eines Authentifizierungsversuchs oder einer Projektdatei-Manipulation kann ausreichen, um Detection-Lücken aufzudecken. Die Übungstiefe wird durch Freigaben, Prozesskritikalität und Sicherheitsgrenzen bestimmt. Gute Teams definieren daher vorab, welche Aktionen nur emuliert, welche in Testumgebungen ausgeführt und welche im Produktivnetz strikt ausgeschlossen werden.

Der häufigste Fehler vor OT-Übungen ist ein technikzentrierter Start. Zuerst werden Frameworks, Sensoren oder Emulationswerkzeuge diskutiert, während die eigentlichen Betriebsgrenzen unklar bleiben. In industriellen Umgebungen muss die Vorbereitung mit Freigaben, Verantwortlichkeiten und No-Go-Zonen beginnen. Dazu zählen Safety-relevante Systeme, produktionskritische Zeitfenster, zulässige Kommunikationsmuster, Eskalationswege und Abbruchkriterien. Ohne diese Basis ist jede Übung fachlich schwach, selbst wenn sie technisch sauber aussieht.

Vor dem ersten Test braucht es ein belastbares Bild der Umgebung. Das bedeutet nicht zwingend vollständige Asset-Perfektion, aber mindestens eine arbeitsfähige Sicht auf Zonen, Übergänge, kritische Hosts, Fernwartung, Engineering-Systeme, Historian-Anbindungen und vorhandene Logging-Quellen. In vielen Anlagen existieren zwar Netzpläne, diese sind aber veraltet oder abstrahieren die Realität. Purple Teaming deckt solche Lücken schnell auf, wenn ein vermeintlich isoliertes Segment plötzlich doch über einen Wartungspfad erreichbar ist.

Besonders wichtig ist die Trennung zwischen produktionsnaher Validierung und risikofreier Reproduktion. Viele Techniken sollten zuerst in Laboren, Integrationsumgebungen oder digitalen Zwillingen geprüft werden. Das gilt vor allem für Protokollinteraktionen mit Modbus, DNP3, OPC, S7, EtherNet/IP oder proprietären Steuerungsprotokollen. Selbst scheinbar harmlose Scans können Geräte überlasten oder Kommunikationsfehler auslösen. Deshalb ist eine abgestufte Teststrategie Pflicht.

• Phase 1: Dokumenten- und Architekturabgleich mit OT-Betrieb, Netzwerk, Automatisierung und Security
• Phase 2: Validierung von Hypothesen in Labor, Staging oder isolierten Teilnetzen
• Phase 3: streng begrenzte Produktivtests mit klaren Freigaben, Beobachtung und Abbruchkriterien

Ein sauberer Scope beschreibt nicht nur Systeme, sondern auch erlaubte Wirkungen. Beispiel: Erlaubt ist das Nachstellen einer SMB-Authentifizierung von einer Engineering-Station zur Dateifreigabe, nicht erlaubt ist das Ausführen unbekannter Binärdateien auf dem Host. Erlaubt ist das Emulieren einer RDP-Anmeldung gegen einen Jump-Host, nicht erlaubt ist das Verändern von SPS-Logik. Solche Grenzen verhindern Missverständnisse zwischen Red-, Blue- und OT-Betrieb.

In der Praxis bewährt sich ein gemeinsames Kickoff mit Security, OT-Engineering, Netzwerk, Betrieb und gegebenenfalls Safety-Verantwortlichen. Dort werden Annahmen offen gelegt: Welche Datenquellen existieren wirklich? Welche Sensoren sehen Ost-West-Verkehr? Welche Systeme dürfen aktiv angesprochen werden? Welche Alarmierungen landen im SOC und welche nur lokal beim Betreiber? Diese Abstimmung ist enger als in vielen IT-Programmen und ähnelt eher einem kontrollierten Betriebsprojekt als einer klassischen Sicherheitsübung.

Wer Purple Teaming in Industrie und KRITIS aufbauen will, sollte die Besonderheiten aus Industrie, Kritis und Iec 62443 mitdenken. Gerade IEC 62443 hilft dabei, Zonen, Conduits, Rollen und Schutzanforderungen so zu strukturieren, dass Übungen nicht nur technisch interessant, sondern betrieblich verwertbar werden.

Die meisten relevanten OT-Szenarien beginnen nicht auf der SPS, sondern in angrenzenden Bereichen. Ein kompromittiertes Office-Konto, eine schwache VPN-Konfiguration, ein unsauber abgesicherter Fernwartungszugang oder ein gemeinsam genutzter Engineering-Account reichen oft aus, um sich schrittweise in Richtung OT zu bewegen. Purple Teaming sollte deshalb Angriffspfade entlang realer Vertrauensbeziehungen modellieren, nicht entlang spektakulärer Einzelfälle.

Ein typischer Pfad sieht so aus: Initial Access in der IT, Discovery auf administrativen Systemen, Zugriff auf Jump-Hosts oder Historian-Server, Missbrauch von Vertrauensstellungen, Bewegung in die OT-DMZ, Identifikation von Engineering-Workstations, Zugriff auf Projektdateien oder Rezepturen, anschließend Interaktion mit HMI oder Steuerungsmanagement. Nicht jeder Schritt muss technisch vollzogen werden. Entscheidend ist, welche Signale an jeder Stufe sichtbar werden und wo Kontrollen fehlen.

In OT sind Credentials oft langlebiger als in der IT. Service-Konten, lokal gespeicherte Zugangsdaten, gemeinsam genutzte Administratoren oder fest konfigurierte Verbindungen schaffen stabile Angriffsflächen. Dazu kommt, dass viele Systeme aus Betriebsgründen nur eingeschränkt gehärtet sind. Ein Purple-Teaming-Szenario sollte daher nicht nur Malware oder Exploits betrachten, sondern auch den Missbrauch legitimer Funktionen: Dateiübertragungen, Projekt-Uploads, Remote-Desktop, Engineering-Software, Backup-Mechanismen oder geplante Tasks.

Ein weiterer realistischer Pfad ist die Manipulation von Sichtbarkeit statt direkter Prozessänderung. Angreifer müssen nicht sofort Sollwerte verändern. Bereits das Unterdrücken von Alarmen, das Verändern von Historian-Daten, das Täuschen von HMI-Anzeigen oder das Stören von Kommunikationspfaden kann operative Entscheidungen beeinflussen. Für Purple Teaming ist das besonders wertvoll, weil solche Aktionen oft weniger riskant zu emulieren sind als direkte Steuerbefehle, aber dennoch erhebliche Detection-Lücken offenlegen.

Die Modellierung solcher Pfade profitiert von Threat Modeling und Und Mitre Attack. Wichtig ist jedoch, ATT&CK nicht mechanisch zu verwenden. Im OT-Bereich muss jede Technik gegen reale Architektur, Prozessabhängigkeit und Betriebsfreigabe gespiegelt werden. Eine Technik ist nur dann relevant, wenn sie im konkreten Umfeld plausibel, beobachtbar und sicher testbar ist.

Ein praxistaugliches Szenario beschreibt daher nicht nur Taktiken und Techniken, sondern auch den operativen Kontext: Welche Schicht wird berührt, welche Kommunikationsbeziehung wird genutzt, welche Datenquelle soll anschlagen, welche Reaktion wird erwartet, und welche maximale Wirkung ist zulässig? Diese Präzision verhindert, dass Purple Teaming in OT zu einer Sammlung lose verbundener Einzeltests verkommt.

Szenario: Missbrauch eines Engineering-Zugangs
Startpunkt: kompromittierter Jump-Host in der OT-DMZ
Ziel: Nachweis, ob Zugriff auf Engineering-Station erkannt wird
Erlaubte Aktion: Authentifizierungstest, Dateizugriff auf Projektverzeichnis, keine Logikänderung
Erwartete Telemetrie: Windows Security Logs, Jump-Host-Logs, Netzwerk-Metadaten, OT-Monitoring
Erwartete Reaktion: Alarmierung, Triage, Zuordnung zur Zone, Eskalation an OT-Betrieb
Abbruchkriterium: ungewöhnliche CPU-Last, Kommunikationsfehler, Bedienerhinweis aus Leitstand

Viele OT-Programme scheitern nicht an fehlenden Alarmen, sondern an fehlender Kontextualisierung. Ein einzelner Verbindungsaufbau auf Port 445 oder 3389 ist in der IT vielleicht Routine, in einer Produktionszelle aber hochgradig verdächtig. Umgekehrt kann industrieller Verkehr auf ungewöhnlichen Ports legitim sein, wenn Herstellerlösungen oder Altanlagen so arbeiten. Detection im OT-Bereich muss deshalb technische Signale mit Anlagenkontext verbinden.

Wirkungsvolle Purple-Teaming-Übungen prüfen nicht nur, ob ein Event erzeugt wird, sondern ob daraus ein verwertbarer Incident entsteht. Das umfasst Datenqualität, Zeitstempel, Asset-Zuordnung, Zonenkontext, Benutzerbezug, Korrelation mit Change-Fenstern und die Frage, ob das SOC die Bedeutung des Systems überhaupt erkennt. Ein Alarm auf einer Engineering-Station ist anders zu bewerten als derselbe Alarm auf einem Bürorechner.

Besonders relevant sind Datenquellen, die ohne invasive Agenten auskommen: SPAN/TAP-basierte Netzwerksicht, Firewall-Logs, Jump-Host-Logs, Windows-Events auf HMI- und Engineering-Systemen, Historian-Zugriffe, VPN-Logs, Authentifizierungsdaten und Change-Management-Informationen. In vielen OT-Umgebungen ist diese Telemetrie fragmentiert. Purple Teaming zeigt, wo Korrelationen fehlen und welche Signale zwar vorhanden, aber operativ unbrauchbar sind.

Ein häufiger Irrtum ist die Annahme, dass OT-Monitoring allein ausreicht. Tatsächlich entstehen viele frühe Indikatoren in IT-nahen Systemen: ungewöhnliche VPN-Nutzung, neue Admin-Sessions, Dateiübertragungen in die OT-DMZ, Änderungen an Backup-Shares oder verdächtige Prozesse auf Jump-Hosts. Erst die Verbindung mit OT-Sicht macht daraus ein belastbares Lagebild. Genau hier überschneiden sich Und Siem, Und Soc und Und Detection Engineering.

Gute Detection-Use-Cases in OT sind präzise formuliert. Nicht: "Erkenne laterale Bewegung". Sondern: "Alarmiere, wenn ein nicht freigegebener Host eine SMB-Session zu einer Engineering-Station aufbaut", oder: "Alarmiere, wenn außerhalb des Wartungsfensters ein Projektverzeichnis auf dem Engineering-Server gelesen wird". Solche Regeln sind enger, aber deutlich belastbarer. Sie reduzieren Rauschen und passen besser zu stabilen OT-Kommunikationsmustern.

Auch die Reaktion muss OT-tauglich sein. Ein automatisches Isolieren eines Hosts kann in der IT sinnvoll sein, in der Produktion aber Prozesse gefährden. Purple Teaming sollte deshalb Response-Entscheidungen mittrainieren: Wer darf eine Session trennen? Wann wird nur beobachtet? Wann wird der Leitstand informiert? Wann ist eine Safety-Bewertung nötig? Detection ohne abgestimmte Reaktion bleibt in OT unvollständig.

Der teuerste Fehler ist Scope-Unschärfe. Wenn unklar bleibt, welche Systeme aktiv getestet werden dürfen, welche nur beobachtet werden und welche tabu sind, entstehen operative Risiken und fachlich wertlose Ergebnisse. In OT reicht ein missverstandener Testschritt, um Bedienpersonal zu verunsichern oder Störungen auszulösen. Deshalb müssen Scope, Wirkgrenzen und Eskalationswege schriftlich und technisch eindeutig sein.

Ein zweiter Fehler ist das blinde Übertragen von IT-Playbooks. Aggressive Netzwerkscans, Credential-Dumping auf sensiblen Hosts, ungetestete EDR-Maßnahmen oder automatisierte Containment-Aktionen können in OT mehr Schaden anrichten als der simulierte Angriff selbst. Viele Altgeräte reagieren empfindlich auf ungewöhnliche Pakete, hohe Frequenzen oder Session-Muster. Was im Rechenzentrum banal ist, kann in einer Fertigungszelle problematisch sein.

Drittens wird häufig nur auf die "letzte Meile" geschaut. Teams wollen direkt industrielle Protokolle testen, obwohl die eigentlichen Schwächen in Fernwartung, Segmentierung, Identitätsmanagement oder Engineering-Workstations liegen. Das führt zu spektakulären, aber wenig relevanten Übungen. Realistische Angreifer nutzen den einfachsten gangbaren Weg. Purple Teaming muss genau diese Wege priorisieren.

• Fehler 1: aktive Tests ohne vorherige Validierung in Labor oder Staging
• Fehler 2: fehlende Einbindung von OT-Betrieb und Automatisierungstechnik
• Fehler 3: Alarmregeln ohne Asset- und Zonenkontext
• Fehler 4: Erfolgsmessung nur über Anzahl der Alerts statt über Reaktionsqualität
• Fehler 5: keine saubere Dokumentation von Annahmen, Grenzen und Beobachtungen

Ein weiterer häufiger Fehler ist die Verwechslung von Sichtbarkeit mit Sicherheit. Nur weil ein OT-Monitoring-System Protokolle dekodieren kann, bedeutet das nicht, dass relevante Angriffe erkannt werden. Ohne Baselines, Zonenkontext und abgestimmte Use-Cases bleibt die Erkennung oberflächlich. Purple Teaming muss deshalb immer auch die Qualität der Analyse prüfen: Wurde der Alarm richtig priorisiert? Wurde der betroffene Prozess erkannt? Wurde die richtige Fachstelle eingebunden?

Ebenso problematisch ist eine rein technische Nachbereitung. Wenn das Ergebnis nur aus Event-IDs, Paketmitschnitten und Tool-Outputs besteht, fehlt der betriebliche Mehrwert. OT-Verantwortliche brauchen Antworten auf konkrete Fragen: Welche Kommunikationsbeziehung war unnötig offen? Welcher Fernwartungsprozess ist riskant? Welche Erkennung ist mit vorhandenen Mitteln realistisch? Welche Maßnahme verbessert Sicherheit, ohne die Anlage zu destabilisieren? Genau an dieser Stelle helfen strukturierte Erkenntnisse aus Typische Fehler Beim Purple Teaming und Best Practices.

Schließlich wird oft zu selten iteriert. Eine einzelne Übung liefert Momentaufnahmen. OT-Umgebungen ändern sich durch Wartung, Lieferanten, Segmentierungsprojekte, neue Sensorik oder geänderte Betriebsprozesse. Purple Teaming muss wiederholt und angepasst werden. Sonst veralten Annahmen schneller als die Dokumentation.

Ein belastbarer OT-Workflow ist streng phasenorientiert. Zuerst werden Hypothesen formuliert, dann Datenquellen und Freigaben geprüft, anschließend erfolgt die technische Validierung in sicherer Umgebung, danach die begrenzte Durchführung im Zielkontext und zuletzt die gemeinsame Auswertung. Diese Reihenfolge ist nicht bürokratisch, sondern notwendig, um technische Erkenntnisse in betriebsfähige Maßnahmen zu übersetzen.

In der Planungsphase werden Szenarien priorisiert. Gute Kandidaten sind solche mit hoher Plausibilität und guter Beobachtbarkeit: Missbrauch von Fernwartung, Zugriff auf Engineering-Stationen, unzulässige Verbindungen zwischen Zonen, Manipulation von Projektdateien, verdächtige Nutzung administrativer Werkzeuge oder ungewöhnliche Historian-Abfragen. Szenarien mit potenzieller Prozesswirkung werden nur dann produktionsnah getestet, wenn die Wirkung sicher begrenzt werden kann.

Während der Durchführung braucht es einen klaren Kommunikationskanal zwischen Übungsteam, SOC und OT-Betrieb. Jede Aktion wird zeitlich markiert, damit Telemetrie sauber korreliert werden kann. Gleichzeitig darf die Übung nicht so transparent sein, dass jede Erkennung künstlich leicht wird. Ein praxistauglicher Mittelweg ist die Vorabfreigabe des Fensters bei gleichzeitiger Nichtoffenlegung einzelner Schritte an die Analysten.

Ein sauberer Ablauf orientiert sich an einem wiederholbaren Muster, wie es auch in Prozess, Ablauf und Playbook beschrieben wird, im OT-Kontext aber enger geführt werden muss. Besonders wichtig ist die Trennung zwischen Beobachtung, Emulation und Interaktion. Beobachtung bedeutet passives Sammeln und Korrelation. Emulation bedeutet das Nachstellen eines Verhaltens ohne volle technische Wirkung. Interaktion bedeutet echte Kommunikation mit Zielsystemen unter kontrollierten Grenzen.

OT-Purple-Teaming-Workflow
1. Zielbild definieren: Welche Fähigkeit soll geprüft werden?
2. Scope und No-Go-Zonen freigeben
3. Datenquellen und Verantwortliche bestätigen
4. Technik in Labor oder Staging validieren
5. Produktivfenster mit Beobachtung und Abbruchkriterien starten
6. Aktionen zeitlich markieren und dokumentieren
7. Detection, Triage und Eskalation live bewerten
8. Findings in Maßnahmen, Regeln und Prozessänderungen überführen
9. Re-Test mit angepassten Kontrollen durchführen

Entscheidend ist die Nachbereitung. Jede Beobachtung wird einer Kategorie zugeordnet: fehlende Sichtbarkeit, unzureichende Korrelation, falsche Priorisierung, unklare Zuständigkeit, riskante Architektur, unsaubere Fernwartung, unnötige Berechtigung oder fehlende Betriebsregel. Erst dadurch entstehen umsetzbare Maßnahmen. Reine Tool-Ergebnisse ohne diese Einordnung bleiben in OT meist folgenlos.

Ein guter Workflow endet nicht mit dem Report, sondern mit einem Re-Test. Detection-Regeln, Segmentierungsanpassungen, Jump-Host-Härtung oder geänderte Wartungsprozesse müssen erneut geprüft werden. Nur so wird aus einer Übung ein belastbarer Verbesserungszyklus.

Tools sind im OT-Bereich Mittel zum Zweck, nicht der Zweck selbst. Die Auswahl hängt von Architektur, Freigaben und gewünschter Testtiefe ab. Passive Netzwerksensorik, SIEM-Korrelation, Windows-Event-Analyse auf Engineering-Hosts, Jump-Host-Monitoring und kontrollierte Emulationswerkzeuge sind oft wertvoller als offensive Frameworks mit breitem Funktionsumfang. Gerade in produktionsnahen Umgebungen ist Zurückhaltung ein Qualitätsmerkmal.

Netzwerkbasierte OT-Sensoren liefern häufig die erste belastbare Sicht auf Zonen, Kommunikationsbeziehungen und Protokollnutzung. Ihr Nutzen steigt stark, wenn sie mit klassischen Security-Datenquellen korreliert werden. Ein Alarm über eine neue Modbus-Kommunikation ist deutlich aussagekräftiger, wenn parallel ein VPN-Login, eine neue Admin-Session und ein Dateizugriff auf dem Engineering-Share sichtbar sind. Deshalb sollte Werkzeugauswahl immer entlang des gesamten Signalpfads erfolgen.

Bei aktiven Werkzeugen gilt: Was in IT-Labs üblich ist, kann in OT unzulässig sein. Selbst bekannte Scanner oder Frameworks müssen mit konservativen Parametern, klaren Zielsystemen und vorab validierten Testmustern eingesetzt werden. Häufig reicht es, Netzwerkverhalten zu emulieren oder Authentifizierungs- und Dateizugriffe kontrolliert nachzustellen. Volle Exploitation ist selten notwendig, um Detection und Reaktion zu prüfen.

Für die Auswertung sind Plattformen hilfreich, die Zeitachsen, Asset-Kontext und Korrelation sauber abbilden. Das betrifft sowohl klassische Log-Plattformen als auch spezialisierte OT-Monitoring-Lösungen. Wer tiefer in Werkzeuglandschaften einsteigen will, findet angrenzende Themen unter Tools, Open Source Tools und Und Log Analyse. Im OT-Bereich zählt aber weniger die Anzahl der Werkzeuge als deren kontrollierte Einbettung in Freigaben, Beobachtung und Auswertung.

Auch EDR und XDR müssen differenziert betrachtet werden. Auf modernen Windows-basierten HMI- oder Engineering-Systemen können sie wertvoll sein, auf älteren oder herstellersensiblen Systemen jedoch problematisch. Purple Teaming sollte deshalb nicht pauschal "mehr Agenten" fordern, sondern prüfen, wo agentenbasierte Sicht sinnvoll, zulässig und stabil ist. In vielen Fällen entsteht die beste Abdeckung aus einer Kombination aus Netzwerkmetadaten, zentralen Logs und wenigen gezielt überwachten Schlüsselsystemen.

OT-Purple-Teaming ist nur dann wirksam, wenn Ergebnisse messbar in bessere Erkennung, klarere Prozesse und geringere operative Risiken überführt werden. Reine Aktivitätsmetriken wie Anzahl der Tests oder erzeugten Alerts sind dafür ungeeignet. Entscheidend ist, ob relevante Szenarien früher erkannt, besser eingeordnet und sicherer bearbeitet werden können.

Gute Metriken verbinden Technik und Betrieb. Dazu gehören Zeit bis zur Erkennung eines unzulässigen Zugriffs auf eine Engineering-Station, Qualität der Asset-Zuordnung im Alarm, Zeit bis zur Einbindung des OT-Betriebs, Anteil korrekt korrelierter IT-/OT-Signale, Anzahl unnötig offener Kommunikationsbeziehungen, Abdeckung priorisierter Angriffspfade und Erfolgsquote von Re-Tests nach umgesetzten Maßnahmen. Solche Kennzahlen sind anstrengender zu erheben, aber deutlich aussagekräftiger.

Reporting muss für mehrere Zielgruppen funktionieren. Analysten brauchen Rohdetails, Zeitstempel, Event-Ketten und Regelverhalten. OT-Betrieb braucht Auswirkungen auf Prozessnähe, Wartung, Segmentierung und Bedienbarkeit. Management braucht priorisierte Risiken, Aufwand-Nutzen-Abwägungen und klare Entscheidungen. Ein einziger Bericht ohne Zielgruppentrennung führt meist dazu, dass niemand wirklich damit arbeitet.

• Technische Findings: Datenquellen, Event-Ketten, Detection-Lücken, Fehlalarme, Reaktionsverhalten
• Betriebliche Findings: Prozessbezug, Freigabeprobleme, Kommunikationswege, Verantwortlichkeiten
• Maßnahmen: Regelanpassung, Segmentierung, Härtung, Fernwartungsprozess, Re-Test-Termin

Wichtig ist die Nachverfolgung. Jede Maßnahme braucht einen Owner, eine Frist, eine technische Prüfbarkeit und einen geplanten Re-Test. Ohne Re-Test bleibt unklar, ob eine neue Regel wirklich greift oder nur auf dem Papier existiert. Gerade in OT können Änderungen durch Herstellerrestriktionen, Wartungsfenster oder Betriebsprioritäten verzögert werden. Das muss im Reporting sichtbar sein.

Für strukturierte Nachbereitung sind Themen wie Reporting, Dokumentation und Erfolg Messen besonders relevant. Im OT-Kontext sollte jede Kennzahl jedoch an reale Betriebsfähigkeit gekoppelt sein. Eine Detection-Regel, die nur unter Laborbedingungen funktioniert oder im Schichtbetrieb niemandem zugeordnet werden kann, ist kein Fortschritt.

Reife OT-Programme arbeiten mit wiederkehrenden Szenarien. Dieselben Kernpfade werden in Intervallen erneut geprüft, ergänzt um neue Risiken aus Architekturänderungen, Lieferantenanbindungen oder Vorfällen. Dadurch entsteht Vergleichbarkeit über Zeit. Genau diese Wiederholbarkeit macht Purple Teaming im OT-Bereich zu einem Instrument der kontinuierlichen Verbesserung statt zu einer einmaligen Sonderaktion.

Die besten OT-Szenarien sind nicht die lautesten, sondern die mit hoher Realitätsnähe und klarer Auswertbarkeit. Ein Beispiel ist der Missbrauch eines Fernwartungszugangs außerhalb des Wartungsfensters. Hier lassen sich VPN-Logs, Jump-Host-Events, Session-Daten und OT-Kommunikation korrelieren, ohne direkt in Steuerungslogik einzugreifen. Das Szenario prüft Identitätsmanagement, Freigabeprozesse, Alarmierung und Eskalation gleichzeitig.

Ein zweites starkes Szenario ist der Zugriff auf Engineering-Projektdateien. Viele Anlagen hängen operativ an diesen Dateien, Rezepturen oder Konfigurationsständen. Schon das kontrollierte Lesen oder Kopieren aus einem unerwarteten Kontext kann zeigen, ob Dateizugriffe, Benutzerwechsel und Zonenverletzungen erkannt werden. Gleichzeitig bleibt die technische Wirkung begrenzt, solange keine Änderungen oder Uploads erfolgen.

Ein drittes Szenario betrifft ungewöhnliche Ost-West-Kommunikation innerhalb der OT. In stabilen Produktionsnetzen sind Kommunikationsmuster oft vorhersehbar. Wenn ein HMI plötzlich mit einem System spricht, das normalerweise nur von einer Engineering-Station angesprochen wird, ist das ein wertvoller Detection-Test. Solche Übungen sind besonders nützlich, um Segmentierungsregeln und Baselines zu validieren.

Auch Historian- und Datenintegritätsszenarien sind praxisnah. Nicht jede Bedrohung zielt auf direkte Prozessmanipulation. Das Verändern, Verzögern oder selektive Unterdrücken von Daten kann Entscheidungen im Betrieb beeinflussen. Purple Teaming kann hier prüfen, ob Anomalien in Datenflüssen, ungewöhnliche Abfragen oder Inkonsistenzen zwischen Quellen erkannt werden.

Wer Szenarien systematisch aufbauen will, kann sich an Szenarien, Use Cases und Real World Beispiele orientieren. Im OT-Bereich sollte jedes Szenario jedoch zusätzlich vier Fragen beantworten: Ist der Pfad realistisch, ist die Telemetrie vorhanden, ist die Wirkung begrenzbar und ist die Reaktion organisatorisch trainierbar? Fehlt eine dieser Bedingungen, sinkt der praktische Wert deutlich.

Beispielübung: Unzulässiger Zugriff auf Historian-Daten
Annahme: kompromittiertes Konto mit Zugriff auf OT-DMZ
Aktion: ungewöhnliche Abfrage außerhalb des Normalprofils
Ziel: Erkennung von Benutzeranomalie und Datenzugriff
Datenquellen: Authentifizierung, Historian-Logs, Netzwerk-Metadaten, SIEM
Erwartung: Alarm mit Asset-Kontext, Triage, Rückfrage an OT-Betrieb
Maßnahme nach Test: Baseline schärfen, Service-Konten trennen, Alarmregel anpassen

Praxisnahe Übungen sind selten spektakulär, aber hochwirksam. Sie verbessern genau die Fähigkeiten, die in realen Vorfällen zählen: frühe Erkennung, korrekte Einordnung, abgestimmte Reaktion und sichere Kommunikation zwischen Security und Betrieb.

Langfristig erfolgreich ist OT-Purple-Teaming nur dann, wenn es nicht als isolierte Sicherheitsübung betrieben wird. Es muss in Betriebsprozesse, Architekturentscheidungen, Wartungsmodelle, Lieferantensteuerung und Incident-Response eingebettet sein. Die technische Übung allein deckt Schwächen auf, beseitigt sie aber nicht. Erst wenn Findings in Segmentierung, Freigaben, Fernwartung, Identitätsmanagement und Monitoring einfließen, entsteht echte Resilienz.

Governance spielt dabei eine größere Rolle als oft angenommen. Wer darf Tests freigeben, wer bewertet Restrisiken, wer entscheidet über produktionsnahe Maßnahmen, und wie werden Hersteller oder Dienstleister eingebunden? Gerade in OT mit vielen externen Partnern ist diese Klärung entscheidend. Ein unsicherer Lieferantenzugang oder ein schlecht kontrollierter Wartungsprozess kann jede technische Härtung unterlaufen.

Ebenso wichtig ist die Zusammenarbeit zwischen SOC und OT-Betrieb. Analysten brauchen ein Verständnis dafür, welche Systeme prozesskritisch sind, welche Zeiten sensibel sind und welche Reaktionen betrieblich tragbar bleiben. Umgekehrt braucht der Betrieb Vertrauen in Security-Maßnahmen. Purple Teaming schafft dieses Vertrauen nur dann, wenn Übungen kontrolliert, transparent dokumentiert und fachlich sauber ausgewertet werden. Genau deshalb überschneidet sich OT-Purple-Teaming stark mit Collaboration, Communication und Integration.

Ein reifes Programm arbeitet risikobasiert. Nicht jede Anlage braucht dieselbe Tiefe, nicht jede Zone dieselben Kontrollen und nicht jeder Angriffspfad denselben Testaufwand. Kritische Prozesse, hohe Fremdzugriffsquote, schwache Segmentierung oder bekannte Legacy-Abhängigkeiten rechtfertigen häufigere und gezieltere Übungen. Weniger kritische Bereiche können mit leichteren Validierungen und längeren Intervallen auskommen.

Am Ende ist Purple Teaming im OT-Bereich eine Disziplin der kontrollierten Realität. Gute Teams simulieren nicht das maximal Mögliche, sondern das betrieblich Relevante. Sie messen nicht nur, ob ein Alarm erzeugt wurde, sondern ob die Organisation den Vorfall versteht und sicher handlungsfähig bleibt. Genau darin liegt der Unterschied zwischen einer technischen Demonstration und einem belastbaren Sicherheitsprogramm.

Wer OT-Purple-Teaming ernsthaft aufbauen will, sollte klein, präzise und wiederholbar starten: ein realistischer Angriffspfad, saubere Freigaben, klare Datenquellen, enge Beobachtung, konkrete Maßnahmen und ein geplanter Re-Test. Daraus entsteht Schritt für Schritt ein Programm, das Risiken reduziert, Detection verbessert und die Zusammenarbeit zwischen Security und Betrieb nachhaltig stärkt.