Springer Berlin Heidelberg New York Hongkong London Mailand Paris Tokio
Die Reihe Xpert.press des Springer-Verlags vermittelt Professionals in den Bereichen Betriebs- und Informationssysteme, Software Engineering und Programmiersprachen aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.
Markus Schumacher Utz Rödig Marie-Luise Moschgath
Hacker Contest Sicherheitsprobleme, Lösungen, Beispiele Mit 62 Abbildungen
123
Markus Schumacher Technische Universität Darmstadt Fachbereich Informatik IT Transfer Office (ITO) http://www.ito.tu-darmstadt.de/ Utz Rödig Technische Universität Darmstadt • FB 18 Fachbereich Elektrotechnik und Informationstechnik Multimedia Kommunications (KOM) http://www.kom.e-technik.tu-darmstadt.de/ Marie-Luise Moschgath Eidgenössische Technische Hochschule Zürich Department of Computer Science Distributed Systems Group http://www.inf.ethz.ch/
ISSN 1439-5428 ISBN 3-540-41164-X Springer-Verlag Berlin Heidelberg New York Die Deutsche Bibliothek – CIP-Einheitsaufnahme Schumacher, Markus: Hacker-Contest: Sicherheitsprobleme, Lösungen, Beispiele / Markus Schumacher; Utz Roedig; Marie-Lusie Moschgath. – Berlin; Heidelberg: Springer 2003 (Xpert-Press) ISBN 3-540-41164-X
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.
Springer-Verlag Berlin Heidelberg New York ein Unternehmen der BertelsmannSpringer Science+Business Media GmbH http://www.springer.de © Springer-Verlag Berlin Heidelberg 2003 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka, Heidelberg Satz: Datenbearbeitung durch G&U e.Publishing Services GmbH, Flensburg Gedruckt auf säurefreiem Papier SPIN: 10785482 33/3142 GF 5 4 3 2 1 0
Inhaltsverzeichnis
Einleitung 1.1 1.2 1.3
1
Motivation ................................................................................................... 1 Zielgruppen ................................................................................................. 2 Zum Aufbau des Buches ............................................................................. 2
Teil I Grundlagen 2.1 2.2 2.3
7
Begriffe und Konzepte der IT-Sicherheit .................................................... 7 Der Hacker Contest ................................................................................... 23 Security Patterns ........................................................................................ 39
Hacker und Cracker 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8
71
Hacker und Cracker ................................................................................... 71 Geschichte der Hacker und Cracker .......................................................... 73 Die Hacker-Ethik ...................................................................................... 75 Berühmte Hacker und Cracker .................................................................. 77 Motivation von Hackern und Crackern ..................................................... 95 Ablauf von Angriffen ................................................................................ 97 Relevante Informationsquellen ............................................................... 101 Grundsätzliche Bedrohungen .................................................................. 105
Computerkriminalität 4.1 4.2
113
Was ist Computerkriminalität? ............................................................... 113 Statistiken ................................................................................................ 115
Inhaltsverzeichnis
V
4.3 4.4 4.5 4.6
Deliktformen ........................................................................................... Deutsche Rechtsprechung ....................................................................... Europäische und internationale Rechtsprechung .................................... Sicherheitsmaßnahmen zum Schutz kritischer Infrastrukturen ..............
134 136 145 153
Teil II Basisfunktionen und Sicherheitsprinzipien 5.1 5.2 5.3
163
Einleitung ................................................................................................ 163 Basisfunktionen ...................................................................................... 163 Sicherheitsprinzipien .............................................................................. 177
Systeme
193
6.1 6.2 6.3 6.4 6.5 6.6
193 193 196 205 215 221
Einleitung ................................................................................................ Physikalischer Schutz ............................................................................. Authentisierung ....................................................................................... Schutz der Dateien .................................................................................. Installation und Konfiguration ................................................................ Erkennen von Angriffen .........................................................................
Netzwerke
229
7.1 7.2 7.3 7.4
229 229 235 241
Einleitung ................................................................................................ Sicherheit im Local Area Network ......................................................... Sicherheit im Wide Area Network .......................................................... Sicherheit durch Firewalls ......................................................................
Teil III Arbeiten mit Security Patterns
255
8.1 8.2 8.3 8.4
Einleitung ................................................................................................ Dokumentation von Security Patterns .................................................... Anwendungsbeispiel: Sicherheit im LAN .............................................. Anwendungsbeispiel: Sicherheit im WAN .............................................
255 255 262 266
VI
Inhaltsverzeichnis
Ausblick 9.1 9.2 9.3
275
Zusammenfassung ................................................................................... 275 Die Zukunft des Hacker Contest ............................................................. 276 Die Zukunft von Security Patterns .......................................................... 277
Danksagung
281
Literaturverzeichnis
283
Stichwortverzeichnis
293
Abkürzungen
299
Inhaltsverzeichnis VII
Abbildungsverzeichnis
Abb. 2-1 Abb. 2-2 Abb. 2-3 Abb. 2-4 Abb. 2-5 Abb. 2-6 Abb. 2-7 Abb. 2-8 Abb. 2-9 Abb. 2-10 Abb. 2-11 Abb. 3-1 Abb. 3-2 Abb. 3-3 Abb. 3-4 Abb. 3-5 Abb. 3-6 Abb. 4-1 Abb. 4-2 Abb. 4-3 Abb. 4-4 Abb. 4-5 Abb. 4-6 Abb. 4-7 Abb. 4-8 Abb. 4-9 Abb. 4-10 Abb. 4-11 Abb. 4-12 Abb. 4-13 Abb. 4-14 Abb. 4-15
a
Zusammenhang zwischen Angriff und Maßnahme ................ 21 Charakteristik des Begriffs „Angriff“ ..................................... 22 Charakteristik des Begriffs „Maßnahme“ ............................... 22 Angriffspunkte im TCP/IP-Schichtenmodell ......................... 29 Netzwerktopologie des Hacker Contest .................................. 31 System Security Engineering .................................................. 40 Schematische Darstellung eines Security Patterns ................. 54 Darstellung der Kantensemantik von Security Patterns ......... 58 Security Patterns auf Anwendungsebene ................................ 62 Security Patterns für kryptografische Software ...................... 63 Kategorisierung nach Schichten ............................................. 66 Erkundung mit Suchmaschinen .............................................. 98 Ergebnis einer Abtastung mit einem Netzwerk-Scanner ........ 99 Resultat eines Angriffs: Offenlegung ................................... 107 Resultat eines Angriffs: Täuschung ...................................... 108 Resultat eines Angriffs: Unterbrechung ............................... 110 Resultat eines Angriffs: Widerrechtliche Aneignung ........... 111 CERT/CC: gemeldete Vorfälle ............................................. 116 Fälle von Computerkriminalität ............................................ 118 Aufklärungsquote Computerkriminalität .............................. 118 Übersicht Computerkriminalität ........................................... 119 Karten und Computerbetrug ................................................. 119 Einfluss Kartenbetrug und Software-Piraterie ...................... 120 Weitere Deliktformen ........................................................... 120 Tätergruppen ......................................................................... 122 CSI/FBI-Klassifikation der Angreifer .................................. 123 PricewaterhouseCoopers-Klassifikation der Angreifer ........ 124 Relative Altersstruktur der Täter .......................................... 125 Absolute Altersstruktur der Täter ......................................... 125 Geschlechterstruktur der Täter .............................................. 126 Geschlechterstruktur: deutsche und ausländische Täter ....... 126 Bezifferte Schäden nach der PKS ......................................... 128
Abbildungsverzeichnis
IX
Abb. 4-16 Abb. 4-17 Abb. 4-18 Abb. 4-19 Abb. 4-20 Abb. 5-1 Abb. 5-2 Abb. 5-3 Abb. 6-1 Abb. 6-2 Abb. 6-3 Abb. 6-4 Abb. 6-5 Abb. 6-6 Abb. 7-1 Abb. 7-2 Abb. 7-3 Abb. 7-4 Abb. 7-5 Abb. 7-6 Abb. 7-7 Abb. 7-8 Abb. 7-9 Abb. 7-10 Abb. 7-11 Abb. 7-12 Abb. 7-13 Abb. 8-1 Abb. 8-2 Abb. 8-3
X
Schäden durch Software-Piraterie ........................................ 129 Computer Crime and Security Survey – Teil 1 .................... 131 Computer Crime and Security Survey – Teil 2 .................... 131 Prozentuale Software- und Produktpiraterie-Rate ................ 132 Schäden durch Software- und Produktpiraterie .................... 133 Verschlüsselung und Entschlüsselung .................................. 168 Basisfunktionen auf der Metaebene ...................................... 177 Modell einer Passierstelle: Referenzmonitor ........................ 183 Benutzerauthentisierung ....................................................... 205 Berechtigungen für Dateien und Verzeichnisse ................... 207 Schutz von Dateien ............................................................... 214 Installation und Konfiguration .............................................. 221 Auszug aus einer Log-Datei ................................................. 225 Erkennen von Angriffen ....................................................... 226 Kommunikation über einen Switch ...................................... 230 Sicherheit im Local Area Network ....................................... 234 Anschluss privater Netze an das Internet .............................. 236 Unsichere Kommunikation über das Internet ....................... 236 Angriff einer Kommunikation über das Internet .................. 238 Virtuelles privates Netz ........................................................ 240 Security-Pattern-System virtuelles privates Netz ................. 241 Netzübergang zwischen einem privaten Netz und dem Internet ................................................................... 242 Paketfilter .............................................................................. 245 Stateful-Filter ........................................................................ 247 Proxy ..................................................................................... 249 NAT ...................................................................................... 250 Firewall Security Patterns ..................................................... 252 Sequenzen von Patterns ........................................................ 262 Modellierung eines Switch-Pattern-Systems ........................ 264 Implementierung des VPN-Pattern-Systems ........................ 271
Abbildungsverzeichnis
Tabellenverzeichnis
b
Abb. 1-0 Tabelle 1-0
Tab. 2-1 Tab. 2-2 Tab. 2-3 Tab. 2-4 Tab. 3-1 Tab. 3-2 Tab. 8-1
Einordnung von Verletzlichkeiten ..............................................16 Quelltextzeilen des Linux Kernels ohne Subsysteme.................37 Stärken der Methoden und Werkzeuge.......................................48 Berücksichtigung des Faktors Mensch .......................................48 Qualitative Einordnung von Informationsquellen ....................105 Gegenüberstellung von Bedrohungen und Schutzzielen ..........112 Security Patterns und Common Criteria Elemente ...................259
Tabellenverzeichnis
XI
Einleitung
1
Abb. 1-0 Tabelle 1-0 „Complexity is the worst enemy of security.“ Bruce Schneier
1.1 Motivation Wird Sicherheit in der Informationstechnik (IT) heute als Qualitätsmerkmal betrachtet, so fällt auf, dass wir oftmals weit von den Qualitätsstandards entfernt sind, wie sie in anderen Branchen als selbstverständlich betrachtet werden. Bruce Schneiers Zitat nennt einen der Hauptgründe für diesen Zustand: Die IT-Systeme und Anwendungen sind heute so komplex geworden, dass es kaum machbar ist, alle möglichen Angriffswege vorherzusehen und entsprechende Sicherheitsmaßnahmen zu treffen. Darüber hinaus sind, wie wir später zeigen werden, heutige Werkzeuge und Methoden zur Etablierung von Sicherheit zeitaufwändig und oft teuer. Es fehlt auch eine hinreichende Kompatibilität bzw. Integration der verschiedenen Vorgehensweisen. Diese Erkenntnisse decken sich auch mit den Erfahrungen, die wir seit 1999 mit der Durchführung des „Hacker Contest“, nach dem dieses Buch benannt ist, gemacht haben. Die Philosophie dieser Veranstaltung ist es, Werkzeuge und Methoden eines Angreifers kennen zu lernen. Um ein IT-System verteidigen zu können, muss der Sicherheitsverantwortliche in der Lage sein, das IT-System und seine Umgebung aus der Sicht eines Angreifers zu sehen und verstehen. Die Teilnehmer haben sich daher einerseits kritisch mit prinzipiellen Angriffskonzepten auseinander gesetzt; andererseits wurden auch entsprechende praktische Erfahrungen mit Schutzmaßnahmen für Anwendungen, Systeme und Netzwerken gesammelt. Dieses Buch baut auf Erfahrungen und Erkenntnissen dieser Lehrveranstaltung auf. Neben einer Einführung in das Thema Sicherheit werden paarweise ausgewählte Sicherheitsprobleme und Lösungen betrachtet. Dabei wird auch berücksichtigt, welche Kompromisse eingegangen werden müssen oder ob eine Lösung zusätzliche Probleme schafft. Das hier zugrunde gelegte Konzept basiert auf (Design-)Patterns, die als bewährte Lösungen für bekannte Probleme verstanden werden und sich beim Entwurf von Softwaresystemen als Methode etabliert haben. Wir übertragen die
M. Schumacher et al., Hacker Contest © Springer-Verlag Berlin Heidelberg 2003
1.1. Motivation
1
wesentlichen Elemente solcher „Musterlösungen“ auf Sicherheitsprobleme und beschreiben Sicherheitsprobleme und -lösungen sowie deren Abhängigkeiten untereinander in Form von „Security Patterns“. Dieser Ansatz reflektiert das Konzept des Hacker Contest, da sowohl Angriffe als auch die entsprechenden Sicherheitsmaßnahmen berücksichtigt werden. Wie wir später noch zeigen werden, stellen Security Patterns eine Methode dar, um mit den oben erwähnten Problemen besser umgehen zu können. Es gibt eine große Menge von Büchern zum Thema Sicherheit auf dem Markt. Diese Bücher behandeln typischerweise eine Reihe von etablierten Sicherheitsprotokollen, -mechanismen und -technologien. Ein anderer Ansatz sind Werke, die sich mit Angriffstechniken von „Hackern“ auseinander setzen. Dieses ist sehr wichtig, um zu verstehen, woher die Gefahren kommen. Weiterhin gibt es weniger technische Beiträge, die den Menschen in das Zentrum der Betrachtungen stellen. Mit diesem Buch versuchen wir, diese drei Ansätze zu kombinieren, d.h., sowohl Sicherheitsmaßnahmen gegen bestimmte Angriffstechniken vorzustellen als auch den Faktor Mensch dabei zu berücksichtigen. IT-Sicherheit und insbesondere der Entwurf und Betrieb sicherer Systeme ist ein sehr umfangreiches Gebiet. Mit diesem Buch verfolgen wir allerdings keine vollständige Abhandlung des Themenbereichs. So finden beispielsweise kryptografische Verfahren oder Zugriffskontrolle keine Berücksichtigung. Das primäre Ziel dieses Buchs ist es vielmehr, einen neuen konzeptionellen Ansatz zu vermitteln, der Menschen dabei hilft, Sicherheitsprobleme strukturiert zu lösen.
1.2 Zielgruppen Dieses Buch kann unter zwei Gesichtspunkten betrachtet werden. Für Einsteiger in das Thema Sicherheit ist es als einführender Text zu verstehen, der Sicherheit aus dem Blickwinkel von Angreifern und Verteidigern sieht. Wichtige Konzepte und Begriffe werden nach und nach eingeführt und ausgewählte Sicherheitsprobleme sowie entsprechende bewährte Lösungen vorgestellt. Für Experten in der Wirtschaft sowie Wissenschaftler in Forschung und Lehre dürften sowohl das Konzept des Hacker Contest („Kenne Deine Feinde ...“) als auch der Ansatz der Security Patterns interessant sein.
1.3 Zum Aufbau des Buches Dieses Buch besteht aus drei aufeinander aufbauenden Teilen. Teil I beinhaltet eine Darstellung von Grundlagen im Bereich Sicherheit und eine thematische Einführung in die Welt von Hackern und Crackern mit entsprechenden rechtlichen Hintergründen. Teil II ist ein Katalog von ausgewählten Security Patterns, also Sicherheitsproblemen und Lösungen in strukturierter Form. Der Fokus liegt dabei auf der
2
1 Einleitung
Sicherheit von IT-Systemen und -Netzwerken. In Teil III wird diskutiert, wie mit diesem Katalog gearbeitet und wie er weiterentwickelt werden kann. Nachfolgend wird der Inhalt im Detail vorgestellt. Teil I – Kapitel 2 Zu Beginn werden die grundlegenden Begriffe und Konzepte der IT-Sicherheit, wie sie in diesem Buch verwendet werden, vorgestellt. Dabei wird auch beschrieben, wie diese Begriffe und Konzepte zueinander in Bezug stehen. Anschließend gehen wir ausführlicher auf das Experiment Hacker Contest ein. Wir zeigen außerdem, warum die Bedrohung durch Angriffe aus dem Internet ernst genommen werden muss. Daraufhin präsentieren wir die Konzeption und die Durchführung des Hacker Contest und zeigen Erkenntnisse, die wir aus dieser Arbeit gezogen haben. Besonders wichtig ist die Feststellung, dass IT-Sicherheit maßgeblich vom Faktor Mensch beeinflusst wird. Daher beschreiben wir einige Merkmale von komplexen Situationen, in denen Menschen unweigerlich Fehler machen, so dass Sicherheitslücken entstehen können. Den Abschluss der Einführung bildet die Beschreibung des konzeptionellen Ansatzes der Security Patterns, die im weiteren Verlauf des Buchs zur Beschreibung von Sicherheitsproblemen und -lösungen verwendet werden. – Kapitel 3 Wir stellen Hintergründe zum Thema „Hacker und Cracker“ vor. Die Geschichte der Hacker und Cracker wird skizziert, und die Kerngedanken der so genannten Hackerethik werden vorgestellt. Wir geben einige Beispiele für berühmte Hacker und Cracker. Schließlich werden noch deren unterschiedliche Motive dargestellt – wichtig um zu verstehen, woher und warum Gefahren drohen. Es wird gezeigt, wie ein Angriff grundsätzlich abläuft und welche Angriffstechniken dabei eingesetzt werden können. Wir zeigen, welche allgemeinen Bedrohungen durch einen Angreifer hervorgerufen werden können. Schließlich stellen wir einige charakteristische Informationsquellen dar, die sowohl zur Vorbereitung von Angriffen als auch zur Verteidigung herangezogen werden können. – Kapitel 4 Die Durchführung eines Angriffs ist kein harmloses Delikt. Daher betrachten wir auch die rechtlichen Aspekte der Computerkriminalität. Anhand von verschiedenen Statistiken zu Zwischenfällen, Computerkriminalität, Täterprofilen und Schäden werden die Ausmaße von Computerkriminalität verdeutlicht. Wir erläutern, welche Deliktformen unterschieden werden und wie die deutsche Rechtsprechung diese ahndet. Ergänzend werden europäische und internationale Bestrebungen zur Vereinheitlichung der Gesetzgebung bei Computerkriminalität und zur Sicherung der kritischen Infrastruktur beschrieben.
1.3. Zum Aufbau des Buches
3
Teil II – Kapitel 5 Am Anfang des Security Pattern-Katalogs werden grundlegende Sicherheitsfunktionen, die in diesem Buch verwendet werden, vorgestellt. Dazu gehören beispielsweise Identifikation und Authentisierung und Identitätsbasierte Zugriffskontrolle. Außerdem stellen wir grundsätzliche Sicherheitsprinzipien vor, die beim Entwurf von IT-Systemen und Netzwerken berücksichtigt werden sollten. – Kapitel 6 Eine wichtige Rolle spielt auch die Ebene der IT-Systeme, insbesondere der Betriebssysteme. Wir betrachten besonders die Authentisierung, den Schutz der Dateien, die Installation und Konfiguration sowie Konzepte zum Erkennen von Angriffen. – Kapitel 7 Schließlich werden verschiedene Aspekte der Netzwerksicherheit beschrieben. Dazu gehört die Sicherheit im Local Area Network, Sicherheit im Wide Area Network und das grundlegende Konzept hinsichtlich der Sicherheit durch Firewalls. Teil III – Kapitel 8 Außerdem thematisieren wir, wie neue Security Patterns gefunden (nicht etwa erfunden) und wie diese in einen bestehenden Katalog von Security Patterns integriert werden können. Anhand von Beispielen zeigen wir, wie mit Security Patterns gearbeitet werden kann. Dazu gehört auch, wie Patterns real implementiert werden und was passiert, wenn eine solche Implementierung unsicher wird. In diesem Fall treten Inkonsistenzen innerhalb eines Patterns bzw. dem Pattern-Katalog auf, die sich im Allgemeinen auch auf andere Patterns negativ auswirken. – Kapitel 9 Im letzten Kapitel werden zunächst die wichtigsten Ergebnisse dieses Buchs zusammengefasst. Es wird insbesondere dargestellt, warum sich der Pattern-Ansatz besonders gut dazu eignet, Sicherheitsprobleme u.a. strukturiert darstellen zu können. Dann verweisen wir auf laufende und geplante Forschungsarbeiten, die das Ziel haben, Security Patterns noch besser in den Prozess des sicheren Systementwurfs integrieren zu können.
4
1 Einleitung
Teil I0
.
5
Grundlagen
2
Abb. 1-0 Ziel dieses Kapitels ist die Einführung in die Grundlagen, auf denen dieses Buch basiert. Da viele Begriffe und Konzepte der IT-Sicherheit in der Literatur nicht eindeutig oder gar nicht festgelegt sind, beginnen wir dieses Kapitel mit der Festlegung der Terminologie, die in diesem Buch verwendet wird. Neben den Definitionen zeigen wir auch die Zusammenhänge zwischen den Begriffen und Konzepten wie beispielsweise Bedrohungen, Angriffe und Verletzlichkeiten. Im nächsten Abschnitt erläutern wir zunächst, warum wir das Experiment Hacker Contest durchgeführt haben. Wir zeigen anhand einiger Beispiele, dass es einerseits eine Bedrohung durch Angriffe aus dem Internet gibt, und andererseits wird diese Bedrohung auch auf unterschiedlichen Ebenen als ernst zu nehmende Gefahr wahrgenommen. Ein Ziel des Hacker Contest ist es daher, im Detail zu verstehen, wie Angreifer vorgehen. Daraus kann abgeleitet werden, welche Maßnahmen getroffen werden müssen. Die Analyse des Hacker Contest wird u.a. zeigen, dass der Mensch im Zentrum der Betrachtung stehen muss, wenn das beschriebene Problem der ITSicherheit gelöst werden soll. Schließlich beschreiben wir den Ansatz der Security Patterns, die bewährte Lösungen für wiederkehrende Sicherheitsprobleme in strukturierter Form darstellen. Wir werden sie später dazu verwenden, um ausgewählte Sicherheitsprobleme und die entsprechenden Lösungen vorzustellen. Wir betrachten zuerst Werkzeuge und Vorgehensweisen, die typischerweise dazu eingesetzt werden, um sichere IT-Anwendungen, Systeme und Netzwerke entwickeln und betreiben zu können. Mit den Erkenntnissen, die wir aus dem Hacker Contest gewonnen haben, zeigen wir, dass es eine Lücke zwischen den eher theoretischen Sicherheitsansätzen und dem praktischen Tagesgeschäft gibt. Security Patterns stellen einen Weg dar, den Menschen beim Schutz gegen die Bedrohung durch Angriffe systematisch und pragmatisch zu unterstützen und somit einen Teil dieser Lücke zu schließen.
2.1 Begriffe und Konzepte der IT-Sicherheit Im Folgenden werden die aus dem Bereich IT-Sicherheit verwendeten Begriffe definiert, die innerhalb dieser Arbeit verwendet werden. Eine Beschreibung dieser Begriffe ist notwendig, da in der Literatur unterschiedliche Definitionen existieren.
2.1. Begriffe und Konzepte der IT-Sicherheit M. Schumacher et al., Hacker Contest © Springer-Verlag Berlin Heidelberg 2003
7
2.1.1 Sicherheit Der Begriff Sicherheit wird in den unterschiedlichsten Bereichen mehr oder weniger überlegt verwendet. Insbesondere im Bereich der IT-Sicherheit ist es wichtig zu verstehen, was genau eigentlich Sicherheit bedeutet (eine umfassende Betrachtung des Begriffs Sicherheit ist in [86] zu finden). Das lateinische Wort securus bedeutet „sorglos“ oder „unbekümmert“ zu sein und wurde ursprünglich in der Rechtssprache als „frei von Schuld, Pflichten und Strafe sein“ verwendet. Erst später kristallisierte sich die Bedeutung „Schutz vor Schaden, Verlust, Gefahr“ heraus. Eine allgemeine Definition des Begriffs Sicherheit kann beispielsweise in einem Lexikon nachgeschlagen werden [77]: Sicherheit, Zustand des Unbedrohtseins, der sich objektiv im Vorhandensein von Schutz[einrichtungen] bzw. im Fehlen von Gefahr[enquellen] darstellt und subjektiv als Gewissheit von Individuen oder sozialen Gebilden über die Zuverlässigkeit von Sicherheits- und Schutzeinrichtungen empfunden wird. Def. 1-1 Enzyklopädische Definition von Sicherheit
Diese Definition kann auf die IT-Welt übertragen werden. Tatsächlich sind überall Einrichtungen, die uns Schutz vor IT-spezifischen Gefahren bieten sollen, zu finden. Ein Passwort hilft dabei, berechtigte Benutzer zu identifizieren und authentifizieren, Verschlüsselung schützt uns gegen das Ausspähen von Informationen, Zugriffskontrollverfahren verhindern den unbefugten Zugriff auf Ressourcen. Dabei zeigt sich allerdings auch, dass Sicherheit grundsätzlich sehr individuell empfunden wird. Schutzeinrichtungen, die für den einen sehr wichtig sind, kommen einem anderen eher irrelevant vor. Es ist auch interessant zu hinterfragen, was es bedeutet, auf bestimmte Schutzvorkehrungen zu verzichten. Solange der Ernstfall nicht eintritt, es also nicht zu einem Angriff und somit keinem Schaden kommt, entstehen keine Kosten. Abschließend wollen wir festhalten, dass eine allgemeine Empfehlung für Schutzeinrichtungen nicht gegeben werden kann. Jede Schutzmaßnahme (und deren Kombinationen) muss auf individuelle Bedürfnisse zugeschnitten und angepasst werden. Aus einer Vielzahl von technischen Lösungen und individuellen Bedürfnissen muss eine Auswahl getroffen werden, die die bestmögliche objektive und subjektive Sicherheit gewährleistet. 2.1.2 Ressourcen Sicherheit wird nicht nur objektiv und subjektiv als Zustand des Unbedrohtseins empfunden. Eine Bedrohung richtet sich immer gegen eine Ressource, d.h., Aussagen über IT-Sicherheit gelten nur in dem Kontext dieser Ressource. Wir definieren den Begriff Ressource wie folgt:
8
2 Grundlagen
Ressourcen sind Informationen sowie die entsprechenden IT-Betriebsmittel. Dazu zählen im IT-Kontext insbesondere Anwendungen, Systeme und Netzwerke. Für den Eigentümer stellen die Ressourcen einen Wert dar, den es gegen Bedrohungen zu schützen gilt. Def. 1-2 Ressource
Im Schichtenmodell des Grundschutzhandbuches des BSI sind beispielsweise einige typische IT-Ressourcen aufgeführt [24]. Für jede dieser Ressourcen werden dann relevante Bedrohungen und entsprechende Gegenmaßnahmen aufgeführt. Zusammengenommen ergibt dies jeweils einen „Baustein“ für den Grundschutz. Im Folgenden listen wir einige solcher Bausteine, deren Schichten wir teilweise auch in diesem Buch betrachten, auf: – Systeme DOS-PC, Unix-Systeme, Laptops bzw. Notebooks, PC mit diversen WindowsVarianten, nichtvernetzte Systeme, diverse vernetzte Systeme, TK-Anlagen, Faxgeräte, Anrufbeantworter, Mobiltelefone etc. – Anwendungen E-Mail, WWW, Lotus Notes, Datenbanken etc. – Netze Heterogene Netze, Netz- und Systemmanagement, Modem, Firewall, Remote Access etc. Darüber hinaus gibt es auch Werte, die auf organisatorischer und personeller Ebene angesiedelt sind. Hier geht es im Wesentlichen um übergeordnete Maßnahmen, die grundsätzlich immer durchgeführt werden sollten. Außerdem werden noch Bausteine der physikalischen Infrastruktur beschrieben. 2.1.3 Schutzziele Die allgemeine Definition von Sicherheit werden wir nun für den Bereich der ITSicherheit konkretisieren. Dies bedeutet insbesondere festzulegen, welche Ziele durch den Schutz von IT-Ressourcen erreicht werden sollen. In Anlehnung an eine Definition der OECD definieren wir Sicherheit wie folgt [85]:
2.1. Begriffe und Konzepte der IT-Sicherheit
9
Können die Schutzziele Verfügbarkeit, Vertraulichkeit und Integrität gewährleistet werden, so ist ein IT-System als sicher zu betrachten. – Verfügbarkeit bedeutet, dass ein Informationssystem im vorgesehenen zeitlichen Rahmen erreichbar und nutzbar ist. – Vertraulichkeit bedeutet die Freigabe von Daten und Informationen nur an autorisierte Personen, Gruppen und Prozesse zu einer vorgegebenen Zeit und in einer vorherbestimmten Art und Weise. – Integrität bedeutet, dass Daten und Informationen vollständig und genau sind und dass die Vollständigkeit und Genauigkeit über die Zeit erhalten bleiben. Def. 2-1 Schutzziele und Sicherheit
Die einzelnen Schutzziele können in weitere Teilziele untergliedert werden [134]. Da Sicherheit gemäß Definition 2-1 auch von subjektiven Faktoren beeinflusst wird, kann die Gewichtung und Signifikanz der Schutzziele sowie der Teilziele in Abhängigkeit von der Natur der IT-Ressource variieren. – Verfügbarkeit Zur Gruppe der Verfügbarkeitsziele gehören die Erreichbarkeit und die Rechtsverbindlichkeit. Die Erreichbarkeit sichert, dass zu einer Ressource jederzeit Kontakt aufgenommen bzw. dass sie jederzeit verwendet werden kann. Die Rechtsverbindlichkeit soll sichern, dass ein Nutzer rechtlich belangt werden kann, wenn er seine Verantwortlichkeiten innerhalb einer angemessenen Zeit nicht erfüllt. – Vertraulichkeit Zu den Vertraulichkeitszielen gehört die Vertraulichkeit selbst, also die Geheimhaltung von Daten. Zusätzlich gehören die Verdecktheit, die Anonymität und die Unbeobachtbarkeit zu den Vertraulichkeitszielen. Verdecktheit versteckt die Übertragung von vertraulichen Daten, d.h., niemand außer den Kommunikationspartnern kann die Existenz einer vertraulichen Kommunikation erkennen. Anonymität sichert, dass ein Nutzer Ressourcen und Dienste benutzen kann, ohne seine Identität zu offenbaren. Selbst der Kommunikationspartner erfährt die Identität nicht. Unbeobachtbarkeit sichert, dass ein Nutzer Ressourcen und Dienste benutzen kann, ohne dass andere beobachten können, dass die Ressource oder der Dienst genutzt wird. Dritte können weder das Senden noch den Erhalt von Nachrichten beobachten.
10
2 Grundlagen
– Integrität Falls Informationen nicht richtig, vollständig und aktuell sind, muss dies nicht erkennbar sein. Zu der Integrität gehört außerdem die Zurechenbarkeit, die sichern soll, dass Sendern bzw. Empfängern von Informationen das Senden bzw. der Empfang der Informationen gegenüber Dritten bewiesen werden kann. 2.1.4 Bedrohungen Bevor auf den Schutz vor Bedrohungen eingegangen werden kann, muss zunächst ein Verständnis für die Bedrohungen selbst vorhanden sein. In Anlehnung an das Internet Security Glossary [104] definieren wir den Begriff Bedrohung wie folgt: Eine Bedrohung tritt dann auf, wenn es entsprechende Umstände, Möglichkeiten, Aktionen oder Ereignisse gibt, die die Sicherheit gefährden und Schaden anrichten können. Def. 2-2 Bedrohung
Eine mögliche Bedrohung stellen Angriffe auf IT-Ressourcen dar, d.h., ein Angreifer versucht, die Sicherheit einer IT-Ressource zu unterwandern und zu seinem Vorteil auszunutzen. IT-Ressourcen werden oftmals als sicher angesehen, wenn keine Verletzlichkeiten bekannt sind und es damit keine bekannten Bedrohungen gibt. Die oben gegebene Definition von Sicherheit wird falsch interpretiert. Das Gefühl der Sicherheit ist trügerisch, denn nur das Fehlen öffentlich bekannter Lücken bedeutet noch nicht, dass diese nicht vorhanden sind und es niemanden gibt, der eine Verletzlichkeit in der entsprechenden IT-Ressource kennt und ausnutzen kann. Somit spiegelt die fehlende Wahrnehmung einer Bedrohung, die mit dem Gefühl der Sicherheit einhergeht, nur eine falsche Sicherheit vor. In Abschnitt 3.8 stellen wir eine Klassifizierung grundsätzlicher Bedrohungen im IT-Kontext vor. 2.1.5 Angreifer und Angriffe Zentrale Aspekte der IT-Sicherheit sind Angreifer und Angriffe, die von ihnen durchgeführt werden. Sie sind letzten Endes der Grund, warum es überhaupt notwendig ist, die Ressourcen zu schützen. Angreifer führen eine oder mehrere Aktionen durch, um Ressourcen der rechtmäßigen Eigentümer zu missbrauchen. Angreifer stellen damit eine Bedrohung für die jeweilige Ressource dar. Def. 2-3 Angreifer
Der Angreifer ist eine Ursache für Bedrohungen, die das Sicherheitsrisiko erhöhen. Formal wird auch von dem Urheber von Bedrohungen gesprochen (z.B. in den Common Criteria), da ein Angriff rein objektiv betrachtet z.B. nicht von einer ungewollten Fehlbedienung unterschieden werden kann. Der Einfachheit halber verwenden wir in diesem Buch aber stets den Begriff Angreifer.
2.1. Begriffe und Konzepte der IT-Sicherheit
11
Angreifer können in verschiedene Klassen eingeteilt werden. Dazu können die Attribute Verhalten (z.B. wohldefiniert, zufällig, geplant), Motivation (Sabotage, Spionage etc.), seine Fachkenntnisse und seine Lokation (physikalischer Zugang, Netzwerkzugang etc.) herangezogen werden. Ein Angreifer hat grundsätzlich mehr Möglichkeiten, wenn er innerhalb der Schutzzone operiert. In diesem Fall sprechen wir von einem Innentäter, der einen legitimen Zugang zu den IT-Systemen hat, diesen aber für seine Zwecke missbraucht. Ein bekannter Fall eines Innentäters war beispielsweise ein Bankangestellter, der sich immer Pfennigbeträge, deren Fehlen auf der Kundenabrechnung wegen Rundungsfehlern gar nicht aufgefallen ist, auf sein Konto überwiesen hat. Nur ein Innentäter konnte die notwendigen Kenntnisse über die internen Abläufe und die Befugnis zur Umbuchung haben. Ein Angreifer von außen hätte es in dieser Hinsicht ungleich schwerer. Ihm stehen lange nicht so viele Wege offen wie einem Innentäter. Die genannten charakteristischen Merkmale eines Angreifers bestimmen die Auswirkungen eines Angriffs und die entsprechenden Gegenmaßnahmen. Für den Begriff Angriff verwenden wir in diesem Buch die folgende Definition: Ein Angriff ist eine vorsätzliche Handlung, um die Schutzeinrichtungen einer Ressource zu umgehen oder die Schutzziele, die für eine Ressource gelten, zu verletzen. Def. 2-4 Angriff
Ein Angriff kann mit der durchzuführenden Aktion (z.B. Objekte erzeugen, zerstören, modifizieren, ausspähen etc.), dem Fehler, der zu der Verletzlichkeit geführt hat (z.B. ein Konfigurationsfehler), und der Phase des Lebenszyklus (z.B. Entwicklung oder Betrieb) der attackierten Ressource klassifiziert werden. Weiterhin wird zwischen aktiven und passiven Angriffen unterschieden. Außerdem spielt es eine wesentliche Rolle, ob ein Angriff von innen oder außen vorgenommen wird. Bei einem aktiven Angriff wird versucht, die Ressourcen eines ITSystems zu verändern oder deren Betrieb zu beeinflussen. Dahingegen wird mithilfe von passiven Angriffen versucht, aufgrund der Beobachtung des Systems oder ausgetauschter Daten, möglichst viele nützliche Informationen (z.B. die Kreditkartennummer des Opfers) zu gewinnen. Ein erfolgreicher Angriff führt im Allgemeinen zu einem Schaden. Dies beinhaltet die Auswirkungen eines Angriffs, also beispielsweise die Vorteile, die sich ein Angreifer verschaffen kann (z.B. ein administrativer Systemzugang) oder die Verletzung eines der Schutzziele (z.B. Vertraulichkeit oder Integrität). 2.1.6 Anforderungen Das Themengebiet IT-Sicherheit beinhaltet neben den technischen Aspekten weitere wesentliche, aber nicht technische Aspekte. Dazu gehören beispielsweise juristische, psychologische oder wirtschaftliche Fragestellungen. Ein wesentlicher Teil der technischen Aspekte kann mit Mitteln der Informationstechnik behandelt wer-
12
2 Grundlagen
den. Auf diesen Aspekten der IT-Sicherheit liegt der Fokus dieses Buches. Entsprechend dieser Einschränkung wird das Themengebiet IT-Sicherheit wie im Folgenden verstanden. Wir definieren den Begriff Anforderung wie folgt: Eine Anforderung beschreibt eine Eigenschaft, die von einer Ressource erwartet wird. Anforderungen können im Gegensatz zueinander stehen wie z.B. Sicherheit und Benutzbarkeit. Def. 2-5 Anforderung
An ein IT-System werden die unterschiedlichsten Anforderungen gestellt. Um einen Eindruck über solche Anforderungen vermitteln zu können, stellen wir kurz einige Beispiele aus dem ISO Standard 9126, der für die Qualität von Softwareprodukten ein hierarchisches Modell für solche Anforderungen definiert, vor [61]: – Funktionalität Es geht bei dieser Anforderung um Funktionen, die ein Produkt erfüllen muss, um die Bedürfnisse der Benutzer zu erfüllen. Nach dem ISO Standard gehören zu den Funktionalitätseigenschaften außerdem die Eignung, Richtigkeit, Interoperabilität sowie die Konformität zu Standards, Konventionen, Gesetzen und andere Aspekte, die die Funktionalität betreffen. Es ist bemerkenswert, dass zudem auch die Sicherheit als Aspekt der Funktionalität genannt wird. Wie wir in diesem Abschnitt noch zeigen werden, sind wir der Meinung, dass dies nicht richtig ist (im Software Engineering wird Sicherheit oft als nichtfunktionale Eigenschaft betrachtet). – Zuverlässigkeit Die Anforderungen, die die Zuverlässigkeit eines Software-Produkts spezifizieren, beziehen sich darauf, dass das Produkt bestimmte Stufen der Performanz gewährleisten kann. Zu den Zuverlässigkeitseigenschaften gehören Reife, Fehlertoleranz und Wiederherstellung des Betriebs nach einer Störung. Auch hier kann die Komformität zu Standards etc. gefordert werden. – Benutzbarkeit Die Erfüllung dieser Anforderung ist von hoher Bedeutung. IT-Ressourcen, die nur schwer benutzbar sind, werden von dem Benutzer nicht angenommen. Die Anforderung der Benutzbarkeit kann weiter in Erlernbarkeit, Bedienbarkeit und Attraktivität aufgegliedert werden. Auch hier sollten ergonomische Standards berücksichtigt werden. – Effizienz Hier geht es um eine angemessene Performanz im Hinblick auf die im Betrieb zur Verfügung stehenden Betriebsmittel. Dazu sind ein angemessenes zeitliches Verhalten (Antwortzeiten, Verarbeitungszeiten und Durchsatzraten) sowie eine vertretbare Auslastung der Betriebsmittel zu zählen.
2.1. Begriffe und Konzepte der IT-Sicherheit
13
– Wartbarkeit Dies bedeutet, dass es die Möglichkeit geben muss, ein Produkt zu ändern, wenn dies die äußeren Gegebenheiten erfordern. Dazu sollten insbesondere die Anforderungen Diagnosefähigkeit, Änderbarkeit, Stabilität und Testbarkeit erfüllt werden. – Portabilität Schließlich sollte es möglich sein, ein Produkt von einer Umgebung in eine andere zu überstellen. Dazu müssen Anforderungen wie die Anpassbarkeit an und die Installationsfähigkeit in verschiedene Umgebungen gewährleistet sein. Weiterhin kann die Austauschbarkeit gegen andere Produkte und die Fähigkeit, mit anderen Produkten in einer gemeinsamen Umgebung existieren zu können, gefordert werden. An erster Stelle der Anforderungen steht zunächst immer die Funktionalität, d.h., das System soll genau das tun, was von ihm erwartet wird. So erwarten wir beispielsweise von dem „Zurück“-Knopf eines Webbrowsers, dass eine Seite zurückund nicht etwa vorgesprungen wird. Die Forderung nach Sicherheit wird allerdings aus verschiedenen Gründen nicht in genügendem Maß berücksichtigt. Ein wesentlicher Grund dafür ist, dass Sicherheit eigentlich eine nichtfunktionale Eigenschaft ist: Ein Benutzer, dessen Ressource korrekt funktioniert, kann eigentlich nicht sagen, ob es auch sicher ist oder nicht 1. Es ist grundsätzlich auch gar nicht möglich, eine Aussage darüber zu treffen, ob eine Ressource sicher ist. Das Einzige, was definitiv nachgewiesen werden kann, ist, ob eine Ressource unsicher ist, d.h., eine bekannte Verletzlichkeit dafür existiert. Selbst wenn alles Menschenmögliche getan worden ist und es nicht gelingt, eine Verletzlichkeit zu finden, kann damit keine Aussage über die Sicherheit getroffen werden. Vielleicht wird schon am nächsten Tage eine bis dahin unbekannte Sicherheitslücke entdeckt. Dennoch ist für den letztendlichen Erfolg einer Ressource auch deren Sicherheit von Bedeutung, da diese Einfluss auf die Erfüllung der primären funktionalen Anforderungen hat. Zusätzlich hat der Sicherheitsaspekt erheblichen Einfluss auf nicht technische Anforderungen wie z.B. die Wirtschaftlichkeit oder die Gesetzeskonformität der IT-Ressourcen. Wie wir in Abschnitt 2.2.3 zeigen werden, führt insbesondere die zweitrangige Betrachtung der Sicherheit dazu, dass IT-Systeme erst nachträglich in ein Sicherheitskonzept integriert werden bzw. ein Sicherheitskonzept für sie erstellt wird. Dies führt in der Regel dazu, dass Sicherheitsanforderungen nicht mehr in dem Maße umgesetzt werden können, wie dies bei einer Beachtung dieser Anforderungen schon bei der Konzeption des IT-Systems möglich gewesen wäre.
1
Von Edsger W. Dijkstra stammt die Aussage, dass Tests immer nur die Existenz von Fehlern zeigen können, aber niemals die Fehlerfreiheit. Diese Aussage lässt sich auf das Gebiet der IT-Sicherheit übertragen, wenn Sicherheitslücken als Fehler verstanden werden.
14
2 Grundlagen
Aus den offensichtlichen Wechselwirkungen, die zwischen Sicherheit und anderen Systemanforderungen bestehen, folgt, dass eine optimale 2 Gesamtlösung in der Regel nur dann erreicht werden kann, wenn alle Parameter 3 gemeinsam angepasst werden. Dies bedeutet, dass auch Sicherheitsanforderungen, die in bestimmten Sicherheitslösungen umgesetzt werden, an die Systemanforderungen der zu schützenden Ressourcen angepasst werden müssen. Es bedeutet andererseits aber auch, dass die zu schützenden Ressourcen ebenfalls angepasst werden müssen, um keine funktionalen Einschränkungen durch die mit einer Sicherheitslösung umgesetzten Sicherheitsanforderungen zu erfahren. Gerade dieser Aspekt kann in der Praxis allerdings nur schwer umgesetzt werden, da eine Neudefinition bestehender Architekturen meist nicht möglich ist. 2.1.7 Verletzlichkeiten Damit ein Angriff überhaupt stattfinden kann, muss eine IT-Ressource Sicherheitslücken aufweisen, die ausgenutzt werden können. Für den englischen Begriff Vulnerability gibt es die korrekten Übersetzungen Verletzlichkeit oder Verwundbarkeit. Allerdings werden oftmals die Begriffe Schwachstelle oder Sicherheitslücke synonym verwendet. Von einer Sicherheitslücke wird jedoch nur dann gesprochen, wenn eine Schutzmaßnahme fehlerhaft ist, was dann zu einer Verletzlichkeit führt. Wir verwenden in diesem Buch ausschließlich die folgende Definition für Verletzlichkeit: Ein System weist eine Verletzlichkeit auf, wenn es nur in einem unzureichenden Maß Schutz gegen Missbrauch jeglicher Art gewährt. Wird diese Verletzlichkeit ausgenutzt, so ist die Sicherheit des betroffenen Systems gefährdet. Def. 2-6 Verletzlichkeit
In [66] wird eine Einteilung in vier grundlegende Arten von Verletzlichkeiten vorgenommen. Wie in Tabelle 2-1 dargestellt, bezieht sich diese Gliederung auf zwei Faktoren. Der erste Faktor bezieht sich auf das spezifische Ziel eines Angriffs, wobei zwischen Personen und IT-Systemen unterschieden wird. Der zweite Faktor bezieht sich auf die Zeitspanne, die verstreicht, bis ein Angreifer eine solche Verletzlichkeit ausnutzen kann.
2 3
Optimal = Ausreichende Umsetzung aller Anforderungen Parameter = Sicherheitsmechanismen sowie andere Systemparameter
2.1. Begriffe und Konzepte der IT-Sicherheit
15
Tab. 2-1 Einordnung von Verletzlichkeiten
Person
IT-System
Unmittelbar
„Social Engineering“
Logischer Fehler
Benötigt eine gewisse Zeitspanne
Fehlerhafte Richtlinie
Schwachstelle
Die verschiedenen Arten von Verletzlichkeiten werden im Folgenden kurz diskutiert: – Logische Fehler Ein logischer Fehler stellt eine Möglichkeit dar, einen Effekt auszunutzen, der sich negativ auf die IT-Sicherheit auswirkt. Dies kann als elementarer Fehler bezeichnet werden. Solche Probleme entstehen durch bestimmte Umstände, meist durch schlecht geschriebene Programme, die einen Zugang zu einem System mit größeren Rechten als beabsichtigt erlauben. Dies ist der Typ von Verletzlichkeit, an den gewöhnlich zuerst gedacht wird. – Schwachstelle Eine Schwachstelle resultiert aus einer Schutzmaßnahme, die aufgrund eines Entwurfsfehlers zu einem Angriff führen kann. Unter diesen Typus fallen in der Regel Maßnahmen, die zwar grundsätzlich dazu geeignet sind, die Sicherheit zu erhöhen, jedoch mit entsprechenden Kenntnissen des Angreifers umgangen werden können. Auch der klassische Begriff der „Security by Obscurity“ fällt in diesen Bereich. Darunter ist zu verstehen, dass die Sicherheit einer Ressource auf geheim gehaltenen Konzepten und Mechanismen beruht. Die Sicherheit einer Ressource ist damit so lange gegeben, bis ein Dritter das Geheimnis kennt. Aller Erfahrung nach war es bisher immer nur eine Frage der Zeit, bis es dazu kam. Der Kernpunkt dieses Typs einer Verletzlichkeit ist, dass zwar Sicherheit vorhanden ist, es jedoch auch mehr oder minder effiziente Wege gibt, um diese Sicherheit auszuhebeln. – Social Engineering Unter Social Engineering ist ein direkter Angriff auf die Sicherheitsrichtlinien eines Unternehmens zu verstehen. Dabei wird versucht, die Richtlinien des Unternehmens mit der unfreiwilligen Mithilfe von Mitarbeitern zu umgehen. Darunter ist beispielsweise zu verstehen, dass ein Mitarbeiter von einem Dritten dazu gebracht wird, Geheimnisse preiszugeben, wie beispielsweise das Passwort seiner Benutzerkennung. – Fehlerhafte Richtlinien Schließlich beziehen sich fehlerhafte Richtlinien auf Fehler bei der Planung zur Vermeidung bestimmter Situationen. Beispielsweise ist es fatal, wenn bei der
16
2 Grundlagen
Erstellung von Backups ein derartiger Fehler vorliegt, der zur Unbrauchbarkeit der gesicherten Daten führt. Ein anderes Beispiel ist es, wenn Personen Zugriffsrechte auf Daten haben, die nicht für sie bestimmt sind. Diese Einteilung ist nicht vollständig und allgemein gültig, erscheint uns aber durchaus als geeignet, um eine grobe Gliederung von Verletzlichkeiten durchzuführen. Beispielsweise ist es durchaus denkbar, dass man Social Engineering auch über einen längeren Zeitraum durchführt, um einen bestimmten Geheimnisträger dazu zu bringen, Informationen preiszugeben. Dies wäre das klassische „Spionageszenario“, bei dem zuerst das Vertrauen einer Person erworben wird, um diese dann zu Indiskretionen zu verleiten. Gleichermaßen hinterfragt werden kann die Abgrenzung von logischen Fehlern und Schwächen. Im Grenzbereich zwischen diesen Typen kann es Verletzlichkeiten geben, die nicht eindeutig zugeordnet werden können. Eine solche Zweideutigkeit tritt bei dem in [66] zitierten Beispiel mit der Umgehbarkeit einer Schutzmaßnahme auf. Dabei kann es sich einerseits tatsächlich um eine Schwäche handeln, es kann dabei jedoch auch ein logischer Fehler vorliegen. Für die Betrachtung von Verletzlichkeiten einer IT-Ressource ist dabei in der Regel der Bereich der logischen Fehler sowie der Bereich der Schwächen, der sich direkt in Produkten widerspiegelt, interessant. Dabei ist es möglich, die logischen Fehler weiter nach dem Zeitpunkt ihrer Entstehung zu untergliedern. Die Fehler gehen, ähnlich wie auch die alltäglichen und nicht direkt sicherheitsrelevanten Programmierfehler, auf eine von mehreren Ursachen zurück. Diese sind beispielsweise Verständnisfehler, Entwurfsfehler, Implementierungsfehler, Systemintegrationsfehler und Konfigurationsfehler. 2.1.8 Maßnahmen Um einen Zustand des Unbedrohtseins erreichen zu können, müssen nach Definition 2-1 entsprechende Schutzeinrichtungen vorhanden sein. Wir sprechen in diesem Fall von Maßnahmen, die wir wie folgt definieren: Eine Maßnahme ist eine Aktion, ein Gerät, eine Prozedur oder eine Technik, die Bedrohungen und Angriffe verhindert oder Verletzlichkeiten ausmerzt. Def. 2-7 Maßnahme
Es gibt eine Reihe alternativer Strategien, um Maßnahmen zum Schutz vor Bedrohungen zu erreichen [29]. Idealerweise ergänzen sich dabei proaktive und reaktive Maßnahmen. Primäres Ziel ist es, die Auswirkungen von Verletzlichkeiten zu eliminieren oder aber den Schaden zu begrenzen. Im Folgenden werden die verschiedenen Ansätze vorgestellt.
2.1. Begriffe und Konzepte der IT-Sicherheit
17
– Proaktive Maßnahmen Wir sprechen von Prävention gegen Gefahren, die vorhergesehen wurden. Gegen sie können bereits im Vorfeld entsprechende Vorkehrungen getroffen werden. Im Zusammenhang mit IT-Systemen können dies z.B. qualitativ hochwertige Hardware, Software und Datenträger sein. Weiterhin können starke physikalische und logische Mechanismen zur Zugriffskontrolle eingesetzt werden. Organisatorisch kommen Maßnahmen zur Bewusstseinsbildung, Zuordnung von Verantwortung sowie festgelegte Prozeduren, die bei der Einstellung oder dem Ausscheiden von Personal angewendet werden. In bestimmten Fällen kann es Sinn machen, Risiken erst gar nicht entstehen zu lassen, indem kritische Technologien oder Verfahren nicht verwendet werden. Da durch diese Entscheidungen zur Verhinderung von Angriffen bestimmte Produkte nicht in Frage kommen, stehen allerdings auch weniger Freiheitsgrade bei der Umsetzung der Funktionalität einer IT-Ressource zur Verfügung. Möglicherweise scheidet diese Variante aber aus, da bestimmte äußere Zwänge, wie etwa Kompatibilität zu anderen Produkten oder die Rückwärtskompatibilität zu bereits existierenden Komponenten, die Verwendung unsicherer Komponenten notwendig machen. Ein anderes Konzept, das auch in der realen Welt als Mittel zur Prävention eingesetzt wird, ist das Prinzip der Abschreckung. So wird z.B. jeder Benutzer darauf hingewiesen, dass ihm entsprechend hohe Strafen drohen, wenn er widerrechtliche Handlungen begeht. Durch entsprechend publikumswirksam inszenierte Strafprozesse von Angreifern, die von den Behörden aufgespürt wurden, kann dieser Effekt verstärkt werden. Mitarbeitern droht im Falle von schwerwiegenden Vergehen die fristlose Kündigung und ein damit verbundener Verlust der Reputation. Andererseits nützt dies alles nichts, wenn ein Angreifer sich nicht abschrecken lässt. Selbst wenn er entdeckt und dingfest gemacht wird, lässt sich der entstandene Schaden möglicherweise nicht rückgängig machen. – Reaktive Maßnahmen Weitere Gegenmaßnahmen zielen darauf ab, einen Angriff als solchen überhaupt zu erkennen. Diese Maßnahmen zur Detektion sind unerlässlich, um festzustellen, dass etwas nicht stimmt. Nur wenn ein Angriff erkannt worden ist, kann korrigierend eingegriffen werden, d.h., es werden entsprechende Schritte als Reaktion auf den Angriff eingeleitet. So kann beispielsweise nach einer bestimmten Anzahl von Fehlversuchen beim Anmelden eines Benutzers eine Nachricht an den Systemadministrator generiert und der betroffene Zugang automatisch gesperrt werden. Wenn es nicht gelingt, einen Angriff rechtzeitig zu erkennen, müssen Vorkehrungen zum Wiederaufsetzen getroffen werden. Dazu gehören z.B. redundante Komponenten und spezielle Einrichtungen zum regelmäßigen Sichern von Daten. Darüber hinaus muss ein Notfallplan dokumentiert werden, damit klar ist,
18
2 Grundlagen
wer was im Ernstfall zu tun hat. Sinnvollerweise werden Notfälle von Zeit zu Zeit geübt. So kann beispielsweise sichergestellt werden, dass ein Backup tatsächlich die zu sichernden Daten enthält und nicht irgendwelche zufälligen Bitfolgen. IT-Sicherheit bedeutet auch die Minimierung der Risiken. Wie im wirklichen Leben kann jedoch nicht allen Gefahren mit technischen oder organisatorischen Maßnahmen begegnet werden. Für die verbleibenden Restrisiken bietet es sich an, eine entsprechende Absicherung vorzusehen. Dazu gehören beispielsweise Verträge mit Versicherungsgesellschaften und Wartungsverträge mit Herstellern. Leider wird in der Praxis manchmal eine eher zweifelhafte Alternative zu den oben beschriebenen Strategien gewählt. Viele Entscheidungsträger hängen Mythen an, die kontraproduktiv für die Sicherstellung der Geschäftsinteressen des Unternehmens sind [43]. So wird etwa fälschlicherweise geglaubt, dass sich im eigenen Unternehmen noch nie sicherheitsrelevante Vorfälle ereignet hätten oder dass die eingebauten Sicherheitsvorkehrungen ausreichend seien. Die Gefahren werden so einfach toleriert; im Allgemeinen allerdings nur so lange, bis tatsächlich etwas passiert ist. 2.1.9 Risiko Der Begriff Risiko wird immer dann verwendet, um abschätzen zu können, mit welchen Gefahren eine bestimmte geplante Aktion verbunden sein könnte. Auf den ITBereich übertragen kann Risiko gemäß dem Internet Security Glossary wie folgt definiert werden [104]: Das Risiko ist der zu erwartende Verlust, der sich aus den Wahrscheinlichkeiten für einen bestimmten Angriff, der eine bestimmte Verletzlichkeit ausnutzt und zu einem bestimmten Schaden führt, zusammensetzt. Def. 2-8 Risiko
Das Risiko wird im IT-Kontext grundsätzlich dazu verwendet, um eine Entscheidung darüber treffen zu können, ob eine bestimmte Maßnahme überhaupt notwendig ist. Dazu muss ermittelt werden, wie oft ein bestimmter Angriff durchgeführt wird und wie hoch der zu erwartende Schaden ist. Dieser Ansatz ist aber aus mehreren Gründen von zweifelhaftem praktischen Wert. Einerseits ist es schwierig, zuverlässiges Zahlenmaterial für die Eintrittswahrscheinlichkeit sowie die Kosten, mit denen ein Schaden beziffert wird, eines Angriffs zu ermitteln. Dies liegt u.a. an der Dunkelziffer, d.h., es muss davon ausgegangen werden, dass längst nicht alle Angriffe gemeldet werden 4.
4
Ein Grund für die Geheimhaltung eines Angriffs ist beispielsweise die Angst vor einem Imageverlust, der höheren Schaden als der Angriff selbst nach sich ziehen könnte.
2.1. Begriffe und Konzepte der IT-Sicherheit
19
Andererseits sind die Ergebnisse einer Risikoanalyse nicht zeitinvariant, d.h., sie sollten grundsätzlich jährlich aktualisiert werden, um so den Trends der sich ständig ändernden Angriffsvarianten gerecht zu werden. Hier besteht die Gefahr, dass mit den Zahlen des Vorjahres gearbeitet wird, da dies definitiv weniger Kosten verursacht als eine Neuermittlung. Dies führt allerdings auch zu weniger aussagekräftigen Ergebnissen. 2.1.10 Zusammenfassung Zu Referenzzwecken fassen wir die Kernpunkte der Definitionen der aus dem Bereich IT-Sicherheit verwendeten Begriffe, die in diesem Buch verwendet werden, auf einen Blick zusammen. – Sicherheit Wesentlich für eine Begriffsbildung ist, dass IT-Sicherheit nur auf den ersten Blick ein rein technisches Problem ist. IT-Sicherheit wird von Menschen für Menschen umgesetzt, dementsprechend muss den sich daraus ergebenden Aspekten ebenfalls Rechnung getragen werden. Der technische – und für dieses Buch wesentliche – Aspekt der Sicherheit kann folgendermaßen beschrieben werden: Sicherheit von IT-Ressourcen ist der Schutz von Verfügbarkeit, Vertraulichkeit und Integrität. – Ressourcen Ressourcen sind Informationen sowie die entsprechenden IT-Betriebsmittel. Dazu zählen im IT-Kontext insbesondere Anwendungen, Systeme und Netzwerke. Für den Eigentümer stellen die Ressourcen einen Wert dar, den es gegen Bedrohungen zu schützen gilt. – Schutzziele Entsprechend der obigen Definition sind die Schutzziele in IT-Systemen: Verfügbarkeit, Vertraulichkeit und Integrität. – Bedrohungen Eine Bedrohung tritt dann auf, wenn es entsprechende Umstände, Möglichkeiten, Aktionen oder Ereignisse gibt, die die Sicherheit gefährden und Schaden anrichten können. – Angreifer und Angriffe Angreifer führen eine oder mehrere Aktionen durch, um Ressourcen der rechtmäßigen Eigentümer zu missbrauchen. Angreifer stellen damit eine Bedrohung für die jeweilige Ressource dar. Ein Angriff ist eine vorsätzliche Handlung, um die Schutzeinrichtungen einer Ressource zu umgehen oder die Schutzziele, die für eine Ressource gelten, zu verletzen.
20
2 Grundlagen
– Anforderungen Eine Anforderung beschreibt eine Eigenschaft, die von einer Ressource erwartet wird. Anforderungen können im Gegensatz zueinander stehen wie z.B. Sicherheit und Benutzbarkeit. – Verletzlichkeiten Ein System weist eine Verletzlichkeit auf, wenn es nur in einem unzureichenden Maße Schutz gegen Missbrauch jeglicher Art gewährt. Wird diese Verletzlichkeit ausgenutzt, so ist die Sicherheit des betroffenen Systems gefährdet. – Maßnahmen Eine Maßnahme ist eine Aktion, ein Gerät, eine Prozedur oder eine Technik, die Bedrohungen und Angriffe verhindert oder Verletzlichkeiten ausmerzt. Proaktive Maßnahmen richten sich gegen Bedrohungen, die vorhergesehen wurden. Reaktive Maßnahmen zielen darauf ab, einen Angriff als solchen überhaupt zu erkennen. – Risiko Das Risiko ist der zu erwartende Verlust, der sich aus den Wahrscheinlichkeiten für einen bestimmten Angriff, der eine bestimmte Verletzlichkeit ausnutzt und zu einem bestimmten Schaden führt, zusammensetzt. Im Folgenden sind noch einmal alle Begriffe sowie deren Zusammenhänge untereinander als „Begriffsnetzwerk“, das sich aus den bisherigen Definitionen ergibt, dargestellt. Abbildung 2-1 verdeutlicht den komplementären Zusammenhang zwischen den Begriffen Maßnahme und Angriff. Während ein Angriff Ressourcen bedroht und damit das Risiko für den Eigentümer einer Ressource erhöht, schützen Maßnahmen gegen Angriffe und minimieren daher das Risiko. Risiko minimiert führt zu Maßnahme
Angriff
schützt bedroht Ressource Abb. 2-1 Zusammenhang zwischen Angriff und Maßnahme
2.1. Begriffe und Konzepte der IT-Sicherheit
21
Abbildung 2-2 verdeutlicht die Charakteristik von Angriffen, d.h., es werden die Begriffe, die rund um den Begriff Angriff geordnet sind, im Zusammenhang gezeigt. Hier wird nochmals deutlich, dass ein Angriff wesentlich durch den Angreifer selbst sowie durch die Verletzlichkeit, die zur Durchführung eines Angriffs ausgenutzt wird, bestimmt wird. Risiko Bedrohung führt zu ist eine
Ressource Angriff
bedroht
ausgeführt von
nutzt aus
Angreifer
Verletzlichkeit
Abb. 2-2 Charakteristik des Begriffs „Angriff“
In Abbildung 2-3 wird entsprechend die Charakteristik von dem Begriff Maßnahme dargestellt. Hervorzuheben ist hier, dass Maßnahmen sowohl durch Schutzziele als auch durch Anforderungen, die jeweils von dem Eigentümer einer Ressource festgelegt werden, bestimmt werden. Risiko Anforderung minimiert festgelegt durch
Ressource
Maßnahme
schützt
ausgeführt von Eigentümer
festgelegt durch Schutzziele
Abb. 2-3 Charakteristik des Begriffs „Maßnahme“
22
2 Grundlagen
2.2 Der Hacker Contest Um verstehen zu können, welche Vorgehensweisen und Mechanismen bei Angriffen ablaufen, und auf dieser Basis die richtigen Maßnahmen zu ergreifen, können wir nicht auf Beobachtungen der Vorgänge in der realen IT-Welt zurückgreifen. Dies hat prinzipiell zwei Gründe: – Im Falle eines erfolgreichen Angriffs kann davon ausgegangen werden, dass bei weitem nicht alle Opfer bereit sind, eine Auskunft über die Details der Vorgänge zu geben, d.h., dass die Dunkelziffer hoch sein wird. Ein Motiv für dieses Verschweigen ist beispielsweise die Angst vor einer nachhaltigen Rufschädigung. – In gleicher Weise ist es kaum möglich, Informationen von einem Angreifer zu erhalten. In der Regel sind die Angreifer weder bekannt, noch sind sie dazu bereit bekannt zu geben, wie genau sie bei einem Angriff vorgegangen sind. Dies war auch die Motivation, das Experiment „Hacker Contest“ zu planen und durchzuführen. In einem kontrollierten Rahmen haben wir mit verschiedenen Teilnehmergruppen einerseits verschiedene Angriffskonzepte identifiziert, durchgeführt und analysiert, um die Bedrohungen für IT-Ressourcen besser verstehen zu können. Andererseits haben wir feststellen können, welche Konzepte und Mechanismen aus Sicht des Eigentümers einer IT-Ressource notwendig sind, um ein angemessenes Sicherheitsniveau erreichen zu können. IT-Sicherheit ist kein Problem, für das es eine einfache Lösung gibt. Durch das Nachstellen der IT-Welt im Versuchslabor konnten wir allerdings einige Ursachen dafür identifizieren, warum das Problem mit dem Schutz gegen Angriffe offenbar nicht richtig in den Griff zu bekommen ist: Obwohl es verschiedene Hilfsmittel für den Schutz von IT-Ressourcen gibt, steht dabei immer die Technik im Vordergrund. Da diese auch ohne das Problem der IT-Sicherheit schon komplex ist, sind insbesondere Laien schnell überfordert, wenn es darum geht, die richtigen Maßnahmen zu ergreifen. Uns ging es daher auch darum, den Faktor Mensch im Kontext der ITSicherheit zu berücksichtigen. In diesem Abschnitt diskutieren wir zunächst, wie ernst die Gefahr durch Angriffe genommen werden muss. Dann beschreiben wir zunächst das Konzept des „Hacker Contest“ und geben einen Überblick über die betrachteten Themenkomplexe. Wir stellen den Aufbau des Versuchlabors vor und präsentieren schließlich die Erkenntnisse, die wir aus dem Experiment gewonnen haben. Verallgemeinert übertragen wir diese Erkenntnisse dann wieder auf die IT-Welt. 2.2.1 Gefahr durch Hacker – Hype oder Realität? Hacker sind immer wieder ein Thema, dem in der Öffentlichkeit eine große Aufmerksamkeit geschenkt wird, wie beispielsweise die Angriffe Distributed Denial of
2.2. Der Hacker Contest
23
Service (DDoS) im Februar 2000, der E-Mail-Wurm I Love You im Mai 2000 oder der Code Red im Jahr 2001 gezeigt haben. In einem Artikel von Spiegel Online [87] wird der britische Außenminister Robin Cook folgendermaßen zitiert: „Hacker könnten Großbritannien schneller als ein militärischer Angriff in die Knie zwingen.“ Dahinter steckt die Auffassung, dass die Bedrohung durch Hacker längst eine staatsfeindliche Dimension erreicht hat und Hacken als subversiver Akt betrachtet wird. Sicherlich muss dabei der Zeitpunkt berücksichtigt werden, den Cook für seine Rede gewählt hat. Am gleichen Tag wurden dem britischen Parlament Unterlagen über die Kosten der staatlichen Geheimdienste, die sich nach offiziellen Angaben seit dem Ende des kalten Krieges mindestens verdoppelt haben, vorgelegt. So handelt Cook vermutlich nicht ganz uneigennützig, wenn er sagt, dass die Geheimdienste auf die Gefahr aus dem Internet reagieren müssen. Von der Hand zu weisen sind solche Szenarien nicht. Im Juli 1998 hat beispielsweise die amerikanische Hackergruppe Legion of the Underground (LoU) gewissermaßen eine Kriegserklärung gegen den Irak und China ausgesprochen. Wie z.B. in [94] beschrieben, „diente der Plan des Hackens und Zerstörens der Kommunikationsinfrastrukturen der genannten Länder der Unterstützung der Menschenrechte und der Opfer von Menschenrechtsverletzungen.“ Obwohl es aufgrund der Intervention anderer Hackergruppen, die auf die Hacker-Ethik verwiesen, niemals zu diesen Angriffen kam, eine – wohl unfreiwillige – Legitimierung für die Aufrüstung zum Infowar war damit allemal gegeben. An dieser Stelle können wir festhalten, dass die Gefahr durch Angriffe aus dem Internet erkannt worden ist und sehr ernst genommen wird. Außerdem gibt es einzelne Personen und Gruppen, die offenbar bereit dazu sind, um entsprechende kriminelle Energie aufzubringen, Angriffe mit schwerwiegenden Folgen zu planen und durchzuführen. Um dies zu verdeutlichen, betrachten wir im Folgenden einige populäre Attacken. Melissa Im März 1999 machten die ersten Meldungen über ein Microsoft Word 97- und Word 2000-Makro-Virus die Runde. Das Virus verbreitete sich über Microsoft Outlook E-Mails, die eine infizierte Word-Datei enthielten. In der entsprechenden Empfehlung des CERT wird beschrieben, dass sich dieses Virus sehr schnell ausgebreitet hat und in kurzer Zeit sehr viele Systeme rund um den Globus infizierte [25]. Die Hersteller von Anti-Virus-Programmen haben diesem Virus den Namen Melissa gegeben. Hatte sich das System eines Opfers mit dem Virus infiziert, führte dies dazu, dass weitere verseuchte E-Mails an die ersten 50 Einträge aus dem Outlook-Adressbuch gesendet wurden. Dabei wurde zwar der direkt betroffene Rechner kaum beschädigt, allerdings kam es zu erheblichen Überlastungen von Mail-Servern. So mussten beispielsweise die Mail-Server von führenden Herstellern wie etwa Compaq, Intel, Lucent, Microsoft und Motorola vom Netz genommen werden.
24
2 Grundlagen
Eine Analyse des Melissa-Quelltexts hat ergeben, dass eine Aktion des Benutzers des betroffenen Systems notwendig ist, damit sich der Virus verbreiten kann: Das Opfer muss die infizierte Word-Datei öffnen. Dies ist übrigens auch der Grund, warum Melissa nicht als Wurm, sondern als Virus klassifiziert wird. Allerdings ist es auch möglich, dass im Falle einer bestimmten Konfiguration der E-Mail-Software der Anhang der Nachricht automatisch geöffnet wird. Wir halten fest, dass die primären Ursachen für den Schaden im Fall Melissa menschliches Fehlverhalten und ggf. eine Fehlkonfiguration der E-Mail-Software sind. Abschließend möchten wir darauf hinweisen, dass Melissa nicht sehr destruktiv war, obwohl dies ohne weiteres möglich gewesen wäre. So wurden beispielsweise keine Dateien gelöscht oder Festplatten formatiert. Außerdem wurde weitgehend davon abgesehen, sensible Informationen, wie z.B. die Passwort-Datei, offen zu legen. Love Letter Ein prominenter Nachfolger von Melissa ist der Love Letter-Wurm, der zum ersten Mal am 4. Mai 2000 auftauchte und der sich außerordentlich schnell verbreitete. Auch hier wurden in kürzester Zeit weltweit Hunderttausende Systeme infiziert. Der Wurm konnte sich auf unterschiedlichste Weisen verbreiten. Dazu gehören beispielsweise E-Mails, IRC, USENET-news und WWW-Seiten. Ähnlich wie bei Melissa versendet sich der Wurm an alle Einträge des Microsoft Outlook-Adressbuchs (Version 98 oder 2000). Ausgenutzt wird dabei die Tatsache, dass Outlook vollen Zugriff auf den Windows Scripting Host (WHS) hat, der es erlaubt, nahezu beliebige Skripte auszuführen. Zusätzlich wird der Benutzer elegant hereingelegt: Die Nachricht scheint von einem Bekannten zu kommen, die Betreffzeile klingt eigentlich harmlos. Da die Namenserweiterung .vbs für Visual Basic-Skripte von Outlook standardmäßig nicht angezeigt wird, denkt das Opfer, eine ungefährliche .txt erhalten zu haben, und öffnet diese mit einem Mausklick. Nach einer Schätzung des amerikanischen CERT beläuft sich der Schaden weltweit auf Arbeitsstunden im Wert von zehn Milliarden Dollar. Der mutmaßliche Autor des Wurms wurde von Beamten des Philippine National Bureau of Investigation (NBI) ermittelt. Die Anklage wurde allerdings fallen gelassen, da es zu diesem Zeitpunkt kein nationales Gesetz gab, das auf die Erstellung und Freisetzung von Viren (und Würmern) angewendet werden konnte. Die Ursachen für den Erfolg dieses Angriffs sind eigentlich die gleichen wie bei Melissa, allerdings kommt noch ein weiterer Fehler hinzu. Dass ein E-Mail-Programm in der Lage ist, Skripte auszuführen, kann hinsichtlich der Sicherheit als Entwurfsfehler in der Betriebssystemsoftware bezeichnet werden. Bemerkenswert ist auch, dass die breite Masse, aber auch die Experten, die es eigentlich hätten besser wissen können, offenbar nichts aus dem Melissa-Vorfall gelernt hat. Offenbar haben die wenigsten die Outlook-Konfiguration so geändert, dass die automatische Verknüpfung zwischen E-Mail-Programm und Anwendung aufgelöst wurde. Die Bequemlichkeit hat in diesem Fall über das Sicherheitsbewusstsein gesiegt.
2.2. Der Hacker Contest
25
Schließlich gibt es eine weitere Parallele: Der Love Letter-Autor hat bei weitem nicht alle Möglichkeiten ausgeschöpft. In einem Artikel der Zeit wird der dänische Viren-Experte Jakob Ostergaard folgendermaßen zitiert [17]: „Wir haben gesehen, wie jemand die Hand am Zünder einer Atombombe hatte – und sich dann mit einer Gummizwille begnügte.“ Der Autor des Artikels schreibt zudem: „Mit entsprechender krimineller Energie hätte man das Virus zu einer verheerenden Waffe machen können.“ Distributed Denial of Service Ein großer Schritt hin zur Zerstörung der Kommunikationsinfrastruktur durch die Anwendung „digitaler Waffen“ wurde erstmals durch die Angriffe Distributed Denial of Service (DDoS) gemacht. Im Februar 2000 wurden renommierte WWW-Anbieter wie etwa Yahoo, CNN und eBay zum Opfer dieser Variante von DDoSAttacken. Dabei wurden längst bekannte Schwächen ausgenutzt, die für andere „normale“ DDoS-Attacken verwendet worden sind. Neuartig war dabei, dass nicht nur ein einzelnes, sondern eine Vielzahl von Systemen für den Angriff verwendet werden. Wie in [79] beschrieben, wurden „hundert bis tausend gleichzeitig angreifende Systeme“, die typischerweise über weite Teile des Internets verteilt (engl. distributed) sind, beobachtet. Dem eigentlichen DDoS-Angriff geht die Installation von Handlern und Agenten voraus. Die Agenten, die von den Handlern kontrolliert werden, sind die Programme, die den eigentlichen Angriff vornehmen. Der Angreifer profitiert von diesem Konzept in mehrfacher Hinsicht. Zunächst kann er vergleichsweise einfach seine Identität verschleiern, da es keine direkte Kommunikation zwischen Opfer und Angreifer gibt. Durch Fälschung der Absenderadresse kann bereits die Bestimmung der Agentensysteme, die am nächsten zum Opfer platziert sind, deutlich erschwert werden. Weiterhin ist es durch die Bündelung der Ressourcen vieler Systeme möglich, Ziele mit großen Reserven und breitbandigen Netzwerkanbindungen zu attackieren. Schließlich ist die Entdeckung von Agenten oder Handlern auf Zwischensystemen weitgehend unproblematisch: Durch die Verteilung der Agenten und Handler auf viele Systeme sind DDoS-Attacken sehr robust gegen Ausfälle dieser Art. Die Yankee Group hat den Schaden, alle Ausgaben mit einberechnet, auf 1,2 Milliarden Dollar beziffert. Soweit bekannt wurde zwar der Autor der Software, die für die Angriffe eingesetzt worden ist, identifiziert, der oder die eigentlichen Täter sind aber (nach unserem Erkenntnisstand) nicht bekannt. Eines der größten Probleme bei DDoS-Angriffen sind die zahlreichen unsicheren Rechner ahnungsloser Dritter. Solange es kein überzeugendes Konzept gibt, bekannte Fehler auf IT-Systemen schnell und systematisch zu beseitigen, wird diese Gefahr bestehen bleiben. Zusammenfassung Die Analyse ausgewählter Angriffe hat gezeigt, dass die Gefahr durch Angriffe aus dem Internet von den Eigentümern von IT-Ressourcen sehr ernst genommen werden muss. Obwohl die technischen Ursachen für die Verletzlichkeiten bekannt sind, wie-
26
2 Grundlagen
derholen sich allerdings die Angriffe immer wieder, ohne dass es offenbar zu einer Verbesserung dieser problematischen Situation kommt. Das Ziel des Hacker Contest ist es nun, das beschriebene Problem in seiner Gesamtheit verstehen zu können. Dies bedeutet, experimentell Einsichten in die Vorgehensweise von Angreifern und den Eigentümern der IT-Ressourcen zu erhalten. Durch Beobachtung der Abläufe können Defizite identifiziert und ergänzende Methoden zur Verbesserung herausgearbeitet werden. 2.2.2 Konzeption Um eine IT-Ressource vor einem Angreifer schützen zu können, reicht die Kenntnis von theoretischen Grundlagen der einzelnen Sicherheitskomponenten (Firewalls, Kryptografie, Passworte etc.) allein nicht aus. Es ist vielmehr notwendig, dass das komplexe Zusammenspiel der einzelnen Sicherheitskomponenten untereinander erkannt und verstanden wird. Die Sicherheit einer Komponente hängt oft direkt von der Verwendung bzw. Sicherheit einer oder mehrerer anderer Komponenten ab. Es gibt aber auch versteckte Abhängigkeiten, die auf den ersten Blick nicht ohne weiteres zu erkennen sind. Solche Abhängigkeiten sind komplex, vielschichtig und abstrakt kaum erfassbar. Insbesondere Laien auf dem Gebiet IT-Sicherheit werden daher zwangsläufig Fehler machen, wenn sie neben dem Tagesgeschäft plötzlich sicherheitsrelevante Aufgaben wahrnehmen müssen. Nach unserer Auffassung lassen sich diese Zusammenhänge einfacher verstehen und erfassen, wenn das Zusammenspiel verschiedener IT-Ressourcen im laufenden Betrieb beobachtet werden kann. Neben den generellen Abhängigkeiten, die die Gesamtsicherheit einer IT-Ressource beeinflussen, ist es ebenfalls notwendig, die Vorgehensweise und das Verhalten eines Angreifers zu kennen. Um eine IT-Ressource effizient schützen zu können, muss der Eigentümer in der Lage sein, die entsprechende IT-Ressource aus der Sicht des Angreifers zu sehen und zu verstehen. Nur so kann er wissen, welche Angriffe zu erwarten und welche Maßnahmen sinnvoll sind. Das primäre Ziel des Hacker Contest war es deshalb, den Teilnehmern den Begriff IT-Sicherheit im Experiment praxisnah und möglichst vielschichtig zu erläutern. Dabei schlüpften die Teilnehmer sowohl in die Rolle der Angreifer als auch in die Rolle von Eigentümern (z.B. vertreten durch Systemadministratoren), die ihre Systeme zu verteidigen hatten. So war es möglich, die jeweiligen Verhaltensmuster und Möglichkeiten besser kennen zu lernen und zu verstehen. Der Ansatz für die Bearbeitung einzelner Themenkomplexe war immer gleich. Zunächst wurde ein konzeptionelles Verständnis für die sicherheitsrelevanten Aspekte der jeweiligen Problemstellung erarbeitet. Dann wurde nach Verletzlichkeiten in den konkret betrachteten IT-Ressourcen gesucht, um danach exemplarisch einige Angriffe durchführen zu können. Schließlich wurden, falls möglich, Maßnahmen erarbeitet, um den jeweiligen Angriff zukünftig zu verhindern oder aber die Auswirkungen wenigstens auf ein Minimum zu beschränken. Ende-zu-Ende-Sicherheit umfasst die Absicherung von Informationen von der Nachrichtenquelle bis zur Nachrichtensenke, d.h. auf allen Ebenen, die durchlaufen
2.2. Der Hacker Contest
27
werden. Um dies zu bewerkstelligen, müsste also der gesamte Kommunikationspfad abgesichert werden, was in der Theorie zwar möglich, aber nicht immer praktikabel ist. Einer der Gründe für dieses Problem ist sicherlich, dass es heute bereits Lösungen für die zahlreichen Teilprobleme gibt, die eine integrierte Lösung (noch) nicht zulassen, weil diese entweder zu teuer für den Eigentümer der IT-Ressource oder zu unkomfortabel für den Benutzer eines Systems sind. So nützt beispielsweise der sicherste SSL-Tunnel oder eine mit PGP verschlüsselte E-Mail nichts, wenn das Zielbzw. das Quellsystem so schwach konfiguriert ist und ein potenzieller Eindringling die Gelegenheit erhält, in Besitz der geheimen Schlüssel zu kommen. Ein Angreifer könnte auch versuchen, die unverschlüsselte Datei auf der Festplatte auszuspähen. Im Hacker Contest haben wir versucht, diese eher ganzheitliche Sichtweise zu vermitteln und zumindest einige wesentliche Ansatzpunkte für die Umsetzung von Sicherheit, wie beispielsweise System- und Netzsicherheit, sowie organisatorische und operative Maßnahmen zu verinnerlichen. Auswahl der Themen Bei der Auswahl der Themen haben wir uns primär an den Ebenen des TCP/IPSchichtenmodells, das in Abbildung 2-4 dargestellt ist, orientiert [125]: – Anwendungen Die Anwendungsschicht umfasst dabei alle Anwendungen und Prozesse, die auf das Netzwerk zugreifen. Sie bildet typischerweise die Schnittstelle zum Benutzer bzw. zu den Endsystemen der Benutzer, in diesem Fall Server und Client. Bei der Betrachtung der Sicherheit spielen diese Systeme ebenfalls eine entscheidende Rolle. – Transport Die Transportschicht stellt Ende-zu-Ende-Datendienste bereit. Dabei bietet das Transmission Control Protocol (TCP) verbindungsorientierte Übertragung mit Fehlererkennung und Korrektur auf dem gesamten Übertragungsweg. Das weniger verwaltungsaufwändige User Datagram Protocol (UDP) bietet dahingegen eine verbindungslose Übertragung. – Internet Die Internetschicht definiert den Aufbau von Datagrammen, d.h. den kleinsten Einheiten für die Übertragung im Internet, und routet Daten. Das Internet-Protokoll (IP) definiert den Transport von Datagrammen, die Internetadressierung und das Routing von Datagrammen zu fremden Rechnern. IP verfügt über keine eigene Fehlerkorrektur. Außerdem wird das Internet Control Message Protocol (ICMP) zur Versendung von Kontrollinformationen bereitgestellt. ICMP wird für Flusskontrolle, Erkennung unerreichbarer Ziele, Änderungen im Routing und Statusabfragen bei fremden Rechnern eingesetzt.
28
2 Grundlagen
– Netzzugang Die Netzzugangsschicht enthält Routinen für den Zugriff auf physikalische Netze. Sie ist für die Übertragung von Daten in einem direkt angeschlossenen Netzwerk zuständig. Es wird definiert, wie ein IP-Datagramm über das Netzwerk transportiert wird. Dabei ist für jeden physikalischen Netzwerkstandard ein eigenes Protokoll notwendig. In dieser Schicht wird dann auch eine Abbildung von IP-Adressen auf physikalische Netzadressen vorgenommen.
Server
Client
Angreifer Anwendungsschicht
Anwendungsschicht
Transportschicht
Transportschicht
Internetschicht
Internetschicht
Netzzugangsschicht
Netzzugangsschicht
Abb. 2-4 Angriffspunkte im TCP/IP-Schichtenmodell
Die Herangehensweise, Sicherheit in einem Schichtenmodell zu betrachten, ist insbesondere dann sinnvoll, wenn unterschiedliche Kategorien von Angriffen, die auf immer höheren Abstraktionsebenen stattfinden, in Betracht gezogen werden: physikalische, syntaktische und semantische Angriffe [71]: – Physikalische Angriffe Sie beziehen sich im weiteren Sinn auf Elemente in der Netzzugangsschicht eines Netzes, z.B. Verbindungskabel und Switches. Außerdem werden Ziele wie etwa Stromnetze, Wasser- und Gasleitungen oder Telefonanlagen angegriffen. – Syntaktische Angriffe Diese Angriffe beeinflussen die Ablauflogik eines Protokolls oder IT-Systems. Dazu gehören einige Denial-of-Service-Angriffe, aber auch Trojaner und Viren. Syntaktische Angriffe finden typischerweise auf höheren Schichten statt, d.h. Internet-, Transport- oder Anwendungsschicht.
2.2. Der Hacker Contest
29
– Semantische Angriffe Hier nutzt der Angreifer das Vertrauen aus, das Benutzer in ihre Systeme haben. Ohne Wissen des Benutzers werden falsche Informationen in ein System eingeschleust, um Fehler herbeizuführen. Diese Angriffe finden in der Regel auf der Anwendungsebene oder sogar außerhalb der Systeme statt (Social Engineering). Mithilfe dieses Ansatzes kann erarbeitet werden, wie ein Verteidigungskonzept der eigenen IT-Ressourcen gestaltet werden muss, d.h., wie Schutzziele formuliert und organisatorisch bzw. technisch umgesetzt werden. Die Themen des Hacker Contest setzen sich aus Grundlagen und fortgeschrittenen Gebieten zusammen. Zu den Grundlagen gehört beispielsweise immer die Absicherung von IT-Systemen, da bereits bei deren Installation und Inbetriebnahme die Grundlage für sichere Informationsverarbeitung gelegt wird. Zudem wurden auch die Konfigurationen der Netze und Dienste berücksichtigt. Zusätzlich wurden immer aktuelle Themenstellungen, wie beispielsweise Distributed-Denial-of-ServiceAngriffe oder Makro-Viren, aufgegriffen. Naturgemäß kann der Hacker Contest den Bereich der IT-Sicherheit nicht vollständig abdecken. Es ist aber sehr wohl möglich, die unterschiedlichen Themen in einen größeren Kontext einzuordnen und die Zusammenhänge zu erkennen. Dieser Ansatz bildet auch die Basis für die Auswahl der Themen dieses Buchs. Aufbau und Durchführung Um einen kontrollierten Ablauf des Hacker Contest gewährleisten zu können und auch um den Vorwurf der Fahrlässigkeit zu entkräften, wurden entsprechende Vorsichtsmaßnahmen getroffen. Die verschiedenen Netzwerksegmente der teilnehmenden Gruppen wurden durch eine Firewall vom Internet abgeschirmt. In Abbildung 2-5 ist die Netzwerktopologie des Labors schematisch dargestellt. Sie entspricht einem in der Praxis oft eingesetzten Screened Subnet [140]. Dabei wird der gesamte Netzwerkverkehr mithilfe eines Packetfilters kontrolliert. Vorteile dieser Variante sind der günstige Preis, da physikalisch nur ein Router mit Filterfunktionalität benötigt wird, sowie der minimale Einfluss auf den Datendurchsatz. Als Nachteil erweist sich, dass ein Packetfilter nicht in der Lage ist, auf Anwendungs- bzw. Benutzerebene zu filtern. Im Rahmen unseres Experiments hat sich dies allerdings auch als nicht notwendig erwiesen. Der eingesetzte Packetfilter ließ nach außen, also Verbindungen von den internen Netzen zum Internet, lediglich die Protokolle HTTP, FTP und DNS zu. Von außen nach innen war der Zugriff nur über SSH erlaubt. Durch diese restriktive Maßnahme war es möglich, die Auswirkungen von ggf. außer Kontrolle geratenen Angriffen auf die internen Netze zu beschränken. Um die Zielsetzung der Praxisnähe zu gewährleisten, wurde ein breites Spektrum von typischerweise in Unternehmen eingesetzten Betriebssystemen untersucht. So kamen z.B. aktuelle Versionen der Solaris-Betriebssysteme von Sun Microsystems sowie aktuelle Linux-Distributionen von Debian, Redhat und SuSE zum Einsatz.
30
2 Grundlagen
Darüber hinaus standen auch BSD-basierte Unix-Betriebssysteme zur Verfügung, wie etwa das als besonders sicher geltende OpenBSD und das ebenfalls kostenfreie FreeBSD. Als professionelle Microsoft-Betriebssysteme kamen Windows NT 4.0 (Server und Workstation) sowie dessen Nachfolger Windows 2000/XP zum Einsatz. Die Teilnehmer hatte nun u.a. die Aufgabe, in Gruppen bestimmte Dienste, wie beispielsweise HTTP und FTP, in ihrem Segment anderen Gruppen (also nach „außen“) zur Verfügung zu stellen. Sie wurden so zum Eigentümer und Betreiber von IT-Ressourcen. Die weiteren Aufgaben waren nun, die Rechner im Netzwerk der jeweils anderen Gruppe zu attackieren, aber auch die eigenen Rechner vor unbefugten Zugriffen zu schützen.
Internet
Router/ Filter
Netzwerk B Netzwerk A
Abb. 2-5 Netzwerktopologie des Hacker Contest
Da die Aufgaben in der Regel für die Teilnehmer völlig neu waren, mussten sie sich zunächst eine Vielzahl von praktischen Informationen beschaffen und Hindernisse, wie sie z.B. bei der Installation von Systemen und Diensten üblich sind, überwinden. Viele der Probleme konnten gelöst werden, indem zum einen im Internet recherchiert wurde, welche Verletzlichkeiten die Systeme aufweisen, wie man sie als Angreifer nutzen und schließlich wie man sich dagegen schützen kann. Zum anderen waren aber auch kreative Lösungen möglich. Zwischen den Gruppen entstand im positiven Sinn ein Wettbewerbscharakter, der die Teilnehmer in ungewöhnlicher Weise motivierte.
2.2. Der Hacker Contest
31
Auf dieser Basis wurden geeignete Angriffsszenarien entwickelt und tatsächlich durchgeführt. Die auf diese Weise gewonnenen Erkenntnisse wurden wiederum genutzt, um geeignete Gegenmaßnahmen zu entwickeln und Schritt für Schritt auch praktisch umzusetzen. Erste Ergebnisse Das häufigste Gegenargument, das sowohl während der Planungsphase als auch bei der Durchführung des Experiments „Hacker Contest“ angeführt worden war, lautete, dass es gefährlich sei, wenn die Teilnehmer gewissermaßen zum „Cracker“ ausgebildet würden und diese eventuell Gefallen an dieser Art der Computernutzung finden könnten. Sicherlich erhielten die Teilnehmer durch diese Form der Ausbildung einen tiefen Einblick in die Welt des „Hackens“ bzw. „Crackens“. Nach unserer Ansicht ist aber genau dies zwingend notwendig, um sich in der Praxis effektiv gegen Angriffe schützen zu können. Wir denken weiterhin, dass auch durch das Aufzeigen der rechtlichen Konsequenzen sowie die Erkenntnis, dass ein Angriff auch nachweisbare Spuren hinterlässt, auf ein verantwortungsvolles Umgehen mit dem erworbenen Wissen hingearbeitet worden ist. Ein weiterer problematischer Punkt war der Zeitaufwand, den eine solche Veranstaltung mit sich bringt. Die Teilnehmer hatten die Aufgabe, ihre Rechner selbst zu installieren, zu konfigurieren und dann ein Netzwerk aufzubauen und diese ITRessourcen schließlich auch zu betreiben. Da nicht erwartet werden konnte, dass die Teilnehmer mehrere verschiedenartige Betriebssysteme gleichermaßen gut beherrschen, war teilweise ein hoher Einarbeitungs- und Betreuungsaufwand nötig. Die nach dem Aufbau des Netzes nötige Recherche und vor allem die Durchführung der Angriffe hatte sich ebenfalls als äußerst zeitaufwändig erwiesen. Dennoch hat sich gezeigt, dass die Teilnehmer aufgrund der interessanten Thematik und des neuartigen Konzeptes bereit waren, sehr viel mehr Zeit aufzuwenden, als dies für herkömmliche Veranstaltungen zur Aus- und Weiterbildung notwendig gewesen wäre. Es konnte ein Bewusstsein für die Gefahren bei der Nutzung von Diensten in öffentlichen Netzen geschaffen werden. Da die Teilnehmer beispielsweise mit eigenen Augen gesehen haben, dass ihr Passwort bei unterschiedlichen Protokollen (wie etwa POP3, Telnet oder FTP) unverschlüsselt übertragen wird, wissen sie nun, dass es auch sichere Alternativen gibt, die bei Bedarf eingesetzt werden können. Der Hacker Contest erwies sich so als gute Ergänzung zu theoretischen Grundlagen, die beispielsweise in Büchern oder im Rahmen von Vorlesungen an einer Universität vermittelt werden. Aufgrund der positiven Erfahrungen mit dem Hacker Contest könnte grundsätzlich auch innerhalb von Unternehmen darüber nachgedacht werden, vergleichbare Konzepte anzubieten, um so weiter zur praxisnahen Aus- und Weiterbildung von IT-Sicherheitsexperten und IT-Anwendern beizutragen. Dies könnte ein wichtiger Baustein im Rahmen eines übergeordneten Sicherheitsprozesses sein, um aus den Fehlern der Vergangenheit zu lernen.
32
2 Grundlagen
Zum Zeitpunkt der Erstellung des Manuskriptes für dieses Buch lagen mehr als 500 Seiten Dokumentation vor, die einen Überblick über die unterschiedlichen Möglichkeiten, die Angreifern zur Verfügung stehen, geben. Diese Berichte beleuchten diverse Verletzlichkeiten der unterschiedlichen Betriebssysteme, Netzkomponenten und Dienste. Weiterhin werden, falls möglich, Gegenmaßnahmen aufgezeigt. Teile dieser Dokumentation bilden die Basis für dieses Buch. Analyse und Erkenntnisse IT-Sicherheit ist ein außerordentlich vielschichtiges und komplexes Gebiet. Mithilfe des Hacker Contest konnten wir einige der Probleme der realen Welt im Experiment nachstellen und so bei der Analyse wichtige Erkenntnisse gewinnen: – Informationsflut Für Einsteiger erscheint die Flut an notwendigem Hintergrundwissen, die erarbeitet werden muss, um selbst kleinere Probleme zu lösen, zunächst nicht überschaubar. Menschen neigen in solchen Situationen dazu, die anscheinend nächstliegende Lösung zu wählen, und übersehen dabei mögliche negative Fern- und Nebenwirkungen. Dabei ist es keineswegs damit getan, sich auf Produkte zu verlassen, die Sicherheit gewissermaßen „von der Stange“ versprechen. ITSicherheit muss in allen Bereichen und rund um die Uhr verstanden und gelebt werden. Um nochmals Bruce Schneier zu zitieren: „Sicherheit ist ein Prozess.“ [101] Ein Ziel dieses Buches ist es, ein Konzept zu vermitteln, um den Menschen bei diesem komplexen Prozess zu unterstützen. Dabei traten allerdings weitere Probleme auf, die wir im Folgenden kurz ansprechen werden. – Fehlende/Unterschiedliche Struktur Bei der Sichtung der schriftlichen Ergebnisse des Hacker Contest fiel auf, dass eines der größten Probleme bei der Dokumentation von Wissen im Bereich der IT-Sicherheit eine fehlende oder uneinheitliche Struktur der Information zu erkennen ist. Wenn verschiedene Bücher oder Artikel zu einem bestimmten Thema verglichen werden, stellt sich zunächst heraus, dass typischerweise keine vergleichbare Herangehensweise der Autoren erwartet werden kann. Genau dies wäre aber für den Leser wünschenswert, um Probleme besser einordnen und bewerten zu können. Außerdem sind solche Dokumente oft auf unterschiedlichen Abstraktionsniveaus und weisen einen unterschiedlichen Grad an Komplexität auf. Weiterhin werden oftmals Wechselwirkungen und Beziehungen zu anderen Problemen nicht hinreichend aufgezeigt. Genau dieses Problem hat sich auch bei der Dokumentation des Hacker Contest ergeben. Trotz der Vorgabe einer einheitlichen Format- und Strukturvorlage hat sich gezeigt, dass die verschiedenen Dokumente, an denen mehr als 40 Autoren mitgewirkt haben, zwar inhaltlich korrekt, aber hinsichtlich der beschriebenen Probleme nicht optimal sind.
2.2. Der Hacker Contest
33
Eine geeignete Dokumentation sollte das Wissen systematisch erfassen. Außerdem muss darauf geachtet werden, dass keine wichtigen Elemente verloren gehen oder überstrapaziert werden. Im Nachhinein als wichtig erkannte Probleme sollten zudem leicht hinzuzufügen sein. – Anwendbarkeit Neben der Frage, wie Wissen auf dem Gebiet IT-Sicherheit vermittelt werden kann, bleibt noch offen, wie diese Dokumentation benutzt bzw. effizient angewendet werden kann. Dem Leser wird es u.U. nicht viel nutzen, wenn er erst ein ganzes Buch lesen muss, um Lösungen für sein konkretes Problem zu finden und zu verstehen. Daraus folgt, dass ein systematischer Ansatz zur Dokumentation von praktisch anwendbarem Wissen im Bereich IT-Sicherheit wünschenswert ist. Diese Methode muss zudem Fern- und Nebenwirkungen geeignet berücksichtigen. In Abschnitt 2.3 stellen wir ein solches Konzept vor: Security Patterns. Zunächst wollen wir aber die Erkenntnisse aus dem Hacker Contest verallgemeinern und zurück auf die ITSicherheit in der realen Welt übertragen. 2.2.3 IT-Sicherheit und der Faktor Mensch Der unserer Ansicht nach wichtigste Grund für die beschriebenen Probleme ist, dass IT-Sicherheit nur auf den ersten Blick ein rein technisches Problem ist. Im Zentrum des Handelns bei der IT-Sicherheit steht immer der Mensch und insbesondere der Eigentümer der zu schützenden IT-Ressourcen. Im Folgenden beschreiben wir, welchen bedeutenden Einfluss der Faktor Mensch auf die IT-Sicherheit hat. Dabei wird deutlich werden, dass die verschiedenen beschriebenen Aspekte nicht isoliert gesehen werden können, da sie einander teilweise bedingen. IT-Sicherheit ohne Expertenwissen Das Gebiet der IT-Sicherheit ist, mit Ausnahme der Kryptografie, ein vergleichsweise neues Gebiet der Wissenschaft. Zudem weist die IT-Sicherheit mehrere verschiedene Ebenen auf, wie beispielsweise Betriebssysteme, Kommunikationsnetze, Datenbanken und Software Engineering. Daher ist es sehr schwierig, eine moderne IT-Ressource sicher zu machen: Es sind viele verschiedene Komponenten und Mechanismen einbezogen. Außerdem ändern sich Vertrauensbeziehungen in Netzwerken oft, so dass eine umfassende Analyse der Sicherheitsanforderungen eine allenfalls begrenzte Gültigkeit haben kann. Ein beträchtliches Maß an Expertenwissen ist nötig, um sichere Systeme zu konzipieren, zu entwickeln und zu betreiben. Dieses Wissen ist zwar im Allgemeinen bekannt, aber in der Regel nur auf wenigen Schultern verteilt bzw. schwer zugänglich. Ein Grund mag in der kommerziellen Seite der IT-Sicherheitsberatung liegen. Andererseits würde mancher Spezialist wohl über das eine oder andere Sicherheitsproblem reden, oftmals sind ihnen jedoch die Hände gebunden, da sie in der Regel
34
2 Grundlagen
einer Geheimhaltungspflicht unterliegen. Darüber hinaus spielen wirtschaftliche und politische Faktoren eine Rolle, wie das Beispiel der GSM-Verschlüsselung (Global System for Mobile Communication) zeigt, die auch auf Initiative des britischen Geheimdienstes abgeschwächt und damit die Sicherheitsfunktionalität dieses Systems herabgesetzt wurde. Zudem werden oftmals Mitarbeiter von IT-Abteilungen mit sicherheitsrelevanten Aufgaben betraut, ohne entsprechend ausgebildet zu sein. In gewisser Weise wird IT-Sicherheit – wenn überhaupt – lediglich als Zusatzeigenschaft betrachtet. Neben der reinen Funktionalität des Systems wird vielmehr Wert darauf gelegt, dass Systemeigenschaften wie z.B. Performance, Benutzbarkeit und Verfügbarkeit gewährleistet werden. Da beim Personal oft gespart werden muss, wird Sicherheit nicht mit der richtigen Priorität behandelt. So beschäftigen sich Laien mit dem Thema ITSicherheit, und es kommt unweigerlich zu Fehlern. Strukturierte Lösung von Problemen Wenn Menschen versuchen, ein Problem zu lösen, verfolgen sie oftmals Ad-hocLösungen, d.h., der naheliegendste Weg wird gewählt. Es wird ohne über die akute Situation hinauszudenken und ohne ein Problem im Kontext von anderen Problemen zu betrachten an Lösungen gearbeitet. Der Einfluss von Fern- und Nebenwirkungen wird in den meisten Fällen übersehen [41]. Ein einfaches Beispiel für dieses Phänomen ist der Umgang mit Systempasswörtern. Ein Systemadministrator versucht zu verhindern, dass die Benutzer schwache Passwörter wählen und die Systeme damit verletzbar machen. Er konfiguriert die Systeme so, dass starke Passwörter erzwungen werden, d.h., ein Benutzer kann kein Passwort wählen, das nicht bestimmten Kriterien genügt. So darf ein Passwort beispielsweise nicht in einem Wörterbuch zu finden sein, da es sonst leicht durch einen Wörterbuchangriff geknackt werden kann. Dieser Lösungsansatz erscheint auf den ersten Blick nachvollziehbar und richtig. Allerdings wurde nicht berücksichtigt, dass sich jetzt kein Benutzer diese starken Passwörter merken kann. Eine Konsequenz könnte sein, dass die Benutzer sich ihre Passwörter auf einem Stück Papier notieren, das dann von einem Angreifer, der physikalischen Zugang zu dem System hat, unter der Tastatur oder – noch schlimmer – am Monitor befestigt gefunden werden kann. Falsche Annahmen Am Anfang der Konzeption eines jeden IT-Systems stehen bestimmte Annahmen über dessen Parameter und dessen Umgebung. Die Gesamtmenge der Annahmen bilden das Realitätsmodell, das oftmals nicht explizit vorliegt [41]. Das Modell kann richtig oder falsch sein, vollständig oder unvollständig. Viele Menschen streben allerdings nach Harmonie und Sicherheit, so dass falsche und unvollständige Annahmen oftmals nicht kritisch hinterfragt werden. Dies führt letzten Endes zu einem nicht gerechtfertigten Vertrauen in die Technik und gaukelt ein falsches Gefühl von Sicherheit vor.
2.2. Der Hacker Contest
35
So geht beispielsweise ein Entwickler, ohne sich selbst darüber im Klaren zu sein, davon aus, dass eine temporär erzeugte Datei nur von der Anwendung selbst benutzt wird. Tatsächlich werden solche Dateien oftmals in Verzeichnissen erzeugt, die von jedem gelesen und geschrieben werden können. Wenn zudem noch der Name der temporären Dateien geraten werden kann, so ist es für einen Angreifer möglich, gezielt Dateien zu platzieren und entsprechende Race Conditions auszunutzen. So sichert sich etwa ein Programm eine Ressource (z.B. eine temporäre Datei), schützt sie aber nicht gegen Missbrauch. Ein zweites, von einem Angreifer gestartetes Programm kann sich dann zum richtigen Zeitpunkt dieser Ressource bedienen und diese missbrauchen. Ein anderes Beispiel sind Annahmen über die Laufzeitumgebung eines Programms. Obwohl die meisten Programme heute auf den gängigsten Plattformen installiert werden können, treten unter bestimmten Umständen unvorhergesehene Verhaltensweisen auf. Ein Programm könnte so z.B. Zugriff auf Funktionalitäten haben, die nicht beabsichtigt waren. So könnte beispielsweise ein Entwickler fälschlicherweise voraussetzen, dass ein bestimmtes Objekt immer unter einem bestimmten Namen angesprochen werden kann oder dass immer genügend Speicher zur Verfügung steht. IT-Sicherheit und Komplexität IT-Sicherheit ist ein sehr komplexes Gebiet mit vielfältigen Abhängigkeiten. Selbst wenn die wichtigsten Abhängigkeiten identifiziert worden sind, kann es schwierig werden, sie alle angemessen zu berücksichtigen. Bezogen auf IT-Ressourcen sind dies beispielsweise die Anzahl der Quelltextzeilen, Anzahl der Module, Konfigurationsparameter, Software-Versionen, Kombination von Komponenten etc. So kann beispielsweise der Administrator eines Web-Servers gut beurteilen, ob die von ihm eingesetzte Software sicher ist. Er liest regelmäßig alle Mailing-Listen, die sein Produkt betreffen, und spielt immer Patches ein, sobald dies notwendig ist. Möglicherweise kann er aber nicht sagen, ob die Kombination aus Web-Server, Betriebssystem und Hardware-Komponenten sicher ist – ganz zu schweigen von den Wechselwirkungen, die sich aus anderen Software-Paketen ergeben. Es kann nämlich durchaus sein, dass eine Schwachstelle nur im Zusammenhang mit einem anderen Programm auftritt oder aber durch einen Fehler in dieser Komponente verursacht wird. Die IT-Ressource und ihre Laufzeitumgebung sind zu komplex, um als Ganzes betrachtet werden zu können. Um also die Sicherheit eines Systems gewährleisten zu können, müssen all diese Merkmale berücksichtigt werden. Darüber hinaus ist es notwendig, nicht nur die Merkmale einzelner IT-Ressourcen und deren Komponenten zu betrachten. Es muss vielmehr berücksichtigt werden, dass die verschiedenen Komponenten einer ITRessource (und damit auch deren Einzelmerkmale) nicht unabhängig voneinander existieren, sondern sich gegenseitig beeinflussen. Wer in einer derartigen Welt von interagierenden Teilsystemen Sicherheit erreichen will, muss auch in interagierenden Teilsystemen denken.
36
2 Grundlagen
Der Trend zur zunehmenden Komplexität in IT-Systemen lässt sich beispielsweise an der Entwicklung des Linux-Kernels zeigen. Im Zeitraum von 4,5 Jahren wurden alle drei Monate die aktuellen Versionen des Linux-Kernels untersucht [8]. Tabelle 2-2 zeigt die entsprechenden Ergebnisse dieses Linux-Benchmarks. Dargestellt werden die Quelltextzeilen des reinen Kernels, d.h. ohne Subsysteme wie z.B. Treiber, Dateisysteme etc. Der Rückgang der Anzahl ab dem Kernel 2.1.1 ist darauf zurückzuführen, dass die 2.1.x-Kernel keine offiziellen Freigaben, sondern Entwicklungsversionen sind. Dennoch entspricht der Trend einer exponentiellen Wachstumsrate. Besonders bemerkenswert ist, dass die Größe des gesamten Kernels (also inklusive der Subsysteme) um 319 % gestiegen ist. Der größte Anstieg ist in dem Treiber-Subsystem auszumachen: 348 %. Tab. 2-2 Quelltextzeilen des Linux-Kernels ohne Subsysteme
Version
Datum
Quelltextzeilen
2.0.1
7/1996
8.001
2.1.1
10/1996
6.953
2.1.14
12/1996
6.984
2.1.32
4/1997
8.001
2.1.44
7/1997
7.972
2.1.58
10/1997
7.958
2.1.77
1/1998
8.854
2.1.92
4/1998
9.224
2.1.108
7/1998
9.659
2.1.124
10/1998
9.812
2.2.6
4/1999
10.143
2.3.10
7/1999
10.477
2.3.20
10/1999
11.483
2.3.38
1/2000
11.013
2.4.0
1/2001
13.086
Zeitabhängigkeiten IT-Sicherheit als Zustand des Unbedrohtseins ist in hohem Maße zeitabhängig. Eine IT-Ressource, die heute als sicher angesehen wird, kann morgen unsicher sein. ITRessourcen, die typischerweise in ein Netzwerk integriert sind, sind ständigen Änderungen unterworfen. Sowohl die IT-Ressourcen, das System als auch dessen Umfeld entwickeln sich weiter. Aussagen, die die IT-Sicherheit betreffen, sind daher nur dann sinnvoll, wenn ein Bezug zur Zeit hergestellt werden kann.
2.2. Der Hacker Contest
37
Außerdem erzwingen Marktanforderungen immer schnellere Entwicklungszyklen, so dass bei der Erarbeitung von Lösungen Zeitdruck entsteht. Dies führt dazu, dass nicht alle Informationen berücksichtigt werden können. Eine umfassende und vollständige Analyse steht allerdings im Widerspruch zu dem Zwang des schnellen Handelns. Obwohl die Erfassung zeitlicher Tendenzen sehr wichtig ist, ist es für Menschen nicht immer leicht, die Trends, denen das Gesamtgebilde unterworfen ist, zu erkennen und angemessen zu berücksichtigen. Für die Sicherheit ist dies mehr als fatal, da eigentlich nur Experten, die genau wissen, welche Auswirkungen ihr Handeln auf die Sicherheit haben kann, angemessen reagieren können. Allerdings wird Sicherheit immer noch oftmals nur als „Add-on“ oder sogar als Bremse betrachtet und deshalb vernachlässigt bzw. oft nur im Bedarfsfall notdürftig nachgebessert. Dies erweist sich allerdings als schwierig, wenn nicht sogar unmöglich (von den Kosten einer solchen Nachbesserung ganz zu schweigen). Ein Beispiel für Zeitabhängigkeiten sind kryptografische Algorithmen, deren Stärke auf sehr schwierigen mathematischen Problemen basiert. Wenn ein Genie eine Lösung für solch ein Problem findet, ist der jeweilige Algorithmus nicht mehr sicher. So hängt beispielsweise die Sicherheit des asymmetrischen RSA-Verschlüsselungsverfahrens davon ab, dass es mit der heute verfügbaren Rechenleistung – selbst wenn alle Rechner weltweit zusammengeschaltet würden – sehr zeitaufwändig ist, die Primfaktoren von sehr großen Zahlen zu finden. Bei hinreichend großer Schlüssellänge würde es länger als das Alter des Universums dauern, eine Nachricht durch Ausprobieren aller möglichen Schlüssel (Brute-Force-Angriff) zu entschlüsseln. Solange es keinen mathematischen Durchbruch gibt, gilt RSA demnach als sicher. Da es nach heutigem Erkenntnisstand nicht danach aussieht, suchen die Forscher nach einer technologischen Lösung: dem Quanten-Computer. Ein solches System wäre dann so unglaublich schnell, dass mit RSA verschlüsselte Nachrichten in angemessener Zeit geknackt werden könnten. Warum ein zeitlicher Bezug so wichtig ist, zeigen zudem die zeitlichen Eigenschaften von Verletzlichkeiten (siehe z.B. [101]). Obwohl es trivial klingt, existieren Verletzlichkeiten von Anfang an, d.h., bereits bevor sie entdeckt worden sind. Nach der Entdeckung (z.B. durch einen Hacker oder Wissenschaftler) beginnt der Wettlauf gegen die Zeit. In dieser Phase wissen nur wenige Leute etwas von der Verletzlichkeit, und es sind noch keine Gegenmaßnahmen bekannt. Je nachdem, wer die Verletzlichkeit entdeckt hat, verbreiten sich die Neuigkeiten mehr oder weniger schnell. Eine öffentliche Bekanntgabe, z.B. in einer Newsgroup oder einer Mailing-Liste, erhöht die Zahl der Personen deutlich, die etwas über die Verletzlichkeit wissen. Wenn es Anleitungen und Skripte gibt, mit denen die Verletzlichkeit ausgenutzt werden kann (Exploits), können diese in öffentlich zugängliche Angriffsprogramme integriert werden. Nun ist es auch Personen, denen der technische Hintergrund fehlt, möglich, die Verletzlichkeit auszunutzen. Das Risiko sinkt allmählich, sobald Workarounds und Gegenmaßnahmen entwickelt, publiziert und von den Anwendern umgesetzt werden. Hersteller geben so beispielsweise, je nach Brisanz der Verletzlichkeit, Patches oder Upgrades heraus. Da viele Leute regelmäßigen Nachbesserungen ihrer Systeme wenig Aufmerksamkeit entgegenbringen, bleibt ein gewisses Restrisiko allerdings bestehen, zumindest solange die betroffenen Systeme noch in Betrieb sind.
38
2 Grundlagen
2.2.4 Zusammenfassung Die Beobachtung der experimentellen Abläufe zwischen Angreifern und Eigentümern der IT-Ressourcen hat gezeigt, dass es auf Seite der Eigentümer einige Defizite gibt. Im Rahmen des Hacker Contest war dies im Wesentlichen die Flut an Informationen, die verarbeitet werden musste, um sich zunächst in einen Themenkomplex einzuarbeiten und dann die richtigen Entscheidungen treffen zu können. Ein Teilproblem dabei ist, dass die unterschiedlichen Informationsquellen inhomogen hinsichtlich Qualität und Quantität sind. So ist beispielsweise eine Antwort in einem FAQ-(Frequently Asked Questions-)Dokument in der Regel zwar von hoher Qualität, allerdings reicht die Information für einen Laien oft nicht aus. Umgekehrt gibt es auch WWW-Seiten, die zwar viel Inhalt bieten, allerdings eine eher geringe Qualität aufweisen (wie beispielsweise „White Papers“, bei denen es oft nur darum geht, die Vorzüge eines Produktes hervorzuheben). Ein letztes Problem war schließlich die Übertragbarkeit und damit die Anwendbarkeit von Informationen. Insbesondere für Laien muss die Information genügend Details enthalten, damit die richtigen Maßnahmen gewählt und ausgeführt werden können. Diese im Experiment aufgetretenen Probleme lassen sich auf die reale IT-Welt übertragen bzw. können entsprechend ergänzt werden. Im Zentrum steht dabei immer der Mensch, der mit der Aufgabe betraut wird, eine IT-Ressource vor Angriffen zu schützen. Es kann davon ausgegangen werden, dass jeder, der kein Sicherheitsexperte ist, auf ähnliche Probleme stößt, wie wir sie im Hacker Contest beobachtet haben. Dazu gehören insbesondere Ad-hoc-Lösungen, die mehr Probleme schaffen können, als sie lösen, sowie die Zeitabhängigkeit von IT-Ressourcen und deren Umgebung, die richtige Entscheidungen stark erschweren können. Problematisch ist auch die Einstellung, Fehler bewusst in Kauf zu nehmen und erst zu beheben, wenn sie (oftmals zufällig) entdeckt werden.
2.3 Security Patterns Da wir immer wieder Angriffe, die auf grundsätzlich bekannten Fehlern beruhen, beobachten können, reichen die verfügbaren Methoden und Werkzeuge zum Schutz von IT-Ressourcen offenbar nicht aus. Wir sind immer noch weit davon entfernt, die Sicherheit von IT-Ressourcen in den Maßstäben zu gewährleisten, wie sie in anderen Branchen längst üblich sind. Wir glauben daher, dass nur erfahrene Experten zuverlässig Sicherheitsanforderungen analysieren, Verletzlichkeiten aufdecken und IT-Ressourcen mit „guter“ Sicherheit entwerfen und betreiben können. Design Patterns (auch bekannt als Entwurfsmuster), die bisher hauptsächlich beim objektorientierten Software-Entwurf eingesetzt wurden, stellen eine Möglichkeit dar, dieses Problem zu lösen. Sie sind ein Konzept, um immer wieder auftretende Probleme sowie bewährte Lösungen systematisch zu dokumentieren. In strukturierter Form wird schriftlich festgehalten, in welchem Kontext das Problem auftritt, welche Anforderungen (engl. Forces) zu beachten sind und welche Lösungen sich
2.3. Security Patterns
39
dafür anbieten. Da Patterns von Experten geschrieben und diskutiert werden, können Laien von deren Wissen und Expertise profitieren. Daher bietet es sich an, diesen Ansatz auf den Problembereich Sicherheit zu übertragen und bestehende Werkzeuge und Prozesse auf diese Weise sinnvoll zu ergänzen. Unter Security Engineering verstehen wir grundsätzlich die Planung und Umsetzung von IT-Sicherheit als Ingenieurdisziplin [109]. Gerade in diesem Bereich klafft eine große Lücke zwischen Theorie und Praxis hinsichtlich der Werkzeuge und Methoden. Während Wissenschaftler an formalen Ansätzen arbeiten, müssen Praktiker primär die Forderungen ihrer Kunden erfüllen und können daher nicht immer so vorgehen, wie es theoretisch erstrebenswert wäre. In diesem Abschnitt betrachten wir zunächst, welche Mittel dem Eigentümer von IT-Ressourcen typischerweise zur Verfügung stehen, um die richtigen Schutzmaßnahmen auszuwählen und umzusetzen. Wir zeigen Vor- und Nachteile dieser Methoden auf. So können wir zeigen, dass es hier bestimmte Defizite gibt, die mit Security Patterns adressiert werden können. Danach stellen wir das Konzept der Security Patterns im Detail vor. 2.3.1 Methoden und Werkzeuge Edward Amoroso definiert System Security Engineering als Verfahren, um zu einer optimalen Sicherheitslösung zu kommen [5], die auf der Identifikation aller sicherheitsrelevanten Faktoren und Probleme beruht. Zustand des Bedrohtseins
Spezifikation
Gegenmaßnahmen
Identifikation von Bedrohungen, Verletzlichkeiten und Angriffen
Priorisierung
Bestimmung des Risikos
Risiko vertretbar
Abb. 2-6 System Security Engineering
Ziel dabei ist es, von einem Zustand des Bedrohtseins zu einem Zustand zu kommen, in dem die Risiken akzeptabel sind, d.h., eine IT-Ressource gilt als ausreichend geschützt. Wie in Abbildung 2-6 gezeigt, müssen auf diesem Weg möglicherweise in mehreren Iterationen folgende Schritte durchlaufen werden:
40
2 Grundlagen
– Spezifikation Alle kritischen Komponenten einer IT-Ressource müssen in diesem Schritt möglichst vollständig erfasst werden. – Identifikation von Bedrohungen, Verletzlichkeiten und Angriffen Für jede Komponente müssen nun die grundsätzlichen Bedrohungen ermittelt werden. Daraus lassen sich Rückschlüsse über mögliche Verletzlichkeiten sowie die zu erwartenden Angriffe treffen. – Bestimmung des Risikos Für alle Komponenten muss nun das Risiko für einen Angriff bestimmt werden. In diese Berechnung fließen die Erkenntnisse aus den vorangegangenen Schritten ein. – Priorisierung Erweisen sich bestimmte Risiken als zu hoch, müssen die entsprechenden Verletzlichkeiten priorisiert werden. Verletzlichkeiten in besonders kritischen Komponenten erhalten eine hohe Priorität. Dieser Schritt ist besonders wichtig, um eine sinnvolle Reihenfolge für die Umsetzung von Schutzmaßnahmen zu erhalten. – Gegenmaßnahmen Gegenmaßnahmen, die die identifizierten Bedrohungen, Verletzlichkeiten und Angriffe verhindern oder deren Auswirkungen auf ein Minimum reduzieren, müssen nun ausgewählt und umgesetzt werden. Dabei sind die Anforderungen des Eigentümers zu berücksichtigen (Kosten, Benutzbarkeit etc.). Diese Schritte werden grundsätzlich so lange wiederholt, bis die Schutzmaßnahmen zu einem vertretbaren Risiko geführt haben. In den vergangenen Jahren haben sich einige Werkzeuge und Methoden etabliert, die in Unternehmen angewendet werden, mit denen diese Schritte durchgeführt werden können. Sie unterscheiden sich in verschiedenen Merkmalen. Zum einen weisen sie eine unterschiedliche Granularität auf, decken also verschiedene Abstraktionsebenen ab. Weiterhin unterscheiden sich die Methoden hinsichtlich des Aufwands für die Durchführung und den damit verbundenen Kosten. Schließlich gibt es auch strukturelle Unterschiede, d.h., die Methoden sind formal, semiformal oder informal. Die Ausprägung dieser Merkmale wirkt sich unmittelbar auf die Anwendbarkeit und die Benutzbarkeit der Methoden aus. Im Folgenden beschreiben wir einige ausgewählte Methoden und Werkzeuge. Zusammenfassend zeigen wir dabei auch, wie die Aspekte benötigtes Hintergrundwissen, strukturiertes Problemlösen, falsche bzw. unvollständige Annahmen und Zeitabhängigkeiten (siehe Abschnitt 2.2.3) jeweils adressiert werden.
2.3. Security Patterns
41
Security Policy Zumindest in der Theorie sollte am Anfang jeder Aktivität im Bereich IT-Sicherheit die Erstellung einer Security Policy stehen [140]. Sie ist ein zentraler Bestandteil des System Security Engineering. Allgemein gesprochen beschreiben Security Policies, wie Informationen in einer Organisationseinheit verwendet werden. Für IT-Ressourcen bedeutet dies, dass zunächst die zu schützenden Objekte und Werte identifiziert werden. Dann werden potenzielle Bedrohungen, die die Werte betreffen, ermittelt. Weiterhin werden das angestrebte Sicherheitsniveau und damit die Anforderungen an eine IT-Ressource und deren Umgebung festgelegt. In weiteren Schritten wird diese Security Policy auf die entsprechenden IT-Ressourcen (z.B. Betriebssystem oder Firewall) angewendet. Typischerweise wird die Security Policy in Form eines nicht formalen Textdokuments erstellt. Dies führt zu einigen Problemen, die wir im Folgenden kurz skizzieren möchten. Die monolithische und lineare Beschreibung von Problemen und Lösungen erschwert, dass Abhängigkeiten und Wechselwirkungen zwischen einzelnen Textabschnitten erkannt werden können. Außerdem werden die Beziehungen zwischen den einzelnen Problemen nicht klar. Da sich viele Parameter, wie etwa Anforderungen oder bestimmte Bedrohungen, oft ändern, ist eine Security Policy bereits dann nicht mehr auf dem neuesten Stand, wenn sie geschrieben wird. Darüber hinaus muss die Person, die für die Erstellung des Dokuments zuständig ist, ein Sicherheitsexperte sein, da nichts übersehen werden darf. Risikoanalyse Es ist nicht notwendig, jeden Wert gleichermaßen zu schützen. Es macht beispielsweise kaum einen Sinn, öffentlich zugängliche Informationen zu verschlüsseln. Anders sieht dies bei Medizin-, Militär- oder Entwicklungsinformationen aus. Hier gelten deutlich höhere Sicherheitsanforderungen. Es muss also für alle sicherheitsrelevanten Anwendungen, Systeme und Netzwerke ermittelt5 werden, welche Risiken im Einzelfall bestehen. Auf dieser Basis können dann angemessene Sicherheitsmaßnahmen ergriffen werden. Die Verwendung von IT-Ressourcen ist aufgrund höherer Gewalt, menschlicher Fehlleistungen, technischem Versagen und vorsätzlichen Angriffen immer mit Risiken verbunden. Auf allen Ebenen müssen daher Informationen vor solchen Bedrohungen geschützt werden. Dabei führt allerdings ein zu geringer Schutz früher oder später zu Schäden unterschiedlicher Art und Höhe. Zu viel Schutz ist hingegen eine Verschwendung von finanziellen, materiellen und personellen Ressourcen.
5
Unternehmensvorstände sind in Deutschland seit 1998 sogar durch das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG, siehe [135]) verpflichtet, „für ein angemessenes Risikomanagement [...] zu sorgen“. Dazu gehören nach Ansicht der Autoren insbesondere auch IT-Sicherheitsrisiken.
42
2 Grundlagen
Risikoanalysen stammen aus der Versicherungswelt und haben zum Ziel, bestimmte Situationen und deren Auswirkungen unter Berücksichtigung der Eintrittswahrscheinlichkeit zu bewerten, um daraus am Ende eine angemessene Versicherungsprämie errechnen zu können. Rader [91] argumentiert, dass diese Vorgehensweise auch auf die Computerwelt übertragbar ist und dort zur indirekten Bestimmung der Sicherheit verwendet werden kann: Um zu bestimmen, ob ein gewisses (Sicherheits-)Risiko noch tragbar ist, müssen zunächst zwei Werte ermittelt werden. Zum einen muss für jedes Risiko der wertmäßige Verlust beziffert werden, der bei Eintritt der Risikosituation entsteht. Zum anderen muss in geeigneter Weise beurteilt werden, wie hoch die Eintrittswahrscheinlichkeit einer solchen Situation ist. Aus diesen beiden Werten errechnet sich durch Multiplikation der Erwartungswert eines Risikos. Anhand dieses Wertes kann entschieden werden, ob dieses Risiko noch tragbar ist oder durch Gegenmaßnahmen verringert werden muss. Während für die Eintrittswahrscheinlichkeit vor allem auf das Kriterium Verfügbarkeit bezogen wenigstens einige historische, statistische Daten 6 zur Verfügung stehen, ist die Bestimmung der Schadenshöhe oft nur durch Schätzung auf Basis von Erfahrungswerten möglich. Das liegt daran, dass sich dieser Wert aus mehreren Einzelwerten zusammensetzt: Lässt sich der Zeitaufwand zur Wiedereingabe von verlorenen Daten noch verhältnismäßig genau ermitteln, wird es bei der Festlegung der durch den (Produktions-)Stillstand enstehenden Kosten schon schwieriger; mehr oder weniger unmöglich ist es schließlich, den zu erwartenden Imageverlust durch den bekannt gewordenen unachtsamen Umgang mit sensitiven (Kunden-)Daten – etwa bei Einbrüchen in E-Commerce-Webseiten, bei denen eine große Zahl von Kreditkartennummern von Kunden ausgespäht wurde – oder den Verlust durch Spionage von internen Informationen (wie z.B. Forschungsdaten) durch die Konkurrenz zu beziffern. Um sinnvolle Werte zu ermitteln, sollten alle Beteiligten, die mit dem IT-System zu tun haben könnten, zu Wort kommen: Benutzer, Betreiber, Administratoren etc. Es muss erfragt werden, welche Werte für wen bedroht sind und wie stark. Ist bekannt, wie wahrscheinlich bestimmte Angriffe sind? Wer sind die potenziellen Angreifer und welche Motive könnten sie haben? Wie in Abschnitt 3.5 beschrieben, kann dies zu unterschiedlichen Angriffsszenarien führen, gegen die Maßnahmen ergriffen werden müssen. Brauchbare Ergebnisse können qualitative Aussagen zum Schadensumfang (z.B. gering, kritisch, katastrophal) und zur Eintrittswahrscheinlichkeit (niedrig, mittel, hoch) sein. Wird eine Risikoanalyse durchgeführt, kann davon ausgegangen werden, dass angemessene Aufwände für Sicherheitsmaßnahmen getrieben werden. Außerdem wird ein Bewusstsein dafür geschaffen, welche Angriffe zu erwarten sind und welcher Schaden entstehen könnte, wenn keine Maß-
6
Für den Sicherheitsaspekt Verfügbarkeit gibt es z.B. zu fast allen Hardwarekomponenten Zahlen zur Ausfallwahrscheinlichkeit (MTBF genannt: mean time between failure), womit sich z.B. die Ausfallwahrscheinlichkeit eines RAID-Festplattenverbundes aufgrund eines Plattendefektes berechnen lässt.
2.3. Security Patterns
43
nahmen ergriffen werden. Werden solche Risiken akzeptiert, muss auch die Verantwortung im Falle eines Schadens übernommen werden. Da idealerweise alle Beteiligten zumindest in einer initialen Phase der Risikoanalyse mit einbezogen werden sollten, wird auch klar, wer diese Verantwortung übernehmen muss. Risikoanalysen erfordern Expertenwissen, um die einzelnen Faktoren der Risikoberechnung auch sinnvoll bestimmen zu können. Der Aufwand für Risikoanalysen ist zwar hoch, gewissenhaft durchgeführt sollte es sich aber lohnen, genau zu wissen, welche Maßnahmen benötigt werden und welche nicht (da grundsätzlich ermittelt werden kann, welche Maßnahmen angemessen sind, lassen sich im Idealfall die Kosten optimieren). Die Ergebnisse einer Risikoanalyse sind in hohem Maß zeitabhängig, d.h., der Vorgang muss regelmäßig wiederholt werden. Evaluierungskriterien Eine Reihe von meist staatlichen Organisationen haben ein ureigenes Interesse daran, IT-Systeme und Anwendungen hinsichtlich der Sicherheit zu untersuchen und zu bewerten. Dies gilt insbesondere für Militär und Geheimdienste, aber auch immer stärker für zivile Bereiche. Aus diesem Grund wurden diverse Kriterien zur Bewertung der Sicherheit von IT-Systemen erarbeitet. Der wohl bekannteste dieser Standards sind die Trusted Computer System Evaluation Criteria (TCSEC), besser bekannt unter dem Namen Orange Book (so bezeichnet wegen der Farbe des Einbands) [39]. Sie wurden von der National Security Agency (NSA) des amerikanischen Verteidigungsministeriums entwickelt und befassen sich im Wesentlichen mit der Sicherheit von autonomen (also nicht vernetzten) IT-Systemen im militärischen Bereich. Verschiedene solcher nationaler Standards wurden in den Common Criteria for Information Technology Criteria (CC) vereinigt und haben sich als internationaler Standard etabliert [30]. Alle Evaluierungsstandards definieren verschiedene Ebenen, auf denen IT-Ressourcen bewertet und verglichen werden können. Die Ebenen repräsentieren unterschiedliche Mengen an Sicherheitsfunktionalität und ein zunehmendes Maß an Zusicherung, d.h., es muss nachgewiesen werden können, dass diese Funktionalität auch erfüllt wird (engl. Assurance Level). Das primäre Ziel dabei ist es nachzuweisen, dass eine IT-Ressource einerseits bestimmten Anforderungen hinsichtlich der Schutzmechanismen genügt. Andererseits muss die Korrektheit der Implementierung ebenfalls bestimmten Stufen der Zusicherung entsprechen. Dennoch sollten auch Evaluierungskritierien kritisch betrachtet werden. Da sie sich nur auf jeweils einen Evaluierungsgegenstand beziehen, können Abhängigkeiten zu anderen IT-Ressourcen und Komponenten leicht übersehen werden. Hinzu kommt, dass der Prozess der Evaluierung einerseits teuer und andererseits sehr zeitaufwändig ist. Vergleichbar mit den Security Policies kann es so dazu kommen, dass es schwierig wird, die Ergebnisse eine Evaluierung auf dem aktuellen Stand zu halten. Schließlich ist es für Laien nahezu unmöglich, solche Evaluierungen durchzuführen, da der Prozess komplex ist und ein hohes Maß an Hintergrundwissen erfordert.
44
2 Grundlagen
Angriffsmodelle Zu den formaleren Ansätzen gehört eine Reihe von symbolischen Baumrepräsentationen, die in den vergangenen Jahren entwickelt worden sind. Oftmals basieren sie auf UND/ODER-Bäumen, die einige grundlegende Berechnungen erlauben, wenn den jeweiligen Knoten bestimmte Werte, wie z.B. die Kosten für einen Angriff, zugewiesen werden. Diese Werte propagieren sich dann nach bestimmten Gesetzmäßigkeiten bis zu dem Wurzelknoten eines solchen Baums. Ein anderes Ergebnis könnte sein, welcher Angriff am wahrscheinlichsten ist, vorausgesetzt, die Werte „möglich“ und „unmöglich“ werden den jeweiligen Knoten zugeordnet. Die bekanntesten Bäume sind Fehler-, Bedrohungs- und Angriffsbäume und werden im Folgenden kurz vorgestellt. Eine Fehlerbaumanalyse (engl. Fault Tree Analysis, FTA) ist eine deduktive Topdown-Methode, um eine Risiko- oder Zuverlässigkeitsanalyse an einem System durchzuführen. Dabei wird grafisch ein Baum mit logischen UND/ODER-Verknüpfungen aufgebaut. Der Wurzelknoten repräsentiert dabei einen Systemfehler, der zu einer Unterbrechung der Systemfunktionalität führt. Folgeknoten werden Ereignisse zugeordnet, die zum Auftreten des jeweils oberen Ereignisses führen. Blattknoten werden dann erreicht, wenn „Basisereignisse“ erreicht werden, d.h., eine weitere Aufgliederung ist nicht mehr möglich. Auf Basis von Erfahrungswerten und Tests können den einzelnen Knoten Fehlerwahrscheinlichkeiten zugewiesen werden, so dass die Ausfallwahrscheinlichkeit des Systems berechnet werden kann. Ein methodischer Ansatz, um Bedrohungen zu identifizieren, sind Bedrohungsbäume (engl. Threat Tree). Dies sollte den Ausgangspunkt für jede Aktivität im Bereich IT-Sicherheit darstellen [5]. Völlig analog zu Fehlerbäumen wird eine Baumstruktur aufgebaut. Allerdings repräsentieren die Knoten jetzt verschiedene Bedrohungen. Problematisch ist anzumerken, dass nicht klar ist, wann der Prozess der Identifikation von Bedrohungen terminiert, da versehentlich immer mehr Details von spezifischen Angriffen hinzugefügt werden. Angriffsbäume (engl. Attack Tree) wurden von Bruce Schneier eingeführt und folgendermaßen definiert: „Ein Angriffsbaum ist ein methodischer und formaler Ansatz, um Wege zum Angriff auf die Sicherheit von Systemen zu finden.“ Der Wurzelknoten stellt dabei das Ziel eines Angriffs dar, wie z.B. ein System lahm zu legen. Weitere Knoten entsprechen dann verschiedenen Wegen, um dieses Ziel zu erreichen. Auch bei diesem Konzept entsteht so eine Baumstruktur. Mithilfe von Angriffsbäumen kann z.B. berechnet werden, was ein Angriff kostet, wie wahrscheinlich ein Angriff ist oder welche Expertise ein Angriff erfordert. Es ist möglich, dass verschiedene Angriffsbäume kombiniert werden können. Dies setzt aber voraus, dass solche Angriffsbäume verwaltet und von verschiedenen Benutzern verwendet werden können [116]. Die beschriebenen Ansätze decken bestimmte Sicherheitsaspekte ab, d.h. Fehler, Bedrohungen und Angriffe. Die Bäume ergänzen sich also, sind aber auch als Werkzeug im Zusammenhang mit anderen Vorgehensweisen (z.B. bei der Erstellung
2.3. Security Patterns
45
einer Security Policy) sinnvoll. Der Prozess, Bäume dieser Art zu erstellen und zu pflegen, setzt allerdings einiges an Wissen voraus. Neulinge im Bereich IT-Sicherheit vergessen sicherlich einige Knoten. Laut Bruce Schneier kann dies allerdings toleriert werden, da davon auszugehen ist, dass man mit jeder Erstellung eines neuen Angriffsbaums besser wird [101]. Daten-, Funktions- und objektorientierte Modellierung Daten-, Funktions- und objektorientierte Modellierungstechniken werden zu den semiformalen Ansätzen gezählt. Sie lassen sich grundsätzlich durch verschiedene, auch textuelle Elemente charakterisieren. Eine bekannte Datenmodellierungstechnik ist das Entity Relationship Model (ERM), objektorientierte Modellierung wird im Allgemeinen mithilfe der Unified Modeling Language (UML) durchgeführt. Hinsichtlich der IT-Sicherheit ermöglicht die Verwendung von UML-Klassendiagrammen beispielsweise die Beschreibung von Eigenschaften und der Beziehungen zwischen Rollen im Zusammenhang mit Zugriffskontrolle. Zustandsdiagramme können dazu verwendet werden, das Verhalten von Elementen oder Rollen zu beschreiben. Aktivitätsgrafen, Ablauf- und Kollaborationsdiagramme kommen zum Einsatz, um das Zusammenspiel der verschiedenen Elemente eines Systems zu beschreiben. Kurz gesagt erlauben es solche semiformalen Ansätze, Systeme und deren Abhängigkeiten strukturiert zu beschreiben. Der Vorteil gegenüber den formalen Methoden ist, dass sie visuell lesbar und damit auch für Nichtexperten im Bereich der Modellierung nützlich sind. Allerdings ist eine automatisierte Validierung aufgrund der semiformalen Struktur kaum möglich. UML kann aber beispielsweise „formaler“ gemacht werden, wenn Nebenbedingungen und Einschränkungen mithilfe der Object Constraint Language (OCL) als Teil des Modells formuliert werden. Formale Methoden IT-Sicherheit ist auch ein Schwerpunktthema im Bereich der formalen Methoden. Allgemein umfassen sie deskriptive Techniken wie z.B. Spezifikationssprachen, Modelle und Logiken. Darüber hinaus zählen auch Analyseverfahren wie z.B. das Überprüfen von Modellen und Theoremen dazu. Im Bereich der IT-Sicherheit werden formale Methoden eingesetzt, um z.B. Authentifizierungs-, Zahlungs- oder Handelsprotokolle zu verifizieren. So wurde etwa das Bell-LaPadula-Modell für Zugriffskontrolle, das im Orange Book verwendet wird, formal untersucht [11]. Es gibt auch eine Reihe von Beschreibungssprachen (siehe [35]), um Richtlinien (engl. Policies) formal darzustellen, sowie Verfahren zur Konsistenzüberprüfung und zum Auffinden von Konflikten (siehe [123]). Formale Methoden haben verschiedene Vorteile. Zum einen ermöglichen sie es, die Schnittstelle zwischen einem System und seiner Umgebung exakt zu spezifizie-
46
2 Grundlagen
ren. Außerdem können das Verhalten und die Eigenschaften eines Systems präziser charakterisiert werden. Es kann auch nachgewiesen werden, dass ein System konform zu einer Spezifikation ist, was insbesondere im Bereich der IT-Sicherheit eine wichtige Forderung ist, da so Vertrauen in die Funktionalität etabliert werden kann. Allerdings können formale Methoden nur auf Probleme einer bestimmten Komplexität, wie z.B. dem Entwurf von Smart-Cards oder kryptografischen Protokollen, angewendet werden. Komplexere Systeme, die sogar verteilt sind und mit anderen Komponenten interagieren, können allerdings kaum betrachtet werden, da diese zu komplex sind und zu viele Abhängigkeiten aufweisen. Außerdem ist ein fundierter mathematischer Hintergrund notwendig, um formale Methoden richtig anwenden zu können. Laien profitieren demnach nur eingeschränkt von diesem Ansatz. Schließlich muss darauf hingewiesen werden, dass das Ergebnis einer Verifikation immer nur so gut sein kann, wie die Annahmen, die bei der Modellierung eines Systems getroffen worden sind. Auch hier muss auf die langjährige Erfahrung von Experten gesetzt werden. Eine der größten Herausforderungen im Bereich der formalen Methoden wird es daher sein, die Möglichkeiten zur Spezifikation von Systemen weiter zu verbessern. Außerdem muss erreicht werden, dass formale Methoden besser in den gesamten Entwicklungsprozess integriert werden. So sind beispielsweise Schnittstellen zu etablierten Entwicklungswerkzeugen und partielle Spezifikationen denkbar, um so auch mit größeren Systemen umgehen zu können. Diskussion Die beschriebenen Methoden können nach verschiedenen Kriterien qualitativ miteinander verglichen werden. In Tabelle 2-3 fassen wir zunächst die Stärken der vorgestellten Methoden und Werkzeuge für das System Security Engineering zusammen. Bei der Abstraktionsebene betrachten wir, ob ein Ansatz eher von organisatorischer, technischer oder regulativer Natur ist. Weiterhin berücksichtigen wir den zeitlichen (und damit auch finanziellen) Aufwand für die Anwendung einer Methode. Schließlich halten wir fest, wie strukturiert eine Methode sowie deren Ergebnisse sind. Je strukturierter ein Ansatz, desto höher ist das Potenzial zur Automatisierung. Aus Tabelle 2-3 lassen sich die folgenden Erkenntnisse ableiten: Die Ansätze lassen sich grob in organisatorische bzw. technische Ansätze einteilen. Daraus folgt, dass ein übergeordneter Prozess, der die unterschiedlichen Ebenen verbindet, notwendig ist. Sicherheit hat ihren Preis, d.h., der notwendige Aufwand muss vorab immer berücksichtigt werden. Die Struktur der einzelnen Ansätze ist sehr unterschiedlich. Insbesondere Ansätze mit einem mittleren bzw. hohen Grad an Struktur eignen sich für die Automatisierung von Teilbereichen (z.B. Suchen und Finden, Wartung etc.).
2.3. Security Patterns
47
Tab. 2-3 Stärken der Methoden und Werkzeuge
Security Policy
Risikoanalyse
Evaluierungskriterien
Angriffsmodelle
Semiformale Methoden
Formale Methoden
Abstraktionsebene
organisatorisch, regulativ
organisatorisch
technisch
technisch
technisch
technisch
Aufwand
mittelhoch
hoch
hoch
mittel
mittel
mittelhoch
Struktur
niedrig
niedrig
mittel
hoch
mittel
hoch
In Tabelle 2-4 zeigen wir nun, wie der Faktor Mensch von den jeweiligen Ansätzen berücksichtigt wird. Wir gehen dabei auf die in Abschnitt 2.2.3 diskutierten Aspekte ein: – – – –
Wie hoch ist das benötigte Hintergrundwissen des Anwenders? Trägt ein Ansatz zur Problemlösung bei, d.h., werden Maßnahmen ermittelt? Unterstützt ein Ansatz bei der Formulierung der Annahmen? Sind die Ergebnisse eines Ansatzes zeitabhängig? Tab. 2-4 Berücksichtigung des Faktors Mensch
Security Policy
Risikoanalyse
Evaluierungskriterien
Angriffsmodelle
Semiformale Methoden
Formale Methoden
Expertise
mittelhoch
mittelhoch
hoch
mittelhoch
hoch
hoch
Problemlösung
nein
nein
nein
nein
ja
ja
Vollständigkeit Annahmen
bedingt
bedingt
ja
bedingt
bedingt
bedingt
Zeitabhängigkeit
hoch
hoch
mittel
mittel
mittel
mittel
Hier zeigt sich, dass alle betrachteten Ansätze ein mittleres bis hohes Maß an Hintergrundwissen voraussetzen. Außerdem gibt es offenbar nur wenige Verfahren, die den Menschen bei der Problemlösung unterstützen. Bis auf die Evaluierungskriterien, die vollständige Kriterienkataloge liefern, hängt die Vollständigkeit der Annahmen immer von der Expertise des Anwenders eines Verfahrens ab. Schließlich kann festgehalten werden, dass die Ergebnisse insbesondere dann stark zeitabhängig sind, wenn sehr spezifische Aspekte betrachtet werden. Generische Ansätze sind davon nicht weniger betroffen.
48
2 Grundlagen
Zusammenfassend halten wir fest, dass es offenbar eine Lücke bei den Methoden und Werkzeugen für das System Security Engineering gibt. Ideal wäre ein ergänzendes Verfahren, das eine hinreichende Struktur aufweist, mit vertretbarem Aufwand durchzuführen ist und verschiedene Abstraktionsebenen berücksichtigt. Außerdem sollten auch Laien mit solch einem Verfahren zurechtkommen. Auch Nichtexperten sollten bei der Problemlösung unterstützt werden. Dazu gehört insbesondere, dass Hilfestellungen bei der Ermittlung der Annahmen gegeben werden. Schließlich sollte es auch möglich sein, Zeitabhängigkeiten zu berücksichtigen. Im Folgenden zeigen wir, wie die aufgezeigte Lücke mit Security Patterns grundsätzlich verkleinert bzw. in Teilbereichen geschlossen werden kann. 2.3.2 Musterlösungen für sichere IT-Systeme? Patterns (Muster) sind ein viel diskutiertes Thema im Bereich der Software-Entwicklung. Sie sind eine spezielle textuelle Form der Problemlösung, die ihren Ursprung in einer Entwurfsrichtung der zeitgenössischen Architektur, dem literarischem Programmieren sowie der Dokumentation von bewährten Vorgehensweisen in verschiedenen Disziplinen haben. Eine allgemeine Definition eines Patterns gibt der Architekt Christopher Alexander in seinem Buch „The Timeless Way of Building“, das als „der Klassiker“ auf dem Gebiet der Patterns zu bezeichnen ist [2]: Jedes Pattern ist eine aus drei Teilen bestehende Regel, die eine Beziehung zwischen einem bestimmten Kontext, einem Problem und einer Lösung ausdrückt. Def. 3-1 Alexanders Pattern-Definition
Grundsätzlich beschreibt jedes Pattern ein immer wiederkehrendes Problem in unserer Umgebung und dann die Grundzüge einer Lösung dieses Problems. Die Idee ist es, die Lösung eines Problems aufzuschreiben und anderen zur Verfügung zu stellen, so dass diese im Bedarfsfall darauf zurückgreifen können. Dieser Ansatz ermöglicht einen effizienten Transfer von praktischen Erfahrungen und Fertigkeiten. Prinzipiell können Patterns für alle Arten von Wissen angewendet werden. Mit diesem Buch wenden wir das Pattern-Konzept auf den Bereich IT-Sicherheit an: Security Patterns. Bevor wir die Grundlagen von Security Patterns vorstellen, möchten wir kurz zeigen, welche Vorteile Security Patterns hinsichtlich der Probleme haben, die wir in Abschnitt 2.2.3 aufgezeigt haben. IT-Sicherheit ohne Expertenwissen Naturgemäß erfordert die Anwendung von Security Patterns kein Hintergrundwissen. Security Patterns fangen gewissermaßen das Wissen und die Fertigkeiten von Sicherheitsexperten ein. So wird es prinzipiell möglich, dass Laien wie Experten agieren können, wenn Probleme zu lösen sind. Außerdem verwenden die Experten die Security Patterns wie ein gemeinsames und mächtiges Vokabular, um Sicherheitsprobleme zu behandeln. So wird es auch ermöglicht, Probleme und Lösungen
2.3. Security Patterns
49
effizienter zu identifizieren, zu benennen und zu diskutieren. Mithilfe von systematischen Analysen von Sicherheitsverletzungen können „schlechte“ Praktiken aufgedeckt werden. Auf dieser Basis können „gute“ Lösungen entsprechend dem Stand der Kunst gefunden und in Form von Security Patterns – also gewissermaßen Musterlösungen für Sicherheitsprobleme – bereitgestellt werden. Strukturierte Lösung von Problemen Ein wichtiger Aspekt von Security Patterns ist, dass ein Security Pattern im Allgemeinen nicht isoliert betrachtet werden kann, sondern vielmehr unterschiedliche Beziehungen zu anderen Security Patterns hat. So werden die Fern- und Nebenwirkungen einer Lösung sichtbar, die Auswirkungen von bestimmten Entscheidungen im Entwurfsprozess werden klar. Auf diese Weise verhindert die Verwendung von Security Patterns eine Ad-hoc-Problemlösung und trägt zu einer systematischen und strukturierten Vorgehensweise bei. Falsche Annahmen Sowohl die systematischen Vorgehensweise als auch die strukturierte Beschreibung unterstützen den Anwender von Security Patterns dabei, Probleme im richtigen Zusammenhang zu sehen. Die Annahmen, die zu der Lösung eines bestimmten Problems führen, werden fixiert, so dass sich die Gefahr, dass etwas übersehen oder falsch gemacht wird, reduziert. Es muss daher darauf geachtet werden, dass genau die Rahmenbedingungen, die die Anwendung des Security Patterns ermöglichen, auch zutreffen, da sonst die Zuordnung zwischen Problem und Lösung nicht stimmen könnte. Wenn ein Security Pattern „richtig“ angewendet wird, kann davon ausgegangen werden, dass die optimale Lösung nach dem Stand der Technik umgesetzt wird. IT-Sicherheit versus Komplexität Security Patterns führen verschiedene Abstraktionsebenen ein. Dies ermöglicht es, unterschiedliche Sichtweisen auf ein Problem zu haben, also beispielsweise eine integrierte Ansicht auf das Gesamtsystem und einen feingranularen Blick auf individuelle Komponenten. Außerdem ist die Vollständigkeit einer Lösung insofern gegeben, als dass Folgeprobleme gewissermaßen automatisch erfasst werden, wenn zusätzlich zu dem betrachteten Security Pattern alle verwandten Security Patterns berücksichtigt werden. Zeitabhängigkeiten Systemanforderungen und Rahmenbedingungen ändern sich im Lauf der Zeit. Da Security Patterns untereinander verbunden sind, wird der Einfluss von Änderungen in nachvollziehbarer Weise deutlich. Eine stimmige Sammlung von Security Patterns wird selbst dann nicht notwendigerweise nutzlos, wenn sich herausstellt, dass einige wenige Security Patterns nicht mehr gelten und überarbeitet werden müssen.
50
2 Grundlagen
Aufgrund der Kapselung von Problemen sollten insbesondere Lösungen auf höhere Abstraktionsebenen nicht von Änderungen auf niedrigeren Abstraktionsebenen beeinflusst werden. Wenn ein Security Pattern tatsächlich nicht mehr angewendet werden kann, weil z.B. eine neue Angriffstechnik bekannt geworden ist, müssen es – falls möglich – so überarbeitet werden, dass eine alternative Lösung zugeordnet werden kann. Falls dies nicht möglich ist, so weiß der Anwender des Security Patterns immerhin, dass für dieses Sicherheitsproblem (noch) keine Lösung gefunden worden ist. Hinsichtlich der vorangegangenen Betrachtung der Stärken von Verfahren zum System Security Engineering ordnen sich Security Patterns wie folgt ein: Security Patterns können grundsätzlich auf beliebigen Abstraktionsebenen eingesetzt werden. Der Aufwand bei Security Patterns ist auf Seiten der Anwender eher gering, auf Seiten der Autoren bei der Dokumentation (einmalig) hoch. Spätere Änderungen und Anpassungen dürften eher einen minimalen bis mittleren Aufwand erfordern. Security Patterns weisen einen gewissen Grad an Struktur auf, der eine Teilautomatisierung bestimmter Vorgänge ermöglicht. 2.3.3 Grundlagen von Security Patterns Sowohl die Definitionen eines Security Patterns als auch die von Security PatternSystemen, die im Folgenden gegeben werden, basieren auf den allgemeinen Ausführungen in einem weiteren Standardwerk der Pattern-Literatur [16]. In diesem Abschnitt zeigen wir analog zu [106] und [109], welche Aspekte ein Security Pattern im Vergleich zu einem „herkömmlichen“ (Design-)Pattern ausmachen. Ein Security Pattern beschreibt ein einzelnes wiederkehrendes Sicherheitsproblem, das in einem bestimmten Kontext auftritt, und präsentiert ein bewährtes Schema für dessen Lösung. Def. 3-2 Security Pattern
Security Patterns eignen sich damit besonders gut, um dem Problem entgegenzutreten, dass die gleichen Fehler immer wieder gemacht werden. Außerdem spiegeln sie das grundlegende Prinzip des Hacker Contest wider: Sicherheitsprobleme sind bestimmte Bedrohungen, Verletzlichkeiten und Angriffe, Lösungen sind entsprechende Maßnahmen, die die Risiken minimieren. Die technische Dokumentation des Hacker Contest kann gut in die Form von Security Patterns überführt werden. Struktur eines Security Patterns Je mehr Informationen ein Security Pattern aufweist, desto wichtiger wird die Struktur der Information. Die Struktur führt zu einer Einheitlichkeit der Patterns, so dass ein Vergleich von und die Suche nach Informationen in systematischer Art und Weise vereinfacht wird. Dahingegen bedeutet weniger Struktur mehr informeller Text, was für den Gelegenheitsleser ausreichend ist. Für professionelle Anwender,
2.3. Security Patterns
51
die Vergleiche und Recherchen durchführen wollen, kann dies jedoch nicht akzeptabel sein. Bei der Vorstellung der Kernelemente von Security Patterns beschränken wir uns auf die typischen Elemente: Name, Kontext, Problem, Lösung und Abhängigkeiten [76]. Die Bedeutung der Elemente im Hinblick auf den Sicherheitsaspekt wird im Folgenden kurz vorgestellt. Wir ordnen dabei Sicherheitsbegriffe und -konzepte, die in Abschnitt 2.1 definiert worden sind, den einzelnen Elementen eines Security Patterns zu. In Abbildung 2-7 wird die Struktur eines Security Pattern außerdem schematisch dargestellt. – Name Der Name ist, wie auch bei „normalen“ Patterns, ein wichtiger Bestandteil von Security Patterns. Der Name wird zu einem Teil des Vokabulars der Anwender von Security Patterns. Es sollte daher leicht sein, sich den Namen zu merken und auf ihn zu verweisen. Ein guter Name sollte zudem gleich ein Bild darüber vermitteln, worum es bei dem Pattern geht. Bei Security Patterns macht es durchaus Sinn, den Namen so zu wählen, dass er etwas mit dem Problem oder der Lösung zu tun hat. So wird die Suche nach Security Patterns stark erleichtert. An dieser Stelle kann zudem eine Kurzbeschreibung des Security Patterns gegeben werden. – Kontext Basierend auf einem Szenario wird der Kontext eines Security Patterns erläutert. Die Rahmenbedingungen, unter denen das Problem auftritt, werden so dargestellt. Mithilfe einer Aufzählung der Annahmen können Aspekte der Umgebung, in der die IT-Ressource benutzt werden soll, beschrieben werden. Oftmals müssen IT-Ressourcen bestimmten Sicherheitsvorgaben entsprechen. Eine optionale Beschreibung solcher Aussagen erleichtert daher die eindeutige Bestimmung der Schutzziele. Außerdem wird auf Security Patterns auf höheren Abstraktionsebenen verwiesen, die letzten Endes zu dem Kontext geführt haben. – Problem Hier wird beschrieben, welches Problem von dem Security Pattern gelöst wird. Den Kern von Sicherheitsproblemen bilden Bedrohungen, da eine IT-Ressource grundsätzlich nur dann als sicher gelten kann, wenn Maßnahmen gegen alle bekannten Bedrohungen getroffen werden. Optional können ebenfalls Schutzziele, die ein komplementärer Begriff zu den Bedrohungen sind, formuliert werden. Nur wenn ein bestimmtes Schutzziel gilt, wird eine Bedrohung auch als Gefahr betrachtet. Die wesentlichen Aspekte des Problems werden mithilfe der Beschreibung von ggf. widersprüchlichen Anforderungen (engl. Forces) herausgearbeitet. So möchte beispielsweise ein Anwender eine Nachricht versenden und ein Angreifer könnte diese abhören, aber es sollen keine Änderungen an der Software vorgenommen werden. Im Bereich der Sicherheit lassen sich diese Anfor-
52
2 Grundlagen
derungen aus den allgemeinen Bedrohungen (siehe Abschnitt 2.1.4), also dem Potenzial für eine Verletzung der Sicherheit, ableiten. Als Beispiele, wie es zu solchen Bedrohungen kommt, können außerdem spezielle Angriffe dargestellt werden. In diesem Zusammenhang können durchaus Angriffsbäume als sinnvolle Ergänzung verwendet werden, um charakteristische Angriffe systematisch zu identifizieren. Andere Anforderungen könnten auch Kompromisse zwischen Sicherheitsaspekten und anderen Systemeigenschaften wie etwa Benutzbarkeit und Performanz sein. – Lösung Dieses Element beschreibt die eigentliche Lösung des Problems. Entsprechend der Anforderungen werden Maßnahmen aufgeführt, die das Problem im jeweiligen Kontext lösen, d.h., die Risiken auf ein Minimum reduzieren. Dabei sollte es mindestens eine Maßnahme für jede Bedrohung bzw. jeden Angriff geben 7. An dieser Stelle kann auch vor möglichen Schwierigkeiten bei der Umsetzung gewarnt werden. – Abhängigkeiten Es kann durchaus vorkommen, dass einige Gegenmaßnahmen nicht alle Probleme lösen oder sogar zu neuen Verletzlichkeiten führen. Außerdem gibt es möglicherweise alternative Lösungen. Mithilfe solcher verwandten Patterns wird eine Hierarchie gebildet, die den Abhängigkeiten der einzelnen Probleme und Lösungen untereinander entspricht. Neben den bisher beschriebenen Elementen eines Security Patterns können auch einige optionale Elemente aufgeführt werden, wenn sie zur besseren Verständlichkeit und Anwendbarkeit beitragen. So kann mithilfe von Aliasen auf Namen oder Konzepte verwiesen werden, unter denen das Security Pattern auch bekannt ist. Mithilfe der Beschreibung der Konsequenzen der Anwendung eines Security Patterns kann gezeigt werden, welche Anforderungen bei der Lösung berücksichtigt worden sind und welche nicht. Die Auflistung der Vor- und Nachteile hilft dabei festzustellen, ob das Security Pattern wirklich angewendet werden soll. Ein Beispiel hierfür ist der Widerspruch zwischen Benutzbarkeit und Sicherheit im Netzwerkkontext. So erhöht eine Firewall zwar typischerweise die Sicherheit, da eine Zugriffskontrolle implementiert werden kann, allerdings kann es passieren, dass Anwendungen oder Verhaltensweisen der Benutzer geändert werden müssen. Mithilfe von verschiedenen Diagrammen kann die Struktur einer Lösung (z.B. mit Klassendiagrammen) illustriert werden. Außerdem können so die Interaktionen zwischen den aktiven Teilnehmern (also z.B. Benutzer, Netzwerkknoten etc.) dargestellt werden.
7
Wobei eine Maßnahme durchaus auch gegen mehr als eine Bedrohung Schutz bieten kann.
2.3. Security Patterns
53
• Kurzbeschreibung
Name
Kontext
• Szenario
Problem
• Bedrohung/Schutzziel • Angriff(e)
Lösung
• Maßnahmen
Abhängigkeiten
• Spezialisierung • Voraussetzung
Abb. 2-7 Schematische Darstellung eines Security Patterns
Um die Anwendung eines Security Patterns zu erleichtern, können auch ausgewählte Beispiele verwendet werden. Hier eignen sich beispielsweise Konfigurationsbeispiele oder einige Skizzen. Auch Analogien aus dem richtigen Leben sind an dieser Stelle sinnvoll. In [136] wird beispielsweise immer wieder eine Militärbasis herangezogen, um den Kontext von Security Patterns auf der Anwendungsebene zu verdeutlichen. Es ist schwierig – wenn nicht gar unmöglich – zu beweisen, dass eine IT-Ressource wirklich sicher ist. Tatsächlich ist es sehr viel leichter zu zeigen, dass etwas schief gegangen ist. Mithilfe von Gegenbeispielen kann so z.B. gezeigt werden, wie ein Security Pattern falsch implementiert wird, d.h., die Situation ist schlechter (unsicherer) als vorher. Das Security Pattern würde dann gewissermaßen zu einem AntiSecurity Pattern. Security Pattern-Systeme Security Patterns stehen untereinander in Beziehung. Gruppen von verwandten Patterns werden allgemein als Pattern Language oder Pattern-System bezeichnet. Patterns stellen dabei gewissermaßen die Vokabeln von Patterns Languages dar. Die Regeln für die Umsetzung und die Kombination von Patterns entsprechen sinngemäß der Grammatik. Ein Pattern Language beschreibt Beziehungen und Abhängigkeiten zwischen Patterns. In dem Buch „A System of Patterns“ wird stattdessen der zutreffendere Begriff des Pattern-Systems eingeführt [16]. Die Begründung ist im Wesentlichen darin zu sehen, dass der Begriff „Sprache“ impliziert, dass jeder wichtige Aspekt einer Problemdomäne vollständig abgedeckt wird. Ein Pattern Language muss daher nach Ansicht der Autoren komplett sein, d.h., es darf keine Lücken
54
2 Grundlagen
geben. Typischerweise existieren solche Pattern Languages nur für sehr eingeschränkte und gut verstandene Bereiche. Die Autoren beschreiben in ihrem Werk allerdings nur bestimmte Aspekte von Software-Architekturen, insgesamt wird also keine vollständige Sprache dargestellt. Selbst wenn alle anderen Patterns zu dem Themenkomplex integriert würden, kann davon ausgegangen werden, dass keine Vollständigkeit nachgewiesen werden kann. Wir leiten daraus die folgende Definition eines Security Pattern-Systems ab: Ein Security Pattern-System ist eine Menge von Security Patterns, zusammen mit Richtlinien zur Umsetzung, Kombination und praktischen Anwendung in einer Problemdomäne der IT-Sicherheit. Def. 3-3 Security Pattern-System
Borchers hat erstmals ein formales, von der Problemdomäne unabhängiges Modell eines Pattern-Systems (ursprünglich wird auch hier der Begriff Pattern Language verwendet) eingeführt, das wir im Folgenden nochmals verallgemeinert vorstellen [18]. Auf Basis dieses Modells können wir weitere Eigenschaften von Security Patterns definieren. Dies ist hilfreich, um das intuitive Verständnis von Security Patterns zu formalisieren. Ziel ist es, die Strukturen und Interna von Security Patterns präzise beschreiben zu können. Die ist zudem eine wichtige Voraussetzung, um beispielsweise computerunterstützte Werkzeuge für Autoren und Anwender von Patterns zu entwickeln. Darauf kommen wir in Kapitel 8 nochmals zurück. Seit den grundlegenden Arbeiten von Christopher Alexander kommen die strukturellen Elemente dieses Modells in nahezu allen Patterns vor und stellen somit den kleinsten gemeinsamen Nenner dar, der notwendig ist, um ein Pattern effizient zu vermitteln [76]. 1. Ein Pattern-System ist ein gerichteter azyklischer Graph PS = ( ℘, ℜ ) mit Knoten ℘ = { P 1, P 2, …, P n } und Kanten ℜ = { R 1, R 2, …, R n } . 2. Jeder Knoten P ∈ ℘ stellt ein Pattern dar. 3. Für zwei Knoten P, Q ∈ ℘ gilt P referenziert Q genau dann, wenn eine gerichtete Kante R ∈ ℜ existiert, die von P nach Q führt. 4. Alle Kanten, die von einem Knoten P ∈ ℘ wegführen, werden als verwandte Patterns oder Abhängigkeiten des Knotens bezeichnet. Alle Kanten, die zu dem Knoten zeigen, stellen Teile des Kontexts des Patterns dar. Insbesondere die Forderung nach einem azyklischen Graphen ist hier zu beachten. Wenn nämlich ein Zyklus in einem Pattern-System auftritt, so ist dies ein Indiz dafür, dass bei der Erstellung des Patterns ein Fehler unterlaufen ist, wie folgende Ausführung zeigt. Angenommen, ein Pattern-System würde einen solchen Zyklus P 1, P 2, …, P n, P 1 enthalten. Das würde bedeuten, dass P 1 im Kontext von P 2
2.3. Security Patterns
55
referenziert wird, d. h., P 1 wird für die Anwendung von P 2 vorausgesetzt. P 2 wird wiederum vorausgesetzt, um P3 anwenden zu können, etc. Wird nun schließlich P n vorausgesetzt, um P 1 anwenden zu können, so würde P 1 (indirekt über die Transitivität) sich selbst voraussetzen, was grundsätzlich nicht möglich ist. Also ist die Annahme, dass ein Zyklus im Pattern-Graphen enthalten sein kann, falsch. Im Folgenden erläutern wir, welche Beziehungen zwischen Patterns bestehen können und welche Semantik diese Beziehungen haben. Um aus mehreren Patterns ein Pattern-System zu machen, müssen deren Beziehungen untereinander beschrieben werden. Grundsätzlich lassen sich hier beliebige Beziehungen definieren. In der Pattern-Literatur sind beispielsweise folgende Beziehungen angegeben (siehe auch Abbildung Abb. 2-9 auf Seite 62): – – – – – –
Pattern X ist eine Alternative von Pattern Y Pattern X benutzt Pattern Y Pattern X implementiert Pattern Y Pattern X hängt ab von Pattern Y Pattern X erzeugt Pattern Y etc.
In diesem Buch gehen wir jedoch davon aus, dass sich diese Beziehungstypen weitgehend auf die grundlegenden Beziehungen der Spezialisierung (bzw. Generalisierung) sowie der Voraussetzung reduzieren lassen. Diese Beziehungen wollen wir im Folgenden definieren. Spezialisierung von Security Patterns Die Spezialisierung eines Security Patterns bedeutet grundsätzlich, den Kontext bzw. das Problem zu konkretisieren. Als Beispiel betrachten wir ein Security Pattern im Kontext Netzwerk, wo ein typisches Problem der Schutz der Vertraulichkeit der übertragenen Daten gegen einen digitalen Lauschangriff ist. Wenn wir nun zu dem Kontext eines Ethernet-basierten Local Area Networks (LAN) wechseln, das offensichtlich konkreter als ein allgemeines Netzwerk ist, können wir ebenfalls spezifischere Bedrohungen erkennen: in einem Ethernet-basierten LAN ist es nämlich möglich, Pakete, die eigentlich für andere Stationen bestimmt sind, passiv abzuhören. Solche „Sniffer“-Angriffe sind typisch in diesem Kontext. Wir definieren die Relation Spezialisierung daher wie folgt: Ein Security Pattern X spezialisiert ein Security Pattern Y genau dann, wenn der Kontext von X den Kontext von Y spezialisiert oder das Problem von X das Problem von Y spezialisiert. Def. 3-4 Spezialisierung von Security Patterns
56
2 Grundlagen
Der Kontext wird also spezifischer, und es können spezifischere Probleme hinzukommen. Dabei ändert sich die Abstraktionsebene des Security Patterns. Die folgenden Beispiele illustrieren unterschiedliche Varianten der Definition und deren Bedeutung: – Der Kontext wird spezialisiert, das Problem bleibt gleich Um bei unserem Beispiel zu bleiben, so hätte das Security Pattern dann den Kontext „Ethernet LAN“ und das Problem „Lauschangriff“. Das Security Pattern Y hätte den Kontext „Netzwerk“ und ebenfalls das Problem „Lauschangriff“. In diesem Fall würde also gelten: Security Pattern X spezialisiert Security Pattern Y. Dies hilft, speziellere Lösungen für Probleme in unterschiedlichen Kontexten zu unterscheiden. Je nach Kontext ergeben sich dann unterschiedliche Lösungen wie beispielsweise Verschlüsselung auf der Internet- bzw. der Netzzugangsschicht. Dieser Fall könnte ein Hinweis darauf sein, dass die Anforderungen in den Security Patterns noch nicht ausreichend spezifiziert sind. – Der Kontext bleibt gleich, das Problem wird spezialisiert Das Security Pattern X hat in diesem Fall den Kontext „Netzwerk“ und das speziellere Problem eines „Sniffer“-Angriffs. Security Pattern Y hat dementsprechend den gleichen Kontext und das allgemeinere Problem „Lauschangriff“. Es gilt demnach auch: Security Pattern X spezialisiert Security Pattern Y. Dies hilft dabei, Lösungen für konkretere Probleme zu unterscheiden. So schützt Verschlüsselung beispielsweise grundsätzlich gegen Lauschangriffe, ein LAN mit einem Switch schützt darüber hinaus auch gegen Sniffer-Attacken. Dieser Fall weist u.U. darauf hin, dass die Annahmen im Kontext der Security Patterns nicht ausreichend spezifiziert sind. – Kontext und Problem werden spezialisiert Jetzt hat das Security Pattern X den Kontext „Ethernet LAN“ und das Problem „Sniffing“, und das Security Pattern Y hat den Kontext „Netzwerk“ sowie das Problem „Lauschangriff“. Dies ist die intuitiv natürlichste Auslegung der Spezialisierung. Der Abstraktionsgrad ändert sich in homogener Weise: je spezifischer der Kontext, desto spezifischer die Probleme und damit auch die Lösungen. Wir beschränken uns aber nicht auf diese Auslegung der Definition, um die Kreativität der Autoren von Security Patterns zunächst nicht unnötig einzuschränken und das kontinuierliche Wachsen eines Security Patterns-Systems nicht zu behindern. In einem später folgenden Begutachtungsprozess kann ein weiterer Experte auf solche Fälle hinweisen (siehe Kapitel 8.2). Wenn sowohl Kontext als auch Problem gleich bleiben, ist dies ein Hinweis darauf, dass die entsprechenden Security Patterns identisch sind, da die Lösung eindeutig von Kontext und Problem bestimmt wird. Die Relation der Spezialisierung ist übrigens symmetrisch, d.h., wir sprechen von Generalisierung, wenn ein Security Pattern X ein Security Pattern Y verallgemeinert. Die Definitionen lassen sich analog zu dieser Aussage übertragen.
2.3. Security Patterns
57
Voraussetzung von Security Patterns Grundsätzlich kann ein Security Pattern ein anderes Security Pattern auch voraussetzen. Dies geschieht einerseits dann, wenn in einem Security Pattern ein Problem nur teilweise gelöst wird. Ein Beispiel hierfür ist ein Security Pattern für die „Sichere Kommunikation“. Hier wird die Übertragung von Nachrichten gegen Lauschangriffe geschützt. Allerdings setzt dies voraus, dass vorher beispielsweise ein Security Pattern „Gehärtetes Betriebssystem“ angewendet wird, damit es einem Angreifer nicht möglich ist, den Endpunkt einer sicheren Verbindung zu attackieren und damit in Kenntnis der vertraulichen Informationen zu gelangen. Andererseits kommt es oft vor, dass durch die Anwendung eines Security Patterns ein neues Problem entsteht. So schützt die Verwendung eines Switch zwar gegen Sniffer-Angriffe, allerdings ist der Switch selbst wiederum angreifbar, da er z.B. über administrative Zugänge verfügt, die entsprechend geschützt werden müssen. Wir definieren die Relation Voraussetzung wie folgt: Ein Security Pattern X setzt ein Security Pattern Y voraus, wenn es in Y eine Lösung für das Problem von X gibt, aber nicht in X selbst. Def. 3-5 Voraussetzung von Security Patterns
Da es (im Gegensatz zu Vererbungsgraphen) mehr als einen Beziehungstyp gibt, ist es eine Möglichkeit, jede Kante entsprechend zu beschriften. Fehlt eine solche explizite Beschriftung (wie z.B. in [19]), ist diese den Beschreibungen der Security Patterns zu entnehmen, was sich möglicherweise als recht mühsam für den Leser erweisen kann. Damit keine Inkonsistenzen entstehen, erfordert dies außerdem ein hohes Maß an Disziplin für den Autor von Security Patterns. Eine grafische Darstellung erleichtert dem Leser gerade bei größeren PatternSystemen das Verständnis der Zusammenhänge. Der Pattern-Graph besteht dabei aus Patterns als (benannte) Knoten, deren Zusammenhänge als Kanten (unter Nennung des Beziehungstyps) dargestellt sind. Die Knotenbeschriftung kann optional um eine Kurzbeschreibung von Problem, Kontext und Lösung ergänzt werden. In diesem Buch handhaben wir es so, dass wir, wie in Abbildung 2-8 gezeigt, unterschiedliche Kanten mit verschiedenen Linienarten darstellen.
spezialisiert P1
P2 setzt voraus
P1
P2
Abb. 2-8 Darstellung der Kantensemantik von Security Patterns
58
2 Grundlagen
Konsistenz von Security Pattern-Systemen Aus Definition 3-5 folgt, dass ein Security Pattern, in dem es für jede Bedrohung bzw. für jeden Angriff eine entsprechende Maßnahme gibt, kein anderes Security Pattern voraussetzt. Wir sprechen in diesem Fall von interner Konsistenz eines Security Patterns. Ist dies nicht der Fall, muss es in der Menge der Security Patterns ein anderes Security Pattern geben, das nicht abgedeckte Probleme löst, also vor nach wie vor bestehenden Bedrohungen und Angriffen schützt. In diesem Fall sprechen wir von externer Konsistenz. Ist beides nicht gegeben, führt die Anwendung der Security Patterns möglicherweise dazu, dass es keinen Schutz gegen eine bestimmte Bedrohung gibt. Autoren von Security Patterns müssen also hier besonders aufmerksam sein. Umgekehrt kann im Falle eines konsistenten Security PatternSystems davon ausgegangen werden, dass es für jedes Problem eine Lösung gibt und damit Sicherheit erreicht wird. Bei konsistenten Security Patterns gehen wir also davon aus, dass die Maßnahmen nicht angreifbar sind bzw. keine Verletzlichkeiten aufweisen oder neue Probleme einführen. Falls dem doch so ist, ergibt sich – wie wir beschrieben haben – eine weitere Abhängigkeit. Die Anwendung von Security Patterns ist aber dennoch sinnvoll, selbst wenn angenommen wird, dass die Maßnahmen Schutz bieten und dies nicht zutrifft. Sobald dieses Problem nämlich erkannt wird, kann sofort reagiert werden: Man weiß umgehend, wo Handlungsbedarf besteht. Falls wir in den Security Patterns in diesem Buch Maßnahmen aufführen, die angreifbar sind, und kein ergänzendes Security Pattern in diesem Buch enthalten ist, verweisen wir auf entsprechende Literatur. Im Folgenden besprechen wir unterschiedliche Gründe, wie es dazu kommen kann, dass die Konsistenz eines Security Pattern-Systems nicht mehr gegeben ist. Wir betrachten dabei interne und externe Einflüsse von Security Patterns. Änderungen in Security Patterns Auf höheren Abstraktionsebenen sind Security Patterns möglichst zeitinvariant zu gestalten. Je näher sich aber ein Security Pattern durch Spezialisierung auf eine reale Implementierung zu bewegt, desto höher wird die Wahrscheinlichkeit, dass sich bestimmte Parameter im Lauf der Zeit ändern. In diesem Fall kann sowohl die interne als auch die externe Konsistenz eines Security Patterns nicht mehr gegeben sein. Folgende interne Änderungen sind beispielsweise denkbar: – Wird das festgelegte Szenario verändert, z.B. die Topologie eines Netzes oder die möglichen Kommunikationsbeziehungen, so ergeben sich möglicherweise neue Sicherheitsprobleme, die dann wiederum eine neue bzw. veränderte Lösung zur Folge haben.
2.3. Security Patterns
59
– Die Schutzziele können ebenfalls variieren. Jeder Eigentümer einer bestimmten IT-Ressource kann für sich andere Schutzziele priorisieren. Dies kann dann ebenfalls dazu führen, dass eine neue Lösung notwendig wird. – Neue Angriffe können bekannt werden, z.B. durch die Verfügbarkeit neuer Technologien, die dann wiederum die Beschaffenheit der Lösung beeinflussen. – Andere Maßnahmen, um sich gegen die innerhalb des Security Patterns beschriebenen Angriffe zu schützen, sind ebenfalls möglich. Die Maßnahmen beschreiben eine technische Realisierung eines Schutzzieles. Es ist grundsätzlich möglich, mithilfe verschiedener Maßnahmen ein angestrebtes Schutzziel zu erreichen. Die gewählten Maßnahmen, mit denen ein Schutz realisiert wird, hängen im Wesentlichen von den definierten Schutzzielen, den Anforderungen, den verfügbaren technischen Methoden sowie dem geltenden Kontext ab. Nachdem sichergestellt ist, dass die inneren Abhängigkeiten der einzelnen PatternKomponenten eines Security Patterns berücksichtigt wurden, müssen die externen Abhängigkeiten immer wieder geprüft werden. Die Betrachtung der externen Abhängigkeiten ermöglicht es, Aussagen über den Sicherheitszustand eines durch Security Patterns beschriebenen Szenarios zu geben. In diesem Zusammenhang sind folgende externe Beeinflussungen denkbar: – Ein Security Pattern X, das im Lösungsabschnitt die Verschlüsselung einer Kommunikationsstrecke beschreibt, wird in der Regel auf ein Security Pattern Y aufbauen, das einen Verschlüsselungsalgorithmus beschreibt. Ist diese Abhängigkeit bekannt, so ist sofort klar, dass der Schutz durch X nicht mehr gegeben ist, wenn Y intern nicht mehr konsistent ist (z.B. durch Entdeckung einer neuen Angriffsmethode). – Treten in einem Security Pattern X Inkonsistenzen auf, so lässt sich daraus folgern, dass diese Inkonsistenz auch in allen Security Patterns auftritt, die X spezialisieren. Beschreibt X beispielsweise generell ein „Virtual Private Network“ und Y stellt die Spezialisierung von X dar (z.B. ein PPTP-basiertes VPN), so führt eine Inkonsistenz in X auch zu einer Inkonsistenz von Y. Zu einer solchen Inkonsistenz in X kann beispielsweise eine falsche Annahme bei der Definition des Kontextes führen. Die Kenntnis von externen Abhängigkeiten eines Security Patterns X von einem Anti-Security Pattern Y kann ebenfalls verwendet werden, um eine Aussage über den Sicherheitszustand eines durch das Pattern X beschriebenen Szenarios zu erhalten. Beschreibt das Security Pattern X beispielsweise die Verschlüsselung eines Kommunikationskanals und das Anti-Security Pattern Y die Verwendung schlechter Passwörter, so kann X im Zusammenhang mit Y keine sichere Lösung beschreiben.
60
2 Grundlagen
Interne und externe Abhängigkeiten müssen bei der Dokumentation eines Security Pattern beachtet werden. Ein Security Pattern stellt daher eine Momentaufnahme dar. Ein wesentlicher Punkt bei der Verwendung von Security Patterns ist die Tatsache, dass sich ein Security Pattern ändern kann. Security Patterns müssen daher in einen kontinuierlichen Anpassungskreislauf eingebettet sein. 2.3.4 Ausgewählte Beispiele für Security Patterns Heute ist eine ganze Reihe von einzelnen Security Patterns und Pattern-Systemen bekannt. Um die Grundlagen von Security Patterns zu verdeutlichen, zeigen wir im Folgenden ausgewählte Beispiele. Eine aktuelle Liste der bisher veröffentlichten Arbeiten befindet sich in [105].
Security Patterns für die Sicherheit auf Anwendungsebene Die Pionierarbeiten wurden von Yoder und Barcalow geleistet. Im Jahr 1997 stellten sie Security Patterns vor [136], mit denen sichere Anwendungen entwickelt werden können. In Abbildung 2-9 werden die Zusammenhänge zwischen diesen Security Patterns, die wir an dieser Stelle kurz vorstellen, dargestellt. – Einzelner Zugangsweg Es ist schwierig, eine Anwendung abzusichern, die prinzipiell beliebig viele Zugangspunkte hat. Als Lösung hat sich daher die Beschränkung auf einen einzelnen Zugangsweg bewährt. – Prüfstelle Verschiedene Anwender haben unterschiedliche Sicherheitsanforderungen. Nun tritt das Problem auf, wie diese unabhängig von dem Entwurf der Anwendung realisiert werden können. Als Lösung wird die Kapselung eines entsprechenden Verfahrens, das die Sicherheitsanforderungen eines Unternehmens umsetzt, vorgeschlagen. – Rollen Die Verwaltung von Benutzern, die jeweils unterschiedliche Rechte haben, ist ab einer gewissen Menge nicht mehr handhabbar. Mithilfe von Rollen wird daher eine Gruppierung von Benutzern mit vergleichbaren Rechten vorgenommen. – Sitzungen Verschiedene Module einer Anwendung benötigen Zugriff auf sicherheitsrelevante Informationen, wie z.B. die Benutzeridentität. Es hat sich bewährt, solche Informationen global mithilfe eines Sitzungskonzeptes zu kapseln und abhängig von den Rechten eines Benutzers lokal zugreifbar zu machen.
2.3. Security Patterns
61
– Volle Ansicht mit Fehlermeldungen Benutzer dürfen Operationen nur dann aufrufen, wenn sie die entsprechenden Rechte besitzen. Abhängig von diesen Rechten können daher Fehlermeldungen angezeigt werden, sobald versucht wird, illegale Operationen aufzurufen. – Limitierte Ansicht Eine alternative Lösung ist es, dem Benutzer entsprechend seiner Rechte lediglich die Operationen anzubieten, die er durchführen darf. Sichere ZugangsschichtAnwendungen können nur so sicher sein wie ihre Umgebung. Auf Basis von externen Sicherheitsmechanismen (etwa auf Ebene von Betriebssystem, Netzwerk oder Datenbanken) sollte daher eine sichere Zugangsschicht aufgebaut werden, die Nachrichten von und zu der Anwendung schützen. Einzelner Zugangsweg
Prüfstelle erzeugt, nutzt
hängt ab von
Sichere Zugangsschicht
erzeugt
Sitzungen definieren Limitierte Ansicht
Rollen
haben definieren
Volle Ansicht mit Fehlern
Abb. 2-9 Security Patterns auf Anwendungsebene
Security Patterns für kryptografische Software Einen weiteren Meilenstein stellt die Arbeit von Braga et al. dar. Im Fokus steht hier die Kryptografie als klassisches Gebiet der IT-Sicherheit. In diesem Zusammenhang behandelt die Sammlung von insgesamt neun Security Patterns die Entwicklung von kryptografischen Software-Komponenten [19]. Dabei liegt der Fokus auf den tradi-
62
2 Grundlagen
tionellen Sicherheitsmerkmalen, d.h. Vertraulichkeit, Integrität, Authentizität und Nicht-Abstreitbarkeit. Das Security Pattern „Geheimhaltung von Informationen“ beschreibt, wie die Vertraulichkeit von Nachrichten gewahrt werden kann. Das Security Pattern „Integrität von Nachrichten“ zeigt, wie ohne die Hilfe von vorher ausgetauschten kryptografischen Schlüsseln verhindert werden kann, dass ein Angreifer Nachrichten ändert oder ersetzt. Das Security Pattern „Authentisierung von Nachrichten“ verdeutlicht, wie Nachrichten unter Verwendung von kryptografischen Schlüsseln authentisiert werden können. Weiterhin beschreibt das Security Pattern „Authentisierung des Absenders“, wie verhindert werden kann, dass einer der Kommunikationspartner den Empfang oder das Versenden einer Nachricht abstreiten kann. Auf Basis dieser vier generischen kryptografischen Security Patterns werden die übrigen Security Patterns wie z.B. „Geheimhaltung mit Integrität“ oder „Geheimhaltung mit Authentisierung“ abgeleitet. Kryptografisches Meta-Pattern
Authentisierung von Nachrichten
Authentisierung des Absenders
Geheimhaltung von Informationen
Geheimhaltung mit Authentisierung Geheimhaltung mit Signatur
Integrität von Nachrichten
Signatur mit Anhang Geheimhaltung mit Integrität
Geheimhaltung mit Signatur mit Anhang Abb. 2-10 Security Patterns für kryptografische Software
2.3. Security Patterns
63
Zusammen bildet diese Sammlung die „Generic Object-Oriented Cryptografic Architecture“ (GOOCA), die in Abbildung 2-10 dargestellt wird. Es handelt sich dabei um reine Spezialisierungen übergeordneter Security Patterns. Interessant ist auch die Verwendung eines Meta-Patterns, das gewissermaßen den Wurzelknoten in dem Security Pattern-System bildet. Wir werden später von diesem Konzept auch Gebrauch machen. Authentisierung von Prozessen Die von Brown et al. präsentierte Arbeit beschreibt detailliert ein einzelnes Pattern, das einen anfragenden Prozess authentisiert, bevor über den Zugang zu einem verteilten Objekt entschieden wird [15]. Die Autoren haben zudem Beziehungen zu Security Patterns für die Zugangskontrolle identifiziert. Dies ist somit eine der ersten Arbeiten, die Security Patterns in anderen Dokumenten zumindest textuell referenzieren. Security Patterns für die Zugriffskontrolle Eine Reihe von Beiträgen beschreib verschiedene Lösungen für die Zugangskontrolle. So werden beispielsweise Sicherheitsfunktionen für die Authentisierung, die Zugriffskontrolle und das Filtern von Daten in einer verteilten Umgebung zu einem Rahmenwerk kombiniert. Dabei werden im Einzelnen die folgenden (Security) Patterns verwendet: Data Filter [50], Bodyguard [82], RPC Client [59] und das bereits erwähnte Authenticator Security Pattern. Zusammen mit einer Struktur für ein Sicherheitsmodell bilden diese Patterns das „Object Filter and Access Control Framework“. Fernandez diskutiert weitere Security Patterns für die Zugriffskontrolle, nämlich „Zugriffskontrollregeln“ und „Rollenbasierte Zugriffskontrolle“ [47]. Das Neue dabei ist, dass vorgeschlagen wird, mithilfe von Metadaten Nebenbedingungen festzulegen, um Zugangskontrollregeln zu definieren. Außerdem werden, basierend auf dem „Schichten“-Pattern (siehe Buschmann et al. [16]), konzeptuelle Ebenen definiert, wobei auf jeder Ebene jeweils unterschiedliche Sicherheitsmechanismen und Verfahren zur Erzwingung von Sicherheit (engl. Enforcement) zum Tragen kommen. Auf der bisher beschriebenen Basis wird eine Menge von Security Patterns für Sicherheitsmodelle beschrieben [48]. Dabei finden sich Lösungen in Form von etablierten Sicherheitsmodellen. Das Pattern „Autorisierung“ basiert auf Zugriffskontrolllisten, das Pattern für „Mehrstufige Sicherheit“ basiert auf den Theorien von Bell-LaPadula. Außerdem wird das bereits erwähnte Pattern für „Rollenbasierte Zugriffskontrolle“ integriert. Es wird gezeigt, wie diese generischen Patterns auf allen Ebenen des Schichtenmodells angewendet werden können.
64
2 Grundlagen
2.3.5 Kategorisierung von Security Patterns Die Arbeiten auf dem Gebiet von Security Patterns entwickeln sich kontinuierlich weiter. Wie wir beschrieben haben, ist heute eine Mischung aus einzelnen Patterns, Frameworks, Pattern Languages usw. verfügbar. Security Pattern-Systeme bilden eine Menge von zueinander in Beziehung stehenden Security Patterns, die es gemeinsam ermöglichen, ein Problem höherer Komplexität zu lösen. Insbesondere im Bereich der IT-Sicherheit ist es aber sehr wichtig, verschiedene Abstraktionsstufen und Blickwinkel auf eine IT-Ressource zu haben. Eine entsprechende Kategorisierung erleichtert z.B. das Suchen und Finden von geeigneten Lösungen in größeren Mengen von Security Patterns. Werden beispielsweise die Security Patterns im vorangegangenen Abschnitt in einem größeren Security Pattern-System zusammengefügt, wird bereits deutlich, dass eine Kategorisierung auch dabei helfen kann, die Übersicht zu wahren. Im Folgenden stellen wir gängige Ansätze zur Kategorisierung von Security Patterns, die auch kombiniert werden können, kurz vor. Schichtenmodell Fernandez hat erkannt, dass Security Patterns oftmals in verschiedene Schichten eingeteilt werden können [47,48]. Dies sei ein Spezialfall des konzeptuellen „Schichten“-Patterns [16]. Er schlägt eine Alternative vor, die betont, wo die entsprechende Information verarbeitet wird. In Abbildung 2-11 werden diese Schichten illustriert. Auf der höchsten Ebene werden relevante Klassen einer Anwendung definiert („Metaebene). Danach kommt eine Schicht, die aktive Objekte dieser Klassen zu einem bestimmten Zeitpunkt enthält. Auf der Systemebene wird eine Ausführungsumgebung, zu der auch Betriebssysteme und Datenbank-Managementsysteme gehören, bereitgestellt. In der Verteilungsschicht werden die Prozesse und Objekte auf verschiedene Knoten verteilt. Zu jedem Knoten gehören auf der Hardware-Ebene eine oder mehrere CPUs, die mittels bestimmter Protokolle durch ein Netzwerk verbunden sind. In diesem Buch verwenden wir ebenfalls solch einen Ansatz, allerdings orientieren wir uns analog zu der Konzeption des Hacker Contest an dem TCP/IP-Schichtenmodell (siehe Abschnitt 2.2.2).
2.3. Security Patterns
65
X
Klassen
Y Metaebene
Z
Objekte
x:X
y:Y Anwendungsebene
z:Z
Ausführende Prozesse
Knoten 1
x.p1
x.p1
y.p1
y.p1
z.p1
Systemebene
z.p1 VerteilungsKnoten 2 ebene
CPU 1
CPU 2
CPU 3
Protokolle {
HardwareEbene
Abb. 2-11 Kategorisierung nach Schichten
Abstraktionsniveau Häufig wird nach der Abstraktionsstufe der Patterns kategorisiert. Dabei wird zwischen konzeptuellen Patterns (die Systemarchitektur betreffend), Design Patterns und Idiomen unterschieden: – Konzeptuelle Patterns (engl. Architectural Patterns) beziehen sich auf die grundlegende Systemstruktur und somit auf die wesentlichen Eigenschaften des Systems. Sie finden in der Angangsphase der Entwicklung eines IT-Systems Anwendung, wenn es darum geht, das System in Komponenten zu zerlegen und komponentenübergreifende Strukturen zu definieren. Ein Beispiel ist die Zugriffskontrolle auf Anwendungsebene. Dabei geht es grundsätzlich darum, den Objektzugriff in Abhängigkeit vom angemeldeten Benutzer einzuschränken. Dies muss jedoch komponentenübergreifend, d. h., in allen Modulen des Systems geschehen und ist daher eine wesentliche Systemeigenschaft. Wird dies in der
66
2 Grundlagen
Planungsphase vergessen, ist ein nachträgliches Ergänzen sehr schwierig, da das gesamte System überarbeitet werden muss. Erschwerend kommt hinzu, dass Zugriffskontrolle von der Benutzeranmeldung abhängig ist, die dann vielleicht ebenfalls modifiziert werden müsste. – Design Patterns liegen eine Abstraktionsstufe tiefer, denn sie beziehen sich auf den Entwurf einzelner Komponenten. Fehler an dieser Stelle wirken sich zwar nicht so gravierend wie auf der konzeptuellen Ebene aus, aber auch hier ist es von Vorteil, bereits für einzelne Komponenten Lösungsansätze zu kennen. Da der Entwurf einzelner Komponenten sich nach der Architektur des Systems richtet, dürfen Design Patterns mit den konzeptuellen Patterns nicht im Konflikt stehen. Die Beschreibung von Design Patterns kann beispielsweise Objekte, Klassen, Vererbungsdiagramme etc. enthalten. – Idiome sind Lösungsansätze auf einer Implementierungsebene. Sie befassen sich damit, Probleme bezüglich der Programmierung zu lösen. Ziel ist es, Algorithmen anzugeben, wie einzelne Aufgaben, die weder konzeptueller Art sind noch das Design einzelner Komponenten betreffen, gelöst werden können, also beispielsweise das Sortieren einer Liste, Speicherverwaltung oder das Senden einer E-Mail. Kategorisierung nach Schlüsselwörtern Alternativ zur Kategorisierung anhand des Abstraktionsniveaus ist es möglich, einen eher feingranularen und strukturierten Ansatz mit Name-Wert-Paaren zu verfolgen. Im Folgenden stellen wir Vorschläge für mögliche Dimensionen für eine derartige Kategorisierung vor [133]. Es bestehen hier Beziehungen zwischen den einzelnen Kategorien, und es ist auch möglich, dass es für bestimmte Kategorien mehrere gültige Werte geben kann. Ein wichtiges Kriterium ist der Zeitpunkt, zu dem ein Security Pattern angewendet werden kann. In diesem Zusammenhang kann der Lebenszyklus eines ITSystems herangezogen werden, d.h., es sollen beispielsweise Sicherheitsprobleme bei Planung, Analyse, Entwurf, Implementierung, Integration oder Einsatz eines ITSystems gelöst werden. Ein weiterer Punkt ist, welcher Aspekt des Problemraums von einem Security Pattern angesprochen wird. Dies betrifft sowohl die physikalische, organisatorische und technische Sicherheit als auch die Regeln, die in einer Organisation gelten. Schließlich kann noch der Wirkungsbereich (engl. Scope) des Security Patterns angegeben werden. Beispiele hierfür sind, ob es grundsätzlich immer angewendet werden kann oder ob es sich beispielsweise um ein rein akademisches oder um ein domänenspezifisches Security Pattern handelt.
2.3. Security Patterns
67
2.3.6 Zusammenfassung In diesem Abschnitt haben wir das Konzept der Security Patterns vorgestellt. Wir haben dabei zunächst ausgewählte Methoden und Werkzeuge für das System Security Engineering analysiert. Dies hat ergeben, dass der Faktor Mensch typischerweise nicht im Vordergrund steht, d.h., die Verfahren sind üblicherweise zu aufwändig und zu komplex, um von Laien angewendet werden zu können. Diese und andere Faktoren haben uns dazu bewogen, Security Patterns als Ergänzung zu diesen Verfahren vorzuschlagen. Security Patterns beschreiben bewährte Lösungen für wiederkehrende Sicherheitsprobleme. Dies sind insbesondere Bedrohungen, Verletzlichkeiten und Angriffe, die die Sicherheit von IT-Ressourcen gefährden. Lösungen stellen demnach Maßnahmen dar, die das Risiko auf ein vertretbares Minimum reduzieren. Dies reflektiert auch genau das Konzept des Hacker Contest, wo sich Angreifer und Eigentümer von IT-Ressourcen in verschiedenen Szenarien gegenüberstehen. Daher eignen sich Security Patterns auch besonders gut, um die technischen Ergebnisse des Hacker Contest systematisch dokumentieren zu können. Security Patterns werden von Experten dokumentiert und können von Laien – im Idealfall ohne tieferes Hintergrundwissen im Bereich Sicherheit – verwendet werden. Da Security Patterns nicht isoliert voneinander existieren, sondern vielmehr Beziehungen zu anderen Security Patterns bestehen, hilft dieser Ansatz dabei, Probleme strukturiert und vollständig erfassen und lösen zu können – vorausgesetzt, die Menge der Security Patterns ist korrekt und vollständig. Auf die interne und externe Konsistenz muss daher beim Schreiben von Security Patterns besonders geachtet werden. Um die Grundlagen von Security Patterns verdeutlichen zu können, haben wir ausgewählte Beispiele von Security Patterns vorgestellt. Dabei wurde ersichtlich, dass ein weiteres Problem auftritt, wenn die Menge der Security Patterns eine gewisse Anzahl überschreitet. Aus diesem Grund ist es sinnvoll, eine Kategorisierung von Security Patterns vorzunehmen. Hierfür haben wir verschiedene Ansätze, die auch kombiniert werden können, vorgestellt. Abschließend möchten wir kurz darauf eingehen, was ein Pattern im Allgemeinen ausmacht, und auch, was der Pattern-Ansatz nicht leisten kann. Eigenschaften von Patterns Doug Lea hat eine Checkliste für das Schreiben von guten Patterns veröffentlicht [69]. Die wichtigsten Punkte dieser Liste wollen wir kurz diskutieren. An erster Stelle steht sicherlich, dass ein Pattern eine konstruktive Lösung beinhaltet. Patterns sind niedergeschriebene Erfahrungen von Experten, die praktisch anwendbar sein sollen. Patterns sollten daher auch Schritte oder Regeln enthalten, die beschreiben, wie die entsprechende Lösung umgesetzt werden kann. Weiterhin beschreiben die Patterns die Anforderungen, die bei einem bestimmten Problem in einem bestimm-
68
2 Grundlagen
ten Kontext auftreten. Darüber hinaus sollte auch gezeigt werden, wie die Lösung diese Anforderungen, die sich teilweise auch widersprechen können, erfüllt. Ein weiterer wichtiger Aspekt ist, dass Patterns mindestens einmal erfolgreich angewendet worden sein sollten. Bei Patterns auf höheren Abstraktionsebenen kann sogar gezeigt werden, dass eine allgemeine Lösung in verschiedenen Szenarien anwendbar ist. Schließlich ist es besonders wichtig, dass Patterns auch auf andere Patterns verweisen. Dabei sollten insbesondere die Beziehungen Spezialisierung und Voraussetzung berücksichtigt werden. Grenzen des Security Pattern-Ansatzes Analog zu obiger Checkliste können auch Aussagen getroffen werden, was der Ansatz mit Patterns (und damit auch Security Patterns) nicht leisten kann: – Patterns sind weder unausgereifte Ideen und Theorien noch neue Erfindungen. In diesen Fällen kann nämlich nicht von einer bewährten Lösung gesprochen werden. Dementsprechend sind Patterns naturgemäß auch keine Lösungen, die nur einmal funktioniert haben. In diesem Zusammenhang muss auch festgehalten werden, dass Patterns keine abstrakten Prinzipien oder Heuristiken sind, sie müssen vielmehr ohne Umwege in der Praxis anwendbar sein. – Es ist weiterhin grundsätzlich möglich, beliebige Dokumente im Pattern-Format zu schreiben. Hier handelt es sich aber nicht notwendigerweise um Patterns, das Dokument muss die oben aufgeführten Eigenschaften erfüllen. – Patterns sind keine Lösungen in beliebigen Kontexten. Kontext, Problem und Anforderungen legen die Lösung eindeutig fest. Abschließend möchten wir darauf hinweisen, dass auch Patterns kein Allheilmittel für die bisher beschriebenen Probleme im Bereich IT-Sicherheit sind. Sie sollten allerdings als Ergänzung zu den Methoden und Werkzeugen des System Security Engineering gesehen werden. Dabei steht der Faktor Mensch im Vordergrund, d.h., insbesondere Laien sollten in der Lage sein, IT-Ressourcen zu entwerfen und zu betreiben und dabei die richtigen Schutzmaßnahmen zu ergreifen.
2.3. Security Patterns
69
Hacker und Cracker
3
Abb. 3-0 Tabelle 3-0 Eine vollständige Abhandlung über Hacker und Cracker würde den Rahmen dieses Buches sprengen. Da es jedoch für das Verständnis der Sicherheit von IT-Ressourcen relevant ist, wollen wir Grundlegendes über Hacker und Cracker nicht vorenthalten. Was ist eigentlich der Unterschied zwischen Hackern und Crackern? Gibt es überhaupt einen? Diese Fragen wollen wir zuerst versuchen zu beantworten. Eine einfache Definition der Begriffe, ein kurzer Einblick in die Geschichte der Hacker und Cracker, ihre Ethik. Ein paar der interessantesten Hacks der Geschichte sollen dabei helfen. Anschließend wird versucht, die Motivation von Hackern und Crackern für ihr Handeln zu ergründen.
3.1 Hacker und Cracker Es vergeht kaum eine Woche, in der nicht eine Zeitung oder ein Nachrichtenmagazin eine Schauergeschichte über Hacker zu berichten weiß. So sicher, wie man sich sein kann, dass die nächste Meldung über Hacker nicht lange auf sich warten lässt, so sicher kann man sein, dass sich die Hacker-Gemeinde über die sorglose Begriffswahl der Medien empört. Was steckt eigentlich hinter dem Begriff „Hacker“? Ist es wirklich der böse Jugendliche, der in den Medien als eine Gefahr für die Gesellschaft und das System dargestellt wird? Eine Definition des Begriffs „Hacker“ findet sich im so genannten „Jargon-File“, dem Wörterbuch der Hacker. Das Jargon-File entstand in den 50er-Jahren am Massachusetts Institute of Technology (MIT) und wird von freiwilligen Redakteuren permanent auf dem neuesten Stand gehalten [63]. Der Begriff „Hacker“ wird darin wie folgt definiert: – hacker/ n./ [originally, someone who makes furniture with an axe] 1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. 2. One who programs enthusiastically (even obsessively) or who
M. Schumacher et al., Hacker Contest © Springer-Verlag Berlin Heidelberg 2003
3.1. Hacker und Cracker
71
enjoys programming rather than just theorizing about programming. 3. A person capable of appreciating {hack value}. 4. A person who is good at programming quickly. 5. An expert at a particular program, or one who frequently does work using it or on it; as in 'a Unix hacker'. (Definitions 1 through 5 are correlated, and people who fit them congregate.) 6. An expert or enthusiast of any kind. One might be an astronomy hacker, for example. 7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations. 8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence 'password hacker', 'network hacker'. The correct term for this sense is {cracker}. Der Jargon-File stellt das Programmieren von Computern in das Zentrum der Definition. Das Wort „Hacker“ beschreibt also einen Spezialisten oder Guru, der alle Haken und Ösen, Ecken und Kanten eines Betriebssystems kennt. Kein langweiliger Software-Ingenieur, sondern ein kreativer Programmierer, der seinen Rechner besser kennt als der normale Durchschnittsanwender. Ein Hacker ist jemand, den die intellektuelle Herausforderung lockt, Beschränkungen von Rechnern und Systemen zu überwinden. Er identifiziert sich mit dem Computer und ist erst dann zufrieden, wenn dieser genau so arbeitet, wie er es will. Der „echte“ Hacker versteht sich als Pionier, Programmier- und Netz-Magier. Hacker bauten das Internet, brachten das World Wide Web (WWW) zum Laufen, machten das Unix-Betriebssystem zu dem, was es heute ist, und vieles mehr. Da ein Hacker eine Person ist, die sich für die innersten Arbeitsweisen eines Rechners interessiert, viel über Betriebssysteme und Programmiersprachen weiß, ist er in der Lage, Sicherheitslöcher in den Systemen zu finden und die Ursachen dafür zu entdecken. Hacker sind ständig auf der Suche nach neuem Wissen und teilen ihre Entdeckungen Interessierten mit. Sie würden niemals absichtlich Daten zerstören. Es ist verständlich, dass sich die „wahren“ Hacker von den in den Medien dargestellten „destruktiven“ Hackern distanzieren möchten, denn sie sind die eigentlichen Pioniere der Informationstechnologie. Diese „destruktiven“ Hacker werden deshalb zur eindeutigen Unterscheidung von der Hacker-Gemeinde als „Cracker“ oder „Cyberpunk“ bezeichnet. Diese Distanzierung der Hacker von den Crackern findet sich auch in der Definition von Hacker wieder und zieht sich auch sonst durch das ganze Jargon-File. Ein Hacker hält sich – im Gegensatz zum Cracker – an die Hacker-Ethik (siehe Abschnitt 2.3), ihrem Ehrenkodex. Im Jargon-File wird für den Begriff „Cracker“ folgende sehr kurze Definition gegeben: – cracker/ n./ One who breaks security on a system. Coined ca. 1985 by hackers in defense against journalistic misuse of {hacker} (q.v., sense 8). An earlier attempt to establish 'worm' in this sense around 1981–82 on Usenet was largely a failure.
72
3 Hacker und Cracker
Ein Cracker ist also ein Computer-Freak, der sich mit dem bloßen Überwinden fremder Sicherungssysteme nicht zufrieden gibt, sondern sein Wissen dazu nutzt, in anderen Systemen Schäden anzurichten. Die Absichten eines Crackers sind immer böswillig. Wirkliche Hacker halten Cracker für ein „faules, unverantwortliches und nicht besonders schlaues Pack“. Kurz und bündig formuliert: „Hacker bauen Dinge auf, und Cracker zerstören diese.“
3.2 Geschichte der Hacker und Cracker Die erste Generation von Hackern entwickelte sich in den 50ern und in den Anfängen der 60er-Jahre, als die ersten Maschinen mit Tastatur und Bildschirm für jedermann zur Verfügung standen. Bald gab es einige Studenten, die von den Möglichkeiten dieser neuen Maschinen so fasziniert waren, dass sie nächtelang davor saßen und versuchten, Programme zu schreiben und die neue Technik bis an die Grenzen des Möglichen auszunutzen. Eine Hochburg dieser Szene entwickelte sich am berühmten „Tech Model Railroad Club“ („Eisenbahnclub“) des Massachusetts Institute of Technology (MIT) in Boston, USA [128]. Studenten, die zuvor schon die Telefonschaltnetze und Kontrollsysteme erkundet hatten, wurden durch die dort vorhandenen ersten Rechner angelockt. Der damalige Direktor, Marvin Minsky, hatte Verständnis für ihren Entdeckerdrang und ließ sie gewähren. Diese Studenten und Mitarbeiter, darunter Peter Deutsch, Bill Gosper, Richard Greenblatt, Tom Knight, und Jerry Sussman, wurden als die ersten Hacker bezeichnet. Unter dem Begriff verstand man damals „Personen, denen es Spaß machte, die Details eines programmierbaren Systems zu erforschen und dessen Möglichkeiten zu erweitern“. Die Bezeichnung Hacker war zu dieser Zeit eine hohe Auszeichnung und hart erarbeitet, denn die Maschinen waren groß, langsam, schwer zu bedienen, und es kostete außergewöhnliche Anstrengung, einfachste Berechnungen durchführen zu lassen. Es ist kein Zufall, dass die Hacker-Kultur ihren Ausgang am berühmten MIT hatte, eine der Eliteuniversitäten in den USA [127]. Den Studenten stand ein PDP-1 von der Firma Digital Equipment Corporation zur Verfügung. Im Gegensatz zu den bis dahin üblichen IBM-Großrechnern war es mit dem PDP-1 zum ersten Mal möglich, direkt mit dem Rechner zu arbeiten. Die Studenten konnten die Programme bei deren Abarbeitung beobachten, die Programme testen, während sie liefen und die Fehler direkt beheben. Sie erfanden etliche neue Programmiertricks, entwickelten unter anderem das erste Spiel („Spacewar“) und den Joystick. Obwohl die Studenten teilweise ihr Studium vernachlässigten, ließ die liberale Fakultät sie gewähren. Ihre Fähigkeiten wurden mit der Zeit so bekannt, dass sie sogar den Auftrag erhielten, an der Entwicklung des PDP-6 mitzuarbeiten. Mit der Verbreitung der Rechner entstanden auch weitere Zentren der Hacker- Kultur. Zu den ersten zählte die Carnegie Mellon University sowie die Stanford University, aber auch Firmen wie AT&T und Xerox. Zu dieser zweiten Generation von Ha-
3.2. Geschichte der Hacker und Cracker
73
ckern in der Mitte der 60er-Jahre zählten unter anderem die legendären Ed Fredkin, Brian Reid, Jim Gosling, Brian Kernighan, Dennis Ritchie und Richard Stallman. Die Wiege der dritten Hacker-Generation liegt im nördlichen Kalifornien. Im Homebrew Computer Club in der San Francisco Bay Area hatte sich eine Gruppe von Experten mit der Idee zusammengefunden, ihre eigenen Rechner zu bauen. Bis zu diesem Zeitpunkt waren die Rechner so groß und teuer, dass nur Firmen oder größere Einrichtungen darüber verfügten. Begeisterte Computer-Freaks waren auf diese wenigen Maschinen beschränkt, die sie mit vielen teilen mussten. Sie wollten nun endlich ihre eigenen Maschinen, die sie auch zu Hause programmieren konnten. Es war diese Gruppe von Hackern, zu denen legendäre Figuren wie Lee Felsenstein, Steve Dompier, Steve Wozniak, Steve Jobs und Bill Gates gehören, die den Grundstein für die Entwicklung des heutigen Personal Computers legten. Die eigentliche Netz-Revolution begann, als man die Rechner per Telefonnetz miteinander verbinden konnte. Mit dem Vorläufer des Internets, dem Arpanet, eröffneten sich für die Computer-Freaks weitere faszinierende Möglichkeiten. Sie benötigten einen einfachen Heim-Computer, ein Modem und einen Telefonanschluss. Hacker waren nun Datenreisende, die Spaß daran hatten, die neuen, globalen Datennetze zu erforschen und miteinander zu kommunizieren, ohne jemandem Schaden zuzufügen. Der Begriff „Joy-Riding“ wurde geprägt. Da das damalige Netz zum einfachen Austausch von Daten konzipiert worden war, waren die Hürden, die genommen werden mussten, um an die Daten auf fremden Rechnern zu kommen, nicht hoch bzw. nicht vorhanden. Dass der Zugriff auf fremde Maschinen und Daten unter den Hackern nicht als etwas Verwerfliches angesehen wurde, lag daran, dass sich in der Gemeinschaft früh eine Art von „Informationssozialismus“ entwickelt hatte: die Bereitschaft, Informationen, Wissen und Erfahrungen untereinander auszutauschen. Angelehnt an die „Woodstock-Generation“ forderten die Hacker den unbegrenzten Zugang zu Computern, freie Informationen und Dezentralisierung. Staatlicher Autorität wie Politik und Militär galt es von Grund auf zu misstrauen. Sie folgten dem Leitsatz „Information wants to be free“ und glaubten fest an die Möglichkeit, mithilfe des Computers die Welt zu verbessern. Hinter allem standen die Ideale, an einer gemeinsamen Sache zu arbeiten, Aufgaben zu bewältigen und seine Freiheit zu verteidigen. Dazu zählte nicht nur der Austausch von Wissen in codierter Form, sondern auch der freie Gebrauch von Software und Dokumentation, also Dinge, die heutzutage als „geistiges Eigentum“ gehandelt werden. In der ersten Generation der Computer und Hacker waren die Programme weitestgehend frei zugänglich gewesen und wurden üblicherweise von vielen Leuten gleichzeitig in verschiedenen Richtungen weiterentwickelt. Mit dem Voranschreiten der Kommerzialisierung der Software-Industrie war diese allgemeine Zugänglichkeit von Programmen verschwunden. Es begann ein regelrechter kalter Krieg um die Ressource Information. Neben der Hacker-Szene hatte sich seit Ende der 60er-Jahre die „Phreaker“-Kultur entwickelt. Das Ziel der „Phreaks“ (Phone-Freaks) war es, anfangs noch ohne Computer, den Telefongesellschaften „eins auszuwischen“, indem sie kostenlos um die Welt telefonierten und zu ihrer Unterhaltung Telefonkonferenzen schalteten. Da das Reisen der Hacker im Datennetz kostspielig war, vereinigten sich bald beide
74
3 Hacker und Cracker
Kulturen, und es entstand eine neue Hacker-Subkultur. Das primäre Ziel dieser neuen Hacker-Kultur war noch immer Spaß zu haben, große Maschinen zu erforschen, zu manipulieren und für den eigenen Zweck zu nutzen, doch nun auf Kosten der Telefongesellschaften oder auch anderer Benutzer. Die „Hacker-Ethik“ war nicht allen heilig. War die Moral der Hacker durch die Phreaker schon aufgeweicht, wurde nun aus den verschiedensten Gründen das Wissen und Können zur Beschaffung und Manipulation von Daten eingesetzt. Wirtschaftlicher Schaden entstand. Mit der Ausbreitung des Kommunikationsnetzes und der Kommerzialisierung wuchsen auch die „Sicherheitsmechanismen“ der Rechner. Durch das Einführen von Passwörtern und Zugriffskontrollen waren die Hacker nun gezwungen, sich auf weniger feine Arten den Zugang zu den Rechensystemen zu beschaffen. Das wurde ihnen aber meist nicht besonders schwer gemacht. Einfachste Attacken wie Ausspähen von Passwörtern am Arbeitsplatz, Durchwühlen des Mülls von Rechenzentren oder das beliebte „Social Engineering“ waren sehr oft erfolgreich. So passiert auch 1967 in der Wiege der Hacker, dem MIT. Auf Druck des amerikanischen Verteidigungsministeriums sollte am MIT der Zugriff auf den Großrechner durch Passwörter eingeschränkt werden. Die Studenten waren wenig begeistert und reagierten unter anderem mit Sabotage. Sie veröffentlichten Passwörter und ein selbst geschriebenes Programm, welches das Betriebssystem des Großrechners zum Absturz brachte. Der Begriff Hacker bekam so auch hier schon sehr früh eine subversive Ausrichtung. Das Thema „Hacken“ wurde immer brisanter. Anfang der 80er-Jahre von der Presse und der Filmindustrie aufgegriffen, führten die verschiedenen Berichte und Filme zu einem neuen Hacker-Bild in der Öffentlichkeit. Bekannteste „Hacks“ wie der KGB-Hack, der VMS-Source-Code-Klau bei DEC, der NASA-Hack oder der Btx-Hack, hochgespielt durch die Medien, erschütterte die Gesellschaft und deren Glauben an die Allmacht der Technologie. In der öffentlichen Meinung war der Hacker zu einem böswilligen Eindringling mutiert, der versucht, sensible Daten zu stehlen, zu veröffentlichen oder gar zu manipulieren. Er stellt damit eine Gefahr für die Gesellschaft und den Staat dar. Trotz aller Versuche der Hacker-Gemeinde ist es nicht gelungen, das ursprüngliche Bild des Hackers wieder zu erlangen. Hacker und Cracker werden in den Medien unter dem gleichen Begriff – nämlich Hacker – subsumiert. Die Leistungen und Errungenschaften der wahren Hacker werden dadurch leider (zumindest teilweise) in ein falsches Bild gerückt.
3.3 Die Hacker-Ethik Früh bildeten sich in der Hacker-Gemeinschaft ein ungeschriebenes Gesetz heraus, das ihre Ideologien widerspiegelte und als „Hacker-Ethik“ bekannt wurde [51,127]. Das Wort Ethik leitet sich vom dem griechischen Wort „thos“ ab. Eine Übersetzung lautet: Gewohnheit, Herkommen und Sitte. Es ist die moralische Grundlage, der Ehrenkodex, die Grundwerte der wahren Hacker.
3.3. Die Hacker-Ethik
75
Im Netz existieren die verschiedensten Versionen der Hacker-Ethik; auch ist umstritten, von wem sie ursprünglich stammt. Eine erste Version findet man in dem 1984 veröffentlichten Buch „Hackers: Heroes of the Computer Revolution“ von Steven Levy: Übersetzt lauten die Grundsätze der Ethik in etwa: – Der Zugang zu Computern und allem, was einem zeigen kann, wie diese Welt funktioniert, sollte unbegrenzt und vollständig sein. – Alle Informationen müssen frei sein. – Misstraue Autoritäten – fordere Dezentralisierung. – Beurteile einen Hacker nach dem, was er tut, und nicht nach üblichen Kriterien wie Aussehen, Alter, Rasse oder gesellschaftlicher Stellung. – Man kann mit einem Computer Kunst und Schönheit schaffen. – Computer können das Leben zum Besseren verändern. Eine neuere Definition des Begriffs „Hacker-Ethik“ findet man heute im „JargonFile“. Darin wird Hacker-Ethik wie folgt definiert: – hacker ethic/n./ 1. The belief that information-sharing is a powerful positive good, and that it is an ethical duty of hackers to share their expertise by writing open-source and facilitating access to information and to computing resources wherever possible. 2. The belief that system-cracking for fun and exploration is ethically OK as long as the cracker commits no theft, vandalism, or breach of confidentiality. Die Hacker-Ethik wurde über die Jahre viel diskutiert und erweitert. Sehr umstritten ist beispielsweise der vierte Punkt der Levy-Definition. Er fordert, dass kein Hacker wegen seines Aussehens, seines Alters, seiner Rasse oder seiner gesellschaftlichen Stellung diskriminiert werden soll, erwähnt jedoch nicht das Geschlecht. Werden damit implizit weibliche Hacker ausgeschlossen oder nur als „schlechter“ bewertet? Der Chaos Computer Club (CCC), eine Vereinigung von Computer- und Medienexperten in Deutschland, erklärte schon in den 80er-Jahren das Geschlecht zum nicht zulässigen Bewertungsmerkmal für Hacker. Er änderte bzw. ergänzte die HackerEthik um folgende Punkte: – Beurteile einen Hacker nach dem, was er tut, und nicht nach üblichen Kriterien wie Aussehen, Alter, Rasse, Geschlecht oder gesellschaftlicher Stellung. – Mülle nicht in den Daten anderer Leute. – Öffentliche Daten nützen, private Daten schützen. Auch heute befindet sich die Hacker-Ethik – wie die übrige Welt auch – ständig in der Diskussion und Weiterentwicklung.
76
3 Hacker und Cracker
3.4 Berühmte Hacker und Cracker In diesem Abschnitt werden einige der berühmtesten Hacker und Cracker und ihre Hacks kurz vorgestellt. Die Schilderungen werden zeigen, dass die Trennung zwischen Hackern und Crackern nicht immer einfach und eindeutig ist. Es wird geschildert, wie die Hacks durchgeführt, welche Sicherheitslücken ausgenutzt wurden und welche Konsequenzen – soweit bekannt – das Hacking hatte. Captain Crunch und das Blue Boxing In den 60ern entwickelte sich die Phreaker-Szene. Der Begriff „Phreak“ leitet sich von „Phone Freak“ ab. Ganz grob gesagt wird darunter das Eindringen in Kommunikations- bzw. Telefonnetze verstanden. Als einer der Pioniere und eine Legende unter den Phreaks gilt John Draper, ein Funktechniker bei der Air Force, der unter dem Namen „Captain Crunch“ oder nur „Crunch“ bekannt wurde. Sein Pseudonym leitet sich von der gleichnamigen Packung Cornflakes ab, in der er eines Morgens eine Spielzeugpfeife aus Plastik fand. Der Ton dieser billigen Pfeife war sehr hoch und lag zufällig bei 2600 Hertz. Gerade diese 2600 Hz wurden benötigt, um in den Schaltzentralen der amerikanischen Telefongesellschaften AT&T, MCI und Sprint das Signal zu geben, den Gebührenzähler eines Telefonanschlusses zu stoppen, ohne jedoch die Verbindung selbst zu beenden. Man musste also nur nach Zustandekommen einer Telefonverbindung einen Ton von 2600 Hz erzeugen und konnte anschließend kostenlos telefonieren. John Draper behielt sein Wissen nicht für sich, und so entstand das „Blue Boxing“. Da nicht jeder eine Pfeife hatte, die genau auf dieser Frequenz arbeitete, wurde die so genannte Bluebox entwickelt, ein kleines Kästchen, das auf Knopfdruck jene 2600 Hz erzeugte. Die Technik des „Blue Boxing“ funktionierte in Amerika ziemlich lange. Nach Deutschland kam die Bluebox mit der Einführung des 0130-Services der Deutschen Telekom. Nachdem der Schaden, der durch das illegale „Blue Boxing“ verursacht wurde, immer höher wurde, versuchten die Telefongesellschaften Sicherungsmechanismen einzubauen. Diese waren aber meist wenig durchdacht, so dass es nur kurze Zeit dauerte, bis durch die findigen Phreaks neue Wege gefunden wurden, diese Sicherungsmaßnahmen zu umgehen. Das Katz-und-Maus-Spiel dauerte Jahrzehnte an und war für die Telekommunikationsgesellschaften nicht immer ruhmreich. So war es bis in die Neunzigerjahre möglich, auf diese Weise kostenlos zu telefonieren [139]. Der erfolgreichste Hack von John Draper war, einmal um den ganzen Erdball mit sich selbst zu telefonieren, was sehr gute Kenntnisse über die unterschiedlichen, internationalen Telefonschaltungen erforderte. Sein Treiben blieb nicht folgenlos. Er wurde in den 70er-Jahren zweimal zu Gefängnisstrafen verurteilt. Später wurde Draper von Steve Wozniak zu Apple geholt, wo gerade der Apple II erschienen war. Das erste Mac-Textverarbeitungsprogramm „Easy Writer“ schrieb Capt’n Crunch noch als Freigänger. Er musste jeden Abend nach der Arbeit ins Gefängnis zurück. Inzwischen ist John Draper als Präsident einer Software-Firma im Silicon Valley tätig.
3.4. Berühmte Hacker und Cracker
77
Herstatt-Fall Zu den frühen Fällen der Computermanipulation zählt der Herstatt-Fall, der zu hohen Spekulationsverlusten und 1974 letztendlich zum Konkurs des renommierten Kölner Bankhauses führte [54]. Durch eine Schwachstelle bei der Datenweitergabe vom dezentralen Buchungsterminal der Devisenabteilung an das zentrale Buchungssystem war es möglich, ohne Wissen der Bankleitung und ohne Gegengeschäfte zur Absicherung von Risikogeschäften in größerem Umfang spekulative Termingeschäfte abzuschließen. Die Abwicklung eines Devisentermingeschäfts erfolgte folgendermaßen: Die auf Händlerzettel notierten Daten wurden in eine Fakturiermaschine eingegeben. Diese arbeitete die Daten entsprechend auf, druckte die Bestätigung des rechtsverbindlichen Abschlusses für den Geschäftspartner und leitete anschließend die Daten an den Zentralrechner per Lochstreifen weiter. Da die Weiterleitung der Daten an die Zentrale erst nach dem Drucken des Bestätigungsschreibens erfolgte, konnten die Devisenhändler die Weiterleitung des Lochstreifens durch einfaches Betätigen der Abbruchtaste verhindern. Als einzige Sicherung wurde der Abbruch des Vorgangs auf dem Bestätigungsschreiben vermerkt, was durch einfaches Entnehmen des Formulars aus dem Drucker vor dem Betätigen der Abbruchtaste umgangen werden konnte. Der entstandene Schaden belief sich auf ca. 1,2 Milliarden Mark. Der Direktor der Herstatt-Bank, Iva D. Herstatt, wurde von einem Kölner Gericht wegen betrügerischen Bankrotts und Veruntreuung zu viereinhalb Jahren Gefängnis verurteilt. Dieses Urteil wurde vom Bundesgericht aufgehoben. Nach jahrelangen Prozessen wurde er zu einer zweijährigen Freiheitsstrafe auf Bewährung wegen Untreue verurteilt. Bill Gates und Paul Allen Die Lakeside School in Seattle hatte sich 1968 einen kleinen Computer angeschafft, was zu dieser Zeit außergewöhnlich war. Es war die Zeit der Großcomputer von IBM oder Control Data. Computer für den Hausgebrauch waren bis dahin weder konzipiert, noch sah jemand ein Potenzial darin. Da das Budget knapp war, mietete die Lakeside School Rechenzeit eines PDP-10 (Programmed Data Processor) von der Digital Equipment Corporation (DEC). Als 1969 der Unterricht an diesem PDP10 begann, gehörten der dreizehnjährige Bill Gates und sein bester Freund Paul Allen zu den eifrigsten Nutzern [34]. Sie saßen stundenlang davor und erforschten die Funktionsweise des Geräts. Während Paul Allen sich mit der Programmiersprache beschäftigte, schrieb Bill Gates kleine Spielprogramme, um sich die Zeit zu vertreiben. Die beiden trieben es aber so bunt, dass die gemietete Rechenzeit stark überschritten wurde. Die Lakeside School hatte sehr hohe Nutzungsgebühren nachzuzahlen, woraufhin beiden Schülern die weitere Nutzung untersagt wurde. Natürlich suchten die beiden einen Ersatz. Diesen fanden sie in der Computer Center Corporation (CCC), die von jungen Absolventen der Universität von Washington gegründet wurde. Die CCC hatte einen PDP-10 erworben, den sie sich eigentlich nicht leisten konnte. Der Kaufpreis wurde ihnen von DEC so lange ge-
78
3 Hacker und Cracker
stundet, solange sie Programmfehler entdeckten und diese weitermeldeten. Wie Bill Gates und Paul Allen davon erfuhren, konnte Bill Gates mit all seiner Überzeugungskraft die CCC überreden, und sie erhielten freien Zugang zum PDP-10 mit der Auflage, Programmfehler zu suchen, zu dokumentieren und an den CCC zu melden, der diese Informationen an DEC weiterleitete. Die beiden arbeiteten oft die halbe Nacht am Computer und erforschten das Gerät bis in die letzten Details. Natürlich ließen die Probleme nicht lange auf sich warten. Die beiden Computer-Freaks verursachten mehrere Systemabstürze, und Bill Gates hackte das Sicherheitssystem des Computers. Er nutzte dies und änderte die Dateien, in denen die genutzte Rechenzeit für die Abrechnung mitprotokolliert wurde, zu ihren Gunsten ab. Er wurde jedoch dabei erwischt, und die CCC verbot ihm jegliche weitere Nutzung des Systems. Während seiner Arbeit bei der CCC hatte er erfahren, dass die Universität in Washington ebenfalls über einen PDP-10 verfügte, der über das Cybernet (Netzwerk der Control Data Corporation) mit anderen Systemen verbunden war. Er mischte sich unter die Studenten und verschaffte sich über die Terminals der Universität unberechtigten Zugang in die über das Netz angeschlossenen Systeme. Wieder wurde er entdeckt. Als Strafe erhielt er jedoch nur die Auflage, die Finger vom Computer zu lassen, was er natürlich nur kurze Zeit durchhielt. Gerade mal 19 Jahre alt, gründete er 1975 mit Paul Allen die Firma Microsoft. Sie entwickelten zusammen mit anderen Mitarbeitern die Programmiersprache BASIC für den Rechner Altair der Firma MITS, den ersten Personalcomputer im Baukastenprinzip. Da die Nachfrage nach dem ersten Rechner in Eigenbau das Angebot der verfügbaren Selbstbaukästen bei weitem überstieg, griffen die ComputerFreaks zur Selbsthilfe. Durch Zufall gelangten sie an eine Kopie von BASIC. Nach dem Hacker-Ideal „Informationen für alle“ machte diese unter den Anhängern des Altair schnell die Runde. Als Bill Gates dies erfuhr, reagierte er nicht mit so viel Verständnis wie seine früheren Ankläger für ihn. In einem offenen Brief wandte er sich mit harten Anschuldigungen an die Hacker-Gemeinde und verurteilte die Raubkopierer aufs Schärfste. Heute ist Microsoft mit mehr als 39.000 Angestellten in 60 Ländern der größte Software-Hersteller der Welt. Steve Wozniak und Steve Jobs Steve Wozniak und Steve Jobs kannten sich seit der gemeinsamen Zeit in der Schule. Wozniak, der schon in der sechsten Klasse seine Amateurradio-Lizenz erworben hatte, war ein Elektronik- und Computer-Freak und bastelte an Computerschaltungen. 1967 gewann er einen Elektronikwettbewerb mit einer selbst gebauten Rechenmaschine [34]. Durch einen Zeitungsartikel kamen die beiden auf die Idee, die so genannten Blueboxes zu bauen. Da das Phone Phreaking damals Mode war, konnten Jobs und Wozniak eine Zeit lang ein gutes Geschäft machen, indem sie die Schaltungen verkauften. Dabei lernten sie auch John Draper alias Capt’n Crunch kennen. Aufgeschreckt durch einige Verhaftungen in der Hacker-Szene erkannten sie das Risiko und stiegen aus.
3.4. Berühmte Hacker und Cracker
79
1976 erstellte Wozniak eine Platine, die der Apple I werden sollte. Jobs erkannte das Potenzial und bestand darauf, dieses Bastelergebnis zu verkaufen. Sie gründeten zusammen 1976 die Firma „Apple Computer“. Sie bauten selbst – anfangs in einer Garage – die Computer Apple I und Apple II. Der Apple II war der erste Personal Computer mit Kunststoffgehäuse und Farbgrafik. Wozniak verließ Apple enttäuscht vom Computer-Geschäft bald nach seinem Flugzeugabsturz 1981, von dem er sich nur langsam erholte, um zu promovieren und anschließend eine eigene Firma zu gründen (UNUSON). Juni 1983 kehrte er zu Apple zurück. Heute hat er sich offenbar voll und ganz der Erziehung und Bildung mit Computerhilfe verschrieben und beschäftigt sich laut eigener Angaben jeden Tag damit, in seinem Wohnbezirk in Los Gatos, Kalifornien, Schulen mit Computern und Netzwerk-Hardware, Online-Zugängen und Fachwissen zu versorgen. Steve Jobs, der nach dem Ausstieg von Wozniak die Führung der Firma übernahm, stieg 1985 nach Querelen und Intrigen enttäuscht bei Apple aus. Die Geschäftsführung des Unternehmens hatte ihn immer weiter aus dem operativen und strategischen Geschäft verdrängt und von der Entscheidungsfindung ausgeschlossen. Er verkaufte seine Anteile und gründete 1989 NeXT. Jobs wollte eine zweite Revolution des PC in Bezug auf Hardware und Software in Gang setzen. Der Versuch schlug fehl, da er sich nicht gegen die Konkurrenzprodukte von Microsoft durchsetzen konnte. Mit dem Kauf von NeXT durch Apple im Jahre 1995 kehrte er in die Firma zurück. Seit 1998 ist er wieder Vorstandsvorsitzender. Fred Cohen und der erste Virus Der Begriff „Computervirus“ wurde 1981 von Professor Adleman und seinem Doktoranden Fred Cohen eingeführt. Es war auch Fred Cohen, der 1983 den ersten funktionsfähigen Virus entwickelte [124]. Dieser war für eine VAX-11/750, die unter UNIX lief, programmiert und nistete sich im Befehl ’vd’ – Programm zur grafischen Darstellung der Dateistruktur – ein. Der Virus erbte bei jeder Ausführung die Systemprivilegien des infizierten Programms und konnte so innerhalb kürzester Zeit jedem Benutzer diese Privilegien übertragen. 1984 lieferte Fred Cohen seine Doktorarbeit der Elektrotechnik von der University of Southern California (USC) mit dem englischen Titel „Computer Viruses“ ab, deren Veröffentlichung lange Zeit umstritten war. Sie enthielt neben einer umfassenden theoretischen Abhandlung über Computerviren und dem beschriebenen Virus noch weitere experimentelle Viren. Die Universitätsleitung sah eine große Gefahr in Cohens Arbeit und versuchte, diese unter Verschluss zu halten. Innerhalb kurzer Zeit hatte es nämlich Cohens Versuchsvirus geschafft, das Rechenzentrum der Universität vollständig zu verseuchen. Die Definition eines Virus, die Cohen in seiner Dissertation gab, lautet: „We define a computer virus as a program that can infect other programs by modifying them to include a possibly evolved copy of itself. With the infection property, a virus can spread throughout a computer system or network using the authoriza-
80
3 Hacker und Cracker
tions of every user using it to infect their programs. Every program that gets infected may also act as a virus and thus the infection grows.“ Der CCC und der BTX-Hack Steffen Wernéry und Wau Holland, Mitglieder des CCC (Chaos Computer Club), entdeckten im Jahre 1984 eine große Sicherheitslücke im Bildschirmtextsystem (BTX) der Deutschen Bundespost. Wernéry und Holland hatten herausgefunden, dass durch einen schnellen Seitenwechsel im BTX die BTX-Nummer der Hamburger Sparkasse lesbar wurde. Für eine BTX-Seite standen maximal 1926 Bytes zur Verfügung. Nutzte man diesen Platz bis zum letzten Zeichen aus, so erschienen fremde Daten auf dem Bildschirm. Sie testeten das System und machten sich Notizen, da es nicht möglich war, die fremden Daten abzuspeichern. Sie stießen dabei auch auf ein Zahlenmuster, bei dem es sich um die Anschlusskennung der Filiale der Hamburger Sparkasse handelte. In ihren Notizen fanden sie auch das passende Passwort dazu. Daraufhin richtete der CCC selbst eine kostenpflichtige BTX-Seite ein. Mit der Anschlusskennung der Hamburger Sparkasse griffen sie wiederholt auf ihre eigens eingerichtete Seite zu. Die dadurch entstandenen Kosten beliefen sich auf DM 135.000, als sie das Experiment beendeten. Da es bei dieser Aktion darum ging, die vorhandene Sicherheitslücke im BTX-System öffentlich zu machen und die Deutsche Bundespost dazu zu bewegen, den Fehler zu beheben, wurde das Geld der Hamburger Sparkasse zurückerstattet, und die Medien wurden informiert. Am 19. November zeigten sie ihren Hack im Heute-Journal des ZDF und führten einer breiten Öffentlichkeit vor Augen, dass Datennetze nicht so sicher sind, wie die Betreiber dies häufig behaupten. Der CCC zeigte im Laufe der Zeit noch einige andere Sicherheitslücken des BTX-Systems auf – unter anderem, dass es möglich war, EMails im Briefkasten des Empfängers zu verändern, nachdem dieser sie gelesen hatte. Da die BTX-Aktion zwei Jahre vor Inkrafttreten des 2. Gesetzes zur Bekämpfung der Wirtschaftskriminalität stattfand, blieb sie ohne rechtliche Folgen. Der CCC und der NASA-Hack Im Frühjahr 1987 gelang es Hackern, in das Space Physics Analysis Network (SPANNET) der US-Weltraumbehörde NASA einzudringen. Dieses Netzwerk verband zum damaligen Zeitpunkt ca. 1.600 Großrechner, zu denen ca. 4.000 berechtigte Benutzer Zugang hatten. Der Einbruch gelang durch ein Sicherheitsloch im VMS, einem Betriebssystem für Großrechner des Software-Herstellers Digital Equipment Corporation (DEC). Mit dem Systemaufruf $SETUAI war es jedermann möglich, uneingeschränkten Zugriff auf die Datei SYSUAF.DAT zu erhalten, die die Passwörter in verschlüsselter Form und Privilegien enthielt. Da es den Hackern nicht möglich war, die verschlüsselten Passwörter zu entschlüsseln, schleusten sie ein so genanntes „Trojanisches Pferd“ in das System. Loggte sich ein Benutzer in das System ein, protokollierte der Trojaner das Passwort im Klartext in einer Datei mit. Durch die
3.4. Berühmte Hacker und Cracker
81
erhaltenen Passwörter war es den Hackern möglich, ihre Zugriffsrechte sukzessiv auszuweiten. Sie installierten einen privilegierten Benutzer, um jederzeit Zugang zum System zu haben, und beseitigten sämtliche Spuren ihres Einbruches aus den Log-Dateien. Außerdem veränderten sie die Kennwortüberprüfung so, dass sie jederzeit durch Eingabe eines „Generalschlüssels“ als Benutzer mit privilegierten Rechten Zugang hatten, und setzten die Systemvariablen derart, dass die Anzeige so erzielter Zugänge systemintern unterdrückt wurden. Die Hacker waren somit im System unsichtbar. Mit diesen Tricks gelangten die Hacker in 135 VAX-Großrechner im SPANNET in neun westlichen Ländern. Obwohl die Hacker über alle Rechte verfügten, veränderten oder kopierten sie keine der gefundenen Daten. Nach eigenen Angaben wollten sie nur die Sicherheitslücken der Systeme erkunden. Entdeckt wurden sie im Juli 1987 vom Systemverwalter des Europäischen Laboratoriums für Molekularbiologie in Heidelberg, Roy Ommond, der aufgrund einer Beschreibung dieses Betriebssystemfehlers in der deutschen Zeitschrift Datenschutzberater sein System auf Eindringlinge untersuchte. Er informierte daraufhin alle Kollegen im SPANNET durch eine Mitteilung über das Netz, die auch die Information über das Generalpasswort enthielt und die Hacker in Verbindung mit dem CCC brachte. Da diese Mitteilung auch von potenziellen Crackern gelesen werden konnte, wandten sich die Hacker Hilfe suchend an den CCC in Hamburg, der schon früher als Vermittler aufgetreten war. Dieser informierte das Bundesamt für Verfassungsschutz und die Software-Firma DEC. Nach einer Veröffentlichung im Nachrichtenmagazin Panorama schreckten die Behörden und Firmen im In- und Ausland auf. Die Firma Philips in Frankreich und das Europäische Kernforschungszentrum CERN in der Schweiz stellten Strafanzeige wegen Spionage von sensiblen Daten gegen die Vorstandsmitglieder des CCC. 14 Tage nach dem Fernsehbericht wurden deren Wohnungen von Beamten des Bundeskriminalamtes durchsucht. Im März 1988 wurde Vorstandsmitglied Wernery auf einer Vortragsreise in Frankreich von den französischen Behörden sogar vorübergehend festgenommen. Sämtliche Vorwürfe stellten sich jedoch als unbegründet heraus. Nach eigenen Aussagen der Hacker verfolgten sie lediglich das Ziel, die Schwächen des Systems aufzudecken. Andere Ziele gab es nicht. Robert Morris und der Internet-Wurm Am 2. November 1988 wurde ein sich selbstreplizierendes Programm, ein so genannter Wurm, von Robert Morris ins Internet freigesetzt [124]. Robert T. Morris Jr., Sohn des bedeutenden Sicherheitsexperten Robert T. Morris, welcher am National Computer Security Center (NCSC) arbeitete, war zum damaligen Zeitpunkt Doktorand an der Cornell University in Kalifornien. Der Internet-Wurm infizierte VAX-Rechner der Firmen DEC und SUN-3-Systeme, die mit Version 4 des BSD UNIX-Betriebssystems betrieben wurden. Der Wurm analysierte anhand lokaler Routing-Tabellen die Netztopologie und infizierte vornehmlich Rechner, die als Gateway fungierten und ideale Ausgangspunkte für weite-
82
3 Hacker und Cracker
re Attacken waren. Innerhalb von Stunden hatte der Internet-Wurm so einige tausend Rechner infiziert. Die Schätzungen bezüglich der infizierten Systeme reichten von 2400 bis 6000. Der Internet-Wurm sollte so geschrieben sein, dass er sich verbreiten konnte, ohne für die Benutzer der befallenen Maschine sichtbar zu werden. Er enthielt keine explizite Schadensfunktion. Leider waren Fehler im Programmcode, so dass er weitere Programme auf dem gleichen System infizierte und sich schlagartig vermehrte. Ursprünglich geplant als kleiner, nicht weiter auffallender Prozess wuchs er in der Summe jedoch nun so an, dass er durch den Verbrauch des Plattenplatzes und der CPU-Zeit das befallene System lahm legte. Zur Weiterverbreitung nutzte er verschiedene Eigenschaften und Sicherheitslücken auf der Anwendungsebene der TCP/IP-Protokollfamilie aus. Insgesamt wurden vier unterschiedliche Verfahren für die Ausbreitung verwendet: fingerd, sendmail, rsh und unsichere Passwörter. Durch den Aufruf von finderd mit einem überlangen Parameter wurde ein Buffer-Overflow in einer Standard-C-Routine erzeugt. Dadurch wurden Teile des Daemon-Prozesses im Hauptspeicher überschrieben, darunter auch die Rücksprungadresse der gerade ausgeführten Funktion. Die neue Rücksprungadresse zeigte auf einen Teil des überschriebenen Speichers, in dem eine Shell mit den Rechten des Daemon aufgerufen wurde. Mit dieser Shell wurde dann eine Kopie der für den Start des Wurms benötigten Dateien übertragen und ausgeführt. Ein Fehler im sendmail-Programm, eine vom Entwickler in der mit der DEBUG-Option kompilierten Version eingebauten Falltür, erlaubte, dass auf einem Remote-System eine über Electronic Mail empfangene Nachricht als Befehl interpretiert wurde. So konnte ein Wurmprozess auf einem Remote-Rechner eine Shell starten. Der Wurm nutzte auch die ’r’-Dienste aus. Mit ihrer Hilfe ist es möglich, auf anderen Rechnern ohne Passworteingabe bestimmte Befehle oder eine Remote-Shell aufzurufen, wenn der lokale Rechner dort als vertrauenswürdig eingestuft wurde. Diese Einstufung erfolgt durch den Eintrag der Rechnernamen in eine spezielle Datei. Als eine weitere Lücke entpuppte sich die Passwort-Datei. Durch die Möglichkeit, auf die gespeicherten Benutzeridentifikationen und die zugehörigen, wenn auch verschlüsselten Passwörter zugreifen zu können, konnte der Internet-Wurm eine Brute-Force-Attacke durchführen. Gelang es, ein Passwort zu bestimmen, wurde mit diesem und der zugehörigen Benutzeridentifikation versucht, auf einem anderen Rechner des Netzwerks eine Shell zu starten. Die Existenz dieser Sicherheitslücken war seit langer Zeit bekannt, trotzdem waren die allgemein verfügbaren Patches (Korrekturprogramm) zur Behebung der Schwachstellen selten eingespielt. Anfang 1990 wurde Robert T. Morris Jr. auf Basis des 1986 in Amerika eingeführten Computer Fraud and Abuse Act zu drei Jahren Gefängnis auf Bewährung und einem Bußgeld in Höhe von 10.000 $ verurteilt. Außerdem musste er 400 Stunden soziale Arbeit leisten und die Gerichtskosten in Höhe von etwa 150.000 $ tragen. Der Staatsanwalt hatte fünf Jahre Gefängnis und 250.000 $ Strafe gefordert. In den Vereinigten Staaten von Amerika wurde diesem Fall sehr große Aufmerksamkeit geschenkt. Über eine Woche lang fand sich der Fall im November 1988 auf
3.4. Berühmte Hacker und Cracker
83
der Titelseite der New York Times. Der Schaden, den der Wurm angerichtet hatte, wurde auf 100.000 $ bis 10 Mio. $ geschätzt. Als unmittelbare Folge dieses Falles wurde im Dezember 1988 das erste so genannte „Computer Emergency Response Team“ (CERT) ins Leben gerufen. AIDS-Disketten-Fall Ein Fall von Computersabotage durch einen Trojaner ereignete sich im Jahre 1989. Von England aus verschickte die in Panama registrierte Firma PC Cyborg Corporation mehrere tausend Disketten mit einem Informationsprogramm zum Thema AIDS an die Teilnehmer einer internationalen AIDS-Konferenz sowie an medizinische Organisationen und Banken in Europa. Insgesamt wurden ca. 100.000 Disketten verschickt [54]. Es sollte sich laut Werbung um eine Art Datenbank handeln, die zuerst mit dem Befehl INSTALL auf die Festplatte installiert werden musste. Im beiliegenden Lizenzvertrag wies der Hersteller darauf hin, dass bei längerer Nutzung eine Gebühr von 378 US-Dollar zu zahlen sei. Der Lizenzvertrag enthielte auch die ausdrückliche Anweisung, das Programm nur dann zu installieren, wenn die Absicht bestehe, die anfallenden Gebühren zu bezahlen. Dies hielt aber die wenigsten davor zurück, das Programm zu installieren. Bei der Installation benannte das Programm die Datei AUTOEXEC.BAT in AUTO.BAT um und setzte ein Trojanisches Pferd in den Computer. Bei jedem Hochfahren des Systems wurde nun die Anzahl der Starts gezählt. Nach dem neunzigsten Start wurde die „Zerstörungssequenz“ aktiviert. Diese verschlüsselte und versteckte die meisten Dateinamen, wodurch die Zuordnung der Dateinamen zu den eigentlichen Daten nicht mehr vorhanden war. Anschließend wurde der Nutzer dazu aufgefordert, seine Schulden zu bezahlen. Einer der Firmeninhaber wurde kurz darauf am 2. Februar 1990 verhaftet. Er wurde in Großbritannien verurteilt und anschließend in eine geschlossene psychiatrische Anstalt eingewiesen, da es das Gericht als bewiesen ansah, dass der Angeklagte vermindert zurechnungsfähig war. Wie sich herausstellte, sollten die 100.000 nach Europa verschickten Disketten nur ein Test für eine größere Aktion in den USA sein. Hagbard Celin, Pengo und der KGB-Hack Der 1989 aufgedeckte KGB-Hack sorgte für großen Wirbel: Eine Gruppe von fünf jungen Hackern hatte Informationen an den sowjetischen Geheimdienst KGB verkauft. Beim jährlichen Treffen des Computer Chaos Clubs in Hamburg 1985 lernten sich der siebzehnjährige Hans Hübner (Spitzname „Pengo“) und der zwanzigjährige Karl Koch (Spitzname „Hagbard Celine“ nach der Romanfigur Captain Hagbard Celine aus der Trilogie Illuminatus! von Robert Shea und Robert Anton Wilson) kennen, beides passionierte Hacker. Zusammen mit ihren Freunden Dirk-Otto Brzezinski, Peter Carl und Markus Hess fingen sie 1986 an, ihre Fähigkeiten in Geld umzusetzen.
84
3 Hacker und Cracker
Ihre Motive waren unterschiedlicher Natur: Karl Koch glaubte – nicht zuletzt durch seinen ständigen Drogenkonsum – an die Ideale seines Vorbildes Captain Hagbard Celine und wollte durch den Verkauf von Informationen an die Russen den Weltfrieden retten; Peter Carl, ein arbeitsloser 31-jähriger Croupier, erhoffte sich leicht verdientes Geld; Dirk-Otto Brzezinski, ein gut verdienender, freischaffender Programmierer, benötigte für seinen aufwändigen Lebensstil Geld; Hans Hübner, der wie Markus Hess erst später in das Projekt eingeweiht wurde, wollte beweisen, dass er der „Welt größte Hacker“ werden konnte. Er träumte von der Möglichkeit, mit leistungsfähigen Rechnern und Modems zu arbeiten, ohne die Gefahr, entdeckt zu werden. Markus Hess, ein 24-jähriger Physikstudent, hatte weder idealistische noch finanzielle Motive. Er geriet mehr oder weniger unfreiwillig in das Projekt. Peter Carl stellte 1986 den ersten Kontakt zum sowjetischen Geheimdienst in Ost-Berlin her. Er übergab als Kostprobe ihres Könnens eine Liste von Rechnern, in die sie bereits eingebrochen waren, sowie eine Beschreibung der gefundenen Informationen. Diese Informationen waren für den KGB von geringem Interesse. Sie machten deutlich, an was sie interessiert waren: Quellcodes der Betriebssysteme UNIX und VMS, Compiler-Programme, CAM- und CAD-Programme sowie militärische Informationen über Radartechnik, Nuklearwaffen und SDI (Strategic Defense Initiative). Da Karl Koch nicht programmieren konnte und auch Brzezinski keine Möglichkeit sah, an die gewünschten Quellcodes zu gelangen, wurde Markus Hess in das Projekt einbezogen. Markus Hess arbeitete bei einer Hannoveraner ComputerFirma und war dadurch in der Lage, den Quellcode von Berkley UNIX zu beschaffen. Erst anschließend erkannte er, dass er durch seinen „Freundschaftsdienst“ in illegale Geschäfte verwickelt worden war. Was Markus Hess jedoch veranlasste, bei der Gruppe zu bleiben, waren seine Hacker-Ausflüge in die Rechner des Lawrence Berkley Laboratories (LBL) in Kalifornien und von dort in unzählige Rechner. Sein Vorgehen war immer dasselbe: über schlecht oder nicht gesicherte BenutzerAccounts drang er in das Unix-System ein. Einmal im System nutzte er beispielsweise einen Fehler im Emacs-Programm, um privilegierte Rechte zu erhalten. GNUEmacs, ein mächtiges Editierprogramm, enthielt einen eingebauten E-Mail-Client. So wie der GNU-Emacs standardmäßig installiert war, konnte man damit eine EMail vom eigenen Dateiverzeichnis überallhin verschicken. Er prüfte nicht nach, wer es erhalten sollte oder ob der Empfänger die Datei überhaupt wollte. Emacs benannte die Datei um und passte die Zugriffsrechte an den neuen Eigentümer an. Diesen Fehler in der Programmierung nutzte Hess, um eine veränderte Version des Atrun-Programms dem System unterzuschieben. Atrun wurde alle fünf Minuten ausgeführt. Es ordnet routinemäßig andere Jobs und führt Aufräumarbeiten durch. Da dieses Dienstprogramm unter einem privilegierten Modus läuft, ist es normalerweise nicht möglich, ohne Administratorenrechte das Programm auszutauschen. Hess benutzte das Sicherheitsloch im Emacs, schob dem System seine modifizierte Version des Atrun-Programms unter, worauf er innerhalb von fünf Minuten privilegierte Rechte erhielt, und platzierte anschließend das Original-Atrun-Programm wieder dahin zurück, wo es hingehörte, um so seine Spuren zu verwischen.
3.4. Berühmte Hacker und Cracker
85
Karl Koch durchsuchte die Benutzer-Accounts nach brauchbaren Daten und Hinweisen, ob sein Hack oder er entdeckt worden waren. Er nutzte in E-Mails gefundene Hinweise auf Account-Namen und Passwörter, die Trust-Beziehungen der vernetzten Systeme sowie ungesicherte Telefonverbindungen, um in weitere Systeme einzubrechen. Entdeckt wurden seine Aktivitäten durch Zufall. Clifford Stoll, ein neu eingestellter Systemadministrator am Lawrence Berkeley Laboratory in Kalifornien, entdeckte bei seiner Einarbeitung in das System einen Abrechnungsfehler von 75 Cent [122]. Dies bereitete ihm solches Kopfzerbrechen, dass er bei der Suche nach der Ursache dieses Fehlers nicht nachließ. Dabei stieß er dann auf die Spur von Hackern. Nach monatelanger Verfolgungsjagd, bei der er sämtlichen Datenverkehr mitprotokollierte, ist es ihm gelungen, den Hacker in Deutschland zu lokalisieren. Karl Koch wurde am 29. Juni 1987 in Hannover verhaftet. Seit 1986 litt Koch verstärkt unter Angstpsychosen. Ausgelöst wurden diese durch seinen Drogenkonsum, die ständige Observierung durch den Bundesnachrichtendienst und durch die Hausdurchsuchungen bei seinen Freunden. Eine Unterbrechung seines Drogenkonsums und psychologische Betreuung brachten kurzzeitig eine Besserung. Doch schon im Februar fühlte er sich durch eine kannibalistische Verschwörung bedroht, so dass er sich nach Spanien absetzte. Die erneute Einnahme von Kokain verursachte solch starke Depressionen und Angstzustände, dass er nach Deutschland zurückkehrte und sich freiwillig in eine Klinik einliefern ließ. Im August 1987 begann er eine Ausbildung an einer höheren Handelsschule, die er nach kurzer Zeit abbrach. Auch die im August 1988 begonnene Ausbildung zum Wirtschaftsassistent Informatik ließ er einen Monat später wieder fallen. Im Herbst 1988 wurde er mehrfach vom BKA und Verfassungsschutz vernommen. Januar 1989 versuchte er eine weitere Drogentherapie. Mehrfach wurde er festgenommen, vernommen und freigelassen. Seine letzte Aussage beim BKA macht er am 27.4.1989. Am 23.5.1989 kam er von einer Dienstfahrt nicht mehr zurück. Koch war erst 23, als man seinen verbrannten Leichnam am 1. Juni 1989 in einem Waldstück bei Ohof im Landkreis Gifhorn fand. Sein Todestag war der 23.5.1989. Als offizielle Todesursache wurde Selbstmord angegeben, doch wird dies in Hacker-Kreisen aufs Heftigste zurückgewiesen. Es gibt die verschiedensten Gerüchte und Spekulationen über seinen Tod, so auch die Ermordung durch einen westlichen Geheimdienst. Eugene Spafford, Dan Farmer und Wietse Venema Dan Farmer, der im Computer Emergency Response Team arbeitete, entwickelte 1991 zusammen mit Eugene Spafford von der Purdue University COPS. COPS (Computer Oracle Password and Security System) ist ein halbautomatisches (Public-Domain-)Tool, das zur Überprüfung der Sicherheit von Unix-Systemen dient. Es checkt das System auf verschiedene Systemeinstellungen, Zugriffsrechte, SUID-Dateien etc. und deckt so potenzielle Sicherheitslücken auf.
86
3 Hacker und Cracker
Mit Wietse Venema zusammen entwickelte Farmer SATAN, das „System Administrator Tool for Analyzing Networks“. SATAN ist ein mächtiges Tool, um entfernte Unix-Systeme auf bekannte, aber oftmals nicht beseitigte Sicherheitsschwachstellen zu analysieren. Venema, ein begnadeter Programmierer an der Eindhoven University of Technology, entwickelte einige Sicherheitstools. Eines der bekanntesten ist der TCP-Wrapper, ein Programm, das eine genaue Kontrolle und Überwachung von Informationspaketen aus dem Netz ermöglicht. Ein Unix-Betriebssystem hat in seiner Standardinstallation keine Möglichkeit, TCP/IP-Netzwerkprogramme wie finger, ftp oder telnet zu kontrollieren. Mit dem TCP-Wrapper ist es möglich, die Benutzung dieser Programme zu überwachen und gegebenenfalls auf bestimmte Rechner zu beschränken. Tron Boris Floricic (Spitzname „Tron“) wurde durch seine Chipkarten-Hacks bekannt. Seine Manipulation der Telefonkarte der Deutschen Telekom brachte ihn 1995 in Untersuchungshaft. Er hackte Pay-TV-Karten und zeigte so die Unsicherheit von Chipkarten in Mobiltelefonen. Seine Fähigkeiten dürften Militärkreise oder Geheimdienste wenig interessiert haben, umso mehr jedoch die milliardenschwere Industrie sowie die organisierte Kriminalität, die mit gefälschten und gehackten Karten einen lukrativen Handel betreibt. Tron wurde immer wieder von dubiosen Firmen und Unternehmensberatungen gedrängt, für sie zu arbeiten. Kurz vor seinem Tod schockte er sie mit seiner unbekümmerten Ankündigung, die Bauanleitung einer Chipkarte im Internet zu veröffentlichen, die sämtliche europäischen Pay-TV-Sender entschlüsseln könnte. Damit wäre der Markt für die gehackten Chipkarten, deren Preis bei mehreren hundert Mark lag, über Nacht zusammengebrochen. Am 20. Oktober 1998 fand man Tron aufgehängt an einem Baum in einem Park in Berlin-Neukölln. Die Polizei ging von Selbstmord aus, da es für Mord keinerlei Indizien gab. Beim CCC hält man diese Theorie jedoch für unwahrscheinlich, da es keinen sichtlichen Grund für einen Selbstmord gab. Im Gegensatz zu Hagbard war er weder psychisch krank noch nahm er Drogen. Kevin Mitnick Mitnick, bekannt unter mehr als einem halben Dutzend Pseudonyme (z.B. „Condor“), ist wahrscheinlich der bekannteste Hacker der Welt. Mitnick begann seine Karriere als Phreaker [110,111]. Seit seiner Jugend hat Mitnick jegliche als sicher geltenden Computersysteme geknackt, einschließlich Rechner von Militäreinrichtungen, Finanzunternehmen, Software-Unternehmen und anderen Technologieunternehmen. Er brach in das Computersystem der Monroe High School ein, um seine Schulnoten zu verbessern.
3.4. Berühmte Hacker und Cracker
87
In Konflikt mit dem Gesetz kam er erstmals 1981 durch den Einbruch in das „North American Air Defense“-Computersystem in Colorado. Er beschäftigte sich intensiv mit Telefonanlagen, beschaffte sich Software und Computeranleitungen. Mit der Zeit verbesserte er seine Fähigkeiten so, dass er zusammen mit einem Freund problemlos geheime Software von der Firma Digital Equipment Corp. stehlen konnte. Bis 1989 konnte er sich aufgrund seines Alters einer Verhaftung entziehen. Doch das FBI machte die beiden ausfindig und ließ sie verhaften. Das Gericht in Los Angeles verurteilte Kevin Mitnick 1989 zum ersten Mal zu einer Haftstrafe von einem Jahr in einem Niedersicherheitsgefängnis und einer Therapie gegen seine Computersucht. Nach seiner Entlassung hackte er munter weiter. Seinem zugeteilten Bewährungshelfer stießen plötzlich merkwürdige Dinge zu. Telefonate wurden einfach aufgelegt; die Telefongesellschaft konnte jedoch keine Erklärung dafür finden. Es verschwanden alle aufgezeichneten Beweise der Verhaftung und Mitschnitte von einigen Verhören, die auf einem Computer des Gerichts gespeichert waren. Mitnick tauchte für über ein Jahr unter. Vermutlich lebte er in dieser Zeit unter falschem Namen in Nordkalifornien, allerdings gab es auch Zeitungsberichte, die besagten, dass Mitnick zu Hackerfreunden nach Israel flüchtete. Als er wieder nach Los Angeles zurückkam, wurde er vom FBI wegen Verstößen gegen die Bewährungsauflagen und Einbrüchen in verschiedene Systeme gesucht. Daraufhin verschwand er im November 1992 von der Bildfläche. Er verschaffte sich eine neue Identität und lebte nun im Untergrund. Der Showdown für Kevin Mitnick begann in den Weihnachtsfeiertagen 1994 mit einem Einbruch in die Rechner des Sicherheitsexperten Tsutomu Shimomura. Ein Hacker war über das Internet in Shimomuras persönliche Computer eingebrochen und hatte Hunderte persönlicher und geheimer Dateien kopiert. Shimomura ging akribisch vor und setzte forensische Methoden ein, um zu ermitteln, wie der Eindringling in das System gelangt war. Dazu fror er sämtliche Systeme in ihrem aktuellen Zustand ein, um so die Spuren des Eindringlings zu erhalten. Mithilfe komplexer Analyseverfahren konnte er eine sekundengenaue Aufzeichnung des Angriffs auf seine Rechner erstellen. Das Resultat war verblüffend: Der Hacker hatte unter anderem eine Technik benutzt, die bis dahin zwar in der Theorie bekannt war, doch noch von niemandem eingesetzt worden war: IP-Spoofing (Fälschen der Absenderadresse). Bis zu diesem Zeitpunkt war es die einhellige Meinung der Sicherheitsexperten, dass IP-Spoofing in der Praxis nicht durchführbar wäre. Per Zufall wurden einen Monat später auf einen toten Account von „The Well“, einem großen Internet Provider in Kalifornien, die persönlichen Dateien von Shimomura zusammen mit anderen Daten entdeckt. Shimomura wurde informiert, und er ergriff die Chance, den Eindringling aufzuspüren. Er überwachte die Leitungen von „The Well“ mithilfe eines „Sniffers“, ein Paketfilter, der die ein- und ausgehenden Datenpakete nach bestimmten Adressen absucht und jeden Zugriff verfolgt. Dadurch gelang es Shimomura letztendlich mithilfe des FBI, Kevin Mitnik aufzuspüren. Am 14. Februar 1995 wurde Kevin Mitnik in Raleigh, North Carolina, verhaftet. Bis zu diesem Zeitpunkt war Mitnick zweifellos der meistgesuchteste Hacker der Welt. Nach dreieinhalb Jahren ohne Urteil in Haft wurde er in mehreren Gerichts-
88
3 Hacker und Cracker
verhandlungen in 23 Fällen schuldig gesprochen und erhielt eine Höchststrafe von 20 Jahren Gefängnis. Die Härte, mit der die Richter gegen ihn vorgingen, war bis dahin einmalig und für viele nicht zu verstehen. Die Strafe wurde im März 1999 auf 46 Monate verkürzt. Seit 21. Januar 2000 ist er wieder auf freiem Fuß. Seine Bekanntheit und seinen Ruhm verdankt Kevin Mitnick unter anderem Katie Hafner, einer Reporterin von Business Week, und John Markoff, einem Computerjournalisten und Wirtschaftsredakteur der New York Times. Sie veröffentlichten 1991 ihr Buch „Cyberpunk: Outlaws and Hackers on the Computer Frontier“. Der erste Teil des Buches ist Mitnicks Hacker-Aktivitäten gewidmet und machte ihn auf einen Schlag berühmt. John Markoff war auch bei der Verhaftung 1995 anwesend und veröffentlichte zusammen mit Tsutomu Shimomura ein weiteres lukratives Buch. Kritische Stimmen bezeichneten die ganze Aktion als groß angelegte Marketingstrategie des „selbstgefälligen Jägers“ und seines Mitautors Markoff und gaben ihnen eine Mitschuld an der Härte des Vorgehens gegen Mitnick. Es wurden sogar Vermutungen laut, die besagten, dass Tsutomu Shimomura als Fahnder vom FBI angeworben worden war, um Mitnick zu einem Fehltritt zu verführen. Shimomura bestreitet dies und gibt an, er habe nur den Hacker verfolgt, der ihn und andere Programmierer bestohlen habe. Eine andere Version der Geschehnisse gibt Jonathan Littman in seinem Buch „The Fugitive Game“. Er vertritt in diesem dritten Buch über Mitnick die These, dass es gar nicht Mitnick war, der in Shimomuras Rechner eingedrungen ist. Seiner Meinung nach ist Mitnick nur ein mittelmäßiger Hacker und wäre nicht in der Lage gewesen, solch einen Einbruch durchzuführen. Der Einbruch wäre stattdessen von einem israelischen Hacker durchgeführt worden. Für die einen ist Kevin Mitnick der „Meisterhacker“, der ebenso frech wie ruchlos aus der Dunkelheit zuschlug und später die Geschädigten auch noch verhöhnt. Für die anderen ist er Opfer des verletzten Stolzes einiger Personen und Organisationen, ein Sozialfall und Psychopath, der sich durch das Eindringen in die Privatsphäre anderer Menschen Befriedigung verschaffte. Kevin Poulsen Kevin Poulsen, auch bekannt unter dem Decknamen „Dark Dante“, wurde 1989 verhaftet [72,73]. Sein Werdegang ähnelt sehr dem von Kevin Mitnick. Tagsüber arbeitete er als Hacker für das Pentagon, in der Nacht als Datendieb auf eigene Rechnung. Er wurde am meisten bekannt für seine unheimlichen Fähigkeiten, das Telefonsystem von Pacific Bell unter seine Kontrolle zu bringen. Poulsen nutzte seine Talente mehrfach dazu, Radiowettbewerbe zu gewinnen. Einmal war der erste Preis ein Porsche. Er manipulierte die Telefonleitungen so, dass sein Anruf der Gewinneranruf war. Poulsen hat ebenfalls so ziemlich jede Art von Site geknackt, darunter auch eine, die verteidigungsrelevante Daten der US-Regierung enthielt. Er wurde zu fünf Jahre Gefängnis nach Spionagegesetzen verurteilt und am 4. Juni 1996 auf Bewährung freigelassen, nachdem er den Vorwurf der Spionage zurückweisen konnte.
3.4. Berühmte Hacker und Cracker
89
Der geläuterte Hacker baute sich eine Karriere als Journalist auf. Er schrieb eine wöchentliche Kolumne für techTV und veröffentlichte verschiedene Artikel zum Thema Computersicherheit. Aaron Spohr, Marcel Henning und der T-Online-Hack Dem 16-jährigen Aaron Spohr und seinem Freund Marcel Henning gelangen es 1998, die Daten von 600 T-Online-Nutzern mit einem einfachen Trick auszuspionieren. Sie schleusten ein so genanntes „Trojanisches Pferd“, ein spezielles Überwachungsprogramm, ein. Dieses zeichnete die Passwörter auf und übermittelte diese an die Hacker. Diese nutzten ihr so erlangtes Wissen jedoch nicht für sich aus, sondern informierten die Medien. Ihr Motiv war es, auf die unzureichenden Sicherheitsvorkehrungen aufmerksam zu machen. Kim Schmitz Der Hacker Kim Schmitz alias „Kimble“ hackte sich in die Rechner des deutschen Beamtenbundes ein, kopierte und las geheime Dokumente wie die Briefe vom Bundeskanzler. Er kopierte Daten von 2.170 Kunden des Datex-P- Netzes der Telekom und bot sich anschließend als Sicherheitsexperte an. Er knackte die Zugangscodes von Calling-Cards amerikanischer Bürger und telefoniert auf deren Kosten mit eigens eingerichteten Talk-Lines in Übersee. Er verdiente damit mehrere 100.000 USDollar und richtete einen Schaden in Millionenhöhe an. Weiter soll er gestohlene Kreditkarten mit geknackten Daten neu kodiert und weiterverkauft haben. Seiner eigenen Aussage nach war seine Motivation die Geltungssucht. Er wollte der Beste und Bekannteste in der Hacker-Szene werden. Doch auch seine ständige Geldnot war wohl Triebfeder seiner Handlungen. Am 23. März 1998 wurde er zu zwei Jahren Jugendstrafe auf Bewährung verurteilt. Er wurde unter anderem des Computerbetruges in acht Fällen, Ausspähen von Daten und Verrat von Geschäfts- und Betriebsgeheimnissen, Beihilfe zum Computerbetrug, der gewerbsmäßigen Bandenhehlerei in zwei Fällen, Fälschung beweiserheblicher Daten, des Missbrauchs von Titeln und des Betruges schuldig gesprochen. Mittlerweile hat Kim Schmitz die Fronten gewechselt und arbeitet als Sicherheitsberater. Er gründete seine eigene Sicherheitsfirma Kimvestor. Der 27-jährige Multi-millionär machte vor kurzem erneut Schlagzeilen, als er ankündigte, den Pleitekandidaten Letsbuyit.com retten zu wollen. Wegen des Vorwurfs des Betrugs (allerdings nicht im Zusammenhang mit seinem umstrittenen Ruf als Hacker) hat sich Schmitz erneut vor dem Gericht zu verantworten.
90
3 Hacker und Cracker
Raymond Torricelli und der NASA-Hack Viel Aufsehen erregte 1998 ein erneuter Einbruch bei der NASA. Raymond Torricelli, auch bekannt unter dem Pseudonym „Rolex“, gehörte einer Hacker-Gruppe namens „#conflict“ an. Insgesamt soll er sich unrechtmäßigen Zugang zu 800 Computern verschafft haben, darunter auch zwei Computer der NASA, die im Jet Propulsion Laboratory standen und zur Entwicklung von Satelliten und zur Analyse zukünftiger Weltraummissionen genutzt wurden. Torricelli beschädigte die geknackten Rechner nicht. Er sucht mit dem Programm „John-the-Ripper“ nach Passwörtern, um so Zugang zu weiteren Computern zu erhalten. Als er Juli 2000 verhaftet wurde, fand man auf seinem Computer 76.000 Passwörter gespeichert. Auf einem der NASA-Rechner hatte er unbemerkt von den Administratoren einen Chat-Room installiert, in dem die Mitglieder von „#conflict“ Informationen austauschen, wie man in Server eindringt und an Kreditkartendaten herankommen kann. Er gab zu, die Daten von 15 Kreditkarten geklaut und missbraucht zu haben. Torricelli drohte eine Höchststrafe von 27 Jahren, doch nach seinem Geständnis wird mit einem Urteil von acht bis 14 Monaten Gefängnis gerechnet. Die Urteilsverkündung erfolgte im März 2001. Die BBC berichtete, dass im ersten Halbjahr 2000 über eine halbe Million Angriffe auf die NASA durchgeführt wurden. Doch kann man sich des Gefühls nicht erwehren, dass zu wenig in die Sicherheit der Systeme investiert wird. Ist es wirklich möglich, dass Hacker unter den Augen einer Organisation wie der NASA sich wochen-, teilweise monatelang auf deren Systemen tummeln können, ohne entdeckt zu werden? David Smith und der Melissa-Virus Er trat am 29. März 1999 zum ersten Mal auf und gilt als einer der größten GAUs im Internet-Zeitalter: der Melissa-Virus. Innerhalb von zwei Tagen hatte er über 100.000 Rechner weltweit infiziert. Insgesamt wurde die Zahl der infizierten Systeme auf über eine Million geschätzt mit einem Schaden von 80 Millionen US-Dollar. Der Virus infiziert Word 97- und Word 2000-Dokumente und versendet sich automatisch per E-Mail an bis zu 50 Adressen aus dem Outlook-Adressbuch. Dies führte zur Überlastung und schließlich zum Zusammenbruch vieler Mailserver. Die ursprünglich infizierte Nachricht lief über eine Newsgroup und enthielt ein Attachment mit Passwörtern für Sex-Sites. Im März noch wurde David Smith (Pseudonym VicodinES) vom FBI verhaftet und am 8. April 1999 angeklagt. Gerüchten zufolge konnte Smith aufgrund der umstrittenen Seriennummer (GUID-Nummer), die Microsoft heimlich den Anwendern der Word-Software anheftet, gefasst werden. Der damals 30-jährige war als Programmierer bei AT&T tätig. Ende August gab er zu, unter anderem den MakroVirus Melissa verfasst zu haben und illegal in das System von AOL eingedrungen zu sein, um dort den Virus auszusetzen. Um seine Spuren zu verwischen, hat er anschließend den Rechner, mit dem er Melissa geschrieben hat, zerstört.
3.4. Berühmte Hacker und Cracker
91
David Smith bekannte sich schon im Dezember 1999 schuldig, Melissa entwickelt, freigesetzt und damit einen Schaden von 80 Millionen US-Dollar verursacht zu haben. Damit hat Smith nach amerikanischem Recht eine Gefängnisstrafe zwischen 46 und 57 Monaten zu erwarten sowie eine Geldstrafe in Höhe von maximal 160 Millionen US-Dollar. Bis heute wurde jedoch kein Urteilsspruch gefällt. Dieser wurde seit dem 18. Februar 2000 schon zum fünften Mal nun auf den 10. September 2001 verschoben. Smith befindet sich seit Dezember 1999 gegen eine Kaution von 100.000 US-Dollar auf freiem Fuß. Onel de Guzman und der „I LOVE YOU“-Virus Am 4. Mai 2000 wurde ein neuer E-Mail-Wurm entdeckt, der sich rasant im Internet verbreitete. Weltweit wurden so innerhalb kürzester Zeit die E-Mail-Systeme vieler Unternehmen, Behörden und Parlamente lahm gelegt. In Deutschland beispielsweise gelang es „ILOVEYOU“, in mehrere Bundes- und Länderministerien vorzudringen, den weltgrößten Hersteller der Druckbranche, die Heidelberger Druckmaschinen AG, sowie den Reisekonzern TUI und die Kieler Werft HDW zu infizieren. Beim ZDF in Mainz legte er die gesamte Kommunikation lahm. Die Produktion der „Mittelbayerischen Zeitung“ in Regensburg war derart betroffen, dass nur eine Notausgabe erscheinen konnte. Und auch der Terminkalender der Expo 2000Geschäftsführerin Birgit Breuel wurde durch „ILOVEYOU“ beschädigt. In den USA schlich sich der Wurm in die Netzwerke des Kongresses, des Verteidigungsministeriums, der Zentralbank, der Küstenwache und vieler weiterer Behörden ein. Es wurde geschätzt, dass 60 bis 80 Prozent aller Unternehmen in den USA betroffen waren. Die Schadensfunktion steckte in einem Dateianhang (Attachment) einer E-Mail mit dem Titel „ILOVEYOU“ und der Textnachricht: „kindly check the attached LOVELETTER coming from me“. Durch Aktivierung des Attachments wurde das enthaltene Visual Basic-Script-Programm LOVE-LETTER-FOR-YOU.TXT.vbs gestartet. Befallen wurden ausschließlich Windows-Rechner mit Internet Explorer 5.0. Der E-Mail-Wurm kopiert die Dateien Win 32DLL.vbs, MS Kernel32.vbs, LOVE-LETTER-FOR-YOU.HTM und LOVE-LETTER-FOR-YOU.TXT.vbs, die den Code des E-Mail-Wurms enthalten, ins Windows-Verzeichnis bzw. WindowsSystemverzeichnis. Außerdem überschreibt er unwiederbringlich Dateien mit den Erweiterungen VBS, VBE, JS, JSE, CSS, WSH, SCT, HTA, MP3, MP2, JPG und JPEG mit seinem eigenen Code und hängt zusätzlich „.vbs“ an den Dateinamen an. Wird eine der überschriebenen Dateien aktiviert, wird der Wurm neu installiert. Zusätzlich wird die Registry von „ILOVEYOU“ durch Einfügen der Keys HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\ MSKernel32 und HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices\ Win32DL so verändert, dass „ILOVEYOU“ bei jedem Booten des Rechners neu gestartet wird. Er verändert die Startseite des Internet Explorers auf eine von mehreren möglichen Seiten, die den Code WIN-BUGSFIX.EXE enthalten. Dieser kann dann heruntergeladen, ausgeführt und damit der Code des Wurmes modifiziert werden, wodurch dieser eine gewisse Mutationsfähigkeit be-
92
3 Hacker und Cracker
sitzt. Nach dem Start bzw. bei bestimmten Alarmzeiten ruft „ILOVEYOU“ die Funktion WNetEnumCashedPasswords auf und schickt anschließend die so ermittelten RAS-Passwörter an die E-Mail-Adresse „
[email protected]“. Der E-Mail-Wurm verbreitete sich sowohl über E-Mail mithilfe von Outlook als auch über mIRC („Internet Relay Chat“-Client). Der Wurm verschickt sich selbst an offenbar unbegrenzt viele Adressaten, die er im Outlook-Adressbuch des befallenen Nutzers findet, mit dem Namen des Geschädigten als Absender bzw. über IRC DCC-Downloads an alle Teilnehmer desselben IRC-Channels. Im Juni 2000 wurde schließlich der philippinische Informatikstudent Onel de Guzman unter Strafanzeige verhaftet. Ein Internet-Service-Provider hatte dem Philippine National Bureau of Investigation (NBI) den Hinweis gegeben, dass der E-Mail-Wurm seinen Ursprung in der Wohnung des philippinischen Bankangestellten Reonel Ramones hatte. Nachdem feststand, dass Ramones nicht der Urheber von „ILOVEYOU“ war, fiel der nächste Verdacht auf seine Freundin Maria Irene de Guzman, die gerade ihr Informatikstudium beendet hatte. Auf Onel de Guzman, dem Bruder von Maria Irene de Guzman, wurden die Ermittler des NBI schließlich aufmerksam, weil seine Examensarbeit Ähnlichkeiten mit dem Programmcode des Loveletter-Wurms aufwies. Diese war von den Gutachtern des AMA Computer Colleges mit der Begründung, dass das Programm zum Stehlen von Passwörtern illegal sei, abgelehnt worden. Eindeutige Beweise liegen nicht vor, jedoch räumte de Guzman ein, dass er den Wurm möglicherweise aus Versehen in die Welt gesetzt haben könnte. Eine direkte Folge dieses Vorfalls ist die Schaffung eines neuen Gesetzes gegen Computerkriminalität, das vom philippinischen Präsident Joseph Estrada im Juni 2000 unterzeichnet wurde. Für de Guzman kommt dieses allerdings zu spät, da seine Tat vor Inkrafttreten des Gesetzes erfolgte. Die einzige Möglichkeit schien eine Anklage wegen Diebstahls und Scheckkartenbetrugs. Diese Anklagen wies das Justizministerium jedoch mit der Begründung ab, dass die angeführten Delikte nicht auf den Bereich der Computerkriminalität anwendbar seien und die vom Untersuchungsausschuss zusammengetragenen Beweismittel nicht für eine rechtskräftige Verurteilung ausreichten. Im August 2000 musste somit die philippinische Staatsanwaltschaft bekannt geben, dass es keine rechtliche Grundlage gebe, gegen den 23-jährigen Hacker strafrechtlich vorzugehen. Als einzige verbleibende Möglichkeit wird nun geprüft, ob Zivilklagen gegen de Guzman Erfolg haben könnten, doch dazu muss ein Verlust durch den zerstörerischen Virus nachgewiesen werden können. Mafiaboy und die Distributed-Denial-of-Service-Angriffe Bei Denial-of-Service-Angriffen wird versucht, durch Ausnutzung von Schwachpunkten in der Konzeption oder Implementierung von Diensten ein System durch Absturz oder Überlastung zum Erliegen zu bringen. Die Angriffstechniken sind dabei seit Jahren bekannt: UDP-Flood, TCP-SYN-Flood und PING-Flood mit IP-Spoofing. Eine neue Variante mit verheerenden Folgen trat erstmals Mitte 1999 auf: die „Distributed Denial of Service Attacks“ (DDoS-Attacken). Wie der Name besagt,
3.4. Berühmte Hacker und Cracker
93
erfolgt der Angriff nicht mehr von einem einzelnen und damit leichter zu lokalisierendem Ausgangspunkt aus, sondern koordiniert von vielen hierarchisch geordneten Einzelsystemen. Die Anzahl der an einem Angriff beteiligten Systeme kann dabei von wenigen bis einige hundert variieren. Die entsprechende Angriffssoftware (so genannte Agents und Handler) werden mittels Trojanischer Pferde auf Computer nichts ahnender Benutzer eingeschleust. Der Angriff wird von den Agents durchgeführt, koordiniert wird dieser jedoch über die so genannten Handler. Agents melden sich bei einem erreichbaren Handler an und bekommen dann ihre Aufgabe zugeteilt. Die Kommunikation zwischen den Komponenten erfolgt (in manchen Tools) verschlüsselt oder über Kontrollnachrichten (ICMP). Sofern die infiltrierten Systeme es erlauben, senden die Agents die Angriffssignale mit falschem Absender (IPSpoofing). Durch diese verschiedenen Mechanismen ist der Angriff nur schwer zu entdecken und noch schwieriger zu blockieren. Benutzt wurden für die Angriffe Tools wie „Stacheldraht“ (vom deutschen Programmierer „Randomizer“) und „Tribe Flood Network“ (TFN). Das Ziel dieser DDoS-Angriffe waren große Sites wie Dell Computer, Amazon, eBay, Yahoo, CNN und ZDNet. Diese Sites waren durch die Angriffe jeweils wenige Stunden nicht mehr erreichbar. Schätzungen des FBIs zufolge belief sich der von „Mafiaboy“ verursachte Gesamtschaden auf rund 1,7 Mrd. US-Dollar. Nachdem zuerst der 20-jährige deutsche Hacker „Mixter“, Programmierer der DDoS-Tools (TFN) und deren überarbeitete Version TFN2K, und der 17-jährige Nordamerikaner „Coolio“ unter Verdacht standen und in den Medien „vorverurteilt“ wurden, wurde am 15. April 2000 in Montreal ein 15-jähriger Kanadier mit dem Spitznamen „Mafiaboy“ festgenommen. Zum Verhängnis wurde „Mafiaboy“, dessen richtiger Name nach kanadischem Recht nicht veröffentlicht werden darf, seine eigene Eitelkeit. Wiederholt hatte er vor seinen Freunden per E-Mail und in Chats mit seinen Attacken geprahlt. Dabei ging er so weit, dass er verriet, welche Tools er benutzt und wo er die belastenden Festplatten „versenkt“ hatte. Er bekannte sich zu 56 der 66 ihm zur Last gelegten DDoS-Angriffe, darunter auf die Sites von CNN, Yahoo, Dell, Amazon, EBay und weitere in Kanada, den United States, Dänemark und Korea. „Mafiaboy“ drohen nach kanadischem Recht bis zu zwei Jahre Haft und 1000 kanadische Dollar Strafe. Bei einer Anhörung vor dem Jugendgericht im Juni 2001 empfahl der vom Gericht benannte Sozialarbeiter Chung einen 5-monatigen Aufenthalt in Obhut, da der Angeklagte seiner Einschätzung nach keine Einsicht oder Reue zeigen würde. Die DDoS-Angriffe, die in großer Deutlichkeit zeigten, wie anfällig das Internet ist, lieferten Politikern der verschiedenen Länder die Gelegenheit, die Notwendigkeit eines höheren Schutzes der Infrastruktur hervorzuheben und stärkere Überwachung und Kontrollen zu fordern. So warb die Clinton-Regierung für die im nächsten Haushalt vorgesehene Erhöhung der entsprechenden Ausgaben auf zwei Milliarden Dollar für die Einrichtung von FIDNET (Federal Intrusion Detection Network), die steigenden Personalausgaben für Computerexperten und die Einrichtung eines „Institute for Information Infrastructure Protection“. Auch der deutsche Bundesinnenminister Otto Schily wurde sehr schnell aktiv und kündigte die Einrichtung einer Task-Force zur Bekämpfung der Internet-Kriminalität an.
94
3 Hacker und Cracker
3.5 Motivation von Hackern und Crackern Hacker/Cracker (im Folgenden wird zur Vereinfachung nur von „Hackern“ und „Hacking“ gesprochen) dringen in fremde Computersysteme ein, schauen sich im harmlosesten Fall Daten anderer Leute an und haben meist kaum ein Unrechtsgefühl dabei. Vielmehr haben die meisten eine rationale Erklärung für ihr Tun. Die Rechtfertigungen umfassen ein weites Spektrum, von denen im Folgenden die wichtigsten vorgestellt werden. Es handelt sich um eine ungeordnete Aufzählung von möglichen Hacking-Motiven. In der Realität wird es selten ein einziges Motiv für das Hacking geben, sondern es wird in der Regel eine Kombination der verschiedensten Motive sein. Die Gewichtung der Einzelmotive hängt im Wesentlichen vom jeweiligen Angreifertyp ab. Sucht/Besessenheit Vor allem jugendliche Hacker haben oftmals Probleme mit ihren Eltern. Der Computer wird so zum Ersatz. Fehlende Kommunikationspartner werden durch den Computer ersetzt, oder der Computer dient als Kommunikationsmedium. Das Hacking wird für sie lebensnotwendig. Die benötigte Soft- und Hardware wird durch Hacking beschafft. Das Motiv Sucht bzw. Besessenheit wird nicht nur von den Gegnern als Argument verwendet, sondern auch von den Hackern und ihren Verteidigern selbst. Neugierde Ein weniger abwertendes Motiv für Hacking ist die Neugierde auf technische Details und Zusammenhänge. Der Reiz der Sache ist oftmals bei jugendlichen Straftätern das Motiv. Die Befriedigung, ein bestimmtes System oder eine Organisation „erobert“ oder einfach ein kompliziertes Problem gelöst zu haben, führt zur Steigerung des Selbstwertgefühls. Der „Nebeneffekt“ eines evtl. finanziellen Vorteils spielt dabei selten eine Rolle. Anerkennung/soziale Motivation Ein weit verbreitetes Motiv ist das soziale Gefüge und dessen Rituale. Gerade in den Siebzigerjahren, als es noch die „wahren“ Hacker gab, war es in der Hacker-Szene sehr wohl üblich, dass man sich durch einen spektakulären Hack einen gewissen Ruf verschaffen musste. Dies ist vergleichbar mit einer Mutprobe oder einem Aufnahmeritual. Erst dann durfte man sich Hacker nennen und wurde in eine klar abgegrenzte Gruppe von Leuten integriert, was dann auch eine gewisse soziale Stellung und ein soziales Umfeld ergab. Durch den Hack erlangen die Hacker die Anerkennung in der Hacker-Gemeinde, gewinnen ein Gefühl der Überlegenheit und der Kontrolle.
3.5. Motivation von Hackern und Crackern
95
Langeweile Oftmals wird von den Hackern Langeweile und das Fehlen von geistiger Stimulanz als Motiv für ihre Taten angegeben. Sie fühlen sich in der Schule bzw. der Universität mental unterfordert und finden die angebotenen Systeme unbefriedigend. Sie suchen nach neuen Herausforderungen. Machtgefühl Das Gefühl, „alles“ kontrollieren zu können, bereitet einen besonderen Reiz. Dabei spielt der finanzielle Aspekt eine geringe bis keine Rolle. Einzig das Wissen, die Gesellschaft oder ein politisches System empfindlich schlagen zu können, ist von Bedeutung. Technische Motivation Als Motivation für einen Hack werden oftmals die Aufdeckung von Lücken und die Verbesserung der allgemeinen Systemsicherheit angegeben. Dies ist jedoch ein sehr kontrovers diskutiertes Argument. Es ist wahr, dass viele Sicherheitslücken dadurch entdeckt und geschlossen wurden. Manche Hacker gehen sogar so weit zu behaupten, sie würden der Gesellschaft eine Dienstleistung erbringen, wenn sie in Computer eindringen und damit auf Sicherheitsmängel aufmerksam machen. Manche wünschen sich dafür sogar eine Belohnung oder zumindest Anerkennung. Die Gegenseite argumentiert, dass es nicht notwendig sei, in Systeme einzudringen oder gar lahm zu legen, um die Sicherheitslücken aufzuzeigen. Eine simple Mitteilung an den Hersteller oder Systemadministrator würde genügen. Dass dies nicht der Fall ist, zeigen die vielen erfolgreichen Hacks, die altbekannte Sicherheitslücken ausgenutzt haben, für die längst Patches bzw. Anweisungen zur Behebung vorlagen. Doch rechtfertigt dies kriminelles Vorgehen? Robin-Hood-Syndrom Das Robin-Hood-Syndrom ist eher bei den jugendlichen Tätern zu finden. Dieser wohl eher weltanschauliche Grund für das Hacking ist, durch Umverteilung von finanziellen Werten, beispielsweise durch Manipulation von Bankkonten, die Welt zu verbessern. Politische und ideologische Motivation Hinter Angriffen auf staatliche, soziale oder auch wirtschaftliche Organisationen stehen oftmals politische oder ideologische Gründe. Manche Hacker verstehen sich als Beschützer der Gesellschaft. Mit dem Hack wollen sie ihre politische Meinung kundtun. Der Feind ist der „Big Brother“, der alles überwacht und kontrolliert. Durch das Eindringen in deren Netze, Manipulationen beispielsweise der WebSeiten oder auch Entwenden und Veröffentlichung von sensitiven Daten werden die großen Widersacher kontrolliert und deren Ruf geschädigt.
96
3 Hacker und Cracker
Finanzielle Probleme/Finanzielle Bereicherung Finanzielle Bereicherung bzw. Habgier ist mit Abstand der häufigste Beweggrund für das Hacking. Ist der Täter finanziellem Druck ausgesetzt, steigt auch die Bereitschaft, die ihm anvertrauten Daten zur Sanierung seiner Finanzen zu missbrauchen. Das direkte Verwenden der Daten beispielsweise für eine Erpressung oder aber der Verkauf der Daten werden fälschlicherweise als einfaches Mittel zum Zweck mit geringem Risiko betrachtet. Rache Rache als Motiv für ein Computerdelikt ist nicht selten. Das Ziel dabei ist meist, Schaden anzurichten. Der Grund ist vermeintliches oder tatsächliches Unrecht, das dem Täter selbst zugefügt wurde. Sexueller Missbrauch Etwas fragwürdig ist die im Seminar „Psychology of a Hacker“ auf der RSA Data Security Conference veröffentliche These des kanadischen Psychologen Marc Rogers, die besagt, dass der durchschnittliche Hacker aus der Mittelklasse stammt, weiß und zwischen 12 und 28 Jahre alt ist, wenig soziale Kontakte hat und mit hoher Wahrscheinlichkeit als Kind sexuell missbraucht wurde. Die Zuhörer der Veranstaltung reagierten auf diese These mit einem Sturm der Entrüstung. Marc Rogers ist ein ehemaliger Angestellter der kanadischen Polizei und promovierte über das Thema „Cyberterrorismus“. Er erstellte Studien zur Psychologie von Hackern, um ihre Vorgehensweise besser erklären zu können.
3.6 Ablauf von Angriffen Es gibt verschiedene Vorgehensweisen, um einen Angriff durchzuführen. In diesem Abschnitt stellen wir typische Schritte, die nicht notwendigerweise in der angegebenen Reihenfolge stattfinden müssen, vor. Es kann auch durchaus vorkommen, dass einige Schritte überlappen oder vollständig zusammenfallen. So werden beispielsweise Abtastungen während der Erkundungsphase durchgeführt. Im Folgenden stellen wir einige dieser Techniken vor. Erkundung Grundsätzlich werden in diesem Schritt Information über das potenzielle Opfer gesammelt. Dazu gehören zunächst die Netzwerk- und Rechneradressen, die ohne Aufsehen zu erregen beschafft werden können. D.h., in dieser Phase werden Standardinformationsdienste wie etwa DNS oder whois eingesetzt. Zusätzlich kann auch das WWW-Angebot des Opfers nach verwertbaren Informationen (Namen,
3.6. Ablauf von Angriffen
97
Telefonnummern, E-Mail-Adressen etc.) durchsucht werden. Oftmals resultieren auch Recherchen mit gängigen Suchmaschinen in brauchbaren Informationen. Abbildung 3-1 zeigt so beispielsweise das von uns anonymisierte Ergebnis einer Abfrage nach dem Stichwort „Firewall“ und dem Arbeitsgeber des Firewall-Administrators. Neben Name und E-Mail-Adresse konnte dieser Nachricht, die in einem E-Mail-Archiv des Firewall-Anbieters zu finden war, das eingesetzte FirewallProdukt, ein Zusatzmodul und das Betriebssystem entnommen werden. Außerdem wurden alle Kontaktinformationen, wie etwa Telefonnummer und Anschrift, genannt. At 10:02 AM 2/10/99 +0100,
[email protected] wrote: > > Hi! > > we use FIREWALL PRODUCT with SOME MODULES running on NT. > > Are there any known problems with BROWSER X? > > Thank you in advance. > > >
[email protected] > > Tel. (0xxx) xxx-xxxxx > Fax (0xxx) xxx-xxxxx > > Arbeitgeber > Abteilung > Strasse > PLZ Stadt Abb. 3-1 Erkundung mit Suchmaschinen
Oft kann auch aus Rechnernamen die Funktion eines Systems abgeleitet werden. So deuten Namen wie gatekeeper.my-victim.de oder fw.my-victim.de darauf hin, dass sich hinter den Namen eine Firewall verbirgt. Nachdem der Angreifer Informationen aller Art gesammelt hat, geht er auf dieser Basis in die Phase der Abtastung über. Abtastung Mit den gesammelten Informationen ist der Angreifer nun in der Lage, gezielt bestimmte Systeme nach Anwendungsdiensten abzutasten. Es geht dabei primär darum, Systeme zu finden, die eine ausnutzbare Verletzlichkeit aufweisen. In Abbildung 3-2 wird das Ergebnis einer Abtastung mit dem Programm nmap [52] gezeigt. In diesem Fall konnten das Betriebssystem und die angebotenen Dienste identifiziert werden. Es wird ebenfalls ermittelt, wie aufwändig es ist, die Sequenznummern einer TCP/IP-Verbindung zu erraten – in diesem Fall ist es sehr schwierig. Je
98
3 Hacker und Cracker
nach der verwendeten Abtasttechnik fällt dieser Vorgang mehr oder weniger auf. So ist beispielsweise die Verwendung eines Programms, das in kurzen, regelmäßigen Abständen eine ping-Anfrage an jeden Rechner in einem Netzwerk sendet, sehr auffällig und kann mit herkömmlichen Hilfsmitteln leicht entdeckt werden. Es gibt aber auch Werkzeuge, die vergleichsweise „leise“ arbeiten, so dass solche Analysen nur schwerlich detektiert werden können. Derartige Programme arbeiten beispielsweise mit zufällig gewählten Zeitabständen zwischen den einzelnen Anfragen, so dass kein von einem Intrusion Detection System (IDS) erkennbares Muster entsteht. Interesting ports on target.my-victim.de (192.168.83.70): (The 1503 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 110/tcp open pop-3 111/tcp open sunrpc 515/tcp open printer 2049/tcp open nfs 2401/tcp open cvspserver 3306/tcp open mysql TCP Sequence Prediction: Class=random positive increments Difficulty=3883648 (Good luck!) Remote operating system guess: Linux 2.1.122 - 2.2.14 Abb. 3-2 Ergebnis einer Abtastung mit einem Netzwerk-Scanner
An dieser Stelle möchten wir anmerken, dass nicht alle Analysen über IP-basierte Netzwerke durchgeführt werden. Typischerweise hat der Angreifer während der Erkundungsphase einige Telefonnummern ermittelt. Oft lässt sich so auf weitere Rufnummern der Nebenstellenanlage eines Unternehmens schließen. Mithilfe eines Wardialers1 lässt sich nun herausfinden, ob sich hinter bestimmten Rufnummern ein Modemanschluss, der sich ggf. attackieren lässt, befindet. Auf diese Weise kann ein Angreifer leicht einige Sicherheitsmaßnahmen, wie z.B. Firewalls, umgehen und sich Zugang zu internen Systemen verschaffen. Ziel dieser Phase ist es, umfangreiche Informationen über die Systeme und die laufenden Dienste potenzieller Opfer zu beschaffen. In einem weiteren Schritt können diese Informationen mit einer Datenbasis, die bekannte Verletzlichkeiten enthält, abgeglichen werden. Damit weiß der Angreifer genau, wie er die Systeme angreifen kann, d.h., der Angriff kann durchgeführt werden.
1
Ein Programm, das systematisch einen vorgegebenen Rufnummernblock wählt.
3.6. Ablauf von Angriffen
99
Durchführung Je nach den Motiven und dem, was ein Angreifer erreichen will (siehe Abschnitt 3.5), werden Angriffe auf die unterschiedlichste Art und Weise ausgeführt. Abhängig davon werden die entdeckten Verletzlichkeiten ausgenutzt. Dabei spielt es auch eine entscheidende Rolle, wo sich der Angreifer und das attackierte System befinden. Als Innentäter stehen dem Angreifer so Möglichkeiten offen, den internen Zugang zu einem System zu nutzen, um mit Verletzlichkeiten der dort installierten Software seine Ziele zu erreichen. Angriffe, die über das Netzwerk durchgeführt werden, können sich auf Server, die einen Dienst anbieten, richten. In diesem Fall ist der Angreifer in der Rolle eines bösartigen Klienten. Umgekehrt kann aber auch ein manipulierter Server dazu verwendet werden, um legitime Klienten zu hintergehen. Schließlich kann sich der Angreifer auch in einen Kommunikationskanal einklinken. In diesem Fall spielt er den Man-in-the-Middle, der entweder passiv Informationen sammelt oder aber aktiv bestimmte Nachrichten manipuliert. Ein Beispiel für einen Angriff ist die Modifikation von Systemdateien. So gelingt es einem Angreifer beispielsweise, einen neuen Benutzer mit einem ihm bekannten Passwort anzulegen. In ähnlicher Weise könnte er sich auch bestimmte Systemdateien etwa via E-Mail zusenden. In beiden Fällen steht ihm das System für weitere Angriffe auf andere Systeme offen. Neben dem unbefugten Informationsgewinn oder der Manipulation kann ein Angreifer es auch auf die Verfügbarkeit abgesehen haben. In diesem Fall blockiert er Systemdienste oder bringt sie zum Absturz. Manche Angriffe bestehen aus der Ausnutzung einer einzelnen Verletzlichkeit. Andere verwenden bereits attackierte Zwischensysteme für weitere Angriffe. Es kann aber auch dazu kommen, dass ein Angreifer zusätzliche Software installiert, um so zu einem beliebigen späteren Zeitpunkt durch eine Hintertür leicht Zugang zu erlangen. Solche Werkzeuge können auch Informationen sammeln und versenden. Schließlich ist es möglich, koordinierte Attacken durchzuführen (beispielsweise ein Distributed Denial of Service-Angriff). Grundsätzlich gilt dabei die Regel, dass viele Zwischensysteme das Aufspüren eines Angreifers erheblich erschweren, wenn nicht sogar unmöglich machen. Je länger solche Ketten sind, desto wahrscheinlicher ist es, dass wichtige Informationen oder die Bereitschaft zur Kooperation verloren gehen. Verwischen der Spuren Um einer Entdeckung zu entgehen, versucht ein versierter Angreifer, möglichst wenige Spuren zu erzeugen. Er wird aber auch versuchen, seine Spuren zu verwischen oder vollständig zu beseitigen. Im einfachsten Fall werden dabei Log-Dateien modifiziert oder gelöscht, wobei das Fehlen einer Datei eher auffällt als eine geschickte Modifikation. Es können aber auch komplexere Vorkehrungen getroffen werden, so dass das Erzeugen von Spuren unterbunden wird. Bei einer bestimmten Technik werden beispielsweise versteckte Verzeichnisse verwendet, um dort Programme, die für den Angriff benötigt werden, zu installieren. Es können aber auch bestimmte Systemprogramme ersetzt werden, so dass die Präsenz
100 3 Hacker und Cracker
des Angreifers auf den ersten Blick gar nicht auffällt. Unter Unix-Systemen könnten hier etwa Programme wie ps, who, top oder w ausgetauscht werden. Es ist in diesem Zusammenhang sogar denkbar, ganze Laufzeitbibliotheken oder sogar Kernel-Module zu ersetzen. Oftmals werden solche Funktionen zum Verwischen der Spuren gebündelt in Rootkits, die auf bestimmte Systeme zugeschnitten sind, zusammengestellt.
3.7 Relevante Informationsquellen Durch das zunehmende Interesse der Öffentlichkeit kommt immer öfter die Frage auf: „Wie werde ich ein Hacker?“ Die Anworten darauf, wie sie beispielsweise in Foren wie den Newsgroups de.comp.security oder de.org.ccc gegeben werden, verweisen typischerweise darauf, dass selbst bei großem Interesse und Einsatz einige Jahre vergehen, bis man sich als richtiger “Hacker“ fühlen kann. Allein um sein eigenes Betriebssystem zu beherrschen, ist bereits ein enormes Hintergrundwissen erforderlich. Typischerweise dient ein freies, Unix-ähnliches Betriebssystem, wie beispielsweise Linux oder FreeBSD, als Basis für die Streifzüge im Netz. Ist dieses System richtig installiert und konfiguriert, muss noch ein IP-Zugang zum Internet geschaffen werden. Dabei werden reine Internet-Provider mit PPP-Zugang gegenüber Online-Diensten wie T-Online oder AOL bevorzugt, da letztere u.a. die eigentliche Funktionalität hinter grafischen Benutzungsoberfächen verstecken und z.T. sogar modifizierte und damit nicht kompatible Protokolle verwenden. Der fortgeschrittene Hacker weiß, wie neue Kernels für das System erstellt werden, und kann so z.B. die sicherheitsrelevante Unterstützung für Firewalls und Paketfilter erreichen. Ein Muss für jeden Hacker sind umfassende Kenntnisse gängiger Programmiersprachen wie C/C++ und Perl. Um sich im Netz bewegen zu können, erweist sich ferner Erfahrung im Umgang mit den grundlegenden Netzwerkanwendungen ftp, telnet, sendmail etc. als unverzichtbar. Das intensive Studium der entsprechenden RFCs ist dabei besonders hilfreich. Um sich dieses Wissen und vor allem Erfahrung mit dem Umgang und den Schwachstellen von vernetzten IT-Ressourcen aneignen zu können, bietet sich eine Vielzahl von Informationsquellen an, die sich teilweise deutlich unterscheiden. Im Folgenden werden einige repräsentative Informationsquellen vorgestellt. 3.7.1 Computer Emergency Response Teams Die Computer Emergency Response Teams (CERTs) sind häufig nicht gewinnorientierte Organisationen, die sich aus größeren Projekten oder Gruppen heraus entwickelt haben. Der Ursprung der CERTs liegt im amerikanischen CERT Coordination Center (CERT/CC). In Deutschland wäre hier beispielsweise das DFN-CERT zu nennen, das sich aus dem Deutschen Forschungsnetz (DFN) heraus entwickelt hat. Ein weiteres Beispiel ist das australische AUSCERT. Ziel der CERTs ist es, Informationen über Verletzbarkeiten zu sammeln und bereitzustellen. Dies geschieht in der Regel im Rahmen so genannter „Advisories“. Dabei warnen die CERTs regel-
3.7. Relevante Informationsquellen 101
mäßig nur vor extrem gefährlichen oder aber einen besonders breiten Personenkreis betreffenden Verletzlichkeiten und beobachten darüber hinaus auch Bereiche wie Viren oder Trojaner. Da die CERTs jedoch großen Wert auf Vollständigkeit der Informationen innerhalb der Advisories legen, sind diese nicht immer aktuell, da eine gewisse Zeit benötigt wird, um die Informationen zu allen Aspekten einer Verletzbarkeit sowie die Möglichkeiten, die Verletzbarkeit zu beseitigen, zusammenzutragen. Außerdem verfolgen viele CERTs die Strategie, Informationen über Verletzbarkeiten erst dann zu veröffentlichen, wenn deren Beseitigung sichergestellt ist, so dass oft eine Veröffentlichung eines Advisories weiter verzögert wird. Über die Advisories hinaus gibt es beim CERT/CC zwei weitere regelmäßige Mitteilungstypen: Einerseits gibt es die „Vulnerability Notes“, die Informationen über neu entdeckte Verletzlichkeiten enthalten. Dabei können sich aus Vulnerability Notes zu einem späteren Zeitpunkt Advisories entwickeln. Andererseits gibt es die „Incident Notes“, die Informationen über ungewöhnliche Vorfälle im Internet enthalten, die sich möglicherweise später als Versuche zur Ausnutzung einer Verletzbarkeit erweisen könnten. Um die aktuellen CERT-Advisories zu erhalten, kann man entweder die WWW-Seiten des jeweiligen CERT nutzen oder die in der Regel angebotenen Mailing-Listen abonnieren. Neben diesen öffentlichen, nationalen CERTs gibt es noch eine Reihe weiterer Organisationen, die sich ähnlich wie ein CERT auf Informationen und Beratung zum Thema IT-Sicherheit spezialisiert haben. Dabei handelt es sich nicht selten um staatliche Organisationen, wie etwa die Computer Incident Advisory Capability (CIAC), die eine Einrichtung des amerikanischen Energieministeriums ist. Sie unterstützt auf Anfrage alle Einrichtungen des Energieministeriums bei Vorfällen, die die IT-Sicherheit betreffen. Eine ähnliche Rolle (allerdings nur für die amerikanische Bundesregierung und ihre Einrichtungen) spielt die Federal Computer Incident Response Capability (FedCIRC). 3.7.2 Hacker-Gruppen Eine weitere wichtige Quelle für Informationen über Schwachstellen stellen Hacker-Gruppen dar. Dabei handelt es sich um Gruppen von Individuen, die sich, häufig mit nicht eindeutig legalen Zielen, aber mit sehr hohem Engagement und Knowhow damit beschäftigen, Verletzlichkeiten in IT-Ressourcen aufzuspüren. Dieses Wissen wird dann zumindest von einigen Hacker-Gruppen veröffentlicht. Dabei wird dann in der Regel nicht darauf geachtet, ob Dritten durch das frühzeitig veröffentlichte Wissen über Angriffsmöglichkeiten möglicherweise Schaden zugefügt werden könnte. Die Hacker-Gruppen nutzen zum Informationsaustausch häufig eigene WWWSeiten, manchmal auch öffentliche Newsgroups im USENET oder auch IRC-Kanäle und ICQ-Kommunikation. Beispiele für Hacker-Gruppen, die im Internet eigene Web-Seiten betreiben, sind der Chaos Computer Club (CCC), Phrack oder auch L0phT, eine Gruppe, die inzwischen auch im kommerziellen Bereich als IT-Sicherheits-Beratungsunternehmen tätig ist (L0phT wurde mittlerweile von dem Unternehmen @stake als Forschungsbereich übernommen).
102 3 Hacker und Cracker
3.7.3 Sicherheitsunternehmen Viele Beratungsfirmen für IT-Sicherheit und Hersteller von Sicherheitssoftware veröffentlichen regelmäßig Informationen zu Schwachstellen. Dies geschieht allerdings meist nicht uneigennützig, sondern dient als Nachweis für die eigene Kompetenz und, im Falle der Hersteller, natürlich auch, um Werbung für eigene, Schutz bietende Produkte oder Dienstleistungen zu machen. INFILSEC Systems Security bezeichnet seine Datenbankangebote beispielsweise als eine „Vulnerability Engine“, die als Werkzeug für Hersteller, Systemadministratoren, Sicherheitsberater und Analysten dienen soll, und verfolgt damit den Aufbau und Betrieb eines zentralen Repositorys für Verletzbarkeiten von Betriebssystemen, Anwendungen und Protokollen. Außerdem werden Informationen darüber, wie diesen Verletzbarkeiten begegnet werden kann, gespeichert. INFILSEC will die Ergebnisse von Mailing-Listen wie Bugtraq extrahieren und über seine Suchmaschine zur Verfügung stellen. Dazu stellt INFILSEC ein Online-Update-System zur Verfügung, das die Möglichkeit bietet, Informationen in das System einzuspeisen. Ein weiteres Beispiel ist das Unternehmen Internet Security Systems (ISS), das Sicherheitssoftware und -beratung verkauft und daneben die Datenbank X-Force betreibt. 3.7.4 IT-Unternehmen Eine weitere Quelle stellen IT-Unternehmen selbst dar, die Informationen zu Verletzbarkeiten in ihren Produkten veröffentlichen. Dabei gibt es jedoch nahezu kein Unternehmen, das solche Informationen aus freien Stücken heraus veröffentlicht. Meist werden diese Informationen erst dann veröffentlicht, wenn eine Verletzbarkeit durch eine der anderen Quellen bekannt wird. Dabei muss davon ausgegangen werden, dass im Regelfall nur die Informationen veröffentlicht werden, die im Großen und Ganzen schon bekannt sind, und dass keine initiative Meldung von Verletzbarkeiten, die bisher vermeintlich nur der Hersteller kennt, stattfindet. Als Beispiel für die herstellerseitige Veröffentlichung von Informationen über Verletzbarkeiten kann die Microsoft Security Mailing-Liste dienen. 3.7.5 Newsgroups, Mailing-Listen und Instant Messaging Unterstellt man, dass die „echten“ Hacker ohnehin über aktuelle Informationen zu Verletzbarkeiten verfügen, stellen Newsgroups im USENET und spezielle MailingListen die aktuellsten, öffentlich zugänglichen Quellen für Schwachstelleninformationen dar. Informationen zu diesen Quellen liefern Hacker, Mitarbeiter von IT-Unternehmen und andere IT-Profis. Newsgroups, in denen sicherheitsrelevante Themen diskutiert werden, sind beispielsweise: – comp.security.unix – comp.security.ssh
3.7. Relevante Informationsquellen 103
– – – – – –
comp.security.misc de.comp.security comp.lang.java.security comp.os.ms-windows.nt.admin.security comp.os.netware.security comp.security.firewalls
Sicherheitsbezogene Mailing-Listen existieren ebenfalls in großer Anzahl. Zu den bedeutendsten zählen: – Bugtraq – NT Bugtraq – Alert Es kann weiterhin davon ausgegangen werden, dass Informationen über IRC-Kanäle ausgetauscht werden. Dieses Vorgehen unterstützt insbesondere weltweite Kooperationen und hilft auch dabei, möglichst unerkannt in geschlossenen Benutzergruppen zu bleiben. 3.7.6 Bücher Abschließend sollen noch Bücher als Quelle für Informationen zu Verletzlichkeiten von IT-Ressourcen genannt werden. Dabei können Bücher naturgemäß keine hochaktuellen Themen behandeln. Dafür können sie aber sehr ausführlich Konzepte von traditionellen Fehlern beim Software-Design oder bei Implementierungen der ITRessourcen darstellen. Ein Beispiel für solch ein (Online-)Buch stellt die Abhandlung über Computer-Verletzlichkeiten von Eric Knight dar [66]. 3.7.7 Zusammenfassung Um fundierte Grundlagenkenntnisse zu erhalten und über aktuelle Entwicklungen informiert zu sein, muss eine Reihe von Informationsquellen unterschiedlicher Natur herangezogen werden. Wie sich auch im Hacker Contest herausgestellt hat, erweist sich dies als sehr zeitaufwändiges Unterfangen, bei dem besonders darauf geachtet werden muss, welche Information relevant ist und welche nicht. Wichtige Attribute bei der Betrachtung der beschriebenen Informationsquellen sind: Seriosität, Zuverlässigkeit und Reaktionszeit. In Tabelle 3-1 haben wir in Anlehnung an [108] eine qualitative Einordnung bezüglich dieser Merkmale vorgenommen.
104 3 Hacker und Cracker
Tab. 3-1 Qualitative Einordnung von Informationsquellen
Informationsquelle
Seriosität
Zuverlässigkeit
Reaktionszeit
CERT (Advisory)
hoch
hoch
niedrig
CERT (sonst. Meldung)
hoch
hoch
mittel
Hacker-Gruppen
niedrig
i.d.R. hoch
hoch
Sicherheitsunternehmen
mittel-hoch
mittel-hoch
niedrig-mittel
Newsgroups/Mailing-Listen
niedrig-hoch
niedrig-hoch
hoch
Instant Messaging
niedrig-hoch
niedrig-hoch
hoch
Bücher
mittel-hoch
mittel-hoch
sehr niedrig
Unter Seriosität verstehen wir die Reputation einer Informationsquelle. CERTs sind hier sicherlich hoch einzustufen, wohingegen Hacker-Gruppen im Allgemeinen einen eher zweifelhaften Ruf genießen. Das Kriterium der Zuverlässigkeit bezieht sich auf die Qualität der Information. Auch hier sind CERTs sehr zuverlässig, aber auch Hacker-Gruppen liefern hier in der Regel zuverlässige Informationen. Besonders bemerkenswert ist die Reaktionszeit, d.h. die Zeit, die vom Bekanntwerden einer Verletzlichkeit bis zur Publikation entsprechender Informationen verstreicht. Aufgrund der Veröffentlichungspolitik der CERTs sind hier lange Reaktionszeiten die Regel: Es werden erst dann Informationen herausgegeben, wenn bekannt ist, wie ein Problem beseitigt werden kann. Oft erhält der Hersteller auch einen Hinweis und eine Frist, um an Maßnahmen arbeiten zu können. Mailing-Listen beispielsweise verfolgen hier jedoch eher eine „Full Disclosure“-Politik, d.h., es wird sofort alles über eine Verletzlichkeit bekannt gegeben, auch wenn noch keine Maßnahmen bekannt sind. Der Hintergedanke ist hier, dass der Eigentümer einer IT-Ressource informiert ist und entsprechend reagieren kann, bevor dies ein Angreifer tut. Es wird dabei davon ausgegangen, dass ein versierter Angreifer die entsprechende Verletzlichkeit ohnehin schon kennt.
3.8 Grundsätzliche Bedrohungen In diesem Abschnitt wird ein Überblick über grundsätzliche Bedrohungen gegeben, wie er beispielsweise in dem Internet Security Glossary verwendet wird [104]. Die Bedrohungen werden dabei in folgende Kategorien eingeteilt: – – – –
(unbefugte) Offenlegung Täuschung Unterbrechung Widerrechtliche Aneignung
3.8. Grundsätzliche Bedrohungen 105
Dabei werden den Bedrohungen entsprechende Angriffsmuster zugeordnet. Wie sich zeigen wird, ist es durchaus möglich, dass bestimmte Angriffe zu unterschiedlichen Ergebnissen führen können. So kann beispielsweise der Einsatz von bösartiger Hardware, Firmware oder Software sowohl zu einer Täuschung als auch zu einer Unterbrechung führen. (Unbefugte) Offenlegung Wir sprechen dann von einer unbefugten Offenlegung, wenn es einem Angreifer gelingt, Zugang zu Informationen zu erhalten, die nicht für ihn bestimmt sind. In diesem Fall ist die Vertraulichkeit nicht mehr gewährleistet. Die in Abbildung 3-3 dargestellten Angriffe können zu einer solchen unbefugten Offenlegung führen. Die Unterkategorien der Offenlegung werden im Folgenden besprochen. – Bloßstellung Führt ein Angriff dazu, dass sensible Informationen an unbefugte Dritte gelangen, fällt dies in die Kategorie Bloßstellung. Dies beinhaltet die beabsichtigte Offenlegung und das aktive Durchsuchen von Daten nach brisanten Inhalten. Darüber hinaus können aber auch menschliche Fehlhandlungen zu einer eher unbeabsichtigten Preisgabe von Geheimnissen führen. In vergleichbarer Weise kommen Systemfehler (in Hard- oder Software) als mögliche Ursache in Frage. – Abfangen Sensible Informationen sind auf dem Weg von einer befugten Informationsquelle zu einer befugten Informationssenke. Gelingt es nun einem unbefugten Dritten, direkt auf solche sensible Informationen zuzugreifen, fällt dies in die Kategorie des Abfangens. Dazu gehört der Diebstahl von physikalischen Speichermedien, wie z.B. Festplatten oder Disketten. Außerdem ist es möglich, eine Kommunikation passiv zu belauschen und die so gewonnene Information aufzuzeichnen (Abhören oder Belauschen). Schließlich ist es möglich, Signale, die von einem System ausgestrahlt werden, aufzufangen und auszuwerten (Analyse von Abstrahlungen). Dies ist z.B. die Abstrahlung eines Monitors, die keineswegs zur Kommunikation gedacht ist, aber dennoch auswertbare Informationen enthält.
106 3 Hacker und Cracker
(Unbefugte) Offenlegung
Bloßstellung
Beabsichtigte Offenlegung Aktives Durchsuchen Menschliche Fehlhandlung
Abfangen
Inferenz
Diebstahl Abhören
Eindringen
Analyse des Verkehrs
Physikalischer Zugang
Analyse der Signale
Penetration
Analyse von Abstrahlungen
Nachbau Kryptanalyse
HW/SW Fehler Abb. 3-3 Resultat eines Angriffs: Offenlegung
– Inferenz Wir sprechen von Inferenz, wenn es einem Angreifer auf einem indirekten Weg gelingt, sensible Informationen zu erhalten. Dies müssen nicht zwangsläufig Informationen sein, die über den Kommunikationskanal ausgetauscht werden, d.h., die Informationen können prinzipiell auch verschlüsselt sein. Es werden vielmehr Rückschlüsse aus der Charakteristik oder Nebeneffekten der Kommunikation gezogen. Dazu gehören einerseits die Analyse des Verkehrs, wie z.B. Sender und Empfänger, aber auch Zeitpunkt, Dauer, Frequenz, Informationsmenge und die bloße Tatsache, dass die Kommunikation überhaupt stattfindet. Analog dazu kann indirekt Information aus abgestrahlten Signalen gewonnen werden (Analyse der Signale). – Eindringen Das Eindringen in eine IT-Ressource bedeutet, dass es ein Angreifer schafft, in den Besitz sensibler Informationen zu gelangen, indem er Schutzeinrichtungen umgeht. Der Angreifer erlangt z.B. unbefugten physikalischen Zugang zu Informationen. Es kann zudem sein, dass auf logischer Ebene ein Zugriff auf Informationen möglich ist, d.h., der Angreifer dringt aktiv in die IT-Ressource ein (Penetration). Durch die Analyse des Entwurfs und der Interna einer Systekompo-
3.8. Grundsätzliche Bedrohungen 107
nente kann ein Angreifer ebenfalls sehr viel wertvolle Informationen in Erfahrung bringen, indem er auf diesem Weg einen Nachbau der IT-Ressource erstellt. Falls Informationen verschlüsselt worden sind, kann durch gezielte Analysen versucht werden, auf den Klartext zu schließen (Kryptanalyse). Täuschung Ein Angreifer führt dann eine erfolgreiche Täuschung durch, wenn es ihm gelingt, einem regulären Benutzer oder einer IT-Ressource manipulierte Informationen unterzuschieben, ohne dass dies bemerkt wird. Das potenzielle Opfer geht dann fälschlicherweise davon aus, mit korrekten Informationen zu arbeiten. Die in Abbildung 3-4 dargestellten Angriffe können zu einer derartigen Täuschung führen. Die Unterkategorien der Täuschung werden im Folgenden diskutiert. Täuschung
Maskierung
Fälschung
Vorspiegelung
Austauschen
Bösartige Logik
Einfügen
Nichtanerkennung
Abstreiten des Versendens Abstreiten des Empfangs
Abb. 3-4 Resultat eines Angriffs: Täuschung
– Maskierung Um eine Maskierung durchzuführen, spiegelt der Angreifer eine falsche Identität vor. So erlangt er Zugang zu einem System oder kann eine böswillige Aktion durchführen. Ein Spezialfall dieses Angriffs ist die Vorspiegelung der Identität eines regulären Benutzers oder Systems. Im Zusammenhang mit Maskierung sind an dieser Stelle auch jede Art bösartiger Logik in Hardware, Firmware oder Software (z.B. Trojaner, Würmer, logische Bomben etc.) zu nennen, die augenscheinlich eine gewünschte oder nützliche Funktion durchführen, aber tatsächlich versuchen, dem Angreifer Zugang zu Systemressourcen zu verschaffen oder den Benutzer dazu zu bringen, unwissentlich weitere bösartige Funktionen aufzurufen.
108 3 Hacker und Cracker
– Fälschung Ein Angreifer führt eine Fälschung mit dem Ziel durch, berechtigte Benutzer oder Systeme durch gefälschte Informationen zu täuschen. Dies kann einerseits durch das Austauschen (also die Änderung oder Ersetzung) gültiger Informationen erreicht werden. Andererseits ist es möglich, falsche Informationen einzufügen. – Nichtanerkennung Ein Angreifer kann außerdem die Verantwortung für ein bestimmtes Ereignis oder eine Aktion abstreiten und so versuchen, das Opfer zu täuschen. Typischerweise werden dabei zwei Fälle der Nichtanerkennung unterschieden: Der Angreifer leugnet, dass er bestimmte Informationen generiert hat bzw. bestimmte Aktionen durchgeführt hat (Abstreiten des Versendens). Der Empfänger von Informationen streitet ab, dass er bestimmte Informationen erhalten hat (Abstreiten des Empfangs). Unterbrechung Ein Angriff führt dazu, dass Dienste und Funktionen einer IT-Ressource unterbrochen werden oder nicht mehr korrekt arbeiten. Die in Abbildung 3-5 gezeigten Angriffe können zu einer Unterbrechung führen. Die Unterkategorien der Unterbrechung werden im Folgenden beschrieben. – Verhinderung Der Betrieb einer IT-Ressource wird verhindert oder unterbrochen, indem eine Komponente der IT-Ressource unbrauchbar gemacht wird. Auch in diesem Zusammenhang kann dies z.B. durch bösartige Hardware, Firmware oder Software, die gezielt eingeschleust wird, um Funktionen oder Komponenten der betroffenen IT-Ressource zu zerstören, erreicht werden (bösartige Logik). Außerdem ist es möglich, Komponenten mit Vorsatz physikalisch zu zerstören. Es ist aber auch denkbar, dass unbeabsichtigte menschliche Fehlhandlungen zu einer Unterbrechung führen. In gleichem Maße können Fehler in Hard- oder Software die Ursache für einen Ausfall sein. Schließlich kann höhere Gewalt wie z.B. Feuer, Blitzeinschlag oder Stürme zu einem Schaden führen. – Korrumpierung Durch die Modifizierung von Systemfunktionen oder bestimmten Informationen kommt es zu einer unerwünschten Änderung des Systemverhaltens. In diesem Fall sprechen wir von einer Korrumpierung des Systems. Dies kann zum einen durch eine absichtliche Veränderung (Manipulation) von Logik, Daten oder Kontrollinformationen einer IT-Ressource erreicht werden. Auch in diesem Kontext kann bösartige Logik in Hardware, Firmware oder Software zu solchen Modifikationen führen. Genauso können menschliches Fehlverhalten, Hard- bzw. Software-Fehler oder höhere Gewalt als Ursachen identifiziert werden.
3.8. Grundsätzliche Bedrohungen 109
– Blockierung Die Ausführung von Diensten wird durch einen Angriff unterbrochen, so dass bestimmte Funktionen der IT-Ressource verhindert werden. Dies kann z.B. durch die Blockierung von Kommunikation, Benutzerdaten oder Kontrollinformationen kommen (Interferenz). Zu einer Überlast kommt es dann, wenn eine Komponente der IT-Ressource mit mehr Anfragen überflutet wird, als es verarbeiten kann. Unterbrechung
Verhinderung
Korrumpierung
Bösartige Logik Physikalische Zerstörung Menschliche Fehlhandlung HW/SWFehler Höhere Gewalt
Blockierung
Manipulation
Interferenz
Bösartige Logik
Überlast
Menschliche Fehlhandlung HW/SWFehler Höhere Gewalt
Abb. 3-5 Resultat eines Angriffs: Unterbrechung
Wir weisen darauf hin, dass wir in diesem Buch Bedrohungen, die sich aufgrund höherer Gewalt ergeben, grundsätzlich nicht betracht werden – auch wenn das Ergebnis oftmals den Folgen eines Angriff gleichgesetzt werden kann. Wir konzentrieren uns ausschließlich auf sicherheitsrelevante Bedrohungen, d.h., der Grund ist in einem Angriff zu sehen. Widerrechtliche Aneignung Wenn es einem Angreifer gelingt, die Kontrolle über Dienste oder Funktionen einer IT-Ressource zu übernehmen, so hat er gewissermaßen das Territorium des Opfers besetzt. Die in Abbildung 3-6 gezeigten Angriffe können zu solch einer widerrechtlichen Aneignung führen. Die Unterkategorien der widerrechtlichen Aneignung werden im Folgenden aufgeführt.
110 3 Hacker und Cracker
Widerrechtliche Aneignung
Zweckentfremdung
Missbrauch
Diebstahl eines Dienstes Diebstahl einer Funktion Diebstahl von Daten
Manipulation Bösartige Logik Verletzung von Rechten
Abb. 3-6 Resultat eines Angriffs: Widerrechtliche Aneignung
– Zweckentfremdung Prinzipiell kann ein unbefugter Dritter logische oder physikalische Kontrolle über ein System erlangen, so dass es zu einer Zweckentfremdung kommt. Dies kann beispielsweise als Diebstahl eines Dienstes bezeichnet werden, d.h., ein Dienst wird von einem Angreifer unrechtmäßig benutzt und steht so rechtmäßigen Benutzern nicht mehr zur Verfügung. Außerdem kann ein Angreifer ohne Berechtigung in den Besitz von Hardware, Software oder Firmware einer ITRessource gelangen und ohne Berechtigung dessen Funktion nutzen (Diebstahl einer Funktion). Schließlich können Informationen gestohlen und von einem Dritten zu seinem Vorteil verwendet werden (Diebstahl von Daten). – Missbrauch Es kann ein Angriff durchgeführt werden, der eine Komponente der betroffenen IT-Ressource dazu bringt, Funktionen oder Dienste derart auszuführen, dass die Sicherheit beeinträchtigt wird. Wir sprechen in diesem Fall von einem Missbrauch der IT-Ressource. So kann beispielsweise die vorsätzliche Änderung von Logik, Daten oder Kontrollinformationen dazu führen, dass nicht autorisierte Funktionen oder Dienste ausgeführt werden (Manipulation). Alternativ kann diese Aufgabe in diesem Zusammenhang von bösartiger Logik in Hardware, Firmware oder Software übernommen werden. Schließlich kann ein Angreifer versuchen, die Rechte einer Komponente derart zu erweitern, dass nicht autorisierte Funktionen ausgeführt werden können. Es kommt somit zu einer Verletzung der Rechte einer Komponente.
3.8. Grundsätzliche Bedrohungen 111
Bedrohungen und Schutzziele In Abschnitt 2.1.3 haben wir einige Schutzziele der IT-Sicherheit und deren Teilziele aufgeführt. Wie in Tabelle 3-2 dargestellt, können die Schutzziele den oben aufgeführten Bedrohungen zugeordnet werden.
Tab. 3-2 Gegenüberstellung von Bedrohungen und Schutzzielen
Schutz der Inhalte
Schutz der Umstände
Offenlegung
Vertraulichkeit Verdecktheit
Anonymität Unbeobachtbarkeit
Täuschung
Integrität
Zurechenbarkeit
Unterbrechung
Verfügbarkeit
Erreichbarkeit Rechtsverbindlichkeit
Dabei muss der Schutzgegenstand bei der Betrachtung der Schutzziele ebenfalls berücksichtigt werden [134]. So betreffen beispielsweise einige Schutzziele die Information selbst (z.B. der Inhalt von Nachrichten), während andere eher die Umstände der Kommunikation, wie etwa Identitäten oder Adressen, betreffen. Die unbefugte Offenlegung betrifft die Vertraulichkeitsziele, die Täuschung, die Integritätsziele und die Unterbrechung die Verfügbarkeitsziele. Die widerrechtliche Aneignung, also die vollständige Übernahme einer IT-Ressource, betrifft alle Schutzziele und wird daher nicht gesondert aufgeführt.
112 3 Hacker und Cracker
Computerkriminalität
4
Abb. 4-0 Tabelle 4-0 Im vorangegangenen Kapitel wurden ausgewählte Hacks vorgestellt. In diesem Kapitel wird nun ein kurzer Einblick in die Rechtslage bei Computerdelikten gegeben, um zu zeigen, dass es sich beim Cyberspace nicht um einen rechtsfreien Raum handelt, wie viele fälschlicherweise glauben. Sollte ein Leser dieses Buch missverständlich als eine Ermutigung zum Hacken sehen und nicht wie beabsichtigt als ein Versuch einer Sensibilisierung für die Sicherheitsproblematik, so soll ihm oder ihr zumindest aufgezeigt werden, welche strafrechtlich relevanten Folgen ein widerrechtliches Handeln nach sich ziehen kann und wird. Da sich Rechtslage und -sprechung an die rasante Entwicklung der Informationstechnologie anpassen müssen, unterliegen sie ständigen Veränderungen. Die hier getroffenen Aussagen können daher nicht mehr sein als eine Momentaufnahme zum Zeitpunkt der Erstellung des Manuskripts. In den nächsten Abschnitten wird versucht, den Begriff „Computerkriminalität“ zu definieren. Anhand von verschiedenen Statistiken zu Zwischenfällen, Computerkriminalität, Täterprofilen und Schäden werden die Ausmaße von Computerkriminalität verdeutlicht. Es wird erläutert, welche Deliktformen unterschieden werden und wie die deutsche Rechtsprechung diese ahndet. Es werden die Bestrebungen in Europa und weltweit zur Vereinheitlichung der Gesetzgebung bei Computerkriminalität und zur Sicherung der kritischen Infrastruktur beschrieben.
4.1 Was ist Computerkriminalität? Seit den 70er-Jahren wird in den meisten Industriestaaten versucht, durch neue Gesetze den Herausforderungen der neuen Technologien zu begegnen. Meist wurden mehrere Anpassungen durchlaufen. Doch es war genau diese rasante Entwicklung, die verhindert hat, dass vom Gesetzgeber eine einheitliche Definition für den Begriff „Computerkriminalität“ festgelegt wurde. Darauf hat man bewusst verzichtet, um auch zukünftige Formen dieses Kriminalitätsphänomens unter einer allgemeineren Definition erfassen zu können.
4.1. Was ist Computerkriminalität? 113 M. Schumacher et al., Hacker Contest © Springer-Verlag Berlin Heidelberg 2003
Fasst man die Mehrheit der vertretenen Meinungen zusammen, dann versteht man unter „Computerkriminalität“ im Allgemeinen strafbare Handlungen, bei denen der Computer entweder das Werkzeug oder aber das Tatobjekt ist. Mit diesem Verständnis dieses Begriffs kann zwischen dem Bereich der „Computerkriminalität im engeren Sinne“ und dem Bereich „Computerkriminalität im weiteren Sinne“ differenziert werden [13]. Unter dem Terminus der „Computerkriminalität im engeren Sinne“ werden all jene strafbaren Handlungen aufgeführt, bei denen der Computer die Straftat erst ermöglicht oder maßgeblich beeinflusst hat. Unter dem Terminus der „Computerkriminalität im weiteren Sinne“ werden hingegen alle konventionellen Straftaten subsumiert, bei denen der Computer als Medium zur effizienteren Durchführung genutzt wird. Dies erstreckt sich mittlerweile auf ein erhebliches Spektrum an Kriminalitätsformen: Wirtschaftskriminalität, politischer Extremismus, organisierte Kriminalität sowie Drogenkriminalität. Eine sehr allgemeine und für den Zweck des Strafrechts eigentlich ungeeignete Definition des Begriffs „Computerkriminalität“ stammt aus dem Jahre 1986 von der OECD: „any illegal, unethical, or unauthorized behaviour relating to the automatic processing and the transmission of data“. Eine etwas ausführlichere, wenn auch einseitige Beschreibung des Begriffs „Computerkriminalität“ ist in ’Der Brockhaus multimedial 2001’ zu finden: „Straftaten und andere Delikte, die im Zusammenhang mit Computern begangen werden. Dazu gehören: – Verbreitung verbotener, pornografischer oder jugendgefährdender Inhalte und Medien im Internet, in Mailboxen oder auf CD (Jugendschutz, MultimediaGesetz); – Missbrauch bei Online-Geschäften: Bestellungen auf Kosten anderer, Fälschung oder Benutzung fremder PINs, Kartennummern und Ähnliches bei Online-Banking (Computerbetrug, § 263a StGB); – unbefugtes Ausspähen von Daten, die nicht für jedermann bestimmt sind und die speziell gesichert sind (§ 202a StGB); – rechtswidriges Löschen oder Unbrauchbarmachung von Daten; auch der Versuch ist strafbar (Datenveränderung, § 303a StGB); – Computersabotage: unberechtigtes Eindringen in Computer eines Betriebes, Unternehmens oder einer Behörde, um Daten zu verändern beziehungsweise die Anlage unbrauchbar zu machen oder zu verändern (§ 303b StGB).“ Die beiden ersten Punkte beschreiben die populärsten Formen der Computerkriminalität, die jedoch mit dem Begriff Hacking nichts zu tun haben. Die letzten drei Punkte sind Ausschnitte von relevanten Gesetzestexten.
114 4 Computerkriminalität
4.2 Statistiken Sicherheitsspezialisten werden oft nach Statistiken zu Computerkriminalität befragt. Kunden wollen wissen, welche Risiken sie eingehen, Administratoren wollen wissen, welche Sicherheitsvorkehrungen sie treffen müssen, und Manager wollen wissen, was Sicherheit kostet. Dahinter steckt die Idee, durch Auswertung der Erfahrung anderer, ähnlicher Organisationen auf das eigene Risikoniveau zu schließen und damit die notwendig(st)en Sicherheitsvorkehrungen bei vertretbaren Kosten treffen zu können. Leider ist es nicht möglich, eine (vollständige) Antwort auf diese Fragen zu geben. Im Wesentlichen sind es zwei Gründe, die verhindern, dass eine zuverlässige Statistik der Computerkriminalität erstellt wird: die Aufdeckungsrate und die Art der Berichterstattung. Die Aufdeckungsrate bei Computerkriminalität ist sehr gering bzw. die Dunkelziffer sehr hoch, wie das folgende Beispiel zeigt: Das Department of Defense (DoD) führte zwischen 1994 und 1996 einen Test zu „Intrusion Detection“ durch. Dabei wurden insgesamt ca. 68.000 Systeme attackiert, wobei 2/3 der Versuche erfolgreich waren. Erschreckend daran war, dass nur 4% der erfolgreichen Angriffe von den Systemadministratoren entdeckt wurden. Auch das zweite Problem wurde durch diese Studie deutlich: Von den erfolgreichen und entdeckten Angriffen wurden nur 10% weitergemeldet und nur ein Bruchteil von 1% an die zuständige Organisation in der Art, dass sie in eine Statistik einfließen konnten [64]. Dies bedeutet, dass weniger als 18 der über 45.000 erfolgreichen Attacken in die Statistik einflossen und die Dunkelziffer dieser Studie somit über 99,96% bzw. die Melderate unter 0,04% lag. In der von Karl-Friedrich Fecht, Walter Opfermann und Wolfgang Scheiterle verfassten Studie „Computerspionage – Risiken und Prävention“ wird die Dunkelziffer bei Computerkriminalität auf 85% geschätzt [46]. Nach Schätzungen des FBI liegt die Dunkelziffer zwischen 85% und 93%. Der Hauptgrund für die extrem hohe Dunkelziffer bei Computerkriminalität liegt in der Angst der Firmen vor Image- und Reputationsverlust. Wie diese Zahlen belegen, sollte man daher beim Lesen einer Statistik zum Thema Computerkriminalität vorsichtig sein und diese mit Skepsis behandeln. Trotz dieses Wissens wollen wir nicht darauf verzichten, im Folgenden einige Zahlen aus anerkannten, öffentlichen Statistiken zu präsentieren, damit ein Gefühl dafür entwickelt werden kann, wie und in welchem Umfang die Kriminalität in unseren computerisierten Alltag Einzug gehalten und wie sie sich im Laufe der Zeit entwickelt hat. 4.2.1 Gemeldete Zwischenfälle Das erste CERT (Computer Emergency Response Team oder dt. Computer-NotfallTeam) wurde 1988 als direkte Folge des Auftretens des Internet-Wurms von Morris gegründet. Der Wurm hatte deutlich gemacht, dass eine Expertengruppe für die Be-
4.2. Statistiken 115
ratung bei konkreten Vorfällen und Problemen bei der Rechner- und Netzsicherheit dringend notwendig war. Als deutlich wurde, dass es notwendig war, die Arbeit der einzelnen Gruppen auch international zu koordinieren und zusammenzuführen, um angemessen auf die heutige Bedrohung der Systeme und Netzwerke reagieren zu können, wurde 1990 das „CERT System“ geschaffen, das heute als „Forum of Incident Response and Security Teams“ (FIRST) bekannt ist und weltweit mehr als 40 Mitglieder umfasst: sieben davon in Europa, eines in Australien, die übrigen in den Vereinigten Staaten. In Deutschland wurde erst 1993 das DFN-CERT (Deutsches Forschungsnetz – Computer Emergency Response Team) als Projekt am Fachbereich Informatik der Universität Hamburg ins Leben gerufen. Seit 1999 steht es als DFN-CERT GmbH als Notfall-Team für deutsche Anwender, Administratoren und Manager bereit und dient darüber hinaus internationalen Teams bei Problemen mit deutschen Rechnern als primärer Ansprechpartner. Dabei kooperiert das DFN-CERT eng mit anderen Notfall-Teams, insbesondere im Rahmen des internationalen Forums of Incident Response and Security Teams (FIRST). Ein Sicherheitsvorfall aus Sicht des DFN-CERTs ist ein „Ereignis, das Missbrauch von Rechnern, Netzwerken, angebotenen Diensten oder Informationen, Verlust der Vertraulichkeit von Informationen, Veränderungen an Informationen oder Systemen sowie einen Verlust der Verfügbarkeit eines Rechners oder Netzwerkes in Folge eines Angriffs zur Folge hat. Auch der Verdacht eines solchen Ereignisses bleibt bis zu dessen Entkräftung ein Sicherheitsvorfall“ [78]. Die dem CERT jährlich gemeldeten Rechner- und Netzattacken stiegen seit dem Gründungsjahr mit gerade acht Vorfällen auf 21756 Vorfälle im Jahr 2000. Wie Abb. 4-1 zeigt, stieg die Anzahl der gemeldeten Vorfälle rapide an.
22000 20000 18000 16000 14000 12000 10000 8000 6000 4000 2000 0
88 89
90 91
92
93 94
95 96
97 98
gemeldete Zwischenfälle
Abb. 4-1 CERT/CC: gemeldete Vorfälle
116 4 Computerkriminalität
99
00
4.2.2 Computerkriminalität in der PKS Jährlich wird in Deutschland die Polizeiliche Kriminalstatistik (PKS) vom Bundeskriminalamt (BKA) veröffentlicht [13]. Die PKS erfasst ausschließlich aufgedeckte, gemeldete und endbearbeitete Straftaten. Es handelt sich somit um verlässliche Zahlen und nicht um eine Umfrage. Da es sich bei der PKS um eine Ausgangsstatistik handelt, werden Fälle erst nach Abschluss der polizeilichen Ermittlungen bei der Abgabe des Verfahrens an die Staatsanwaltschaft statistisch erfasst. Durch teilweise sehr lange – oft mehrjährige – Bearbeitungszeiten und die mitunter beträchtlichen Zeitabstände zwischen der Tatbegehung und deren Aufdeckung spiegelt die PKS daher nur bedingt die Kriminalitätslage im Jahr der Erfassung wider. Die PKS macht Angaben über die Art und Zahl der erfassten Straftaten, den Tatort und die Tatzeit, die Opfer und die Schäden, das Aufklärungsergebnis sowie das Alter, das Geschlecht, die Nationalität und andere Merkmale der Tatverdächtigen. Um einen Eindruck zu vermitteln, wie die Entwicklung der Computerkriminalität verlief und wie sich die Täterprofile über die Zeit entwickelten, wurden die PKSDaten seit 1987 bis einschließlich 2000 ausgewertet. Die Zahlen von 1987 bis einschließlich 1990 erfassen ausschließlich die alten Bundesländer. Ab 1991 wurden die neuen Länder einbezogen, doch sind aufgrund von Anlaufschwierigkeiten die Zahlen von 1991 und 1992 für die neuen Länder zu gering ausgefallen. In der PKS werden unter dem Begriff „Computerkriminalität“ folgende acht Delikte subsumiert: – Betrug mittels rechtswidrig erlangter Karten für Geldausgabe- bzw. Kassenautomaten – Computerbetrug – § 26a StGB – – Betrug mit Zugangsberechtigungen zu Kommunikationsdiensten – Fälschung beweiserheblicher Daten, Täuschung im Rechtsverkehr bei Datenverarbeitung – § 269, 270 StGB – – Datenveränderung, Computersabotage – §§ 303a, 303b StGB – – Ausspähen von Daten – Software-Piraterie (private Anwendungen) – Software-Piraterie in Form gewerbsmäßigen Handelns Nicht erfasst werden in der PKS Delikte der Computerkriminalität wie Betrügereien oder Verbreitung rechtswidrigen Inhalts, wie beispielsweise Pornografie im World Wide Web. Die erfassten und endbearbeiteten Fälle von Computerkriminalität in Deutschland sind von 1987 bis 2000 von 3.067 auf 56.684 angestiegen (siehe Abbildung 4-2). Das entspricht einer Steigerung von insgesamt knapp 1850%. Die Aufklärungsrate schwankte dabei zwischen 41,2% und 48,9% und blieb somit im Wesentlichen über die Jahre gleich (siehe Abbildung 4-3).
4.2. Statistiken 117
. Computerkriminalität
60000 55000 50000 45000 40000 35000 30000 25000 20000 15000 10000 5000
0
25% 17% -1,5% 22%
erfaßte Fälle
15% 33%
Steigerungsrate zum Vorjahr
9% 87
88
51%
23% 42% 58% 50% 0% 89
90
91
92
93
aufgeklärte Fälle 94
95 96
97
98
99
00
Abb. 4-2 Fälle von Computerkriminalität
p
gq
50% 48% 46% 44% 42% 40% 38% 36%
87
88
89
90
91
92
93
94
95 96
97
98
99
00
Abb. 4-3 Aufklärungsquote Computerkriminalität
Den weitaus größten Anteil an den in der PKS erfassten Fällen der Computerkriminalität haben der „Betrug mit rechtswidrig erlangten Karten“ und der „Computerbetrug“ (Abbildung 4-5). Der „Betrug mit rechtswidrig erlangten Karten“ hat mit einer Steigerungsrate von knapp 5040% von 1987 auf das Jahr 2000 auch den größten Anteil am Gesamtanstieg der Computerkriminalität (Abbildung 4-4). Entgegen vielen Schlagzeilen ist also (noch) nicht der Hacker, sondern der Betrüger das Hauptproblem.
118 4 Computerkriminalität
1,7% 0,9% 0,5% 2,4% 0,9% 3,9% 11,6%
78,1% Softwarepiraterie in Form gewerbsmäßigen Handelns. Softwarepiraterie (private Anwendungen) Ausspähen von Daten Datenveränderung, Computersabotage Fälschung beweiserheblicher Daten, Täuschung im Rechtsverkehr bei Datenverarbeitung Betrug mit Zugangsberechtigungen zu Kommunikationsdiensten Computerbetrug (§ 263a StGB) Betrug mittels rechtwidrig erlangter Karten für Geldausgabebzw. Kassenautomaten
Abb. 4-4 Übersicht Computerkriminalität
50000 40000 30000 20000 10000 0 87
88
89
90
91
92
93
94
95 96
97
98
99
00
Betrug mittels rechtswidrig erlangter Karten für Geldausgabe- bzw. Kassenautomaten Computerbetrug (§ 263a StGB)
Abb. 4-5 Karten und Computerbetrug
4.2. Statistiken 119
Betrachtet man die Fallzahlen der Computerkriminalität ohne Kartenbetrug und Software-Piraterie, so ergibt sich ein etwas anderes Bild (Abbildung 4-6). Der Anstieg von 3067 Fällen im Jahre 1987 auf 10.117 Fälle im Jahre 2000 entspricht dann „nur“ einer Steigerung von knapp 330%. 60000 50000 40000 30000 20000 10000 0 87
88
89
90 91
92
93
94
95 96
CK ohne Kartenmissbrauch und Software-Piraterie
97
98
99
00
CK gesamt
Abb. 4-6 Einfluss Kartenbetrug und Software-Piraterie
2400 2200 2000 1800 1600 1400 1200 1000 800 600 400 200 0
87
88
89
90
91
92
93
94
95 96
97
98
99
00
Betrug mit Zugangsberechtigungen zu Kommunikationsdiensten Fälschung beweiserheblicher Daten, Täuschung im Rechtsverkehr bei Datenverarbeitung Datenveränderung, Computersabotage Ausspähen von Daten Software-Piraterie (private Anwendungen) Software-Piraterie in Form gewerbsmäßigen Handelns
Abb. 4-7 Weitere Deliktformen
120 4 Computerkriminalität
Hohe Anstiegsraten verzeichnen die private und gewerbsmäßige Software-Piraterie, die in der PKS seit 1991 bzw. 1994 erfasst werden. Detailliertere Zahlen für Software-Piraterie liegen von der Business Software Alliance (BSA) vor (siehe hierzu Abschnitt 4.2.4). 4.2.3 Täterprofile Die ständig steigende Verbreitung des Internets führte dazu, dass immer mehr Firmen und Organisation am World Wide Web angeschlossen sind. Auch Klein- und Mittelständische Firmen können es sich heute nicht mehr leisten, nicht online zu sein. Der Anschluss an das WWW bringt aber nicht nur Vorteile. Wurden vor wenigen Jahren die Angriffe hauptsächlich von Studenten oder häufig noch jugendlichen Hackern, die oftmals aus Neugier in fremde Systeme eindrangen, sowie dem Innentäter durchgeführt, steigt der Anteil von professionellen Datendieben, die beispielsweise für Industriespionage von der Konkurrenz bezahlt werden. Um in geeigneter Form auf eine Attacke reagieren, aber auch um geeignete Maßnahmen treffen zu können, wäre es oftmals hilfreich, ja sogar notwendig, seinen aktuellen bzw. potenziellen Angreifer zu kennen oder zumindest „kategorisieren“ zu können. Leider gibt es auch dazu sehr wenig gesichertes Material. 4.2.3.1 Tätergruppen Die möglichen Angreifer lassen sich im Wesentlichen in folgende Personengruppen einteilen: – Firmenangehörige/Insider – Personen aus dem Universitäts- und Schulumfeld, Wannabees, Script-Kiddies – Personen aus dem Konkurrenz-/Wettbewerbsumfeld – Hacker aus der Computer-Untergrundszene, Hacker, Gurus – Industriespione/Professionelle Hacker – Fremde Regierungen, Geheimdienste Die Gruppen können unterschieden werden in ihrem Know-how, der kriminellen Energie und den zur Verfügung stehenden finanziellen und personellen Mitteln.
4.2. Statistiken 121
Kriminelle Energie
hoch qualifizierte Angriffe
Innentäter Firmenangehörige
Industriespione Geheimdienst Organisierte Kriminalität Cracker
Script-Kiddies Studenten/Schüler
Computer-Untergrund Hacker Gurus
einfache Angriffe
qualifizierte Angriffe
Know-how Abb. 4-8 Tätergruppen
Script-Kiddies verfügen über geringes Wissen und bedienen sich allgemeinem, öffentlich zugänglichen Wissen und Mitteln. Es ist auch meist diese Gruppe, deren kriminelles Vorgehen entdeckt und bekannt wird. Es handelt sich um einfache Angriffe mit geringen finanziellen und personellen Ressourcen. Ähnliches gilt für den klassischen Innentäter. Im Gegensatz zu Script-Kiddies, Studenten und Schülern ist jedoch bei diesem im Allgemeinen die kriminelle Energie hoch. Bei qualifizierten Angriffen wird Spezialwissen eingesetzt. Es kommen allgemein zugängliche Hilfsmittel zum Einsatz, und die finanziellen sowie personellen Ressourcen sind hoch. Stehen sehr hohe finanzielle und personelle Mittel zur Verfügung, werden Spezialkenntnisse und -hilfsmittel eingesetzt, die der Allgemeinheit nicht zur Verfügung stehen, so wird von einem hochqualifizierten Angriff gesprochen. Bei diesen Angreifern ist das kriminelle Potenzial in der Regel sehr hoch. Zu dieser Gruppe zählen das organisierte Verbrechen, die Geheimdienste und zum Teil die Wirtschaftsspione. Die Wahrscheinlichkeit, dass diese Angreifer entdeckt werden, ist sehr gering. Für die Spurensuche nach einem Angriff kann es daher sehr nützlich sein, den Typ des Angreifers zu kennen. Innentäter hinterlassen andere Spuren als Angreifer aus dem Internet, da ihnen andere Möglichkeiten zur Verfügung stehen; qualifizierte und hochqualifizierte Angreifer verfügen über das Know-how und die entsprechenden Mittel, ihre Spuren zu verwischen bzw. verschwinden zu lassen. Außentäter sind Personen, die nicht über einen legalen Zugang zum angegriffenen Computersystem verfügen. Diese Täter versuchen über externe Datenleitungen in das System einzudringen. Innentäter sind demgegenüber mit einer teilweisen oder umfassenden Zugriffsberechtigung ausgestattet, die sie bei ihren Angriffen auf das System missbräuchlich nutzen. Da sie etwaige Außensicherungen nicht zu überwin-
122 4 Computerkriminalität
den brauchen, sind sie in einer sehr viel günstigeren Ausgangsposition als der Außentäter. Ein privilegierter Innentäter mit umfassenden Zugangsrechten eines Systemverantwortlichen ist in der Lage, sich nahezu unbegrenzte Informationsmöglichkeiten zu erschließen. Umfragen von Ernst & Young [67] zeigen, dass 82% der Delikte durch eigene Mitarbeiter begangen wurden. Die Hälfte dieser Mitarbeiter hatte eine Betriebszugehörigkeit von mehr als fünf Jahren, ein Viertel sogar mehr als zehn Jahren. Computer Security Institute (CSI)
Prozent
Im jährlich veröffentlichten CSI/FBI Computer Crime and Security Survey [32,33] werden Angreifer in fünf Klassen eingeteilt: fremde Regierungen, fremde Firmen, unabhängige Hacker, US-Firmen und unzufriedene (Ex-)Mitarbeiter. Den Angaben der befragten Firmen zufolge nimmt mit über 80% die Gruppe der unzufriedenen (Ex-)Mitarbeiter an den Tatverdächtigen der Computerkriminalität den größten Anteil ein, Tendenz fallend (siehe Abb. 4-9). Der Anteil der Hacker fremder Regierungen und konkurrierender Firmen ist ebenfalls fallend, der Anteil unabhängiger Hacker steigt dagegen. So erfreulich dies auch klingen mag, sollte man bei Betrachtung der Zahlen jedoch nicht vergessen, dass diese Zahlen durch Befragungen ermittelt wurden. Es ist davon auszugehen, dass eine Firma lieber zugibt, dass sie von „normalen“ Hackern attackiert wurde als von Konkurrenzfirmen. Ein weiterer Punkt ist die Aufdeckungs- und Aufklärungsrate. Script-Kidies, die zur Klasse der unabhängigen Hacker zählen, sind um einiges leichter zu entdecken als professionelle Wirtschaftsspione. 100 90 80 70 60 50 40 30 20 10 0
Fremde Regierungen Fremde Firmen Unabhängige Hacker US-Firmen Unzufriedene (EX-)Mitarbeiter
1997
1998
1999
2000
Abb. 4-9 CSI/FBI-Klassifikation der Angreifer
4.2. Statistiken 123
PricewaterhouseCoopers / Informationweek
Prozent
Die Unternehmensberatung PricewaterhouseCoopers führte Anfang 2000 in Zusammenarbeit mit den Redaktionen der InformationWeek in den USA, Deutschland, Großbritannien, Frankreich, Südafrika und Asien eine Studie zum Thema Informationssicherheit durch. Es beteiligten sich 4952 IT-Manager und Sicherheitsbeauftragte in mehr als 50 Ländern. Dieser Studie zufolge stellt der ehemalige Mitarbeiter eine geringe Gefahr dar (siehe Abb. 4-10). Auch der eigene Mitarbeiter – ob autorisiert oder nicht – wird vergleichsweise selten verdächtigt. Am meisten fürchten die Verantwortlichen die Gefahr von außen durch Hacker. Diese werden nach Viren und Trojaner als zweitgrößte Gefahr für das Firmennetz angesehen.
45 40 35 30 25 20 15 10 5 0 Hacker
unbekannt autorisierte nicht ehemalige Mitarbeiter autorisierte Mitarbeiter Mitarbeiter weltweit
Deutschland
Abb. 4-10 PricewaterhouseCoopers-Klassifikation der Angreifer
4.2.3.2 Alters- und Geschlechterstruktur Die PKS erlaubt die Erstellung eines sehr groben Täterbildes, denn auch hier ist die hohe Dunkelziffer bzw. die sehr geringe Aufklärungsquote zu berücksichtigen. In diese Statistik können nur ermittelte Täter einfließen, und je professioneller diese sind, desto seltener werden sie gefasst und damit erfasst. Interessant sind jedoch die Tendenzen. Wird in den Medien immer das Bild des jugendlichen, oft minderjährigen Hackers verbreitet, so zeigt die PKS ein anderes Bild (siehe Abb. 4-11, Abb. 4-12). Waren in den Jahren 1987 bis 1994 die Täter der Altersstufe 21 bis 25 dominierend, so stellt seit 1994 die Täterklasse der zwischen 30- bis 40-Jährigen den Hauptanteil. Ebenfalls stark rückläufig sind die Zahlen für Täter im Alter von 25 bis 30 Jahren. Geht man davon aus, dass die ehemals 21- bis 30-Jährigen älter werden und nun zur nächsten Altersstufe dazuzählen, könnte man daraus einfach schließen: „Einmal Hacker, immer Hacker.“
124 4 Computerkriminalität
. 30% 25% 20% 15% 10% 5% 0%
87
88
89
90
91
92
93
94
95 96
97
98
unter 14 Jahren
14 bis 18
18 bis 21
21 bis 25
25 bis 30
30 bis 40
40 bis 50
über 50
99
00
99
00
Abb. 4-11 Relative Altersstruktur der Täter
3000 2500 2000 1500 1000 500 0
87
88
89
90
91
92
93
94
95 96
97
98
unter 14 Jahren
14 bis 18
18 bis 21
21 bis 25
25 bis 30
30 bis 40
40 bis 50
über 50
Abb. 4-12 Absolute Altersstruktur der Täter
Untersucht man die Geschlechterstruktur (Abb. 4-13) der Täter im Bereich Computerkriminalität, so lässt sich eine weitere interessante Tendenz feststellen. Wie allgemein angenommen, handelt es sich bei den Tätern der Computerkriminalität meis-
4.2. Statistiken 125
tens um Männer. Der Anteil der Frauen lag im Jahre 1987 „nur“ bei 16%, im Jahre 1999 jedoch schon bei 23%, für das Jahr 2000 konnte eine leicht rückläufige Tendenz auf 22% festgestellt werden. Extremer ist der Anstieg des Frauenanteils bei den ausländischen Tatverdächtigen: von 4% im Jahre 1987 auf 18% im Jahr 2000 (Abb. 4-14). Wobei der Anteil der ausländischen Tatverdächtigen in diesen Jahren zwischen 14% und 28% lag, mit steigender Tendenz. Wenn auch langsam, so ist doch ein stetiger Anstieg des Frauenanteils in dieser Männerdomäne festzustellen. 90% 80%
85%
84% 81%
82%
80% 77% 79% 78%
77% 78%
70% 60% 50% 40% 30%
20% 16%19%
15%
23% 22%
20% 23% 21% 22%
18%
10% 0%
87
88
89
90
91
92
93
weiblich
94
95 96
97
98
99
00
98
99
00
männlich
Abb. 4-13 Geschlechterstruktur der Täter
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
87
88
89
90
weiblich, dt
91
92
männlich, dt
93
94
95 96
weiblich, ausl.
97
männlich, ausl.
Abb. 4-14 Geschlechterstruktur: deutsche und ausländische Täter
126 4 Computerkriminalität
4.2.4 Schadensbilanz Statistiken können keine gesicherten Daten über den durch Computerkriminalität verursachten Schaden geben, da die Dunkelziffer der Delikte zu hoch ist und der tatsächliche Schaden nur über Schätzungen erfasst werden kann. Die Schätzung des direkt entstandenen Sachschadens ist relativ einfach. Anders sieht es jedoch bei den angefallenen indirekten Kosten, beispielsweise Personal- oder Folgekosten, aus. Noch schwieriger werden die Abschätzungen, wenn ideelle Werte wie Rufschädigung erfasst werden sollen. Da die veröffentlichten Statistiken selten detaillierte Informationen über die unter dem Begriff „Computerkriminalität“ subsumierten Delikte geben oder über die Art der erfassten Kosten, sind Vergleiche nicht möglich. Daher werden im Folgenden verschiedene öffentlich zugängliche Statistiken einfach nur wiedergegeben. PKS In der Polizeilichen Kriminalstatistik (PKS) wird Schaden nur bei bestimmten Deliktgruppen wie beispielsweise Diebstahl und Vermögensdelikten erfasst. Als Schaden gilt dabei der Verkehrswert des rechtswidrig erlangten Gutes. Die PKS erfasst im Bereich Computerkriminalität nur den Schaden der endermittelten Fälle der Delikte „Betrug mittels rechtswidrig erlangter Karten für Geldausgabe- bzw. Kassenautomaten“, „Computerbetrug – § 26a StGB – “, „Betrug mit Zugangsberechtigungen zu Kommunikationsdiensten“, „Software-Piraterie (private Anwendungen)“ und „Softwarepiraterie in Form gewerbsmäßigen Handelns“. Die übrigen Delikte der Computerkriminalität treten in der Schadensbilanz nicht auf.
4.2. Statistiken 127
Millionen
50 45 40 35 30 25 20 15 10 5 0
97
98
99
00
Betrug mittels rechtswidrig erlangter Karten für Geldausgabebzw. Kassenautomaten Computerbetrug (§ 263a StGB) Betrug mit Zugangsberechtigungen zu Kommunikationsdiensten Software-Piraterie (private Anwendungen)
Abb. 4-15 Bezifferte Schäden nach der PKS
Wie Abb. 4-15 zeigt, blieb der Schaden, der durch Betrug mit rechtswidrig erlangten Karten verursacht wurde, zwischen 1997 und 1999 in etwa konstant. Während der Schaden durch Computerbetrug und private Software-Piraterie sank, wuchs der Schaden durch unberechtigten Zugang zu Kommunikationsdiensten sehr stark an. Einen enormen Zuwachs erfuhr der Schaden durch gewerblich betriebene SoftwarePiraterie (Abb. 4-16). Dieser stieg von 70,6 Mio. DM im Jahre 1997 auf 2,48 Mrd. DM im Jahr 1999, sank jedoch im darauf folgenden Jahr wieder auf knapp 32 Mio. DM. Das entspricht einer Steigerung von ca. 3413% innerhalb von zwei Jahren. Der Gesamtschaden der in der Schadensbilanz erfassten Fälle von Computerkriminalität belief sich für das Jahr 1999 somit auf ca. 2,5 Mrd. DM, im Jahre 2000 jedoch „nur“ knapp 132 Mio. DM. Wie diese große Abweichung für das Jahr 1999 zustande kommt, ist aus der Statistik nicht ersichtlich.
128 4 Computerkriminalität
Millionen
3000 2481
2500 2000 1500 1000 500
71
0 97
32
7 98
99
00
Abb. 4-16 Schäden durch Software-Piraterie
TÜV Rheinland/Berlin-Brandenburg Schätzungen des TÜVs Rheinland/Berlin-Brandenburg besagen, dass sich der Schaden allein in Deutschland pro Jahr auf rund 20 Milliarden Mark beläuft. Detlef Henze, Geschäftsführer der TÜV-Tochter Security Informationstechnologie, präsentierte die Zahlen auf einem Kongress in Köln und wies außerdem darauf hin, dass laut Umfrage unter IT-Unternehmen die Computerkriminalität noch zunehmen wird [131]. Die Schätzung des Schadens erfolgte durch einen unabhängigen Sicherheitsexperten auf Basis von angezeigten wie auch nicht angezeigten und damit auch nicht öffentlich gewordenen Vorfällen. Computer Security Institute/FBI Das Computer Security Institute (CSI) und das San Francisco Federal Bureau of Investigation's (FBI) Computer Intrusion Squad geben jährlich den „Computer Crime and Security Survey“ heraus [32,33]. Der Bericht enthält Angaben über den Schaden, der in den USA durch Computerkriminalität entstanden ist. Dieser Bericht lässt sich sehr schwer bzw. nicht mit der PKS vergleichen, da darin die Computerkriminalität in folgende Deliktformen aufgespalten wird: – IP-Spoofing über das Internet – Aktives Kabel-Sniffing (extern) – Sabotage (WAN) – Systemeinbrüche durch Externe über das Internet – Denial of Service über das Internet
4.2. Statistiken 129
– – – – – – – –
Unautorisierte Serverzugriffe durch Interne Sabotage (Computer und Netzwerk; LAN) Viren Netzstörung durch Interne Gezielter Laptop-Diebstahl Ausnutzung firmeninterner Informationen Telekommunikationsbetrug Kreditkartenbetrug
Das CSI befragte Anfang 2000 insgesamt 643 Unternehmen, Behörden, Finanzinstitutionen oder Universitäten, von denen 70 Prozent über das Auftreten von Computerviren, Diebstahl von Laptops oder Missbrauch der Internet-Nutzung hinaus von verschiedenen schweren Vorfällen berichteten. Bei einem Viertel sei von außen in die Computersysteme eingedrungen worden, bei einem weiteren Viertel seien DoSAngriffe registriert worden. Fast 80 Prozent berichteten vom Missbrauch des Internet-Zugangs durch Angestellte (Herunterladen von Pornografie oder illegaler Software), 70 Prozent von einem nicht autorisierten Zugang von Angehörigen der Organisation und 60 Prozent, dass ihre Computersysteme des Öfteren Ziele von Angriffen gewesen seien. Ein Drittel meinte, sie wüssten nicht, ob ein unautorisierter Zugriff oder Missbrauch stattgefunden habe. Bei den Angaben über finanzielle Verluste muss man wohl besonders vorsichtig sein. 74 Prozent der Befragten räumten finanzielle Verluste ein, 42 Prozent konnten oder wollten die Höhe der Verluste auch beziffern. Demnach hätten diese 273 Organisationen allein durch Computerkriminalität Verluste von insgesamt über 260 Millionen Dollar erlitten. In allen Kategorien vom Diebstahl von Informationen über Betrug bis hin zu Angriffen und Sabotage haben die Vorfälle gegenüber den letzten Jahren zugenommen. Die Entwicklung seit 1997 zeigen Abbildung 4-17 und 4-18. Die Ausnutzung firmeninterner Informationen, die Netzstörung durch Interne oder auch der Diebstahl von Laptops stiegen stetig an. Der Schaden durch Viren ist erfreulicherweise stark rückläufig. Insgesamt wuchs der geschätzte Gesamtschaden in den USA in den Jahren 1997 bis 1999 von 100 Mio. auf 123 Mio. US-Dollar an.
130 4 Computerkriminalität
IP
-S p
oo
fin
üb
if f
er ...
l-S n
..
..
in g
rc h.
rv ic e.
du
)
1998
g
he
(W AN
be
Se
Ka
of
g
ge
rü c
Mio. US-Dollar
1997
Ak tiv es
ia l
ta
ru n
bo
m ei nb
zs tö
D en
N et
Sa
Sy st e
ut
ez
g
ie lte
tz un
rn e
8 7 6 5 4 3 2 1 0
l
..
N )
ah
(L A
st
gr iff .
ge er ve rz u
ta
...
Vi re n
rI
g
ru g
tru
et
sb e
nb
pD ie b bo
to
Sa
ap
rS
rL
te
io n
in
ik at
itk ar te
fir m en
om m un
Kr ed
or is ie rte
G
sn u
U na
Au
Te le k
Mio. US-Dollar 6
5
4
3
2
1
0
1999
Abb. 4-17 Computer Crime and Security Survey – Teil 1
1997
1998
1999
Abb. 4-18 Computer Crime and Security Survey – Teil 2
4.2. Statistiken 131
Business Software Alliance/Software & Information Industry Association Ein anderes Bild zeigt die Schadensbilanz der Business Software Alliance (BSA) und der Software & Information Industry Association (SIIA) [21,22]. Zur Ermittlung der Zahlen in der BSA/SIIA Software-Piraterie-Studie werden zwei Datenbestände verglichen: der Softwarebedarf und die tatsächlichen Softwarelizenzierungen. Um die Software-Piraterie länderweise bewerten zu können, entwickelte das Consulting-Unternehmen International Planning and Research (IPR) Corporation eine komplexe Rechenmethode zur Abschätzung des Softwarebedarfs, die unter [23] nachzulesen ist. Die Differenz zwischen der angeblich installierten Software und den tatsächlichen Verkaufszahlen ergibt den geschätzten Anteil der Raubkopien.
Piraterie-Rate in %
100 90 80 70 60 50 40 30
W
el
tw
0
ei t W US es A te ur D eu op a ts ch la Sc nd hw ei O z st eu ro p Ja a pa n As Ch ie i n/ na N Paz or da ifik M La m e itt t l e ein r i k a re a r O me s t rik en a /A fri ka
20 10
1994
1995
1996
1997
1998
1999
2000
Abb. 4-19 Prozentuale Software- und Produktpiraterie-Rate
Dass eine Schätzung des Softwarebedarfs anhand einer Schätzung der PC-Verkäufe in einem Land nur sehr schwer ist, wenn nicht gar unmöglich (Wie kann abgeschätzt werden, welche PCs Neu- und welche Ersatzanschaffungen sind? Ob der PC für den Privat- oder Geschäftsgebrauch vorgesehen ist? Welches Betriebssystem auf dem PC installiert wird?), zeigt, dass die Zahlen der BSA kritisch betrachtet werden müssen, insbesondere da es sich um eine Allianz der größten Software-Unternehmen handelt, die verständlicherweise ihre Interessen wahren wollen und müssen. Durch die BSA und der SIIA wird jährlich der „Global Software Piracy Report“ herausgegeben. Daraus geht hervor, dass seit 1994 die Software- und Produkt-
132 4 Computerkriminalität
piraterie weltweit zwar von 49% auf 37% im Jahre 2000 (Abb. 4-19) gesunken ist, doch der Schaden (Abb. 4-20) in etwa konstant geblieben ist. Der für das Jahr 1994 ermittelte Schaden belief sich auf 12,3 Mrd. US-Dollar; der Schaden für das Jahr 2000 wurde auf 11,8 Mrd. US-Dollar beziffert. Die annähernd gleich bleibenden Schadenssummen trotz drastisch sinkender Prozentzahlen erklären sich aus dem steigenden Marktvolumen im Bereich Software. In Deutschland sank die Raubkopie-Rate im Jahre 2000 auf 28% und lag damit deutlich unter dem Durchschnitt Westeuropas von 34%. Der Schaden wurde 2000 für Deutschland auf 635,3 Mio. US-Dollar; für Westeuropa auf 3,08 Mrd. US-Dollar beziffert. Während für Europa – einschließlich Osteuropa – , Nordamerika, Lateinamerika, Mittlerer Osten und Afrika sinkende Piraterie-Raten zu verzeichnen sind, steigen die Zahlen für Asien und Pazifik überraschenderweise wieder an. Die Hightech-Nation Japan verzeichnet einen Anstieg von 6% seit dem letzten Jahr auf nun 37% für das Jahr 2000 mit einem bezifferten Schaden von 1666,3 Mio. US-Dollar; China immerhin von 3% auf erschreckende 94%.
14000
10000 8000 6000 4000 2000
el tw ei t W US es A t D eur eu op ts ch a la Sc nd hw O st eiz eu ro pa Ja pa n C As ie hin n a N /Pa or zi fi d M La a m k itt e le tein rik re a r O am st erik en a /A fri ka
0
W
Schaden in $ Mio.
12000
1994
1995
1996
1997
1998
1999
2000
Abb. 4-20 Schäden durch Software- und Produktpiraterie
4.2. Statistiken 133
4.3 Deliktformen Der potenzielle Missbrauch von internationalen Computernetzen kann grob in drei Bereiche eingeteilt werden: Datenschutzdelikte, Wirtschaftskriminalität (Missbrauch durch Handlungen) und Datenweitergabedelikte (Missbrauch durch Inhalte) [113]. Datenschutzdelikte liegen immer dann vor, wenn personenbezogene Daten unrechtmäßig weitergegeben werden. Als Beispiele dafür sind der Missbrauch von „Stasi-Akten“ oder die Weitergabe von widerrechtlich erlangten medizinischen Daten zu nennen. Unter Datenweitergabedelikten, bei denen das Internet für die Übertragung schädigender oder rechtswidriger Informationen benutzt wird, fällt beispielsweise die Verbreitung von Kinderpornografie, Volksverhetzung oder Verleumdung. Datenschutzdelikte sowie Datenweitergabedelikte werden hier nicht weiter betrachtet, da sie nur am Rande eine Rolle für das klassische Hacking spielen. Unter den Begriff „Missbrauch durch Handlungen“ werden schädigende und rechtswidrige Aktivitäten subsumiert, bei denen das Internet benutzt wird. Darunter fallen beispielsweise rechtswidriges Eindringen in Informationssysteme, Manipulation und Sabotage von Computern und Netzen, Spionage und Weitergabe bzw. Veröffentlichung von Geheimnissen, rechtswidrige Erfassung, Nutzung und Weitergabe von personenbezogenen Daten und Verstöße gegen das Urheberrecht sowie Rechte zum Schutz geistigen Eigentums. In der deutschen Rechtsprechung werden folgende Deliktformen der Computerkriminalität unterschieden: Computermanipulation, Computersabotage, Computererpressung, Computerhacking, Computerspionage, Computerbetrug, Softwarediebstahl und andere Formen der Produktpiraterie [60,62]. Computermanipulation Unter dem Begriff „Computermanipulation“ subsumiert man ein weites Spektrum von unterschiedlichen Fällen. Durch die Zunahme der elektronischen Speicherung von Daten nehmen auch die Angriffsziele zu. Klassische Computermanipulationen sind Abrechnungsmanipulationen im Bereich der Gehalts- und Rechnungszahlung, Bilanz- und Kontomanipulationen, die oftmals von unzufriedenen oder entlassenen Angestellten durchgeführt werden. Historisches Beispiel dafür ist der Herstatt-Fall (siehe Kapitel 3.4). Zu einem Massendelikt hat sich auch der Missbrauch des Telefonnetzes entwickelt. In den 60er-Jahren ging es meist darum, billig Telefongespräche auf Kosten der Telefongesellschaften zu führen (siehe „Blue Boxing“ Kapitel 3.4). Da die damals angewandten Techniken mittlerweile kaum mehr zum Erfolg führen, wird heute meist auf Rechnung anderer Teilnehmer telefoniert: durch Einbruch in schlecht geschützten Voice-Mail-Systeme, die Verwendung fremder „calling card“-Nummern oder gefälschter Telefonkarten sowie im Funktelefonnetz die Verwendung modifizierter Sprechfunkgeräte oder selbst konstruierter Geräte.
134 4 Computerkriminalität
Computersabotage Unter Computersabotage wird das vorsätzliche Beschädigen oder Vernichten von Daten oder Hardware verstanden. Da für die physikalische Beschädigung von Hardware, seien es Rechner, Datenträger oder Netzverbindungen, eine persönliche Anwesenheit erforderlich ist, überwiegt die Sabotage von Daten. Für die Computersabotage gibt es unzählige Fälle: Firmenangestellte, die nach einer Kündigung aus Rache Daten manipulierten, löschten oder verschwinden ließen, um für die Wiederbeschaffung Geld von der Firma zu erpressen, oder zerstörerische Trojaner, Viren- und Wurmprogramme; Konkurrenzunternehmen, die versuchen, ihren Mitbewerber auszuschalten oder zumindest für eine begrenzte Zeit lahm zu legen. Zu den bekannteren Fällen aus der Vergangenheit zählen der Internet- und der AIDS-Wurm. Computer-Hacking Unter dem Begriff Computer-Hacking versteht man traditionell das Eindringen in fremde Rechnersysteme. Das Ziel und die Motivation können unterschiedlicher Natur sein. Es reicht von der Freude am Überwinden von Sicherheitsmaßnahmen, über Demonstration des Könnens, Manipulation und Sabotage aus Rache bis hin zu Spionage. Einer der berühmtesten Computer-Hacking-Fälle ist der KGB-Hack (siehe Abschnitt 3.4). Computerspionage Unter Computerspionage wird das Eindringen in fremde Computer verstanden, um sich private, geschäftliche oder militärische Daten wie Computerprogramme, Forschungs- und Rüstungsdaten, Daten des kaufmännischen Rechnungswesens oder Kundenadressen anzueignen [46]. Dies kann sowohl durch das Kopieren der Daten, durch Mitnahme von Datenträgern oder auch durch Auffangen von elektromagnetischer Abstrahlung geschehen. Die so gewonnenen Daten werden in der Regel kommerziell genutzt, sei es durch Erpressung des Eigentümers, Nutzung des erlangten Wissens oder durch Weiterverkauf an interessierte Dritte wie beispielsweise beim KGB-Hack. Computerbetrug Bei Computerbetrug handelt es sich um die Ausnutzung von Rechnern zum Zwecke der Bereicherung. Der Computerbetrug erfasst die Fälle, in denen das Ergebnis eines Datenverarbeitungsprozesses beeinflusst wird, beispielsweise durch Umgestaltung des Programms, Verfälschung der verwendeten Daten oder Einwirkung auf den Ablauf des Programms mit dem Vorsatz des Betrugs. Delikte dieser Art werden statistisch betrachtet meist von Insidern begangen. Für Hacker ist dies meist uninteressant.
4.3. Deliktformen 135
Zeitdiebstahl Dieser Strafbestand kann als überholt angesehen werden. Er stammt aus der Zeit der Großrechner, in der Rechenzeit noch sehr kostbar und die Ressourcen sehr knapp waren. Softwarediebstahl und andere Formen der Produktpiraterie Unter Softwarediebstahl wird das unbefugte Kopieren und Nutzen von fremden Computerprogrammen verstanden. Dieser Strafbestand wird nicht nur durch Kopieren von Datenträgern begangen, sondern auch durch das Eindringen in fremde Rechner sowie dem anschließenden illegalen Kopieren und Weiterverbreiten von Individual- oder Standardsoftware. Dass sich dies sogar existenzbedrohend auswirken kann, zeigte der deutsche „Inkassoprogramm“-Fall: Ein freiberuflicher Programmierer erstellte im Auftrag eines Inkassounternehmens ein Programm einschließlich des Pflichtenheftes sowie der Einweisung der Mitarbeiter. Nachdem der Programmierer das Programm auch an andere Firmen lizenzierte, klagte das Inkassounternehmen und unterlag. Der 1. Senat des BGH entschied am 9.5.1985, dass ein Computerprogramm nur dann urheberrechtsfähig sei, wenn es das Können eines Durchschnittsprogrammierers erheblich übersteige. Diese Entscheidung ist seit dem Inkrafttreten des heutigen Urhebergesetzes 1993 überholt. Dass in manchen Fällen auch der leichtsinnige Umgang mit Sicherheitsmaßnahmen durch Softwarevertreiber eine Rolle spielen kann, zeigte ein Fall im Jahre 1994. Ein Softwarehändler verteilte auf der größten Computermesse in Deutschland (CeBIT) 280.000 Exemplare einer CD-ROM, die Programme im Wert von über 100.000 DM enthielten. Die einzelnen Programme waren durch einen Code geschützt, den ein Kunde nach Abschluss eines Vertrages erhielt. Jugendlichen Hackern gelang es jedoch in kürzester Zeit, den unzureichenden Schutz zu knacken.
4.4 Deutsche Rechtsprechung Als Reaktion auf verschiedene EDV-bezogene Wirtschaftsdelikte wurde in den 80er-Jahren eine Reform des Strafrechts, das für die Verletzung von Gesetzen Sanktionen bestimmt und damit deren Einhaltung erzwingt, ausgelöst. Dies wurde notwendig, da durch die Computerkriminalität nicht mehr traditionelle strafrechtliche Rechtsgüter betroffenen waren, sondern neue, immaterielle Güter. Auch neue Formen der Tatbegehung traten auf, so dass die bestehenden Straftatbestände nicht ohne weiteres anzuwenden waren, denn dem deutschen Strafrecht liegen verschiedene Prinzipien zugrunde, die den Sinn haben, den Bürger vor Willkür zu schützen und das Strafrecht auf die Anwendung bei schwerwiegenden Fällen zu beschränken. Zu den Prinzipien gehören: „keine Strafe ohne Gesetz“, das Analogieverbot und „Geltung des milderen Gesetzes“.
136 4 Computerkriminalität
Durch das Prinzip „keine Strafe ohne Gesetz“ kann ein Täter nur dann angeklagt werden, wenn zum Zeitpunkt der Tathandlung diese Tat mit Strafe belegt war. Es ist also nicht möglich, eine Tat im Nachhinein zu bestrafen, wenn ein entsprechendes Gesetz erst später erlassen wurde. Der Grundsatz des Analogieverbots verhindert, dass bereits bestehende Gesetze analog angewendet werden können. Dadurch soll verhindert werden, dass nicht passende Gesetze passend gemacht werden. Hat sich die Gesetzeslage zwischen dem Zeitpunkt der Tathandlung und der Entscheidung des Strafgerichts geändert, so kommt der Grundsatz des milderen Gesetzes zur Anwendung. 4.4.1 Zweites Gesetz zur Bekämpfung der Wirtschaftskriminalität In Deutschland wurde am 1. August 1986 das 2. Gesetz zur Bekämpfung der Wirtschaftskriminalität (2. WiKG) erlassen, das einen ersten Ansatz darstellte, das strafrechtliche Problem der Computerkriminalität zu erfassen und die oben genannten Deliktbereiche abzudecken. Daher wurde es in der Presse auch oftmals als „AntiHacker-Gesetz“ bezeichnet. Die Sachverständigenkommission zur Bekämpfung der Wirtschaftskriminalität empfahl schon 1976, die durch die damals neuartigen Scheck-, Kreditkarten- und Computermanipulationen vermeintlich entstandenen Strafbarkeitslücken zu schließen. Ein erster Entwurf wurde zwei Jahre später vorgelegt, jedoch erst weitere vier Jahre später am 30.9.1982 wurde das 2. WiKG in den Bundestag eingebracht. Da am darauf folgenden Tag ein konstruktives Misstrauensvotum gegen den damaligen Bundeskanzler Schmidt und daraus resultierend die Auflösung des Deutschen Bundestages folgte, wurde das 2. WiKG erst am 27.2.1986 von der neuen Regierung verabschiedet und trat damit erst 14 Jahre nach Einsetzen der Kommission am 1.8.1986 in Kraft. Die wichtigsten Paragrafen des 2.WiKG, die auch heute noch bei Computerkriminalität in Deutschland Anwendung finden, sind [62,129]: – – – – –
§ 202a StGB Ausspähen von Daten § 263a StGB Computerbetrug § 269 StGB Fälschung beweiserheblicher Daten § 303a StGB Datenveränderung § 303b StGB Computersabotage
§ 202a StGB: Ausspähen von Daten 1. Wer unbefugt Daten, die nicht für ihn bestimmt und gegen unberechtigten Zugang besonders gesichert sind, sich oder einem anderen verschafft, wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft. 2. Daten im Sinne des Absatzes 1 sind nur solche, die elektronisch, magnetisch oder sonst nicht unmittelbar wahrnehmbar gespeichert sind oder übermittelt werden.
4.4. Deutsche Rechtsprechung 137
Ursprünglich sah der Entwurf des 2. WiKG keinen Tatbestand gegen das Ausspähen von Daten vor [103]. Erst in einer Anhörung des Rechtsausschusses des Bundestages forderten der Computerrechtsexperte Prof. Dr. Ulrich Sieber und ein Vertreter der Nixdorf Computer AG, Oertel, das Anzapfen und das Abhören von Datenleitungen und den Zugriff auf fremde Datenbestände strafrechtlich zu verfolgen. Vor Inkrafttreten des 2. WiKG waren Daten nur unzureichend vor Spionage geschützt. So schützt § 43 BDSG nur personenbezogene Daten natürlicher Personen, § 201 StGB verbietet die Aufnahme bzw. das Abhören des nichtöffentlichen gesprochenen Wortes, § 202 Abs. StGB setzt eine Fixierung der menschlichen Gedanken voraus, § 17 UWG bezieht sich ausschließlich auf Betriebs- und Geschäftsgeheimnisse, und für § 15 FAG ist das Betreiben einer Fernsprechanlage Voraussetzung. Mit § 202a StGB sollte eine Parallele zum Briefgeheimnis gezogen werden. Umstritten ist, welches Rechtsgut durch die Norm des § 202a StGB konkret geschützt wird: Nach Meinung von Fritjof Haft, Professor der Rechtswissenschaft in Tübingen, sind ausschließlich Daten mit wirtschaftlichem Wert vor Diebstahl zu schützen. Damit wären beispielsweise persönliche Daten und Mitteilungen nicht geschützt. Die überwiegende Auffassung ist jedoch: Das Rechtsgut von § 202a StGB ist das Verfügungs- bzw. das formelle Geheimhaltungsinteresse des über die Daten Verfügungsberechtigten. Der Verfügungsberechtigte ist in der Regel die speichernde Stelle. Das Geheimhaltungsinteresse muss jedoch durch eine besondere Sicherung dokumentiert sein. Hätte der Verfügungsberechtigte kein Interesse an der Geheimhaltung, würde er die Daten für jedermann frei zugänglich bereitstellen. Die Vorkehrungen müssen einen gewissen Sicherungsgrad aufweisen, d.h. aber auch, dass Zugangssicherungen, die jeder Laie durchbrechen kann, ungenügend sind. Sie müssen aber nicht unüberwindbar sein – sofern dies überhaupt möglich ist. Anerkannte Verfahren sind beispielsweise Passwörter, Magnet- oder Chipkarten, Datenverschlüsselung oder biometrische Verfahren. Einfach zu erratende Passwörter stellen dagegen einen unzureichenden Schutz dar. Gleiches gilt für die ungesicherte Übertragung von Daten von Rechner zu Rechner. Als ausreichende Sicherung bei der Übertragung gilt die Verschlüsselung der Daten. Die kompromittierende Abstrahlung eines Monitors hingegen ist in der Regel nicht gegen unberechtigten Zugriff besonders gesichert und verstößt somit auch nicht gegen § 202a StGB. Ein weiterer umstrittener Punkt bei der Interpretation ist, ob zusätzlich zu den Interessen des Verfügungsberechtigten auch die Interessen des vom Inhalt der Daten Betroffenen mitgeschützt sind. Das wird überwiegend verneint, da personenbezogene Daten bereits durch § 43 BDSG geschützt werden. Der Datenbegriff ist – nach Ansicht der Literatur – als „weiter“ Datenbegriff anzusehen. Daten sind danach alle durch Zeichen oder kontinuierliche Funktionen dargestellten Informationen, die Gegenstand oder Ergebnis eines Verarbeitungsvorganges sind. Durch diese Auffassung des Datenbegriffes ist ebenfalls Software durch § 202a StGB geschützt, da Software als eine Ansammlung von einzelnen Daten anzusehen ist. Der Datenbegriff wird jedoch eingeschränkt durch den Zusatz „elektronisch, magnetisch oder sonst nicht unmittelbar wahrnehmbar gespeichert sind oder übermittelt werden“. Unter „nicht unmittelbar wahrnehmbar“ werden solche Daten
138 4 Computerkriminalität
verstanden, deren Inhalt erst nach einer technischen Umformung (z.B. Darstellung am Bildschirm, Ausgabe am Drucker) für den Menschen wahrnehmbar werden. Unmittelbar wahrnehmbar sind dagegen beispielsweise auf Lochkarten gespeicherte Daten oder manuell erstellte Datenansammlungen; diese sind durch §§ 201 und 202 StGB geschützt. Durch § 202a StGB sind nur solche Daten geschützt, die „gespeichert sind oder übermittelt werden“. Das bedeutet, dass sowohl die Weitergabe von Daten auf Datenträger, Daten, die noch nicht gespeichert sind, also beispielsweise Eingabedaten, oder auch ausgedruckte und damit unmittelbar wahrnehmbare Daten nicht geschützt sind. Dringt ein Hacker im Auftrag des jeweiligen Unternehmens in deren Rechner ein, so greift die Formulierung „nicht für ihn bestimmt“ nicht. Durch den erteilten Auftrag liegt ein tatbestandsausgleichendes Einverständnis vor, und die Tat ist nicht nach § 202a StGB strafbar. §202a StGB bestraft ebenfalls nicht den Datendieb, der ihm überlassene Daten (einschließlich Software) weitergibt. So konnte Markus Hess (KGB-Hack) nicht wegen Ausspähens von Daten angeklagt werden, da er lediglich Programme seiner Firma weitergegeben hatte, auf die er berechtigten Zugriff hatte. Durch den Begriff „verschaffen“ in Abschnitt 1 lässt der Gesetzgeber den Versuch des Ausspähens sowie das bloße Eindringen in ein Computersystem straffrei. Der Täter muss die tatsächliche Verfügungsgewalt über die Daten erhalten. Die Kenntnisnahme wird jedoch nicht vorausgesetzt. Die Problematik dieser Differenzierung zwischen „Eindringen“ und „Abrufen von Daten“ liegt aber darin, dass es technisch nicht möglich ist, eine Unterscheidung zu treffen. Dringt ein Hacker in einen Computer ein, so erhält er automatisch Daten übermittelt, die ihm den Stand seiner Bemühungen mitteilen. Diese Daten nimmt der Täter automatisch wahr. Der Grund für den Gesetzgeber, diese Unterscheidung zu treffen und das bloße Eindringen straffrei zu belassen, ist wohl im BTX-Hack zu sehen. Dieser Hack wurde damals nicht als kriminelle Machenschaft betrachtet, da der CCC „lediglich“ auf die Sicherheitsmängel aufmerksam machen wollte. Die Idee war also, dass diejenigen, die den technischen Fortschritt dadurch fördern, dass sie Probleme der neuen Technik aufzeigen, nicht mit einer Strafe belegt werden sollten. Die Einstellung änderte sich erst mit dem Auftreten der ersten kriminellen Hacks, zu denen der NASAund der KGB-Hack zählen. § 263a StGB: Computerbetrug 1. Wer in der Absicht, sich oder einem Dritten einen rechtswidrigen Vermögensvorteil zu verschaffen, das Vermögen eines anderen dadurch beschädigt, dass er das Ergebnis eines Datenverarbeitungsvorgangs durch unrichtige Gestaltung des Programms, durch Verwendung unrichtiger oder unvollständiger Daten, durch unbefugte Verwendung von Daten oder sonst durch unbefugte Einwirkung auf den Ablauf beeinflusst, wird mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft.
4.4. Deutsche Rechtsprechung 139
2. § 263 Abs. 2 bis 7 gilt entsprechend. Der Computerbetrug ist die computerbezogene Ergänzung zum traditionellen Betrug [8,11,37]. Da der klassische Betrug nach § 263 StGB die Täuschung eines Menschen mit nachteiliger Vermögensverfügung voraussetzt, schied die Anwendung des § 263 StGB für den Fall des Computerbetrugs aus. Bei der Formulierung eines Paragrafen darf die Beschreibung der Tathandlung nicht zu genau sein, da sonst Lücken in diesem Bereich entstehen würden. Eine allgemeine Umschreibung birgt dagegen die Gefahr der uferlosen Ausweitung und damit der Verfassungswidrigkeit. Diese Schwierigkeit wurde in § 263a StGB dadurch umgangen, dass vier Tatbestandsmerkmale bzw. Tatmittel festgelegt wurden: – – – –
unrichtige Gestaltung des Programms Verwendung unrichtiger oder unvollständiger Daten unbefugte Verwendung von Daten das unbefugte Einwirken auf den Ablauf der Datenverarbeitung
Dem Tatbestandsmerkmal der Täuschung in § 269 StGB entspricht somit das Beeinflussen des Ergebnisses eines Datenverarbeitungsvorganges durch eines der vier genannten Tatmittel. Die Absicht bei der Formulierung der ersten beiden Tatbestandsvarianten war die Erfassung von Programm- und die Eingabemanipulation. Die zu dieser Zeit ersten auftretenden Missbrauchsfälle von Geldautomaten und BTX-Systemen beeinflussten die Definition der dritten Tatbestandsvariante der „unbefugten Verwendung von Daten“. Da die Manipulation in diesen Fällen – meist die Verwendung fremder Zugangs- oder Berechtigungsdaten – nicht durch die Verwendung von unrichtigen oder unvollständigen Daten erfolgte, waren diese Fälle nach allgemeiner Auffassung nicht von der zweiten Variante abgedeckt. Mit der Variante „unbefugtes Einwirken auf den Ablauf der Datenverarbeitung“ sollte die Hardwaremanipulation, „neue“ Manipulationstechniken sowie weitere beliebige Beeinflussung des Datenverarbeitungsvorganges ohne die Eingabe von Daten abgedeckt werden. Die Verabschiedung des § 263a StGB in diesem Wortlaut erfolgte trotz vielfacher Bedenken und Kritikpunkte. Daher herrscht in der Literatur auch nahezu Einigkeit darüber, dass die Formulierung missglückt ist. Einigkeit herrscht nur darüber, dass das geschützte Rechtsgut des Computerbetrugs vorrangig das Vermögen ist. Die Frage nach der Verfassungsmäßigkeit des § 263a StGB stellt sich vor allem wegen der Formulierung „das Ergebnis eines Datenverarbeitungsvorgangs [...] beeinflusst“ und der dritten und vierten Tatbestandsvariante, insbesondere wegen des unbestimmten Rechtsbegriffs „unbefugt“. Auch sehen einige Kritiker den Bestimmtheitsgrundsatz und das strafrechtliche Analogieverbot aus Art. 103 Absatz 2 GG verletzt. Der Bestimmtheitsgrundsatz fordert, dass der Gesetzgeber die Voraussetzungen einer Strafbarkeit so konkret festlegt, dass Tragweite und Anwendungsbereich der Strafnorm genau erkennbar sind. Das strafrechtliche Analogieverbot besagt, dass im Wege der Anwendung eines Rechtssatzes auf einen von ihm nicht
140 4 Computerkriminalität
verfassten, aber als rechtsähnlich empfundenen Sachverhalt Tatbestände weder geschaffen noch bestehende ausgeweitet werden dürfen. Die Problematik des § 263a StGB liegt eigentlich darin, dass die Computertechnologie sehr rasch voran schreitet. Der Gesetzgeber konnte die Entwicklung nicht voraussehen und damit die Reichweite der neuen Strafnorm. Die Fälle von Geldautomaten- und BTX-Manipulationen spielten eine weit geringere Rolle in der Computerkriminalität, als bei der Formulierung des Paragrafen angenommen wurde. Der erste Fall, bei dem § 263a StGB angewendet wurde, war die Manipulation von Geldspielautomaten. Durch die Umstellung von mechanischen auf computergesteuerte Automaten wurde es möglich, durch einen mitgeführten Computer den aktuellen Programmzustand des Gerätes abzufragen, mit Kenntnis der enthaltenen Software den weiteren Spielverlauf vorherzusagen und damit zu „manipulieren“. Verschiedene Gerichte kamen zu unterschiedlicher Einschätzung über die Anwendbarkeit der Rechtsnorm. Waren die einen der Auffassung, dass es sich um eine unbefugte Einwirkung auf den Ablauf handelt, waren andere gegenteiliger Auffassung. Der Bundesgerichtshof, an das der Fall durch das Bayrische Oberlandesgericht zwecks einer Divergenzentscheidung verwiesen wurde, schloss sich der „täuschungsähnlichen“ Auslegung des § 263a StGB des Bayrischen Oberlandesgerichts an, wonach der Täter „konkludent über seine Kenntnis vom Stand des Computerprogramms und damit über seine Bereitschaft, die Risikotaste nur in programmgerechter, also auch das Verlustrisiko einschließender Weise betätige“ [10], täusche. Weitere strittige Fälle zur Anwendbarkeit des § 263a StGB liegen im Bereich Codekartenmissbrauch und wurden teilweise ebenfalls erst durch den Bundesgerichtshof endgültig entschieden. Es werden vier Fallgruppen des Codekartenmissbrauchs unterschieden: – – – –
Missbrauch der eigenen Codekarte Missbrauch einer fremden Codekarte Missbrauch einer entwendeten Codekarte Verwendung total gefälschter Codekarten
Die Verwendung total gefälschter und entwendeter Codekarten ist nach § 263a StGB strafbar. Der Missbrauch einer fremden Codekarte durch abredewidriges Abheben und der Missbrauch durch den berechtigten Karteninhaber (Kontoüberziehung) wurden nicht als betrugsspezifisches Unrecht eingestuft und sind somit nicht nach § 263a StGB strafbar. Wie diese kurz geschilderten Fälle zeigen, ist die Anwendung von § 263a StGB schwierig. Die Gerichte behalfen sich bei der Subsumtion der von ihnen zu beurteilenden Sachverhalte unter § 263a StGB häufig mit reinen Strafwürdigkeitserwägungen unter Umgehung der Komplexität dieser Vorschrift. Manche Gerichte lehnen diese Strafnorm als verfassungswidrig ab und lösen die Problematik durch Verwendung anderer Vorschriften.
4.4. Deutsche Rechtsprechung 141
§ 269 StGB: Fälschung beweiserheblicher Daten 1. Wer zur Täuschung im Rechtsverkehr beweiserhebliche Daten so speichert oder verändert, dass bei ihrer Wahrnehmung eine unechte oder verfälschte Urkunde vorliegen würde, oder derart gespeicherte oder veränderte Daten gebraucht, wird mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft. 2. Der Versuch ist strafbar. 3. § 267 Abs. 3 und 4 gilt entsprechend. Der § 269 StGB wurde als digitales Pendant zur Urkundenfälschung (§ 267 ff. StGB) eingeführt. Die Anwendung der traditionellen Paragrafen setzen eine stoffliche, visuelle Erkennbarkeit einer Urkunde mit eindeutigem Aussteller voraus, was für digitale Urkunden nicht zutrifft. Die Probleme des § 269 StGB liegen in der Erkennbarkeit des Ausstellers und in der Konkurrenz zu § 268 StGB sowie zu dem gleichzeitig geschaffenen § 263a StGB. Geschütztes Rechtsgut des § 269 StGB ist die Sicherheit und Zuverlässigkeit des Rechtsverkehrs. Das Tatobjekt sind beweiserhebliche Daten, wobei der Begriff Daten im Sinne des § 202a StGB verwendet wird. Beweiserheblich sind Daten dann, wenn sie urkundsgleiche Beweisfunktion haben und dazu bestimmt sind, bei einer Verarbeitung im Rechtsverkehr als Beweisdaten für rechtlich erhebliche Tatsachen benutzt zu werden. Der Bedeutungsgehalt ergibt sich somit erst durch die Gleichstellung mit der Urkunde, in der rechtserhebliche Informationen, die einer Person oder einem Rechtssubjekt zugeordnet werden, dauerhaft zu Beweiszwecken abgelegt sind und die den jeweiligen Aussteller als Garant des Erklärungsinhalts erkennen lassen. Die Tathandlungen des § 269 StGB sind die Speicherung oder Veränderung dergestalt, dass bei der Wahrnehmung, d.h. bei einer visuellen Darstellung, eine unechte oder verfälschte Urkunde vorliegen würde. Weiter ist der Gebrauch dieser gespeicherten oder verfälschten Daten sowie der Versuch des Gebrauchs strafbar. Voraussetzung der Tathandlung und damit der Anwendbarkeit des § 269 StGB ist jedoch das vorsätzliche Handeln und die Absicht zur Täuschung im Rechtsverkehr. Anwendung findet § 269 StGB beispielsweise bei der Fälschung von Automatenscheckkarten. Das Übertragen von Kontendaten auf eine Scheckkarten-Blankette, welche mithilfe technischer Geräte gesammelt wurden, kommt dem Herstellen einer unechten Urkunde gleich. Durch die Einführung der „digitalen Signatur“ könnte § 269 StGB zukünftig an Bedeutung gewinnen.
142 4 Computerkriminalität
§ 303a StGB: Datenveränderung 1. Wer rechtswidrig Daten (§ 202a Abs. 2) löscht, unterdrückt, unbrauchbar macht oder verändert, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft. 2. Der Versuch ist strafbar. Ähnlich § 202a StGB wurde auch § 303a StGB auf Druck der Öffentlichkeit in das 2. WiKG aufgenommen [103,119]. Begründet wurde dies mit dem hohen wirtschaftlichen Wert von Computern, Software und gespeicherten Daten. Zwar war die Anzahl der Fälle von Datensabotage und -veränderungen noch sehr gering, doch sind schon die ersten Schäden durch Virenprogramme oder Sabotageakte, verursacht durch entlassene oder verärgerte Angestellte, aufgetreten. Die potenzielle Gefahr dieser Vergehen wurde erkannt. Tatobjekt sind Daten im Sinne des § 202a StGB. Das bedeutet auch, dass § 303a StGB nur Datenveränderungen an solchen Daten ahndet, die ausreichend geschützt sind. Sabotage an ungesicherten Daten ist somit nicht abgedeckt. Unter Löschen von Daten wird dabei verstanden, dass die Daten unwiederbringlich verloren sind. Dies gilt nur für physisch gelöschte Daten, logisch gelöschte Daten werden nicht als gelöschte, sondern nur als unterdrückte Daten betrachtet. Unter unterdrückten Daten werden solche verstanden, die in ihrer Integrität unangetastet bleiben, wobei jedoch für den Verfügungsberechtigten der Zugriff auf irgendeine Art entzogen wurde. Dies kann beispielsweise durch Ändern von Zugriffsrechten oder Passwörtern erfolgen, durch Entzug des Datenträgers oder durch MailBomben, die durch Überlastung des Systems verhindern, dass weitere Mails den Empfänger erreichen können. „Unbrauchbar gemacht“ sind Daten dann, wenn sie in ihrer Gebrauchsfähigkeit derart eingeschränkt sind, dass sie nicht mehr ordnungsgemäß verwendet werden können. Dies kann durch Teillöschung, Überschreibung oder auch Hinzufügen von Daten erfolgen. Werden Daten verändert, so wird ihr Informationsgehalt oder Aussagewert geändert. Die Begriffe „löschen“, „unterdrücken“, „unbrauchbar machen“ und „verändern“ sind nicht disjunkt zueinander. Eine gelöschte Datei ist auch verändert, wenn sich dadurch ihr Informationsgehalt verändert hat. Die Datenveränderung nach § 303a StGB, sei es durch Löschung, Unterdrückung, Unbrauchbarmachung oder Veränderung, kann sowohl durch einen Menschen – einem unmittelbaren Täter – erfolgen oder durch ein schädliches Programm wie Virenprogramme oder Trojanische Pferde. Die Installation eines schädigenden Programms, das eine Datenveränderung hervorruft, kann dabei unmittelbar durch den Täter oder durch mittelbare Täterschaft erfolgen. Ein mittelbarer Täter, der trotz Kenntnis der Bedrohung ein infiziertes Programm bereitstellt, muss sich die Handlung des Tatmittlers zurechnen lassen. Die Frage, ob § 303a StGB also auf die Verbreitung von Viren anzuwenden ist, kann nicht allgemein gültig beantwortet werden. Es muss der einzelne Fall betrachtet werden. Handelt es sich um einen überschreibenden Virus, d.h. das Wirtsprogramm wird teilweise überschrieben oder so verändert, dass es seine ursprüngliche
4.4. Deutsche Rechtsprechung 143
Funktion nicht mehr vollständig erfüllen kann, so liegt der Tatbestand des Unbrauchbarmachens und Veränderns vor. Für einen nichtüberschreibenden Virus, der an das Wirtsprogramm nur angehängt wird, ist die bloße Infektion nicht als tatbestandsmäßig i.S.v. § 303a StGB anzusehen. Hier ist die Funktionsweise ausschlaggebend. Handelt es sich um eine Funktion mit positiver Zielrichtung, wie beispielsweise beim Cohen-Virus, so kann kein erheblicher Verletzungserfolg festgestellt werden und auch nur in Ausnahmefällen eine erhebliche Beeinträchtigung. Bei Viren mit Funktionen, die lediglich belästigen, wie beispielsweise der Weihnachtsbaum-Virus1 oder der Marihuana-Virus2, kommt als Tathandlung Unterdrückung in Betracht, da der Benutzer während der Zeit, in der der Virus seine Funktion ausführt, nicht an seine Daten herankommt. Ausschlaggebend ist immer die Erheblichkeit der Verletzungswirkung. Bei Viren, die Daten verändern, löschen oder zerstören, liegt eindeutig ein Tatbestand i.S.v. § 303a StGB vor. Ähnlich zu bewerten sind Würmer, logische Bomben und Trojaner. Da hier keine Infektion vorliegt, wie bei Viren, ist einzig die Funktionsweise ausschlaggebend. Enthält ein Trojanisches Pferd ein Spoofing-Programm zum Ausspähen von Passwörtern, so kommt nicht § 303a StGB zur Anwendung, da keine Datenveränderung vorliegt. Doch kann § 202s StGB greifen, wenn das Programm aktiviert wird. Die bloße Installation ist allerdings nicht strafbar. § 303b StGB: Computersabotage 1. Wer eine Datenverarbeitung, die für einen fremden Betrieb, ein fremdes Unternehmen oder eine Behörde von wesentlicher Bedeutung ist, dadurch stört, dass er 1. eine Tat nach § 303a Abs. 1 begeht oder 2. eine Datenverarbeitungsanlage oder einen Datenträger zerstört, beschädigt, unbrauchbar macht, beseitigt oder verändert, wird mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft. 2. Der Versuch ist strafbar. Das Rechtsgut, das durch § 303b StGB geschützt wird, ist das Interesse von Wirtschaft und Verwaltung am störungsfreien Ablauf einer Datenverarbeitung [55,80,119]. Durch § 303b StGB werden Behörden, Industrieunternehmen und Betriebe privater oder öffentlicher Natur geschützt, nicht aber private Haushalte.
1
Der Weihnachtsbaum-Virus zeichnete auf dem Bildschirm einen Weihnachtsbaum, der verschwand, sobald das Wort „christmas“ eingetippt wurde. 2 Der Marihuana-Virus gab auf dem Bildschirm einen Text aus, der die Legalisierung von Marihuana forderte.
144 4 Computerkriminalität
Für einen Tatbestand i.S.v. § 303b ist von Bedeutung, dass es sich um eine „wesentliche“ Beeinträchtigung der Datenverarbeitungsanlage handelt. Eine erhebliche Störung liegt nur dann vor, wenn diese nicht ohne größeren Kosten- oder Zeitaufwand (z.B. durch Neustart des Computers) behoben werden kann. Die Dauer der Störung ist dabei unerheblich. § 303b StGB ist als Qualifizierung von § 202a zu sehen. Er kommt dann zum Tragen, wenn durch die Datenveränderung i.S.v. § 202a die Datenverarbeitung wesentlich gestört wird. Neben Angriffen auf die Software erfasst § 303b StGB auch Angriffe auf die Hardware der Datenverarbeitungsanlage. Diese können durch spezielle Programme erfolgen oder durch physische Gewalteinwirkung. Nicht abgedeckt werden jedoch Angriffe auf die Hardware von Netzen, soweit sie nicht direkt einer Datenverarbeitungsanlage zugeordnet werden können. 4.4.2 Anwendbarkeit des deutschen Strafrechts Ob das deutsche Strafrecht zur Anwendung kommt, hängt im Wesentlichen von der Art des Delikts ab. Unproblematisch ist es für diejenigen Delikte, die vom internationalen Strafrecht nicht nur nach dem Territorialitätsprinzip, sondern auch nach dem aktiven Personalitätsprinzip, dem Weltrechtsprinzip, dem Prinzip der stellvertretenden Strafpflege oder dem Schutzprinzip erfasst werden. Bei Computerspionage, -sabotage oder -manipulation kommen im Wesentlichen das Territorialitäts- (§3 StGB) und das Ubiquitätsprinzip (§9 StGB) zur Anwendung. Das Territorialitätsprinzip besagt, dass das deutsche Strafrecht für die Taten gilt, “die im Inland begangen“ wurden; das Ubiquitätsprinzip (§9 Abs. 1 StGB) gilt für Taten, die “an jedem Ort begangen, an dem der Täter gehandelt hat oder im Falle des Unterlassens hätte handeln müssen oder an dem der zum Tatbestand gehörende Erfolg eingetreten ist oder nach der Vorstellung des Täters eintreten sollte“. Damit unterliegen sowohl Computerdelikte, die von einem Täter von Deutschland aus an ausländischen Rechnern begangen werden, wie auch Delikte, die vom Ausland aus an deutschen Systemen begangen werden, dem deutschen Strafrecht. Unterliegt ein Delikt dem deutschen Strafrecht und ist die deutsche Strafverfolgungsbehörde für die Verfolgung der Tat zuständig, so kann diese nach den Regeln des Völkerrechts jedoch nur auf deutschem Staatsgebiet tätig werden. Ermittlungen im Ausland würden das Hoheitsrecht des fremden Staates verletzen. Länderübergreifende Ermittlungen sind daher nur durch Kooperation der einzelnen Ermittlungsbehörden möglich, die den einschlägigen Normen über die internationale Amts- und Rechtshilfe unterliegen.
4.5 Europäische und internationale Rechtsprechung Auf internationaler und supranationaler Ebene besteht weitestgehend Einigkeit darüber, dass die Computerkriminalität wirksam bekämpft werden muss. Doch weisen
4.5. Europäische und internationale Rechtsprechung 145
vor allem die strafrechtlichen Bestimmungen über das Hacking, den Schutz von Geschäftsgeheimnissen sowie die nationalen Rechtsordnungen große Unterschiede auf. Oftmals sind die vorhandenen Gesetze unzureichend. Dies zeigt auch eine Studie des Washingtoner Consulting-Unternehmens McConnell International [74]. Die Studie „Cyber Crime ... and Punishment? Archaic Laws Threaten Global Information“ vom Dezember 2000 prüfte 52 Staaten – Deutschland war nicht darunter – bezüglich vorhandener Gesetze zur Ahndung von zehn verschiedenen Arten von Computerkriminalität aus den Bereichen „Datenbezogene Vergehen“, „NetzwerkKriminalität“, „Zugangserschleichung“ und „Mittäterschaft zu Cyber-Straftaten“. Lediglich zehn Länder kannten Tatbestände für sechs oder mehr Vergehen. Neun Länder verfügten über teilweise aktualisierte Gesetze für Computerkriminalität, erschreckenderweise verfügten 33 Länder über unzureichende oder nicht vorhandene Gesetze. Einzig die Philippinen können alle zehn Arten von Computerkriminalität verfolgen, USA immerhin neun. Es herrscht also weltweiter Nachholbedarf. Aus diesem Grund versuchen verschiedene Organisationen ihre diesbezüglichen Maßnahmen zu koordinieren und zu harmonisieren: Die Innenminister der G8 billigten im Dezember 1997 einen 10-Punkte-Aktionsplan, welcher auf dem Gipfeltreffen im Mai 1998 in Birmingham angenommen wurde. Ebenfalls seit 1997 arbeitet der Europarat am Entwurf eines internationalen Cybercrime-Abkommens. Es wurde eine gemeinsame Task Force der Europäischen Gemeinschaft und der Vereinigten Staaten zum Schutz kritischer Infrastrukturen gebildet. Die Vereinigten Staaten, die OECD und verschiedene internationalen Gremien (Global Business Dialogue, Trans-Atlantic Business Dialogue, etc.) sind ebenfalls im Bereich der Gesetzgebung für Computerkriminalität tätig. 4.5.1 G7/G8 Seit 1975 finden jährlich mehrere Konferenzen der Gruppe der sieben wichtigsten Industriestaaten (G7) Deutschland, Frankreich, Großbritannien, Italien, Japan, Kanada und USA zur Erörterung aktueller Fragen zur Weltwirtschaftslage statt [53]. Seit 1994 trafen sich die G7-Staaten und Russland unter der Bezeichnung P8 („Political 8“) jeweils im Anschluss an die G7-Gipfel, um über Wirtschaftsfragen zu beraten. Auf dem 24. Weltwirtschaftsgipfel in Birmingham 1998 konstituierte sich mit der vollständigen Aufnahme Russlands offiziell die G8. Die G8 beschäftigt sich im Wesentlichen mit politischen Fragen, die G7 mit finanz- und wirtschaftspolitischen. Die G8 kann keine formalen Abkommen schließen, jedoch kann sie durch ihre Studien und Berichte eine beratende Tätigkeit für den Europäischen Rat ausüben. Dieser arbeitet zurzeit an einer Konvention für Cyber-Kriminalität, die eine verbindliche Abmachung unter den EU-Mitgliedstaaten und so genannten beobachtenden Ländern, USA, Kanada und Japan, sein wird. Seit Jahren ist die Bekämpfung der grenzüberschreitenden organisierten Kriminalität ein zentrales Thema der G8-Konferenzen und damit auch die Hightech-Kriminalität. Uneinheitliche Regelungen und unterschiedliche Datenschutzbestimmungen stellen die Strafverfolger bei der Verfolgung internationaler Computerkriminalität vor große technische und organisatorische Probleme. Im Januar 1997
146 4 Computerkriminalität
wurde daher die Arbeitsgruppe „Hightech-Kriminalität“ als Untergruppe der Lyon Group sowie eine 24-Stunden-Kontaktgruppe gegründet. Das Ziel der Arbeitsgruppe „Hightech-Kriminalität“ ist es, die Gesetzgebung in den verschiedenen Bereichen der Computerkriminalität zu harmonisieren. Die Expertengruppe soll den Missbrauch der Datennetze untersuchen und Empfehlungen für mögliche Lösungen geben. Die 24-Stunden-Kontaktgruppe hat das Ziel, innerhalb kürzester Zeit länderübergreifend auf einen Vorfall zu reagieren und zu ermitteln. Eines ihrer größten Anliegen ist dabei eine Regelung für die Speicherung von Verbindungs- und Bestandsdaten bei Internet-Service-Providern und Telekommunikationsgesellschaften. Diese sollen international angeglichen werden, um eine schnelle grenzüberschreitende Verfolgung zu ermöglichen. Seit Mai 1999 will die G8 die internationale Führungsrolle bei der Verbrechensbekämpfung übernehmen. Im Oktober1999 trafen sich die Innen- und Justizminister der G8 in Moskau, um über Hightech-Kriminalität zu beraten. Sie verabschiedeten eine Erklärung zur „Bekämpfung der dunklen Seiten der Globalisierung“. Demnach sollen die einzelnen Länder die technischen und auch rechtlichen Möglichkeiten für eine grenzüberschreitende Verfolgung von Computerkriminalität schaffen. Es sollen nicht nur die Zugriffe auf die Verbindungsdaten und Netze der anderen Staaten möglich sein, sondern auch der Einsatz von Methoden, die im ermittelten Staat erlaubt, im angefragten Staat aber verboten sind. Den G8-Staaten soll es auch erlaubt sein, in den Mitgliedsstaaten Daten zu löschen, zu kopieren, Computersysteme zu durchsuchen oder auch zu beschlagnahmen. Im Mai 2000 trafen sich die (Minister-)Präsidenten bei der G8-Konferenz in Paris und berieten zusammen mit Vertretern der Wirtschaft und Juristen erneut über das Thema Computerkriminalität. Trotz verbreiteter Hysterie durch die jüngsten VirenAttacken (Melissa, I love you), endete das Treffen ohne konkrete Beschlüsse, da die Auffassungen und Vorstellungen zu unterschiedlich sind. Während die US-Polizei eine Art Cyber-Polizei, eine superschnelle Eingreiftruppe, fordert, lehnte der französische Innenminister Chevènement diesen Vorschlag kategorisch ab und forderte den Ausbau von Interpol. Auch Vertreter der Privatwirtschaft warnten vor einer Überregulierung des Internets und sprachen sich gegen die Schaffung neuer und für eine verstärkte Anwendung der vorhandenen Gesetze aus. Die beteiligten Staaten waren sich nur mal wieder einig bezüglich einer verstärkten Kooperation zur Bekämpfung der Kriminalität im Internet. Der Beschluss eines weiteren Treffens im Juli 2000 in Okinawa beinhaltet eine Intensivierung der Aktivitäten im Bereich Computerkriminalität durch Verstärkung der internationalen Zusammenarbeit und insbesondere der Zusammenarbeit mit der Industrie sowie die Umsetzung der in den OECD-Richtlinien vorgeschlagenen Maßnahmen. Bei der G8-Konferenz im Oktober 2000 in Berlin mit dem Thema „Security and Confidence in Cyberspace“ standen die Fragen im Vordergrund, wie Straftäter im Internet aufzuspüren sind („Einfrieren“ von Kommunikationsdaten) und wie die Sicherheit der Internet- und Intranet-Infrastruktur gewährleistet werden kann. Wie schleppend die Diskussion um Computerkriminalität verläuft, zeigt auch, dass ein wichtiger Aspekt der Debatte zwischen Politikern und Wirtschaft die „ver-
4.5. Europäische und internationale Rechtsprechung 147
trauensbildenden Maßnahmen“ aller Nutzer in das neue Medium und seine Geschäftsmöglichkeiten war. Erfreulich ist jedoch die Tatsache, dass der deutsche Außenminister J. Fischer der Orwell’schen Idee einer globalen Cyber-Polizei und „vollständigen“ Überwachung mit dem Argument eine klare Absage erteilte, dass Grund- und Freiheitsrechte nicht auf Kosten der Bekämpfung von Cyber-Kriminalität eingeschränkt werden dürfen. 4.5.2 Der Europarat Der Europarat (EuR) stand bei seiner Gründung im Mai 1949 am Anfang der europäischen Integration und Zusammenarbeit. Das Ziel des EuR, dem Deutschland 1951 beitrat, war die Förderung der gemeinsamen Interessen, des Friedens und der politischen Freiheit. Die Organe des EuRs sind das Ministerkomitee als Entscheidungsinstanz, die Parlamentarische Versammlung als demokratisches Forum und der Kongress der Gemeinden und Regionen Europas. Der Europarat ist eine von der EU unabhängige Institution. Dem EuR gehören zurzeit 41 Mitgliedstaaten an. Seit 1990 hat er 17 Mitgliedstaaten aus Mittel- und Osteuropa aufgenommen. Die Erweiterung ist jedoch noch nicht abgeschlossen: Die transkaukasischen Länder (Armenien, Georgien, Aserbaidschan), Weißrussland, Monaco, Bosnien und Herzegowina sowie die Bundesrepublik Jugoslawien haben bereits einen Beitrittsantrag gestellt. USA, Japan und Kanada haben einen Beobachterstatus. Nichteuropäische Staaten haben sich Konventionen und Teilabkommen des EuRs angeschlossen. Eine „Gesetzgebung“ des EuRs ist möglich durch den Erlass von Konventionen, die von den einzelnen Ländern ratifiziert werden müssen. Anschließend sind sie für die unterzeichnenden Mitgliedstaaten völkerrechtlich verbindlich. Die Notwendigkeit eines länderübergreifenden Gesetzes zur Bekämpfung von Cyber-Kriminalität wurde im EuR früh erkannt. Er veröffentlichte schon 1989 und 1995 Empfehlungen zum Umgang mit Computerkriminalität. Diese wurden jedoch als unzureichend empfunden. Daher wurde im Februar 1997 die Expertengruppe „Committee of Experts on Crime in Cyber-Space“ eingesetzt. Diese sollte eine Konvention zur Harmonisierung von Internet-Straftaten und vor allem zur internationalen Zusammenarbeit erarbeiten. Diese Konvention – die „Convention on Cyber Crime“ [42] – sollte die bis dahin weitestgehende und umfassendste internationale Regulierungsinitiative werden. Der Europarat unternimmt damit erneut einen Versuch, die unterschiedlichen Bemühungen seitens G8, OECD, UNO und EU zusammenzuführen. Die Idee der Konvention ist es, statt einer internationalen Bekämpfertruppe die nationalen Sicherheitsbehörden und Gesetze zu harmonisieren und damit die Grundlage für eine internationale Kooperation zu bilden. Die Cybercrime-Konvention Experten aus 41 Mitgliedstaaten des EuRs sowie aus den angeschlossenen Ländern wie USA, Japan, Kanada und Südafrika arbeiten an der „Convention on Cyber
148 4 Computerkriminalität
Crime“ mit. Der Europarat versucht mit der Cybercrime-Konvention einen gemeinsamen strafrechtlichen Mindeststandard im Bereich des Computer- und Telekommunikationsstrafrechts für die Mitgliedstaaten zu setzen. Das Ziel ist es, eine gemeinsame Rechtsgrundlage für die Strafverfolgung der meist länderübergreifenden Cyber-Kriminalität zu schaffen. Der Entwurf listet alle erdenklichen Verbrechen im Cyberspace auf: Hacking, Beeinträchtigung von Rechnersystemen, illegales Abfangen von Daten, Verstöße gegen das Urhebergesetz, Besitz und Handel mit Kinderpornografie etc. Der Entwurf verlangt auch die Festlegung von Mindeststandards für Strafmaße. Die ursprüngliche Planung sah vor, dass bis Dezember 2000 ein endgültiger Entwurf vorliegt, der dann bis Ende 2001 vom Ministerrat, dem obersten Organ des Europarats, ratifiziert werden kann. Am 22. Juni 2001 wurde die 27. und wahrscheinlich endgültige Fassung veröffentlicht, die im Herbst dem Ministerkomitee zur Verabschiedung vorgelegt werden soll. Gegenüber der heftigst diskutierten 25. Fassung, die am 22.12.2000 – kurz vor Weihnachten – in aller Stille im Web veröffentlicht wurde, wurde lediglich eine neue Datenschutzklausel eingefügt, aber sonst alles beim Alten gelassen. Damit wurde lediglich die Kritik der Arbeitsgruppe der Datenschützer der Europäischen Union aufgegriffen, die die Ansicht vertraten, dass die neue Cybercrime-Konvention in weiten Teilen gegen das Menschenrechtsabkommen des Staatenbundes verstoßen würde. Der Entwurf zum Cybercrime-Abkommen des Europarates mit dem Schwerpunkt zur Bekämpfung von Hacken von Computersystemen, Übertragung von kinderpornografischem Material, Computerbetrug und Datenspionage umfasst 48 Artikel. Davon standen unter anderem unter heftiger Kritik: – Article 3 – Illegal interception: Eine Ausnahmeregelung zum illegalen Abhören von und zu Computersystemen erlaubt das Hacken und Abhören computervermittelter Kommunikation für „im Einklang mit dem Gesetz stehende Behörden“. Welche darunter zu verstehen sind, bleibt offen. Ob beispielsweise der Betrieb des weltweiten, von der National Security Agency mit ihren Geheimdienstpartnern betriebene Lauschsystem Echelon oder ähnliche Einrichtungen anderer Länder dazu zählen, wird in keiner Fußnote erwähnt. – Article 6 – Misuse of devices: Die Herstellung, der Vertrieb, die Nutzung und selbst der Besitz von Geräten und Programmen, die dazu dienen, in Systeme einzudringen oder abzuhören, sind verboten, sofern diese mit illegaler Absicht eingesetzt werden. Ein Administrator darf Hackertools programmieren und anwenden, um Sicherheitslücken in seinem System zu entdecken; im Besitz eines Crackers sind dieselben Tools jedoch illegal. Dieser Artikel lässt aber jegliche Definition von „illegalen technischen Hilfsmitteln“ missen. Es wird daher kritisiert, dass der vorliegende Entwurf die Entwicklung neuer Sicherheitstools entscheidend behindert und den Regierungen eine übermächtige Rolle in der wissenschaftlichen Forschung einräumt.
4.5. Europäische und internationale Rechtsprechung 149
– Article 19 – Search and seizure of stored computer data: Artikel 19 fordert einen verpflichtenden Zugang der Regierung zu allen gespeicherten Daten, wenn nötig. – Article 17, 18, 24 und 25, der vom Abfangen und Mithören von elektronischen Daten im Zuge von Ermittlungsverfahren handelt. Es werden Gesetze gefordert, die einerseits das Abhören durch Ermittlungsbehörden erlauben und einerseits Provider dazu zwingen sollen, Datensammlungen in Echtzeit zu ermöglichen und durchzuführen. Nach heftigen Protesten wurde in der 25. Version eine Einschränkung getroffen, die die Anschaffung neuer teurer Abhöranlagen und -schnittstellen durch die Provider vorerst nicht zwingend vorschreibt. Befremdlich ist jedoch, dass keine Einschränkungen getroffen wurden, unter welchen Umständen solche massiven Eingriffe in die Privatsphäre verdächtiger Personen vorgenommen werden dürfen. Nach Ansicht von Datenschutzorganisationen stehen diese Artikel im Widerspruch zu den Datenschutzrichtlinien der EU und sind unverträglich mit der Europäischen Menschenrechtscharta und mit der Rechtsprechung des Europäischen Gerichtshofes für Menschenrechte. Die unzähligen Einwände durch die verschiedenen Organisationen und Verbände sind nur durch kleine kosmetische Korrekturen in den Entwurf eingeflossen. Der Wirtschaft geht das Abkommen in vielen Bereichen zu weit. Es wird davor gewarnt, dass das bisherige Wachstum im Bereich elektronischen Handels ausgebremst werden könnte. Das Sicherheitsproblem ist nicht dadurch zu lösen, dass Angriffswerkzeuge und Computerviren verboten werden. Bürgerrechtsorganisationen aus aller Welt sorgen sich, dass die Konvention „die Rechte von Individuen bedroht und gleichzeitig die Macht der Polizeibehörden ausdehnt“. 4.5.3 Europäische Kommission Die Europäische Kommission ist die „Exekutive“ der Europäischen Union. Sie ist die Initiatorin politischer Maßnahmen, die politischen Entscheidungen liegen jedoch beim Rat in Kooperation mit dem Parlament. Die Kommission ist unabhängig von den einzelnen Nationalstaaten und ausschließlich dem „allgemeinen Wohl“ der europäischen Einigung verpflichtet. Sie kann Gesetzesinitiativen in Form von „Vorschlägen“ an den Rat der Europäischen Union und das Europäische Parlament richten. Jedes Mitgliedsland ist in der Kommission vertreten. Von den fünf großen Ländern werden jeweils zwei Kommissare gestellt, die übrigen Länder stellen jeweils einen. Im Januar 2001 veröffentlichte die Europäische Kommission einen Vorschlag zur Bekämpfung von Computerkriminalität mit dem Titel „Schaffung einer sicheren Informationsgesellschaft durch Verbesserung der Sicherheit von Informationsinfrastrukturen und Bekämpfung der Computerkriminalität“ (eEuropa 2002) [44]. Darin werden grundlegende – und nicht gerade neue – Erkenntnisse veröffentlicht wie die Notwendigkeit zur Angleichung nationaler Gesetze – da Cyber-Kriminalität nicht
150 4 Computerkriminalität
an den Grenzen Halt macht und die Bekämpfung auf nationaler wie auch internationaler Ebene notwendig ist – und dass Cyber-Kriminalität eine Bedrohung für Investitionen sowie Anlagen der Industrie darstellt. Der Plan sieht vor, dass bis Ende 2002 ein „koordiniertes und kohärentes“ europäisches Konzept für die Bekämpfung der Cyber-Kriminalität vorliegen soll. Die Realisierung soll in mehreren Stufen erfolgen. In den nächsten Jahren möchte die Europäische Kommission in einer ersten Stufe Vorschläge zur Bekämpfung der Kinderpornografie erarbeiten, im Anschluss daran Gesetzesvorschläge zum Hacking und zu Denial-of-Service-Attacken. Die Kommission möchte auch durch Prozessverordnungen sicherstellen, dass schnelle internationale Zusammenarbeit bei den Ermittlungen möglich ist. Aus diesem Grunde unterstützt sie die Forderungen nach Ausweitung der Abhörmaßnahmen bei neuen Technologien, eine Standardisierung der technischen Abhöranforderungen für Provider und Telekommunikationsunternehmen sowie die Ausweitung der Zuständigkeit von Europol bei Computerkriminalität. 4.5.4 Vereinte Nationen (UNO) Die Vereinten Nationen nehmen sich des Problems der Computerkriminalität nur zögerlich an. Das ist umso erstaunlicher, da es die einzige Organisation ist, der beinahe alle Staaten angehören und die somit als einzige einen wirklichen weltweiten Konsens finden könnte. Die Möglichkeit einer Rechtsetzung durch die UNO wäre die Schaffung eines „Völkerstrafrechts“ durch den Abschluss völkerrechtlicher Verträge. Doch bisher gibt es nur wenige davon. Ein Versuch eines internationalen Strafgesetzbuches ist der „Draft Code of Crimes Against the Peace and Security of Mankind“ aus dem Jahre 1996. Darin sind jedoch keine Kommunikationsdelikte zu finden. Im April 2000 fand in Wien der zehnte „United Nations Congress on the Prevention of Crime and the Treatment of Offenders“ statt. Auf diesem Kongress, der alle fünf Jahre stattfindet, treffen sich unterschiedliche Experten des Strafrechts. Er dient der Entwicklung von Normen und Standards für verbesserte nationale und internationale Zusammenarbeit, zum Austausch von Erfahrungen und als Diskussionsforum für Strategien zur Bekämpfung von Kriminalität. Neben organisiertem Verbrechen und Korruption war Computerkriminalität im April 2000 ein zentrales Thema. Der ganztägige Workshop „Verbrechen im Zusammenhang mit Computer-Netzwerken“, der zu diesem Thema eigens durchgeführt wurde und an dem Vertreter der Regierungen und der Industrie teilnahmen, enthielt vier Panel-Diskussionen und verschiedene Vorträge von geladenen Experten. Ziel war der Austausch von Informationen über Ermittlungstechniken und vorhandene Computerkriminalitätsgesetze in Ländern mit verschiedenen Erfahrungen und Ermittlungsstrategien. Die Erkenntnisse dieses Workshops waren:
4.5. Europäische und internationale Rechtsprechung 151
– Computerkriminalität sollte unter Strafe gestellt werden, – es werden angemessene Gesetze für die Untersuchung und strafrechtliche Verfolgung benötigt, – Regierungen und Industrie sollten zusammenarbeiten, – verbesserte internationale Kooperation für die Verfolgung im Internet wird benötigt, – und die UNO sollte weitere Aktivitäten fördern, um den Bereich der technischen Zusammenarbeit zu unterstützen. Die im Dezember 2000 erlassene UNO-Resolution 55/59 befasst sich in Paragraf 18 mit High-Technology und Computerkriminalität. Die Mitgliedstaaten beschlossen in diesem Paragrafen, aktionsorientierte Richtlinien zur Vorbeugung und Bekämpfung von Computerkriminalität zu entwickeln, und verpflichten sich daran zu arbeiten, diese Verbrechen besser zu verhindern, zu untersuchen und strafrechtlich verfolgen zu können. Das „Economic and Social Council“ hatte in der Resolution 199/23 vom 28. Juli 1999 eine Studie gefordert, die untersuchen soll, welche geeigneten Maßnahmen auf nationaler und internationaler Ebene zur Vorbeugung und Bekämpfung von Computerkriminalität möglich und notwendig sind. Diese Studie wurde auf dem im April 2001 in Wien abgehaltenen zehnten UNO-Kongress der „Commission on Crime Prevention and Criminal Justice“ (CPCJ) vorgestellt. Diese „Studie“ beschreibt in der Einleitung das Problem als global, dynamisch und interdisziplinär und listet im Weiteren die Aktivitäten verschiedener internationaler Organisationen auf dem Gebiet der Computerkriminalität auf. Sie empfiehlt dem „Centre for International Crime Prevention“ die Durchführung einer ausführlicheren Studie, die den Bedarf der einzelnen Länder ermitteln soll. Eine Gruppe von Experten soll dann auf Grundlage dieser neuen Studie die Kommission auf dem elften CPCJ-Kongress im Jahre 2002 dahingehend beraten, inwieweit eine internationale Vorgaben durchführbar und wünschenswert wäre. 4.5.5 Organization for Economic Cooperation and Development Der Organization for Economic Cooperation and Development (OECD) gehören 29 Staaten an, darunter alle west- und mitteleuropäischen Staaten, die USA, Kanada, Mexiko, Japan, Südkorea, Australien und Neuseeland. Sie wird als die Organisation angesehen, die für die Rechtsangleichung die herausragende Rolle spielen könnte. Die OECD hat auch bereits wichtige Vorarbeiten geleistet. Schon 1985 wurden detaillierte Empfehlungen zur Strafbarkeit bestimmter Computerdelikte veröffentlicht, die aber bei weitem nicht mehr dem heutigen Stand der Technik genügen. Im November 1992 übernahm die OECD die Empfehlungen des ICCP-Komitees („Information, Computer and Communications Policy“), das im Wesentlichen für die Regulierung von Internet-Inhalten zuständig ist. Das ICCP-Komitee hatte 1990 eine Expertengruppe eingesetzt, um Richtlinien für Sicherheit von Informationssystemen zu erarbeiten. Die Expertengruppe, die aus Regierungsangehörigen, Mathe-
152 4 Computerkriminalität
matikern, Informatikern und Rechtswissenschaftlern bestand, veröffentlichte ihre „Guidelines for the Security of Information Systems“ nach zweijähriger Arbeit im Oktober 1992. Der Schwerpunkt der OECD-Arbeit liegt jedoch in der Unterstützung von Electronic Commerce. So übernahm die OECD im Mai 1997 die Empfehlungen des Berichts über „Global Information Infrastructure/Global Information Society“. Im August 1997 veröffentlichte die OECD ihre Kryptografie-Richtlinien, nach denen unter anderem die Weiterentwicklung der Kryptografie international unterstützt werden soll sowie das individuelle Grundrecht auf Schutz der Geheimhaltung der Kommunikation und der personenbezogenen Daten bei nationalen KryptografieGesetzen zu beachten sind. Weitere Veröffentlichungen in den Bereichen digitale Signatur, Zertifizierung, Privacy und Konsumentenschutz folgten. Nach einer Überprüfung der „Guidelines for the Security of Information Systems“ im Jahre 1997, wird nun auf der nächsten OECD-Konferenz im September 2001 in Tokyo ein Workshop zum Thema „Information Security in a Networked World“ veranstaltet. Als Hintergrundinformation dienen die Guidelines von 1992. Vorgesehen sind unter anderem Diskussion zur Rolle der OECD, der Bedeutung der OECD-Guidelines, die Notwendigkeit von internationaler Zusammenarbeit und deren Voraussetzung, über den aktuellen Stand und Ausprägung der Cyber-Kriminalität, aber auch den Einfluss auf den E-Commerce. Die erwarteten Diskussionsergebnisse sollen die Grundlage schaffen für die anstehende Überarbeitung der Guidelines durch die OECD Working Party on Information Security and Privacy, die im Jahre 2002 abgeschlossen sein soll.
4.6 Sicherheitsmaßnahmen zum Schutz kritischer Infrastrukturen Neben den internationalen Bemühungen in den Bereichen der Gesetzgebung zu Computerkriminalität und Zusammenarbeit bei der Verfolgung von Tätern haben die verschiedenen Regierungen in den letzten Jahren erkannt, dass der Schutz „kritischer Infrastrukturen“ vor allem ein nationales Problem – und damit ein Problem der Regierung – und nicht nur der einzelnen Unternehmen ist. Aber was versteckt sich hinter dem Begriff „kritische Infrastrukturen“ überhaupt? Dieser Begriff wird in teilweise unterschiedlicher Bedeutung verwendet, abhängig von den unterschiedlichen gesellschaftlichen Betrachtungsweisen. Für das BSI – als Vertreter des europäischen Standpunktes – sind kritische Infrastrukturen „Organisationen und Einrichtungen mit (lebens-)wichtiger Bedeutung für das staatliche Gemeinwesen [...], wenn durch Ausfall oder Störungen für größere Bevölkerungsgruppen nachhaltig wirkende Versorgungsengpässe oder andere dramatische Folgen eintreten. Für das reibungslose Funktionieren von Staat und Wirtschaft sind die Infrastrukturbereiche Telekommunikation, Transport- und Verkehrswesen, Energieversorgung (Elektrizität, Öl, Gas), Gesundheitswesen (einschl. Lebensmittel- und Trinkwasserversorgung), Notfall- und Rettungsdienste, Regie-
4.6 Schutz kritischer Infrastrukturen 153
rung und öffentliche Verwaltung (einschließlich Polizei, Zoll und Bundeswehr) sowie Bank-, Finanz- und Versicherungswesen von besonderer Bedeutung “. Die etwas abweichende Betrachtungsweise der Amerikaner offenbart sich im Bericht der vom damaligen amerikanischen Präsidenten Clinton eingerichteten Kommission zum Schutz kritischer Infrastrukturen (PCCIP) vom Oktober 1997. Darin wird der Begriff „kritische Infrastrukturen“ umschrieben als: „Infrastructures which are so vital that their incapacitation or destruction would have a debilitating impact on defense or economic security“. Hier wird die amerikanische Einstellung deutlich, dass die Sicherung der weltweiten Wettbewerbsfähigkeit der amerikanischen Volkswirtschaft Vorrang vor allem anderen hat. Durch diese Auffassung wird der Kreis der Einrichtungen und Unternehmen, die zur kritischen Infrastruktur hinzuzählen sind, gegenüber der europäischen Auffassung erheblich ausgeweitet. Durch diese Ausweitung wird der Versuch einer Realisierung erheblich erschwert. Ein weiterer aus dieser Auffassung resultierender Unterschied ist die Bedeutung des Datenschutzes und der individuellen Freiheiten, die als direkte Gegenspieler für Schutzmaßnahmen zur Sicherung dieser Infrastrukturen gelten. 4.6.1 Deutschland Im Folgenden stellen wir einige Initiativen von Deutschland vor. Dabei handelt es sich um verschiedene Task Forces und Arbeitskreise, die an Lösungen zum Schutz staatlich relevanter Ressourcen arbeiten. Task Force „Schutz kritischer Infrastrukturen“ Nachdem im Oktober 1997 in den USA der PCCIP-Bericht „Critical Foundations“ vorgelegt wurde, wurde das Bundesamt für Sicherheit der Informationstechnik (BSI) vom damaligen Innenminister Manfred Kanther beauftragt, eine entsprechende Studie für Deutschland zu erstellen. Noch im Jahre 1997 wurde dazu die Ressortarbeitsgruppe „kritische Infrastrukturen“ (KRITIS) am BSI eingerichtet. Die in Auftrag gegebene Studie „Informationstechnische Bedrohungen für kritische Infrastrukturen in Deutschland“ sollte die kritischen Infrastrukturen, die Art der Gefährdungen und der möglichen Aggressoren identifizieren sowie geeignete Schutzmaßnahmen erarbeiten. Die Studie wurde in Zusammenarbeit mit möglicherweise betroffenen Bundesressorts des BSI erstellt und sollte im Frühjahr 2001 dem Kabinett und anschließend auch der Öffentlichkeit vorgestellt werden. Der mehrfach umgeschriebene Bericht erlangte durch Abstimmungsprobleme nie ein verabschiedungsreifes Stadium. Die vorläufige Version 7.95 vom 3. Dezember 1999 enthält neben allgemein Bekanntem mehr offene Fragen, Probleme und unklare Lösungsvorschläge als konkrete Lösungsansätze. Im Frühjahr 2001 hat die Arbeitsgruppe KRITIS ein Studienprojekt gestartet, in dem die Netzwerksicherheit von Finanzdienstleistern überprüft werden sollte. Ziel der umfangreichen Untersuchung war die Identifizierung von Schwachstellen, mit deren Hilfe Angreifer in das Bankensystem eindringen oder dieses lahm legen könn-
154 4 Computerkriminalität
ten. Dazu wurden die Netzwerke der Finanzdienstleister bis ins Detail analysiert, um potenzielle Knackpunkte in den bestehenden Sicherheitsvorkehrungen festzustellen. Ein erster Berichtsentwurf der von der Eschborner Unternehmensberatung Eurosec Chiffriertechnik & Sicherheit erstellten Studie liegt nun vor und wird gegenwärtig von Experten des BSI geprüft. Diese Studie soll dann der Bundesregierung als Grundlage für weitere Schritte zum Schutz der kritischen Infrastrukturen dienen. Task Force „Sicheres Internet“ Ein weiterer Versuch, dem Problem Computerkriminalität zu begegnen, wurde von Innenminister Otto Schily nach den Distributed-Denial-of-Service-Attacken unternommen. Er rief am 14. Februar 2000 die Task Force „Sicheres Internet“ ins Leben. Diese setzt sich aus zwölf ständigen Mitgliedern aus verschiedenen Ministerien, dem BSI und dem Bundeskriminalamt zusammen. Die Kernaufgabe der InternetTask-Force ist die Analyse der Schwachstellen in Deutschland und die Erarbeitung von Gegenmaßnahmen. Bisher wurden zwei Maßnahmenkataloge im Internet veröffentlicht: „Empfehlungen zum Schutz vor verteilten Denial of Service-Angriffen im Internet“ und „Empfehlungen zum Schutz vor Computer-Viren aus dem Internet“. Die darin enthaltenen Empfehlungen sollen als Leitlinien und Diskussionsgrundlage zur konkreten Realisierung von Maßnahmen verstanden werden. Ergänzend dazu befindet sich – ebenfalls von Schily initiiert – eine „schnelle Eingreiftruppe“ beim Bundesamt für Sicherheit in der Informationstechnik im Aufbau. „Arbeitskreis Schutz von Infrastrukturen“ Parallel zu den Bemühungen von Schily wurde von der Industrieanlagen-Betriebsgesellschaft (IABG), München, der „Arbeitskreis Schutz von Infrastrukturen“ (AKSIS) gegründet. Das vom Bund 1961 gegründete Unternehmen IABG berät das Militär, die Luft- und Raumfahrtindustrie sowie Behörden und Unternehmen in sicherheitstechnischen Fragen. Im 1999 etablierten Arbeitskreis, der sich zweimal jährlich trifft, arbeiten Experten aus Staat und Wirtschaft, wie die Sicherheitschefs von Großkonzernen wie Deutsche Bank, Lufthansa, Siemens, Dasa und Telekom, Vertreter von Tüv, Eisenbahnbundesamt, Bundesbank, Gesellschaft für Reaktorsicherheit, BKA und Ministerien zusammen. Angeschlossen haben sich dieser Interessenvereinigung etwa 80 Unternehmen, Verbände und Dienstleister, darunter Banken, Telekommunikationsunternehmen, Energieversorger, Bundesressorts und Bundesländer, das BSI, Sicherheitsdienste und Forschungseinrichtungen. Der Arbeitskreis ist ein Forum zum Erfahrungs- und Informationsaustausch und arbeitet eng mit KRITIS zusammen. Sein Hauptanliegen ist vor allem, die Verletzlichkeit der Infrastruktur durch die Vernetzung zwischen den Sparten wie Verkehr, Energieversorgung, Banken und Finanzwesen, Telekommunikation, Sicherheitsdiensten und -organisationen, sensitiven Wirtschaftsunternehmen und öffentlicher Verwaltung zu analysieren, darzustellen und Maßnahmen zum übergreifenden Sicherheits-
4.6 Schutz kritischer Infrastrukturen 155
management zu erarbeiten. Das mittelfristige Ziel von AKSIS ist der systematische Auf- und Ausbau eines übergreifenden Informations-, Krisenmanagement- und Schutzsystems in enger Partnerschaft von Staat und Privatwirtschaft. 4.6.2 Europa Von den Einzelstaaten haben nur wenige – darunter Deutschland, Großbritannien, Schweiz und Skandinavien – begonnen, Einrichtungen zu etablieren, die die Aufgabe der Sicherung der kritischen Infrastrukturen haben. Erste Projekte zum Thema „Critical Infrastructure Dependability and Protection“ entstehen im IST-Programm (Information Societies Technologies) und dem „eEurope2002 Action Plan“ der EU 44. 4.6.3 USA Ein Problem, das bei der Bekämpfung von Computerkriminalität in den USA aufgetreten ist, ergab sich aus der Zuständigkeit der einzelnen Gruppen. Das Militär fühlte sich lange nicht zuständig, da es sich zum einen nicht um physische Gewalt handelt und zum anderen dem US-Militär durch den „Posse Comitatus Act“ von 1878 verboten ist, im Inland aktiv zu werden. Das Federal Bureau of Investigation (FBI) gehörte zu den ersten, die sich dem Problem der Computerkriminalität annahmen. Das FBI organisierte die ersten Konferenzen zum Thema Computerkriminalität 1992 in Charleston und 1997 in New York. Und es war auch eine Abteilung des FBI, die im Februar 1995 Kevin Mitnick (siehe Kapitel 3.4) festgenommen hat. Das FBI bildete im Februar 1992 die „National Computer Crime Squad“ (NCCS) zur Untersuchung von Fällen der Computerkriminalität und im gleichen Jahr noch das „Computer Analysis and Response Team“ (CART), das für die Computerforensik zuständig ist. Weitere Abteilungen folgten Ende 1995 in New York und San Francisco. Das 1995 neu gegründete „Computer Investigations and Infrastructure Threat Assessment Center“ (CITAC) war für die Untersuchung der Bedrohungen für Rechner und der Infrastruktur zuständig. Seit August 1997 wurde das CITAG mit immer neuen, weiterreichenden Rechten versehen und durch die Etablierung des „Office of Computer Investigations and Infrastructure Protection“ (OCIIP) und im Februar 1998 des „National Infrastructure Protection Center“ (NIPC) ausgebaut. Bis heute wurde die NIPC ständig vergrößert, und die Befugnisse ausgeweitet wurden. Die Aufgaben des NIPC sind die Bedrohungen für die amerikanische Infrastruktur zu analysieren sowie Warnungen und Ratschläge bezüglich Informationstechnologie und auch Cyber-Terrorismus abzugeben. Alle Exekutiv-Abteilungen sind verpflichtet, mit dem NIPC zusammenzuarbeiten. Parallel dazu wurden in den Regionalbüros des FBI im Rahmen des „National Infrastructure Protection and Computer Intrusion Program“ (NIPCIP) entsprechende Abteilungen aufgebaut. Anfang nahm diese Entwicklung im Cleveland FBI Field Office mit dem InfraGard-Pilotprogramm. Das Pilotprogramm startete 1996, als das
156 4 Computerkriminalität
Cleveland FBI Field Office Experten der Region um Unterstützung bei der Untersuchung der Bedrohungen und Sicherung der kritischen Infrastruktur bat, darunter auch die Universität von Cleveland/Ohio. Offiziell eingeführt wurde das InfraGardProgramm am 5. Januar 2001 von der NIPC als Koordinator des NIPCIP zusammen mit der Privatwirtschaft. Es dient dem Informationsaustausch zwischen der US-Regierung, regionalen und staatlichen Verwaltungen und privaten Unternehmen. Inzwischen verfügt jedes der 56 regionalen FBI-Büros über eine InfraGard-Sektion mit insgesamt 518 Firmen als Mitglieder. Hauptziel ist der anonymisierte Informationsaustausch zwischen der US-Regierung, regionalen und staatlichen Verwaltungen und privaten Unternehmen. Als Reaktion auf den Bombenanschlag in Oklahoma im April 1995 wurde im August 1996 von der damaligen Justizministerin Janet Reno auf Weisung vom damaligen Präsidenten Clinton eine interministerielle Arbeitsgruppe eingesetzt, die die Verwundbarkeit Amerikas durch Terrorismus untersuchen sollte. Die „Critical Infrastructure Protection Working Group“ (CIPWG) bestand aus Vertretern aus der Strafverfolgung, des Militärs, der Spionageabwehr und dem Nationalen Sicherheitsrat. In dem dem Präsidenten vorgelegten Bericht der CIWG wurde erstmals die Verwundbarkeit der kritischen Infrastrukturen durch Cyber-Attacken genannt. Die CIPWG empfahl eine umfassende Studie zum Schutz der kritischen Infrastrukturen und als kurzfristige Maßnahme die Bildung einer Task Force. Präsident Clinton setzte diese Empfehlung um und etablierte im Juli 1996 durch die Executive Order 13010 die „President’s Commission on Critical Infrastructure Protection“ (PCCIP). Die Kommission setzt sich aus Vertretern der Regierung und der Privatwirtschaft zusammen. Diese sollte einen umfassenden Bericht über die Sicherheit aller Infrastruktursysteme der USA erstellen, die Bedrohungen und Schwachstellen identifizieren, nationale Richtlinien erarbeiten und Strategien zum Schutz empfehlen. Zeitgleich mit der PCCIP wurde die „Infrastructure Protection Task Force“ (IPTF) gegründet, die die Aufgabe hatte, bis zum Abschlussbericht der Kommission die dringlichsten Aufgaben der Infrastruktursicherheit zu übernehmen. An der IPTF waren das FBI, die NSA und das Pentagon beteiligt. Angesiedelt wurde die IPTF beim Justizministerium, um die Zusammenarbeit mit dem kurz zuvor im FBI eingerichteten CITAC zu gewährleisten. Im Oktober 1997 legte die PCCIP ihren Abschlussbericht „Critical Foundations“ vor. Darin wird betont, dass das Land sehr stark von den Infrastrukturen abhängig ist und es daher als nationale Aufgabe betrachtet werden muss, diese zu schützen. Als kritische Infrastrukturen wurden die Branchen Information und Kommunikation, Banken- und Finanzwesen, Wasser-, Elektrizität-, Gas- und Ölversorgung, Verkehr und Transport, Notfalldienste und die Systeme der Regierung und Verwaltung identifiziert. Er wurde betont, dass der anwachsende Cyber-Terrorismus unmittelbar mit der Sicherheit der kritischen Infrastruktur verbunden ist. Empfehlungen und Maßnahmen zur Gewährleistung des Schutzes wurden ausgesprochen. Auch wurde betont, dass maximal drei bis fünf Jahre zur Etablierung eines umfassenden nationalen „Schutzschildes“ für die Infrastruktur verbleiben, bevor die Bedrohung für die nationale und wirtschaftliche Sicherheit bedrohliche Ausmaße annimmt. Als Kritik
4.6 Schutz kritischer Infrastrukturen 157
am PCCIP-Bericht muss angeführt werden, dass einige dieser Empfehlungen möglicherweise eine Reihe von wichtigen Bürgerfreiheiten wie die Meinungs- und Informationsfreiheit beschneiden könnten. Der erste Schritt zur Umsetzung der gewonnenen Erkenntnisse des von der PCCIP vorgelegten Berichts wurden durch die Veröffentlichung der „Presidential Decision Directive“ PDD-63 im Mai 1998 gemacht. Sie bildete die Grundlage zur Etablierung der „National Structure for Critical Infrastructure Protection“, einem nationalen „Schutzschild“ für kritische Infrastrukturen, und forderte die Umsetzung innerhalb von zwei Jahren, nach maximal fünf Jahren soll die volle Leistungsfähigkeit erreicht werden. Der ehemalige Präsident Clinton richtete das Amt eines „National Coordinator for Security, Infrastructure Protection and Counter-Terrorism“ ein, der vom ebenfalls neuen „Critical Infrastructure Assurance Office“ (CIAO) bei der Strategieentwicklung unterstützt werden soll. Der National Coordinator berichtet dem Präsidenten, besorgt den Etat und koordiniert die einzelnen Büros bei der Entwicklung von Richtlinien, der Etablierung und dem Krisenmanagement. Das CIAO – früher das „National Plan Coordination Office“ – ist für die Koordination nationaler Schulungsprogramme wie auch für gesetzgebende und öffentliche Angelegenheiten zuständig. Die Sicherheit einzelner Sektoren der Infrastruktur, etwa Information, Wasser oder Transport, wurde unterschiedlichen Ministerien als „Lead Agencies“ unterstellt. Die interministeriellen Koordination zur Durchsetzung der PDD-63 wird durch die ebenfalls neu geschaffene „Critical Infrastructure Coordination Group“ (CICG) sichergestellt, welcher Vertreter der verschiedenen Ministerien angehören. Der Vorsitz der CICG hat der National Coordinator. Im Dezember 1999 wurde die Initiative „Partnership for Critical Infrastructure Security“ (PCIS) gegründet. An der PCIS beteiligt sind Unternehmen aus mehr als einem halben Dutzend Infrastrukturbranchen, darunter Telekommunikation, Transport, Stromversorgung oder Finanzwesen. Im Dezember 2000 wurde von der PCIS der Regierung ein geheimer Bericht überreicht, der den Fortschritt der Privatwirtschaft bei der Sicherung der kritischen Infrastrukturen und der Hacker-Abwehr dokumentieren soll. Der „National Plan for Information Systems Protection“ (kurz Nationalplan) wurde von Clinton am 7.1.2000 vorgelegt. Darin wurden fast alle Empfehlungen des PCCIP-Berichts von 1997 berücksichtigt. Das hochgesteckte Ziel ist es, bis 2003 einen weitgehenden Schutz der kritischen Infrastrukturen aufzubauen, um die meisten bekannten Schwachstellen in kritischen Informationssystemen von Regierungsbehörden und Schlüsselindustrien zu eliminieren. Der Plan unterscheidet dabei drei übergeordnete Ziele: – 1. Vorbereiten und Verhindern – 2. Entdecken und Reagieren und – 3. Aufbau solider Grundlagen.
158 4 Computerkriminalität
Das zweite Ziel „Entdecken und Reagieren“ soll durch den Aufbau eines vernetzten Intrusion Detection-Systems (IDS) erreicht werden. Das „Federal Intrusion Detection Network“ (FIDNet), angesiedelt am NIPC, sollte der Regierung helfen, Angreifer schnell zu erkennen, (halb-)automatisch Mechanismen der Gegenwehr auslösen und die leichte Lokalisierung von Angreifern ermöglichen. Die Erfüllung des dritten Grobziels wird durch Neuerungen in der Gesetzgebung unterstützt, die ermöglichen, dass Gelder für das Vorhaben zur Verfügung stehen. Die Pläne des FIDNet sahen vor, den US-Strafverfolgungsbehörden nie dagewesene Überwachungsmöglichkeiten über das Internetverhalten jedes Einzelnen zu geben. Das stieß wegen der befürchteten Einschränkungen des Datenschutzes auf heftigsten Widerstand sowohl in der Öffentlichkeit als auch im Kongress und scheiterte daraufhin. Als Konsequenz wurden die Pläne zurückgezogen, doch 2000 eingeschränkt auf die Überwachung von Regierungssystemen und Beamten wieder hervorgeholt. Man nahm von einem automatischen, zentralen System, das gegen geltendes Recht verstoßen würde, Abstand. Die einzelnen Behörden und Ministerien betreiben jeweils unabhängige Intrusion-Detection-Systeme in ihren eigenen Netzen. Die gesammelten Informationen werden (freiwillig) an die „Federal Computer Incident Response Capability“ (FedCIRC) gemeldet. Die (FedCIRC) der General Services Administration ist für die Sicherheit aller nicht militärischen Regierungscomputer zuständig und ist Betreiber des FIDNet. Die Überwachung der Rechner und Systeme des „Department of Defense“ (Verteidigungsministerium) liegt in den Händen der bereits 1999 eröffneten „Joint Task Force – Computer Network Defense“ (JTF-CND). Bei Angriffen auf Systeme, die zum nationalen Sicherheitsapparat gehören, ist das schon 1998 eingerichtete „National Security Incident Response Center“ (NSIRC) der NSA zuständig. Es unterstützt auch JTF-CND, NIPC und den Nationalen Sicherheitsrat durch Echtzeitanalysen und Computerforensik. Das FBI arbeitet immer enger mit der „National Security Agency“ (NSA) zusammen, die die technische Unterstützung liefert. Die NSA ist der Abhörgeheimdienst der Streitkräfte und betreibt Stationen in der ganzen Welt, u.a. im Rahmen des Echelon-Systems. Deren Rolle wuchs infolge des Nationalplans, der für die Einrichtung des „National Security Incident Response Center“ (NSIRC) bei der NSA sorgte. Das NSIRC hat im Wesentlichen vier Aufgabenbereiche: den Informationsschutz, die Berichterstattung und Analyse der Netzwerkvorfälle, die Analyse des Potenzials der Hacker und die Bedrohungsanalyse. Sie pflegen eine zentrale Datenbank mit Informationen über Computersicherheitsprobleme und versorgen die Sicherheitsexperten des betreuten nationalen Sicherheitsapparats mit Detailwissen über die neuesten Hacker-Techniken. Zusammen mit der Privatwirtschaft wurde ein „National Infrastructure Assurance Council“ (NIAC) eingerichtet, um die Zusammenarbeit zu verbessern und auszubauen. Dieses Beratungsgremium, in dem Firmenchefs aus der Computerbranche und anderen wichtigen Infrastruktursektoren vertreten sind, soll dem Präsidenten mit Rat und Tat zur Seite stehen. Clinton ernannte die 21 Mitglieder – darunter auch Bill Gates und Alfred R. Berkeley III (Präsidenten von Nasdaq Stock Market, Inc.) – erst im Januar 2001 kurz vor seinem Amtsabtritt, was auf harsche Kritik stieß.
4.6 Schutz kritischer Infrastrukturen 159
Im Bereich der privaten Industrie wurde mit der Schaffung von „Information Sharing and Analysis Centers“ (ISAC) begonnen. Sie dient dem anonymisierten Informationsaustausch über Sicherheitslücken zwischen den Mitgliedern und der Regierung, sammelt allgemeine Informationen zum Thema IT-Sicherheit und berät in technischen und organisatorischen Fragen. Sie steht damit in direkter Konkurrenz zu etablierten Einrichtungen wie dem CERT, Mailing-Listen wie Bugtraq, dem InfraGard-Programm oder dem PCIS. Angesiedelt ist die ISAC, zu dessen achtzehn Mitgliedern Firmen wie Cisco, Intel, AT&T, IBM, EDS, Microsoft und Oracle zählen, bei der Firma Internet Security Systems in Atlanta. Ihre Arbeit nahm sie im März 2001 auf. Im Februar 2001 wurde der Bericht über die Sicherheit der staatlichen Computernetze von der CIAO herausgegeben. Er soll der neuen Regierung Aufschluss über den Stand der Implementierung des Nationalplans geben. Die wesentliche Aussage dieses Berichts ist, dass Fortschritte erzielt wurden, doch noch viel zu tun ist. Die Zusammenarbeit der Regierung mit der Industrie wurde verbessert. Die Identifizierung der wichtigsten, schutzwürdigsten Objekte hat begonnen, ist jedoch noch nicht abgeschlossen. US-Präsident Bush hat den Schutz der kritischen Infrastruktur – wie schon sein Vorgänger Clinton – als ein wichtiges Thema für die US-Wirtschaft und die nationale Sicherheit eingestuft. Entsprechende Zusagen zur Finanzierung wurden trotz versprochener Steuersenkungen getroffen. Es existieren jedoch auch Gruppen innerhalb der Reihen der Privatwirtschaft und der Datenschützer, die strikt gegen staatliche Regulierungen sind. Sie argumentieren, dass der größte Teil der kritischen Infrastruktur sich in Privatbesitz befindet und es daher die Aufgabe der Betreiber sein müsste. Da die Vorstellung der „Selbstregulierung des Marktes“ das amerikanische Weltbild sehr stark prägt, ist die Kooperationsbereitschaft der privaten Betreiber mit den staatlichen Sicherheitsbehörden vergleichsweise gering.
160 4 Computerkriminalität
Teil II0
161
Basisfunktionen und Sicherheitsprinzipien
5
Abb. 1-0 Tabelle 1-0
5.1 Einleitung Zunächst befassen sich die Security Patterns im ersten Teil dieses Kapitels mit den grundlegenden Sicherheitsfunktionen, die in diesem Buch verwendet werden: Identifikation und Authentisierung, Verschlüsselung, Zugriffskontrolle, Integrität und Audit. Sie stellen die Grundbausteine für die technische Umsetzung von Sicherheitszielen dar. Im zweiten Abschnitt dieses Kapitels beschäftigen wir uns mit Security Patterns, die Sicherheitsprinzipien repräsentieren, die beim Entwurf von ITAnwendungen, Systemen und Netzwerken auf allen Ebenen zum Tragen kommen sollten. Sie stellen somit eine Art von Patterns auf der „Metaebene“ dar, die bei grundsätzlichen Entwurfsentscheidungen helfen können (siehe Abschnitt 2.3.5). Viele dieser Prinzipien wurden bereits 1975 in dem klassischen Artikel „The Protection of Information in Computersystems“ von Jerome Saltzer und Michael Schroeder beschrieben [96]. Sie finden sich auch in der aktuellen Literatur zum Thema Sicherheit wieder, wie beispielsweise in Büchern zum Thema Firewalls [28,140] oder allgemeinere Werke im Bereich der IT-Sicherheit (siehe z.B. [5], [101] oder [90]). Im Internet sind ebenfalls Dokumente zu finden, die dem Leser auf Basis der klassischen Quelle „Best Security Practices“ näherbringen (siehe [88] und [93]).
5.2 Basisfunktionen In diesem Abschnitt beschreiben wir die in diesem Buch verwendeten grundlegenden Sicherheitsfunktionen, die zur Umsetzung von technischen Gegenmaßnahmen auf den unterschiedlichen Ebenen verwendet werden können. Andere Abschnitte im Buch setzen diese Security Patterns voraus oder spezialisieren sie in einem bestimmten Kontext.
M. Schumacher et al., Hacker Contest © Springer-Verlag Berlin Heidelberg 2003
5.1. Einleitung 163
5.2.1 Identifikation und Authentisierung Auf unterschiedlichsten Ebenen müssen Ressourcen davor geschützt werden, dass sie von einem unberechtigten Objekt verwendet werden können. Daher müssen Maßnahmen getroffen werden, um nachzuweisen, dass ein Objekt tatsächlich die Identität inne hat, die es vorgibt. In diesem Abschnitt stellen wir kurz die grundlegenden Konzepte für diesen Prozess der Identifikation und Authentisierung vor. Dabei werden Unterschiede hinsichtlich des Aufwands und der resultierenden Sicherheit deutlich. Kontext Der Zugang zu IT-Ressourcen ist zunächst physikalisch möglich, d.h., der Benutzer gibt beispielsweise Texte über eine Tastatur ein und liest diese später wieder aus. Er kann Dateninformationen lesen, schreiben und löschen, aber auch periphere Geräte wie beispielsweise Drucker verwenden. Darüber hinaus sind Netzwerkzugriffe möglich, d.h., der Benutzer kann über Netzwerkanwendungen wie z.B. telnet oder ftp auf das System zugreifen. Problem Die Nutzung von Anwendungen und Diensten einer IT-Ressource ist grundsätzlich für alle Benutzer möglich, die wissen, wie auf die IT-Ressource zugegriffen werden kann. Es muss gewährleistet sein, dass nur Benutzer mit einer entsprechenden Berechtigung Zugang zu der IT-Ressource erhalten. Ein Angreifer könnte sonst vertrauliche Informationen finden, verändern oder zerstören. Grundsätzlich muss ein Verfahren zur Authentisierung von Benutzern folgenden sicherheitsrelevanten Anforderungen, die teilweise im Konflikt zueinander stehen, genügen [88]: – Qualität Jedes Authentisierungsschema muss eine gewisse Qualität aufweisen, um Angriffen zu widerstehen. Schwache Verfahren können in der Regel leicht umgangen werden. – Aufwand Der Aufwand für die Authentisierung muss vertretbar sein. Ist die Benutzbarkeit der Verfahren nicht gegeben, kann davon ausgegangen werden, dass versucht wird, den Aufwand zu reduzieren (und damit das Verfahren zu schwächen), oder aber die IT-Ressource wird nur dann genutzt, wenn es sich nicht vermeiden lässt (und damit die Effizienz ihrer Arbeit verringert). Es gibt auch weniger sicherheitsrelevante Anforderungen. So muss sich beispielsweise der Verwaltungsaufwand für den Betreiber einer IT-Ressource in einem vernünftigen Rahmen bewegen. Die passwortbasierte Authentisierung ist sicherlich am
164 5 Basisfunktionen und Sicherheitsprinzipien
einfachsten umzusetzen, bietet dafür aber am wenigsten Sicherheit. Biometrische Verfahren sind dagegen sehr sicher, allerdings ist der Aufwand zur erstmaligen Erfassung der biometrischen Merkmale hoch. Zudem werden für jede IT-Ressource Sensoren zur Abtastung benötigt. Eine wichtige Rolle spielt auch die Skalierbarkeit eines Authentisierungsschemas. Lösung Die IT-Ressource muss daher in der Lage sein herauszufinden, wer der jeweilige Benutzer ist. Dazu muss zunächst eine eindeutige Zuordnung zwischen der Identität des Benutzers und einem eindeutigen Identifizierungsmerkmal erfolgen. In einem zweistufigen Vorgang kann dann die Identität des Benutzers sicher ermittelt werden: 1. Identifikation: Der Benutzer wird anhand des Identifizierungsmerkmals identifiziert (ein Grenzbeamter schaut beispielsweise im Pass nach dem Namen einer Person). 2. Verifikation: Anhand von Authentisierungsinformationen wird die Zuordnung von Identität und Benutzer überprüft (der Grenzbeamte vergleicht das Passbild mit dem Gesicht der Person). Grundsätzlich wird dabei drei Prinzipien der Authentisierung unterschieden: – Etwas, das der Benutzer weiß: Dienstanbieter und Benutzer teilen ein gemeinsames Geheimnis und können so sicherstellen, wer das Gegenüber ist. Passwörter oder PINs sind die am häufigsten verwendeten Vertreter dieser Kategorie. – Etwas, das der Benutzer hat: Es wird eine Zuordnung zwischen einem physikalischen Token und der Identität des Benutzers gemacht. Der Besitzer des Tokens ist berechtigt, eine Ressource zu nutzen. Hierzu gehören beispielsweise Chip- und Magnetkarten. – Etwas, das der Benutzer ist: Hierbei werden unverwechselbare Merkmale des Menschen zur (biometrischen) Authentisierung benutzt. Zu den Verfahren, die dieses Prinzip implementieren, gehören z.B. die Stimmerkennung, Gesichtserkennung, Retina-Abtastungen oder Systeme, die Fingerabdrücke erkennen können. Die Reihenfolge der Konzepte spiegelt auch das erreichbare Sicherheitsniveau wider. Gemeinsame Geheimnisse sind qualitativ unsicherer als physikalische Token, die wiederum schwächer als biometrische Merkmale sind. Besonders starke Formen
5.2. Basisfunktionen 165
der Authentisierung setzen auf eine Kombination von mindestens zwei der beschriebenen Prinzipien, um insgesamt ein höheres Sicherheitsniveau zu erreichen. Abhängigkeiten Theoretisch kann das beschriebene Pattern als intern korrekt bezeichnet werden, falls angenommen wird, dass die jeweiligen Maßnahmen sicher sind. Tatsächlich ist aber jedes der beschriebenen Authentisierungskonzepte an sich wieder angreifbar, so dass sich hier Abhängigkeiten zu weiteren Patterns ergeben. Wir zeigen anhand von Passwörtern, dass ein gemeinsames Geheimnis grundsätzlich immer dafür anfällig ist, dass es erraten werden kann (siehe Security Pattern Passwortqualität). Physikalische Tokens können grundsätzlich immer gestohlen oder gefälscht werden, wobei insbesondere Letzteres mit hohem Aufwand verbunden ist, wenn die Qualität der Tokens hoch ist. Für die Realisierung von Authentisierung mit physikalischen Tokens wird eine Vielzahl von Produkten angeboten. Wir empfehlen, sich bei den jeweiligen Herstellern im Detail zu informieren. Biometrische Merkmale können gefälscht werden, wenn die Qualität der Verifikation schlecht ist. Bei einer Demonstration im Rahmen einer Veranstaltung des Chaos Computer Clubs ist es beispielsweise gelungen, mit einem künstlichen Finger ein Fingerabdrucksystem zu täuschen (siehe [121]). Es ist zudem noch schwieriger, biometrische Merkmale zu missbrauchen 1. Eine gute Übersicht über biometrische Verfahren ist in [12,84] zu finden. 5.2.2 Verschlüsselung Eine grundlegende Bedrohung ist die unbefugte Offenlegung von Informationen. Einem Angreifer soll es nicht gelingen, vertrauliche Informationen unberechtigterweise lesen zu können. Durch die Verschlüsselung von Informationen kann gewährleistet werden, dass nur berechtigte Empfänger die Informationen lesen können. Kontext Es wird über ein unsicheres, öffentliches Netz kommuniziert, oder IT-Ressourcen werden verwendet, die über solche Netze erreichbar sind. Es wird davon ausgegangen, dass Sender und Empfänger über ein gemeinsames Geheimnis und insbesondere entsprechende kryptografische Schlüssel verfügen.
1
Dies läuft auf die Anwendung von Gewalt hinaus. Ein Angreifer könnte einen Benutzer beispielsweise nötigen, sich an einem System zu authentisieren.
166 5 Basisfunktionen und Sicherheitsprinzipien
Problem Es besteht die Gefahr, dass ein Angreifer unberechtigt in den Besitz von Informationen gelangen kann. Er wird versuchen, den Übertragungsweg oder aber die Informationsquelle bzw. -sinke anzugreifen. Eine Angriffsmöglichkeit ist, die Informationen auf dem Übertragungsweg passiv abzufangen. Der Angreifer belauscht dabei den Nachrichtenkanal und hat somit direkten Zugang zu den Informationen. Hat der Angreifer Zugang zu einer IT-Ressource und die dort gespeicherten Informationen sind nicht gegen unbefugten Zugriff geschützt, ist das Lesen von geheimen Informationen ebenfalls möglich. Dies ist insbesondere auch dann der Fall, wenn Speichermedien (oder sogar komplette Systeme, wie etwa ein Laptop) gestohlen werden. Lösung Wenn sich ein Benutzer vor unbefugtem Informationsgewinn schützen will, muss erreicht werden, dass nur bestimmte Personen oder IT-Komponenten Zugriff auf bestimmte Daten haben bzw. diese einsehen können. Dies kann mithilfe von kryptografischen Verfahren zur Ver- und Entschlüsselung sensitiver Informationen realisiert werden. Zunächst wird davon ausgegangen, dass nur Sender und der rechtmäßige Empfänger im Besitz der kryptografischen Schlüssel sind. Außerdem wird angenommen, dass die Funktion e invers zur Funktion d ist, d.h., dass die Entschlüsselung von verschlüsselten Informationen wieder zu dem ursprünglichen Klartext führt. Dieser Vorgang wird in Abbildung 5-1 schematisch dargestellt. Der Sender wendet nun eine Verschlüsselungsfunktion e mit einem kryptografischen Schlüssel k1 an, um die im Klartext vorliegende Information m zu verschlüsseln. Der resultierende Chiffretext c kann nun über den ungesicherten Kanal gesendet werden. Ein Angreifer kann jetzt nicht ohne weiteres die Nachricht mitlesen, da er den Schlüssel zum Dekodieren der Nachricht nicht kennt. Der Empfänger wendet nach Empfang der verschlüsselten Informationen c die Entschlüsselungsfunktion d mit einem kryptografischen Schlüssel k2 an, um die ursprüngliche Information m im Klartext zu erhalten. Das beschriebene Konzept kann auch lokal auf der jeweiligen IT-Ressource angewendet werden. In diesem Fall werden dann verschlüsselte Informationen auf einem Speichermedium abgelegt und zu einem späteren Zeitpunkt, wenn wieder auf die Information zugegriffen werden soll, entschlüsselt. Für einen Angreifer sind damit auch gestohlene Speichermedien wertlos. Bei der Auswahl eines geeigneten Verfahrens zur Verschlüsselung sollte darauf geachtet werden, dass folgende Überlegungen berücksichtigt werden [99]: Bei einem veröffentlichten Algorithmus kann davon ausgegangen werden, dass dieser von vielen Experten analysiert worden ist. Wenn es niemandem gelungen ist, den Algorithmus zu brechen, ist anzunehmen, dass der Algorithmus gut ist und damit ein höheres Maß an Vertrauen rechtfertigt, als ein nichtöffentliches Verfahren, das niemand einschätzen und bewerten kann.
5.2. Basisfunktionen 167
Neben der Stärke des Algorithmus hängt das erreichbare Sicherheitsniveau stark von der Länge der Schlüssel ab. Zwar galt so beispielsweise der amerikanische Data Encyrption Standard (DES) bis heute als sicher, Experten gehen jedoch davon aus, dass in wenigen Jahren, wenn jedermann (d.h. zu erschwinglichen Preisen) eine mehr als ausreichende Rechenkapazität für Brute-Force-Angriffe zur Verfügung steht.
Angreifer
Sender
Empfänger
k1
k2
c m
Verschlüsselung
Entschlüsselung
c = e(m,k1)
m = d(c,k2)
Ungesicherte Übertragung
m
Abb. 5-1 Verschlüsselung und Entschlüsselung
Abhängigkeiten Speziellere Ausprägungen von Verschlüsselungsverfahren sind asymmetrische und symmetrische Verschlüsselungsansätze. Dabei kommen zusätzliche Probleme auf, um die entsprechenden Schlüssel sicher zu erzeugen, aufzubewahren und zu verteilen. Grundlagen zu kryptografischen Verfahren sind in Bruce Schneiers Standardwerk zu finden [99], eine Pattern Sammlung zum Thema Management von kryptografischen Schlüsseln wurde von Lehtonen und Pärssinen veröffentlicht [70]. Die Verschlüsselung von Informationen löst zumindest in der Theorie das Problem des unberechtigten Informationsgewinns. In der Praxis ergeben sich aber auch einige Nachteile bzw. Fallstricke, auf die wir im Folgenden kurz hinweisen wollen. Es sollte nicht vergessen werden, dass es Möglichkeiten gibt, kryptografische Methoden zu umgehen. Ein Angreifer wird beispielsweise kaum versuchen, einen verschlüsselten Kommunikationskanal anzugreifen, wenn er stattdessen leicht Zugang zu einem der Endpunkte erlangen kann, um dort die Informationen direkt im Klartext abzugreifen. Es muss demnach immer berücksichtigt werden, wo Kryptografie schützen kann und wie dieser Schutz durch zusätzliche Maßnahmen ergänzt werden muss. Es muss auch darauf hingewiesen werden, dass selbst als theoretisch sicher angesehene Verschlüsselungsverfahren fehlerhaft implementiert werden können. In die-
168 5 Basisfunktionen und Sicherheitsprinzipien
sem Fall können sich Verletzlichkeiten2 ergeben, die von einem Angreifer ausgenutzt werden können, so dass der vermeintliche Schutz nicht mehr gegeben ist. Die Anwendung von Verschlüsselungstechniken erhöht zudem die Komplexität des Systems und beeinträchtigt möglicherweise die Performanz. Zusätzlich zu den „normalen“ Abläufen kommen nun an bestimmten Stellen zusätzliche bzw. abgeänderte Aufrufe hinzu. Außerdem handelt man sich mit der Lösung eines Problems, also dem Schutz der Vertraulichkeit, ein neues Problem ein: um Informationen verschlüsseln zu können, müssen Protokolle und Verfahren zur Erzeugung, Verwaltung und Verteilung der kryptografischen Schlüssel ausgewählt und integriert werden. Insgesamt sollte im Rahmen einer Risikoanalyse darauf geachtet werden, dass der zusätzliche Aufwand und die zu erfüllenden Randbedingungen für die Verschlüsselung nicht den eigentlichen „Wert“ der Informationen übersteigen. Verschlüsselungsverfahren sind oftmals auch Gegenstand rechtlicher Vorschriften. Insbesondere bei länderübergreifenden verteilten Systemen sollten diesbezüglich die notwendigen Recherchen 3 angestellt werden. 5.2.3 Schutz der Integrität Informationen können durch Angreifer grundsätzlich verändert oder ersetzt werden. Mithilfe von Hash-Funktionen wird daher ein Modification Detection Code (MDC) berechnet, damit Modifikationen vom Empfänger erkannt werden können. Kontext Es wird über ein unsicheres, öffentliches Netz kommuniziert, oder IT-Ressourcen werden verwendet, die über solche Netze erreichbar sind. Der Empfänger möchte sicherstellen, dass die Informationen während der Übertragung nicht verändert oder ersetzt worden sind. Es wird davon ausgegangen, dass Sender und Empfänger über kein gemeinsames Geheimnis und insbesondere keine entsprechenden kryptografischen Schlüssel verfügen. Problem Der Empfänger muss in der Lage sein zu erkennen, ob Informationen nach dem Absenden und vor dem Empfang durch einen Angreifer verändert worden sind. Dabei muss die folgende Anforderung berücksichtigt werden:
2
Im Jahr 2000 warnte das CERT vor Verletzlichkeiten des Authentisierungs- und Verschlüsselungsprotokolls Kerberos [26]. Aufgrund mehrerer Buffer-Overflows konnte ein Angreifer so Administrationsrechte erlangen. Unter bestimmten Umständen war es sogar möglich, die gesamte Kerberos-Domäne zu kompromittieren. 3 In Frankreich ist es beispielsweise ohne Genehmigung nicht ohne weiteres möglich, beliebige kryptografische Algorithmen und Produkte einzusetzen.
5.2. Basisfunktionen 169
– Verhältnismäßigkeit Die günstigste Lösung kann möglicherweise sein, eine Nachricht mehrfach zu senden. Stimmen alle Kopien überein, geht man davon aus, dass die Integrität nicht verletzt worden ist. Eine Lösung darf also nicht aufwändiger als diese Variante sein. – Fälschungssicherheit Es darf nicht möglich sein, dass ein Angreifer den Lösungsansatz imitiert und der Empfänger fälschlicherweise glaubt, korrekte Informationen vorliegen zu haben. – Verifikation Der Empfänger muss anhand von Zusatzinformationen verifizieren können, dass die Nachricht nicht manipuliert worden ist. Lösung Eine Hash-Funktion ist eine mathematische Funktion, die ein Dokument beliebiger Größe auf eine Zeichenkette fester Größe abbildet. Typischerweise sind diese HashWerte signifikant kleiner als das ursprüngliche Dokument. Hash-Funktionen sind Einwegfunktionen, d.h., es ist leicht, den Hash-Wert zu bilden, es ist aber nahezu unmöglich, von dem Hash-Wert auf das ursprüngliche Dokument zu schließen. Weiterhin erfüllen geeignete Hash-Funktionen die Eigenschaft, dass sie kollisionsresistent sind, d.h., es ist sehr unwahrscheinlich, dass zwei Dokumente in dem gleichen Hash-Wert resultieren. Mithilfe einer geeigneten Hash-Funktion, die vorab festgelegt wird, erzeugt der Sender einer Nachricht den MDC. Zusammen mit der Nachricht wird der MDC zu dem Empfänger übertragen. Der Empfänger wiederum berechnet aus dem Dokument ebenfalls den MDC. Stimmen beide MDC überein, so sind die Informationen nicht verändert worden. Weitverbreitete Hash-Funktionen sind MD5 (Message Digest, siehe [92]) und der vom NIST und der NSA entwickelte SHA (Secure Hash Algorithm, siehe [83]). Bei MD5 ist man sich jedoch nicht sicher, ob es nicht erfolgreiche kryptografische Angriffe gibt. Da SHA keine bekannten Verletzlichkeiten aufweist, längere HashWerte liefert und zudem schneller als andere Verfahren arbeitet, wird es von vielen Experten bevorzugt [99]. Abhängigkeiten MDC-basierte Verfahren sichern nur die Integrität der Information, d.h. dass Nachrichten, die von einem Angreifer mit einem entsprechenden MDC versendet werden, durchaus korrekt sind, aber eben nicht von dem regulären Sender. Daher müssen zusätzlich Verfahren zur Identifikation und Authentisierung verwendet werden.
170 5 Basisfunktionen und Sicherheitsprinzipien
Dabei wird ein Hash-Wert von dem Dokument und beispielsweise einem gemeinsamen Geheimnis berechnet. Weiterhin gewährleistet die beschriebene Lösung nicht die Vertraulichkeit der Informationen, d.h., eine Kombination mit dem Security Pattern Verschlüsselung ist sinnvoll. 5.2.4 Identitätsbasierte Zugriffskontrolle In diesem Abschnitt wird das Problem behandelt, dass Ressourcen grundsätzlich gegen unberechtigte Zugriffe geschützt werden müssen. Als Lösung hat sich ein Vermittler bewährt, der bei jeder Interaktion gemäß einer Sicherheitsrichtlinie prüft, ob der Zugriff erlaubt ist oder nicht. Kontext Es wird über ein unsicheres, öffentliches Netz kommuniziert, oder IT-Ressourcen werden verwendet, die über solche Netze erreichbar sind. Es wird davon ausgegangen, dass die Identität der anfragenden Instanz ermittelt worden ist. Problem Grundsätzlich kann eine beliebige Entität auf die Ressourcen einer anderen Entität zugreifen. Die Rolle der zugreifenden Entität wird im Zusammenhang der Zugriffskontrolle allgemein als Subjekt bezeichnet, und die Rolle der Entität, auf die zugegriffen wird, wird allgemein als Objekt bezeichnet. Subjekte, die mit Objekten interagieren, können im Kontext von Betriebssystemen beispielsweise Prozesse sein, die auf Dateien zugreifen; im Kontext von Netzwerken kann dies etwa ein Programm sein, das eine Anfrage an einen Netzwerkdienst sendet. Dabei muss der Zugriff auf Objekte, die dabei benötigt werden, möglich sein. Grundsätzlich ergeben sich daraus folgende Bedrohungen: – Unberechtigter Zugriff auf Ressourcen Es muss allgemein verhindert werden, dass ein Angreifer unberechtigt auf eine Ressource zugreifen kann. Darunter fallen lesende Zugriffe auf Informationen, d.h., ein Angreifer darf auf keinen Fall auf Informationen zugreifen, die nicht für ihn bestimmt sind. Außerdem müssen Zugriffe unterbunden werden, bei denen ein Angreifer versucht, Informationen zu verändern. – Unbeabsichtigte Anfragen Auch unbeabsichtigte Zugriffe von scheinbar regulären Prozessen, Anwendungen, Systemen etc. stellen ein Problem dar. Ohne Absicht kann so durchaus Schaden angerichtet werden, indem beispielsweise versehentlich wichtige Dateien gelöscht werden.
5.2. Basisfunktionen 171
Lösung Die Interaktion zwischen Subjekten und Objekten muss jederzeit kontrolliert werden. Um die Zugriffskontrollfunktion zu realisieren, wird explizit eine Komponente benötigt, die zwischen Subjekt und Objekt vermittelt. Jede Anfrage geht so nicht direkt vom Subjekt zum Objekt, sondern wird zunächst an die Zugriffskontrolle übergeben. Dabei muss anhand eines oder mehrerer Attribute, die mit der aufrufenden Instanz verknüpft sind, festgestellt werden, ob diese gemäß einer Sicherheitspolitik eine entsprechende Berechtigung hat. Typischerweise können dabei folgende Attribute zur Überprüfung herangezogen werden: – Namen Die Identität kann beispielsweise über den Name eines Benutzers ermittelt werden. Auch Anwendungsprogramme können so oder z.B. über TCP-Portnummern identifiziert werden. – Adressen IT-Systeme und Netzwerkknoten werden üblicherweise über Adressen identifiziert wie beispielsweise Ethernet oder IP-Adressen. Dies hat oftmals auch eine topologische Bedeutung, d.h., die Zugriffsentscheidung wird aufgrund des Ortes, an dem eine Interaktion initiiert bzw. beendet worden ist, getroffen. So kann beispielsweise der Zugriff nur von bestimmten Terminals aus zugelassen werden. – Gruppenzugehörigkeit Hiermit ist die Zuordnung einzelner Subjekte zu einer Gruppe, die das Recht für bestimmte Interaktionen hat, möglich. Typisch ist hier beispielsweise die Einteilung von Benutzern nach Funktionen, also etwa Administratoren oder Benutzern. IT-Ressourcen können so z.B. nach Arbeitsplatzrechnern und Servern eingeteilt werden. Falls die aufrufende Instanz berechtigt ist, wird der Zugriff gewährt, andernfalls verweigert, d.h., es kommt typischerweise zu einer Fehlermeldung. Zugriffskontrolle wird auf nahezu allen Ebenen benötigt. Am feingranularsten können Zugriffsentscheidungen auf der Ebene von Anwendungen getroffen werden. Dort existieren Konzepte wie Rollen von Benutzern sowie damit verbundene Interaktionen, die sie zur Wahrnehmung ihrer Aufgaben durchführen können müssen. Weniger granulare Entscheidungen werden auf unteren Ebenen wie beispielsweise den Systemen, Netzen oder sogar auf Hardwareebene getroffen.
172 5 Basisfunktionen und Sicherheitsprinzipien
Abhängigkeiten Eine wichtige Voraussetzung, damit Zugriffskontrolle überhaupt möglich ist, ist die Identifikation und Authentisierung, mit deren Hilfe die Attribute, die für eine Zugriffsentscheidung herangezogen werden, ermittelt werden. Zur Zugriffskontrolle können auch noch allgemeinere Attribute herangezogen werden, die nicht auf der Identität von Subjekt und Objekt basieren. So kann der Zugriff etwa auf einen bestimmten Zeitraum begrenzt werden. Es ist dann beispielsweise nur möglich, zu den regulären Bürozeiten, nicht aber am Wochenende und an Feiertagen, bestimmte Ressourcen zu nutzen. Um ein Maximum an Sicherheit zu erreichen, empfiehlt es sich, dass bei der Vergabe der Zugriffsrechte nur die unbedingt benötigten Rechte vergeben werden (siehe Security Pattern Minimale Privilegien). Da zu den herkömmlichen Zeiten für die Verarbeitung einer Anfrage eines Subjekts an ein Objekt nun noch die Überprüfung der Rechte hinzukommt, ist evtl. mit Einbußen hinsichtlich der Performanz zu rechnen. Dies hängt stark von dem verwendeten Verfahren zur Zugriffskontrolle ab. Bei besonders hohem Schutzbedarf kann Zugriffskontrolle auch mit Verfahren zur Verschlüsselung ergänzt werden. Nur wer in Besitz der entsprechenden kryptografischen Schlüssel ist, kann auf bestimmte Informationen zugreifen. Verschiedene Security Patterns zum Thema Zugriffskontrolle wurden von Fernandez veröffentlicht [48]. Dort werden insbesondere die Struktur allgemeiner Zugriffskontrollregeln, die Zugriffskontrollmatrix, rollenbasierte Zugriffskontrolle sowie Zugriffskonzepte in Umgebungen, in denen es klassifizierte Daten gibt, behandelt. Außerdem wird ein Security Pattern für die Zugriffskontrolle auf Dateien beschrieben. 5.2.5 Audit Angriffe auf IT-Ressourcen bleiben unentdeckt, wenn es keine Möglichkeit gibt, Unregelmäßigkeiten im Betrieb festzustellen. Dies liegt oftmals daran, dass Systemlogs ausgeschaltet sind oder nicht konsequent überwacht werden. Nur wenn Aktionen zu Benutzern zugeordnet werden können, ist es möglich, unbekannte Systemzustände zu erkennen und entsprechend zu reagieren. Kontext Es wird über ein Netz kommuniziert, oder IT-Ressourcen werden verwendet, die über solche Netze erreichbar sind. Problem Grundsätzlich sollen Benutzer für ihre Aktionen in einer IT-Umgebung verantwortlich gemacht werden können. Nur so ist es möglich herauszufinden, ob sich alle an die Vorschriften eines Unternehmens gehalten haben. Ein Beispiel hierfür ist die private Nutzung von IT-Ressourcen während der Arbeitszeiten: Das Versenden und
5.2. Basisfunktionen 173
Empfangen privater E-Mails ist oftmals untersagt, Zuwiderhandlungen können unter Umständen mit einer Abmahnung geahndet werden. Folgende Bedrohungen treten in diesem Zusammenhang auf: – Täuschung Es ist wünschenswert, wenn eine Täuschung durch einen Benutzer festgestellt werden kann. Ein Beispiel hierfür ist das Abstreiten einer Aktion, wenn ein Benutzer leugnet, eine bestimmte Nachricht gesendet oder empfangen zu haben. Auch in diesem Fall sollte es möglich sein, den Initiator einer Aktion im System zu ermitteln. – Missbrauch Es muss möglich sein, einen Angriff als solchen erkennen zu können. Kann eine Unterscheidung zwischen normalen Aktionen und Angriffen nicht getroffen werden, kommt es ebenfalls zum Verlust der Zurechenbarkeit. In diesem Fall ist eine angemessene Reaktion nicht mehr möglich. Lösung Um einen Verlust der Zurechenbarkeit zu verhindern, müssen Zeit, Herkunft und andere wichtige Eigenschaften einer Aktion erfasst werden. Ein solches „Auditing“ oder „Logging“ kann grundsätzlich verschiedene Auswirkungen haben: – Abschreckung Angriffe werden verhindert, da der Angreifer vom Audit abgeschreckt wird, d.h., das Risiko, entdeckt zu werden, wird als zu hoch eingeschätzt. – Reaktion Findet ein Angriff statt und kann dies aufgrund von Audit-Informationen erkannt werden, ist es möglich, angemessen zu reagieren. So kann beispielsweise ein Alarm ausgelöst oder eine automatische Reaktion (etwa das Sperren einer Benutzerkennung) ausgelöst werden. – Rekonstruktion Schließlich können Angriffe rekonstruiert werden, sofern der Angreifer seine Spuren nicht verwischt hat. Nach einem Angriff kann also möglicherweise herausgefunden werden, was genau passiert ist. Idealerweise werden die Ursachen identifiziert und die Sicherheitslücken geschlossen. Die Zurechenbarkeit von Aktionen zu Benutzern erfordert die Einhaltung einiger Randbedingungen. Außerdem müssen je nach Situation einige Entscheidungen getroffen werden. Zunächst müssen die Audit-Mechanismen in den IT-Systemen aktiviert werden. Standardmäßig sind solche Mechanismen oft abgeschaltet oder unzu-
174 5 Basisfunktionen und Sicherheitsprinzipien
reichend konfiguriert. Weiterhin muss darauf geachtet werden, dass die LogInformationen ausreichend gegen Manipulationen geschützt sind. Nun muss entschieden werden, welche Informationen überhaupt erfasst werden sollen. Dazu gehören beispielsweise Lese- und Schreibzugriffe auf sensitive Daten, (erfolgreiche und missglückte) Anmeldeversuche am System oder jeder Boot-Vorgang eines Systems. Im Zweifelsfall sollte lieber zu viel Information erhoben werden als zu wenig. Nur so können die wichtigen Eigenschaften eines Angriffs erkannt werden. Wichtig ist auch die Repräsentation der Audit-Informationen. Die Struktur der Meldungen sollte möglichst einheitlich sein und wohldefinierte, aussagekräftige Einträge enthalten. Eine automatisierte Bearbeitung der Informationen wird so erheblich erleichtert. Schließlich muss noch entschieden werden, ob zentrales oder dezentrales Logging durchgeführt wird. Der wesentliche Vorteil von zentralem Logging ist, dass alle Informationen an einer Stelle zusammenlaufen, so dass die Analysen vereinfacht werden. Andererseits führt dies möglicherweise zu einem Schwachpunkt: Gelingt es einem Angreifer, den zentralen Log-Server zu knacken, kann er beliebig Informationen manipulieren oder löschen. Ein solcher Log-Server muss also besonders gut geschützt werden. Außerdem muss gewährleistet sein, dass die LogInformationen sicher übertragen werden können. Bei dezentralem Logging sind Manipulationen für einen Angreifer schwerer durchzuführen, da er nun Zugang zu mehreren Systemen haben muss. Genauso wird aber auch die Auswertung der LogInformationen erschwert. Die Auswertungen von Audit-Informationen ist umso präziser, je mehr Informationen erhoben werden. Wird allerdings zu viel Information gespeichert, kann sich dies negativ auf die Performanz auswirken. Um zu verhindern, dass das Auditing vom Systemadministrator wieder deaktiviert wird, muss gewährleistet sein, dass Benutzer nicht spürbar von einem Audit-Mechanismus beeinträchtigt werden. Wir möchten auch darauf hinweisen, dass die Forderung nach Zurechenbarkeit im Widerspruch zu datenschutzrechtlichen Aspekten stehen kann. Ein Unternehmen darf nicht völlig beliebige Informationen über das Verhalten der Mitarbeiter erheben, um diese zu überwachen. 5.2.6 Zusammenfassung Die einzelnen zuvor beschriebenen Security Patterns können nun im Zusammenhang als Security Pattern-System, wie in Abbildung 5-2 gezeigt, dargestellt werden. Sie bilden auf der Metaebene die Grundlage für die grundlegenden Techniken zum Schutz gegen Bedrohungen. Zu Referenzzwecken fassen wir diese Security Patterns im Folgenden zusammen: – Identifikation und Authentisierung Es muss gewährleistet sein, dass nur Benutzer mit einer entsprechenden Berechtigung Zugang zu der IT-Ressource erhalten. In einem zweistufigen Vorgang
5.2. Basisfunktionen 175
muss daher die Identität einer anfragenden Entität auf Basis von gemeinsamen Geheimnissen, physikalischen Tokens oder biometrischen Merkmalen ermittelt werden. – Verschlüsselung Bei der Speicherung oder Übertragung von Informationen ist die Vertraulichkeit gefährdet, wenn Unbefugte Zugriff auf die Informationen erhalten können. Eine bewährte Lösung ist die Verschlüsselung der entsprechenden Informationen mit geeigneten kryptografischen Verfahren. – Schutz der Integrität Es muss erkannt werden, ob Informationen nach dem Absenden und vor dem Empfang durch einen Angreifer verändert worden sind. Daher sollte eine geeignete Einweg-Hash-Funktion vereinbart werden, mit der ein Hash-Wert berechnet werden kann, der mit den Informationen versendet wird. Beim Empfang wird ebenfalls ein Hash-Wert berechnet. Stimmen beide Werte überein, so wurden die Informationen nicht verändert. – Identitätsbasierte Zugriffskontrolle Der unberechtigte sowie unbeabsichtigte Zugriff auf IT-Ressourcen muss verhindert werden. Daher muss anhand eines oder mehrerer identitätsbasierter Attribute, die mit der aufrufenden Instanz verknüpft sind, festgestellt werden, ob diese gemäß einer Sicherheitspolitik eine entsprechende Berechtigung haben. Daraus ergibt sich eine Anhängigkeit zu dem Security Pattern Identifikation und Authentisierung. Bei höherem Schutzbedarf ist eine zusätzliche Verschlüsselung der Informationen sinnvoll. – Audit Grundsätzlich sollen Benutzer für ihre Aktionen in einer IT-Umgebung verantwortlich gemacht werden können. Außerdem muss es möglich sein, potenzielle Angriffe erkennen zu können. Um einen Verlust der Zurechenbarkeit zu verhindern, müssen Zeit, Herkunft und andere wichtige Eigenschaften einer Aktion erfasst werden.
176 5 Basisfunktionen und Sicherheitsprinzipien
Basisfunktionen
Identifikation und Authentisierung
Audit Schutz der Integrität
Verschlüsselung
Identitätsbasierte Zugriffskontrolle
Abb. 5-2 Basisfunktionen auf der Metaebene
5.3 Sicherheitsprinzipien In diesem Abschnitt werden einige weniger technische Sicherheitsprinzipien beschrieben, die sich als Stand der Kunst beim Entwurf sicherer IT-Ressourcen bewährt haben. Werden diese Prinzipien nicht berücksichtigt, steigt die Wahrscheinlichkeit, dass das resultierende System Verletzlichkeiten aufweisen wird. Die folgenden Security Patterns werden möglichst generisch beschrieben, also unabhängig davon, ob sie beispielsweise auf Netzwerkebene angewendet werden. Daher wird ein gemeinsamer Kontext angenommen: Beim Entwurfsprozess muss der Systemarchitekt verschiedene strategische Entscheidungen treffen, wie Sicherheit grundsätzlich erreicht und durchgesetzt werden soll. Dieser Kontext muss dann für Ebenen auf niedrigerem Abstraktionsniveau konkretisiert werden. Da dieser Kontext bei allen Security Patterns vorkommt, wird er bei den einzelnen nachfolgenden Abschnitten nicht mehr explizit aufgeführt. Wie bei Security Patterns auf der Metaebene üblich, treten nur bedingt Abhängigkeiten zu anderen Security Patterns auf. 5.3.1 Konservative Vorgehensweise Vertrauen in eine Ressource besteht dann, wenn der Benutzer sicher sein kann, dass sich die Ressource erwartungsgemäß verhält [107]. Ändern sich die Interna der Ressource oder aber deren Umgebung ständig, wird es schwierig, Vertrauen aufzubauen. Vom Standpunkt der IT-Sicherheit ist eine konservative Vorgehensweise bei der Auswahl und Kombination von IT-Ressourcen und Komponenten gegenüber ständigen Erneuerungen und Erweiterungen zu bevorzugen.
5.3. Sicherheitsprinzipien 177
Problem Neue Systeme und Komponenten oder aber auch Erweiterungen weisen grundsätzlich keine bekannten Verletzlichkeiten auf. Es ist aber nur eine Frage der Zeit, bis jemand vorhandene Verletzlichkeiten aufdeckt. Es ist a priori nur schwer abschätzbar, welche Folgen dies haben kann. Neue Systeme sind unbekannt und nicht so gut verstanden, wie ein System, das schon einige Zeit auf dem Markt ist. „Neu“ ist damit keinesfalls mit „sicher“ gleichzusetzen. Neben neuen Versionen bieten Hersteller typischerweise auch Sicherheits-Updates bzw. -Patches an, wenn Verletzlichkeiten bekannt werden. Auch hier ist Vorsicht geboten, da dies mit einer Änderung des Systems gleichzusetzen ist und durchaus zu zusätzlichen Verletzlichkeiten führen kann. Lösung Die Lösung für dieses Problem spiegelt den eigentlichen Ansatz von Security Patterns sehr gut wider. Um Sicherheit erreichen zu können, ist eine konservative Vorgehensweise empfehlenswert, d.h., es sollte auf Lösungen und Produkte zurückgegriffen werden, die sich bewährt haben. Sicherheit braucht Zeit. Aufgrund der Komplexität moderner verteilter Systeme kann kaum davon ausgegangen werden, dass im Vorfeld alle Möglichkeiten, die zu einer Verletzlichkeit führen, bedacht werden können. Erst nach einem bestimmten Zeitraum, wenn Erfahrungen mit dem System in bestimmten Umgebungen gesammelt werden konnten, werden auch Verletzlichkeiten aufgedeckt, die vorher nicht berücksichtigt wurden. Hat sich ein System über einen bestimmten Zeitraum gegen bekannte Angriffe als sicher erwiesen, ist es gegenüber einem neuen, unbekannten System zu bevorzugen. Es sollte auch überlegt werden, ob bestimmte neue Funktionalitäten überhaupt benötigt werden. Möglicherweise reicht der vorhandene Funktionsumfang völlig aus. Ist dies der Fall, sollte auf ein neues System bzw. eine Erweiterung verzichtet werden. Genauso sollten Funktionen, die nicht benötigt werden, unbedingt abgeschaltet werden: Etwas, das nicht da ist, kann auch nicht missbraucht werden. Schließlich möchten wir noch darauf hinweisen, dass auch bei Sicherheits-Patches ein konservatives Vorgehen angebracht ist. Es sollte zunächst geklärt werden, ob das eigene System überhaupt betroffen, d.h., die entsprechende Funktion überhaupt aktiviert ist. Falls ja, ist es möglicherweise sinnvoll, erst einmal abzuwarten, welche Erfahrungen andere Benutzer mit dem Update gemacht haben 4. Bei einer konservativen Vorgehensweise gewinnt man Sicherheit, wenn folgende Aspekte beachtet werden: Manchmal ist das Update auf neue Produkte unumgänglich, insbesondere dann, wenn ein Hersteller keinen Support mehr anbietet. Wartet
4
So hat beispielsweise der Servicepack 6 für Microsoft Windows NT 4.0 die Kommunikation über die TCP/IP-Ports gestört. In diesem Fall war sinnvoll, Reaktionen abzuwarten, um dann gleich den Servicepack 6a zu installieren.
178 5 Basisfunktionen und Sicherheitsprinzipien
man zu lange, bis ein Sicherheits-Update eingespielt wird, ist das System angreifbar, und es kommt möglicherweise zu einem Schaden. Die Entscheidung könnte daher von der Dringlichkeit des Problems abhängig gemacht werden: Bei eher unbedeutenden Verletzlichkeiten kann länger gewartet werden. 5.3.2 Einfachheit Komplexität ist der größte Feind von Sicherheit [101]. Daher sollte das viel zitierte „Kiss“-Mantra (engl. Abkürzung für „Keep it simple, stupid!“) insbesondere bei dem Entwurf sicherer Systeme berücksichtigt werden [75]. Problem Menschen machen in komplexen Situationen früher oder später Fehler [41]. Der Entwurf, der Betrieb und die Nutzung von modernen Systemen können schnell zu Situationen führen, in denen die menschlichen Fähigkeiten an ihre Grenzen geraten. Werden rein funktionale Probleme noch vergleichsweise leicht erkannt, können sich bestimmte Entscheidungen fatal auf die Sicherheit auswirken. Es kann auch passieren, dass sicherheitsrelevante Entscheidungen gar nicht getroffen werden, weil das Problem aufgrund der hohen Komplexität nicht erkannt worden ist. Werden mehrere Systeme zu einem größeren, verteilten Gesamtsystem zusammengeführt, erhöht sich die Komplexität nochmals. Das Gesamtsystem wird immer intransparenter und verändert sich möglicherweise dynamisch, so dass gar keine Chance besteht, sich einen genauen Überblick über das System zu verschaffen. Lösung Sichere Systeme sollten so einfach wie möglich sein, denn jede überflüssige Funktion birgt zusätzliche potenzielle Risiken in sich. Es sollte daher von Anfang an kritisch hinterfragt werden, welchen Anforderungen ein System genügen muss. Nur wirklich notwendige Eigenschaften sollten dann auch in das Pflichten- bzw. Anforderungsheft aufgenommen werden. Ein weiterer Punkt ist, dass Menschen die Systeme verstehen müssen. Die Systeme sollten daher so durchschaubar wie möglich sein. Schon bei der Entwicklung muss daher darauf geachtet werden, dass z.B. Programmierrichtlinien aufgestellt und eingehalten werden. Außerdem ist die Anwendung von systematischen Entwurfsmethoden (wie beispielsweise der Rational Unified Process [132]) ratsam, da dies zu einem klaren Konzept führt, das zudem auch ordentlich dokumentiert ist. Auch bei zugekauften Systemen gilt, dass überprüft werden sollte, ob wirklich alle Komponenten benötigt werden und ob die Dokumentation des Systems ausreichend ist. Nach Möglichkeit sind auch Komponenten, die sich bereits als sicher bewährt haben, wiederzuverwenden. Auf diese Weise können zumindest Teile des (neuen) Systems besser eingeschätzt und die Komplexität damit reduziert werden.
5.3. Sicherheitsprinzipien 179
Einfache Systeme sind leichter zu beherrschen und damit besser abzusichern. Allerdings muss auch davon ausgegangen werden, dass zukünftige Systeme immer komplexer werden, so dass die Forderung nach Einfachheit zwar oberstes Ziel bleiben sollte, aber nicht immer realisiert werden kann. 5.3.3 Absicherung der schwächsten Stellen Oft wird in Sicherheitskreisen die Analogie gebraucht, das es Sicherheit mit einer Kette vergleichbar ist. Ein System ist damit nur so sicher wie das schwächste Kettenglied. In einem kontinuierlichen Prozess müssen daher die schwachen Kettenglieder identifiziert und entsprechend geschützt werden. Problem Angreifer folgen dem Prinzip des geringsten Widerstands [90]. Es muss demnach davon ausgegangen werden, dass ein Angreifer alle Möglichkeiten ausschöpfen wird. Möglicherweise wird er weder den naheliegendsten Weg wählen noch den, der am besten geschützt ist. Das bedeutet, dass ein Angreifer nicht die gut geschützten Teile eines Systems angreifen wird, sondern sich vielmehr auf die am schwächsten abgesicherten Komponenten konzentrieren wird. So wird beispielsweise im „richtigen“ Leben kein Einbrecher versuchen, durch eine mit mehreren Schlössern abgesicherte Tür einzudringen, wenn er stattdessen einfach eine Scheibe einschlagen oder sogar noch besser durch die Hintertür gehen kann. Genauso konzentrieren sich Angriffe aus dem Internet selten auf eine gut konfigurierte Firewall. Es ist oftmals viel leichter, indirekte Wege einzuschlagen. Ein Angreifer könnte z.B. versuchen, interne Mitarbeiter mithilfe von fingierten E-Mails oder Telefonanrufen zu täuschen und zu bestimmten Aktionen zu veranlassen. In einer solchen E-Mail könnte dazu aufgefordert werden, dass aufgrund von Systemarbeiten das Passwort auf einen bestimmten Wert gesetzt werden muss. In ähnlicher Weise wird kaum ein Angreifer versuchen, mit SSL verschlüsselten Datenverkehr zu knacken – selbst dann, wenn eher schwache Algorithmen bzw. Schlüssellängen verwendet werden. Es dürfte leichter sein, einen der Endpunkte anzugreifen, um so direkt an die gewünschten Informationen zu gelangen. Lösung Schwache Glieder in der Sicherheitskette müssen erkannt und abgesichert werden. Sind die Risiken für einzelne Komponenten bekannt, müssen angemessene Maßnahmen getroffen werden. Dies kann nur mit einem kontinuierlichen Prozess erreicht werden, da Sicherheit nicht dauerhaft gewährleistet werden kann. Es muss immer wieder hinterfragt werden, ob die Maßnahmen noch ausreichen oder ob sich neue Angriffsmöglichkeiten ergeben haben, weil beispielsweise ein bestimmter Algorithmus oder aber ein konkretes Produkt nicht mehr sicher ist.
180 5 Basisfunktionen und Sicherheitsprinzipien
5.3.4 Mehrschichtige Verteidigung Oftmals hängen Entscheidungsträger dem Irrglauben an, sie seien sicher, da im Unternehmen eine Firewall eingesetzt wird [43]. Ein talentierter Angreifer könnte jedoch beispielsweise mit einer E-Mail einen Trojaner versenden und so versuchen, die Firewall zu umgehen. In diesen und vergleichbaren Situationen ist es besser, sich nicht auf eine einzige Schutzmaßnahme zu verlassen, sondern eine mehrschichtige Verteidigung aufzubauen. Problem Moderne verteilte Anwendungen bestehen aus verschiedenen Komponenten auf den unterschiedlichsten Ebenen. Daher sind sie auch von vielen verschiedenen Wegen aus angreifbar. Datenobjekte im Hauptspeicher, Dateien, Prozesse, Geräte oder Kommunikationsverbindungen – all das (und mehr) sind mögliche Ziele für einen Angreifer. Eines der Kernprobleme ist es, dass oftmals Komponenten in einem Netzwerk verbunden werden, die zunächst allein stehend entwickelt worden sind. Diese Komponenten weisen dann naturgemäß keinen zusätzlichen Schutz gegen netzwerkbasierte Angriffe auf. Umgekehrt können Netzwerkomponenten aufgrund von Verletzlichkeiten auf Anwendungs- oder Systemebene bei einem Angriff in Mitleidenschaft gezogen werden. Wenn eine einzige Komponente des gesamten Systems erfolgreich angegriffen werden kann, betrifft dies im schlimmsten Fall alle anderen Komponenten. Lösung Eine einzelne IT-Ressource darf die Sicherheit einer übergeordneten IT-Umgebung nicht gefährden. Daher sollten mehrere Sicherheitsmechanismen und -maßnahmen eingesetzt werden, die sich gegenseitig ergänzen oder absichern. Die Hürde muss für einen anzunehmenden Angreifer mit den vertretbaren Mitteln so hoch wie möglich gelegt werden. Ein Beispiel für das Prinzip der mehrschichtigen Verteidigung ist der Einsatz und die Kombination von verschiedenen Konzepten auf der Netzwerkebene. Mithilfe von Paketfiltern, Proxies, Netzwerkadressumsetzung, Virenscannern (auf Netzwerk- und Systemebene) und Intrusion Detection-Systemen können wirkungsvolle Schutzkonzepte auf der Netzwerkebene aufgebaut werden. Auf Systemebene sind gehärtete Betriebssysteme sowie eine gewissenhafte Installation und Konfiguration wichtige Voraussetzungen für den sicheren Betrieb. Auf Anwendungsebene spielen sichere Programmiertechniken und die Auswahl der richtigen Anwendungen eine wesentliche Rolle. Die Vorteile der mehrschichtigen Verteidigung liegen auf der Hand: Das Gefahrenpotenzial für das Gesamtsystem wird reduziert. Wird eine Komponente attackiert, bleiben die Auswirkungen des Angriffs in lokalen Grenzen. Als Nachteil für mehr Sicherheit erkauft man sich aber eine höhere Komplexität des Gesamtsystems,
5.3. Sicherheitsprinzipien 181
mehr Administrationsaufwand und höhere Kosten, da insgesamt mehr Komponenten eingesetzt werden müssen. Außerdem kann sich dies auf die Performanz des Gesamtsystems auswirken. Es muss im Rahmen einer Risikoanalyse entschieden werden, wie weit die mehrschichtige Verteidigung getrieben wird. Den Aufwendungen für die Implementierung eines Sicherheitskonzeptes müssen zu dem erwarteten Schaden in einem vertretbaren Verhältnis stehen. 5.3.5 Passierstelle IT-Sicherheit kann nur erreicht werden, wenn Daten- und Informationsflüsse bekannt sind und kontrolliert werden können. Auf Netzwerkebene werden beispielsweise Firewalls verwendet, um den gesamten Netzwerkverkehr durch eine Passierstelle zu lenken. Dort wird dann, entsprechend vorher festgelegter Sicherheitsrichtlinien, pro Paket entschieden, ob der Zugang gewährt oder abgelehnt wird. Problem Grundsätzlich sollen auf allen Ebenen nur Interaktionen erlaubt werden, die gemäß der geltenden Sicherheitsregeln erlaubt sind. Es muss gewährleistet sein, dass feindselige Instanzen keine Möglichkeiten haben, unberechtigterweise mit den eigenen Ressourcen zu interagieren. Dies wird allerdings umso schwieriger, je mehr Zugänge es zu einem System es gibt. Wenn Sicherheit an vielen verschiedenen Stellen, im schlimmsten Fall von jeder Komponente selbst verwaltet und kontrolliert wird, nimmt zudem der Aufwand für Verwaltung und Abgleich von Sicherheitsinformationen zu. In diesem Fall kann es auch sein, dass auf dem Informationspfad bestimmte Sicherheitsanforderungen schlecht oder gar nicht erfüllt werden können. Insgesamt können so Sicherheitslücken entstehen, die die Sicherheit des Gesamtsystems gefährden. Lösung Der Einsatz einer Passierstelle erzwingt Anwendungsaufrufe, Netzwerkpakete etc. in einen einzigen kontrollierbaren Kanal, der leicht überwacht und kontrolliert werden kann. Dieses Prinzip findet sich auch in der realen Welt oft wieder, wie beispielsweise bei Kassen in Supermärkten oder aber bei Passkontrollen an Flughäfen. In Abbildung 5-3 wird als konzeptionelles Modell einer Passierstelle ein Referenzmonitor5 dargestellt (siehe z.B. [5]). Der Referenzmonitor ist eine Komponente des Systems, die unterschiedliche Sicherheitsanforderungen umsetzen kann. Er ist bei allen Anfragen beteiligt und schützt somit das System vor unberechtigten Zugriffen.
5
Der Begriff des Referenzmonitors kommt ursprünglich aus der Welt der Betriebssysteme, die oftmals als Monitor bezeichnet worden sind.
182 5 Basisfunktionen und Sicherheitsprinzipien
Anfrage
Referenzmonitor
Erlaube Anfrage
Verbiete Anfrage Abb. 5-3 Modell einer Passierstelle: Referenzmonitor
Konsequenzen Die Verwendung einer Passierstelle führt zu einer effizienteren Verwaltung der Benutzer und des Zugriffs auf Informationen, da nicht mehr jede einzelne Komponente die Zugriffskontrolle durchführen muss. So ist es auch möglich, eine gemeinsame Menge von Technologien und Standards für alle Sicherheitsdienste zu verwenden. Die gesamte Sicherheitsarchitektur wird durchschaubar und nachvollziehbar. Die Anwendungen bzw. Systeme müssen jedoch möglicherweise angepasst werden, damit sie weiterhin uneingeschränkt funktionieren. Die Konfiguration eines Browsers muss beispielsweise so geändert werden, dass ein Proxy verwendet wird. Es kann auch notwendig sein, dass sich die Benutzer anders verhalten müssen, etwa indem sie sich zuerst bei einem Proxy anmelden müssen, bevor sie Zugang zum Internet erhalten. Wird eine Passierstelle eingesetzt, müssen zudem alle Informationen, die für entsprechende Zugriffskontrollentscheidungen erforderlich sind, vorliegen – selbst dann, wenn sie nicht für die aktuelle Anfrage benötigt werden. So muss beispielsweise unbedingt die Identität eines Benutzers bekannt sein. Passierstellen können nur dann wirkungsvoll eingesetzt werden, wenn sie wirklich bei allen Anfragen beteiligt sind. Installiert jedoch ein Benutzer z.B. ein Modem, so kann er eine Firewall leicht umgehen, und die angestrebte Sicherheit ist nicht mehr gewährleistet. Abhängigkeiten Die wichtigste Information, auf die eine Passierstelle zugreifen muss, ist die Identität des Anfragenden. Daher besteht hier eine Abhängigkeit zur Sicherheitsfunktion Identifikation und Authentisierung. Darüber hinaus wird die Identitätsbasierte Zugriffskontrolle idealerweise in der Passierstelle implementiert, so dass auch hier eine Abhängigkeit besteht. Um sicherzustellen, dass niemand versucht, die Passierstelle zu umgehen, sollte zudem das Security Pattern Audit angewendet werden. Idealerweise wird in einer Passierstelle das Prinzip Sicherheit als Standardverhalten umgesetzt, d.h., wenn die Komponente gestört ist oder ausfällt, soll keine Anfrage mehr erlaubt werden.
5.3. Sicherheitsprinzipien 183
5.3.6 Sicherheit als Standardverhalten Bestimmte Secure Shell(ssh)-Implementierungen werden auf den unsicheren rlogin/rsh-Modus zurückgesetzt, wenn eine der kommunizierenden Anwendungen zwar kein ssh, wohl aber rlogin/rsh unterstützt. Diese Konfiguration hat gewissermaßen Unsicherheit als Standardverhalten. Wird ssh beispielsweise in einer durch Skripte automatisierten Umgebung eingesetzt, wird es dem Benutzer möglicherweise nicht einmal auffallen, dass die angedachte Sicherheit nicht mehr vorhanden ist. Problem Aufgrund bestimmter Umstände, wie beispielsweise gezielte Angriffe oder eher zufällige Fehler, kann die Sicherheit einer IT-Ressource gefährdet werden. In diesem Fall darf dies nicht zu weniger Sicherheit führen. Die Sicherheit des Systems sollte im Falle eines (erfolgreichen) Angriffs unbedingt zunehmen. Eine mögliche Folge unsicheren Standardverhaltens ist die Erweiterung von Rechten eines Benutzers aufgrund falscher oder nicht vorhandener Fehlerbehandlungsroutinen. Fehlerhafte Maßnahmen können aber auch zu einem Denial-of-Service-Angriff äquivalente Folgen haben: Das System schaltet sich in diesem Fall ab und ist auch für reguläre Benutzer nicht mehr zugänglich. Wie oben dargestellt, kann das unbemerkte Fehlschlagen einer Maßnahme dazu führen, dass der Administrator bzw. der Benutzer nichts von dem Problem mitbekommt und sich das System in einem unsicheren Zustand befindet. Lösung IT-Systeme sollten Sicherheit als Standardverhalten aufweisen. Wenn eine einzelne Komponente angegriffen wird, soll das System bei Problemen sicherer und keinesfalls unsicherer werden. Das Prinzip der Sicherheit als Standardverhalten findet sich in vielen technischen Systemen wieder. Wenn beispielsweise die Verifikation PINEingabe eines Mobiltelefons nicht mehr funktioniert, sollte es (außer den Notrufnummern) nicht möglich sein, das Gerät zu verwenden. Und wenn das kryptografische Modul der E-Mail-Anwendung ausfällt, sollten keine Nachrichten im Klartext versendet werden. Im Zweifelsfall ist es immer besser, den Zugang und die Rechte einzuschränken, als einen Angreifer ungehindert agieren zu lassen. Im Fall von vermeintlichen Falschmeldungen (engl. „False Positives“) werden nämlich auch berechtigte Benutzer in Mitleidenschaft gezogen. Es kann dann davon ausgegangen werden, dass ein zu restriktiv konfiguriertes System – sofern möglich – nicht mehr benutzt wird.
184 5 Basisfunktionen und Sicherheitsprinzipien
Abhängigkeiten Es empfiehlt sich daher ebenfalls, das Auftreten von Problemen zu protokollieren und ggf. eine Alarmierung des Benutzers oder Administrators auszulösen (siehe Security Pattern Audit). 5.3.7 Vielfalt 1999 hat sich der Makro-Virus Melissa über die E-Mail-Software Microsoft Outlook verbreitet und einen enormen volkswirtschaftlichen Schaden angerichtet. Dies konnte u.a. deshalb passieren, da die meisten Unternehmen die gleiche E-Mail-Software verwendet haben. Problem Aus Effizienzgründen erscheint es oftmals sinnvoll, IT-Ressourcen gleichen Typs zu verwenden. Die Verwaltung und Administration solcher „Monokulturen“ kann beispielsweise leichter automatisiert werden. Außerdem müssen sich Administratoren und Anwender nur in einem Umfeld sehr gut auskennen, breite Hintergrundkenntnisse sind nicht notwendig. Diese Vorgehensweise führt zu folgenden Problemen: – Schadenspotenzial Werden IT-Ressourcen des gleichen Typs verwendet, so kann ein Angreifer, der weiß, wie in eine dieser IT-Ressourcen eingedrungen werden kann, möglicherweise auch alle anderen Systeme erfolgreich angreifen. Ein Angreifer hat damit den gleichen Gewinn an Effizienz wie der Eigentümer einer IT-Ressource bei der Verwaltung und Administration. – Konfigurationsfehler Werden IT-Ressourcen gleichen Typs zentral konfiguriert, kann davon ausgegangen werden, dass Konfigurationsfehler in allen IT-Ressourcen gleichermaßen auftreten. – Implementierungsfehler Gleiches gilt für einen Fehler in der Implementierung, dessen Folgen sich sofort auf alle IT-Ressourcen gleichen Typs auswirken.
5.3. Sicherheitsprinzipien 185
In einem CERT Advisory wurde beispielsweise von einer Verletzlichkeit 6 des Webservers Apache, der einen Marktanteil von über 50% hat, berichtet [27]. Betroffen sind demnach eine Vielzahl der installierten Server (Version 1.3 bis 1.3.24 und Version 2 bis 2.0.36). Bei den älteren Versionen erlaubt dies einem Angreifer, beliebige Programme auf dem betroffenen System auszuführen, bei der neuen Software kommt es zu einem Denial-of-Service. Insbesondere bei IT-Ressourcen, die zur Implementierung von Schutzmaßnahmen hat dies fatale Folgen. Werden beispielsweise mehrere Paketfilter nacheinander aufgebaut, um eine Mehrschichtige Verteidigung aufzubauen, hat ein Angreifer leichtes Spiel. Hat er eine fundamentale Verletzlichkeit entdeckt, kann er alle Verteidigungslinien durchbrechen, und der vermeintliche Schutz ist nicht mehr gegeben. Lösung Es muss verhindert werden, dass ein Implementierungsfehler oder eine Fehlkonfiguration einer IT-Ressource die Sicherheit der gesamten IT-Umgebung gefährdet. Daher sollten insbesondere bei der Umsetzung von Schutzmaßnahmen IT-Ressourcen unterschiedlichen Typs verwendet werden. Anschaulich wird dies bei der Benutzerauthentisierung mit Passwörtern. Passwörter stellen eine Maßnahme zum Schutz von IT-Ressourcen dar und sind selbst Ressourcen, die angegriffen werden können. Typischerweise haben Benutzer Zugang zu verschiedenen IT-Ressourcen wie beispielsweise zu Online-Banking, Bürorechner und der private Computer zu Hause. Idealerweise werden dabei unterschiedliche Passwörter verwendet. Gelingt es einem Angreifer nun, das Passwort des privaten Systems zu knacken, hat er damit nicht automatisch Zugang zu dem Bankkonto. Es muss aber beachtet werden, dass Vielfalt keine Sicherheit garantiert. Verschiedene Ressourcen können gemeinsame Wurzeln haben. So sind beispielsweise die meisten Unix-Betriebssysteme von BSD oder System V abgeleitet, so dass sich Fehler grundsätzlich „vererben“ können. Außerdem schützt Vielfalt nicht notwendigerweise vor Fehlkonfigurationen, da auch unterschiedliche IT-Ressourcen von den gleichen Personen betreut und verwendet werden, die u.U. die gleichen Fehler machen. Wird auf Sicherheit durch Vielfalt gesetzt, erkauft man sich dies durch höhere Komplexität und höhere Kosten. Außerdem wirkt sich Vielfalt oftmals negativ auf die Interoperabilität aus. Schließlich steht das Konzept der Vielfalt im Konflikt zu der Forderung nach Einfachheit.
6
Pikant ist hierbei, dass das Sicherheitsunternehmen ISS zuerst von dieser Verletzlichkeit berichtet hat. Dabei wurden die Apache-Entwickler, die bereits von dem Problem wussten und an einer Lösung arbeiteten, lediglich zwei Stunden vor der Veröffentlichung informiert. Ein sehr kurzer Zeitraum, um angemessen reagieren zu können. Dies führte zu weiteren Diskussionen für und gegen solch eine fundamentale Auslegung der „Full Disclosure“-Veröffentlichungpolitik.
186 5 Basisfunktionen und Sicherheitsprinzipien
5.3.8 Minimale Privilegien Verletzlichkeiten entstehen oftmals aufgrund von zu großzügig zugewiesenen Benutzungsrechten. Daher sollten für die jeweilige Aufgabe nur die Rechte vergeben werden, die benötigt werden. Problem Oftmals werden privilegierte Benutzerkennungen für „normale“ Aufgaben verwendet, d.h., die entsprechenden Rechte wären eigentlich nicht notwendig. Ein Beispiel hierfür ist ein Benutzer, der mit den Rechten eines Administrators arbeitet, obwohl er lediglich einen Drucker zurücksetzen möchte. Es wäre besser, hier ein privilegiertes Programm, das der Benutzer mit regulären Rechten ausführen kann und das den Drucker zurücksetzt, zu verwenden. Im Folgenden führen wir weitere Gründe auf, warum die missbräuchliche Verwendung von privilegierten Benutzerkennungen zu einer Bedrohung werden kann: – Umgehen der Zugriffskontrolle Mit Benutzerkennungen sind Rechte verbunden, um bestimmte Aufgaben durchführen zu können. Mithilfe des Konzepts Identitätsbasierte Zugriffskontrolle kann dann der Zugriff auf Ressourcen eingeschränkt werden. Werden privilegierte Benutzerkennungen verwendet, kann die Anforderung nach Zugriffskontrolle nicht mehr erfüllt werden, d.h., die Zugriffkontrolle ist nutzlos. – Auswirkung von Fehlern Fehler, die mit privilegierten Benutzerkennungen begangen werden, können fatale Folgen haben. Dies gilt einerseits für reguläre Benutzer, die möglicherweise einen Befehl aufrufen, der beispielsweise wichtige Dateien löscht (etwa rm -rf im Root-Verzeichnis eines Unix-Systems, d.h., alle Daten werden gelöscht). Andererseits hat ein Angreifer mehr Möglichkeiten, wenn es ihm gelingt, sich ITRessourcen widerrechtlich anzueignen, die mit privilegierte
