Zehn SIEM Use Cases, die in fast jeder Umgebung fehlen oder falsch eingestellt sind
Diese Seite beschreibt zehn Use Cases so, wie sie in einen Katalog gehören: mit Ziel, Datenquelle, Erkennungslogik in Worten, Schweregrad und Reaktion. Ohne Event-IDs und ohne Abfragesprache eines bestimmten Herstellers, damit Sie die Beschreibung in jedem SIEM umsetzen können.
- 10 Use Cases mit allen Angaben für den Katalog
- 5 Spalten: Ziel, Datenquelle, Logik, Schweregrad, Reaktion
- 0 Event-IDs, Herstellersyntax oder Technik-Nummern
- 1 Testfall je Use Case, den Sie noch ergänzen müssen
Was die fünf Spalten bedeuten
Jede Zeile der Tabelle ist ein vollständiger Use Case auf Anforderungsebene. Die Umsetzung im SIEM und der Testfall kommen in Ihrem Katalog dazu.
- Ziel
Was erkannt werden soll
Das Angriffsverhalten oder die Richtlinienverletzung, um die es geht. Das Ziel begründet, warum der Use Case existiert, und ist der Maßstab, an dem später Fehlalarme und Tuning gemessen werden.
- Datenquelle
Woher die Ereignisse kommen
Die Protokolle, die der Use Case braucht. Fehlt eine Quelle oder liefert sie ein Feld nicht, greift die Logik ins Leere. Prüfen Sie diese Spalte zuerst, bevor Sie eine Regel bauen.
- Logik
Wie erkannt wird, in Worten
Die Erkennungslogik so beschrieben, dass eine zweite Person sie versteht und in jedem SIEM umsetzen kann. Schwellenwerte und Zeitfenster sind Startwerte und werden im Tuning an Ihre Umgebung angepasst.
- Schweregrad
Wie dringend reagiert wird
Kritisch, Hoch oder Mittel steuert Reaktionszeit und Eskalation. Bei einigen Use Cases hängt der Grad vom Verlauf ab, etwa ob auf viele Fehlversuche eine erfolgreiche Anmeldung folgt.
- Reaktion
Was der Analyst tut
Die ersten Prüf- und Eindämmungsschritte in Kurzform. Sie sind der Kern des Playbooks und entscheiden, ob aus dem Alarm eine Wirkung wird oder nur ein Ticket.
- Fehlt noch
Testfall und Verantwortlicher
Beide gehören in jeden Katalogeintrag, stehen hier aber nicht, weil sie von Ihrer Umgebung abhängen: Wie erzeugen Sie das Ereignis reproduzierbar, und wer verantwortet den Use Case im Betrieb?
Katalog auf Anforderungsebene
Die Reihenfolge folgt grob dem Verlauf eines Angriffs: vom Zugang über die Ausweitung bis zur Wirkung. Auf schmalen Bildschirmen lässt sich die Tabelle seitlich verschieben.
| Use Case | Ziel | Datenquelle | Logik in Worten | Schweregrad | Reaktion |
|---|---|---|---|---|---|
| Brute Force auf Anmeldungen | Passwort-Rateversuche gegen ein Konto oder viele Konten erkennen, bevor ein Treffer gelingt. | Authentifizierungsprotokolle von Domänencontrollern, VPN, Identity Provider, exponierten Webanwendungen. | Viele fehlgeschlagene Anmeldungen von einer Quelle oder auf ein Konto in einem kurzen Zeitfenster. Höherer Grad, wenn darauf eine erfolgreiche Anmeldung derselben Quelle folgt. | Mittel; Hoch bei anschließendem Erfolg | Quelle und Zielkonten prüfen. Bei Erfolg Konto sperren, Kennwort zurücksetzen, Sitzungen beenden. Quelle an der Perimeter-Komponente blockieren. |
| Impossible Travel | Nutzung gestohlener Zugangsdaten erkennen, auch wenn das Kennwort korrekt war. | Anmeldeprotokolle von Identity Provider und Cloud-Diensten mit Standortangabe zur Quelladresse. | Zwei erfolgreiche Anmeldungen desselben Kontos aus Orten, die in der dazwischen liegenden Zeit physisch nicht erreichbar sind. Bekannte VPN-Austrittspunkte des Unternehmens ausgenommen. | Hoch | Nutzer über einen zweiten Kanal kontaktieren. Bestätigt er die Anmeldung nicht: Sitzungen beenden, Kennwort und zweiten Faktor zurücksetzen, Vorfall eröffnen. |
| Neue Domänen-Admins | Unerlaubte Rechteausweitung auf die höchste Berechtigungsstufe erkennen. | Active-Directory-Ereignisse zu Änderungen an Gruppenmitgliedschaften privilegierter Gruppen. | Jede Aufnahme eines Kontos in eine privilegierte Gruppe, die nicht zu einer genehmigten Änderung im Change-Prozess passt oder außerhalb des Wartungsfensters erfolgt. | Hoch | Mit dem Change-Prozess abgleichen. Ohne Freigabe: Mitgliedschaft sofort entfernen, ausführendes Konto und Quellsystem untersuchen, weitere Aktionen desselben Kontos prüfen. |
| Deaktivierung von Logging | Versuche erkennen, Spuren zu verwischen oder die Erkennung blind zu machen. | Ereignisse zum Löschen von Protokollen, Änderungen an Audit-Richtlinien, Heartbeats der Log-Agenten, Statusmeldungen des Protokollsammlers. | Ein Protokoll wird gelöscht, eine Audit-Richtlinie abgeschwächt oder ein Agent meldet sich nicht mehr, ohne dass eine Wartung angekündigt ist. Auch: Ein System liefert plötzlich deutlich weniger Ereignisse als üblich. | Hoch | Ausführenden Nutzer identifizieren und dessen weitere Aktivität prüfen. Protokollierung wiederherstellen. Bei fehlender Erklärung System isolieren und als Vorfall behandeln. |
| Massen-Dateiänderungen | Laufende Ransomware-Verschlüsselung oder Massenlöschung so früh erkennen, dass Eindämmung noch möglich ist. | Dateiserver-Auditprotokolle, Endpoint-Detection, Protokolle des Backup-Systems. | Ein Konto ändert, benennt um oder löscht innerhalb weniger Minuten ungewöhnlich viele Dateien, insbesondere mit neuen oder einheitlichen Dateiendungen oder unter Ablage einer Erpressernotiz. Bekannte Batch-Prozesse ausgenommen. | Kritisch | Konto sperren und Endgerät sofort vom Netz trennen. Krisenstab und Notfallplan aktivieren. Backup-Integrität prüfen und Backups vor Zugriff schützen. Ausbreitung auf weitere Freigaben prüfen. |
| Datenabfluss in Cloud-Speicher | Abfluss von Unternehmensdaten an private oder nicht freigegebene Speicherdienste erkennen. | Proxy- und Firewall-Protokolle, DNS, Cloud Access Security Broker, Data Loss Prevention. | Ungewöhnlich großes Upload-Volumen eines Nutzers oder Systems zu Speicherdiensten, die nicht auf der Freigabeliste stehen, verglichen mit dem bisherigen Normalverhalten dieses Nutzers. | Hoch | Übertragung unterbrechen, Zieldienst blockieren. Inhalt und Umfang der Daten bewerten. Datenschutz und Recht einbeziehen, weil Meldepflichten nach DSGVO und NIS2 ausgelöst sein können. |
| Verdächtige PowerShell | Ausführung von Angriffswerkzeugen und nachgeladenen Skripten auf Endgeräten und Servern erkennen. | Skriptblock- und Prozessprotokolle der Endgeräte, Endpoint-Detection. | Kodierte oder verschleierte Befehle, Skripte, die Inhalte aus dem Internet nachladen und direkt ausführen, oder PowerShell, gestartet von Office-Anwendungen oder von Nutzern ohne administrative Aufgaben. | Hoch | Prozess und Elternprozess prüfen, Skriptinhalt sichern. Endgerät isolieren, wenn die Ausführung nicht erklärbar ist. Weitere Systeme mit derselben Signatur suchen. |
| MFA-Fatigue | Erschöpfungsangriffe auf die Mehrfaktor-Authentisierung erkennen, bei denen der Nutzer zur Bestätigung gedrängt wird. | Protokolle des MFA-Dienstes und des Identity Providers. | Viele MFA-Anfragen für ein Konto in kurzer Zeit, die abgelehnt bleiben oder unbeantwortet auslaufen, insbesondere zu ungewöhnlichen Zeiten. Höchster Grad, wenn nach der Serie eine Bestätigung erfolgt. | Hoch | Nutzer anrufen und die Anfragen klären. Kennwort zurücksetzen, weil es dem Angreifer bekannt ist. Sitzungen beenden. Prüfen, ob der MFA-Dienst eine Zahlenabfrage statt einfacher Bestätigung erlaubt. |
| Anmeldung aus TOR oder anonymen Netzen | Zugriffe erkennen, bei denen der Angreifer seine Herkunft gezielt verschleiert. | Anmeldeprotokolle von VPN, Identity Provider und Webanwendungen, angereichert mit Listen bekannter Anonymisierungsdienste. | Erfolgreiche Anmeldung oder wiederholte Versuche von Adressen, die aktuellen Listen von TOR-Austrittsknoten oder kommerziellen Anonymisierungsdiensten zugeordnet sind. | Mittel; Hoch bei erfolgreicher Anmeldung | Bei Erfolg Sitzung beenden und Konto prüfen. Bei wiederholten Versuchen die Adressen blockieren. Grundsätzlich klären, ob Anmeldungen aus Anonymisierungsnetzen technisch unterbunden werden können. |
| Dienstkonto interaktiv angemeldet | Missbrauch technischer Konten erkennen, deren Zugangsdaten oft alt, hoch berechtigt und weit verbreitet sind. | Anmeldeprotokolle von Domänencontrollern, Servern und Arbeitsplätzen; Liste der Dienstkonten aus dem Verzeichnisdienst. | Ein als Dienstkonto gekennzeichnetes Konto meldet sich interaktiv an, per Fernzugriff oder an einem Arbeitsplatz, statt ausschließlich als Dienst auf den dafür vorgesehenen Systemen. | Hoch | Sitzung beenden, Kennwort rotieren und abhängige Dienste nachziehen. Klären, woher die Zugangsdaten stammen. Berechtigungen des Kontos auf das Notwendige reduzieren. |
Strukturiert erfassen: Mit der Use Case Factory auf jamorie.eu können Sie diese und Ihre eigenen Use Cases strukturiert erfassen und dokumentieren, einschließlich Testfall und Verantwortlichem.
Vier Erkennungsmuster stecken hinter den zehn Beispielen
Wer die Muster kennt, kann eigene Use Cases nach demselben Schema formulieren und weiß vorab, welche Art von Fehlalarmen zu erwarten ist.
-
Schwellenwert in einem Zeitfenster
Zu viele gleichartige Ereignisse in zu kurzer Zeit: Brute Force, MFA-Fatigue, Massen-Dateiänderungen. Einfach umzusetzen, aber empfindlich gegenüber falsch gesetzten Schwellen. Fehlalarme entstehen durch legitime Automatisierung, die ebenfalls viele Ereignisse erzeugt.
-
Abweichung vom Normalverhalten
Ein Konto oder System tut etwas, das es bisher nicht getan hat: Impossible Travel, Datenabfluss in Cloud-Speicher. Braucht eine Lernphase und Kontextdaten, erkennt dafür auch Angriffe mit gültigen Zugangsdaten. Fehlalarme entstehen bei Reisen, neuen Aufgaben und Umzügen von Diensten.
-
Abgleich mit einer Freigabe
Eine sicherheitsrelevante Änderung ohne passenden Vorgang: neue Domänen-Admins, Deaktivierung von Logging. Die Erkennung ist scharf, wenn der Change-Prozess gelebt wird, und erzeugt Dauerrauschen, wenn Administratoren an ihm vorbeiarbeiten. Der Use Case prüft damit indirekt auch die Prozessdisziplin.
-
Grundsätzlich verbotenes Verhalten
Etwas, das in Ihrer Umgebung nie legitim sein sollte: Dienstkonto interaktiv angemeldet, Anmeldung aus anonymen Netzen, verdächtige PowerShell durch Office-Anwendungen. Diese Use Cases haben die wenigsten Fehlalarme, setzen aber voraus, dass die Regel klar formuliert und die Ausnahmen bekannt sind.
Von der Vorlage zum eigenen Use Case
Sechs Schritte, um einen Use Case aus der Tabelle in Ihrer Umgebung produktiv zu nehmen, ohne dass er beim ersten Betriebstag im Alarmrauschen untergeht.
-
Datenquelle prüfen
Liefert die genannte Quelle die Ereignisse tatsächlich ans SIEM, vollständig, mit den nötigen Feldern und ohne größere Verzögerung? Wenn nicht, ist die Anbindung der erste Arbeitsschritt, nicht die Regel.
-
Schwellenwerte und Zeitfenster festlegen
Messen Sie zuerst, wie oft das Ereignis im Normalbetrieb vorkommt, und setzen Sie die Schwelle darüber. Ein Startwert aus der Tabelle ersetzt diese Messung nicht.
-
Bekannte Ausnahmen definieren
Schwachstellenscanner, Backup-Konten, Monitoring, Reise-VPN der Geschäftsleitung: Was erwartungsgemäß anschlägt, wird vorab als Ausnahme mit Begründung dokumentiert, nicht erst nach dem hundertsten Fehlalarm.
-
Playbook ausformulieren
Die Reaktion aus der Tabelle wird zu konkreten Schritten mit Zuständigkeit, Eskalationsweg und Kriterien für Fehlalarm oder Vorfall. Ergänzen Sie, wer außerhalb der Bürozeiten erreichbar ist.
-
Testfall bauen und ausführen
Erzeugen Sie das Ereignis kontrolliert oder spielen Sie Testdaten ein und prüfen Sie, ob der Alarm mit den richtigen Feldern ausgelöst wird. Erst dann geht der Use Case in den Betrieb.
-
Betrieb messen und nachjustieren
Anzahl der Alarme, Anteil Fehlalarme, Bearbeitungszeit. Nach den ersten Wochen folgt die erste Tuning-Runde. Wie die aussieht, beschreibt die Seite zu False Positives und Tuning.
Vertiefung zu SIEM Use Cases
Die Beispiele sind der Einstieg. Wie Sie die Abdeckung steuern und Fehlalarme in den Griff bekommen, behandeln die weiteren Seiten.
-
MITRE ATT&CK-Mapping
Wie Use Cases den Taktiken zugeordnet werden, wie eine Abdeckungsmatrix als Steuerungsinstrument dient und wo die Abdeckungsmessung an Grenzen stößt.
-
False Positives und Tuning
Ursachen von Fehlalarmen, Messung der False-Positive-Rate, der Tuning-Zyklus mit Allowlists und Schwellenwerten und die Frage, wann ein Use Case abgeschaltet wird.
-
Übersicht: SIEM Use Cases
Die sechs Bausteine eines Use Case, der Lebenszyklus von der Idee bis zur Außerbetriebnahme und die Kennzahlen MTTD und MTTR.
Zu den Beispiel-Use Cases
Warum stehen in der Tabelle keine Event-IDs oder Suchabfragen?
Weil die Logik in Worten herstellerunabhängig ist und länger gültig bleibt als jede konkrete Abfrage. Wer versteht, was erkannt werden soll, kann die Regel in jedem SIEM umsetzen und nach einem Plattformwechsel neu bauen. Die konkrete Abfrage gehört in die Implementierungsdokumentation des jeweiligen Use Case, nicht in die Anforderung.
Können wir die zehn Use Cases direkt übernehmen?
Als Anforderung ja, als fertige Regel nein. Jeder Use Case setzt bestimmte Datenquellen voraus und braucht Schwellenwerte, die zu Ihrer Umgebung passen. Ein Brute-Force-Use Case mit zehn Fehlversuchen in fünf Minuten passt für ein kleines Unternehmen, für einen Identity Provider mit Zehntausenden Nutzern nicht. Prüfen Sie zuerst die Datenquelle, dann die Schwelle, dann das Playbook.
Welche der zehn Use Cases sollten wir zuerst umsetzen?
Die, deren Datenquellen bereits angeschlossen sind und die Ihre kritischsten Systeme betreffen. In den meisten Umgebungen sind das neue Domänen-Admins, Deaktivierung von Logging und Massen-Dateiänderungen, weil sie auf Standard-Windows- und Dateiserver-Protokollen aufsetzen und späte Angriffsphasen sichtbar machen, in denen jede Minute zählt.
Wie hängen Schweregrad und Reaktion zusammen?
Der Schweregrad bestimmt, wie schnell jemand reagieren muss und wer eskaliert wird. Ein kritischer Alarm ruft außerhalb der Bürozeiten jemanden aus dem Bett, ein mittlerer wird am nächsten Werktag bearbeitet. Die Reaktion beschreibt, was dann konkret geschieht. Beides muss zusammenpassen: Ein kritischer Alarm ohne definierte Sofortmaßnahme erzeugt nur Stress, keine Eindämmung.
Wo dokumentieren wir unsere Use Cases?
In einem Katalog, den Ihr Team und nicht der SIEM-Hersteller besitzt: als strukturierte Einträge mit Ziel, Datenquellen, Logik, Schweregrad, Playbook, Testfall, Verantwortlichem und Änderungshistorie. Ob das ein Wiki, ein Ticketsystem oder ein spezialisiertes Werkzeug ist, ist zweitrangig, solange jeder Eintrag vollständig ist und beim Tuning fortgeschrieben wird.
Edouard Jacques
Welche dieser Use Cases fehlen bei Ihnen?
Im kostenlosen Erstgespräch gleichen wir die zehn Beispiele mit Ihrem Bestand ab: Was ist umgesetzt, was ist getestet, welche Datenquellen fehlen. Sie erhalten eine ehrliche Einschätzung und eine Reihenfolge für die nächsten Schritte.
- Abgleich der zehn Use Cases mit Ihrem Katalog
- Fehlende Datenquellen und ihr Anbindungsaufwand
- Priorisierung nach Risiko und Aufwand
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