D I P L O M A R B E I T - Fraunhofer

Transcrição

Wilhelm Büchner Hochschule
Darmstadt
Fachbereich Informatik
DIPLOMARBEIT
ANALYSE SICHERHEITSRELEVANTER GESCHÄFTSPROZESSE
EINES ANWENDUNGSFALLS AUS DER FINANZBRANCHE UND
ERMITTLUNG DER HIERFÜR GEEIGNETEN METHODEN
vorgelegt bei: Prof. Dr. Thomas Freytag
von: Peter von Oppenkowski
Matr.-Nr.: 872538
Anschrift: Am Lüderich 9, 51491 Overath
Abgabetermin: 01.09.2011
Fachbetreuer: Dipl.-Inform. Nicolai Kuntze
in Zusammenarbeit mit: Fraunhofer-Institut für Sichere Informationstechnologie - SIT
Einleitung
"You can't defend. You can't
prevent.
The only thing you can do is
detect and respond."
- Bruce Schneier
Einleitung
I. Danksagung
Mein erster und besonderer Dank gilt Herrn Prof. Dr. Thomas Freytag für die Betreuung meiner Diplomarbeit. Weiter danke ich ihm für seine inhaltlichen und konzeptionellen Ratschläge, die mir stets von großer Hilfe waren und mir die nötige
Sicherheit zum Gelingen dieser Arbeit gegeben haben.
Ebenso bedanken möchte ich mich bei den beiden Herren Nicolai Kuntze und Roland
Rieke vom Fraunhofer-Institut, die mich in das spannende Thema der IT-Sicherheit
eingeführt und mir die Gelegenheit gegeben haben, einen Beitrag zu aktuellen Fragestellungen zu leisten.
Ich danke auch meiner Freundin, die mir, trotz dass sie sich in anderen Umständen
befindet, während der ganzen Zeit Verständnis entgegengebracht und mir immer
ein gutes Gefühl vermittelt hat. Zudem danke ich ihr für die Unterstützung beim
Korrekturlesen.
Meinen Eltern möchte ich dafür danken, dass sie immer an mich glauben und mich wo immer sie nur können - unterstützen.
Zu guter Letzt widme ich diese Arbeit meinem ersten Kind Eleni, dessen schon jetzt
stolzer Papa sie noch in diesem Jahr willkommen heißen wird.
Einleitung
II. Inhaltsverzeichnis
I.
Danksagung
II.
Inhaltsverzeichnis
III.
Tabellenverzeichnis
IV.
Abkürzungsverzeichnis
V.
Abbildungsverzeichnis
1
Einleitung ................................................................................................................ 1
1.1
Motivation ............................................................................................................... 2
1.2
Ziel und Vorgehensweise der Arbeit ......................................................................... 3
1.3
Aufbau der Arbeit .................................................................................................... 3
2
IT-Sicherheit, Bedrohungen und Methoden ............................................................ 4
2.1
2.2
2.3
Problembereich IT-Sicherheit ................................................................................... 4
2.1.1
Grundwerte der IT-Sicherheit........................................................................ 6
2.1.2
Bedrohungen und Gefährdungen ................................................................. 7
2.1.3
Angriffe und Angreifer.................................................................................. 8
2.1.4
Risiken und Schwachstellen ........................................................................ 13
Informationstechnologie bei FDL............................................................................ 15
2.2.1
Betriebliche Anwendungen......................................................................... 16
2.2.2
Vernetzung und verteilte Systeme .............................................................. 17
2.2.3
Sicherheitskritische Geschäftsprozesse und Ereignisse ................................ 19
2.2.4
Datenschutz, Datensicherheit und Compliance ........................................... 20
Security Information and Event Management (SIEM) ............................................. 22
2.3.1
Einsatzumfeld von SIEM Lösungen.............................................................. 22
Einleitung
2.4
2.5
3
2.3.2
Funktionsweise von SIEMs .......................................................................... 23
2.3.3
Collection ................................................................................................... 24
2.3.4
Normalization ............................................................................................ 25
2.3.5
Aggregation ............................................................................................... 25
2.3.6
Correlation ................................................................................................. 26
2.3.7
Reporting ................................................................................................... 29
Modellierungsmethode UML ................................................................................. 30
2.4.1
Misuse Case Diagramm .............................................................................. 30
2.4.2
Mal-Activity Diagramm .............................................................................. 31
Attack-Trees Methode ........................................................................................... 32
Anwendungsfall aus der Finanzbranche ................................................................ 33
3.1
Umfeld und Zugangssysteme der Bank ................................................................... 33
3.2
Internetbanking Anwendung .................................................................................. 36
3.3
3.4
3.2.1
Internetbanking Überweisung .................................................................... 38
3.2.2
Prozessablauf der Überweisung.................................................................. 40
Bedrohungsanalyse ................................................................................................ 44
3.3.1
Zugangsdaten des Kunden missbrauchen ................................................... 44
3.3.2
Kunden austricksen und manipulieren ........................................................ 47
3.3.3
Banksystem kompromittieren..................................................................... 50
3.3.4
Kundenrechner infizieren............................................................................ 51
Risikoanalyse und Sicherheitsanforderungen ......................................................... 52
3.4.1
Analyse zu Zugangsdaten des Kunden missbrauchen .................................. 52
3.4.2
Analyse zu Kunden austricksen und manipulieren ....................................... 54
3.4.3
Analyse zu Banksystem kompromittieren ................................................... 55
Einleitung
3.5
4
Modellierung der Einwirkung auf Prozesse ............................................................. 57
3.5.1
Misuse Case Internetbanking Überweisung ................................................ 57
3.5.2
Mal-Activity Internetbanking Überweisung ................................................ 58
3.5.3
Objekte bei der Internetbanking Überweisung ............................................ 62
Erkenntnisse und Implikationen ............................................................................ 63
4.1
Geschäftsprozessereignisbasierte Sicherheitsanalyse ............................................. 63
4.1.1
Ableitung von Angriffsindikatoren .............................................................. 64
4.1.2
Indikatoraussagen ..................................................................................... 64
4.1.3
Sicherheitsanalysemodell ........................................................................... 66
4.2
Sicherheitsanforderungen und Implikationen für die Praxis.................................... 67
4.3
Implikationen für die Forschung ............................................................................. 68
4.4
Zusammenfassung ................................................................................................. 68
VI.
Anlagen
VII.
Literaturverzeichnis
VIII.
Eidesstattliche Erklärung
Einleitung
III. Tabellenverzeichnis
Tabelle 2.1: Angreifer-Klassifikation ........................................................................................ 9
Tabelle 2.2 Fristen zur Aufbewahrung regulierter Daten ....................................................... 21
Tabelle 3.1: Anwendungsfallbeschreibung Login auf Website ............................................... 40
Tabelle 3.2: Anwendungsfallbeschreibung Überweisung beauftragen ................................... 40
Tabelle 3.3: Risikoanalyse – Kunden-Credentials physisch erlangen (Baum 1.1.n) .................. 53
Tabelle 3.4: Risikoanalyse – Kunden-Credentials ausspähen (Baum 1.2.n.n) .......................... 54
Tabelle 3.5: Risikoanalyse – Social Engineering betreiben (Baum 1.3.n)................................. 54
Tabelle 3.6: Risikoanalyse – MITM Angriff betreiben (Baum 2.1.n.n) ..................................... 55
Tabelle 3.7: Risikoanalyse – Social Engineering betreiben (Baum 2.2.n.n).............................. 55
Tabelle 3.8: Risikoanalyse – Kunden Credentials erraten (Baum 3.1.n) .................................. 56
Tabelle 3.9: Risikoanalyse – Internetbanking manipulieren (Baum 3.2.n) .............................. 56
Tabelle 3.10: Misuse-Case Beschreibung MITB Methode einsetzen ....................................... 58
Einleitung
IV.
Abkürzungsverzeichnis
ACH ................. Automated Clearing House
AGB .... Allgemeine Geschäftsbedingungen
AWF.................................. Anwendungsfall
BDSG ................ Bundesdatenschutzgesetz
BKA............................. Bundeskriminalamt
BSI ........... Bundesamt für Sicherheit in der
.................................. Informationstechnik
Bsp. ............................................... Beispiel
bspw. .................................. beispielsweise
bzw. ................................ beziehungsweise
ca. ..................................................... circa
CE .................... Composite/Complex Event
CIP .......... Critical Infrastructure Protection
d.h. ............................................. das heißt
DMZ ........................ Demilitarisierte Zone
DNS ........................ Domain Name System
DoS .................................. Denial of Service
E2E ........................................... End to End
EBICS ...............Electronic Banking Internet
.......................... Communication Standard
engl. ............................................. englisch
EPS ............................... Events Per Second
EV-SSL.................. Extended-Validation-SSL
f. .................................................. folgende
FDL .............................. Finanzdienstleister
ff................................................ folgenden
FinTS........... Financial Transaction Services
FISMA ........... Federal Information Security
....................................... Management Act
FTAM ....................File Transfer and Access
............................................. Management
GLBA................... Gramm–Leach–Bliley Act
GUI ..................... Graphical User Interface
GWG............................. Geldwäschegesetz
HBCI ........ Home Banking Comter Interface
HIPAA ...... Health Insurance Portability and
..................................... Accountability Act
HTML ............ Hypertext Markup Language
HTTPS HyperText Transfer Protocol Secure
i.D. .................................... im Durchschnitt
i.S.v........................................ im Sinne von
IAM ....... Identity and Access Management
IDS ................. Intrusion Detection Systeme
IPS ................Intrusion Protection Systeme
ISDN ... Integrated Services Digital Network
IT ........................ Informationstechnologie
LAN............................. Local Area Network
MASSIF .. Projekt: MAnagement of Security
.............. information and events in Service
.......................................... InFrastructures
Mio. .......................................... Million(en)
MITB........................... Man in the browser
MITM ........................... Man in the middle
NERC ....North American Electric Reliability
.............................................Corporation’s
OMG............... Object Management Group
p.a. .............................................. per anno
PCI ... Payment Card Industry Data Security
.................................................... Standard
PIN ... Persönliche Identifikations-Nummer
RSA ...Public-Key-Kryptographie von Rivest,
................................. Shamir und Adleman
RZB ......................... Raiffeisen Zentralbank
SEM .............. Security Event Management
SES ................ Security Effectiveness Score
SHA ....................... Secure Hash Algorithm
SIEM ..........Security Information and Event
............................................. Management
SIEMs ....... Security Information and Event
.............................. Managemen System(e)
SIM ...... Security Information Management
SNMP ......... Simple Network Management
..................................................... Protocol
sog...................................... sogenannte(n)
SOX.............................. Sarbanes-Oxley Act
SQL ................. Structured Query Language
SSL ............................ Secure Sockets Layer
STP ................ Straight Through Processing
SWIFT ..... Society for Worldwide Interbank
.................... Financial Telecommunication
TAN .......................... Transaktionsnummer
TLS............. Transmission Control Protocol,
............................ Transport Layer Security
u.a. .................................... unter anderem
UML ............... Unified Modeling Language
usw...................................... und so weiter
VAR ............................................. Variante
vgl. ............................................ vergleiche
VPN ................................................ Virtual
........................................ Private Network
WAN........................... Wide Area Network
ZKA .................... Zentraler Kreditausschuss
Einleitung
V.
Abbildungsverzeichnis
Abbildung 2.1: Konsequenzen aus Angriffen auf die Unternehmens-IT.................................... 5
Abbildung 2.2: Kategorien der Gefährdungen ......................................................................... 7
Abbildung 2.3: Unternehmenserfahrungen mit Angriffen auf die IT ...................................... 12
Abbildung 2.4: Übersicht betrieblicher Anwendungen eines Finanzdienstleisters .................. 16
Abbildung 2.5: IT-Architektur der RZB ................................................................................... 18
Abbildung 2.6: Überblick einer SIEM Lösung ........................................................................ 23
Abbildung 2.7: Komponenten eines SIEMs ............................................................................ 24
Abbildung 2.8: Redundante Ereignisse BIP2488E, BIP2230E und BIP2232E in SYSLOG ........... 26
Abbildung 2.9: Relationsmodell bei Korrelation von Event1||Event2 .................................... 27
Abbildung 2.10: Zusammenhang des Misuse Case Konzepts zum Use Case Diagramm .......... 31
Abbildung 2.11: Darstellung UND- und ODER-Knoten in Attack-Trees ................................... 32
Abbildung 3.1: Kundenzielgruppen und elektronische Bankzugänge ..................................... 33
Abbildung 3.2: Schnittstellen der Bankrechnerfunktionen ..................................................... 35
Abbildung 3.3: Funktionen der Anwendung Internetbanking ................................................ 37
Abbildung 3.4: Anwendungsfalldiagramm zur Internetbanking Überweisung ........................ 39
Abbildung 3.5: Aktivitätsdiagramm Login Internetbanking ................................................... 41
Abbildung 3.6: Aktivitätsdiagramm Internetbanking Überweisung ....................................... 43
Abbildung 3.7: Angriffsbaum Internetbanking Überweisung ................................................. 44
Abbildung 3.8: Angriffsbaum Internetbanking Zugangsdaten missbrauchen .......................... 45
Abbildung 3.9: Beispiel zum Man-in-the-browser Angriff ...................................................... 47
Abbildung 3.10: Angriffsbaum Internetbanking Kunden austricksen und manipulieren ........ 48
Abbildung 3.11: Angriffsbaum Internetbanking Banksystem kompromittieren ..................... 50
Einleitung
Abbildung 3.12: Angriffsbaum Kundenrechner infizieren ...................................................... 51
Abbildung 3.13: Misuse-Case Diagramm zur Internetbanking Überweisung .......................... 57
Abbildung 3.14: Mal-Activity Diagramm Internetbanking Login ............................................. 59
Abbildung 3.15: Mal-Activity Diagramm Internetbanking Überweisung ................................. 60
Abbildung 3.16: Objekte bei der Internetbanking Überweisung ............................................ 62
Einleitung
1 Einleitung
Die Informationstechnologie (IT) hat in den Finanzdienstleistungshäusern schon lange
einen übergreifenden Einzug erhalten und unterstützt Kunden sowie Mitarbeiter bei
täglichen Routinen. Der Einsatz von mobilen und stark vernetzten IT-Systemen ist dabei in nahezu sämtlichen Geschäftsprozessen wiederzufinden und leistet als Rückgrat
vieler Geschäftsmodelle einen wesentlichen Beitrag zur Erreichung der Unternehmensziele. Immer deutlicher zählt die dabei eingesetzte IT-Infrastruktur zum wertvollen, besonders zu schützenden Gut eines Unternehmens und ist zugleich zunehmend
dem Einwirken komplexer Ereignisse - resultierend aus Missbräuchen oder auch
Fehlbedienungen - auf sicherheitskritische Eigenschaften der Geschäftsprozesse
ausgesetzt. Für die Finanzbranche entstehen auf diese Weise Schäden, die sehr
vielfältig ausfallen können und dessen vorläufiger Höhepunkt sich - verursacht durch
einen einzelnen Fall von Computermissbrauch - auf eine bedrohliche Schadenssumme
von 4,9 Milliarden Euro beläuft1.
Der IT-Sicherheit wird damit eine enorme Bedeutung zuteil, dessen Erfolg, gemessen
an der Minimierung der Gefährdung des reibungslosen Geschäftsablaufs bzw. der
Vermeidung wirtschaftlicher Schäden, wesentlich von der effizienten Ermittlung und
Bewertung von Bedrohungen und Risiken und anschließender Maßnahmen abhängt.
Dem wird die Sicherheitsanalyse - deren Ergebnisse sich in den Sicherheitsanforderungen widerspiegeln - gerecht, die allerdings aufgrund der Dynamik bei IT-Systemen
bereits einen stetig wiederkehrenden Aufwand für das Unternehmen bedeutet.
Zusätzlich und weitaus aufwendiger ergibt sich die Durchführung und Überwachung
der aus den Anforderungen hervorgehenden Sicherheitsmaßnahmen im Tagesgeschäft2. Um diesen Aufgaben Herr zu werden bedienen sich Finanzdienstleister (FDL)
technischer Hilfsmittel, dessen Leistungsfähigkeit einen gewichtigen Einflussfaktor auf
ein optimales Verhältnis zwischen höchstmöglichem Schutz bei geringstmöglichem
Arbeitsaufwand ausmacht.
Zu den von den FDL genutzten technischen Hilfsmitteln zählen unter anderem Firewalls, Vierenscanner, Intrusion Detection bzw. Intrusion Protection Systeme (IDS/IPS),
1
2
vgl. [01] ZEIT ONLINE, dpa, Reuters, 2010
vgl. [02] Ponemon Institute LLC, 2010, S. 3 und 7
1
Einleitung
die im Wesentlichen sicherheitskritische Aktivitäten innerhalb eines Rechnernetzes
oder -systems erkennen bzw. anzeigen und ggf. unterbinden sowie zunehmend
Security Information and Event Management (SIEM) Lösungen. Letztere nehmen eine
übergeordnete Rolle ein, da diese auf erstgenannte aufsetzen und deren Funktionen
bündeln, anreichern oder sogar übernehmen können. Diese Eigenschaft macht SIEM
Systeme zum zentralen Ansatzpunkt zur Verbesserung sicherheitstechnischer und
betriebswirtschaftlicher Aspekte.
1.1 Motivation
Die FDL – deren Umfänge an eingesetzter IT-Infrastruktur mittlerweile derer von ITDienstleistungsunternehmen gleichen1 – stehen vor der Herausforderung, der Compliance gegenüber gerecht zu handeln und nicht den Überblick zu verlieren. Das trifft
insbesondere auf den Umgang mit der Datenflut von sicherheitsrelevanten Ereignissen zu2. Da diesem enormen Datenaufkommen mit manueller Bearbeitung praktisch
nicht nachzukommen ist, werden SIEM Systeme eingesetzt, die das Sicherheitsniveau
signifikant steigern und den Aufwand erheblich senken können 3. Dass ein so beachtlicher Mehrwert zu erzielen ist, kann darauf zurückgeführt werden, dass seit sich der
Begriff SIEM zu etablieren begann4 eine stetige Weiterentwicklung stattfand, wobei
Einsatzmöglichkeiten erweitert und die Systeme insgesamt ausgeklügelter wurden.
Dieser Weiterentwicklung hat sich auch das Gemeinschafts-Projekt MASSIF (MAnagement of Security information and events in Service InFrastructures)5 , welches
durch die Europäische Kommission finanziert wird, verschrieben. Das FraunhoferInstitut für Sichere Informationstechnologie ist Forschungsleiter in diesem Projekt
und verantwortlich für die Konzeption eines Modells zur prädiktiven (d.h. vorhersagenden) Sicherheitsanalyse bzw. Korrelation von Ereignissen auf und quer durch
mehrere Prozessebenen (multi-level).
1
die Deutsche Bank betreibt ca. 21.000 im Vergleich zu ca. 30.000 Servern, die von Facebook betrieben werden, vgl. [03] IBM Deutschland GmbH, 2011 und [04] intac, 2010
2
bis zu 15 Mio. security events pro Tag bei der Commerzbank zu managen, vgl. [05] ArcSight Inc., 2010
3
i.D. wird ein SES (Security Effectiveness Score) von 0,61 mit Einsatz eines SIEMs zu ohne von 0,08
erreicht und eine Kostenreduktion von 24% erzielt, vgl. [02] Ponemon Institute LLC, 2010, S. 12
4
geprägt durch M. Nicolett und A. Williams im Jahr 2005 vgl. [06] Williams, 2007
5
siehe http://www.massif-project.eu/
2
Einleitung
Die vorliegende Arbeit soll hierzu einen Beitrag leisten, indem der Zusammenhang
zwischen Basis- (z.B. login) und Geschäftsprozess-Ereignissen bei FDL analysiert wird.
1.2 Ziel und Vorgehensweise der Arbeit
Im Rahmen dieser Arbeit soll anhand von exemplarischen Prozessen eines Anwendungsfalls eines FDL der Zusammenhang zwischen Basisereignissen in der ITInfrastruktur (wie z.B. login und logoff) und Ereignissen in Geschäftsprozessen erarbeitet werden, um auf dieser Basis Möglichkeiten herauszustellen, die zu einer
Verbesserung der Leistungsfähigkeit bei SIEMs im Bereich der Sicherheitsanalyse bzw.
Korrelation verwendet werden können.
Hierzu werden Geschäftsprozesse mit sicherheitskritischen Eigenschaften erfasst und
einer Sicherheitsbetrachtung unterzogen. Die Betrachtung umfasst Methoden der
Bedrohungs-/ und Risikoanalyse, aus der eine für die Branche geeignete Methode
ausgewählt wird, die zur Ermittlung von auf Geschäftsprozesse wirkender relevanter
Ereignisse ausreichend geeignet ist. Die so ermittelten Ereignisse und deren Einwirken werden nach Klassen sortiert und in einem Modell zur Sicherheitsanalyse in
Echtzeit (bestehend aus auf geschäftsprozessbasierenden Ereignissen und Relationen)
aufgezeigt, um die sich daraus ergebenden Sicherheitsanforderungen und Zusammenhänge für die oben erwähnte Verbesserung von SIEMs nutzen zu können.
1.3 Aufbau der Arbeit
Die Arbeit ist wie folgt aufgebaut: Zu Beginn werden in Kapitel 2 einige Grundlagen
vorgestellt, die für die Betrachtung ereignisgesteuerter Sicherheitsmechanismen, der
Durchführung einer Sicherheitsanalyse sowie zum Verständnis der IT-Infrastruktur
und Sicherheitsbedrohungen bei FDL von Bedeutung sind. In Kapitel 3 erfolgt zunächst die Vorstellung des Anwendungsfalls eines FDL mit anschließender Analyse
und Modellierung der auf den Geschäftsprozess einwirkenden Ereignisse. Das abschließende Kapitel 4 widmet sich der aus dieser Arbeit zu gewinnenden Erkenntnisse, die zum Entwickeln eines Modells zur geschäftsprozessbasierten Sicherheitsanalyse in Echtzeit genutzt werden und führt Implikationen für Wissenschaft und Praxis
auf.
3
IT-Sicherheit, Bedrohungen und Methoden
2 IT-Sicherheit, Bedrohungen und Methoden
Im Zuge der immer weiter voranschreitenden Professionalisierung der Computerkriminalität, steigender Schadensfälle 1 und nicht abreißender Berichte über stattgefundene Hackerangriffe2 wächst auch das gesellschaftliche Sicherheitsbewusstsein im
Umgang mit der IT. All dieses hat Unternehmen dazu bewogen, sich noch intensiver
als in der Vergangenheit mit der IT-Sicherheit auseinanderzusetzen,3 um ihre Unternehmenswerte adäquat zu schützen. Bei FDL trifft die IT-Sicherheit dabei auf eine
komplexe IT-Infrastruktur mit einer ganzen Ansammlung sicherheitskritischer Anwendungen mit verteilten Systemen, für die hohe regulatorische Anforderungen
gelten und für deren Schutz bzw. Einhaltung besondere Hilfsmittel erforderlich sind.
Beginnend mit der IT-Sicherheit gibt dieses Kapitel einen Einblick zu diesen Themen,
was dem besseren Verständnis des im Folgekapitels behandelten Anwendungsfalls
eines FDL dienen soll.
2.1 Problembereich IT-Sicherheit
Die IT-Sicherheit befasst sich mit dem Schutz von Informationen bzw. Informationssystemen vor Störungen und Angriffen, um die System-Verlässlichkeit (engl. dependability) zu gewährleisten, Schäden zu vermeiden und Risiken zu minimieren. Dieses
beinhaltet sowohl den Aspekt der Funktionssicherheit (engl. safety), bei dem es sich
hauptsächlich um die physikalische und innerbetriebliche Sichtweise handelt (z.B.
Serverausfall, Festplattencrash, Laufzeitfehler oder Spannungsschwankungen), als
auch den der Informationssicherheit (engl. security), bei dem der unberechtigte bzw.
missbräuchliche Zugriff betrachtet wird.4 Wie am Beispiel eines Denial-of-Service
(DoS) Angriffs jedoch gut zu erkennen ist, sind diese beiden Aspekte oft fließend
ineinander übergehend. Der Fall eines DoS zeigt dabei exemplarisch, dass bei Safety
auch ein gewisses Maß an Security mit einbezogen werden muss, da ansonsten den
1
2
3
4
die eingesetzten Methoden werden immer raffinierter und die registrierten Fälle stiegen in 2010 um
33 Prozent, vgl. [07] BKA und BITKOM, 2010; [08] Symantec Corporation, 2011
Cyberattacke auf vertrauliche Daten des Internationalen Währungsfonds über die Finanzsituation
verschiedener Länder, vgl. [09] Frankfurter Allgemeine Zeitung GmbH, 2011; Hacker stehlen abermals sensible Nutzerdaten von Sony, vgl. [10] Frankfurter Allgemeine Zeitung GmbH, 2011
mehr als die Hälfte beabsichtigen die Ausgaben zur Verbesserung der IT-Sicherheit auf Vorjahresniveau zu halten und 42 Prozent planen sogar mehr zu investieren, vgl. [11] BSI, 2009
vgl. [12] Eckert, 2009, S. 4 ff.
4
Ansprüchen von Safety selbst nicht entsprochen werden kann.1 Eine weiterführende
Betrachtung des Aspekts Safety ist nicht Gegenstand dieser Arbeit, es wird jedoch
hierauf im Abschnitt 2.1.2 Bedrohungen und Gefährdungen unter dem Begriff Störungen noch einmal Bezug genommen, um ein komplettes Bild über die potenziellen
Gefährdungen der Unternehmens-IT zu geben.
Die zu schützenden Unternehmenswerte einer Organisation spiegeln sich in der ITSicherheit in den sog. Grundwerten (auch Schutzziele genannt)2 wider. Vernachlässigt
das IT-Sicherheits-Management den Schutz dieser Grundwerte oder sind die eingesetzten Sicherheitsmaßnahmen unzureichend, können dem Unternehmen hieraus
erhebliche Konsequenzen entstehen, wie die folgende Abbildung aus einer Untersuchung zeigt.
3
Abbildung 2.1: Konsequenzen aus Angriffen auf die Unternehmens-IT
Demnach hat fast jedes zweite Unternehmen mindestens einen Ausfall der IT-Systeme
mit der Folge von Produktivitätsverlusten durch Angriffe auf die Unternehmens–IT
erlitten. Nicht zuletzt aufgrund des bereits erwähnten gesellschaftlichen Sicherheitsbewusstseins, ist der Imageschaden hierbei als besonders weitreichend hervorzuhe1
2
3
die Anstrengung nach einer allgemeingültigen Abgrenzung beider Begriffe wird schon länger verfolgt
und liefert bisher unterschiedliche Definitionen, vgl. u.a. [13] The Computer Journal - A. BURNS, J.
McDERMID AND J. DOBSON, 1991; [14] Schneier, 1. Auflage 23. Januar 2004, S. 121 f.; [15] Freiling,
2010, die vorliegende Diplomarbeit lehnt sich an die Definition von [12] Eckert, 2009 an
vgl. [12] Eckert, 2009, S. 6; [16] Bundesamt für Sicherheit in der Informationstechnik, 2011
Quelle: [17] IDC Central Europe GmbH, Juli 2010
5
ben, da sich dieser schwer bemerkbar langfristig auf die Geschäftsentwicklung auswirken kann und gut jedes 5. Unternehmen ereilt. Die FDL-Branche stellt hierbei keine
Ausnahme dar. Es zeigt sich mit einem Produktivitätsausfall von 45%, einem Vertrauensverlust der Kunden (Imageschaden) von 37% und einem Auftrags-/ Kundenrückgang von 18% ein ähnliches Schadensbild. 1 Aus der Studie ergibt sich darüber hinaus,
dass bereits jeder fünfte Bankkunde von einem Angriff oder Betrug betroffen war.
2.1.1 Grundwerte der IT-Sicherheit
Sämtliche Informationen bzw. Daten und deren verarbeitende Systeme einer Organisation stellen aus Sicht der IT prinzipiell schutzbedürftige Unternehmenswerte dar. Die
Unternehmenswerte sind Bedrohungen ausgesetzt wie z.B. unberechtigte Zugriffe,
Manipulationen, Sabotagen, Datenverluste etc., was zu einem Schaden für das Unternehmen führen kann. Ziel der IT-Sicherheit in diesem Zusammenhang ist es daher,2
 die Vertraulichkeit (engl. confidentiality), d.h. Informationen können nur von
