Und Siem: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Ein SIEM ist im Purple Teaming kein Selbstzweck und auch kein bloßer Speicherort für Logs. Der eigentliche Wert entsteht erst dann, wenn simulierte Angriffsaktivitäten reproduzierbar in verwertbare Signale übersetzt werden. Genau an dieser Stelle scheitern viele Umgebungen: Es gibt Daten, Dashboards und Regeln, aber keine belastbare Aussage darüber, welche Angriffsschritte tatsächlich erkannt werden, welche nur zufällig sichtbar sind und welche komplett untergehen.

Purple Teaming mit SIEM bedeutet, offensive Aktionen gezielt gegen die vorhandene Telemetrie und die bestehenden Erkennungsregeln zu testen. Das Ziel ist nicht, möglichst viele Events zu erzeugen, sondern eine klare Verbindung zwischen Technik, Datenquelle, Parsing, Korrelation, Alarmierung und Analysten-Workflow herzustellen. Ein Angriffsschritt gilt erst dann als sauber abgedeckt, wenn nachvollziehbar ist, welche Rohdaten entstehen, wie sie normalisiert werden, welche Felder für die Erkennung relevant sind, welche Regel greift und wie das Ergebnis im SOC bearbeitet wird. Wer diesen End-to-End-Pfad nicht prüft, testet nur Teilstücke.

Im Unterschied zu reinem Und Pentesting liegt der Fokus nicht auf der Frage, ob ein System kompromittierbar ist, sondern ob die Verteidigung die relevanten Spuren erkennt und korrekt bewertet. Das verbindet Purple Teaming eng mit Und Detection Engineering und mit der operativen Realität im Und Soc. Ein SIEM ist dabei die zentrale Schicht, in der sich Host-, Netzwerk-, Identitäts- und Cloud-Telemetrie treffen. Wenn diese Schicht schlecht modelliert ist, helfen auch gute EDR- oder XDR-Sensoren nur begrenzt.

Ein häufiger Denkfehler besteht darin, SIEM-Erkennung mit bloßer Event-Präsenz zu verwechseln. Dass ein Prozessstart, ein Login oder eine PowerShell-Ausführung im SIEM auftaucht, bedeutet noch nicht, dass daraus eine belastbare Detection gebaut werden kann. Oft fehlen Kontextfelder, Parent-Child-Beziehungen, User-Rollen, Asset-Kritikalität oder Zeitbezüge. Purple Teaming deckt genau diese Lücken auf, weil ein Angriff nicht abstrakt, sondern schrittweise gegen reale Datenpfade validiert wird.

Saubere Arbeit mit SIEM im Purple Teaming beginnt deshalb immer mit einer präzisen Fragestellung: Welcher Angriffspfad wird simuliert, welche Taktik aus Und Mitre Attack steht im Fokus, welche Datenquellen sollen die Aktivität abbilden, welche Regeln oder Hypothesen werden geprüft und wie wird Erfolg gemessen? Ohne diese Struktur entsteht nur Lograuschen. Mit dieser Struktur wird aus einem Test ein verwertbarer Verbesserungszyklus.

Die Qualität eines Purple-Teaming-Ergebnisses steht und fällt mit der Qualität der Logquellen. Viele SIEM-Installationen sammeln große Mengen an Daten, aber nur ein kleiner Teil davon ist für Detection wirklich brauchbar. Für offensive Validierung zählt nicht die Menge, sondern die Präzision. Eine unvollständige Windows-Audit-Policy, fehlende Sysmon-Konfiguration, unstrukturierte Firewall-Logs oder Identity-Events ohne Session-Kontext führen dazu, dass Angriffsschritte nur fragmentarisch sichtbar werden.

