Kritis: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

In Kritischen Infrastrukturen gelten andere Spielregeln als in klassischen Office-, Web- oder Cloud-Umgebungen. Stromversorgung, Wasser, Gesundheit, Transport, Telekommunikation oder industrielle Versorgungsnetze arbeiten mit Systemen, bei denen Verfügbarkeit, Prozessstabilität und Safety oft höher priorisiert sind als aggressive Sicherheitsmaßnahmen. Genau deshalb muss Purple Teaming in KRITIS anders geplant, anders durchgeführt und anders ausgewertet werden.

Der Kern von Purple Teaming bleibt gleich: Angriffe werden kontrolliert simuliert, Blue-Team-Fähigkeiten werden parallel geprüft, Detection-Lücken werden sichtbar gemacht und direkt verbessert. In KRITIS reicht es aber nicht, einzelne Taktiken auszuführen und zu prüfen, ob ein Alert ausgelöst wurde. Entscheidend ist, ob die Übung den realen Betriebszustand respektiert, ob OT- und IT-Abhängigkeiten verstanden wurden und ob jede Aktion technisch wie organisatorisch abgesichert ist.

Viele Teams übernehmen Methoden aus Enterprise-Netzen unverändert in KRITIS-Umgebungen. Das führt zu gefährlichen Fehlannahmen. Ein Portscan, der in einer Büro-IT harmlos wirkt, kann auf älteren Embedded-Komponenten, Feldgeräten oder proprietären Gateways unerwartete Seiteneffekte auslösen. Ein Credential-Test gegen einen Domänencontroller mag in der IT vertretbar sein, kann aber in einer segmentübergreifenden Umgebung Kaskadeneffekte auf Historian, Engineering-Station oder Leitwarte haben. Purple Teaming in KRITIS verlangt deshalb ein präzises Verständnis von Zonen, Kommunikationspfaden, Wartungsfenstern, Safety-Grenzen und Eskalationswegen.

Ein weiterer Unterschied liegt in der Zielsetzung. In klassischen Purple-Team-Übungen steht oft die Verbesserung von Detection und Response im Vordergrund. In KRITIS kommt eine zusätzliche Ebene hinzu: die Absicherung betrieblicher Kernprozesse gegen Störung, Manipulation und verdeckte Beeinflussung. Nicht jede erfolgreiche Erkennung ist automatisch ein Erfolg, wenn die Erkennung erst nach Prozessbeeinträchtigung greift. Gute Übungen prüfen daher nicht nur, ob ein Angriff gesehen wird, sondern ob er früh genug, im richtigen Kontext und mit handlungsfähigen Informationen erkannt wird.

Wer die Grundlagen sauber einordnen will, findet ergänzende Perspektiven unter Was Ist Purple Teaming und Im Ot Bereich. Für KRITIS ist besonders wichtig, dass Purple Teaming nicht als Show-Exercise verstanden wird, sondern als kontrollierter Verbesserungsprozess mit klaren technischen Grenzen.

Eine belastbare KRITIS-Übung beginnt immer mit der Frage: Welche Systeme dürfen niemals aktiv beeinflusst werden, welche dürfen nur passiv beobachtet werden und welche können in einer isolierten oder abgestimmten Form realistisch getestet werden? Erst danach folgen Technik, Tools und TTPs. Wer diese Reihenfolge umdreht, produziert keine belastbaren Ergebnisse, sondern unnötiges Risiko.

Schwache Purple-Team-Übungen scheitern selten an fehlenden Tools. Sie scheitern an unklaren Zielen. In KRITIS ist das besonders kritisch, weil unpräzise Zieldefinitionen schnell zu unnötigen Aktionen führen. Ein realistisches Ziel ist nicht „Lateral Movement testen“, sondern zum Beispiel: Kann das SOC erkennen, wenn ein kompromittierter IT-Admin-Account über einen erlaubten Wartungspfad in Richtung OT pivotiert? Oder: Werden verdächtige Änderungen an Engineering-Artefakten, Rezepturen oder Konfigurationsdateien erkannt, bevor sie produktiv wirksam werden?

