Typische Fehler Beim Purple Teaming: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Viele Teams starten Purple Teaming mit der Erwartung, dass ein gemeinsamer Termin zwischen Offensive und Defensive automatisch zu besseren Erkennungsregeln, saubereren Reaktionsprozessen und messbarer Resilienz führt. In der Praxis passiert oft das Gegenteil: Es werden einzelne Angriffe demonstriert, Logs betrachtet, ein paar Regeln angepasst und am Ende bleibt unklar, ob die Sicherheitslage tatsächlich verbessert wurde. Der Kernfehler liegt fast nie in fehlender Technik, sondern in einem unsauberen Verständnis dessen, was Purple Teaming operativ leisten soll.

Ein belastbarer Purple-Teaming-Ansatz ist kein Show-Case für Exploits und auch kein verkapptes Red Teaming mit Zuschauern. Ziel ist die kontrollierte Verbesserung von Detection, Telemetrie, Reaktionsfähigkeit und technischem Verständnis auf beiden Seiten. Wer das Format mit einem klassischen Penetrationstest verwechselt, produziert zwangsläufig falsche Ergebnisse. Genau deshalb lohnt sich der Blick auf Was Ist Purple Teaming und auf die operative Methodik, bevor einzelne Fehler analysiert werden.

Ein typischer Fehlstart beginnt mit einer zu groben Zieldefinition. Aussagen wie „mal schauen, wie gut das SOC ist“ oder „wir testen heute Ransomware“ sind zu unpräzise. Ohne klar definierte Hypothesen fehlt die Grundlage für jede Bewertung. Eine brauchbare Fragestellung wäre dagegen: Erkennt das SIEM PowerShell-Ausführung mit verdächtigen Parametern auf administrativen Endpunkten? Korrelieren EDR und Windows Event Logs die Aktivität? Wird der Alert priorisiert und korrekt triagiert? Erst solche Fragen machen Purple Teaming messbar.

Ebenso problematisch ist die Annahme, dass jede ATT&CK-Technik automatisch relevant ist. Ein Unternehmen mit stark gehärteten Linux-Servern, aber schwacher Microsoft-365-Überwachung sollte nicht zuerst Zeit in exotische Linux-Persistenz investieren, wenn Identitätsangriffe und Cloud-Telemetrie die realistischeren Risiken darstellen. Gute Übungen orientieren sich an Bedrohungsmodell, Architektur, vorhandener Telemetrie und Verteidigungszielen. Schlechte Übungen orientieren sich an Tool-Demos.

Ein weiterer Denkfehler: Purple Teaming wird oft als einmalige Maßnahme geplant. Dadurch entstehen Momentaufnahmen statt Verbesserungszyklen. Detection Engineering braucht Wiederholung, Regressionstests und Versionierung. Eine Regel, die heute anschlägt, kann morgen nach Parser-Änderungen, Log-Format-Wechseln oder Agent-Updates wirkungslos sein. Wer Purple Teaming nicht als wiederholbaren Workflow versteht, erzeugt kurzfristige Aktivität, aber keine nachhaltige Verteidigungsfähigkeit.

Die häufigsten Grundfehler am Anfang lassen sich auf wenige Muster reduzieren:

• Unklare Ziele statt testbarer Hypothesen
• Fokus auf Angriffsdemonstration statt Detection-Validierung
• Keine Priorisierung nach realem Risiko und vorhandener Telemetrie
• Einmalige Übung ohne Wiederholung, Regression und Nachverfolgung

Sauberes Purple Teaming beginnt daher nicht mit Payloads, sondern mit Scope, Annahmen, Datenquellen, Erfolgskriterien und Verantwortlichkeiten. Erst wenn diese Basis steht, lohnt sich die technische Ausführung.

Der häufigste operative Fehler ist ein unsauberer Scope. In vielen Umgebungen wird nur grob festgelegt, welche Systeme „im Test“ sind. Nicht definiert wird dagegen, welche Benutzerkonten verwendet werden dürfen, welche Sicherheitskontrollen aktiv bleiben müssen, welche Logquellen als Referenz dienen und welche Eingriffe in Produktivsysteme tabu sind. Das führt zu zwei Problemen: Erstens entstehen Ergebnisse, die nicht reproduzierbar sind. Zweitens werden Findings falsch interpretiert, weil unklar bleibt, ob eine Erkennung wegen echter Schwäche oder wegen Scope-Artefakten ausgeblieben ist.