In der Praxis müssen Logquellen nach ihrer forensischen und detektiven Aussagekraft bewertet werden. Windows Security Logs liefern andere Informationen als Sysmon, EDR-Telemetrie andere als klassische AV-Logs, Proxy-Daten andere als DNS-Resolver-Logs. Ein SIEM kann nur dann starke Korrelationen erzeugen, wenn diese Quellen zeitlich, semantisch und feldseitig zusammenpassen. Genau deshalb ist Und Log Analyse kein Nebenthema, sondern Kernbestandteil jeder Purple-Teaming-Übung mit SIEM.

Besonders relevant sind Quellen, die Prozessketten, Authentifizierungen, Netzwerkverbindungen, Dateioperationen, Registry-Änderungen, Script-Ausführung und Identitätsereignisse abbilden. Wer nur Perimeter-Logs und Domain-Controller-Events einspeist, kann viele moderne Angriffsschritte nicht sauber nachvollziehen. Umgekehrt erzeugen breit aktivierte Quellen ohne Filter oft so viel Rauschen, dass echte Signale in der Masse untergehen. Purple Teaming hilft, diese Balance datenbasiert zu finden.

• Host-Telemetrie: Prozessstarts, Parent-Child-Beziehungen, Commandline, Module Loads, Registry, Dateioperationen, Services, Scheduled Tasks
• Identity-Telemetrie: Logons, Kerberos-Events, MFA-Ereignisse, Privilegänderungen, Gruppenmitgliedschaften, Cloud-Identity-Aktivitäten
• Netzwerk- und Infrastruktur-Telemetrie: DNS, Proxy, Firewall, VPN, Webserver, E-Mail-Gateway, Load Balancer, Cloud Control Plane

Ein weiterer kritischer Punkt ist die Feldnormalisierung. Wenn dieselbe Benutzeridentität in einer Quelle als samAccountName, in einer anderen als UPN und in einer dritten als E-Mail-Adresse auftaucht, scheitern Korrelationen oft an banalen Mapping-Fehlern. Dasselbe gilt für Hostnamen, IP-Adressen hinter NAT, Zeitzonen oder Event-Timestamps. Purple Teaming sollte deshalb nie nur Regeln testen, sondern immer auch die Datenpipeline selbst: Kommen Events vollständig an, werden sie korrekt geparst, sind die Felder konsistent und lassen sich Entitäten zuverlässig zusammenführen?

In reifen Umgebungen wird jede relevante Detection an eine dokumentierte Mindesttelemetrie gebunden. Fehlt diese Telemetrie, ist die Detection formal nicht einsatzfähig. Das verhindert die verbreitete Illusion, eine Regel sei produktiv, obwohl ihre Datenbasis nur in Teilsegmenten vorhanden ist.

Ein SIEM-Use-Case ist nur dann belastbar, wenn er aus einem realistischen Angriffsschritt abgeleitet wurde. Viele Regeln entstehen jedoch aus generischen Listen wie „PowerShell erkannt“, „Admin Login außerhalb der Zeiten“ oder „Viele fehlgeschlagene Logins“. Solche Regeln können nützlich sein, bilden aber selten einen konkreten adversarialen Ablauf ab. Purple Teaming zwingt dazu, Detection-Hypothesen aus tatsächlichen Techniken abzuleiten.

Der saubere Weg beginnt mit einer Technik oder Teiltechnik, etwa Credential Dumping, Remote Service Creation, Kerberoasting, WMI-Ausführung oder Missbrauch legitimer Admin-Tools. Danach wird festgelegt, welche beobachtbaren Artefakte diese Technik in der eigenen Umgebung erzeugt. Erst dann wird entschieden, ob eine einzelne Regel genügt oder ob mehrere Signale korreliert werden müssen. Dieser Ansatz ist deutlich robuster als das nachträgliche Suchen nach auffälligen Events.

