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
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:
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.
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:
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.
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.
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.
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.
Dieser überprüft die Integrität der SIEM-Plattform. Beispielsweise kontrollieren wir, ob Logdaten mit Verspätung ankommen oder ob interne Limiten erreicht werden.