- Der Einsatz von Forensik
- Wo finde ich gesicherte Informationen und wann können sie als gesichert gelten, so dass diese als Baseline dienen können?
Im ersten Beitrag haben wir die führenden Open Source Anwendungen, die den unterschiedlichen Bedarf im Markt abdecken und mit deren Hilfe Digital Forensics and Incident Repsonse – zu Deutsch Digitale Forensik und Reaktion auf Vorfälle – Informationen über die Komponenten einer Infrastruktur oder einem einzelnen System gesammelt werden und von Security Experten für tiefgehende Untersuchungen eines Vorfalls verwendet werden.
In diesem Beitrag findet sich eine Hilfestellung wie die Effektivität der Anwendungen und die Analyse robuster und detaillierter in ihrer Aussagekraft werden und gegebenenfalls auch in kürzere Zeit durchgeführt werden kann, in dem verschiedene unterstützende Massnahmen und Verhaltensweisen im Unternehmen etabliert und verwendet werden und was der Fachbereich und die IT Organisation für eine möglichst effektive Integration und Nutzung berücksichtigen sollte. Bevor aber im dritten Teil die Verwendung der Anwendungen vorgestellt wird, gibt es zuvor einen kleinen Exkurs in die typischen Probleme, die sich um das Thema gesicherte Informationen über das Verhalten einer Anwendung oder Dienste ranken.
Der Einsatz von Forensik
Üblicherweise kommen forensische Techniken erst nach einem Vorfall zum Einsatz. Die Verwendung erfordert eine sehr durchdachte und gut geplante Vorgehensweise zur Sicherung von Beweisen und hohe Genauigkeit bei der Durchführung der Arbeiten. Da sich schon in der Frühzeit, noch vor dem Aufkommen des Incident Response Management als Bestandteil von ITIL, vor allem in der bei einem Vorfall notwendigen post mortem Analyse gezeigt hat, dass häufig sehr tiefgreifende Untersuchung notwendig sind, um einen Fehler oder Manipulation zu finden und den sicheren und vertrauenswürdigen Betrieb der betroffenen Anwendung oder des Dienstes wiederaufnehmen zu können, drängte sich die Kombination aus forensischen Techniken und der Reaktion auf eine Vorfall geradezu auf. Dabei lässt sich mittels geeigneten Digital Forensics Anwendungen oder Frameworks die Dokumentation eines Incident Response Eintrag gut durch entsprechende Automatismen anreichern.
Diese post mortem Analyse nach einem IT Sicherheitsvorfall wird benötigt, um den Rechenschaftspflichten in Form der Dokumentation des Vorfalls nachzukommen als auch um die Wiederherstellung der Anwendung oder Dienste sicherzustellen. Dabei wird mit Hilfe von Digitaler Forensik diese Analyse untermauert.
Typische zu untersuchende forensischen Datenquellen und Artefakte:
- Vollständige Disc-Images
- Forensik des Arbeitsspeicher
- Forensik des Dateisystems
- Forensik des Betriebssystems
- Forensik des Verhaltens einer Anwendung
- Netzwerkforensik
In der Regel wird mit der forensischen Untersuchung von Sicherheitsvorfällen bei Null angefangen. Während eine Abteilung mit einem Sicherheitsbeauftragten und ihn unterstützende und mit entsprechendem Fachwissen ausgestattete Mitarbeiter vorhanden sind und häufig auch Sicherheitstechnisches Fachwissen unter den Mitarbeitern der IT Betriebsorganisation verfügbar ist – ein Forensik-Experte befindet sich meist nicht im Mitarbeiterstamm und wird daher von aussen herangezogen.
Die Unternehmensführung hat bei der Beauftragung eines Forensik-Experten in der Regel die Beantwortung von solche Fragen: wie konnte in das System eingebrochen werden. Wer ist der Täter? Welche Ziele hat der Einbruch verfolgt? Sind Daten entwendete worden? im Fokus. Die IT Organisation hat den Fokus eher auf die erste und dritte Frage gerichtet und als zudem: was wurde kompromittiert? Gibt es Anzeichen das Daten entwendet wurden? Sind Konfigurationen verändert worden? Wurden Hintertüren etabliert? Gibt es weitere verdächtige Aktivitäten? Welche Zugänge sind kompromittiert? Sind die Netze abgeschottet worden? Wurde der Zugang von aussen in die Infrastruktur blockiert? und viele weiter Fragen.
Die Forensik beginnt häufig ganz am Anfang mit seinen Untersuchung (quasi bei Null) damit, die oben erwähnten Datenquellen auf typische Merkmale einer Malware oder einer anderen Art von Kompromittierung zu untersuchen. Dazu werden je nach Grad der Spezialisierung der Anwendung oder Dienste Antworten auf spezifische Fragen benötigt. Diese Fragen zu beispielsweise der Verhaltensweise des Dienste oder Anwendung muss dann mit Informationen aus der Kreis der Fachleute im Unternehmen beantwortet werden oder, sofern vorhanden, aus Anwendungsdokumentation des Herstellers und ergänzt mit Informationen aus dem Betriebshandbuch des Dienstes oder der Anwendung erstellt durch die IT Organisation.
Das birgt eine Reihe von Nachteilen:
- Es wird Personal gebunden, das mit der Beschaffung von Informationen beauftragt wird.
- Dieses Vorgehen ist zeitaufwändig.
- Die IT Dokumentation muss einer regelmässigen Prüfung unterzogen worden sein, damit die Inhalte als gesichert Korrekt angesehen werden können.
- Die IT Dokumentation ist häufig an verschiedenen Orten verteilt und es fehlt eine Übersicht wer, wo, welche Dokumentation pflegt.
- Mitarbeiter als auch Experten des Herstellers eine Anwendung müssen im Zugriff sein.
- Auf Grund von Unklarheiten wird versucht – sofern vorhanden – an einem anderen System oder Dienst die Verhaltensweise zu beobachten und mit dem Vorfall zu vergleichen.
- Bei „exotischen“ Anwendungen oder begleitende Komponenten, die zur Bereitstellung eines Dienstes eingesetzt werden, fehlen häufig Erfahrungswerte oder gesicherte Kenntnisse über Verhaltensweisen oder warum eine Konfiguration genauso durchgeführt wie sie vorgefunden wurde.
Diese Liste lässt sich beliebig lang fortführen. Daher ist unser Ansatz aufzuzeigen, welche begleitenden Massnahmen vor allen die Dauer der Untersuchungen positiv beeinflussen und somit schneller das Vertrauen in einen sicheren Dienst wiederherstellen können.
Wo finde ich gesicherte Informationen und wann können sie als gesichert gelten, so dass diese als Baseline dienen können?
Die Erfahrung zeigt, und das gilt nicht nur für die post mortem Analyse nach einem Sicherheitsvorfall, sondern auch ganz allgemein sollte eine Baseline geschaffen und dokumentiert werden. Damit ist die Dokumentation gemeint, wie sich eine Anwendung oder Dienst nach der Installation und Implementation der Konfiguration in und aller beteiligten Komponenten verhält – also das Betriebshandbuch. Dieses liegt im Idealfall an eine Ort, der im Unternehmen als der Platz der gesammelten Dokumentation bekannt ist.
Vielfach wird sich der eine oder andere Leser fragen: Wieso? Die ist doch vorhanden. Und ja, das stimmt vielfach auch – in Teilen! Sie existiert in Form von Dokumentation zu Installation und Betrieb und Wartung. Sie ist manchmal im Handbuch des Herstellers häufig in allgemeiner Form im Kapitel unter Fehlersuch beschrieben. Es gibt in grösseren IT Organisation auch Lösungen zur Orchestrierung von automatischen Deployments und allgemeinen Konfiguration von Servern und Software. Auch Dienst wie IDM / IAM und Monitoring Lösungen beinhalten wichtige Informationen über eine Anwendung. Sie existiert aber vornehmlich in den Köpfen derjenigen Personen, die hauptamtlich damit betraut sind einen Dienst oder Anwendung zu betreuen. Das Wissen bildet sich häufig bei der ersten Installation oder während der Bereitstellung der Komponenten und der Anbindung an komplementäre Dienste und Anwendungen aus. Oder wenn der Dienst oder Anwendung mit neuer Software aktualisiert wird, und vor allem nach Ausfällen bei der Wiederherstellung.
Unsere Auffassung nach sollte die IT Dokumentation einer Anwendung als auch eines Dienstes eine Baseline enthalten. Also ein Kapitel das beschreibt wie die Anwendung oder der Dienst sich verhält sobald man sie oder ihn das verwendet. Was sind die Voraussetzungen und Merkmale an denen IT Betreuer und Anwender ablesen können, ob die Anwendung oder Dienst sich wie vorgesehen verhält. Wobei aus Anwendersicht allein das präsentierte UI und deren Inhalte bewertbar sind. Der Anwendungsbetreuer oder Dienstverantwortliche hingegen sollte mit allen Informationen über das Verhalten auf und in der Infrastruktur und die Verwendung der Infrastruktur Ressourcen, in die die Anwendung oder der Dienst eingebettet ist enthalten.
