Purple Teaming: Detection Engineering im Sprint – so läuft es ab

Viele Unternehmen haben in den letzten Jahren erheblich in Erkennungstechnik investiert: ein SIEM, eine EDR-Lösung auf allen Endpunkten, vielleicht einen Vertrag mit einem externen SOC-Dienstleister. Die Frage, die danach offen bleibt, lautet: Erkennt das alles tatsächlich einen Angriff – oder erzeugt es nur Lizenzkosten und Alarme über fehlgeschlagene Anmeldungen? Die Standardregeln der Hersteller decken Bekanntes ab, aber nicht die konkrete Umgebung, nicht die eigenen Dienstkonten, nicht die Art, wie Administratoren hier arbeiten.

Purple Teaming beantwortet diese Frage ohne Umweg. Ein Angriffsteam führt eine konkrete Angriffstechnik aus, das Verteidigungsteam prüft im selben Moment, ob sie im Log auftaucht, ob ein Alarm entsteht und ob sie blockiert wurde – und passt die Regel an, wenn nicht. Dann die nächste Technik. Das ist Detection Engineering mit eingebautem Praxistest: Statt Regeln gegen Annahmen zu schreiben, werden sie gegen reale Angriffe validiert.

Dieser Beitrag beschreibt, wie ein Purple-Team-Sprint abläuft, welche Rollen beteiligt sind, mit welchen Kennzahlen Sie den Fortschritt messen, wie die ATT&CK-Heatmap als Ergebnisformat funktioniert und warum die DORA-Regulierung das Format für Finanzunternehmen verpflichtend macht.

Was Purple Teaming ist – und was nicht

Der Name leitet sich aus der Mischung ab: Red Team (Angreifer) und Blue Team (Verteidiger) arbeiten nicht gegeneinander, sondern zusammen. Anders als beim Red Teaming ist nichts verdeckt. Das Blue Team weiß, was wann ausgeführt wird, und kann in Echtzeit beobachten, wie seine Werkzeuge reagieren.

Daraus folgt, was Purple Teaming nicht leistet: Es misst keine reale Reaktionszeit und keine Entscheidungsfähigkeit unter Druck. Ob das SOC um drei Uhr nachts einen Alarm richtig einordnet, zeigt nur ein verdeckter Test. Was Purple Teaming leistet, ist die systematische Verbesserung der Erkennungsgrundlage – und zwar schneller als jedes andere Format, weil zwischen Erkenntnis und Korrektur keine Wochen liegen, sondern Minuten.

Purple Teaming ist deshalb der empfohlene Einstieg, bevor ein Unternehmen sein erstes Red Teaming beauftragt. Wer vorher weiß, dass die Erkennung von Kerberoasting oder von verdächtigen PowerShell-Aufrufen fehlt, kann sie aufbauen – und das spätere Red Teaming liefert dann Erkenntnisse über die Reaktion statt eine Liste fehlender Regeln.

Ablauf eines Purple-Team-Sprints

Ein Sprint dauert typischerweise zwei bis fünf Tage und folgt pro Technik demselben Zyklus. Vorab werden die Angriffstechniken ausgewählt, die geprüft werden sollen – im Fachbegriff TTPs (Tactics, Techniques and Procedures) nach MITRE ATT&CK. Die Auswahl orientiert sich an der Bedrohungslage: Techniken, die aktuelle Ransomware-Gruppen nutzen, Techniken aus dem letzten Red-Team-Bericht, oder Techniken, die für das eigene Geschäftsmodell besonders relevant sind.

1. TTP auswählen und Erwartung formulieren. Das Team einigt sich auf eine Technik, etwa T1003.001 (Auslesen von Zugangsdaten aus dem LSASS-Prozess), und formuliert vorab, was passieren sollte: Welches Werkzeug sollte es blockieren? Welches Log sollte es enthalten? Welche Regel sollte alarmieren? Diese Erwartung ist der Maßstab.
2. Technik ausführen. Das Red Team führt die Technik auf einem vereinbarten System aus – mit denselben Werkzeugen und Varianten, die reale Angreifer nutzen, nicht mit einem Lehrbuchbeispiel. Uhrzeit, Host und Parameter werden protokolliert.
3. Prüfen: geloggt, erkannt, blockiert? Das Blue Team sucht in SIEM und EDR nach Spuren. Drei Fragen in dieser Reihenfolge: Ist das Ereignis überhaupt im Log angekommen? Hat eine Regel darauf angesprochen und einen Alarm erzeugt? Wurde die Aktion verhindert? Jede Antwort wird dokumentiert, inklusive der Zeit zwischen Ausführung und Alarm.
4. Regel anpassen oder erstellen. Fehlt das Log, wird die Logquelle konfiguriert. Fehlt der Alarm, wird eine Regel geschrieben oder eine bestehende geschärft. Löst die Regel aus, aber zu spät oder zu ungenau, wird sie verfeinert. Diese Arbeit passiert im Sprint, nicht als Hausaufgabe danach.
5. Wiederholen und verifizieren. Das Red Team führt dieselbe Technik erneut aus, oft in einer leicht abgewandelten Variante, um zu prüfen, ob die neue Regel greift und nicht nur das exakte Werkzeug erkennt. Erst wenn Erkennung und Alarm bestätigt sind, gilt die Technik als abgedeckt. Dann folgt die nächste.

