Dokumentation: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Purple Teaming scheitert selten an fehlenden Tools. Es scheitert deutlich häufiger an unklaren Zielen, nicht reproduzierbaren Tests, lückenhaften Nachweisen und Berichten, die zwar Aktivität dokumentieren, aber keine belastbare Verbesserung der Erkennungs- und Reaktionsfähigkeit belegen. Genau an dieser Stelle wird Dokumentation zum operativen Kernbestandteil. Sie ist nicht nur ein Abschlussartefakt, sondern das verbindende Element zwischen Angriffssimulation, Detection Engineering, Incident Response, Management-Nachweis und technischer Nacharbeit.

Im Unterschied zu klassischem Pentesting oder isolierten Red-Team-Übungen ist Purple Teaming ein kollaborativer Prozess. Red und Blue arbeiten nicht nacheinander, sondern aufeinander abgestimmt. Dadurch entstehen mehr Zwischenergebnisse: Hypothesen, Testfälle, Telemetriebeobachtungen, Detection-Lücken, Tuning-Entscheidungen, False-Positive-Bewertungen, Log-Quellen, Eskalationspfade und Lessons Learned. Ohne strukturierte Dokumentation gehen diese Informationen verloren oder bleiben an einzelne Personen gebunden. Das führt dazu, dass dieselben Fehler in späteren Iterationen erneut auftreten.

Eine belastbare Dokumentation beantwortet immer vier Fragen: Was wurde getestet? Unter welchen Bedingungen wurde getestet? Was wurde beobachtet? Welche konkrete Verbesserung wurde daraus abgeleitet? Wenn eine dieser Fragen offen bleibt, ist der Erkenntnisgewinn eingeschränkt. Besonders kritisch ist das bei Angriffstechniken, die nur unter bestimmten Randbedingungen sichtbar werden, etwa bei PowerShell-Telemetrie, EDR-Blockierungen, Cloud-Audit-Logs oder Identitätsereignissen in hybriden Umgebungen.

Gute Purple-Team-Dokumentation ist deshalb eng mit Methodik, Workflow und Reporting verbunden. Sie muss technisch präzise genug sein, damit ein Analyst einen Test reproduzieren kann, und gleichzeitig klar genug, damit Verantwortliche Risiken, Prioritäten und Fortschritt nachvollziehen können. Das bedeutet: keine Marketing-Sprache, keine vagen Aussagen wie „Detection verbessert“, sondern konkrete Nachweise mit Datenquellen, Regeln, Zeitstempeln, Host-Kontext und Ergebnisstatus.

Dokumentation erfüllt im Purple Teaming mehrere Funktionen gleichzeitig:

• Sie schafft Reproduzierbarkeit für Tests, Tuning und spätere Regressionen.
• Sie liefert Nachweise für Detection-Gaps, Verbesserungen und Restrisiken.
• Sie verbindet technische Detailtiefe mit Management-tauglicher Priorisierung.
• Sie reduziert Wissensverlust bei Teamwechseln, Schichtbetrieb und externen Dienstleistern.

Besonders wertvoll wird Dokumentation dann, wenn sie nicht erst am Ende entsteht. Wer erst nach einer Übung versucht, Kommandos, Hostnamen, Alert-Zeitpunkte und Logquellen zu rekonstruieren, produziert zwangsläufig Lücken. In reifen Umgebungen wird deshalb während der Durchführung dokumentiert: Testfall-ID, ATT&CK-Technik, Operator-Aktion, erwartete Telemetrie, tatsächliche Telemetrie, Alert-Verhalten, Analystenreaktion und Folgemaßnahmen. Dieser Ansatz macht Purple Teaming zu einem messbaren Verbesserungsprozess statt zu einer einmaligen Demonstration.

Wer die Grundlagen und Abgrenzung vertiefen will, findet ergänzende Einordnung unter Was Ist Purple Teaming sowie im Vergleich unter Purple Team Vs Red Team Vs Blue Team. Für die praktische Umsetzung zählt jedoch vor allem eines: Dokumentation muss so aufgebaut sein, dass sie technische Entscheidungen stützt und nicht nur Ergebnisse archiviert.

Eine brauchbare Dokumentation beginnt nicht mit Findings, sondern mit dem Testkontext. Ohne Scope, Zielsysteme, Annahmen und Erfolgskriterien lassen sich Ergebnisse nicht sauber interpretieren. Wenn etwa Credential Dumping auf einem Testsystem erfolgreich war, ist das nur dann aussagekräftig, wenn klar dokumentiert wurde, welche Schutzmechanismen aktiv waren, welche Benutzerrechte vorlagen und welche Telemetriequellen tatsächlich angebunden waren.