Gute Ziele orientieren sich an realen Angreiferpfaden, vorhandenen Schutzmaßnahmen und betrieblichen Auswirkungen. Dazu gehört die Trennung zwischen IT-zentrierten und OT-nahen Fragestellungen. Ein IT-zentriertes Ziel kann Credential Access, Remote Service Abuse oder Missbrauch von Jump Hosts betreffen. Ein OT-nahes Ziel kann die Erkennung ungewöhnlicher Schreibzugriffe, Engineering-Änderungen, Firmware-Transfers oder untypischer Kommunikationsmuster zwischen Segmenten betreffen.

In der Praxis haben sich vier Zielkategorien bewährt: Erstens die Validierung von Sichtbarkeit, also ob relevante Telemetrie überhaupt vorhanden ist. Zweitens die Validierung von Erkennungslogik, also ob aus Telemetrie ein belastbarer Alarm entsteht. Drittens die Validierung operativer Reaktion, also ob SOC, OT-Betrieb und Incident Response abgestimmt handeln können. Viertens die Validierung von Schutzgrenzen, also ob Segmentierung, Freigaben und administrative Prozesse tatsächlich das verhindern, was sie verhindern sollen.

• Technische Ziele: Telemetrie, Detection, Korrelation, Forensikfähigkeit
• Prozessziele: Eskalation, Freigabewege, Schichtübergaben, Kommunikationsketten
• Betriebsziele: Verfügbarkeit, Safety, Wiederanlauf, Einfluss auf Kernprozesse

Diese Zielkategorien müssen vor der Übung priorisiert werden. Nicht jede Übung darf alles gleichzeitig abdecken. In KRITIS ist ein enger Scope oft besser als ein breiter. Ein sauber abgegrenztes Szenario liefert verwertbare Ergebnisse, während ein überladener Scope meist nur Alarmrauschen, Unsicherheit und unvollständige Erkenntnisse erzeugt.

Hilfreich ist die Verbindung mit Und Mitre Attack und Threat Modeling. Dadurch wird aus einer allgemeinen Sicherheitsübung ein nachvollziehbarer Test gegen konkrete Bedrohungsannahmen. Besonders in KRITIS muss jede Technik auf Relevanz geprüft werden: Nicht jede bekannte TTP ist für die eigene Umgebung plausibel, aber jede plausible TTP sollte gegen vorhandene Kontrollen validiert werden.

Ein häufiger Fehler ist die Vermischung von Audit-Zielen, Pentest-Zielen und Purple-Team-Zielen. Ein Audit prüft Konformität, ein Pentest sucht Schwachstellen und ein Purple-Team-Engagement validiert Erkennung und Reaktion entlang realistischer Angriffspfade. Diese Unterschiede müssen im Vorfeld klar sein, sonst entstehen falsche Erwartungen an Ergebnis, Tiefe und Risiko. Ergänzend dazu lohnt sich der Blick auf Vs Penetrationstest, wenn die Abgrenzung im Unternehmen unscharf ist.

Ohne belastbares Architekturverständnis ist Purple Teaming in KRITIS blind. Gemeint ist nicht nur ein Netzplan mit Segmenten, sondern ein operatives Modell der Umgebung: Welche Systeme steuern Prozesse, welche sammeln Daten, welche dienen der Fernwartung, welche Systeme sind für Authentisierung zuständig und welche Verbindungen existieren nur in Ausnahmefällen? Gerade diese Ausnahmepfade sind oft sicherheitskritisch, weil sie selten überwacht und schlecht dokumentiert sind.

Typische Übergänge zwischen IT und OT entstehen über Jump Hosts, Historian-Systeme, Patch- und Update-Server, Backup-Infrastrukturen, Fernwartungszugänge, Engineering-Workstations und Identitätsdienste. In vielen Umgebungen ist die Segmentierung auf dem Papier sauber, in der Praxis aber durch operative Sonderregeln aufgeweicht. Purple Teaming muss genau diese realen Übergänge prüfen. Ein Angreifer nutzt nicht die Architekturzeichnung, sondern den Pfad, der tatsächlich funktioniert.

Besonders relevant sind implizite Vertrauensbeziehungen. Dazu zählen Service-Accounts mit weitreichenden Rechten, gemeinsam genutzte Administrator-Konten, veraltete Protokolle ohne starke Authentisierung, unkontrollierte Dateifreigaben oder Wartungszugänge mit schwacher Protokollierung. In KRITIS sind solche Konstrukte oft historisch gewachsen. Sie existieren nicht aus Nachlässigkeit, sondern weil Betrieb, Herstellerabhängigkeit und Verfügbarkeitsanforderungen lange Vorrang hatten. Genau deshalb müssen Übungen realistisch und respektvoll mit diesen Altlasten umgehen.

