Einfuehrung: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Purple Teaming ist kein eigenstaendiger Ersatz fuer Penetrationstests, Red Teaming oder Blue Teaming. Es ist ein Arbeitsmodus, in dem offensive und defensive Rollen gezielt zusammenarbeiten, um Erkennung, Reaktion und technische Schutzmassnahmen messbar zu verbessern. Der Kern besteht nicht darin, moeglichst spektakulaere Angriffe zu simulieren, sondern Sicherheitskontrollen unter realistischen Bedingungen zu pruefen und direkt zu optimieren.

In der Praxis scheitern viele Teams bereits an der Grundannahme. Statt Purple Teaming als kontrollierte Validierung von Detection und Response zu behandeln, wird es oft als lockerer Workshop verstanden. Das fuehrt zu unklaren Zielen, schwachen Testfaellen und Ergebnissen ohne operative Wirkung. Ein sauberer Ansatz beginnt deshalb mit einer klaren Definition: Welche Angreifertechnik wird geprueft, welche Datenquellen sollen anschlagen, welche Analytik soll ausloesen, welche Reaktion wird erwartet und wie wird Erfolg gemessen?

Wer den Unterschied zu anderen Formaten verstehen will, sollte die Abgrenzung zu Purple Team Vs Red Team Vs Blue Team sowie zu Vs Penetrationstest sauber nachvollziehen. Ein klassischer Penetrationstest sucht primaer nach Schwachstellen und Fehlkonfigurationen. Purple Teaming dagegen fragt: Wird die Aktivitaet gesehen, korrekt eingeordnet und in vertretbarer Zeit bearbeitet?

Der operative Mehrwert entsteht durch kurze Lernzyklen. Ein Angriffsschritt wird ausgefuehrt, Telemetrie wird geprueft, Regeln werden angepasst, Logging wird erweitert und der Test wird erneut gefahren. Genau diese Iteration unterscheidet reife Purple-Programme von einmaligen Uebungen. Deshalb ist Purple Teaming eng mit Und Detection Engineering, Und Threat Hunting und einem belastbaren Workflow verbunden.

Ein weiterer zentraler Punkt: Purple Teaming ist kein Produkt. Weder ein EDR noch ein SIEM noch ein Framework loesen das Problem allein. Werkzeuge helfen nur dann, wenn Hypothesen, Testdesign, Datengrundlage und Auswertung stimmen. Ohne diese Basis produziert selbst teure Technologie nur Rauschen, false positives und Scheinsicherheit.

Purple Teaming liefert den groessten Nutzen dort, wo bereits defensive Kontrollen vorhanden sind, deren Wirksamkeit aber unklar ist. Das betrifft vor allem Umgebungen mit SIEM, EDR, XDR, zentralem Logging, Cloud-Telemetrie und einem SOC. In solchen Landschaften existieren viele Datenquellen, aber oft nur begrenzte Gewissheit darueber, ob relevante Angriffstechniken wirklich erkannt werden.

Ein typischer Anwendungsfall ist die Validierung von Angriffspfaden entlang der MITRE-ATT&CK-Taktiken. Statt allgemein von Initial Access, Persistence oder Lateral Movement zu sprechen, wird eine konkrete Technik ausgewaehlt und in einer kontrollierten Umgebung nachgestellt. Danach wird geprueft, ob Prozessstarts, Parent-Child-Beziehungen, Registry-Aenderungen, Netzwerkverbindungen, Script-Ausfuehrung oder Authentifizierungsereignisse sichtbar sind. Die Verbindung zu Und Mitre Attack und Mitre Attack Mapping ist deshalb kein Formalismus, sondern die Grundlage fuer reproduzierbare Tests.

Besonders sinnvoll ist Purple Teaming in folgenden Situationen:

• nach Einfuehrung neuer Sicherheitswerkzeuge wie EDR, SIEM oder XDR, um reale Sichtbarkeit statt Herstellerannahmen zu pruefen
• nach groesseren Infrastrukturveraenderungen wie Cloud-Migration, Active-Directory-Hardening oder Netzwerksegmentierung
• vor Audits, Krisenuebungen oder Management-Reviews, wenn belastbare Aussagen zur Erkennungsfaehigkeit benoetigt werden
• nach Sicherheitsvorfaellen, um beobachtete Angriffsmuster gezielt gegen bestehende Kontrollen zu validieren
• im Rahmen kontinuierlicher Verbesserung, wenn Detection Use Cases systematisch erweitert werden sollen

