Lade Inhalt...

Theorie und Praxis digitaler Forensik in Kreditinstituten: Eine Kurzdarstellung von Verfahren und Werkzeugen

©2011 Studienarbeit 75 Seiten

Zusammenfassung

Das vorliegende Buch untersucht den Zusammenhang von IT-Sicherheit und IT-Forensik in Bezug auf Wirtschaftskriminalität in Banken. Hierfür wird bei der Analyse und Beschreibung des Security Engineering der Fokus auf die Verhütung von Wirtschaftskriminalität gelegt und es findet sich der Bezug der digitalen Forensik auf die Besonderheiten der Kreditinstitute.
Ein weiterer sehr interessanter Teilbereich der IT-Security ist die Erkennung und Analyse eines Einbruchs oder Einbruchsversuchs. Für diese Analyse bietet der Markt eine unzählige Anzahl an Werkzeugen, die mit ihrem Funktionsumfang die Erkennung des Angriffs und den gesamten forensischen Prozess abdecken können. Die Analyse einer kleinen Auswahl dieser Werkzeuge ist ebenfalls Zielsetzung des vorliegenden Fachbuchs.

Leseprobe

2.2.2 Interne Angriffsarten

Ein interner Angriff wird von Personen durchgeführt, die zum engeren Kreis des Unternehmens gehören. Hierbei kann es sich sowohl um „Komplizen“ handeln, die von externen Angreifern überzeugt wurden, wie auch um Personen, die selbst kriminelle Zielsetzungen verfolgen [Gesc04, S. 19]. Der Gesamtverband der deutschen Versicherungswirtschaft [GDV03] geht davon aus, dass ein Anteil von bis zu 40% der Angriffe von internen Tätern durchgeführt wird. Die Studie der CSI [Rich08] präsentiert ein ähnliches jedoch nicht so deutliches Bild (Abbildung 2): ein Teil der untersuchten Unternehmen führen einen mäßigen bis hohen Anteil der verursachten Schäden auf Mitarbeiter zurück. Die abweichenden Aussagen resultieren u. a. aus einer hohen und nur schwer abschätzbaren Dunkelziffer und somit leider nur wenig genauen Statistiken [Gesc04, S. 21].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Prozentualer Anteil an Schäden durch interne Angreifer [Rich08]

Bei der Evaluation von Statistiken ist demnach zu berücksichtigen, dass interne Angriffe häufig nicht festgestellt oder gemeldet werden. Auch können die Schäden von internen Angriffen meistens nicht genau evaluiert werden, was die vorliegende Statistik ebenfalls verfälscht.

Eine besondere Gefahr geht von frustrierten oder entlassenen Personen aus, die aufgrund ihrer betrieblichen Tätigkeit weitreichende Rechte in der Technologie-Landschaft haben. Hierunter fallen beispielsweise Systemadministratoren, die mit Hilfe ihres regulären Benutzerprofils Zugriff auf Server und Daten haben und so entweder Diebstahl betreiben können oder sich über Malware back-doors schaffen, mit deren Hilfe sie später noch in das Unternehmensnetzwerk eindringen können. Durch die einfachen Möglichkeiten des oberen Managements interne Kontrollverfahren zu umgehen (Management Override), ist es nicht verwunderlich, dass bis zu 30% der internen Angriffe von Personen des Top Managements durchgeführt werden [Krol08]. Spezielle, unbeeinflussbare technische Kontrollen könnten Schutz gegen diese eher organisatorische Aktivitäten bieten, so dass Ausnahmen unbeeinflussbar nicht möglich sind.

Die genaue Betrachtung der möglichen Angriffsarten von Innentätern führt zu dem Ergebnis, dass die Barrieren einfacher zu durchbrechen sind als von externen Angreifern. Insbesondere wenn Personen in Schlüsselpositionen Gründe finden, sich oder Dritten einen Vorteil oder dem Unternehmen einen Nachteil zu verschaffen.

Der für Betrug und Veruntreuung nötige Zugriff auf Datenbestände oder Prozesse kann sowohl zum Nutzungskonzept des Mitarbeiters gehören, als auch durch Fehler oder Fälschungen erlangt sein. Wenn die nötige kriminelle Energie beim Mitarbeiter vorliegt, kann dieser sich die Vermögensgegenstände des Unternehmens zu Eigen machen und damit zu einem Schaden beim Unternehmen führen. Hierzu ist es meistens nötig, einen Weg zu finden, interne Sicherungsprozesse zu umgehen.

In Banken kann das Umfeld und die ständige Präsenz von großen Geldbeträgen zu einer Verharmlosung von kriminellen Aktivitäten führen und den Mitarbeiter ermutigen bei Entdecken einer Sicherheitslücke diese zu nutzen. Demnach sollten Banken höchsten Wert darauf legen, dass Entscheidungen die einen Mittelabfluss vom Unternehmen bewirken immer durch mehrere Kontrollinstanzen überprüft werden, auch wenn es sich um wiederkehrende, aber vermeintlich kleine Beträge handelt.

