Hacker Contest: Sicherheitsprobleme, Lösungen, Beispiele (Xpert.press)

Springer Berlin Heidelberg New York Hongkong London Mailand Paris Tokio Die Reihe Xpert.press des Springer-Verlags ve...

Author: Markus Schumacher | Utz Roedig | Marie-Luise Moschgath

168 downloads 1573 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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


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


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.


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.


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


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.


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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


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.).


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


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,


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.


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


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.


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.


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.


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


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).


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.


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.


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


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


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.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


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.


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


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


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


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


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


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.


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


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.


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


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.


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


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.


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


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,


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.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


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


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).


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.


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.


(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-


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.


– 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.


– 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.


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.


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.


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


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).


. 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.


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


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


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.


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-


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


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.“


. 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-


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


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.


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.


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


– – – – – – – –

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.


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


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-


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.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.


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“.


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


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.


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


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.


§ 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.


§ 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


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.


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


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-


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


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.


– 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


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:


– 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-


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-


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-


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


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


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.


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ß.


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.


Teil II0

161

Basisfunktionen und Sicherheitsprinzipien

5


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.


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.


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.


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-


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.


– 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.


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.


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.


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


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-


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


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.


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.


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.


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.


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,


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.


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.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.


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.


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.


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 privilegierten Benutzerkennungen betrieben werden. – Beeinflussung des Auditing Benutzerkennungen dienen auch dazu, Aktionen einem Benutzer bzw. einer ITRessource zuzuordnen. Werden Benutzerkennungen nicht sinngemäß verwendet, ist solch ein Auditing nicht mehr möglich. Fehlverhalten und Angriffe können dann u.U. nicht mehr erkannt werden. – Keine zuverlässigen Testergebnisse Tests von IT-Ressourcen mit privilegierten Benutzerkennungen haben möglicherweise keine Aussagekraft, da in diesem Fall Annahmen gelten, die unter


regulären Bedingungen nicht notwendigerweise gewährleistet sind. Dies ist insbesondere darauf zurückzuführen, dass die Zugriffskontrolle und das Auditing ausgehebelt werden. Lösung Das Risiko bei Fehlverhalten und potenziellen Angriffen muss minimiert bzw. im Schadensfall müssen die Auswirkungen begrenzt werden. Daher müssen die Rechte, die für eine bestimmte Aktion benötigt werden, auf ein Minimum reduziert werden. Idealerweise wird die Gewährleistung von Rechten auch zeitlich begrenzt, d.h. nur so lange wie tatsächlich notwendig. Eine Analogie aus der realen Welt verdeutlicht dieses Prinzip. In größeren Gebäuden werden oftmals Schließanlagen verwendet. Manche Schlüssel passen zu einzelnen Bürotüren, wohingegen andere für eine Reihe von Räumen passen (Gruppenschlüssel). Schließlich gibt es im Allgemeinen auch einen Zentralschlüssel, der Zugang zu allen Türen verschafft. Auf diese Weise kann das Prinzip der minimalen Privilegien implementiert werden. So erhalten beispielsweise Mitarbeiter jeweils einen Büroschlüssel, Abteilungsleiter einen entsprechenden Gruppenschlüssel und der Geschäftsführer den Zentralschlüssel. Das Prinzip der minimalen Privilegien erhöht die Komplexität, insbesondere dann, wenn die zugrunde liegende IT-Ressource keine entsprechenden Mechanismen anbietet. Es muss zudem darauf geachtet werden, dass die Benutzer und ITRessourcen nicht zu wenige Rechte haben, da sie in diesem Fall ihre Aufgaben nicht erfüllen können. Abhängigkeiten Dieses Security Pattern setzt voraus, dass es eine Identitätsbasierte Zugriffskontrolle gibt, mit der das Prinzip der minimalen Rechte implementiert werden kann. 5.3.9 Bootstrapping Ein zentrales Problem ist es, Sicherheit von Anfang an gewährleisten zu können. Im Ursprungszustand gelten bestimmte Annahmen nicht, so dass es notwendig ist, ITRessourcen zunächst zu isolieren, um bestimmte Maßnahmen umzusetzen. In einem Bootstrapping-Prozess werden die IT-Ressourcen entsprechend abgesichert und danach in die eigentliche Umgebung integriert. Problem Schutzmaßnahmen bauen im Allgemeinen auf anderen Schutzmaßnahmen auf, die oftmals als implizit vorausgesetzt werden. Dies ermöglicht u.a. folgende Angriffsszenarien:


– Maskierung/Fälschung von vertrauenswürdigen Quellen Viele IT-Ressourcen können über Netzwerkverbindungen installiert, konfiguriert und aktualisiert werden. Aus Sicherheitsgesichtspunkten ist dies problematisch, da dies Vertrauen zu der Quelle erfordert und diese Vertrauensbeziehung oft nicht explizit etabliert wird. Gelingt es einem Angreifer beispielsweise, das Web-Angebot eines Herstellers zu imitieren und das potenzielle Opfer beispielsweise durch das Fälschen von DNS-Einträgen auf die entsprechende Seite zu locken, wird dies möglicherweise gar nicht auffallen, und das arglose Opfer verschafft dem Angreifer damit beliebige Möglichkeiten, IT-Ressourcen zu manipulieren. Vermeintlichen Schutz bieten kryptografische Verfahren, die mithilfe von Hash-Werten und digitalen Signaturen die Authentizität und Integrität einer Quelle garantieren sollen. Ein Angreifer kann aber manipulierte Software-Pakete ebenfalls mit seinen eigenen Hash-Werten und Signaturen versehen. Es hängt hier an der Arglosigkeit des Opfers, die kryptografischen Möglichkeiten zu nutzen, um festzustellen, ob tatsächlich der eigentliche Hersteller oder ein Angreifer das Gegenüber ist. – Ausspähen Oftmals werden Passwörter zur Identifikation und Authentisierung verwendet. Initial werden typischerweise das Passwort des Systemverwalters sowie ausgewählter Benutzer festgelegt. Ist die IT-Ressource in dieser Phase in ein Netzwerk integriert, kann ein Angreifer grundsätzlich versuchen, die IT-Ressource anzugreifen und die Passwörter auszuspähen. Er hat damit zu einem späteren Zeitpunkt, wenn die IT-Ressource vermeintlich geschützt ist, Zugang zu dem System. – Manipulation Ein Angreifer kann versuchen, dem potenziellen Opfer manipulierte Komponenten unterzuschieben. So können in entsprechend modifizierten Software-Paketen beispielsweise Trojaner enthalten sein, die dem Angreifer einen Zugang zu der IT-Ressource ermöglichen. Eine Möglichkeit ist hier, manipulierte Installationsmedien (z.B. CD-ROMs einer Linux-Distribution) zu kopieren und dem Eigentümer der betreffenden IT-Ressource unterzuschieben. – Man-in-the-Middle Unter bestimmten Voraussetzungen gelingt ein Man-in-the-Middle-Angriff. Der Angreifer positioniert sich dabei (beispielsweise mithilfe von DNS-Spoofing) zwischen Quelle und Ziel einer Anfrage. Dabei ist es grundsätzlich möglich, auch durch kryptografische Verfahren geschützte Kommunikation anzugreifen. Ausgenutzt wird beispielsweise der Zeitpunkt, in dem der Benutzer mit einem neuen bzw. geänderten Public Key konfrontiert wird. Dieser muss für einen erfolgreichen Angriff akzeptiert werden. Entweder handelt es sich um den ersten Login Request des Quellsystems auf das Zielsystem, womit noch kein Public Key des Zielsystems eingetragen war, oder es ist bereits ein Public Key-Eintrag für das Zielsystem vorhanden.


Im ersten Fall wird der Benutzer von der entsprechenden Software in der Regel gefragt, ob für das Quellsystem der (neue) Public Key des Zielsystems eingetragen werden soll. Kennt der Benutzer den richtigen Public Key nicht, besteht die Möglichkeit, dass er den falschen Key einfach akzeptiert. Im zweiten Fall wird beim Benutzer nachgefragt, ob der den bereits eingetragenen Public Key des Zielsystems mit dem neuen überschreiben möchte. In beiden Fällen ist es von der Arglosigkeit des Benutzers abhängig, ob er den falschen Public Key akzeptiert und somit der Angriff erfolgreich verläuft. Lösung Um initial eine Basis für weitere Schutzmaßnahmen zu schaffen, müssen die entsprechenden IT-Ressourcen zunächst isoliert werden. Während eines solchen Bootstrapping bietet es sich dann an, grundlegende Maßnahmen durchzuführen. Dabei sind zwei Varianten zu unterscheiden: – Out of Band Es wird ein alternativer Kanal ausgewählt, um die Authentizität einer IT-Ressource oder eines Benutzers zu verifizieren. Bei PGP sollte beispielsweise so vorgegangen werden, dass sich die Kommunikationspartner am Telefon den HashWert (genannt „Fingerprint“) gegenseitig bestätigen. Ebenfalls im Kontext kryptografischer Schlüssel hat sich das Verfahren der Post-Identifikation bewährt. Dabei bestätigt eine neutrale Person (der Post-Angestellte), dass der Kunde tatsächlich der ist, der er vorgibt zu sein (durch Kontrolle des Personalausweises). Die entsprechende Bestätigung wird dann an den Kommunikationspartner weitergegeben. – Offline Es kann auch sinnvoll sein, eine IT-Ressource vom Netzwerk zu trennen, um Eingriffe von außen gänzlich auszuschließen. So kann beispielsweise Betriebssystemsoftware von Originalmedien (in der Regel erkennbar durch Zertifikate oder Hash-Werte, die Out of Band überprüft werden können) installiert werden. Danach wird das System konfiguriert und abgesichert und anschließend wieder in den Netzwerkverbund integriert. Die Konsequenz dieser Vorgehensweise ist sicherlich ein höherer Aufwand. Allerdings sollte insbesondere bei kritischen IT-Ressourcen nicht darauf verzichtet werden, da man sonst nie ausschließen kann, dass es einem Angreifer von Anfang an gelungen ist, die Kontrolle zu erlangen.


5.3.10 Zusammenfassung Die oben beschriebenen Security Patterns, die grundlegende Prinzipien für den sicheren Entwurf und Betrieb von IT-Ressourcen darstellen, können wie folgt zusammengefasst werden: – Konservative Vorgehensweise Da im Lauf der Zeit Fehler identifiziert und behoben worden sind, sind bewährte Lösungen grundsätzlich sicherer als gänzlich neue Ansätze. Dies steht oftmals im Widerspruch zur Forderung nach neuen Eigenschaften. – Einfachheit Einfache Strukturen sind leicht überschaubar und beherrschbar. Fehler können besser erkannt und behoben bzw. von Anfang an vermieden werden. Einfachheit steht allerdings im Widerspruch zu dem Trend stetig zunehmender Komplexität. – Absicherung der schwächsten Stellen Angreifer werden den Weg des geringsten Widerstandes gehen. Daher müssen die schwächsten Stellen identifziert und besonders geschützt werden. Dies ist ein kontinuierlicher, iterativer Vorgang. – Mehrschichtige Verteidigung Um zu verhindern, dass die Kompremittierung einer IT-Ressource alle anderen in Mitleidenschaft zieht, sollten mehrere sich ergänzende Schutzkonzepte verwendet werden. Mehrschichtige Verteidigung erhöht aber die Komplexität und wirkt sich auf die Kosten aus. – Passierstelle Maßnahmen können nur dann effizient umgesetzt werden, wenn Kontrolle an einer definierten Stelle ausgeführt werden kann. Dies schränkt möglicherweise die Benutzbarkeit einer IT-Ressource ein. – Sicherheit als Standardverhalten Auch Schutzmaßnahmen können in einen Zustand kommen, in dem Teile ausfallen oder gestört werden. In diesem Fall sollte das Verhalten so sein, dass sich das Sicherheitsniveau erhöht. Im Zweifelsfall ist die Nutzung einer IT-Ressource dann nicht mehr möglich, sie kann aber auch nicht mehr weiter attackiert werden.


– Vielfalt Werden IT-Ressourcen gleichen Typs verwendet, hat es ein Angreifer leichter. Gelingt es ihm, eine bestimmte Verletzlichkeit einer IT-Ressource auszunutzen, kann er dies womöglich auch bei allen anderen. Daher sollte insbesondere bei der Umsetzung von Schutzmaßnahmen auf eine Vielfalt der Verteidigung gesetzt werden. Dies wirkt sich zunächst auf die Kosten, aber auch auf die Komplexität aus. – Minimale Privilegien Es sollten nur die Rechte gewährleistet werden, die notwendig sind, um eine bestimmte Aufgabe zu erfüllen. Ist dies nicht der Fall, haben Angriffe möglicherweise weitreichendere Konsequenzen. Es muss allerdings darauf geachtet werden, dass nicht zu restriktiv vorgegangen wird, da die Aufgabe sonst gar nicht ausgeführt werden kann. – Bootstrapping Um eine Basis für den sicheren Betrieb einer IT-Ressource zu schaffen, müssen initial Maßnahmen ergriffen werden, die nur von dem Eigentümer kontrolliert werden. Dazu wird die IT-Ressource isoliert, bzw. es wird Vertrauen außerhalb der regulären Kanäle etabliert.


Systeme

6


6.1 Einleitung In diesem Kapitel betrachten wir Probleme der IT-Sicherheit, die auf der Ebene der IT-Systeme auftreten. IT-Systeme werden einerseits eingesetzt, um sicherheitskritische Informationen zu verarbeiten und zu speichern. Andererseits sind die meisten IT-Systeme heute in der einen oder anderen Form vernetzt, so dass auch der Übergang zum Netzwerk eine wichtige Rolle spielt. Die Absicherung von IT-Systemen sollte daher ein integraler Bestandteil des Sicherheitsprozesses sein. Die meisten Probleme im Bereich der IT-Systeme treten aufgrund von Fehlkonfigurationen auf, insbesondere bei unzureichenden Standardeinstellungen von Hard- und Software. In diesem Kapitel werden daher Security Patterns vorgestellt, die dabei helfen, geplante und bereits eingesetzte IT-Systeme entsprechend der eigenen Sicherheitsanforderungen richtig zu konfigurieren. Ein zentraler Punkt ist dabei auch die Sicherheit der Betriebssysteme, d.h. softwareseitige Maßnahmen zum Schutz der Ressourcen eines IT-Systems.

6.2 Physikalischer Schutz Im Zusammenhang mit Sicherheit wird oft vom Zwiebelschalenmodell gesprochen, bei dem Sicherheitsmaßnahmen in mehreren Schichten umgesetzt werden. Oft wird über Sicherheitsaspekte auf logischen Ebenen, wie Netzwerken, Protokollen und Anwendungen, gesprochen. Wird jedoch der physikalische Zugang zu einem ITSystem nicht hinreichend geschützt – gewissermaßen die äußere Schicht der Zwiebel –, kann in vielen Fällen auch keine Sicherheit auf den inneren Schichten gewährleistet werden.

6.1. Einleitung 193 M. Schumacher et al., Hacker Contest © Springer-Verlag Berlin Heidelberg 2003

Kontext Beschrieben wird ein einzelnes, allgemeines IT-System, das nicht in einen Netzwerkverbund integriert ist. Wir gehen davon aus, dass grundsätzlich beliebige Betriebssysteme verwendet werden können. Weiterhin werden keine Annahmen über die Hardware-Plattform getroffen. Das IT-System verfügt über übliche Peripheriegeräte wie Festplatten, Disketten- und CD-Laufwerke. Problem Bevor Maßnahmen gegen unrechtmäßigen Zugriff auf logischer Ebene, also z.B. lokal über Anwendungen, getroffen werden, muss das IT-System auch physikalisch entsprechend geschützt werden. Bedrohungen gehen dabei sowohl von Innentätern als auch von Dritten ( z.B. Reinigungspersonal) aus. Dabei sind insbesondere folgende Bedrohungen relevant: – Ausspähen von Informationen Ein Angreifer mit Zugang zu einem Raum, in dem ein IT-System steht (beispielsweise ein Büro), kann grundsätzlich immer versuchen, sicherheitsrelevante Informationen auszuspähen. Ein Blick über die Schulter eines arglosen Benutzers kann einem versierten Angreifer genügen, beispielsweise das Passwort eines Benutzers mitzulesen, so dass später ein Zugang auf logischer Ebene möglich wird. – Installation und Modifikation der Hardware Ein Angreifer kann die Hardware des Systems derart manipulieren, dass weitere Schutzmaßnahmen umgangen werden können. Dazu gehört beispielsweise die Installation eines Modems oder eines Handys, so dass eine direkte Verbindung des IT-Systems zum Internet möglich ist. Der Verkehr über solche Verbindungen kann nicht mithilfe herkömmlicher Maßnahmen wie einer Firewall kontrolliert werden. Auf diese Weise wird das IT-System allen Gefahren ausgesetzt, die sich aus einer solchen nicht vorgesehenen Vernetzung ergeben. Ein anderes Beispiel ist die Installation eines zusätzlichen bootfähigen Peripheriegeräts. Dies kann eine bootfähige Diskette, CD oder aber eine zusätzliche Festplatte sein. Ändert der Angreifer nun noch die Boot-Reihenfolge, kann er prinzipiell alle Sicherheitsvorkehrungen auf dem ursprünglichen Medium umgehen, d.h., er hat vollen Zugriff auf die dort gespeicherten Informationen. – Diebstahl von Daten oder Geräten Mithilfe von Wechseldatenträgern wie Disketten können leicht Informationen kopiert und in unberechtigte Hände gebracht werden. Ähnlich verhält es sich mit beschreibbaren CDs, was allerdings einen CD-Brenner voraussetzt. Als Variante ist auch der Diebstahl von Datenträgern oder sogar des gesamten IT-Systems

194 6 Systeme

denkbar. Der Angreifer kann die Daten dann in aller Ruhe untersuchen. Schließlich ist es noch möglich, eine Tastatur-Wanze anzubringen. Solch ein Gerät wird zwischen Tastatur und IT-System geschaltet und zeichnet alles auf, was vom Benutzer eingegeben wird. Interessant sind auch hier wieder Benutzerkennungen und Passwörter. – Zerstörung von Gerät oder Daten Werden Teile oder das gesamte IT-System zerstört, ist die Verfügbarkeit nicht mehr gegeben. So kann ein Angreifer gezielt versuchen, strategisch wichtige Komponenten außer Gefecht zu setzen. Als Motive kommen hier einerseits Sabotage, aber auch die Verschleierung eines tatsächlichen Angriffs in Frage. Je nach Aufwand der Angreifer kann es zu erheblichen Ausfallzeiten kommen. Für einen Anbieter, der seine Dienste ausschließlich über das Internet anbietet, kann dies fatale Folgen haben. Lösung Erst durch eine hinreichende physikalische Absicherung wird der sichere Betrieb eines IT-Systems möglich. Zu den technischen Maßnahmen gehört zunächst die Aktivierung der Schutzmaßnahmen des IT-Systems. Das Gehäuse sollte so weit möglich abgeschlossen sein. Möglicherweise sind hierfür zusätzliche Vorrichtungen von Drittanbietern notwendig. Ergänzend können nicht benötigte externe Steckplätze und Hardware beispielsweise im BIOS von PCs deaktiviert, falls möglich sogar physikalisch entfernt werden. Alternativ kann auch das Gehäuse versiegelt werden, um die Installation und Manipulation von Hardware zumindest zu erschweren. Versucht ein Angreifer dennoch einen Angriff auf diesem Weg, hinterlässt er auf alle Fälle sichtbare Spuren am IT-System, die sofort erkannt werden können (Kratzer am Gehäuse, gebrochene Siegel). Ein weiterer wichtiger Aspekt ist die sichere Aufstellung eines IT-Systems. Als Daumenregel gilt, dass ein IT-System, das sensitive Daten verarbeitet, nicht in einem normalen Büro aufgestellt werden sollte, da solche Räume z.T. auch öffentlich zugänglich sein müssen und in der Regel nicht besonders geschützt sind. Schutz gegen unberechtigtes Ausspähen von Monitor und Tastatur kann durch geeignete Aufstellung des IT-Systems erreicht werden. Es sollte so aufgestellt werden, dass ein Angreifer nicht ohne weiteres über die Schultern eines Benutzers blicken kann. Auch Blicke durch Fenster sollten nach Möglichkeit verhindert werden. Zur Absicherung eines Raumes können je nach Gefährdungslage Technologien eingesetzt werden, die eine Überwachung und Kontrolle des Zugangs ermöglichen. Denkbar sind hier Überwachungskameras und Zugangskarten. Hierbei muss besonders darauf geachtet werden, wie der Zugang von Reinigungs- und Wartungspersonal sowie Geschäftspartnern geregelt wird.

6.2. Physikalischer Schutz 195

Abhängigkeiten Der Einsatz von abschließbaren Geräten erfordert die Verwaltung der Schlüssel. Dabei muss gewährleistet sein, dass der Schlüssel selbst nicht jedem zugänglich ist. Außerdem müssen genügend verschiedene Exemplare existieren, damit nicht mit einem einzigen Schlüssel alle Systeme geöffnet werden können. Wenn ein Angreifer versucht, physikalische Schutzmaßnahmen zu umgehen, hinterlässt er dabei meistens Spuren. Daher müssen zusätzliche Maßnahmen getroffen werden, um solche Unregelmäßigkeiten festzustellen. Im Rahmen eines Audit-Prozesses (siehe Security-Patter Audit) müssen daher auch die physikalischen Schutzmaßnahmen regelmäßig kontrolliert werden. Es bietet sich an, dieses Security-Patterns zu verwenden, um eine Mehrschichtige Verteidigung umzusetzen.

6.3 Authentisierung IT-Systeme mit gängigen Betriebssystemen wie beispielsweise Microsoft Windows XP oder Sun Solaris erfordern eine gesicherte Anmeldung [126]. Wenn sich ein Benutzer bei einem System anmeldet und somit identifiziert, findet eine Authentisierung des Benutzers durch einen Systemprozess statt. So wird überprüft, ob der Benutzer derjenige ist, der er vorgibt zu sein. In diesem Abschnitt werden daher grundlegende Probleme beschrieben, die beim Einsatz von Passwörtern zu beachten sind. Dazu gehören auch Abhängigkeiten von der Passwortqualität und dem Schutz der Passwörter. 6.3.1 Benutzerauthentisierung mit Passwörtern Passwörter sind – obwohl sie nicht das sicherste Verfahren zur Identifikation und Authentisierung von Benutzern darstellen – nach wie vor weit verbreitet. Das Verfahren ist für jeden leicht nachvollziehbar und in nahezu allen IT-Systemen implementiert bzw. lässt sich vergleichsweise leicht integrieren, da beispielsweise keine zusätzliche Hardware eingebunden werden muss. Kontext Dieses Pattern konkretisiert das Security Pattern für Identifikation und Authentisierung im Kontext von IT-Systemen. Es wird zudem davon ausgegangen, dass keine zusätzliche Hard- oder Software verwendet werden soll, d.h., es werden ausschließlich die Schutzmechanismen des Betriebssystems betrachtet. Problem Es muss gewährleistet sein, dass nur Benutzer mit einer entsprechenden Berechtigung Zugang zum System erhalten. Ein Angreifer könnte sonst vertrauliche Infor-

196 6 Systeme

mationen finden, verändern oder zerstören. Insbesondere die Ressourcen und Betriebsmittel des IT-Systems wie beispielsweise Dateien, Anwendungen, Datenbanken, Geräte oder Netzverbindungen müssen geschützt werden. Lösung Damit das IT-System rechtmäßige Benutzer von Angreifern unterscheiden kann, muss eine eindeutige Zuordnung zwischen der Identität des Benutzers und einem eindeutigen Identifizierungsmerkmal erfolgen. In die Kategorie vom gemeinsamen Geheimnis zwischen Benutzer und IT-System fallen dabei Passwörter, die grundsätzlich eine sichere Identifikation und Authentisierung ermöglichen. Im System werden vorab eine Benutzerkennung und ein Passwort hinterlegt, so dass ein gemeinsames Geheimnis zwischen System und Benutzer existiert. Damit der Benutzer auf das System zugreifen kann, muss er sich zunächst durch Eingabe seiner Benutzerkennung gegenüber dem System identifizieren. Typischerweise wird im gleichen Schritt auch das Passwort abgefragt. Das System sucht dann den Benutzer in der entsprechenden Liste und vergleicht das eingegebene mit dem hinterlegten Passwort. Stimmen beide überein, wird der Zugang zum System gewährt, andernfalls verweigert. Hinsichtlich der Generierung von Passwörtern können grundsätzlich zwei Varianten, die sich in der Qualität und dem Aufwand für den Benutzer unterscheiden, betrachtet werden: – Benutzergenerierte Passwörter Das Passwort wird vom Benutzer selbst gewählt. Dabei kann davon ausgegangen werden, dass der Benutzer ein Passwort wählt, das er sich gut merken und mit dem er gut umgehen kann (z.B. keine Sonderzeichen verwenden, die umständliche Eingaben auf der Tastatur erfordern). Aus diesen Gründen ist allerdings die Gefahr einer schlechten Qualität der Passwörter groß, d.h. ein Angriff hat gute Aussichten auf Erfolg. – Systemgenerierte Passwörter Diese Passwörter werden prinzipiell zufällig generiert. Sie sind daher zwar recht sicher, es fällt den Benutzern aber vermutlich schwerer, sich solche Passwörter zu merken. Passwörter sind vergleichsweise leicht umzusetzen, da nahezu in allen IT-Systemen die entsprechenden Mechanismen zur Verfügung stehen. Sie bieten aber nicht das Sicherheitsniveau wie Token-basierte oder biometrische Verfahren. Abhängigkeiten Passwörter sind eine Lösung für die Identifikation und Authentisierung von Benutzern im Kontext von IT-Systemen. Die Lösung selbst ist allerdings angreifbar, so dass sich Abhängigkeiten zu weiteren Security-Patterns ergeben. Eine hohe Qualität

6.3. Authentisierung 197

von Passwörtern kann durch Anwendung und Prüfung der Einhaltung von Konventionen (Passwortqualität) erreicht werden. Darüber hinaus muss auch ein Schutz der Passwörter, d.h. der korrekte Umgang mit den Passwortinformationen durch Benutzer und Betreiber des IT-Systems, selbst gegeben sein (siehe Security Pattern Schutz der Passwörter). Ist dies nicht der Fall, können bestimmte Angriffe zur Umgehung des vermeintlichen Schutzes durch Passwörter führen. 6.3.2 Passwortqualität Die Benutzkennung ist im Allgemeinen kein Geheimnis, sie ist beispielsweise oftmals Teil der E-Mail-Adresse eines Benutzers. Falls dem Angreifer die Benutzerkennung bekannt ist und der Benutzer ein schlechtes Passwort gewählt hat, kann er die richtige Zeichenfolge eines Passworts ermitteln, um sich dann mit der Identität des Benutzers bei einem Dienst oder einem System anzumelden. Passwort-Attacken können erschwert werden, wenn Passwörter nach Regeln erstellt werden, die zu einer hohen Passwortqualität führen. Kontext Dieses Pattern wird vom Security Pattern zur Benutzerauthentisierung mit Passwörtern verwendet. Es wird also davon ausgegangen, dass Passwörter verwendet werden, um zu verhindern, dass Unbefugte ein IT-System verwenden können. Problem Passwörter sind gemeinsame Geheimnisse und können daher grundsätzlich immer von einem Angreifer ermittelt werden. Eine schlechte Qualität bedeutet dabei, dass der zeitliche Aufwand für einen Angreifer reduziert signifikant wird. So lohnt es sich, Zeit in einen Angriff zu investieren, da mit hoher Wahrscheinlichkeit ein Erfolg möglich ist. Dies ist beispielsweise dann der Fall, wenn das gemeinsame Geheimnis nur aus einer kurzen Zeichenfolge besteht: Eine vierstellige PIN kann schneller erraten werden als eine achtstellige Zeichenfolge. Wenn es einem Angreifer gelingt, in Kenntnis der geheimen Informationen zu gelangen, kann er Zugang zum System erhalten und böswillige Aktionen durchführen. Er übernimmt so die Identität eines regulären Benutzers oder Systems, ohne dass dies vom Systembetreiber erkennbar wäre. Die sicherheitsrelevanten Anforderungen, die grundsätzlich an Verfahren zur Authentisierung gestellt werden, können im Kontext dieses Patterns konkretisiert werden. Zunächst betrachten wir Angriffe, die sich aufgrund einer schlechten Passwortqualität ergeben:

198 6 Systeme

– Erraten von Passwörtern Die Benutzerkennungen selbst leiten sich typischerweise aus dem Namen (z.B. hmeier für den Benutzer Hans Meier) oder der Funktion des Benutzers ab (z.B. sysop), können daher naturgemäß leicht ermittelt werden und stellen so gesehen kein Geheimnis dar. Das eigentliche Problem mit Passwörtern ist, dass der Angreifer einfach versuchen kann, das Geheimnis des Benutzers zu erraten. Dies wird ihm insbesondere dann gelingen, wenn als Passwort ein Begriff verwendet wird, der ebenfalls leicht mit dem Benutzer in Verbindung gebracht werden kann, wie der Name der Firma oder der Vor- bzw. Nachname. Dies setzt allerdings gewisse Kenntnisse über das Umfeld des Benutzers vorraus, die sich der Angreifer im Vorfeld des Angriffs beschaffen muss. Ein leichtes Spiel hat der Angreifer auch, wenn bekannte Standardpasswörter verwendet werden (z.B. Zeichenfolgen, die leicht auf der Tastatur eingegeben werden können wie etwa „12345678“ oder „qwertzui“). – Wörterbuchangriff Der Angreifer kann auch einen Wörterbuchangriff (engl. Dictionary Attack) durchführen, falls ein Benutzer Passwörter verwendet, die sich grundsätzlich in einem Wörterbuch finden lassen. Im Internet findet man leicht thematisch sortierte und umfangreiche Wörterbücher. So gibt es Wörterbücher, die ausschließlich aus Namen, religiösen Begriffen oder Markennamen bestehen. Vermeintlich bessere Passwörter, die durch Anhängen zusätzlicher Zeichen, Jahreszahlen o.Ä. gebildet werden, können durch bestimmte Operationsmodi von PasswortCracker-Tools, die genau diesem Verhalten nachempfunden sind, schnell entschlüsselt werden. – Brute-Force-Angriffe Gelingt es auf diesem Weg nicht, das Passwort zu erraten, bleibt außerdem noch die Möglichkeit, systematisch alle Kombinationen durchzuprobieren. Dieser Angriff, der sich auch automatisieren lässt, wird Brute-Force-Angriff genannt. Verfügt der Angreifer über genügend Zeit und Ressourcen, führt dieser Angriff früher oder später immer zum Erfolg. Besteht ein Passwort aus acht Zeichen und einem rein alphanumerischen Zeichensatz, so benötigt ein Angreifer für einen derartigen Brute-Force-Angriff auf einem High-End-PC nicht einmal einen Tag. Mit zunehmender Rechenleistung oder dem Partionieren des Passwortraums auf mehrere Systeme kann dieser Aufwand nochmals drastisch reduziert werden. Diese Angriffe gelingen übrigens auch, wenn der Angreifer ein verschlüsseltes Passwort knacken möchte. Typischerweise werden Passwörter mit einer bekannten Einwegfunktion verschlüsselt, das Resultat ist ein Hash-Wert, aus dem sich das Passwort nicht ableiten lässt. Kennt der Angreifer allerdings die Einwegfunktion, verschlüsselt er wie oben beschrieben verschiedene Zeichenfolgen und vergleicht diese mit dem Passwort-Hash. Fällt dieser Vergleich positiv aus, so ist auch das verschlüsselte Passwort geknackt.


