SIEM Kurzfassung

Natürlich sollten wie Exchange Server und das Active Directory überwachen und spätestens nach einem Security Vorfall oder sogar Viren/Malware-Problem wünschen sich viele Administratoren und auch Geschäftsführer, dass Sie das Thema Logging etwas höher priorisiert hätten. Diese Seite beschreibt nicht sehr technisch die Zusammenhänge und Überlegungen für ein SIEM (Security Information and Event Management)

Alles ist eine Message

Wer nachvollziehen will, was in seinem IT-System so alles passiert, muss Vorgänge aufschreiben. Solche Meldungen haben meist folgende Bestandteile:

  • Zeitstempel
    Eine möglichst genaue Zeit ist wichtig, um Meldungen aus verschiedenen Systemen in Bezug zu setzen. Hierbei sind natürlich Zeitzonen, Sommer/Winter-Zeit aber auch Verzögerungen in der Übertragung zu berücksichtigen. Das generierende System hat vielleicht auch gar keine "verlässliche" Zeitquelle, so dass auch die nachfolgenden Systeme ihren Stempel addieren können.
  • Quelle
    Jede Nachricht hat einen Ursprung und der muss als Kriterium mit erfasst werden. Die Quelle kann bei "dummen Geräten" einfach eine IP-Adresse sein. Denkbar ist aber auch der Name des Programms oder Prozesses oder sogar eines Moduls.
  • Schweregrad  und Klassifizierung
    Es ist üblich, dass eine Meldung auch einen Schweregrad (Severity) enthält, d.h. ob es nur eine Information, eine Warnung oder sogar eine Fehlermeldung ist. Auch verschiedene Debug-Level sind denkbar
  • Nachricht
    Zuletzt muss jede Meldung auch eine Beschreibung haben. Das kann einfach ein String sein, wobei ich auch schon XML und JSON-Strukturen gesehen habe. Alles ist möglich, solange das Ziel diese Informationen auch parsen kann.

Der Begriff eine Message kann durchaus breit gefasst werden. Wenn z.B. eine Überwachungssoftware per SNMP jede Minute die Pakete eines Routers ausliest, dann ist das Ergebnis nur eine Zahl. Aber auch das ist genaugenommen eine "Meldung". Sie können die Richtung der Betrachtung einfach drehen und daraus einen "Sendevorgang" von der CPU zum nächsten System beschreiben. Die Überschrift "Alles ist eine Message" soll das auch beschreiben, dass die Einsammlung von Systemmeldungen und die Überwachung von Systemparametern gar nicht so weiter von einander entfernt sind.

Monitoring und LogManagement

Beim klassischen Monitoring gibt es eine zentrale Instanz, z.B. CheckMK, Nagius, PRTG u.a., die die zu überwachenden Systeme abfragt und Wert ermittelt. All diesen "Überwachungssystemen" ist aber gemein, dass Sie eher Werte einsammeln und grafisch aufbereiten aber keine Verarbeitung von "Mitteilungen" betreiben. Hierfür gib es andere Produkte wie Splunk, Elastic (ELK), Graylog, Syslog, Azure Log Monitor etc. die große Meldungen zentralisieren und vorhalten.

Ein SIEM bedient sich in der Regel aus diesen Daten und erlaubt eine Analyse vergangener Vorgänge aber Software kann auch in Echtzeit die Meldungen zu Verbindung bringen. Genaugenommen kann das SIEM auch die numerischen Daten einer Performanceüberwachung nutzen, um z.B. Abweichungen der Betriebsparameter als Auslöser für weitergehende Analysen nutzen. Es gibt also eine gewisse Überlappung zwischen einer "Überwachung" und einem Logmanagement und SIEM und erwarten Sie nicht, dass Sie ein System finden, welches alle Belange optimal abdeckt. Die meisten Firmen nutzen verschiedene Werkzeuge, um ihre Anforderungen zu erfüllt.

Manchmal ist es allein eine Frage der Zuständigkeiten. Die Daten eines SIEM darf vielleicht nur die Security-Gruppe sehen während Verfügbarkeitsdaten und Performancecouter primär für die Service-Verantwortlichen relevant sind.