Der erste Pflichtblock ist daher der Rahmen der Übung. Dazu gehören Zeitraum, beteiligte Teams, Freigaben, Kontaktwege, Eskalationsregeln, Scope-Grenzen, Ausschlüsse und Annahmen. Gerade in produktionsnahen Umgebungen muss dokumentiert sein, welche Systeme nicht berührt werden durften, welche Lastgrenzen galten und welche Notfallstopps vereinbart wurden. Fehlt dieser Teil, entstehen später Diskussionen darüber, ob ein Test realistisch, zulässig oder überhaupt vergleichbar war.

Der zweite Pflichtblock ist die Testfallbeschreibung. Jeder Testfall braucht eine eindeutige Kennung, eine Zielsetzung und eine technische Beschreibung. Empfehlenswert ist die Zuordnung zu Taktik und Technik aus Und Mitre Attack beziehungsweise zu einem internen Threat Model. Dabei reicht es nicht, nur eine ATT&CK-ID zu notieren. Dokumentiert werden müssen auch Variante, Ausführungspfad und Randbedingungen. T1059 ist beispielsweise zu breit, wenn nicht klar ist, ob PowerShell interaktiv, über Script Block Logging, encoded commands oder über einen Remote-Execution-Pfad verwendet wurde.

Der dritte Pflichtblock ist die Beobachtungsebene. Hier wird festgehalten, welche Datenquellen erwartet wurden und welche tatsächlich verfügbar waren. Dazu zählen EDR-Ereignisse, Windows Event Logs, Sysmon, Proxy-Logs, DNS, Authentifizierungsdaten, Cloud-Audit-Logs, E-Mail-Telemetrie oder Netzwerk-Metadaten. Viele Teams dokumentieren nur Alerts. Das ist zu wenig. Ein fehlender Alert kann viele Ursachen haben: keine Datenquelle, falsches Parsing, zu restriktive Korrelation, unterdrückte Severity, fehlerhafte Zeitsynchronisation oder schlicht ein nicht ausgerollter Sensor. Nur wenn die Beobachtungsebene sauber dokumentiert ist, lässt sich die Ursache eingrenzen.

Der vierte Pflichtblock ist die Bewertung. Hier wird festgehalten, ob eine Technik verhindert, erkannt, verspätet erkannt, nur teilweise sichtbar oder vollständig unsichtbar war. Diese Bewertung muss an Kriterien gebunden sein. „Erkannt“ ist kein belastbarer Status, wenn der Alert erst 40 Minuten später im SIEM auftauchte und keine verwertbaren Felder enthielt. Ebenso ist „blockiert“ nicht ausreichend, wenn die Blockierung nur auf einem einzelnen Gold-Image funktioniert, aber nicht auf älteren Clients.

Der fünfte Pflichtblock ist die Maßnahme. Jede Lücke braucht eine konkrete Folgeaktion: neue Regel, Tuning bestehender Regel, Aktivierung zusätzlicher Logs, Parser-Korrektur, Sensor-Rollout, Playbook-Anpassung, Härtung, IAM-Änderung oder Schulungsbedarf im SOC. Ohne Maßnahmenblock bleibt Dokumentation rein beschreibend. Purple Teaming verlangt aber umsetzbare Verbesserung.

Ein praxistauglicher Minimalaufbau für jeden Testfall sieht so aus:

Testfall-ID: PT-2026-017
Ziel: Erkennung von LSASS-Zugriffen auf Windows-Workstations prüfen
ATT&CK: Credential Access / OS Credential Dumping
Systeme: WIN11-CLIENT-07, EDR aktiv, Sysmon v15
Operator-Aktion: signierter Test-Binary-Aufruf mit dokumentierter LSASS-Handle-Anfrage
Erwartete Telemetrie: Process Create, Handle Access, EDR Memory Protection Event
Tatsächliche Telemetrie: Process Create vorhanden, Handle Access fehlt, EDR Alert ausgelöst
Alert-Zeit: 14:03:22
Analystenreaktion: Ticket erstellt nach 6 Minuten, keine Host-Isolation
Bewertung: Teilweise erkannt
Maßnahme: Sysmon-Konfiguration erweitern, EDR-Playbook für Credential Access anpassen
Retest: offen

Zusätzlich sollte jede Dokumentation eine klare Trennung zwischen Rohbeobachtung und Interpretation enthalten. Rohbeobachtung sind Zeitstempel, Event-IDs, Query-Ergebnisse, Screenshots, Hashes, Hostnamen und Prozessketten. Interpretation ist die Einordnung, warum ein Signal relevant oder unzureichend war. Werden beide Ebenen vermischt, entstehen später Missverständnisse, insbesondere wenn andere Teams die Ergebnisse für Und Detection Engineering oder Und Threat Hunting weiterverwenden.

Dokumentation ist kein Endprodukt, sondern ein Workflow. Wer sie erst nach Abschluss erstellt, verliert Genauigkeit. In der Praxis bewährt sich ein dreistufiges Modell: Vorbereitungsdokumentation, Live-Dokumentation und Nachbereitungsdokumentation. Jede Phase hat einen anderen Zweck und andere Artefakte.