Ein Beispiel: Für eine Technik wie „PowerShell Download Cradle“ reicht es nicht, nur nach powershell.exe zu suchen. In vielen Umgebungen ist PowerShell legitim. Relevant werden erst Kombinationen wie verdächtige Commandline-Muster, Netzwerkverbindungen zu seltenen Zielen, nachgelagerte Prozessstarts, Script Block Logging, AMSI-Hinweise oder Dateischreibvorgänge in temporäre Pfade. Ein guter SIEM-Use-Case beschreibt deshalb nicht nur den Trigger, sondern auch den Kontext, der False Positives reduziert und die Analystenentscheidung beschleunigt.

Die Verbindung zu Mitre Attack Mapping ist dabei zentral. ATT&CK liefert keine fertigen Regeln, aber eine gemeinsame Sprache für Techniken, Datenquellen und Testfälle. Im Purple Teaming wird daraus ein praktischer Ablauf: Technik auswählen, Emulation definieren, erwartete Telemetrie festlegen, SIEM-Regel prüfen, Ergebnis bewerten, Lücken schließen, erneut testen. Genau daraus entstehen belastbare Use Cases, die nicht auf Annahmen, sondern auf validierten Beobachtungen beruhen.

Wichtig ist außerdem die Trennung zwischen Erkennung einer Einzelaktivität und Erkennung eines Angriffsmusters. Ein einzelner Event kann verdächtig sein, aber erst die Sequenz macht den Fall priorisierbar. Ein Login auf einen Jump Host, gefolgt von einem ungewöhnlichen Service-Create, anschließendem LSASS-Zugriff und ausgehender Verbindung zu einem seltenen Ziel hat eine andere Aussagekraft als jedes dieser Signale für sich allein. SIEM-Use-Cases sollten deshalb so modelliert werden, dass sie sowohl atomare Erkennungen als auch Kettenbildungen unterstützen.

Ein belastbarer Purple-Teaming-Workflow mit SIEM ist kein einmaliger Test, sondern ein kontrollierter Zyklus. Die Reihenfolge ist entscheidend. Wer zuerst emuliert und erst danach überlegt, welche Logs relevant wären, produziert meist unklare Ergebnisse. Besser ist ein Ablauf, der Detection-Design und Emulation eng verzahnt. In der Praxis hat sich ein Vorgehen bewährt, das mit Scope, Hypothese und Mindesttelemetrie startet und erst danach in die technische Ausführung geht.

Vor dem Test muss klar sein, welche Systeme, Benutzer, Sensoren und Logpfade betroffen sind. Ebenso wichtig ist die Definition des erwarteten Ergebnisses. Soll eine bestehende Regel auslösen? Soll eine neue Korrelation validiert werden? Soll geprüft werden, ob ein Analyst den Fall mit den vorhandenen Feldern überhaupt triagieren kann? Diese Fragen entscheiden darüber, ob ein Test erfolgreich war oder nur Aktivität erzeugt hat.

Die Emulation selbst sollte so nah wie möglich an realen Angreifertechniken liegen, aber kontrolliert und reproduzierbar bleiben. Das bedeutet: bekannte Testkonten, dokumentierte Hosts, definierte Zeitfenster, eindeutige Kennzeichnung der Aktionen und möglichst identische Wiederholbarkeit. Nur so lassen sich Änderungen an Regeln oder Parsern später sauber vergleichen. In vielen Teams wird dieser Ablauf im Workflow oder im Playbook fest verankert.

Nach der Emulation beginnt die eigentliche Arbeit. Jetzt wird geprüft, ob die Rohdaten vollständig angekommen sind, ob die Normalisierung stimmt, ob die Regel ausgelöst hat, wie schnell der Alarm sichtbar wurde und ob die Fallinformationen für eine Triage ausreichen. Wenn eine Detection nicht greift, muss die Ursache präzise eingegrenzt werden: fehlende Datenquelle, fehlerhaftes Parsing, falsche Feldnamen, zu enge Schwellenwerte, falsche Zeitfenster oder ungeeignete Logik. Ohne diese Ursachenanalyse bleibt Tuning blind.

