All About Security

18.11.2010 Risiko- & Kontinuitätsmanagement, Security-Management, Fachartikel

Live Analyse im Rahmen der Sicherheitsvorfallbehandlung

Nicht jeder Sicherheitsvorfall ist auf den ersten Blick als solcher zu erkennen. Viele Sicherheitsvorfälle, insbesondere wenn es sich um gezielte vorsätzliche Angriffe auf IT-Systeme handelt, fallen erst nach Tagen oder Wochen auf. Die Herausforderung für die Systemverantwortlichen besteht nun darin, eine betriebliche Störung von einer sicherheitsrelevanten Unregelmäßigkeit zu unterscheiden. Hinweise hierzu gibt der nachfolgende Artikel.

Klassische Verdachtsmomente für eine Manipulation durch Unbefugte wären etwa, wenn der Administrator unbekannte Prozesse oder Benutzer entdeckt. Auch das Vorhandensein unbekannter Dateien oder Verzeichnisse - womöglich an unüblichen Stellen oder mit ungewöhnlichen Rechten versehen - sollte stutzig machen. Verdächtig wäre ebenso eine nicht erklärbare hohe Systemlast, das plötzliche Nichtfunktionieren oder langsamer werden von Diensten oder ungewöhnliche Anmeldungen an Systemen. Intrusion-Detection-Systeme können weitere Hinweise auf Angriffe liefern. Neben diesen sichtbaren Indizien ist aber auch das Fehlen von erwarteten Dateien oder Konfigurationen verdächtig, indiziert es doch grundsätzlich eine ungewöhnliche Veränderung des Systems. Der denkbar ungünstigste Fall ist das Bekanntwerden eines Sicherheitsvorfalls durch Information von externen Dritten, da hier in vielen Fällen ein Reputationsschaden entsteht.

Nach dem Erkennen einer sicherheitsrelevanten Unregelmäßigkeit müssen die Verantwortlichen zunächst entscheiden, ob es sich um einen Sicherheitsvorfall mit eventuell zu erwartenden größeren Schäden handelt. Entscheidungsgrundlage hierfür ist die klare Definition eines Sicherheitsvorfalls innerhalb der Organisation. Wie nach dem Feststellen eines Sicherheitsvorfalls weiter vorzugehen ist, sollte in einer Richtlinie zur Behandlung von Sicherheitsvorfällen dokumentiert sein. Darin ist zu regeln, bei welchem Ereignis welche Schritte einzuleiten sind, wer gemäß der Meldewege wann und durch wen zu alarmieren ist und wer welche Verantwortlichkeiten hat. Denn bei Auftreten eines Sicherheitsvorfalls ist es in der Regel zu spät, sich darüber Gedanken zu machen. Dann ist Reagieren gefragt. Bei der Reaktion auf einen Sicherheitsvorfall – im Fachjargon: Incident Response – sind die Betroffenen in vielen Fällen vorerst auf sich alleine gestellt. Dies gilt insbesondere für Organisationen mit verteilten Standorten, an denen in den ersten Stunden nach Bekanntwerden des Vorfalls nicht immer ein Expertenteam oder externe Sicherheitsspezialisten für dessen Behandlung verfügbar sein können. In diesen Fällen muss sich vertrauenswürdiges Sicherheitspersonal vor Ort mit der Sicherung der Beweismittel beschäftigen. Das setzt voraus, dass die verantwortlichen Mitarbeiter die Methoden und Werkzeuge zur Behandlung von Sicherheitsvorfallen kennen und deren Einsatz beherrschen. Die Durchführung der notwendigen Maßnahmen zur Behebung von Sicherheitsvorfällen erfolgt meist unter Zeitdruck. Falsche Reaktionen können aber noch zur Verschlimmerung der Situation beitragen, etwa indem man durch überhastete Entscheidungen versehentlich Daten löscht, die eventuell beweiskräftig gewesen wären. Das gilt insbesondere für die Tätigkeiten am aktiven, nicht ausgeschalteten System - während der sogenannten Live Analyse. In einer solchen Situation ist es alles andere als einfach, die Nerven zu bewahren und mit Bedacht vorzugehen.

