Jede Sekunde erzeugen Betriebssysteme, Anwendungen und Netzwerkgeräte in einem Unternehmen kleine Textnachrichten, die verschiedenste Ereignisse beschreiben, beispielweise wenn sich ein Benutzer angemeldet hat, eine Datei erstellt wurde oder eine Netzwerkverbindung abgebrochen ist. Diese Nachrichten – auch Log-Daten genannt – speichern die Systeme normalerweise in einer Log-Datei auf einem lokalen Speichermedium. Log-Daten liefern wichtige Informationen über aufgetretene Ereignisse. Daher können sie wertvolle Dienste leisten, um Sicherheitsvorfälle oder Probleme im Systembetrieb zu erkennen. Zudem sind sie bei Audits oder forensischen Untersuchungen hilfreich.
Unterliegt ein Unternehmen Regularien wie dem Sarbanes-Oxley Act (SOX), Basel II, dem Health Insurance Portability and Accountability Act (HIPAA) oder dem Payment Card Industry Data Security Standard (PCI-DSS), so ist es sogar faktisch mehr oder weniger dazu gezwungen, seine Log-Nachrichten zu sammeln und auszuwerten. Zu diesem Zweck könnte eine zentrale System-Logging-Lösung die Arbeit erleichtern, die alle im Unternehmen verteilen Log-Daten auf einem einzigen zentralen Log-Server konsolidiert und speichert.
Herausforderungen eines zentralen Log-Managements
Bei einem Log-Management muss sich ein Unternehmen zunächst mit den verschiedenen Geräten auseinandersetzen, auf denen die Log-Daten liegen. Denn diese laufen in der Praxis unter den unterschiedlichsten Betriebssystemen und nutzen unterschiedlichste Log-Verfahren. An dieser Stelle hilft das etablierte und branchenweit akzeptierte Syslog-Protokoll (RFC 3164, 3195 und 5424) dabei, plattformübergreifend Log-Informationen einzusammeln und an eine zentrale Sammelstelle zu transportieren.
Der Markt bietet in diesem Bereich viele unterschiedliche Lösung an, die teilweise auch als Open-Source-Versionen verfügbar und Bestandteil einiger Linux-Distributionen sind. Im Vergleich zu Linux-Systemen behandeln Windows-Plattformen Log-Einträge anders. Denn Windows schreibt seine Log-Informationen nicht in eine Textdatei, sondern im Binärformat in sein Ereignisprotokoll. Um auch diese Daten in eine Syslog-Infrastruktur einbinden zu können, haben verschiedenen Hersteller hierfür entsprechende Windows-Agenten entwickelt. Diese lesen das Ereignisprotokoll regelmäßig aus und leiten die Log-Informationen dann per Syslog an den zentralen Log-Server im Unternehmen weiter. Andere Geräte wie beispielsweise Switches oder Router können von Haus aus Syslog-Nachrichten absetzen. Dazu muss der Administrator dort lediglich einen Server oder Syslog-Relay konfigurieren, der die Meldungen entgegennimmt.
Eine Herausforderung, insbesondere bei der späteren Analyse von Log-Daten, sind unterschiedliche Zeitstempel und Nachrichtenformate der einzelnen Meldungen. So verzichten beispielsweise einige Log-Systeme bei der Angabe von Datum und Uhrzeit auf das Jahr oder die Zeitzone, was eine spätere Korrelation der Meldungen mit denen anderer Systeme erschwert. Hier können entsprechende Syslog-Implementationen helfen, die den Zeitstempel jeder Log-Nachricht beim Transport etwa in das einheitliche Format des ISO-Standards 8601 konvertieren. Wer ganz auf Nummer sicher gehen möchte, kann zudem eine externe Timestamping Authority (TSA) einbinden (siehe hierzu auch RFC 3161), die für alle Log-Meldungen einen vertrauenswürdigen Zeitstempel liefert.
Sammeln von Log-Dateien allein reicht nicht aus
Um jederzeit im Nachhinein nachvollziehen zu können, was sich in einer Anwendung oder im Netzwerk abgespielt hat ist es wichtig, dass auch wirklich alle relevanten Log-Daten im zentralen Speicher ankommen. Denn könnte beispielsweise ein Angreifer verhindern, dass Informationen über seine erfolglosen Anmeldeversuche an einer Applikation übertragen werden, blieben seine Aktivitäten viel länger oder sogar vollständig unentdeckt.
Daher sollten Unternehmen beim Aufbau einer Log-Infrastruktur darauf achten, dass diese alle Syslog-Meldungen zwischenspeichert, wenn eine Verbindung von einer Log-Quelle zum zentralen Speicher vorübergehend unterbrochen ist. Zu diesem Zweck verfügen einige Syslog-Relays über einen festplattenbasierten Nachrichtenpuffer. Fällt dann beispielsweise die WAN-Verbindung zwischen einer Niederlassung und dem zentralen Rechenzentrum aus, kann der Sylog-Relay in der Außenstelle weiterhin alle dort generierten Meldungen einsammeln und zwischenspeichern. Steht die Verbindung zur Zentrale wieder, leert er seinen Puffer in den zentralen Meldungsspeicher.
Alternativ könnte die Syslog-Infrastruktur auch den Log-Lieferanten darauf hinweisen, dass ein Transport der Meldungen aktuell nicht möglich ist. Dann kann beispielsweise eine Anwendung ihre Daten entweder selber zwischenspeichern – oder aus Sicherheitsgründen sogar ihren Betrieb einstellen, bis eine Zustellung der Log-Meldungen wieder möglich ist. Eine weitere Variante ist, bei Nichterreichbarkeit des zentralen Syslog-Servers die Meldungen vorübergehend an einen Backup-Server zu leiten.
Schließlich kann die Syslog-Infrastruktur jede von einem Server, Netzwerkgerät oder einer Anwendung eingesammelte Meldung mit einer einmaligen Sequenznummer versehen. So lässt sich auch später jederzeit nachvollziehen – und in regulierten Branchen nachweisen –, dass alle generierten Meldungen auch übertragen und zentral abgelegt wurden.
Vertraulichkeit und Integrität von Log-Informationen
Das zentrale Sammeln und Speichern der unternehmensweiten Log-Daten ist der erste richtige Schritt zu einem vorgabenkonformen Umgang mit den Systemmeldungen. Doch den anfangs genannten Regularien ist dies nicht genug. So schreibt beispielsweise der PCI-DSS in seinem Punkt 4 vor, dass die Daten von Kreditkarteninhabern bei der Übertragung über öffentliche Netzwerke zu verschlüsseln sind, beispielsweise mit SSL/TLS (Secure Sockets Layer / Transport Layer Security).
Enthält nun beispielsweise eine Syslog-Meldung eines Online-Shops solche Daten, so muss diese folglich bei der Übermittlung an die Syslog-Sammelstelle entsprechend abgesichert werden. Eine verschlüsselte Übertragung empfiehlt sich auch dann, wenn Log-Meldungen Benutzernamen, Passwörter oder sonstige vertrauliche Daten enthalten. Kann ein Angreifer zum Beispiel eine Meldung über einen fehlgeschlagenen Anmeldeversuch eines Benutzers abfangen, die dessen Login und das durch einen Buchstabendreher falsche Passwort enthält, so kann er die korrekten Zugangsdaten einfach erraten.
Ähnliches verlangt auch der Standard COBIT 4.1 (Control Objectives for Information and related Technology). Er wird von Unternehmen gerne herangezogen, um die technisch weniger konkreten Vorgaben von SOX oder Basel II umzusetzen. Für den Austausch sensibler Daten schreibt COBIT im Abschnitt DS5.11 dabei vor, dass "Mechanismen unter anderem die Authentizität des Inhaltes sicherstellen müssen". In der Praxis lässt sich das umsetzen, indem sich beispielsweise ein Syslog-Sender und -Empfänger gegenseitig über X.509-Zertifikate authentifizieren. Angreifer haben so keine Möglichkeit, gefälschte Meldungen in den Log-Speicher einzuschleusen oder sich einer Anwendung gegenüber als Syslog-Kollektor auszugeben, um Log-Daten auszuspähen.
Sichere Ablage der Log-Dateien ist Pflicht
Die Hauptmotivation der gesetzlichen Regelwerke, Unternehmen zum Sammeln und Speichern ihrer Log-Daten zu zwingen, ist es, alle IT-Ereignisse transparent und jederzeit nachvollziehbar zu machen. Entsprechend fordert beispielsweise PCI-DSS in Punkt 10.2 wieder ganz konkret, "Audit-Trails für alle Systemkomponenten zu implementieren". Sind Vollständigkeit, Vertraulichkeit und Authentizität der Log-Daten während der Übertragung gesichert, müssen diese dann so gespeichert werden, dass sie auch dort nicht verändert werden können.
Gleichzeitig muss sichergestellt sein, dass nur berechtigte Personen Zugriff auf die Audit-Trails haben (PCI-DSS 10.5). In der Praxis lässt sich dies durch eine Verschlüsselung und digitale Signatur der gespeicherten Daten erzielen. Die Verschlüsselung stellt sicher, dass nur autorisierte Mitarbeiter darauf zugreifen können, während die Signatur Veränderungen an den abgelegten Daten verhindert.
Je nachdem, wie lange Unternehmen ihre Log-Daten aufheben wollen oder müssen – PCI-DSS 10.7 fordert mindestens ein Jahr für Audit-Trails –, können die Datenmengen schnell sehr groß werden. Um die Flut von in der Praxis bis zu mehreren GByte an Rohdaten pro Stunde einzudämmen, gibt es zwei Möglichkeiten:
Einerseits sollte die Syslog-Lösung in der Lage sein, die gespeicherten Daten zu komprimieren. Andererseits können auch hier intelligente Filter in den Syslog-Kollektoren dafür sorgen, dass unwichtige Informationen wie beispielsweise eine Meldung über eine erfolgreich zugestellte E-Mail gar nicht erst an den zentralen Speicher weitergeleitet werden. Dies ist natürlich nur dann möglich, wenn das regulative Rahmenwerk die Filterung von Meldungen erlaubt.
Log-Datei-Management als Chance
Das Sammeln und Speichern der unternehmensweiten Log-Daten ist nicht nur lästige Pflicht für regulierte Branchen, sondern auch eine Chance für jedes Unternehmen. So können insbesondere die konsolidierten Daten aller IT-Systeme dabei helfen, die Ursache von Störungen im IT-Betrieb schneller ausfindig zu machen. Gleichzeitig können sie die Sicherheit im Unternehmen erhöhen, indem sie SIEM-Produkten (Security Information and Event Management) zuarbeiten. Diese versuchen, durch die Korrelation von Ereignissen sicherheitsrelevante Vorgänge zu erkennen, die bei der Analyse einzelner Log-Dateien nicht auffallen würden.
Versucht zum Beispiel ein Angreifer, sich an allen Anwendungen im Unternehmen einmalig anzumelden, so würde jede Applikation zwar einen fehlgeschlagenen Versuch in ihr Protokoll schreiben. Bei Betrachtung der einzelnen Log-Datei wäre dies jedoch nicht auffällig. Korreliert ein SIEM-System nun die Ereignisse aller Systeme, so würde auffallen, dass innerhalb einer kurzen Zeitspanne von einem Benutzer viele erfolglose Anmeldeversuche ausgehen. Das verschafft dem betroffenen Unternehmen dann überhaupt erst die Möglichkeit, zeitnah darauf zu reagieren.
Eine Log-Infrastruktur kann dabei SIEM-Systeme einerseits mit den notwendigen Log-Daten versorgen. Da die Eventkorrelation ein sehr rechenintensiver Vorgang ist, können andererseits auch hier intelligente Filter in der Syslog-Infrastruktur dabei helfen, das SIEM nur mit den relevanten Log-Meldungen zu belasten. Dadurch ist es in der Lage, Richtlinienverstöße noch schneller zu identifizieren und zu melden.
Wegsehen hilft nicht
Unternehmen regulierter Branchen verfolgen heute zwei Strategien, um mit den Auflagen zum Absichern ihrer IT-Infrastruktur umzugehen: Entweder sie versuchen, diese so gut wie möglich umzusetzen, oder sie ignorieren sie zumindest so lange, bis der Druck von außen zu groß wird. Dabei ist es weniger grundsätzliche Ablehnung der Vorschriften, die Unternehmen zur Missachtung verleitet, sondern meist die Hilflosigkeit, wie mit den oft sehr schwammig formulierten Vorgaben so umzugehen ist, dass auch die mit der Implementation einer Lösung verbundenen Kosten noch vertretbar sind.
Hier bietet der Markt eine Vielzahl von Anbieter Compliance-konformer Log-Management-Lösungen, die bei den gesetzlich vorgeschriebnen Pflichtaufgaben helfen könnten. Wer dies nicht will, ist früher oder später eigenverantwortlich gezwungen, sich das Know-how und die entsprechenden Hilfsmittel anzueignen und diese dann im Unternehmen umzusetzen. Denn letztlich ist es mit der Umsetzung der Vorgaben wie mit dem nächsten Zahnarztbesuch: Sie lassen sich mit stetig wachsendem Schadensrisiko herauszögern, verhindern kann man sie aber nicht. (hal)