Ein Unternehmen investiert sechsstellige Beträge in ein SIEM-System, schreibt Dutzende Erkennungsregeln und richtet Alert-Schwellenwerte ein. Dann passiert ein Einbruch. Später stellt sich heraus: Die Regel, die den Angriff hätte erkennen sollen, war seit Monaten deaktiviert. Ein Logformat hatte sich geändert, die Regel lief ins Leere. Niemand hatte das bemerkt.
Dieser Ablauf ist kein Randfall. Laut einer Untersuchung des Bundesamts für Sicherheit in der Informationstechnik aus dem Lagebericht 2023 haben Angreifer im Schnitt mehr als 23 Tage ungestörten Zugriff auf kompromittierte Netzwerke, bevor sie entdeckt werden. Ein wesentlicher Grund: Detektionsregeln werden einmalig geschrieben und dann nicht mehr systematisch auf ihre Funktionsfähigkeit geprüft.
Was Detection Validation konkret bedeutet
Detection Validation bezeichnet den Prozess, mit dem Sicherheitsteams überprüfen, ob ihre bestehenden Erkennungsregeln unter realen Bedingungen tatsächlich anschlagen. Es geht nicht darum, neue Angriffe zu simulieren, um Lücken zu finden. Es geht darum, bekannte Angriffstechniken gezielt gegen das eigene Monitoring zu spielen und zu prüfen: Gibt es einen Alert? Landet er im richtigen System? Schlägt jemand auf den Alert an?
Der Unterschied zu klassischen Penetrationstests ist entscheidend. Ein Pentest sucht Schwachstellen in der Infrastruktur. Detection Validation sucht Schwachstellen in der Erkennungsfähigkeit. Beide Disziplinen ergänzen sich, adressieren aber unterschiedliche Fragen.
Warum Regeln still verrotten
SIEM-Regeln haben ein strukturelles Problem: Sie werden einmal erstellt, oft anlässlich eines konkreten Incidents oder nach einer Threat-Intelligence-Meldung, und dann in Betrieb genommen. Was danach passiert, hängt weitgehend vom Zufall ab.
Folgende Szenarien lassen Regeln lautlos versagen:
- Log-Quellen ändern ihr Format oder werden auf neue Server migriert. Die Feldnamen im SIEM passen nicht mehr, die Regel matcht nicht mehr.
- Schwellenwerte werden angepasst, um Alert-Fatigue zu reduzieren, ohne zu prüfen, ob damit auch legitime Angriffssignale unterdrückt werden.
- Angreifer ändern ihre Techniken. Eine Regel, die auf Mimikatz in Version 2.1 ausgelegt war, erkennt eine modifizierte Variante nicht mehr.
- Zuständigkeiten wechseln. Der Analyst, der die Regel erstellt hat, ist nicht mehr im Team. Niemand weiß mehr, was sie genau tut.
Das Ergebnis ist ein SIEM, das auf dem Papier vollständig konfiguriert ist, in der Praxis aber signifikante blinde Flecken hat.
Methodik: So läuft eine Validierung ab
Eine strukturierte Detection Validation folgt einem klaren Ablauf. Ausgangspunkt ist ein Regelinventar: Welche Detektionsregeln existieren, gegen welche Angriffstechniken richten sie sich, und wann wurden sie zuletzt verifiziert? Viele Teams haben auf diese Fragen keine belastbare Antwort.
Im zweiten Schritt werden Angriffstechniken aus dem MITRE ATT&CK-Framework ausgewählt, die den für das Unternehmen relevanten Bedrohungsakteuren entsprechen. Ein mittelständischer Maschinenbauer in Deutschland steht vor anderen Risiken als ein Finanzdienstleister. Die Auswahl der Techniken sollte diese Realität abbilden.
Dann folgt die eigentliche Ausführung. Angriffstechniken werden kontrolliert in der Produktionsumgebung oder einer möglichst realistischen Testumgebung ausgeführt. Spezialisierte Dienstleister, die sich auf Detection Validation spezialisiert haben, führen diese Tests mit Werkzeugen durch, die echte Angreiferverhalten imitieren, ohne produktive Systeme zu gefährden. Parallel dazu wird im SIEM beobachtet, ob und welche Alerts generiert werden.
Abschließend werden die Ergebnisse in drei Kategorien eingeteilt: Regelungen, die korrekt ausgelöst haben; Regelungen, die ausgelöst haben, aber mit falschen oder unvollständigen Informationen; und Regelungen, die vollständig versagt haben. Nur die dritte Kategorie wird oft kommuniziert, dabei ist die zweite mindestens genauso relevant.
Typische Befunde aus der Praxis
Wer Detection Validation zum ersten Mal systematisch durchführt, erlebt häufig ähnliche Überraschungen. Eine repräsentative Auswahl aus Erfahrungsberichten von Security-Operations-Teams:
| Befund | Häufigkeit (geschätzt) |
|---|---|
| Regeln matchen nicht, weil Log-Felder umbenannt wurden | sehr häufig |
| Alerts landen in falscher Queue, werden nicht bearbeitet | häufig |
| Schwellenwert zu hoch, Angriff bleibt unter Radar | häufig |
| Regel korrekt, aber keine Eskalation bei Auslösung konfiguriert | gelegentlich |
| Regel funktioniert vollständig korrekt | seltener als erwartet |
Zahlen aus internen Audits verschiedener Branchen deuten darauf hin, dass zwischen 30 und 50 Prozent aller produktiven Detektionsregeln bei einer ersten systematischen Validierung nicht wie erwartet funktionieren. Das ist keine Katastrophe, sondern ein normaler Ausgangszustand. Problematisch wird es erst, wenn dieser Zustand unbekannt bleibt.
Wie oft muss validiert werden?
Eine einmalige Validierung ist besser als keine. Aber sie ist kein dauerhafter Schutz. Die Faustregel in der Praxis lautet: kritische Regeln mindestens quartalsweise, alle anderen Regeln mindestens einmal jährlich. Zusätzlich sollte jede größere Infrastrukturänderung, jeder Wechsel der Log-Management-Plattform und jede bekannte Änderung in der Bedrohungslandschaft einen gezielten Validierungslauf auslösen.
Einige Teams integrieren einfache Validierungsroutinen in ihre CI/CD-Pipelines für Detektionslogik. Wenn eine Regel geändert wird, wird automatisch ein Testsignal erzeugt und geprüft, ob der Alert korrekt auslöst. Dieses Prinzip, bekannt aus der Softwareentwicklung als automatisiertes Testing, überträgt sich gut auf den Detection-Engineering-Bereich.
Was Verantwortliche konkret anstoßen können
Für Sicherheitsverantwortliche, die Detection Validation einführen möchten, empfiehlt sich ein schrittweiser Einstieg. Zunächst lohnt es sich, das eigene Regelinventar zu dokumentieren und nach Kritikalität zu priorisieren. Parallel dazu ist es sinnvoll, sich mit Frameworks wie dem IT-Grundschutz des BSI auseinanderzusetzen, der Anforderungen an die Wirksamkeitsprüfung von Sicherheitsmaßnahmen explizit adressiert.
Der nächste Schritt ist die Auswahl relevanter Angriffstechniken auf Basis des eigenen Bedrohungsmodells. Wer das intern nicht abbilden kann, greift auf externe Expertise zurück. Wichtig dabei: Die Ergebnisse müssen in konkrete Verbesserungsmaßnahmen münden, sonst bleibt Validation eine reine Bestandsaufnahme ohne operativen Mehrwert.
Detection Validation ist kein Projekt, das man einmal abschließt. Es ist ein wiederkehrender Betriebsprozess. Wer ihn etabliert, weiß, was sein Monitoring tatsächlich kann. Und das ist im Ernstfall der entscheidende Unterschied.
