Metriken: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Purple Teaming ohne belastbare Metriken endet fast immer in subjektiven Aussagen wie „Detection wurde verbessert“, „das SOC war schneller“ oder „die Übung war erfolgreich“. Solche Aussagen klingen gut, sind aber operativ wertlos. In einer realen Sicherheitsorganisation muss messbar sein, welche Angriffstechnik getestet wurde, welche Telemetrie vorhanden war, welche Erkennung gegriffen hat, wie schnell reagiert wurde und ob die Verbesserung nachweisbar reproduzierbar ist. Genau an diesem Punkt trennt sich eine saubere Sicherheitsvalidierung von einer reinen Demo.

Der Kernfehler liegt meist darin, dass Aktivität mit Wirksamkeit verwechselt wird. Viele Teams zählen durchgeführte Übungen, erzeugte Alerts oder geschriebene Detection Rules. Diese Zahlen sehen in Reports gut aus, sagen aber wenig über die tatsächliche Verteidigungsfähigkeit aus. Eine hohe Alert-Anzahl kann sogar ein Zeichen für schlechte Qualität sein, wenn Analysten mit Rauschen überlastet werden. Ebenso ist eine große Zahl getesteter ATT&CK-Techniken kein Beweis für Reife, wenn die Tests oberflächlich waren oder keine belastbare Validierung der Erkennung stattgefunden hat.

Gute Metriken müssen drei Fragen beantworten: Was wurde getestet? Wie gut wurde es erkannt oder verhindert? Welche Verbesserung ist nach der Iteration tatsächlich eingetreten? Wer sich mit Purple Teaming ernsthaft beschäftigt, muss Metriken deshalb als Steuerungsinstrument verstehen und nicht als Reporting-Dekoration. Das gilt unabhängig davon, ob die Organisation gerade erst mit Was Ist Purple Teaming startet oder bereits einen etablierten Workflow betreibt.

In der Praxis entstehen brauchbare Kennzahlen nur dann, wenn Red-, Blue- und Detection-Engineering-Perspektive zusammengeführt werden. Das Red Team liefert die technische Wahrheit über die ausgeführte Aktion. Das Blue Team bewertet Sichtbarkeit, Alarmierung und Reaktion. Detection Engineering übersetzt Beobachtungen in robuste Regeln, Korrelationen und Datenanforderungen. Ohne diese gemeinsame Sicht werden Metriken verzerrt. Dann misst das Red Team nur Ausführungserfolg, das SOC nur Ticketzahlen und das Management nur Prozentwerte ohne Kontext.

Eine weitere Ursache für schlechte Metriken ist fehlende Trennung zwischen Sicherheitskontrolle und Testdesign. Wenn eine Technik nicht erkannt wurde, kann das an fehlender Telemetrie, falscher Log-Pipeline, unzureichender Normalisierung, schlechter Regelqualität, Timing-Problemen oder einer unrealistischen Simulation liegen. Wer nur „detected“ oder „not detected“ dokumentiert, verliert die eigentliche Ursache. Genau deshalb müssen Metriken immer mit Testbedingungen, Datenquellen und Annahmen verknüpft werden.

Saubere Kennzahlen im Purple Teaming sind keine universellen Standardwerte, sondern kontextgebundene Messgrößen. Ein Windows-zentriertes Enterprise-SOC misst anders als ein Cloud-first-Team, ein OT-Umfeld anders als ein klassisches Office-Netz. Trotzdem bleibt die Grundregel gleich: Metriken müssen reproduzierbar, technisch nachvollziehbar und entscheidungsrelevant sein. Alles andere erzeugt Scheinsicherheit.

In belastbaren Purple-Teaming-Programmen lassen sich Metriken grob in vier Gruppen einteilen: Abdeckung, Erkennungsqualität, Reaktionsgeschwindigkeit und Stabilität der Kontrolle. Diese Einteilung ist praxistauglich, weil sie sowohl technische Details als auch Management-Perspektiven verbindet. Wer nur eine Gruppe misst, bekommt ein verzerrtes Bild.