Ein sauberes Vorab-Mapping beantwortet unter anderem folgende Fragen: Welche Logquellen decken die Übergänge zwischen IT und OT ab? Welche Systeme liefern Prozesskontext, damit ein Alarm fachlich eingeordnet werden kann? Welche Aktionen sind in Produktionszeiten tabu? Welche Systeme dürfen nur in einer Labor- oder Staging-Umgebung geprüft werden? Welche Herstellerfreigaben oder Betriebsfreigaben sind erforderlich?

In vielen Fällen lohnt sich eine methodische Vorbereitung über Methodik und Workflow. Für KRITIS ist dabei entscheidend, dass technische Tests nie losgelöst vom Betriebsmodell geplant werden. Ein Beispiel: Das Ausführen eines harmlos wirkenden Discovery-Befehls auf einer Engineering-Station kann unkritisch sein, solange keine aktive Kommunikation zu Steuerungskomponenten ausgelöst wird. Derselbe Schritt kann aber problematisch werden, wenn lokale Agenten, Monitoring-Tools oder Sicherheitsprodukte darauf mit automatisierten Folgeaktionen reagieren.

Architekturverständnis bedeutet auch, Datenflüsse zu verstehen. Wenn ein SIEM nur IT-Logs erhält, aber keine OT-nahen Ereignisse, dann wird ein lateraler Übergang möglicherweise nur als gewöhnliche Admin-Aktivität erscheinen. Wenn EDR auf Servern vorhanden ist, aber nicht auf spezialisierten OT-Systemen, entsteht eine Sichtbarkeitslücke genau dort, wo Angreifer nach dem Pivot landen wollen. Purple Teaming deckt diese Lücken nur dann auf, wenn die Übung bewusst an den Übergängen ansetzt und nicht nur innerhalb eines einzelnen Segments bleibt.

Ein häufiger Irrtum besteht darin, Purple Teaming über Tools zu definieren. In KRITIS ist das besonders gefährlich. Nicht das Werkzeug bestimmt den Wert der Übung, sondern die Qualität des Szenarios. Ein realistisches Szenario bildet einen plausiblen Angreiferpfad ab, berücksichtigt vorhandene Schutzmaßnahmen und endet nicht bei der ersten Erkennung, sondern bei der Frage, ob die Organisation die Lage korrekt versteht und wirksam handeln kann.

Ein starkes KRITIS-Szenario beginnt oft in der IT, weil dort Initial Access realistischer und sicherer simuliert werden kann. Von dort aus wird geprüft, ob ein Angreifer über administrative Pfade, schwache Segmentierung, missbrauchbare Vertrauensstellungen oder unzureichend überwachte Wartungszugänge in sensible Bereiche gelangt. Die Übung muss nicht zwingend bis zur Prozessbeeinflussung gehen. Häufig reicht es, den letzten technisch sicheren Punkt vor einer kritischen Aktion zu erreichen und dort Detection, Kontextanreicherung und Reaktionsfähigkeit zu validieren.

Beispiele für belastbare Szenarien sind kompromittierte Fernwartung, Missbrauch eines Backup-Systems als Transitpunkt, Credential Reuse zwischen IT und OT-nahen Systemen, Manipulation von Konfigurationsdateien auf Engineering-Stationen, unautorisierte Nutzung administrativer Remote-Dienste oder verdeckte Datensammlung über Historian- und Management-Systeme. Solche Szenarien sind deutlich wertvoller als generische Malware-Simulationen ohne Bezug zur eigenen Umgebung.

Wer Inspiration für Szenarioaufbau sucht, kann Szenarien, Use Cases und Real World Beispiele heranziehen. Entscheidend bleibt aber die Anpassung an die eigene Architektur. Ein Szenario ist nur dann brauchbar, wenn es reale Betriebswege, reale Kontrollen und reale Reaktionsketten abbildet.

