SIEM Use Cases: Ihr SIEM erkennt nur, was Sie ihm beibringen
Ein SIEM sammelt Logs. Ob daraus Erkennung wird, entscheidet die Qualität der Use Cases: klar definiertes Ziel, passende Datenquellen, getestete Regel, sinnvoller Schweregrad und ein Playbook für die Reaktion. Diese Seite zeigt, wie Sie Use Cases strukturiert entwickeln, betreiben und messen.
- 6 Bausteine, die jeder Use Case braucht
- 7 Phasen von der Idee bis zur Außerbetriebnahme
- ATT&CK Zuordnung zu Taktiken und Techniken
- MTTD / MTTR Kennzahlen, an denen sich Erkennung messen lässt
Was ein SIEM Use Case ist
Ein Use Case ist mehr als eine Korrelationsregel. Er beschreibt vollständig, was erkannt werden soll, womit, wie schwer der Fall wiegt und was danach passiert.
- 1
Ziel
Welches Angriffsverhalten oder welche Richtlinienverletzung soll erkannt werden, und warum ist das für Ihr Unternehmen relevant? Ohne klares Ziel lässt sich weder der Nutzen noch die Fehlalarmquote bewerten.
- 2
Datenquellen
Welche Logquellen liefern die nötigen Ereignisse, in welchem Format, mit welcher Verzögerung? Fehlt eine Quelle oder ein Feld, greift die Regel ins Leere. Die Datenquellen sind der häufigste Grund, warum Use Cases in der Praxis scheitern.
- 3
Regel oder Analytik
Die konkrete Erkennungslogik: Schwellenwerte, Zeitfenster, Korrelation mehrerer Ereignisse oder statistische Abweichung vom Normalverhalten. Dokumentiert so, dass eine zweite Person sie versteht und ändern kann.
- 4
Schweregrad
Wie dringend muss ein Alarm bearbeitet werden? Der Schweregrad steuert Eskalation und Reaktionszeit und sollte aus dem Risiko abgeleitet sein, nicht aus dem Bauchgefühl beim Anlegen der Regel.
- 5
Reaktions-Playbook
Was tut der Analyst, wenn der Alarm kommt? Erste Prüfschritte, Kriterien für Fehlalarm oder echten Vorfall, Eskalationsweg, Eindämmungsmaßnahmen. Ein Use Case ohne Playbook erzeugt Alarme ohne Wirkung.
- 6
Testfall
Ein reproduzierbarer Test, der den Alarm auslöst und belegt, dass Regel, Datenquelle und Parser zusammenspielen. Wird bei jeder Änderung wiederholt und ist der einzige Nachweis, dass der Use Case tatsächlich funktioniert.
Von der Idee bis zur Außerbetriebnahme
Use Cases sind keine Einmalarbeit. Jeder durchläuft einen Lebenszyklus, und jede Phase hat ein Ergebnis, das dokumentiert wird.
-
Idee
Auslöser sind Bedrohungslage, ein eigener Vorfall, ein Audit-Befund, eine neue Logquelle oder eine Lücke in der ATT&CK-Abdeckung. Ideen werden gesammelt und nach Risiko und verfügbaren Datenquellen bewertet.
-
Anforderung
Ziel, benötigte Datenquellen, erwartetes Verhalten, Schweregrad und Zuordnung zu MITRE ATT&CK werden festgehalten. Wer den Alarm bearbeitet und was die Reaktion ist, wird jetzt geklärt, nicht erst nach dem ersten Alarm.
-
Implementierung
Die Regel oder Analytik wird im SIEM umgesetzt, Parser und Feldnormalisierung geprüft, das Playbook geschrieben. Die Umsetzung wird versioniert, damit Änderungen nachvollziehbar bleiben.
-
Test
Der Testfall wird ausgeführt: Erzeugt das simulierte Ereignis den Alarm mit den erwarteten Feldern? Wie viele Alarme entstehen im Normalbetrieb? Erst nach bestandenem Test geht der Use Case in den Betrieb.
-
Betrieb
Alarme werden bearbeitet, Ergebnisse dokumentiert. Erfasst werden Anzahl der Alarme, Anteil Fehlalarme, Zeit bis zur Bearbeitung. Diese Zahlen sind die Grundlage für das Tuning.
-
Tuning
Schwellenwerte, Ausnahmen und Zeitfenster werden anhand der Betriebsdaten angepasst. Jede Änderung wird begründet, getestet und dokumentiert, damit das Tuning die Erkennung schärft statt sie unbemerkt auszuhöhlen.
-
Außerbetriebnahme
Wenn die Datenquelle wegfällt, das Risiko nicht mehr besteht oder ein besserer Use Case die Erkennung übernimmt, wird der alte Use Case dokumentiert abgeschaltet. Tote Regeln kosten Lizenz, Rechenzeit und Aufmerksamkeit.
Typische Use Cases und ihre ATT&CK-Zuordnung
Diese Use Cases finden sich in den meisten Umgebungen. Die Zuordnung zu MITRE ATT&CK zeigt, welchen Angriffsschritt sie sichtbar machen.
| Use Case | ATT&CK-Taktik | Typische Datenquellen |
|---|---|---|
| Brute Force auf Anmeldungen | Credential Access | Authentifizierungslogs von Domänencontrollern, VPN, Identity Provider |
| Impossible Travel | Initial Access (gültige Konten) | Anmeldelogs von Identity Provider und Cloud-Diensten mit Standortinformation |
| Ungewöhnliche Privilegienerweiterung | Privilege Escalation | Windows-Sicherheitsereignisse, sudo- und Auditlogs, EDR |
| Massen-Dateiverschlüsselung (Ransomware-Indikatoren) | Impact | Dateiserver-Auditlogs, EDR, Backup-System |
| Deaktivierung von Sicherheitslogging | Defense Evasion | Ereignis zum Löschen des Audit-Logs, Agent-Heartbeats, Änderungen an Audit-Richtlinien |
| Anlegen neuer Domänen-Admins | Persistence / Privilege Escalation | Active-Directory-Ereignisse zu Gruppenmitgliedschaften |
| Datenabfluss über Cloud-Speicher | Exfiltration | Proxy- und Firewall-Logs, DNS, CASB, DLP |
Strukturiert erfassen: Mit der Use Case Factory auf jamorie.eu können Sie Use Cases strukturiert erfassen und dokumentieren, mit allen sechs Bausteinen an einem Ort.
Woran Sie einen guten Use Case erkennen
Vier Qualitätsmerkmale entscheiden, ob ein Use Case im Betrieb hilft oder stört. Und weil nicht alles gleichzeitig geht, braucht es eine Reihenfolge.
-
False-Positive-Rate
Wie viele Alarme stellen sich als harmlos heraus? Eine hohe Rate ermüdet das Team und führt dazu, dass echte Treffer übersehen werden. Die Rate wird je Use Case gemessen und ist die wichtigste Eingangsgröße für das Tuning.
-
Abdeckung
Welche Taktiken und Techniken decken Ihre Use Cases ab, und welche Systeme sind einbezogen? Eine Abdeckungsmatrix gegen MITRE ATT&CK zeigt Lücken und verhindert, dass zehn Use Cases dasselbe erkennen und andere Angriffsschritte niemand sieht.
-
Testbarkeit
Lässt sich der Use Case reproduzierbar auslösen? Wenn nicht, ist er nicht prüfbar, und Sie merken erst im Ernstfall, dass ein Parser-Update ihn stillgelegt hat.
-
Dokumentation
Ziel, Logik, Datenquellen, Playbook, Testfall, Verantwortlicher, Änderungshistorie. Vollständig dokumentierte Use Cases überleben Personalwechsel und Toolwechsel und sind im Audit vorzeigbar.
Priorisierung: Neue Use Cases werden nach zwei Fragen gereiht.
- Wie hoch ist das Risiko, das der Use Case adressiert: Welche Angriffsschritte auf welche kritischen Systeme macht er sichtbar?
- Sind die benötigten Logquellen bereits angeschlossen und in brauchbarer Qualität vorhanden, oder muss zuerst die Datenbasis geschaffen werden?
- Hoher Risikobeitrag und vorhandene Daten zuerst; hoher Risikobeitrag ohne Daten wird zum Projekt für die Logquellen-Anbindung.
- Use Cases mit geringem Risikobeitrag, die aber viele Alarme erzeugen, werden kritisch geprüft und eher abgeschaltet als weiter getunt.
Kennzahlen für Erkennung und Reaktion
Ob Ihre Use Cases wirken, zeigt sich nicht an der Anzahl der Regeln, sondern an der Zeit, die zwischen Angriff, Erkennung und Behebung liegt.
-
MTTD: Mean Time to Detect
Die mittlere Zeit vom Beginn eines Vorfalls bis zu seiner Erkennung. Sie zeigt, ob Use Cases und Datenquellen die relevanten Angriffsschritte früh genug sichtbar machen.
-
MTTR: Mean Time to Respond
Die mittlere Zeit von der Erkennung bis zur Eindämmung oder Behebung. Sie hängt vor allem von Playbook, Zuständigkeiten und Eskalationswegen ab, weniger von der Technik.
-
Je Use Case
Anzahl der Alarme, Anteil echter Vorfälle, Bearbeitungszeit, Datum des letzten erfolgreichen Tests. Diese Werte machen sichtbar, welche Use Cases tragen und welche nur Aufwand erzeugen.
Strategie, Tool-Auswahl und Betrieb: Fragen zur SIEM-Strategie, zur Auswahl der Plattform und zum Betriebsmodell behandelt unser Schwesterportal siem-beratung.com. Diese Seite konzentriert sich auf die Erkennungslogik.
JAMORIE: Beratung für IT-Sicherheit und Compliance
JAMORIE Consulting aus Eschborn bei Frankfurt am Main berät mittelständische Unternehmen zu IT-Sicherheit und Compliance. Pragmatisch, mit Blick auf das, was ein Team im Alltag tragen kann.
-
Use-Case-Katalog aufbauen
Wir erarbeiten mit Ihnen einen priorisierten Katalog: Risiken, vorhandene Logquellen, ATT&CK-Zuordnung, Schweregrade. Ergebnis ist eine Liste, die Ihr Team oder Ihr Dienstleister direkt umsetzen kann.
-
Bestehende Use Cases prüfen
Wir sichten Ihre aktiven Regeln: Was erzeugt Alarme ohne Wirkung, was ist nicht getestet, was fehlt? Daraus entsteht eine Tuning- und Abschaltliste mit Begründung je Use Case.
-
Betrieb und Messung einrichten
Lebenszyklus, Dokumentationsvorlage, Testroutine und Kennzahlen werden so aufgesetzt, dass sie in Ihrem SOC oder beim Dienstleister dauerhaft funktionieren, herstellerunabhängig.
SIEM Use Cases kurz beantwortet
Wie viele Use Cases braucht ein SIEM?
Es gibt keine richtige Zahl. Entscheidend ist, ob die Use Cases die Risiken abdecken, die für Ihr Unternehmen relevant sind, und ob jeder Alarm auch bearbeitet wird. Wenige gut getestete Use Cases mit klarer Reaktion sind wertvoller als Hunderte importierte Regeln, die niemand kennt und deren Alarme ungelesen bleiben.
Reichen die mitgelieferten Regeln des SIEM-Herstellers nicht aus?
Herstellerregeln sind ein brauchbarer Startpunkt, kennen aber weder Ihre Systemlandschaft noch Ihre Schwellenwerte. Ohne Anpassung erzeugen sie viele Fehlalarme oder greifen ins Leere, weil die vorausgesetzten Logquellen fehlen. Jede übernommene Regel sollte wie ein eigener Use Case behandelt werden: mit Ziel, Test, Playbook und Verantwortlichem.
Was ist eine akzeptable False-Positive-Rate?
Das hängt vom Schweregrad und von der Kapazität Ihres Teams ab. Ein Use Case für kritische Ereignisse darf mehr Fehlalarme erzeugen als einer, der täglich hundertfach anschlägt. Wichtiger als ein fester Zielwert ist, dass Sie die Rate je Use Case messen, im Tuning nachweislich senken und Alarme ohne Reaktion konsequent hinterfragen.
Warum die Zuordnung zu MITRE ATT&CK?
Die Zuordnung zu Taktiken und Techniken macht sichtbar, welche Angriffsschritte Sie erkennen können und wo Lücken sind. Sie schafft eine gemeinsame Sprache zwischen Detection Engineering, Incident Response und Management und hilft bei der Priorisierung neuer Use Cases. Sie ersetzt aber keine Risikobewertung für Ihr Unternehmen.
Wie testet man einen Use Case?
Mit einem dokumentierten Testfall, der das erwartete Ereignis erzeugt oder als Testdaten einspielt und prüft, ob der Alarm mit den richtigen Feldern ausgelöst wird. Der Test wird bei Änderungen an Regel, Datenquelle oder Parser wiederholt. Ohne Testfall wissen Sie nicht, ob ein stiller Use Case nichts findet oder schlicht nicht mehr funktioniert.
Wer ist für Use Cases zuständig, wenn der SOC extern betrieben wird?
Der Dienstleister betreibt die Regeln, die Verantwortung für Abdeckung und Priorisierung bleibt bei Ihnen. Vereinbaren Sie im Vertrag, wie neue Use Cases beauftragt werden, wie Tuning dokumentiert wird und in welchem Rhythmus Sie den Use-Case-Katalog gemeinsam durchgehen. Der Katalog selbst sollte Ihnen gehören.
Sprechen wir über Ihre Use Cases
Im kostenlosen Erstgespräch gehen wir Ihren aktuellen Use-Case-Bestand durch: Was deckt er ab, was fehlt, was erzeugt nur Alarme. Sie erhalten eine ehrliche Einschätzung und einen Vorschlag für die nächsten Schritte.
- Bestandsaufnahme Ihrer Use Cases und Logquellen
- Die größte Erkennungslücke und ihre Priorität
- Aufwand für Katalog, Tests und Kennzahlen
Danke, wir rufen Sie an.
Sie hören innerhalb eines Werktags von uns, meist deutlich schneller. Wenn Sie lieber gleich einen festen Termin wählen möchten, geht das direkt im Kalender auf jamorie.eu.
Termin selbst wählen