Industrie: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Purple Teaming in industriellen Umgebungen unterscheidet sich fundamental von Übungen in klassischen Office-, Web- oder Cloud-Landschaften. In OT-Netzen, Produktionslinien, Prozessleitsystemen und ICS-Architekturen ist das Ziel nicht, möglichst spektakulär einzudringen, sondern Sicherheitskontrollen unter realistischen Bedingungen zu validieren, ohne Verfügbarkeit, Safety oder Prozessstabilität zu gefährden. Genau an diesem Punkt scheitern viele Teams: Sie übertragen IT-Pentest-Denken direkt auf Produktionsumgebungen und unterschätzen die betrieblichen Abhängigkeiten.

Industrieanlagen bestehen selten aus homogenen, modernen Systemen. Typisch sind gewachsene Netzsegmente, proprietäre Protokolle, alte Windows-Systeme, Engineering-Workstations, HMI-Server, Historian-Systeme, Fernwartungszugänge, SPSen, Safety-Komponenten und externe Dienstleister mit privilegiertem Zugriff. Purple Teaming muss diese Realität abbilden. Es geht darum, Angriffswege nachvollziehbar zu simulieren und parallel zu prüfen, ob Logging, Alarmierung, Segmentierung, Zugriffskontrollen und Incident-Response-Prozesse tatsächlich funktionieren.

Der operative Mehrwert entsteht nicht durch einen einzelnen Angriffsschritt, sondern durch die enge Kopplung von Angriffssimulation und Verteidigungsverbesserung. Deshalb ist Purple Teaming in der Industrie vor allem eine Validierungsmethode für Erkennungsfähigkeit, Reaktionsfähigkeit und technische Resilienz. Wer nur Payloads ausführt, ohne Telemetrie, Freigaben, Safety-Grenzen und Prozessauswirkungen zu berücksichtigen, betreibt kein belastbares Purple Teaming, sondern erhöht das Risiko ungeplanter Störungen.

In OT-Umgebungen ist die wichtigste Grundregel: Jede Aktivität muss anlagenschonend, reversibel und nachvollziehbar sein. Das betrifft Scans, Authentifizierungsversuche, Protokollinteraktionen, Host-Artefakte und Netzwerkverkehr. Selbst harmlose Maßnahmen aus der IT können in der Produktion unerwartete Effekte auslösen, etwa durch fragile Geräte-Stacks, ungetestete Broadcast-Last oder schlecht dokumentierte Abhängigkeiten zwischen Engineering-Station und Steuerungsebene.

Ein industrielles Purple-Team-Programm beginnt daher nicht mit Tools, sondern mit Scope, Betriebsfreigabe, Asset-Kritikalität und klaren Abbruchkriterien. Erst danach folgen Taktiken, Techniken und Telemetrieziele. Wer die Grundlagen von Was Ist Purple Teaming und die Unterschiede zu klassischen Teammodellen sauber einordnen will, sollte außerdem den Purple Teaming Vergleich kennen. In der Industrie ist diese Abgrenzung besonders relevant, weil Rollen, Verantwortlichkeiten und Freigabeprozesse deutlich strenger sind als in Standard-IT.

Der größte Denkfehler in Industrieprojekten besteht darin, OT wie ein langsameres IT-Netz zu behandeln. Tatsächlich gelten andere Prioritäten. In Office-Umgebungen steht häufig Vertraulichkeit im Vordergrund. In der Industrie dominieren Verfügbarkeit, Integrität von Prozessdaten und Safety. Ein Security-Test, der einen Domain Controller kurz belastet, ist in der IT oft beherrschbar. Ein vergleichbarer Fehler an einer Engineering-Station, einem OPC-Server oder einer HMI-Komponente kann Produktionsstillstand, Qualitätsprobleme oder im schlimmsten Fall sicherheitsrelevante Zustände auslösen.