Ein praxisnahes Beispiel: In einer Energie- oder Versorgungsumgebung existiert ein Jump Host für externe Dienstleister. Die Übung simuliert den Missbrauch eines legitimen Wartungsfensters. Das Red-seitige Team nutzt keine exotischen Exploits, sondern arbeitet mit erlaubten Protokollen, gültigen Zugangsdaten und unauffälligen Zeitfenstern. Das Blue Team muss erkennen, dass zwar formal autorisierte Zugriffe stattfinden, das Verhalten aber vom üblichen Muster abweicht: andere Zielsysteme, andere Befehlsfolgen, ungewöhnliche Dateitransfers, atypische Uhrzeiten oder fehlende Ticket-Referenzen. Genau solche Unterschiede entscheiden in KRITIS über die Qualität der Erkennung.

Ein zweites Beispiel betrifft die Manipulation von Betriebsdaten statt direkter Prozesssteuerung. Angreifer verändern keine Steuerlogik, sondern beeinflussen Datenquellen, Dashboards oder Alarmgrenzen. Das Ziel ist nicht sofortige Sabotage, sondern das Verfälschen der Lagewahrnehmung. Purple Teaming sollte solche Szenarien bewusst einbeziehen, weil sie in hochregulierten Umgebungen oft realistischer und schwerer zu erkennen sind als laute disruptive Aktionen.

Der größte Mehrwert von Purple Teaming in KRITIS liegt meist nicht im Nachweis, dass ein Angriff technisch möglich ist. Dieser Nachweis ist oft schon bekannt. Der eigentliche Gewinn entsteht, wenn Detection-Lücken präzise sichtbar werden und in belastbare Erkennungslogik überführt werden. Dafür reicht es nicht, einzelne Signaturen zu bauen. KRITIS braucht kontextstarke Detection, die technische Ereignisse mit Betriebsrealität verknüpft.

Ein Beispiel: Ein Login auf einem Jump Host ist für sich genommen nicht verdächtig. Verdächtig wird er erst im Kontext. Erfolgt der Zugriff außerhalb eines genehmigten Wartungsfensters? Kommt er von einer ungewöhnlichen Quelle? Werden danach Systeme adressiert, die für den betreffenden Dienstleister untypisch sind? Werden Dateien übertragen, die nicht zum Auftrag passen? Wird ein administratives Tool genutzt, das in diesem Segment selten vorkommt? Gute Detection entsteht aus dieser Kombination von Ereignissen, nicht aus einem einzelnen Logeintrag.

In KRITIS ist Fehlalarmkontrolle ebenso wichtig wie Erkennungsstärke. Ein SOC, das jede Wartungsaktivität als Incident behandelt, verliert schnell Akzeptanz im Betrieb. Umgekehrt ist eine zu konservative Detection blind für Missbrauch legitimer Zugänge. Purple Teaming hilft, diese Balance zu finden. Während der Übung wird sichtbar, welche Felder in Logs fehlen, welche Korrelationen unzuverlässig sind und wo betrieblicher Kontext in SIEM oder XDR nicht verfügbar ist. Ergänzend dazu sind Und Siem, Und Edr und Und Detection Engineering besonders relevant.

Ein belastbarer Detection-Workflow in KRITIS umfasst mehrere Ebenen. Erstens Rohtelemetrie: Authentisierung, Prozessstarts, Netzwerkverbindungen, Dateioperationen, Konfigurationsänderungen, Remote-Zugriffe. Zweitens Kontextdaten: Asset-Kritikalität, Segmentzugehörigkeit, Wartungsfenster, Verantwortlichkeiten, Herstellerbezug, Prozessrolle. Drittens Korrelation: zeitliche Abfolge, Benutzerverhalten, Pfadabweichungen, Sequenzen typischer Angriffsschritte. Viertens Response-Hinweise: Was darf das SOC tun, was muss mit OT abgestimmt werden, wann ist nur Beobachtung zulässig?

• Erkennung ohne Asset-Kontext erzeugt in KRITIS oft unbrauchbare Alarme
• Erkennung ohne Wartungs- und Freigabedaten verwechselt legitime Arbeit mit Angriffen
• Erkennung ohne Response-Grenzen kann operative Schäden verursachen