Auch in spezialisierten Umgebungen ist der Ansatz wertvoll. In Cloud-Plattformen muessen andere Telemetriequellen und Kontrollpunkte betrachtet werden als in klassischen On-Prem-Netzen. Wer in hybriden Architekturen arbeitet, sollte Purple Teaming nicht isoliert auf Endpunkte begrenzen, sondern Identitaeten, API-Aktivitaeten, Control-Plane-Events und Workload-Telemetrie einbeziehen. Vertiefungen dazu finden sich in In Cloud Umgebungen, In Aws und In Azure.

Ein weiterer starker Einsatzbereich ist die Ueberpruefung von SOC-Prozessen. Viele Teams haben Alerts, aber keine belastbare Aussage zu Triage-Qualitaet, Eskalationswegen oder Reaktionszeit. Purple Teaming deckt genau diese Luecke auf, weil nicht nur die technische Erkennung, sondern auch die operative Verarbeitung sichtbar wird. Damit wird aus einer rein technischen Uebung ein Test des gesamten Verteidigungsprozesses.

Die Qualitaet eines Purple-Teamings entscheidet sich vor dem ersten Test. Ohne klaren Scope wird aus einer kontrollierten Uebung schnell ein unstrukturierter Angriffslauf. Ein guter Scope beschreibt Zielsysteme, erlaubte Techniken, Ausschluesse, Zeitfenster, Sicherheitsmassnahmen, Rollback-Optionen und Ansprechpartner. Besonders wichtig ist die Trennung zwischen produktionsnaher Realitaet und betrieblichem Risiko. Nicht jede Technik darf in jeder Umgebung live getestet werden.

Ebenso wichtig sind Hypothesen. Eine Hypothese ist keine vage Erwartung wie „das EDR sollte etwas sehen“, sondern eine konkrete Annahme. Beispiel: Wenn auf einem Windows-Endpunkt PowerShell mit Base64-kodiertem Befehl gestartet wird, dann erzeugt der Host Prozess-Telemetrie, Script-Block-Logging und einen EDR-Alert mit definierter Schwere. Solche Hypothesen zwingen dazu, Datenquellen und erwartete Signale vorab zu benennen.

Vor dem Test muss geklaert sein, welche Telemetrie ueberhaupt vorhanden ist. In vielen Umgebungen fehlt nicht die Erkennung, sondern die Datengrundlage. Sysmon ist unvollstaendig konfiguriert, PowerShell-Logging deaktiviert, DNS-Logs werden nicht zentral gesammelt, Cloud-Audit-Logs laufen nur teilweise ein oder Zeitstempel sind zwischen Systemen nicht synchron. Unter solchen Bedingungen sind Ergebnisse kaum belastbar. Deshalb gehoert zur Vorbereitung immer eine technische Vorpruefung der Datenpfade.

Ein belastbarer Vorbereitungsrahmen umfasst mindestens:

• konkrete Angriffstechniken statt allgemeiner Szenarien
• eindeutige Zielsysteme, Benutzerkontexte und Netzwerksegmente
• bekannte Datenquellen mit validierter Log-Qualitaet und Zeitkonsistenz
• definierte Erfolgskriterien fuer Detection, Triage und Response
• Abbruchkriterien, Freigaben und Kommunikationswege bei Stoerungen

In reifen Umgebungen wird diese Vorbereitung in einen standardisierten Prozess oder eine Methodik ueberfuehrt. Das reduziert Reibung, verhindert Scope-Drift und macht Ergebnisse vergleichbar. Besonders hilfreich ist es, jede Uebung an ein Threat Model zu koppeln. Dann werden nicht beliebige Techniken getestet, sondern solche, die fuer die eigene Branche, Architektur und Angreiferlage relevant sind. Die Verbindung zu Threat Modeling ist deshalb operativ sinnvoll und nicht nur dokumentarisch.

Ein oft uebersehener Punkt ist die Definition von Nicht-Zielen. Wenn eine Uebung auf Credential Access und Lateral Movement fokussiert, dann sollte nicht nebenbei Privilege Escalation, Exfiltration und Cloud Persistence mitgetestet werden. Solche Scope-Erweiterungen wirken produktiv, zerstoeren aber die Auswertbarkeit. Gute Purple-Teams testen scharf abgegrenzte Fragestellungen und iterieren danach kontrolliert weiter.