Ist es dem Angreifer erst einmal gelungen, ein Passwort zu ermitteln, so kann er mit der Identität des Benutzers und den entsprechenden Rechten jederzeit auf das System zugreifen. Lösung Es ist sehr wichtig, dass der Aufwand für die Authentisierung mit Passwörtern für die Benutzer vertretbar ist. Damit sichere Passwörter die oben beschriebenen Angriffe erschweren, müssen sie allerdings komplex aufgebaut sein. So kann es Benutzern möglicherweise schwer fallen, sich das Passwort zu merken, insbesondere dann, wenn es sich um mehrere Passwörter handelt. Dies ist insbesondere beim Einsatz von systemgenerierten Passwörtern der Fall. So könnten Benutzer versuchen, überall das gleiche Passwort zu verwenden oder aber aufzuschreiben. Durch entsprechende Regelungen kann eine hohe Qualität der Passwörter erreicht werden, die das Knacken deutlich erschweren und der Forderung nach einem vertretbaren Aufwand genügten. Gute Passwörter zeichnen sich dadurch aus, dass die maximale Länge voll ausgenutzt wird (also z.B. 14 Zeichen bei Windows NT), die Zeichenfolge selbst zufällig ist und sowohl alphanumerische als auch Sonderzeichen enthalten sind. Als Beispiel werden nun zwei einfache Merkstrategien für gute Passwörter vorgestellt, die Teil einer umfassenden Richtlinie über den Umgang mit Passwörtern sein können: – Akronym-Methode Bei der Akronym-Methode wählt der Benutzer einen oder mehrere Sätze und verwendet dann als Passwort die Anfangsbuchstaben der einzelnen Wörter, wobei Vokale beispielsweise durch Ziffern oder Sonderzeichen ersetzt werden können. Aus dem Satz „Mein Auto hat vier Räder und fünf Türen!“ wird so das Passwort „M@h4Ru5T!“. – Collage-Methode Bei der Collage-Methode wird ein Wort aus einer natürlichen Sprache ausgewählt und in eine andere natürliche Sprache übersetzt. Danach werden beiden Wörtern drei aufeinander folgende Buchstaben z.B. vom Wortanfang entnommen und mit zwei Ziffern oder Sonderzeichen, die sich gut merken lassen, verbunden. Aufbauend auf dem Wort „Gewicht“ könnte sich so das Passwort „Gew79WEI“ ergeben („Gewicht“, „WEIGHT“, sie wiegen 79 Kilo). Wenn ein Benutzer Zugang zu verschiedenen Systemen hat und sich damit mehrere Passwörter merken muss, stoßen allerdings auch diese Techniken schnell an ihre Grenzen. Dies gilt auch für systemgenerierte Passwörter, die im Allgemeinen zufällig gewählt werden und den oben aufgeführten Kriterien genügen. Bruce Schneier schlägt deshalb einen alternativen Ansatz vor [100]:

200 6 Systeme

– Verwaltung von Passwörtern Es wird davon ausgegangen, dass man sich richtig gute Passwörter ohnehin nicht merken kann. Deshalb sollten möglichst lange und zufällige Zeichenketten als Passwort erzeugt und aufgeschrieben werden! Diese Passwörter werden dann an einem besonders gesicherten Ort (beispielsweise im eigenen Geldbeutel, auf den man typischerweise immer gut aufpasst) aufbewahrt oder mit einer entsprechenden Software verwaltet (z.B. Password Safe). Letzteres hat den Vorteil, dass man sich dann nur das eine Passwort merken muss, das die Verwaltungssoftware freischaltet. Allerdings muss sehr darauf geachtet werden, dass dieses Programm keine Lücken aufweist, die ein Angreifer ausnutzen könnte, um Zugriff auf alle Passwörter zu bekommen. Ergänzend zu diesen Maßnahmen sollte die Qualität der Passwörter zudem technisch überprüft werden. Dies gilt sowohl bei der initialen Eingabe als auch im laufenden Betrieb durch Passwort-Audits. Darüber hinaus ist es empfehlenswert, die Passwörter regelmäßig zu wechseln. Somit wird der Zugriff eines Angreifers auf ein System mit einem erratenen Passwort zeitlich begrenzt. Weiterhin ist darauf zu achten, dass Erstpasswörter (die möglicherweise Standardpasswörter sind) auf jeden Fall bei der ersten Anmeldung des Benutzers gewechselt werden müssen. Außerdem muss auf technischer Ebene verhindert werden, dass ein Angreifer beliebig viele Anmeldungsversuche hat. Wenn entsprechende Audit-Funktionen des Betriebssystems aktiviert werden, kann im Falle eines Angriffs entsprechend reagiert werden. So könnte es bespielsweise zu einer automatischen Sperrung einer Benutzerkennung nach drei Fehlversuchen kommen, die nur vom Systemadministrator aufgehoben werden kann. Grundsätzlich sollte hierbei eine Nachricht an den Administrator übermittelt werden. Abhängigkeiten Eine hohe Passwortqualität ist eine wichtige Voraussetzung dafür, dass eine Benutzerauthentisierung mit Passwörtern überhaupt erst möglich wird. Ist dies nicht gegeben, kann die vermeintliche Schutzmaßnahme leicht umgangen werden, der Benutzer wiegt sich in falscher Sicherheit. 6.3.3 Schutz der Passwörter Maßnahmen zur Authentisierung von Benutzern, die vor unberechtigten Zugriffen auf Anwendungs-, System- oder Netzwerkebene schützen sollen, können umgangen werden, wenn Identifikationsmerkmale und Authentisierungsinformationen nicht richtig gehandhabt werden. In diesem Abschnitt wird beschrieben, worauf beim korrekten Umgang mit Passwörtern unbedingt geachtet werden sollte.


Kontext Schutzmaßnahmen werden in der Regel durch System- und Anwendungssoftware, die entsprechend installiert und konfiguriert sein muss, umgesetzt. Auf Systemebene werden beispielsweise Passwörter als Maßnahme zur Authentisierung von Benutzern verwendet. Die Passwortinformationen selbst werden typischerweise in Dateien auf dem System abgelegt. Weiterhin kann es vorkommen, dass ein Passwort von einem System auf das andere übertragen werden muss, damit auf ein IT-System über ein Netzwerk zugegriffen werden kann. Problem Sowohl auf Unix- als auch auf Windows NT-Systemen werden die Passwortinformationen gemeinsam mit dem Benutzernamen im System abgespeichert, wobei die Passwörter üblicherweise mit einer bekannten Einwegfunktion verschlüsselt werden (Hash-Verfahren bei Windows NT, modifizierte DES-Version bei Unix). Dabei sind die Lese- und Schreibrechte so eingestellt, dass nur der Authentisierungsprozess darauf zugreifen kann – ein normaler Benutzer kann diese Informationen im Regelfall nicht auslesen. Neben einer hohen Qualität von Passwörtern muss auch darauf geachtet werden, dass die Passwortinformationen selbst gegen Angreifer geschützt werden. Wie im Folgenden gezeigt, gibt es verschiedene Möglichkeiten, die von einem Angreifer ausgenutzt werden können, um Passwörter auszuspähen und damit den Schutz auszuhebeln. – Social Engineering Ein Angreifer kann zunächst versuchen, den Benutzer zu täuschen. Mithilfe von „Social Engineering“ wird er versuchen, über ein Gespräch an die gewünschte Information zu kommen. Der Angreifer wählt beispielsweise eine beliebige Nummer, die leicht aus öffentlich zugänglichen Kontaktinformationen eines Unternehmens abgeleitet werden kann. Der Angreifer gibt sich dann als Netzwerkadministrator aus und sagt, dass er etwas umkonfigurieren muss und zu diesem Zweck die Benutzerkennung und das Passwort des Mitarbeiters benötigt. Der Erfolg hängt maßgeblich davon ab, wie plausibel der Angreifer sein Anliegen vortragen kann und ob der Mitarbeiter die gewünschte Information preisgibt. – Ausspähen vor Ort Für einen Angreifer mit physikalischem Zugang zu einem System, ist es leicht, relevante Informationen auszuspähen. Ein begehrtes Objekt sind beispielsweise Passwörter, die auf einem Zettel notiert worden sind und unachtsam in unmittelbarer Nähe des Systems aufbewahrt werden (etwa in der Schreibtischschublade, unter der Tastatur oder besonders gravierend direkt am Monitor klebend). Ein Angreifer kann auch versuchen, solche Informationen z.B. durch die Beobachtung von Benutzern zu erhalten. Schaut er einem Benutzer bei Eingabe des Passworts über die Schultern, ist er bereits am Ziel. Er könnte auch Kameras oder

202 6 Systeme

Spiegel anbringen, um an die Informationen zu gelangen. Ähnlich einzustufen ist die Installation einer unscheinbaren Tastaturwanze, also einem Gerät, das jeden Tastendruck aufzeichnet. – Manipulation der Hardware/Software Darüber hinaus kann ein Angreifer relevante Komponenten wie die Festplatte des IT-Systems stehlen und so an dort abgelegte Passwortinformationen gelangen. – Abhören der Übertragung von Passwörtern Grundsätzlich ist es von geringer Bedeutung, ob das Passwort im Klartext oder verschlüsselt übertragen wird, da ein Brute-Force-Angriff immer zum Erfolg führen wird. Ein Angreifer kann mit geeigneter Software die Übertragung abhören. Eine andere Möglichkeit, an die Hash-Werte zu kommen, besteht im Belauschen der Netzwerkkommunikation. Bei lokalen Netzwerken wird ein Zugang zu einem Netzwerkknoten sowie eine Software benötigt, die den Netzwerkverkehr mitschneidet (Sniffer). Viele Protokolle versenden die verschlüsselten Passwortinformationen über das Netzwerk (insbesondere dann, wenn Authentisierungsserver verwendet werden), so dass ein Angreifer passiv warten kann, bis er eine ausreichende Menge an Passwörtern gesammelt hat. Einige Dienste versenden die Passwörter sogar unverschlüsselt, was den Aufwand für den Angreifer erheblich reduziert. Passwörter werden im Allgemeinen in Dateien abgelegt und stellen gewissermaßen eine IT-Ressource dar, die gegen die beschriebenen Angriffe geschützt werden muss. Lösung Passwörter müssen sowohl organisatorisch als auch technisch geschützt werden. Grundsätzlich dürfen Benutzer ihr Passwort in keinem Fall preisgeben, und es darf auch nicht möglich sein, das Passwort in irgendeiner Form auszuspähen. Im Einzelnen müssen daher die folgenden Maßnahmen umgesetzt werden: – Erstellung von verbindlichen Regeln Zunächst muss sichergestellt werden, dass der richtige Umgang mit Passwörtern für jeden Benutzer eine Pflicht darstellt. Wird das Passwort weitergegeben, kann das Verfahren der Authentisierung, das auf einem gemeinsamen Geheimnis basiert, nicht mehr funktionieren. Darüber hinaus muss es Verfahrensanweisungen geben, wie dies im Alltag zu erreichen ist. Diese Dokumente müssen für jeden verständlich und eindeutig formuliert sein. Der nächste Schritt ist die Unterweisung der Benutzer. Sie müssen wissen, dass es entsprechende Regelungen gibt und dass diese verbindlich sind. Es sollte auch auf Konsequenzen bei Nichteinhaltung (z.B. eine Abmahnung) dieser Regelungen eingegangen werden.


– Auswahl geeigneter Plattformen Systeme müssen auch technisch in der Lage sein, die Regelungen zum richtigen Umgang mit Passwörtern umzusetzen. Werden Betriebssysteme eingesetzt, die keine Zugriffskontrollfunktionen implementieren (wie etwa Windows 9x oder ältere Versionen von Mac OS), ist ein Schutz von Passwörtern auf Dateiebene kaum machbar. – Standortwahl und Sicherheitsbewusstsein Die richtige Standortwahl für ein IT-System ist eine weitere wichtige Voraussetzung für die IT-Sicherheit, die direkt von der physikalischen Sicherheit des Systems abhängt. Es darf einem Angreifer nicht ohne weiteres möglich sein, Arbeitsplätze auszuspionieren, d.h., auch auf physikalischer Ebene muss eine Zugangskontrolle umgesetzt werden. Außerdem sollten sich Benutzer nicht scheuen, Personen anzusprechen und eine Legitimation zu fordern, wenn der Verdacht des Ausspähens von Passwörtern besteht. Gleiches gilt auch für den vermeintlichen Servicetechniker, der beispielsweise versucht, eine Festplatte auszutauschen oder eine Tastaturwanze anzubringen. – Schutz der Dateien Die Passwort-Informationen werden vom Betriebssystem in Passwort-Dateien abgelegt. Hat ein Angreifer Zugriff auf diese Dateien, kann er die Passwörter ermitteln. Die Passwort-Datei darf deshalb im laufenden Betrieb nur für berechtigte Systemdienste zugänglich sein. Es ist darauf zu achten, dass es auch keine Kopien dieser Datei gibt, die eventuell für jeden lesbar sind. – Schutz auf Netzwerkebene Werden Passwörter über nicht vertrauenswürdige Netzwerke übertragen, sollte darauf geachtet werden, dass die gesamte Kommunikation ausreichend verschlüsselt wird. Wird nämlich nur das Passwort verschlüsselt, besteht immer noch die Gefahr eines Brute-Force-Angriffs. Abhängigkeiten Der Schutz von Passwörtern ist eine weitere wichtige Voraussetzung für die Identifikation und Authentisierung. Das beste Passwort nützt nichts, wenn ein Angreifer Kenntnis über das gemeinsame Geheimnis zwischen System und Benutzer erlangt. Darüber hinaus muss auch der Schutz auf den unteren Ebenen gewährleistet sein, d.h. Physikalischer Schutz und Schutz der Dateien sowie Sicherheit im Local Area Network bzw. Sicherheit im Wide Area Network hinsichtlich der Vertraulichkeit und Integrität von Passwörtern, die übertragen werden. Es muss also das Konzept Mehrschichtige Verteidigung implementiert werden.

204 6 Systeme

6.3.4 Zusammenfassung Die einzelnen zuvor beschriebenen Security Patterns können nun im Zusammenhang als Security-Pattern-System, wie in Abbildung 6-1 gezeigt, dargestellt werden. Voraussetzung für den Schutz der Vertraulichkeit und Integrität der Daten, die gespeichert bzw. verarbeitet werden, ist die Authentisierung von Benutzern auf Systemebene. Passwörter stellen – trotz bekannter Unzulänglichkeiten – nach wie vor ein weit verbreitetes Verfahren für diesen Zweck dar. Es zeigt sich, dass Passwörter aufgrund der Angreifbarkeit verschiedener Ebenen durch andere Maßnahmen geschützt werden müssen. Auch hier muss also das Prinzip Mehrschichtige Verteidigung angewendet werden. Authentisierung

Benutzerauthentisierung mit Passwörtern

Schutz der Passwörter

Passwortqualität

Physikalischer Schutz

Sicherheit im Local Area Network

Sicherheit im Wide Area Network

Abb. 6-1 Benutzerauthentisierung

6.4 Schutz der Dateien In Form von Dateien werden Informationen auf IT-Systemen persistent abgelegt. Sie stellen damit eine zentrale IT-Ressource dar, die gegen Angriffe auf Systemebene geschützt werden muss. Zu den bewährten Schutzkonzepten sind insbesondere Zugriffskontrolle von Dateien, Verschlüsselung sensitiver Informationen, Schutz gegen Manipulation sowie Erstellung von Sicherheitskopien zu zählen.

6.4. Schutz der Dateien 205

6.4.1 Zugriffskontrolle von Dateien Typischerweise bieten die Betriebssysteme von IT-Systemen die Möglichkeit, Zugriffsrechte für Dateien zu vergeben. Auf diese Weise werden die Dateien gegen unberechtigten Zugriff geschützt. Kontext Der Kontext dieses Patterns spezialisiert das Security Pattern Identitätsbasierte Zugriffskontrolle. Dabei sind die zu schützenden Objekte Dateien und Verzeichnisse sowie Peripheriegeräte, die von Benutzern verwendet werden. Problem Grundsätzlich gibt es unterschiedliche Arten von Subjekten, wie beispielsweise Benutzer, Benutzergruppen oder aber andere IT-Systeme. Die Dateien und Verzeichnisse müssen nun gegen unberechtigte Zugriffe von Angreifern sowie unbeabsichtigte Zugriffe von regulären Benutzern geschützt werden: – Schutz der Vertraulichkeit Kann ein Angreifer oder ein regulären Benutzer eine Datei oder ein Verzeichnis lesen, so ist die Vertraulichkeit nicht mehr gegeben. Neben Benutzerdaten sind hier insbesondere Systemdaten wie die Passwortdatei zu schützen. – Schutz der Integrität Ist es einem Angreifer oder einem regulärer Benutzer ohne entsprechende Berechtigung möglich Dateien zu modifizieren, kann grundsätzlich die Integrität nicht mehr gewährleistet werden. Hier gilt es, auch Benutzer- und Systemdaten zu schützen. – Schutz der Konfiguration eines Systems Viele Einstellungen der Konfiguration eines Systems werden über bestimmte Programme, die nur von Administratoren verwendet werden sollten, vorgenommen. Ist dies nicht gewährleistet, kann eine Herabsetzung des Sicherheitsniveaus die Folge sein. Ein Angreifer könnte z.B. eine Benutzerkennung mit Passwort erzeugen oder aber seine Rechte erweitern. Dateien unterschiedlichen Typs und mit unterschiedlichem Schutzbedarf müssen gegen die beschriebenen Bedrohungen geschützt werden.

206 6 Systeme

Lösung Unter Nutzung des Betriebssystems kann eine Identitätsbasierte Zugriffskontrolle implementiert werden. In Anlehnung an Fernandez können Berechtigungen wie in Abbildung 6-2 dargestellt betrachtet werden [48]. Identifizierte Subjekte, also Benutzer oder andere IT-Ressourcen, sind berechtigt, auf bestimmte Objekte zuzugreifen. In diesem Fall sind es Dateien und Verzeichnisse. Das entsprechende Recht kann durch eine Zugriffsart (z.B. „lesen“ oder „schreiben“) sowie optional durch ein datenspezifisches Merkmal (z.B. „vertraulich“ oder „streng vertraulich“) ausgedrückt werden. Berechtigung Subjekt

Objekt

Recht Abb. 6-2 Berechtigungen für Dateien und Verzeichnisse

Die Vergabe von Berechtigungen auf Datei- und Verzeichnisebene erfordert die Durchführung mehrerer Schritte, die teilweise initial bei der Inbetriebnahme, teilweise aber auch in regelmäßigen Intervallen durchgeführt werden sollten: – Ermittlung des Schutzbedarfs Typischerweise ist der Schutzbedarf für unterschiedliche Objekte auf einem ITSystem nicht gleich. So haben beispielsweise Benutzerdaten einen anderen Schutzbedarf als etwa Systembibliotheken oder Konfigurationsdateien. Außerdem dürfen bestimmte Programme nur von Administratoren aufgerufen werden (z.B. Benutzerverwaltung), während andere grundsätzlich jedem zugänglich sein sollten (z.B. Textverarbeitung oder Webbrowser). Um den Schutzbedarf ermitteln zu können, muss geklärt werden, welche Rechte notwendig sind, um bestimmte Aktionen mit den Dateien durchführen zu können (also beispielsweise lesen, schreiben, ausführen). Hier muss insbesondere darauf geachtet werden, welches Zugriffskontrollverfahren im jeweiligen System implementiert ist. Danach können die notwendigen Rechte den jeweiligen Dateien zugeordnet werden. Oftmals werden die Systeme mit einer Standardkonfiguration ausgeliefert, so dass ein Zugriffskontrollschema existiert. Da dies jedoch in den meisten Fällen eher auf eine komfortable Benutzung ausgelegt ist, sollte unbedingt eine Überprüfung und Anpassung der Zugriffsrechte vorgenommen werden. Es ist ratsam, hier das Prinzip Minimale Privilegien umzusetzen. Hilfreich sind Programme, die einen bei dieser Aufgabe unterstützen. Das in Perl geschriebene Skript


Check.pl durchsucht beispielsweise auf Unix/Linux-Systemen das gesamte Dateisystem nach Dateien, die mit Administratorenrechten (suid, sgid, sticky) ausgeführt werden oder schreibbar sind [2]. Auf diese Weise können effizient Dateien ermittelt werden, die möglicherweise nicht hinreichend geschützt sind. – Bildung von Benutzergruppen Benutzer mit identischen Tätigkeitsprofilen werden zu Benutzergruppen zusammengefasst. Dies sind beispielsweise Mitarbeiter, Gäste und Administratoren. Weiterhin können Benutzer nach Zugehörigkeit zu bestimmten Projektgruppen zugeordnet werden. Es ist durchaus möglich, Benutzer mehr als einer Gruppe zuzuordnen. – Implementierung Betriebssysteme bieten typischerweise grafische Schnittstellen oder kommandozeilenorientierte Werkzeuge an, um Benutzer und Gruppen einzurichten, eine entsprechende Zuordnung vorzunehmen sowie Rechte zu vergeben. Manchmal können die entsprechenden Dateien, in denen die Konfigurationsdaten für die Zugriffskontrolle abgelegt werden, auch direkt bearbeitet werden (z.B. bei Linux-Systemen die Datei /etc/group, in der die Zuordnung von Benutzerkennungen und Benutzergruppen festgehalten ist). Da diese Dateien gut dokumentiert und intuitiv nachvollziehbar sind, besteht gegenüber von Hilfsprogrammen der Vorteil, dass der Administrator eine bessere Kontrolle darüber hat, welche Rechte tatsächlich vergeben werden. Die Vorteile dieses Ansatzes sind, dass er eine Reihe von Subjekten wie Benutzer und Benutzergruppen umfasst. Die Zugriffsobjekte können einzelne Dateien, Verzeichnisse sowie rekursive Strukturen von Verzeichnissen und Dateien sein. Es ist sogar möglich, Zugriffsberechtigungen implizit zu vergeben, wenn beispielsweise der Zugriff auf ein Verzeichnis auf die darin enthaltenen Dateien übertragen wird. Als nachteilig kann sich erweisen, dass nicht alle Systeme erlauben, Berechtigungen auf die beschriebene Weise zu vergeben. Die meisten Betriebssysteme verwenden zudem lediglich Berechtigungen zum Lesen, Schreiben und Ausführen von Dateien, obwohl grundsätzlich weitere Berechtigungen auf einem höheren Abstraktionsniveau möglich sind. Abhängigkeiten Dieses Security Pattern stellt den Schutz von Dateien dar, wie er sich in Unix, Linux, Windows und anderen Betriebssystemen bewährt hat. Das Security Pattern ist eine Spezialisierung von Identitätsbasierte Zugriffskontrolle. Es setzt allgemein eine Identifikation und Authentisierung voraus. Oftmals wird hierfür eine Benutzerauthentisierung verwendet. Bei der Vergabe von Berechtigungen sollte beachtet werden, dass Minimale Privilegien implementiert werden.

208 6 Systeme

6.4.2 Verschlüsselung sensitiver Informationen Für besonders schutzbedürftige Informationen, bei denen reguläre Mechanismen der Zugriffskontrolle zur Wahrung der Vertraulichkeit nicht ausreichen, bietet es sich an, die entsprechenden Dateien zu verschlüsseln. Kontext Es wird davon ausgegangen, dass eine Zugriffskontrolle von Dateien umgesetzt worden ist. Dies beinhaltet zudem die Identifikation und Authentisierung von Benutzern bzw. IT-Ressourcen, die auf die Daten eines IT-Systems zugreifen wollen. Problem Bei hohem Schutzbedarf kann es sein, dass der Schutz durch die Zugriffskontrolle von Dateien nicht genügt, um die Vertraulichkeit der Inhalte einer Datei ausreichend zu schützen. Dies kann beispielsweise in folgenden Fällen relevant werden: – Unzureichender Schutz Das zugrunde liegende IT-System bietet keine ausreichenden Verfahren zur Zugriffskontrolle. Es muss davon ausgegangen werden, dass es von einem Angreifer leicht ausgehebelt werden kann. Dies wäre dann der Fall, wenn es dem Angreifer gelänge, den Datenträger bzw. das gesamte IT-System zu stehlen. – Komplexe Beziehungen Die Beziehungen zwischen Klassen von Dateien bzw. Verzeichnissen und Benutzern sind derart komplex, dass es nicht möglich ist, eine entsprechende Sicherheitsrichtlinie mit Berechtigungen umzusetzen. Einem Angreifer darf es auch dann nicht gelingen, die Vertraulichkeit von Daten zu verletzen, wenn er Zugriff auf die entsprechenden Dateien und Verzeichnisse erhält. Lösung Werden Daten mit hohem Schutzbedarf verschlüsselt, können Unzulänglichkeiten in Zugriffskontrollverfahren kompensiert werden. Selbst wenn es einem Angreifer gelingt, Zugriff auf die Dateien und Verzeichnisse zu erhalten, kann er nichts mit den verschlüsselten Informationen anfangen, da er nicht im Besitz der entsprechenden kryptografischen Schlüssel ist. Es kann je nach Anzahl der zu schützenden Dateien sinnvoll sein, lediglich einzelne Dateien zu verschlüsseln oder aber ganze Verzeichnisse bzw. bestimmte Partitionen der Festplatte. Bei maximalem Schutzbedarf kann die Verschlüsselung der gesamten Festplatte sinnvoll sein.


Auch hier muss im Rahmen einer Risikoanalyse abgewägt werden, ob die zusätzliche Komplexität und Einbußen bei der Performance bei einer Verschlüsselung in Kauf genommen werden können. Die Verschlüsselung sensitiver Informationen ist ein Instrument, um Verfahren zur Zugriffskontrolle zu verstärken. Es muss sehr darauf geachtet werden, dass keine unverschlüsselten Versionen der Dateien existieren. Abhängigkeiten Dieses Security Pattern spezialisiert das allgemeine Konzept der Verschlüsselung. Es wird bei hohem Schutzbedarf benötigt, wenn die Möglichkeiten der Zugriffskontrolle von Dateien nicht ausreichen. Neben Einbußen bei der Performanz erkauft man sich das Problem des Managements von kryptografischen Schlüsseln (siehe Lehtonen und Pärssinen [70]). Weiterhin muss darauf geachtet werden, dass die Verschlüsselung nicht umgangen werden kann, d.h, eine Mehrschichtige Verteidigung sollte umgesetzt werden. 6.4.3 Schutz gegen Manipulation Ein Angreifer kann Dateien ersetzen oder verändern. Insbesondere bei Konfigurationsdateien kann dies fatale Auswirkungen auf die Sicherheit eines IT-Systems haben. Daher müssen Änderungen von Dateien erkannt werden, damit entsprechend reagiert werden kann. Kontext Dieses Security Pattern konkretisiert den Schutz der Integrität auf Ebene von ITSystemen. Dabei werden insbesondere Dateien betrachtet, die sicherheitsrelevante Informationen enthalten können. Es wird davon ausgegangen, dass zwischen Benutzer und IT-System kein gemeinsames Geheimnis und keine entsprechenden kryptografischen Schlüssel ausgetauscht worden sind. Problem Ein Angreifer kann versuchen, Zugang zu einem IT-System zu erhalten, indem beispielsweise sicherheitsrelevante Konfigurationsdateien manipuliert werden. Werden solche Änderungen nicht erkannt, kann der Angreifer zunächst unbemerkt das kompromittierte IT-System nutzen. Folgende Angriffe gefährden die Integrität von Dateien, die von einem IT-System verwaltet werden: – Trojaner Trojaner sind Programme, die sich zunächst so verhalten, wie der Benutzer dies erwartet. Im Hintergrund laufen aber Aktionen ab, die vom Angreifer, der dem Benutzer den Trojaner untergeschoben hat, kontrolliert werden. So können

210 6 Systeme

beispielsweise Tastatureingaben mitgelesen werden (wichtig zum Abfangen von Passwörtern). – Hintertüren Hintertüren (engl. Backdoor) sind Programme, die nach einem erfolgreichen Angriff hinterlassen werden, um zu einem späteren Zeitpunkt einen weiteren Zugriff zu ermöglichen. Selbst wenn die eigentliche Verletzlichkeit, die zu dem ersten Angriff geführt hat, erkannt und behoben worden ist, hat der Angreifer immer noch die Möglichkeit, das IT-System zu missbrauchen. – Manipulierte Konfigurationsdatei Insbesondere bei Unix-und Linux-Systemen werden sicherheitsrelevante Konfigurationsdaten in Dateien abgelegt. Gelingt es einem Angreifer, diese zu verändern oder zu ersetzen, ist der vermeintliche Schutz nicht mehr gewährleistet. Ein Beispiel hierfür ist die Passwort-Datei. Der Angreifer kann einen neuen Benutzer mit einem entsprechenden Passwort anlegen und hat somit Zugang zum System. Weitere lohnende Ziele sind die hosts.allow-Datei, in der festgelegt werden kann, welche IP-Adressen Zugang zum IT-System haben. Ähnlich verhält es sich mit der Konfiguration einer Firewall. Ein Angreifer könnte sich hier grundsätzlich beliebige Routen in interne Netze freischalten. – Rootkit Rootkits sind Programme, die einem Angreifer dabei helfen, unentdeckt zu bleiben. Dabei werden Systemprogramme ersetzt, die auf die Anwesenheit eines Angreifers schließen lassen (z.B. die Liste der Prozesse oder der angemeldeten Benutzer). Außerdem können Log-Dateien manipuliert werden, so dass keine Spuren hinterlassen werden. – Versteckte Dateien und Verzeichnisse Oftmals werden auch versteckte Verzeichnisse angelegt, um dort eigene ausführbare Software zu installieren. Diese Verzeichnisse können aber auch als „Zwischenlager“ für den Austausch von Raubkopien und anderen illegalen Daten verwendet werden. Lösung Mithilfe einer geeigneten Hash-Funktion, die vorab festgelegt wird, werden von den zu schützenden Dateien MDC berechnet. Diese Werte werden zunächst sicher gespeichert. Soll nun festgestellt werden, ob Dateien manipuliert worden sind, werden die MDC-Werte erneut berechnet und mit den abgespeicherten Werten verglichen. Stimmen beide MDC überein, so sind die Dateien nicht verändert worden. Ein Werkzeug hierzu ist tripwire, das als Open-Source-Version frei erhältlich ist [130]. Tripwire berücksichtigt bei der Bildung von Hash-Werten auch andere