Praktisch bedeutet das: Detection-Regeln müssen nicht nur technisch korrekt sein, sondern betrieblich anschlussfähig. Ein Alarm, der keine Aussage zur Kritikalität des betroffenen Systems, zum Segment, zum Wartungsstatus und zum möglichen Impact enthält, ist in einer KRITIS-Lage zu schwach. Purple Teaming sollte deshalb immer auch die Qualität der Alarmanreicherung prüfen. Ein guter Alarm beantwortet nicht nur „Was ist passiert?“, sondern auch „Warum ist das hier relevant?“ und „Welche sichere nächste Aktion ist möglich?“

Gerade in OT-nahen Umgebungen ist außerdem wichtig, dass nicht jede Erkennung auf Endpoint-Telemetrie beruhen kann. Netzwerkbasierte Sichtbarkeit, Protokollverständnis, Asset-Inventarisierung und Log-Quellen aus Management- und Fernwartungssystemen sind oft entscheidend. Wer Detection nur aus klassischer IT-Perspektive denkt, übersieht die Hälfte des Problems.

Die meisten Probleme in KRITIS-Purple-Teaming-Projekten sind keine hochkomplexen technischen Fehler. Es sind wiederkehrende Planungs- und Abstimmungsfehler. Der erste große Fehler ist die Annahme, dass ein bestehender Enterprise-Purple-Team-Prozess unverändert auf KRITIS übertragbar ist. Das führt zu zu aggressiven Testschritten, unklaren Freigaben und fehlender Einbindung des Betriebs.

Der zweite Fehler ist die Verwechslung von Sichtbarkeit mit Sicherheit. Viele Organisationen verfügen über SIEM, EDR oder Netzwerkmonitoring und gehen davon aus, damit ausreichend vorbereitet zu sein. In der Übung zeigt sich dann, dass zwar Daten vorhanden sind, aber keine belastbaren Use Cases, keine saubere Korrelation und keine klare Zuständigkeit für OT-nahe Alarme existieren. Sichtbarkeit ohne Auswertung ist nur Datensammlung.

Der dritte Fehler ist ein zu technischer Fokus ohne Prozesssicht. Ein Alarm kann korrekt auslösen und trotzdem wertlos sein, wenn niemand weiß, wer informiert werden muss, welche Systeme betroffen sind und welche Maßnahmen zulässig sind. In KRITIS ist diese Lücke besonders gefährlich, weil unkoordinierte Reaktionen selbst Schaden verursachen können. Ein isolierter Host in der Office-IT ist oft vertretbar. Eine unbedachte Trennung in einer OT-nahen Kette kann Betriebsunterbrechungen auslösen.

Der vierte Fehler ist fehlende Dokumentation der Ausgangslage. Ohne Baseline lässt sich nach der Übung kaum bewerten, ob Detection wirklich verbessert wurde. Welche Logs waren vorher vorhanden? Welche Regeln existierten? Welche Eskalationszeiten galten? Welche Systeme waren im Scope? Ohne diese Daten bleibt das Ergebnis subjektiv. Wer tiefer in wiederkehrende Schwachstellen einsteigen will, findet ergänzende Inhalte unter Fehler und Typische Fehler Beim Purple Teaming.

Ein weiterer häufiger Fehler ist zu viel Vertrauen in Hersteller- oder Integrator-Aussagen. Aussagen wie „dieses System ist segmentiert“, „dieser Zugang wird nur bei Bedarf genutzt“ oder „dieser Account ist rein technisch“ müssen in der Übung überprüfbar sein. Purple Teaming lebt von validierten Annahmen, nicht von Architekturfolklore. Gerade in historisch gewachsenen KRITIS-Landschaften existieren oft Sonderfälle, temporäre Freigaben und vergessene Übergänge, die in keiner aktuellen Dokumentation sauber auftauchen.

Schließlich scheitern viele Projekte an falscher Erfolgsmessung. Wenn Erfolg nur bedeutet, dass ein Angriff irgendwann entdeckt wurde, dann bleiben zentrale Fragen offen: Wie früh wurde er erkannt? War der Alarm verständlich? Konnte das SOC den Pfad rekonstruieren? Wurden OT-Verantwortliche rechtzeitig eingebunden? Wäre die Reaktion im Echtfall sicher gewesen? Ohne diese Perspektive bleibt Purple Teaming oberflächlich.