Flüchtige Daten einsammeln

Bei Verdacht auf einen Sicherheitsvorfall wird in der Regel versucht, mit Bordmitteln - anhand der Prozessliste des Windows Task Managers etc. - zu überprüfen, ob dieser sich bestätigt. Damit wird allerdings der Zustand des Systems schon verändert und unter Umständen Beweisspuren des Delikts zerstört. Des Weiteren muss sich die handelnde Person bewusst sein, dass die systemeigenen Werkzeuge im Rahmen des Einbruchs manipuliert worden sein könnten. Sie könnten bei der Datenwiedergabe Spuren des Einbruchs vor den Augen der handelnden Person verbergen, aber auch Spuren - im schlimmsten Fall Datenbestände - löschen. Sie sind daher nicht mehr als vertrauenswürdig einzustufen und ihre Verwendung ist unbedingt zu vermeiden.

Im Falle eines begründeten Verdachtsmoments ist es daher sinnvoll, grundsätzlich von einem Einbruch respektive einem Sicherheitsvorfall auszugehen und vor allen weiteren Untersuchungen zunächst sämtliche flüchtigen Daten zu sichern, die nach dem Ausschalten des betroffenen Systems nicht mehr verfügbar wären. Die Tragweite eines Sicherheitsvorfalls wird in vielen Fällen erst im weiteren Verlauf der Ermittlungen deutlich. Glücklich, wer da auf die flüchtigen Daten aus der Live Analyse zurückgreifen kann. Zwei Dinge sind bei der Live Analyse vor allem wichtig: Man muss die flüchtigen Daten des verdächtigen Systems schnellstmöglich sicherstellen und dabei den Zustand des Systems so wenig wie möglich verändern. Das aus der klassischen forensischen Wissenschaft bekannte und von Edmund Locard formulierte Austauschprinzip (Locard’s Exchange Principle) „Jeder und alles am Tatort nimmt etwas mit und lässt etwas zurück“ ist ebenfalls auf die Computerforensik und konkret auf die Live Analyse anwendbar. So resultieren aus den erforderlichen Tätigkeiten in der Regel auch Veränderungen des Systemzustands. Umso wichtiger ist es, alle durchgeführten Handgriffe ausführlich und nachvollziehbar zu protokollieren. Es beginnt und endet mit der Bestimmung der Systemzeit, womit die Zeitspanne der Live Analyse festgehalten und zu den restlichen Geschehnissen auf dem verdächtigen System abgegrenzt ist. Für die zeitliche Korrelation der sichergestellten Daten von weiteren Systemen, die für die Aufklärung des Sicherheitsvorfalls relevant sind, müssen die Zeitdifferenzen aller beteiligten Systeme zu einer Referenzzeit ermittelt werden. Es kann auch keinesfalls schaden, einen Kollegen zu bitten, bei der folgenden Beweissicherung als Zeuge zu fungieren.

Die Sicherungsreihenfolge der flüchtigen Daten ist durch deren Halbwertszeit bestimmt. Begonnen wird nach Ermittlung der Systemzeit immer mit den flüchtigsten Informationen. Werkzeuge für das Sichern dieser Daten sind das Minimum, das in die Toolbox eines Ermittlers gehört. Die Werkzeuge des verdächtigen Systems sind für die Live Analyse tabu. Folglich muss sich der Ermittler die Toolbox aus Werkzeugen aufbauen, die aus vertrauenswürdigen Quellen stammen. Dabei ist insbesondere darauf zu achten, dass die Werkzeuge statisch gelinkt sind. Tools, die für die Sicherung der flüchtigen Daten Systembibliotheken verwenden oder mit ihnen wunderschöne GUI s hervorzaubern, sollte man nicht einsetzen. Die Verwendung von Kommandozeilen-Tools erleichtert außerdem die erforderliche Dokumentation, da sich die Ergebnisse unkompliziert in Berichte integrieren lassen. Das manuelle Aufrufen der Incident- Response-Tools ist aufgrund der Vielzahl an Parametern fehlerträchtig und kostet wertvolle Zeit. Denn auch ein laufendes System, mit dem nicht direkt interagiert wird, verändert sich unentwegt und zerstört dabei womöglich Daten, die für die Aufklärung des Sachverhaltes relevant sein könnten. Das Ziel ist also eine zeitnahe, zügige, reproduzier- und vergleichbare Herangehensweise bei der Beweismittelsicherung.

