Mit Ki: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

KI im Purple Teaming ist dann nützlich, wenn klar definiert ist, welche Arbeit beschleunigt werden soll und welche Entscheidungen zwingend menschliche Prüfung erfordern. In realen Umgebungen scheitert der Einsatz selten an fehlender Rechenleistung, sondern fast immer an unklaren Zielen, schlechter Datenbasis und falschen Erwartungen. Ein Sprachmodell ersetzt weder Telemetrie noch Detection Engineering noch operative Erfahrung. Es kann aber Hypothesen strukturieren, Logquellen korrelieren, Testfälle generieren, Erkennungslogik sprachlich und technisch verfeinern und die Zusammenarbeit zwischen Red und Blue Team deutlich beschleunigen.

Im Kern bleibt Purple Teaming ein gemeinsamer Lern- und Verbesserungsprozess. KI verändert nicht das Ziel, sondern die Geschwindigkeit und den Detailgrad einzelner Arbeitsschritte. Besonders stark ist der Nutzen dort, wo wiederkehrende Muster auftreten: Mapping auf ATT&CK-Techniken, Normalisierung von Beobachtungen, Entwurf von Sigma- oder SPL-Abfragen, Priorisierung von Testfällen, Zusammenfassung von Findings und Ableitung nächster Iterationen. Wer dagegen erwartet, dass KI automatisch realistische Angriffe simuliert, präzise Detektionen ohne Fehlalarme erzeugt und dabei noch die Umgebung korrekt versteht, produziert meist nur schnelleren Unsinn.

Ein belastbarer Einstieg beginnt mit einer sauberen Abgrenzung: Welche Aufgaben sind datengetrieben, welche kontextgetrieben und welche risikokritisch? Datengetriebene Aufgaben wie Clustering ähnlicher Alerts, Extraktion von IoCs aus Berichten oder Umformulierung von Detection-Ideen lassen sich gut unterstützen. Kontextgetriebene Aufgaben wie die Bewertung geschäftskritischer Systeme, die Interpretation von Admin-Verhalten oder die Freigabe produktiver Gegenmaßnahmen bleiben menschlich. Risikokritische Aufgaben wie Block-Regeln, Quarantäne, Identitätsmaßnahmen oder Änderungen an produktiven Sensoren dürfen niemals blind aus KI-Ausgaben übernommen werden.

Wer die Grundlagen noch sauber abgrenzen will, sollte zuerst Was Ist Purple Teaming, Methodik und Ki Im Purple Teaming zusammen betrachten. Erst daraus ergibt sich ein realistisches Betriebsmodell. KI ist kein drittes Team neben Red und Blue, sondern ein Werkzeug innerhalb eines kontrollierten Workflows.

In der Praxis entstehen die größten Effekte an drei Stellen: vor der Übung bei der Vorbereitung, während der Übung bei der Hypothesenbildung und nach der Übung bei der Auswertung. Vor der Übung hilft KI beim Zerlegen eines Angriffspfads in überprüfbare Teiltechniken. Während der Übung unterstützt sie beim schnellen Vergleich von beobachteter Telemetrie gegen erwartete Artefakte. Nach der Übung beschleunigt sie die Dokumentation, die Priorisierung von Detection Gaps und die Formulierung konkreter Engineering-Aufgaben.

Entscheidend ist die Reihenfolge. Erst Zielbild, dann Datenlage, dann Testdesign, dann KI-Unterstützung. Wer mit dem Tool beginnt, landet fast immer bei Showcases statt bei belastbaren Verbesserungen. Purple Teaming mit KI funktioniert nur dann sauber, wenn jede KI-Ausgabe als Entwurf behandelt wird, nicht als Wahrheit. Das gilt für Angriffsskripte, Detection Queries, Zusammenfassungen und Risikoaussagen gleichermaßen.