Abdeckungsmetriken beantworten, welche Angriffsflächen, Plattformen, Datenquellen und ATT&CK-Techniken tatsächlich geprüft wurden. Dabei reicht es nicht, einfach T1059 oder T1003 als „getestet“ zu markieren. Entscheidend ist, welche Sub-Technik, welches Betriebssystem, welcher Ausführungskontext und welche Sicherheitskontrollen betroffen waren. Ein PowerShell-Test auf einem Admin-Host ist nicht gleichbedeutend mit einer validierten Erkennung für PowerShell-Missbrauch im gesamten Unternehmen. Gute Coverage-Metriken sind deshalb immer präzise segmentiert.

Qualitätsmetriken bewerten, ob eine Erkennung fachlich brauchbar ist. Dazu gehören True-Positive-Rate, False-Positive-Verhalten, Kontexttiefe des Alerts, Eindeutigkeit der Triage-Hinweise und die Fähigkeit, zusammenhängende Aktivität zu korrelieren. Ein Alert, der nur „suspicious process“ meldet, ist operativ deutlich schwächer als ein Alert, der Parent-Child-Beziehung, Commandline, Benutzerkontext, Host-Rolle und ATT&CK-Zuordnung liefert. Qualität ist nicht nur eine Frage des Auslösens, sondern der Verwertbarkeit.

Geschwindigkeitsmetriken sind im SOC-Umfeld besonders relevant. Gemeint sind nicht nur klassische MTTD oder MTTR, sondern feinere Zwischenwerte: Zeit bis zum ersten relevanten Event im SIEM, Zeit bis zur Korrelation, Zeit bis zur Analysten-Sichtbarkeit, Zeit bis zur Eskalation und Zeit bis zur wirksamen Eindämmung. Gerade im Zusammenspiel mit Und Siem und Und Soc zeigt sich häufig, dass die eigentliche Verzögerung nicht in der Detection Rule, sondern in Parsing, Indexierung oder Ticket-Weiterleitung liegt.

Stabilitätsmetriken prüfen, ob eine Kontrolle dauerhaft funktioniert oder nur unter Laborbedingungen. Eine Detection, die heute anschlägt, aber nach einem Agent-Update, einem Log-Format-Wechsel oder einer geänderten Prozesskette ausfällt, ist operativ unsicher. Purple Teaming muss deshalb nicht nur einmalige Treffer messen, sondern Wiederholbarkeit über Zeit. Genau hier entsteht die Verbindung zu Iteration und zu einem belastbaren Prozess.

• Coverage: Welche Technik, welche Plattform, welcher Scope, welche Datenquelle wurden tatsächlich validiert?
• Qualität: Wie präzise, verwertbar und rauscharm ist die Erkennung im Analystenalltag?
• Geschwindigkeit: Wie lange dauert es von der Aktion bis zur Sichtbarkeit, Bewertung und Reaktion?
• Stabilität: Bleibt die Kontrolle auch nach Änderungen an Infrastruktur, Logging oder Tooling wirksam?

Diese vier Gruppen sollten nicht isoliert betrachtet werden. Eine hohe Coverage bei schlechter Qualität ist wertlos. Eine schnelle Reaktion ohne ausreichende Sichtbarkeit führt zu Fehlentscheidungen. Eine stabile Kontrolle ohne relevante Abdeckung schützt nur einen kleinen Teil der Angriffsfläche. Gute Metriken entstehen daher immer als zusammenhängendes Modell und nicht als lose KPI-Sammlung.

Der häufigste Workflow-Fehler besteht darin, Metriken erst am Ende einer Übung zu sammeln. Dann fehlen Zeitstempel, Randbedingungen und technische Details. Saubere Messung beginnt vor der ersten Simulation. Bereits in der Planungsphase müssen Zieltechnik, Testziel, Scope, Erfolgskriterien, erwartete Datenquellen und Messpunkte festgelegt werden. Ohne diese Vorarbeit ist später kaum noch nachvollziehbar, ob ein fehlender Alert ein Detection-Problem oder ein Testdesign-Problem war.

Ein belastbarer Ablauf startet mit einer Hypothese. Beispiel: „Credential Dumping über LSASS-Zugriff auf Windows-Servern soll durch EDR-Telemetrie erkannt und innerhalb von fünf Minuten im SIEM sichtbar werden.“ Diese Hypothese ist messbar. Sie definiert Technik, Plattform, Datenquelle und Zeitfenster. Danach wird die Testausführung vorbereitet: Host-Auswahl, Benutzerkontext, Tooling, Logging-Status, Baseline-Traffic und Freigaben. Erst dann folgt die eigentliche Simulation.

Während der Ausführung müssen Rohdaten und Beobachtungen parallel erfasst werden. Das Red Team dokumentiert exakte Befehle, Hashes, Zeitpunkte, Hostnamen, Benutzerkontext und Abweichungen vom Plan. Das Blue Team protokolliert eingehende Events, Alerts, Korrelationen, Analystenreaktionen und Eskalationen. Detection Engineering hält fest, welche Regelversion, welche Parser und welche Datenpipelines aktiv waren. Nur wenn diese drei Sichtweisen zusammengeführt werden, entsteht eine belastbare Metrik.

Ein praxistauglicher Workflow orientiert sich oft an einem klaren Ablauf mit Vorbereitung, Ausführung, Beobachtung, Auswertung, Verbesserung und Re-Test. In reiferen Umgebungen wird das als kontinuierlicher Lifecycle betrieben. Der entscheidende Punkt ist: Metriken dürfen nicht nur Endergebnisse beschreiben, sondern müssen den Weg dorthin sichtbar machen. Sonst bleibt unklar, an welcher Stelle die Verteidigung tatsächlich versagt oder funktioniert hat.

Ein Beispiel aus der Praxis: Eine Simulation erzeugt keinen Alert. Ohne Workflow-Disziplin lautet das Ergebnis oft einfach „nicht erkannt“. Mit sauberer Messung kann das Ergebnis differenziert werden: EDR hat Event erzeugt, Event wurde lokal gespeichert, aber nicht an den Collector übertragen; SIEM erhielt keine Daten; daher keine Korrelation; Analyst hatte keine Sichtbarkeit. Diese Auflösung ist entscheidend, weil die Verbesserung dann nicht in einer neuen Detection Rule liegt, sondern in der Telemetrie-Pipeline.

Besonders in Umgebungen mit mehreren Tools ist eine eindeutige Zeitnormalisierung Pflicht. Unterschiedliche Zeitzonen, Clock Drift, verzögerte Ingestion und asynchrone Verarbeitung verfälschen sonst Geschwindigkeitsmetriken massiv. Wer MTTD misst, ohne Event-Zeit, Ingest-Zeit und Alert-Zeit sauber zu trennen, produziert unbrauchbare Zahlen. In professionellen Programmen werden deshalb alle Zeitpunkte standardisiert und in der Dokumentation klar benannt.

Die Verbindung zu Dokumentation und Reporting ist direkt: Nur strukturierte Erfassung macht spätere Trendanalysen möglich. Einzelne Übungen liefern Momentaufnahmen, erst konsistente Datensätze über mehrere Iterationen zeigen echte Reifeentwicklung.

Viele Organisationen messen Dinge, die leicht zu zählen sind, aber wenig Aussagekraft besitzen. Dazu gehört die Anzahl geschriebener Detection Rules, die Zahl getesteter Techniken, die Menge erzeugter Alerts oder die Anzahl durchgeführter Purple-Teaming-Sessions. Solche Kennzahlen können als Aktivitätsindikatoren nützlich sein, sind aber keine Wirksamkeitsmetriken. Wer sie als Erfolgsmaßstab verwendet, optimiert auf Beschäftigung statt auf Verteidigungsfähigkeit.

Ein klassisches Beispiel ist die Quote „x Prozent der ATT&CK-Techniken abgedeckt“. Diese Zahl wirkt beeindruckend, ist aber oft methodisch schwach. Wurde die Technik realistisch simuliert? Wurde nur ein einzelner Testfall ausgeführt? Galt die Abdeckung für alle relevanten Plattformen oder nur für einen Laborhost? Wurde Prävention, Detection oder Response gemessen? Ohne diese Einordnung ist die Prozentzahl kaum belastbar. Genau deshalb sollte ATT&CK-Mapping immer mit technischem Kontext kombiniert werden, wie es auch in Und Mitre Attack und Mitre Attack Mapping relevant ist.

Ebenso problematisch ist die reine Alert-Anzahl. Mehr Alerts bedeuten nicht automatisch bessere Sicherheit. In vielen SOCs ist das Gegenteil der Fall: Je mehr unpräzise Alerts erzeugt werden, desto höher die Analystenbelastung und desto größer die Wahrscheinlichkeit, dass echte Signale untergehen. Eine gute Metrik betrachtet daher nicht nur, ob ein Alert ausgelöst wurde, sondern ob er korrekt priorisiert, verständlich und handlungsfähig war.