3 Security Engineering und digitale Forensik in Kreditinstituten

Seit mehreren Jahrzehnten werden große Teile der betriebswirtschaftlichen Aktivitäten mehr und mehr durch (teil-)automatisierte Abwicklung von Rechnernetzen unterstützt, was eine immer umfassendere Datensammlung mit sich bringt. Je mehr Daten digitalisiert vorliegen, desto gravierender sind Auswirkungen der Angriffe auf diese digitalen Datenspeicher und -prozesse der Unternehmen. Insbesondere aufgrund der sensiblen Daten und der mit der Technologiestruktur zusammenhängenden Informationstiefe der Kreditinstitute ist dies eines der gefährdetsten Branchen der Wirtschaft.

Es ist daher nachvollziehbar, dass auch der Bereich der IT-Sicherheit in der Wirtschaft und den Kreditinstituten immer größeren Stellenwert gewann und sowohl technische wie organisatorische Möglichkeiten gesucht wurden, die Entwicklung der Computerkriminalität einzudämmen. Als Beispiel ist der IT-Grundschutzkatalog des Bundesamtes für Sicherheit in der Informationstechnik zu nennen, das eine umfassende Liste von Bedrohungen und möglichen Gegenmaßnahmen nennt und entsprechende Handlungsanweisungen für Unternehmen formuliert[1].

Während die Prozesse des Security Engineering primär ein technisches Umfeld schaffen sollen, in dem die Gefahr von absichtlichen und unabsichtlichen Schädigungen so weit möglich reduziert wird, sollen die forensischen Aktivitäten Auswertungen von Beweisen im Nachhinein ermöglichen. Diese Analysen werden durch die Implementierung eines durchdachten und professionellen Sicherheitskonzepts zusätzlich stark vereinfacht.

3.1 Definition und Zielsetzung des Security Engineering

Die Maßnahmen, die mit der Zielsetzung der IT-Sicherheit durchgeführt werden, werden als Security Engineering bezeichnet. Hierbei geht es um den Aufbau und den Betrieb von Securitykonzepten und –prozessen, die Gefahren erkennen und Gegenmaßnahmen etablieren.

Neben „aktiven“ Angriffen zählen auch „passive“ Gefahren dazu, die aus dem Verlust oder Ausfall von Daten und Systemen resultieren, die unbeabsichtigt auftreten. Auch für den Fall von Hardwareschäden und Naturkatastrophen gibt es Sicherungskonzepte (Business Continuitiy/Desaster Recovery Plan).

Dem Security Engineering liegt dabei ein Vorgehensmodell zu Grunde das eine Analyse des berücksichtigten Systems vornimmt, ein Sicherheitskonzept etabliert und die Überwachung des Konzepts sicherstellt. Die allgemeinen Konstruktionsprinzipien sind hierbei anerkannt und unterstützen bei der Definition der Berechtigungskonzepte [Ecke09, S. 168].

3.1.1 Allgemeine Konstruktionsprinzipien

Bereits zu Beginn der elektronischen Datenverarbeitung haben sich Konstruktionsprinzipen ergeben, die bis heute die Basis des Sicherheitsmanagements darstellen [Ecke09, S. 168f.]. Die nachfolgend genannten fünf Prinzipien sind die wichtigsten und bekanntesten und sollten auch beim IT-Management von Kreditinstituten dringend Anwendung finden, um Angriffe aus dem Innern des Unternehmens zu vermeiden. Nach [Müll10, S. 158ff.] gibt es noch unzählige mehr, auf deren vollständige Nennung aus Platzgründen verzichtet wird.

Das Erlaubnisprinzip definiert dabei die Empfehlung, dass den User grundsätzlich alles verboten sein soll, sofern er nicht explizit dafür die Erlaubnis erhalten hat.

Das Vollständigkeitsprinzip fordert, dass jede Aktivität des Benutzers kontrolliert wird und gegen die aktuellen Rechte abgeglichen wird. Eine Ausnahme von der Vollständigkeit kann „Hintertüren“ öffnen, um die Rechteeinschränkungen zu umgehen.

Das Prinzip der minimalen Rechte fordert den Umfang der Rechte so minimal wie möglich. Jeder Benutzer soll nur die Rechte erhalten, die auch dringend für seine Tätigkeiten notwendig sind.

Das Prinzip der Benutzerakzeptanz fokussiert im Gegensatz zu den anderen nicht auf technische Lösungen sondern stellt die Handlungsweisen des Nutzers in den Mittelpunkt. Erst ein einfaches und verständliches System und die Sensibilität des Benutzers für den Sinn der Regelungen führt dazu, dass dieser die technischen Anforderungen nicht auszuhebeln versucht. Nur so kann bspw. vermieden werden, dass die Passwörter desktopnah frei zugänglich notiert werden, das Passwort leicht zu erraten ist oder an Kollegen weiter gegeben wird [Stub02].