Ein belastbarer Scope beschreibt nicht nur Ziele, sondern auch Randbedingungen. Dazu gehören Netzwerksegmente, Endpunkttypen, Cloud-Konten, Identitätsquellen, Logging-Pfade, Aufbewahrungszeiten, EDR-Policies, SIEM-Onboarding-Status und Eskalationswege. Gerade in hybriden Umgebungen ist das entscheidend. Wenn ein Angriffspfad über On-Prem-AD beginnt, aber die entscheidende Aktion in Azure AD oder Microsoft 365 stattfindet, muss die Übung beide Ebenen abdecken. Sonst wird nur ein Teil des Kill-Chains betrachtet und die Bewertung bleibt wertlos.

Ebenso kritisch ist ein fehlendes Bedrohungsmodell. Ohne Bezug zu realistischen Gegnerprofilen wird Purple Teaming schnell beliebig. Dann testet das Team Techniken, die zwar spektakulär wirken, aber für die eigene Umgebung kaum Relevanz haben. Sinnvoller ist die Ableitung aus bekannten Angriffswegen: Initial Access über Phishing oder VPN, Credential Access über LSASS-nahe Techniken oder Token-Missbrauch, Lateral Movement über RDP, SMB, WinRM oder Remote Services, Exfiltration über Cloud-Speicher oder Web-Protokolle. Die Auswahl muss zur Umgebung passen, nicht zur Lieblingsliste des Operators.

Ein weiterer Fehler ist die Vermischung von Sicherheitszielen. Manche Übungen sollen gleichzeitig Awareness schaffen, Detection verbessern, Incident Response trainieren, Management beeindrucken und Tool-Beschaffungen rechtfertigen. Das ist operativ unbrauchbar. Jede Session braucht ein primäres Ziel. Geht es um Telemetrie-Lücken? Um Alert-Qualität? Um Triage-Zeiten? Um die Validierung neuer Sigma- oder SPL-Regeln? Ohne Priorität werden Ergebnisse diffus.

Auch Erfolgskriterien werden oft zu weich formuliert. „Der Angriff wurde erkannt“ reicht nicht. Erkannt von wem? Durch welche Datenquelle? Mit welchem Zeitversatz? Mit welcher Genauigkeit? Wurde die Aktivität nur im EDR-Portal sichtbar oder tatsächlich als verwertbarer Alarm an das SOC geliefert? Wurde die Technik nur auf Host-Ebene gesehen, aber nicht der Benutzerkontext erfasst? Wurde ein Alert erzeugt, aber als Low Severity wegsortiert? Gute Erfolgskriterien sind technisch und prozessual zugleich.

Ein Beispiel aus der Praxis: Eine Übung simuliert Credential Dumping auf einem Test-Host. Das Team meldet Erfolg, weil der EDR eine verdächtige Speicherzugriffsaktivität protokolliert hat. Bei genauer Prüfung zeigt sich jedoch, dass kein SIEM-Alert erzeugt wurde, keine Korrelation mit Benutzer- und Prozesskontext stattfand und das SOC die Aktivität nie gesehen hätte. Formal war Telemetrie vorhanden, operativ war die Detection wirkungslos. Genau solche Fehlbewertungen entstehen, wenn Erfolgskriterien nicht vorab definiert sind.

Saubere Zielbilder verlangen deshalb eine Kombination aus Bedrohungsbezug, technischem Scope und messbaren Outcomes. Wer diesen Schritt überspringt, produziert Aktivität ohne Aussagekraft und verwechselt Sichtbarkeit mit Verteidigungsfähigkeit.

Ein gravierender Fehler im Purple Teaming ist die Nutzung unrealistischer Simulationen. Viele Teams testen Erkennungen mit stark vereinfachten Befehlen, Labor-Payloads oder bekannten Atomic-Tests, ohne zu prüfen, ob diese Ausführung dem Verhalten realer Angreifer in der eigenen Umgebung überhaupt ähnelt. Das Problem ist nicht, dass solche Tests grundsätzlich schlecht wären. Das Problem ist, dass aus ihnen oft falsche Schlüsse gezogen werden.

Ein einfacher PowerShell-Befehl mit klar erkennbaren Parametern kann problemlos detektiert werden, während ein leicht veränderter Ablauf mit Encodierung, indirekter Ausführung oder LOLBins dieselbe Detection umgeht. Wenn die Übung nur die triviale Variante prüft, entsteht Scheinsicherheit. Gleiches gilt für Credential Access, Discovery oder Lateral Movement. Ein Test mit Standard-Tools und offensichtlichen Kommandozeilen ist nützlich für Baseline-Validierung, aber nicht ausreichend für belastbare Aussagen über die Erkennungsqualität.