Im Bezug auf das Einsammeln von Events für eine spätere Verarbeitung gibt es in der Regel mehrere Bausteine:

  1. Die Quellen
    Das sind dann Switches, Router, Proxyserver, Fileserver, Exchange Server etc., die ihre "Vorgänge" normal lokal protokolieren. Beispiele dazu sind das Windows Eventlog, Exchange MessageTracking Logs, IISlogs. Der Service selbst muss also eine Verbindung zum Backend aufbauen können. Systeme ohne eigenen Speicher sind prädestiniert dazu, Meldungen an ein kompatibles System zu senden, z.B. Syslog oder NetFlow
    Es gibt aber auch Applikationen, die z.B. eine REST-API zum Auslesen durch ein anderes System aus der Ferne bereitstellen. Hier muss dann natürlich die Zentrale die System kennen (Service Discovery oder Konfiguration) und über das Netzwerk auch erreichen können.
  2. Kollektoren
    Die gelieferten oder abgerufenen Daten müssen in einen Datenspeicher übertragen werden. Ich bezeichne diese Funktion als "Kollektor". Sie holen oder erhalten die Meldungen und ergänzen ggfls. Informationen (Client-IP, Zeitstempel) oder parsen und konvertieren die Meldungen, ehe Sie dann an den Speicher weiter gegeben werden.
    Daher gibt es auch Agenten, die man auf dem zu überwachenden System installiert, die dann "lokal" lesen und schon verarbeiten.
    https://www.elastic.co/de/logstash/
    https://docs.graylog.org/v1/docs/sending-data
     https://docs.microsoft.com/de-de/azure/azure-monitor/agents/agent-data-sources
  3. Backend
    Hinten nimmt dann etwas die Daten an und speichert meist in einer Realtime Datenbank und erlaubt eine Auswertung
  4. Parser/SIEMS
    Interessant wird es dann, wenn die Auswertung die verschiedenen Quellen zueinander korreliert.

Beispiel

Wenn Sie ihre Umgebung komplett integriert haben, dann könnten folgende Quellen ihnen Daten in ihre zentrale Speichen liefern

  • Der Switch meldet, welche Ports "online" gehen und welche MAC-Adresse gelernt wurde
  • Der DHCP-Server meldet, welche IP-Adresse vergeben wurde
  • Der Router meldet, wenn er per ARP eine IP-Adresse und MAC-Adresse lernt
  • Die Switch/Router/Firewalls melden, welche Quell-IP:Port mit welcher Ziel-IP:Port eine Verbindung hat (mit Datenmenge/Durchsatz/Anzal/Dauer)
  • Der VPN-Server meldet, welcher Anwender sich gerade angemeldet hat
  • Der PC bzw. DomainController meldet, wenn ein eine Anmeldung mit einem Konto erfolgt und welcher Client dies ist
  • Der KDC meldet, welches Kerberos-Ticket er für welchen Service und Anwender ausstellt
  • Dateiserver, SQL-Server etc. melden, welcher angemeldete User und Client welche Information liest, ändert, löscht
  • Der WebServer meldet die Zugriffe mit Informationen zum authentifizierten Benutzer, Useragent, IP-Adresse, Datenmenge
  • Gebäudesteuerung meldet, wenn Personen die Tür öffnen und das Gebäude betreten
  • Code und eigene Skripte können Statusmeldungen und Telemetrie- und Performancedaten der Applikation oder sogar Debuglogs protokollieren
  • Umgebungssensoren messen Energiebedarf, Stromausfälle, Wassereinbruch, Temperaturwerte
  • Ein Host könnte aber auch CPU-Last, DISK-Status, LAN-Status, gestartet/gestoppte Prozesse etc. melden.
    Auch numerische Wert sind eine "Message" auch wenn es nicht klassische ein Logeintrag ist.
  • und viele weitere Quellen

Dann kann ein SIEM versuchen "ungewöhnliche" Dinge zu finden oder wenn jemand was findet, dann kann man den Weg durch die Systeme nachvollziehen und besser rausfinden, was der Angreifer alles so gemacht hat. Ein Stück weit kann man damit sogar ein Monitoring ableiten, z.B. wenn ein Webserver viele 500-Fehler liefert, ein Exchange Server viele NDRs erstellt oder eine CPU-Last zu hoch oder auch zu niedrig ist

SIEM für Developer