In KRITIS entscheidet der Workflow über den Erfolg der Übung. Ein technisch starkes Team ohne saubere Steuerung ist ein Risiko. Deshalb braucht jede Purple-Team-Übung klare Rollen, Freigabeprozesse, Abbruchkriterien und Kommunikationswege. Das gilt besonders dann, wenn IT, OT, SOC, externe Dienstleister und Betriebsverantwortliche gemeinsam beteiligt sind.

Ein belastbarer Workflow beginnt mit einer Vorabfreigabe auf Management- und Betriebsebene. Dabei werden Scope, zulässige Techniken, verbotene Aktionen, Zeitfenster, Kontaktketten und Notfallstopps definiert. Danach folgt ein technischer Readiness-Check: Sind Logquellen aktiv? Sind Ansprechpartner erreichbar? Sind Monitoring-Teams informiert? Existiert ein sicherer Kanal für Echtzeitabstimmung? Gibt es eine klare Entscheidungskompetenz, wenn die Übung unerwartete Effekte zeigt?

Während der Durchführung ist eine White-Cell oder Steuerungsfunktion sinnvoll. Diese Instanz überwacht den Ablauf, bewertet Risiken in Echtzeit und entscheidet bei Grenzfällen. Gerade in KRITIS darf das Red-seitige Team nicht autonom eskalieren, nur weil ein nächster Schritt technisch möglich wäre. Jede Aktion muss gegen die vereinbarten Grenzen geprüft werden. Das ist kein Zeichen von Schwäche, sondern professioneller Betriebsschutz.

Ein praxistauglicher Ablauf orientiert sich häufig an Prozess, Ablauf und Playbook. Für KRITIS sollte dieser Ablauf mindestens folgende Elemente enthalten:

• Pre-Check mit Scope, Freigaben, Kontaktliste, Abbruchkriterien und technischen Baselines
• Kontrollierte Ausführung mit Live-Abstimmung, Protokollierung und Risikobewertung jedes Schritts
• Direkte Nachbereitung mit Detection-Tuning, Incident-Review und Maßnahmenverfolgung

Wichtig ist auch die Trennung zwischen Übungsmodus und Incident-Modus. Wenn das Blue Team eine Aktivität erkennt, muss klar sein, ob es frei reagieren darf oder ob bestimmte Maßnahmen nur nach White-Cell-Freigabe zulässig sind. In KRITIS ist diese Unterscheidung essenziell, weil spontane Gegenmaßnahmen produktive Prozesse beeinträchtigen können. Gleichzeitig darf die Übung nicht so stark künstlich begrenzt werden, dass keine realistische Reaktion mehr sichtbar wird. Gute Workflows definieren deshalb Reaktionsstufen: beobachten, validieren, koordinieren, eingreifen.

Ein oft unterschätzter Punkt ist die lückenlose Protokollierung. Jede Aktion des Red-seitigen Teams, jede Beobachtung des Blue Teams, jede Freigabe und jede Abweichung vom Plan muss nachvollziehbar dokumentiert werden. Nur so lässt sich später sauber bewerten, ob eine Detection zu spät, zu ungenau oder gar nicht gegriffen hat. Ohne diese Chronologie wird die Nachbereitung spekulativ.

Die technische Umsetzung in KRITIS folgt dem Prinzip der minimal notwendigen Wirkung. Ziel ist nicht maximale Realitätsnähe um jeden Preis, sondern maximale Erkenntnis bei kontrolliertem Risiko. Das bedeutet: lieber eine TTP abstrahiert und sicher simulieren als eine produktionsnahe Aktion ausführen, deren Nebeneffekte nicht vollständig beherrscht werden.

Ein Beispiel ist Credential Access. Statt aggressive Speicherzugriffe oder invasive Tools auf sensiblen Systemen auszuführen, kann die Übung auf vorgelagerten Systemen ansetzen oder mit kontrollierten Artefakten arbeiten, die dieselben Detection-Pfade validieren. Ähnlich bei Lateral Movement: Nicht jeder Remote-Execution-Pfad muss produktiv genutzt werden. Oft genügt die kontrollierte Ausführung auf freigegebenen Testsystemen innerhalb derselben Überwachungskette, um Logging, Alarmierung und Eskalation realistisch zu prüfen.