Besonders kritisch wird es, wenn Operatoren Payloads absichtlich so bauen, dass sie „gut sichtbar“ sind. Das kann für Schulungszwecke legitim sein, verfälscht aber die Bewertung der Verteidigung. Purple Teaming soll nicht beweisen, dass ein Tool Alarm auslösen kann, sondern ob die Umgebung unter realistischen Bedingungen verwertbare Signale liefert. Dazu gehört auch, dass Prozessketten, Parent-Child-Beziehungen, Benutzerkontexte, Netzwerkziele und Host-Rollen realistisch gewählt werden.

Ein klassisches Beispiel ist Lateral Movement. In vielen Übungen wird PsExec oder ein ähnliches Werkzeug direkt und isoliert ausgeführt. In realen Vorfällen ist Lateral Movement jedoch oft eingebettet in vorherige Discovery, Credential Access, Session Hijacking oder Missbrauch legitimer Admin-Tools. Die Detection muss also nicht nur den Einzelbefehl sehen, sondern die Sequenz verstehen. Wer nur Einzelaktionen testet, übersieht Korrelationen und verpasst die Chance, echte Angriffsmuster abzubilden.

Auch die Wahl der Testsysteme ist oft falsch. Ein Angriff auf einen frisch aufgesetzten Labor-Host mit Standard-Logging sagt wenig über produktionsnahe Endpunkte aus, auf denen Legacy-Software, Ausnahmen in EDR-Policies oder spezielle Admin-Tools aktiv sind. Gerade dort entstehen die interessanten Detection-Lücken. Gute Übungen orientieren sich an repräsentativen Systemen: Administrator-Workstations, Jump Hosts, Terminalserver, Build-Server, Cloud-Management-Systeme oder kritische Applikationsserver.

Wer realistische Simulationen aufbauen will, sollte Angriffe nicht nur nach Technik, sondern nach Ausführungskontext modellieren. Dazu gehören Benutzerrolle, Privilegstufe, Host-Typ, Tageszeit, Netzwerkpfad, verwendete Binärdateien, Logquellen und erwartete Verteidigungsreaktionen. Erst dann wird sichtbar, ob eine Detection robust ist oder nur auf offensichtliche Laborartefakte reagiert.

Für die Praxis bedeutet das: Atomic Tests sind ein Einstieg, keine Endstation. Sie eignen sich zur Erstvalidierung, müssen aber durch variierte, kontextnahe und mehrstufige Szenarien ergänzt werden. Gute Referenzen dafür liefern Beispiele, Real World Beispiele und Übungen mit sauberem Und Mitre Attack-Bezug.

Einer der teuersten Denkfehler im Purple Teaming ist die Gleichsetzung von vorhandenen Logs mit funktionierender Detection. Nur weil ein Ereignis irgendwo im EDR, SIEM oder in Rohlogs auftaucht, ist noch keine Erkennung vorhanden. Detection bedeutet, dass aus Telemetrie ein verwertbares Signal entsteht, das korrekt priorisiert, verständlich angereichert und operativ nutzbar ist. Alles darunter ist lediglich Datenspeicherung.

In vielen Sessions wird nach einer Angriffsausführung zuerst geprüft, ob Events vorhanden sind. Wenn ja, gilt der Test als bestanden. Genau hier beginnt die Fehlbewertung. Entscheidend ist nicht, ob ein Event existiert, sondern ob die Pipeline funktioniert: Erfassung, Normalisierung, Parsing, Feldextraktion, Korrelation, Alerting, Kontextanreicherung und Triage. Fällt eine dieser Stufen aus, ist die Detection praktisch unbrauchbar.

Ein typisches Beispiel ist die Ausführung verdächtiger PowerShell-Kommandos. Der Host erzeugt Script Block Logging, der EDR sieht Prozessparameter, das SIEM ingestiert die Daten. Trotzdem bleibt der Angriff unentdeckt, weil die Parser das relevante Feld falsch mappen, die Regel auf ein anderes Feld referenziert oder die Korrelation nur auf Server, nicht aber auf Workstations angewendet wird. Wer nur „Log vorhanden“ prüft, übersieht diese Brüche.

Ebenso häufig werden False Positives und False Negatives nicht sauber bewertet. Eine Regel, die jede administrative PowerShell-Nutzung alarmiert, ist nicht automatisch gut. Sie erzeugt möglicherweise so viel Rauschen, dass echte Angriffe im Alltag untergehen. Purple Teaming muss daher nicht nur die Auslösung einer Regel testen, sondern auch ihre Präzision. Dazu gehört die Frage, ob die Detection zwischen legitimer Administration, Automatisierung und missbräuchlicher Nutzung unterscheiden kann.

