Detection Coverage: Wissen Sie, was Ihr SIEM tatsächlich erkennt?

Die meisten Unternehmen mit SIEM-System gehen davon aus, dass sie Angriffe erkennen. Die wenigsten können sagen, welche. Detection Coverage — die systematische Messung dessen, was ein SIEM tatsächlich erkennt und was nicht — ist eine der am stärksten vernachlässigten Disziplinen in der Cybersicherheit.

Das Problem: Gefühlte Sicherheit statt messbare Erkennung

Ein SIEM sammelt Logs, korreliert Events und generiert Alerts. Aber die entscheidende Frage lautet nicht, ob es Alerts generiert — sondern ob es die richtigen Angriffstechniken erkennt. Ein SIEM mit 500 aktiven Regeln kann trotzdem blind sein für die Techniken, die Angreifer tatsächlich einsetzen.

Der Mandiant M-Trends Report 2025 zeigt: Die durchschnittliche Dwell Time — die Zeit zwischen Erstinfektion und Entdeckung — liegt global bei 10 Tagen. Bei Unternehmen ohne externes Monitoring sind es oft Wochen oder Monate. Das bedeutet: Viele SIEM-Systeme erkennen Angriffe entweder gar nicht oder zu spät, um den Schaden zu begrenzen.

Das Problem ist nicht die Technologie. Das Problem ist, dass niemand systematisch misst, was erkannt wird — und was nicht.

MITRE ATT&CK als Messrahmen

Das MITRE ATT&CK Framework katalogisiert über 200 Angriffstechniken in 14 Taktiken — von Initial Access über Lateral Movement bis Exfiltration. Es bietet damit einen standardisierten Rahmen, um Detection Coverage zu messen: Für jede Technik kann dokumentiert werden, ob eine Erkennungsregel existiert, ob sie getestet wurde und ob sie in der Praxis funktioniert.

Die Realität in den meisten Organisationen: Die Coverage-Map zeigt mehr Lücken als Abdeckung. Typische Schwachstellen:

• Initial Access (TA0001): Oft gut abgedeckt durch E-Mail-Security und Endpoint-Detection
• Execution (TA0002): PowerShell- und Script-Monitoring ist verbreitet, aber oft nicht granular genug
• Persistence (TA0003): Häufig blind — Registry-Modifikationen, Scheduled Tasks und DLL-Hijacking werden in vielen SIEM-Konfigurationen nicht überwacht
• Lateral Movement (TA0008): Eine der größten Lücken. Pass-the-Hash, RDP-Hijacking und WMI-basierte Bewegung erzeugen in Standard-SIEM-Konfigurationen oft keine Alerts
• Exfiltration (TA0010): Datenabfluss über HTTPS, DNS-Tunneling oder Cloud-Storage wird selten erkannt

Detection Engineering: Von Regeln zu messbarer Qualität

Detection Engineering behandelt SIEM-Regeln wie Software: Sie werden entwickelt, getestet, versioniert und kontinuierlich verbessert. Der Ansatz geht über das bloße Schreiben von Korrelationsregeln hinaus und umfasst einen vollständigen Lifecycle:

1. Threat Intelligence: Welche Techniken nutzen die Angreifer, die für unsere Branche und Infrastruktur relevant sind?
2. Data Source Mapping: Welche Logs brauchen wir, um diese Techniken zu erkennen? Werden diese Logs tatsächlich gesammelt?
3. Rule Development: Erkennungslogik entwickeln — nicht nur Signaturen, sondern verhaltensbasierte Regeln
4. Testing: Regeln gegen reale Angriffssimulationen (Atomic Red Team, MITRE Caldera) validieren
5. Tuning: False Positives reduzieren, ohne die Erkennungsrate zu opfern
6. Measurement: Coverage gegen ATT&CK-Matrix messen und Lücken dokumentieren

MTTD: Die Metrik, die zählt

Die wichtigste Kennzahl für Detection-Qualität ist Mean Time to Detect (MTTD) — die durchschnittliche Zeit zwischen dem Beginn eines Angriffs und seiner Erkennung. MTTD wird pro Angriffstechnik gemessen, nicht pauschal für das gesamte SIEM.

Warum das wichtig ist: Ein SIEM kann Brute-Force-Angriffe in Sekunden erkennen (niedriger MTTD) und gleichzeitig blind sein für Lateral Movement via WMI (MTTD: unendlich). Der Durchschnittswert verschleiert die tatsächlichen Lücken.

Um MTTD sinnvoll zu messen, brauchen Organisationen regelmäßige Purple-Team-Übungen: Das Red Team führt definierte ATT&CK-Techniken aus, das Blue Team misst, wie schnell — und ob — sie erkannt werden. Die Ergebnisse fließen direkt in die Detection-Engineering-Roadmap.

Die häufigsten Coverage Gaps

Basierend auf Branchenberichten und Erfahrungswerten sind folgende Bereiche in den meisten SIEM-Implementierungen unterabgedeckt:

• Cloud-native Angriffe: Azure AD/Entra-ID-Manipulation, AWS-IAM-Eskalation, GCP-Service-Account-Missbrauch — die meisten SIEMs sammeln On-Premise-Logs zuverlässig, aber Cloud-Telemetrie nur lückenhaft
• Identity-basierte Angriffe: Token Theft, Session Hijacking, OAuth-App-Registrierung — Angriffe, die keine Malware hinterlassen
• Nicht-menschliche Identitäten: Service-Accounts, API-Keys und Bot-Accounts werden selten mit derselben Aufmerksamkeit überwacht wie menschliche Benutzer
• Datenexfiltration: Outbound-Traffic-Analyse, DLP-Integration und DNS-Monitoring fehlen in vielen SIEM-Konfigurationen
• Living-off-the-Land: Angriffe, die ausschließlich legitime System-Tools nutzen (PowerShell, WMI, PsExec), sind ohne Baseline-Monitoring kaum erkennbar

Von der Lückenanalyse zur Roadmap

Detection Coverage zu messen ist kein Selbstzweck. Die Ergebnisse müssen in eine priorisierte Roadmap münden:

1. Bestandsaufnahme: Aktuelle Regeln gegen MITRE ATT&CK mappen — was ist abgedeckt, was nicht?
2. Priorisierung: Welche Techniken nutzen die relevantesten Threat Actors für unsere Branche? Diese zuerst abdecken
3. Data Source Gaps schließen: Oft fehlt nicht die Regel, sondern die Datenquelle. Ohne Cloud-Logs keine Cloud-Detection
4. Testen und validieren: Jede neue Regel muss gegen reale Angriffssimulationen getestet werden — nicht nur syntaktisch korrekt sein
5. Kontinuierlich messen: Coverage ist kein Zustand, sondern ein Prozess. Neue Techniken erfordern neue Regeln

Handlungsempfehlungen

• ATT&CK Coverage Assessment durchführen: Bestehende SIEM-Regeln gegen die MITRE-ATT&CK-Matrix mappen. Tools wie DeTT&CT automatisieren diesen Prozess
• Data Source Inventory erstellen: Dokumentieren, welche Logs tatsächlich gesammelt werden — und welche fehlen. Ohne Daten keine Detection
• Purple-Team-Übungen etablieren: Regelmäßig (mindestens quartalsweise) Angriffstechniken simulieren und MTTD messen
• Detection-as-Code: SIEM-Regeln in Git versionieren, in CI/CD-Pipelines testen und automatisiert deployen
• Coverage-Dashboard aufbauen: Eine ATT&CK-Heatmap, die auf einen Blick zeigt, wo die Erkennung stark ist — und wo die blinden Flecken liegen