Wenn Sie, wie z.B. Net at Work, auch als Softwareentwickler unterwegs sind, dann sollten Sie auch hier zumindest rudimentär eine gewisse Protokollierung vorsehen, die vom Kunden angezapft werden kann. Niemand kann erwarten, dass Sie nativ bestimmte SIEM-Produkte integrieren aber aussagekräftige Protokolldateien, Eventlog oder Syslog sind ein Anfang, mit dem eine Firma auch ihre Produkte in die zentrale Überwachung mit aufnehmen kann. Sie sollten natürlich dokumentieren, welche Daten an welcher Stelle bereitgestellt werden und wie diese sinnvoll abgerufen werden können.

  • Datei API
    Der einfachste Weg ist die Ausgabe in eine Textdatei, da die meisten SIEM-Lösungen problemlos solche Dateien einlesen können. Sie sollten aber schon darauf achten, dass z.B. jede Meldung in einer Zeile steht und durch Trennzeichen einen Zeitstempel, die Quelle und einen Schweregrad und vielleicht noch weitere Kennzeichen enthält. Das macht das Parsen später einfacher
  • WebService/API
    In der Docker/Micro-Services-Welt gibt es verschiedene Lösungen zum Monitoring (z.B. Prometheus), die per HTTPS die Verfügbarkeit und den Status der Microservices abfragen.
  • Meldungsversand.
    Eine Textzeile per UDP an einen SYSLOG-Server zu senden, ist kein Heckenwerk. Auch ein HTTP-Post mit den Daten als Payload an eine kompatible Gegenstelle stellt kein Problem dar.

Für SYSLOG gibt es eine RFC, die zumindest grob den Aufbau beschreibt, Bei allen anderen Optionen sprechen wir über mehr oder weniger proprietäre Schnittstellen. Wenn es von der SIEM-Lösung einen Agenten für ihre Betriebssystem gibt, dann dürfte der Web über lokale Dateien am flexibelsten sein.

Kleiner Tipp: Auch wenn es nicht zu berichten gibt, könnte ihr Applikation dennoch immer mal wieder auch einen "Mir geht es Gut"-Status vermelden. So kann ein SIEM auch erkennen, wenn ein System nicht mehr funktioniert oder die Meldungen aus einem anderen Grund ausbleiben.

Welche SIEM kaufen?

Sie können sich sicherlich vorstellen, dass ein SIEM-System nicht unbedingt eine einfache Software ist und speziell die Pflege von Regeln zu Erkennung von Angriffen oder auch nur das Nachverfolgen von Auffälligkeiten eine gehörige Portion Fachkenntnis braucht. Je kleiner eine Firma ist, desto schwerer kann Sie das selbst leisten und lagert entweder erst einmal die Software in die Cloud aus oder sogar die komplette Überwachung als Managed Services.

Hinzu kommt, dass lange Zeit meist nur "sensible" oder sehr große Firmen ein SIEM implementiert haben. Meist waren das auch Branchen wie Gesundheit, Rüstung, Finanzen, Pharmazie, Versicherungen. Entsprechend hochpreisig sind viele SIEM-Produkte, da sie seltener installiert wurden und die Kunden auch zahlungskräftig und zahlungswillig waren. Mittlerweile ist zumindest ein zentrales Log-Management auch im Mittelstand angekommen oder wird verstärkt nachgefragt. Verschiedene Anbieter schnüren daher Pakete, die auf diesen Markt angepasst sind und kombinieren weitere Funktionen wie z.B. Virenscanner und Verhaltenskontrolle.

Gerade für kleine Firmen muss es im ersten Schritt, gar kein komplettes SIEM sein, sondern sie gewinnen schon viel, wenn die eingesetzten Schutzprodukte etwas mehr machen, als nur mit Patterns nach Malware suchen. Ich würde Microsoft Defender for Business nun nicht als SIEM-System bezeichnen aber manchmal ist weniger auch mehr. Natürlich gibt es ähnliche Angebote auch von anderen AV-Herstellern als Suite.

Ich habe mich gegen eine Liste von SIEM-Lösungen entschieden und spreche auch keine Empfehlung aus. Das Thema ist sensibel, die Einsatzbereiche und Budgets unterschiedlich u.a., so dass eine Auflistung sogar in eine falsche Richtung lenken könnte.

Ich kann ihnen natürlich die verschiedenen Produkte aus der Oiffce365/Microsoft 365 Linie "Microsoft Defender for ..." oder Azure Sentinel als SIEM der Microsoft Cloud vorstellen. Dennoch sollte jede Überlegung zu dem Thema mit einer Ermittlung ihrer Umgebung, Anforderungen und Wünsche beginnen, ehe dann verschiedene Produkte gegenübergestellt werden. Ansonsten gibt es bekannte Zeitschriften und Firmen wie Gartner, die sich an Übersichten und Gegenüberstellungen versuchen.

Weitere Links