Damit unterbleibt eine Verknüpfung von Log-Meldungen, die zu einer Erkennung von bereits einfachsten Zusammenhängen notwendig wäre. Beispielsweise führt das Anlegen eines neuen Benutzers in einem Directory und das kurz darauf folgende Löschen dieses Benutzers bei herkömmlichen Log-Auswertungen zu keinem Alarm.
Hier handelt es sich schlichtweg um zwei Log-Meldungen, die jeweils für sich betrachtet keine Gefahr darstellen. Dass gerade die geringe Zeitspanne zwischen
dem Anlegen und dem Löschen diese Aktion verdächtig macht, bleibt der herkömmlichen Log-Auswertung verborgen. Möglich ist beispielsweise, dass diese Accounts – unbeabsichtigt – mit Fehlern angelegt wurden. Auch denkbar ist aber, dass sie nur kurzzeitig erstellt wurden, um sensible Daten unter falschen Namen auszulesen. Das Beispiel macht deutlich, dass eine reaktive und auf einzelne Systeme bezogene Log-Auswertung für einen entscheidenden Nachteil bei der Sicherstellung des Betriebs und damit auch der Verfügbarkeit von IT-Umgebungen sorgt. Aus diesem Grund wird heutzutage die Erkennung von komplexen Angriffen
durch Korrelation von Log-Meldungen gefordert. Security Information and Event Management (SIEM) Tools beseitigen diese Nachteile und ermöglichen eine proaktive Bewertung des Gesamtzustandes einer IT-Umgebung. Zur Sicherstellung
ihrer Funktion basieren sie auf einer Mutli-Tier-Archtiektur. Mindestens drei Schichten sorgen für eine effiziente Verarbeitung der Informationen innerhalb des SIEM-Tools. Die Abbildung zeigt den grundsätzlichen Aufbau. Im Folgenden werden die einzelnen
Ebenen beschrieben.

Log-Erzeugung

Auf Ebene 0 werden die Log-Meldungen erzeugt. Diese können über zwei verschiedene Ansätze vom SIEM-Tool verarbeitet werden. Zunächst ist hier der
PUSH-Ansatz zu nennen. Hier werden die Log-Meldungen vom erzeugenden
System zum SIEM-Tool geschickt. Dem gegenüber steht der PULL-Ansatz. In
diesem Fall wird eine Komponente des SIEM-Tools so konfiguriert, dass sie die


Log-Meldungen von den ausgewählten Systemen in bestimmten Zeitabständen
ausliest.

Vorverarbeitung

Auf Ebene 1 erfolgt die Vorverarbeitung der Log- Meldungen. Neben der Filterung und der Normalisierung werden die Log-Meldungen hier auch aggregiert und kategorisiert.

Filterung

Die Filterung verfolgt das Ziel unnötige Log-Meldungen sofort auszusortieren. Dies ist notwendig, da die Menge der anfallenden Daten viel zu groß ist um alle Log- Meldungen zu verarbeiten.

Normalisierung

Nach der Filterung werden die verbleibenden Log-Meldungen normalisiert. Notwendig ist dies, da sich die Log- Meldungen von Hersteller zu Hersteller mitunter stark unterscheiden. Große Unterschiede bestehen auch zwischen Log-Meldungen von Betriebssystemen und Applikationen. Unerlässlich bleibt damit ein gemeinsames Format in das alle anfallenden Log-Meldungen konvertiert
werden.

Aggregation

Auf Ebene 1 erfolgt eine Aggregation von Log-Meldungen. Oftmals werden identische Log-Meldungen mehrmals hintereinander von dem gleichen System
erzeugt. Hier gilt es zu beachten, dass der Informationswert der zweiten und jeder nachfolgenden Log-Meldung gering ist. Aus diesem Grund wird nur die erste Log-Meldung weiterverarbeitet, die allerdings um die Information „Anzahl der aufgetretenen identischen Log-Meldungen“ erweitert wird.

Kategorisierung und Priorisierung

Das Ziel bei der Kategorisierung ist die Verfeinerung des Infomationswertes
von Log-Meldungen. Beispielsweise können Zoneninformationen mit aufgenommen
werden. Damit ist es möglich Log-Meldungen aus dem Hochsicherheitsbereich
entsprechend zu priorisieren. Auch erfolgt hier eine Einordnung der Log-Meldung in einem System-Typ wie Firewall, Betriebssystem, diverse Applikationen usw.
Nach Abschluss von Ebene 1 bezeichnet man die verbleibenden Log-Meldungen
als Events. Sie besitzen alle den gleichen Aufbau und lassen sich damit im SIEMTool
einfach verarbeiten.

Korrelation

Im Anschluss an Ebene 1 werden die Events korreliert. Hierzu kommt in den
meisten Fällen ein Regelsystem zum Einsatz. In diesem werden unterschiedliche
Events miteinander verknüpft. Neben Regelsystemen fi ndet sich in vielen SIEM-Tools auch eine Anomaliekomponente. Diese schlägt Alarm, wenn es zu Abweichungen vom Normalzustand der überwachten IT-Umgebung kommt.
Beide Ansätze machen es notwendig das SIEM-Tool auf die jeweilige ITUmgebung
vorzubereiten. Dies beginnt bei der Festlegung von verschiedenen Sicherheitszonen und endet mit der Definition von False Positives. Greift eine Korrelationsregel, so wird ein Alert erzeugt. Dieser ist vom gleichen Typ wie ein Event und kann somit für weitere Korrelationen verantwortlich sein.

Reaktion

Wurde ein Alert erzeugt, muss sichergestellt sein, dass auch angemessen reagiert
wird. Dazu ist es notwenig einen Security Incident Handling Prozess zu defi nieren. In diesem muss festgelegt werden, welche Events als Security Events bezeichnet werden, wie diese verarbeitet werden und vor allem welche Reaktion auf welchem Alert folgt. Hier gilt es fachliche und hierarchische Eskalation zu unterscheiden.

Fazit

Eine reaktive bzw. eine auf einzelne Systeme bezogene Log-Auswertung entspricht nicht den Anforderungen der heutigen Zeit. Gefordert werden proaktive und systemübergreifende Methoden. Durch die Korrelation von Events können Bedrohungen bereits im Vorfeld von SIEM-Tools erkannt werden. Dabei berücksichtigen diese die komplette IT-Umgebung. Folglich kann mit der
Einführung eines SIEM-Tools und den damit verbundenen Prozessen eine bessere
Absicherung von IT-Umgebungen gewährleistet werden.

---

weiterführende Infos / Links :

---

Anmerkungen: