Brauche ich ein SIEM?

In diesem Post beschäftige ich mich mit der Frage, ob man ein SIEM braucht oder nicht. Wie so oft gibt es gute Gründe für und gegen ein SIEM. Aber starten wir mit der Frage, was ein SIEM überhaupt ist oder tut.

Die Abkürzung «SIEM» steht für «Security Information and Event Monitoring». Die Grund-Idee ist, dass ein SIEM in Echtzeit Security relevante Daten auswertet, im entsprechenden Kontext bewertet und aufbereitet. Die Grundlage dafür sind in der Regel Log-Daten von verschiedenen Systemen im Netzwerk wie z.B. Firewalls, Server, Proxies, Clients, Active-Directory und so weiter. Das SIEM korreliert die Logs und bereitet diese entsprechend auf. Zusätzlich integriert ein SIEM weitere Informationen wie beispielsweise Threat-Intelligence Feeds. Nehmen wir folgendes Beispiel:

Die Firewall generiert einen Alert, da eine Verbindung zu einem bekannten C&C (Command&Control) Server aufgebaut wurde.

Nun geht ein Security-Administrator hin und führt folgende Schritte manuell aus:

1. 1. Er prüft die Source-IP Adresse anhand der Firewall-Logs. In diesem Fall ist die Source-IP die Adresse des Proxy-Servers.
   2. Prüfen der Proxy-Logs um die Source-IP des entsprechenden Clients zu identifizieren.
   3. Prüfen der Active-Directory (oder Client) Logs um zu prüfen welcher Benutzer zu der Zeit auf dem Client eingeloggt war.
   4. Eventuell isolieren des Clients und weiterführende forensische Analyse des Vorfalls. Z.B. könnte man die Zugriffe des Clients auf das restliche Netzwerk nach Auffälligkeiten prüfen.

Ein richtig konfiguriertes und eingestelltes SIEM wird uns diese manuellen Prozesse abnehmen und die Informationen automatisiert für uns aufbereiten. Auch weiterführende Prozesse wie die Isolation des Clients kann über Integrationen damit automatisiert werden. Zugegeben, das war ein sehr einfacher Anwendungsfall, welcher aber die Funktionsweise verständlich aufzeigt. Die Logs werden von einem SIEM in der Regel für lange Zeit gespeichert und indexiert, damit diese auch manuell durchsucht werden können.

Nach dem Beispiel mag man sich fragen, wo denn das Problem liegt? Die Lösung kann einem offensichtlich eine Menge Arbeit abnehmen. Dazu tut sie dies noch schneller und ohne Flüchtigkeits-Fehler. Da stimme ich auch voll zu, ein SIEM welches gut gepflegt und sinnvoll integriert ist, bietet einen grossen Mehrwert für jedes Security-Team.

Das Problem dabei ist, dass ein SIEM kontinuierlich gepflegt und an die Umgebung angepasst werden muss. Bei den meisten Lösungen kommen einige «Correlation Rules» für einfache Use-Cases, wie im Beispiel oben, mitgeliefert. Es liegt aber in der Natur der Sache, dass diese auf die entsprechende Umgebung angepasst werden müssen. Für komplexe Use-Cases müssen die Regeln dann auch manuell geschrieben werden. Dazu wird dann auch Know-How über die entsprechenden Angriffstechniken nötig. Wenn ich nämlich nicht weiss, wonach ich suchen soll, dann werde ich es auch ganz bestimmt nicht finden.

Ich habe schon einige gescheiterte SIEM Projekte gesehen, bei welchen nach zwei bis drei Jahren die Lösung wieder eingestampft wurde. Grund dafür war meistens, dass das SIEM auch nach dieser Zeit viel zu wenig Mehrwert bieten konnte. Man hat den Aufwand für den Betrieb unterschätzt und die Lösung zu wenig gepflegt.

Zusammengefasst lässt sich sagen: Ein SIEM ist ein enorm mächtiges Werkzeug. Man darf aber den Aufwand für die Integration und den Betrieb nicht unterschätzen. Es setzt einiges an Zeit und Aufwand voraus um Mehrwert aus der Lösung zu generieren.

Nun stellt sich vermutlich die Frage, was die Alternative ist. In den meisten Fällen, die ich gesehen habe, wurde ein SIEM durch eine NDR (Network Detection and Response) und/oder eine EDR (Endpoint Detection and Response) Lösung ersetzt. Diese Lösungen bieten direkt ab Inbetriebnahme einen Mehrwert und generieren deutlich weniger False-Positives. Durch eine Kombination der beiden Lösungen kann auch eine breite Abdeckung erreicht werden. Trotzdem würde ich empfehlen, die Log-Daten von den Systemen zentral zu speichern und Langzeit verfügbar zu machen. Dafür wird aber kein SIEM benötigt.

Zum Schluss darf natürlich das Fazit nicht fehlen. Grundsätzlich würde ich ein SIEM jedem Security-Team empfehlen, welches genügend Ressourcen und Know-How für den Betrieb aufbringen kann. Ich würde hier im Minimum eine Vollzeitstelle vorsehen. Wer diese Ressourcen nicht aufbringen kann oder will, ist mit den genannten Alternativen besser unterwegs. Vor allem die «Time to Value», also die Zeit bis die Lösung Mehrwert bietet, ist bei den Alternativen massiv besser. Schlussendlich kriege ich mehr für mein Geld in kürzerer Zeit.