In der Vorbereitung werden Ziele, Testfälle und Messkriterien definiert. Hier entsteht die Testmatrix. Sie enthält Technik, Zielplattform, geplante Ausführung, erwartete Datenquellen, erwartete Alerts, Verantwortliche und Abbruchkriterien. Diese Matrix ist die Referenz für die spätere Bewertung. Ohne sie wird aus Purple Teaming schnell eine lose Sammlung von Einzelsimulationen. Die Vorbereitung ist eng mit Prozess, Ablauf und Playbook verknüpft.

Während der Durchführung muss in Echtzeit dokumentiert werden. Das bedeutet nicht, dass jede Aktion in langen Fließtexten beschrieben wird. Entscheidend ist eine strukturierte Erfassung: Wer hat wann was auf welchem System ausgeführt, welche Artefakte wurden erzeugt, welche Telemetrie war sichtbar, welche Alerts wurden ausgelöst, wie reagierte das Blue Team, welche Abweichungen traten auf. Gerade bei iterativen Tests ist es wichtig, jede Änderung zu markieren. Wenn eine Detection-Regel zwischen zwei Läufen angepasst wurde, muss klar erkennbar sein, welche Ergebnisse vor und welche nach der Änderung entstanden sind.

Nach der Durchführung folgt die Konsolidierung. Hier werden Rohdaten bereinigt, Findings priorisiert, Maßnahmen formuliert und Retests geplant. Ein häufiger Fehler besteht darin, nur die „spannenden“ Ergebnisse zu dokumentieren. Ebenso wichtig sind negative Ergebnisse und Randbedingungen. Wenn eine Technik nicht getestet werden konnte, weil ein Sensor ausgefallen ist oder ein Parser fehlerhaft war, ist das selbst ein relevantes Ergebnis. Es zeigt, dass die Messfähigkeit eingeschränkt war.

Ein belastbarer Workflow trennt außerdem zwischen Operator-Log, Detection-Log und Management-Zusammenfassung. Das Operator-Log enthält technische Details zur Ausführung. Das Detection-Log beschreibt Sichtbarkeit, Korrelation und Analystenreaktion. Die Management-Zusammenfassung verdichtet Risiken, Trends und Prioritäten. Werden diese Ebenen in ein einziges Dokument gepresst, leidet entweder die technische Tiefe oder die Lesbarkeit.

In reifen Teams hat sich folgende Ablaufstruktur bewährt:

• Vor dem Test: Scope, Hypothesen, Testfälle, Datenquellen und Erfolgskriterien festlegen.
• Während des Tests: Aktionen, Zeitpunkte, Telemetrie, Alerts und Reaktionen live protokollieren.
• Nach dem Test: Findings konsolidieren, Maßnahmen priorisieren, Retests terminieren und Verantwortlichkeiten zuweisen.

Wichtig ist auch die Versionierung. Detection-Regeln, Parser, Sigma-Varianten, SIEM-Queries und EDR-Policies ändern sich laufend. Dokumentation ohne Versionsbezug ist nur begrenzt verwertbar. Wenn ein Test im Januar fehlschlug und im März erfolgreich war, muss nachvollziehbar sein, welche Änderung den Unterschied verursacht hat. Sonst bleibt unklar, ob die Verbesserung real oder zufällig war.

Ein weiterer Praxispunkt: Screenshots allein sind keine gute Dokumentation. Sie können hilfreich sein, ersetzen aber keine strukturierten Felder. Screenshots sind schwer durchsuchbar, schlecht vergleichbar und oft ohne Kontext wertlos. Besser sind tabellarische oder formularbasierte Einträge mit ergänzenden Belegen. Screenshots dienen dann nur als Zusatznachweis, etwa für EDR-Block-Events, Prozessbäume oder SIEM-Trefferbilder.

Wer Purple Teaming als wiederkehrenden Verbesserungsprozess betreibt, sollte Dokumentation immer so anlegen, dass spätere Iteration und Regressionstests möglich sind. Nur dann lässt sich nachweisen, ob eine erkannte Lücke tatsächlich geschlossen wurde oder nach Systemänderungen erneut auftritt.

Der wertvollste Teil einer Purple-Team-Dokumentation ist fast immer die technische Nachweisführung. Hier trennt sich belastbare Analyse von bloßer Aktivitätsbeschreibung. Entscheidend ist, dass nicht nur festgehalten wird, ob ein Alert ausgelöst wurde, sondern warum er ausgelöst wurde, welche Daten ihn speisten, welche Felder relevant waren und wo die Grenzen der Erkennung lagen.