Ein sauberer Purple-Workflow ist zyklisch. Zuerst wird eine Technik ausgewaehlt, dann kontrolliert ausgefuehrt, anschliessend werden Rohdaten, Alerts und Analystensicht geprueft. Danach folgen Anpassungen an Logging, Parsing, Korrelation, Detection-Logik oder Playbooks. Abschliessend wird dieselbe Technik erneut getestet. Ohne Retest bleibt unklar, ob eine Verbesserung wirklich wirkt oder nur auf dem Papier existiert.

Ein realistischer Ablauf beginnt oft mit einer Minimalvariante der Technik. Statt sofort komplexe Angriffsketten zu simulieren, wird zunaechst ein einzelner Schritt validiert. Beispiel: Ausfuehrung eines bekannten LOLBin, Start einer PowerShell mit auffaelligen Parametern oder Erzeugung eines verdächtigen Scheduled Tasks. Erst wenn die Basissignale sichtbar sind, wird die Komplexitaet erhoeht. Dieses Vorgehen spart Zeit, weil Fehler in Telemetrie und Parsing frueh auffallen.

Ein typischer Ablauf kann so aussehen:

1. Technik und Ziel definieren
2. Testsystem und Benutzerkontext festlegen
3. Baseline-Telemetrie vor dem Test pruefen
4. Angriffsschritt kontrolliert ausfuehren
5. Rohlogs und Alerts korrelieren
6. Detection-Luecken identifizieren
7. Regel, Parser oder Logging anpassen
8. Test wiederholen
9. Ergebnis dokumentieren und Metriken aktualisieren

Entscheidend ist die Trennung zwischen Rohsignal und fertigem Alert. Wenn ein Angriff nicht alarmiert wird, bedeutet das nicht automatisch, dass keine Daten vorhanden sind. Oft existieren die relevanten Events, werden aber nicht geparst, nicht normalisiert oder nicht sinnvoll korreliert. In SIEM-Umgebungen liegt das Problem haeufig in Feldnamen, Zeitfenstern, Join-Logik oder zu aggressiven Filterbedingungen. In EDR-Umgebungen sind es eher Policy-Limits, ausgeschlossene Pfade oder unzureichende Verhaltensregeln.

Genau hier zeigt sich der Wert enger Zusammenarbeit zwischen offensiver und defensiver Seite. Das offensive Team weiss, wie eine Technik in der Praxis aussieht und welche Varianten Angreifer nutzen. Das defensive Team versteht Datenquellen, Regelwerke und betriebliche Nebenwirkungen. Erst diese Kombination fuehrt zu robusten Erkennungen statt zu fragilen Signaturen. Vertiefend dazu passen Collaboration und Communication.

Ein weiterer Erfolgsfaktor ist die Versionierung. Detection-Regeln, Parser, Sigma-Varianten, SIEM-Queries und Testfaelle sollten nachvollziehbar versioniert sein. Sonst ist nach einigen Wochen nicht mehr klar, welche Aenderung welchen Effekt hatte. Reife Teams behandeln Detection Content wie Code: mit Review, Test, Freigabe und Rueckverfolgbarkeit.

Ein klassisches Purple-Szenario ist die Ausfuehrung von PowerShell in Kombination mit Living-off-the-Land-Techniken. Der Grund ist einfach: Diese Aktivitaeten sind in realen Angriffen haeufig, technisch variabel und fuer viele Verteidiger schwer sauber zu erkennen. Gleichzeitig eignen sie sich gut, um die Qualitaet von Prozess-Telemetrie, Command-Line-Logging und Verhaltensanalysen zu pruefen.

Ein oberflaechlicher Test startet nur einen offensichtlichen PowerShell-Befehl und freut sich ueber einen Alert. Das ist wenig aussagekraeftig. Ein brauchbarer Test variiert Parameter, Parent-Prozesse, Benutzerkontexte und Ausfuehrungsarten. Wird PowerShell interaktiv gestartet, per Office-Makro, ueber WMI, via Scheduled Task oder aus einem Service-Kontext? Wird nur der Prozess erkannt oder auch der semantische Inhalt? Gibt es Script-Block-Logging, AMSI-Sichtbarkeit und Korrelation mit nachgelagerten Netzwerkereignissen?

Ein minimales Testmuster kann so aussehen:

powershell.exe -NoProfile -ExecutionPolicy Bypass -EncodedCommand SQBlAHgA...

Wenn darauf kein Alert folgt, beginnt die eigentliche Arbeit. Zuerst wird geprueft, ob der Prozessstart ueberhaupt im Endpunkt-Logging sichtbar ist. Danach, ob die Command Line vollstaendig erfasst wurde. Anschliessend, ob Script-Block-Logs vorhanden sind und ob das SIEM diese korrekt ingestiert. Erst dann lohnt sich die Frage nach einer Detection-Regel. Viele Teams springen direkt zur Regel und uebersehen, dass die Datenbasis lueckenhaft ist.

Dasselbe gilt fuer LOLBins wie rundll32, regsvr32, mshta oder certutil. Eine Detection auf den Dateinamen allein ist schwach, weil legitime Nutzung und Missbrauch eng beieinander liegen. Starke Erkennung entsteht durch Kontext: Parent-Prozess, Pfad, Parameter, Zieladresse, Benutzerrolle, Hosttyp und zeitliche Korrelation mit anderen Events. Genau deshalb sind Beispiele und Mitre Attack Beispiele nur dann wertvoll, wenn sie nicht als starre Signaturliste verstanden werden, sondern als Ausgangspunkt fuer kontextbezogene Detection.

In der Praxis zeigt sich oft ein wiederkehrendes Muster: Ein Test wird erkannt, eine leicht veraenderte Variante aber nicht. Das ist kein Randproblem, sondern der Normalfall. Gute Purple-Teams testen deshalb nie nur den Happy Path einer Erkennung, sondern auch nahe Varianten. Erst wenn eine Regel gegen typische Umgehungen robust bleibt und gleichzeitig die Fehlalarmrate tragbar ist, kann von echter Verbesserung gesprochen werden.

Die haeufigsten Fehler sind nicht technisch komplex, aber operativ teuer. Der erste Fehler ist Zielunklarheit. Wenn nicht feststeht, ob Detection validiert, Analysten trainiert, Playbooks getestet oder Management-Risiken bewertet werden sollen, entstehen Ergebnisse ohne Fokus. Der zweite Fehler ist zu grosse Komplexitaet. Ganze Kill Chains sehen beeindruckend aus, verdecken aber, an welcher Stelle die Verteidigung tatsaechlich versagt.

Ein dritter Fehler ist die Verwechslung von Tool-Demos mit Purple Teaming. Ein Hersteller-Playbook oder ein fertiges Detection-Pack ersetzt keine Validierung in der eigenen Umgebung. Unterschiedliche Host-Konfigurationen, Logging-Policies, Parser, Zeitzonen, Proxy-Wege und Benutzerrollen veraendern das Ergebnis massiv. Deshalb muessen Techniken immer gegen die reale eigene Telemetrie getestet werden.

Besonders schaedlich sind folgende Fehlmuster:

• zu breite Scopes mit zu vielen Techniken in einer einzigen Uebung
• fehlende Baseline-Pruefung der Datenquellen vor dem Test
• keine Trennung zwischen Rohdaten, Detection-Logik und Analystenprozess
• kein Retest nach Regelanpassungen
• Erfolgsmessung nur ueber Anzahl der Alerts statt ueber Qualitaet und Reaktionsfaehigkeit

Ein weiterer Klassiker ist die politische Verzerrung. Wenn Teams Angst haben, schlecht dazustehen, werden Tests weichgespuelt, Ergebnisse beschoenigt oder kritische Luecken nicht sauber dokumentiert. Purple Teaming funktioniert nur in einer Kultur, in der technische Defizite offen benannt werden duerfen. Das Ziel ist nicht, ein Team zu gewinnen zu lassen, sondern die Verteidigung objektiv zu verbessern.

Ebenso problematisch ist fehlende Dokumentation. Ohne nachvollziehbare Testschritte, Zeitpunkte, Hostnamen, Benutzerkontexte, Hashes, Event-IDs und Query-Versionen lassen sich Ergebnisse spaeter kaum reproduzieren. Dann wird dieselbe Diskussion in jeder Uebung neu gefuehrt. Wer tiefer in Fehlmuster einsteigen will, findet passende Vertiefungen unter Typische Fehler Beim Purple Teaming und Fehler.