Hinzu kommt, dass industrielle Kommunikation oft nicht für aggressive Sicherheitsprüfungen entworfen wurde. Protokolle wie Modbus, DNP3, Profinet, EtherNet/IP oder OPC-Varianten verhalten sich je nach Implementierung empfindlich. Viele Geräte liefern kaum aussagekräftige Logs, manche Systeme reagieren auf ungewöhnliche Sequenzen mit Neustarts oder Kommunikationsabbrüchen. Purple Teaming muss deshalb mit einem tiefen Verständnis der Anlage durchgeführt werden: Welche Systeme dürfen aktiv angesprochen werden, welche nur passiv beobachtet, welche gar nicht?

Ein weiterer Unterschied ist die Lebensdauer der Systeme. In Produktionsumgebungen laufen Komponenten oft zehn bis zwanzig Jahre oder länger. Patching ist selten trivial, weil Herstellerfreigaben, Wartungsfenster und Prozessabhängigkeiten berücksichtigt werden müssen. Daraus folgt: Detection und Kompensation sind in der Industrie oft wichtiger als die naive Forderung nach sofortigem Patchen. Purple Teaming liefert genau hier belastbare Erkenntnisse, indem es zeigt, welche Angriffsaktivitäten trotz Altlasten erkennbar sind und wo blinde Flecken bestehen.

Auch die Netzarchitektur ist meist komplexer als die Dokumentation vermuten lässt. Zwischen Office-IT, DMZ, Historian, Jump Hosts, Fernwartung, Produktionszellen und Safety-Netzen existieren häufig Sonderwege, temporäre Freischaltungen oder inoffizielle Betriebspraktiken. Ein sauberer Workflow muss diese Realität aufnehmen, statt sich auf idealisierte Netzwerkdiagramme zu verlassen. Gerade in der Industrie ist die Differenz zwischen dokumentierter und tatsächlicher Architektur oft der entscheidende Risikofaktor.

• Verfügbarkeit und Safety haben Vorrang vor aggressiver Testtiefe.
• Jede Technik muss auf Prozessverträglichkeit und Rückbaubarkeit geprüft werden.
• Erfolg wird nicht an Exploits gemessen, sondern an validierter Detection und belastbarer Reaktion.

Deshalb ist Purple Teaming im OT-Bereich eng mit Architekturverständnis, Betriebsabstimmung und Detection Engineering verknüpft. Wer industrielle Besonderheiten ignoriert, produziert entweder wertlose Ergebnisse oder unnötige Risiken. Ergänzend lohnt der Blick auf Im Ot Bereich und Und Mitre Attack, weil dort die technische Strukturierung von Szenarien und Techniken besonders greifbar wird.

In der Praxis entscheidet die Vorbereitungsphase darüber, ob ein Purple-Teaming-Vorhaben verwertbar ist. Ein industrieller Scope darf nie nur aus IP-Bereichen bestehen. Er muss Betriebsziele, kritische Assets, verbotene Aktionen, zulässige Zeitfenster, Eskalationswege und technische Schutzgrenzen enthalten. Besonders wichtig ist die Trennung zwischen Beobachtung, Interaktion und Veränderung. Viele Probleme entstehen, weil diese Stufen nicht sauber definiert werden.

Ein belastbarer Scope beantwortet mindestens folgende Fragen: Welche Produktionslinien sind betroffen? Welche Systeme sind nur passiv zu analysieren? Welche Authentifizierungsversuche sind zulässig? Dürfen Konfigurationen gelesen werden? Dürfen Services neu gestartet werden? Sind Protokoll-Reads erlaubt, aber keine Writes? Welche Fernwartungszugänge dürfen simuliert werden? Welche Alarme müssen vorab an Betrieb und Leitwarte kommuniziert werden? Ohne diese Präzision wird aus einer Sicherheitsübung schnell ein Betriebsrisiko.

Ebenso wichtig ist die Rollenklärung. In industriellen Purple-Team-Übungen arbeiten nicht nur Red und Blue Team zusammen. Hinzu kommen OT-Betrieb, Automatisierungstechnik, Netzwerkverantwortliche, Safety-Verantwortliche, externe Integratoren und häufig auch Hersteller. Diese Beteiligten müssen nicht alle im Detail jede Technik verstehen, aber sie müssen wissen, wann welche Aktivität stattfindet, welche Auswirkungen möglich sind und wann ein Test sofort gestoppt wird.