Besonders wertvoll ist die Trennung zwischen Telemetrie-Test und Detection-Test. Ein Telemetrie-Test beantwortet: Werden die relevanten Daten überhaupt erzeugt und zentral verfügbar gemacht? Ein Detection-Test beantwortet: Führt diese Datenlage zu einem belastbaren Alarm? Ein Response-Test beantwortet: Wird der Alarm richtig bearbeitet? Wenn diese Ebenen vermischt werden, entstehen Reports mit unklaren Aussagen und Maßnahmen ohne Priorität.

In reifen Umgebungen wird Detection-Validierung wie Software-Qualität behandelt. Regeln werden versioniert, Testfälle dokumentiert, Änderungen nachvollzogen und Regressionen regelmäßig geprüft. Genau hier überschneidet sich Purple Teaming mit Und Detection Engineering, Und Log Analyse und Und Alerting. Ohne diesen Engineering-Ansatz bleibt Purple Teaming eine lose Sammlung von Einzeltests.

Praktisch bewährt sich eine Validierung entlang klarer Prüffragen:

• Wurde die relevante Telemetrie vollständig und ohne Parsing-Verlust erfasst?
• Hat eine konkrete Regel oder Analytik den Testfall ausgelöst?
• War der Alert mit Host-, Benutzer-, Prozess- und Zeitkontext angereichert?
• Konnte das SOC den Fall ohne manuelles Rätselraten korrekt einordnen?

Erst wenn alle vier Fragen positiv beantwortet werden, kann von wirksamer Detection gesprochen werden. Alles andere ist Vorarbeit, aber noch keine Verteidigung.

Purple Teaming lebt von Zusammenarbeit, scheitert aber oft an Teamdynamik. Ein häufiger Fehler ist ein unausgesprochener Wettbewerb zwischen Offensive und Defensive. Das Red Team will beweisen, dass es unentdeckt bleibt. Das Blue Team will zeigen, dass die vorhandenen Kontrollen ausreichen. In dieser Konstellation werden Informationen zurückgehalten, Ergebnisse beschönigt und technische Diskussionen emotional statt analytisch geführt. Der eigentliche Zweck, nämlich gemeinsame Verbesserung, geht verloren.

Ein belastbarer Ablauf verlangt klare Rollen. Das offensive Team liefert reproduzierbare Testfälle, dokumentiert Ausführungskontext und benennt Variationen. Das defensive Team prüft Telemetrie, Regeln, Korrelationen und Triage-Pfade. Beide Seiten arbeiten gegen dieselbe Fragestellung, nicht gegeneinander. Sobald eine Übung zum Prestigeprojekt wird, sinkt die Qualität der Erkenntnisse drastisch.

Ein weiterer Fehler ist die falsche Taktung der Informationsfreigabe. Manche Sessions sind so transparent, dass das Blue Team jeden Schritt vorab kennt. Dann wird nicht Detection getestet, sondern nur die Fähigkeit, auf angekündigte Ereignisse zu reagieren. Andere Sessions sind so intransparent, dass das Blue Team keinerlei Kontext erhält und nachträglich nur schwer nachvollziehen kann, was tatsächlich passiert ist. Beides ist unbrauchbar. Sinnvoll ist eine abgestufte Transparenz: erst Baseline-Test ohne Hinweise, dann kontrollierte Offenlegung für Root-Cause-Analyse, anschließend Wiederholung zur Validierung der Verbesserung.

Auch Sprache und Dokumentation sind oft ein Problem. Das Red Team beschreibt Aktionen in Tool-Begriffen, das Blue Team denkt in Datenquellen und Use Cases. Wenn nicht sauber übersetzt wird, reden beide aneinander vorbei. „Mimikatz ausgeführt“ ist keine ausreichende Beschreibung. Relevant sind Prozessname, Parent-Prozess, Benutzerkontext, Zielhost, Privilegstufe, Speicherzugriffsmuster, EDR-Reaktion und Zeitstempel. Nur so kann das Blue Team die richtigen Datenpunkte prüfen.

Schlecht moderierte Sessions verlieren sich außerdem in Einzelfragen. Statt systematisch zu klären, warum eine Detection versagt hat, wird über Tools, Signaturen oder Operator-Stil diskutiert. Besser ist ein fester Analysepfad: Was war die Hypothese? Was wurde ausgeführt? Welche Telemetrie war erwartet? Welche Telemetrie war tatsächlich vorhanden? Welche Regel hätte greifen sollen? Wo ist die Pipeline gebrochen? Welche Änderung wird umgesetzt? Wann erfolgt der Retest?

In der Praxis helfen dafür klare Kommunikations- und Kollaborationsmuster. Wer Purple Teaming ernsthaft betreibt, braucht definierte Übergaben, gemeinsame Terminologie und eine nachvollziehbare Nachverfolgung offener Punkte. Genau deshalb sind Collaboration, Communication und ein sauberer Prozess keine Nebenthemen, sondern Kernbestandteile funktionierender Übungen.