Vor jeder Aktion sollte geprüft werden, welche Telemetrie erwartet wird. Wenn ein Schritt ausgeführt wird, ohne dass vorher klar ist, welche Logs, Events oder Netzwerkspuren entstehen sollen, ist die Übung schlecht vorbereitet. Purple Teaming ist kein Blindflug. Es geht darum, Hypothesen zu testen: Wenn diese TTP auf diesem System unter diesen Bedingungen ausgeführt wird, dann sollten diese Datenquellen reagieren und diese Regeln anschlagen. Bleibt das aus, ist die Lücke präzise benennbar.

Ein einfacher, aber wirkungsvoller Ansatz ist die Arbeit mit TTP-Matrizen. Für jede Technik werden Zielsystem, Vorbedingungen, erwartete Telemetrie, erlaubte Ausführungstiefe, potenzielle Risiken und Abbruchkriterien dokumentiert. In KRITIS verhindert das spontane Improvisation. Ergänzend können Inhalte aus Und Mitre Attack, Mitre Attack Mapping und Best Practices genutzt werden, um Techniken sauber zu strukturieren.

Ein Beispiel für eine kontrollierte technische Planung:

TTP: Missbrauch legitimer Remote-Verbindung
Ziel: Validierung von Login-, Session- und Zielsystem-Korrelation
Systemklasse: Jump Host / Administrationsserver
Vorbedingungen: Wartungsfenster simuliert, White-Cell aktiv, Logging geprüft
Erwartete Telemetrie:
- erfolgreiche Authentisierung
- Session-Aufbau
- Zielsystemkontakt
- Prozessstart oder Dateioperation
Risiken:
- ungewollte Verbindung zu produktionskritischen Endpunkten
- Fehlalarm mit operativer Eskalation
Abbruch:
- unerwartete Zielsysteme
- Performance-Anomalien
- ungeplante Reaktion automatisierter Schutzsysteme

Diese Form der Vorbereitung macht den Unterschied zwischen einer kontrollierten Sicherheitsübung und einem riskanten Experiment. Besonders in KRITIS sollte jede TTP so gewählt werden, dass sie Erkenntnis über Detection und Reaktion liefert, ohne unnötig tief in produktive Prozessketten einzugreifen.

Eine KRITIS-Purple-Team-Übung ist erst dann wertvoll, wenn aus Beobachtungen konkrete Verbesserungen entstehen. Das Reporting darf deshalb nicht bei einer chronologischen Beschreibung der Angriffe stehen bleiben. Es muss technische, operative und organisatorische Erkenntnisse zusammenführen. Gute Berichte beantworten mindestens vier Fragen: Welche Annahmen wurden geprüft? Was wurde beobachtet? Welche Lücken wurden bestätigt? Welche Maßnahmen haben die höchste Priorität?

Wichtig ist die Trennung zwischen Findings, Ursachen und Maßnahmen. Ein Finding kann lauten: Missbrauch eines legitimen Wartungszugangs wurde nicht erkannt. Die Ursache kann sein: fehlende Korrelation zwischen Wartungsfreigabe, Login-Quelle und Zielsystemverhalten. Die Maßnahme ist dann nicht einfach „mehr Logs“, sondern zum Beispiel die Anreicherung von Authentisierungsereignissen mit Ticket- und Asset-Kontext, plus neue Regeln für Zielsystemabweichungen und Session-Muster.

In KRITIS sollten Metriken nicht nur technische Erkennung messen. Relevante Kennzahlen sind unter anderem Zeit bis zur ersten Sichtbarkeit, Zeit bis zur korrekten Einordnung, Qualität der Eskalation, Anteil verwertbarer Alarme, Vollständigkeit der Telemetrie entlang des Angriffspfads und Umsetzungsgrad der Maßnahmen nach der Übung. Wer diese Ebene vertiefen will, kann Reporting, Dokumentation und Metriken ergänzend betrachten.

Ein häufiger Fehler im Reporting ist die Vermischung von Risiko und Dramatik. Nicht jede nicht erkannte Aktion ist gleich kritisch. Entscheidend ist, an welcher Stelle des Angriffspfads die Lücke liegt und welche betrieblichen Folgen daraus entstehen könnten. Eine nicht erkannte Discovery-Aktion in einem wenig kritischen Segment ist anders zu bewerten als ein unerkannter Übergang über einen administrativen Wartungspfad in Richtung OT. Gute Berichte priorisieren nach Angreiferwert, Betriebsnähe und Umsetzbarkeit der Gegenmaßnahmen.