Ein professioneller Ablauf orientiert sich an einem klaren Prozess: Zieldefinition, Asset-Validierung, Telemetrieprüfung, Dry Run, kontrollierte Durchführung, gemeinsame Auswertung, Detection-Tuning, Retest. Gerade der Dry Run wird oft unterschätzt. Dabei wird nicht der Angriff geprobt, sondern die sichere Durchführung: Kommunikationskanäle, Notfallkontakte, Logging-Verfügbarkeit, Snapshot- oder Backup-Status, Monitoring der Produktionsparameter und Abbruchmechanismen.

In vielen Industrieprojekten ist es sinnvoll, mit einer read-only Phase zu starten. Zuerst wird geprüft, welche Logs vorhanden sind, welche Netzwerkdaten sichtbar werden, wie EDR oder NDR reagieren und ob das SOC OT-Ereignisse überhaupt korrekt einordnet. Erst danach folgen vorsichtige Interaktionen. Diese Reihenfolge reduziert Risiko und erhöht die Aussagekraft der Ergebnisse, weil früh sichtbar wird, ob die Verteidigung schon an einfachen Signalen scheitert.

Beispiel für einen sicheren Freigabe-Workflow:

1. Zielsysteme und Kritikalität bestätigen
2. Verbotene Aktionen schriftlich festlegen
3. Wartungsfenster und Ansprechpartner definieren
4. Logging- und Monitoring-Pfade vorab testen
5. Abbruchkriterien technisch und organisatorisch abstimmen
6. Testschritte in risikoarme und risikoreichere Phasen trennen
7. Nach jeder Phase Go/No-Go Entscheidung treffen

Wer industrielle Übungen ohne diese Disziplin startet, produziert meist hektische Ad-hoc-Entscheidungen. Genau daraus entstehen Fehlalarme, unvollständige Daten und Diskussionen darüber, ob ein Testschritt überhaupt freigegeben war. Saubere Purple-Team-Arbeit ist in der Industrie immer auch saubere Betriebskoordination.

Die meisten industriellen Szenarien beginnen nicht direkt an der SPS. Realistische Angriffspfade starten typischerweise in der IT oder an Übergangspunkten: kompromittierte Benutzerkonten, schlecht abgesicherte VPN-Zugänge, Fernwartungslösungen, Jump Hosts, Historian-Verbindungen, Engineering-Laptops oder gemeinsam genutzte Administrationskonten. Purple Teaming sollte diese Wege priorisieren, weil sie in echten Vorfällen deutlich häufiger relevant sind als exotische Direktangriffe auf Feldgeräte.

Ein typisches Szenario ist der Missbrauch eines Fernwartungszugangs. Der Angreifer gelangt über gültige Zugangsdaten oder schwache Zugriffskontrollen auf einen Jump Host, bewegt sich von dort zu einer Engineering-Station und versucht anschließend, Konfigurationsdaten, Projektdateien oder Kommunikationsbeziehungen zu verstehen. In einer Purple-Team-Übung wird nicht blind eskaliert, sondern jeder Schritt gegen vorhandene Kontrollen geprüft: Wird der Login erkannt? Wird die ungewöhnliche Quell-IP alarmiert? Ist die Session-Aufzeichnung aktiv? Werden Dateioperationen auf Engineering-Systemen protokolliert? Erkennt das SOC die Bewegung Richtung OT?

Ein weiteres realistisches Muster ist die Nutzung legitimer Werkzeuge. In Industrieumgebungen sind Living-off-the-Land-Techniken besonders relevant, weil aggressive Malware-Simulationen oft nicht zulässig sind. PowerShell, WMI, PsExec-ähnliche Mechanismen, RDP, SMB, geplante Tasks oder Hersteller-Tools können ausreichen, um Detection-Lücken sichtbar zu machen. Der Wert der Übung liegt darin, zu zeigen, welche legitimen Verwaltungsaktionen in welchem Kontext verdächtig werden müssen.

