Was ist SIEM Use Case Management und worauf kommt es dabei an? 5 FAQs

Was versteht man unter einem SIEM Use Case?

Unter einem Use Case wird in Bezug auf das Thema SIEM ein Gesamtpaket von Bestandteilen verstanden, welche es erlauben, ein konkretes Bedrohungsszenario zu identifizieren. Typische Bestandteile eines umfänglichen Use Cases sind eine ausführliche Dokumentation vom Bedrohungsszenario, Anforderungen an die operative IT, Detektionsmechanismus, technische Anforderungen an das SIEM, eine Beschreibung der vorzunehmenden Normalisierungen sowie eine Assoziation des Use Cases mit abgedeckten Compliance-Anforderungen.

Es ist sinnvoll, ergänzend einen Testcase zu erstellen, welcher zur laufenden Validierung der Use Case Funktionalität genutzt werden kann. Der Einsatz derartiger Tests ist insbesondere im Falle von Betriebssystem-Updates und zur Abdeckung von Compliance-Anforderungen sinnvoll, um eine fortwährende Funktionalität des Use Case zu gewährleisten.

Wie wähle ich für mein Unternehmen die passenden Use Cases aus?

 Eine Herausforderung bei der Auswahl passender Use Cases ist, gerade initial, die fehlende Übersicht über potentielle Threats (Bedrohungen), die es zu erkennen gilt. Bei der Aufstellung einer umfänglichen Übersicht ist es deshalb ratsam, sich auf etablierte Frameworks zu verlassen, um ohne großen Ressourcenaufwand und dennoch mit hoher Qualität in die Planungsphase eintreten zu können. Dabei empfiehlt SECUINFRA die Verwendung technisch und zugleich praktisch ausgerichteter Frameworks.

Compliance Frameworks sind als Orientierungshilfe für die Auswahl konkreter Use Cases eher ungeeignet, da diese in der Regel nur vage Handlungsanweisungen und Empfehlungen formulieren, aus denen sich keine konkreten Detektionsmechanismen ableiten lassen. Da Compliance Frameworks und Anforderungen jedoch in der Auditierung oft ein hohes Maß an Wichtigkeit aufweisen, sollten die identifizierten Use Cases anschließend den erfüllten Anforderungen aus der Compliance zugeordnet werden.

Was sind die wichtigsten Frameworks für die Entwicklung von SIEM Use Cases?  

Es existiert mittlerweile eine Vielzahl verschiedener Frameworks, die bei der Identifikation relevanter Threats sehr hilfreich sein können. Im Folgenden werden die Frameworks genannt, welche sich für die Ableitung von Threats und Use Cases als bseonders geeignet erwiesen haben. Hierzu zählen beispielsweise das ATT&CK Framework von MITRE, die Microsoft Security Monitoring Recommendations, das CIS (Center for Internet Security) Top 20 sowie OWASP (Open Web Application Security Project).

Das ATT&CK Framework von MITRE ist die umfangreichste Sammlung von systembezogenen Angriffstechniken, die frei verfügbar ist. Die Angriffstechniken werden dabei einer oder mehreren Taktiken (Kategorien) zugeordnet, die dem typischen Ablauf eines Angriffs entsprechen und stark an die Killchain erinnern.

Dabei enthält jeder Eintrag des Frameworks

– eine Beschreibung des Angriffs

– eine Auflistung der APT (Advanced Persistent Threats) , die dafür bekannt sind, diese Technik einzusetzen

– Empfehlungen, um den erfolgreichen Einsatz der Technik zu verhindern sowie

– Methoden der Detektion.

Da relevante Frameworks sehr umfassend sind, ist es gerade im Zuge der Einführung eines SIEM Systems nicht sinnvoll, eine komplette Abdeckung erreichen zu wollen. Stattdessen empfiehlt sich eine geschickte Streuung der Use Case Auswahl auf die Bereiche von Angreiferverhalten, welche besonders eindeutig detektierbar sind und häufig Anwendung finden. Lesen Sie hierzu auch unseren TechTalk Beitrag: Wie MITRE ATT&CK zur Auswahl von SIEM Use Cases genutzt werden kann

Welche Kriterien sind für die SIEM Use Case Auswahl relevant?

Zur Beurteilung potenzieller Use Cases sollten wenigstens die folgenden Kriterien in Betracht gezogen werden:

1. Potenzieller Impact im Falle des Eintretens

• Auf das betroffene Asset
• Auf die betroffenen Nutzer
• Auf die betroffene Organisationseinheit
• Auf die Geschäftsprozesse

2. Wahrscheinlichkeit des Eintritts

• Häufigkeit des Auftretens im Allgemeinen
• Faktorierung durch die IT-Landschaft (Wie anfällig ist mein Unternehmen für einen solchen Angriff?)
• Wahrscheinlichkeit der Mitigation durch bestehende Sicherheitsmechanismen

