Logs sind das Rohmaterial für ein Security Monitoring. Wer sie ungefiltert sammelt, scheitert aber an der Masse. Wie also sollen Firmen ihre Daten selektieren?
Ohne eine gezielte und laufende Analyse von Log-Daten ist die IT-Security blind. Zentral gelagerte Log-Files sind die Voraussetzung für ein Security Monitoring. Gegenüber einer dezentralen Speicherung bringt sie mehrere Vorteile:
- Für die Analyse von Problemen reicht ein Login. Der Wechsel zwischen Systemen und Konsolen entfällt.
- Spuren zu verwischen wird für Angreifer schwieriger, weil die Log-Daten laufend auf ein zentrales System transportiert werden.
- Daten können über alle integrierten Systeme korreliert betrachtet werden. Der Datenfluss widerspiegelt sich in den zentral gesicherten Logs.
Logdaten sammeln. „Alles“ sammeln geht nicht
In einer idealen Welt würden wir alle Daten sammeln, die anfallen. In der Praxis ist das unmöglich. Niemand hat Zeit und Ressourcen, solche Datenmengen zu analysieren. Zudem verrechnen manche Software-Hersteller nach Volumen. Deshalb muss man sich sehr gut überlegen, worauf man verzichten kann.
Wertvolles identifizieren: Vorarbeit, die sich auszahlt
Alles zu sammeln ist auch deshalb nicht hilfreich, weil ein wichtiger Gedankengang fehlt: Welche Teile der Infrastruktur sind es wert, beobachtet zu werden? Daten zu klassifizieren, ist ein wesentlicher Schritt im Security Monitoring.
Zeit und Geld dafür fehlen oft. Trotzdem sollte man diesen Schritt auf keinen Fall unterlassen. In der Praxis zeigt sich nämlich, dass man sich früher oder später dennoch Gedanken dazu machen muss. Wer die wertvollen digitalen Güter (neudeutsch "Assets") der Firma im Rahmen eines Risk-Managements zu Beginn identifiziert, spart Zeit.
Sind die digitalen Assets bestimmt, ist sehr einfach zu entscheiden, welche Informationen gesammelt werden müssen: Jeweils alle Daten, die zu einem Asset protokolliert sind. Innerhalb dieser präzis definierten Assets soll man also tatsächlich alles sammeln.
Zentral sammeln: Wer, was, wann, wie
Konkret benötigt ein Security Analyst mindestens diese Angaben:
- Wer hat auf die Daten zugegriffen? (System, Benutzer)
- Was hat der User mit den Daten gemacht? (angelegt, modifiziert, gelöscht, kopiert, etc)
- Wann hat er die Daten modifiziert? (Zeitstempel, möglichst normiert auf UTC, insbesondere bei global agierenden Unternehmen wichtig)
- Wie hat er auf die Daten zugegriffen? (Client Software)
Hat man diese Daten, kann man nachvollziehen, was mit einem Asset passiert ist. Weil die Daten zentral gespeichert sind, ist es aufwendig, die Spuren von Zugriffen und Manipulationen zu verwischen.
Alarme für besonders wertvolle Assets: Use Cases
Dank der Selektion von wertvollen Assets können Security-Verantwortliche proaktiv Alarme anlegen. Zum Beispiel für den Fall, dass auf eine zentrale Datenbank mit Administrator-Rechten zugegriffen wird. In diesem Zusammenhang sprechen wir von Use Cases.
Maschinen können keine Use Cases definieren
Die Use Cases bestimmen, was gesammelt werden muss. Die meisten Use Cases sind unternehmensspezifisch formuliert. Es ist deshalb eine Illusion zu glauben, ein automatisches Werkzeug könne diese Arbeit übernehmen. Wir haben bis heute auf dem Markt kein Werkzeug gesehen, dass dies kann - auch wenn es die Werbung suggeriert.
Aus unseren Erkenntnissen und Erfahrungen haben wir den Security Monitoring Cycle geschaffen. Er führt prozessorientiert durch die verschiedenen Phasen. In der Phase „Review“ werden die Assets identifiziert. In der Phase „Concept“ definieren wir Use Cases und bestimmen, welche Daten in der nächsten Phase (Collect) gesammelt werden sollen.