Auch die Übergänge zwischen IT und OT sind ein zentrales Testfeld. Viele Organisationen glauben, ihre Segmentierung sei stark, bis eine Purple-Team-Übung zeigt, dass Historian-Server, Patch-Management-Wege, Backup-Systeme oder Monitoring-Komponenten unerwartete Brücken bilden. Solche Erkenntnisse sind besonders wertvoll, weil sie nicht nur einzelne Schwachstellen, sondern strukturelle Vertrauensbeziehungen offenlegen.

• Fernwartung und Drittzugriffe sind häufigere Einstiegspunkte als direkte SPS-Angriffe.
• Engineering-Workstations sind oft sicherheitskritischer als auf den ersten Blick erkennbar.
• Legitime Admin-Werkzeuge erzeugen in OT oft die realistischeren Detection-Tests als laute Exploit-Methoden.

Für die Szenarioauswahl lohnt sich ein Blick auf Szenarien, Real World Beispiele und Threat Modeling. In der Industrie müssen Szenarien nicht maximal komplex sein. Sie müssen glaubwürdig, betrieblich vertretbar und messbar sein.

Viele Industrieunternehmen investieren in SIEM, EDR, NDR oder XDR und erwarten danach automatisch belastbare Erkennung. In der Praxis bleibt die Detection dennoch schwach, weil Datenquellen unvollständig, Zeitstempel inkonsistent, Asset-Kontexte unklar und Use Cases nicht auf OT-Prozesse abgestimmt sind. Purple Teaming deckt diese Lücken schonungslos auf, weil es nicht fragt, ob ein Tool vorhanden ist, sondern ob ein konkreter Angriffsschritt sichtbar, verständlich und bearbeitbar wird.

Ein klassisches Beispiel: Ein Login auf einem Jump Host wird im SIEM erfasst, aber ohne Zuordnung zu Schichtbetrieb, Wartungsfenster oder externer Dienstleisterrolle. Technisch existiert ein Event, operativ ist es wertlos. Ähnlich problematisch sind EDR-Installationen auf wenigen Windows-Systemen, während zentrale OT-Komponenten, Netzwerkübergänge oder proprietäre Systeme praktisch unsichtbar bleiben. Das Ergebnis ist eine Scheinsicherheit, die erst in einer Purple-Team-Übung auffällt.

Gute Detection in der Industrie basiert auf Korrelation. Einzelne Events reichen selten aus. Erst die Kombination aus Benutzerkontext, Asset-Kritikalität, Kommunikationsrichtung, Zeitfenster und Prozessbezug macht aus Telemetrie eine verwertbare Warnung. Deshalb ist Purple Teaming eng mit Und Detection Engineering, Und Log Analyse und Und Alerting verbunden.

Ein weiterer Fehler ist die Übertragung klassischer IT-Use-Cases auf OT. Ein Portscan-Alarm mag in der Office-IT sinnvoll sein, in der Industrie ist oft relevanter, wenn ein Engineering-Host außerhalb des Wartungsfensters mit mehreren Steuerungssegmenten kommuniziert oder wenn ein Fernwartungskonto plötzlich auf Systeme zugreift, die nicht zum üblichen Verantwortungsbereich gehören. Purple Teaming hilft dabei, solche kontextbasierten Erkennungsregeln aus realen Betriebsabläufen abzuleiten.

Auch die Reaktionskette muss geprüft werden. Ein Alarm ist nur dann nützlich, wenn das SOC oder der OT-Betrieb daraus eine handlungsfähige Entscheidung ableiten kann. Wer darf eine Session trennen? Wer bewertet, ob eine Engineering-Aktivität legitim ist? Wie wird zwischen Wartung und Missbrauch unterschieden? Ohne diese Antworten bleibt Detection ein Dashboard-Thema ohne operative Wirkung.

Beispiel für eine OT-nahe Detection-Hypothese:

Wenn ein externes Wartungskonto
- außerhalb des freigegebenen Zeitfensters
- über einen Jump Host
- auf eine Engineering-Workstation zugreift
- und anschließend Dateioperationen in Projektverzeichnissen ausführt,

dann muss ein priorisierter Alarm mit Asset-Kontext,
Benutzerrolle und Eskalationspfad erzeugt werden.

Solche Hypothesen sind deutlich wertvoller als generische Signaturen. Sie verbinden Technik mit Betriebsrealität und lassen sich in Purple-Team-Iterationen sauber testen, verbessern und erneut validieren.

Die häufigsten Fehler sind nicht technisch spektakulär, sondern organisatorisch und methodisch. Der erste große Fehler ist ein zu aggressiver Scope. Wenn Teams ohne OT-Abstimmung Scans, Authentifizierungsversuche oder Payloads einsetzen, gefährden sie Stabilität und verlieren sofort das Vertrauen des Betriebs. Der zweite Fehler ist ein zu enger Scope, bei dem nur harmlose Demo-Schritte erlaubt sind. Dann entsteht kein realistisches Bild der Verteidigungsfähigkeit.

Ein weiterer Klassiker ist die Verwechslung von Sichtbarkeit mit Sicherheit. Nur weil ein SIEM Daten empfängt oder ein EDR Agent installiert ist, bedeutet das nicht, dass relevante Angriffsschritte erkannt werden. Purple Teaming zeigt oft, dass Logs zwar vorhanden sind, aber nicht korreliert, nicht priorisiert oder nicht verstanden werden. Ebenso problematisch ist die Annahme, dass Herstellerdokumentation die tatsächliche Architektur widerspiegelt. In Industrieumgebungen existieren fast immer Ausnahmen, Altverbindungen und historisch gewachsene Sonderlösungen.

Viele Teams scheitern auch an der Kommunikation. Red Team, Blue Team, OT-Betrieb und Management sprechen oft unterschiedliche Sprachen. Das Red Team denkt in Techniken, das SOC in Events, der Betrieb in Verfügbarkeit und das Management in Risiko. Wenn diese Perspektiven nicht zusammengeführt werden, endet die Übung in isolierten Findings statt in umsetzbaren Verbesserungen. Genau deshalb sind Collaboration und Communication in der Industrie keine weichen Themen, sondern operative Voraussetzungen.

Ein besonders teurer Fehler ist das Auslassen des Retests. Nach der ersten Runde werden Regeln angepasst, Segmentierungen nachgeschärft oder Alarmierungen verändert. Wenn diese Änderungen nicht erneut gegen dasselbe Szenario validiert werden, bleibt unklar, ob die Verbesserung tatsächlich wirkt oder nur auf dem Papier existiert. Purple Teaming ist kein Einmalprojekt, sondern ein iterativer Verbesserungsprozess.

• Zu laute Tests ohne OT-Freigabe erzeugen Risiko und zerstören Akzeptanz.
• Zu harmlose Tests liefern keine belastbare Aussage über Detection und Reaktion.
• Ohne Retest bleiben Verbesserungen unbewiesen.

Wer diese Fehler systematisch vermeiden will, sollte sich mit Typische Fehler Beim Purple Teaming, Best Practices und Iteration beschäftigen. In industriellen Umgebungen ist methodische Disziplin oft wichtiger als technische Kreativität.

Frameworks sind in der Industrie nützlich, solange sie nicht als Ersatz für echte Tests missverstanden werden. MITRE ATT&CK hilft bei der Strukturierung von Taktiken und Techniken, insbesondere wenn IT- und OT-nahe Angriffsschritte sauber gemappt werden sollen. IEC 62443 liefert einen belastbaren Rahmen für industrielle Sicherheitszonen, Rollen, Anforderungen und Schutzmaßnahmen. KRITIS-Vorgaben schärfen den Blick für Nachweisbarkeit, Resilienz und organisatorische Reife. Aber kein Framework beantwortet automatisch die Frage, ob eine konkrete Engineering-Station verdächtige Dateioperationen erkennt oder ob ein Fernwartungszugang im richtigen Kontext alarmiert wird.

Der praktische Nutzen entsteht erst durch die Übersetzung in testbare Hypothesen. Statt abstrakt zu sagen, dass laterale Bewegung relevant ist, wird konkret geprüft, ob eine Bewegung vom Jump Host zur Engineering-Workstation sichtbar ist. Statt allgemein Segmentierung zu fordern, wird getestet, welche Kommunikationspfade tatsächlich offen sind. Statt nur Compliance-Anforderungen abzuhaken, wird validiert, ob die vorhandenen Kontrollen im Ernstfall tragfähig sind.

Gerade in regulierten Umgebungen ist diese Verbindung entscheidend. Auditorisch saubere Dokumentation und operative Wirksamkeit sind nicht dasselbe. Ein Unternehmen kann formal gute Richtlinien besitzen und trotzdem bei einer realistischen Purple-Team-Übung an banalen Übergängen zwischen IT und OT scheitern. Umgekehrt können technisch starke Teams ihre Wirksamkeit oft nicht sauber nachweisen, wenn Mapping, Dokumentation und Metriken fehlen.

Deshalb sollte jede industrielle Purple-Team-Übung drei Ebenen verbinden: Technik, Prozess und Nachweis. Technik bedeutet konkrete Angriffsschritte und Telemetrie. Prozess bedeutet Freigaben, Eskalation, Reaktion und Zusammenarbeit. Nachweis bedeutet Mapping auf Anforderungen, dokumentierte Ergebnisse und nachvollziehbare Verbesserungen. Diese Verbindung ist besonders relevant bei Iec 62443, Kritis und Mitre Attack Mapping.

Ein reifes Team nutzt Frameworks als gemeinsame Sprache, nicht als Selbstzweck. Das reduziert Missverständnisse zwischen Security, OT-Betrieb und Management und macht Ergebnisse vergleichbar. Die eigentliche Qualität entsteht aber erst im Test: Welche Technik wurde simuliert, welche Daten waren sichtbar, welcher Alarm entstand, wie schnell wurde reagiert, welche Lücke blieb offen?

In industriellen Purple-Team-Übungen ist Tool-Auswahl kein Selbstzweck. Entscheidend ist, ob ein Werkzeug kontrollierbar, nachvollziehbar und für die Zielumgebung verträglich ist. Ein Netzwerktool, das in der IT unauffällig arbeitet, kann in OT zu viel Last erzeugen. Ein Agent, der auf einem Standardserver problemlos läuft, kann auf einer alten HMI-Plattform unerwartete Nebeneffekte haben. Deshalb müssen Werkzeuge nicht nur funktional, sondern betrieblich bewertet werden.

Für viele Übungen reichen einfache Mittel: gezielte Authentifizierungsereignisse, kontrollierte Dateioperationen, definierte Remote-Zugriffe, simulierte Benutzeraktionen, Netzwerkverbindungen mit klarer Signatur oder harmlose Befehlsausführungen auf freigegebenen Testsystemen. Der Mehrwert entsteht aus der Beobachtung dieser Schritte, nicht aus maximaler Komplexität. In OT ist weniger oft mehr, solange die Technik realistisch genug ist, um Detection und Reaktion zu prüfen.

Wichtig ist außerdem die Trennung von Produktions- und Referenzsystemen. Wo immer möglich, sollten riskantere Schritte zuerst in einer repräsentativen Testumgebung validiert werden. Doch auch das hat Grenzen: Viele OT-Labore bilden die Realität nur teilweise ab. Deshalb muss klar dokumentiert werden, welche Erkenntnisse aus dem Labor stammen und welche in der Produktion unter kontrollierten Bedingungen bestätigt wurden.