Auch MTTD wird häufig falsch verwendet. Wenn der Startzeitpunkt unklar ist, der Angriff in mehreren Phasen verläuft oder nur ein später Teil der Aktivität erkannt wurde, ist eine einzelne MTTD-Zahl irreführend. Wurde die erste Ausführung erkannt oder erst die nachgelagerte Seitwärtsbewegung? Wurde die Technik selbst erkannt oder nur eine Folgeaktivität? Ohne präzise Definition verliert die Kennzahl ihren Wert.

Ein weiterer Fehler ist das Vermischen von Präventions- und Detection-Erfolg. Wenn eine Aktion durch Application Control blockiert wurde, ist das positiv. Es ist aber nicht dasselbe wie eine erfolgreiche Detection. In Reports werden solche Ergebnisse oft zusammengeworfen, wodurch die tatsächliche Sichtbarkeit überschätzt wird. Für operative Entscheidungen müssen Blockierung, Sichtbarkeit, Alarmierung und Reaktion getrennt ausgewiesen werden.

• „Technik getestet“ ohne Angabe von Plattform, Scope und Testtiefe
• „Alert vorhanden“ ohne Bewertung von Präzision und Analysten-Nutzbarkeit
• „MTTD verbessert“ ohne saubere Definition des Messbeginns
• „Abdeckung gestiegen“ ohne Nachweis reproduzierbarer Re-Tests
• „Erfolg“ trotz fehlender Trennung zwischen Prävention und Detection

Diese Fehlmetriken entstehen oft aus Zeitdruck oder aus dem Wunsch nach einfachen Dashboards. In der Praxis sind sie gefährlich, weil sie Investitionen in die falsche Richtung lenken. Ein Team baut dann mehr Regeln, obwohl eigentlich Logging fehlt. Oder es optimiert auf schnellere Ticket-Erstellung, obwohl die eigentliche Schwäche in der Event-Korrelation liegt. Wer typische Fehler vermeiden will, sollte sich auch mit Typische Fehler Beim Purple Teaming und Fehler beschäftigen.

Für den operativen Alltag haben sich einige Kernmetriken bewährt, wenn sie sauber definiert und technisch unterlegt sind. Dazu gehört zunächst die Telemetrie-Verfügbarkeit. Bevor über Detection gesprochen wird, muss klar sein, ob die relevanten Datenquellen überhaupt vorhanden, vollständig und zeitnah verfügbar sind. Dazu zählen Prozessstarts, Commandlines, Netzwerkverbindungen, Registry-Änderungen, Authentifizierungsereignisse, Script-Logs, EDR-Sensor-Events oder Cloud-Audit-Daten. Fehlt diese Grundlage, sind alle nachgelagerten Metriken verzerrt.

Darauf folgt die Detection-Auslösequote pro Testfall. Diese Kennzahl ist nur dann sinnvoll, wenn Testfälle klar definiert sind. Ein Testfall sollte Technik, Variante, Plattform, Benutzerkontext und Zielkontrolle enthalten. So lässt sich später unterscheiden, ob eine Regel nur bei Standardausführung funktioniert oder auch bei leicht veränderten Parametern. In reifen Umgebungen wird zusätzlich gemessen, wie robust die Detection gegen kleine Variationen ist. Das ist besonders wichtig, wenn mit Und Edr, Und Xdr oder mehreren Sensorquellen gearbeitet wird.

Eine weitere zentrale Metrik ist die Alert-Qualität. Sie lässt sich anhand mehrerer Unterpunkte bewerten: Enthält der Alert ausreichenden Kontext? Ist die ATT&CK-Zuordnung korrekt? Gibt es Triage-Hinweise? Ist die Priorisierung angemessen? Lässt sich der Alert einem konkreten Host und Benutzer zuordnen? Solche Qualitätsmerkmale entscheiden darüber, ob ein Analyst schnell und sicher reagieren kann oder erst mühsam Rohdaten zusammensuchen muss.

Im Response-Bereich sind Zeit bis zur Analysten-Sichtung, Zeit bis zur Eskalation und Zeit bis zur Eindämmung besonders relevant. Diese Werte sollten nicht als globale Durchschnittszahlen geführt werden, sondern nach Schweregrad, Schichtmodell, Datenquelle und Use Case segmentiert werden. Sonst verdecken Mittelwerte operative Schwächen. Ein SOC kann im Durchschnitt gut aussehen und trotzdem bei bestimmten Techniken systematisch zu langsam sein.