• Planung: Technik, Scope, Testkonten, Zielsysteme, erwartete Telemetrie, Erfolgskriterien
• Ausführung: kontrollierte Emulation, Zeitmarken, Dokumentation der Befehle und beobachteten Effekte
• Validierung: Rohdaten prüfen, Parser kontrollieren, Regelverhalten bewerten, Analystensicht nachvollziehen, Tuning ableiten

Ein häufiger Fehler ist, Tuning nur auf False Positives zu reduzieren. Genauso wichtig sind False Negatives, unvollständige Kontexte und Alerts ohne Handlungswert. Eine Detection, die zwar auslöst, aber keine entscheidenden Felder wie User, Host, Parent Process oder Zieladresse enthält, ist operativ schwach. Purple Teaming bewertet deshalb nicht nur, ob ein Alert existiert, sondern ob er im Betrieb verwertbar ist.

Die meisten Detection-Probleme im SIEM sind keine exotischen Spezialfälle, sondern wiederkehrende Grundfehler. Einer der häufigsten ist die Annahme, dass ingestierte Daten automatisch nutzbar sind. Tatsächlich sind viele Events unvollständig geparst, falsch normalisiert oder ohne die Felder gespeichert, die für Korrelationen notwendig wären. Das fällt oft erst im Purple Teaming auf, wenn eine eigentlich simple Technik nicht erkannt wird, obwohl die Rohdaten vorhanden sind.

Ein weiterer Klassiker ist die Überbewertung vendorseitiger Standardregeln. Solche Regeln können einen guten Startpunkt liefern, aber sie kennen weder die lokalen Admin-Workflows noch die Eigenheiten der Infrastruktur. Ohne Anpassung erzeugen sie entweder Alarmfluten oder sie bleiben so konservativ, dass relevante Aktivitäten nicht erfasst werden. Besonders problematisch wird das bei hybriden Umgebungen, in denen On-Prem-, Cloud- und Identitätsdaten zusammengeführt werden müssen.

Auch Zeitbezüge werden oft unterschätzt. Wenn Host-Logs in UTC, Firewall-Logs in lokaler Zeit und Cloud-Events mit Verzögerung ankommen, zerfallen Ereignisketten. Eine Korrelation, die auf fünf Minuten ausgelegt ist, kann dadurch ins Leere laufen. Purple Teaming deckt solche Probleme zuverlässig auf, weil die Testzeitpunkte bekannt sind und mit den SIEM-Daten abgeglichen werden können.

Ebenso kritisch ist die fehlende Trennung zwischen administrativ legitimem Verhalten und adversarialem Missbrauch. Viele Techniken nutzen Standardwerkzeuge: PowerShell, PsExec, WMI, RDP, Scheduled Tasks, Service Control Manager. Wer nur nach dem Tool sucht, erzeugt Rauschen. Wer jedoch Kontext wie ungewöhnliche Quelle, seltenes Ziel, atypische Uhrzeit, neue Benutzerrolle, ungewöhnliche Prozesskette oder Kombination mit weiteren Signalen einbezieht, erhöht die Präzision deutlich. Genau hier zeigt sich die Nähe zu Und Alerting und zu Und Threat Detection.

Ein besonders teurer Fehler ist das fehlende Feedback aus dem operativen Betrieb. Wenn Analysten regelmäßig Alerts schließen, weil Kontext fehlt oder die Regel unklar formuliert ist, muss das in die Detection zurückfließen. Ohne diese Rückkopplung bleibt das SIEM ein Regelcontainer statt eines lernenden Systems. Purple Teaming liefert dafür einen strukturierten Rahmen, weil jede getestete Detection nicht nur technisch, sondern auch operativ bewertet wird.

Schließlich scheitern viele Teams an unklarer Verantwortlichkeit. Wer pflegt Parser? Wer verantwortet Datenqualität? Wer entscheidet über Tuning? Wer dokumentiert Detection Coverage? Wenn diese Rollen nicht geklärt sind, bleiben Lücken dauerhaft offen. Ein SIEM wird nur dann stark, wenn Datenengineering, Detection Engineering und SOC-Betrieb sauber zusammenspielen.