Attribute einer Datei, die sich nicht ändern dürfen, wie die Größe oder das Erstellungsdatum. Bei der Implementierung dieses Konzepts muss besonders auf die Verhältnismäßigkeit geachtet werden. Werden beispielsweise Dateien oder Verzeichnisse überwacht, die sich öfter ändern (temporäre Verzeichnisse, Log-Dateien etc.), kann die Verifikation der Prüfsummen wegen vieler Falschmeldungen nicht effizient durchgeführt werden. Dies kann schließlich dazu führen, dass das Konzept nicht mehr verwendet wird bzw. die Ergebnisse einer Prüfung ignoriert werden. Abhängigkeiten Da die Hash-Werte selbst wieder in einer Datei, die ein lohnendes Ziel für einen Angriff sein kann, abgelegt werden, tritt hier ein Bootstrapping-Problem auf. Diese Datei darf also nicht auf dem IT-System selbst abgelegt werden. Sinnvoll ist beispielsweise, die Hash-Werte auf einem nicht schreibbaren Medium abzulegen (z.B. Diskette mit Kopierschutz oder CD-ROM). Eine andere Möglichkeit ist es, die Datei auf einem anderen, besonders geschützten System abzulegen und die Verifikation dort vorzunehmen. Ergänzend zum Schutz gegen Manipulation müssen Verfahren zum Erkennen von Angriffen initiiert werden, da es sein kann, dass ein Angreifer Dateien manipuliert, die nicht überwacht werden. Versucht er nun auf dieser Basis das System zu attackieren, kann dies aufgrund von Unregelmäßigkeiten festgestellt werden, was der Umsetzung des Security Patterns Mehrschichtige Verteidigung entspricht. 6.4.4 Erstellung von Sicherheitskopien Um dem Verlust von Daten im Falle von Angriffen vorzubeugen, müssen regelmäßig Sicherheitskopien erstellt werden. Diese Maßnahme schützt auch gegen unvorhergesehene Fehler im System – wie beispielsweise defekte Festplatten. Kontext Es wird davon ausgegangen, dass verschiedene Maßnahmen zum Schutz von Dateien umgesetzt worden sind. Dazu gehören die Zugriffskontrolle von Dateien, die Verschlüsselung sensitiver Informationen sowie der Schutz gegen Manipulation. Problem Die Maßnahmen zum Schutz von Dateien können sich als unzureichend erweisen oder aber eine Verletzlichkeit aufweisen, die einen Angriff möglich machen. Folgende Probleme können zu einem Verlust von Verfügbarkeit und Integrität der Daten führen:

212 6 Systeme

– Modifikation und Löschen von Dateien Ein Angreifer kann sicherheitsrelevante Daten ändern. Dazu gehören Konfigurationsdateien, aber auch Dokumente, die vertrauliche Informationen erhalten. Im Zusammenhang mit Viren wurde beobachtet, dass mehr oder weniger gezielt Dateien manipuliert oder sogar gelöscht worden sind. – Systemfehler Systemfehler sind zwar nicht zwangsläufig Resultate eines Angriffs, sie können aber auch dazu führen, dass Daten unwiederbringlich verloren gehen. Lösung Die letzte Chance, um verloren gegangene Daten wieder herzustellen, ist die Erstellung von Sicherheitskopien. Dabei müssen folgende Schritte durchgeführt werden: – Planung Hier muss festgelegt werden, welche Dateien gesichert werden sollen. Bei der Erstellung eines Plans kann möglicherweise auf die Schutzbedarfsgruppen, die im Rahmen der Planung einer Zugriffskontrolle von Dateien ermittelt worden sind, zurückgegriffen werden. Anwendungs- und Systemprogramme müssen beispielsweise nicht unbedingt gesichert werden, da sie jederzeit neu installiert werden können. Viel wichtiger sind Konfigurationsdaten und die Dateien der Benutzer. Dazu gehören Dokumentationen oder Quelltexte von Eigenentwicklungen. – Werkzeuge installieren und konfigurieren Auf technischer Ebene müssen geeignete Hardware und entsprechende Software ausgewählt und konfiguriert werden. Dabei wird grundsätzlich zwischen lokalen und vernetzten Ansätzen unterschieden. – Testen Besonders wichtig ist es zu testen, ob die ausgewählten Dateien tatsächlich gesichert worden sind. Durch die Wiederherstellung einer Sicherungskopie kann zudem der Ernstfall geprobt werden. So wird klar, ob der Vorgang an sich lückenlos dokumentiert und von jedem nachvollziehbar ist. Sicherheitskopien sollten regelmäßig durchgeführt werden. Es ist sinnvoll, mehrere Versionen aufzubewahren, so dass die Wiederherstellung eines definierten Zustands grundsätzlich möglich ist. Damit nicht immer alle Dateien gesichert werden müssen, sollten die Werkzeuge inkrementelle Sicherheitskopien unterstützen, d.h., es werden nur die Dateien gesichert, die sich seit der letzten Durchführung einer Sicherheitskopie verändert haben.


Abhängigkeiten Die Erstellung von Sicherheitskopien kann durch Maßnahmen zum Schutz gegen Manipulation und ggf. zur Verschlüsselung sensitiver Informationen ergänzt werden. Auch hier tritt wieder ein Bootstrapping-Problem auf. Die Medien, auf denen die Sicherheitskopien abgespeichert werden, können wiederum angegriffen werden. Besonders wichtig ist hier Physikalischer Schutz, um zu gewährleisten, dass die Medien nicht manipuliert worden sind oder gestohlen werden können. 6.4.5 Zusammenfassung Die einzelnen zuvor beschriebenen Security Patterns können nun im Zusammenhang als Security-Pattern-System, wie in Abbildung 6-3 gezeigt, dargestellt werden. Schutz der Dateien

Zugriffskontrolle von Dateien

Schutz gegen Manipulation

Erstellung von Sicherheitskopien

Verschlüsselung sensitiver Informationen

Identitätsbasierte Zugriffskontrolle

Schutz der Integrität

Verschlüsselung Abb. 6-3 Schutz von Dateien

Dabei werden die komplexeren Strukturen und Abhängigkeiten vom Schutz der Dateien deutlich. Neben Security Patterns, die vorausgesetzt werden, kommen hier auch Spezialisierungen von Basisfunktionen (z.B. Verschlüsselung oder Schutz der Integrität) zum Tragen.

214 6 Systeme

Vorausgesetzt wird zunächst die Zugriffskontrolle von Dateien, die durch Verschlüsselung sensitiver Informationen ergänzt werden kann. Weiterhin muss der Schutz gegen Manipulation gewährleistet sein. Wichtig ist auch die Erstellung von Sicherheitskopien, falls andere Maßnahmen fehlschlagen. So können Dateien im Zweifelsfall wiederhergestellt werden. Auch hier muss das Prinzip Mehrschichtige Verteidigung angewendet werden. Zudem ist es oftmals notwendig, im Rahmen eines Bootstrapping-Prozesses die Grundlagen für bestimmte Schutzmaßnahmen zu schaffen.

6.5 Installation und Konfiguration Bereits bei der Installation eines IT-Systems und insbesondere des Betriebssystems müssen die Fundamente für den sicheren Betrieb gelegt werden. Während des Bootstrapping des Systems werden grundlegende Voraussetzungen für den sicheren Betrieb geschaffen. Der nächste Schritt ist das Minimales System, um unsicheren Standardkonfigurationen entgegenzuwirken. Weiterhin ist es notwendig, konsequent eine Zeitnahe Installation von Updates vorzunehmen, um das Zeitfenster, in dem ein System anfällig für neu aufgedeckte Verletzlichkeiten ist, zu minimieren. 6.5.1 Bootstrapping des Systems Im Betrieb eines IT-Systems gelten andere Rahmenbedingungen als während der Planung und Entwicklung. Um den operativen Anforderungen gerecht werden zu können, müssen initial Maßnahmen ergriffen werden, um von Anfang an eine Basis für weitere Schutzvorkehrungen treffen zu können. Kontext Es wird davon ausgegangen, dass ein IT-System entwickelt bzw. gekauft worden ist. Das System soll nun in Betrieb genommen werden. Typischerweise werden moderne IT-Systeme in einen Netzwerkverbund integriert. Dieses Security Pattern spezialisiert das Security-Pattern Bootstrapping im Kontext von IT-Systemen. Problem Schutzmaßnahmen bauen im Allgemeinen auf anderen Schutzmaßnahmen auf, die oftmals als implizit vorausgesetzt werden. Die Grundlagen müssen bereits bei der Installation und Inbetriebnahme eines IT-Systems gelegt werden, da sonst keine Gewissheit besteht, ob das System nicht kompromittiert worden ist. Die Angriffe können nun im Kontext von IT-Systemen konkretisiert werden:

6.5. Installation und Konfiguration 215

– Maskierung/Fälschung von vertrauenswürdigen Quellen Nahezu alle Linux-basierten Systeme können heute mit Protokollen wie http oder ftp installiert und aktualisiert werden. Auch bei Microsoft Windows-Systemen ist diese Vorgehensweise mittlerweile üblich. Ein Angreifer kann nun versuchen, eine vermeintlich vertrauenswürdige Quelle zu imitieren und dem Eigentümer des IT-Systems so manipulierte Software unterzuschieben. – Ausspähen Werden bei der Installation und Inbetriebnahme Netzwerkprotokolle verwendet, besteht die Möglichkeit, diese abzuhören. Oftmals werden dabei Passwörter im Klartext übertragen, so dass der Angreifer möglicherweise ein leichtes Spiel hat. Interessant ist auch das Ausspähen bei der Verwendung von Funktastaturen. Hier ist es möglich, mit einem zweiten Empfänger die Tastenanschläge abzuhören. – Manipulation Ein Angreifer kann versuchen, das System während der Inbetriebnahme zu manipulieren. Denkbar ist beispielsweise ein manipuliertes Installationsmedium (z.B. CD-ROM), auf dem Trojaner und Hintertüren enthalten sind und dem Angreifer somit zu einem späteren Zeitpunkt einen Zugang ermöglichen. Weiterhin ist der Versuch denkbar, bereits auf Hardwareebene zu manipulieren, indem beispielsweise Tastaturwanzen o.Ä. angebracht werden. Dies setzt allerdings einen physikalischen Zugang voraus (z.B. bei der Auslieferung des Systems). Lösung Um initial eine Basis für weitere Schutzmaßnahmen zu schaffen, muss das IT-System zunächst isoliert werden. Dabei ist auch auf Systemebene zwischen der Offlineund der Out-Of-Band-Variante zu unterscheiden: – Out of Band Werden über eine Netzwerkverbindung Komponenten des Systems installiert oder aktualisiert, muss darauf geachtet werden, dass die Quellen nicht manipuliert worden und authentisch sind. Dies kann mithilfe von Hash-Werten geschehen, die sowohl über das entsprechende Software-Paket als auch über ein gemeinsames Geheimnis zwischen IT-System und Installationsquelle gebildet werden. Dieses Geheimnis muss dann über einen anderen Kanal verifiziert werden. Ist dies nicht möglich, bietet es sich an, verschiedene Quellen auszuwählen. So ist die Wahrscheinlichkeit, dass es einem Angreifer gelungen ist, alle Quellen zu manipulieren, geringer. In diesem Fall können abweichende Hash-Werte erkannt werden.

216 6 Systeme

– Offline Manipulationen über ein Netzwerk können gänzlich ausgeschlossen werden, wenn das Bootstrapping offline erfolgt. In diesem Fall muss aber darauf geachtet werden, dass die Installationsmedien nicht manipuliert worden sind. Dies kann beispielsweise durch geeignete Echtheitszertifikate des Herstellers, dem in diesem Fall vertraut werden muss, gewährleistet werden. Besonders zu beachten ist auch, dass die Hardware nicht manipuliert worden ist. Dies kann durch entsprechende Siegel des Herstellers kontrolliert werden. Abhängigkeiten Eine wichtige Voraussetzung für das Bootstrapping des Systems ist ein Physikalischer Schutz der Umgebung des IT-Systems. Auf diese Weise kanneine Reihe von Manipulationsmöglichkeiten verhindert werden. Durch Maßnahmen zum Schutz der Integrität können Manipulationen der Installationsmedien erkannt werden. Die Authentizität der Installationsquellen kann zudem durch Verfahren zur Identifikation und Authentisierung gewährleistet werden. Neben dem Bootstrapping des Systems müssen ein Minimales System sowie eine Zeitnahe Installation von Updates gegeben sein, um die Sicherheit im Betrieb aufrechterhalten zu können. 6.5.2 Minimales System IT-Systeme werden oftmals mit Einstellungen und Diensten ausgeliefert, die vom Sicherheitsstandpunkt aus betrachtet als kritisch einzustufen sind, da sie Verletzlichkeiten aufweisen und einem Angreifer damit die Möglichkeit zu einem Angriff geben können. Kontext Es wird davon ausgegangen, dass durch ein Bootstrapping des Systems eine sichere Installation und Konfiguration erfolgt ist. Weiterhin nehmen wir an, dass Maßnahmen zum physikalischen Schutz des Systems sowie entsprechende Maßnahmen zum Schutz auf der logischen Ebene getroffen worden sind. Problem Viele Systeme werden standardmäßig mit Diensten und Einstellungen installiert, die nicht sicher sind. Dabei handelt es sich einerseits um Implementierungsfehler, andererseits um Fehler in der Standardkonfiguration. Der Grund hierfür ist wohl darin zu suchen, dass die Benutzbarkeit des Systems nach Ansicht vieler Anbieter an erster Stelle steht. Dies kann zu folgenden Möglichkeiten für Angriffe führen:


– Standarddienste Oft werden Internet-Dienste wie http- oder ftp-Server standardmäßig installiert und aktiviert. Dies kann sogar ohne Kenntnis des Eigentümers des IT-Systems erfolgen, wenn die Installationsoptionen sehr umfangreich und unübersichtlich sind. Laufen diese Dienste und sind zudem so konfiguriert, dass prinzipiell jeder sie benutzen kann, ist das zugrunde liegende IT-System grundsätzlich gefährdet. Dies gilt insbesondere dann, wenn es sich bei den entsprechenden Diensten um ältere Versionen handelt, die bekannte Verletzlichkeiten aufweisen. – Standardbenutzerkennungen Für bestimmte Anwendungen wie Datenbanken werden Standardbenutzerkennungen eingerichtet. Damit kann ein Angreifer bereits gezielt Brute-Force-Angriffe durchführen. Problematisch wird dies insbesondere dann, wenn zusätzlich Standardpasswörter verwendet werden. – Standardpasswörter Manche Systeme werden mit Standardpasswörtern oder mit gar keinem Passwort ausgeliefert. Hierzu sind auch Master-Passwörter zu zählen, die von Herstellern gewissermaßen als Hintertür zur Wartung vergeben werden. Angriffe sind somit außerordentlich trivial durchzuführen. Laufen Dienste unbemerkt und ungeschützt im Hintergrund, kann ein Angreifer das System unbesorgt als Basis für weitergehende Angriffe, als Zwischenlager für illegale Dateien usw. missbrauchen. Lösung Es sollten nur Dienste installiert und aktiviert werden, die unbedingt benötigt werden. Jede weitere Komponente eines Systems kann Verletzlichkeiten aufweisen und somit die Sicherheit des gesamten Systems gefährden. Viele Installationsroutinen bieten Profile für minimale Varianten eines Systems an. Aufbauend auf einem solchen Kernsystem können nach und nach die benötigten Komponenten nachinstalliert und konfiguriert werden. Um an Effizienz zu gewinnen, können gehärtete Systeme repliziert werden, wenn dies die Einsatzumgebung erlaubt (bei Arbeitsplatzrechnern, die grundsätzlich identisch sein können, ist dies beispielsweise möglich). Weiterhin müssen Standardbenutzerkennungen gelöscht werden, falls sie nicht verwendet werden. Gleiches gilt für Kennungen von Personen, die ein Unternehmen verlassen haben. In diesem Fall sollten die Benutzerkennungen deaktiviert werden. Bei Passwörtern muss zudem darauf geachtet werden, dass initiale Passwörter geändert werden müssen. Dies wird von einigen Systemen unterstützt. Andernfalls kann auch im Rahmen eines Passwort-Audits überprüft werden, ob das Passwort geändert worden ist. Standardpasswörter sollten zudem umgehend geändert werden.

218 6 Systeme

Abhängigkeiten Mit diesem Security Pattern werden die Prinzipien Konservative Vorgehensweise und Einfachheit umgesetzt. Dabei muss in der Praxis immer ein Kompromiss zwischen Sicherheit und Benutzbarkeit eingegangen werden. 6.5.3 Zeitnahe Installation von Updates Sicherheit weist eine Zeitabhängigkeit auf. Wird eine noch nicht bekannte Verletzlichkeit aufgedeckt, ist die Sicherheit des betroffenen IT-Systems grundsätzlich nicht mehr gegeben. Kontext Ein IT-System ist sicher installiert und konfiguriert worden. Es kann davon ausgegangen werden, dass Maßnahmen zum physikalischen Schutz des Systems sowie entsprechende Maßnahmen zum Schutz auf der logischen Ebene getroffen worden sind. Problem Da IT-Systeme komplex sind, ist es nahezu unmöglich, alle Verletzlichkeiten im Vorfeld zu erkennen. Typischerweise treten in jedem System sicherheitsrelevante Probleme erst dann auf, wenn IT-Systeme in größerem Maßstab und im Alltagsbetrieb verwendet werden. Dabei sind insbesondere folgende Aspekte problematisch: – Publikation von Lösungen Obwohl die meisten Anbieter versuchen, Lösungen für bekannt gewordene Verletzlichkeiten anzubieten, dauert es immer eine gewisse Zeit vom Zeitpunkt der Publikation von Informationen über eine Verletzlichkeit bis zur Bekanntgabe einer Lösung. Der Anbieter benötigt schließlich Zeit, um eine praktikable Lösung zu finden, die das Problem tatsächlich beseitigt (und nach Möglichkeit nicht zusätzliche Probleme schafft). – Vorbereitung und Umsetzung Selbst wenn bekannt ist, wie eine Verletzlichkeit beseitigt werden kann, sind die betroffenen Systeme noch immer gefährdet. Der Eigentümer des IT-Systems muss zunächst entsprechende Maßnahmen einleiten und die Systeme aktualisieren. Dieses Zeitfenster (engl. Window of Exposure) schafft einem Angreifer die Gelegenheit, die Verletzlichkeit auszunutzen und das betroffene IT-System zu attackieren.


Lösung Das Zeitfenster, in dem die Möglichkeit zum Angriff besteht, muss auf ein Minimum reduziert werden. Dabei haben sich folgende Maßnahmen bewährt: – Informationsbeschaffung und -auswertung Zunächst ist es wichtig, sich einen Überblick über relevante Informationsquellen zu verschaffen. Es ist empfehlenswert, sich dabei nicht nur auf die Hersteller zu beschränken, sondern vielmehr auf einen Mix aus Informationsquellen zu setzen (die Angreifer machen dies vermutlich genauso). Nur so kann gewährleistet werden, möglichst umfassende Informationen über ein Problem zu erhalten. Da dies sehr zeitaufwändig werden kann, ist es eventuell sinnvoll, einen Mitarbeiter mit dieser Aufgabe zu betrauen bzw. einen entsprechenden Informationsdienst zu abonnieren. – Provisorische Lösungen Besonders wichtig ist es, je nach Gefährdungslage nicht bis zur Veröffentlichung einer Lösung zu warten. Bei hohem Risiko kann die betroffene Komponente beispielsweise sofort deaktiviert werden, falls dies die Situation zulässt. Oftmals wird auch von Dritten zu provisorischen Lösungen geraten, die umgesetzt werden können, bis ein Update des Herstellers verfügbar ist. Idealerweise wird die Verletzlichkeit durch das Einspielen eines Patches oder eines Hersteller-Updates behoben. Hier muss allerdings sichergestellt werden, dass keine neuen Probleme entstehen. Es sollte darauf geachtet werden, welche Erfahrungen andere mit dem Update gemacht haben. Abhängigkeiten Dieses Security Pattern setzt das Prinzip Konservative Vorgehensweise um. Außerdem entspricht die Anwendung dieses Security-Patterns einer Absicherung der schwächsten Stellen im laufenden Betrieb. Es setzt voraus, dass die Security-Patterns Bootstrapping des Systems sowie Minimales System angewendet worden sind. Insgesamt muss initial ein Zustand der Sicherheit erreicht worden sein. 6.5.4 Zusammenfassung Die einzelnen zuvor beschriebenen Security Patterns können nun im Zusammenhang als Security-Pattern-System, wie in Abbildung 6-4 gezeigt, dargestellt werden. Dabei werden komplexere Zusammenhänge zwischen Security Patterns auf unterschiedlichen Abstraktionsebenen deutlich. Insbesondere bei der Installation und Konfiguration eines IT-Systems sollten die Prinzipien Einfachheit und Konservative

220 6 Systeme

Vorgehensweise umgesetzt werden. Initial sind Abhängigkeiten zu den Security Patterns Physikalischer Schutz, Schutz der Integrität sowie Identifikation und Authentisierung zu beachten. Installation und Konfiguration

Bootstrapping des Systems Physikalischer Schutz

Minimales System

Zeitnahe Installation von Updates

Schutz der Integrität Einfachheit


Konservative Vorgehensweise Absicherung der schwächsten Stellen Abb. 6-4 Installation und Konfiguration

6.6 Erkennen von Angriffen Die meisten Einbrüche in Rechnersysteme bleiben unentdeckt, da Systemmeldungen (Logs) deaktiviert sind oder nicht konsequent überwacht werden. Die meisten Betriebssysteme bieten allerdings die Möglichkeit an, Logs einzuschalten und in Dateien oder Datenbanken zu speichern. Es existieren zudem Schnittstellen, die es erlauben, system- und plattformübergreifend Logs zu sammeln und auszuwerten. Geschieht die Auswertung online, lässt sich hiermit eine Alarmierung aufbauen, die schon nahe an ein Intrusion Detection System (IDS) herankommt. Besonders wichtig ist dabei die Aktivierung von Logging-Mechanismen sowie das darauf aufbauende Filtern, auswerten und reagieren relevanter Informationen.

6.6. Erkennen von Angriffen 221

6.6.1 Aktivierung von Logging-Mechanismen Angriffe können nur erkannt werden, wenn genügend Informationen über Benutzeraktivitäten und Systemereignisse festgehalten werden. Dazu müssen zunächst die Logging-Mechanismen eines IT-Systems aktiviert werden. Kontext Ein IT-System ist sicher installiert und konfiguriert worden. Es kann davon ausgegangen werden, dass Maßnahmen zum physikalischen Schutz des Systems sowie entsprechende Maßnahmen zum Schutz auf der logischen Ebene getroffen worden sind. Problem Angriffe können grundsätzlich erkannt werden, wenn mithilfe von Systemmeldungen Abweichungen von einem bekannten Sollzustand des IT-Systems auftreten. Diese Art der Protokollierung wird als Logging, die Dateien, die dabei erzeugt werden, als Logs bezeichnet. Ein Abweichung liegt z.B. dann vor, wenn sonntags Aktionen von einem Benutzer durchgeführt wurden und dieser eigentlich am Wochenende nicht arbeitet. IT-Systeme bieten im Allgemeinen die Möglichkeit, solche Ereignisse aufzuzeichnen. Wird man allerdings unvorbereitet mit einem Einbruch konfrontiert, besteht zudem die Gefahr, dass durch panische und unüberlegte Aktionen wertvolle Spuren (z.B. eingeschleuste Programme, Log-Meldungen usw.), die von einem Angreifer hinterlassen wurden, vernichtet werden könnten. Werden Logging-Mechanismen gar nicht aktiviert, werden Unregelmäßigkeiten, die auf Angriffe schließen lassen, überhaupt nicht erkannt. Damit können folgende Maßnahmen nicht durchgeführt werden: – Forensische Analyse Mithilfe von Systemmeldungen lässt sich herausfinden, was genau ein Angreifer getan hat. Nur so besteht Gewissheit, ob ein System ernsthaft zu Schaden gekommen ist oder nicht. – Alarmierung Es ist grundsätzlich möglich, Angriffe frühzeitig zu erkennen und zu unterbinden. Dies setzt voraus, dass im Fall verdächtiger Vorkommnisse frühzeitig eine Alarmierung erfolgt. – Wiederaufnahme des Betriebs Mithilfe von Aufzeichnungen kann der Eigentümer des IT-Systems herausfinden, welche Komponenten durch einen Angriff betroffen waren. Dies erleichtert die

222 6 Systeme

Wiederaufnahme des Betriebs nach einem Angriff, da so beispielsweise gezielt Sicherungskopien wieder eingespielt werden können. – Strafverfolgung Im Schadensfall ist die Aufzeichnung von Systemmeldungen möglicherweise der einzige Beweis für eine Straftat. Lösung Die Komponenten zur Erzeugung von Systemmeldungen müssen identifiziert, konfiguriert und aktiviert werden. Die Informationen müssen ausreichen, um eine Abweichung von einem Sollzustand zu erkennen. Ist dies nicht möglich, müssen entsprechende Komponenten nachinstalliert werden. Wichtige Systemmeldungen sind beispielsweise: – Erzeugen, ändern und löschen von relevanten Dateien – Änderungen von Sicherheitsmerkmalen (z.B. Zuweisung eines Benutzers zu einer neuen Gruppe oder Erteilung und Widerruf von Berechtigungen) – Ergebnisse von Authentisierung oder Zugriffskontrolle (also Identität verifiziert bzw. Zugriff erlaubt oder verweigert) – Verwendung externer Laufwerke und Netzwerkressourcen (z.B. Einbinden von ZIP-Medien oder Floppies, Nutzung von Netzlaufwerken via NFS oder Samba) – Irreguläre Bootvorgänge können ebenfalls auf Manipulationen hindeuten. Dies sollte nur von Administratoren durchgeführt werden. Logs, die zur Funktionsanalyse verwendet werden, können lokal auf dem Rechner verbleiben, da sie so in regelmäßigen Intervallen leichter analysiert werden können. Ein täglich automatisch gestartetes Skript wertet beispielsweise Log-Dateien aus, erstellt eine kurze, aussagekräftige Zusammenfassung und sendet das Ergebnis als E-Mail an den Administrator. Weiterhin wird so ein unnötiges Einloggen in das System vermieden. Eine andere Möglichkeit wäre es, alle zu protokollierenden Meldungen zu einem zentralen Log-Server zu senden und dort weiter zu verarbeiten, mit dem Vorteil, dass mehrere Rechner mit einem Auswertungsprogramm analysiert werden können. Die Konfiguration dieses Programms wird allerdings mit zunehmender Rechnerzahl immer unübersichtlicher.


Abhängigkeiten Dieses Security Patterns spezialisiert die Basisfunktion Audit im Kontext von ITSystemen. Die erwähnten Maßnahmen arbeiten auf Basis von Dateien bzw. übertragen Informationen über ein Netzwerk. Sie sind damit prinzipiell angreifbar und müssen zusätzlich geschützt werden. Es muss insbesondere der Schutz der Dateien gewährleistet werden. Bei verteilten Logging-Verfahren ist zudem die Sicherheit im Local Area Network und die Sicherheit durch Firewalls als Ergänzung zu betrachten. Schließlich besteht eine Abhängigkeit zum Security Pattern Filtern, auswerten und reagieren. 6.6.2 Filtern, auswerten und reagieren Insbesondere beim Einsatz von mehreren IT-Systemen fallen schnell große Mengen von Daten an. Da diese manuell nicht mehr ausgewertet werden können, müssen die Daten gefiltert bzw. verdichtet werden. So lassen sich aussagekräftige Meldungen als Basis für weitere Aktionen erzeugen. Kontext Ein IT-System ist sicher installiert und konfiguriert worden. Es kann davon ausgegangen werden, dass Maßnahmen zum physikalischen Schutz des Systems sowie entsprechende Maßnahmen zum Schutz auf der logischen Ebene getroffen worden sind. Außerdem wurde das Security Pattern Aktivierung von Logging-Mechanismen angewendet, das ein neues Problem erzeugt hat. Problem Log-Dateien können schnell einen sehr großen Umfang erreichen und werden somit immer unübersichtlicher. Um dies zu verdeutlichen, haben wir in Abbildung 6-5 den Auszug aus einer Log-Datei von einem zentralen Log-Server gezeigt. Damit das Beispiel nicht unübersichtlich wird, haben wir nachträglich Zeilennummern eingefügt und zahlreiche unwichtige Zeilen entfernt (es werden lediglich einige DNS-Anfragen dargestellt). In den Zeilen 4, 8 und 12 sind Meldungen eines Authentisierungsservers zu sehen. Die zeitlichen Abstände sind sehr kurz; zu kurz, als dass ein Mensch dreimal ein Passwort falsch eintippen könnte. Offensichtlich wurde hier mit einem geeigneten Programm für den Benutzernamen „joe“ ein Brute-Force-Angriff auf ein ftp-Gateway vorgenommen. Dabei treten die im Folgenden beschriebenen Probleme auf: – Umfang Bei regulärem Betrieb gehen kritische Meldungen schnell in einer Flut von „normalen“ Ereignissen unter. Die bloße Menge macht es für einen Menschen unmöglich, umfangreiche Log-Dateien manuell auszuwerten.

224 6 Systeme