Wichtig ist außerdem die Re-Test-Erfolgsquote nach Verbesserungen. Viele Teams implementieren neue Regeln oder Parser, prüfen aber nicht konsequent nach, ob die Maßnahme unter denselben Bedingungen tatsächlich wirkt. Ohne Re-Test bleibt jede Verbesserung eine Annahme. Purple Teaming ist deshalb eng mit Und Detection Engineering und Und Threat Detection verbunden: Jede Änderung muss validiert werden, nicht nur dokumentiert.

Ein praxistauglicher Metriksatz für SOC und Detection Engineering umfasst daher nicht nur Trefferquoten, sondern die gesamte Kette von Datenverfügbarkeit bis Reaktionswirksamkeit. Erst diese End-to-End-Sicht zeigt, ob eine Verteidigung im Ernstfall funktioniert.

Beispiel für einen Testfall-Datensatz

Test-ID: PT-WIN-CRDUMP-01
Technik: T1003.001 OS Credential Dumping: LSASS Memory
Plattform: Windows Server 2019
Hostrolle: Applikationsserver
Benutzerkontext: lokaler Administrator
Ausführungszeit: 2026-04-02T10:14:33Z
Erwartete Datenquellen:
- EDR Process Event
- Sysmon Event ID 10 / 1 je nach Konfiguration
- SIEM Ingestion
Erwartete Kontrolle:
- High Severity Alert
- Analystensichtbarkeit < 5 Minuten
Ergebnis:
- EDR Event vorhanden
- SIEM Ingestion verzögert um 11 Minuten
- Kein korrelierter Alert
Root Cause:
- Parser verwirft Feld "GrantedAccess"
Maßnahme:
- Parser-Fix, Re-Test geplant

Solche Datensätze sind deutlich wertvoller als ein einfaches „nicht erkannt“. Sie machen Ursachen sichtbar und erlauben echte Verbesserung statt kosmetischer KPI-Pflege.

Eine einzelne Kennzahl ohne Vergleichswert ist fast immer unzureichend. Wenn ein Alert heute nach sieben Minuten sichtbar wird, ist das gut oder schlecht? Die Antwort hängt von der bisherigen Leistung, der Technik, dem Datenpfad und dem Risiko ab. Deshalb braucht Purple Teaming Baselines. Eine Baseline beschreibt den Ausgangszustand vor Verbesserungsmaßnahmen. Erst durch den Vergleich zwischen Vorher und Nachher wird sichtbar, ob eine Maßnahme tatsächlich Wirkung entfaltet hat.

Baselines sollten pro Use Case und pro Technikfamilie geführt werden. Credential Access, Lateral Movement, Defense Evasion und Command Execution haben unterschiedliche technische Eigenschaften und unterschiedliche Anforderungen an Telemetrie und Reaktion. Eine globale Durchschnittsmetrik über alle Tests verschleiert diese Unterschiede. Sinnvoller ist es, Trends pro Kategorie, Plattform und Datenquelle zu verfolgen.

Ein weiterer Punkt ist die Segmentierung nach Umgebung. Ein On-Prem-Windows-Server, ein Linux-Container in Kubernetes und ein Cloud-Workload in AWS erzeugen unterschiedliche Daten, unterschiedliche Verzögerungen und unterschiedliche Kontrollpunkte. Wer diese Umgebungen in einer einzigen Kennzahl zusammenfasst, verliert die operative Aussagekraft. Deshalb sollten Metriken immer entlang der tatsächlichen Architektur geschnitten werden, etwa nach Endpoint, Server, Cloud, Identität oder Netzwerk.

Trendanalysen sind besonders wertvoll, wenn sie mit Iterationen verknüpft werden. Nach jeder Purple-Teaming-Runde wird gemessen, welche Kontrollen verbessert wurden, welche weiterhin Lücken aufweisen und welche neuen Probleme durch Änderungen entstanden sind. So entsteht ein realistisches Bild der Sicherheitsreife. Diese Arbeitsweise passt eng zu Best Practices, zu einer belastbaren Strategie und zu einem systematischen Erfolg Messen.