Ein guter Indikator für Reife ist die Frage, ob beide Teams nach einer Session dieselbe Ursache für einen Detection-Fehler benennen. Wenn das Red Team von „Bypass“ spricht, das Blue Team aber von „fehlendem Logging“, liegt meist schon in der gemeinsamen Analyse ein strukturelles Problem.

Viele Purple-Teaming-Programme investieren viel Energie in Tool-Auswahl und zu wenig in Datenverständnis. Es wird über EDR, SIEM, XDR, SOAR oder Emulationsplattformen gesprochen, aber nicht über Event-Qualität, Feldkonsistenz, Zeitquellen, Parser-Fehler oder Datenlücken. Das ist gefährlich, weil die beste Plattform wertlos ist, wenn die zugrunde liegende Telemetrie unvollständig oder falsch normalisiert ist.

Ein klassischer Fehler ist die Annahme, dass ein EDR alle relevanten Host-Aktivitäten automatisch in ausreichender Tiefe erfasst. In Wirklichkeit unterscheiden sich Produkte stark bei Prozessdetails, Registry-Sichtbarkeit, Script-Inhalten, Netzwerkmetadaten, Speicherzugriffen und Retention. Wer Purple Teaming nur auf Basis von Produktversprechen plant, statt die tatsächlichen Datenfelder zu prüfen, baut Detections auf unsicherem Fundament.

Ähnlich problematisch ist die SIEM-Perspektive. Viele Regeln werden auf normalisierte Felder geschrieben, ohne zu prüfen, ob diese in allen Datenquellen konsistent befüllt sind. Ein Use Case funktioniert dann auf Windows-Servern, aber nicht auf Workstations. Oder er funktioniert im Labor, aber nicht in Cloud-Workloads, weil dort andere Feldnamen, andere Timestamps oder andere Identitätsattribute vorliegen. Solche Inkonsistenzen fallen oft erst im Purple Teaming auf, wenn die Übung sauber genug geplant ist.

Auch Emulationstools werden häufig missverstanden. Sie sind hilfreich, um Techniken reproduzierbar auszuführen, aber sie ersetzen keine Analyse. Ein Tool kann eine ATT&CK-Technik markieren, doch die Verteidigung muss verstehen, welche konkreten Artefakte in der eigenen Umgebung entstehen. Genau deshalb sollte jede Übung nicht nur das Tool und die Technik dokumentieren, sondern auch die beobachteten Datenpunkte: Event IDs, EDR-Felder, Prozessketten, Netzwerkverbindungen, Benutzerattribute, Host-Rollen und Zeitbezug.

In der Praxis lohnt sich ein nüchterner Blick auf die Tool-Landschaft. Ob Tools, Open Source Tools oder Integrationen Und Siem und Und Edr genutzt werden, ist zweitrangig gegenüber der Frage, welche Daten zuverlässig vorliegen und wie sie operationalisiert werden. Gute Teams kennen ihre Datenquellen besser als ihre Marketingfolien.

Ein weiterer Fehler ist die fehlende Trennung zwischen Tool-Limitierung und Implementierungsfehler. Wenn eine Detection nicht funktioniert, wird schnell das Produkt verantwortlich gemacht. Oft liegt die Ursache aber in deaktivierten Sensoren, fehlerhaften Parsern, unvollständigem Onboarding, falsch gesetzten Ausschlüssen oder nicht ausgerollten Policies. Purple Teaming sollte genau diese Unterschiede sichtbar machen. Nur dann lassen sich Maßnahmen priorisieren: Produktwechsel, Konfigurationsanpassung oder Engineering-Nacharbeit.

Wer blinde Flecken reduzieren will, muss jede Übung als Datenqualitätsprüfung verstehen. Nicht das Tool erkennt den Angriff, sondern die Kombination aus Sensorik, Datenpipeline, Analytik und Betriebsprozess. Sobald dieser Zusammenhang klar ist, werden viele vermeintliche Tool-Probleme als Architektur- oder Betriebsprobleme erkennbar.

Ein Purple-Teaming-Workshop ohne Nachverfolgung ist kaum mehr als ein technischer Termin. Einer der häufigsten Fehler besteht darin, Findings zwar zu sammeln, aber keine verbindliche Umsetzung zu organisieren. Detection-Lücken werden dokumentiert, Parser-Probleme benannt, neue Regeln vorgeschlagen und Telemetrie-Maßnahmen diskutiert. Wochen später ist unklar, was davon umgesetzt wurde, welche Änderungen produktiv sind und ob die ursprüngliche Schwachstelle noch existiert.