autorisierten Subjekten oder Objekten eingesehen werden und es ist sichergestellt, dass unautorisierte Dritte keine Kenntnis erlangen,
 die Integrität (engl. integrity), d.h. die Manipulation von Informationen ist
nicht unautorisiert und unbemerkt möglich, sowie
 die Verfügbarkeit (engl. availability), d.h. die Informationen stehen im Rahmen von eigenen oder gesetzlichen Vorgaben zur Verfügung,
bei den eingesetzten Systemen zu gewährleisten. Neben diesen drei maßgeblich zu
schützenden Grundwerten der Informationssicherheit (auch Datensicherheit) werden
- je nach Sinnhaftigkeit des jeweiligen Anwendungsbereichs - die Schutzziele dezidierter betrachtet und um bspw. die Folgenden ergänzt3:
 Abrechenbarkeit (engl. accountability)
 Anonymisierung (engl. anonymity)
 Authentizität (engl. authenticity)
 Verbindlichkeit (engl. non repudiation)
1
2
3
vgl. [18] FICO - Fair Isaac Corporation, 2011
vgl. u.a. [19] BSI, November 2009, S. 12 f.; [20] Miller, Harris, Harper, Vandyke, & Blask, 1. Auflage 1.
November 2010, S. 9 ff.; [12] Eckert, 2009, S. 6 ff.
vgl. [19] BSI, November 2009, S. 49; [12] Eckert, 2009, S. 6 ff.
6
Auf diese Weise können schutzbedürftige Werte einer Unternehmung individuell
herausgestellt und als zusätzliche Schutzziele konkret in die Sicherheitsbetrachtung
mit aufgenommen werden. So ist es aus Sicht des FDL durchaus sinnvoll, die Verbindlichkeit genauer zu betrachten, um z.B. sicherzustellen, dass das Risiko der Verleugnung einer getätigten Online-Überweisung ausreichend abgesichert wird. Ebenso
trifft dieses auf die Authentizität zu, wobei beispielsweise beim Telefon-Banking die
Echtheit der Kommunikationspartner zu gewährleisten ist (i.S.v. Spricht der Kunde
tatsächlich mit dem Sprach-Computer der Bank und umgekehrt?).
2.1.2 Bedrohungen und Gefährdungen
In der IT-Sicherheit sind Bedrohungen (engl. threats) Ereignisse oder Umstände,
welche die oben genannten Schutzziele bzw. Grundwerte bedrohen. Eine tatsächliche
Gefährdung für das Unternehmen ergibt sich erst dann, wenn die Bedrohungen auf
vorhandene Schwachstellen (engl. weakness) der Unternehmens-IT, was sowohl den
technischen als auch den organisatorischen Blickwinkel betrifft, treffen bzw. diese
ausnutzen, wodurch konkrete Risiken (vgl. 2.1.4) hinsichtlich möglicher Schäden
entstehen. Das Spektrum der Gefährdungen ist breit und lässt sich, wie in der folgenden Übersicht dargestellt, global in Angriffe und Störungen unterteilen.
Gefährdungen
Angriffe
Aktive
Angriffe
Störungen
Passive
Angriffe
Fahrlässigkeit
Höhere Gewalt
Manipulation
Abhören
Unsachgemäße
Bedienung
Missachtung von
Sicherheitsvorschriften
Techn. Defekt
Stromausfall u.
Überspannung
Sabotage
Datenklau
Mangelhaftes
Systemdesign
Organisatorische
Mängel
Hitze, Feuer u.
Blitzschlag
Wasser- u.
Feuchtigkeit
Hacking
Spionage
Streik u.
Demonstration
Naturkatastrophen
Security
Safety
Abbildung 2.2: Kategorien der Gefährdungen1
1
in Anlehnung an [21] Hoppe & Prieß, 2003, S. 33, [12] Eckert, 2009, S. 15 ff. zitiert nach BSILehrbriefen der IT-Sicherheit
7
Wobei in der IT-Sicherheit grundsätzlich Angriffe durch den bereits erwähnten Aspekt
der Security und Störungen durch den der Safety abdeckt werden.
Unter Angriffe fallen alle Gefährdungen, die auf ein vorsätzliches Handeln zurückzuführen sind, wobei zwischen aktiven und passiven Angriffen unterschieden werden
kann. „Passive Angriffe betreffen die unautorisierte Informationsgewinnung und
zielen auf den Verlust der Vertraulichkeit ab. Aktive Angriffe betreffen die unautorisierte Modifikation von Datenobjekten und richten sich somit gegen die Datenintegrität oder Verfügbarkeit eines IT-Systems“.1
Gefährdungen hingegen, die unbeabsichtigt, ohne bewusstes Dazutun oder aufgrund
einer Verkettung unglücklicher Ereignisse entstehen, sind unter Störungen zusammengefasst. Störungen resultieren in erster Linie aus höherer Gewalt oder Fahrlässigkeit, können aber auch Folge eines Angriffs sein, wie z.B. bei einem DoS-Angriff, der
auf das Herbeiführen eines System-/ Anwendungsabsturzes abzielt oder z.B. ein
Wurm-Angriff der eine Manipulation der Firmware respektive Sensoren bewirkt, die
einen Hardwareschaden hervorrufen kann.
2.1.3 Angriffe und Angreifer
Angreifer unterscheiden sich in ihrer Qualifikation, Motivation und den eingesetzten
Mitteln erheblich. Die Angreiferklasse mit den wohl meisten Anhängern stellen
hierbei die sog. Skriptkiddies (abgeleitet von Skript und Kid) dar, die ein Gruppe
bestehend aus jugendlichen Angreifern bezeichnet. Diese greifen auf vorgefertigte,
automatisierte Angriffswerkzeuge (sog. Exploits oder Rootkits)2 zurück und können so
ohne tiefreichendes Grundwissen Angriffe durchführen. Bezeichnend für die Angreiferklasse der Hacker sind sehr versierte Angreifer, denen es durch individuell entwickelte Angriffsmethoden gelingt, auch in gesicherte Rechnernetze einzudringen. Diese
und weitere Angreiferklassen und deren jeweils markanteste Eigenschaften nach
Motivation, Know-how und zur Verfügung stehender Ressourcen zugeordnet, sind in
der folgenden Tabelle aufgeführt.
1
2
Zitat aus IT-Sicherheit: [12] Eckert, 2009, S. 17
Programme oder Befehlsfolgen, wobei Exploits auf Sicherheitslücken und Fehlfunktionen abzielen,
um Systeme anzugreifen und Rootkits speziell zur Erlangung und Verschleierung der Kontrolle (Administratorrechte) über Systeme genutzt werden.
8
Bezeichnung Motivation
Know-how
Ressourcen
 Langeweile gepaart mit
jugendlichem Leichtsinn
 Spieltrieb u. Neugier
 Streben nach Anerkennung
 Vandalismus
 Experimentierfreude
 subjektiver Gerechtigkeitssinn und Selbstjustiz
 Informationsfreiheit
 Streben nach Anerkennung
 höhere Ziele
 nicht unbedingt
technisch versiert
 bei zuletzt durchgeführten DDoS Angriffen
organisierter1
 technisch sehr versiert
 tiefreichendes Computergrundwissen
 entwickelt eigene bzw.
neue Exploits
 frei verfügbare
Exploits/ Rootkits
 viel Zeit
Cracker
 Profitgier
 persönliche Vorteile
 Schädigung Dritter
Mitarbeiter
 Frust
 Rachegelüste
 Profitgier
 persönliche Vorteile
 Vertuschung
 Mobbing
 Gewinnstreben
 Wettbewerbsvorteil
 Industrie- u. Unternehmensspionage
 Sabotage
 Profitgier
 Machtgier
 entwickelt eigene bzw.
neue Exploits
 nicht unbedingt
technisch versiert
 Insiderwissen
Skriptkiddie
Hacker
Wettbewerber
Krimineller
Geheimdienst/
Regierung
 Wirtschaftsspionage
 Verbrechensbekämpfung
 Gewinnung von Erkenntnissen zur innen-, außen- und
sicherheitspolitischen Lage
 politische Intervention
 Aufklärung, Vergeltung, und
Abwehr
 Sabotage
 starke Community
mit regem Wissensaustausch
 hohe verteilte
Rechnerleistung
u. Bandbreite
durch Community
 gehört unter
Umständen der
Hacker Community an
 Bot-Netze 2
 frei verfügbare
Exploits/ Rootkits
 bereits vorhandener (physischer)
Zugang/ Zugriff
 nicht unbedingt
technisch versiert
 hohes Budget
 beauftragter
Cracker
 hoher Organisationsgrad
 technisch versiert bis
sehr versiert
 hohes Budget
 beauftragter
Cracker
 greift auf eigene
Entwickler zurück
 hohes Budget
 viel Manpower
 hohe technische
Ausstattung
 beauftragter
Cracker
 Zusammenarbeit
mit Hacker
 Legislative
 hoher Organisationsgrad