Wichtig ist dabei, Trends nicht mit linearem Fortschritt zu verwechseln. In der Praxis verschlechtern sich einzelne Kennzahlen zeitweise, etwa nach Agent-Updates, Architekturänderungen, neuen Parsern oder geänderten Log-Retention-Regeln. Das ist kein Zeichen für Scheitern, sondern ein normaler Effekt dynamischer Umgebungen. Gute Metriken machen solche Rückschritte sichtbar, damit sie früh korrigiert werden können.

Ein häufiger Fehler in Trendanalysen ist die fehlende Konsistenz der Testbedingungen. Wenn ein Re-Test mit anderem Tooling, anderem Benutzerkontext oder anderer Hostrolle durchgeführt wird, ist der Vergleich nur eingeschränkt belastbar. Deshalb müssen Baselines immer zusammen mit den Testparametern gespeichert werden. Nur so bleibt nachvollziehbar, ob eine Verbesserung auf die Kontrolle oder auf veränderte Rahmenbedingungen zurückzuführen ist.

Wenn Metriken schlecht ausfallen, liegt das Problem nicht automatisch in der Detection Rule. In vielen Fällen ist die Ursache vorgelagert. Die häufigste Schwachstelle ist unvollständige oder instabile Telemetrie. Sensoren sind nicht auf allen Hosts aktiv, Logging ist unterschiedlich konfiguriert, Felder fehlen, Events werden gedroppt oder nur verzögert übertragen. In solchen Situationen ist jede Aussage über Detection-Qualität nur eingeschränkt belastbar.

Direkt danach folgt Parsing und Normalisierung. Ein Event kann technisch vorhanden sein und trotzdem für die Erkennung unbrauchbar sein, wenn relevante Felder falsch extrahiert, abgeschnitten oder in inkonsistente Schemas überführt werden. Gerade in heterogenen SIEM-Landschaften ist das ein Dauerproblem. Viele vermeintliche Detection-Lücken sind in Wahrheit Datenqualitätsprobleme. Wer Metriken sauber interpretiert, prüft deshalb immer zuerst die Datenkette vom Sensor bis zur Suchabfrage.

Ein weiterer häufiger Grund ist ein zu enger oder falscher Scope. Wenn nur wenige Testsysteme betrachtet werden, entstehen schnell optimistische Ergebnisse, die sich nicht auf die Gesamtumgebung übertragen lassen. Ein Detection Use Case kann auf einem gehärteten Referenzhost hervorragend funktionieren und auf älteren Servern komplett versagen. Metriken müssen deshalb klar ausweisen, für welchen Scope sie gelten.

Unrealistische Tests verfälschen Ergebnisse in beide Richtungen. Zu einfache Simulationen erzeugen künstlich gute Trefferquoten, weil sie bekannte Standardmuster auslösen. Zu künstliche oder unpassende Simulationen können umgekehrt legitime Kontrollen umgehen, ohne dass daraus eine reale Schwäche ableitbar ist. Gute Purple-Teaming-Metriken basieren daher auf realistischen Angriffsvarianten, wie sie in Use Cases, Szenarien und Real World Beispiele abgebildet werden.

• Telemetrie fehlt oder ist auf relevanten Systemen nicht konsistent aktiviert
• Parser oder Normalisierung zerstören Felder, die für Korrelationen benötigt werden
• Der Testscope ist zu klein oder nicht repräsentativ für die Produktionsrealität
• Simulationen sind zu generisch, zu laut oder technisch nicht realitätsnah
• Zeitstempel und Ingestion-Pfade werden nicht sauber getrennt gemessen

In der Praxis lohnt sich bei schlechten Messwerten fast immer eine Root-Cause-Analyse entlang der gesamten Verarbeitungskette. Erst wenn klar ist, wo das Signal verloren geht, kann die richtige Maßnahme gewählt werden. Sonst wird häufig an der falschen Stelle optimiert, etwa durch neue Regeln, obwohl eigentlich Sensor-Rollout oder Parser-Fix nötig wären.

Ein gutes Purple-Teaming-Reporting muss zwei Ebenen gleichzeitig bedienen: operative Tiefe für Analysten, Engineers und Incident Responder sowie verdichtete Steuerungsinformationen für Führungskräfte. Der Fehler vieler Reports besteht darin, nur eine dieser Ebenen zu bedienen. Reine Management-Dashboards verlieren technische Ursachen aus dem Blick. Reine Rohdaten-Reports sind für Entscheidungen auf Leitungsebene zu granular.