– Bedeutung Bei der Auswertung müssen auch Zusammenhänge (wie oben beschrieben) erkannt werden, damit klar wird, ob eine Abweichung vom Sollzustand vorliegt. Mar 22 01:13:11 server ipmon[268]: 01:13:10.963186 eth0 @65535:0 p client1,1144 -> dnsserver,53 PR udp len 20 67 K-S Mar 22 01:13:11 server ipmon[268]: 01:13:10.963619 eth0 @65535:0 p dnsserver,53 -> client1,1144 PR udp len 20 148 K-S Mar 22 01:13:11 server ipmon[268]: 01:13:10.963667 eth0 @65535:0 p dnsserver,53 -> client1,1144 PR udp len 20 148 K-S Mar 22 01:13:11 server authsrv[274]: BADAUTH joe (ftp-gw firewall) Mar 22 01:13:12 server ftp-gw[273]: exit host=firewall cmds=2 in=0 out=0 user=unauth duration=2 ... Mar 22 01:13:14 server ipmon[268]: 01:13:13.962837 eth0 @65535:0 p dnsserver,53 -> client2,1150 PR udp len 20 148 K-S Mar 22 01:13:14 server ipmon[268]: 01:13:13.962885 eth0 @65535:0 p dnsserver,53 -> client2,1150 PR udp len 20 148 K-S Mar 22 01:13:14 server authsrv[276]: BADAUTH joe (ftp-gw firewall) Mar 22 01:13:15 server ftp-gw[275]: exit host=firewall cmds=2 in=0 out=0 user=unauth duration=2 ... Mar 22 01:13:17 server ipmon[268]: 01:13:16.994967 eth0 @65535:0 p dnsserver,53 -> client3,1156 PR udp len 20 148 K-S Mar 22 01:13:17 server ipmon[268]: 01:13:16.995015 eth0 @65535:0 p dnsserver,53 -> client3,1156 PR udp len 20 148 K-S Mar 22 01:13:17 server authsrv[278]: BADAUTH schumach (ftpgw firewall) Mar 22 01:13:17 server ftp-gw[277]: exit host=firewall cmds=2 in=0 out=0 user=unauth duration=1 Abb. 6-5 Auszug aus einer Log-Datei

Lösung Zunächst müssen geeignete Filter und entsprechende Schwellwerte definiert werden. So können beispielsweise obige Meldungen, bei denen drei erfolglose Anmeldeversuche festgehalten wurden, zu einer Meldung zusammengefasst werden. Weiterhin muss eine Klassifizierung der Log-Meldungen vorgenommen werden. Mögliche Kategorien wären „Unbekannte Meldungen“, „Gefährliche Meldungen“


und „Ungefährliche Meldungen“. Die Zusammenfassung der Meldungen aus unserem Beispiel wären dann in der Kategorie „Gefährliche Meldungen“ einzuordnen. Werkzeuge wie logsurf [40], swatch [9] oder mächtigere Intrusion-DetectionSysteme (z.B. snort [118], eigentlich ein Netzwerk-IDS, das aber grundsätzlich auch lokal eingesetzt werden kann) sind hierbei hilfreich. Wenn eine Abweichung vom Regelbetrieb erkannt wird, muss auch eine Reaktion erfolgen. Laut Common Criteria kann dies sein, „den autorisierten Benutzer zu informieren, dem autorisierten Benutzer eine Menge von möglichen Aktionen zur Begrenzung vorzuschlagen oder Korrekturaktionen durchzuführen.“ Für den Eventualfall ist es sicherlich sinnvoll, einen Plan zu erstellen. Formblätter für eine gewissenhafte Dokumentation des Angriffs sind in diesem Zusammenhang empfehlenswert, da so der Angriff nachher leichter analysiert, die getroffenen Maßnahmen besser gerechtfertigt und eine eventuelle strafrechtliche Verfolgung eines Hackers aufgenommen werden können. Da es jederzeit zu einem sicherheitskritischen Ereignis kommen kann, ist nicht immer garantiert, dass ein Administrator erreichbar ist, der vielleicht wüsste, welche Schritte zu unternehmen sind. Ein vorher festgelegter Plan, etwa in Form einer Checkliste, ermöglicht es auch unbedarften Mitarbeitern, die richtigen ersten Schritte zu tun, und garantiert weiterhin, dass keine notwendigen Maßnahmen übersehen werden. 6.6.3 Zusammenfassung Die beschriebenen Security Patterns zum Erkennen von Angriffen können nun im Zusammenhang als Security-Pattern-System, wie in Abbildung 6-4 gezeigt, dargestellt werden. Audit Schutz der Dateien Erkennen von Angriffen

Sicherheit im Local Area Network Sicherheit durch Firewalls

Aktivierung von Logging-Mechanismen

Filtern, auswerten und reagieren Abb. 6-6 Erkennen von Angriffen

226 6 Systeme

Das Security-Pattern Aktivierung von Logging-Mechanismen, das eine Spezialisierung der Audit-Basisfunktion darstellt, führt zu einem neuen Problem. Die Menge der Systemmeldungen ist von einem menschlichen Benutzer nicht mehr auswertbar. Er ist nicht mehr in der Lage, richtige Schlussfolgerungen aus den Systemmeldungen zu ziehen. Daher besteht eine Abhängigkeit zum Security Pattern Filtern, auswerten und reagieren. Da Log-Informationen selbst angreifbar sind, bestehen zudem Abhängigkeiten zum Schutz der Dateien sowie Schutzmaßnahmen im Bereich lokaler Netzwerke und an Netzwerkgrenzen durch Firewalls (wir gehen davon aus, dass Logging-Daten nicht über die Grenzen von internen Netzwerken über das Internet verteilt werden).


Netzwerke

7

7.1 Einleitung In diesem Kapitel des Buches werden verschiedene, exemplarisch ausgewählte Sachverhalte im Kontext der Netzwerksicherheit dargestellt und diskutiert. Anhand verschiedener Beispiele wird gezeigt, wie mithilfe von Security Patterns typische Probleme im Kontext der Netzwerke beschrieben werden können.

7.2 Sicherheit im Local Area Network Zunächst werden wir Sicherheitsprobleme diskutieren, die bei der Kommunikation in einem lokalen Netzwerk – bezeichnet als Local Area Network (LAN) – auftreten. Zur Beschreibung dieser Sicherheitsprobleme und ihrer Lösungen werden wir ein Security-Pattern-System verwenden, das im Folgenden schrittweise entwickelt wird. Um den sehr großen Bereich „Sicherheit im Local Area Network“ auf ein hier sinnvolles Maß zu reduzieren, werden wir einen Teilbereich herausgreifen. Der herausgegriffene Teilbereich wird, wie bei Security Patterns üblich, durch die im Kontext der einzelnen Security Patterns festgelegten Randbedingungen bestimmt. 7.2.1 Abhören der Kommunikation im Ethernet Im Ethernet kann der Datenaustausch zwischen zwei Stationen von einer dritten, unberechtigten Station abgehört werden. Dieses Problem lässt sich beseitigen, indem das Ethernet durch einen so genannten Switch realisiert wird, der nur eine Kommunikation zwischen den beteiligten Stationen zulässt. Kontext Das in [125] beschriebene Ethernet zur Realisierung eines LANs stellt den Kontext für dieses Security Pattern dar. Für das Verständnis der folgenden Abschnitte ist von Bedeutung, dass sich im Ethernet alle angeschlossenen Stationen einen gemeinsamen Übertragungskanal – das so genannte „Shared Medium“ – teilen. Dementsprechend sind für das Ethernet Verfahren definiert, die den Zugriff auf das gemeinsam genutzte Medium regeln, sowohl für das Senden als auch für das Empfangen von Daten.


7.1. Einleitung 229

Problem Alle von einer Station gesendeten Daten werden von allen anderen am Ethernet angeschlossenen Stationen empfangen. Jede Station im Ethernet ist durch eine eindeutige MAC-Adresse gekennzeichnet. Versendet eine Station ein Paket, so wird im Paket-Header sowohl die MAC-Adresse der Senderstation als auch die MACAdresse der Empfängerstation eingetragen. Jede Empfängerstation prüft anhand der im empfangenen Paket enthaltenen MAC-Zieladresse, ob die Daten für sie bestimmt sind und verarbeitet werden müssen. Daraus ergibt sich nun folgende Bedrohung: Generell kann eine am Medium angeschlossene Station sich regelwidrig verhalten und Daten, die nicht an sie adressiert sind, dennoch verarbeiten. Dadurch wird es einer solchen Station möglich, die Kommunikation zwischen zwei anderen Stationen abzuhören und somit die Vertraulichkeit der Daten zu gefährden. Ein konkreter Angriff bzw. ein konkretes Angriffswerkzeug, mit dem diese Bedrohung ausgenutzt werden kann, ist ein so genannter Sniffer [97]. Lösung Das Ziel muss nun folglich die Entkopplung der Kommunikationswege sein. Nur an der Kommunikation beteiligte Rechner sollen in der Lage sein, auf die verschickten Daten zuzugreifen. Um die beschriebenen Probleme zu lösen, wird das Ethernet durch einen Switch realisiert. Der Switch sorgt dafür, dass Daten immer genau zwischen den beteiligten Kommunikationspartnern direkt ausgetauscht werden, ohne dass die an der Kommunikation unbeteiligten Stationen davon etwas mitbekommen. Die im Ethernet-Standard festgelegten Zugriffsverfahren der Stationen auf das Medium müssen dabei nicht verändert werden. Abb. 7-1 zeigt die Funktionsweise eines Switches. Wird ein Datenpaket von Station A an Station E gesendet, so sorgt der Switch dafür, dass das Paket direkt an den Ausgang, an dem Station E angeschlossen ist, gesendet wird. Der Switch „schaltet“ für die jeweiligen Kommunikationspartner eine virtuelle Verbindung, die nicht von anderen Stationen eingesehen werden kann. A

D

B

E

C

F Shared Medium

A

D

B

E

C

F Switch

Abb. 7-1 Kommunikation über einen Switch

Alle anderen Stationen bekommen von diesem Datentransfer nichts mit, ein auf Station D installiertes Sniffer-Werkzeug hätte demnach keine Wirkung mehr. Der

230 7 Netzwerke

Switch verwendet die MAC-Adressen der einzelnen Stationen, um festzustellen, an welchen Ausgang das an einem Eingang empfangene Paket weiterzuschicken ist. Welche MAC-Adressen welchem Ausgang zuzuordnen sind, muss dem Switch per Konfiguration mitgeteilt werden. Diese Konfiguration erfolgt in der Regel automatisch, indem der Switch sich merkt, welche MAC-Adressen innerhalb der an den Anschlüssen empfangenen Pakete verwendet worden sind. Abhängigkeiten Durch das Einführen der neuen Netzwerkkomponente „Switch“ ergeben sich auch neue Probleme. Der Switch, der zur Realisierung der direkten Netzwerkkommunikation verwendet wird, ist nämlich grundsätzlich selbst durch verschiedene Angriffe bedroht. Diese neuen Probleme und ihre Lösungen werden durch verwandte Security Patterns beschrieben: Zum einen kann die durch den Switch realisierte direkte Kommunikation durch verschiedene Manipulationen der Zuordnung von MAC-Adressen untergraben werden. Diese Lösungen und Probleme sind innerhalb des Patterns Manipulation der MAC-Adressen erfasst. Zum anderen benötigt ein Switch, wie jede andere Netzwerkkomponente auch, administrative Zugänge. Diese sind ebenfalls angreifbar und müssen daher entsprechend gesichert werden. Dies ist durch das Security Pattern Missbrauch der administrativen Zugänge beschrieben. 7.2.2 Manipulation der MAC-Adressen Ein Switch verwendet die Ethernet-MAC-Adressen der angeschlossenen Stationen, um festzustellen, an welchen Ausgang das an einem Eingang empfangene Paket weiterzuschicken ist. Diese Arbeitsweise eines Switches eröffnet einem Angreifer prinzipiell die Möglichkeit, durch Manipulation von MAC-Adressen die Funktionsweise des Switches zu stören. Kontext Der Kontext dieses Patterns ist durch seine Beziehung zum Security Pattern Abhören der Kommunikation im Ethernet festgelegt. Der Kontext entspricht also dem des Security Patterns Abhören der Kommunikation im Ethernet sowie der zusätzlichen Veränderung dieses Kontextes durch die Anwendung der Maßnahme „Switch“: ein Ethernet-basiertes LAN, realisiert mithilfe einer zentralen Netzwerkkomponente – einem Switch. Problem Es besteht die Bedrohung, dass die Weiterleitung der Daten innerhalb eines Switches durch die Manipulation von MAC-Adressen so beeinflusst wird, dass ein Angreifer unberechtigt Zugang zu Daten einer Kommunikationsverbindung erlangt. Um dies zu verdeutlichen, wird im Folgenden ein konkreter Angriff beschrieben, der diese Bedrohung ausnutzt.

7.2. Sicherheit im Local Area Network 231

Ein Switch durchläuft einen Lernprozess; dabei wird erkannt, welche MACAdressen über die entsprechenden Anschlüsse zu erreichen sind. Ein Angreifer kann nun dem Switch eine falsche MAC-Adresse vorgaukeln und dadurch eine fehlerhafte Weiterleitung der Pakete erreichen. Ein solcher Angriff soll anhand Abb. 7-1 erläutert werden. Wir nehmen an, dass der Angreifer Host D unter Kontrolle hat und für einen Angriff auf den Kommunikationsweg zwischen Host A und Host E verwenden möchte. Für den Angriff benötigt er die MAC-Adresse von Host A und Host E. Kennt der Angreifer diese nicht direkt, kann er durch eine normale ARP-Anfrage [125] in deren Besitz gelangen. Nachdem der Angreifer sich die MAC-Adressen beschafft hat, generiert er einige Netzwerkpakete, die als Absender die MAC-Adresse von Station A oder Station E verwenden. Durch die automatische Konfiguration des Switches (Lernprozess) erkennt nun der Switch, dass Host A und Host E über denselben Switch-Ausgang erreichbar sind wie auch Host D. Der Switch ist fähig, mehrere MAC-Adressen pro Ausgang zu verwalten, da die Möglichkeit der Verwaltung mehrerer Stationen an einem Ausgang besteht (Kaskadierung von Switches/Hubs). Nun existiert eine Zuordnung der gleichen MAC-Adresse zu mehreren Ausgängen. Dies ist generell nicht falsch, da solch ein Fall z.B. für Broadcast oder Multicast vorkommen kann. Ein Paket, das nun von A an E geschickt wird, wird durch den Switch sowohl an Ausgang D als auch an Ausgang E weitergegeben. Damit ist der Angreifer nun wiederum in der Lage, einen Paket-Sniffer als Angriffswerkzeug zu verwenden. Diese Form des Angriffs werden wir nachfolgend als „ARP-Cache Poisoning“ bezeichnen. In der Literatur sind weitere Angriffsbeispiele beschrieben, die diese potenzielle Schwachstelle nutzen [98,95]. Lösung Es ist notwendig, die automatische Lernfähigkeit des Switches zu beschränken. Dies kann geschehen, indem die an jedem Port zugelassenen MAC-Adressen statisch konfiguriert und festgelegt werden. Es kann auch realisiert werden, indem zu einem bestimmten Zeitpunkt, nach einer Überprüfung durch den entsprechenden Administrator, die ARP-Tabelle auf dem Switch „eingefroren“ wird. Damit ist ein ARP-Cache-Poisoning nicht mehr möglich. 7.2.3 Missbrauch der administrativen Zugänge Ein Switch benötigt einen oder mehrere administrative Zugänge. Diese Zugänge werden gebraucht, um das Gerät zu konfigurieren und zu verwalten. Sie müssen so gesichert sein, dass kein Angreifer sie verwenden kann, um die Funktionsweise des Gerätes zu kompromittieren. Die administrativen Zugänge müssen dementsprechend mit Maßnahmen zur Authentisierung gesichert werden.

232 7 Netzwerke

Kontext Eine Netzwerkkomponente besitzt einen oder mehrere Zugänge, die zur Administration des Gerätes verwendet werden. Als Zugang wird hier eine Schnittstelle angenommen, die über ein Netzwerk erreichbar ist. Dies kann ein HTTP-Interface sein, welches die Konfiguration bzw. Verwaltung durch den Administrator über einen Webbrowser ermöglicht. Weiterhin wird festgelegt, dass dieser Zugang über dieselbe Infrastruktur erreicht wird, die sie selbst realisiert. Für einen Switch bedeutet dies, dass er einerseits ein LAN realisiert, andererseits aber auch über die administrative Schnittstelle per LAN erreicht werden kann. Problem Ein Sicherheitsproblem ergibt sich durch die Tatsache, dass der administrative Zugang über ein Netz erreicht wird, an dem nicht nur die Station des Administrators, sondern auch viele andere Stationen angeschlossen sind. Ein Angreifer kann nun den administrativen Zugang nutzen, um das Gerät zu manipulieren oder um Informationen über das Gerät abzufragen. Netzwerkkomponenten bieten beispielsweise eine SNMP-Schnittstelle an, über die ein solches Gerät verwaltet werden kann. Viele dieser Komponenten sind ab Werk so eingestellt, dass diese Schnittstelle aktiviert und für jeden benutzbar ist 1. Dies ermöglicht einem Angreifer, die Funktionsweise des Gerätes nahezu beliebig zu beeinflussen. Lösung Zur Lösung dieses Problems muss jeder administrative Zugang über eine geeignete Authentisierung verfügen. Bevor die administrative Schnittstelle verwendet werden kann, muss eine Authentisierung der anfragenden Person durchgeführt werden. Abhängigkeiten Da das Konzept der Authentisierung vor der Verwendung einer Ressource (hier des administrativen Zugangs) selbst wieder Bedrohungen ausgesetzt ist, für die eine Lösung gefunden werden muss, wird diese Tatsache in einem eigenen Security Pattern beschrieben. Damit hängt das hier beschriebene Security Pattern vom Security Pattern Identifikation und Authentisierung ab. Auf Systemebene wird oftmals eine Benutzerauthentisierung mit Passwörtern vorgenommen. Außerdem besteht eine Abhängigkeit zum Security Pattern Abhören der Kommunikation im Ethernet.

1

SNMP bietet die Möglichkeit einer Authentisierung. Die initial gesetzten Passwörter für die meisten Komponenten (z.B. public/private) sind aber bekannt, weshalb die Schnittstelle oft nach Inbetriebnahme eines Gerätes für jeden nutzbar ist.

7.2. Sicherheit im Local Area Network 233

7.2.4 Zusammenfassung Die zuvor beschriebenen Security Patterns können nun im Zusammenhang als Security-Pattern-System, wie in Abb. 7-2 gezeigt, dargestellt werden. Die einzelnen Security Patterns sind durch Relationen, dargestellt durch die Pfeile, miteinander verknüpft. Das Security Pattern Abhören der Kommunikation im Ethernet ist direkt mit den beiden anderen Security Patterns Manipulation der MAC-Adressen verbunden, da sich aus der Umsetzung der Lösung „Switch“ in einem lokalen Netzwerk eine neue Bedrohung ergibt. Außerdem ergeben sich weitere Möglichkeiten zu einem Angriff, d.h., der Missbrauch der administrativen Zugänge muss verhindert werden. Das Security Pattern Missbrauch der administrativen Zugänge hängt wiederum davon ab, ob eine sichere Identifikation und Authentisierung vorgenommen wurde. Abhören der Kommunikation im Ethernet

Manipulation der MAC-Adressen

Missbrauch der administrativen Zugänge

Identifikation und Authentisierung Abb. 7-2 Sicherheit im Local Area Network

Da das Security Pattern Abhören der Kommunikation im Ethernet einen Switch als Lösung vorgibt, müssen die beiden von ihm abhängenden Security Patterns – um zu einer sicheren Gesamtlösung für das im Security Pattern Abhören der Kommunikation im Ethernet beschriebene Problem zu gelangen – ebenfalls berücksichtigt werden. Das bedeutet insbesondere, dass die beiden abhängigen Security Patterns sich in einem konsistenten Zustand (siehe Kapitel 2.3.3) befinden müssen. Führt beispielsweise ein neu bekannt gewordener Angriff innerhalb des Security Patterns Manipulation der MAC-Adressen zu einer internen Inkonsistenz, so propagiert sich diese entlang der gegebenen Relationen fort. Damit stellt auch das Security Pattern Abhören der Kommunikation im Ethernet keine sichere Lösung mehr dar. Gleiches gilt im Falle eines erkannten, neuen Angriffs innerhalb des Security Patterns Identifikation und Authentisierung. Ein Fehler dort würde sich auf das Pattern Missbrauch der administrativen Zugänge und somit auf das Pattern Abhören der Kommunikation im Ethernet auswirken.

234 7 Netzwerke

7.3 Sicherheit im Wide Area Network Nachdem wir ein Security-Pattern-System zur Beschreibung und Lösung von bestimmten Problemen in einem LAN dargestellt haben, werden wir uns in diesem Abschnitt auf ein Security-Pattern-System aus dem Bereich der Wide Area Networks – zu dem auch das Internet zählt – konzentrieren. 7.3.1 Virtuelles privates Netz Ein öffentliches, IP-basiertes Netz kann genutzt werden, um mehrere private Netzwerke miteinander zu verbinden. Der Kommunikationsweg zwischen den privaten Netzen ist dabei verschiedensten Bedrohungen – wie dem Abhören des Kommunikationsweges durch einen Angreifer – ausgesetzt. Wird die Einschränkung gemacht, dass eine Kommunikation zwischen Rechnern nicht innerhalb der privaten Netze und Rechner innerhalb des öffentlichen Netzes, sondern nur zwischen Rechnern innerhalb der privaten Netze stattfindet, so kann der Kommunikationsweg durch ein so genanntes Virtuelles Privates Netz (VPN) gesichert werden. Kontext Als Kontext dieses Patterns wird eine Kommunikation über ein öffentliches, IPbasiertes Netz angenommen. Die Endpunkte einer Kommunikationsverbindung sollen dabei durch einzelne Rechner oder ganze Netzwerke abgebildet werden. Einzelne, spezielle Applikationen als Kommunikationsendpunkte werden auf dieser Ebene also nicht betrachtet. Die Kommunikation selbst erfolgt über ein öffentliches Netz, was bedeutet, dass die Kommunikationsendpunkte keinen Einfluss darauf haben, wer Zugriff auf die transportierten Daten auf ihrem Weg durch das öffentliche Netz hat. Des Weiteren wird das öffentliche Netz als IP-basiert angenommen. Im Folgenden wird das in Abb. 7-3 dargestellte Szenario zugrunde gelegt. Zwei private IP-Netzwerke, Netzwerk A und Netzwerk B, sind jeweils über einen Router an das öffentliche Internet angeschlossen. Beide privaten Netzwerke unterstehen einer administrativen Einheit; z.B. gehören beide Netze zu einer Firma und stellen das Netzwerk des Firmensitzes (Netzwerk A) sowie einer Zweigstelle (Netzwerk B) dar. Zwischen beiden privaten Netzen besteht der Bedarf, Daten auszutauschen. So werden die Systeme innerhalb des Netzwerks B die vom Server innerhalb des Netzwerks A angebotenen Dienste (z.B. Fileserver-Dienste) nutzen. Werden zwischen Rechner A1 und B1 Daten ausgetauscht, werden die IP-Pakete (Quelladresse A1, Zieladresse B1) über den Router A in das Internet übertragen. Innerhalb des Internets werden die Pakete dann anhand der Zieladresse an Router B weitergeleitet, der dann wiederum die Pakete an den Zielrechner übermittelt.

7.3. Sicherheit im Wide Area Network 235

B1 Netzwerk A

Netzwerk B

Internet Router A

A1

Router B

Abb. 7-3 Anschluss privater Netze an das Internet

In diesem Szenario wird davon ausgegangen, dass innerhalb beider privater Netze im Internet gültige IP-Adressen verwendet werden. Im Szenario wird nicht betrachtet, ob eventuell auch eine Kommunikation zwischen den privaten Netzen und Rechnern innerhalb des Internets stattfindet. Das Internet wird im hier dargestellten Szenario gewissermaßen als „Transportmedium“ zwischen den Netzen A und B verwendet. Dies wird in der Praxis oft umgesetzt, da die Kopplung zweier Netze über das Internet meist günstiger zu realisieren ist als die Kopplung mithilfe anderer Mechanismen (z.B. Kopplung über das Telefonnetz mittels einer Standleitung). Problem In öffentlichen Netzen gibt es keine zentrale administrative Einheit, die eine Garantie geben kann, dass die Daten „sicher“ durch das Internet transportiert werden. Die möglichen Bedrohungen innerhalb des Kontextes ergeben sich bereits aus dessen Definition. Es wird ein öffentliches Netz zugrunde gelegt, in dem die Kommunikationsendpunkte keinen Einfluss darauf haben, wer Zugriff auf die transportierten Daten auf ihrem Weg durch das öffentliche Netz hat. Abb. 7-4 erläutert dies für das Internet als öffentliches Netz. R13

Netz 3

Netz 1

R34

A Router A

Netz 4 R12 Netz 2

X

B Router B

R24

Router X

Abb. 7-4 Unsichere Kommunikation über das Internet

Das zwischen den Netzen A und B liegende Internet besteht seinerseits aus verschiedenen Teilnetzen, die über Router miteinander verbunden sind. Dabei gehören die einzelnen Teilnetze nicht zur gleichen administrativen Domäne. Dies bedeutet,

236 7 Netzwerke

dass Daten beim Austausch zwischen den beiden Netzen A und B auf ihrem Weg in der Regel das „Gebiet“ verschiedener administrativer Domänen durchqueren. Angenommen Netz A befindet sich in Deutschland und Netz B in den USA, dann könnte Netz 1 zum Beispiel einem deutschen Internet-Provider gehören, die Netze 2 und 3 einem internationalen Provider und Netz 4 einem amerikanischen Provider. Es stellt sich dabei die Frage, inwieweit man den einzelnen Netzbetreibern, die die Daten transportieren, vertrauen kann oder möchte. Passieren die Daten auf ihrem Weg durch das Internet ein Netz, zu dem auch Angreifer Zugang haben, ergeben sich folgende Bedrohungen: – Abfangen Die transportierten Daten können auf ihrem Weg durch das Netz von einem Angreifer abgefangen und verarbeitet werden. Die Daten erreichen das eigentliche Ziel nicht, der Angreifer übernimmt die Rolle des Empfängers. – Modifikation Ein Angreifer kann die transportierten Daten auf ihrem Weg durch das von ihm (teilweise) kontrollierte Netz modifizieren. Dateninhalte können also auf ihrem Weg zwischen Sender und Empfänger verändert werden, ohne dass der Sender oder der Empfänger dies bemerken. – Man-in-the-Middle Ein Angreifer kann mit dem Ziel kommunizieren und sich selbst als der reguläre Sender ausgeben. Der Empfänger erkennt nicht, dass er mit einem Angreifer anstatt des eigentlichen Senders kommuniziert. – Abhören Die transportierten Daten können auf ihrem Weg durch das Netz eingesehen werden. Ein Angreifer hat Zugriff auf die Dateninhalte der durch das von ihm kontrollierte Netz transportierten Daten. – Abhören der Kommunikationsbeziehungen Ein Angreifer kann die Kommunikation zwischen Sender und Empfänger beobachten und Informationen aus dieser Kommunikationsbeziehung gewinnen. Der Angreifer kann feststellen, welche Endpunkte Kommunikationsbeziehungen haben und zu welchen Zeiten. Die hier beschriebenen fünf verschiedenen Bedrohungen werden in der Literatur [49,99] als die wesentlichen betrachtet. Andere Bedrohungen lassen sich zumeist auf die hier beschriebenen zurückführen und sind in der Regel davon abgeleitete Sonderfälle.


Beispiel Im Folgenden wird gezeigt, wie sich eine der oben beschriebenen Bedrohungen konkret von einem Angreifer nutzen lässt. Das folgende Beispiel zeigt nur eine konkrete Ausprägung, es stehen einem Angreifer aber nahezu beliebige andere Möglichkeiten zur Verfügung, um eine Verletzlichkeit auszunutzen und so zu einer Bedrohung zu werden. AN

A1

R13 Netz 1

R34

A Router A

Netz 4 R12 Netz 2

X

B1

Netz 3

B Router B

R24

Router X

Abb. 7-5 Angriff einer Kommunikation über das Internet

In diesem Beispiel gehen wir davon aus, dass der Angreifer (teilweise) Kontrolle über das Netz 1 hat (siehe Abbildung 7-5). Er verfügt über einen Rechner AN in diesem Netzwerk und hat Kontrolle über den Router R13. Ist das Netz 1 groß genug, wird ein Angreifer unentdeckt einen Rechner AN betreiben können, entweder durch Betrieb eines eigenen Rechners oder indem er Zugang (über das Netz oder lokal) zu einem in diesem Netz befindlichen Rechner erlangt hat und ihn als Angriffsrechner (AN) umfunktioniert. Kontrolle über den Router R13 zu bekommen ist sicher schwieriger, aber nicht unmöglich. Wir gehen daher davon aus, dass der Angreifer im Besitz des „root“-Passworts dieses Systems ist. Im Beispiel nutzt der Angreifer die erste der zuvor beschriebenen Angriffe aus. Der Rechner A1 bietet einen WWW-Server-Dienst an. Der Angreifer will das Netz so manipulieren, dass alle HTTP-Anfragen, die von B1 an den Server A1 gestellt werden, nicht von diesem, sondern von einem manipulierten WWW-Server-Dienst auf AN bearbeitet werden. Der Angreifer kann folgendermaßen vorgehen: Der Angreifer modifiziert den Router R13 so, dass alle TCP-Pakete, die an den WWW-Server-Dienst auf A1 adressiert sind, an den WWW-Server-Dienst auf AN umgelenkt werden. Dazu muss der Router natürlich diese Funktionalität besitzen. Viele Router, insbesondere rechnerbasierte, besitzen diese Funktionalität, um damit ein transparentes Umlenken von Verbindungen zum Zwecke der einfacheren Netzadministration bzw. zur Implementierung von transparenten Caches realisieren zu können. Dies wird implementiert indem der Router die IP-Adressen der entsprechenden Pakete bei ihrem Durchlauf durch den Router modifiziert. Der Client B1 erhält dadurch die angeforderte HTTP-Seite vom WWW-Server des Angreifers und nicht vom gewünschten Server A2. Für den Client B1 besteht dabei keine Möglichkeit zu erkennen, dass er nicht mit dem gewünschten Ziel kommuniziert. Der An-

238 7 Netzwerke