Da die Sicherheit eines Systems nicht von der Geheimhaltung abhängen darf, besagt das Prinzip des offenen Entwurfs dass die Sicherheitssysteme die nötige Sicherheit bieten müssen auch wenn sie offen dargestellt werden.

3.1.2 Bedrohungsanalyse und Schutzbedarf

Nachdem die Konstruktionsprinzipien bekannt sind, ist im Rahmen eines Engineering-Prozesses eine Analyse der Bedrohungen durchzuführen, die den individuellen Schutzbedarf des Unternehmens definiert. Eckert [Ecke09, S. 181f.] schlägt hierfür die Erstellung einer Bedrohungsmatrix oder eines Bedrohungsbaumes vor. In beiden Fällen wird die Angriffsart und die Möglichkeiten der Durchführung analysiert und entsprechende Gegenmaßnahmen ermittelt.

Die hierbei ermittelten Bedrohungen können wie folgt klassifiziert werden [Ecke09, S. 181]:

- Bedrohungen durch externe Angriffe
- Datenintegrität und Informationsvertraulichkeit (Umgehen interner Kontrollen)
- Abstreiten durchgeführter Aktionen
- Spezialisten mit Insider-Wissen
- Rechtemissbrauch/Ausnutzen von Vertrauensstellungen

3.1.3 Sicherheitsarchitektur

Wenn nun die Ziele und die möglichen Risiken bekannt sind, kann ein IST- und SOLL-Zustand definiert werden, der im Rahmen des Engineering-Prozesses angeglichen werden soll. Dies erfolgt zum einen durch die Orientierung an den Grundfunktionen vertrauenswürdiger Systeme [Ecke09, S198ff.] die sich wie folgt darstellen:

- Identifikation und Authentifikation
- Rechteverwaltung
- Rechteprüfung
- Beweissicherung
- Wiederaufbereitung
- Gewährleistung der Funktionalität

und zum Anderen an allgemeinen Schutzzielen, die erreicht werden sollen [Ecke09, S6ff.]:

- Authentizität
- Integrität
- Informationsvertraulichkeit
- Unzulässiger Informationsfluss
- Verfügbarkeit
- Verbindlichkeit
- Anonymisierung und Pseudomisierung

Unter Berücksichtigung dieser Punkte ist eine allgemeine Sicherheitsarchitektur zu definieren und umzusetzen, was sowohl technisch als auch organisatorisch aufwändig und komplex ist. Die Architektur muss alle Risiken ausschalten oder reduzieren, dabei gesetzliche Rahmenbedingungen einhalten und unterstützen, darf dabei aber den betrieblichen Ablauf nicht unnötig stark einschränken. Diesen Trade-Off bestmöglich aufzulösen ist Aufgabe der entsprechenden Sicherheitsingenieuren des Unternehmens.

Während sich diese Vorgaben auf die interne Sicherheitsarchitektur beziehen, kommt bei Kreditinstituten ein weiteres großes Thema hinzu. Die Legitimation von Kunden bei der Abwicklung des elektronischen Zahlungsverkehrs. Im Privatkundenbereich wird meistens das Protokoll FinTS (ehemals HBCI) und Internetbanking über PIN/TAN-Verfahren genutzt. Hierbei ist die Herausforderung das Verfahren auch in Bezug auf Phishing-Attacken zu sichern. Die Legitimationsverfahren im Firmenkundenbereich sind wesentlich detaillierter und komplexer. Während die Großbanken mehrere Standard-Tools anbieten, die von Kunden genutzt werden können und entsprechende gesicherte Schnittstellen und Gateways implementiert sind, gibt es auch Großkunden die proprietäre Formate verwenden wollen. Diese Tools und individuelle Lösungen ermöglichen die automatisierte Einbindung in Geschäfts- und Abstimmprozesse der Kunden, bspw. die Andienung der Gehaltszahlungen zur Bank direkt aus dem Personalabwicklungssystem. Hierbei können Kunden auch eigene Legitimationslösungen wie verteilte elektronische Unterschriften fordern. Hier ist vorstellbar, dass die Gehaltszahlungen automatisch aus dem Ungarischen Rechenzentrum angedient werden, von der Personalabteilung in London auf rechnerische Richtigkeit bestätigt und vom Geschäftsführer in Frankfurt freigegeben werden müssen. Die Technik muss in all diesen Teilschritten die Vertraulichkeit und die Integrität gewährleisten und sicherstellen, dass die Autorisierungen korrekt sind.

3.2 Definition und Zielsetzung digitaler Forensik

Die digitale Forensik, auch IT- oder Computer Forensik genannt, beschreibt die Tätigkeiten, die mit der Gewinnung und Sicherung von Beweisen nach Systemeinbrüchen oder anderen digitalen Angriffen in Verbindung stehen. Die Analysen der digitalen Forensik müssen dabei so aufgesetzt werden, dass die Beweise der Wirtschaftsstraftaten gerichtsverwertbar und vollständig vorliegen. Die Beweissammlung dient hierbei sowohl der Aufklärung von Straftaten die direkt IT-bezogen sind, bspw. illegales Eindringen in das Unternehmensnetzwerk, aber auch der Aufklärung von Straftaten, die nur digital „dokumentiert“ sind, was beispielsweise durch Email-Verkehr zu korruptionellen und betrügerischen Handlungen erfolgt.