Die Lösung ist ein mehrschichtiges Reporting-Modell. Auf oberster Ebene stehen wenige belastbare Kennzahlen: validierte Use Cases, erkannte versus nicht erkannte Testfälle, Zeit bis zur Sichtbarkeit, Re-Test-Erfolgsquote und offene kritische Lücken. Darunter folgt die technische Ebene mit Testfall-Details, Datenquellen, Alert-Inhalten, Root Causes und konkreten Maßnahmen. So bleibt die Verbindung zwischen Zahl und technischer Realität erhalten.

Wichtig ist, dass Management-Kennzahlen nicht losgelöst von Risiko interpretiert werden. Eine nicht erkannte Technik in einem selten genutzten Laborsystem ist anders zu bewerten als dieselbe Lücke auf Domain Controllern oder in Cloud-Identitätsdiensten. Gute Reports priorisieren deshalb nach Angriffsrelevanz, Asset-Kritikalität und Ausnutzbarkeit. Das macht Metriken handlungsfähig.

Für technische Teams sollte jeder Report mindestens folgende Fragen beantworten: Welche Technik wurde wie ausgeführt? Welche Datenquelle hätte Sichtbarkeit liefern müssen? Welche Kontrolle hat versagt oder funktioniert? Wo liegt die Ursache? Welche Maßnahme ist geplant? Wann erfolgt der Re-Test? Ohne diese Struktur bleibt Reporting rückblickend statt steuernd.

Besonders wirksam ist Reporting dann, wenn es direkt in Verbesserungsprozesse überführt wird. Ein Report darf nicht mit der Feststellung „Lücke vorhanden“ enden. Er muss Verantwortlichkeiten, Fristen und Re-Test-Kriterien enthalten. In reifen Programmen wird das mit Ticketing, Detection Backlog und Engineering-Sprints verknüpft. Dadurch wird Purple Teaming zu einem operativen Verbesserungsmechanismus und nicht zu einer isolierten Übung.

Beispiel für eine kompakte Management-Zusammenfassung

Zeitraum: Q2
Durchgeführte Testfälle: 28
Kritische Testfälle: 9
Sofort erkannt: 14
Verzögert erkannt: 6
Nicht erkannt: 8
Durchschnitt Zeit bis Analystensichtbarkeit: 6m 40s
Re-Test nach Fix erfolgreich: 5 von 7
Hauptursachen offener Lücken:
1. Fehlende Endpoint-Telemetrie auf Legacy-Servern
2. Parser-Fehler in Authentifizierungslogs
3. Unzureichende Korrelation zwischen EDR und SIEM

Operative Prioritäten:
- Sensor-Rollout auf verbleibende Server
- Parser-Korrektur und Validierung
- Neue Korrelation für Credential Access Use Cases

Solche Zusammenfassungen sind nur dann belastbar, wenn darunter technische Evidenz liegt. Genau diese Verbindung macht den Unterschied zwischen kosmetischem Reporting und echter Steuerung.

Wirklich nützliche Metriken entstehen nicht durch einzelne Workshops, sondern durch wiederholbare Workflows. Ein sauberer Workflow beginnt mit der Auswahl eines priorisierten Use Cases auf Basis von Risiko, Threat Intelligence, Architektur und vorhandenen Lücken. Danach werden Testziel, Scope, Hypothese, Datenquellen und Erfolgskriterien definiert. Erst dann folgt die technische Vorbereitung der Simulation.

Während der Durchführung müssen alle Beteiligten mit derselben Referenz arbeiten: eindeutige Test-ID, synchronisierte Zeitbasis, definierte Kommunikationskanäle und klare Rollen. Das Red Team dokumentiert die Wahrheit der Ausführung. Das Blue Team bewertet Sichtbarkeit und Reaktion. Detection Engineering analysiert Datenqualität und Regelverhalten. Diese Zusammenarbeit ist eng mit Collaboration und Communication verbunden. Ohne abgestimmte Kommunikation werden Metriken schnell unvollständig oder widersprüchlich.

Nach der Ausführung folgt die Auswertung mit Root-Cause-Analyse. Dabei wird nicht nur festgehalten, ob ein Test erfolgreich erkannt wurde, sondern warum. Anschließend werden Maßnahmen priorisiert: Logging aktivieren, Parser korrigieren, Regel schärfen, Korrelation ergänzen, Playbook anpassen oder Analysten schulen. Jede Maßnahme erhält einen Verantwortlichen und ein Re-Test-Kriterium. Erst der Re-Test schließt den Zyklus.

