Security Information and Event Management mit Splunk

Inhaltsübersicht:

Die Splunk-Instanzen

Eine Splunk-Installation besteht im einfachsten Fall aus einer einzelnen Instanz, die Daten erhebt, sie indexiert und die Suche in den Daten ermöglicht. Die volle Leistungsfähigkeit von Splunk entfaltet sich aber erst in einer „distributed environment“, in dem jede Splunk-Instanz spezialisiert auf eine Aufgabe ausgelegt ist und nur einen Teil der Verarbeitungspipeline abbildet:

siem uf01siem uf02  siem uf03
Universal Forwarder: Daten sammeln und weiterleiten

siem intermediate
Intermediate oder Heavy Forwarder: Daten parsen und Feldanreicherung

siem indexer
Indexer: Daten indexieren, Daten suchen, Datenalterung

siem search
Search Head: Suchanfragen parsen und an Indexer weiterleiten, Ergebnisse aufbereiten und visualisieren

siem cm
Cluster Master: Verwaltung von redundant ausgelegten Indexern

siem lm
License Master: Überwachung des Lizenzvolumens, Bereitstellen von Lizenzen

siem ds
Deployment Server: Verteilung von Splunk-Apps auf andere Infrastrukturkomponenten Ein hoch verfügbares „distributed environment“ unter Beteiligung all dieser Komponenten könnte wie in Grafik 1 abgebildet aussehen:

Beim Indexieren werden automatisch Felder in dem Event bestimmt (weitere Felder lassen sich hinzufügen) und die Werte dieser Felder in ein Verzeichnis im Bucket eingetragen. Über die Werte der Felder kann hinterher schnell nach Events gesucht werden (Feldextraktion zum Indexing-Zeitpunkt).

Ein Feld ist stets das Raw Event, wie es der Log-Datei entnommen wurde. Es besteht auch die Möglichkeit, erst zum Zeitpunkt der Suche in dem Raw Event Felder zu bestimmen (z.B. mit regulären Ausdrücken), über deren Werte gesucht werden kann. Dabei gilt: Feldextraktion zum Indexing-Zeitpunkt bedeutet mehr Speicherbedarf und höhere Lizenzkosten, Feldextraktionen zum Suchzeitpunkt kosten Zeit.

Eine Suche bezieht sich immer auf einen Zeitbereich, der absolut (z.B. am 13.05.2016 zwischen 15:00:00 und 18:00:00 Uhr) oder relativ (z.B. in der letzten halben Stunde) definiert werden kann. Der Zeitbereich definiert also einen ersten Filter für die Events in einer Suche. Splunk-Suchen erinnern an Pipes unter Unix/Linux – durch eine initiale Suche wird eine Ausgangsmenge an Events bereitgestellt.

Diese wird dann durch das Verketten mit weiteren Kommandos über das Pipe-Symbol gefiltert oder angereichert, bis die Ergebnismenge erreicht ist.

Ergebnismengen lassen sich mit Splunk-Bordmitteln sowohl als Tabellen oder als Charts darstellen. Suchen lassen sich abspeichern (saved searches) und in sogenannten Dashboards visualisieren. Dem Betrachter wird so eine Analyse mit den aktuellen Daten in einem vorformatierten Schaubild präsentiert.

Um solche Dashboards nur definierten Benutzern zugänglich oder unabhängiger von den Gegebenheiten auf einem bestimmten Search Head zu machen, lassen sich die zugehörigen Definitionen und Konfigurationsdateien zu einer Splunk-App zusammenfassen.

siem 01Grafik 1: Beispiel für ein hoch verfügbares „distributed environment“