Die wichtigsten Fragen, die im Rahmen einer forensischen Untersuchung beantwortet werden sollen, zielen auf die beteiligten Personen, die Zeiträume und die Aktivität ab und untersuchen die Lücken im Sicherheitskonzept, die zu dem Problem geführt haben kann [Gesc04, S. 55]. Für forensische Untersuchungen im Zahlungsverkehr der Kreditinstitute liegt ein Schwerpunkt in der Sicherstellung der Identitäten bei der Beauftragung von Banktransaktionen.

Das BSI definiert für deren Leitfaden „IT-Forensik“ [BSI11, S. 8] den Begriff wie folgt: „IT-Forensik ist die streng methodisch vorgenommene Datenanalyse auf Datenträgern und in Computernetzen zur Aufklärung von Vorfällen unter Einbeziehung der Möglichkeiten der strategischen Vorbereitung insbesondere aus der Sicht des Anlagenbetreibers eines IT-Systems“.

3.2.1 Beteiligte Personen

Während große Unternehmen und Banken interne IT-Sicherheits- und Forensikabteilungen etablieren können, lohnt es sich in kleinen oder mittelständischen Unternehmen nicht, das dringend notwendige und umfassende Fachwissen aufzubauen. Hier wird im Regelfall auf externe Spezialisten gesetzt, die Unternehmen bei der Durchführung forensischer Untersuchungen unterstützen.

Unabhängig von der Größe des Unternehmens müssen sich die forensischen Teams aus unterschiedlichen Disziplinen zusammensetzen, um alle Anforderungen zu erfüllen. In großen deutschen Banken werden IT-Forensik-Team häufig entsprechend der Aufgaben aus technischen (Mitarbeiter der IT Security), nicht-technischen (Interne Revision), juristischen (Rechtsabteilung), personalrelevanten (Personalabteilung) und aus der Compliance zugeordnete Bereiche zusammen gestellt . Das Team setzt sich also in der Regel aus Juristen, Revisoren, Wirtschaftsprüfern (bei finanziellen Aktivitäten), IT- und Netzwerkspezialisten und Projektmanager zur Koordination zusammen [Gesc04, S. 40]. Diese Forensik-Teams sollten einen engen Kontakt zum Senior- oder Top-Management pflegen, da auf dieser Ebene wichtige Entscheidungen getroffen werden müssen. Desweiteren wird die zentrale Abteilung zur Unternehmenskommunikation eingebunden um über interne und externe Kommunikationswege zu entscheiden.

Insgesamt ist aber darauf zu achten, dass der Kreis der involvierten Personen möglichst klein gehalten wird, da man nicht immer ausschließen kann, dass ein mögliches Team-mitglied am Angriff beteiligt war.

3.2.2 Vorgehensmodelle

Obwohl es mittlerweile klare gesetzliche Regelungen und Rechtsprechungen gibt, konnte sich aufgrund der heterogenen Angriffsstruktur und Systemlandschaften bislang kein einheitliches Vorgehensmodell durchsetzen. Leidglich Grundsätze sind bekannt und zu berücksichtigen, jeder einzelne Schritt ist dann aber vom Experten zu entscheiden und zu planen.

Trotzdem haben sich einzelne Verfahrensweisen als sinnvoll herausgebildet, die im Wesentlichen in wenige Schritte eingeteilt werden können. Das BSI untergliedert in deren Leitfaden [BSI11, S. 60] den zeitlichen Ablauf einer forensischen Untersuchung in die Schritte strategische Vorbereitung (SV), operationale Vorbereitung (OV), Datensammlung (DS), Untersuchung (US), Datenanalyse (DA) und Dokumentation (DO).

Geschonneck [Gesc04, S. 56f.] gliedert die Ermittlung in die Phasen Vorbereitung, Schutz der Beweismittel, Imaging, Untersuchung und Bewertung und Dokumentation. Später auch wie Dolle in die drei Schritte sichern, analysieren und Präsentieren.

In IT-Forensik Richtlinien deutscher Großbanken finden sich die Untergliederungen der Untersuchung im Anschluss an eine Erkennung oder Meldung in die Schritte „vorgelagerte Untersuchung“, „formale Informationsaufnahme“ und „detaillierte Auswertung der Informationssammlung“. Es gibt also unterschiedlich detaillierte Ansätze, die jedoch immer durch die Erkenntnis (Intrusion Detection) ausgelöst und dann sequenziell ausgeführt werden.