Ein typischer Fehler ist die Gleichsetzung von Telemetrie und Detection. Telemetrie bedeutet, dass ein Ereignis sichtbar ist. Detection bedeutet, dass aus dieser Sichtbarkeit ein verwertbares Signal entsteht. Ein Sysmon Event 1 für einen Prozessstart ist noch keine Detection. Erst wenn Prozessname, Parent-Child-Beziehung, Commandline, Signaturstatus, Benutzerkontext und gegebenenfalls weitere Korrelationen sinnvoll ausgewertet werden, entsteht ein belastbarer Erkennungsmechanismus. Dokumentation muss diese Trennung sauber abbilden.

Für jeden Testfall sollten mindestens folgende technische Ebenen dokumentiert werden: Datenquelle, Rohereignis, Parsing/Normalisierung, Regel- oder Query-Logik, Alert-Ausgabe, Analystenworkflow und Response-Ergebnis. Wenn eine dieser Ebenen fehlt, bleibt die Ursache eines Erfolgs oder Misserfolgs unklar. Beispiel: Ein Alert bleibt aus. Ohne Dokumentation der Rohereignisse ist nicht erkennbar, ob die Datenquelle fehlte oder die Regel versagte. Ohne Dokumentation der Regelversion ist nicht erkennbar, ob die Query veraltet war. Ohne Analystenworkflow ist nicht erkennbar, ob ein vorhandener Alert im Rauschen unterging.

Besonders wichtig ist die Erfassung von Zeitbezügen. Purple Teaming misst nicht nur Sichtbarkeit, sondern auch Reaktionsfähigkeit. Deshalb sollten mindestens vier Zeitpunkte dokumentiert werden: Ausführung der Aktion, Eingang des Rohereignisses, Generierung des Alerts und erste Analystenreaktion. In SIEM- und EDR-Umgebungen können zwischen diesen Punkten erhebliche Verzögerungen liegen. Eine Detection, die erst nach 20 Minuten sichtbar wird, kann für schnelle Angriffsschritte praktisch wertlos sein.

Ein Beispiel für eine technische Dokumentation eines Detection-Falls:

Aktion: PowerShell mit Base64-encoded command auf WIN10-22
Startzeit: 09:14:08
Datenquellen: Sysmon Event ID 1, PowerShell Operational Log 4104, EDR Process Telemetry
Rohsichtbarkeit:
- Sysmon Event vorhanden um 09:14:09
- 4104 fehlt wegen deaktiviertem Script Block Logging
- EDR erfasst Commandline gekürzt
Detection-Regel:
- SIEM Query sucht nach "EncodedCommand" in process.command_line
- Regelversion: DET-PS-014 v3.2
Alert:
- nicht ausgelöst
Ursache:
- Feldnormalisierung im Parser entfernt Parameterpräfix
Bewertung:
- Telemetrie teilweise vorhanden, Detection fehlgeschlagen
Maßnahme:
- Parser korrigieren, alternative Erkennung über Parent-Child und Base64-Muster ergänzen
Retest:
- geplant nach Parser-Deployment

Diese Art der Dokumentation macht sofort sichtbar, dass das Problem nicht in der Angriffssimulation lag, sondern in der Datenaufbereitung. Genau solche Erkenntnisse sind im Purple Teaming wertvoll, weil sie direkt in Und Log Analyse, Und Alerting und SIEM-Tuning überführt werden können.

Auch Reaktionsschritte müssen präzise dokumentiert werden. „SOC hat reagiert“ ist kein verwertbarer Status. Relevant sind Ticket-Erstellung, Klassifizierung, Eskalation, Host-Isolation, Benutzerkontakt, IOC-Suche, Scope-Erweiterung und Abschlussbewertung. Nur so lässt sich erkennen, ob eine Detection operativ nutzbar ist. Ein Alert ohne handlungsfähigen Kontext erzeugt oft nur zusätzliche Last.

In Umgebungen mit Und Edr, Und Xdr oder zentralem Und Siem sollte außerdem dokumentiert werden, welche Plattform die primäre Sichtbarkeit geliefert hat. Das verhindert Fehleinschätzungen. Nicht selten wird ein Erfolg dem SIEM zugeschrieben, obwohl die eigentliche Erkennung aus dem EDR kam. Für Architekturentscheidungen ist diese Unterscheidung essenziell.

Viele Purple-Team-Berichte sehen auf den ersten Blick professionell aus und sind trotzdem operativ schwach. Der Grund ist fast immer derselbe: Sie dokumentieren Aktivität statt Erkenntnis. Ein Bericht mit vielen Screenshots, Toolnamen und ATT&CK-Referenzen kann dennoch wertlos sein, wenn nicht klar wird, welche Detection-Lücke existierte, warum sie existierte und wie sie geschlossen werden soll.

Der häufigste Fehler ist unpräzise Sprache. Formulierungen wie „Angriff wurde erkannt“, „Monitoring war erfolgreich“ oder „Blue Team reagierte angemessen“ sind ohne Kriterien unbrauchbar. Was genau wurde erkannt? Durch welche Regel? Mit welcher Verzögerung? Welche Felder waren sichtbar? Welche Entscheidung traf der Analyst? Ohne diese Details bleibt die Aussage nicht überprüfbar.

