Es ist klar, dass eine rein dezentrale Protokollierung auf IT-Systemen hier nicht viel hilft, denn wie sollen den Forderungen nach Aufbewahrung und regelmäßiger Prüfung nachgekommen werden? Erst eine zentrale Protokollierung kann einen wirklichen Sicherheitsgewinn liefern. Dementsprechend wird dies typischerweise von der Informationssicherheit ebenfalls gefordert, wie die Anforderung OPS.1.1.5.A6 „Aufbau einer zentralen Protokollierungsinfrastruktur (S)“ des Bausteins OPS.1.1.5 Protokollierung des BSI IT-Grundschutz-Kompendiums zeigt [1].
Wenn eine zentrale Protokollierung kein „Datengrab“ sein soll, das nur bei forensischen Analysen von Incidents geöffnet wird, hilft es nichts — es muss eine automatisierte kontinuierliche Auswertung von Logs her. So kann Analysten ein aktuelles Lagebild in Dashboards vermittelt werden, und es können automatisiert in Echtzeit Anomalien erkannt, entsprechende Alarme erzeugt und ggf. kann sogar automatisch reagiert werden. Hier fordert beispielsweise der Baustein DER.1 „Detektion von sicherheitsrelevanten Ereignissen“ für einen normalen Schutzbedarf zwar nur die „Nutzung einer zentralen Protokollierungsinfrastruktur für die Auswertung sicherheitsrelevanter Ereignisse“ (Anforderung DER.1.A11), jedoch bei erhöhtem Schutzbedarf auch die „Zentrale Detektion und Echtzeitüberprüfung von Ereignismeldungen“ (Anforderung DER.1.A15). Damit ist man auf direktem Weg von einem zentralen Log Management hin zu einem Security Information and Event Management (SIEM).
Produkte sowohl für das reine Log Management als auch für SIEM sind seit Jahren auf dem Markt verfügbar (z.B. Graylog, Splunk und QRadar) und entsprechend bewährt. Man unterschätzt dabei jedoch oft die Herausforderungen, denen man sich bei der Einführung einer zentralen Protokollierung stellen muss.
Herausforderung 1: Verantwortlichkeit
Wer ist verantwortlich für die zentrale Protokollierungslösung und wer kümmert sich um systemübergreifende Dashboards und entsprechende Analysen? Falls bereits eine Organisationseinheit für das zentrale IT-Monitoring besteht, könnte die Protokollierungslösung hier angesiedelt werden. Genauso ist es denkbar, dass sich die Partei, die für die operative Informationssicherheit verantwortlich ist, auch um die Protokollierungslösung kümmert.
Herausforderung 2: IT-Integration der Protokollierungslösung selbst
Eine zentrale Protokollierungslösung hat in der Regel einen hohen Schutzbedarf hinsichtlich Vertraulichkeit und Integrität der Daten und muss daher entsprechend abgesichert werden. Eine typische Maßnahme ist hier, dass die Server der Protokollierungslösung einer ggf. dedizierten Sicherheitszone zugeordnet werden und die Kommunikation durch eine Firewall gefiltert wird. Dies hätte zunächst die Folge, dass für jedes IT-System, das seine Event-Logs der Protokollierungslösung bereitstellen möchte, eine Freischaltung an der Firewall vorgenommen werden müsste. Außerdem muss berücksichtigt werden, dass an der Firewall nun eine erhöhte Last zu bewältigen ist.
Nehmen wiran, dass Systeme aus einer Internet-DMZ unter Verwendung von Syslog (als standardisiertes Protokoll zur Übertragung der Event-Logs) in die zentrale Protokollierung aufgenommen werden sollen. Dabei würden die DMZ-Systeme Syslog-Nachrichten unmittelbar an den Protokollierungsserver schicken, d.h. ein direkter IP-basierter Zugriff vom DMZ-Bereich auf ein schützenswertes internes System würde stattfinden. Das widerspricht aber gängigen Sicherheitsanforderungen, die hier statt eines Push aus dem DMZ-Bereich auf den Protokollierungsserver ein Pull vom Protokollierungsserver fordern. Es müsste also eine Ausnahmegenehmigung in Verbindung mit der Durchführung einer Risikobetrachtung eingeholt werden.
Daher arbeitet man hier gerne mit vorgeschalteten Satellitensystemen (Kollektoren oder Log-Forwarder) und nur noch für diese Systeme müssten Freischaltungen vorgenommen werden. Sofern es von der Protokollierungslösung unterstützt wird, kann hier dann auch das beschriebene Pull-Prinzip realisiert werden.
Herausforderung 3: Anbindung der IT-Landschaft an die zentrale Protokollierung
Wer entscheidet, ob eine Anwendung oder ein IT-System in die zentrale Protokollierung aufgenommen werden soll und welche Daten dann auch protokolliert werden sollen? Hier müssen die jeweiligen Anwendungs- bzw. Systemverantwortlichen mit der Informationssicherheit zusammenarbeiten, und je nach Inhalt der Protokolle müssen dabei auch der Datenschutzbeauftragte und der Betriebs- oder Personalrat konsultiert werden.
In diesem Zusammenhang ist auch zu klären, wie die Anbindung an die zentrale Protokollierung erfolgen soll. Manche Systeme unterstützen beispielsweise nicht Syslog und es kann sogar eine zusätzliche spezielle Software (ggf. als Agent auf dem System) zur Anbindung an die Protokollierungslösung erforderlich sein.
Außerdem muss berücksichtigt werden, dass die Aktivierung einer Protokollierung auf einem IT-System die Performance des Systems möglicherweise deutlich reduzieren kann.
Für ein einzelnes System mögen diese Festlegungen und Betrachtungen noch überschaubar sein, in Summe ist der Aufwand bei der Vielzahl der Anwendungen und Systeme in der IT jedoch erheblich. Insbesondere wird bereits an dieser Stelle deutlich, dass Protokollierung ein Querschnittsthema ist, für das die gesamte IT einen Beitrag leisten muss.
Hier wird auch ein anderer Problembereich deutlich: Bei der Beschaffung einer Protokollierungslösung weiß man oft noch nicht genau genug, wie viele Anwendungen und IT-Systeme in die zentrale Protokollierung aufgenommen werden sollen, mit wie vielen Ereignissen pro Sekunde zu rechnen ist, wie groß das Log-Volumen ist und wie lange Logs vorgehalten werden sollen. Für die Dimensionierung verwendet man also meist Schätzwerte. Es kann vorkommen, dass man früher als erwartet beispielsweise den Storage oder die Lizenzen erweitern muss.
Herausforderung 4: Zugriff auf Protokolle
Es muss geregelt werden, wer unter welchen Bedingungen einen Zugriff auf die protokollierten Daten erhalten darf.
Zunächst werden Mitarbeiter aus den Bereichen IT-Monitoring und der operativen Informationssicherheit Zugriffe benötigen, um sich über Dashboards ein Lagebild zu verschaffen und um bei einem (Security-)Incident Ursachenforschung zu betreiben. Diese Mitarbeiter haben damit einen tiefen Einblick in alle (Problem-)Bereiche der IT. Es ist klar, dass die Zugriffsmöglichkeiten mit Datenschutz und Betriebs- bzw. Personalrat abgestimmt sein müssen.
Auch die Teams, die die Anwendungen und IT-Systeme selber betreiben, werden auf Log-Daten zugreifen wollen. Folgendes Beispiel illustriert ein mögliches Problem dabei: Im Team für eine Web-Anwendung wird ein Fehler analysiert, und hierzu wird ein Zugriff auf die zentralen Logs der Web-Anwendung bereitgestellt. Dabei wird vom Team festgestellt, dass die zugrunde liegende Datenbank, die auch von anderen Anwendungen genutzt wird, ein Problem hat. Darf das Team dann ohne weiteres auf die Event-Logs der Datenbank zugreifen, die dann ja auch Informationen aus den anderen Anwendungen und von administrativen Zugriffen beinhalten?
Es müssen also entsprechende Festlegungen im Rollen- und Berechtigungskonzept für die zentrale Protokollierung gemacht werden.
Fazit
Für eine erfolgreiche Einführung und einen nachhaltigen Nutzen braucht man eine langfristige Strategie, die einen schrittweisen Aufbau der zentralen Protokollierung ermöglicht und so verhindert, dass man sich am Anfang überhebt. Beispielsweise könnte der erste Schritt darin bestehen, zunächst eine zentrale Protokollierung für den DMZ-Bereich einzuführen, um dann in einem zweiten Schritt kritische interne Systeme zu berücksichtigen und dann in späteren Schritten in die Breite zu gehen. Wesentliche Grundlagen sind dabei ein umfassendes Protokollierungskonzept und entsprechende Regelungen und Prozesse.
Protokollierung ist eben eine typische Querschnittsfunktion, die naturgemäß schwer in einer Linienorganisation untergebracht werden kann, da einerseits eine zentrale Verantwortung für Betrieb und Nutzung der Protokollierungslösung benötigt wird, sich aber andererseits die gesamte IT aktiv beteiligen muss.
Verweise
[1] https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/itgrundschutzKompendium_node.html