Schliesslich scheitern viele Programme an fehlender Priorisierung. Nicht jede Detection-Luecke ist gleich kritisch. Wenn ein Team Wochen in exotische Techniken investiert, waehrend grundlegende Erkennung fuer Credential Dumping, Remote Execution oder verdächtige Authentifizierungen fehlt, ist der Ressourceneinsatz falsch gewichtet. Gute Purple-Programme priorisieren nach Risiko, Angreiferrelevanz und betrieblicher Exponierung.

Werkzeuge sind wichtig, aber nur als Verstaerker eines guten Prozesses. Ein Purple-Teaming-Setup braucht in der Regel drei Ebenen: Angriffssimulation, Telemetrieerfassung und Auswertung. Fuer die Simulation kommen je nach Zielumgebung unterschiedliche Mittel zum Einsatz, von einfachen nativen Bordmitteln bis zu Frameworks fuer kontrollierte Emulation. Fuer die Auswertung sind SIEM, EDR, XDR und spezialisierte Analyseplattformen relevant. Entscheidend ist jedoch nicht die Anzahl der Tools, sondern die Qualitaet der Datenpfade zwischen ihnen.

In Windows-zentrierten Umgebungen sind Prozessstarts, Command Lines, Registry-Aenderungen, Services, Scheduled Tasks, Netzwerkverbindungen, Anmeldungen und PowerShell-Artefakte oft die tragenden Signale. In Linux-Umgebungen verschiebt sich der Fokus auf Prozessbaum, Shell-Historie, sudo-Nutzung, systemd, Audit-Logs, Cron, SSH und Netzwerk-Telemetrie. In Cloud-Umgebungen kommen API-Calls, IAM-Aenderungen, Storage-Zugriffe, Control-Plane-Events und Workload-Sensorik hinzu.

Viele Teams investieren zuerst in offensive Tools und zu wenig in Datenqualitaet. Das fuehrt zu einem paradoxen Zustand: Angriffe lassen sich immer realistischer simulieren, aber die Verteidigung kann sie mangels sauberer Telemetrie nicht auswerten. Deshalb sollte die Frage nicht lauten, welches Tool am spektakulaersten ist, sondern welche Datenquelle fuer die gewaehlte Technik unverzichtbar ist und wie verlaesslich sie vorliegt. Passende Vertiefungen finden sich unter Tools, Tools Liste und Und Siem.

Ein Beispiel aus der Praxis: Ein Team testet verdächtige PowerShell-Nutzung und sieht im SIEM nur gekuerzte Command Lines. Die Detection ist dadurch praktisch blind. Das Problem liegt nicht in der Query, sondern im Upstream-Logging oder im Feldmapping des Collectors. Ein anderes Team testet Lateral Movement ueber PsExec, erkennt aber nur den Service-Start auf dem Zielsystem, nicht die vorgelagerte Authentifizierung und die Admin-Freigabenutzung. Auch hier fehlt nicht zwingend eine Regel, sondern die Korrelation ueber mehrere Datenquellen.

Wer Werkzeuge bewertet, sollte deshalb immer vier Fragen stellen: Welche Technik soll simuliert werden? Welche Rohdaten muessen dafuer sichtbar sein? Wo werden diese Daten normalisiert? Und wie wird aus ihnen ein belastbarer Alert oder Hunt-Use-Case? Ohne diese Kette bleibt Tool-Auswahl oft nur Beschaffung ohne Sicherheitsgewinn.

Ohne Metriken bleibt Purple Teaming eine Serie interessanter Einzelereignisse. Der eigentliche Wert entsteht erst, wenn Fortschritt ueber Zeit sichtbar wird. Dabei sind einfache Kennzahlen oft nuetzlicher als komplizierte Dashboards. Relevant ist nicht, wie viele Tests insgesamt gelaufen sind, sondern wie sich Erkennungsabdeckung, Triage-Qualitaet und Reaktionsfaehigkeit fuer priorisierte Techniken entwickeln.

Eine brauchbare Metriklandschaft trennt technische und operative Sicht. Technisch geht es um Fragen wie: Wurde die Aktivitaet in den Rohdaten sichtbar? Wurde sie korrekt geparst? Wurde ein Alert erzeugt? War die Schwere passend? Operativ geht es um Zeit bis zur Sichtbarkeit, Zeit bis zur Triage, Qualitaet der Einordnung, Eskalationsweg und Wirksamkeit der Gegenmassnahme. Diese Trennung verhindert, dass ein fehlender Alert vorschnell als Analystenfehler oder umgekehrt als reines Tool-Problem interpretiert wird.