Ein weiterer Fehler ist fehlende Reproduzierbarkeit. Wenn Kommandos, Parameter, Host-Kontext oder verwendete Binärdateien nicht dokumentiert werden, kann ein Retest nicht sauber durchgeführt werden. Das ist besonders problematisch, wenn Detection-Tuning auf Basis eines einmaligen Tests erfolgt. Ohne Reproduzierbarkeit bleibt unklar, ob eine spätere Verbesserung tatsächlich dieselbe Technik adressiert oder nur eine ähnliche Variante.

Ebenfalls kritisch ist die Vermischung von Prävention und Detection. Wenn eine Aktion durch EDR blockiert wurde, ist das nicht automatisch ein Detection-Erfolg. Es kann ein Präventionserfolg sein, ohne dass ausreichende Sichtbarkeit für Analysten vorhanden ist. Umgekehrt kann eine Aktion vollständig sichtbar sein, aber ohne Blockierung. Dokumentation muss diese Unterschiede klar trennen, sonst entstehen falsche Sicherheitsannahmen.

Sehr häufig fehlen auch Negativbefunde. Teams dokumentieren ausgelöste Alerts, aber nicht die erwarteten Signale, die ausblieben. Gerade diese Lücken sind jedoch der Kern des Purple Teamings. Ein fehlendes Event, ein unvollständiges Feldmapping oder eine nicht onboardete Datenquelle sind oft wichtiger als ein einzelner Treffer. Wer nur positive Ergebnisse dokumentiert, verliert die eigentliche Verbesserungsperspektive.

Besonders schädlich sind diese Fehlerbilder:

• Testfälle ohne klare Zielsetzung, Erfolgskriterien oder ATT&CK-Zuordnung.
• Alerts ohne Nachweis der zugrunde liegenden Rohtelemetrie und Regelversion.
• Findings ohne konkrete Maßnahme, Verantwortlichkeit und Retest-Termin.
• Berichte, die nur den Endzustand zeigen, aber keine Iterationen und Änderungen nachvollziehbar machen.

Ein weiterer typischer Fehler ist die fehlende Trennung zwischen Beobachtung und Schlussfolgerung. Beispiel: „Kein Alert, weil das SIEM die Technik nicht erkennt.“ Diese Aussage ist oft voreilig. Vielleicht war die Datenquelle nicht angebunden, vielleicht war die Uhrzeit des Endpunkts falsch, vielleicht wurde das relevante Feld im Parser verworfen. Solange diese Ursachen nicht dokumentiert und geprüft wurden, ist die Schlussfolgerung unsauber.

Auch organisatorische Fehler schlagen direkt auf die Dokumentation durch. Wenn Red Team, Blue Team und Detection Engineers unterschiedliche Bezeichnungen für denselben Testfall verwenden, entstehen Inkonsistenzen. Wenn Zeitstempel in verschiedenen Zeitzonen notiert werden, werden Korrelationen unzuverlässig. Wenn Hostnamen während der Übung geändert oder Snapshots zurückgesetzt werden, ohne dies zu vermerken, sind spätere Analysen kaum noch belastbar.

Viele dieser Probleme tauchen auch in Typische Fehler Beim Purple Teaming und bei allgemeinen Fehler auf. In der Dokumentation wirken sie jedoch besonders stark, weil sie nicht nur den aktuellen Test schwächen, sondern auch alle Folgeaktivitäten: Tuning, Retest, Audit-Nachweis, Lessons Learned und Trendanalyse.

Vorlagen sind dann nützlich, wenn sie Struktur geben, ohne technische Realität zu glätten. Eine gute Vorlage zwingt dazu, die relevanten Informationen vollständig zu erfassen. Eine schlechte Vorlage erzeugt nur Checkbox-Berichte. Im Purple Teaming sollten Vorlagen deshalb eng an den operativen Ablauf angepasst sein.

Für Testfälle empfiehlt sich ein Formular mit festen Feldern und einem Freitextbereich für Besonderheiten. Feste Felder sorgen für Vergleichbarkeit, Freitext für Kontext. Typische Pflichtfelder sind Testfall-ID, Technik, Zielsystem, Operator, Startzeit, Endzeit, Ausführungsweg, erwartete Telemetrie, tatsächliche Telemetrie, Alert-Status, Analystenreaktion, Bewertung und Maßnahme. Ergänzend sinnvoll sind Felder für Risiko bei Produktivnähe, Abbruchgrund und Referenzen auf Tickets oder Detection-Regeln.

Für Findings sollte die Vorlage nicht nur den Mangel beschreiben, sondern den Wirkmechanismus. Ein gutes Finding lautet nicht „PowerShell wurde nicht erkannt“, sondern etwa: „Encoded PowerShell wurde im SIEM nicht erkannt, weil der Parser das Commandline-Feld normalisiert und den Parameterindikator entfernt; EDR-Telemetrie war vorhanden, wurde aber nicht korreliert.“ Diese Formulierung ist technisch belastbar und direkt umsetzbar.