Während große Kreditinstitute und Unternehmen häufig eigene Richtlinien und Vorgehensmodelle definiert haben, entwickeln verschiedene Institute Modelle zur digitalen Forensik, die sich erwartungsgemäß im Laufe der kommenden Jahre vereinheitlichen oder sich verschiedenen Modelle als „Best Practice“ herausbilden werden [BaTu06]. Das „forensic process model“ des US Justizministeriums, das „abstract digitals forensics model“ und das „integrated digital investigation model“ orientieren sich bei ihrer Detaillierung der Prozesse ebenfalls am S-A-P Modell und untergliedern dieses in bis zu 14 Einzelschritte. Hierbei wird beim umfangreichen integrated digital investigation model die Tatortanalyse auch in einen physischen und einen digitalen Tatort unterschieden und erweitert so die Untersuchungen um die klassischen Tätigkeiten der Forensik [BuTa06].

3.2.3 Wesentliche Anforderungen an die digitale Forensik

Insbesondere wenn die digitale Forensik eingesetzt wird, um gerichtsverwertbare Beweise zu sammeln, sind hohe Anforderungen an die Methoden und Prozesse gerichtet. Um die Beweisfähigkeit vor Gericht nicht zu gefährden, finden sich in der Literatur [u.a. SaJe00] nachfolgende vier Prinzipien:

- Keine Aktionen der Ermittler dürfen die Beweisfähigkeit vor Gericht vermindern
- In den Ausnahmefällen, dass eine Person das Originalobjekt direkt betreten oder untersuchen muss, ist sicher zu stellen, dass diese Person die fachlichen Fähigkeit besitzt, die Auswirkungen des eigenen Handelns abzuschätzen
- Eine Dokumentation aller durchgeführter Aktivitäten muss so erstellt werden, dass ein fachkundiger Dritter mit diesen Aktivitäten zum selben Ergebnis kommt

Bei der Untersuchung muss eine Person dafür Verantwortlich sein, dass diese Prinzipien eingehalten werden Insbesondere der dritte Punkt zeigt, wie wichtig eine korrekte und professionelle Arbeitsweise als Forensiker ist und dass die Mitarbeiter und Prozesse großen Einfluss auf den Erfolg der Untersuchung hat.

4 Werkzeuge zur Unterstützung digitaler Forensik

Ebenso umfangreich wie die Möglichkeiten der wirtschaftskriminellen Aktivitäten sind auch die unterstützenden Werkzeuge. Das Fachgebiet ist dabei sehr breit und geht von der Analyse von ICQ-Chats [KiDaRo08], spezieller Bildforensik [SeMe08] über mobile Telefone, Smartphones und PDAs [Will05] bis zu modernen Spielekonsolen wie die Play Station Portable [Panc08].

Um Angriffe auf die Datensicherheit in Unternehmen zu vermeiden, sind sowohl organisatorische wie auch technische Maßnahmen notwendig. Auch wenn ein Angriff erkannt oder gemeldet wurde ist es hilfreich, wenn das Unternehmen oder das Kreditinstitut bereits organisatorische Maßnahmen definiert, Früherkennungssysteme eingerichtet und technische Möglichkeiten der Forensik vorbereitet hat. Erst durch die Festlegung des „whistle blowing[2] “- und der „incident response[3] “-Prozesse ist es möglich, die Verantwortlichkeiten innerhalb des Unternehmens zuzuordnen und die Entscheidung über die Hinzuziehung externer Spezialisten oder der Strafermittlungsbehörden schnell zu treffen [Gesc04, S. 37f.] und so korrekt und zeitnah zu reagieren.

Diese organisatorischen und technischen Maßnahmen können durch Softwareprodukte unterstützt werden, die sowohl kommerziell als auch frei zu erwerben sind. Die Zielsetzung dieser Software kann stark differieren, muss sich aber immer aus den bereits aufgeführten Gründen an den Vorgehensmodellen der digitalen Forensik orientieren und gewisse Bedingungen erfüllen.

4.1 Eigenschaften forensischer Werkzeuge

Um die Prinzipien der IT-Forensik zu erfüllen, müssen die Werkzeuge Eigenschaften aufweisen, die folgende Anforderungen an die Beweiserhebung nach [Doll09] erfüllen:

- Akzeptanz: Die Erhebung der Beweisdaten muss akzeptiert und zulässig sein und den gesetzlichen Vorgaben genügen. Sollte die Erhebung der Daten als unzulässig oder gesetzeswidrig erkannt werden, so wird i. d. R. so verfahren, als wenn diese Beweise nicht vorliegen. Dies kann ein herber Rückschlag für die Ermittlungsbemühungen bedeuten.
- Ursache und Auswirkung: Die Zuordnung von Indizien auf Aktionen oder Personen ist unabdingbar, um als Indiz verwendet werden zu können. Ohne diese authentische und eindeutige Zuordnung kann das Indiz nicht verwendet werden.
- Wiederholbarkeit und Dokumentation: Die einzelnen Schritte werden so dokumentiert, dass diese von einem fachkundigen Dritten identisch wiederholt werden können und dies zu den gleichen Ergebnissen führt.
- Integrität und Vollständigkeit: Die ermittelten Beweise müssen jederzeit integer und nach den „common practices“ ermittelt werden. Die Spuren dürfen nicht verändert werden. Die Untersuchung darf sich auch nicht nur auf eine einzelne Aktion beschränken, sondern muss immer auch die Aktionen beleuchten, die zu einer Entlastung der jeweiligen Personen führen können. Es ist also vollständig nach belastenden und entlasteten Aktionen zu suchen.
- Glaubwürdigkeit: Die Auswertungen der Analysen sind so aufzubereiten und zu dokumentieren, dass auch eine Person ohne technischen Hintergrund die Zusammenhänge versteht und die Robustheit der Methoden nachgewiesen werden kann. Dies stellt auch sicher, dass eine absichtliche Fehlinterpretation im Nachhinein ausgeschlossen werden kann.