Ein sauberer Workflow enthält außerdem Qualitätskontrollen für die Metriken selbst. Dazu gehört die Prüfung, ob Testfälle vergleichbar sind, ob Zeitstempel konsistent erfasst wurden, ob Scope-Änderungen dokumentiert wurden und ob Ergebnisse reproduzierbar sind. Ohne diese Meta-Qualitätssicherung werden Trenddaten mit der Zeit unzuverlässig.

In größeren Umgebungen lohnt sich die Standardisierung über Templates oder Playbooks. Ein strukturiertes Playbook definiert, welche Felder pro Testfall erfasst werden, wie Root Causes klassifiziert werden und wann ein Re-Test als bestanden gilt. Das reduziert Interpretationsspielraum und verbessert die Vergleichbarkeit über Teams hinweg. Ergänzend helfen Checkliste und Best Practices Unternehmen, operative Disziplin dauerhaft zu verankern.

Nachhaltige Verbesserung entsteht nur, wenn Metriken direkt in Engineering und Betrieb zurückfließen. Eine erkannte Lücke muss in konkrete Arbeit übersetzt werden. Ein erfolgreicher Fix muss erneut validiert werden. Ein stabiler Use Case muss regelmäßig regressionsgetestet werden. Genau dadurch wird aus Purple Teaming ein kontinuierlicher Verbesserungsprozess statt einer einmaligen Sicherheitsveranstaltung.

Ein typischer Fall aus der Praxis: Ein Team misst für mehrere Credential-Access-Simulationen eine schlechte Detection-Quote und meldet an das Management, dass das SOC bei dieser Technikfamilie unzureichend aufgestellt sei. Die erste Reaktion ist oft, neue Detection Rules zu schreiben. Nach einigen Wochen steigt die Zahl der Alerts, aber die operative Lage verbessert sich kaum. Analysten klagen über Rauschen, und Re-Tests bleiben inkonsistent.

Eine saubere Analyse zeigt dann häufig ein anderes Bild. Die Simulationen wurden auf unterschiedlichen Hosttypen durchgeführt, teilweise mit aktivem EDR-Tamper-Protection, teilweise ohne. Auf einigen Systemen fehlten relevante Prozess- und Handle-Events. Im SIEM wurden bestimmte Felder aus EDR-Daten nicht korrekt normalisiert. Die vorhandene Regel war nicht grundsätzlich schlecht, sondern erhielt auf einem Teil der Systeme schlicht nicht die benötigten Eingabedaten. Die ursprüngliche Kennzahl „Detection-Quote 35 Prozent“ war also zu grob und führte zur falschen Maßnahme.

Nach Aufteilung der Metrik in Teilbereiche entsteht ein belastbares Bild: Telemetrie-Verfügbarkeit 62 Prozent, Parser-Konsistenz 71 Prozent, Detection-Auslösung bei vollständiger Telemetrie 89 Prozent, Analysten-Sichtbarkeit innerhalb von fünf Minuten 54 Prozent. Erst diese Zerlegung zeigt, wo investiert werden muss. Die Priorität liegt nun auf Sensor-Rollout, Parser-Fix und Pipeline-Latenz, nicht auf blindem Regelwachstum.

Nach Umsetzung der Maßnahmen wird derselbe Testfall unter vergleichbaren Bedingungen erneut ausgeführt. Jetzt liegen vollständige Events vor, die Korrelation greift, der Alert enthält verwertbaren Kontext und die Analystensichtbarkeit sinkt auf unter drei Minuten. Die Verbesserung ist nicht nur gefühlt, sondern technisch nachweisbar. Genau so müssen Purple-Teaming-Metriken funktionieren: Sie sollen Ursachen sichtbar machen, Maßnahmen steuern und Fortschritt reproduzierbar belegen.

Wer solche Ergebnisse systematisch erreichen will, sollte Metriken nicht isoliert betrachten, sondern als Teil von Methodik, Framework und operativer Sicherheitsverbesserung. Dann werden Kennzahlen zu einem Werkzeug, das Detection verbessert, Risiken reduziert und Sicherheitskontrollen realitätsnah validiert. Ohne diese Disziplin bleiben Metriken nur Zahlen in einem Dashboard.