greifer ist in der Lage, die Anfragen des Clients zu bearbeiten und veränderte HTTPSeiten an den Client B1 auszuliefern. Dieses Verfahren ermöglicht es auch, die Anfragen von B1 an andere Dienste umzulenken. Voraussetzung für den hier dargestellten Angriff ist, dass alle IPPakete, die zwischen A1 und B1 verschickt werden, über den Router R13 gesendet werden. Lösung Um die oben beschriebenen Probleme zu lösen, müssen die generellen Bedrohungen durch geeignete Maßnahmen beseitigt werden. Danach sind keine konkreten Angriffe mehr möglich. Um generelle Bedrohungen zu verhindern, müssen durch entsprechende Maßnahmen folgende Schutzziele erfüllt werden: – Zugriffskontrolle Es wird verhindert, dass ein Empfänger Daten von einem unberechtigten Sender entgegennimmt und verarbeitet. Nicht berechtigte Systeme werden von der Kommunikation ausgeschlossen. – Verbindungslose Integrität Eine Manipulation der Daten auf der Kommunikationsstrecke kann erkannt werden. – Authentisierung der Datenherkunft Es kann geprüft werden, ob die empfangenen Daten auch wirklich vom Kommunikationspartner geschickt wurden. – Vertraulichkeit Die zu übertragenden Daten werden verschlüsselt, so dass ein Abhören auf der Übertragungsstrecke nicht möglich ist. – Eingeschränkte Vertraulichkeit des Traffic Flows Es wird verhindert, dass die Kommunikationsbeziehungen aus den Datenströmen ersichtlich werden. Eine Maßnahme, die den oben beschriebenen Kontext sowie die zuvor dargestellten allgemeinen Sicherheitsziele berücksichtigt, ist ein virtuelles privates Netzwerk (VPN). Bei einem VPN werden mehrere private Netzwerke über ein öffentliches Netzwerk durch einen gesicherten Tunnel miteinander gekoppelt (siehe Abbildung 7-6). Die Aus- bzw. Eingangs-Router (VPN-Router) der privaten Netzwerke dienen dabei als Tunnelendpunkte. Der Tunnel selbst besteht aus einer kryptografisch abgesicherten Netzwerkverbindung zwischen den Tunnelendpunkten. IP-Pakete, die diese Tunnel passieren, werden als gesicherte Nutzlast der Tunnelverbindung versendet.


Gesicherter Tunnel

B1 Netzwerk A

A1

Netzwerk B

VPN-Router A

VPN-Router B

Abb. 7-6 Virtuelles privates Netz

Zur Sicherung werden die zu verschickenden Daten durch den entsprechenden VPN-Router mithilfe eines Verschlüsselungsalgorithmus verschlüsselt. Bevor der Tunnel zum Transport der Datenpakete zwischen den privaten Netzen verwendet werden kann, muss dieser zuerst etabliert werden. Zum einen ist dafür eine gegenseitige Authentisierung der VPN-Router nötig, zum anderen müssen die für die Verschlüsselung der Daten notwendigen Schlüssel ausgetauscht werden. Das oben beschriebene Angriffsbeispiel stellt sich nach Verwendung eines VPN folgendermaßen dar: Ein von B1 an A1 gesendetes IP-Paket wird zunächst von B1 an den VPN-Router B gesendet. Router B schickt nun das empfangene IP-Paket über die Tunnelverbindung weiter. Dazu wird das empfangene IP-Paket als Nutzdaten der Tunnelverbindung verpackt; die Nutzdaten werden vor dem Weiterleiten durch Router B verschlüsselt. Das entstandene Tunnelpaket könnte ebenfalls wie zuvor beschrieben durch einen Angreifer abgefangen werden. Dieser ist aber jetzt nicht mehr in der Lage, das Paket zu verarbeiten, da er nicht über den entsprechenden Schlüssel zum Entpacken des Tunnelpakets verfügt. Der zuvor beschriebene Angriff ist nach Verwendung des VPNs nicht mehr möglich. Des Weiteren werden die restlichen Schutzziele folgendermaßen umgesetzt: Nachdem das Paket durch den VPN-Router A empfangen wurde, wird das Original-IPPaket aus dem Tunnelpaket „entpackt“ und an A1 weitergesendet. Der VPN-Router A kann nach Empfang des getunnelten Paketes folgende Prüfungen vornehmen: – Integrität Das übermittelte IP-Paket kann nur dann ordnungsgemäß entpackt werden, wenn es auf seinem Weg durch das Internet nicht verändert wurde. – Authentisierung Router A weiß, dass das Paket von Router B stammt (da nur Router A und Router B über den entsprechenden Schlüssel verfügen).

240 7 Netzwerke

Ein Schutz gegen die Analyse des Kommunikationsaustauschs an sich ist eingeschränkt gegeben. Ein Angreifer kann zwar sehen, dass zwischen Netzwerken Pakete ausgetauscht werden, ist aber nicht mehr in der Lage, diese einzelnen Systemen zuzuordnen, da der gesamte Verkehr getunnelt wird. Abhängigkeiten Die wichtigsten Abhängigkeiten des Security Patterns Virtuelles privates Netz werden in Abbildung 7-7 dargestellt. Die Vertraulichkeit und auch die Integrität der Pakete kann mithilfe geeigneter Verfahren zur Verschlüsselung erreicht werden. Besonders wichtig ist die Identifikation und Authentisierung der Endpunkte eines VPN-Tunnels. Schließlich hängt diese Lösung wesentlich davon ab, ob auf Ebene der Systeme die entsprechenden Maßnahmen getroffen werden. Ist dies nicht der Fall, kann ein Angreifer versuchen, den Tunnel zu umgehen und die Endpunkte direkt anzugreifen. Virtuelles privates Netz

Systeme

Verschlüsselung


Abb. 7-7 Security-Pattern-System virtuelles privates Netz

7.4 Sicherheit durch Firewalls Der letzte Abschnitt dieses Kapitels beschreibt Sicherheitsprobleme in Netzwerken, die durch den Einsatz von Firewalls gelöst werden können. Im Folgenden wird Schritt für Schritt ein Security-Pattern-System vorgestellt, das die typischen Bausteine einer Firewall beschreibt und deren Zusammenhänge untereinander aufzeigt. 7.4.1 Firewall Besteht zwischen zwei Netzwerken ein Übergang, so ergibt sich das Problem, dass prinzipiell alle Rechner und Dienste in einem Netzwerk von Rechnern aus dem anderen Netzwerk angesprochen werden können. Um die potenziellen Risiken der Zugriffsmöglichkeiten an einem zentralen Übergangspunkt zwischen beiden Netzwerken einzuschränken, kann eine Firewall verwendet werden.

7.4. Sicherheit durch Firewalls 241

Kontext Der Kontext dieses Patterns ist, wie in Abbildung 7-8 gezeigt, durch ein privates Netzwerk gegeben, das wiederum einen Übergang zu einem weiteren Netzwerk aufweist. Im dargestellten Szenario ist das zweite Netzwerk das Internet.

AN Privates Netz A

Internet

Router A

A1

Abb. 7-8 Netzübergang zwischen einem privaten Netz und dem Internet

Das private Netzwerk wird oftmals auch als „internes“, das andere als „externes“ Netzwerk bezeichnet. Weiterhin wird angenommen, dass beide Netze verschiedene administrative Bereiche repräsentieren. Problem Wenn der Betreiber des privaten Netzes dafür sorgt, dass alle Rechner bzw. Applikationen innerhalb des privaten Netzes sicher sind (siehe beispielsweise Kapitel 6), so kann ein Angreifer (AN in Abb. 7-8) innerhalb des Internets eigentlich keine Bedrohung für das private Netz darstellen. Dies bedeutet aber, dass alle Rechner innerhalb des privaten Netzes entsprechend der vom Betreiber gewünschten Sicherheitsrichtlinie betrieben werden müssten. In der Realität ist dieser Wunsch aber nur schwer umzusetzen. Gründe liegen beispielsweise in mangelndem oder fehlendem Sicherheitsbewusstsein, möglicherweise sogar einem falschen Sicherheitsverständnis. Je umfangreicher die Zahl der Rechner und Applikationen innerhalb des internen Netzes, desto höher ist die Wahrscheinlichkeit, dass eine dieser internen Komponenten nicht entsprechend der vorgegebenen Richtlinie eingesetzt wird. Nutzt ein externer Angreifer die Verletzlichkeit einer internen Komponente erfolgreich aus, so hat dies Einfluss auf die gesamte verwendete Infrastruktur. Im Detail sind folgende Probleme zu nennen: – Unzureichende Zugriffskontrolle Bei größeren Mengen von internen Systemen wird die Handhabung von Berechtigungen sehr komplex. Es kann dann nicht sichergestellt werden, dass auf jedem System eine ausreichende Zugriffskontrolle durchgeführt wird. Es kann einem Angreifer möglich sein, mit einem internen Rechner zu kommunizieren, obwohl die im privaten Netz angestrebte Sicherheitsrichtlinie dies verbietet. Ein solcher Fall kann eintreten, wenn der interne Rechner die vorgegebene Sicherheitsrichtlinie bezüglich der Zugriffskontrolle nicht erfüllt.

242 7 Netzwerke

– Verletzlichkeiten interner Systeme Rechner innerhalb des privaten Netzes können nicht immer erkennen, ob Daten, die an sie gesendet werden, eine Bedrohung darstellen. Diese Daten werden dann durch den internen Rechner verarbeitet; ein Angreifer ist dadurch in der Lage, entsprechende Verletzlichkeiten auszunutzen. – Sichtbare Netzwerktopologie Die internen Strukturen des privaten Netzes sind erkennbar. Ein Angreifer innerhalb des externen Netzes kann prinzipiell alle im internen Netz verwendeten Rechner und Dienste adressieren. Durch die Offenlegung dieser Information wird es dem Angreifer überhaupt erst möglich, gezielt Angriffe durchzuführen. – Entdeckung von Angriffen Angriffsversuche können nicht entdeckt werden, da nicht sichergestellt ist, ob auf jedem internen System ein Audit entsprechend der internen Sicherheitsrichtlinien durchgeführt wird. Lösung Eine Firewall implementiert bestimmte Funktionen, um die oben beschriebenen Probleme zu lösen. Der in Abb. 7-8 dargestellte Router wird dabei durch ein FirewallSystem ersetzt. Dieses Firewall-System erbringt zusätzlich zu der notwendigen Routing-Funktionalität auch folgende Funktionen zum Schutz des internen Netzes: – Analyse Die Firewall muss in der Lage sein, die über sie verschickten Daten zu analysieren. Die so gewonnenen Informationen werden teilweise zur Realisierung der nachfolgend beschriebenen Funktionen benötigt. Die Analyse der Daten kann auf verschiedene Arten erfolgen, die sich hinsichtlich ihrer Parameter wie z.B. technische Umsetzung, Güte, Granularität usw. unterscheiden. Beispielsweise ist eine Analyse der Semantik der Header einzelner Protokolle, die Analyse der durchlaufenden Zustände einer Protokollzustandsmaschine, die zwischen zwei Kommunikationspartnern abgewickelt wird, oder die Analyse der Zusammenhänge verschiedener parallel aktiver Kommunikationsverbindungen denkbar. – Zugriffskontrolle Die Firewall muss eine Zukriffskontrolle durchführen können, basierend auf den Identitäten von Sender und Empfänger der über die Firewall laufenden Daten. Die Identitäten können durch die oben beschriebene Analyse der Daten oder durch andere Verfahren ermittelt werden. Die Identitätsprüfung erfolgt auf verschiedene Arten, so kann als Identität ein Benutzer, ein bestimmter Prozess auf einem Rechner oder ein Rechner verwendet werden.


– Filterung und Modifikation Basierend auf den durch die Analyse der Daten gewonnenen Informationen muss entschieden werden, ob durch die übermittelten Daten eine Bedrohung entstehen kann oder nicht. Aufgrund dieser Entscheidung werden die Daten dann weitergeleitet oder verworfen. Zusätzlich kann festgelegt werden, ob Daten vor einer Weiterleitung modifiziert werden müssen, um potenzielle Angriffe zu verhindern. – Verbergen Eine Firewall muss in der Lage sein, die auf der einen Seite der Netzgrenze liegenden Strukturen vor der anderen Seite zu verbergen. Dies entzieht einem Angreifer die Möglichkeit, sich Informationen über mögliche Ziele zu verschaffen. – Audit Angriffe auf IT-Systeme bleiben unentdeckt, wenn es keine Möglichkeit gibt, Unregelmäßigkeiten im Betrieb festzustellen. Eine Firewall muss deshalb für die oben beschriebenen Funktionen ein Audit durchführen können. Basis für das Audit können unter anderem die durch die Analyse gewonnenen Informationen darstellen. Abhängigkeiten Das hier beschriebene Security Pattern Firewall setzt die Security Patterns Identitätsbasierte Zugriffskontrolle und Audit voraus. Zur Überprüfung der Identität von Sender und Empfänger werden die im Security Pattern Identifikation und Authentisierung beschriebenen Konzepte verwendet. Das Erfassen von Unregelmäßigkeiten im Betrieb ist allgemein im Security Pattern Audit und auf Systemebene in den Security Patterns zum Erkennen von Angriffen beschrieben. Weiterhin ist der Einsatz einer Firewall geeignet, um eine Mehrschichtige Verteidigung umzusetzen. Sie dienen dazu, die Absicherung der schwächsten Stellen in den internen Netzen zu unterstützen. Weiterhin stellen Firewalls idealerweise eine Passierstelle dar, in der Sicherheitspolitiken technisch umgesetzt werden können. 7.4.2 Paketfilter Ein Paketfilter stellt eine spezielle Möglichkeit zur Realisierung einer Firewall dar. Somit besitzt das hier beschriebene Pattern den gleichen Kontext sowie die gleiche Problembeschreibung wie das übergeordnete Pattern Firewall. Durch die Berücksichtigung spezieller Anforderungen ergibt sich innerhalb dieses Patterns allerdings eine spezialisierte Firewall-Lösung. Problem Insbesondere bei hohem Datenaufkommen kann eine Firewall zu einem Flaschenhals in einem Netzwerk werden. Sie soll die ihr zugewiesenen Aufgaben umsetzen,

244 7 Netzwerke

indem sie nur auf Informationen der Paket-Header innerhalb der Internet- und Transportschicht zugreift. Dadurch können Firewalls mit einem sehr hohen Datendurchsatz – im Vergleich zu den im folgenden Abschnitt beschriebenen Proxies oder Stateful-Filtern – erstellt werden. Lösung Ein Paketfilter besteht aus einer Netzwerkkomponente – z.B. einer Bridge oder einem Router – zum Verbinden zweier Netzwerke, die durch eine Filterfunktion erweitert wird. Der Filter prüft anhand zuvor festgelegter Kriterien (den Filterregeln), ob die von der Netzwerkkomponente weiterzuleitenden Datenpakete den Sicherheitsbestimmungen entsprechend zulässig sind. zur Analyse verwendete Schichten Datenfluss Paketfilter

Abb. 7-9 Paketfilter

Ein nicht zulässiges Datenpaket stellt grundsätzlich eine Bedrohung dar und wird daher verworfen bzw. nicht weitergeleitet. Die an bestimmten Positionen enthaltenen Werte innerhalb der Datenpakete werden dabei mit den zuvor festgelegten Filterregeln verglichen, um zu entscheiden, ob eine derartige Bedrohung vorliegt. Im Wesentlichen werden die in den Header-Feldern der Internet- und Transportschicht enthaltenen Werte innerhalb der Datenpakete geprüft. Da jede Prüfung eines Pakets ohne Berücksichtigung der bereits analysierten Pakete durchgeführt wird, können die Daten der Applikationsebene nicht geprüft werden. Eine Analyse der Daten der Applikationsebene würde erfordern, Applikationsdaten sowie Zustände der jeweiligen Applikationsprotokollautomaten vorzuhalten. IP-basierte Paketfilter untersuchen beispielsweise die Pakete nach dem Typ des Pakets (z.B. TCP oder UDP), nach IP-Adressen des Senders und Empfängers sowie nach den Portnummern des Senders und Empfängers. Pakete, die beispielsweise an einen bestimmten Empfänger gerichtet sind, können so als Bedrohung erkannt (sofern in den Filterregeln festgelegt) und die Weiterleitung dieser Pakete an den Empfänger verhindert werden. Eine Firewall, die nur durch die Verwendung eines Paketfilters realisiert wird, setzt demnach die von einer Firewall zu übernehmenden Funktionen folgendermaßen um: – Analyse Die Header-Felder der Internet- und Transportschicht können überprüft werden. – Zugriffskontrolle Der Paketfilter kann die Identität der Kommunikationsteilnehmer anhand der verwendeten Portnummern und der IP-Adressen bestimmen.


– Filterung und Modifikation Die Firewall entscheidet, ob die Daten weitergeleitet werden (Filterung). Eine Modifikation der Daten ist vor dem Weiterleiten möglich. – Verbergen Ein Verbergen der internen Netzstrukturen ist teilweise möglich, so dass bestimmte Kommunikationsendpunkte nicht adressiert werden können. – Audit Wird ein Netzwerkpaket durch die Firewall verworfen und nicht weitergeleitet, erfolgt ein entsprechender Vermerk. Es ist daher möglich, reguläre Nachrichtenflüsse und Angriffe im Nachhinein zu analysieren. Abhängigkeiten Dieses Security Pattern ist eine Spezialisierung des Security Patterns Firewall. Damit ergeben sich insbesondere Abhängigkeiten zum Security Pattern Identitätsbasierte Zugriffskontrolle. 7.4.3 Stateful-Filter Eine weitere Möglichkeit zur Umsetzung einer Firewall besteht in der Verwendung eines Stateful-Filters. Kontext und Problem entsprechen dem des allgemeinen Security Pattern Firewall. Durch die speziellen Anforderungen ergibt sich wiederum eine besondere Lösung. Problem Datenpakete stehen oftmals in einem Zusammenhang, d.h., sie sind Teil eines Protokolls zwischen den Kommunikationsendpunkten. Dies kann mit einem Paketfilter nicht erreicht werden. Die Firewall soll die ihr zugewiesenen Aufgaben umsetzen, indem sie auf Informationen innerhalb aller Schichten der über sie verschickten Netzwerkpakete zugreift. Weiterhin sollen Informationen berücksichtigt werden, die durch die Prüfung von zuvor verarbeiteten Paketen gewonnen wurden. Mithilfe dieser Vorgehensweise können Firewalls mit einem sehr hohen Datendurchsatz– im Vergleich zu einer Proxy-basierten Firewall – erstellt werden. Aufgrund der zusätzlichen Prüfungskriterien im Vergleich zu einem Paketfilter kann zudem ein höheres Sicherheitsniveau erreicht werden. Lösung Bei einem Stateful-Filter handelt es sich um einen einfachen Paketfilter, der zusätzlich in der Lage ist, bei der Prüfung der Pakete auch auf Informationen zurückzugreifen, die durch die Prüfung von zuvor verarbeiteten Paketen gewonnen wurden.

246 7 Netzwerke

Ein Stateful-Filter für das TCP/IP-Protokoll ist beispielsweise in der Lage zu prüfen, ob ein TCP-Paket zu einer bereits ordnungsgemäß geöffneten TCP-Verbindung gehört oder nicht. zur Analyse verwendete Schichten Datenfluss Stateful-Filter

Abb. 7-10 Stateful-Filter

Der Stateful-Filter „merkt“ sich gewissermaßen, dass zwischen dem Sender und Empfänger bereits TCP-Pakete für den TCP-Verbindungsaufbau in der richtigen Reihenfolge ausgetauscht wurden. Wird dann zu einem späteren Zeitpunkt ein TCPPaket durch den Stateful-Filter geprüft, kann dieser feststellen, ob das Paket den festgelegten Filterregeln entspricht (wie bei einem normalen IP-Paketfilter) und zusätzlich im Kontext der aktuellen TCP-Verbindungen Sinn macht. Ein Stateful-Filter kann auch in der Lage sein, einzelne Protokolle der Applikationsschicht zu „verstehen“, und dadurch auch Informationen zur Prüfung der Daten heranziehen, die nur auf dieser Schicht verfügbar sind. Beispielsweise kann ein Stateful-Filter, der die Applikationssemantik des FTP-Protokolls „versteht“, die auf dem FTP-Kontrollkanal ausgehandelten IP-Adressen und Portnummern für den FTP-Datenkanal ermitteln. Diese Informationen stehen dann für die Prüfung der nachfolgenden TCPPakete zur Verfügung; TCP-Pakete können als Pakete einer FTP-Datenverbindung identifiziert werden. Eine Firewall, die nur durch die Verwendung eines Stateful-Filters realisiert wird, setzt demnach die von einer Firewall zu übernehmenden Funktionen folgendermaßen um: – Analyse Die Header-Felder der Internet-, Transport- und Applikationsschicht können überprüft werden. Zusätzlich besteht die Möglichkeit zur Überprüfung der Verbindungssemantik. – Zugriffskontrolle Der Stateful-Filter kann die Identität der Kommunikationsteilnehmer anhand der verwendeten Portnummern und der IP-Adressen bestimmen. Zusätzlich können benutzerbezogene Informationen, die innerhalb der Applikationsschicht eventuell vorhanden sind, verwendet werden. – Filterung und Modifikation Die Firewall entscheidet, ob die Daten weitergeleitet werden (Filterung). Eine Modifikation der Daten ist vor dem Weiterleiten möglich.


– Verbergen Ein Verbergen der internen Netzstrukturen ist teilweise möglich, da bestimmte Kommunikationsendpunkte nicht adressiert werden können. – Audit Werden Daten durch die Firewall verworfen oder modifiziert, wird dies entsprechend vermerkt. Somit ist eine spätere Analyse des Netzwerkverkehrs möglich. Abhängigkeiten Dieses Security Pattern stellt eine Spezialisierung des Security Patterns Paketfilter dar. Damit stellt es ebenfalls eine Spezialisierung des Security Patterns Firewall dar und besitzt so auch die Abhängigkeiten zu den Security Pattern Identitätsbasierte Zugriffskontrolle und Audit. 7.4.4 Proxy Eine weitere, weit verbreitete technische Umsetzung einer Firewall ist die Verwendung von Proxies. Häufig wird der Begriff „Application Level Gateway“ als Synonym verwendet. Die im Folgenden nicht aufgeführten Pattern-Elemente entsprechen denen des Security Patterns Firewall. Problem Die Firewall erfüllt ihr Aufgabe, indem nur Informationen, die innerhalb der Anwendungsschicht verfügbar sind, verwendet werden. Zusätzlich soll die Firewall für alle über sie laufenden Kommunikationsverbindungen den Kommunikationsendpunkt auf Transportebene darstellen. Eine Kommunikationsverbindung zwischen internen und externen Rechnern wird dadurch nur auf Applikationsebene ermöglicht. So werden Angriffe verhindert, die Verletzlichkeiten der Transport- oder Netzwerkschicht ausnutzen. Da das „Auftrennen“ einer Verbindung auf Applikationsebene einen hohen Aufwand darstellt, hat eine solche Firewall einen geringeren Datendurchsatz als beispielsweise ein Paketfilter. Verglichen mit einem Paketfilter kann allerdings ein höheres Sicherheitsniveau umgesetzt werden. Lösung Ein Proxy wird in den Kommunikationspfad zwischen zwei Kommunikationspartnern eingebracht, indem er für die jeweiligen Kommunikationsteilnehmer den Kommunikationsendpunkt widerspiegelt.

248 7 Netzwerke

zur Analyse verwendete Schichten Datenfluss

Proxy

Abb. 7-11 Proxy

Mithilfe dieser Vorgehensweise wird die Verbindung zwischen zwei Kommunikationspartnern durch den Proxy aufgetrennt. Alle Datenpakete, die an den Kommunikationsteilnehmer gesendet werden, nimmt der Proxy entgegen und verarbeitet diese auf Applikationsebene. Dazu benötigt er „Wissen“ über das der Kommunikation zugrunde liegende Applikationsprotokoll. Bei der Verarbeitung wird geprüft, ob sich durch die Daten Bedrohungen ergeben können. Dies geschieht anhand zuvor festgelegter Kriterien. Als Entscheidungsgrundlage, ob die Daten an den Empfänger weitergeleitet werden, können nur die aus der Applikationsschicht zu gewinnenden Informationen verwendet werden. Informationen, die in den Daten der unteren Schichten enthalten sind, stehen einem Proxy nicht zur Verfügung. Eine Firewall, die nur durch die Verwendung eines Proxies realisiert wird, setzt demnach die von einer Firewall zu übernehmenden Funktionen folgendermaßen um: – Analyse Die Header/Daten der Applikationsschicht können überprüft werden. Zusätzlich kann die Applikationssemantik überprüft werden. – Zugriffskontrolle Der Proxy kann die Identität der Kommunikationsteilnehmer anhand der benutzerbezogenen Informationen prüfen, die innerhalb der Applikationsschicht eventuell vorhanden sind. – Filterung und Modifikation Die Firewall entscheidet, ob die Daten weitergeleitet werden. Eine Modifikation der Daten ist vor dem Weiterleiten möglich. – Verbergen Da die Kommunikationsteilnehmer durch den Proxy voneinander getrennt sind, können die Netzstrukturen verborgen werden. – Audit Werden Daten durch die Firewall verworfen oder modifiziert, so wird dies entsprechend angezeigt.


Abhängigkeiten Dieses Security Pattern stellt eine Spezialisierung des Security Patterns Firewall dar. Dadurch besitzt es Abhängigkeiten zu den Security Patterns Identitätsbasierte Zugriffskontrolle und Audit. 7.4.5 NAT Network Address Translation (NAT) wurde ursprünglich entwickelt, um dem Problem der knapp werdenden IP-Adressen zu begegnen. Da nahezu alle heute verwendeten Firewalls auch über eine NAT-Komponente zur Realisierung Firewall-spezifischer Aufgaben verfügen, rechnen wir diese Funktionalität einer Firewall zu. Problem Die Firewall soll verhindern, dass Adressen der Vermittlungs- und Transportschicht außerhalb des internen Netzes verwendet werden. Zur Umsetzung dieser Aufgabe muss die Firewall auf Informationen innerhalb aller Schichten der über sie verschickten Netzwerkpakete zugreifen. Zusätzlich müssen auch Informationen berücksichtigt werden, die durch die Prüfung von zuvor verarbeiteten Paketen gewonnen wurden. Lösung Eine NAT-Komponente ermöglicht es, in einem Subnetz IP-Adressen zu verwenden, die im Internet keine Gültigkeit besitzen. Schickt ein Sender innerhalb dieses Subnetzes ein IP-Paket an einen Empfänger im Internet, so wird die an der Grenze des Subnetzes verwendete NAT-Komponente der im Internet ungültigen Adresse des Absenders durch eine gültige ersetzen. zur Analyse verwendete Schichten Datenfluss NAT-Komponente

Abb. 7-12 NAT

Die NAT-Komponente muss sich diese Adressumsetzung merken, um die eintreffenden Antwortpakete an den korrekten Empfänger durch eine weitere Umschreibung der IP-Adresse weiterleiten zu können. Neben dem Effekt, dass auf diese Weise ein gesamtes Subnetz nur eine gültige IP-Adresse zur Kommunikation mit Rechnern im Internet benötigt, beinhaltet dieser Mechanismus auch eine Schutzfunktion. Rechner innerhalb des privaten Subnetzes können aus dem Internet nicht adressiert werden, da sie keine gültige IP-Adresse besitzen. Eine Kommunikation mit internen Geräten ist erst möglich, nachdem eine Verbindung von innen initiiert

250 7 Netzwerke

und dieses Mapping in der Adressumsetzungstabelle der NAT-Komponente eingetragen wurde. Ein solches Gerät ermöglicht so das Verbergen der internen Strukturen eines Netzwerks. Eine Firewall, die nur durch die Verwendung einer NAT-Komponente realisiert wird, setzt demnach die von einer Firewall zu übernehmenden Funktionen folgendermaßen um: – Analyse Die Header-Felder der Vermittlungs-, Transport- und Applikationsschicht können hinsichtlich der NAT-Funktionalität überprüft werden. Zusätzlich kann die Verbindungssemantik überprüft werden. – Zugriffskontrolle Die NAT-Komponente kann die Identität der Kommunikationsteilnehmer anhand der verwendeten Portnummern und der IP-Adressen bestimmen. – Filterung und Modifikation Die NAT-Komponente entscheidet, ob die Daten weitergeleitet werden. Es wird entschieden, ob eine Adressumsetzung für eine bestimmte Kommunikationsverbindung durchgeführt wird. Eine Modifikation der Daten ist vor dem Weiterleiten nötig, um die verwendeten IP-Adressen und Portnummern zu verändern. – Verbergen Netzstrukturen werden durch die NAT-Komponente vollständig verborgen. – Audit Werden Daten durch die NAT-Komponente verworfen oder modifiziert, so wird dies entsprechend angezeigt. Abhängigkeiten Dieses Pattern stellt eine Spezialisierung des Pattern Firewall dar. Dadurch besitzt es Abhängigkeiten zu den Pattern Identitätsbasierte Zugriffskontrolle und Audit. 7.4.6 Zusammenfassung Eine Firewall ermöglicht es, an einem Übergangspunkt zwischen zwei, meist unter getrennter administrativer Verwaltung stehenden Netzwerken Überprüfungen und/oder Modifikationen der über die Netzgrenze fließenden Daten anhand der gegebenen Anforderungen vorzunehmen. So kann eine Firewall nur als Maßnahme gegen Bedrohungen eingesetzt werden, die am entsprechenden Netzübergang, an dem die Firewall eingesetzt wird, neutralisiert werden können. Eine Firewall kann folglich nicht die alleinige Maßnahme zur Beseitigung aller Bedrohungen darstellen und muss durch andere Maßnahmen ergänzt werden. Wird dies berücksichtigt, muss


das oben dargestellte Security-Pattern-System entsprechend erweitert bzw. mit anderen Security Patterns verknüpft werden. In Abb. 7-13 ist das resultierende Security-Pattern-System für Firewalls dargestellt. Dabei werden die Abhängigkeiten innerhalb des Systems sowie zu zentralen Security Patterns außerhalb des Systems gezeigt. Um ein Maximum an Sicherheit zu erhalten, sollten moderne FirewallArchitekturen aus einer Kombination der vorgestellten Lösungen aufgebaut werden. Dem entgegen stehen höhere Kosten und steigende Komplexität.

P1:Firewall

P2: Paketfilter

P3: NAT

P4: Proxy P6: Audit

P5: Stateful-Filter

P7: Zugriffskontrolle Abb. 7-13 Firewall Security Patterns

252 7 Netzwerke

Teil III0 Tabelle 1-0

253

Arbeiten mit Security Patterns

8


8.1 Einleitung In diesem Kapitel zeigen wir, wie Wissen und Fertigkeiten von Sicherheitsexperten in Form von Security Patterns festgehalten werden können. Dazu ist es notwendig zu wissen, wie Patterns im Allgemeinen und Security Patterns im Speziellen überhaupt gefunden werden können. Dies beinhaltet auch eine Art von Qualitätssicherung mithilfe etablierter Vorgehensweisen innerhalb der Pattern Community: Shepherding und Writer’s Workshops. Schließlich weisen wir noch auf Quellen hin, die sich besonders gut als „Rohmaterial“ für Security Patterns eignen. In den folgenden Abschnitten des Kapitels zeigen wir anhand von zwei Beispielen, wie Security Patterns über die bloße Vermittlung von Expertenwissen hinaus genutzt werden können.