Ein sauberer Workflow trennt die Phasen Vorbereitung, Ausführung und Auswertung. In jeder Phase sind andere KI-Funktionen sinnvoll. In der Vorbereitung geht es um Struktur. Ein realistisches Szenario wird in Taktiken, Techniken, erwartete Telemetrie, vorhandene Sensorik und Erfolgskriterien zerlegt. Genau hier kann KI große Textmengen in handhabbare Arbeitspakete übersetzen. Aus einem Threat-Intel-Bericht oder einem Incident-Postmortem lassen sich Testhypothesen ableiten: Welche Prozesse sollten sichtbar sein, welche Parent-Child-Beziehungen sind verdächtig, welche Registry- oder Dateisystemartefakte müssten entstehen, welche Netzwerkspuren wären plausibel?

Während der Ausführung ist KI vor allem als Assistenzsystem nützlich. Sie kann Live-Beobachtungen gegen vorbereitete Erwartungen spiegeln, Query-Varianten vorschlagen und bei der schnellen Einordnung helfen, ob ein fehlender Alert eher auf fehlende Telemetrie, falsches Parsing oder eine Lücke in der Erkennungslogik zurückgeht. Das spart Zeit, solange die Analysten die Umgebung verstehen. Ohne dieses Verständnis werden Fehlinterpretationen nur beschleunigt.

In der Auswertung ist der Nutzen oft am größten. Purple Teaming erzeugt viele Rohdaten: Screenshots, Befehle, Zeitstempel, Prozessketten, Event-IDs, EDR-Telemetrie, SIEM-Treffer, Fehlalarme, Ausnahmen, Lessons Learned. KI kann diese Daten in konsistente Findings überführen, ähnliche Beobachtungen gruppieren und aus technischen Details konkrete Maßnahmen ableiten. Gute Teams nutzen das, um schneller in die nächste Iteration zu kommen, statt Wochen mit manueller Nachbereitung zu verlieren.

• Vorbereitung: Szenario zerlegen, ATT&CK-Mapping prüfen, erwartete Artefakte definieren, Testfälle priorisieren.
• Ausführung: Queries verfeinern, Telemetrie vergleichen, Hypothesen zu Detection Gaps formulieren, Beobachtungen strukturieren.
• Auswertung: Findings konsolidieren, Maßnahmen ableiten, technische Schulden sichtbar machen, Reporting beschleunigen.

Wichtig ist, dass jede Phase eigene Qualitätskriterien hat. In der Vorbereitung zählt Vollständigkeit. In der Ausführung zählt Nachvollziehbarkeit. In der Auswertung zählt Umsetzbarkeit. KI darf diese Kriterien nicht verwässern. Ein automatisch erzeugter Bericht ist wertlos, wenn die zugrunde liegenden Beobachtungen nicht reproduzierbar sind. Eine automatisch erzeugte Query ist gefährlich, wenn niemand versteht, warum sie anschlägt oder warum sie schweigt.

Wer den Ablauf organisatorisch schärfen will, findet ergänzende Perspektiven in Workflow, Prozess und Ablauf. KI entfaltet ihren Wert nicht isoliert, sondern nur innerhalb eines disziplinierten Betriebsmodells mit klaren Übergaben zwischen Angriffsseite, Detection-Seite und Engineering.

Der häufigste Denkfehler im KI-gestützten Purple Teaming ist die Annahme, dass ein Modell fehlende oder schlechte Telemetrie kompensieren kann. Das Gegenteil ist der Fall. Je schlechter die Datenbasis, desto überzeugender werden falsche Schlüsse formuliert. Ein Modell kann nur mit dem arbeiten, was vorhanden ist: Event-IDs, Prozessdaten, Kommandozeilen, Netzwerkmetadaten, Authentifizierungsereignisse, DNS, Proxy, Cloud-Audit-Logs, EDR-Signale, Asset-Kontext und Identitätsinformationen. Fehlen diese Daten oder sind sie inkonsistent, entstehen blinde Flecken, die durch sprachlich saubere Antworten nur kaschiert werden.

In Windows-Umgebungen zeigt sich das besonders deutlich. Wenn Process Creation Events ohne vollständige CommandLine erfasst werden, kann KI keine belastbaren Aussagen zu LOLBins, Encoded Commands oder Missbrauch legitimer Tools treffen. Wenn Parent-Process-Daten fehlen, wird die Prozesskette unbrauchbar. Wenn Zeitstempel zwischen EDR, SIEM und Domain Controllern nicht sauber synchronisiert sind, scheitert jede Korrelation. Wenn Hostnamen, Benutzerkennungen oder Asset-Tags nicht normalisiert sind, werden Zusammenhänge künstlich getrennt oder falsch verbunden.

