Datenprotokoll streng nach Gesetz

Enikö Visky ist Regional Director DACH bei BalaBit IT Security in München

Banken und Finanzinstitute gehören schon seit Langem zu den am stärksten regulierten Branchen. Dies wird sich durch die aktuelle Krise auf den Finanz- und Warenmärkten aller Wahrscheinlichkeit nach noch weiter verschärfen. Aber auch andere Organisationen, etwa in den USA börsennotierte Aktiengesellschaften oder Unternehmen aus der Gesundheitsbranche, unterliegen zahlreichen Regularien. Weniger bekannt ist dabei, dass diese Vorschriften auch Vorga-ben zum Umgang mit den Statusmeldungen machen, die Netzwerkkomponenten, Server, Betriebssysteme und Anwendungen laufend generieren.

Das im Compliance-Umfeld wahrscheinlich am meisten zitierte Regelwerk ist der Sarbanes-Oxley Act (SOX). SOX ist im Bezug auf die IT eher allgemein gehalten, was die Umsetzung in der Praxis nicht gerade erleichtert. Der Payment Card Industry Data Security Standard (PCI-DSS), der sich primär an Banken, Kreditkarten- und Handelsunternehmen sowie Dienstleister richtet, wird dagegen schon recht konkret: Zahlreiche Vorgaben beziehen sich direkt auf Protokollinformationen, insbesondere auf die sichere Übertragung und Speicherung der Daten. So fordert beispielsweise der Punkt 4.1 des PCI-DSS, dass vertrauliche Kreditkartendaten nur verschlüsselt über öffentliche Netze übertragen werden dürfen. Punkt 10.5 verlangt, dass Audit-Trails, also Interaktionsprotokolle, so abzusichern sind, dass sie nicht manipuliert werden können. Weiterhin müssen Log-Daten mindestens ein Jahr lang aufbewahrt werden und mindestens drei Monate lang online abrufbar sein.

Unternehmen der entsprechend regulierten Branchen müssen sich also mit dem Thema auseinandersetzen. Aber es gibt auch ganz pragmatische Gründe, warum sich die Sammlung und Auswertung von Log-Daten lohnen kann. Gibt es beispielsweise Probleme in einem bestimmten Teil des Unternehmensnetzwerks, kann ein Administrator mithilfe von Werkzeugen zur Log-Datenanalyse genau feststellen, welche IT-Komponente wann in welchem Zustand war. Dies erleichtert einerseits die Fehlersuche. Andererseits hilft es auch dabei, nach einem Sicherheitsvorfall den genauen Hergang der Ereignisse zu rekonstruieren.

Zudem gibt es Tools, die in Echtzeit versuchen, durch die Korrelation von Ereignissen, Angriffe auf das Netzwerk oder Anwendungen zu erkennen. Versucht beispielsweise ein Angreifer, sich nacheinander an allen Systemen im Unternehmen einmalig mit einem bestimmten Benutzernamen und Passwort anzumelden, so erscheint dies aus der Perspektive der einzelnen Anwendung wie ein normaler Vorgang - selbst wenn der Anmeldeversuch scheitert. Der konsolidierte Blick auf alle fehlgeschlagenen Anmeldeereignisse zeigt hingegen, dass alle Anmeldeversuche von einem bestimmten Rechner innerhalb kurzer Zeit ausgingen. Dies lässt sich nun als sicherheitsrelevanter Vorfall werten und könnte entweder einen Alarm oder das Abschaltung des angreifenden Switch-Ports auslösen.

Die Korrelation und Analyse von Log-Daten übernimmt beispielsweise Software für das Security Information und Event Management (SIEM). Doch kann diese nur dann zuverlässig arbeiten, wenn ihr auch alle relevanten Log-Meldungen vollständig vorliegen. Gehen Meldungen auf dem Weg von der Quelle zum Ziel verloren, sind die verbleibenden Daten wenig aussagekräftig bis unbrauchbar.

Fast jede aktive Netzwerkkomponente, jedes Betriebssystem und so gut wie jede Unternehmensanwendung ist heute in der Lage, Informationen über interne Ereignisse zu protokollieren. Während Microsofts Windows Server dabei eigene Wege geht und diese Daten in sein Ereignisprotokoll schreibt, unterstützen die meisten Log-Quellen den Syslog-Standard.