Ein gutes Reporting dokumentiert nicht nur den Befund, sondern auch die Ursache. Beispiel: „Technik nicht erkannt“ ist zu unpraezise. Besser ist: „Prozessstart vorhanden, Command Line abgeschnitten, daher Query-Bedingung nicht erfuellt; Parser-Anpassung umgesetzt; Retest erfolgreich.“ Solche Aussagen sind technisch verwertbar und schaffen Klarheit fuer Engineering, SOC und Management.

Besonders nuetzliche Kennzahlen sind unter anderem Detection Coverage pro priorisierter Technik, Retest-Erfolgsquote nach Anpassungen, mittlere Triage-Zeit, Anteil verwertbarer Alerts, false-positive-Rate nach Regelhaertung und Zeit bis zur Schliessung kritischer Detection-Luecken. Wer das systematisch aufsetzt, arbeitet faktisch an Erfolg Messen, Metriken und belastbarem Reporting.

Wichtig ist ausserdem die Nachvollziehbarkeit ueber mehrere Uebungen hinweg. Wenn dieselbe Technik in verschiedenen Quartalen getestet wird, muessen Unterschiede in Scope, Hosttyp, Benutzerkontext und Tooling dokumentiert sein. Sonst werden Aenderungen in den Ergebnissen falsch interpretiert. Reife Teams fuehren deshalb Testkataloge, Detection-Matrizen und Versionshistorien, statt nur einzelne Reports abzulegen.

Der beste Einstieg in Purple Teaming ist nicht das grosse Programm, sondern ein eng begrenzter, technisch sauberer Pilot. Geeignet sind wenige, aber relevante Techniken mit hoher Angreifernaehe und guter Messbarkeit. Typische Startpunkte sind verdächtige PowerShell-Nutzung, Credential Access auf Testsystemen, Scheduled Tasks, Remote Service Creation, Missbrauch von LOLBins oder auffaellige Authentifizierungssequenzen. Ziel ist nicht Breite, sondern belastbare Lernkurven.

Ein sinnvoller Start besteht aus einem kleinen Kernteam mit offensiver, defensiver und infrastruktureller Kompetenz. Dieses Team definiert Scope, waehlt Techniken, prueft Telemetrie, fuehrt Tests durch, haertet Detection und dokumentiert Ergebnisse. Erst wenn dieser Ablauf stabil funktioniert, sollte die Ausweitung auf weitere Plattformen, Cloud-Workloads oder komplexere Angriffspfade erfolgen. Wer zu frueh skaliert, skaliert meist nur Unklarheit.

Fuer Unternehmen mit wenig Erfahrung lohnt sich ein Blick auf Purple Teaming Für Anfänger, Roadmap und Best Practices. Entscheidend ist jedoch weniger das Lesen als die Disziplin in der Umsetzung. Jede Uebung sollte mit einer klaren Frage beginnen und mit einer nachweisbaren Verbesserung enden.

Ein pragmatischer Einfuehrungsplan sieht oft so aus:

Phase 1: Pilot mit 3 bis 5 priorisierten Techniken
Phase 2: Aufbau wiederverwendbarer Testfaelle und Detection-Standards
Phase 3: Einbindung von SOC, Incident Response und Plattform-Teams
Phase 4: Ausweitung auf Cloud, Identitaeten und kritische Geschaeftsprozesse
Phase 5: Regelmaessige Retests, Metriken und Management-Reporting

Wichtig ist die institutionelle Verankerung. Purple Teaming darf nicht nur von Einzelpersonen getragen werden. Es braucht feste Verantwortlichkeiten fuer Testdesign, Detection-Engineering, Freigaben, Dokumentation und Nachverfolgung offener Massnahmen. Sonst verpuffen Erkenntnisse nach jeder Uebung. In reifen Organisationen ist Purple Teaming deshalb eng mit Im Unternehmen, Integration und dem operativen Lifecycle verbunden.

Am Ende zaehlt nicht, wie oft Purple Teaming stattgefunden hat, sondern ob die Verteidigung nachweisbar besser geworden ist. Wenn priorisierte Techniken heute schneller erkannt, sauberer eingeordnet und wirksamer beantwortet werden als vor drei Monaten, dann funktioniert das Programm. Genau daran sollte es gemessen werden.