Ein professionelles Team definiert vorab Stop-Kriterien. Dazu gehören unerwartete CPU-Last auf kritischen Hosts, Kommunikationsabbrüche, Alarmzustände in der Anlage, Fehlverhalten von HMI oder Historian, unzulässige Prozesswerte oder Anzeichen dafür, dass ein Testschritt anders wirkt als geplant. Stop-Kriterien sind keine Formalität, sondern ein Sicherheitsmechanismus. Wer sie nicht ernst nimmt, handelt fahrlässig.

Beispiel für technische Stop-Kriterien:

- Verlust der Kommunikation zu kritischen OT-Assets
- Unerwarteter Neustart oder Freeze eines HMI-/Engineering-Systems
- Auffällige Prozesswertabweichungen
- Nicht freigegebene Schreiboperation auf Steuerungsebene
- Monitoring-Ausfall während eines aktiven Testschritts

Bei der Werkzeugauswahl helfen strukturierte Übersichten wie Tools, Open Source Tools oder Automation Tools. In der Industrie gilt jedoch: Das beste Tool ist das, dessen Wirkung vollständig verstanden und sicher begrenzt werden kann.

Der eigentliche Wert industriellen Purple Teamings zeigt sich nach der Durchführung. Wenn Ergebnisse nur als Liste technischer Beobachtungen dokumentiert werden, fehlt der operative Nutzen. Gute Berichte verbinden Angriffspfad, betroffene Assets, beobachtete Telemetrie, Alarmqualität, Reaktionsverhalten, Prozessauswirkung und konkrete Verbesserungsmaßnahmen. Entscheidend ist die Frage: Was muss sich im Betrieb ändern, damit derselbe Pfad künftig früher erkannt oder wirksamer unterbunden wird?

Ein belastbares Reporting trennt dabei sauber zwischen Schwachstelle, Detection-Lücke, Prozesslücke und Architekturproblem. Beispiel: Ein externer Wartungszugang ohne starke Kontextprüfung ist nicht nur ein IAM-Thema. Wenn der Zugriff zwar protokolliert, aber nicht priorisiert wird, liegt zusätzlich eine Detection-Lücke vor. Wenn das SOC den Alarm nicht an den OT-Betrieb eskalieren kann, existiert eine Prozesslücke. Wenn der Jump Host zu viele Segmente erreicht, kommt ein Architekturproblem hinzu. Erst diese Differenzierung macht Maßnahmen wirksam.

Ebenso wichtig sind Metriken. In der Industrie sind nicht nur klassische Kennzahlen wie Time to Detect oder Time to Respond relevant. Hinzu kommen Kontextmetriken: Anteil kritischer Assets mit verwertbarer Telemetrie, Abdeckung definierter Fernwartungs-Use-Cases, Qualität der Asset-Zuordnung, Zahl der getesteten Übergänge zwischen IT und OT, Anteil erfolgreich retesteter Verbesserungen. Solche Kennzahlen zeigen echte Reife statt bloßer Aktivität.

Retests sind der Punkt, an dem sich Professionalität von Aktionismus trennt. Nach jeder Verbesserung muss geprüft werden, ob sie unter denselben Bedingungen funktioniert. Nur so lässt sich verhindern, dass neue Regeln zu laut, zu unpräzise oder betrieblich unbrauchbar sind. Gerade in OT ist ein schlecht abgestimmter Alarm fast so problematisch wie gar kein Alarm, weil er Vertrauen in das Monitoring untergräbt.

Für die Verstetigung im Unternehmen sind Reporting, Dokumentation, Metriken und Erfolg Messen zentrale Bausteine. Purple Teaming in der Industrie ist dann reif, wenn Ergebnisse nicht in Präsentationen enden, sondern in Betriebsstandards, Detection-Use-Cases, Freigabeprozesse und Architekturentscheidungen einfließen.

Langfristig entsteht so ein belastbarer Lernzyklus: Szenario auswählen, sicher durchführen, Detection validieren, Reaktion prüfen, Maßnahmen umsetzen, erneut testen. Genau dieser Zyklus erhöht die Resilienz industrieller Umgebungen deutlich stärker als punktuelle Einzeltests ohne Rückkopplung in den Betrieb.