Auch im Netzwerkbereich gilt: Ohne Kontext sind Muster wertlos. Ein ausgehender TLS-Flow ist nicht verdächtig, nur weil er selten ist. Erst mit Zielkontext, Prozessbezug, Benutzerkontext, Zeitpunkt und Baseline wird daraus ein verwertbares Signal. KI kann helfen, diese Kontexte zusammenzuführen, aber sie kann sie nicht erfinden. Deshalb muss vor jedem KI-Einsatz geprüft werden, welche Datenquellen für das gewählte Szenario wirklich benötigt werden.

Ein typisches Beispiel: Ein Team simuliert Credential Access und erwartet Spuren in Security Logs, EDR und Sysmon. Die KI schlägt daraufhin mehrere Suchabfragen vor. Keine davon findet etwas. Ohne Datenprüfung wird vorschnell geschlossen, dass die Technik nicht sichtbar war. Tatsächlich war Sysmon auf den betroffenen Hosts nicht aktiv, EDR lieferte nur aggregierte Events und die relevanten Security-Logs wurden wegen Retention-Einstellungen bereits rotiert. Das Problem lag nicht in der Detection-Idee, sondern in der Telemetrieversorgung.

Deshalb gehört vor jede KI-gestützte Analyse eine Telemetrie-Checkliste: Welche Quellen sind aktiv, welche Felder sind vollständig, welche Parser sind stabil, welche Zeitfenster sind verfügbar, welche Systeme sind im Scope und welche Ausnahmen existieren? Erst danach lohnt sich die Generierung oder Verfeinerung von Queries. Besonders relevant ist das im Zusammenspiel mit Und Siem, Und Edr und Und Log Analyse.

Ein reifer Ansatz behandelt Datenqualität als eigenes Arbeitspaket im Purple Teaming. Detection Gaps sind oft nur die sichtbare Oberfläche. Darunter liegen Parser-Probleme, unvollständige Sensorik, uneinheitliche Feldnamen, fehlende Hostklassifizierung und unklare Ownership für Logquellen. KI kann diese Probleme schneller sichtbar machen, aber nicht beheben. Beheben müssen sie Engineering, Plattformbetrieb und Security Operations gemeinsam.

Viele Teams nutzen KI zunächst für Query-Generierung. Das ist sinnvoll, aber nur dann, wenn der Input präzise genug ist. Ein schwacher Prompt erzeugt meist generische Abfragen mit hoher False-Positive-Rate oder mit Feldern, die in der eigenen Plattform gar nicht existieren. Ein guter Prompt beschreibt Plattform, Datenquelle, Feldnamen, Zieltechnik, erwartetes Verhalten, Ausschlüsse und Qualitätskriterien. Statt „Erstelle eine Query für verdächtige PowerShell“ muss die Anforderung lauten: Erzeuge eine Suchlogik für PowerShell-Prozessstarts auf Windows-Endpunkten, nutze vorhandene Felder aus Sysmon Event ID 1 und EDR Process Events, fokussiere auf EncodedCommand, ungewöhnliche Parent-Prozesse und Netzwerkverbindungen kurz nach Prozessstart, schließe bekannte Admin-Tools aus, liefere Begründung und mögliche Fehlalarme.

Damit wird aus einem Sprachmodell kein Orakel, sondern ein technischer Sparringspartner. Gute Teams lassen sich nicht nur eine Query erzeugen, sondern mehrere Varianten: breit für Hunting, eng für Alerting, erklärend für Analysten und normalisiert für spätere Portierung. Das reduziert den typischen Fehler, eine einzige KI-generierte Abfrage direkt produktiv zu schalten.

Ein weiterer Punkt ist die Übersetzung zwischen Plattformen. Eine Detection-Idee kann in Sigma formuliert, in Splunk umgesetzt und später in ELK oder XDR-Logik übertragen werden. KI kann diese Übersetzungsarbeit beschleunigen, solange die Semantik erhalten bleibt. Genau hier passieren aber viele Fehler: Feldnamen werden falsch gemappt, Zeitfenster unpassend gewählt, Aggregationen unlogisch gesetzt oder Join-Bedingungen erzeugen Datenverlust. Jede Übersetzung muss gegen echte Daten validiert werden.