Die gerichtliche Überprüfung der Tools und Verfahren in US-amerikanischen Gerichtsverhandlungen haben sich unter dem Namen „Daubert Prozess“ etabliert und beziehen sich auf die Schwerpunkte Testing (Ist die Prozedur bereits getestet?), Error Rate (Gibt es eine statistische Fehlerquote?), Publication (Wurde die Prozedur öffentlich diskutiert?) und Acceptance (Hat die wissenschaftliche Gemeinschaft das Verfahren akzeptiert?). Mit diesem Kontrollprozess haben die Gerichte eine Verfahrensanweisung an der Hand um eine Aussage darüber treffen zu können, ob die gerichtlichen Anforderungen erfüllt sind [Carr02]. Nur wenn das Gericht feststellt, dass die genutzten Methoden sauber angewandt wurden und zuverlässige Ergebnisse liefern, wird der Beweis anerkannt.

4.1.1 Incident Response Prozesse

Der Schwerpunkt der Incident Response-Verfahren ist die schnelle und zielführende Reaktion auf die Angriffserkennung. Dies kann mit oder ohne das Wissen des Angreifers erfolgen. Die Schwerpunkte sollten hierbei darauf liegen, keine gerichtsverwertbaren Beweise zu zerstören und weiteren Schaden zu verhindern. Diese Tätigkeiten können sowohl intern (bspw. IT Security Officer oder Systemadministratoren) wie auch extern (bspw. Razzia von Ermittlungsbehörden) erfolgen und erfordern schnelle und wichtige Entscheidungen. Insbesondere bei Sicherstellung laufender Systeme ergibt sich für die Ermittler ein Operating Dilemma [SaJe00, S. 180]. Dem System zu erlauben, den aktuellen Prozess fertig zu stellen, kann die Beweise sowohl positiv wie auch negativ (im Sinne der Ermittlung) beeinflussen. Hierbei ist von den Ermittlern eine fundierte Entscheidung auf Basis der Umstände zu treffen, die natürlich auch entsprechend dokumentiert werden muss.

Generelle Empfehlung - die jedoch vom Einzelfall abhängt ist es, laufende Systeme nicht abzuschalten. Stattdessen sollte man die Verbindungen trennen um weitere Aktivitäten zu vermeiden, alle eigene Aktivitäten genau loggen und alles weitere auf externen Speichermedien und nicht mehr auf der Festplatte speichern [SaJe00, S. 181].

Die Feststellung eines Angriffs oder eines Systemeinbruchs ist immer mit wichtigen und zeitkritischen Entscheidungen verbunden, weshalb von Unternehmen dringende organisatorische Vorbereitungen zu treffen sind. Wenn ein Notfall erst mal eingetreten ist, ist es häufig schon zu spät organisatorische Entscheidungen zu diskutieren, denn dies kostet wertvolle Zeit [Gesc04, S. 37].

Nach Geschonneck sollen im Rahmen dieser Vorbereitungen frühzeitig

- eine „Incident Awareness“ entwickelt werden, dass bei den Mitarbeitern das Wissen vorliegt, dass und wann ein Angriff eintritt
- ein „Incident Response Plan“ erstellt werden, der Eskalations- und Entscheidungswege definiert und Kompetenzen und Verantwortlichkeiten klärt
- Datenschutzfragen besprochen und die Freigabe der Daten durch den Datenschutzbeauftragten definiert werden
- die korrekten Ansprechpartner bei forensisch spezialisierten Unternehmensberatungen und/oder Ermittlungsbehörden notiert und einen ersten Kontakt aufgebaut werden. Auch die Festlegung von Verschlüsselungsmechanismen ist anzuraten.
- Mitarbeiter eines potentiellen Response Teams ernannt und geschult werden

4.1.2 Beweissicherung und Analyse

