Über den Umgang mit der Logfile-Flut
Log(i(sti)sche) Herausforderungen
Die Ausrüstung moderner Unternehmensnetze mit Security-Systemen hat mittlerweile einen guten Stand erreicht. Was die Sensoren der Sicherheits-Tools, Anwendungen, Datenbanken und Netzwerkgeräte an Logs und Informationen bereitstellen, könnte auch bei der schnellen Erkennung und Abwehr von ausgefuchsten gezielten Angriffen helfen. Aber die permanente Auswertung der Security-Daten ist aufwändig und teuer. Was hilft aus diesen Dilemma?
Der "Hack" des Senders TV5 Monde im April war ein Paradebeispiel für einen gezielte Angriff. "Gezielt" meint dabei nicht nur, dass die Angreifer wahrscheinlich die für Medienunternehmen typische Offenheit ihrer IT-Landschaften mit vielen Schnittstellen zur Außenwelt und eine eventuell eher sorglose Haltung der Mitarbeiter ausgenutzt haben [1, 2]. "Gezielt" heißt hier vor allem: "auf das Business des Opfers zugeschnitten". Hier wurden nämlich keine Daten gestohlen, sondern die Dienstleistungen des Unternehmens missbraucht.
Gezielte Angriffe treffen ins Mark
Mich interessiert, warum derartige Attacken ihre Opfer überraschen. Auf strategisch-theoretischer Ebene befasst sich die Sicherheitsbranche durchaus schon mit entsprechenden Fällen. Man hat erkannt, dass die Ausstattung der Organisationen mit präventiven IT-Sicherheitssystemen kaum noch signifikant zu verbessern ist. Verschlüsselung, Netzwerksicherheit, Applikationssicherheit und Zugangs- sowie Zugriffsschutz erfüllen ihren Zweck. All diese Maßnahmen helfen aber niemals zu hundert Prozent gegen Angreifer, die sich aus kriminellen oder weltanschaulichen Gründen eine mitunter monatelange Analyse von Technik, Organisation und menschlichem Verhalten in einem Unternehmen leisten und dann Social Engineers sowie Hacker einsetzen, um auf kreative Weise zum Ziel vorzurücken.
Die Ungleichheit der Chancen zwischen Angreifern und Opfern lässt sich wohl nur noch durch eine adäquate Perfektion der reaktiven Sicherheit zugunsten der "Guten" verschieben. Die Zaubermittel, um die es hier geht, heißen "Korrelation von Security-Informationen" und "schnelle Reaktion (Threat Response)". Wie schon angedeutet, beschränken sich die gefährlichsten Cyberkriminellen heute gerade nicht auf nur einen Angriffsvektor. Ein kleiner Hack hier, ein Stöbern in einer Datenbank dort, ein manipulativer Anruf bei einem Entwickler, dann vielleicht ein getarnter "Hausbesuch" mit Griff in die Mülltonne und schließlich ein weiterer vorsichtiger Hack - Profis halten ihre Einzelschritte möglichst so weit unter dem Radar der einzelnen Sicherheitssensoren im Netz, dass die damit verbundenen Security-Events nirgendwo einen Alarm auslösen, sondern im Grundrauschen der alltäglichen bösartigen Aktivitäten untergehen.
Menschen, die auf Logfiles starren
Wäre man allerdings in der Lage, die kleinen Anomalien aufeinander zu beziehen, die keinen der implementierten Sensoren für sich anschlagen lassen, könnte man einen konzertierten Angriff eventuell wahrnehmen, auch wenn man das dahinter versteckte logische Vorgehen noch nicht kennt. Der gemeinsame Nenner, der einen "Blended Threat" (einen konzertierten Mehrvektor-Angriff) verraten kann, ist das "Asset" - das Ziel im Unternehmen, um das die Attacke kreist. Im obigen Beispiel würden sich die Hacks, der Anruf, das Auftauchen im Gebäude und so weiter zwangsläufig um die technischen Ziele oder die Informationen herum gruppieren, die lahmgelegt, missbraucht oder gestohlen werden sollen. Zumindest auf der technischen Ebene, die neben dem IT-Equipment mit Hard- und Software heute meist auch die Zutrittssicherungen für Gebäude erfasst, könnte man dies anhand der permanenten Analyse der Log-Files aller Security- und Netzwerkgeräte und einiger Traffic-Informationen aufdecken.
Genau dies allerdings schaffen derzeit nur wenige Organisationen. Wenn es überhaupt einen zentralen Log-Server (Syslog etc.) gibt, der sicherheitsrelevante Informationen aufgreift, erfasst er nur selten wirklich alle Logs - und dass die Daten gesammelt werden, heißt noch lange nicht, dass irgendjemand sie permanent auswertet. Dazu fehlt es oft an entsprechend ausgebildetem Personal.
Problem Fachkenntnismangel
Allein das Wort "ausgebildet" hat hier wiederum zwei Seiten. Will man Logs manuell auf Anomalien durchsuchen, muss man nicht nur profunde Fachkenntnisse aufweisen und fortwährend die Entwicklungen auf dem Angriffssektor im Blick behalten, sondern auch in der Lage sein, im Wust der immer gleichen Log-Informationen die wenigen Anomalien überhaupt zu entdecken. Evolutionsbedingt ist das menschliche Gehirn aber nicht auf das Erkennen von (geringen) Abweichungen in einer Gesamtheit hin optimiert, sondern aufs Wiedererentdecken von Mustern im Unübersichtlichen [3]. Erst langes Training schärft die Sinne für Anomalien, etwa bei Code-Analysten und Lektoren. Aber auch ein entsprechend geübter Spezialist ermüdet immer noch schnell, wenn er permanent auf gleichförmig duchrauschende Informationen starrt.
Manuelle Log-Auswertung ist aus diesen Gründen aufgrund von Personalkosten teuer und aufgrund der mangelnden menschlichen Eignung für die notwendigerweise einzuhaltende "Betriebsart" fehlerträchtig und ineffizient. Hinzu kommt, dass die Logs von Legacy-Systemen oder historisch separierten Systemen häufg in isolierten Repositories gesammelt und von gesondertem Personal ausgewertet werden. Die "Silos" schneiden dann wichtige Bereiche einer IT-Infrastruktur wieder von der zeitnahen Gesamtkorrelation ab und machen es Hackern leicht, weiter Versteck zu spielen.
SIEM filtert vor
Deshalb setzen manche Unternehmen bereits SIEM-Systeme (Security-Information- und Event-Management) ein. Diese sammeln Log- und Traffic-Daten aus möglichst vielen (allerdings bisher nur "technischen" [4]) Quellen und schaffen bereits heute eine rudimentär "intelligente" Vorfilterung durch Korrelation. Das beliebte Standardbeispiel ist der Alarm, den solch ein System auslöst, wenn sich derselbe Mitarbeiter eines Unternehmens um 5.30 Uhr in Hamburg in eine Workstation einloggt und um 5.35 Uhr in München versucht, ein Rechenzentrum zu betreten. Solch simple, aber ermüdungsfreie Logik ist genau das Gebiet, in dem technische Systeme dieser Art Schwächen des Menschen optimal ausgleichen können. Ober besser gesagt: könnten, denn SIEM-Implementierungen sind ebenfalls teuer. Zwar bringen einige Systeme bereits Korrelationsregeln für bekannte konzertierte Angriffstricks mit und werden in dieser Hinsicht von ihren Herstellern auf ähnliche Weise aktuell gehalten wie Virenschutz- und Intrusion-Prevention-Produkte, aber die Feinheiten einer Asset-bezogenen Beziehungslogik muss der Anwender den Produkten erst müsam durch den Bau kundenspezifischer Regeln beibringen. Genau deshalb sind die Investitionen in digitale Log-Korrelation vor allem zu Beginn einer Implementierung ebenfalls recht hoch.
Dennoch werden die meisten größeren Unternehmen um diesen Schritt wohl nicht herumkommen. Wenn ein Unternehmen beispielsweise mit 80 verschiedenen Security-Systemen von 35 Herstellern operiert (reale Zahlen aus einer IBM-Erhebung [5]), hat es kaum eine Chance, mit manuellen Kontrollen die Übersicht zu behalten. Die Logdaten selbst können schnell die "Big Data"-Schwelle erreichen, internationale Konzerne etwa landen ohne Weiteres schon einmal bei Werten von über 500 GByte pro Tag.
Das Dumme ist nur, dass für die Reaktion auf Alarme das Umgekehrte gilt wie für das permanente Auswerten der Log-Daten: Hier sind Maschinen überfordert und Menschen die besseren Operateure. Auch dafür ein Beispiel: Ein Unternehmen einer beliebigen Branche hat jahrelang an der Entwicklung eines streng geheimen Produkts gearbeitet und möchte es nun endlich auf einer bedeutenden Messe präsentieren. Kurz vor dem großen Ereignis könnte es einem SIEM-System auffallen, das nächtliches Einloggen an Entwicklungsdatenbanken durch Personen zunimmt, die dort sonst eher selten zu Gast sind. Auch Anmeldefehler treten häufiger auf. Schließlich beginnen tief in der Nacht Personen im großen Stil mit der Übermittlung von Daten, die zum Teil als vertraulich eingestuft sind, an bisher nie kontaktierte Adressaten.
Automatismen haben Grenzen
Ein automatisch vorgehendes System könnte hier kaum anders reagieren als mit der blitzschnellen Isolation der betroffenen Datenspeicher. Ein menschlicher Operator, der sein Unternehmen kennt, wüsste demgegenüber selbst ohne ausdrückliche Benachrichtigung durch die Firmenleitung von der bevorstehenden Messe, hätte über das Engagement einer neuen Werbeagentur in der Hauszeitung gelesen, dürfte sich über die übernächtigt dreinblickenden Gestalten aus dem Marketing vielleicht schon beim Mittagessen amüsiert haben und wäre über eine Zunahme von Fehleingaben zwischen Dämmerung und Morgengrauen deshalb nicht überrascht, wenn sie aus dieser Abteilung kämen. Außerdem wäre ihm vermutlich klar, dass die Dokumentenklassifikation die fällige Umbuchung von "geheim" zu "veröffentlichungsreif" nicht für alle Informationen aus dem Produktbereich schnell genug bewältigen kann. Er würde deshalb wahrscheinlich nicht sofort radikal eingreifen und so den Messeauftritt seines Arbeitgebers ruinieren, sondern vorher zumindest versuchen, die Marketing-Kollegen telefonisch zu erreichen.
Korrelation, wie es sie mittlerweile sogar schon speziell für Mobilumgebungen gibt [6], ist somit nur die eine Seite der Perfektionierung in der Logauswertung. Angemessene Reaktion ist die andere. Versuchen Hacker etwa, einen Betreiber kritischer Infrastrukturen lahmzulegen, kann es sogar sinnvoll sein, zentrale IT-Services einem direkten Angriff zum Trotz am Netz zu halten, weil eine radikale Sicherheitsreaktion größere Schäden nach sich ziehen würde als der Angriff selbst.
Entsprechende Entscheidungen vermögen aber nur Menschen zu treffen, die einerseits große Erfahrung mit solchen Angriffsformen haben und andererseits viel über das Business des Opfers, die Nebenwirkungen bestimmter Vorgehensweisen auf seine Produktivtechnik und die Folgen von Service-Unterbrechungen wissen. Wirklich gut bewältigen diese Aufgabe nur interdisziplinäre Sicherheitsteams [7], die sich ihren Job teuer bezahlen lassen. Die Reaktion auf unerwartete Security-Ereignisse ist das, was in Security Operation Centern (SOCs) stattfindet: Threat Response.
Kein "billiger" Ausweg in Sicht
Unternehmen müssen also erkennen, dass sie eine bessere Abwehr gezielter Angriffe nur durch professionelles Log-Management erreichen. Dieses Unterfangen gelingt nicht ohne die Allokation beträchtlicher Mittel und gute Planung. Log-Management "nebenbei" funktioniert nicht.
Ein Verzicht auf Weiterentwicklung in diesem Sektor ist aus Compliance- und Risiko-Management-Sicht allerdings längst keine echte Option mehr. Außerdem ist entsprechende Ignoranz auch in sich unbefriedigend, weil die Informationen, die man zur rechtzeitigen Aufdeckung von Blended Threats einsetzen kann, den Unternehmen in Form der Logs ja schon zur Verfügung stehen. Sie einfach einzusammeln, ohne etwas aus ihnen zu machen, bedeutet mangelnde Nutzung der bereits getätigten Investitionen.
Für manche Organisationen mag teilweises Outsourcing der geschilderten Aufgaben eine gute Option sein: "Managed SIEM" und "externes SOC". Ein externer Betrieb durch Dienstleister reduziert die Implementierungskosten für ein eigenes SIEM und gewährt Zugang zu flexibel in der Leistung anpassbaren Systemen. Es holt außerdem spezialisierte, erfahrene "Incident-Jäger" ins Boot, die auf Wunsch rund um die Uhr zur Verfügung stehen - bei guten Anbietern auch aus rein europäischen SOCs heraus.
Die Einschränkung "teilweise" ist hier aber sehr ernst zu nehmen: Weniger bei der eigentlichen Log- und Traffic-Überwachung, aber um so mehr bei der Reaktion auf plötzliche Angriffe ist immer eine Abstimmung zwischen den Security-Profis beim SOC-Betreiber und Business-Insidern aus den Fachabteilungen nötig, um die möglichen Nebenwirkungen von Sicherheitsentscheidungen einzuschätzen und gering zu halten. Komplettes Outsourcing dürfte deshalb ebenfalls nur selten gelingen, und für den Einstieg benötigt man kompetente Beratung. Gutes Log-Management ist eine Aufgabe, deren Bedeutung zunimmt und der keine Institution entgeht.
Lesen Sie mehr zum Thema