Beispiel für einen präzisen Arbeitsauftrag an ein Modell:

Zieltechnik:
- Verdächtige Ausführung von rundll32.exe mit ungewöhnlichen Argumenten

Datenquellen:
- Sysmon Event ID 1
- EDR Process Events
- DNS Logs optional

Erwartete Indikatoren:
- rundll32.exe mit URL, JavaScript, DLL-Export oder ungewöhnlichem Parent
- Parent nicht explorer.exe, cmd.exe oder legitimer Installer
- nachgelagerte Netzwerkverbindung innerhalb von 120 Sekunden

Anforderungen:
- erstelle 1 Hunting-Query und 1 Alerting-Query
- benenne bekannte False Positives
- liste Felder auf, die zwingend vorhanden sein müssen
- gib Testhinweise für Purple-Teaming-Ausführung

Das Ergebnis muss anschließend technisch geprüft werden: Existieren die Felder? Ist die Logik performant? Funktioniert sie auf historischen Daten? Trifft sie auf bekannte Testfälle? Erzeugt sie Rauschen bei Softwareverteilung oder Admin-Aktivitäten? Genau hier beginnt echtes Und Detection Engineering. KI beschleunigt Formulierung und Variantenbildung, aber die Qualität entsteht erst durch Validierung, Tuning und Rückkopplung mit realer Telemetrie.

Besonders stark ist dieser Ansatz im Zusammenspiel mit Mit Splunk oder Mit Elk Stack, weil dort Query-Qualität, Feldkonsistenz und Performance sofort sichtbar werden. Wer KI nur für Textproduktion nutzt, verschenkt den eigentlichen Mehrwert: schnellere technische Iteration.

Die meisten Fehler sind keine Modellfehler, sondern Workflow-Fehler. Teams setzen KI zu früh, zu breit oder ohne Qualitätskontrolle ein. Dadurch entstehen falsche Prioritäten, unbrauchbare Detektionen und ein gefährlicher Eindruck von Reife. Besonders problematisch wird das, wenn Management oder Operations annehmen, dass „KI-unterstützt“ automatisch „präziser“ bedeutet.

• Unklare Zielsetzung: Es wird kein konkreter Angriffspfad getestet, sondern nur allgemein nach „verdächtigem Verhalten“ gesucht.
• Fehlende Datenprüfung: Queries werden erzeugt, bevor klar ist, welche Telemetrie tatsächlich vorhanden und vollständig ist.
• Blindes Vertrauen: KI-Ausgaben werden ohne Gegenprüfung in Playbooks, Alerts oder Reports übernommen.
• Zu breite Prompts: Das Modell liefert generische Antworten, die technisch plausibel klingen, aber nicht zur Umgebung passen.
• Keine Baseline: Seltene Aktivitäten werden als verdächtig gewertet, obwohl sie in der Umgebung normal sind.
• Keine Rückkopplung: Ergebnisse aus der Übung fließen nicht in Parser, Sensorik, Use Cases oder Dokumentation zurück.

Ein klassischer Fehler ist die Vermischung von Hunting und Alerting. KI erzeugt eine breite Suchlogik, die für explorative Analysen gut geeignet ist. Diese Logik wird dann unverändert als produktiver Alert verwendet. Das Ergebnis sind Fehlalarme, Analystenmüdigkeit und sinkendes Vertrauen in die Detection. Ein anderes Muster ist die Überschätzung von Zusammenfassungen. Wenn ein Modell einen Vorfall oder eine Übung elegant zusammenfasst, wirkt das professionell. Wenn aber Zeitachsen, Hostbezüge oder technische Kausalitäten falsch sind, wird aus einer guten Formulierung eine schlechte Entscheidungsgrundlage.