Syslog steht dabei für zweierlei: Einerseits für ein Protokoll, das definiert, wie Systemereignisse formatiert und über Computernetze übertragen werden. Gleichzeitig steht Syslog auch für Programme, die Ereignismeldungen entgegennehmen, weiterleiten oder speichern. Unterstützt ein Gerät oder ein Programm das Syslog-Protokoll, so bedeutet dies einfach, dass es Syslog-Meldungen über das Netzwerk absetzen kann. Zuständig für die Sammlung und Speicherung sind sogenannte Syslog-Kollektoren, die beispielsweise Bestandteil der gängigen Linux-Distributionen sind.

Ab einer gewissen Unternehmensgrösse beziehungsweise Zahl von Komponenten und Anwendungen, die Syslog-Meldungen absetzen, ist es sinnvoll, eine hierarchische Syslog-Infrastruktur aufzubauen. Dazu nimmt beispielsweise ein Syslog-Kollektor pro Standort alle dort generierten Meldungen entgegen und leitet sie an den Syslog-Kollektor in der Zentrale weiter, der die Meldungen dann speichert. Weiterleitende Syslog-Programme nennt man auch Syslog-Relays. Bei den Relays ist es unter anderem wichtig, dass sie eingehende Meldungen zwischenspeichern können, falls das Relay-Ziel vorübergehend nicht erreichbar ist. Denn Syslog-Quellen beginnen irgendwann damit, ihre Meldungen zu verwerfen, wenn sie diese nicht erfolgreich absetzen können.

Auch Syslog-agnostische Anwendungen, die den De-facto-Standard nicht unterstützen, lassen sich dabei in eine unternehmensweite Syslog-Infrastruktur integrieren. Hierzu installiert man beispielsweise auf einem Windows-Server einen Syslog-Agenten, der regelmässig das Ereignisprotokoll des Windows-Servers durchforstet und alle neuen Einträge als Syslog-Meldung an den nächsten Relay weiterleitet.

Um den zentralen Syslog-Speicher oder ein dort angeschlossenes SIEM nicht zu überlasten, sollten Syslog-Relays und -Kollektoren in der Lage sein, wichtige von unwichtigen Meldungen zu unterscheiden und nur Erstere weiterzuleiten. Denn da die Eventkorrelation ein sehr rechenintensiver Vorgang ist, kann ein SIEM dies mit reduzierter Last deutlich effizienter erledigen.

So ist es beispielsweise für ein SIEM nicht relevant, ob ein E-Mail-Server eine Nachricht erfolgreich zustellen konnte. Fehlgeschlagene Anmeldeversuche, überlaufende Festplatten, extreme CPU-Auslastung oder übermässiger Netzwerkverkehr an einem Switch-Port sind hingegen wichtige Informationen. Die Filterregeln der Syslog-Relays sollten sich dabei individuell anpassen lassen.

Um die eingangs erwähnten Vorgaben in Bezug auf Log-Daten zu erfüllen, sind noch weitere Massnahmen notwendig. Die geforderte Vertraulichkeit der Syslog-Meldungen lässt sich etwa durch eine verschlüsselte SSL-Übertragung sichern. Dabei müssen zumindest alle Relays und Kollektoren dies unterstützen. Um die Authentizität von Syslog-Quellen zu garantieren, können sich Syslog-Sender und -Empfänger gegenseitig über X.509-Zertifikate authentisieren. Das verhindert wirkungsvoll Syslog-Injection-Angriffe.

Ebenso wichtig - und auch vom PCI-DSS gefordert - ist eine revisionssichere Speicherung der Log-Daten, um sie auch dort vor Manipulation zu schützen. Dazu sollten die empfangenen Daten idealerweise mit einem Zeitstempel einer externen vertrauenswürdigen Timestamping Authority (TSA) versehen sein, und andererseits verschlüsselt und signiert abgespeichert werden. Für grössere Infrastrukturen gibt es zu diesem Zweck dedizierte Hardware, beispielsweise die Syslog-ng Store Box, die hochverfügbar ausgelegt ist und alle für eine Compliance-gerechte Sammlung, Speicherung und Archivierung notwendigen Funktionen mitbringt.

Syslog-ng: die Open-Source-Variante

Syslog-ng ist eine Open-Source Implementierung von Syslog mit allen Features und einigen Erweiterungen, die bekannte Schwachstellen des Protokolls beheben.
In SuSE Linux ab Version 9.3 ist Syslog-ng der standardmässige Syslog-Server. Da die Open-Source-Variante für eine Vielzahl von Plattformen verfügbar ist, erleichtert sie den Aufbau eines heterogenen Logging-Systems. Syslog-ng wird aufgrund seiner weiten Verbreitung von vielen anderen Syslog-Implementierungen als Referenzimplementierung verwendet.
Kommerzielle Erweiterungen ermöglichen zudem den Aufbau Compliance-konformer Syslog-Infrastrukturen.