Der Grund liegt meist in fehlender Ownership. Wenn nicht eindeutig festgelegt ist, wer eine Detection schreibt, wer Parser anpasst, wer Logging aktiviert, wer Ausnahmen prüft und wer den Retest terminiert, versanden selbst gute Erkenntnisse. Purple Teaming braucht deshalb dieselbe Disziplin wie Incident-Nachbereitung oder Vulnerability-Management: Ticketing, Verantwortliche, Fristen, Prioritäten und Statuskontrolle.

Noch gravierender ist das Fehlen von Regressionstests. Eine einmal verbesserte Detection bleibt nicht automatisch stabil. Änderungen an Logformaten, Agent-Versionen, Cloud-APIs, Parsern oder Datenmodellen können funktionierende Regeln unbemerkt brechen. Ohne wiederholbare Testfälle wird dieser Verlust oft erst im Ernstfall sichtbar. Reife Teams pflegen deshalb eine Bibliothek validierter Szenarien, die regelmäßig erneut ausgeführt werden.

Ein sauberer Verbesserungszyklus besteht aus Test, Analyse, Maßnahme, Retest und späterem Regressionstest. Erst dieser Kreislauf macht Fortschritt messbar. Wer nur testet und dokumentiert, aber nicht erneut prüft, kennt den Zustand der Verteidigung nicht. Genau hier greifen Iteration, Ablauf und Lifecycle ineinander.

Praktisch bewährt sich ein einfacher, aber strenger Maßnahmenrahmen:

• Jedes Finding erhält einen technischen Owner und einen fachlichen Owner
• Jede Maßnahme wird mit konkretem Soll-Zustand und Testfall verknüpft
• Jede umgesetzte Änderung wird durch einen Retest bestätigt
• Jeder kritische Use Case wird in einen wiederkehrenden Regressionstest überführt

Ein Beispiel: Während einer Übung wird festgestellt, dass verdächtige Nutzung von rundll32 zwar im EDR sichtbar, aber im SIEM nicht alarmiert wird. Die Maßnahme lautet nicht einfach „Regel verbessern“, sondern präzise: Parser-Feld für CommandLine validieren, Sigma-Regel auf produktives Feld mappen, Ausschlüsse für bekannte Softwareverteilung dokumentieren, Severity auf Medium setzen, Retest mit zwei Varianten durchführen, Regression monatlich ausführen. Erst diese Präzision verhindert, dass Findings zu unverbindlichen Notizen verkommen.

Auch Management-Reporting kann hier schaden, wenn es nur Aktivität statt Wirksamkeit misst. Die Zahl der Sessions oder getesteten Techniken sagt wenig aus. Relevanter sind geschlossene Detection-Lücken, reduzierte Triage-Zeit, verbesserte Kontextanreicherung und stabile Regressionsergebnisse. Purple Teaming ist nur dann wertvoll, wenn Verbesserungen nachweisbar in den Betrieb übergehen.

Dokumentation ist im Purple Teaming kein Verwaltungsanhang, sondern die Voraussetzung für Reproduzierbarkeit. Trotzdem werden viele Übungen nur grob protokolliert: Technikname, grober Zeitrahmen, vielleicht ein Screenshot aus dem SIEM. Damit lässt sich weder ein Finding sauber nachvollziehen noch ein Retest zuverlässig durchführen. Besonders problematisch wird das, wenn mehrere Teams, Schichten oder externe Dienstleister beteiligt sind.

Eine brauchbare Dokumentation muss mindestens festhalten, was genau ausgeführt wurde, in welchem Kontext, mit welchen Voraussetzungen und mit welchem beobachteten Ergebnis. Dazu gehören Hostname, Benutzerkonto, Privilegstufe, Zeitstempel, verwendete Befehle oder Payload-Varianten, Zielsysteme, erwartete Telemetrie, tatsächlich beobachtete Telemetrie, ausgelöste Alerts, nicht ausgelöste Alerts und die technische Ursache für Abweichungen. Ohne diese Details bleibt jedes Finding interpretationsfähig und damit operativ schwach.

Ein häufiger Fehler ist die Vermischung von Management- und Technikbericht. Das Management braucht Risiko, Priorität, Auswirkungen und Maßnahmenstatus. Das Engineering-Team braucht Event IDs, Query-Logik, Parser-Felder, Prozessketten und Reproduktionsschritte. Wenn beides in einem unscharfen Dokument zusammenläuft, fehlt beiden Zielgruppen die nötige Tiefe. Besser sind getrennte Sichten auf dieselbe Datenbasis.