Auch auf der Angriffsseite gibt es typische Probleme. KI-generierte Testschritte sind oft syntaktisch korrekt, aber operativ unsauber. Sie berücksichtigen keine Egress-Filter, keine Endpoint Controls, keine lokalen Besonderheiten und keine Sicherheitsmechanismen der Zielumgebung. Wer solche Vorschläge ungeprüft nutzt, testet nicht die Erkennung, sondern nur die Robustheit gegen schlechte Vorbereitung. Gerade bei Werkzeugen wie Mit Metasploit, Mit Nmap oder Mit Burp Suite muss klar sein, dass KI keine operative Erfahrung ersetzt.

Ein weiterer teurer Fehler ist fehlende Dokumentation der Modellnutzung. Wenn später unklar ist, welcher Prompt zu welcher Query, welchem Finding oder welcher Maßnahme geführt hat, fehlt die Nachvollziehbarkeit. Das erschwert Review, Reproduktion und Lessons Learned. Reife Teams versionieren deshalb nicht nur Detection-Regeln, sondern auch Prompts, Eingabedaten, Modellversionen und Validierungsergebnisse. Wer typische Schwächen systematisch vermeiden will, sollte ergänzend Typische Fehler Beim Purple Teaming und Fehler mitdenken.

KI bringt nur dann Stabilität in Purple Teaming, wenn Rollen und Freigaben sauber definiert sind. Ohne klare Zuständigkeiten entstehen Schattenentscheidungen: Das Red Team nutzt KI für Angriffsskripte, das Blue Team für Queries, das Engineering für Parser-Anpassungen, aber niemand prüft die Übergänge. Genau dort entstehen operative Risiken. Ein belastbarer Workflow trennt deshalb Entwurf, Review, Test und produktive Übernahme.

Das Red Team darf KI nutzen, um Testfälle zu strukturieren, Befehlsvarianten zu vergleichen oder Artefakte vorab zu antizipieren. Die Freigabe für tatsächliche Ausführung erfolgt aber nur nach Scope-Prüfung, Sicherheitsbewertung und Abstimmung mit dem Blue Team. Das Blue Team darf KI für Query-Entwürfe, Triage-Hinweise und Korrelationen nutzen. Die Freigabe für produktive Alerts oder Response-Aktionen erfolgt jedoch erst nach Validierung auf historischen und aktuellen Daten. Das Engineering darf KI für Parser- oder Pipeline-Ideen nutzen, aber Änderungen an produktiven Datenpfaden müssen denselben Change-Prozess durchlaufen wie jede andere Plattformänderung.

Ein sauberer Workflow enthält immer einen Review-Punkt mit klarer Frage: Ist das Ergebnis technisch korrekt, operativ sinnvoll und für die Umgebung geeignet? Diese Frage kann kein Modell beantworten, weil sie Kontext, Risikoakzeptanz und Betriebswissen voraussetzt. Deshalb ist Collaboration wichtiger als Tooltiefe. KI beschleunigt Kommunikation, ersetzt sie aber nicht.

In der Praxis bewährt sich ein Vier-Stufen-Modell. Stufe eins ist der KI-Entwurf. Stufe zwei ist das technische Review durch die zuständige Fachrolle. Stufe drei ist die Validierung im Test- oder Purple-Teaming-Fenster. Stufe vier ist die kontrollierte Übernahme in Betrieb, Dokumentation oder Playbooks. Jede Stufe hinterlässt Artefakte: Prompt, Ergebnis, Reviewer, Testdaten, Entscheidung, offene Risiken.

Minimaler Freigabe-Workflow:

1. KI-Entwurf erzeugen
2. Datenquellen und Feldverfügbarkeit prüfen
3. Fachreview durch Red/Blue/Engineering
4. Test gegen bekannte Positiv- und Negativfälle
5. Dokumentation von Annahmen und Grenzen
6. Erst danach produktive Nutzung oder formale Empfehlung

Dieser Ablauf wirkt aufwendig, spart aber Zeit. Ohne ihn werden Fehler erst im Betrieb sichtbar: Alerts fluten das SOC, Parser brechen Dashboards, Testfälle erzeugen unerwartete Seiteneffekte oder Reports enthalten falsche Kausalitäten. Wer Purple Teaming als wiederholbaren Verbesserungsprozess versteht, braucht deshalb nicht nur gute Technik, sondern einen stabilen Playbook-Ansatz und belastbare Dokumentation.