In einem fünftägigen Sprint lassen sich auf diese Weise je nach Komplexität zwischen fünfzehn und vierzig Techniken durcharbeiten. Der Lerneffekt für das Blue Team ist dabei mindestens so wertvoll wie die neuen Regeln: Die Verteidiger sehen, wie Angreifer wirklich arbeiten, und entwickeln ein Gefühl dafür, welche Spuren ein Angriff hinterlässt.

Rollen im Purple Team

• Red-Team-Operator. Führt die Techniken aus, erklärt dem Blue Team Varianten und Umgehungsmöglichkeiten und schlägt vor, welche Artefakte eine robuste Regel auswerten sollte. Gestellt durch den externen Dienstleister.
• Detection Engineer. Schreibt und testet die Erkennungsregeln im SIEM oder EDR. Intern oder beim MSSP angesiedelt; muss Schreibrechte auf die Regelwerke haben, sonst steht der Sprint still.
• SOC-Analyst. Bewertet die erzeugten Alarme so, wie er es im Alltag tun würde, und gibt Rückmeldung, ob ein Alarm verständlich und handhabbar ist. Eine Regel, die technisch korrekt auslöst, aber niemand einordnen kann, ist im Ernstfall wertlos.
• Infrastruktur- oder Plattformverantwortliche. Konfigurieren Logquellen nach, etwa Audit-Richtlinien auf Domänencontrollern oder PowerShell-Logging per Gruppenrichtlinie. Ohne sie bleibt „nicht geloggt“ ein offenes Finding.
• Moderation und Dokumentation. Hält die Ergebnisse pro Technik fest, achtet auf das Zeitbudget und pflegt die Heatmap. Oft übernommen vom Dienstleister, damit sich das interne Team auf die Inhalte konzentriert.

Die Geschäftsführung muss nicht teilnehmen, sollte aber den Sprint beauftragen und die Ergebnisse präsentiert bekommen. Die Heatmap vor und nach dem Sprint ist ein Bild, das ohne Fachwissen verständlich ist.

Kennzahlen: Wie Sie den Fortschritt messen

Die Faustregel 1-10-60 stammt von CrowdStrike: eine Minute erkennen, zehn Minuten bewerten, sechzig Minuten eindämmen. Sie ist ein ambitionierter Richtwert, kein Standard – aber sie macht deutlich, dass Erkennung, die erst nach Stunden alarmiert, gegen eine durchschnittliche Breakout Time von 29 Minuten (CrowdStrike Global Threat Report 2026) zu langsam ist. Die Kennzahlen MTTD und MTTR – mittlere Zeit bis Erkennung und bis Behebung – ergeben sich aus solchen Messungen über mehrere Sprints hinweg.

Die ATT&CK-Heatmap als Ergebnisformat

Das zentrale Ergebnis eines Purple-Team-Sprints ist eine Heatmap über die Matrix von MITRE ATT&CK Enterprise, die derzeit fünfzehn Taktiken von Reconnaissance bis Impact umfasst. Jede getestete Technik erhält eine Farbe: blockiert, erkannt mit Alarm, nur geloggt, unentdeckt, nicht getestet. Die Matrix zeigt auf einen Blick, wo die Erkennung stark ist und wo sie Lücken hat – etwa eine gut abgedeckte Taktik „Execution“ neben einer fast leeren „Credential Access“.

