Im folgenden Artikel geben wir einen Einblick, wie neue Use Cases entwickelt werden und welche Fragen man sich dabei stellen sollte.

Use Case Testing
Vorbereitung

Als erstes wird analysiert, welche Arten von Logs existieren und mit welchen das verdächtige Verhalten detektiert werden könnte. Wie wird das Verhalten geloggt? Gibt es verschiedene Systeme, auf welchen jeweils anders geloggt wird? Können die Systeme unserer Kunden die entsprechenden Logdaten generieren oder braucht es dafür zusätzliche Software? Entsteht zusätzliches Logvolumen?

Im zweiten Schritt analysieren wir, wie das Verhalten mit bestehenden Datenmodellen abgebildet werden kann; dies kann uns später bei der Korrelation von verschieden Ereignissen helfen. Die Datenmodelle helfen uns nicht nur bei der Analyse, sondern geben uns auch die Möglichkeit, effizient in den Logs zu suchen und so die Ansprüche an die Infrastruktur und damit die Kosten für unsere Kunden tief zu halten.

Als letztes stellt sich die Frage, ob das verdächtige Verhalten simuliert werden kann. Falls dies der Fall ist, planen wir die Integration einer Prozedur, mit welcher der Use Case täglich End-to-End getestet werden kann

Umsetzung

Jetzt geht es um die Umsetzung! Diese beginnt mit der Normalisierung der rohen Logdaten. Dabei werden die benötigten Feldinhalte extrahiert, und den entsprechenden Feldern des Datenmodells zugeordnet. Zum Beispiel wird aus UserName=’Admin’ das normalisierte Feld user=’Admin’.

Sobald die Daten im erwünschten Format vorliegen, machen wir uns daran die «Suche» zu schreiben. Eine solche kann je nach Use Case sehr einfach (zum Beispiel Suche nach gewissen Feldinhalten) oder auch sehr kompliziert aussehen (wenn Informationen aus verschiedenen Datemodellen zusammengeführt und korreliert werden müssen). Wir beachten dabei, dass jeder Use Case gewisse obligatorische Elemente enthält:

• Sicherheitsdomäne (Netzwerk, Endpoint etc.)
• Timestamps
• Möglichkeit zum Unterdrücken von nicht relevanten Vorfällen
• Drilldowns für die Analyse der rohen Logzeilen
• Verlinkung mit bestehenden Dashboards

Wenn immer möglich schreiben wir eine Testprozedur und integrieren diese in unser End-to-End Testing-Framework. Dieses simuliert auf einem dedizierten Host täglich die zu detektierenden Abläufe und gibt uns die Möglichkeit festzustellen, ob alle Use Cases einwandfrei funktionieren.

Im Rahmen unseres Releaseprozesses werden die neuen Use Cases ausgiebig getestet und danach bei unseren Kunden ausgerollt.

Fehlerquellen im Betrieb

Aufgrund der Vielzahl an Systemen und Netzwerkarchitekturen ist auch die Liste der möglichen Fehlerquellen lang. Ohne End-To-End Testing ist es sehr schwierig abzuschätzen, zu welchem Grad ein SIEM verfügbar ist, und Mängel können bisweilen jahrelang unentdeckt bleiben.

Eine Auswahl möglicher Fehlerquellen verdeutlicht, wie wichtig eine laufende Kontrolle ist:

• Änderung am Logformat: Nach einem Softwareupdate werden Ereignisse in einem anderen Format geloggt. Dabei kann ein kleiner Unterschied dazu führen, dass einzelne Feldinhalte nicht mehr korrekt extrahiert werden.
• Neue Logquelle: Nach dem Wechsel auf eine neue Software (z. B. neue Antiviruslösung) werden Logs in einem neuen Format geliefert, welches die SIEM-Lösung noch nicht versteht und normalisiert werden muss.
• Logforwarding funktioniert nicht einwandfrei: Das Logvolumen könnte zu gross sein, oder gewisse Systeme liefern Logs verspätet. Dies kann dazu führen, dass Logs nicht zum richtigen Zeitpunkt durchsucht und korreliert werden können.
• Limiten: Wir haben sogar öfters beobachtet, dass aufgrund von internen Limiten bei im SIEM Splunk die Anzahl Suchresultate begrenzt wurde.
• Felder ohne Werte: Bei Aggregationen nach einzelnen Feldern kann es vorkommen, dass Events, welche leere Felder enthalten, aus der Suche ausgeschlossen werden.
• Vom Hersteller erhältliche Add-Ons normalisieren oft fehlerhaft.
• Einer der Prozesse zwischen Erzeugung der Logs und der Alarmierung ist eingefroren.
   

Fazit

Die Entwicklung eines Use Cases ist selbst bei einfachen Fällen eine komplexe Angelegenheit. Nur in Kombination mit einem End-to-End Testing Framework kann ein zuverlässiges Funktionieren der Angriffserkennung gewährleistet werden.

Ergänzende Informationen

Glossar

Use Case

Ein Use Case (= Anwendungsfall) definiert einen Angriff. Wenn wir im Zusammenhang mit einer SIEM-Lösung von einem Use Case sprechen, so ist damit die Suche nach verdächtigem Verhalten gemeint, dass durch einen Use Case detektiert werden soll. Kombiniert mit der Testprozedur, siehe auch Use Case Testing, wird sichergestellt, dass die Suche und die Alarmierung zuverlässig funktionieren.  

Emergency Use Case

Neu haben wir auch die Möglichkeit Use Cases in einem beschleunigten Prozess auszurollen. Dies ist beispielsweise bei einer akut auftretenden Bedrohung von Nutzen. Später werden Emergency Use Cases entweder als normale Use Cases ausgerollt oder falls die Bedrohungslage nicht mehr besteht, entfernt.

Customer Use Case

Viele unserer Kunden haben eigene Vorgaben oder Wünsche, was zusätzlich zu unseren bestehend Use Cases beobachtet werden soll. In diesem Fall beraten wir und setzen kundenspezifische Use Cases um.

Operational Use Case

Dieser überprüft die Integrität der SIEM-Plattform. Beispielsweise kontrollieren wir, ob Logdaten mit Verspätung ankommen oder ob interne Limiten erreicht werden.