Ein realistisches Beispiel zeigt besser als jede Theorie, wo KI hilft und wo nicht. Ausgangslage ist eine Windows-Domäne mit EDR, SIEM und zentralem Logging. Das Team will einen Angriffspfad testen, der mit Phishing-bedingtem Initial Access beginnt, über PowerShell und Credential Access weitergeht und in Lateral Movement endet. Das Ziel ist nicht, einen vollständigen Angriff zu fahren, sondern die Sichtbarkeit und Reaktionsfähigkeit an mehreren Punkten zu prüfen.

In der Vorbereitung wird ein Incident-Bericht als Input genutzt. KI zerlegt den Bericht in Teiltechniken, schlägt erwartete Artefakte vor und erstellt eine erste Liste potenzieller Datenquellen. Das Team prüft diese Liste manuell und ergänzt lokale Besonderheiten: Sysmon ist nur auf kritischen Servern aktiv, EDR liefert auf Clients gute Prozessdaten, DNS-Logs sind vollständig, PowerShell Script Block Logging ist nur teilweise aktiviert. Schon hier zeigt sich der erste Mehrwert: Die KI hat die Struktur geliefert, aber die Umgebungskorrektur kam aus dem Team.

Während der Ausführung wird zunächst ein harmloser Testfall für PowerShell gestartet. Die KI-generierte Hunting-Query findet die Aktivität im EDR, aber nicht im SIEM. Die Analyse zeigt, dass das SIEM-Feld für CommandLine anders benannt ist als im Query-Entwurf. Nach Anpassung trifft die Suche. Anschließend wird Credential Access simuliert. Erwartet wurde ein Alert, tatsächlich bleibt das SIEM still. Die KI schlägt mehrere Ursachen vor: fehlende Event-Quelle, zu enge Filter, Parser-Problem, falsches Zeitfenster. Das Team prüft systematisch und stellt fest, dass die Detection nur auf Server-OU angewendet wurde, der Test aber auf einem Client lief. Das ist kein KI-Fehler, sondern ein Scope-Fehler in der Regel.

Im nächsten Schritt wird Lateral Movement über administrative Werkzeuge simuliert. Die KI hilft dabei, Parent-Child-Muster und Netzwerkbezüge in eine neue Query zu überführen. Diese Query ist als Hunting-Logik brauchbar, erzeugt aber in der Alerting-Variante zu viele Treffer, weil Softwareverteilung ähnliche Muster produziert. Erst nach Einbau von Asset-Kontext, Wartungsfenstern und bekannten Service-Konten sinkt das Rauschen auf ein akzeptables Maß.

Die Auswertung zeigt drei konkrete Verbesserungen: Erstens müssen Feldmappings zwischen EDR und SIEM vereinheitlicht werden. Zweitens braucht die Credential-Access-Detection einen klaren Scope über Client- und Serverklassen. Drittens muss die Lateral-Movement-Logik zwischen Admin-Betrieb und verdächtigem Verhalten unterscheiden. KI hat in diesem Beispiel nicht „die Detection gebaut“, sondern Hypothesen, Varianten und Dokumentation beschleunigt. Die eigentliche Qualität entstand durch Testen, Gegenprüfen und Tuning.

Solche Übungen lassen sich gut mit Szenarien, Use Cases und Und Threat Detection verbinden. Der operative Gewinn entsteht nicht durch spektakuläre Angriffe, sondern durch präzise Verbesserungen an Sichtbarkeit und Reaktion.

Ohne Messbarkeit bleibt KI im Purple Teaming ein Bauchgefühl. Reife Teams definieren deshalb vorab, welche Verbesserungen erwartet werden. Das können technische Kennzahlen sein, aber auch Prozessmetriken. Beispiele sind Zeit bis zur ersten brauchbaren Query, Anzahl validierter Detection-Varianten pro Übung, Reduktion von False Positives nach Tuning, Anteil reproduzierbarer Findings, Zeit bis zur Dokumentation, Abdeckung definierter ATT&CK-Techniken oder Zahl geschlossener Detection Gaps pro Iteration.