Die Heatmap hat drei Vorteile gegenüber einer Findings-Liste. Erstens ist sie vergleichbar: Die Matrix vor und nach dem Sprint, oder von Quartal zu Quartal, zeigt den Fortschritt sichtbar. Zweitens ist sie priorisierbar: Lücken in Taktiken, die reale Angreifergruppen schwerpunktmäßig nutzen, lassen sich gegen Threat-Intelligence-Berichte abgleichen. Drittens ist sie anschlussfähig: Dieselbe Darstellung nutzen wir im Red-Team-Bericht, sodass Red-Team-Ergebnisse und Purple-Team-Fortschritt in einem Bild zusammenlaufen. Wie Sie die Heatmap im Vorstand präsentieren, beschreibt unser Beitrag zu MITRE ATT&CK für Entscheider.

Wichtig ist Ehrlichkeit in der Darstellung. Eine Technik gilt nur dann als „erkannt“, wenn der Alarm bei einem Analysten ankommt und verständlich ist – nicht, wenn irgendwo ein Logeintrag entsteht, den niemand auswertet. Und eine Heatmap mit 600 Techniken, von denen 40 getestet wurden, sollte die nicht getesteten klar als solche zeigen, statt Vollständigkeit vorzutäuschen.

DORA verlangt Purple Teaming in der Abschlussphase

Für Finanzunternehmen ist Purple Teaming keine Empfehlung mehr, sondern Teil der Pflicht. Die Verordnung (EU) 2022/2554 (DORA) schreibt in Artikel 26 und 27 für benannte Institute Threat-Led Penetration Testing mindestens alle drei Jahre vor. Die zugehörige technische Regulierungsnorm, Delegierte Verordnung (EU) 2025/1190, regelt den Ablauf im Detail: Nach der aktiven Red-Team-Phase von mindestens zwölf Wochen folgt die Abschlussphase mit Red-Team-Report binnen vier Wochen, Blue-Team-Report sowie Replay-Workshop und Purple Teaming binnen zehn Wochen. Die Zusammenfassung geht acht Wochen nach Bestätigung an die zuständige Behörde – in Deutschland BaFin, für bedeutende Institute die EZB, operativ begleitet durch das TLPT Cyber Team der Bundesbank.

Die Logik dahinter ist dieselbe wie in diesem Beitrag: Ein Red Teaming, dessen Ergebnisse nur in einem Bericht landen, verbessert die Verteidigung wenig. Erst wenn Red und Blue Team die Angriffskette gemeinsam nachvollziehen und die erkannten Lücken im Purple Teaming schließen, entsteht der Lerneffekt, den die Regulierung erreichen will. Das TIBER-EU-Rahmenwerk der EZB, im Februar 2025 an die DORA-RTS angepasst, enthält Purple Teaming ebenfalls als festen Bestandteil. Mehr dazu im Beitrag zu DORA-TLPT: Zeitplan, Rollen und Fristen.

Für Unternehmen außerhalb der Finanzregulierung ist diese Vorgabe eine gute Vorlage: Planen Sie nach jedem Red Teaming einen Purple-Team-Sprint ein, der die Detection Gaps aus dem Bericht abarbeitet. Die Kosten dafür sind klein im Vergleich zum Red Teaming selbst – und ohne diesen Schritt verpufft ein erheblicher Teil der Investition.

Fazit

Purple Teaming ist der schnellste Weg von „wir haben ein SIEM“ zu „wir erkennen Angriffe“. Der Sprint-Zyklus aus Ausführen, Prüfen, Anpassen und Wiederholen ersetzt Annahmen durch Nachweise, die Kennzahlen machen den Fortschritt messbar, und die ATT&CK-Heatmap übersetzt ihn in ein Bild, das auch die Geschäftsführung versteht. Als Einstieg vor dem ersten Red Teaming und als Pflichtbestandteil nach einem DORA-TLPT hat das Format seinen festen Platz. Wie wir einen Sprint mit Ihrem Team aufsetzen, welche Techniken wir für Ihre Branche priorisieren und wie wir mit Ihrem MSSP zusammenarbeiten, finden Sie auf der Seite zu unserem Purple Teaming.

Quellen

• Verordnung (EU) 2022/2554 (DORA), Art. 26 und 27; Delegierte Verordnung (EU) 2025/1190 (RTS zu TLPT), eur-lex.europa.eu
• Europäische Zentralbank, TIBER-EU Framework, Fassung Februar 2025, ecb.europa.eu
• MITRE ATT&CK Enterprise Matrix, attack.mitre.org
• CrowdStrike, Global Threat Report 2026 – Breakout Time; CrowdStrike 1-10-60-Regel

Häufige Fragen zum Thema