Retests brauchen eine eigene Struktur. Viele Teams ergänzen nur „behoben“ oder „nicht behoben“. Das ist zu grob. Ein Retest muss dokumentieren, welche Änderung vorgenommen wurde, welche Version aktiv war, ob dieselbe Technik erneut ausgeführt wurde, ob Nebenwirkungen entstanden und ob die Detection robust gegen Varianten ist. Sonst wird aus einer punktuellen Korrektur keine nachhaltige Verbesserung.

Ein kompaktes Finding-Template kann so aussehen:

Finding-ID: F-PT-031
Titel: Fehlende Erkennung von lateralem WMI-Start
Betroffene Technik: Remote Execution / WMI
Betroffene Systeme: Windows Server Segment B
Beschreibung:
WMI-basierte Prozessstarts waren in der zentralen SIEM-Korrelation nicht sichtbar.
Rohereignisse lagen auf dem Zielhost vor, wurden aber nicht ingestiert.
Auswirkung:
Laterale Bewegung kann ohne zentrale Alarmierung erfolgen.
Ursache:
WinRM/WMI-relevante Logs nicht an Collector angebunden.
Empfehlung:
Log-Onboarding ergänzen, Detection-Regel für verdächtige WMI-Spawn-Ketten erstellen.
Priorität: Hoch
Verantwortlich: Detection Engineering / Windows Platform
Retest-Datum: 2026-05-14

Für Retests ist zusätzlich eine Variantensicht sinnvoll. Wenn eine Regel auf einen exakten String tuned wurde, kann sie beim nächsten leicht veränderten Kommando wieder versagen. Deshalb sollte dokumentiert werden, ob nur der Originalfall oder auch Varianten geprüft wurden, etwa alternative Parent-Prozesse, andere Parameterreihenfolge, andere Benutzerkontexte oder andere Hostrollen.

In der Praxis funktionieren Vorlagen am besten, wenn sie in den laufenden Lifecycle integriert sind und nicht als separates Berichtswesen danebenstehen. Das bedeutet: dieselbe Testfall-ID taucht in Planung, Durchführung, Detection-Tuning und Retest wieder auf. So entsteht eine durchgehende Nachvollziehbarkeit vom ersten Test bis zur bestätigten Verbesserung.

Wer mit konkreten Szenarien arbeitet, sollte Vorlagen außerdem an die Übungsart anpassen. Ein Web-naher Test mit Burp und Identitätsbezug braucht andere Felder als ein Endpoint-zentrierter Credential-Access-Test oder ein Cloud-Szenario. Ergänzende Beispiele finden sich in Beispiele, Szenarien und Real World Beispiele.

ATT&CK-Mapping ist nützlich, aber nur dann, wenn es präzise und nicht dekorativ eingesetzt wird. Viele Berichte listen Taktiken und Techniken auf, ohne den konkreten Testfall sauber zu verankern. Das führt zu einer Scheingenauigkeit. Eine gute Dokumentation nutzt ATT&CK nicht als Etikett, sondern als Struktur für Hypothesen, Coverage-Bewertung und Priorisierung.

Der erste Schritt ist die Zuordnung auf Technik- oder Subtechnik-Ebene, soweit sinnvoll. Der zweite Schritt ist die Beschreibung der konkreten Variante. Der dritte Schritt ist die Verknüpfung mit Datenquellen, Detection-Logik und Reaktionsanforderungen. Erst dadurch wird aus einem ATT&CK-Verweis ein operativ nutzbarer Nachweis. Wenn etwa T1021 dokumentiert wird, muss klar sein, ob es um SMB, RDP, WinRM oder WMI ging, welche Authentifizierung genutzt wurde und welche Telemetrie erwartet wurde.

Besonders stark wird Dokumentation, wenn sie zusätzlich mit Threat Modeling verbunden ist. Dann wird nicht nur festgehalten, dass eine Technik getestet wurde, sondern warum sie für die eigene Umgebung relevant ist. Ein Unternehmen mit starkem Microsoft-Fokus, Hybrid Identity und zentralem EDR hat andere Prioritäten als eine OT-nahe Umgebung oder ein Cloud-native Stack. Dokumentation sollte deshalb immer den Bezug zum realen Bedrohungsmodell herstellen. Das verbessert Priorisierung und verhindert Aktionismus.

Für Detection Engineering ist die Dokumentation die Brücke zwischen Test und Regelentwicklung. Ein Detection Engineer braucht nicht nur die Information, dass ein Test fehlgeschlagen ist, sondern auch die Rohartefakte: Event-Beispiele, Feldnamen, Normalisierungsprobleme, Prozessketten, Hostrollen und False-Positive-Risiken. Ohne diese Details entstehen Regeln, die entweder zu eng oder zu laut sind. Gute Purple-Team-Dokumentation liefert genau diese Grundlage.