8.2 Dokumentation von Security Patterns Bisher haben wir beschrieben, was Security Patterns sind, und haben ausgewählte Themen in dieser Form vorgestellt. Das Wissen beruht zu großen Teilen auf den Erfahrungen der Autoren mit der Planung, Durchführung und Ausführung des Hacker Contests. Wir möchten im Folgenden kurz darauf eingehen, wie man als Sicherheitsexperte, der bisher keine Erfahrungen mit dem Pattern-Ansatz gehabt hat, beginnt, seine Kenntnisse in dieser Form weiterzugeben. Zunächst sollte ein Problembereich betrachtet werden, nicht nur einzelne Ideen. Wir haben hier beispielsweise im Kontext von Systemen die Bereiche Authentisierung, Installation und Konfiguration oder Erkennen von Angriffen. Dabei wird schnell deutlich, dass es innerhalb dieser Bereiche verschiedene Teilprobleme gibt. Nun stellt sich die Frage, was einem Neuling (neuer Kollege, Student, Auszubilden-


8.1. Einleitung 255

der etc.) in diesem Gebiet erklärt werden müsste, damit er immer wieder auftretende Probleme genauso gut bewältigen kann wie man selbst. Alles hier Identifzierte wird in Form einer Liste festgehalten. Wir gehen zunächst davon aus, dass jedes der Listenelemente eine Lösung darstellt. Es wird damit begonnen, in mehreren Iterationen die Elemente eines Security Patterns auszufüllen. Was genau macht den Kontext aus? Welche Annahmen gelten hier implizit und explizit? Was genau ist eigentlich das Problem? Oftmals fällt es schwer, das Problem präzise zu formulieren, da man aufgrund jahrelanger Erfahrung gewissermaßen betriebsblind geworden ist und das Problem als trivial empfindet. Ein weiterer Punkt sind die Anforderungen und Schutzziele, die in einem gegebenen Kontext mit einem bestimmten Problem auftreten. Auch hier muss viel internes Wissen zutage gefördert werden. Schließlich kann man sich wieder der Lösung zuwenden. Erfüllt die Lösung alle Anforderungen? Sind alle Schutzziele erfüllt? Besonders wichtig ist auch, darauf zu achten, welche Beziehungen zu anderen Security Patterns bestehen. Der Anspruch von Security Patterns ist es, eindeutige Lösungen für wiederkehrende Probleme zu beschreiben. Dies kann aber nur dann gewährleistet sein, wenn die Security Patterns veröffentlicht und von anderen Experten begutachtet werden. Hier bietet sich beispielsweise eines der regelmäßig stattfindenden Konferenzen der PLoP-Serie an. Die Pattern Community hat hier Prozesse entwickelt, um die Qualität und die Reife eines Patterns systematisch und kontinuierlich zu verbessern. Zu den wichtigsten gehören das Shepherding, also die Betreuung eines Autors nach der erstmaligen Publikation, sowie die Writer’s Workshops, in denen einzelne Beiträge im Kreis von weiteren Autoren, die idealerweise Experten auf dem jeweiligen Gebiet sind, besprochen werden. 8.2.1 Shepherding Neil Harison hat in einem Artikel beschrieben, wie die Qualität von Patterns vor dem eigentlichen Begutachtungsprozess durch andere Experten gesteigert werden kann [58]. Das Shepherding an sich ist zwar ebenfalls ein Begutachtungsprozess, allerdings wird hier ein einziger erfahrener Autor von Patterns (der Schafhirte) einem neuen Beitrag eines Autors (das Schaf) zugeordnet. Das erklärte Ziel des Shepherds ist es dabei, das Pattern oder die Sammlug von Patterns zu verbessern. Oft sind Shepherds mit dem Prozess an sich vertraut – entweder weil sie früher selbst Beiträge eingereicht oder vorher bereits andere Autoren betreut haben. Das Shepherding ist mächtiger als herkömmliche Gutachten eines Beitrags, da Shepherd und Sheep über einen längeren Zeitraum sehr intensiv mit einem gemeinsamen Ziel zusammenarbeiten: Wenn das Pattern tatsächlich ein Pattern ist, muss es veröffentlicht werden. Die Kernpunkte des Shepherding fassen wir im Folgenden zusammen. Zunächst muss eine konstruktive Atmosphäre zwischen Autor und Shepherd aufgebaut werden. Dem Autor muss klar sein, dass er auf die Hilfe des Shepherd zählen kann. Er muss aber auch bereit sein, Hilfestellungen und Tipps anzunehmen und in das Pattern einzuarbeiten. Insbesondere muss darauf geachtet werden, dass der

256 8 Arbeiten mit Security Patterns

Shepherd nicht die Rolle des Autors übernimmt. Inhaltlich wird besonders Wert darauf gelegt, dass der Leser schnell versteht, worum es in diesem Pattern geht. Das Problem und die Lösung müssen klar formuliert sein. In diesem Zusammenhang wird auch darauf hingearbeitet, dass genau diese Lösung auch zum Problem passt. Die Lösung selbst muss schließlich – für Experten und Anfänger – überzeugend vermittelt werden. Werden diese und weitere Vorgehensweisen beachtet, ist das Pattern in einem Zustand, in dem es von weiteren Experten in einem Writer’s Workshop im Detail begutachtet werden kann. 8.2.2 Writer’s Workshops Ein mächtiges Werkzeug zur Sicherung der Qualität von Inhalt und Form eines Patterns sind „Writer’s Workshops“. Dabei geht es im Wesentlichen darum, so viel Anregungen und Kommentare zur Verbesserung eines Patterns zu erhalten wie möglich. Writer’s Workshops bilden den Schwerpunkt der PLoP-Konferenzen, können aber auch unabhängig davon veranstaltet werden. Teilnehmer der Writer’s Workshops sind idealerweise neben dem Autor Experten auf dem entsprechenden Gebiet, das im Pattern behandelt wird. Es wird davon ausgegangen, dass jeder Teilnehmer das Pattern vorher bereits gelesen und sich damit auseinander gesetzt hat. Ein Moderator sorgt für ein Ablaufen der Treffen nach folgendem Schema: – Ausschluss des Autors Der Autor des Patterns nimmt passiv an der Diskussion teil. Er wird für die anderen Teilnehmer zu einer „Fly on the Wall“, d.h., er darf bis auf weiteres nichts mehr sagen, und es wird so diskutiert, als sei er nicht anwesend. Der Hintergrund dieser Konvention besteht nicht in der Rechtfertigung des Autors für seinen Beitrag, vielmehr in der Verbesserung des Pattern. Diskussionen mit dem Autor wären an dieser Stelle für die Besprechung nur hinderlich. – Inhaltsangabe/Zusammenfassung Zunächst wird das Pattern von zwei Teilnehmern mit eigenen Worten zusammengefasst. Dies ermöglicht es dem Autor zu erkennen, ob er Kontext, Problem und Lösung didaktisch so gut dokumentiert hat, dass das Pattern von Dritten eindeutig verstanden werden kann. – Positive Aspekte Im Anschluss daran formulieren die Teilnehmer positive Aspekte des Patterns. Dies beinhaltet einerseits den Aufbau eines Patterns, wie etwa die verwendete Form (z.B. nach Alexander [2,3] oder Buschmann et al. [16]), Seitenlayout, Kennzeichnung von Problem und Lösung (z.B. durch Überschriften oder Hervorhebung durch einen fetten Zeichensatz), angemessene Verwendung von Zeichnungen und Beispielen usw. Andererseits spielen inhaltliche Kommentare eine wichtige Rolle. Dabei geht es im Wesentlichen darum, ob das Pattern tatsächlich

8.2. Dokumentation von Security Patterns 257

eine bewährte Lösung für ein wiederkehrendes Problem ist. So wird besprochen, ob die Anforderungen von der Lösung erfüllt werden und ob Beziehungen zu anderen Patterns richtig erfasst worden sind. – Verbesserungsvorschläge Im nächsten Schritt werden konstruktive Vorschläge zur Verbesserung des Patterns diskutiert. Dies betrifft ebenfalls Form und Inhalt des Patterns. Der Autor und damit auch das Pattern profitieren dabei von der Expertise der Teilnehmer des Writer’s Workshops. Beispiele hierfür sind Vorschläge für weitere Szenarien, in denen das Pattern schon einmal angewendet worden ist, alternative Bezeichnungen, um die Assoziation zwischen Namen und Lösung zu verbessern, oder präzisere Formulierungen für die Problemstellung, um diese zeitinvarianter zu machen. – Verständnisfragen Dem Autor wird nun gestattet, auf Basis von Notizen, die er sich während der Diskussion gemacht hat, Verständnisfragen an die Teilnehmer zu stellen. Auch hier ist es wichtig zu verstehen, dass es nicht um Rechtfertigung, sondern um Verbesserung des Beitrags geht. Abschließend fasst der Autor die Diskussion zusammen. Er hat nun genügend Ideen, um seine Arbeit zu verbessern, und kann sicher sein, dass sein Pattern nach Einarbeitung der Vorschläge wirklich eine bewährte Lösung darstellt, die dann einem Anwenderkreis1 zugänglich gemacht werden kann. Auch der Anwender des Patterns weiß, dass in das Pattern nicht nur die Erfahrungen des Autors, sondern auch die eines zusätzlichen Expertenkreises eingeflossen sind. 8.2.3 Quellen für Security Patterns Da Security Patterns bewährte Sicherheitslösungen für wiederkehrende Problemstellungen beschreiben, werden sie nicht erfunden, sondern gefunden. Sicherheitsstandards wie etwa der British Standard 7799 [20] oder das IT-Grundschutzhandbuch [24] sind daher wertvolle Orientierungshilfen bei der Dokumentation von Security Patterns. Das IT-Grundschutzhandbuch beispielsweise enthält Maßnahmenkataloge für verschiedene IT-Bausteine sowie universell anwendbare Konzepte wie Datensicherung und das Wiederaufsetzen nach einem Sicherheitsvorfall. Typischerweise werden relevante Bedrohungen, exemplarische Angriffe, Schutzziele und die entsprechenden Maßnahmen aufgeführt – viele Informationen also, die in Security Patterns benötigt werden. Weitere wichtige Ressourcen für Security Patterns sind Informationsquellen wie einschlägige Webseiten und Mailing-Listen sowie relevante Artikel oder Bücher (siehe Abschnitt 3.7). Besonders wichtig sind 1

Patterns der PLoP-Konferenzen werden typischerweise auch im Internet publiziert und sind ohne Einschränkungen jedem zugänglich.


auch interne Informationsquellen: die Mitarbeiter eines Unternehmens, die am besten wissen, „wie es schon immer gemacht worden ist“, und dies auch begründen können. Bevor damit begonnen wird, nach Material für Security Patterns in Sicherheitsstandards und anderen Informationsquellen zu suchen 2, müssen zunächst die Zusammenhänge zwischen den Begriffen und Konzepten in den jeweiligen Informationsquellen und den Elementen von Security Patterns herausgearbeitet werden, da nicht davon ausgegangen werden kann, dass eine einheitliche Terminologie verwendet wird. Außerdem möchten wir darauf hinweisen, dass es oftmals notwendig ist, mehr als eine Informationsquelle für die Recherche heranzuziehen, da nicht immer alle Elemente eines Security Patterns auf einmal vorhanden sind. Dies gilt erfahrungsgemäß insbesondere für die Beziehungen zwischen Security Patterns sowie dem Kontext. Solche Aussagen sind oft nicht explizit in den Informationsquellen enthalten. Als Beispiel haben wir eine Möglichkeit aufgezeigt, wie Kontext, Problem und Anforderungen eines Security Patterns entsprechend der Terminologie der Common Criteria vereinheitlicht und formalisiert werden können [106]. Wie in Tabelle 8-1 dargestellt, wird in den Common Criteria eine Menge von standardisierten Aussagen, die mit den Elementen von Security Patterns in Beziehung gebracht werden können, festgelegt. Tab. 8-1 Security Patterns und Common-Criteria-Elemente

Security Patterns

Common Criteria

Kontext

Annahmen, Policy-Aussagen

Problem

Bedrohungen, Angriffe

Anforderungen

Funktionale Sicherheitsanforderungen

Lösung

–

Im Teil 1 der Common Criteria, „Einführung und allgemeines Modell“, lassen sich Definitionen dieser Elemente finden. Im Anhang C wird dort beschrieben, wie ITSicherheitsvorgaben standardgemäß spezifiziert werden sollen. Werte für die einzelnen Parameter lassen sich beispielsweise in der „Common Criteria Knowledge Base“ finden. Dabei handelt es sich um eine vom NIAC entwickelte Wissensdatenbank, die frei bezogen werden kann [Quelle]. Wir möchten darauf hinweisen, dass die Common Criteria als Evaluierungsstandard selbst keine Lösungen enthalten.

2

Im Englischen wird hier analog zum Erzabbau von „Pattern Mining“ gesprochen, also dem „Schürfen“ nach Patterns in „Wissensgruben“.


– Sicherheitsumgebung Die Annahmen beschreiben die Sicherheitsaspekte der Umgebung, in der beabsichtigt wird, eine IT-Ressource zu nutzen. Es gibt verschiedene Kategorien von Annahmen. Dazu gehören beispielsweise Annahmen über das Verhalten von Administratoren und Benutzern. Weiterhin müssen Annahmen über die Sicherheit von Daten und Kommunikationskanälen sowie physikalische und organisatorische Sicherheit getroffen werden. Solche Annahmen beziehen sich auf den Kontext eines Security Patterns und müssen durch andere Security Patterns vorab gewährleistet sein. – Sicherheitspolitiken In der Regel müssen IT-Ressourcen bestimmten Sicherheitspolitiken des Eigentümers entsprechen. Optional ist daher eine explizite Beschreibung typischer Aussagen von Sicherheitspolitik hilfreich, um später die Schutzziele eines Security Patterns nachvollziehbarer zu machen. Die Sicherheitspolitiken werden ebenfalls dem Kontext eines Security Patterns zugeordnet. – Sicherheitsziele Die Sicherheitsziele adressieren alle identifzierten Sicherheitsaspekte. Sie müssen „geeignet sein, allen identifizierten Bedrohungen entgegenzuwirken und alle organisatorischen Politiken und Annahmen abzudecken.“ Sie gehören daher zur Beschreibung des Problems eines Security Patterns. – Bedrohungen und Angriffe Bedrohungen werden durch Angreifer hervorgerufen. Wie in Abschnitt 2.1.5 beschrieben, werden die Angreifer durch deren Motivation, Fachkenntnisse und verfügbare Ressourcen charakterisiert. Auch Angriffe werden in den Common Criteria genannt. Sowohl für Bedrohungen und Angriffe existieren verschiedene Kategorien und detaillierte Listen. Sie werden ebenfalls der Problembeschreibung von Security Patterns zugeordnet. – Funktionale Sicherheitsanforderungen Die funktionalen Sicherheitsanforderungen sind in mehreren hierarchischen Klassen organisiert, wie beispielsweise Privatsphäre und Authentisierung. Auf diese Weise kann klar festgelegt werden, welchen Anforderungen eine IT-Ressource und deren Umgebung genügen müssen, um den identifizierten Bedrohungen entgegnen zu können. Wir glauben, dass sowohl Autoren als auch Anwender von Security Patterns von Sicherheitsstandards und vergleichbaren Informationsquellen profitieren können [106]. Obwohl die Terminologie Security Patterns auf diese Weise mehr standardisiert und formalisiert wird, sind die Security Patterns selbst immer noch lesbar und verständlich. Der Vorteil dabei ist, dass es leichter wird, Security Patterns von verschiedenen Autoren in ein größeres Security Pattern-System zu integrieren. Ob-


wohl viele Praktiker der Pattern Bewegung denken, dass formale Ansätze nicht auf Patterns angewendet werden sollten [16], sind wir der Meinung, dass dies insbesondere bei Security Patterns Sinn macht, da so besser festgestellt werden kann, ob bestimmte Sicherheitsanforderungen tatsächlich umgesetzt werden. Da Annahmen, Schutzziele und Anforderungen präzise identifiziert werden können, wird es möglich, Security Pattern in gewisser Weise mehr Vertrauen entgegezubringen. Es kann nämlich davon ausgegangen werden, dass Sicherheitsstandards von Experten verfasst werden. Interne Kommentare der Herausgeber und öffentliche Rückmeldungen haben dabei geholfen, sie im Lauf der Zeit kontinuierlich zu verbessern, d.h., sie sind stimmig hinsichtlich Form und Inhalt. Es ist ein andauerndes Experiment, Sicherheitstandards als Quelle für Security Patterns zu nutzen. Unsere Erfahrung mit diesem Ansatz hat allerdings gezeigt, dass der Dokumentationsprozess signifikant beschleunigt werden kann. Experten kennen üblicherweise die Lösungen zu einem bestimmten Problem. Werden sie aber gebeten, ihr Know-how zu dokumentieren, geraten sie zwangsläufig in Schwierigkeiten, da sie auf Wissen zurückgreifen, das ein Resultat jahrelanger praktischer Erfahrungen ist. Es kann davon ausgegangen werden, dass solches Wissen nicht explizit vorliegt. Da Standards wie die Common Criteria dabei helfen, diese eher schwierigen Aspekte eines Security Patterns zu verfassen, kann sich der Autor voll und ganz auf die Dokumentation der Lösung konzentrieren. Um auch praktisch zu zeigen, dass Sicherheitsstandards bei der Dokumentation von Security Patterns hilfreich sind, haben wir mehrere Security Patterns nach diesem Ansatz verfasst [106]. Die Erkenntnisse dieser Arbeit und entsprechender Rückmeldungen waren dabei wie folgt: – Die funktionalen Sicherheitsanforderungen repräsentieren eine vollständige Menge der sicherheitsrelevanten „Forces“ von Security Patterns. Die Wahrscheinlichkeit, dass eine Anforderung vergessen wird, ist daher eher gering. – Viele Sicherheitsstandards beinhalten umfangreiche Sammlungen von Annahmen, Bedrohungen, Angriffen sowie Schutzzielen. Dies hilft ebenfalls dabei, die entsprechenden Abschnitte eines Security Patterns so vollständig wie möglich zu beschreiben. – Selbst wenn – wie in den Common Criteria – keine Lösungen enthalten sind, helfen Sicherheitsstandards dabei, zielgerichtet nach anderen Informationsquellen zu suchen. Eine Analyse von Sicherheitsstandards hat gezeigt, dass eine sorgfältig zusammengestellte Sammlung von Security Patterns insbesondere für Laien effizienter als die Standards selbst ist, da diese klar strukturiert sind und Beziehungen zwischen den einzelnen Security Patterns berücksichtigt werden.


8.2.4 Sequenzen von Security Patterns Pattern-Sequenzen beschreiben sinnvolle Anwendungsreihenfolgen von zueinander in Beziehung stehenden Patterns. Es handelt sich hier um ein vergleichweise neues Forschungsthema, das von James Coplien initiiert und erstmals ausführlicher auf der EuroPLoP-Konferenz 2001 diskutiert worden ist [31]. Coplien beschreibt Sequenzen auch als „Architect’s Tour“. Dies bringt zum Ausdruck, dass sie den Anwender von Patterns dabei unterstützen sollen, sein System unter Verwendung von Patterns zu entwerfen.

C

A

B

D

Abb. 8-1 Sequenzen von Patterns

Entscheidend für Sequenzen sind die Beziehungen setzt voraus. Setzt beispielsweise die Anwendung des Patterns B die des Patterns A voraus und sind C sowie D zwei Patterns, die beide die Anwendung von Pattern B voraussetzen, so sind A, B, C und A, B, D mögliche Sequenzen des Pattern-Systems. Abbildung 8-1 zeigt exemplarisch, wie diese Sequenzen dargestellt werden können. Dabei kann es sich bei den Patterns C und D um Alternativen handeln, oder es müssen beide angewendet werden, nachdem B umgesetzt worden ist.

8.3 Anwendungsbeispiel: Sicherheit im LAN Nehmen wir an, ein Netzwerkadministrator hat festgestellt, dass in dem von ihm betreuten LAN sensible Daten durch das Abhören der Kommunikation zwischen zwei Rechnern von Dritten eingesehen werden können. Es wird entschieden, dass diese Bedrohung beseitigt werden soll. Diese Entscheidung entspricht dem Festlegen eines Schutzzieles, womit die Suche nach einem geeigneten Security Pattern beginnen kann. 8.3.1 Auswahl von Security Patterns Der Administrator entscheidet sich, das Security Pattern Abhören der Kommunikation im Ethernet zur Lösung seines Problems zur Hilfe zu nehmen, da es sein Problem


passend beschreibt (hinsichtlich des Kontextes, des Schutzzieles und der Bedrohung). Er sieht, dass ein Switch sein Problem lösen kann, und entscheidet sich, einen solchen zu beschaffen und das Netzwerk umzurüsten. Bei der Auswahl eines geeigneten Produktes helfen ihm die im Security Pattern angegebenen Abhängigkeiten. Er entscheidet sich für einen Switch, der alle in den abhängigen Security Patterns festgelegten Maßnahmen ebenfalls umsetzt. Die in diesen Security Patterns beschriebenen Sachverhalte unterstützen gewissermaßen den Administrator dabei, den Herstellern die „richtigen“ Fragen zu stellen. Die festgestellte Bedrohung ist nun – unter Zuhilfenahme des Security-Pattern-Systems – beseitigt worden. Das Security Pattern sowie alle davon abhängenden Security Patterns sind implementiert und befinden sich in einem konsistenten Zustand. 8.3.2 Modellierung mit Security Patterns Damit das Abhören im Netzwerk auch dauerhaft kein Bedrohung darstellt bzw. sich im Laufe der Zeit keine neue Bedrohungen – möglicherweise auch unerkannt – ergeben, ist der Sicherheitszustand der zu schützenden Ressource (also dem LAN) zu überwachen. Hierfür kann ebenfalls das Security-Pattern-System Sicherheit im Local Area Network verwendet werden (siehe Abbildung 7-2). Dazu wird das Security-Pattern-System durch Spezialisierungen ergänzt, die in diesem Fall konkrete Implementierungen der Security Patterns sind. Implementierungen sind streng genommen keine Security Patterns. Integriert man sie allerdings in ein Security-Pattern-System, um reale Netzwerkszenarien zu modellieren, lassen sich beispielsweise die Auswirkungen von Inkonsistenzen untersuchen. Im Folgenden zeigen wir, wie solch eine Modellierung abläuft. Die im Security-Pattern-System verwendeten Pattern können grundsätzlich in der Sektion „Lösung“ verschiedene alternative Lösungsmöglichkeiten für das entsprechende Problem angeben. Bei der Modellierung eines realen Szenarios muss natürlich berücksichtigt werden, dass man sich bei der konkreten Umsetzung im Allgemeinen für eine der Alternativen entschieden hat. Dementsprechend fallen alle Security Patterns (sowie die von diesen wiederum abhängenden Security Patterns) bei der Modellierung. Im unserem Beispiel muss dies allerdings nicht berücksichtigt werden, da es nur genau eine Lösungsmöglichkeit (d.h. der „Switch“) gibt. Jetzt muss das Security-Pattern-System die spezialisierten „Platzhalter“ für die konkreten Implementierungen erweitern. Der Unterschied zwischen der Implementierung und dem zugehörigen Security Pattern liegt darin, dass in der konkreten Umsetzung bzw. Implementierung zusätzliche Bedrohungen und Angriffe existieren können (d.h., die Implementierung entspricht typischerweise nicht dem Ideal des Security Patterns). In dem hier dargestellten Beispiel betrachten wir zunächst das Security Pattern Missbrauch der administrativen Zugänge (P3). Aufgrund der Auswahl und Verwendung eines speziellen, herstellerspezifischen Switches wird dieses Security Pattern mit zwei speziellen Ausprägungen eines administrativen Zugangs verknüpft:

8.3. Anwendungsbeispiel: Sicherheit im LAN 263

– Administrativer Zugang über eine HTTP-Schnittstelle (P3-A) – Administrativer Zugang über eine SNMP-Schnittstelle (P3-B) Diese in das Security-Pattern-System integrierten Implementierungen weisen nun sicherheitsrelevante Eigenschaften auf, die nur für diese speziellen Zugänge gelten. Der HTTP-Zugang ist beispielsweise zusätzlich dadurch bedroht, dass der entsprechende HTTP-Server eine Schwachstelle – hinsichtlich Implementierung und Konfiguration – aufweisen kann. Deshalb ist dieses Security Pattern mit einem Security Pattern3, das die Sicherheitsprobleme eines WWW-Servers (P6) beschreibt, verknüpft. Gleiches gilt für den SNMP-Zugang, d.h., auch hier sollte es ein Security Pattern für die Sicherheit eines SNMP-Servers geben (P7). Grundsätzlich müssen nicht alle Security Patterns mit einer Implementierung in Verbindung gesetzt werden. Dies hat allerdings Auswirkungen auf die „Genauigkeit“ der Modellierung des Systems. Werden nämlich keine Implementierungen in Beziehung mit dem eigentlichen Security Pattern gesetzt, so können nachfolgend auch nur die allgemeinen Aspekte betrachtet werden. Implementierungs- und umsetzungsspezifische Eigenschaften bleiben dann für diesen Teilaspekt des Systems unbeachtet.

P1

P2

P3

P3A

P4

P6 P3B

P7 P1: Abhören der Kommunikation im Ethernet P2: Manipulation der MAC-Adressen P3: Missbrauch der administrativen Zugänge P4: Identifikation und Authentisierung

P3-A: HTTP-Schnittstelle P3-B: SNMP-Schnittstelle P6: HTTP-Server P7: SNMP-Server

Abb. 8-2 Modellierung eines Switch-Pattern-Systems

3

Dieses Security Pattern ist nicht in diesem Buch beschrieben.


Das Security Pattern Identifikation und Authentisierung (P4) werden wir in dem hier betrachteten Security Pattern-System beispielsweise nicht mit einer Implementierung verbinden. So können also nur allgemeine Aspekte der Authentisierung beachtet werden, nicht aber konkrete Implementierungen. Es wäre aber grundsätzlich möglich, die Authentisierung des HTTP-Servers sowie des SNMP-Servers ebenfalls durch zwei Platzhalter zu integrieren. Ein weiterer Punkt, der Auswirkungen auf die „Genauigkeit“ der Modellierung hat, ist der Grad der Vollständigkeit des Security-Pattern-Systems, d.h., sind wirklich alle relevanten Security Patterns bekannt und integriert? Hier muss sich der Anwender der Security Patterns grundsätzlich auf den Autor und die Prozesse der Qualitätssicherung von Security Patterns verlassen (siehe Abschnitt 8.2). Außerdem könnten wir bereits im generellen Security-Pattern-System auch das sicherlich relevante Betriebssystem eines Switches sowie dessen konkrete Ausprägung im gewählten Produkt berücksichtigen. Für das hier gegebene Beispiel verzichten wir allerdings auf eine vollständige Modellierung, um die Komplexität des Beispiels gering zu halten. Dies reicht zudem aus, um einige interessante Effekte darzustellen. 8.3.3 Auswirkung von Inkonsistenzen Mit dem erweiterten Security Pattern-System im LAN-Kontext lässt sich nun der aktuelle Sicherheitszustand des herstellerspezifischen Switches modellieren. Die internen und externen Abhängigkeiten, die wiederum Einfluss auf den aktuellen Sicherheitszustand des Systems haben, können erfasst werden. Dies geschieht, indem wir die Semantik der Relationen zwischen den einzelnen Security Patterns betrachten. Durch das Bekanntwerden eines neuen Angriffs kann die Implementierung eines Security Patterns inkonsistent werden. Der neue Angriff muss dann zu den bereits beschriebenen Angriffen innerhalb der Beschreibung des Problems hinzugefügt werden. Dadurch wird nun gewissermaßen auch das Security Pattern inkonsistent, da den beschriebenen konkreten Angriffen keine Maßnahmen innerhalb der Lösung entgegenstehen. Diese interne Inkonsistenz kann sich jetzt auch auf andere Security Patterns bzw. Implementierungen auswirken: – Der SNMP-Server weist eine Verletzlichkeit auf, d.h., P7 ist inkonsistent. Da P3B dieses Security Pattern voraussetzt, ist die externe Konsistenz nicht mehr gegeben, d.h., P3-B wird ebenfalls unsicher. Das generische Security Pattern P3 kann jetzt auch als inkonsistent angenommen werden, da die Implementierung wie beschrieben nicht ideal ist. Durch eine weitere Abhängigkeit ist somit auch das Security Pattern P1 betroffen, nicht aber das Security Pattern P2. Ebenso ist die Implementierung P3-A nicht von dieser Inkonsistenz betroffen. – Ist beispielsweise das Security Pattern P4 inkonsistent, breitet sich dieser Fehler zunächst nach P3 und damit auch auf die Implementierungen aus. Es handelt sich in diesem Fall um einen grundlegenden Fehler, d.h., auch die Implementierungen

8.3. Anwendungsbeispiel: Sicherheit im LAN 265