3. Qualität des Erkennungsmechanismus

Mindestens unterteilt in folgende Qualitätsstufen:

• Erkennt spezifische Tools, welche die Technik ausnutzen können
• Erkennt IoC, welche auf die Technik hinweisen
• Erkennt die Technik selbst

4. Geschätzte Komplexität des Use Cases

• Administrativer Aufwand (u.a. Anpassung von Audit Logs, Installation zusätzlicher Software, Anbindung neuer Logquellen, notwendige Firewallfreischaltungen)
• Prozessualer Aufwand (z.B. Anpassung von Runbooks, Rücksprache mit Betriebsrat und/oder Datenschutzbeauftragtem, Erstellung neuer Prozesse u.a.m.)
• Use Case Logik (z.B. technische Komplexität der Thematik, Anzahl zu berücksichtigender Datenquellen, Nutzung von Speichermechanismen, Notwendigkeit neuer Extraktionen sowie Notwendigkeit weiterer Datenanreicherung)
• Visibility Anforderungen (z.B. Notwendigkeit Benutzerlisten zu pflegen, Einordnung von Netzwerksegmenten sowie Anbindung weiterer, sekundärer Datenquellen)

5. Geschätzte Wahrscheinlichkeit der Erkennung durch das eingesetzte SIEM System 

Was ist wichtig für die Entwicklung und Implementierung von SIEM Use Cases?

Die Entwicklung von Use Cases

Ziel der Entwicklung sollte es sein, den bzw. die optimalen Detektionsmechanismen zur Abdeckung eines Threats herauszuarbeiten, welcher unter den gegebenen Bedingungen umsetzbar erscheinen. Die Entwicklung von Use Cases sollte möglichst in einer separaten Testumgebung stattfinden, welche jedoch vom Aufbau her nah an der Produktivumgebung zu halten ist. Ein einfacher Weg, dies zu erreichen besteht darin, die Events aus der Produktivinstanz oder über den Message Streaming Dienst an die Testinstanz des SIEM Systems weiterzuleiten. Um Synergien zwischen Entwicklung und Implementierung zu schaffen, sollte bereits im Zuge der Entwicklungsphase eine minimalistische Dokumentation stattfinden.

Diese Dokumentation sollte zumindest folgende Punkte umfassen:

1. Betroffene Logquellen
2. Begründung der Wahl des Ansatzes
   • Formlose Beschreibung möglicher Detektionsansätze
   • Beurteilung der beschriebenen Detektionsansätze auf Basis praktischer Erfahrungen
   • Erläuterung der Entscheidungsfindung-Beschreibung der Anforderungen an die Logquelle
3. Beschreibung der Anforderungen an das SIEM System
   • Normalisierung von Events
   • Anreicherung von Events
   • Ergänzung um Eigenentwicklungen
4. Beschreibung der Regellogik
5. Beschreibung potenzieller False-Positives und False-Negatives
6. Beschreibung potenzieller Problemstellungen bei der Implementierung

Die Implementierung von Use Cases

Ziel der Implementierung sollte es sein, den fertigen Detektionsansatz in das produktive SIEM-System so zu portieren, dass er performant und zuverlässig betrieben werden kann. Hierzu müssen stärker als in der Entwicklungsphase die Eigenheiten des SIEM-Systems und der IT-Landschaft berücksichtigt werden. Die Dokumentation der Implementierungsphase erfordert besondere Sorgfalt und Akribie, da diese Unterlage häufig Gegenstand der Überprüfung durch externe Auditoren ist.

Sie sollte wenigstens die folgenden Punkte, ergänzend zu den zuvor bereits erfassten Informationen, beinhalten:

Implementierte Anforderungen an das SIEM

1. Normalisierung von Events
   • Art der Normalisierung
   • Technische Beschreibung (Regulärer Ausdruck, XPath oder ähnliches)
   • Begründung für Abweichungen gegenüber der Entwicklung
2. Anreicherung von Events
   • Beschreibung des technischen Mechanismus zur Anreicherung
   • Datenquelle für Anreicherung
   • Zyklus für Aktualisierung der Daten
3. Ergänzung um Eigenentwicklung
   • Beschreibung der ergänzten Funktionalität
   • Name und Kontaktdaten des Entwicklers
   • Verweis auf Dokumentation der Eigenentwicklung

Implementierte Regellogik

1. Abweichungen gegenüber der Entwicklung/ Begründung dieser Abweichungen
2. Anpassungen im Zuge des Regeltunings
   • Beschreibung pro Anpassungsanlass
3. Dokumentation der Testphase
   • Dauer der Testphase
   • Anzahl Regelauslösungen
   • Interpretation der Testphase
4. Zeitpunkt der produktiven Aktivierung des Use Cases
   • Abnahme durch Leitung SOC