IT-Architekturberatung

Aufbau von Logmanagement

 

Betriebssysteme, Applikationen und Netzwerkkomponenten produzieren Logdaten. Selbst in einer kleinen bis mittelständischen Firma fallen hier schnell einige Gigabyte täglich an. „Interessante“ Meldungen gehen in diesem Wust aus Daten schnell verloren und damit gehen unter Umständen auch Meldungen verloren, die größeres Unheil ankündigen, so dass dieses eintreten kann.

Logmanagement übernimmt die Aufgabe, sich durch den Datenberg zu wühlen und die Spreu vom Weizen zu trennen, so dass relevante Meldungen weitergeleitet werden. Zusätzlich können die Daten korreliert werden und so Zusammenhänge erkannt werden, die sonst verborgen blieben. Gerade im Sicherheitskontext hilft nur ein holistischer Ansatz. Statistiken über die gesammelten Daten erlauben zudem Capacity Planning basierend auf realistischen Zahlen, statt Vermutungen und Bauchgefühl.

Am Markt etabliert haben sich einige Lösungen des Security Information Event Managements (SIEM), Splunk als kommerzielle Lösung und Elasticsearch / Logstash / Kibana (ELK) bzw. Graylog im OpenSource Umfeld.

Kibana, Kibana Dashboard, Screenshot

Abb. 1 Screenshot des Kibana Dashboards

Praxisbeispiel - Kundensituation

In einem kleinen bis mittelständigen Kundennetz gibt es bereits diverse Quellen von Logdaten:

  • Windows Server
  • Webserver
  • Firewall
  • Netzwerkkomponenten
  • Applikationslogs

Selbst Windowsserver haben keine einheitliche Sammelstelle für Logdaten. Neben dem Eventlog gibt es Textdateien für Windows Updates und andere Dienste. Im Fehlerfall muss der Admin also auf mehrere Consolen zugreifen und selbst die Zusammenhänge bilden. Verdächtiges Verhalten zu erkennen ist mit manueller Arbeit quasi unmöglich oder kostet Vollzeitmitarbeiter.

Die Auswertung unter Sicherheitsgesichtspunkten ist etwa im regulierten Finanzumfeld sogar vorgeschrieben (vgl. Punkt 17, 29 und 38 der „Bankaufsichtlichen Anforderungen an die IT (BAIT)“). Auch kritische Infrastrukturen, die unter KRITIS fallen, sind von ähnlichen Auflagen betroffen.

In einer Konfiguration, bei der ein VPN-Zugang für Active Directory Benutzer freigeschaltet ist, kann der Admin bei einer Störung einfach den Benutzernamen eines Anwenders, der keine Verbindung hinbekommt, in das System eingeben und bekommt alle relevanten Logmeldungen gezeigt, um so schneller die Ursache des Problems zu finden. Dies erlaubt auch im Operationellen deutliche Effizienzsteigerungen. Ein wichtiger Aspekt bei der Einführung einer solchen Lösung ist die richtige Skalierung. Große Datenmengen wollen in Echtzeit verarbeitet werden. Wird hier an Hardware gespart, können sich Rückstaus ergeben und das System läuft über oder bleibt stehen.

Die Lösung der matrix

Mit der matrix erhalten Kunden den Aufbau einer skalierbaren Lösung, in der die Logs des Kunden zusammengeführt werden. Für Standardanwendungen ist der Aufbau zum Festpreis möglich - Die Einbindung von Applikationslogs geschieht nach Aufwand. Nach einem Assessment der Infrastruktur und anfallenden Log Volumina gibt die matrix aufgrund ihrer Erfahrung auch Empfehlungen für eine passende Hardware.

Nach einer Baselining Phase in der die „Normalwerte“ für diverse KPIs aus den Logdaten ermittelt werden, definiert das matrix-Team mit dem Kunden Alarme, welche das OPs-Team des Kunden rechtzeitig warnen.

Als Einstieg bietet die matrix in einem „Mini“-Projekt einen „Health Check“ aus operativer und Sicherheitssicht, bei dem Kundenlogdaten auf der Infrastruktur der matrix ausgewertet werden und der Kunde einen Bericht über mögliche Auffälligkeiten erhält.

Temperaturmonitor für Server, Screenshot, matrix

Abb. 2 Temperaturmonitor für Server

Haben Sie Fragen?
Wir helfen Ihnen gerne weiter!

Bild Konstantin Agouros
Ihr Ansprechpartner
Konstantin Agouros
Head of Open Source & AWS
matrix technology AG
T
+49 89 589395-600