Wichtig ist die Unterscheidung zwischen Aktivität und Wirkung. Mehr Queries bedeuten nicht automatisch bessere Detection. Mehr Zusammenfassungen bedeuten nicht automatisch bessere Entscheidungen. Mehr Automatisierung bedeutet nicht automatisch weniger Risiko. Wirkung zeigt sich erst dann, wenn die Erkennung belastbarer, die Analyse schneller oder die Zusammenarbeit klarer wird. Genau deshalb müssen KI-gestützte Ergebnisse gegen Baselines gemessen werden.

• Qualität der Detection: Precision, Recall im Testkontext, Fehlalarmrate, Stabilität über verschiedene Hosts und Zeiträume.
• Qualität des Prozesses: Review-Aufwand, Reproduzierbarkeit, Dokumentationsgrad, Zeit bis zur Freigabe.
• Qualität der Zusammenarbeit: weniger Missverständnisse zwischen Red und Blue, klarere Übergaben, schnellere Priorisierung.

Ein häufiger Irrtum ist die Fokussierung auf Modellmetriken statt auf Sicherheitsmetriken. Für Purple Teaming zählt nicht, wie elegant ein Modell formuliert, sondern ob die resultierende Detection einen echten Testfall erkennt, ob Analysten sie verstehen und ob sie im Betrieb tragfähig ist. Deshalb sollten Metriken immer an operative Fragen gekoppelt sein: Wurde die Technik erkannt? Wurde sie korrekt eingeordnet? War die Reaktion angemessen? Konnte die Regel ohne unvertretbares Rauschen produktiv genutzt werden?

Besonders hilfreich ist eine Vorher-Nachher-Betrachtung. Vor der KI-Nutzung braucht ein Team vielleicht zwei Stunden, um aus einem Incident-Bericht drei testbare Detection-Hypothesen abzuleiten. Mit KI sinkt diese Zeit auf dreißig Minuten. Das ist nur dann ein Erfolg, wenn die Hypothesen anschließend auch technisch tragfähig sind. Wenn dagegen die Review-Zeit explodiert, weil die Hälfte der Vorschläge unbrauchbar ist, wurde nur Arbeit verlagert.

Für belastbare Steuerung lohnt sich die Verbindung zu Metriken, Erfolg Messen und Reporting. KI sollte nicht nach Eindruck bewertet werden, sondern nach nachweisbarer Verbesserung im Sicherheitsprozess.

KI im Purple Teaming hat klare Grenzen. Die größte technische Grenze ist fehlender Kontext. Modelle kennen die lokale Umgebung nicht zuverlässig: keine impliziten Admin-Prozesse, keine historischen Sonderfälle, keine politischen Randbedingungen, keine stillschweigenden Betriebsregeln. Die größte operative Grenze ist Verantwortung. Ein Modell trägt keine Verantwortung für Fehlalarme, Produktionsstörungen oder riskante Gegenmaßnahmen. Deshalb müssen Einsatzregeln strikt sein.

Niemals ungeprüft automatisiert werden dürfen produktive Block-Entscheidungen, Identitätsmaßnahmen, Host-Isolation, Firewall-Änderungen, Parser-Rollouts, Regelaktivierungen mit hohem Impact und Angriffsschritte mit potenziell destruktiven Nebenwirkungen. Auch scheinbar harmlose Automatisierung kann gefährlich sein. Eine falsch übersetzte Query in einem SIEM kann Ressourcen binden oder Dashboards unbrauchbar machen. Eine unpräzise Zusammenfassung kann Management-Entscheidungen verzerren. Ein KI-generierter Testschritt kann auf dem falschen System ausgeführt werden.

Ein weiteres Risiko ist Datenabfluss. Wer Logdaten, Hostnamen, Benutzerkennungen, interne Pfade oder Incident-Details in externe Modelle einspeist, muss Datenschutz, Vertraulichkeit und Vertragslage sauber geklärt haben. In sensiblen Umgebungen sind lokale oder streng kontrollierte Modelle oft die einzige vertretbare Option. Selbst dann bleibt das Prinzip der Datensparsamkeit wichtig: Nur die Informationen verwenden, die für die Aufgabe wirklich nötig sind.