Automatisierung

Einen großen Schritt näher kommt man diesem Ziel, wenn die Werkzeuge automatisiert und mit gleichbleibenden Parametern aufgerufen werden. Diesen Ansatz verfolgen Incident-Response-Toolkits - Skripte, die die Werkzeuge entsprechend der Halbwertszeit der zu sichernden Informationen und mit geeigneten Parametern aufrufen. Auf dem Markt sind verschiedene Incident-Response-Toolkits - kommerziell und frei - verfügbar, die sich im Wesentlichen in Konfiguration, Bedienkomfort und Präsentation der Ergebnisse unterscheiden. Die zugrunde liegenden Werkzeuge sind in der Regel ähnlich und lassen sich erweitern. Das Windows Forensic Toolchest hebt sich durch seine umfangreichen und sinnvoll aufgebauten HTML-Reports sowie den interaktiven Modus und die Möglichkeit, Werkzeuge, die das Incident Response Skript benötigt, aus dem Internet herunterzuladen, von den freien Toolkits ab. Für den Profi sind die Werkzeuge auch manuell aufrufbar, etwa um bestimmte Parameter zu ändern oder einzelne Untersuchungen zu wiederholen oder zu überprüfen. Die Ergebnisse der Live Analyse sollten nie auf die Datenträger des zu untersuchenden Systems geschrieben werden, da dadurch potenziell beweiskräftige Daten im freien Speicher überschrieben werden könnten. Das Abbild des Hauptspeichers allein belegt auf aktuellen Systemen mehrere Gigabyte. Vielmehr sollte man die Ergebnisse über das Netzwerk auf ein Analysesystem übertragen oder auf einen leeren externen Datenträger speichern.

Selbst wenn man keine professionelle Spürnase ist und selten in die Verlegenheit kommt, Beweise sammeln zu müssen, lohnt es sich, eine solche Werkzeugsammlung vorzuhalten. Denn erstens steht der Betroffene in einer Einbruchssituation wie erwähnt unter Zeitdruck und findet in der Hektik keine passenden Werkzeuge, schon gar nicht auf verschiedenen externen Datenträgern.

Zweitens sollte man sich beizeiten mit den Werkzeugen befassen und sie ausgiebig ausprobieren, damit man im Ernstfall nicht ins kalte Wasser springt und wertvolle Zeit verliert. Damit der Ermittler die Ergebnisse korrekt interpretiert und die richtigen Schlüsse zieht, sollte er die Eigenheiten und Grenzen der eingesetzten Werkzeuge unbedingt kennen und die Ergebnisse eines Untersuchungsdurchgangs immer mit einem zweiten Werkzeug oder gar weiteren Tools verifizieren. Die Ergebnisse können aus vielerlei Gründen verschieden und durchaus aussagekräftig sein. Sinnvoll ist diese Maßnahme besonders auch in Hinblick auf sogenannte antiforensische Techniken, mit denen ein Einbrecher seine Spuren zu verwischen sucht. Denn dieser kennt die Schwächen der gegnerischen Werkzeuge und macht sie sich zunutze. Ein Ermittler, der die Schwächen ebenfalls kennt und die Ergebnisse mit alternativen Werkzeugen überprüft, ist hier klar im Vorteil.

<< Erste < Vorherige 1 2 Nächste > Letzte >>

Diesen Artikel empfehlen

Autor: Sebastian Krause