Ein praxistauglicher Mapping-Block pro Testfall kann folgende Elemente enthalten:

Threat Hypothesis:
Ein Angreifer mit Benutzerzugang versucht laterale Bewegung über PsExec-ähnliche Mechanismen.

ATT&CK Mapping:
TA0008 Lateral Movement
T1021.002 SMB/Windows Admin Shares
T1569.002 Service Execution

Relevanz für Umgebung:
Administrationsfreigaben in Segment C vorhanden, mehrere Legacy-Server ohne EDR-Tamper-Protection.

Erwartete Datenquellen:
EDR Process Tree, Service Creation Events, SMB Session Logs, Authentifizierungslogs.

Detection Objective:
Service-basierte Remote-Ausführung mit verdächtiger Parent-Child-Kette innerhalb von 2 Minuten alarmieren.

Response Objective:
SOC validiert Hostpaar, Benutzerkontext und initiiert Containment bei nicht autorisierter Quelle.

Mit dieser Struktur wird klar, dass Dokumentation nicht nur rückblickend arbeitet, sondern auch die Zielarchitektur für Detection und Response beschreibt. Das ist besonders wertvoll in Teams, die Purple Teaming eng mit Und Threat Detection und Detection Verbessern verzahnen.

Ein weiterer Vorteil sauberer ATT&CK-Verknüpfung ist die Trendanalyse. Wenn mehrere Iterationen dokumentiert werden, lässt sich erkennen, welche Techniken konsistent gut erkannt werden, wo wiederkehrende Lücken bestehen und welche Datenquellen strukturell schwach sind. Diese Sicht ist deutlich wertvoller als eine bloße Liste einzelner Findings, weil sie Architektur- und Investitionsentscheidungen unterstützt.

Metriken im Purple Teaming sind nur dann sinnvoll, wenn sie auf sauber dokumentierten Einzelbeobachtungen beruhen. Reine Prozentzahlen ohne Kontext führen schnell in die Irre. „80 Prozent der Techniken erkannt“ klingt gut, sagt aber wenig aus, wenn unklar bleibt, welche Techniken getestet wurden, wie tief die Variantenprüfung war und ob die Erkennung operativ verwertbar war.

Belastbare Metriken entstehen aus standardisierten Testfällen. Jeder Testfall liefert Statuswerte wie verhindert, erkannt, verspätet erkannt, teilweise sichtbar, unsichtbar oder nicht testbar. Daraus lassen sich Trends ableiten. Wichtig ist jedoch, dass diese Statuswerte klar definiert sind. „Erkannt“ sollte beispielsweise nur gelten, wenn ein verwertbarer Alert innerhalb eines definierten Zeitfensters mit ausreichendem Kontext erzeugt wurde. Andernfalls ist der Status zu optimistisch.

Für Management-Zwecke sollten Metriken verdichtet, aber nicht entkernt werden. Eine gute Zusammenfassung zeigt etwa: Welche priorisierten Angriffspfade wurden getestet? Welche Detection-Lücken sind kritisch? Welche Maßnahmen haben den größten Effekt? Welche Verbesserungen wurden seit der letzten Iteration bestätigt? Diese Sicht ist deutlich nützlicher als eine lange Liste technischer Events ohne Priorisierung.

Gleichzeitig darf die technische Rückverfolgbarkeit nicht verloren gehen. Jede aggregierte Kennzahl sollte auf konkrete Testfälle zurückführbar sein. Wenn ein Bereich als „verbessert“ markiert wird, muss nachvollziehbar sein, welche Detection-Regel, welches Log-Onboarding oder welche Härtungsmaßnahme dafür verantwortlich war. Sonst sind Metriken politisch anschlussfähig, aber technisch wertlos.

In der Praxis haben sich folgende Kennzahlen bewährt: Anteil verwertbar erkannter Testfälle, mittlere Alert-Latenz, mittlere Zeit bis Analystenreaktion, Anteil testbarer gegenüber nicht testbaren Fällen, Anteil bestätigter Verbesserungen nach Retest und Anzahl wiederkehrender Lücken pro Datenquelle. Diese Kennzahlen zeigen nicht nur Sicherheitsniveau, sondern auch Messfähigkeit und Prozessreife.

Ein Beispiel für eine verdichtete Auswertung:

Testperiode: Q2
Durchgeführte Testfälle: 24
Davon testbar: 21
Verwertbar erkannt: 11
Teilweise sichtbar: 5
Unsichtbar: 5
Mittlere Alert-Latenz: 3m 40s
Mittlere Analystenreaktion: 9m 15s
Häufigste Ursachen für Lücken:
1. Fehlende Log-Quellen
2. Parser-/Feldnormalisierungsfehler
3. Zu enge Detection-Logik
Bestätigte Verbesserungen nach Retest: 6 von 8 Maßnahmen