Die Beweissicherung steht als erster Schritt nach der Angriffserkennung und kann thematisch nach zeitkritischen Sicherungen von flüchtigen Speichern und der Sammlung von zeitlich unkritischen Daten unterschieden werden. Nach Übertragung der flüchtigen Speicher mit Hilfe spezieller Tools kann das angegriffene System vom Netz getrennt werden um weiteren Schaden zu verhindern und mit Hilfe von Programmen und (Schreibschutz-) Hardware muss eine Kopie der Festplatten erstellt werden [Gesc04, S. 56f.]. Wenn hier im Rahmen des Security Engineering entsprechende Vorbereitungen getroffen wurden, können auch die erstellten Protokolle gesichert werden [Ecke09, S. 200f.]. auf Basis der gesicherten Daten erfolgt dann eine zeitlich nachgelagerte Untersuchung, meist im Labor des Forensikers. Die Zielsetzung dieser sogenannten post-mortem Analyse ist nach [Gesc04, S. 55]:

- das Erkennen der Methode oder der Schwachstelle, die der Angreifer für den Systemeinbruch nutzte
- die Feststellung des Schadens
- Identifikation des Angreifers
- Sicherung der Beweise für den Falle einer juristischen Auseinandersetzung

Hierfür ist es also notwendig, dass die Untersuchung des Systems möglichst viele Informationen zur Verfügung stellt, ohne das System zu stören oder zu verändern. Insbesondere ist es dabei wichtig, dass die Glaubwürdigkeit und die Lückenlosigkeit der Beweiskette gewährleistet ist, da die elektronischen Beweise als „Augenscheinbeweise“ keine „Urkundenbeweise“ sind und einer gerichtlichen Kontrolle nicht immer Stand halten [Krol08]. Dafür ist es notwendig, dass die Suche auf dem System keine eigene Veränderungen vornimmt [Gesc04, S. 55f.]. Es gibt verschiedene Methoden um dies sicher zu stellen, zu denen u. a. folgende zählen [CoFo10]:

- Spurensicherungen (getrennte Kopien zur Analyse und Gerichtsauswertung)
- Wiederherstellung gelöschter Daten und Eigenschaften
- Auswertung von Log- und Systemdateien
- Malware-Analyse
- Aufbau von „Fallen“, wenn akuter Verdacht besteht (sog. Honey Pots)
- Suche und Bewertung der Schwachstellen in der IT-Sicherheit

Zur Analyse eines Einbruchs werden meistens mehrere oder alle dieser Methoden kombiniert. Für jede dieser Methoden finden sich auch unterschiedliche Werkzeuge, die genau diesen Prozess technisch ermöglichen (bspw. dd für die Erstellung von bitgenauen Images) oder unterstützen (bspw. Autopsy mit der Zusatzfunktion der Erstellung eines Tätigkeitsprotokolls mit Notizzettelfunktion zur Dokumentation). Diese Werkzeuge lassen sich neben Ihrer Unterstützungsfunktion auch durch weitere Eigenschaften unterscheiden.

4.2 Unterscheidungsmerkmale der Werkzeuge

Es gibt eine Vielzahl von Eigenschaften nach denen sich die große Anzahl an verfügbaren Werkzeugen klassifizieren lassen.

4.2.1 Unterscheidung nach Verfügbarkeit

Die Verfügbarkeit der Software ist ein Unterscheidungsmerkmal, das sehr strittig diskutiert wird. Es gibt eine Reihen von Argumenten für und wider jede Alternative. Insbesondere aus den Gründen der Sicherheit, Verlässlichkeit und der Produktunterstützung, aber auch aus philosophischen Gründen finden sich Unterstützer beider Seiten [Carr02].

Open Source Software enthält einen offenen, frei zugänglichen Quellcode und ermöglicht so Entwicklern, Nutzern und Testern das Programm zu validieren oder durch Entwicklungen den eigenen Bedürfnissen anzupassen. Wie bereits a. a. O. aufgeführt, ist für die Beweisführung bei IT-Forensikprozessen der Daubert-Prozess anzuwenden, der u. a. die öffentliche Diskussion und Akzeptanz als notwendiges Kriterium erachtet [Carr02, S. 3].

Ein offener Quellcode unterstützt die Ansätze des Daubert-Tests und erhöht so die Wahrscheinlichkeit der gerichtlichen Beachtung der Ergebnisse als verwertbare Beweise. Die durchgeführten Testprozesse und die Dokumentation von Fehlerraten sind bei Open-Source Programmen erfahrungsgemäß viel höher, da eine große Gemeinde von Nutzern und Entwicklern die Kontrollen durchführt und Fehler in Foren und Communities diskutiert [Carr02, S. 4f.]. Neben der Dokumentation wird auch durch fortlaufende Bereinigung die Qualität der Software erhöht. Es ist ebenfalls nachvollziehbar, dass ein offener Quellcode die Anforderungen Publication erfüllt während ein proprietärer Quellcode vor Gericht angezweifelt oder nur erschwert anerkannt werden kann.

Auf der anderen Seite haben es Hacker natürlich einfacher einen veröffentlichten Quellcode zu analysieren und Gegenmaßnahmen zu ergreifen. Wenn dieser Gruppe bekannt ist, wie das Analysesystem arbeitet und welche Kontrollen es macht, können entsprechende Aktionen während des Angriffs eingeplant werden, die diese Kontrollen und Analysen umgehen.