Auch Screenshots werden oft überschätzt. Ein Screenshot zeigt, dass etwas zu einem Zeitpunkt sichtbar war. Er ersetzt aber keine Query, keine Event-Referenz und keine genaue Beschreibung des Datenpfads. Für Retests und Regressionen sind strukturierte Artefakte nötig: Queries, Regelversionen, Testbefehle, Hashes, Hostlisten, Zeitfenster und Ticket-Referenzen. Nur so kann ein anderes Team Wochen später denselben Fall erneut prüfen.

Sauberes Reporting bedeutet außerdem, zwischen Beobachtung und Interpretation zu unterscheiden. „Die Detection ist schlecht“ ist keine Beobachtung. Eine belastbare Formulierung wäre: „Die Ausführung von certutil mit URL-Download auf Host X erzeugte Prozess- und Netzwerktelemetrie im EDR, jedoch keinen SIEM-Alert, da das Feld process.command_line im Parser leer blieb.“ Erst daraus lässt sich eine technische Maßnahme ableiten.

Wer Purple Teaming professionell betreibt, dokumentiert nicht nur Findings, sondern auch Negativergebnisse. Wenn eine erwartete Telemetrie nicht vorhanden war, ist das genauso wichtig wie ein ausgelöster Alert. Wenn eine Regel nur unter bestimmten Host-Rollen funktioniert, muss das festgehalten werden. Wenn ein Test wegen EDR-Blockierung nicht vollständig ausgeführt werden konnte, gehört auch das in den Bericht. Nur vollständige Transparenz verhindert falsche Schlussfolgerungen.

Für belastbare Nachverfolgung sind Reporting, Dokumentation und Metriken eng miteinander verknüpft. Dokumentation beschreibt den Fall, Reporting priorisiert die Konsequenz, Metriken zeigen, ob die Verbesserung später tatsächlich eingetreten ist.

Ein sauberer Purple-Teaming-Workflow ist weder kompliziert noch bürokratisch, solange die Reihenfolge stimmt. Zuerst wird ein realistischer Use Case ausgewählt, idealerweise aus Bedrohungsmodell, Incident-Historie oder bekannten Detection-Lücken. Danach werden Scope, Systeme, Konten, Datenquellen und Erfolgskriterien festgelegt. Erst dann folgt die technische Vorbereitung der Testfälle. Diese Reihenfolge verhindert, dass Übungen von Tools oder spontanen Ideen getrieben werden.

In der Vorbereitungsphase sollte jede Technik in konkrete Ausführungsschritte übersetzt werden. Nicht nur „T1059 PowerShell“, sondern welche Befehle, auf welchem Host, mit welchem Benutzer, in welcher Variante und mit welcher erwarteten Telemetrie. Parallel prüft das Blue Team, welche Datenquellen relevant sind: EDR, Windows Events, Sysmon, Proxy, DNS, Identity Provider, Cloud Audit Logs oder Netzwerkdaten. So entsteht vor der Ausführung bereits ein Soll-Ist-Rahmen.

Die Durchführung selbst sollte in Stufen erfolgen. Zuerst ein Baseline-Test mit minimaler Vorabinformation. Danach gemeinsame Analyse der Ergebnisse. Anschließend gezielte Anpassung von Logging, Parsing oder Detection. Danach ein Retest unter denselben Bedingungen. Optional folgt eine härtere Variante mit verändertem Ausführungskontext, um die Robustheit der Detection zu prüfen. Dieser Ablauf verhindert, dass Teams zu früh auf vermeintliche Erfolge schließen.

Wichtig ist die Trennung von Blockierung und Erkennung. Wenn ein EDR eine Aktion verhindert, ist das positiv, ersetzt aber nicht automatisch die Detection-Bewertung. Es muss trotzdem geprüft werden, welche Telemetrie erzeugt wurde, ob ein Alert im zentralen Monitoring ankam und ob das SOC den Fall hätte nachvollziehen können. Sonst bleibt unklar, wie die Umgebung reagiert, wenn dieselbe Technik in leicht veränderter Form nicht blockiert wird.

Nach der technischen Auswertung folgt die Maßnahmenphase. Jede Lücke wird einer Kategorie zugeordnet: fehlende Telemetrie, fehlerhafte Datenpipeline, schwache Detection-Logik, schlechte Kontextanreicherung, unklare Triage oder Prozessproblem. Diese Kategorisierung ist entscheidend, weil sie die Zuständigkeit bestimmt. Nicht jede Detection-Lücke ist ein SIEM-Problem, nicht jede Triage-Schwäche ein SOC-Problem und nicht jede fehlende Sichtbarkeit ein Tool-Problem.

Ein kompakter Referenzablauf kann so aussehen:

1. Use Case aus Risiko oder Incident-Historie auswählen
2. Scope, Systeme, Konten und Guardrails definieren
3. Erwartete Telemetrie und Erfolgskriterien festlegen
4. Testfall mit Variationen vorbereiten
5. Baseline-Ausführung durchführen
6. Telemetrie, Detection und Triage getrennt bewerten
7. Root Cause je Lücke bestimmen
8. Maßnahmen mit Owner und Frist erfassen
9. Retest unter gleichen Bedingungen durchführen
10. Testfall in Regressionstest-Bibliothek übernehmen

Dieser Ablauf passt unabhängig davon, ob die Umgebung eher klassisch, cloudlastig oder hybrid ist. Er funktioniert für Endpunkte, Identitäten, Netzwerkpfade und SaaS-Telemetrie gleichermaßen. Wer tiefer in strukturierte Vorgehensweisen einsteigen will, findet ergänzende Ansätze in Best Practices, Strategie und Playbook.

Der entscheidende Punkt bleibt: Gute Purple-Teaming-Workflows erzeugen nicht nur Erkenntnisse, sondern wiederholbare Verbesserungen. Alles andere ist technische Beschäftigung ohne belastbaren Verteidigungsgewinn.

Reife Purple-Teaming-Programme unterscheiden sich nicht dadurch, dass sie nie Fehler machen. Sie unterscheiden sich dadurch, dass Fehler früh sichtbar werden und nicht in den Betrieb einsickern. Ein reifes Team erkennt schnell, wenn eine Übung zu breit geschnitten ist, wenn ein Testfall nicht reproduzierbar dokumentiert wurde oder wenn eine Detection nur unter Laborbedingungen funktioniert. Diese Selbstkorrektur ist ein wesentliches Qualitätsmerkmal.

Ein guter Frühindikator ist die Konsistenz zwischen Hypothese, Ausführung und Ergebnis. Wenn eine Session mit der Frage startet, ob verdächtige Remote-Service-Erstellung erkannt wird, der Bericht aber nur allgemeine Aussagen zu „Lateral Movement“ enthält, war der Test unscharf. Ebenso problematisch ist es, wenn eine Maßnahme formuliert wird, ohne dass klar ist, welche konkrete Beobachtung sie auslöst. Reife Teams halten die Kette aus Fragestellung, Testfall, Datenlage, Detection und Maßnahme eng zusammen.

Ein zweiter Indikator ist die Qualität der Root-Cause-Analyse. Unreife Teams bleiben auf Symptomeniveau: „Alert kam nicht“, „Tool hat nichts gesehen“, „SOC war zu langsam“. Reife Teams zerlegen den Fehler: Sensor nicht aktiv, Event nicht zentralisiert, Parser-Feld leer, Regel auf falsches Feld gemappt, Severity zu niedrig, Playbook nicht vorhanden, Analystenansicht ohne Kontext. Erst diese Tiefe macht Verbesserungen wirksam.

Drittens zeigt sich Reife in der Fähigkeit, technische und organisatorische Ursachen zu trennen. Eine Detection kann technisch korrekt sein und trotzdem operativ scheitern, wenn der Alert in einer Queue untergeht oder die Eskalation unklar ist. Umgekehrt kann ein SOC sehr gut arbeiten, aber mangels Telemetrie keine Chance haben. Purple Teaming muss beide Ebenen sichtbar machen, sonst werden die falschen Teams mit Maßnahmen belastet.

Auch Metriken werden in reifen Programmen vorsichtig eingesetzt. Gute Kennzahlen messen nicht nur Menge, sondern Qualität. Relevant sind etwa: Anteil reproduzierbarer Testfälle, Zeit bis zur Root-Cause-Bestimmung, Anteil erfolgreich retesteter Findings, Stabilität von Detections über Regressionen hinweg und Abdeckung kritischer Angriffspfade. Weniger hilfreich sind reine Aktivitätsmetriken wie Zahl der Sessions oder Zahl getesteter ATT&CK-Techniken ohne Risikobezug.

Am Ende zeigt sich Reife daran, dass Purple Teaming in den Sicherheitsbetrieb integriert ist. Findings fließen in Detection Engineering, Logging-Backlog, SOC-Playbooks, Hardening und Architekturentscheidungen ein. Genau dort entsteht der eigentliche Nutzen: nicht in der Session selbst, sondern in der nachhaltigen Verbesserung von Sichtbarkeit und Reaktionsfähigkeit. Wer diesen Übergang nicht schafft, wiederholt dieselben Fehler immer wieder.

Saubere Programme arbeiten deshalb mit klaren Standards, aber ohne Starrheit. Sie passen Testfälle an neue Bedrohungen an, prüfen regelmäßig ihre Datenquellen und halten die Verbindung zwischen Technik, Betrieb und Risiko aufrecht. Das ist der Unterschied zwischen isolierten Übungen und echter Verteidigungsentwicklung.