Tabelle 2.1: Angreifer-Klassifikation
Der Begriff Cracker wird von den Medien kaum verwendet und stattdessen mit dem
Hacker unter einen Hut gesteckt. Zur ausreichenden Differenzierung ist daher zu1
2
gelangweilte Kids greifen Kreditkartenfirmen mit DDoS-Attacken an, vgl. [22] ZEIT ONLINE, 2011;
Distributed Denial of Service (DDoS) Attacken entsprechen einer verteilten Dienstblockade, d.h. der
Angriff erfolgt von mehreren Rechnern aus auf ein Opfersystem (ggf. Verwendung von Bot-Netzen2).
infizierte bzw. präparierte (Heim-)PCs mit Netzwerkanbindung, die zentral gesteuert gezielt für
verteilte Angriffe auf Opfersysteme genutzt werden und hierzu an Kriminelle vermietet werden, vgl.
[08] Symantec Corporation, 2011
9
sätzlich zu erwähnen, dass sich Hacker und Cracker zwar insbesondere hinsichtlich
ihrer Qualifikation ähneln bzw. ebenwürdig sind, aber Cracker meist beide Seiten
kennen bzw. alle Schattierungen durchlaufen haben1. Zwischen diesen beiden Gruppen ist demnach ein wichtiger Unterschied herauszustellen. Der Hacker gilt gemeinhin als ethisch2 handelnde Person, die sich selbst auch mit gemeinnützigen Beiträgen
wie z.B. dem Aufdecken von Sicherheitslücken und anschließender Veröffentlichung
identifiziert, mit dem Ziel, die Verantwortlichen dazu zu bewegen, diese zu schließen.
Der Cracker hingegen gilt als unmoralisch, handelt eigennützig, profitorientiert und
bietet hierzu seine Dienste auch (kriminellen) Dritten an.
Ein nicht unbeträchtliches Schadensrisiko geht ebenso von der Gruppe der Mitarbeiter aus. Laut einer Umfrage3 finden zwar mit 58% die meisten Angriffe von extern
(d.h. unautorisiert von außerhalb des Firmennetzwerks bzw. vor der demilitarisierten
Zone (DMZ) aus statt, jedoch sind die internen Angriffe (d.h. mit autorisiertem Zugang
oder Zugriff auf das Firmennetzwerk bzw. die Unternehmens-IT) mit 21% die kostspieligeren für das Unternehmen. Die restlichen 21% sind Angriffe, deren Ursprung
unbekannt ist. Dabei setzen Mitarbeiter zunehmend (22% in 2011 im Verhältnis zu 9%
in 2010) Angriffswerkzeuge wie z.B. Rootkits ein, die immer einfacher zu beschaffen
sind, was die Angriffe von innen heraus gefährlicher macht.4 Angriffe von Mitarbeitern sind zudem schwieriger zu erkennen, da für gewöhnlich die eingesetzten Sicherheitsmaßnahmen/ -mechanismen, wie z.B. Firewalls oder IDS, erstrangig auf den
Angriff von extern ausgelegt werden. Darüber hinaus haben Mitarbeiter - im Gegensatz zu externen Angreifern - den Vorteil über Insiderwissen zu verfügen, was einen
zielgerichteten Angriff mit weniger hinterlassenen Spuren erlaubt. Ein sehr ernstes
Problem aus Mitarbeiter-Angriffen ergibt sich für die Unternehmen (insbesondere
FDL) durch die unberechtigte Weitergabe von (geheimen) Informationen bzw. dem
1
2
3
4
Mit gesetzlicher Würdigung der Computerkriminalität begann sich die Unterscheidung zwischen
White-Hat-, Grey-Hat- und Black-Hat-Hackern, abhängig von der Gesetzestreue bei ihren Handlungen, zu etablieren. Es handelt sich hierbei um eine Ableitung auf Basis alter Western-Filme, wo
Cowboys mit weißem Hut gute, grauem Hut zwischen Gut und Böse sowie schwarzem Hut böse
Charakter repräsentierten. Cracker sind den Black-Hats zugeordnet. Grey-Hats sind Hacker, die
illegale Handlungen durchführen, um dabei ein höheres Ziel zu verfolgen. White-Hats sind gesetzestreue Hacker. Vgl. [23] Cisco Networking Academy, 2006, S. 21 ff.
Hacker erlegen sich selber Werte auf, nach denen sie handeln, vgl. [24] Chaos Computer Club, 2011
2011 CYBERSECURITY WATCH SURVEY vgl. [25] CSO magazine, U.S. Secret Service, Software
Engineering Institute CERT Program at Carnegie Mellon University and Deloitte, 2011
vgl. [25] CSO magazine, U.S. Secret Service, Software Engineering Institute CERT Program at Carnegie
Mellon University and Deloitte, 2011, [07] BKA und BITKOM, 2010
10
Datendiebstahl1 sowie dem Betrug in Verbindung mit Computermissbrauch. Auf die
Weise von Letzterem werden Gelder veruntreut, elektronisch verarbeitete Urkunden
oder Abrechnungen gefälscht und Richtlinien und deren computergestützte Geschäftsprozesse ausgetrickst2, um sich selbst oder (bekannten) Dritten Vorteile zu
verschaffen.
Aus Sicht der FDL stellt die Gruppe der Kriminellen ein besonders hohes Schadensrisiko dar, denn es sind insbesondere die Banken und ihre Kunden, die im Fokus dieser
Angreiferklasse liegen. Hauptsächlich sind es sog. Skimming-Angriffe - der Betrug
mittels rechtswidrig erlangter Kredit- oder Bankkartendaten mit PIN - und sog.
Phishing-Angriffe - der Betrug mittels ausgespähten Zugangsberechtigungsdaten
(engl. credentials) für Kommunikationsdienste wie z.B. dem Online Banking der Bank die von dieser Gruppe praktiziert werden. Angreifer dieser Art sind international aktiv
und gleichen mit ihrem Organisationsgrad und -aufbau multinational agierenden
Unternehmen. Sie haben eine Spitze, die alles koordiniert, Bereiche, die Entwicklungs-, Design- und Abwicklungsaufgaben, wie z.B. die Geldwäsche und das damit
verbundene Anwerben von sog. Finanzagenten (engl. money mules) nachgehen und
hiervon entsprechende Pendants in unterschiedlichen Ländern. Die Beteiligten
solcher Cybercrime-Ringe, von denen die wenigsten einen Überblick über die gesamte
Organisation haben, kommunizieren untereinander mit Pseudonymen und größtenteils über gesicherte Verbindungen, was ein entsprechendes Aufdecken bzw. Bekämpfen dieser Gruppe und deren Aktivitäten erschwert. Dabei stehlen einzelne
Ringe bis zu 72 Mio. US-Dollar von Bankkonten in über 10 Ländern durch den Einsatz
von Malware (engl. für Schadprogramm).3
Neben der Vielfalt der Angreifer sind es diverse Angriffs-Arten mit denen sich Unternehmen auseinandersetzen müssen. Wie dem folgenden Ausschnitt einer Studie
jedoch zu entnehmen ist, ist die Unternehmens-IT in den meisten Fällen Angriffen in
Verbindung mit eingesetzter Malware ausgesetzt.
1
2
3
Einer Schweizer Bank mit etwa 50.000 Mitarbeitern weltweit werden 1.500 Datensätze mutmaßlicher Steuerhinterzieher entwendet und dem Fiskus durch einen unbekannten Informanten angeboten, vgl. [26] Süddeutsche Zeitung GmbH, 2010
z.B. werden Kennzahlen einer automatisierten Bonitätsanalyse modifiziert, um die Finanzierungsbewilligung durch das System zu manipulieren oder Negativmerkmale des Kunden aus der Datenbank
gelöscht oder pseudo Baufinanzierungskunden im System erfasst, um eine Auszahlung zu erreichen.
In diesem Fall wurde der Wurm Conficker verwendet, vgl. [27] ISMG Corp., 2011
11
Abbildung 2.3: Unternehmenserfahrungen mit Angriffen auf die IT1
Selbstverständlich ist – aufgrund befürchteter Reputationsschäden des IT-SicherheitsVerantwortlichen sowie unter Umständen ohne Kenntnis des Unternehmens stattgefundener Angriffe – dem Ergebnis solcher Befragungen zu unterstellen, dass nicht alle
Angriffe benannt wurden. Dennoch zeichnet sich bei Angriffen deutlich die Erfahrung
mit Malware ab. Die FDL sehen sich bzw. ihre Kunden ebenfalls in Form von PhishingAngriffen mit Malware konfrontiert, wobei Skimming-Angriffe für Institute die weitaus größere Bedrohung darstellen.2 Besonders erwähnenswert bei beiden Angriffsarten ist, dass lediglich jeder 4. Fall durch die Bank erkannt wird und beim Rest vom
betroffenen Kunden darauf aufmerksam gemacht wird.3 Was im Umkehrschluss
bedeutet, dass in den meisten Fällen erst spät, nämlich wenn der Schaden bereits
eingetreten und der Angriff vollzogen ist, Kenntnis erlangt wird und so keine Möglich1
2
3
Quelle: [17] IDC Central Europe GmbH, Juli 2010
Top Bedrohung bei Banken: Skimming (83%), Phishing (40%) vgl. [18] FICO - Fair Isaac Corporation,
2011
75% der Schäden bei Banken werden zuerst durch den Kunden erkannt, vgl. [18] FICO - Fair Isaac
Corporation, 2011
12
keit mehr zur Eingrenzung oder zum Vereiteln besteht. Dieser Missstand lässt sich bei
derartiger Angriffs-Konstellation hauptsächlich auf die Schwierigkeit die Schwachstellen bei den eingesetzten Endgeräten ausreichend abzusichern (engl. EndpointSecurity)1 zurückführen. So ist es aus Bankperspektive bspw. nahezu unmöglich,
weder den vom Kunden für das Online Banking eingesetzten PC noch den Kunden
selbst – dem sog. Social Engineering2 – vor Manipulationen zu schützen. Das Ergreifen
entsprechender Schutzmaßnahmen, wie z.B. der Einsatz von Firewalls oder Antivirusprogrammen auf dem heimischen PC, obliegt (bisher)3 allein dem Kunden.4
2.1.4 Risiken und Schwachstellen
Wie bereits erwähnt ergeben sich in der IT-Sicherheit (Schadens-)Risiken für die
Unternehmenswerte aus konkreten Gefährdungen, die wiederum entstehen, wenn
Bedrohungen auf vorhandene Schwachstellen oder Verwundbarkeiten (engl. vulnerability) treffen und diese ausnutzen (vgl. 2.5 Attack-Trees Methode). Ein Risiko ist
demnach ein potenzieller Schaden, der noch nicht eingetreten ist.
Die Identifikation mit anschließender Quantifizierung dieser Risiken – in Form der
Risikoanalyse – ist maßgeblich für die Entscheidung über den Umgang mit den der
Risiken zugrundeliegenden Bedrohungen bzw. potenziell eintretenden, schädigenden
Ereignissen. Den IT-Sicherheits-Verantwortlichen sowie dem Management dient die
Risikoanalyse somit als Hilfe, darüber zu entscheiden, auf welche Weise (i.S.v. Vermeidung, Reduktion, Eliminierung, Transfer oder Akzeptanz)5 man Risiken entgegnet
und in welchem Umfang Sicherheitsmaßnahmen ergriffen werden. Darüber hinaus
bietet sie eine Grundlage für die Freigabe der etwaigen damit verbundenen Investitionen bzw. einer entsprechenden Kosten-Nutzen-Analyse.
1
Endpoint-Security befasst sich mit dem Schutz von Geräten am Kommunikationsendpunkt, was
Endgeräte wie z.B. PCs, Smartphones, Geldautomaten und Point of Sale (POS) Terminals betrifft.
2
zwischenmenschliche (nicht zwingend persönlich stattfindende) Einflussnahme bzw. Manipulation,
um an geheime Informationen oder Credentials zu gelangen, vgl. [12] Eckert, 2009, S. 61 f.
3
Trusted Computing könnte hier zur Situationsverbesserung genutzt werden, vgl. [28] BSI, 2011
4
FDL auferlegen ihren Kunden in Form der AGB Sorgfaltspflichten, wie die Verpflichtung: „…für sein
eigenes Computersystem die notwendigen Sicherheitsvorkehrungen zu treffen und insbesondere
sein Computersystem angemessen gegen den unbefugten Zugriff durch Dritte sowie gegen Computerviren zu schützen. Der Kunde trägt sämtliche Folgen, die sich aus der Preisgabe und der, auch
missbräuchlichen, Verwendung seiner Legitimationsmerkmale…“, um sich schadlos zu halten, vgl.
[29] VZ Depotbank AG, 2011
5
vgl. [23] Cisco Networking Academy, 2006, S. 12
13
Generell liefert die Risikoanalyse hierzu, auch wenn es eine große Auswahl an unterschiedlichen, verfeinernden Methoden wie z.B. Trike, DREAD oder OCTAVE gibt, 1
einen qualitativen oder quantitativen 2 Vergleichswert. Die dabei wohl gängigste
Vorgehensweise und der Ausgangspunkt vieler Methoden, ist das Risiko als Produkt
von Eintrittswahrscheinlichkeit und Schadenshöhe zu berechnen. 3
R  P S
Die Wahrscheinlichkeit bzw. Häufigkeit eines Ereigniseintritts (P) wird multipliziert mit
der Summe aus direkten und Folgeschäden (S) und ergibt so im Produkt das Risiko (R).
Wenn am Beispiel des Skimming-Angriffs einer Bank der mögliche Schaden pro
Ereignis 1.000 Euro beträgt und die Wahrscheinlichkeit, dass dieses Ereignis eintritt,
mit 13 mal täglich gegeben ist, ergibt sich ein jährliches Risiko von 4,68 Mio. Euro p.a..
1.000 Euro  4.680 Ereignisse p.a. = 4.680.000 Euro p.a.
Um die Gleichung mit Werten zur Eintrittswahrscheinlichkeit und Schadenshöhe zu
füllen, wird in der Praxis auf Erfahrungswerte von Experten, aus bereits stattgefundenen Schäden oder Veröffentlichungen sowie aus bestehenden Schadensfalldatenbanken zurückgegriffen. Dabei ist es insbesondere bei der Eintrittswahrscheinlichkeit
wichtig, die für das zu ermittelnde Risiko zugrundeliegende Schwachstelle zu kennen.
Der allgemeinbekannte Satz: „Eine Kette ist nur so stark wie ihr schwächstes Glied“,
trifft auch auf die IT-Sicherheit und insbesondere auf die Schwachstellen zu. Deutlich
wird diese dann, wenn man sich die bereits bei gewöhnlichen Unternehmen eingesetzten zahlreichen Systeme und Subsysteme in der IT vor Augen führt und erst recht,
wenn man berücksichtigt, dass die Kette beim Benutzer beginnt.4 Schwachstellen, die
den Ausgangspunkt der Risiken ausmachen, sind allgegenwärtig und resultieren aus 5:
 Programmierfehlern, die z.B. zulassen, dass Pufferüberläufe (engl. buffer
overflows)6 durch Viren im E-Mail Attachement ausgenutzt werden,
1
2
3
4
5
6
vgl. [30] Larcom, Saitta, Eddington, & Smith, 2005, [31] Bryan Sullivan - Microsoft Security
Development, 2011, [32] Carnegie Mellon University, 2011, [12] Eckert, 2009, S. 209 f.
Wobei die Quantitative Risikoanalyse vom Management oft pervertiert wird, in der Praxis jedoch
kaum möglich ist, da trotz etwaig vorhandener Erfahrungswerte jedes Unternehmen sowie jede
zugrundeliegende Bedrohungsanalyse auf eine individuelle Betrachtung hinausläuft.
vgl . [12] Eckert, 2009, S. 188, Ursprung dieser Methode im FIPS 65 des NIST vgl. [33] NIST, 1994
vgl. [12] Eckert, 2009, S. 38 f.
vgl. [34] BSI, 2011, [23] Cisco Networking Academy, 2006, S. 2 und 18 ff.
Beim Pufferüberlauf werden Sicherheitslücken in der Software ausgenutzt, die im Wesentlichen
darauf beruhen, dass aufgrund Versäumnissen in der Programmierung, Dateneingaben keiner Rest-
14
 mangelhaftem Netzwerkdesign, wie z.B. keine Durchführung des doppelten
Reverse Lookups bei DNS-Servern, was ein DNS-Spoofing1 erlaubt,
 Konfigurationsfehlern bei Hard- und Software, die z.B. dazu führen, dass
Passwörter, obwohl sie eigentlich verschlüsselt sein sollten, im Klartext übertragen werden oder von vornherein zu einfach erraten werden können,
 Konzeptionsfehlern in Programmiersprachen, die z.B. Programmen den Zugriff
auf Systemressourcen erlauben, obwohl sie diese nicht benötigen sowie
 menschlichem Fehlverhalten und Unachtsamkeit, z.B. beim bereits erwähnten
Social Engineering, wenn ein Benutzer aufgrund einer Phishing-Mail seine PIN
und TAN in falsche Hände gibt oder seine Zugangsdaten auf einem Zettel unter der Tastatur aufbewahrt.
Die Anzahl der aufkommenden und zu beachtenden Schwachstellen hängt verständlicherweise hauptsächlich davon ab, in welchem Umfang IT-Systeme betrieben werden. Bezogen auf die FDL ergeben sich aufgrund der bereits in der Einleitung erwähnten Komplexität und Dimension der eingesetzten IT mit zahlreichen verteilten Systemen entsprechend viele zu berücksichtigende Schwachstellen bzw. Angriffspunkte.
Einen Überblick über die IT-Infrastruktur bei FDL gibt der folgende Abschnitt.
2.2 Informationstechnologie bei FDL
Finanzdienstleistungshäuser betreiben, angefangen mit den Geldausgabesystemen,
über das Online Banking, bis hin zu Zahlungsverkehrsabwicklungssystemen, eine
beachtliche Bandbreite sicherheitskritischer IT-Systeme.2 Charakteristisch für eine
dementsprechend komplexe IT-Infrastruktur ist die Vielfalt betrieblicher Anwendungen, ein hoher Grad an Vernetzung und Automatisierung sowie umfangreiche verteilte Systeme als auch ein starker regulatorischer Einfluss auf die gesamte IT.
1
2
riktion nach Größe oder Typ unterliegen, sodass diese Datenmengen in einen dafür zu kleinen reservierten Speicherbereich, den Puffer, geschrieben wird und dadurch hinter dem Ziel-Speicherbereich
liegende Speicherstellen, die als ausführbarer Code deklariert sind oder die Rücksprungadresse eines
Unterprogramms enthalten, überschrieben werden.
Beim DNS-Spoofing handelt es sich um die Manipulation der Zuordnung zwischen einem Rechnernamen und der zugehörigen IP-Adresse, um so Kontrolle über den Datenverkehr zwischen zwei oder
mehreren Kommunikationspartnern zu erlangen.
vgl. [35] Anderson, 2. Auflage 11. April 2008, S. 6 und 313ff.
15
2.2.1 Betriebliche Anwendungen
Die Aufgaben und damit verbundenen Anwendungen bei einem FDL decken ein
breites Spektrum ab und lassen sich, wie in der folgenden Abbildung dargestellt,
klassisch in die Bereiche Vertrieb, Marktfolge und Abwicklung unterteilen.
Abbildung 2.4: Übersicht betrieblicher Anwendungen eines Finanzdienstleisters1
Unter den Bereich Vertrieb fallen sämtliche Anwendungen, die sog. Front-Ends2 für
Kunden und Mitarbeiter bereitstellen. Diese unterstützen sowohl den stationären
Vertrieb, wie z.B. den Filialmitarbeiter, der den Kunden im Nachgang zu einer Schalterzeinzahlung zu einem Produktabschluss berät, als auch rein digitale Kanäle, bei
dem der Kunde z.B. von zu Hause aus über das Homebanking eine Onlineüberweisung
beauftragen kann.
Im Bereich der sich anschließenden Marktfolge sind es Anwendungen, die für die
Nachbearbeitungen und das Kontenmanagement eingesetzt werden. Anwendungen
dieses Bereiches werden auch als Kernanwendung oder kontoführendes System
bezeichnet. Zu den hier aufgeführten Anwendungen zählt die für jedes Produkt
hinterlegte Businesslogik, die z.B. für einen Kontokorrentkredit am Girokonto entsprechende Funktionen für die Limitsteuerung und deren Zins-/Entgeltabrechnung
mit anschließender Verbuchung durchführt.
1
2
in Anlehnung an [36] Gerber, 2011
Front-Ends wie u.a. Clientanwendungen, graphische Benutzeroberflächen und Internetservices.
16
Der Bereich Abwicklung beinhaltet Anwendungen, die zur Durchführung von Clearingund Settlement-Aufgaben, wie z.B. das Versenden bzw. Entgegennehmen und Abwickeln von bankübergreifenden Zahlungsauftragsnachrichten über das SWIFT-Netz1
mit anschließender Weitergabe an das kontoführende System zur korrekten Buchung
am Konto, erforderlich sind und Informationen zu deren Verarbeitung liefern. Wie das
Beispiel zeigt, fallen unter diesen Bereich auch entsprechende externe Schnittstellen
zur (Massen-)Abwicklung von z.B. Wertpapier- und Zahlungsverkehrstransaktionen.
Den aus den drei Bereichen stammenden operativen Anwendungen sind strategische
Querschnittsfunktionen übergeordnet, die es ermöglichen, steuernde Funktionen
wahrzunehmen. Zu den originären Aufgaben des FDL zählt hierbei das Aktiv-PassivManagement2, das drauf angewiesen ist, dass sämtliche stattgefundene Geldmittelzuflüsse (z.B. aus Spareinlagenbuchungen der Kunden) und -abflüsse (z.B. aus Finanzierungsauszahlungen) zeitnah als Information vorliegen. Dies setzt eine entsprechendes
(vertikales) Interagieren zwischen den Anwendungen, die in der Regel auf verteilten
Systemen abgebildet sind (vgl. 2.2.2 Vernetzung und verteilte Systeme), voraus. Das
Erfordernis, dass Anwendungen bzw. Systeme miteinander in Interaktion treten,
ergibt sich ebenso bereichsübergreifend auf der (horizontalen) Ebene der operativen
Anwendungen, was anhand des Ablaufs der oben aufgeführten Beispiele ([Front-EndSystem]: Eingabe einer Onlineüberweisung -> [Kontoführendes System]: Disposition
und Buchung am Konto <-> [Abwicklungs-System]: Clearing des Zahlungsauftrags),
deutlich wird.
2.2.2 Vernetzung und verteilte Systeme
Typisch für die IT-Infrastruktur bei Finanzdienstleistungshäusern und damit die
Komplexität maßgeblich beeinflussend, sind ein hoher Grad an Vernetzung sowie
umfangreiche verteilte Systeme. So ist es insbesondere für die Ausführung der operativen Aufgaben erforderlich, dass der Datenaustausch zwischen den Rechnern der
Mitarbeiter untereinander als auch mit dem Rechnerverbund von Kernanwendungen
1
Die Gesellschaft Society for Worldwide Interbank Financial Telecommunication (SWIFT) betreibt ein
weltweites Telekommunikationsnetz für den Nachrichtenaustausch zwischen den Mitgliedern, primär
Finanzinstituten.
2
Management der gesamten Bilanz- und Konditionenstruktur zur Gestaltung optimaler Aktiv- und
Passivpositionen i.S.v. Unternehmenszielsetzung und unter Beachtung gesetzlicher Vorschriften, vgl.
[37] Krumnow, Gramlich, Lange, Dewner, & (Hrsg.), 2002, S. 31 und 1270 f.
17
bzw. -systemen möglich ist. Die Vernetzung ist dabei auf keine lokale Lösung (LAN)
begrenzt, sondern erstreckt sich ebenso über dezentrale Standorte (WAN), um alle
relevanten Unternehmensteile einzubeziehen, was je nach Geschäftsausprägung über
Ländergrenzen hinweg erfolgen kann, wie die unten abgebildete IT-Architektur der
Raiffeisen Zentralbank beispielhaft veranschaulicht.
Abbildung 2.5: IT-Architektur der RZB1
Neben diesem internen Datenfluss im sog. Intranet ist es für ein marktgerechtes
Angebot unerlässlich seinen Kunden bzw. Geschäftspartnern von außerhalb einen
kontrollierten Zugriff zur komfortablen Abwicklung von Finanzgeschäften, z.B. zur
Durchführung einer Onlineüberweisung, anzubieten. Für diesen Informationsaustausch im Internet oder Extranet betreiben Finanzinstitute diverse Zugänge, damit
eine bedarfsorientierte Vernetzung – auf Basis der Kommunikationswege über Festals auch Funknetz - von externen mit internen Rechnern erfolgen kann.
Um die innerhalb eines solchen Rechnernetzes stattfindenden unternehmensinternen
sowie -übergreifenden Geschäftsprozesse ausreichend zu unterstützen, sind zahlreiche IT-Funktionen aus unterschiedlichsten Aufgabenbereichen notwendig (vgl. 2.2.1
Betriebliche Anwendungen), die verteilt auf miteinander interagierenden TeilAnwendungen bzw. Systemen kooperativ abgewickelt werden. Der Funktionsumfang
und deren Frequentierung sind dabei so enorm, dass in der Praxis die von einzelnen
Finanzinstituten eingesetzten verteilten IT-Systeme bemerkenswerte Dimensionen
von rund 5.000 Anwendungen auf über 21.000 Servern annehmen 2, was zugleich eine
1
2
die RZB ist in 17 Märkten aktiv, Quelle: [38] Oracle - Open World Conference, 2008
durch Deutsche Bank betriebene Anwendungen und Server, vgl. [03] IBM Deutschland GmbH, 2011
18
entsprechend hohe Anzahl zu berücksichtigender Schwachstellen bzw. Angriffspunkte mit sich bringt (vgl. 2.1.4 Risiken und Schwachstellen).
2.2.3 Sicherheitskritische Geschäftsprozesse und Ereignisse
Es ist naheliegend, dass bei Unternehmen, deren Kerngeschäft auf den ihnen anvertrauten Finanzen ihrer Kunden basiert, ein besonderes Augenmerk auf die Sicherheit
gelegt werden muss. Gewissermaßen jeder originäre Geschäftsprozess aus dem
Finanzbereich weist die Gemeinsamkeit auf, in Bezug zu Geldern oder Informationen
Dritter zu stehen, was wiederum sowohl ein interessantes Ziel für Angriffe darstellt
als auch weitreichende Konsequenzen bei Störungen nach sich zieht, bei denen das
Unternehmen generell zur Haftung herangezogen werden kann oder Schäden erleidet. Solche als sicherheitsrelevant zu erachtende Geschäftsprozesse – wie z.B. Bargeldabhebungen – ballen sich förmlich in den Häusern der FDL. Dabei treiben FDL die
durchgängige Automatisierung (i.S.v. STP) sukzessive voran, um dem stetigen Bestreben nach Rentabilität wie auch den wachsenden Ansprüchen ihrer Kunden nachzukommen. In der Praxis führt dieses dazu, dass sicherheitskritische Geschäftsprozesse
zunehmend auf IT-Systemen abgebildet sind, die zwar vom Menschen genutzt werden, der komplette 1 (Funktions-) Ablauf für ihn jedoch zum größten Teil im Verborgenen bleibt und die ordnungsgemäße Durchführung von ihm ohne Weiteres nicht
kontrolliert bzw. gewährleitstet werden kann. Hierzu bedarf es der Unterstützung
technischer Hilfsmittel, die den Geschäftsprozess vor dem Einwirken sicherheitskritischer Ereignisse (engl. Events), welche die Datensicherheit bedrohen bzw. zu unzulässigen (System-) Zuständen führen (vgl. 2.1.1 Grundwerte der IT-Sicherheit), schützen
sowie darüber informieren. Am Bsp. der Bargeldauszahlungen kann so ein SkimmingAngriff am Geldautomaten frühzeitig erkannt werden, indem Ereignisse wie z.B. die
mehrfache Karteneinführung mit anschließendem Transaktionsabbruch – was dem
Justieren des angebrachten Skimming-Moduls dient – sowie das Detektieren des
durch das Skimming-Modul erzeugte Magnetfeld, zusammengefasst (vgl. 2.3.6 Correlation) und als sicherheitsrelevant berücksichtigt werden.
Die erwähnte Automatisierung wiederum geht mit einer Standardisierung der in der
Branche eingesetzten IT-Komponenten einher. So wird in der Regel für Anwendun1
vom Anfang bis zum Ende, i.S.v. End to End (E2E)
19
gen, wie z.B. für die Wertpapiertransaktionsabwicklungen oder bei Internetportalen
für Kunden, auf Komplett- oder Teillösungen weniger spezialisierter Branchensoftwareanbieter zurückgegriffen. Auf der einen Seite kann so im Vergleich zu vollkommen eigenen Softwareentwicklungen besonders vor dem Hintergrund der ITSicherheit von bereits etablierten und resistenten Lösungen profitiert werden, auf der
anderen Seite finden jedoch so eine einmal entdeckte Sicherheitslücke in häufigen
Fällen auch Anwendung auf die gesamte Branche.
Eine sich aufgetane Schwachstelle bei IT gestützten Geschäftsprozessen eines (Teil-)
Unternehmens kann so meist gleich oder ähnlich in anderen vorgefunden und durch
dieselben Angriffsmethoden bzw. Exploits ausgenutzt werden. Diese angewandten
Angriffe bestehen aus respektive verursachen für gewöhnlich aufeinander aufbauende Ereignisse (z.B. das Scannen nach offenen Ports, Serverstarts und -stopps, unberechtigte Zugriffsversuche oder Zugriffe auf besonders sensible Daten), um Systeme
auszuspähen oder in diese einzudringen. Solche sicherheitskritischen Ereignisse sind
für die Abwehr von Angriffen zeitnah zu erkennen und zu interpretieren. Dieses kann
durch den Einsatz von technischen Hilfsmitteln wie dem SIEMs realisiert werden.
2.2.4 Datenschutz, Datensicherheit und Compliance
Die Finanzunternehmen gelten zuweilen als am strengsten reguliert und unterliegen
der Aufsicht zahlreicher Behörden. Dieses spiegelt sich auch in der von FDL verwendeten IT wider. So ist z.B. das Bundesdatenschutzgesetz (BDSG) und bei Banken
insbesondere das Bankgeheimnis die sich wohl am häufigsten an den Geschäftsprozessen entlanghangelnde zu berücksichtigende Bestimmung bzw. Verpflichtung. Dem
Datenschutz, der den Schutz personenbezogener Daten regelt, kommen FDL insofern
nach, dass organisatorische und technische Maßnahmen zum Datenschutz ergriffen
werden, sodass der Datenzugriff ausschließlich kontrolliert durch Berechtigte und
keine unbefugte Datenmanipulation erfolgt. Neben dem Datenschutz, der die Privatsphäre und das damit verbundene Recht auf die informelle Selbstbestimmung
jedes einzelnen vor Missbrauch schützt, ist es die nicht miteinander zu verwechselnde
Datensicherheit, die übergeordnet auf der Ebene allgemeiner sensibler Daten bzw.
Informationen für deren Integrität, Verfügbarkeit und Vertraulichkeit relevant ist (vgl.
2.1.1 Grundwerte der IT-Sicherheit).
20
Vor diesem Hintergrund sehen sich FDL auf der einen Seite konfrontiert mit Angriffen,
wie z.B. Skimming- und Phishing-Attacken, dessen Aktionsradius prinzipiell außerhalb
der IT-Infrastruktur der FDL liegt und somit Schwachstellen ausnutzt, die nur schwer
oder lückenhaft vom FDL abgesichert werden können, um der Datensicherheit und
dem Datenschutz gerecht zu werden. Auf der anderen Seite zeigt sich aber auch, dass
trotz aufwendiger Sicherheitsmaßnahmen Verwundbarkeiten innerhalb der ITInfrastruktur der FDL ausgenutzt werden und ein Problem darstellen. So war es z.B.
möglich, dass unbekannte Angreifer das komplette eBanking eines Kreditinstituts für
2 Tage lahmlegen, Teile eines zentralen Abwicklungssystems für ein nationales Bezahlverfahren (sog. ACH) ausfallen bzw. für die gesamten Banken des Landes nicht
mehr verfügbar sind1 oder über einen Zeitraum von etwa einem Monat Zugang zu
vertraulichen Daten im gesicherten Rechnernetzwerk der Weltbank erlangen. Weitere Compliance relevante Regularien, die unterschiedlichste Anforderungen und
Inhalte mit Belangen für die IT-Sicherheit mit sich bringen, sind in der unten stehenden Tabelle2 aufgeführt. Die ebenfalls enthaltenen Aufbewahrungsfristen lassen auf
den mit der Erfüllung dieser Anforderungen verbundenen Aufwand3 schließen, der
wie das Überwachen von sicherheitskritischen Ereignissen durch den Einsatz von
SIEMs optimiert werden kann bzw. überhaupt erst zu handeln ist.
Tabelle 2.2 Fristen zur Aufbewahrung regulierter Daten
1
2
3
vgl. [39] Bakker, 2011
Quelle: ArcSight, Fristen nach Auslegung von ArcSight.
Der Anforderungskatalog des Payment Card Industry Data Security Standards (PCI) z.B. enthält
konkrete Bestimmungen zu 12 Punkten von der Installation und Pflege einer Firewall, über den
Einsatz und regelmäßigem Update von Virenschutzprogrammen, bis hin zur Einführung und Einhaltung von Richtlinien in Bezug auf die Informationssicherheit.
21
2.3 Security Information and Event Management (SIEM)
SIEM wird aufgrund seiner Entstehungsgeschichte in Bezug gebracht oder auch nicht
selten gleichgesetzt mit SIM (Security Information Management) und SEM (Security
Event Management).1 Die Entwicklung von SIEMs führte die bekannten Konzepte des
SIM2 und SEM3 zusammen und bietet somit eine komfortable und zentrale Verarbeitungsmöglichkeit sämtlicher sicherheitsrelevanter Informationen.
Der folgende Abschnitt gibt einen Überblick über das Einsatzumfeld und Zusammenspiel mit anderen Systemen und befasst sich darüber hinaus mit den Komponenten
eines SIEMs und deren Funktionen.
2.3.1 Einsatzumfeld von SIEM Lösungen
SIEMs sind effektive Hilfsmittel 4, die eingesetzt werden, um komplexe IT-Systeme zu
überwachen. Sie dienen dem Zweck, das IT-Sicherheits-Personal bei der Erkennung
und anschließenden Handhabung von auftretenden Sicherheitsbedrohungen bzw.
Angriffen zu unterstützen und den Anforderungen aus Compliance zu entsprechen.
Eine Betrachtung, die SIEM auf eine isolierte Anwendung reduziert, wird diesen
Systemen nicht gerecht. Stattdessen handelt es sich bei dem Einsatz von SIEMs
vielmehr um SIEM Lösungen, die sich über organisatorische Aspekte sowie die gesamte IT-Infrastruktur erstrecken und so, je nachdem wie ausgeklügelt und umfangreich
diese sind, ein hohes Potenzial hinsichtlich einer effizienten Gestaltung operativer
und strategischer Aufgaben des Sicherheitsmanagements bieten.
Abgesehen vom Leistungsvermögen des SIEMs selbst, ist es naheliegend, dass das
Heben dieses Potenzials maßgeblich davon abhängt, wie gut das SIEMs mit dem
Umfeld verzahnt (i.S.v.: Sind die Informations- und Ereignis- Quellen ausreichend
einbezogen?) und auf das darunterliegende Geschäftsmodell ausgerichtet ist (i.S.v.:
Sind die Verhaltensregeln sinnvoll hinterlegt bzw. konfiguriert? Kann die Korrelation
1
2
3
4
vgl. u.a. [06] Williams, 2007, [41] Gartner, 2011, [42] intiGrow, 2011, [43] Nicolett, 2010
in der Hauptsache das umfassende Sammeln, Speichern und Analysieren von Logdaten nach Compliance Gesichtspunkten primär von Host-Systemen und Anwendungen, vgl. [42] intiGrow, 2011
im Wesentlichen das Sammeln von Ereignissen mit dem größeren Fokus auf Netzwerksicherheitskomponenten und deren Verarbeitung in Echtzeit, vgl. [42] intiGrow, 2011
vgl. [02] Ponemon Institute LLC, 2010
22
auf ausreichend präzise Kontext-Informationen zurückgreifen?). Um diese Maßgaben
zu erfüllen, ist es wichtig die Funktionsweise von SIEMs zu verstehen.
Abbildung 2.6: Überblick einer SIEM Lösung
1
2.3.2 Funktionsweise von SIEMs
Die Auswahl an auf dem Markt befindlichen SIEMs ist groß und selbstverständlich
lassen sich Unterschiede in deren Leistungsmerkmalen feststellen.2 Das zugrundeliegende Funktionskonzept von SIEMs und deren Komponenten gleichen sich jedoch. 3
Wie bereits erwähnt, sind die beiden Konzepte SIM und SEM in SIEM integriert.
Folglich lassen sich die Komponenten – aufgrund ihrer Kernfunktionen auch CoreEngines genannt – Collection, Normalization, Aggregation, Correlation und Reporting
in SIEMs wiederfinden. Bei der Verarbeitung von sicherheitsrelevanten Informationen
bzw. Ereignissen werden diese Komponenten als Prozess innerhalb des SIEMs durchlaufen. Wie die folgende Abbildung zeigt, beginnt der Prozess mit dem Erfassen bzw.
Einsammeln (engl. collection) relevanter Informationen, die aus den unterschiedlichsten Quellen stammen und endet mit dem Reporting, bei dem im Grunde genommen
die erzielten Verarbeitungsergebnisse präsentiert werden. Die einzelnen Funktionskomponenten werden in den folgenden Abschnitten detailliert beschrieben.
1
2
3
in Anlehnung an [44] Tier-3, 2011
Gartner nimmt mit dem „Magischen Quadranten“ eine jährlich Bewertung an einer Auswahl von
etwa 25 SIEM-Anbietern vor, vgl. [41] Gartner, 2011
vgl. u.a. [45] ArcSight, Inc., 2010, [46] Q1 Labs, 2011, [47] AlienVault, 2011
23
Abbildung 2.7: Komponenten eines SIEMs1
2.3.3 Collection
Die Collection bildet den Anfang der Verarbeitungskette in SIEMs und ist zuständig für
das Erfassen bzw. Sammeln sicherheitsrelevanter Informationen. Bei den Informationen handelt es sich um die Protokollierung von Ereignissen, die in Form von Eventbzw. Logdaten von den unterschiedlichsten Systemen (z.B. Servern, Firewalls, Anwendungen, Betriebssystemen usw.) generiert werden. Die Übertragung zwischen
eventliefernden Systemen und SIEMs kann mit oder ohne den Einsatz von sog. Agenten2 erfolgen. So unterstützen einige eventliefernde Systeme Standardprotokolle wie
z.B. SNMP, Syslog, Samba usw.3, die von der Collection-Komponente des SIEMs in der
Regel ohne weiteres verarbeitet werden können. Bei eventliefernden Systemen, die
hierzu nicht in der Lage sind, müssen Agenten eingesetzt werden, die auf den betreffenden Systemen zusätzlich implementiert sind und diese Aufgabe übernehmen.
Unabhängig davon, ob mit oder ohne Agent eingesammelt wird, stehen die zwei
Mechanismen Push oder Pull zur Auswahl.4 Bei Push gibt das eventliefernde System
den Takt für den Zeitpunkt der Übertragungen vor. Bei Pull ist es wiederum das
1
2
3
4
in Anlehnung an [43] Nicolett, 2010
Software, die vom selben Anbieter wie vom verwendeten SIEMs oder auch Dritten stammen kann,
alternativ auch Open Source (GNU General Public License) erhältlich, vgl. [48] Intersect Alliance Pty
Ltd., 2008
vgl. [49] AlienVault LC, 2011, S. 168
vgl. [50] ArcSight, Inc., 2009
24
SIEMs, dass die Übertragung steuert. In diesem Zusammenhang bieten SIEMs von
Haus aus die Möglichkeit Transportprotokolle wie z.B. TLS (Transport Layer Security)
über TCP oder SNMP (Simple Network Management Protocol)1 zu nutzen, um eine
sichere Übertragung zu gewährleisten.2
2.3.4 Normalization
Liegen die Daten einmal vor, ist es die Normalisierung (engl. normalization), die sich
der Collection anschließt und - da sich unter den Herstellern von eventliefernden
Systemen bisher noch kein Standard etabliert hat 3 - die meist unterschiedlichen
Formate in eine vergleichbare Form bringt.
Vor diesem Hintergrund unterstützen SIEMs bereits eine Auswahl an Formaten bzw.
eventliefernder Systeme (wie z.B. Apache, Cisco IDS, Kaspersky AV Kit, Microsoft IIS
und Xirrus) „out of the box“.4 Für darüber hinaus gehende Formate beinhalten SIEMs
größtenteils ein SDK (Software Development Kit) oder Wizard5, um entsprechende
Anpassungen bei den Transformationsregeln vornehmen zu können.
Zur Vergleichbarkeit der Daten gehört auch, dass insbesondere bei Einsatz des SIEMs
in einer Umgebung mit verteilten Systemen und gegebenenfalls unterschiedlicher
Zeitzonen, die Zeitangaben innerhalb der Event-/ Logdaten korrekt in Bezug zu einer
gemeinsamen zentralen Zeit gebracht werden.
Die nun so miteinander vergleichbaren Daten werden zur weiteren Verarbeitung in
einer zentralen Datenbank abgelegt. Aufgrund der Erfüllung von Compliance Vorgaben und IT-Forensischen Hintergründen ist es wichtig, gleichzeitig auch die ursprünglichen Rohdaten zusätzlich zu speichern.
2.3.5 Aggregation
Nach der Normalisierung folgt die Aggregierung (engl. Aggregation), bei der die Daten
so aufbereitet werden, dass eine isolierte Betrachtung frei vom sogenannten Grund1
2
3
4
5
in der Version 3 ist unter RFC 3414 explizit ein User-based Security Model (USM) enthalten, vgl. [51]
IETF Network Working Group, 2002
vgl. [52] Infinigate Deutschland GmbH, 2011
vgl. [53] SANS, 2009, [54] SANS, 2011
SIEMs liefern eine ganze Liste von unterstützen Systemen, vgl. [55] NitroSecurity, Inc, 2011
vgl. [41] Gartner, 2011
25
rauschen (engl. background noise) möglich ist.1 Das bedeutet, bekannte Redundanzen
werden bei den zugelieferten Ereignisinformationen um die, wie z.B. in dem unten
dargestellten Syslog-Ausschnitt gelb markierten Redundanzen, bereinigt.
Abbildung 2.8: Redundante Ereignisse BIP2488E, BIP2230E und BIP2232E in SYSLOG2
Des Weiteren werden aus der gewaltigen Menge3 von Ereignissen die desselben Typs
miteinander verbunden, um so einen besseren Überblick über die Zusammenhänge
zu erhalten und auf möglicherweise stattfindende Angriffe, wie z.B. dem Brute-ForceAngriff4, aufmerksam gemacht zu werden.
2.3.6 Correlation
Die Korrelation (engl. correlation) kann als das Hirn eines SIEMs verstanden werden.
Sie nimmt alle vorliegenden Informationen bzw. Ereignisse auf und zieht hieraus
Rückschlüsse und reagiert entsprechend. Dabei ist die Korrelation im Gegensatz zur
Aggregation, die lediglich Ereignisse desselben Typs in Beziehung bringt, in der Lage,
auch Ereignisse unterschiedlichen Typs in Relation zu setzen. Zusätzlich zeichnet die
1
2
3
4
vgl. [20] Miller, Harris, Harper, Vandyke, & Blask, 1. Auflage 1. November 2010, S. 88
vgl. [56] IBM, 2011
heutige SIEMs verarbeiten bis zu 5.000 Ereignisse pro Sekunde (EPS) , vgl. [57] ArcSight, Inc., 2011
das stupide Ausprobieren aller möglichen Passwörter, um Zugriff auf ein System zu erlangen, vgl. [23]
Cisco Networking Academy, 2006, S. 28 f.
26
Korrelation aus, dass sie Relationen zwischen Ereignissen bilden kann, die über einen
längeren Zeitraum verteilt auftreten1. Dadurch können SIEMs auch komplexe Ereignisbeziehungen herstellen und somit Angriffe erkennen, die sich nur als Kombination
mehrerer unterschiedlicher, nicht zeitgleich stattgefundener Ereignisse ableiten
lassen. Aus diesem Wissen werden, wie in folgender Grafik veranschaulicht, übergeordnete Ereignisse gebildet, die qualifizierter sind und Composite Events oder auch
Complex Events (CE)2 genannt werden (stammen die ursprünglichen Ereignisse aus
verteilten Systemen und werden diese zusammengeführt bzw. hieraus Mengen
gebildet, spricht man auch von sog. Event Clouds).3
Abbildung 2.9: Relationsmodell bei Korrelation von Event1||Event24
Um Angriffe nicht nur im Nachhinein analysieren zu können, sondern Anzeichen eines
gerade stattfindenden Angriffs zeitnah aufzudecken, erfolgt der Prozess in Echtzeit5
und beruht grundsätzlich auf den zwei in den folgenden Abschnitten beschriebenen
Ansätzen.6
Für das Gelingen der Korrelation - d.h. das SIEMs versteht, ob es sich um Angriffe
handelt und kann diese von gewöhnlichen Ereignissen gut unterscheiden - ist ein
Mechanismus erforderlich, der darüber eine Entscheidung trifft. Im Prinzip werden
für diesen Mechanismus die Ansätze angewandt, die bereits aus IDS bzw. IPS bekannt
sind: Zum einen die Erkennung von Angriffsmustern (engl. signature/misuse detection) und zum anderen die Anomalieanalyse (engl. anomaly detection), die durchaus
auch kombiniert eingesetzt werden können (engl. hybrid detection).7 Vereinfacht
1
2
3
4
5
6
7
vgl. [58] Bundesamt für Sicherheit in der Informationstechnik, 2011, S. Abschnitt 1.3.3
bei Composite Event handelt es sich um ein Derivat von Complex Event, vgl. [59] EPTS -Event
Processing Technical Society, 2008
vgl. [59] EPTS -Event Processing Technical Society, 2008
Quelle: [60] The 1st International Conference on Information Science and Engineering, 2009, S. 4866
vgl. u.a. [61] SenSage Inc., 2011, [46] Q1 Labs, 2011, [45] ArcSight, Inc., 2010
vgl. [62] Cai, 2010, S. 299, [63] Jahankhani, Hessami, & Feng, 2010, S. 157
vgl. [63] Jahankhani, Hessami, & Feng, 2010, S. 157 f.
27
betrachtet unterscheiden sich die beiden Ansätze darin: Der eine reagiert bei auftretenden Ereignissen, von denen bekannt ist, dass diese auf einen Angriff hinweisen.
Der andere kommt zum Tragen, wenn bisher nicht bekannt ist, dass es sich um unkritische Ereignisse handelt.
Bei dem auf Angriffsmustern basierten Ansatz werden die vorliegenden Ereignisse mit
allgemein bekanntem Angriffsverhalten verglichen. Hierzu wird auf sog. Signaturen
(engl. signatures) zurückgegriffen, die Informationen über die typischen Eigenschaften von Hacking-Werkzeugen und Methoden sowie Malware wie z.B. Viren, Würmer
oder Trojaner enthalten. Die Bandbreite reicht dabei von einfacher Zeichenerkennung
in Daten, dem sog. Musterabgleich (engl. pattern matching), bis hin zu komplexen
Verhaltensmustern.1 Diese Angriffsmuster werden dem SIEMs als sog. KontextInformationen zugeführt und in der Regel in Datenbanken gespeichert, sodass während des Prozesses darauf zurückgriffen werden kann.2 Die Inhalte bzw. Signaturen
stammen entweder vom Anbieter des SIEMs, einem unabhängigen Dienstleister oder
können, sofern das genutzte SIEMs dieses unterstützt, durch eine einfache Skriptsprache selbst eingebracht werden.3 Zweifellos ist beim Angriffsmuster basierten
Ansatz die Effektivität und, ob Angriffe überhaupt erkannt werden, maßgeblich davon
abhängig, ob die Signatur-Informationen auf dem neusten Stand gehalten werden.
Dabei geht es nicht nur um frisch entdeckte Angriffsmethoden, die als Signatur
unverzüglich in die Datenbank aufgenommen werden sollten, sondern auch um
Modifikationen bereits bekannter Angriffe, die ansonsten aufgrund kleinerer Abweichungen vom Original bereits nicht mehr erkannt werden könnten (engl. false negatives).
Der Anomalieanalyse basierte Ansatz hingegen neigt eher dazu, Angriffe anzuzeigen,
wo keine sind (engl. false positves). Erklären lässt sich dieses dadurch, dass auf
Abweichungen von zuvor als unbedenklich bzw. normal definierten Systemzuständen/ -verhalten reagiert wird und zum Zeitpunkt der Definition nicht alle künftigen
1
vgl. [58] Bundesamt für Sicherheit in der Informationstechnik, 2011, S. Abschnitt 1.3.1
vgl. [63] Jahankhani, Hessami, & Feng, 2010, S. 157 f., [58] Bundesamt für Sicherheit in der
Informationstechnik, 2011, siehe Abschnitt 1.3.1
3
vgl. [64] Symantec Corporation, 2011, [65] SecurityFocus, 2011, [66] BroadWeb Co., 2011, [67]
BroadWeb Co., 2011, [58] Bundesamt für Sicherheit in der Informationstechnik, 2011, siehe
Abschnitt 1.3.1, [68] Symantec Corporation, 2011
2
28
Situationen von vornherein berücksichtigt werden können. Auf Anomalien geprüft
werden kann dabei der Kommunikationsverkehr (Protokolle) zwischen den Rechnern
sowie Aktivitäten von Subjekten und Objekten generell. Hierzu werden statistische
Kennwerte (Mittelwerte, Varianzen, etc.) des Normalzustands/ -verhaltens über z.B.
User, Dateien, Anwendungen und Servern in Verbindung mit z.B. der Anzahl von
gescheiterten Logins, Tageszeiten des Zugriffs, Nutzungshäufigkeit und Zugriffsdauer
gebildet.1 Tritt nun im Tagesgeschäft eine zu hohe Abweichung zu den Kennwerten
auf, leitet das SIEMs hieraus Anzeichen eines Angriffs ab. Die Kennwerte werden, wie
auch schon bei den Signaturen beschrieben, als Kontext-Informationen in einer
Datenbank gespeichert und stehen so dem Korrelationsprozess zur Verfügung.
2.3.7 Reporting
Am Ende der Prozesskette befindet sich das Reporting. Es informiert über den aktuellen Zustand sowie auffälliges Verhalten der überwachten IT-Systeme, die Einhaltung
der Compliance-Anforderungen und alarmiert bei Anzeichen eines Angriffs. Empfänger sind in erster Linie das IT-Sicherheits-Personal aber auch das Revisions- und
Compliance-Personal als auch das Unternehmensmanagement.2 Informiert wird in
Form von abgesetzten Alarmnachrichten (z.B. per E-Mail oder SMS), erstellten Berichten oder aktivem Monitoring über die GUI des SIEMs.
Die Alarmierung findet in Echtzeit statt und kann z.B. als E-Mail versandt werden und
Vorschläge zu Gegenmaßnahmen oder sogar durch das SIEMs bereits präventiv
veranlasste Maßnahmen, wie beispielsweise das Isolieren von erkannter Malware,
beinhalten. Bei den Berichten kann i.d.R. aus einer Vielzahl von Standardvorlagen, die
auch den Aspekt der Compliance abdecken, ausgewählt und entweder Zyklen zur
Erstellung festgelegt (z.B. täglich um 7:00 Uhr um die Aktivitäten der vergangen Nacht
zu sichten) oder ad-hoc abgerufen werden. Das Monitoring über die GUI erlaubt eine
Echtzeit- als auch vergangene Betrachtung für Analysezwecke. Hierbei wird das
Personal durch komfortable, graphische Visualisierung des Sachverhalts über alle
Ereignisebenen hinweg unterstützt.3
1
2
3
vgl. [58] Bundesamt für Sicherheit in der Informationstechnik, 2011, siehe Abschnitt 1.3.2
siehe auch Abbildung 2.6: Überblick einer SIEM Lösung , vgl. [44] Tier-3, 2011
vgl. für den Absatz u.a. [45] ArcSight, Inc., 2010, [49] AlienVault LC, 2011, [61] SenSage Inc., 2011,
[69] eIQnetworks Inc., 2010
29
2.4 Modellierungsmethode UML
Die Unified Modeling Language (UML) ist eine Modellierungssprache, die verbreitet
für die Analyse, Entwicklung und Implementierung von softwarebasierten Systemen
sowie für die (Geschäfts-)Prozessmodellierung in Form von Diagrammen genutzt
wird. 1 UML wurde erstmalig 1997 von der Object Management Group (OMG) standardisiert und beinhaltet in der zuletzt freigegebenen UML-Spezifikation Version 2.3
aus 2010 vierzehn Diagrammtypen, die sich in Struktur- und Verhaltensdiagramme
unterteilen lassen. Innerhalb dieser Diagramme definiert UML Bezeichnungen und
deren mögliche Beziehungen der bei der Modellierung zu verwendenden Gegenstände, was die vereinheitlichte Formulierung eines visuellen Abbilds von statischen
Strukturen oder dynamischen Abläufen ermöglicht.
Das Klassendiagramm (engl. class diagram) zählt zu den Strukturdiagrammen in der
UML und wurde entwickelt, um Klassen und Schnittstellen sowie deren Beziehungen
zu spezifizieren. Es ermöglicht, die Abstraktion von Objekten sowie die Bildung von
Klassen gleichen Verhaltens und Struktur sowie deren Interaktion innerhalb eines
Systems zu modellieren. Aus dem Teil der Verhaltensdiagramme ist es das Aktivitätsdiagramm (engl. activity diagram), welches eine detaillierte und strukturierte Darstellung von Abläufen ermöglicht und somit insbesondere für die Geschäftsprozessmodellierung geeignet ist. Die dabei formulierten Abläufe können Funktionen des Systems oder Anwendungsfällen entsprechen. Anwendungsfälle, d.h. für einen Anwender wahrnehmbare Leistungen, werden mit dem Anwendungsfalldiagramm (engl. Use
Case Diagram) zusammenfassend für ein System dargestellt. Zu den beiden letztgenannten Diagrammtypen existieren die im Folgenden aufgeführten Erweiterungen,
die den Aspekt der IT-Sicherheit einschließen.
2.4.1 Misuse Case Diagramm
Das Misuse Case Diagramm basiert auf dem Anwendungsfalldiagramm aus der UML
Notation – was sich auch durch die Ableitung des Namens vom englischen Use Case
erschließt – und erweitert dieses um die Visualisierungsmöglichkeit bösartiger Handlungen. Misuse Case Diagramme ermöglichen so die gleichzeitige Darstellung des
bereits aus dem Use Case bekannten normalen, legitimen Anwendungsfalls sowie der
1
vgl. [70] OMG, 2010, S. 13
30
hierauf wirkenden Angriffe bzw. des bösartigen Anwendungsfalls.1 Zur Unterscheidung werden hierbei die bösartigen Akteure und Anwendungsfälle schwarz gefärbt.
Zusätzlich zu den existierenden werden zwei weitere Beziehungen, mitigates (wirkt
abschwächend auf einen bösartigen Anwendungsfall) und threatens (bedroht einen
normalen, legitimen Anwendungsfall) eingebracht, die in der Beziehung zum originären Anwendungsfalldiagramm im folgenden Metamodell veranschaulicht werden.
Abbildung 2.10: Zusammenhang des Misuse Case Konzepts zum Use Case Diagramm
2
Wie auch beim originären Anwendungsfalldiagramm gibt das Misuse Case Diagramm
eine zusammenfassende Übersicht zu den Funktionen und Akteuren des betreffenden
Systems. Für eine genauere Beschreibung des veranschaulichten Szenarios ist ein
dem Diagramm angeschlossener tabellarischer Beschreibungsteil vorgesehen.3
2.4.2 Mal-Activity Diagramm
Neben dem Misuse Case Diagramm wurde nach demselben Konzept bei der Erweiterung des klassischen Aktivitätsdiagramms aus der UML Notation verfahren. Im Konkreten heißt das, dass die bestehende Syntax und Semantik übernommen wurden
und die bösartigen Aktivitäten und Akteure mit schwarzer Einfärbung gekennzeichnet
werden. Das so entstandene Mal(icious)-Activity Diagramm4 ergänzt das Misuse Case
Diagramm und kann so die Lücken hinsichtlich der Betrachtung von (Geschäfts-)
1
2
3
4
vgl. [71] Sindre & Opdahl, 2004, S. 34 f.
Quelle: Requirements Engineering Article 2005 - Eliciting security requirements with misuse cases,
vgl. [71] Sindre & Opdahl, 2004, S. 36
vgl. [71] Sindre & Opdahl, 2004, S. 39
bösartige Aktivitäten, die von normalen Handlungen abweichen (engl. Malicious Activities)
31
Prozessabläufen unter dem Aspekt der IT-Sicherheit schließen.1 Es ermöglicht die
gleichzeitige Betrachtung von normalen, legitimen und bösartigen Aktivitäten innerhalb einer (Geschäfts-)Prozessmodellierung.
2.5 Attack-Trees Methode
Attack-Trees (engl. für Bedrohungs-/ Angriffsbäume) ist ein formales Verfahren, um
die Sicherheit von Systemen basierend auf Angriffen zu beschreiben. Dieses ist für die
Bedrohungsanalyse und als Grundlage einer anschließenden Risikoanalyse geeignet,
da zusätzliche Attribute (wie z.B. Kosten oder Eintrittsmöglichkeit) mitgeführt werden
können sowie entsprechende Schutzmaßnahmen hieraus bestimmt werden können.
Das Verfahren ermöglicht es, sich mit der Sicherheit auseinanderzusetzen, Fachkenntnisse festzuhalten und wiederzuverwenden sowie auf Änderungen zu reagieren.2
Die grundlegende Methodik besteht dabei aus einer Baumstruktur, in der die möglichen Angriffe gegen ein System abgebildet werden. Das Ziel des Angreifers wird
hierbei als Wurzel-Element, dem Anfangsknoten, dargestellt. Der (Angriffs) –Weg, um
das -Ziel zu erreichen, wird mit entsprechenden Kindknoten abgebildet. Die Kindknoten werden nach UND-Knoten und ODER-Knoten unterschieden. Besteht die Möglichkeit, das Ziel bzw. den oberen Knoten auf mehrere Arten zu erreichen, werden ODERKnoten verwendet. Ist es erforderlich, mehrere Schritte zur Erreichung des Ziels bzw.
des oberen Knotens zu durchlaufen, werden UND-Knoten verwendet.3
Abbildung 2.11: Darstellung UND- und ODER-Knoten in Attack-Trees
Angriffsbäume sind somit eine geeignete Methode für die Sicherheitsanalyse eines
Systems und dessen Subsysteme (vgl. 2.1.4 Risiken und Schwachstellen), um dabei
deren etwaige Schwachstellen aufzudecken.
1
2
3
vgl. [72] Sawyer, Paech, & Heymans, 2007, S. 355 ff.
vgl. [73] Schneier, 1999
vgl. [73] Schneier, 1999
32
Anwendungsfall aus der Finanzbranche
3 Anwendungsfall aus der Finanzbranche
Der Anwendungsfall bezieht sich auf ein reales Unternehmen aus der Finanzbranche,
dass allerdings im Rahmen der Diplomarbeit aufgrund begründeter Bedenken des FDL
namentlich nicht benannt wird. Beim betreffenden FDL handelt es sich um eine sog.
Universalbank, d.h. ein Kreditinstitut, dass die gesamte Bandbreite des Bank- und
Finanzdienstleistungsgeschäfts abdeckt (im Folgenden Bank genannt). Vor dem
Hintergrund, dass eine hohe Bedrohung aus Phishing-Angriffen hervorgeht (vgl. 2.1.3
Angriffe und Angreifer), stammt der für die vorliegende Arbeit ausgewählte Anwendungsfall bzw. Geschäftsprozess aus dem elektronischen Zahlungsverkehrsgeschäft
einschließlich der damit verbundenen Kundenzugangssysteme der Bank.
3.1 Umfeld und Zugangssysteme der Bank
Die Bank hat ihren Hauptsitz in Deutschland und verfügt über weltweite Standorte.1
Zu den Kundenzielgruppen zählen Privat-, Gewerbe- und Firmenkunden2, denen, wie
in der folgenden schematischen Übersicht dargestellt, ein bedarfsorientiertes Angebot zur Abwicklung ihrer Bankgeschäfte über die elektronischen Zugangskanäle
Internetbanking, Homebanking und Electronic Banking bereitgestellt werden.
Abbildung 3.1: Kundenzielgruppen und elektronische Bankzugänge
1
2
3
3
Der Anwendungsfall beschränkt sich auf die Aktivitäten der Bank im deutschen Markt.
Zu Firmenkunden zählen Unternehmen, die im Regelfall mehr als 5 Mio. Euro p.a. Umsatz erzielen.
In Anlehnung an Produktinformationen der von der Bank genutzten Anbieter
33
Das Internetbanking ist ein von der Bank bereitgestelltes Zugangssystem, was von
allen drei Kundengruppen genutzt werden kann und durch den Aufruf der entsprechenden Website über einen Browser (wie z.B. dem Microsoft Internet Explorer oder
Mozilla Firefox) erreicht wird. Der Datenaustausch zwischen dem Browser bzw. Client
des Kunden und dem Webserver der Bank erfolgt ausschließlich verschlüsselt über
das Kommunikationsprotokoll HTTPS unter Verwendung eines Extended-ValidationSSL-Zertifikats (EV-SSL)1 und der damit einhergehenden Minimalanforderung des
Einsatzes von SHA1 als standardisierte kryptographische Hash-Funktion mit einer
Hashwertlänge von 160 Bit sowie RSA als asymmetrisches Verschlüsselungsverfahren
mit einer Schlüssellänge von 2.048 Bit.2 Die Website liegt hinter zwei Firewalls in einer
demilitarisierten Zone auf einem von der Bank betriebenen Apache Webserver, der
wiederum über ein VPN mit dem in einer weiteren DMZ befindlichen sog. Bankrechner, der als zentrale Verteilungsplattform zur Abwicklung von standardisierten Bankgeschäften einschließlich des Zugangsmanagements fungiert, verbunden ist und
entsprechende Services bereitstellt.
Der Bankrechner stellt hierbei die Middleware dar und beinhaltet neben den Schnittstellen zu den Front-Ends, die Schnittstelle zu den Back-Ends, d.h. dem Kernbankbzw. kontoführenden System sowie zu weiteren externen Abwicklern, wie z.B. das
System für das Wertpapiergeschäftsclearing. Die Datenübertragung erfolgt über SFTP
mit einer batchgesteuerten Verarbeitung. Letzteres setzt das Zwischenspeichern der
Daten am Bankrechner voraus, was in Form einer SQL-Datenbank geschieht, in der
auch die Kundenstammdaten inkl. Zugangsdaten aufbewahrt werden. Analog zum
oben aufgeführten Internetbanking wickelt die Bankrechner-Plattform die von der
Kundenanzahl zwar weitaus weniger, aber dafür intensiver genutzten Zugangssysteme Homebanking und Electronic Banking ab und greift dabei nach demselben Prinzip
auf die Schnittstellen zu den Back-End-Systemen der Bank und externen Abwicklern
zurück. Einen Überblick zu den Schnittstellen gibt der folgende Ausschnitt zu den
Funktionen aus den Anwendungsbereichen Zahlungsverkehr, Kontoinformationen
und Wertpapiergeschäft.
1
2
Das erweiterte Zertifikat liefert vor dem Hintergrund von Phishing-Angriffen eine zusätzliche Sicherheit, indem u.a. auf den ersten Blick über die grün hinterlegte Adresszeile des Browsers durch den
Anwender erkannt werden kann, dass es sich um eine sichere Verbindung und die gewünschte
Website handelt.
Anforderungen aus dem EV Certificate Guidelines v1.0, vgl. [74] The CA / Browser Forum, 2007, S. 57
34
Abholen MCV-Datei
Abholen MC2-Datei
INTERFACE
DATA INPUT
Auszüge (DTAUSFormat) abh.
EBICS/ FTAM/ HBCI/
FinTS/ Website
INTERFACE
ZA-System
INTERFACE
[SFTP]
EBICS/ FTAM/ HBCI/
FinTS/ Website
DATA OUTPUT
Kontoführendes
System
DATA INPUT
INTERFACE
[SFTP]
Kontoauszugsinformationen
SWIFT-Tagesauszüge
abholen
Vormerkposten
abholen
Saldenabfrage
Kontoübersicht
Download MT940/942
(MT940/942, PDF)
Kontoumsätze
anfordern (Zeitraum)
DATA OUTPUT
Kontoinformationen
Orderstatus anfordern
Orderanzeige
anfordern
Wertpapierorderänderung
Depotaufstellung
anfordern
Wertpapierstammd.
anfordern
Wertpapiersuche
INTERFACE
[SFTP]
Wertpapierorderstreichung
WP2 - dwpbank
INTERFACE
[SFTP]
DATA INPUT
Wertpapierorder
einreichen
Payment Engine
INTERFACE
[SFTP]
HBCI/ FinTS/
Website
INTERFACE
Bankrechner - OUT
ZA-System
DATA OUTPUT
DATA INPUT
EBICS/ FTAM/ HBCI/
FinTS/ Website
DATA INPUT
INTERFACE
EBICS/ FTAM/ HBCI/
FinTS/ Website
Request for Transfer
INTERFACE
Wertpapierabwickler-Schnittstelle
Einzelüberweisungen
(SEPA)
Inlandszahlungsverkehrsdatei
Euro-Eilzahlung
Umbuchung
Eilauftrag
Inlandszahlungen
Zahlungsverkehrsd.
von SRZ
Credit Transfer
Initiation (SEPA)
Magnetband senden
EURO-STP-Zahlung
Auslandszahlungsverk
ehrsdatei
EUStandardüberweisung
Credit Transfer
Initiation (SEPA)
Sammellastschriften
EU-Standardüberweisung (o. MT)
AZV-Zahlungsauftrag
(DTAZV)
Credit Direct Debit
Initiation (SEPA)
Upload DTAUS
Sammelüberweisungen
Einzellastschrift
Upload DTAZV
Zahlungsverkehr (Dritt- und Auslandsbanken)
DATA OUTPUT
DATA OUTPUT
Zahlungsverkehr
Bankrechner - IN
Abbildung 3.2: Schnittstellen der Bankrechnerfunktionen1
Das Homebanking und Electronic Banking Front-End basieren dabei auf die vom
Zentralen Kreditausschuss (ZKA) spezifizierten HBCI bzw. FinTS sowie FTAM und EBICS
Standardschnittstellen. Alle diese vier von der Bank unterstützen Kunde-BankSchnittstellenverfahren setzen den Einsatz einer entsprechenden Finanzverwaltungssoftware (wie z.B. StarMoney oder MultiCash) mit jeweils betreffendem Kommunika1
Quelle: Schnittstellendokumentation der Bank zum Bankrechner
35
tionsmodul von Seiten des Kunden voraus.1 Bis auf das FTAM-Verfahren, welches
über eine ISDN-Einwahl arbeitet, kommunizieren die restlichen drei Verfahren über
eine Internetverbindung mit dem Banksystem.
Vor dem Hintergrund, dass das Internetbanking mit Abstand von den meisten Kunden
genutzt wird, die akuten Schadensfälle für die Bank aus diesem Kanal resultieren
sowie die Verfahren der anderen Zugangswege grundsätzlich lediglich auf dem
deutschen Markt Bedeutung finden 2, erfolgt die Betrachtung im restlichen Teil dieser
Arbeit rein auf das Internetbanking bezogen. Zweifelsohne sind die anderen Zugangswege der Bank ebenfalls Bedrohungen ausgesetzt und erfolgreiche Angriffe
lassen sich wie am Beispiel von FinTS nicht ausschließen. 3 Allerdings liegen hierzu der
Bank derzeit keine bekannten Angriffsversuche oder Schadensfälle vor. Dieses kann
darauf zurück geführt werden, dass der Angreifer beim gemeinen Internetbanking im
Vergleich zu den anderen Zugangswegen mit geringerem Aufwand an sein Ziel bzw.
an mehr potenzielle Opfer kommt und das hierbei von ihm entwickelte Vorgehen
bzw. Exploit weltweit und nicht nur bei deutschen Banken funktioniert, wie das
Aufgreifen von entsprechenden Cybercrime-Ringen zeigt.4
3.2 Internetbanking Anwendung
Das Internetbanking der Bank stellt für alle Kundenzielgruppen ein breites Spektrum
an Services bzw. Funktionen zum Zweck der elektronischen Bankgeschäftsabwicklung
bereit. Die darin enthaltenen Funktionen, die einem marktüblichen Angebot entsprechen, werden wie in dem folgenden Ausschnitt der Anwendungsarchitektur nach den
Komponenten Eurozahlungsverkehr, Auslandszahlungsverkehr, Kontoinformationen,
Wertpapiergeschäft, Sonstige Funktionen, Dokumentäres Auslandsgeschäft und
Zugangsmanagement unterschieden.
1
HBCI wurde ab der Version 3.0 in FinTS umbenannt. Banken auf dem Markt unterstützen sowohl HBCI
als auch FinTS Versionen. Die Verpflichtung, FTAM laut ZKA DFÜ-Abkommen zu unterstützen, ist zum
31.12.2010 entfallen. Die meisten Banken bieten das Verfahren jedoch für die Übergangszeit, bis alle
Kunden auf das Nachfolgerverfahren EBICS migriert wurden, weiterhin an, vgl. [75] ZKA, 2004, [76]
ZKA, 2011, [77] ZKA, 2011
2
Anderen Länder steht die Nutzung dieser Verfahren frei, jedoch sind diese über den ZKA nur für
deutsche Kreditinstitute bindend. Der Einsatz von EBICS jedoch wird in Frankreich gerade etabliert.
3
Trotz kombiniertem Einsatz von Virenschutz, Firewall, Chipkarte und Chipkarteleser mit integrierter
Tastatur ist bei FinTS kein 100% wirksamer Schutz vor Angriffen vorhanden, vgl. [78] Haubner, 2004,
S. 46 f.
4
Erfolgreicher Einsatz von einer Malware bei Banken in über 10 Ländern, vgl. [27] ISMG Corp., 2011
36
Internetbanking
Einzelüberweisung
Dauerauftrag
Sammelüberweisungen
Umbuchung
Bestand Daueraufträge
(SEPA)
Einzellastschrift
Dauerauftrag löschen
Lastschrift (SEPA)
Sammellastschriften
Dauerauftrag ändern
Umbuchung
...
Eurozahlungsverkehr
Eilzahlungsauftrag
AZV-Zahlungsauftrag
...
Auslandszahlungsverkehr
Kontoumsätze anfordern
Saldenabfrage
...
Kontoinformationen
Wertpapierorder
einreichen
...
Orderstatus anfordern
Wertpapiergeschäft
Vorlagen einstellen
Vorlagen Bestandsabruf
...
Sonstige Funktionen
Freier Auftrag
Auftragsstatus abrufen
...
Dokumentäres Auslandsgeschäft
Neue TAN-Liste
beantragen
PIN-Änderung
...
Zugangsmanagement
Abbildung 3.3: Funktionen der Anwendung Internetbanking
1
Alle in den jeweiligen Komponenten aufgeführten Funktionen haben gemeinsam,
dass bei deren Ausführung betreffende Services vom Webserver aus beim Bankrechner angefragt werden, der wiederum die Verteilung und Kommunikation mit den
1
Quelle: Ausschnitt aus Dokumentationen der Bank zum Internetbanking
37
dahinterliegenden Back-End-Systemen übernimmt oder, wie bei der Zugangsmanagement-Komponente, den Service selbst bereitstellt.
Die Komponente Zugangsmanagement enthält dabei z.B. Funktionen, die dem Kunden ermöglichen, seine Credentials zu verwalten. Bei der Komponente Kontoinformationen stehen dem Kunden Funktionen zur Einsicht seiner Kontobewegungen zur
Verfügung und die Auslandszahlungsverkehrs-Komponente beinhaltet Funktionen zu
Zahlungsaufträgen, die mit einem Währungsgeschäft verbunden sind. Die Eurozahlungsverkehrs-Komponente weist die Funktionen um die Produkte Dauerauftrag und
Lastschrift sowie die für die in dem Rahmen dieser Diplomarbeit vorgesehene Sicherheitsanalyse ausgewählten Funktionen auf, die sich als Überweisung substituieren
lassen, da dieses hinsichtlich ihres Prozessablaufs auf der dafür ausreichenden Beschreibungsebene/-tiefe, identisch sind.
3.2.1 Internetbanking Überweisung
Als exemplarischer Prozess wird die auf dem Internetbanking basierende Überweisung, die wie bereits oben erwähnt sämtliche aus dem Eurozahlungsverkehrs stammenden Überweisungsarten repräsentiert, verwendet. Die für diesen elektronischen
Geschäftsprozess relevanten Akteure sind:
 Der Kunde, der eine Überweisung über das Internent Banking System der
Bank beauftragt, wozu er sich zunächst über die Website einloggen muss.
 Der Browser des Kunden, über den der Aufruf der Website mit anschließendem Login sowie der Überweisungsbeauftragung erfolgt.
 Das Banksystem, dass die Internetbanking Website und die damit verbundenen Services bereitstellt sowie abschließend den Überweisungsauftrag weiterverarbeitet und die in diesem Kapitel vorangestellt beschriebenen Systeme
der Bank repräsentiert.
Die für die Überweisung im Internetbanking-System hauptsächlichen Anwendungsfälle sind das Login auf der Webseite (AWF1), was wiederum den (Unter-) Anwendungsfall Identität authentisieren (AWF1a) und Finanzstatus anzeigen (AWF1b) inkludiert
bzw. voraussetzt, sowie Überweisung beauftragen (AWF2), der in der Beziehung zum
Anwendungsfall Login auf Website eine bedingte Erweiterung darstellt und die
38
(Unter-) Anwendungsfälle Transaktion erfassen (AWF2a) und Transaktion autorisierten (AWF2b) inkludiert. Eine Übersicht über die Akteure, Anwendungsfälle und deren
jeweilige Beziehungen stellt das unten abgebildete Diagramm dar.
Internetbanking
<<include>>
Identität
authentisieren
<<include>>
Kunde
Login auf Webseite
<<extend>>
Finanzstatus
anzeigen
{Kunde wünscht
eine Überweisung
zu tätigen}
Überweisung
beauftragen
Banksystem
<<include>>
<<include>>
Transaktion
erfassen
Transaktion
autorisieren
Browser
Abbildung 3.4: Anwendungsfalldiagramm zur Internetbanking Überweisung
Im Folgenden werden die beiden Anwendungsfälle Login auf Website und Überweisung beauftragen sowie deren jeweilige inkludierte Anwendungen beschrieben.
Eigenschaft
Beschreibung
#ID
AWF1
Name/Titel
Login auf Website (include: Identität authentisieren, Finanzstatus anzeigen)
Zielsetzung
Der Kunde kann die Kontonummer und Internetbanking PIN in die dafür
vorgesehenen Maskenfelder eingeben und bestätigt dieses mit der
Auswahl des Buttons Anmelden, um sich einzuloggen bzw. zu authentisieren. Im Anschluss wird die Kundenidentität authentifiziert, indem
seine Eingabe (Kontonummer und PIN) geprüft wird. Handelt es sich um
korrekte Eingabedaten ist der Kunde legitimiert und im Internetbanking
eingeloggt. Er bekommt den Finanzstatus mit Aktion-Auswahl angezeigt
und kann hieraus die Überweisungsbeauftragung aufrufen.
39
Lokales
Diagramm
siehe Abbildung 3.4: Anwendungsfalldiagramm zur Internetbanking
Überweisung
Beziehungen
Überweisung beauftragen
Akteure
Kunde, Browser, Banksystem


Vorbedingung
Das Konto muss zum Internetbanking zugelassen sein
Der Kunde muss die Website des Internetbankings aufgerufen
haben
Nachbedingung
Gewählte Aktion wurde durchgeführt.
Ablauf
siehe Abbildung 3.6: Aktivitätsdiagramm Internetbanking Überweisung
Bemerkungen
Anwendungsfall ist Basis für andere Anwendungsfälle
Tabelle 3.1: Anwendungsfallbeschreibung Login auf Website
Eigenschaft
Beschreibung
#ID
AWF2
Name/Titel
Überweisung beauftragen (include: Transaktion erfassen, Transaktion
autorisieren)
Zielsetzung
Der Kunde ruft Überweisung beauftragen auf. Hier kann er zwischen den
Überweisungsarten wählen und im Anschluss in einer Eingabemaske die
Zahlungsauftragsdetails der Transaktion erfassen. Nach Überprüfung
seiner Eingabe kann er mit Eingabe der TAN die betreffende Transaktion
autorisieren bzw. Überweisung(en) freigeben.
Lokales
Diagramm
siehe Abbildung 3.4: Anwendungsfalldiagramm zur Internetbanking
Überweisung
Beziehungen
Login auf Webseite
Akteure
Kunde (legitimiert), Browser, Banksystem
Vorbedingung
Der Kunde muss im Internetbanking angemeldet sein.
Nachbedingung
Die Transaktion wurde freigegeben und damit autorisiert zur Weiterverarbeitung an das Banksystem übergeben.
Ablauf
Bemerkungen
-
Tabelle 3.2: Anwendungsfallbeschreibung Überweisung beauftragen
3.2.2 Prozessablauf der Überweisung
Unten stehende Abbildung zeigt den Prozessablauf zu AWF1, der mit der Etablierung
einer sicheren Verbindung 1 nach Aufruf der Internetbanking Adresse durch den
Kunden beginnt. Auch an dieser Stelle werden die in diesem Kapitel vorangestellt
1
vgl. [12] Eckert, 2009, S. 783 ff. und [79] Davies, 2011, S. 299 ff.
40
beschriebenen Systeme der Bank unter Banksystem zusammengefasst. Wurde die
sichere Verbindung zwischen dem Browser des Kunden und dem System der Bank
hergestellt, beginnt der Austausch der Anwendungsdaten zwischen beiden Systemen.
Kunde
Browser
ruft https Adresse auf
sendet ClientHello
Banksystem
antwortet ServerHello mit Zertifikat
sendet Handshake mit Zertifikat
Eingabe: Kontonummer und PIN
erwidert Handshake
fragt Website an
sendet Login- Website
zeigt Login Website an
loggt sich ein
sendet erfasste Eingabe
prüft die Eingabe
[NOK]
zählt Eingabeversuch
[<3]
[OK]
zeigt F-Login-Website an
zeigt Finanzstatus-Website an
sendet F-Login-Website
[=3]
sendet Finanzstatus-Website
sperrt PIN
zeigt PIN-Sperre-Website an
sendet PIN-Sperre-Website
Abbildung 3.5: Aktivitätsdiagramm Login Internetbanking
Der Kunde erhält über seinen Browser die Login-Seite angezeigt und authentisiert sich
durch die Eingabe seiner Kontonummer und der dazugehörigen PIN (nummerisch 5stellig). Die Eingabe wird an das Banksystem übertragen, wo dieses auf ihre Richtig41
keit hin geprüft wird. Sind die Eingaben falsch, erhält der Kunde die Möglichkeit seine
Eingabe zweimal zu wiederholen bzw. zu verbessern. Ist der dritte Login-Versuch
hintereinander aufgrund falscher Eingabedaten gescheitert und die dabei verwendete
Kontonummer zuordnungsfähig, erfolgt eine sog. PIN-Sperre (d.h. das Konto ist für
das Internetbanking Verfahren bis auf weiteres nicht mehr nutzbar) und der Kunde
wird entsprechend über den Ausdruck seines Browsers informiert. Sind die vorliegenden Login-Daten hingegen korrekt, wird dem Kunden über den Browser der Finanzstatus des Internetbankings angezeigt. Auf dieser Seite hat der Kunde die Möglichkeit, über die Auswahl des Menüpunkts Überweisung einen Überweisungsauftrag zu
initiieren.
Der Prozessablauf der Überweisungsbeauftragung, der durch die auf der nächsten
Seite stehende Abbildung dargestellt ist, schließt sich dem oben beschriebenen an
und entspricht dem AWF2: Überweisung beauftragen. Der Ablauf beginnt mit der
Auswahl des Menüpunkts Überweisung durch den Kunden. Der Browser fragt betreffenden Service bei dem Banksystem an, dass wiederum auf die dafür vorgesehene
Überweisungs-Seite überleitet. Dem Kunden stehen auf dieser vom Browser angezeigten Seite Überweisungsarten bereit, von denen er eine auswählt und eine für
diese Art erforderliche Erfassungsmaske angezeigt bekommt. In der Maske werden
durch den Kunden für den Zahlungsauftrag relevante Details (Empfänger- Bank, Name
und Konto; Betrag; Verwendungszweck; etc.) eingegeben, die im Anschluss zur
syntaktischen Prüfung an das Banksystem übertragen werden. Ist die Syntax der
Eingabedaten nicht korrekt, erhält der Kunde die Möglichkeit zur Anpassung seiner
Eingaben mit entsprechendem Hinweis, bis die Daten korrekt sind. Dasselbe gilt für
die Prüfung des Kontolimits, bei dem der Kunde die Möglichkeit hat, den Betrag
anzupassen. Im nächsten Schritt wird der Kunde zur Eingabe der TAN (nummerisch 6stellig) aufgefordert, um die Freigebe der zuvor erfassten Überweisung zu erwirken.
Die TAN wird wie die PIN mit zwei möglichen Fehlversuchen geprüft, mit der Folge,
dass entweder die TAN (ohne PIN-Sperre) aufgrund 3 Fehleingaben gesperrt wird und
der Kunde entsprechend informiert wird oder bei erfolgreicher Eingabe der betreffende Zahlungsauftrag autorisiert zur Weiterverarbeitung gegeben und dem Kunden
entsprechend bestätigt wird.
42
Kunde
Browser
wählt Überweisung
fragt Überweisung an
Banksystem
sendet Überweisungs-Website
zeigt Überweisungs-Website an
wählt Überweisungsart
Eingabe: Empfänger
Name, Bank u. Konto;
Betrag; Zweck; etc.
fragt Überweisungsart an
sendet Überweisungsmaske
zeigt Überweisungsmaske an
gibt Überweisung ein
prüft die Eingabensyntax
[NOK]
zeigt Überweisungsmaske mit F. an
sendet Fehler Maske
[OK]
prüft Kontolimit
[NOK]
Eingabe: TAN
zeigt Überweisungsmaske mit L. an
zeigt Freigabe-Website an
gibt Auftrag frei
sendet Freigabedaten
[OK]
sendet Limit Maske
sendet Freigabe-Website
prüft Feigabe
[NOK]
[OK]
zählt Freigabeversuch
weiterverarbeiten
[<3]
[=3]
zeigt Fehler-Website an
sendet Fehler-Website
sperrt TAN
zeigt TAN-Sperre-Website an
zeigt Bestätigungs-Website an
sendet TAN-Sperre-Website
sendet Bestätigungs-Website
Abbildung 3.6: Aktivitätsdiagramm Internetbanking Überweisung
43
3.3 Bedrohungsanalyse
Die Bedrohungsanalyse erfolgt durch die Erstellung eines Angriffsbaums (vgl. 2.5
Attack-Trees Methode), der sich auf den im vorangegangenen Abschnitt beschriebenen Geschäftsprozess der Internetbanking Überweisung bezieht. Das Ziel des Angriffs
ist die Manipulation bzw. Initiierung einer Internetbanking Überweisung mit dem
Motiv Geld zu stehlen. Dabei ist der Angreifer ein Nutzer ohne berechtigten Zugriff
auf das System, der sich jedoch in missbräuchlicher Absicht Zugriff verschafft (hat).
Um dieses Ziel zu erreichen, bestehen für den Angreifer die generellen Möglichkeiten:
1 In den Besitz der Zugangsdaten des Kunden zu gelangen, um eine entsprechende Überweisung selbst zu initiieren.
2 Den Kunden bzw. seine Überweisung so auszutricksen bzw. zu manipulieren,
dass die Überweisung zu seinen Gunsten verläuft.
3 Das System der Bank zu kompromittieren und, um Geld zu stehlen, eine
Überweisung zu manipulieren oder initiieren.
Die anschließende Abbildung zeigt nochmal die drei vorgenannten Angriffsmöglichkeiten, dessen jeweilige Angriffswege in den folgenden Abschnitten detailliert als
separate Angriffsbäume beschrieben werden. 1
Abbildung 3.7: Angriffsbaum Internetbanking Überweisung
3.3.1 Zugangsdaten des Kunden missbrauchen
Nutzt der Angreifer für den Angriff die Zugangsdaten des Kunden und nimmt so
dessen Identität an, ist es zunächst erforderlich, sich diese vom Kunden zu beschaffen,2 wozu es wie in unten dargestellter Abbildung mehrere Möglichkeiten gibt.
1
2
Die Gesamtdarstellung des Angriffsbaums ist der Anlage dieser Arbeit beigefügt.
Auf die Beschaffung der Credentials über Bank oder Dritte wird in dieser Arbeit nicht eingegangen.
44
Abbildung 3.8: Angriffsbaum Internetbanking Zugangsdaten missbrauchen
45
Dabei kann der Angreifer die Zugangsdaten beim Kunden vor Ort erlangen, indem er
diese z.B. als Notiz auf einem Zettel in der Nähe des Kunden-PCs findet oder sogar die
originalen PIN und TAN Dokumente entwendet, die der Kunden unachtsam aufbewahrt hat. Bis hin zu, dass der Angreifer auf die Idee kommt, den Kunden um die
Herausgabe seiner Credentials zu bedrohen. Diese Vorgehensarten, an die Zugangsdaten des Kunden zu kommen, lassen sich zwar nicht ausschließen, können aber
vernachlässigt werden, da diese kein nennenswertes Risiko für die Bank darstellen
(vgl. 3.4 Risikoanalyse und Sicherheitsanforderungen Abschnitt 1.1.n).
Anders zu bewerten ist es, da hiervon durch einen Angreifer deutlich mehr Kunden
betroffen sein können, wenn der Angreifer - für den gewöhnlichen Kunden nicht offensichtlich wahrnehmbar - die Zugangsdaten mit technischen Hilfsmitteln ausspäht (vgl.
3.4 Risikoanalyse Abschnitt 1.2.n.n). Die eingesetzte Malware kann hierbei auf mehrerlei Wegen auf den Rechner des Kunden (vgl. 3.3.4 Kundenrechner infizieren) gelangen.
Auf dem infizierten Rechner können dann die Credentials des Kunden ausgespäht
werden, indem ein Keylogger benutzt wird, der sämtliche Tastatureingaben (inkl. der
Eingabe von Kontonummer, PIN und TAN beim Internetbanking) des Kunden mitschneidet und an die Angreifer sendet, der den Mitschnitt dann nach den Credentials
auswertet. Alternativ kann ein Formgrabber benutzt werden, der ähnlich funktioniert,
jedoch gezielt Maskeneingaben mitschneidet, was für die Suche nach Credentials für
das Login auf der Internetbanking Seite der Bank zielführender ist.1 Für das Ausspähen
ist ebenfalls der Einsatz von Spyware möglich. Mit der Spyware2 ist der Angreifer in der
Lage, sämtliche Kundenaktivitäten zu verfolgen (indem z.B. Videos oder Screenshots an
den Angreifer übertragen werden) und gezielt Informationen auf dem System des
Kunden zu sammeln. Mit dem Einsatz eines Packet Sniffer3 können die zwischen der
Bank und dem Kundensystem ausgetauschten (verschlüsselten) Nachrichtenpakete
mitgelesen und an den Angreifer versandt werden, der wiederum aus den Paketen die
Credentials entschlüsseln bzw. identifizieren kann, um diese entsprechend zu nutzen.
Eine weitere Möglichkeit, um an die Zugangsdaten des Kunden zu kommen, ist der
Einsatz von Social Engineering Methoden (vgl. 2.1.3 Angriffe und Angreifer). Hierbei
1
vgl. [12] Eckert, 2009, S. 61 u. 76; [80] FBI - Federal Bureau of Investigation, 2010; [35] Anderson, 2.
Auflage 11. April 2008, S. 650
2
vgl. [12] Eckert, 2009, S. 23 ff.; [35] Anderson, 2. Auflage 11. April 2008, S. 646 f.
3
vgl. [12] Eckert, 2009, S. 119 ff.; [35] Anderson, 2. Auflage 11. April 2008, S. 636
46
täuscht der Angreifer die Identität der Bank oder eines vertrauenswürdigen Dritten
vor und setzt sich telefonisch mit dem Kunden in Verbindung, um so unter einem
Vorwand geschickt an die Zugangsdaten zu gelangen oder versendet an den Kunden
nach demselben Prinzip eine Phishing1 Instant-Message oder E-Mail im Namen und
Corporate Design der Bank, um direkt an die Credentials zu kommen oder ihn auf eine
vorgetäuschte, dem Anschein nach von der Bank stammenden, Website zu leiten 2, wo
Kontonummer, PIN und TAN(s)3 zu erfassen sind. Eine ebenfalls auf dem Social Engineering und zugleich auf dem Einsatz von Malware basierende Methode ist der Manin-the-browser (MITB) Angriff4. Sobald der Kunde sich erfolgreich eingeloggt hat,
erscheint im infizierten Browser, wie am unten aufgeführten Beispiel des Internetbankings einer Genossenschaftsbank zu sehen ist, ein Fenster mit einer angeblichen
Sicherheitsabfrage, die den Kunden auffordert, seine TANs zu hinterlegen, die nach
Eingabe zur weiteren Verwendung an den Angreifer gesandt werden.
Abbildung 3.9: Beispiel zum Man-in-the-browser Angriff5
3.3.2 Kunden austricksen und manipulieren
Aus Sicht des Angreifers stellt das Vorgehen, den Kunden auszutricksen oder sein
Handeln zu manipulieren, die effektivste Möglichkeit zur Erreichung seines Ziels dar.
1
2
3
4
5
vgl. [12] Eckert, 2009, S. 142 f.; [35] Anderson, 2. Auflage 11. April 2008, S. 21 ff.
Die Umleitung kann auch durch sog. Pharming erfolgen, indem z.B. die Hostdatei des Kundensystems
manipuliert wird und so, trotz richtiger URL Eingabe die Website des Angreifers aufgerufen wird.
In der Praxis werden auf diese Weise Kunden der Bank wahrhaftig dazu gebracht, ihre gesamten
noch unverwendeten TANs (eine TAN-Lste enthält für gewöhnlich 100 Stück) mühevoll auf der Website des Angreifers zu erfassen und somit preiszugeben.
vgl. [81] Ardagna & Zhou, 2011, S. 34
Quelle: [82] Raiffeisenbank-Kastellauen, 2011
47
Abbildung 3.10: Angriffsbaum Internetbanking Kunden austricksen und manipulieren
48
Denn hierbei werden entweder die Datenpakete aus der Überweisungsbeauftragung
des Kunden in Form eines Man-in-the-middle (MITM) Angriffs1 abgefangen und
anschließend manipuliert an die Bank weitergeleitet oder der Kunde wird durch Social
Engineering dazu gebracht, direkt eine Überweisung im Sinne des Angreifers zu
beauftragen.
Wie aus dem abgebildeten Angriffsbaum ebenfalls hervorgeht, bestehen bei der
MITM Methode die beiden Möglichkeiten, dass sich der Angreifer in der Rechnernetzwerkumgebung oder direkt am vom Kunden genutzten Rechner platziert, um
zwischen die Kommunikation des Kunden- und des Banksystems zu gelangen. Beim
Erstgenannten ist es grundsätzlich möglich, sich auch physikalisch, indem lokale
Netzwerkkomponenten (wie z.B. Netzwerkkabel oder Router) manipuliert werden,
in den Datenfluss einzubinden, jedoch ist das logische Zwischenschalten vor dem
Hintergrund, dass sich der Angreifer so grundsätzlich mit weniger Aufwand ein breites
Angriffspotenzial erschließt und weniger äußerlich sichtbare Spuren hinterlässt, die
weitaus praktikablere Variante. Dabei ist es erforderlich, Pharming Methoden wie das
DNS-Rebinding oder DNS-Cache-Poisoning2 zu betreiben, um den Datenverkehr über
den Rechner des Angreifers zu leiten. Am Rechner des Kunden kann durch den Einsatz
von Malware Packet-Sniffing3 betrieben werden, was erlaubt, die Datenpakete abzufangen und bei Bedarf erneut einzuspielen (engl. Replay)4, um so z.B. verschlüsselte
Authentisierungsdaten erneut zu senden und damit Zugang zu erlagen oder Internetbanking Sitzungen durch das sog. Session Hijacking5 zu übernehmen. In beiden Fällen,
beim Einsatz von Pharming oder Sniffing, ist ebenso die Manipulation der abgefangenen Datenpakete möglich, um so Inhalte im Sinne des Angreifers zu initiieren.
Auf der anderen Seite besteht die Möglichkeit, den Angriff mit Social Engineering
Methoden durchzuführen. Auch hier findet das Pharming Verwendung, allerdings um
den Kunden auf einen Webserver des Angreifers zu leiten, dem sog. Website spoo-
1
2
3
4
5
vgl. [12] Eckert, 2009, S. 142; [23] Cisco Networking Academy, 2006, S. 30; [14] Schneier, 1. Auflage
23. Januar 2004, S. 108 ff.; [35] Anderson, 2. Auflage 11. April 2008, S. 48 ff.
vgl. [12] Eckert, 2009, S. 122ff. u. S.142; oder auch spoofing von DNS tables genannt vgl. [14]
Schneier, 1. Auflage 23. Januar 2004, S. 181 ff.
vgl. [12] Eckert, 2009, S. 142; [23] Cisco Networking Academy, 2006, S. 24 ff.; [35] Anderson, 2.
Auflage 11. April 2008, S. 636
vgl. [12] Eckert, 2009, S. 120 u. 413; [35] Anderson, 2. Auflage 11. April 2008, S. 383 f.
vgl. [12] Eckert, 2009, S. 118 f. u. 143; [35] Anderson, 2. Auflage 11. April 2008, S. 636
49
fing.1 Die Website ist so designt, dass sie dem Kunden das echte Internetbanking der
Bank vortäuschen soll. Um diesen Anschein so gut wie möglich zu wahren, wird in der
Regel sogar eine SSL-Verbindung zwischen Angreifer- und Kundensystem genutzt und
dem Kunden Echtdaten z.B. zu seinen Kontoumsätzen eingespielt. Über das auf diese
Weise vorgetäuschte Internetbanking wickelt der Kunde wie gewohnt seinen Überweisungsauftrag (einschließlich der abschließenden TAN-Eingabe) ab. Jedoch wird
parallel im Hintergrund eine Sitzung mit dem echten Internetbanking vom Angreifer(system) gehalten, bei der die vom Kunden preisgegebenen Credentials zur Freigabe
einer im Sinne des Angreifers (d.h. anderes Zielkonto, maximaler Betrag) erfassten
Überweisung genutzt werden. Über den Einsatz von Malware kann durch die Umleitung des Kundenseitenaufrufs derselbe Effekt vom Angreifer erzielt werden. Das oben
beschriebene Vorgehen kann auch durch den MITB Angriff in Form von Java Scriptbzw. HTML-Injections,2 welche die komplette oder Teile (z.B. durch Popups oder
Frames) der Website manipulieren, ausgeübt werden, was den Einsatz von Webservern zur Täuschung nicht mehr erforderlich macht.
3.3.3 Banksystem kompromittieren
Der folgende Angriffsbaum zeigt Möglichkeiten, das Angriffsziel zu erreichen, indem
das Banksystem kompromittiert wird, d.h. im konkreten Fall durch Manipulation oder
Eindringen (engl. intrusion) die Integrität oder Vertraulichkeit des Systems zu verletzen. Möglichkeiten, wie z.B. der DoS-Angriff, die auf die Verfügbarkeit abzielen,
werden wegen des zugrunde gelegten Motivs Geld zu stehlen nicht berücksichtigt.
Abbildung 3.11: Angriffsbaum Internetbanking Banksystem kompromittieren
1
2
vgl. [12] Eckert, 2009, S. 147 f.; [14] Schneier, 1. Auflage 23. Januar 2004, S. 170
vgl. [83] OWASP, 2009
50
Auf der einen Seite besteht die Möglichkeit durch den sog. Brute-Force Angriff1 (engl.
für rohe Gewalt) die Zugangsdaten durch mehrfache Eingabeversuche zu erraten oder
zu kalkulieren. Das Kalkulieren setzt voraus, dass eine Schwäche bei der Zufallsgenerierung der PIN bzw. TANs besteht und dem Angreifer der hierfür von der Bank
verwendete Algorithmus bekannt ist. Diese Art des Angriffs auf die Bank und der von
ihr eingesetzten Sicherheitsmechanismen ist, wie unter 3.4 Risikoanalyse und Sicherheitsanforderungen Abschnitt 3.1.n noch genauer begründet wird, für den Angreifer
weniger Erfolg versprechend. Auf der anderen Seite kann durch die Methoden BufferOverflow2 (engl. für Pufferüberlauf), SQL- oder Command-Injection3 Zugriff auf das
Banksystem erlangt werden, um so das Internetbanking in seiner Funktion zu manipulieren oder Daten, wie z.B. die Kundenzugangsdaten, einzusehen oder zu manipulieren. So kann mit einer Injection (engl. für Einschleusung) versucht werden, über den
Webserver auf die Webanwendung Einfluss zu nehmen bzw. auf die Datenbank
zuzugreifen (vgl. 3.1 Umfeld und Zugangssysteme der Bank), indem in den Maskenfeldern auf der Website Dateneingaben erfolgen, die von der Anwendung als Kommando bzw. von der Datenbank als Anfrage interpretiert werden oder während des
Login-Prozesses durch einen Buffer-Overflow Maschinencode des Angreifers zur
Ausführung gebracht werden, um Systemzugang zu erlangen.4
3.3.4 Kundenrechner infizieren
Der Einsatz von Malware setzt die Infizierung des Kundenrechners voraus. Die vom
Angreifer hierfür genutzten möglichen Wege stellt die folgende Abbildung dar.
Abbildung 3.12: Angriffsbaum Kundenrechner infizieren
1
2
3
4
vgl. [14] Schneier, 1. Auflage 23. Januar 2004, S. 99 ff.; [35] Anderson, 2. Auflage 11. April 2008, S.
668; [12] Eckert, 2009, S. 66
vgl. [12] Eckert, 2009, S. 45 ff.; [35] Anderson, 2. Auflage 11. April 2008, S. 119 ff.; [14] Schneier, 1.
Auflage 23. Januar 2004, S. 205 ff.
vgl. [35] Anderson, 2. Auflage 11. April 2008, S. 124 u. 762; [12] Eckert, 2009, S. 140 ff.
bei der Danske Bank wurde dieser Angriff erfolgreich praktiziert, vgl. [84] Secunia, 2010
51
Die Malware gelangt dabei auf das System, indem eine E-Mail mit einem versteckten
HTML-Skript samt eingebetteter Anwendung oder einer ausführbaren Datei in der
Anlage an den Kunden versandt wird. Ebenso kann das Kundensystem infiziert werden, indem der Kunde beim Internetsurfen auf eine präparierte Website kommt oder
vom Angreifer durch z.B. eine SPAM-E-Mail auf diese geleitet wird, welche die
Schwachstellen seines Browsers ausnutzt, um per Drive-by-Download1 Malware auf
dem Kundenrechner zu installieren. Ein weiterer Weg ist, wenn eine dem Anschein
nach harmlose Anwendung vom Kunden installiert bzw. verwendet wird, die allerdings einen Trojaner oder Virus enthält oder sich während einer bestehenden Internetverbindung im Hintergrund für den Kunden unbemerkt ein Wurm einnistet oder
beim Austausch von Speichermedien, wie z.B. einem USB-Stick, mit Freunden oder
Kollegen ein Wurm oder Virus eingefangen wird. 2
3.4 Risikoanalyse und Sicherheitsanforderungen
In diesem Abschnitt erfolgt eine Risikoanalyse einschließlich abgeleiteter Sicherheitsanforderungen zu den in der Bedrohungsanalyse identifizierten Angriffsmethoden
bzw. -vorgehen. Sicherheitsanforderungen, denen die Bank bereits gerecht wird, sind
mit () und aus der Analyse als empfohlen hervorgehende, noch umzusetzende
Sicherheitsmaßnahmen sind mit () gekennzeichnet.
3.4.1 Analyse zu Zugangsdaten des Kunden missbrauchen
Im Folgenden werden die Angriffsvorgehen aus der Bedrohungsanalyse weiterführend untersucht, die darauf basieren, dass sich der Angreifer zunächst die Zugangsdaten vom Kunden beschafft, um diese im Anschluss zur Erreichung des Angriffsziels,
das Initiieren einer eigenen Überweisung, missbraucht (vgl. Knoten 1 aus Abbildung
3.7: Angriffsbaum Internetbanking Überweisung). Die Betrachtung erfolgt unterteilt
nach den Knoten (samt Folgeknoten):
 1.1 Kunden-Credentials physisch erlangen in Tabelle 3.3 (#Baum 1.1.n),
 1.2 Kunden-Credentials ausspähen in Tabelle 3.4 (#Baum 1.2.n.n) sowie
 1.3 Social Engineering betreiben in Tabelle 3.5 (#Baum 1.3.n).
1
2
vgl. [12] Eckert, 2009, S. 143
vgl. [23] Cisco Networking Academy, 2006, S. 36 ff. und [12] Eckert, 2009, S. 43 ff.
52
Eigenschaft
Beschreibung
#Baum
1.1.n
Angriffsvorgehen
1.1
Kunden-Credentials physisch erlangen (oder)
1.1.1
Kundenaufzeichnungen finden
Risikoanalyse
Diese A.-vorgehen stellen für die Bank Gefährdungen mit keinem nennenswerten Risiko dar, was damit begründet wird, dass es sich bei hieraus resultierenden Schäden um Einzelfälle handelt, welche die Bank selten betreffen.
Sicherheitsanforderungen
 Zeitlich versetzter Versand von PIN und TAN Dokumenten per Post an den
Kunden, um das Abfangen durch Dritte zu erschweren. ()
 Stetige Sensibilisierung der Kunden hinsichtlich richtigen Verhaltens. ()
 Verpflichtung der Kunden zur Geheimhaltung über AGB. ()
Betreffende Angriffsmöglichkeiten können als nicht kritisch gewertet und die
bereits praktizierten Maßnahmen als ausreichend befunden werden.
Folgerung
1.1.2
Kunden bedrohen oder bestehlen
Tabelle 3.3: Risikoanalyse – Kunden-Credentials physisch erlangen (Baum 1.1.n)
Eigenschaft
Beschreibung
#Baum
1.2.n.n
Angriffsvorgehen/
Knoten
1.2
Kunden-Credentials ausspähen (und)
1.2.1
Kundenrechner infizieren (*4)
1.2.2.1
1.2.2.2
Formgrabber benutzen
Spyware benutzen
Risikoanalyse
Vor dem Hintergrund, dass die Bank unten beschriebene Sicherheitsmaßnahmen einsetzt, stellen diese Angriffsvorgehen für die Bank ein geringes
Risiko dar. Aufgrund dieser Sicherheitsmaßnahmen ist das Ausspähen der
gesamten Credentials (einschließlich unverbrauchter TAN) für den Angreifer
im Vergleich zu anderen Vorgehen und deren Erfolgsaussichten uninteressant
bzw. aufwendiger. Dieses führt dazu, dass oben genannte Angriffe äußerst
selten vorkommen und somit ein großer Schaden ausbleibt:
1.2.2
Malware einsetzen (oder)
1.2.2.3 Keylogger benutzen
1.2.2.4 Passiv Packet Sniffer benutzen
0,5 Schäden p.a. x 1.500 EUR = 750 EUR p.a.
Vor dem Aspekt der Vertraulichkeit sind die Angriffe jedoch durchaus kritisch
zu betrachten, da mit diesen Angriffen die PIN leicht ausgespäht werden
kann und so die Finanzen des Kunden eingesehen werden können. Zweifellos
zuzuordnende Schadensfälle liegen der Bank hierzu jedoch nicht vor.
Folgerung
 Beidseitige Kommunikationspartner-Authentifizierung mit Einsatz von SSLZertifikaten u. Verschlüsselung, um das Packet Sniffing zu vermeiden. ()
 Verwendung eines indizierten Einmalpassworts (iTAN) zur Auftragsautorisierung und damit die TAN einem konkreten Auftrag zuweisen, um die
ausgespähte TAN für andere Transaktionen unbrauchbar zu machen. ()
 Vordefiniertes, vom Kunden anpassbares Auftragslimit (z.B. 1.500 EUR)
pro Buchung einstellen, um Einzelschadenshöhen gering zu halten. ()
 Kunden auf Prävention durch aktuelle Antivirus, Firewall u. Systempatches hinweisen, um unbemerkten Malwareeinstatz zu erschweren. ()
 Zwei-Faktor-Authentifizierung beim Kundenlogin verwenden, um oben
genannten Vertraulichkeitsaspekt für diese Angriffe sicherzustellen. ()
Das ermittelte Risiko ist zu gering, als dass diese Angriffsvorgehen zusätzliche
Maßnahmen erforderlich bzw. wirtschaftlich vertretbar macht. Dieses gilt
53
auch für das genannte latente Risiko bezüglich der Vertraulichkeit. Es wird
empfohlen das Restrisiko zu akzeptieren.
Tabelle 3.4: Risikoanalyse – Kunden-Credentials ausspähen (Baum 1.2.n.n)
Eigenschaft
Beschreibung
#Baum
1.3.n
Angriffsvorgehen/
Knoten
1.3
Social Engineering betreiben (oder/und)
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
Website spoofing einsetzen
Phishing Instant-Messaging oder E-Mail senden
MITB benutzen
Telefon Phishing betreiben
Risikoanalyse
Für die Bank stellen die Angriffsvorgehen aufgrund der unten aufgeführten
risikoreduzierenden, bereits praktizierten Sicherheitsmaßnahmen sowie
hierdurch sinkende Schadensfälle, was größten Teils auf die Sensibilisierung
der Kunden zurückgeführt werden kann, mittlerweile wieder ein mittleres
Risiko dar. Dennoch ergibt sich auf Kulanz von der Bank regulierter Schaden:
250 Schäden p.a. x 1.500 EUR = 375.000 EUR p.a.
Folgerung
 Bereits unter Knoten 1.2.n.n. benannte Sicherheitsmaßnahmen. ()
 Einsatz EV-SSL-Zertifikaten, um das Website spoofing zu erschweren. ()
 Intensive Sensibilisierung der Kunden hinsichtlich Betrugsmaschen. ()
 Logging von IP-Adressen u. User-Agent-Daten bei Überweisungsbeauftragung zur Auswertung von Auffälligkeiten im SIEMs, um zentrale oder über
Bots verteilte Einreichungen des Angreifers aufzuspüren. ()
 Sicherheitsverfahren wie z.B. Mobile TAN (mTAN) oder optischen TANGenerator (Flickercode) für die Autorisierung der Überweisung verwenden, um auf Initiative der Bank nur eine gültige TAN zu erhalten, die zugleich zweckgebunden und in ihrer Gültigkeit zeitlich begrenzt ist. ()
Die bisherigen Maßnahmen haben zu einer Reduktion des Risikos geführt. Es
ist sinnvoll, das verbliebene Restrisiko weiter zu reduzieren und hierzu oben
genannte Empfehlung umzusetzen bzw. zu prüfen (Kosten/Nutzen).
Tabelle 3.5: Risikoanalyse – Social Engineering betreiben (Baum 1.3.n)
3.4.2 Analyse zu Kunden austricksen und manipulieren
Die in diesem Abschnitt analysierten Angriffsvorgehen greifen in Echtzeit, d.h. während der Kunde die Internetbanking Überweisung durchführt, in die Kommunikation
zwischen Banksystem und Kunde ein (vgl. Knoten 2 aus Abbildung 3.7: Angriffsbaum
Internetbanking Überweisung). Die Betrachtung erfolgt unterteilt nach den Knoten
(samt Folgeknoten):
 2.1 MITM Angriff betreiben in Tabelle 3.6 (#Baum 2.1.n.n) sowie
 2.2 Social Engineering betreiben in Tabelle 3.7 (#Baum 2.2.n.n).
54
Eigenschaft
Beschreibung
#Baum
2.1.n.n
Angriffsvorgehen
2.1
MITM Angriff betreiben (oder/und)
2.1.1
2.1.2.1
2.1.2.2
Replay anwenden
Packet Sniffer
2.1.3
Pharming betreiben
2.1.2.3
2.1.2.4
2.1.2 Malware einsetzen (oder/und)
Datenpaket manipulieren
Session hijacking
2.1.4 Datenpaket manipulieren
Risikoanalyse
Diese Angriffsvorgehen stellen aufgrund unten aufgeführter, risikoreduzierender und bereits praktizierter Maßnahmen für die Bank ein geringes Risiko
dar (insbesondere die verschlüsselte Kommunikation vereitelt die Kryptoanalyse mit anschließender Manipulation in Echtzeit).
 Bereits unter Knoten 1.2.n.n. praktizierte Sicherheitsmaßnahmen. ()
 IDS/IPS zur Anomalieerkennung in Kommunikationssitzung nutzen. ()
 Verwendung einer langen, zufällig generierten, während der Internetbankingsitzung wechselnden, zeitlich begrenzt gültigen Sitzungsnummer. ()
Betreffende Angriffsmöglichkeiten können als nicht kritisch gewertet und die
bereits praktizierten Maßnahmen als ausreichend befunden werden.
Folgerung
Tabelle 3.6: Risikoanalyse – MITM Angriff betreiben (Baum 2.1.n.n)
Eigenschaft
Beschreibung
#Baum
2.2.n.n
Angriffsvorgehen
2.2
Social Engineering betreiben (oder/und)
2.2.1
2.2.2 Malware einsetzen (oder/und)
2.2.2.1 MITB benutzen 2.2.2.2 Seitenaufruf umleiten 2.2.2.3 Website spoofing einsetzen
2.2.3
Risikoanalyse
Pharming betreiben
2.2.4 Website spoofing einsetzen
Für die Bank stellen die Angriffsvorgehen ein hohes Risiko mit stetig steigender Schadensumme dar. Der hierbei entscheidende Faktor ist der manipulierbare Kunde, der bei der Überweisungsdurchführung geschickt mit immer
neuen Betrugsmaschen vom Angreifer ausgetrickst wird. Es ergibt sich eine
auf Kulanz von der Bank regulierte Schadenssumme:
1.300 Schäden p.a. x 1.500 EUR = 1.950.000 EUR p.a.
Folgerung
 Bereits unter Knoten 1.3.n. benannte Sicherheitsmaßnahmen. ()
 Einsatz von Sicherheitsverfahren, welche die Überweisung zur Freigabe
zusätzlich auf weiteren Geräten (Handy bzw. Kartenleser der Sicherheitsklasse 3) anzeigen, um das Austricksen des Kunden zu erschweren. ()
Trotz praktizierter Maßnahmen besteht ein hohes Risiko. Zur Reduktion ist
die Empfehlung umzusetzen bzw. zu prüfen (Kosten/Nutzen). Bei der Prüfung
ist zu berücksichtigen, dass absehbar ist, dass eine komplette Eliminierung
des Risikos hierdurch nicht zu erreichen ist.
Tabelle 3.7: Risikoanalyse – Social Engineering betreiben (Baum 2.2.n.n)
3.4.3 Analyse zu Banksystem kompromittieren
Die im Folgenden analysierten Angriffsvorgehen sind direkt auf das Banksystem
gerichtet, ohne dass der Kunde hierbei unmittelbar involviert ist (vgl. Knoten 3 aus
55
Abbildung 3.7: Angriffsbaum Internetbanking Überweisung). Dabei erfolgt die Betrachtung unterteilt nach den Knoten (samt Folgeknoten):
 3.1 Kunden Credentials erraten in Tabelle 3.8 (#Baum 3.1.n) sowie
 3.2 Internetbanking manipulieren in Tabelle 3.9 (#Baum 3.2.n).
Eigenschaft
Beschreibung
#Baum
3.1.n
Angriffsvorgehen
3.1
Kunden Credentials erraten (oder)
3.1.1
Brute force Attack durchführen
Risikoanalyse
Dieses Angriffsvorgehen stellt für die Bank kein nennenswertes Risiko dar.
Das mögliche Kalkulieren der Credentials wird ausgeschlossen und das
erfolgreiche Erraten der 5-stelligen PIN und im Anschluss der 6-stelligen iTAN
(nicht klassische TAN, d.h. die Wahrscheinlichkeit die TAN beim ersten Mal zu
erraten, schrumpft von theoretisch 100/106 auf 1/106) in jeweils 3 Versuchen
ist äußerst unwahrscheinlich:
(
(
Folgerung
(
(
)
)
(
(
(
)
))
(
)
))
0,000000009%
 Der Kunde wird darauf hingewiesen die Initial-PIN zu ändern. ()
 Die Autorisierung einer Überweisung erfolgt zusammen mit der iTAN. ()
 3 Falscheingaben der PIN oder TAN führen zur Kontosperre. ()
Betreffende Angriffe sowie das Restrisiko können als nicht kritisch gewertet
und die bereits praktizierten Maßnahmen als ausreichend befunden werden.
Tabelle 3.8: Risikoanalyse – Kunden Credentials erraten (Baum 3.1.n)
Eigenschaft
Beschreibung
#Baum
3.2.n
Angriffsvorgehen
3.2
Internetbanking manipulieren (oder)
3.2.1
3.2.2
SQL-Injection durchführen
Buffer overflow durchführen
Risikoanalyse
Aufgrund unten aufgeführter, risikoreduzierender und bereits praktizierter
Maßnahmen stellen die Angriffsvorgehen für die Bank ein geringes Risiko dar.
 Einsatz von Firewalls, IDS/IPS und SIEM u. einem Pacht-Management. ()
 Software-Qualitätsmanagement einschließlich Testumgebungen. ()
 Durchführung regelmäßiger Penetrationstests. ()
 Security-Teams / Leitstands u. Security-Revision etablieren. ()
Die praktizierten Maßnahmen führen zu einem akzeptablen Restrisiko. Die
ordnungsgemäße kontinuierliche Durchführung ist sicherzustellen.
Folgerung
3.2.3
Command-Injection durchführen
Tabelle 3.9: Risikoanalyse – Internetbanking manipulieren (Baum 3.2.n)
56
3.5 Modellierung der Einwirkung auf Prozesse
Wie aus der Analyse im vorherigen Abschnitt hervorgeht, sind es die auf Social Engineering zurückzuführenden Angriffe, die für die Bank das höchste Risiko ergeben. Vor
diesem Hintergrund wird nachfolgend dargestellt, wie diese Angriffsvorgehen auf den
Geschäftsprozess der Internetbanking Überweisung (vgl. 3.2.1 Internetbanking
Überweisung) einwirken, um hieraus Erkenntnisse für die Verbesserung von Sicherheitsmaßnahmen zu gewinnen. Hierzu erfolgt die Modellierung des Angriffs, bei dem
der Angreifer die MITB Methode (vgl. 3.3.2 Kunden austricksen und manipulieren,
Knoten 2.2.2.1) nutzt, da sich diese mit der herkömmlichen auf den Basisereignissen
aus der Netzwerkkommunikation basierenden Sicherheitsanalyse nicht erkennen lässt
und somit einen geeigneten Ansatz bietet, Ereignisse auf Geschäftsprozessebene
aufzuzeigen, die wiederum eine Angriffserkennung ermöglichen.
3.5.1 Misuse Case Internetbanking Überweisung
Das unten abgebildete Diagramm zeigt die bereits beschriebenen Anwendungsfälle
zum Internetbanking sowie die aus einem MITB Angriff hervorgehenden bösartigen
Prozesse mit den Akteuren Angreifer und Malware wie z.B. die Trojaner ZeuS, URLZone oder SpyEye.1 Die Beschreibung kann der Tabelle 3.10 entnommen werden.
Identität
authentisieren
Internetbanking
<<include>>
<<include>>
Kunde
Login auf Webseite
<<extend>>
{Kunde wünscht
eine Überweisung
zu tätigen}
Finanzstatus
anzeigen
<<threat>>
{Kunde wird dazu
gebracht eine
Überweisung für
den Angreifer
durchzuführen}
Zur Überweisung
auffordern
<<extend>>
Kundenrechner
infizieren
Banksystem
<<include>>
MITB Methode
einsetzen
Überweisung
beauftragen
Angreifer
<<include>>
<<include>>
Browser
Transaktion
autorisieren
Transaktion
erfassen
<<threat>>
<<extend>>
<<threat>>
{Dem Kunden
werden falsche
Überweisungsinhalte angezeigt}
Überweisung
einschleusen
Malware
Abbildung 3.13: Misuse-Case Diagramm zur Internetbanking Überweisung
1
Nachfolgende Beschreibungen/-abläufe basieren auf den von der Bank vorliegenden Schadensberichten.
57
Eigenschaft
Beschreibung
Name/Titel
MITB Methode einsetzen (include: Kundenrechner infizieren)
Angriff
Der Angreifer infiziert das Kundensystem mit Schadprogrammen, die im
Moment des Internetbankingaufrufs durch den Browser aktiv werden.
Sobald sich der Kunde erfolgreich eingeloggt hat, wird über eine HTMLInjection die originale Website der Bank um eine Mitteilung des Angreifers
ergänzt (z.B. Hinweis auf eine Fehlbuchung mit der Bitte um Korrekturüberweisung), die den Kunden dazu bewegt eine Überweisung im Sinne
des Angreifers zu beauftragen. Alternativ wird dem Kunden bei der
Transaktionserfassung eine manipulierte Erfassungsmaske eingespielt, die
der Kunde wie gewohnt befüllt. Die erfassten Daten werden ihm zur
Freigabe erneut angezeigt und im Anschluss ohne Bedenken von ihm
autorisiert. Tatsächlich allerdings wurde für den Kunden unbemerkt im
Hintergrund eine manipulierte Überweisung an das Banksystem gesandt
und autorisiert.
Lokales
Diagramm
siehe Abbildung 3.13: Misuse-Case Diagramm zur Internetbanking Überweisung
Beziehungen
Zur Überweisung auffordern, Überweisung einschleusen
Akteure
Kunde (legitimiert), Browser, Banksystem, sowie Angreifer, der dem Profil
des Kriminellen (vgl. Tabelle 2.1) entspricht, und Malware.
Vorbedingung
Der Kunde muss im Internetbanking angemeldet sein und der Kundenrechner bzw. Browser mit einem Trojaner wie z.B. ZeuS, URLZone oder
SpyEye infiziert sein
Nachbedingung
Die manipulierte Transaktion wurde freigegeben und damit autorisiert zur
Weiterverarbeitung an das Banksystem übergeben.
Ablauf
Bemerkungen
Die erstbeschriebene Variante des MITB Angriffs ist auch dann noch
effektiv, sofern der Kunde keinen Verdacht schöpft, wenn wie unter den
Sicherheitsanforderungen empfohlene Sicherheitsverfahren, welche die
Überweisung zur Freigabe zusätzlich auf weiteren Geräten (wie z.B. Handy
bzw. Kartenleser der Sicherheitsklasse 3) anzeigen, Verwendung finden.
Tabelle 3.10: Misuse-Case Beschreibung MITB Methode einsetzen
3.5.2 Mal-Activity Internetbanking Überweisung
Der bereits vorgestellte Prozessablauf (vgl. 3.2.2 Prozessablauf der Überweisung) wird
in den folgenden Diagrammen um die bösartigen Prozesse aus dem MITB Angriff
ergänzt. Das erste Diagramm zeigt das Login (AWF1) und die hierauf einwirkenden
Prozesse der ergänzten Akteure Angreifer und Malware sowie vorangestellt deren
anbahnende Aktivitäten. Letzteres dient dem besseren Verständnis und späteren
Ableiten von Anhaltspunkten für die Angriffserkennung. Das zweite Diagramm stellt
den ergänzten Ablauf des Überweisungsprozesses (AWF2) dar, dass ebenfalls zum
besseren Verständnis und Ableiten mit den Folgeaktivitäten des Angreifers abschließt.
58
Kunde
Browser
Malware
Banksystem
Angreifer
Öffnet E-Mail und
führt Trojaner aus
Sendet E-Mail
mit Trojaner
infiziert System / Browser
ruft https
Adresse auf
sendet ClientHello
lässt Money Mules
Bankkonten eröffnen
Hinterlegt Bankverbindungen in Angreifer-Host
erkennt Aufruf u.
verbindet sich mit Host
antwortet ServerHello mit Zertifikat
sendet Handshake mit Zertifikat
Eingabe: Kontonummer und PIN
erwidert Handshake
wählt MITB Angriffsvariante
fragt Website an
sendet Login- Website
zeigt Login Website an
loggt sich ein
prüft die Eingabe
[VAR 1
(Zur Überweisung
auffordern)]
[NOK]
zählt Eingabeversuch
[VAR 2
(Überweisung
einschleusen)]
[<3]
[OK]
sendet F-Login-Website
zeigt F-Login-Website an
generiert HTML-Code
mit Kundenmitteilung u.
Fehlbuchung
zeigt manipulierte
Finanzstatus-Website an
injiziert HTML-Code in
Finanzstatus-Website
zeigt PIN-Sperre-Website an
[=3]
sendet Mitteilungsinhalt u.
Bankverbindung
sendet Finanzstatus-Website
sperrt PIN
sendet PIN-Sperre-Website
Abbildung 3.14: Mal-Activity Diagramm Internetbanking Login
Die Angriffsanbahnung erfolgt durch den Versand eines Trojaners an den Kunden per
E-Mail, um dessen System zu infizieren. Das Kundensystem kann wie erwähnt auch
auf anderem Weg infiziert werden (vgl. 3.3.4 Kundenrechner infizieren). Gleichzeitig
kümmert sich der Angreifer stetig um neue Finanzagenten einschließlich Bankkonten,
die als spätere Empfänger der manipulierten Überweisung dienen, und hinterlegt
betreffende Kontoverbindungen in einer Datenbank auf seinem Host. Sobald der
Trojaner den Aufruf der Internetbanking Adresse erkennt, verbindet sich dieser mit
dem Host, der ihn anweist, welche MITB Angriffs-Variante vom Angreifer durchgeführt werden soll. Soll eine Überweisung eingeschleust werden (VAR 2), überwacht
der Trojaner die Browseraktivitäten, bis es zur Überweisungsbeauftragung kommt.
Soll der Kunde dagegen dazu gebracht werden eine Überweisung im Sinne des Angreifers durchzuführen (VAR 2), wird diesem nach dem Login eine vom Host bereitgestell59
te Aufforderung zur Korrekturbuchung einer Fehlbuchung, die zugleich auch in seinen
letzten Kontoumsätzen erscheint, durch HTML-Injection des Trojaners angezeigt.
Kunde
Browser
Malware
verarbeitet Auswahl
fordert Überweisungsmaske direkt an
Banksystem
Angreifer
[VAR 1]
bestätigt die
Korrekturbuchung
durchzuführen
[VAR 2]
übernimmt Eingabe
zeigt vorausgefüllte
Überweisungsmaske an
befüllt Felder in
Überweisungsmaske
wählt
Überweisung
fragt Überweisung an
erkennt Anfrage u.
verbindet sich mit Host
wählt
Überweisungsart
Sendet
Bankverbindung
zeigt ÜberweisungsWebsite an
sendet Überweisungs-Website
generiert HTML-Code
zur Maskenmanipulation
Eingabe:
Empfänger
Name, Bank u.
Konto; Betrag;
Zweck; etc.
injiziert HTML-Code mit
Masken-Dummy als Frame
im Vordergrund
zeigt Masken-Dummy an
befüllt Felder in
Überweisungsmaske
im Hintergrund
prüft die Eingabensyntax
gibt Überweisung ein
sendet erfasste Eingabe(n)
[VAR 2] liest Eingabe aus
Masken-Dummy
[VAR 1]
zeigt Überweisungsmaske
mit Fehler an
[NOK]
[OK]
sendet Fehler Maske
generiert HTMLCode zur FreigabeWebsite
Eingabe: TAN
zeigt Überweisungsmaske
mit Limit an
zeigt FreigabeWebsite an
gibt Auftrag frei
prüft Kontolimit
[NOK]
[OK]
sendet Limit Maske
[VAR 1]
injiziert HTMLCode mit MaskenDummy Eingaben
sendet Freigabe-Website
[VAR 2]
sendet Freigabedaten
prüft Feigabe
[NOK]
generiert HTML-Code
zur Bestätigungs-Website
[OK]
zählt Freigabeversuch
weiterverarbeiten
[<3]
[=3]
zeigt Fehler-Website an
sendet Fehler-Website
sperrt TAN
zeigt TAN-SperreWebsite an
zeigt BestätigungsWebsite an
sendet TAN-Sperre-Website
[VAR 1]
injiziert HTMLCode mit MaskenDummy Eingaben
sendet BestätigungsWebsite
[VAR 2]
sendet Bericht an Host
weist Money Mule
an Geld abzuheben
und anonym zu
transferieren
betreibt Geldwäsche
Abbildung 3.15: Mal-Activity Diagramm Internetbanking Überweisung
60
Entscheidet sich der Kunde der dem Anschein nach von der Bank stammenden Aufforderung nachzukommen, braucht er dieser lediglich durch eine Buttonbetätigung
zuzustimmen und der Trojaner fordert über den Browser auf direktem Wege die
Überweisungsmaske vom Banksystem an. Der Browser zeigt dem Kunden im nächsten Schritt die vom Banksystem bereitgestellte und vom Trojaner vorausgefüllte
Überweisungsmaske, die entsprechend der erfundenen Fehlbuchung den selben
Empfänger und Betrag (der Betrag ergibt sich aus dem aus dem im Original Finanzstatus ermittelbaren Verfügungsrahmen bzw. Kontosaldo, der diesen nicht übersteigt)
aufweist, an. Der Kunde übernimmt die Eingaben, um die Korrekturbuchung durchzuführen. Daraufhin wird der reguläre Überweisungsprozess durchlaufen, indem der
Browser die Eingaben an das Banksystem übermittelt und dem Kunden zuletzt die
Bestätigungs-Website zur gerade von ihm autorisierten Überweisung zugeht. Der
Trojaner wirkt in diesen Prozess nicht weiter ein, sondern sendet lediglich einen
Bericht über Erfolg oder Misserfolg sowie zu den Zahlungsdetails an den Host.
Wurde der Trojaner hingegen angewiesen nach der zweiten Variante (VAR 2) zu
verfahren, d.h. eine Überweisung einzuschleusen, würde dieser erst dann wieder
aktiv, sobald der Kunde das Überweisungsmenü über den Browser aufruft. Der
Trojaner ruft dann eine aktuelle Kontoverbindung vom Host des Angreifers ab, die er
zur Befüllung der Überweisungsmaske verwendet. Zuvor generierte der Trojaner
einen HTML-Code, der in die Originalwebsite injiziert wird, sodass ein HTML-Frame
mit einem Masken-Dummy im Vordergrund, d.h. vor der eigentlichen Eingabemaske,
vom Browser angezeigt wird, sodass der Kunde von der Befüllung durch den Trojaner
nichts mitbekommt und den Masken-Dummy mit seinen Überweisungsdaten befüllt.
Im Ergebnis sendet der Kunde statt seiner Überweisung die vom Trojaner eingeschleuste Überweisung an das Banksystem. Damit der Kunde keinen Verdacht
schöpft, verwendet der Trojaner die im Masken-Dummy erfassten Daten und zeigte
diese ebenfalls per HTML-Injection in der Freigabe- und Bestätigungs-Website an.
Diese Verschleierung kann sich fortsetzen, indem dem Kunden, wenn er in der bestehenden Internetbanking Sitzung über die Finanzstatus-Website seine Umsätze erneut
prüfen möchte, die aus dem Masken-Dummy stammenden Eingaben statt des tatsächlichen Umsatzes per HTML-Injection eingespielt werden. Abschließend sendet
der Trojaner, wie auch schon bei der ersten Variante, einen Bericht an den Host.
61
Bei beiden Varianten stellt der Host dem Trojaner für die Überweisungsgutschrift eine
Bankverbindung zur Verfügung, die bei derselben Bank wie das vom Angriff betroffene Kundenkonto geführt wird, da die Zielbuchung innerhalb der Bank unmittelbar
nach der Autorisierung erfolgt. Hierdurch ist der Angreifer in der Lage, den Finanzagenten zeitnah anzuweisen, das aus dem MITB-Angriff stammende Geld von seinem
Konto an ihn zu transferieren, was das Zeitfenster für die Bank hinsichtlich der Angriffserkennung und etwaiger Gegenmaßnahmen, wie z.B. die Sperrung des Zielkontos oder einem Überweisungsrückruf, erheblich eingrenzt. Das Transferieren des
gestohlenen Geldes an den Angreifer erfolgt anonym. Hierzu hebt der Finanzagent in
der Regel das Geld bar ab und nutzt im Anschluss den Finanztransaktionsservice von
Western Union1, um die Spur zu den Bankkonten zu verwischen und das Geld in
Länder zu transferieren, wo größere Bareinzahlungen auf Konten des Anbieters
WebMoney2 möglich sind, sodass das Geld anonym zum Angreifer gelangt. Der
Angreifer betreibt dann die finale Geldwäsche.
3.5.3 Objekte bei der Internetbanking Überweisung
Das unten abgebildete Klassendiagramm veranschaulicht die bei der Internetbanking
Überweisung relevanten Objekte und deren Beziehungen. Es dient dem besseren
Verständnis und der Ableitung von Angriffserkennungsansätzen im nächsten Kapitel.
Lastbuchung
Person
-girokonto: Kontonummer : int
-EmpängerKonto : int
-EmfängerName : string
-EmpfängerBank : string
-EmpfängerBankCode : int
-Verwendungszweck : string
-Betrag : int
-Buchungsdatum : int
-Auftragsart : int
-Umsatz : struct
+setUmsatz()
0..*
-umsatz
-überweisung
0..*
0..*
1..1
-gegenbuchen
-name: Name
-adresse: Adresse
-geschäftspartner: GP_ID
-Gebieitsfremder : bool
+getAdress() : Adresse
+getName() : Name
-person
Girokonto
0..1
1..*
-name
0..* 1..1
Name
Adresse
-Name : string
-Vorname : string
-Titel : string
-Strasse : string
-Hausnummer : string
-Postleitzahl : string
-Ort : string
-Land : string
-adresse
0..*
1..1
1
1..1
Geschäftspartner
-Kontonummer : int
-BankCode : int
-girokonto
-Eröffnungstag : int
-Saldo : double
Credentials
-girokonto
-Limit : float
-girokonto: Kontonummer
-buchung: Umsatz
-PIN : int
-Kontoart : int
0..* 1..1 -iTAN : struct
+getUmsatz()
-finanzstatus
0..*
-nutzt
-login, überweisung
1..1
Internetbanking
1..* 1..1
+Login() : Credentials
+Überweisung() : Buchung
+Finanzstatus() : Girokonto
1..1
1..*
Kunde
-GP_ID : int
-person: Person
-girokonto: Kontonummer
+getPerson() : Person
+getGirokonto() : Girokonto
1..1
1..1
Buchung
Gutschrift
Abbildung 3.16: Objekte bei der Internetbanking Überweisung
1
2
ermöglicht weltweiten Geldversand ohne Bankkontenverwendung (vgl. [85] Western Union, 2011)
der Transfer zwischen den Konten von WebMoney ist anonym und es sind Ein- und Auszahlungen in
Bar oder per Überweisung möglich (vgl. [86] WebMoney, 2011 und [87] WebMoney, 2011)
62
Erkenntnisse und Implikationen
4 Erkenntnisse und Implikationen
Wie die Analyse im vorangegangen Kapitel ergeben hat, sind es die Angriffe auf Basis
des Social Engineerings, die für die Bank das höchste Risiko ergeben und denen
aufgrund des Faktors Mensch nur schwer mit technischen Sicherheitsmaßnahmen
beizukommen ist. Diese Schwierigkeit wird eindrucksvoll vom im vorherigen Kapitel
modellierten MITB-Angriff demonstriert, der zusätzlich die Schwachstellen bei den
vom Kunden eingesetzten Endgeräten ausnutzt, die, wie bereits als Problematik bei
der Endpoint-Security (vgl. 2.1.3 Angriffe und Angreifer) erwähnt, außerhalb des
Einflussbereichs der Bank liegen. Dabei wird aus den Mal-Activity Diagrammen ersichtlich, dass der durchschnittliche Kunde die Manipulation ad-hoc nur schwer oder
gar nicht erkennen kann. Viel gravierender ist jedoch, dass dasselbe auch für die Bank
gilt. Die Bank ist mit den herkömmlich eingesetzten Sicherheitsmaßnahmen nicht in
der Lage die Angriffe zeitnah zu erkennen, da ihr der Angriff wie eine gewöhnliche
Überweisung erscheint. Vor diesem Hintergrund setzt sich das letzte Kapitel mit dem
Aufzeigen einer auf den Geschäftsprozessen der Bank basierenden Sicherheitsanalyse, die eine rechtzeitige Angriffserkennung zum Ziel hat, auseinander.
4.1 Geschäftsprozessereignisbasierte Sicherheitsanalyse
Wie in der Praxis bei Basisereignissen mit Hilfe von SIEMs bereits üblich, lassen sich
auch komplexe Beziehungen mit Ereignissen auf Geschäftsprozessebene (vgl. 2.3.6
Correlation) abbilden. Allerdings ist die hierfür erforderliche Erstellung von sinnvollen
Kontext-Informationen, die den SIEMs zur Korrelation dienen, im Gegensatz zu den
Basisereignissen deutlich aufwendiger. Bei Basisereignissen kann branchenübergreifend ohne große Anpassung auf (Wissens-) Datenbanken mit Angriffsmustern oder
Kennzahlen und Regeln zur Anomalieanalyse zurückgegriffen werden. Bei Geschäftsprozessereignissen hingegen ist eine individuelle Prozessanalyse, die in der Regel für
das Unternehmen von branchenspezialisierten externen Consultants erbracht wird, 1
notwendig, um verwendbare Ereignisse zu identifizieren. Infolgedessen wird in den
nächsten Abschnitten mit Hilfe der aus der vorangegangen Untersuchung der Internetbanking Überweisung erlangten Erkenntnisse ein für die Finanzbranche geeignetes
1
Umgebungen und Business ist zu individuell, als dass diese durch SIEM Anbieter erbracht werden
kann, vgl. [88] Libeau, 2011 und [89] Hild, 2011.
63
Modell zur geschäftsprozessereignisbasierten Sicherheitsanalyse aufgezeigt. Hierzu
werden im nächsten Abschnitt Ereignisse auf der Geschäftsprozessebene abgeleitet,
die im Modell als Angriffsindikatoren dienen.
4.1.1 Ableitung von Angriffsindikatoren
Bei der Suche nach Indikatoren für Angriffe ist es naheliegend, dass man sich zunächst
ausschließlich dem betreffenden Geschäftsprozess widmet. Im Fall der Internetbanking Überweisung wird allerdings deutlich, dass es durchaus möglich wäre, sobald das
Banksystem den Eingang des erfassten Überweisungsauftrags registriert, die Dateninhalte (vgl. Klasse Buchung in Abbildung 3.16: Objekte bei der Internetbanking Überweisung), wie z.B. den Verwendungszweck auf Auffälligkeiten (z.B. hohes Aufkommen
eines identischen oder ähnlichen Inhalts) hin zu prüfen, jedoch einen Angriff daran
festzumachen zu unpräzise wäre und somit zu viele false positves oder negatives
produzieren würde.1 Stattdessen ist die Kombination von Indikatoren auf Basis von
geschäftsprozessübergreifenden Ereignissen in der Lage, Angriffe weitaus präziser zu
erkennen. Dabei ist es sinnvoll, auch Geschäftsprozesse zu berücksichtigen, die nicht
unmittelbar in Beziehung zueinander stehen. So hat der Kontoeröffnungsprozess, der
auch bei der Konteröffnung des Finanzagenten durchlaufen wird, mit dem eigentlichen Geschäftsprozess der Internetbanking Überweisung zwar nur einen indirekten
Bezug, allerdings lassen sich aus diesem Angriffsindikatoren ableiten. Dasselbe gilt für
etwaige Geschäftsprozesse der Bank, die vom Angreifer bzw. Finanzagenten nach
dem eigentlichen Angriff auf die Internetbanking Überweisung genutzt werden, wie
z.B. den Geldtransfer mit Western Union. Dementsprechend können Ereignisse zur
besseren Angriffserkennung geschäftsprozessübergreifend als Indikatoren herangezogen werden. Dabei lassen sich die Indikatoren wie im nächsten Abschnitt nach
ihrem zeitlichen Auftreten klassifizieren.
4.1.2 Indikatoraussagen
Bei den Indikatoren handelt es sich um Aussagen, die den Verdacht eines Angriffs
darlegen. Als erstes werden die Indikatoraussagen hergeleitet, die sich aus den
Ereignissen, die vor dem Angriff stattfinden, entnehmen lassen:
1
*
+.
Banken verarbeiten täglich etwa 10 Mio. Transaktionen vgl. [03] IBM Deutschland GmbH, 2011
64
Da die Banken selbst oder auf Verlangen des BKA für den Betrug verwendete festgestellte Zielkonten sperren oder auflösen, ist der Angreifer gezwungen, sich stetig neue
Kontoverbindungen bei der zum Angriff vorgesehenen Bank über den Finanzagenten
zu beschaffen. Der Angreifer wendet sich dabei an Privatpersonen und wirbt diese für
die Eröffnung oder Verwendung eines bereits bestehenden Kontos und der Weiterleitung von Geldern gegen entsprechende Bezahlung an. Da den vom Angreifer angesprochenen Personen zu unterstellen ist, dass den meisten bewusst ist, auf welche
kriminellen Handlungen (vgl. GWG) sie sich einlassen, eröffnen diese, wenn sie den
Job annehmen, ein separates Konto, um gefühlt mehr Kontrolle und Anonymität zu
erlangen oder lehnen den Job von vornherein ab. Aufgrund Letzterem heuern Angreifer auch gerne Personen aus dem Ausland an. Aus oben allgemeinhin bekannter
Vorgehensweise lassen sich die unten stehenden Indikatoraussagen folgern.

Eröffnung des Zielkontos vor weniger als 4 Monaten

regelmäßige Gehalts-/Renten-Zahlungseingänge auf das Zielkonto

Zielkonto entspricht der Kontoart Privatkundenkonto

Kontoinhaber ist gebietsfremd (Kundenwohnsitz im Ausland)

auf dem Zielkonto erfolgen Lastschrifteinzüge

Zielkontoinhaber unterhält mehrere Girokonten bei der Bank
Aus den Ereignissen, die während des eigentlichen Ablaufs bzw. Angriffs der Internetbanking Überweisung stattfinden, lassen sich die folgenden Indikatoren ableiten:
*
+.

geballter Eingang mehrerer Internetbanking Überweisungen auf ein Zielkonto

Verwendungszweck ist zu vielen anderen Überweisungen gleich oder ähnlich
So ist es aus Sicht des Angreifers zweckmäßig, ein verfügbares Zielkonto gleich für
mehrere manipulierte Internetbanking Überweisungen zu nutzen und diese in einem
engem Zeitrahmen durchzuführen, um so effizient wie möglich zu verfahren bis der
Angriff auffällt. Des Weiteren ist davon auszugehen, dass die beim Angriff vom Trojaner eingesetzten Verwendungszwecke gleich sind oder sich zumindest ähneln.
Ereignisse, die aus Handlungen nach dem eigentlichen Angriff resultieren, erlauben
auf die folgenden Indikatoren zu schließen:
*
+.
65

bei Kundenreklamation wird ein vom Angreifer genutztes Zielkonto identifiziert

Kontoinhaber eines Zielkontos nutzt Western Union Service

Guthaben am Zielkonto wird durch Barauszahlungen abgeschöpft
So werden, wie bereits erwähnt, die meisten Angriffe durch den Kunden erkannt.1
Dabei wird die Bank in der Regel durch Nachforschung einer Reklamation zu beim
Kunden aufgekommenen Widersprüchlichkeiten oder Zweifel auf Zielkonten des
Angreifers bzw. Finanzagenten aufmerksam. Des Weiteren nutzen diese zum Abschöpfen und Transfer der auf den Zielkonten gesammelten Überweisungsbeträge
Barauszahlungen und Transferservices wie z.B. Western Union. Beides wird vom
Finanzagenten durchaus in derselben Bank bzw. Filiale durchgeführt.
4.1.3 Sicherheitsanalysemodell
Auf Basis der oben aufgeführten Indikatoren wird in diesem Abschnitt ein Modell
aufgezeigt, welches sich für eine Sicherheitsanalyse in Echtzeit, wie sie durch den
Einsatz eines SIEMs praktiziert werden kann, eignet. Dabei bilden die Indikatoren
sowie das Ereignis
{Weiterverarbeitung der freigebenden Internetbanking
Überweisung} Teilaussagen, die als Gesamtaussage für das Anzeigen eines potenziellen Angriffs kombiniert genutzt werden können. D.h. ist/sind die Bedingung(en) der
(Gesamt-)Aussage erfüllt bzw. wahr, liegt ein potenzieller Angriff
vor. Die erste
hierfür verwendete kombinierte Aussage bezieht sich auf den Fall, dass das Zielkonto
bereits als Angriffskonto erkannt ist und eine weitere manipulierte Internetbanking
Überweisung auf dieses erfolgt:
Die zweite Kombination zielt auf kürzlich eröffnete Privatkundenkonten ab, die in
dieser Zeit Auffälligkeiten aufwiesen:
(
( (
)
))
In der nächsten Kombination werden Privatkundenkonten berücksichtigt, auf denen
Internetbanking Überweisungen gutgeschrieben werden, die Auffälligkeiten hinsichtlich der Zahlungsdetails sowie der Häufigkeit aufweisen:
1
75% der Schäden bei Banken werden zuerst durch den Kunden erkannt, vgl. [18] FICO - Fair Isaac
Corporation, 2011
66
Die letzte kombinierte Aussage bezieht sich auf Privatkundenkonten, die durch eine
Ballung von Internetbanking Gutschriften und ähnliche/gleiche Zahlungsdetails oder
in Verbindung mit Western Union Transaktionen auffallen:
(
)
Aus den oben kombinierten Teilaussagen ergibt sich die folgende Gesamtaussage:
(
(
((
( (
)
))
(
)
(
(
)))))
Diese kann als Kontext-Information (vgl. 2.3.6 Correlation) in SIEMs hinterlegt und
somit zur Erkennung von potenziellen Angriffen auf die Internetbanking Überweisung
genutzt werden.
4.2 Sicherheitsanforderungen und Implikationen für die Praxis
Die vorliegende Arbeit liefert - neben den aus der Analyse (vgl. 3.4 Risikoanalyse und
Sicherheitsanforderungen) hervorgegangen Empfehlungen - die zusätzliche Erkenntnis, die Anwendung der oben modellierten geschäftsprozessereignisbasierten Sicherheitsanalyse in die Sicherheitsanforderungen der Bank aufzunehmen, um der
Schwachstelle Mensch beim Social Engineering Angriff mit einer effektiven Maßnahme zu entgegnen. Für die Umsetzung dieser Maßnahme liefern SIEMs die unterstützenden Funktionen.
SIEMs bieten mit der Verarbeitungskette Collection, Normalization, Aggregation,
Correlation und Reporting (vgl. 2.3.2 Funktionsweise von SIEMs) die ideale Unterstützung zu der geschäftsprozessereignisbasierten Sicherheitsanalyse in Echtzeit.
Die Herausforderung bei der Umsetzung ergibt sich beim Einsammeln der Ereignisse,
die als Indikatoren genutzt werden. Betreffende Ereignisse stammen dabei aus
unterschiedlichen Systemen, wie z.B. dem Kontoführenden System. Bei Kontoeröffnung werden die relevanten Daten (z.B. Kontoeröffnungsdatum und Kontoart) in
einer Datenbank ablegt, ohne dabei von vornherein für das SIEMs verarbeitbare
Logdaten inklusive der erforderlichen Dateninhalte bereitzustellen.
Trotz des Einsatzes von SIEM Agenten läuft es an dieser Stelle auf individuelle Entwicklungsarbeiten hinaus. Eine gewöhnliche Datenbankabfrage ist vor dem Hinter-
67
grund des hohen Transaktionsaufkommens 1 und der Echtzeitanforderung als performancekritisch zu werten. Um den SIEMs die für die Sicherheitsanalyse erforderlichen
Daten zugänglich zu machen, ist, wie bei Sicherheitssoftware wie z.B. IDS bereits
üblich, die Bereitstellung von Geschäftsprozessereignissen in Standardprotokollen wie
z.B. SNMP (vgl. 2.3.3 Collection) anzustreben.
4.3 Implikationen für die Forschung
Ausgelegt auf den Malware gestützten Social Engineering Angriff, wurde in dieser
Arbeit ein spezifisches Modell entwickelt, dass aufzeigt, wie der Schwierigkeit beizukommen ist, wenn herkömmliche technischen Sicherheitsmechanismen und auf
Basisereignisse beruhende Sicherheitsanalysen nicht ausreichend sind.
Durch eine Verifikation des Modells unter realen Bedingungen bzw. unter Verwendung von Echtdaten können zusätzliche Erkenntnisse zur Verbesserung des Modells
erlangt werden. Dabei können weitere Indikatoraussagen und Geschäftsprozesse
eingebracht und die im Modell verwendete Wahrheitswertlogik auf Mehrwertlogiksysteme erweitert werden, um die Angriffserkennung zu präzisieren.
4.4 Zusammenfassung
Banken weisen, wie die Bedrohungs- u. Risikoanalyse zu einem exemplarischen
Anwendungsfall einer deutschen Universalbank in dieser Arbeit zeigt, grundsätzlich
ein hohes Sicherheitsniveau auf. Dennoch ergeben sich immense Schäden aus Angriffen, die auf die Schwachstellen Mensch in Form des Bankkunden und EndpointSecurity in Form des Kundensystems zurückzuführen sind.
Beide Gefährdungen sind nur schwer zu sichern, da sie außerhalb des Einflussbereichs
der Banken liegen. Mit der Entwicklung des Modells zur geschäftsprozessereignisbasierten Sicherheitsanalyse kann dazu beigetragen werden, dieses allgemein für die
Branche gegenwärtige Problem zu lösen. Das Modell zeigt dabei auf, wie mit Zuhilfenahme von SIEMs und geschäftsprozessübergreifenden Ereignissen potenzielle
Angriffe frühzeitig erkannt werden können.
1
Banken verarbeiten täglich etwa 10 Mio. Transaktionen vgl. [03] IBM Deutschland GmbH, 2011
68
VI. Anlagen
Abbildung: Angriffsbaum Internetbanking Überweisung (komplett)
VII. Literaturverzeichnis
[01] ZEIT ONLINE, dpa, Reuters. (5. 10 2010). Ex-Börsenhändler Kerviel muss ins Gefängnis.
Abgerufen am 04. 03 2011 von http://www.zeit.de/wirtschaft/2010-10/kerviel-prozessstrafe
[02] Ponemon Institute LLC. (Juli 2010). First Annual Cost of Cyber Crime Study.
[03] IBM Deutschland GmbH. (1 2011). Business Analytics & Optimization Insider: Aus
Leidenschaft für Daten - Data-Governance-Initiative bei der Deutschen Bank AG.
Abgerufen am 3. 3 2011 von ibm.com/de/insider
[04] intac. (13. 04 2010). A comparison of dedicated servers-by company. Abgerufen am 22.
05 2011 von http://www.intac.net/a-comparison-of-dedicated-servers-bycompany_2010-04-13/
[05] ArcSight Inc. (2010). Customer Case Study - Commerzbank.
[06] Williams, A. (Januar 2007). The Future of SIEM – The market will begin to diverge.
[07] BKA und BITKOM. (6. September 2010). Pressemitteilung: Online-Kriminelle gehen immer
raffinierter vor. Abgerufen am 2. Juni 2011 von Bundeskriminalamt:
http://www.bka.de/pressemitteilungen/2010/pm100906.html
[08] Symantec Corporation. (5. April 2011). Symantec Sicherheitsbericht: Cyberkriminalität ist
deutscher Exportschlager. Abgerufen am 2. Juli 2011 von
http://www.webcitation.org/query?url=http%3A%2F%2Fwww.symantec.com%2Fde%2F
de%2Fabout%2Fnews%2Frelease%2Farticle.jsp%3Fprid%3D20110405_01&date=201104-11
[09] Frankfurter Allgemeine Zeitung GmbH. (12. Juni 2011). Ausmaß noch ungewiss: Hacker
greifen IWF an - Hintergründe - Wirtschaft - FAZ.NET. Abgerufen am 24. Juni 2011 von
http://www.faz.net/-01x5i9
[10] Frankfurter Allgemeine Zeitung GmbH. (3. Juni 2011). Sicherheitslücken: Hacker stehlen
abermals Sony-Daten - Netzwirtschaft - Wirtschaft - FAZ.NET. Abgerufen am 24. Juni
2011 von http://www.faz.net/-01wnvx
[11] BSI. (2009). Die Lage der IT-Sicherheit in Deutschland.
[12] Eckert, C. (2009). IT-Sicherheit: Konzepte - Verfahren - Protokolle. München: Oldenbourg
Verlag.
[13] The Computer Journal - A. BURNS, J. McDERMID AND J. DOBSON. (Juli 1991). On the
Meaning of Safety and Security. Abgerufen am 25. Juni 2011 von
http://comjnl.oxfordjournals.org/content/35/1/3.full.pdf+html
[14] Schneier, B. (1. Auflage 23. Januar 2004). Secrets and Lies: Digital Security in a Networked
World. Indiana: Wiley Publishing, Inc.
[15] Freiling, F. C. (25. Juni 2010). Safety versus Security - Gegenüberstellung und Einordnung.
Abgerufen am 25. Juni 2011 von http://pi1.informatik.unimannheim.de/filepool/presentations/siemens-vortrag-jul-2010.pdf
[16] Bundesamt für Sicherheit in der Informationstechnik. (2011). BSI: Glossar/Begriffe.
Abgerufen am 28. Juni 2011 von
https://www.bsi.bund.de/DE/Themen/InternetSicherheit/GlossarBegriffe/GlossarBegriff
e_node.html
[17] IDC Central Europe GmbH. (Juli 2010). IT Security in Deutschland 2010. Frankfurt a.M.
[18] FICO - Fair Isaac Corporation. (11. Januar 2011). New Bank survey reveals top fraud
threats and vulnerabilities. Abgerufen am 27. April 2011 von
http://bankinganalyticsblog.fico.com
[19] BSI. (November November 2009). IT-Grundschutz-Kataloge - 11. Ergänzungslieferung.
[20] Miller, D. R., Harris, S., Harper, A. A., Vandyke, S., & Blask, C. (1. Auflage 1. November
2010). Security Information and Event Management (SIEM) Implementation. McgrawHill.
[21] Hoppe, G., & Prieß, A. (2003). Sicherheit von Informationssystemen - Gefahren,
Maßnahmen und Managment im IT-Bereich. Herne/Berlin: Verlag Neue WirtschaftsBriefe GmbH & Co.
[22] ZEIT ONLINE. (14. April 2011). Netz-Angriff der Namenlosen - Unter dem Namen
Anonymous attackieren Internet-Aktivisten Firmen-Websites und Regierungen. Wer
steckt hinter dieser neuen Form des politischen Protests? Abgerufen am 1. Juli 2011 von
http://www.zeit.de/2011/16/Anonymous
[23] Cisco Networking Academy. (Oktober 2006). Network Security 1 and 2 Companion Guide.
Cisco Press.
[24] Chaos Computer Club. (2011). CCC | hackerethics. Abgerufen am 3. Juli 2011 von
http://www.ccc.de/de/hackerethics
[25] CSO magazine, U.S. Secret Service, Software Engineering Institute CERT Program at
Carnegie Mellon University and Deloitte. (31. Januar 2011). 2011 CYBERSECURITY
WATCH SURVEY. Abgerufen am 7. März 2011 von
www.deloitte.com/us/securityandprivacysolutions
[26] Süddeutsche Zeitung GmbH. (3. Februar 2010). Die erfolgreichste CD der Welt. Abgerufen
am 3. Juli 2011 von Die Steuerhinterzieher-CD ist die erfolgreichste CD der Welt:
http://sueddeutsche.dehttp://www.sueddeutsche.de/politik/steuerhinterziehung-die
[27] ISMG Corp. (27. Juni 2011). Bank Information Security Articles- $72M Bank Fraud Scheme
Busted. Abgerufen am 4. Juli 2011 von
http://www.bankinfosecurity.eu/articles.php?art_id=3790
[28] BSI. (2011). Trusted Computing im praktischen Einsatz. Abgerufen am 7. Juli 2011 von
https://www.bsi.bund.de/ContentBSI/Themen/Sichere_Plattformen/trustedcomputing/
TrustedPlatformModul/TCGimpraktEinsatz/praxis_kritik.html
[29] VZ Depotbank AG. (2011). Allgemeine Geschäftsbedingungen für den registrierten
Zugang zum VZ Finanzportal. Abgerufen am 6. Juli 2011 von
https://finanzportal.vermoegenszentrum.ch
[30] Larcom, B., Saitta, E., Eddington, M., & Smith, S. (2005). Trike v1 Methodology Document.
Abgerufen am 7. Juli 2011 von http://www.octotrike.org/
[31] Bryan Sullivan - Microsoft Security Development. (2011). Security Briefs - DREAD.
Abgerufen am 7. Juli 2011 von http://msdn.microsoft.com/de-de/site/ee336031
[32] Carnegie Mellon University. (2011). OCTAVE® Information Security Risk Evaluation.
Abgerufen am 7. Juli 2011 von http://www.cert.org/octave/
[33] NIST. (1994). National Institute of Standards and Technology - Federal Information
Processing Standards Publication 65. Abgerufen am 4. Juni 2011 von GUIDELINE FOR THE
ANALYSIS OF LOCAL AREA NETWORK SECURITY:
http://www.itl.nist.gov/fipspubs/fip65.htm
[34] BSI. (2011). BSI: Gefährdungen: Begriffserläuterung, Einführung. Abgerufen am 10. Juli
2011 von
https://www.bsi.bund.de/DE/Themen/InternetSicherheit/Gefaehrdungen/gefaehrdunge
n_node.html
[35] Anderson, R. J. (2. Auflage 11. April 2008). Security Engineering: A Guide to Building
Dependable Distributed Systems. Indiana: Wiley Publishing, Inc.
[36] Gerber, S. (2011). Architekturen betrieblicher Anwendungssysteme. Potsdam: Universität
Potsdam.
[37] Krumnow, J., Gramlich, L., Lange, T. A., Dewner, T. M., & (Hrsg.). (2002). Gabler Bank
Lexikon. Wiesbaden: Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH.
[38] Oracle - Open World Conference. (September 2008). Raiffeisen International Bank: Using
Oracle Consulting to Achieve Rapid Migration of ETL Processes to Better Support Data
Warehousing. San Fransisco, CA: Oracle.
[39] Bakker, J. (23. 02 2011). CSO SECURITY AND RISK: DDoS attack forces Dutch bank offline.
Abgerufen am 07. 03 2011 von www.csoonline.com
[40] Behar, R. (10. 10 2008). World Bank Under Cyber Siege in 'Unprecedented Crisis'.
Abgerufen am 20. 03 2011 von http://www.FOXNews.com
[41] Gartner. (12. Mai 2011). Magic Quadrant for Security Information and Event
Management.
[42] intiGrow. (2011). Security Information and Event Management. Abgerufen am 4. Juni
2011 von http://www.intigrow.com/security-information-management.html
[43] Nicolett, M. (2010). The Gartner Security Information and Event Mamagement Magic
Quadrant 2010 - Dealing with Targeted Attacks. Abgerufen am 7. Juni 2011 von
http://www.gartner.com/it/content/1380400/1380414/june_30_security_information_
mnicolett.pdf
[44] Tier-3. (2011). Tier-3 - Huntsman Architecture. Abgerufen am 3. Juni 2011 von
http://www.tier-3.com/products-architecture.php
[45] ArcSight, Inc. (2010). ArcSight SIEM Product Platform. Abgerufen am 1. Juni 2011 von
http://www.arcsight.com/collateral/ArcSight_SIEM_Product_Platform.pdf
[46] Q1 Labs. (2011). QRadar SIEM 7 Data Sheet. Abgerufen am 02. Juni 2011 von
http://q1labs.com/content/resource-download.aspx?id=f2010cb3-01da-49fc-96ee35bb3dcdbe80.pdf
[47] AlienVault. (2011). AlienVault Unified SIEM - Unified Security Management. Abgerufen
am 2. Juni 2011 von http://alienvault.com/docs/AlienVault_Solution_Datasheet.pdf
[48] Intersect Alliance Pty Ltd. (2008). The Snare Toolset - A White Paper. Abgerufen am 8.
Juni 2011 von
http://www.intersectalliance.com/resources/Documentation/Snare_Toolset_White_Pap
er-2.6.pdf
[49] AlienVault LC. (2011). Alienvault SIEM Users Manual 1.0. Campbell, CA, USA.
[50] ArcSight, Inc. (2009). ArcSight- Logger 4 - White Paper. Cupertino, CA, USA.
[51] IETF Network Working Group. (Dezember 2002). RFC 3414- User-based Security Model
(USM) for version 3 of the Simple Network Management Protocol (SNMPv3). Abgerufen
am 11. Juni 2011 von http://tools.ietf.org/html/rfc3414
[52] Infinigate Deutschland GmbH. (2011). Infinigate. Abgerufen am 11. Juni 2011 von
Produktbeschreibung Novell Sentinel Log Manager:
http://www.infinigate.de/produkte/novell/novell_sentinel_log_manager.html
[53] SANS. (Februar 2009). Benchmarking Security Information Event Management (SIEM).
Abgerufen am 10. 06 2011 von
http://www.sans.org/reading_room/analysts_program/eventMgt_Feb09.pdf
[54] SANS. (April 2011). Seventh Annual Log Management Survey Report 2011.
[55] NitroSecurity, Inc. (2011). Supported Devices. Abgerufen am 11. Juni 2011 von
http://www.nitrosecurity.com/products/supported-devices/
[56] IBM. (19. Mai 2011). REDUNDANT EVENTS BIP2488E, BIP2230E AND BIP2232E IN
SYSLOG. Abgerufen am 13. Juni 2011 von https://www304.ibm.com/support/docview.wss?rs=1037&uid=swg1PK96688&context=SS433P&cs=U
TF-8&wv=1&lang=en&loc=en_US
[57] ArcSight, Inc. (2011). Product Brief: ArcSight Express. Abgerufen am 13. Juni 2011 von
http://www.arcsight.com/collateral/briefs/ArcSight_ProductBrief_Express.pdf
[58] Bundesamt für Sicherheit in der Informationstechnik. (2011). BSI: BSI-Leitfaden zur
Einführung von Intrusion-Detection-Systemen. Abgerufen am 18. Juni 2011 von
https://www.bsi.bund.de/ContentBSI/Publikationen/Studien/ids02/gr1_htm.html
[59] EPTS -Event Processing Technical Society. (Juli 2008). Event Processing Glossary - Version
1.1. Abgerufen am 16. Juni 2011 von http://www.epts.com/component/option,com_docman/task,doc_download/gid,66/Itemid,84/
[60] The 1st International Conference on Information Science and Engineering. (2009). Event
Driving Based Alarm Correlation Approach by Using Petri Net. IEEE.
[61] SenSage Inc. (2011). SenSage - Datasheet SIEM Solution for Cisco MARS™. Abgerufen am
14. Juni 2011 von
http://www.sensage.com/collaterals/documents/SenSage_Datasheet_CiscoMARS.pdf
[62] Cai, Z. (2010). Advances in Computation and Intelligence: 4th International Symposium on
Intelligence Computation and Applications, ISICA 2009, Huangshi, China, ... Computer
Science / Theoretical Computer Sci). Berlin / Heidelberg: Springer Verlag.
[63] Jahankhani, H., Hessami, A. G., & Feng, H. (2010). Global Security, Safety, and
Sustainability: 5th International Conference, ICGS3 2009, London, UK, September 1-2,
2009, Proceedings (Communications in Computer and Information Science). Berlin /
Heidelberg: Springer Verlag.
[64] Symantec Corporation. (2011). Symantec Enterprise Security Manager Security Updates |
Symantec. Abgerufen am 19. Juni 2011 von
http://www.symantec.com/business/security_response/securityupdates/list.jsp
[65] SecurityFocus. (2011). SecurityFocus Vulnerability Database updates. Abgerufen am 19.
Juni 2011 von http://www.securityfocus.com/
[66] BroadWeb Co. (2011). BroadWeb Application Database. Abgerufen am 19. Juni 2011 von
http://www.broadweb.com/product_layer7_app.htm
[67] BroadWeb Co. (2011). BroadWeb Security Signature Database. Abgerufen am 19. Juni
2011 von http://www.broadweb.com/product_layer7_ssd.htm
[68] Symantec Corporation. (2011). Attack Signatures List. Abgerufen am 19. Juni 2011 von
http://www.symantec.com/business/security_response/attacksignatures/detail.jsp?asid
=21239
[69] eIQnetworks Inc. (2010). Extending Cisco Security MARS, Forensics and Reporting Solution Data Sheet. Abgerufen am 21. Juni 2011 von
http://www.eiqnetworks.com/resources/eIQ_CiscoMARS.pdf
[70] OMG. (Mai 2010). OMG Unified Modeling LanguageTM (OMG UML). Abgerufen am 25.
Juli 2011 von http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/
[71] Sindre, G., & Opdahl, A. L. (2004). Eliciting security requirements with misuse cases.
London: Springer-Verlag London Limited.
[72] Sawyer, P., Paech, B., & Heymans, P. (2007). Requirements Engineering: Foundation for
Software Quality: 13th International Working Conference, REFSQ 2007. Trondheim,
Norway: Springer Berlin Heidelberg.
[73] Schneier, B. (8. Oktober 1999). Attack Trees. New Orleans, LA.
[74] The CA / Browser Forum. (Juni 2007). GUIDELINES FOR THE ISSUANCE AND
MANAGEMENT OF EXTENDED VALIDATION CERTIFICATES. Abgerufen am 26. Juli 2011
von Minimum Cryptographic Algorithm and Key Sizes:
http://cabforum.org/EV_Certificate_Guidelines.pdf
[75] ZKA. (2004). FinTS-Spezifikation V4.0. Abgerufen am 27. Juli 2011 von http://www.zkaonline.de/uploads/media/FinTS-Spezifikationen_final_01.pdf
[76] ZKA. (2011). ZKA - DFÜ Abkommen - DFÜ-Verfahren FTAM. Abgerufen am 27. Juli 2011
von http://www.zka-online.de/zka/zahlungsverkehr/electronic-banking/dfue-verfahrenftam.html
[77] ZKA. (2011). ZKA - DFÜ Abkommen - DFÜ-Verfahren EBICS. Abgerufen am 27. Juli 2011
von http://www.zka-online.de/zka/zahlungsverkehr/electronic-banking/dfue-verfahrenebics.html
[78] Haubner, K. (2004). FinTS V4.0 Kompendum. Abgerufen am 27. Juli 2011 von Financial
Transaction Services: http://www.hbcizka.de/dokumente/diverse/fints40_kompendium.pdf
[79] Davies, J. (2011). Implementing SSL / TLS Using Cryptography and PKI.
Indianapolis,IN,USA: John Wiley & Sons.
[80] FBI - Federal Bureau of Investigation. (2010). Cyber Banking Fraud. Abgerufen am 7.
August 2011 von Global Partnerships Lead to Major Arrests:
http://www.fbi.gov/news/stories/2010/october/cyber-banking-fraud
[81] Ardagna, C., & Zhou, J. (2011). Information Security Theory and Practice. Heidelberg:
Springer Verlag .
[82] Raiffeisenbank-Kastellauen. (2011). Informationen zum 20-TAN-Trojaner. Abgerufen am
25. Mai 2011 von http://www.raiffeisenbankkastellaun.de/privatkunden/konto___karten/banking/trojanerwarnung.html
[83] OWASP. (23. April 2009). Man-in-the-browser attack. Abgerufen am 7. August 2011 von
https://www.owasp.org/index.php/Man-in-the-browser_attack
[84] Secunia . (8. Juni 2010). Danske Bank e-Sec Control Module Error Logging Buffer Overflow
- Advisories - Community. Abgerufen am 7. August 2011 von
http://secunia.com/advisories/29635
[85] Western Union. (2011). Geld von Vertriebsstandort senden. Abgerufen am 21. August
2011 von
http://www.westernunion.de/WUCOMWEB/staticMid.do?method=load&pagename=ho
wToSendAgent
[86] WebMoney. (2011). Cashing out WMZ and WME to bank accounts. Abgerufen am 21.
August 2011 von http://blog.wmtransfer.com/en/blog/webmoney-news-cashing-outwmz-and-wme-to-banks
[87] WebMoney. (2011). Nearby cities where you can top up WM-purse or withdraw funds
from the System. Abgerufen am 21. August 2011 von
http://geo.webmoney.ru/wmobjects/mycity.aspx?city=85310&lang=en
[88] Libeau, F. (12. Juli 2011). Principal Sales Engineer - ArcSight Germany. (IT Securiy Day,
Interviewer)
[89] Hild, K. (12. Juli 2011). Principal Technology Specialist - Identity & Security Managment Novell Deutschland GmbH. (IT Security Day, Interviewer)
VIII. Eidesstattliche Erklärung
Peter von Oppenkowski (Matrikelnummer: 872538)
Hiermit erkläre ich, Peter von Oppenkowski, dass ich diese Arbeit selbständig abgefasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch nicht
veröffentlicht.
Overath, __________________________________________________
Abgabedatum
Unterschrift

D I P L O M A R B E I T - Fraunhofer

Transcrição

Documentos relacionados

5. Eisbärenturnier 2016 - Strelitzer Feldbogensportgilde eV

Flyer Schmerzambulanz

Teilnahmebedingungen Internet Banking

212003 - Antrag auf steuerliche Unbedenklichkeitsbescheinigung

REZEPT-/ ÜBERWEISUNGSANFORDERUNG

Ein Angebot des CJD Berchtesgaden

mini med junior - MINI MED Upload

Schulungsunterlage Einsatzinformationssystem ÖBRD Modul

Eine positive Herausforderung - neue

bergisCHer gesCHiCHts- VereiN abteiluNg soliNgeN

Allgemeine Geschäftsbedingungen