Ein realistisches Purple-Teaming-Szenario für das SIEM kombiniert mehrere Phasen: initiale Ausführung auf einem Client, Credential Access, Privilegverwendung und laterale Bewegung. Der Mehrwert entsteht nicht durch die einzelne Aktion, sondern durch die Frage, ob das SIEM die Kette als zusammenhängendes Risiko sichtbar machen kann.

Angenommen, auf einem Testsystem wird eine administrative PowerShell mit auffälliger Commandline gestartet. Kurz danach erfolgt ein Zugriff auf sensible Prozessspeicherbereiche, anschließend ein Netzwerkzugriff auf einen zweiten Host und dort die Erstellung eines Remote Service. In einer reifen Umgebung sollten mindestens vier Ebenen sichtbar werden: Host-Telemetrie des Ursprungssystems, Identitätskontext des verwendeten Kontos, Netzwerkbezug zwischen Quelle und Ziel sowie Host-Telemetrie des Zielsystems.

Die erste Detection könnte auf verdächtige Prozessparameter oder auf den Zugriff auf LSASS-nahe Artefakte zielen. Die zweite Detection könnte eine ungewöhnliche Remote-Ausführung erkennen, etwa Service Creation oder WMI. Die dritte Detection korreliert beide Signale über Benutzer, Quelle und Zeitfenster. Genau diese Kettenbildung trennt ein brauchbares SIEM von einer bloßen Event-Sammlung.

Ein mögliches vereinfachtes Suchmuster in einer SIEM-Sprache könnte so aussehen:

index=endpoint
(
  process_name="powershell.exe" AND command_line="*EncodedCommand*"
)
OR
(
  event_id=7045 OR service_creation=true
)
| stats values(host) values(user) values(parent_process) values(command_line) min(_time) as first_seen max(_time) as last_seen by src_ip dest_ip
| where last_seen-first_seen < 900

Dieses Beispiel ist bewusst generisch. In der Praxis muss die Logik an Datenmodell, Feldnamen und Umgebung angepasst werden. Entscheidend ist die Denkweise: Nicht nur einzelne Events suchen, sondern eine Hypothese über den Angriffspfad formulieren und dann prüfen, ob die Daten diese Hypothese tragen. Wenn etwa service_creation zwar vorhanden ist, aber src_ip fehlt, wird die Korrelation schwach. Wenn command_line abgeschnitten wird, verliert die erste Detection an Aussagekraft. Solche Defizite werden im Purple Teaming sichtbar, bevor ein echter Vorfall sie ausnutzt.

In Umgebungen mit Und Edr oder Und Xdr sollte zusätzlich geprüft werden, welche Informationen bereits dort vorliegen und wie sie ins SIEM übernommen werden. Nicht jede Detection gehört ins SIEM, aber jede kritische Detection sollte dort zumindest korrelierbar und reportbar sein, wenn das SIEM die zentrale Betriebsplattform des SOC ist.

Die Qualität eines SIEM steht nicht nur auf den Datenquellen, sondern auf der Fähigkeit, aus Rohereignissen belastbare Entscheidungen abzuleiten. Eine gute Regel ist präzise genug, um operative Relevanz zu erzeugen, aber flexibel genug, um Varianten derselben Technik zu erfassen. Das gelingt selten mit simplen Einzelindikatoren. Starke Detection entsteht meist aus einer Kombination von Merkmalen, Kontext und zeitlicher Beziehung.

Regelentwicklung beginnt mit der Frage, welche Beobachtung wirklich adversarial ist. Ein Prozessstart allein ist selten ausreichend. Ein Prozessstart mit ungewöhnlicher Parent-Child-Kette, verdächtiger Commandline, Ausführung aus atypischem Pfad, nachgelagerter Netzwerkverbindung und privilegiertem Benutzerkontext ist deutlich aussagekräftiger. Korrelation bedeutet dabei nicht zwangsläufig komplexe Graphlogik. Schon einfache Verknüpfungen über Host, User, Zeitfenster und Aktivitätsfolge können die Präzision massiv erhöhen.