Ein weiteres Argument gegen proprietäre Quellcodes ist die Tatsache, dass dem Nutzen nicht detailliert bekannt sein kann, was die Software auf dem System ausführt. Unter Umständen werden unerwünschte oder schädigende Aktionen angestoßen oder gar datenschutzrechtlich bedenkliche Informationen an den Softwarehersteller oder Dritte übermittelt.

4.2.2 Unterscheidung nach Zielgruppe

Manche Werkzeuge werden nur ausgewählten Personengruppen zur Verfügung gestellt, um die Nutzung zu beschränken und zu verhindern, dass Informationen über die Analyseverfahren an Personen geraten, die dies zur Unterstützung ihrer kriminellen Aktivitäten einsetzen. Hierunter fällt das Analysetool COFEE von Microsoft. COFEE ermöglicht die Analyse von Windows und DOS-Systemen. Auch Berufsgruppen oder große, auf Forensik spezialisierte Unternehmensberater stellen eigenen Softwareentwicklungen nur ihren Mitgliedern oder Kunden zur Verfügung, um sich so von anderen Anbietern abzugrenzen.

4.2.3 Unterscheidung nach Umfang der Unterstützung

Die erhältlichen Werkzeuge beziehen sich meistens auf einen bestimmten Teilprozess der Untersuchung und Analyse und spezialisieren sich auf die unterstützenden Maßnahmen hierauf (bspw. Imageerstellung, Suchfunktionen, Passworterkennung). Diese Kernfunktionalität kann aber noch erweitert werden, so dass auch mehrere Schritte des Prozesses unterstützt werden, wobei diese unterschiedlich breit aufgestellt sein können. Auch eine Zusammenfassung von Tools, sog. Toolkits, die teilweise aufeinander abgestimmt sind, können eine großen Teil des Prozesses unterstützen.

4.2.4 Unterscheidung nach Zielsetzung und Unterstützungsfunktion

Die Zielsetzung der einzelnen Tools kann, wie bereits erwähnt stark voneinander abweichen, da im Rahmen der forensischen Analyse unterschiedlichste Tätigkeiten durchgeführt werden müssen. Analog zu den Prozessen der Analyse können die Tools gegliedert werden.

Dolle [Doll09] und weitere Experten gliedern die forensische Analyse in die drei Schritte Sichern, Analysieren und Präsentieren (S-A-P). Diesem vorgeschaltet ist noch das Erkennen, welches bspw. durch Intrusion Detection Systeme (IDS) durchgeführt werden kann. Die Computer Forensic Tool Testing Group (CFTT) des US-amerikanischen nationalen Instituts für Standards und Normung (NIST) untergliedert leicht abweichend und etwas detaillierter auf deren Internetpräsenz[4] die Tools in die Gruppen Disk Imaging, Forensic Media Preparation, Write block (SW/HW), Deleted file recovery, mobile devices und string search.

[...]


[1] Detaillierte Informationen findet der interessierte Leser u. a. unter https://www.bsi.bund.de/cln_165/DE/Themen/ITGrundschutz/itgrundschutz_node.html

[2] Als „whistle blowing“ wird das Melden von Auffälligkeiten bezeichnet und kann bestenfalls auch von Personen erfolgen, die nicht direkt mit der IT Security betraut sind oder keine Mitarbeiter des Unternehmens sind. Bspw. die Commerzbank AG bietet über das Internet ein frei zugängliches „whistle blowing“-System an: https://www.bkms-system.net/bkwebanon/report/clientInfo?cin=coba31&language=ger

[3] „Incident Response“ ist der gesamte organisatorische und technische Ablauf der gestartet wird, wenn ein Angriff gemeldet oder festgestellt wird.

[4] http://www.cftt.nist.gov/

Details

Seiten
75
Erscheinungsform
Erstausgabe
Jahr
2011
ISBN (PDF)
9783956847820
ISBN (Paperback)
9783956842825
Dateigröße
7.2 MB
Sprache
Deutsch
Institution / Hochschule
Universität Duisburg-Essen
Erscheinungsdatum
2015 (Februar)
Note
1,7
Schlagworte
Wirtschaftskriminalität Intrusion Detection Bank IT Security Incident Response

Autor

Ralph Schimpf, M.Sc. wurde 1979 in Tettnang geboren. Er schloss 2003 sein Studium der internationalen Betriebswirtschaftslehre in Reutlingen mit einem Diplom und 2012 ein berufsbegleitendes Studium der Wirtschaftsinformatik an der Universität Duisburg-Essen mit dem Master of Science mit großem Erfolg ab. Der Autor arbeitet in der IT einer großen deutschen Privatbank als Projekt- und Produktmanager im Transaction und Corporate Banking und befasst sich dabei auch mit Themen der IT-Sicherheit. Er wohnt heute in der Eifel, ist verheiratet und hat drei Kinder.
Zurück

Titel: Theorie und Praxis digitaler Forensik in Kreditinstituten: Eine Kurzdarstellung von Verfahren und Werkzeugen