P3-A und P3-B sind betroffen (nicht aber die Implementierungen P6 und P7. Ausgehend von P3 ist auch das Security Pattern P1 von der Inkonsistenz betroffen. Um das reale Netz wieder in einen konsistenten Zustand zu bekommen, müssen entsprechende Maßnahmen identifiziert und umgesetzt werden. Um einem neuartigen Angriff auch zukünftig entgegenwirken zu können, muss geprüft werden, ob es sich um einen grundlegenden Fehler oder einen implementierungsspezifischen Fehler handelt. Im ersten Fall kann es notwendig sein, dass das generische Security Pattern überarbeitet werden muss.

8.4 Anwendungsbeispiel: Sicherheit im WAN In diesem Abschnitt zeigen wir, wie man mithilfe des Security-Pattern-Systems Sicherheit im Wide Area Network Fehler in der Implementierung eines virtuellen privaten Netzes im Vorfeld hätte erkennen können. Dazu stellen wir zunächst die spezialisierten, sehr implementierungsnahen Security Patterns vor, bevor wir diese wie zuvor zur Modellierung des VPN verwenden. 8.4.1 Virtuelles privates Netzwerk (PPTP) Mithilfe des Point-to-Point-Tunneling-Protokolls (PPTP) kann ein spezielles VPN realisiert werden. Dementsprechend stellt das im Folgenden dargestellte PPTP-VPN eine Spezialisierung des allgemeinen VPN Security Patterns dar. Der Kontext, Bedrohungen und Sicherheitsziele ergeben sich aus der Spezialisierung des VPN Security Patterns. Das PPTP Security Pattern unterscheidet sich durch die Berücksichtigung einer speziellen Anforderung sowie der entsprechend angepassten Lösung. Anforderungen Als Randbedingung ist die Berücksichtigung von verschiedenen Protokollen der OSI-Schicht 3 (beispielsweise IPX) innerhalb der privaten Netze gegeben. Dies bedeutet, dass nicht nur private IP-basierte Netze sicher über das dazwischen liegende öffentliche Netz miteinander kommunizieren können. Der gesicherte Tunnel stellt somit neben seiner Schutzfunktion auch eine „Brückenfunktion“ zur Verfügung, mit der sich zwei nicht-IP-basierte Netze über ein IP-basiertes Netz verbinden lassen. Lösung PPTP wird dazu verwendet, verschiedene Protokolle auf der OSI-Schicht 3 gesichert über ein bestehendes IP-Netz zu transportieren. Um die Layer-3-Pakete über das IP-Netz zu transportieren, wird innerhalb von PPTP wiederum das PPP-Protokoll verwendet [125]. Das PPTP-Protokoll selbst bietet generell keine Sicherheits-


dienste an. Innerhalb des PPTP-Protokolls wird für die eigentliche Einkapselung der zu transportierenden Daten das PPP-Protokoll verwendet. Das PPP-Protokoll seinerseits bietet dann über zusätzliche Protokolle eine Authentisierung sowie eine Verschlüsselung an, so dass auf diesem Weg die notwendigen Schutzziele erreicht werden können. Die ausführliche Beschreibung des PPTP-Protokolls ist in [49] gegeben. Im Folgenden wird die Funktionsweise eines PPTP-VPNs kurz beschrieben: – Das PPTP-Protokoll besteht aus zwei Hauptkomponenten: einem TCP/IP-Kontrollkanal und einem Generic-Routing-Encapsulation(GRE)-Datenkanal. Bevor zwischen zwei PPTP-VPN-Routern PPP-Pakete ausgetauscht werden können, muss zuerst eine TCP-Verbindung zwischen den beiden Endpunkten aufgebaut werden. Diese TCP-Kontrollverbindung ist mit der eigentlichen GRE-Datenverbindung assoziiert, aber unabhängig von ihr. Nachdem die TCP-Kontrollverbindung aufgebaut wurde, wird mittels ausgetauschter Nachrichten auf dieser Verbindung der Datenkanal aufgebaut. Nachdem über den Kontrollkanal der Datenstrom initiiert wurde, fließen über den GRE-Datenkanal die PPP-Pakete. Die den Datenkanal nutzende PPP-Verbindung beginnt ihrerseits mit einigen Setup-Meldungen, mit denen Parameter für die PPP-Verbindung ausgehandelt werden. Nach dieser initialen PPP-Aushandlung fließen dann über den GREDatenkanal PPP-Pakete, die zwischen den VPN-Routern die zu tunnelnden IPPakete (oder IPX-Pakete) beinhalten. – Nach dem Aufbau des TCP-Kontrollkanals kann die PPP-Verbindung über den GRE-Datenkanal aufgebaut werden. Zum Aufbau der PPP-Verbindung wird innerhalb von PPP das Link Control Protocol (LCP) dazu verwendet, um die Punkt-zu-Punkt-Verbindung zu konfigurieren und zu testen. Danach werden innerhalb von PPP verschiedene Network-Control-Protokolle (NCP) verwendet, um die Layer-3-Schichten für den Datentransport zu konfigurieren. Innerhalb der LCP-Phase erfolgt die Authentisierung (z.B. CHAP), wozu verschiedene Mechanismen verwendet werden können. Über das LCP-Protokoll kann ebenfalls ein Kompressionsverfahren zwischen den Kommunikationspartnern ausgehandelt werden. – Bei PPTP wird hier anstelle eines Kompressionsverfahrens ein Verschlüsselungsverfahren (z.B. Microsoft Point-To-Point Encryption Protocol, MPPE) ausgehandelt. Abhängigkeiten Das PPTP-Protokoll basiert in wesentlichen Punkten auf dem PPP-Protokoll. Das Authentisierungsverfahren des PPTP-VPNs entspricht dem innerhalb des PPP-Protokolls verwendeten Authentisierungsverfahren. Dadurch hängt das PPTP-VPNPattern von dem Security Pattern PPP-Authentisierung ab. Gleiches gilt für die

8.4. Anwendungsbeispiel: Sicherheit im WAN 267

Abhängigkeit von dem Pattern PPP-Verschlüsselung, da auch das verwendete Verschlüsselungsverfahren auf den innerhalb von PPP definierten Verfahren basiert. Weitere Abhängigkeiten wie beispielsweise zu Security Patterns zur Sicherheit der Endpunkte eines VPN betrachten wir hier nicht explizit. 8.4.2 PPP-Verschlüsselung Dieses Security Pattern ist eine Spezialisierung des Security Patterns Verschlüsselung. Die Vertraulichkeit der übertragenen Informationen muss gewährleistet werden. Kontext Der Kontext dieses Patterns ist durch die in [125] gegebene Definition des Point-toPoint Protocol (PPP) festgelegt. Problem Die Probleme entsprechen dem des allgemeinen Security Patterns zur Verschlüsselung. Die über eine PPP-Verbindung übertragenen Netzwerkpakete sind also grundsätzlich den Bedrohungen des Abhörens ausgesetzt. Lösung Die zu übertragenden Netzwerkpakete müssen durch geeignete kryptografische Verfahren gesichert werden, so dass die Vertraulichkeit gewährleistet bleibt. Zum Aufbau einer PPP-Verbindung wird innerhalb von PPP das Link Control Protocol (LCP) dazu verwendet, um die Punkt-zu-Punkt-Verbindung zu konfigurieren und zu testen. Über das LCP-Protokoll kann ein Kompressionsverfahren zwischen den Kommunikationspartnern ausgehandelt werden. Anstelle des Kompressionsverfahrens kann hier ein Verschlüsselungsverfahren (z.B. Microsoft Point-To-Point Encryption Protocol, MPPE) ausgehandelt werden. Abhängigkeiten Das zuvor dargestellte PPTP-VPN Security Pattern hängt von dem hier beschriebenen Security Pattern ab. Außerdem stellt dieses Security Pattern eine Spezialisierung des allgemeineren Security Pattern Verschlüsselung dar. Zusätzlich ist dieses Pattern mit dem nachfolgend beschrieben Security Pattern Microsoft Point-To-Point Encryption Protocol verknüpft, da dieses Security Pattern wiederum eine Spezialisierung von dem hier beschriebenen Security Pattern darstellt.


8.4.3 Microsoft Point-To-Point Encryption Protocol Dieses Security Pattern stellt eine mögliche Spezialisierung des zuvor beschriebenen Security Patterns PPP-Verschlüsselung dar. Kontext, Problem und Lösung entsprechen deshalb denen des Security Patterns PPP-Verschlüsselung und sind deshalb hier nicht noch einmal aufgeführt; die Unterscheidung liegt in der verwendeten speziellen Umsetzung der Lösung. Lösung Das MPPE-Protokoll definiert ein Verfahren, mit dessen Hilfe Daten über eine Punkt-zu-Punkt-Verbindung verschlüsselt übermittelt werden können. MPPE definiert einen entsprechenden Protokoll-Header, der den zu übermittelnden verschlüsselten Daten vorangestellt wird. Dieser Header enthält Informationen (z.B. eine Sequenznummer), die zwischen beiden Kommunikationspartnern für den Betrieb der MPPE-Strecke ausgetauscht werden müssen. Das MPPE-Verfahren verwendet den RSA-Algorithmus RC4 für die Verschlüsselung der Daten. Während der Laufzeit einer Verbindung werden diese Schlüssel erneuert, um eine Kryptanalyse zu erschweren. Theoretisch kann für jedes übertragene Paket der OSI-Schicht 3 ein neuer Schlüssel verwendet werden. Abhängigkeiten Das hier beschriebene Pattern ist eine Spezialisierung des Patterns PPP-Verschlüsselung. Damit ist es ebenfalls transitiv mit dem Security Pattern Verschlüsselung verknüpft. Außerdem besteht eine Verknüpfung mit dem Security Pattern 4 RSARC4, da dieses Verfahren von MPPE zur Verschlüsselung verwendet wird. 8.4.4 PPP-Authentisierung Innerhalb von PPP müssen die Endpunkte einer Verbindung authentisiert werden, damit kein unberichtigter Zugriff möglich ist. Kontext Der Kontext dieses Patterns ist durch die Definition des Point-to-Point Protocol (PPP) festgelegt. Problem Ein Kommunikationsendpunkt einer PPP-Verbindung kann sich hinsichtlich der Identität des Kommunikationspartners nicht sicher sein. Es ist demnach nicht si4

Dieses Security Pattern beschreiben wir an dieser Stelle nicht.


chergestellt, dass die übertragenen Netzwerkpakete auch von demjenigen empfangen werden, den der Absender der Netzwerkpakete als Empfänger annimmt. Lösung Bevor über eine PPP-Verbindung Netzwerkpakete ausgetauscht werden können, muss sichergestellt werden, dass beide Endpunkte der PPP-Verbindung sich authentisieren. Der jeweilige Kommunikationspartner kann so die Identität seines Gegenüber feststellen. Zum Aufbau einer PPP-Verbindung wird innerhalb von PPP das Link Control Protocol (LCP) dazu verwendet, um die Punkt-zu-Punkt-Verbindung zu konfigurieren und zu testen. Innerhalb der LCP-Phase kann über verschiedene Mechanismen eine Authentisierung (z.B. über CHAP) erfolgen. Abhängigkeiten Das zuvor dargestellte PPTP-VPN Security Pattern hängt von dem hier beschriebenen Security Pattern ab. Außerdem stellt dieses Patten eine Spezialisierung des allgemeineren Pattern Identifikation und Authentisierung dar. Zusätzlich ist dieses Security Pattern mit dem nachfolgend beschriebenen Security Pattern CHAP verknüpft, da dieses Pattern wiederum eine Spezialisierung des hier beschriebenen Pattern darstellt. 8.4.5 Challenge Handshake Authentication Protocol Es werden im Folgenden wiederum nur die Pattern-Elemente beschrieben, die sich von den Elementen der allgemeineren Pattern PPP-Authentisierung unterscheiden. Lösung Das CHAPv1-Protokoll wird verwendet, um den Initiator (Client) der PPP-Verbindung zu authentifizieren. Dieses Verfahren läuft folgendermaßen ab: Der Client fordert einen so genannten „Login Challenge“ vom Server an. Der Server schickt dem Client einen „Random Challenge“, also eine Zufallszahl. Der Client verwendet sein Passwort, um daraus einen symmetrischen DES-Schlüssel abzuleiten. Diesen Schlüssel verwendet dann der Client, um den „Random Challenge“ zu verschlüsseln. Dieser verschlüsselte Wert wird dann an den Server zurückgeschickt. Der Server entschlüsselt diesen Wert mithilfe des in seiner Passwortdatenbank gespeicherten Client-Passwort-Hashs. Wenn der entschlüsselte Block mit dem zuvor gesendeten „Random Challenge“ übereinstimmt, ist die Authentisierung vollständig, und der Server sendet dem Client eine „Success“-Meldung.


Abhängigkeiten Dieses Security Pattern ist eine Spezialisierung des Security Patterns PPP-Authentisierung. Damit ist es ebenfalls mit dem Security Pattern Identifikation und Authentisierung verknüpft. 8.4.6 Analyse der Implementierung Das VPN-Pattern-System kann nun wie in Abbildung 8-3 gezeigt durch die implementierungsnahen Security Patterns erweitert werden. Sowohl für die PPP-Authentisierung als auch die PPP-Verschlüsselung existieren verschiedene Ausprägungen (z.B. MPPE und CHAP), welche jeweils durch ein weiteres spezialisierendes Security Pattern beschrieben werden können.

P1: Virtuelles privates Netz

P2

P3

P4

P5: Virtuelles privates Netzwerk (PPTP)

P6: PPP-Verschlüsselung

P7: PPP-Authentisierung

P8: MPPE

P9: CHAP

P10: RSA RC4

P2: Systeme P3: Verschlüsselung P4: Identifikation und Authentisierung

Abb. 8-3 Implementierung des VPN-Pattern-Systems

Wie bereits in den vorhergehenden Security Patterns beschrieben, verwendet das PPTP-Protokoll das PPP-Protokoll. Innerhalb dieses Protokolls wird das CHAPv1Protokoll verwendet, um den Client (den Initiator des Tunnels) zu authentifizieren. Bei einer Implementierung des Protokolls von der Firma Microsoft laufen dabei folgende Schritte ab:


– Der Client fordert einen so genannten „Login Challenge“ vom Server an. – Der Server schickt dem Client eine 8 Byte große „Random Challenge“, eine Zufallszahl. – Der Client verwendet den LAN-Manager-Hash seines Passworts, um daraus drei DES-Schlüssel abzuleiten. Diese Schlüssel verwendet dann der Client, um den „Random Challenge“ zu verschlüsseln. Diese drei verschlüsselten Blöcke werden dann zu einem 24-Byte-Wert zusammengefügt. Danach wird dieses Verfahren unter Verwendung des NT-Passwort-Hashs wiederholt. Diese beiden verschlüsselten 24-Byte-Werte werden dann an den Server geschickt. – Der Server entschlüsselt die 24-Byte-Werte mithilfe des in seiner Passwortdatenbank gespeicherten Client-Passwort-Hashs. Wenn der dann entschlüsselte Block mit dem zuvor gesendeten „Random Challenge“ übereinstimmt, ist die Authentisierung vollständig, und der Server sendet dem Client eine „Success“-Meldung. – Anschließend wird das MPPE-Protokoll innerhalb von PPP verwendet, um die Daten auf dem Transport zu verschlüsseln. In beide Richtungen (also vom Client zum Server sowie vom Server zum Client) wird dabei derselbe Schlüssel genutzt. Der verwendete Schlüssel wird dabei vom NT-Passwort-Hash abgeleitet. Auf den ersten Blick erscheint dies wie eine richtige Implementierung der beschriebenen Security Patterns. Mithilfe der Modellierung lassen sich nun aber verschiedene Sicherheitslücken aufdecken: – Innerhalb von Windows NT werden zwei verschiedene Passwort-Hashs der Benutzer innerhalb der Passwortdatenbanken gespeichert: zum einen der Windows NT-Passwort-Hash, zum anderen aus Kompatibilitätsgründen der Passwort-Hash des LAN-Managers. Dabei sind beide Hash-Werte aus demselben Passwort abgeleitet. Der Passwort-Hash von Windows NT wird mithilfe des MD4-Verfahrens aus dem 14 Zeichen langen Passwort gebildet. Der Passwort-Hash des LAN-Managers wird gebildet, indem alle Buchstaben des Passworts in Großbuchstaben umgewandelt werden und dann mithilfe des DES-Verfahrens verschlüsselt werden. Um das Passwort eines Benutzers zu entschlüsseln, kann entweder der Hash des LAN-Managers oder der Hash von Windows NT entschlüsselt werden. Der Passwort-Hash des LAN-Managers lässt sich mit sehr geringem Aufwand durch eine Wörterbuch-Attacke entschlüsseln. Dadurch ist dann auch das Passwort von Windows NT bekannt. – Da beide Hashs innerhalb des verschlüsselten CHAP Login-Challenges verwendet werden, können aus dieser Nachricht beide Hashs extrahiert und durch eine Wörterbuch-Attacke entschlüsselt werden. Damit ist das Security Pattern P9 inkonsistent. Das Client-Passwort kann also durch ein Mithören der (zu diesem


Zeitpunkt noch unverschlüsselten) Kommunikation ermittelt werden. Da das verwendete Verschlüsselungsverfahren seinen Schlüssel ebenfalls aus den NT-Passwörtern ableitet, ist dieser dadurch ebenfalls gefährdet. Das Security Pattern MPPE ist somit ebenfalls inkonsistent.

Durch die Art der Implementierung ist der so entstandene verschlüsselte Tunnel nur so sicher, wie es das Client-Passwort gegen eine Wörterbuch-Attacke ist. Die Inkonsistenzen breiten sich so aus, dass letzten Endes die Sicherheit des gesamten VPN (Security Pattern P5) nicht mehr gewährleistet werden kann. Die Situation ist in diesem Fall sogar noch schlimmer. Wir haben in der Modellierung das Windows NTPasswort, aus dem die Hash-Werte berechnet werden, nicht berücksichtigt. Sind die Hash-Werte bekannt, sind also nicht nur das Verschlüsselungs- und Authentisierungsverfahren (und damit das gesamte VPN), sondern auch die Endpunkte selbst betroffen, da das Passwort hier ebenfalls verwendet wird. Dieses Beispiel zeigt, dass die Verwendung theoretisch sicherer Methoden nicht ausreicht, um Schutzziele durchzusetzen. Es ist ebenfalls nötig, diese Methoden so umzusetzen, dass die in der Realität auftretenden Randbedingungen die Erreichung der Schutzziele nicht unmöglich machen.


Ausblick

9


9.1 Zusammenfassung Zunächst möchten wir die wichtigsten Beiträge dieses Buches zusammenfassen. Die Durchführung des Experiments Hacker Contest hat ergeben, dass konventionelle Sicherheitsmethoden und -werkzeuge Defizite aufweisen, die es für Nichtexperten im Bereich der IT-Sicherheit schwierig machen, Sicherheit umzusetzen. Als Ursache hierfür haben wir beispielsweise Zeitdruck, mangelndes oder falsches Sicherheitsverständnis sowie falsche bzw. unvollständige Annahmen identifiziert. Mit diesem Buch haben wir den neuen Ansatz der Security Patterns, die wir als Ergänzung der bekannten Vorgehensweisen verstehen, vorgestellt. Sie tragen dazu bei, immer wiederkehrende Probleme zu vermeiden, da bewährte Lösungen von Experten in strukturierter Form dokumentiert werden. Auf Basis der Sammlung von ausgewählten Security Patterns im zweiten Teil dieses Buches können wir nun zusammenfassen, welche Vorteile sich durch Security Patterns ergeben. Dabei betrachten wir zunächst einige Vorteile, die sich direkt aus der Form der Darstellung ergeben: – Sicherheitsprobleme und die entsprechenden Lösungen werden durch den Pattern-Ansatz in eine strukturierte Form überführt. Dies trägt zur Übersichtlichkeit und Vergleichbarkeit von Wissen bei. – Teilprobleme von übergeordneten Problemkomplexen sind einzeln und übersichtlich durch die Security Patterns voneinander getrennt beschrieben. Damit wird die Komplexität moderner IT-Umgebungen besser beherrschbar. – Zudem können Teilprobleme – z.B. durch die Ergänzung von neuen Angriffskonzepten und alternativen Maßnahmen – gepflegt werden. – Es ist möglich, einzelne bereits durch Problem und Lösung beschriebene Teilprobleme innerhalb eines anderen Problemkomplexes wiederzuverwenden. Dies wurde durch die Abhängigkeiten eines Security Patterns von anderen deutlich.


9.1. Zusammenfassung 275

Insbesondere beim Schreiben von neuen Security Patterns erweist es sich als sehr hilfreich, wenn auf eine Menge von vorhandenen Bausteinen zurückgegriffen werden kann. – Die internen und externen Abhängigkeiten der einzelnen Security Patterns und die daraus resultierenden Auswirkungen auf das Gesamtsystem sind erkennbar und nachvollziehbar. Damit können u.a. auch die Fern- und Nebenwirkungen einer Maßnahme erkannt und besser beurteilt werden. Anhand von Beispielen haben wir außerdem gezeigt, wie der Mehrwehrt eines Systems von Security Patterns genutzt werden kann. Es kann beispielsweise dazu verwendet werden, um ein reales System hinsichtlich seiner Sicherheitseigenschaften zu modellieren. Der Anwender (also z.B. ein Entwickler oder Administrator) kann erkennen, welche Wechselwirkungen in diesem Kontext auftreten können und welche Maßnahmen ergriffen werden müssen. Außerdem kann auf Basis eines solchen Modells festgestellt werden, welche Auswirkungen Inkonsistenzen auf die unterschiedlichen Komponenten eines Gesamtsystems haben. So wird beispielsweise deutlich, dass ein Fehler in der Implementierung eines kryptografischen Verfahrens zur Kompromittierung der Kommunikationsendpunkte eines vertraulichen Tunnels führen kann. An dieser Stelle möchten wir darauf hinweisen, dass Security Patterns zwar ein neuer Ansatz, aber schon deutlich über das Stadium einer Idee hinausgewachsen sind (im Software Engineering haben sich Design Patterns als bewährte Entwurfsmethode etabliert). Wir gehen aber auch davon aus, dass noch nicht alle Möglichkeiten, die sich aus der Verwendung von Security Patterns ergeben, ausgeschöpft sind. Abschließend bleibt zu sagen, dass dieses Buch trotz des plakativen Titels keine „Hacker Fibel“ oder eine Anleitung zum „Hacken für Dummies“ ist. Dokumente, die Angriffe im Detail beschreiben, veralten sehr schnell, da sich die Angriffstechniken und -werkzeuge schnell weiterentwickeln. Obwohl dies für den Leser zunächst reizvoll erscheinen mag, hat dieses Wissen doch eine eher geringe Halbwertszeit. Gleiches gilt auch für die Beschreibung von detaillierten Lösungen, möglicherweise sogar auf Produktebene. Unser Ansatz war es vielmehr, ausgewählte Ergebnisse des Hacker Contest möglichst zeitinvariant zu beschreiben.

9.2 Die Zukunft des Hacker Contest Der Hacker Contest ist und bleibt ein Experiment, bei dem es im Wesentlichen darum geht, den Teilnehmern das Thema Sicherheit praxisnah zu vermitteln. Nur wer Fehler selbst gemacht und die Ursachen verstanden hat, wird zukünftig in der Lage sein, die richtigen Entscheidungen zu treffen. Bei der Auswahl der Themen können wir uns – wie in diesem Buch – nur auf einen kleinen Teil der IT-Sicherheit konzentrieren. Wir beobachten daher weiterhin aktuelle Entwicklungen, um neue interessante Themen für den Hacker Contest zu identifizieren, die über die Grundlagen, die

276 9 Ausblick

in diesem Buch vorgestellt worden sind, hinausgehen. Kandidaten für weitere Themen sind beispielsweise der Aufbau einer Public-Key-Infrastruktur, Intrusion-Detection-Systeme, Sicherheit typischer Anwendungen (WWW, E-Mail etc.) usw. Aber auch neue Protokolle wie das Wireless LAN, das zahlreiche neue (und alte) Sicherheitsprobleme auf die Tagesordnung eines jeden Anwenders bringt, werden eine wichtige Rolle im Hacker Contest spielen. Das übergeordnete Ziel ist es, nicht nur den Teilnehmern des Hacker Contest das entsprechende Wissen zu vermitteln, sondern auch einen Weg zu finden, dies an Dritte weiterzugeben. Dies bedeutet für uns, dass der Ansatz der Security Patterns konsequent als Form der Dokumentation verwendet werden sollte. Damit wäre gewährleistet, dass nicht jeder Einzelne immer wieder ganz von vorne anfängt. So kostet es beispielsweise immer wieder sehr viel Zeit, Systeme zu installieren und entsprechend abzusichern. Ist bekannt, wie dies grundsätzlich funktioniert, kann in Folgeveranstaltungen auf diesen Erkenntnissen aufgebaut werden. Nach einigen Jahren dürfte sich so ein wertvolles Hilfsmittel für jeden Neuling im Bereich IT-Sicherheit ergeben. Für den Experten dient solch ein Katalog von „Best Practices“ als Referenz- und Nachschlagewerk. Der Hacker Contest kann mittlerweile durchaus als feste Größe im Ausbildungsprogramm der TU Darmstadt bezeichnet werden. Neben großer Anfrage seitens der Studenten erfreut sich die Veranstaltung auch einer hohen externen Visibilität. Erstmals haben wir dieses Thema in dem Artikel „Angewandte Informationssicherheit – ein Hacker-Praktikum an Universitäten“ im Informatik-Spektrum vorgestellt. Kurz darauf wurde das Konzept des Hacker Contest im Fachbereich Mathematik der Humboldt-Universität zu Berlin übernommen. In der Ausgabe 21/2001 des Magazins c’t erschien ein Artikel über das Informatikstudium („Harte Kost, Perspektiven fürs Informatikstudium“, S. 132 ff). Darin wurden bekannte Probleme wie falsche Erwartungen, Abbrecher, Praxisfernheit etc. angesprochen. Der Artikel erwähnt negative und positive Beispiele an deutschen Universitäten: „Ein herausragendes Beispiel ist das Hacker-Praktikum der TU Darmstadt …“ Zum Zeitpunkt der Fertigstellung des Manuskripts wurde zudem in diversen Zeitungen (z.B. Spiegel Online, Rubrik Uniwelt) über die Veranstaltung berichtet. Dies sind für uns Indizien, dass das Konzept des Hacker Contest als hilfreich in der Ausbildung des Nachwuchses erkannt wird. Wir möchten Sie dazu einladen, dieses Konzept zu übernehmen und weiter auszubauen.

9.3 Die Zukunft von Security Patterns Dies ist das erste Buch, in dem der Pattern-Ansatz auf den Bereich Sicherheit angewendet worden ist. Obwohl das Konzept der Security Patterns recht neu ist, erscheint es als vielversprechende Alternative, um im Gegensatz zu anderen Büchern rund um die Hacker-Thematik Fertigkeiten und Wissen von Experten in strukturierter Form weitergeben zu können. Grundsätzlich fehlen aber zwei Dinge, um dem Konzept zum Durchbruch zu verhelfen.

9.3. Die Zukunft von Security Patterns 277

Zunächst ist die Basis der Security Patterns noch zu klein, um damit sinnvoll arbeiten und ausbilden zu können. Während der europäischen Pattern-Konferenz EuroPLoP im Jahr 2002 wurde allerdings der Workshop „Thinking about Security Patterns“ veranstaltet, bei dem sich die führenden Autoren von Security Patterns erstmals getroffen haben, um zukünftig gemeinsam an diesem Ansatz weiterzuarbeiten. Es kann also davon ausgegangen werden, dass über dieses Buch und den Hacker Contest hinaus in den nächsten Jahren eine ganze Reihe von Security Patterns veröffentlicht werden, die in einem großen Security Pattern-System integriert werden müssen. Frei nach Christopher Alexander gemäß dem Motto „Build your own Patterns“ fordern wir den Leser dazu auf, seine Erfahrungen ebenfalls in Form von Patterns zu formulieren. Bei Interesse finden sich weitere Informationen unter folgendem URL: http://www.security-patterns.de

Ein umfangreicher Katalog von Security Patterns führt dann zu dem zweiten Problem: Ab einer gewissen Anzahl von Security Patterns ist es nicht mehr möglich, die richtige Lösung für das entsprechende Problem zu finden, insbesondere wenn die Dokumente im WWW verteilt sind. Es ist daher notwendig, eine Suchmaschine zu verwenden, die die semantischen Eigenschaften von Security Patterns ausnutzt, damit Suchanfragen auch zu den richtigen Ergebnissen führen. Mithilfe solcher Werkzeuge können dann auch Analysen, wie wir sie im vorangegangenen Kapitel vorgestellt haben, unterstützt werden. Es kann also z.B. grafisch angezeigt werden, wie sich Fehler in einem Modell ausbreiten oder welche Auswirkungen eine Inkonsistenz in einem Security Pattern auf andere haben. Eine Unterstützung durch Werkzeuge ermöglicht darüber hinaus noch weitergehende Analysen: – Analyse des Security-Pattern-Systems Dies sind einerseits „statische“ Analysen, die auf der Anzahl der Abhängigkeiten eines Security Patterns aufbauen. Wird beispielsweise ein Security Pattern besonders häufig von anderen Security Patterns vorausgesetzt, so kann daraus z.B. die Schlussfolgerung gezogen werden, dass es sich hier um ein Security Pattern handelt, das qualitativ einen besonders hohen Schutz bietet. Eine andere Schlussfolgerung könnte sein, dass bei der Implementierung dieses Security Patterns besonders stark darauf geachtet werden muss, dass keine Fehler gemacht werden. Dies hätte sonst fatale Folgen. Die Interpretation solcher Zusammenhänge kann nicht ohne weiteres automatisiert werden. Sie verbleibt letzten Endes beim Menschen, der allerdings dabei unterstützt wird, solche „kritischen“ Fälle zu erkennen. – Analyse von Nutzungsprofilen Andererseits können Schlüsse aus dem Umgang mit solch einem Werkzeug gezogen werden. Solche „dynamischen“ Analysen des Verhaltens der Benutzer kann z.B. Hinweise darauf geben, welche Probleme besonders oft gelöst werden. Um-

278 9 Ausblick

gekehrt kann angenommen werden, dass zentrale Security Patterns, die sehr selten verwendet werden, offenbar nicht als wichtig erkannt oder schlicht und ergreifend nicht gefunden werden können. Solche Fälle können von einem Werkzeug ebenfalls identifiziert werden, und es bleibt wieder dem Menschen überlassen, entsprechend zu reagieren (beispielsweise kann dies ein Indikator dafür sein, dass die Abhängigkeiten im Security-Pattern-System nicht richtig oder unvollständig sind). Erste Initiativen, solche Hilfsmittel zu entwerfen und zu implementieren, sind – auch außerhalb des speziellen Themas Sicherheit – bereits in Angriff genommen worden.

„There’s no other way to handle the complexity than by breaking it up into manageable pieces.“ – Bruce Schneier

9.3. Die Zukunft von Security Patterns 279

Danksagung

A

Abb. 1-0 Tabelle 1-0 Dank gebührt allen, die zur Entstehung dieses Buches beigetragen haben. Dies sind in erster Linie die Teilnehmer des Hacker Contest, die gewissermaßen als „Versuchskaninchen“ zur Verfügung gestanden haben. Reinhard Bertram möchten wir für die großartige Idee des Hacker Contest danken. Den Sponsoren des Hacker Contest möchten wir unseren Dank aussprechen. Ohne sie wäre all dies nicht möglich gewesen. Hervorheben möchten wir insbesondere das Fraunhofer Institut SIT (Sichere Telekooperation) unter der Leitung von Prof. Dr. Claudia Eckert und Prof. Dr. Heinz Thielmann, das uns durch zahlreiche großzügige Sachspenden unterstützt hat. Weiterhin möchten wir uns bei unseren Betreuern und Mentoren Prof. Alejandro Buchmann (PhD), Prof. Dr. Peter Kammerer, Prof. Dr. Ralf Steinmetz bedanken, die uns die Durchführung der Veranstaltung ermöglicht und uns dabei immer unterstützt haben. Besonderer Dank gilt auch unseren Kollegen, die den Hacker Contest ab dem Jahr 2000 mitbetreut haben. Wir bedanken uns bei Herrn Engesser, Frau Georgiadis, Frau Glaunsinger und Frau Fischer vom Springer-Verlag für die exzellente Betreuung und Unterstützung bei der Realisierung dieses Projekts. Besonderer Dank gilt auch allen Korrekturleserinnen und -lesern, die uns geholfen haben, Fehler und unverständliche Formulierungen aufzudecken und zu verbessern. Dies gilt insbesondere auch für die Kommentierung noch nicht ausgereifter Vorversionen des Manuskripts. Schließlich bedanken wir uns bei unseren Freundinnen, Feunden und Familien, die uns während der Entstehung dieses Buches Kraft und Selbstvertrauen gaben. Danke! Zum Schluss möchten wir dem Leser die Gelegenheit bieten, uns Rückmeldungen zu diesem Buch geben zu können. Schreiben Sie uns eine Nachricht, und sagen Sie uns, was Ihnen gefallen hat und was wir besser machen können. Sie können uns unter folgender E-Mail-Adresse erreichen: [email protected]

Danksagung 281

Literaturverzeichnis

[1]

Auswärtiges Amt, http://www.auswaertiges-amt.de, 2002

[2]

Christopher Alexander, The Timeless Way of Building, Oxford University Press, 1979

[3]

Christopher Alexander, Sara Ishikawa, Murray Silverstein with Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel, A Pattern Language — Towns, Buildings, Construction, Oxford University Press, 1977

[4]

David Allen, Check.pl, http://opop.nols.com/proggie.html, 2002

[5]

Edward Amoroso, Fundamentals of Computer Security Technologies, Prentice Hall, 1994

[6]

Ross Anderson, Security Engineering, A Guide to Building Dependable Distibuted Systems, John Wiley & Sons, 2001

[7]

Anonymous, Hacker’s Guide, Sicherheit im Internet und im lokalen Netz, Markt & Technik, 1999

[8]

R. Appleton, Linux Benchmark Group, Northern Michigan University, 2001

[9]

Tod Atkins, The Simple WATCHdog, 2001 ftp://ftp.cert.dfn.de/pub/tools/audit/swatch/

[10]

BayObLG JR 1994, S. 292

[11]

D. Bell, L. LaPadula, Secure Computer Systems: Mathematical Foundations, Technical Report, The MITRE Corporation, 1973

[12]

Michael Behrens, Richard Roth, Biometrische Identifikation. Grundlagen, Verfahren, Perspektiven, Vieweg Verlag, 2002

[13]

BKA online, Bundeskriminalamt Wiesbaden, http://www.bka.de, 2002

[14]

K. Bremer, Strafbare Internet-Inhalte in internationaler Hinsicht, Dissertation, Rechtswissenschaft, Uni Trier, 2000

[15]

F. Lee Brown, J. DiVietri, G. Diaz de Villegas, E. B. Fernandez, The Authenticator Pattern, Pattern Languages of Programs (PLoP), 1999

Literaturverzeichnis 283

[16]

F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad und Michael Stal, Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996

[17]

D. Borchers, Wo die Liebe hinfällt, Die Zeit, Nr. 20, 2000

[18]

Jan Borchers, A Pattern Approach to Interaction Design, John Wiley & Sons, 2001

[19]

A. M. Braga, C. M. F. Rubira, R. Dahab, Tropyc: A Pattern Language for Cryptografic Software, Pattern Languages of Programs (PLoP), 1998

[20]

British Standards Institute, Information Security Management, British Standard 7799, ISO/IEC 17799, 1998

[21]

BSA (Business Software Alliance) Deutschland, http://www.bsa.de, 2002

[22]

BSA (Business Software Alliance) Global Homepage, http://www.bsa.com, 2002

[23]

BSA, Erhebungsmethodik: So werden die Pirateriezahlen errechnet, http://www.bsa.de/softwarepiraterie/Erh-meth.pdf

[24]

Bundesamt für Sicherheit in der Informationstechnik, IT-Grundschutzhandbuch, http://www.bsi.bund.de/gshb/, 2002

[25]

CERT/CC, Advisory CA-1999-04, Melissa Macro Virus, Carnegie Mellon University, 1999

[26]

CERT/CC, Advisory CA-2000-06, Multiple Buffer Overflows in Kerberos Authenticated Services, Carnegie Mellon University, 2000

[27]

CERT/CC, Advisory CA-2002-17, Apache Web Server Chunk Handling Vulnerability, Carnegie Mellon University, 2002

[28]

W. R. Cheswick und S. M. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Addison-Wesley, Reading, Massachusetts, 1994

[29]

Roger Clarke, Introduction to Information Security, Xamax Consultancy Pty Ltd, 2001

[30]

Common Criteria, Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik, ISO/IEC 15408, Version 2.0, 1998

[31]

Jim Coplien, Focus Group on Organizational Pattern Sequences, 6th European Conference on Pattern Languages of Programs, 2001

[32]

Computer Security Institute (CSI), Computer Security Issues & Trends, 2000

284 Literaturverzeichnis

[33]

Computer Security Institute (CSI), Computer Security Issues & Trends, 2001

[34]

A. Curic. Computer Hacker Pioniere — Die Wegbegleiter unserer digitalen Welt, Lingen, 1995

[35]

N. Damianou, N. Dulay, E. Lupu, M. Sloman, The Ponder Policy Specification Language, POLICY 2001, LNCS, Springer-Verlag, 2001

[36]

M.-O. Dammann, Computerkriminalität aus Sicht von Ermittlungsbehörden, http://www.cert.dfn.de/dfn/berichte/db087/lka52.html

[37]

Datenschutzberater 1995, Heft 10, S. 23

[38]

Datenschutzgruppe. Stellungnahme 4/2001 zum Entwurf einer Konvention des Europarates über Cyberkriminalität, 22. März 2001

[39]

U.S. Department of Defense (DoD), Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, 1985

[40]

DFN-CERT, Logsurfer Homepage, http://www.cert.dfn.de/eng/logsurfer/, 2000

[41]

Dietrich Dörner, Die Logik des Mißlingens — Strategisches Denken in komplexen Situationen, Rowohlt, 1989

[42]

Draft Convention on Cyber-Crime: http://conventions.coe.int/Treaty/EN/cadreprojects.htm,

29. Juni 2001 [43]

Economist Intelligence Unit Limited und Arthur Andersen, Ten Myths about Information Technology Security — Managing Business Risks in the Information Age, 1998

[44]

Europäische Kommission. Schaffung einer sicheren Informationsgesellschaft durch Verbesserung der Sicherheit von Informationsinfrastrukturen und Bekämpfung der Computerkriminalität, Juli 2001

[45]

eEurope 2002. Eine Informationsgesellschaft für alle Aktionspläne, 2002

[46]

K.-F. Fecht, W. Opfermann, W. Scheiterle, Computerspionage — Risiken und Prävention, Bundesministerium für Wirtschaft, Referat Öffentlichkeitsarbeit, BMWi-Dokumentation, Juli 1998

[47]

E. B. Fernandez, Metadata and Authorization Patterns, Technical Report, Florida Atlantic University, 2000

[48]

Eduardo B. Fernandez, Rouyi Pan, A Pattern Language for Security Models, Pattern Languages of Programs (PLOP), 2001


[49]

S. Fischer, C. Rensing, U. Roedig, Open Internet Security — Von den Grundlagen zu den Anwendungen. Springer-Verlag, Heidelberg, 2000

[50]

R. Flanders, E. B. Fernandez, Data Filter Architecture Pattern, Pattern Languages of Programs (PLOP), 1999

[51]

T. Forester, P. Morrison, Computer Ethics — Cautionary Tales and Ethical Dilemmas in Computing, MIT Press, 2. Auflage, 1994

[52]

Fyodor, Nmap Stealth Port Scanner, http://www.insecure.org/nmap/

[53]

G8 Information Center, http://www.g7.utoronto.ca, Juli 2001

[54]

M. Gaulke. Digitale Abgründe — Was die Computerbranche ihren Kunden verschweigt, Verlag Moderne Industrie, 1996

[55]

W. Guder, Computersabotage (§ 303b StGB) — Technische Lebenswirklichkeit und ihre juristische Würdigung, Dissertation, Fachbereich Rechtswissenschaft der Universität Bremen, 2000

[56]

K. Hafner, J. Markoff, Cyberpunk: Outlaws and Hackers on the Computer Frontier, Touchstone Books, Juli 1992

[57]

F. Haft. Das Zweite Gesetz zur Bekämpfung der Wirtschaftskriminalität (2. WiKG). Teil 2: Computerdelikte, NStZ, 1987

[58]

Neil Harrison, The Language of Shepherding, A Pattern Language for Shepherds and Sheep, Pattern Languages of Programs (PLoP), 1999

[59]

Mark Heuser, Eduardo B. Fernandez, RPC Client: A Pattern for the Clientside Implementation of a Pipelined Request/Response Protocol, Pattern Languages of Programs, 1999

[60]

Hoehren, Sieber, Handbuch zum Multimediarecht, C.H. Beck-Verlag, München, 2000

[61]

ISO/IEC, Software Engineering — Product Quality, ISO/IEC 9126, 2001

[62]

St. Jäger, Computerkriminalität, Interest-Verlag, 2. Auflage, 1998

[63]

Jargon-File, http://www.tuxedo.org/~esr/jargon, 2002

[64]

M. E. Kabay, Understanding Studies and Surveys of Computer Crime, 2002

[65]

Kommission der Europäischen Gemeinschaft. Mitteilung der Kommission an den Rat, das Europäische Parlament, den Wirtschafts- und Sozialausschuss und den Ausschuss der Regionen, eEuropa2002, 2000

[66]

Eric Knight, Computer Vulnerabilities, 2001 http://www.securityparadigm.com


[67]

Ernst&Young LLP. Annual Information Security Survey, 2001

[68]

S. Landau, Standing the Test of Time: The Data Encryption Standard, Notices of the American Mathematical Society (AMS), 2000

[69]

Doug Lea, Pattern Checklist, Hillside, 2002 http://hillside.net/patterns/Writing/Check.html

[70]

Sami Lehtonen, Juha Pärssinen, A Pattern Language for Key Management, 8th Conference on Pattern Languages of Programs (PLoP), 2001

[71]

M. Libicki, The Mesh and the Net — Speculations on Armed Conflict in an Age of Free Silicon, Institute for National Strategic Studies, National Defense University, 1994

[72]

J. Littman, The Fugitive Game, Little Brown, 1996

[73]

J. Littman, Watchman — Schatten ohne Gesicht, Wilhelm Goldmann Verlag, München, 1998

[74]

McConnell International, http://www.mcconnellinternational.com, 2002

[75]

G. McGraw, J. Viega, Keep it simple, keep it private, IBM developerWorks, Security Library, 2000

[76]

G. Meszaros, Jim Doble, A Pattern Language for Pattern Writing, Pattern Languages of Programs (PLoP), 1996

[77]

Meyers großes Taschenlexikon, Band 20, Bibliografisches Institut & F.A. Brockhaus AG, Mannheim, 1987

[78]

K. Möller,. Sicherheitsvorfälle im Internet — Beobachtungen des DFN-CERT, http://www.bka.de/aktuell/agenda98/vtr99/vtr_moeller.html

[79]

K. Möller, S. Kelm, Distributed Denial of Service-Angriffe, Informationsbulletin DIB-2000:01, DFN-CERT, 2000

[80]

K. Mühle, Hacker und Computer-Viren im Internet — eine strafrechtliche Beurteilung, Dissertation, Juristische Fakultät der Universität Passau, Mai 1998

[81]

W. Müller. Aktuelle Probleme des § 263a StGB, Europäische Hochschulschriften, Reihe 2, Rechtswissenschaft, Band 2680, Peter Lang, 1999

[82]

F. Das Neves, A. Garrido, Bodyguard, Pattern Languages of Programs III, Hrsg. R. Martin, D. Riehle, F. Buschmann, Addison-Wesley, 1998

[83]

NIST, Secure Hash Standard (SHS), Federal Information Processing Standard 180-1, 1995


[84]

Veronika Nolde, Lothar Leger, Biometrische Verfahren, Deutscher Wirtschaftsdienst, 2002

[85]

OECD, Guidelines for the Security of Information Systems, ISBN 9-26414569-9, 1996

[86]

Gerhard Ott, Sicherheit — was ist das? Überlegungen zur Semantik eines Begriffs, 2001

[87]

F. Patalong, Hacker sind gefährlicher als das Militär, Netzwelt, Spiegel Online, 2001

[88]

Razvan Peteanu, Best Practices for Secure Development, 2001 http://members.home.net/razvan.peteanu/

[89]

M. Rogers, Psychological Theories of Crime and „Hacking“, Department of Psychology, University of Manitoba, 1999

[90]

Charles P. Pfleeger, Security in Computing, 2. Ausgabe, Prentice Hall, 1997

[91]

J. Rader, A Look at Measures of Computer Security from an Insurance Premium Perspective, Technical report, Raytheon Electronic Systems, 2001

[92]

R. Rivest, The MD5 Message-Digest Algorithm, RFC 1321, 1992

[93]

Sasha Romanosky, Security Design Patterns, Morgan Stanley Online, 2001

[94]

F. Rötzer, Hackergruppen gegen Kriegserklärung von LoU, Telepolis, Verlag Heinz Heise, 1999

[95]

R. Russell, Hack Proofing Your Network, Syngress Media, Inc., 2000.

[96]

J. Saltzer, M. Schroeder, The Protection of Information in Computer Systems, University of Virginia, Department of Computer Science, 1975

[97]

J. Scambray, S. McClure, G. Kurtz. Hacking Exposed: Network Security Secrets & Solutions, Osborne/McGraw-Hill, Berkeley, USA, 2001

[98]

S. Sipes, Why your switched network isn’t secure, 2000 http://www.visi0n.net/security/docs/id_san-switch.htm

[99]

Bruce Schneier, Applied Cryptography, 2nd Edition, Addison-Wesley, 1996

[100]

Bruce Schneier, Cryptogram Newsletter, Counterpane, 2001 http://www.counterpane.com

[101]

Bruce Schneier, Secrets & Lies: Digital Security in a networked World, John Wiley & Sons, 2000


[102]

B. Schneier und D. Mudge, Cryptanalysis of Microsoft’s Point-to-Point Tunneling Protocol (PPTP), in Proceedings of the Fifth ACM Conference on Communications and Computer Security, S. 132–141, Mar 1998

[103]

I. Schulze-Heiming, Der strafrechtliche Schutz der Computerdaten gegen die Angriffsformen der Spionage, Sabotage und des Zeitdiebstahls, Dissertation, Münster, Waxmann-Verlag, 1995

[104]

R. Shirey (Herausgeber), Request for Comments (RFC) 2828, Internet Security Glossary, 2000

[105]

Markus Schumacher, Security Patterns Homepage, 2002 http://www.security-patterns.de/

[106]

Markus Schumacher, Security Patterns and Security Standards, Proceedings of the 7th European Conference on Pattern Languages of Programs (EuroPLoP), Irrsee, Deutschland, 2002

[107]

M. Schumacher, Ch. Haul, M. Hurler, A. Buchmann. Data-Mining in Vulnerability Databases. Workshop Sicherheit in vernetzten Systemen, DFNBericht 90, 2000

[108]

M. Schumacher, M.-L. Moschgath, U. Roedig, Angewandte Informationssicherheit: Ein Hacker-Praktikum an Universitäten. Informatik-Spektrum, Springer-Verlag, Juni 2000

[109]

Markus Schumacher und Utz Roedig, Security Engineering with Patterns, Proceedings of the 8th Conference on Pattern Languages of Programs (PLoP), Monticello, Illinois, USA, 2001

[110]

T. Shimomura. Data Zone — Die Hackerjagd im Internet, Deutscher Taschenbuch Verlag, 2. Auflage, 1996

[111]

T. Shimomura, J. Markoff, Takedown: The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw — By the Man Who Did It. Hyperion, 1996

[112]

U. Sieber. Comcrime Study, http://www.jura.uni-muenchen.de/sieber, 1998

[113]

U. Sieber. Missbrauch der Informationstechnik und Informationsstrafrecht — Entwicklungstendenzen in der internationalen Informations- und Risikogesellschaft, 1996

[114]

U. Sieber. Internationales Strafrecht im Internet – Das Territorialitätsprinzip der §§ 3, 9 StGB im globalen Cyberspace, NJW 29/1999, S. 2065–2073

[115]

E. J. Sinrod, W. P. Reilly, Cyber-Crimes: A Practical Approach to the Application of Federal Computer Crime Laws, Santa Clara University, Mai 2000


[116]

Jan Stefan, Markus Schumacher, Collaborative Attack Modeling, 17th ACM Symposium on Applied Computing (SAC 2002), Special Track on Computer Security, 2002

[117]

M. Slatalla, J. Quittner, Masters of Deception, Wilhelm Heyne Verlag, 1997

[118]

SNORT, The Open Source Network Intrusion Detection System, 2002 http://www.snort.org

[119]

M. Sondermann, Computerkriminalität — Die neuen Tatbestände der Datenveränderung gem. § 303a StGB und der Computersabotage gem. § 3003b StGB, Dissertation, Rechtswissenschaftliche Fakultät der Westfälischen Wilhelms-Universität zu Münster, 1989

[120]

J. Soyka, Computer-Kriminalität — Fälle und Fakten. Ein aktueller Report, Wilhelm Heyne Verlag, München, 1986

[121]

Andreas Steinhauser, Biometrie-Workshop, 16. Chaos Communication Congress, 1999

[122]

C. Stoll, Kuckucksei, Fischer Taschenbuch Verlag, 1996

[123]

G. Stone, G. Xie, Network Policy Languages: A Survey and a New Approach, IEEE Network, Volume 15, Nr. 1, 2001

[124]

Symantec, Geschichte der Computerviren, http://www.symantec.com/region/de/avcenter/regeln_de.html

[125]

A. S. Tanenbaum, Computernetzwerke, 3. revidierte Auflage, Prentice Hall, 1996

[126]

A. S. Tanenbaum, Modern Operating Systems, Prentice Hall, New Jersey, 2. Auflage, 2001

[127]

P. A. Taylor, Hackers — Crime in the Digital Sublime, Routledge, 1999

[128]

Tech Model Railroad Club, MIT, http://tmrc-www.mit.edu/

[129]

H. E. Theis, Computerrecht, Luchterhand, 1997

[130]

Tripwire Inc., Home of the Tripwire Open Source Project, 2002 http://www.tripwire.org

[131]

News vom 26.09.2000: TÜV: Mangelnde IT-Sicherheit verursacht Milliardenschäden

[132]

G. Versteegen, Projektmanagement mit dem Rational Unified Process, Xpert.Press, Springer-Verlag, 2000

[133]

M. Voelter, J. Eckstein, Relationships between Patterns in a Pattern Language, Workshop Growing a Pattern Language, OT Conference, 2001


[134]

A. Westfeld, G. Wicke, G. Wolf, J. Zöllner, SSONET – Sicherheit und Schutz in offenen Datennetzen, TU Dresden, 1999

[135]

Klaus Wolf, Bodo Runzheimer, Risikomanagement und KonTraG. Konzeption und Implementierung, Dr. Th. Gabler Verlag, 2001

[136]

J. Yoder und J. Barcalow, Architectural Patterns for Enabling Application Security, Pattern Languages of Programs (PLoP), 1997

[137]

G. Zahn, Die Betrugsähnlichkeit des Computerbetrugs (§ 263a StGB), Dissertation, Shaker-Verlag, 2000

[138]

M. W. Zender, Gefahr aus dem Cyberspace? — Das Internet zwischen Freiheit und Zensur, Birkhäuser-Verlag, 1998

[139]

Ch. Zimmermann, Der Hacker, Heyne, 1998

[140]

E. D. Zwicky, S. Cooper, D. B. Chapman, Building Internet Firewalls, 2nd Edition, O’Reilly, 2000


Stichwortverzeichnis

A Abfangen Informationen 167 Abhören Nachrichtenkanal 167 Absicherung der schwächsten Stellen 180 AIDS-Disketten-Fall 84 Anforderung Benutzbarkeit 13 Effizienz 13 Funktionalität 13 Portabilität 14 Wartbarkeit 14 Wechselwirkungen 15 Zuverlässigkeit 13 Angreifer 11 extern 12 Innentäter 12 Angriff 12 Abhören der Übertragung von Passwörtern 203 Abtastung 98 aktiv 12 Ausspähen 189 Ausspähen vor Ort 202 Durchführung 100 Erkennen 221 Erkundung 97 Fälschung 189

a

Hintertür 211 Man-in-the-Middle 189 Manipulation 189 Manipulation der Hardware/Software 203 Manipulierte Konfigurationsdatei 211 Maskierung 189 passiv 12 physikalisch 29 Rootkit 211 semantisch 30 Social Engineering 202 syntaktisch 29 Trojaner 210 Versteckte Dateien und Verzeichnisse 211 Verwischen der Spuren 100 Wörterbuch 35 Angriffsmodell Angriffsbäume 45 Bedrohungsbäume 45 Fault Tree Analysis 45 Anti-Hacker-Gesetz 137 ARP-Cache Poisoning 232 Audit 173 Auswertung 175 Auswirkungen 174 Beeinflussung 187 Informationen 175 Logging 175

Stichwortverzeichnis 293

Authentisierung 164, 196 Benutzer 196 biometrisch 165 Geheimnis 165 Passwörter 196 physikalischer Token 165 Prinzipien 165

B Backdoor 211 Basisfunktionen 177 Bedrohung 11 Ausspähen von Informationen 194 Diebstahl von Daten oder Geräten 194 Installation und Modifikation der Hardware 194 Täuschung 108 unbefugte Offenlegung 106 Unterbrechung 109 widerrechtliche Aneignung 110 Zerstörung von Gerät oder Daten 195 Benutzer Identifikation 165 Identität 197 Verifikation 165 Bill Gates 78 Bootstrapping 188, 215 BTX-Hack 81

Computersabotage 135 Computerspionage 135 Cybernet 79

D Dan Farmer 86 Data Encyrption Standard (DES) 168 Daten Begriff 138 Herkunft 239 Modifikationen 169 technische Umformung 139 Diebstahl Speichermedien 167 Distributed Denial of Service 26

E Einfachheit 179 Ethernet 229

F False Positive 184 Fehler Auswirkung 187 Firewall 241 Fred Cohen 80 Full Disclosure 105

C

G

Christopher Alexander 49 Computer Emergency Response Team 101 Computer Fraud and Abuse Act 83 Computer Oracle Password and Security System 86 Computerbetrug 135 Computer-Hacking 135 Computermanipulation 134

Geheimhaltungsinteresse 138 Geheimnis 197 Geldspielautomaten Manipulation 141 GRE Datenkanal 267 Grundschutzhandbuch 9

294 Stichwortverzeichnis

H

M

Hacken subversiver Akt 24 Hacker Contest 27 Hash-Funktion 170 MD5 170 Passwort 202 SHA 170 Herstatt-Fall 78 Hintertür 100, 211

MAC-Adresse 230 Man-in-the-Middle 100 Manipulation 210 Maßnahme 17 offline 190 Out of Band 190 proaktiv 18 reaktiv 18 Melissa 91 Minimale Privilegien 187 Minimales System 217 Missbrauch 174 Modification Detection Code (MDC) 169 Motive Anerkennung 95 finanziell 97 Langeweile 96 Machtgefühl 96 Neugierde 95 politisch und ideologisch 96 Rache 97 Robin-Hood-Syndrom 96 Sucht/Besessenheit 95 technische 96

I Identifikation 164 Idiome 67 Implementierungsfehler 185 Integrität Schutz 169 verbindungslose 239 Intrusion Detection System (IDS) 221

K Kevin Mitnick 87 Kevin Poulsen 89 KGB-Hack 84 Komplexität 179 Konfigurationsfehler 185 Konservative Vorgehensweise 177 Konzeptuelle Patterns 66

N NASA-Hack 81, 91 NAT 250 Network Address Translation 250

L LAN 229 Local Area Network 229 Logging 222 Login Challenge 272 Love Letter 25

P Paketfilter 244 Passierstelle 182 Referenzmonitor 182 Passwort Akronym-Methode 200 benutzergeneriert 197 Brute-Force Angriffe 199


Collage-Methode 200 Datei 204 erraten 199 Qualität 198 Schutz 201 Standardpasswörter 218 systemgeneriert 197 Umgang 203 Verwaltung 201 Wörterbuchangriff 199 Patterns Design 67 Pattern-Sequenzen 262 Paul Allen 78 Physikalische Token 166 Proxy 248

R Random Challenge 272 Ressource 8 Risiko 19 Robert Morris 82 Rootkit 211

S Schadenspotenzial 185 Schutz physikalisch 193 Schutzziel 10 Integrität 10 Verfügbarkeit 10 Vertraulichkeit 10 Security Engineering 40 Security Pattern Änderungen 59 Beziehungen 56 Konsistenz 59 Spezialisierung 56 Struktur 51 Systeme von 54 Voraussetzung 58

296 Stichwortverzeichnis

Security Policy 42 Sicherheit 8 Komplexität 36 Standardverhalten 184 Zeitabhängigkeit 37 Sicherheitskette 180 Sicherheitskopien 212 SNMP 233 Softwarediebstahl 136 Standard Common Criteria 44 Orange Book 44 Stateful-Filter 246 Steve Jobs 79 Steve Wozniak 79 Switch 230 System Administrator Tool for Analyzing Networks 87 System Security Engineering 40

T Täuschung 174 Tripwire 211 Trojaner 210 Tron 87 Tunnel 239

U Update 219

V Verletzlichkeit 15 Fehlerhafte Richtlinien 16 logische Fehler 16 Schwachstelle 15, 16 Sicherheitslücke 15 Social Engineering 16 Verschlüsselung 166, 209 Algorithmus 167 asymmetrische 168

Daten 209 Schlüsselverwaltung 169 symmetrische 168 Verfahren 167 Verteidigung mehrschichtig 181 Vertraulichkeit 239 Verzeichnisse versteckte 100 Vielfalt 185 Virtuelles privates Netz 235 Virus Melissa 24 VPN 235

Z Zeitdiebstahl 136 Zugriffskontrolle 171, 239 Attribute 172 Dateien 206 Identifikation und Authentisierung 173 identitätsbasiert 171 Umgehung 187

W Wau Holland 81 Wide Area Network 235 Wirtschaftskriminalität 137 Wörterbuch-Attacke 272


Abkürzungen

b

ACL

Access Control List

ARP

Address Resolution Protocol

BSI

Bundesamt für Sicherheit in der Informationstechnik

CART

Computer Analysis and Response Team

CC

Common Criteria

CCC

Chaos Computer Club

CCC

Computer Center Corporation

CERT

Computer Emergency Response Team

CHAP

Challenge Handshake Authentication Protocol

CIAC

Computer Incident Advisory Capability

CIAO

Critical Infrastructure Assurance Office

CICG

Critical Infrastructure Coordination Group

CITAC

Computer Investigations and Infrastructure Threat Assessment Center

COPS

Computer Oracle Password and Security System

DDoS

Distributed Denial of Service

DES

Data Encryption Standard

DFN

Deutsches Forschungsnetz

DoS

Denial of Service

DNS

Domain Name System

ERM

Entity Relationship Model

FAQ

Frequently Asked Questions

FedCIRC

Federal Computer Incident Response Capability

FIRST

Forum of Incident Response and Security Teams

FTA

Fault Tree Analysis

FTP

File Transfer Protocol

Abkürzungen 299

HTML

Hypertext Markup Language

HTTP

Hypertext Transfer Protocol

IDS

Intrusion Detection System

IP

Internet Protocol

IPsec

IP Security

IPTF

Infrastructure Protection Task Force

IRC

Internet Relay Chat

ISO

International Organization for Standardization

IT

Informationstechnik

LAN

Local Area Network

LCP

Link Control Protocol

MAC

Medium Access Control

MDC

Modification Detection Code

NCCS

National Computer Crime Squad

NCSC

National Computer Security Center

NIPC

National Infrastructure Protection Center

NFS

Network File System

NIPCIP

National Infrastructure Protection and Computer Intrusion Program

NIS

Network Information Services

NIST

National Institute of Standards and Technology

NSA

National Security Agency

OCL

Object Constraint Language

OCIIP

Office of Computer Investigations and Infrastructure Protection

OECD

Organization for Economic Cooperation and Development

OSI

Open Systems Interconnection

PC

Personal Computer

PCIS

Partnership for Critical Infrastructure Security

PGP

Pretty Good Privacy

PKI

Public Key Infrastructure

PPP

Point-to-Point Protocol

300 Abkürzungen

PPTP

Point-to-Point Tunneling Protocol

RSA

Rivest, Shamir, Adleman

RFC

Request for Comments

SATAN

System Administrator Tool for Analyzing Networks

SHA

Secure Hash Algorithm

SNMP

Simple Network Management Protocol

SSH

Secure Shell

SSL

Secure Socket Layer

TCP

Transport Control Protocol

TCSEC

Trusted Computer System Evaluation Criteria

TFN

Tribe Flood Network

TK

Telekommunikation

TLS

Transport Layer Security

UDP

User Datagram Protocol

UML

Unified Modeling Language

URL

Uniform Resource Locator

VPN

Virtuelles Privates Netz

WAN

Wide Area Network

WWW

World Wide Web

Abkürzungen 301

Hacker Contest: Sicherheitsprobleme, Lösungen, Beispiele (Xpert.press)

Contest

Contest

Contest

Hacker

Hacker

Holzbau - Beispiele

The Great Contest

Speech Contest Rulebook

The Contest

Hacker Culture

Dear Hacker

The Contest

Hacker Bibel

Hacker Cracker

Dear Hacker

Holzbau. Grundlagen - Bemessungshilfen - Beispiele

Art of Programming Contest

The P.I. Contest

The P.I. Contest

The Hacker Crackdown

Hacker disassembling uncovered

Herbers Excel-Beispiele

The Candy Corn Contest

The contest problem

Der Fremdsprachen-Hacker

A Hacker Manifesto

El Libro Hacker

Hacker Web Exploition Uncovered

The Hacker Ethic

Hacker Linux Uncovered

Hacker Contest: Sicherheitsprobleme, Lösungen, Beispiele (Xpert.press)

Contest

Contest

Contest

Hacker

Hacker

Holzbau - Beispiele

The Great Contest

Speech Contest Rulebook

The Contest

Hacker Culture

Dear Hacker

The Contest

Hacker Bibel

Hacker Cracker

Dear Hacker

Holzbau. Grundlagen - Bemessungshilfen - Beispiele

Art of Programming Contest

The P.I. Contest

The P.I. Contest

The Hacker Crackdown

Hacker disassembling uncovered

Herbers Excel-Beispiele

The Candy Corn Contest

The contest problem

Der Fremdsprachen-Hacker

A Hacker Manifesto

El Libro Hacker

Hacker Web Exploition Uncovered

The Hacker Ethic

Hacker Linux Uncovered

Recommend Documents