Tuning darf nicht nur auf Unterdrückung hinauslaufen. Viele Teams reagieren auf Alarmfluten mit Whitelists, bis von der Detection kaum noch etwas übrig bleibt. Besser ist ein strukturiertes Vorgehen: erst Rohdaten prüfen, dann legitime Muster identifizieren, anschließend Kontextfelder ergänzen und erst zuletzt gezielt Ausnahmen definieren. Wer zu früh filtert, entfernt oft genau die Signale, die für seltene Angriffe entscheidend sind.

Hilfreich ist die Trennung in drei Ebenen: atomare Regeln für Einzelbeobachtungen, korrelierende Regeln für Sequenzen und priorisierende Logik für Risikoanhebung. So kann eine einzelne verdächtige PowerShell nur mittlere Relevanz haben, in Kombination mit Credential Access und Remote-Ausführung aber automatisch hochgestuft werden. Dieses Modell reduziert Rauschen, ohne Sichtbarkeit zu verlieren.

• Atomare Detection: klar definierte Einzelaktivität mit hoher technischer Präzision
• Korrelation: Verknüpfung mehrerer Signale über Entitäten und Zeitfenster
• Priorisierung: Risikobewertung anhand von Asset-Kritikalität, Benutzerrolle, Seltenheit und Angriffskette

Ein oft übersehener Aspekt ist die Analystenlesbarkeit. Eine Regel kann technisch korrekt sein und trotzdem operativ scheitern, wenn der Alert keine verständliche Begründung liefert. Gute Alerts enthalten die auslösenden Bedingungen, die wichtigsten Kontextfelder, eine kurze Hypothese zur Technik und Hinweise auf die nächsten Prüfschritte. Das verkürzt die Triage erheblich und verbessert die Konsistenz im Schichtbetrieb.

Wer SIEM-Regeln mit Purple Teaming entwickelt, sollte jede Änderung erneut gegen denselben Testfall validieren. Nur so wird sichtbar, ob das Tuning wirklich verbessert oder nur verschoben hat. Reife Teams versionieren ihre Detection-Logik, dokumentieren Testfälle und messen, wie sich Präzision, Abdeckung und Bearbeitbarkeit über mehrere Iterationen verändern.

Ohne Messbarkeit bleibt jede Aussage über Detection-Reife unscharf. Im Purple Teaming mit SIEM reicht es nicht, „Alert wurde ausgelöst“ zu dokumentieren. Entscheidend ist, wie vollständig, wie schnell und wie verwertbar die Erkennung war. Eine Detection kann technisch feuern und trotzdem operativ unzureichend sein, wenn wichtige Felder fehlen, die Priorisierung falsch ist oder der Fall im SOC nicht sauber triagiert werden kann.

Belastbare Bewertungskriterien umfassen mehrere Ebenen. Erstens die Datenverfügbarkeit: Waren alle erwarteten Rohdaten vorhanden? Zweitens die Parser- und Feldqualität: Wurden relevante Attribute korrekt extrahiert? Drittens die Detection-Logik: Hat die Regel die Aktivität erkannt, ohne auf irrelevante Nebeneffekte angewiesen zu sein? Viertens die Alarmqualität: Konnte ein Analyst den Fall mit den gelieferten Informationen einordnen? Fünftens die Reproduzierbarkeit: Lässt sich das Ergebnis mit demselben Testfall erneut bestätigen?