Solche Kennzahlen sind besonders nützlich in Verbindung mit Metriken und Erfolg Messen. Entscheidend bleibt jedoch: Zahlen dürfen nie den technischen Befund ersetzen. Ein einzelner unsichtbarer Credential-Access-Pfad kann kritischer sein als mehrere erfolgreich erkannte Low-Value-Techniken.

Für Audits, Governance und interne Steuerung ist außerdem wichtig, dass Maßnahmen mit Verantwortlichen, Fristen und Retest-Status dokumentiert werden. Nur so wird aus einem Bericht ein Steuerungsinstrument. Reife Teams führen dafür ein Maßnahmenregister, das direkt mit Testfall-IDs und Findings verknüpft ist. Dadurch lässt sich jederzeit nachweisen, welche Lücke offen, in Bearbeitung, umgesetzt oder per Retest bestätigt geschlossen ist.

Die beste Struktur nützt wenig, wenn sie im Alltag nicht gepflegt wird. Deshalb muss Dokumentation an die tatsächlichen Arbeitsmittel des Teams angepasst sein. In vielen Umgebungen besteht der Stack aus Ticket-System, Wiki, SIEM, EDR-Konsole, Chat, Git-Repository und gegebenenfalls einem Case-Management-System. Die Frage ist nicht, ob alles in einem Tool liegen muss, sondern wie Referenzen und Zuständigkeiten sauber verbunden werden.

Ein praxistauglicher Ansatz trennt zwischen führendem Dokument und referenzierten Belegen. Das führende Dokument enthält Scope, Testfall-IDs, Bewertungen, Maßnahmen und Status. Belege wie Query-Exports, Event-Samples, Screenshots, PCAPs, Detection-Regeln oder Parser-Diffs werden referenziert, aber nicht unstrukturiert eingebettet. So bleibt das Dokument lesbar und gleichzeitig tief genug für technische Nacharbeit.

Für Detection-Regeln und Parser ist Versionskontrolle essenziell. Änderungen sollten mit Testfall-IDs verknüpft werden. Wenn eine Sigma-Regel, eine Splunk-Suche oder ein ELK-Parser angepasst wird, muss aus dem Commit oder Change-Record hervorgehen, welcher Purple-Team-Befund die Änderung ausgelöst hat. Das schafft Nachvollziehbarkeit und verhindert, dass Tuning-Entscheidungen später nicht mehr begründet werden können.

Auch die Ablage von Rohdaten braucht Disziplin. Event-Exports, Host-Artefakte und Query-Ergebnisse sollten konsistent benannt werden, idealerweise mit Testfall-ID, Datum, System und Artefakttyp. Sonst werden spätere Retests unnötig aufwendig. Besonders bei mehreren parallelen Übungen oder bei Zusammenarbeit zwischen SOC, Detection Engineering und Plattformteams ist eine klare Benennung unverzichtbar.

Im Alltag bewährt sich folgende Artefakttrennung:

/purple-teaming/
  /2026-Q2/
    /planning/
      test-matrix.xlsx
      scope-and-rules-of-engagement.pdf
    /execution/
      PT-017-operator-log.md
      PT-017-siem-query-results.csv
      PT-017-edr-screenshots/
    /findings/
      F-PT-031.md
      action-register.xlsx
    /retest/
      PT-017-retest-2026-05-14.md
      parser-diff.txt

Welche Tools konkret eingesetzt werden, hängt von der Umgebung ab. In Microsoft-lastigen Umgebungen dominieren oft Defender, Sentinel und Ticketsysteme; in anderen Setups Splunk, ELK oder alternative EDR/XDR-Plattformen. Entscheidend ist weniger das Produkt als die Konsistenz der Dokumentation. Ergänzende Werkzeugübersichten finden sich unter Tools, Tools Liste und Open Source Tools.

Ein weiterer Praxispunkt ist Zugriffsschutz. Purple-Team-Dokumentation enthält oft sensible Informationen: Detection-Lücken, Hostnamen, Admin-Pfade, Log-Schwächen, Response-Defizite. Diese Informationen müssen geschützt, aber für berechtigte Teams zugänglich sein. Zu restriktive Ablage verhindert Zusammenarbeit, zu offene Ablage erhöht das Risiko interner Fehlverwendung. Deshalb sollten Rollen, Freigaben und Aufbewahrungsfristen definiert sein.

Schließlich muss Dokumentation wartbar bleiben. Wenn Vorlagen zu komplex sind, werden sie im Tagesgeschäft umgangen. Wenn sie zu grob sind, liefern sie keine verwertbaren Erkenntnisse. Gute Teams überprüfen ihre Dokumentationsstruktur regelmäßig anhand realer Übungen und passen Felder dort an, wo wiederkehrend Informationen fehlen oder unnötiger Aufwand entsteht.