Ebenso wichtig ist die Maßnahmenverfolgung. Purple Teaming in KRITIS darf kein einmaliges Event bleiben. Nach der Übung müssen Detection-Regeln angepasst, Logquellen erweitert, Freigabeprozesse geschärft, Asset-Daten verbessert und Reaktionsabläufe nachtrainiert werden. Danach folgt idealerweise eine gezielte Re-Validierung. Erst wenn dieselbe TTP unter vergleichbaren Bedingungen besser erkannt und sicherer behandelt wird, ist echte Verbesserung erreicht.

Nachhaltigkeit entsteht durch Iteration. Kleine, präzise Übungen mit klarer Nachverfolgung sind in KRITIS oft wirksamer als seltene Großübungen mit überladenem Scope. Wer Purple Teaming als kontinuierlichen Verbesserungsprozess versteht, gewinnt nicht nur bessere Detection, sondern auch belastbarere Zusammenarbeit zwischen SOC, OT-Betrieb, Engineering und Management.

Ein belastbares KRITIS-Engagement folgt einer klaren Linie. Zuerst wird die Umgebung verstanden, dann werden realistische Ziele definiert, danach werden sichere TTPs ausgewählt und erst dann beginnt die kontrollierte Durchführung. Diese Reihenfolge ist nicht verhandelbar. Wer mit Tools oder Angriffsideen startet, bevor Scope, Betriebsgrenzen und Telemetrie geklärt sind, arbeitet unsauber.

In der Vorbereitung sollten alle Beteiligten dieselbe Sprache sprechen. Das SOC denkt in Alerts und Eskalationen, der OT-Betrieb in Verfügbarkeit und Prozesssicherheit, das Management in Risiko und Nachweisbarkeit. Purple Teaming verbindet diese Perspektiven. Deshalb müssen Szenarien so formuliert werden, dass jede Rolle ihren Beitrag versteht. Ein gutes Szenario beschreibt nicht nur die Technik, sondern auch den erwarteten betrieblichen Kontext und die zulässigen Reaktionen.

Während der Durchführung zählt Disziplin. Jede Aktion wird angekündigt oder zumindest kontrolliert protokolliert, jede Beobachtung wird zeitlich sauber erfasst, jede Abweichung vom Plan wird bewertet. Das Blue Team sollte nicht nur auf Alerts schauen, sondern aktiv prüfen, welche Datenquellen den Pfad abbilden, wo Kontext fehlt und welche Entscheidungen im Echtfall schwierig wären. Gerade diese Unsicherheiten sind wertvolle Ergebnisse.

Nach der Übung beginnt die eigentliche Arbeit. Detection-Tuning, Prozessanpassung, Asset-Kontext, Freigabelogik und Kommunikationswege müssen verbessert werden. Danach folgt eine Re-Validierung mit denselben oder leicht variierten TTPs. Erst diese zweite Runde zeigt, ob die Organisation gelernt hat. Genau hier trennt sich reines Testen von echter Sicherheitsreife.

Für den Ausbau eines strukturierten Programms sind Strategie, Lifecycle, Iteration und Collaboration besonders hilfreich. In KRITIS ist Zusammenarbeit kein weicher Faktor, sondern eine technische Notwendigkeit. Detection ohne Betriebswissen bleibt blind, Betriebswissen ohne Security-Kontext bleibt angreifbar.

Die wichtigste praktische Regel lautet: Jede Übung muss die Sicherheitslage verbessern, ohne die Betriebsstabilität unnötig zu gefährden. Daraus folgen klare Konsequenzen. Keine unkontrollierten Aktionen. Keine Tool-Demos ohne Szenariobezug. Keine Erfolgsmeldungen ohne Re-Validierung. Keine Findings ohne umsetzbare Maßnahmen. Und keine technische Bewertung ohne Einordnung des betrieblichen Impacts.

Wenn diese Prinzipien eingehalten werden, wird Purple Teaming in KRITIS zu einem der wirksamsten Instrumente, um Detection, Zusammenarbeit und operative Resilienz realistisch zu verbessern. Nicht durch spektakuläre Angriffe, sondern durch präzise, kontrollierte und wiederholbare Validierung der Punkte, an denen echte Angreifer in der Praxis ansetzen würden.