Diese Bewertung sollte in einer strukturierten Dokumentation festgehalten werden, idealerweise mit Technikbezug, Testzeitpunkt, verwendeten Systemen, Befehlen oder Tools, erwarteter Telemetrie, tatsächlicher Telemetrie, Regel-ID, Alert-ID, Analystenfeedback und abgeleiteten Maßnahmen. Solche Artefakte sind nicht nur für die Nachvollziehbarkeit wichtig, sondern auch für spätere Regressionstests. Wenn Parser, Sensoren oder SIEM-Content geändert werden, muss sichtbar bleiben, welche Detection dadurch beeinflusst wird.

Besonders wertvoll ist die Verknüpfung mit Coverage-Metriken. Dabei geht es nicht um kosmetische Prozentzahlen, sondern um belastbare Aussagen wie: Welche ATT&CK-Techniken sind gegen reale Telemetrie validiert? Welche nur theoretisch abgedeckt? Welche erfordern zusätzliche Datenquellen? Welche liefern Alerts, aber keine ausreichende Triage-Basis? Solche Fragen sind deutlich aussagekräftiger als reine Regelanzahl.

In der Praxis lohnt sich die Kopplung an Reporting, Dokumentation und Metriken. Dadurch wird aus einzelnen Tests ein nachvollziehbarer Reifegradprozess. Gute Teams dokumentieren nicht nur Erfolge, sondern auch bewusst offene Lücken, inklusive Begründung, Risiko und geplantem Behebungsweg. Das verhindert die gefährliche Scheinsicherheit, die in vielen SIEM-Projekten entsteht.

Ein einmaliges Purple-Teaming-Projekt verbessert ein SIEM kurzfristig. Dauerhafte Wirkung entsteht erst, wenn die Erkenntnisse in den Regelbetrieb überführt werden. Dafür braucht es ein Betriebsmodell, in dem Detection Engineering, SOC, Plattformbetrieb und offensive Testkompetenz eng verzahnt sind. Ohne diese Verzahnung veralten Regeln, Parser driften auseinander und neue Systeme werden ohne belastbare Detection integriert.

Ein praxistaugliches Modell definiert klare Verantwortlichkeiten. Das Plattformteam verantwortet Datenaufnahme, Parsing, Performance und Stabilität. Detection Engineering verantwortet Use Cases, Regelqualität, Korrelation und Testbarkeit. Das SOC liefert Feedback aus Triage und Incident Handling. Purple Teaming validiert regelmäßig, ob die Annahmen noch stimmen und ob neue Angriffstechniken oder Infrastrukturänderungen die Erkennung beeinflussen. Diese Rollen müssen nicht organisatorisch getrennt sein, aber ihre Aufgaben müssen eindeutig sein.

Wichtig ist außerdem ein fester Takt. Neue oder geänderte Detection sollte nicht ungeprüft produktiv gehen. Besser ist ein Zyklus aus Design, Labortest, kontrollierter Emulation, Produktivvalidierung und Review. Dasselbe gilt für neue Logquellen. Bevor eine Quelle als „angeschlossen“ gilt, muss geprüft werden, ob sie für konkrete Detection-Hypothesen nutzbar ist. Reine Ingestion ohne Validierung erzeugt nur Komplexität.

Auch Change Management spielt eine große Rolle. Betriebssystem-Updates, neue EDR-Versionen, geänderte Audit-Policies, Cloud-Migrationen oder Identity-Federation können bestehende Detection unbemerkt schwächen. Purple Teaming sollte deshalb nicht nur reaktiv nach Vorfällen stattfinden, sondern als regelmäßiger Validierungsmechanismus im Sicherheitsbetrieb verankert sein. Genau dort zeigt sich der Unterschied zwischen punktueller Sichtbarkeit und echter Verteidigungsfähigkeit.

Wer diesen Ansatz konsequent umsetzt, entwickelt das SIEM von einer passiven Sammelplattform zu einem aktiven Prüf- und Steuerungsinstrument. Dann wird sichtbar, welche Erkennungen belastbar sind, welche nur unter Idealbedingungen funktionieren und wo Investitionen in Telemetrie, Regeln oder Prozesse den größten Effekt haben.