Auch Halluzinationen sind im Security-Kontext kein akademisches Problem, sondern ein Betriebsrisiko. Ein Modell kann Event-IDs erfinden, Feldnamen verwechseln, Toolverhalten falsch darstellen oder ATT&CK-Techniken ungenau zuordnen. Solche Fehler fallen oft erst spät auf, weil sie sprachlich überzeugend formuliert sind. Deshalb gilt: Jede technische Aussage muss gegen Primärquellen, echte Telemetrie oder reproduzierbare Tests geprüft werden.

Ein sicherer Einsatzrahmen besteht aus wenigen harten Regeln: keine produktive Übernahme ohne Review, keine sensiblen Daten ohne Freigabe, keine automatischen Gegenmaßnahmen ohne menschliche Entscheidung, keine Bewertung ohne Datenprüfung, keine Dokumentation ohne Quellenbezug. Wer diese Regeln ignoriert, erhöht nicht die Reife, sondern nur die Geschwindigkeit, mit der Fehler in den Betrieb gelangen.

Gerade in regulierten oder kritischen Umgebungen sollte der Einsatz zusätzlich mit Im Unternehmen, Kritis und Best Practices abgestimmt werden. KI ist dort nur dann sinnvoll, wenn Governance und technische Kontrolle zusammenpassen.

Ein belastbares Betriebsmodell beginnt klein und kontrolliert. Statt KI sofort breit in Übungen, SOC, Detection Engineering und Reporting auszurollen, sollte mit wenigen klaren Anwendungsfällen gestartet werden. Geeignet sind Aufgaben mit hohem manuellen Aufwand und geringem unmittelbarem Produktionsrisiko: Strukturierung von Szenarien, Entwurf von Hunting-Queries, Konsolidierung von Findings, Ableitung von Testfällen aus Threat-Intel und Unterstützung bei der Nachdokumentation.

Danach folgt die Standardisierung. Für wiederkehrende Aufgaben werden feste Eingabeformate definiert: Welche Datenquellen werden genannt, welche Feldnamen sind relevant, welche Qualitätskriterien gelten, welche Ausschlüsse müssen berücksichtigt werden? So entsteht Konsistenz. Ohne Standardisierung hängt die Qualität zu stark von einzelnen Analysten und deren Prompt-Stil ab. Reife Teams bauen dafür Bibliotheken aus Vorlagen, Beispielprompts, validierten Query-Mustern und Review-Kriterien auf.

Der nächste Schritt ist die Integration in bestehende Arbeitsweisen. KI darf kein Parallelprozess sein. Sie muss in Ticketing, Detection-Backlog, Change-Prozess, Reporting und Lessons Learned eingebettet werden. Jede KI-Ausgabe braucht einen Platz im normalen Sicherheitsbetrieb: als Entwurf, als Review-Artefakt, als Testobjekt oder als dokumentierte Empfehlung. Nur so bleibt nachvollziehbar, was übernommen, verworfen oder angepasst wurde.

Technisch lohnt sich eine Trennung zwischen Assistenz und Automatisierung. Assistenz bedeutet, dass KI Vorschläge macht. Automatisierung bedeutet, dass Vorschläge ohne weitere Prüfung Aktionen auslösen. Für Purple Teaming ist Assistenz fast immer der richtige Standard. Automatisierung ist nur in eng begrenzten, risikoarmen Teilaufgaben sinnvoll, etwa bei der Formatierung von Findings, der Zuordnung zu internen Kategorien oder der Vorbefüllung von Berichtsvorlagen.

Langfristig entsteht Reife durch Wiederholung. Jede Übung verbessert nicht nur Detektionen, sondern auch die KI-Nutzung selbst. Prompts werden präziser, Review-Kriterien schärfer, Datenquellen besser verstanden, Grenzen klarer gezogen. Genau daraus entsteht ein belastbarer Lernzyklus. Wer diesen Zyklus systematisch aufbauen will, sollte ihn mit Lifecycle, Strategie und Integration verzahnen.

Am Ende zählt nicht, ob KI eingesetzt wurde, sondern ob die Sicherheitsfähigkeit messbar gestiegen ist: bessere Sichtbarkeit, präzisere Detection, schnellere Abstimmung, sauberere Dokumentation und weniger Reibung zwischen Angriffssimulation und Verteidigung. Genau dort liegt der reale Wert von KI im Purple Teaming.