IT-Sicherheit in vertikalen F&E-Kooperationen der Automobilindustrie 9783835095526, 3835095528 [PDF]

Zitiervorschau

Marcus Heitmann IT-Sicherheit in vertikalen F&E-Kooperationen der Automobilindustrie

DuD-Fachbeiträge Herausgegeben von Andreas Pfitzmann, Helmut Reimer, Karl Rihaczek und Alexander Roßnagel

Die Buchreihe ergänzt die Zeitschrift DuD – Datenschutz und Datensicherheit in einem aktuellen und zukunftsträchtigen Gebiet, das für Wirtschaft, öffentliche Verwaltung und Hochschulen gleichermaßen wichtig ist. Die Thematik verbindet Informatik, Rechts-, Kommunikations- und Wirtschaftswissenschaften. Den Lesern werden nicht nur fachlich ausgewiesene Beiträge der eigenen Disziplin geboten, sondern sie erhalten auch immer wieder Gelegenheit, Blicke über den fachlichen Zaun zu werfen. So steht die Buchreihe im Dienst eines interdisziplinären Dialogs, der die Kompetenz hinsichtlich eines sicheren und verantwortungsvollen Umgangs mit der Informationstechnik fördern möge. Die Reihe wurde 1996 im Vieweg Verlag begründet und wird seit 2003 im Deutschen Universitäts-Verlag fortgeführt. Die im Vieweg Verlag erschienenen Titel finden Sie unter www.vieweg-it.de.

Marcus Heitmann

IT-Sicherheit in vertikalen F&E-Kooperationen der Automobilindustrie Mit Geleitworten von Prof. Dr. Roland Gabriel und Prof. Dr. Hans-Ottmar Beckmann Prof. Dr. Joachim Fischer und Prof. Dr. Rolf Eschenbach

Deutscher Universitäts-Verlag

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Dissertation Universität Bochum, 2007

. .. Auflage Dezember 1997 1. Auflage Juli 2007 Alle Rechte vorbehalten © Deutscher Universitäts-Verlag | GWV Fachverlage GmbH, Wiesbaden 2007 Lektorat: Frauke Schindler / Britta Göhrisch-Radmacher Der Deutsche Universitäts-Verlag ist ein Unternehmen von Springer Science+Business Media. www.duv.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. 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: Regine Zimmer, Dipl.-Designerin, Frankfurt/Main Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8350-0721-5

Geleitwort Die moderne Automobilindustrie ist ohne den Austausch von elektronischen Informationen u ¨ber Informations- und Kommunikationstechnologien kaum mehr denkbar. Die vorliegende Arbeit besch¨aftigt sich mit einer zentralen Thematik aus diesem Umfeld: Dem sicheren Austausch von elektronischen Informationen zwischen und in Unternehmungen im Allgemeinen und in vertikalen F&E-Kooperationen im Speziellen. Herr Heitmann hat den Anstoß f¨ ur die wissenschaftliche Aufarbeitung dieser Problematik selbst gegeben und diese fundiert und umfangreich erforscht und aus verschiedenen Perspektiven beleuchtet. In der Auseinandersetzung mit den vielf¨altigen Einflussfaktoren auf die IT-Sicherheit in und zwischen Unternehmungen hinsichtlich technischer, organisatorischer, juristischer und monet¨arer Belange spiegelt sich die Erfahrung des Autors in diesem Themenkomplex wider und erh¨alt dadurch eine starke Relevanz f¨ ur die Praxis. Das vielfach postulierte Ende der Perimeter Security (also des Schutzes der Unternehmungsgrenzen) wird in der Arbeit in Frage gestellt. Herr Heitmann zeigt auf, dass in unternehmungs¨ ubergreifenden Kooperationen die Perimeter Security weiterhin einen zentralen Aspekt in der Absicherung von elektronischen Informationen bildet. Demnach ist der Schutz der eigenen Unternehmung die zwingende Voraussetzung f¨ ur eine sichere elektronische Kooperation mit Dritten. Die hier vorgestellten Ans¨atze und Methoden stellen eine wertvolle Grundlage f¨ ur die Weiterentwicklung der IT-Sicherheit in unternehmungsu ¨bergreifenden Kooperationen dar.

Bochum, im M¨arz 2007 Prof. Dr. Roland Gabriel

Geleitwort Die beiden wohl wesentlichsten Ver¨anderungen, hervorgerufen durch den eHype, sind die unz¨ahligen Online-Shops auf der Seite der Konsumenten sowie eine sehr enge Anbindung an Entwicklungs- und Logistiksysteme auf der Seite der Lieferanten. Mit dieser engen Verzahnung und der zur Verf¨ ugungstellung eines breiten Angebotes an Leistungen, Produkten und Informationen geht ein Aufweichen der alten IT Sicherheitsstrategien wie zum Beispiel der Abgrenzung durch Firewalls einher. Zur Zeit findet bei großen Herstellern eine st¨andige Abw¨agung zweier wesentlicher Gesch¨aftsinteressen statt: Integration von Zulieferern und des Vertriebskanals gegen¨ uber der Gew¨ahrleistung der Sicherheit. Hierzu bedarf es zun¨achst einer sorgf¨altigen Analyse und Bewertung des Risikos, hervorgerufen durch die IT-Unterst¨ utzung der Erweiterung der Prozessketten u ¨ber die Unternehmensgrenzen hinaus. Insbesondere die Kosten-Nutzen-Betrachtung von IT-Sicherheit steckt hier noch ganz am Anfang einer gesicherten Methodik. Herr Marcus Heitmann hat in seiner Arbeit u ¨ber IT-Sicherheit in vertikalen F&E” Kooperationen der Automobilindustrie“ aufbauend auf Theorien und Standards aus dem Bereich IT-Sicherheit eine sehr saubere Analyse des IT-Risikos und Maßnahmen zu dessen Minimierung abgeleitet. Insbesondere das von ihm mit entwickelte Konzept eines Access und Identity Management Frameworks ist Basis f¨ ur eine Implementierung eines solchen Systems zur Verwaltung von u ber 800.000 IT Benutzern. ¨ Ich danke Herrn Heitmann f¨ ur unz¨ahlige Diskussionen u ¨ ber Sicherheitsaspekte zur Vermeidung von Risiken in der IT. Seine Kreativit¨at ist in viele Projekte eingegangen und hat so manchen Vortrag bereichert.

Wolfsburg, im Februar 2007 Prof. Dr. Hans-Ottmar Beckmann, Volkswagen AG

Vorwort Die vorliegende Arbeit ist zwischen Juni 2004 und Juli 2006 im Rahmen meiner T¨atigkeit bei der Volkswagen AG entstanden. W¨ahrend meiner Zeit bei der Volkswagen AG hatte ich die Gelegenheit an vielen ¨außerst interessanten Projekten zu arbeiten und Ideen in die Praxis umzusetzen. Dazu geh¨orte unter anderem die Mitarbeit im Projekt Security and Reduction of Risk (S2R) der ODETTE sowie die Mitarbeit an Standards in der Herstellerinitiative Software (HIS) gemeinsam mit anderen Automobilherstellern und -zulieferern. Ich m¨ochte mich bei folgenden Personen/Institutionen bedanken, da sie mich bei der Erstellung der Dissertation und allen begleitenden Notwendigkeiten unterst¨ utzt haben: Herrn Prof. Dr. Roland Gabriel und Frau Prof. Dr. Brigitte Werners danke ich f¨ ur die ¨ Betreuung meiner Dissertation bzw. die Ubernahme der Zweitkorrektur. Insbesondere m¨ochte ich mich daf¨ ur bedanken, dass ich die Gelegenheit erhalten habe, als Fachfremder extern bei Herrn Prof. Dr. Gabriel promovieren zu d¨ urfen. Innerhalb der Volkswagen AG m¨ochte ich mich bei Herrn Prof. Dr. Ottmar Beckmann, dem Chief Information Security Officer, daf¨ ur bedanken, dass er mich in sein Team aufgenommen und mich unterst¨ utzt hat. Mein weiterer Dank geht an meinen Betreuer Rolf Hafner und meine Kollegen Andr´e Oberschachtsiek, Rolf Dobrig und Detlef G¨ unther, die mich stets mit ihrem Know-how und der Bereitschaft zur Diskussion unterst¨ utzt haben. Des Weiteren m¨ochte ich mich bei Stefan Ostrowski, dem Chief Technology Officer, bedanken, der mich stets f¨orderte. Ein ganz besonderer und inniger Dank geb¨ uhrt Klaus Polo“ Polochowitz, der mich immer wieder daran erinnert hat, dass meine Dissertation ” und nicht das Tages- und Projektgesch¨aft im Fokus meiner Aufmerksamkeit stehen sollte. Im Laufe der Zusammenarbeit ist aus einem kollegialen Miteinander eine Freundschaft zwischen uns entstanden. Das Doktorandenkolleg der Volkswagen AG hat mit tollen Veranstaltungen und Weiterbildungsangeboten dazu beigetragen, dass ich mich in Wolfsburg und bei Volkswagen wohlgef¨ uhlt habe. Hier sind vor allem Sebastian H¨aring, Claudia Haig, Philipp Rode, Gerrit Schmidt, Ulrike Siemer und Christiane Staffhorst zu nennen.

X

Vorwort

Dr. Christian Gayer, Dr. Bernd Janson, Dr. Lars Schmidt und insbesondere Dr. Arnd Busche und Dr. Michael Welling danke ich f¨ ur Re-Runden, fachliche und vor allem nichtfachliche Diskussionen sowie die Unterst¨ utzung in allen pr¨ ufungstechnischen Fragen und das regelm¨aßige PBT. Matthias Brandt hat mit Fachverstand die letzten Rechtschreibfehler eliminiert, wof¨ ur ich ihm sehr dankbar bin. Des Weiteren m¨ochte ich mich bei allen Kollegen aus Projekten und Fachabteilungen (insbesondere ISSO und CERT) bedanken. Das fachliche und zwischenmenschliche Miteinander, ob innerhalb des Volkswagen-Konzerns oder hersteller¨ ubergreifend in HIS, VDA oder ODETTE, hat mir stets Freude bereitet. Die Mitarbeiter am Lehrstuhl f¨ ur Wirtschaftsinformatik von Herrn Prof. Dr. Gabriel und am Institut f¨ ur Sicherheit im E-Business (ISEB) standen mir immer mit Rat und Tat beiseite – insbesondere Klaus R¨ udiger hatte stets ein offenes Ohr. Klaas Kuhlmann, Ortwin M¨ uhr und Tim Vogt danke ich einfach nur daf¨ ur, dass es sie gibt. Ulrike Schneider hat mich mit ihrer Liebe und ihrem scharfen juristischen Verstand unterst¨ utzt. Meinen Eltern, Christina und Klaus Heitmann, geb¨ uhrt indes der gr¨oßte Dank, da sie mich stets liebevoll unterst¨ utzt und gef¨ordert haben. Ihnen widme ich dieses Buch.

Wolfsburg, im Januar 2007. Marcus Heitmann

Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abk¨ urzungsverzeichnis

XV XVII XIX

1 Einf¨ uhrung 1.1 Problemstellung, forschungsleitende Fragen und Zielsetzung . . . . . . . . . 1.2 Methodik und Aufbau (Forschungskonzeption und Forschungsprozess) . . .

1 3 5

2 IT-Sicherheit in Unternehmungen 2.1 IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Einf¨ uhrung und Begriffsdefinition . . . . . . . . . . . . . . . . . . . 2.1.2 Schutzziele der IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Klassifizierung und Gef¨ahrdung von Werten . . . . . . . . . . . . . 2.2 Risikomanagement in der IT-Sicherheit . . . . . . . . . . . . . . . . . . . . 2.2.1 Verfahren zur Risikoidentifikation und -analyse . . . . . . . . . . . . 2.2.2 Methodische Probleme in der Identifikation und Analyse von Risiken 2.2.3 Kosten und Nutzen der IT-Sicherheit . . . . . . . . . . . . . . . . . 2.2.3.1 Ausgew¨ahlte Methoden f¨ ur eine Kosten-Nutzen-Analyse der IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . 2.2.3.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Risikomanagement und Reduktion von Risiken . . . . . . . . . . . . 2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit . . . . . . . . . . . . . . 2.3.1 Bundesdatenschutzgesetz (BDSG) . . . . . . . . . . . . . . . . . . . 2.3.2 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Zivil- und Strafrecht . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Service-Level-Agreement (SLA) . . . . . . . . . . . . . . . . . . . . 2.3.5 Weitere ausgew¨ahlte rechtliche Regelungen zur IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 10 11 12 13 16 19 24 27 32 36 40 45 46 48 49 51 55

XII

2.4

2.5

2.6

Inhaltsverzeichnis

Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.1

Technische IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . 59

2.4.2

Organisatorische IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . 74

2.4.3

Ganzheitliche IT-Sicherheit als Prozess . . . . . . . . . . . . . . . . 81

IT-Anwender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.5.1

Theoretische Ans¨atze . . . . . . . . . . . . . . . . . . . . . . . . . . 83

2.5.2

Einflussfaktoren zur Sensibilisierung der IT-Anwender . . . . . . . . 84

Standardwerke zur IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . 88 2.6.1

British Standard 7799-2 . . . . . . . . . . . . . . . . . . . . . . . . 90

2.6.2

ISO/IEC 17799:2005 . . . . . . . . . . . . . . . . . . . . . . . . . . 92

2.6.3

2.6.2.1

Risikoanalyse nach ISO/IEC TR 13335-3 . . . . . . . . . . 93

2.6.2.2

Hauptgruppen nach ISO 17799 . . . . . . . . . . . . . . . 96

BSI IT-Grundschutzhandbuch . . . . . . . . . . . . . . . . . . . . . 100 2.6.3.1

Schutzbedarfsfeststellung nach IT-Grundschutzhandbuch . 102

2.6.3.2

Weitere Vorgehensweise im Grundschutzhandbuch . . . . . 106

2.6.4

Erg¨anzende Normen, Regelwerke und Standards . . . . . . . . . . . 109

2.6.5

Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

3 Struktur und Organisation der Automobilindustrie 3.1

3.2

3.3

3.1.1

Plattform- und Gleichteilestrategie . . . . . . . . . . . . . . . . . . 113

3.1.2

Integration von IT in Wertsch¨opfungsprozesse . . . . . . . . . . . . 115

3.1.3

Verringerung der Fertigungstiefe . . . . . . . . . . . . . . . . . . . . 116

Automobilhersteller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 3.2.1

Einf¨ uhrung und Abgrenzung . . . . . . . . . . . . . . . . . . . . . . 118

3.2.2

Beschaffungsprozesse der Automobilhersteller . . . . . . . . . . . . 121

3.2.3

Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Zulieferunternehmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.3.1

Typologie der Zulieferunternehmungen . . . . . . . . . . . . . . . . 129

3.3.2

Definition der Zulieferunternehmungen gem¨aß der Typologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

3.3.3 3.4

113

Die gegenw¨artige Automobilindustrie . . . . . . . . . . . . . . . . . . . . . 113

3.3.2.1

Teilelieferanten . . . . . . . . . . . . . . . . . . . . . . . . 131

3.3.2.2

Komponentenlieferanten . . . . . . . . . . . . . . . . . . . 132

3.3.2.3

Kernlieferanten . . . . . . . . . . . . . . . . . . . . . . . . 133

Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Ausblick auf zuk¨ unftige Entwicklungen in der Automobilindustrie . . . . . 138

Inhaltsverzeichnis

XIII

4 Vertikale F&E-Kooperationen in der Automobilindustrie 4.1 Einf¨ uhrung und Begriffsdefinition . . . . . . . . . . . . . . . . . . . . . . 4.2 Make-or-Buy und F&E-Outsourcing . . . . . . . . . . . . . . . . . . . . . 4.3 Konventionelle vertikale F&E-Kooperationen . . . . . . . . . . . . . . . . 4.4 Kooperative virtuelle F&E . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Qualit¨atsmanagement – Bewertung von Zulieferern in Kooperationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Grundlagen, Aufgaben und Ziele der Zuliefererbewertung im Qualit¨atsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 IT-Sicherheit als weitere Dimension im Qualit¨atsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Definition und Typologisierung der F&E-Kooperationen in der Automobilindustrie unter Sicherheitsaspekten . . . . . . . . . . . . . . . 4.6.1 Kooperationsumfeld . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Produkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Unternehmungszugeh¨origkeit oder -beteiligung . . . . . . . . . . . 4.6.4 Gr¨oße der Unternehmung . . . . . . . . . . . . . . . . . . . . . . 4.6.5 Finanzielle Situation der Unternehmung . . . . . . . . . . . . . . 4.6.6 Geografische/politische Lage . . . . . . . . . . . . . . . . . . . . . 4.6.7 Grad des Vertrauens . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.8 Wert der Information . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.9 Konnektivit¨at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.10 Standort der Applikation oder des Systems . . . . . . . . . . . . . 4.6.11 Protokolle und Kommunikation . . . . . . . . . . . . . . . . . . . 4.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Gestaltungsans¨ atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen 5.1 IT-Risikomanagement in vertikalen Kooperationen . . . . . . . 5.2 Zertifizierung von Zulieferunternehmungen . . . . . . . . . . . 5.2.1 Optionen der Zertifizierung in F&E-Kooperationen . . 5.2.2 Typologie der Zertifizierungstiefe . . . . . . . . . . . . 5.2.3 Auditierung einer Unternehmung . . . . . . . . . . . . 5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie 5.3.1 Anforderungs-/Spezifikationsphase . . . . . . . . . . . 5.3.2 Anbahnungsphase . . . . . . . . . . . . . . . . . . . . . 5.3.3 Kooperationsphase . . . . . . . . . . . . . . . . . . . . 5.3.4 Abschlussphase . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

143 . 144 . 150 . 151 . 152 . 155 . 156 . 158 . . . . . . . . . . . . .

159 160 160 161 161 163 163 164 165 166 166 167 167

. . . . . . . . . .

171 171 176 177 178 179 183 184 184 185 192

XIV

5.4 5.5

5.6

Inhaltsverzeichnis

5.3.5 Abschließende Bewertung . . . . . . . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes 5.5.1 Bestehende Ans¨atze . . . . . . . . . . . . . . . . . . . . . . 5.5.1.1 PDTnet und OMG PLM Services . . . . . . . . . 5.5.1.2 European Bridge Certification Authority . . . . . 5.5.2 F¨oderales Identit¨atsmanagement . . . . . . . . . . . . . . . 5.5.3 Weitere Gestaltungsans¨atze . . . . . . . . . . . . . . . . . 5.5.3.1 Geschlossene Benutzergruppen . . . . . . . . . . 5.5.3.2 Automotive DRM . . . . . . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

193 194 195 196 197 199 201 212 212 215 216

6 Schlussbetrachtung und Ausblick

221

Literaturverzeichnis

225

Abbildungsverzeichnis 1.1

Internationale Auto-Patente 2003 . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15

Dimensionen der IT-Sicherheit . . . . . . . . . . . . . . . . . . ¨ Uberblick u ¨ber potenzielle Gef¨ahrdungen . . . . . . . . . . . . Ordinale Risikobewertung . . . . . . . . . . . . . . . . . . . . Kosten-Nutzen-Verh¨altnis von IT-Sicherheitsmaßnahmen . . . Dreidimensionale Risikokategorisierung . . . . . . . . . . . . . Beispiel des Risikomanagements anhand einer Alltagssituation Sicherheitselemente im Lebenszyklus von IT-Prozessen . . . . Prozesse im Business Continuity Management . . . . . . . . . Klassifikationsschema f¨ ur Sicherheitsmodelle . . . . . . . . . . IT-Sicherheitskriterienwerke im Vergleich . . . . . . . . . . . . Managementsystem f¨ ur Informationssicherheit, ISMS . . . . . Risikomanagement mit detaillierter Risikoanalyse . . . . . . . Management der IT-Sicherheit . . . . . . . . . . . . . . . . . . Schematischer Ablauf nach GSHB . . . . . . . . . . . . . . . . Prozess der Schutzbedarfsfeststellung nach GSHB . . . . . . .

. . . . . . . . . . . . . . .

3.1 3.2

Konsolidierung bei Automobilherstellern . . . . . . . . . . . . Abh¨angigkeit des Gesch¨aftserfolgs von den Beschaffungsmarktcharakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . Traditionelle Beschaffung und Modular Sourcing . . . . . . . . Lieferantenstruktur eines OEM . . . . . . . . . . . . . . . . . Zusammenhang zwischen Produktkomplexit¨at, Wertsch¨opfung, Eigenanteil an F&E und Position in der Zulieferkette . . . . .

. . . . . . . 119

3.3 3.4 3.5

4.1 4.2 4.3 4.4

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

4 12 15 22 30 41 42 44 45 70 89 91 95 97 101 106

. . . . . . . 123 . . . . . . . 125 . . . . . . . 130 . . . . . . . 135

Anforderungen an Kooperationen aus Sicht der Hersteller und Zulieferer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funktionalit¨at von Telekooperationssystemen . . . . . . . . . . . Strategische Erfolgsfaktoren zur Generierung von Wettbewerbsvorteilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zuordnung der Sicherheitsaspekte . . . . . . . . . . . . . . . . .

. . . . . . 150 . . . . . . 154 . . . . . . 156 . . . . . . 168

XVI

5.1 5.2 5.3

Abbildungsverzeichnis

Dokumentation der IT-Sicherheitsrichtlinien auf drei Ebenen . . . . Abl¨aufe in der Gestaltung von IT-Sicherheit in Unternehmungen . . M¨ogliche Darstellung eines Self Assessments mit Grad der Zielerreichung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Automatische Reduktion von Informationen in CAD-Dokumenten . 5.5 Funktionsprinzip von Digital Rights Management Systemen . . . . 5.6 Exemplarische Darstellung eines Identity and Access Managements die gesamte interne IT-Infrastruktur einer Unternehmung . . . . . . 5.7 FIM zwischen zwei Unternehmungen . . . . . . . . . . . . . . . . . 5.8 Zusammenhang zwischen Sicherheit, Vertrauen und Aufwand . . . . 5.9 FIM f¨ ur Web-Applikationen . . . . . . . . . . . . . . . . . . . . . . 5.10 FIM f¨ ur Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11 Kommunikationsbeziehungen u ¨ ber exklusive Datenleitungen . . . . 5.12 Kommunikationsbeziehungen u ¨ ber exklusive Datenleitungen und Router/Gateway (vereinfachte Darstellung) . . . . . . . . . . . . . .

. . . . 172 . . . . 175 . . . . . . . . . u ¨ber . . . . . . . . . . . . . . . . . .

. 181 . 186 . 188 . . . . . .

204 207 208 210 210 212

. . . . 213

Tabellenverzeichnis 2.1 Klassifikation von Informationen . . . . . . . . . . . . . . . . . . . . . . . 2.2 Beispiel f¨ ur eine ROSI-Kalkulation . . . . . . . . . . . . . . . . . . . . . 2.3 Anwendungsbereiche verschiedener Methoden im IT-Risikomanagement . 2.4 Klassifikation der Verf¨ ugbarkeit . . . . . . . . . . . . . . . . . . . . . . . 2.5 Nutzung von Outsourcing-Dienstleistungen im Jahr 2004 . . . . . . . . . 2.6 Authentifikationsklassen in Kombination mit einer Datenklassifizierung . 2.7 Beispiel f¨ ur eine Zugriffskontrollmatrix . . . . . . . . . . . . . . . . . . . 2.8 Beispiel f¨ ur eine Kombination aus Datenklassifikation und kryptografischen Algorithmen/Schl¨ ussell¨angen . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 Kommunikationsinstrumente der Individual- und Massenkommunikation 2.10 Schutzbedarfskategorien gem¨aß GSHB . . . . . . . . . . . . . . . . . . . 2.11 Beispiele f¨ ur Schutzbedarfskategorien in Bezug auf Schadenstypen . . . . 2.12 Beispiel f¨ ur die Schutzbedarfsfeststellung einer IT-Anwendung . . . . . . 2.13 Beispiel f¨ ur einen Realisierungsplan nach GSHB . . . . . . . . . . . . . . 4.1 4.2 4.3

. . . . . . .

14 35 43 53 54 64 72

. . . . . .

75 86 103 103 104 108

Merkmale der Kooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Definition der Unternehmungsgr¨oße . . . . . . . . . . . . . . . . . . . . . . 161 Definition der Unternehmungsgr¨oße nach Anzahl der Computer . . . . . . 162

Abku ¨ rzungsverzeichnis ACL AES AktG ALE AP B2B BGB BGBl. BGH BMZ Bridge-CA BS BSI BSI BTO BVerfG CA CAD CAM CAS CAx CERT CIO CISO CMMI CobiT CPS CPU CRL CSP DAC DES

Access Control List Advanced Encryption Standard Aktiengesetz Annual Loss Expectancy Asia/Pacific Business to Business B¨ urgerliches Gesetzbuch Bundesgesetzblatt Bundesgerichtshof Brandmeldezentrale European Bridge Certification Authority British Standard Bundesamt f¨ ur Sicherheit in der Informationstechnik British Standard Institute Build-to-order Bundesverfassungsgericht Certification Authority Computer Aided Design Computer Aided Manufacturing Computer Aided Styling Computer Aided“ Technologien ” Computer Emergency Response Team Chief Information Officer Chief Information Security Officer Capability Maturity Model Integration Control Objectives for Information and Related Technology Certificate Practice Statement Central Processing Unit Certificate Revocation List Certified Service Provider Discretionary Access Control Data Encryption Standard

XX

¨ DFU DIN DMU DMZ DRM DSL EAL EB-CA EBIT EDI EDIFACT EDM EG EMEA EMZ EN ENX ESP F&E FAR FIM FMEA FRR FTE FTP GmbHG GoBS GSHB GVO HGB HTTP IAM ICE IEC IP IP IPSec ISACA ISDN

Abk¨ urzungsverzeichnis

Datenfern¨ ubertragung Deutsches Institut f¨ ur Normung e.V. Digital Mock-Up Demilitarisierte Zone Digital Rights Management Digital Subscriber Line Evaluation Assurance Level European Bridge Certification Authority Earnings before Interest and Tax Electronic Data Interchange Electronic Data Interchange for Administration, Transport and Commerce Engineering Data Management Europ¨aische Gemeinschaft Europe, Middle East and Africa Einbruchmeldezentrale Europ¨aische Norm European Network Exchange Elektronisches Stabilit¨atsprogramm Forschung und Entwicklung False Acceptance Rate F¨oderales Identit¨atsmanagement Failure Modes and Effects Analysis False Rejection Rate Failure to Enrol Rate File Transfer Protocol Gesetz betreffend die Gesellschaften mit beschr¨ankter Haftung Grunds¨atze ordnungsm¨aßiger DV-gest¨ utzter Buchf¨ uhrungssysteme Grundschutzhandbuch Gruppenfreistellungsverordnung Handelsgesetzbuch HyperText Transfer Protocol Identity and Access Management Intercity Express International Electrotechnical Commission Internet Protocol Intellectual Property Internet Protocol Security Information Systems Audit and Control Association Integrated Service Digital Network

Abk¨ urzungsverzeichnis

ISMS ISO IT ITIL IuK iViP JIS JIT KBA KMU KonTraG LAN LDSG MAC MAC MAC MARION MSSP NAT NEA NIST NJW OASIS OCSP OCTAVE ODETTE OEM OFTP OMG OSI OSSTMM PDA PDM PDTnet PEP PIN PKI

XXI

Information Security Management System International Standard Organisation Informationstechnik IT Infrastructure Library Information und Kommunikation Initiative zur integrierten virtuellen Produktentstehung Just-in-Sequence Just-in-Time Kraftfahrzeugbundesamt Kleine und mittlere Unternehmen Gesetz zur Kontrolle und Transparenz im Unternehmensbereich Local Area Network Landesdatenschutzgesetz Mandatory Access Control Message Authentication Code Media Access Control M´ethode d’Analyse de Risques Informatiques et d’Optimisation par Niveau Managed Security Service Provider Network Address Translation Netzersatzanlage National Institute of Standards and Technology Neue Juristische Wochenschrift Organization for the Advancement of Structured Information Standards Online Certificate Status Protocol Operationally Critical Threat, Asset and Vulnerability Evaluation Framework Organisation for Data Exchange by Teletransmission in Europe Original Equipment Manufacturer ODETTE File Transfer Protocol Object Management Group Open Systems Interconnection Reference Model Open Source Security Testing Methodology Manual Personal Digital Assistant Produktdatenmanagement Product Data Technology in a Network Produktentwicklungsprozess Personal Identification Number Public-Key-Infrastruktur

XXII

PLM ProSTEP RBAC RCO ROI ROSI SAML SCM SE SEC SLA SOP SOX SPICE SSL SSO StGB SUV TCO TCP TGV TP TR TRIPS URL USP USV UWG VAM VDA VdS VPN WAN WLAN WTO XML ZSB

Abk¨ urzungsverzeichnis

Product Lifecycle Management Pro Standard for the Exchange of Product Model Data Role Based Access Control Real Cost of Ownership Return on Investment Return on Security Investment Security Assertion Markup Language Supply Chain Management Simultaneous Engineering U.S. Securities and Exchange Commission Service Level Agreement Start of Production Sarbanes-Oxley Act Software Process Improvement Capability dEtermination Secure Socket Layer Single Sign On Strafgesetzbuch Sport Utility Vehicle Total Cost of Ownership Transmission Control Protocol Train a` Grand Vitesse Trading Partner Technical Report Trade Related Aspects of Intellectual Property Rights Uniform Resource Locator Unique Selling Proposition Unterbrechungsfreie Stromversorgung Gesetz gegen den unlauteren Wettbewerb Vulnerability Assessment and Mitigation Verband der Automobilindustrie e.V. Verband der Schadenversicherer Virtual Private Network Wide Area Network Wireless Local Area Network World Trade Organization Extensible Markup Language Zusammenbauten

1 Einfu ¨ hrung Die Automobilindustrie ist f¨ ur den Wirtschaftsstandort Deutschland von großer Bedeutung, da sie in Umsatz und Besch¨aftigung der gr¨oßte Industriezweig Deutschlands ist. Jeder siebte Arbeitsplatz ist direkt oder indirekt von der Automobilindustrie abh¨angig. Das Umsatzvolumen betrug 2003 208,6 Mrd. Euro oder fast 10% des Bruttoinlandsprodukts.1 Der Bereich Forschung und Entwicklung in der Automobilindustrie umfasste 2003 ein Volumen von 14,5 Mrd. Euro – dies sind u ¨ ber 30% Prozent der gesamten Forschungsund Entwicklungsaufwendungen der deutschen Wirtschaft.2 Die Forschungs- und Entwicklungst¨atigkeiten (F&E) der Automobilhersteller werden von diesen im Allgemeinen nicht exhaustiv eigenst¨andig betrieben. Es besteht die Tendenz seitens der Automobilhersteller Know-how zu großen Teilen von Dritten zu beziehen. Der Bezug von Leistungen aus der Forschungs- und Entwicklungst¨atigkeit von Dritten geht einher mit der Reduzierung der Fertigungstiefe. F&E in der Automobilindustrie erfordert in zunehmendem Maße kooperative virtuelle Prozesse, welche die Aufwendungen und die Zeit von der Produktidee bis zum fertigen Produkt (Time-to-Market) erheblich reduzieren k¨onnen.3 Dieser Zustand wird mit dem Begriff Extended Enterprise umschrieben und beschreibt die st¨arkere Zusammenarbeit mit Zulieferern und die Diffusion von Aufgaben u ¨ber die Unternehmungsgrenzen hinaus.4 W¨ahrend fr¨ uher Prozesse viel h¨aufiger strikt innerhalb der Unternehmungsgrenzen realisiert wurden, ist heute Integration und Kollaboration mit Externen notwendig. Die Ausgestaltung von Kooperationen in der Automobilindustrie unterliegt einem steten Wandel. Die Einf¨ uhrung von CAx-Technologien5 und Simultaneous Engineering hat die Automobilentwicklung dergestalt maßgeblich beeinflusst, dass sich der Entwicklungsprozess eines Automobils in den vergangenen Jahren von 60 auf unter 30 Monate verk¨ urzt 1 Vgl. Verband der Automobilindustrie e.V. (VDA) 2004: 5 und 202. 2 Vgl. VDA 2004: 5; Radtke/Abele/Zielke 2004: 15. 3 Time-to-Market beschreibt den Zeitraum von der Produktidee bis zur Markteinf¨ uhrung. 4 Vgl. Bloch/Pigneur 1995; Bort 2003; Davis/Spekman 2004. 5 CAx ist ein Sammelbegriff f¨ ur alle Computer Aided“, also computergest¨ utzten, Technologien, wie z.B. ” Computer Aided Design (CAD), Computer Aided Styling (CAS) oder Computer Aided Manufacturing (CAM). In der Produktentwicklung der Automobilindustrie existiert eine CAD-Durchdringung von ca. 90%, vgl. Product Data Technology in a Network 2003b: 2.

2

1 Einf¨ uhrung

hat.6 Dies ist allerdings nicht ausschließlich neuen Technologien zu verdanken: Neue Organisations-, Produktions- und Managementmethoden, wie z.B. Lean Production, haben an den Produktivit¨atsgewinnen ebenfalls einen Anteil, w¨aren allerdings partiell ohne eine informationstechnische Unterst¨ utzung weniger effektiv. Die technischen Ver¨anderungen werden daher teilweise als dritte Revolution in der Automobilindustrie umschrieben, da viele Prozessabl¨aufe ohne den Einsatz moderner Informations- und Kommunikationstechnologien (IuK) unm¨oglich oder ineffizient w¨aren.7 Basis vieler dieser Prozesse ist der Austausch von immateriellen G¨ utern (Informationen i.w.S.), welcher zunehmend in digitaler Form u ¨ber elektronische Netzwerke, z.B. Intranet oder Internet, stattfindet. Da ein offenes Netzwerk wie das Internet prinzipiell allen Akteuren zur Verf¨ ugung steht, gewinnt die Sicherheit der u ¨bermittelten Informationen ¨ immer mehr an Bedeutung. W¨ahrend der Ubertragung der Daten muss in erster Linie die Integrit¨at und Vertraulichkeit der Informationen gew¨ahrleistet werden, damit Dritte die Daten weder unbefugt ver¨andern noch einsehen k¨onnen. Der notwendige Grad an Sicherheit bemisst sich im Wesentlichen aus dem Wert der u ¨bermittelten Information. Besonders sensitive Daten, wie z.B. strategische Planung, kalkulatorische Daten, personenbezogene Informationen oder Ergebnisse aus Forschung und Entwicklung, k¨onnen inh¨arente monet¨are Werte besitzen, deren Preisgabe den Verlust komparativer Wettbewerbsvorteile bedeuten kann und die aus diesem Grund besonders sch¨ utzenswert sind. IT-Sicherheit wird, trotz der vielen Sicherheitvorf¨alle in den letzten Jahren, teilweise von Unternehmun¨ gen als notwendiges Ubel“ bezeichnet, da sie nicht prim¨ar Teil der Wertsch¨opfungskette ” ist und keine Erl¨ose generiert. Sie ist jedoch als Schutz f¨ ur get¨atigte Investitionen, z.B. Wissen u ber Produkte und Prozesse, anzusehen. Das Akronym IP steht nicht nur f¨ ur In¨ ternet Protocol, sondern auch f¨ ur Intellectual Property (geistiges Eigentum) und skizziert damit das Dilemma der Internettechnologien: der einfache, schnelle und kosteng¨ unstige Transfer von Informationen u ugbare Netzwerke mit dem Risiko, dass ¨ber ¨offentlich verf¨ die Informationen von Unbefugten abgeh¨ort, manipuliert oder gel¨oscht werden.

6 Vgl. Atzberger/Kassner/Malorny et al. 2001: 5. 7 Vgl. Feige/Neumann 2001: 32; Picot/Reichwald 1994. Die erste Revolution“ in der Automobilin” dustrie war dabei weniger die Entwicklung und Einf¨ uhrung des Fließbandes sondern die vollst¨andi” ge und passgenaue Austauschbarkeit der Bauteile und die Einfachheit des Zusammenbaus“ (Womack/Jones/Roos 1994: 31). Die zweite Revolution in der Autoindustrie“ wurde ein Begriff durch ” das gleichnamige Buch von James Womack, Daniel Jones und Daniel Roos (Womack/Jones/Roos 1994). Sie erforschten im International Motor Vehicle Program am Massachusetts Institute of Technology die Produktionsbedingungen der Automobilhersteller an u ¨ ber 90 Standorten weltweit. Eines der Erkenntnisse der Studie war, dass die westlichen Hersteller sich im wesentlichen weiterhin an der fordistischen Massenproduktion orientierten, w¨ ahrend japanische Unternehmen ein neuartiges Konzept, welches von den Autoren Lean Production“ getauft wurde, verwendeten. ”

1.1 Problemstellung, forschungsleitende Fragen und Zielsetzung

3

1.1 Problemstellung, forschungsleitende Fragen und Zielsetzung Das Forschungsgebiet IT-Sicherheit in Unternehmungen“ bzw. IT-Sicherheit in Koope” ” rationen“ ist ein sehr junges Forschungsfeld. W¨ahrend die Verschl¨ usselung von sensiblen staatlichen und damit in erster Linie milit¨arischen Informationen bereits im R¨omischen Reich (Caesar-Chiffre) gebr¨aulich war, fand die Verwendung in der Privatwirtschaft, vornehmlich bei Banken, erst in den 1970er Jahren statt. Seit Anfang der 1990er Jahre h¨alt die IT-Sicherheit in gr¨oßerem Umfang Einzug in private Unternehmungen und die ¨offentliche Verwaltung und wird seit Ende der 1990er nahezu fl¨achendeckend in Großunternehmungen und Landes- und Bundesministerien implementiert. Erste Konzepte zur organisatorischen und technischen Absicherung von Informationen und informationstechnischen Systemen existieren seit ca. 1990, wobei die Quasi-Standards8 erst Mitte bis Ende der 1990er Jahre entstanden sind. IT-Sicherheit wurde lange Zeit sehr technikzentriert betrachtet, w¨ahrend Managementund Organisationsaspekte stark vernachl¨assigt wurden. Ebenso wurde IT-Sicherheit fr¨ uher als reiner Kostenfaktor angesehen. Heute ist IT-Sicherheit in einigen Bereichen eine gesetzliche Verpflichtung (siehe Abschnitt 2.3) und wird zum Teil als komparativer Wettbewerbsvorteil gesehen. Erst die Synthese von organisatorischen, technischen und individuellen Maßnahmen kann eine Unternehmung und ihre Gesch¨aftsbeziehungen vor ITSicherheitsgef¨ahrdungen umfassend sch¨ utzen. Die Herausforderung besteht nicht nur in der Etablierung von IT-Sicherheit in einer Unternehmung, sondern auch in der kontinuierlichen Weiterentwicklung und Auditierung, da Informationstechnologie-Management vor allem ein Management des Wandels ist.9 Das Hauptaugenmerk dieser Arbeit liegt auf dem Schutz von Informationen in IT-gest¨ utzten vertikalen Kooperationen in Forschung und Entwicklung zwischen Automobilhersteller und Zulieferunternehmung. Forschung und Entwicklung sind in der deutschen Automobilindustrie von besonderem Interesse. Nimmt man die Anzahl der internationalen Patentanmeldungen im Bereich Automobiltechnik als Bewertungsmaßstab, dann spielt die deutsche Automobilindustrie eine weltweit f¨ uhrende Rolle in der F&E dieses Sektors (siehe Abb. 1.1).

8 Als solche sind z.B. der British Standard 7799 (BS 7799 respektive ISO 17799), das ITGrundschutzhandbuch des Bundesamtes f¨ ur Sicherheit in der Informationstechnik (BSI) oder die Control Objectives for Information and Related Technology (CobiT) der Information Systems Audit and Control Association (ISACA) anzusehen. 9 Vgl. Paulus 2000: 384.

4

1 Einf¨ uhrung

3.333

Deutschland 1.840

Japan

1.680

USA 737

Frankreich

1.692

Übrige Länder 0

500

1.000 1.500 2.000 2.500 3.000 3.500 4.000

Abbildung 1.1: Internationale Auto-Patente 2003 (Europ¨aisches Patentamt, zit. nach VDA 2004) Die Fokussierung auf vertikale Kooperationen begr¨ undet sich durch die Tatsache, dass diese Form der Zusammenarbeit in der Praxis vorherrschend ist.10 Zudem spielt dort die Einbeziehung von Markt- und Verhandlungsmacht eine wesentliche Rolle, da Automobilhersteller eher in der Lage sind, ihre Sicherheitsanforderungen einer Zulieferunternehmung als einem Konkurrenten aufzuoktroyieren. Untersuchungen haben zudem gezeigt, dass kleine und mittlere Unternehmungen (KMU) erhebliche Defizite auf dem Gebiet der ITSicherheit aufweisen, so dass die Automobilhersteller hier auf eine Implementation von Sicherheitsmaßnahmen dr¨angen sollten, um eigene Unternehmungsdaten zu sch¨ utzen.11 Die Zusammenarbeit in Forschung und Entwicklung ist deshalb von besonderem Interesse, da in diesem Bereich sehr sensible Daten anfallen k¨onnen, welche in zunehmendem Maße elektronisch ausgetauscht werden und daher ein potenzielles Ziel von Sabotage, Manipulation oder Spionage sind. Der Anteil fremdbezogener F&E-Leistungen hat in den letzten Jahren stark zugenommen. Folgende forschungsleitende Fragen stehen im Fokus der Untersuchung: • Welche speziellen technischen oder organisatorischen Problemfelder lassen sich in der Absicherung von vertikalen F&E-Kooperationen identifizieren? • Wie l¨asst sich die IT-Sicherheit in Unternehmungen der Automobilindustrie etablieren? • Welche Einflussfaktoren sind bei der Analyse von Risiken und der Gestaltung von Gegenmaßnahmen zu ber¨ ucksichtigen? 10 Vgl. Schmoeckel/Liebler/Schindele 1995: 38. 11 Vgl. Silicon.de 2005: 2; Winkel/Hecht/Tackenberg 2001.

1.2 Methodik und Aufbau (Forschungskonzeption und Forschungsprozess)

5

• Wie kann der bi- bzw. multilaterale Informationsaustausch zwischen Automobilhersteller und -zulieferer gegen Manipulation, Spionage und Sabotage gesch¨ utzt werden? Welche Gestaltungsans¨atze sind dazu geeignet, die Sicherheit von Informationssystemen und Daten branchenweit zu gew¨ahrleisten? Das Ziel der Untersuchung ist die Strukturierung der Grundlagen und die Vorstellung von Gestaltungsans¨atzen zur Absicherung von IT-gest¨ utzten F&E-Kooperationen zwischen Automobilhersteller und -zulieferer. Dabei werden sowohl unilaterale (einzelwirtschaftliche), bilaterale (zwischen zwei Unternehmungen) als auch branchenweite (multilaterale) L¨osungsans¨atze zur Gestaltung sicherer F&E-Kooperationen unter der Ber¨ ucksichtigung monet¨arer, organisatorischer, technischer und juristischer Faktoren erarbeitet. Die Untersuchung ist an den Problemen der Praxis orientiert und soll den Akteuren als Entscheidungs- und Handlungshilfe dienen. Dar¨ uber hinaus sollen mit der vorliegenden Arbeit erste Schritte zu einer Theoriebildung bez¨ uglich des Schutzes von Informationen in unternehmungs¨ ubergreifenden Kooperationen geleistet werden.

1.2 Methodik und Aufbau (Forschungskonzeption und Forschungsprozess) Die angestrebte Zielsetzung soll mit deskriptiven Methoden und einer handlungsorientierten Darstellung erreicht werden. Anhand von Beobachtungen, Erfahrungswerten, Analysen und Fallbeispielen werden induktiv abgeleitete Aussagen erarbeitet. Diese Vorgehensweise begr¨ undet sich zum einen durch die mangelhafte empirische Datenlage, die die deduktive Herleitung von allgemein g¨ ultigen und falsifizierbaren Gesetzen als nicht zul¨assig erscheinen l¨asst.12 Zum anderen fehlt ein geeigneter theoretischer Bezugsrahmen, der in der Lage ist, die vorliegenden Sachverhalte hinreichend fundiert darzustellen und die Fragestellungen explizit zu beantworten. Die Arbeit erh¨alt dadurch einen explorativen Charakter, der in der Theoriebildung nicht einem Begr¨ undungs-, sondern einem Entde” ckungszusammenhang“ zuzuordnen ist. Die Informatik wird hier als Wirtschaftsinformatik verstanden, deren Ziel und Selbstverst¨andnis es ist, die IT-unterst¨ utzte Gestaltung von und in Organisationen zu betreiben. Dabei wird die strukturelle Kopplung von Akteur, Organisation und Informatiksystem betrachtet.13 Im Folgenden wird der Aufbau der Arbeit u ¨ ber die Darstellung der Inhalte der einzelnen Kapitel aufgezeigt. 12 Diese Problematik wird im Abschnitt 2.2 vertiefend behandelt. 13 Vgl. Rolf 2003.

6

1 Einf¨ uhrung

Das erste Kapitel dient der Einf¨ uhrung in die Problematik, der Darstellung der methodischen Konzeption und der Beschreibung des Aufbaus der Arbeit. Im zweiten Kapitel werden die Grundlagen der IT-Sicherheit in Unternehmungen untersucht und vorgestellt, da die Gew¨ahrleistung der unternehmungsinternen Sicherheit eine Pr¨amisse f¨ ur die Sicherheit in unternehmungs¨ ubergreifenden Kooperationen darstellt. Die Analyse und (monet¨are) Bewertung von Risiken ist in diesem Kapitel von essenzieller Bedeutung f¨ ur das Verst¨andnis der elementaren Probleme in der IT-Sicherheit. Da die Legitimation der IT-Sicherheit in Unternehmungen in zunehmendem Maße in juristischen Kontexten stattfindet, werden diese ebenfalls dargestellt. Die Reduktion von Risiken in der elektronischen Datenverarbeitung kann u ¨ ber Schutzmaßnahmen erfolgen. Die vorgestellten technischen und organisatorischen Aspekte und Maßnahmen konzentrieren sich – neben den Grundlagen – maßgeblich auf solche, die zwar eine zentrale Rolle in der Praxis einnehmen, jedoch in der Literatur h¨aufig vernachl¨assigt werden. Zus¨atzlich sind die ITAnwender und deren Sensibilisierung f¨ ur die IT-Sicherheit von Bedeutung. Das Kapitel schließt mit der Vorstellung der relevanten Standards zur Etablierung und Aufrechterhaltung von IT-Sicherheit in Unternehmungen. Im dritten Kapitel werden die Struktur und die Organisation der Automobilindustrie exploriert, um den Untersuchungsgegenstand zu spezifizieren. Es wird begr¨ undet, warum moderne Informations- und Kommunikationstechnologien unerl¨asslich f¨ ur die Zusammenarbeit zwischen Hersteller und Zulieferer sind und welche Entwicklungen in der Automobilindustrie f¨ ur die n¨achsten Jahre prognostiziert werden. Die Grundlagen der Leistungserstellungs- und Leistungsaustauschprozesse in der F&E der Automobilindustrie werden in Kapitel vier dargestellt. Dabei werden verschiedene Formen des Informationsaustausches zwischen OEM und Zulieferer diskutiert sowie eine Typologie der zu beachtenden Aspekte in Kooperationen aus dem Blickfeld der IT-Sicherheit vorgestellt. Kapitel F¨ unf befasst sich schließlich mit dem Risiko- und Policymanagement in unternehmungs¨ ubergreifenden F&E-Kooperationen der Automobilindustrie. Es werden Ans¨atze vorgestellt, welche sowohl die Entscheidungsprozesse als auch Einf¨ uhrung und Betrieb von Sicherheitskonzepten und deren Zertifizierung praktikabel gestalten k¨onnen. Dies geschieht sowohl auf einzelwirtschaftlicher Basis, als auch konzeptuell in m¨oglichen Ans¨atzen zur Gestaltung eines branchenweiten Sicherheitskonzeptes. Das Fallbeispiel einer Kooperation zwischen Automobilhersteller und -zulieferer verdeutlicht dabei den Schutzbedarf in Kooperationsbeziehungen und beschreibt ad¨aquate Maßnahmen zur Reduzierung des vorhandenen Risikos als Gestaltungsansatz. Das sechste Kapitel bietet eine abschließende Bewertung und einen Ausblick auf zuk¨ unftige Entwicklungen hinsichtlich der Gestaltung von IT-Sicherheit in der Automobilindustrie.

1.2 Methodik und Aufbau (Forschungskonzeption und Forschungsprozess)

7

Des Weiteren wird weiterer Forschungsbedarf in den hier vorgestellten Zusammenh¨angen aufgezeigt. Es wird – sofern m¨oglich – bewusst darauf verzichtet, konkrete Produkte f¨ ur die ITSicherheit zu benennen. Stattdessen wird eine organisatorische bzw. technologische, produktneutrale Basis f¨ ur eine L¨osung vorgestellt. Dies begr¨ undet sich u.a. aus der Tatsache, dass der Lebenszyklus von Produkten aus dem Bereich der IT-Sicherheit sehr kurz ist. So ist beispielsweise nicht gew¨ahrleistet, dass nachfolgende Versionen denselben Schutzbedarf oder Funktionsumfang unterst¨ utzen. Zus¨atzlich ist der Einsatz eines Produktes abh¨angig von den bereits eingesetzten Produkten und Anforderungen in einer Unternehmung. Es w¨are daher stets zu pr¨ ufen, ob z.B. die Produkte kompatibel zueinander sind und ob sie sich sinnvoll erg¨anzen. Weiterhin ist eine Produktentscheidung u.a. abh¨angig von dem individuellen Schutzbedarf, monet¨aren Mitteln, eingesetzten Systemen, Wissensstand und Verf¨ ugbarkeit von Personen, Applikationen, Infrastrukturen und Lizenzmodellen. Des Weiteren werden spezifische Applikationen und Dienste in der Regel nur anhand ihres Gattungsbegriffes (z.B. CAD“ statt des Produktnamens einer Applikation eines ” spezifischen Herstellers) genannt, da lediglich der Wert der Daten eine Rolle spielt und nicht das Format.

2 IT-Sicherheit in Unternehmungen Leistungserstellungs- und Leistungsaustauschprozesse mittels Informations- und Kommunikationstechniken u ¨ber ¨offentliche Netzwerke (insbesondere das Internet) sind grunds¨atzlich einer inh¨arenten Sicherheitsproblematik unterworfen. Der ¨offentliche Aspekt des Internets bietet nicht nur Vorteile wie z.B. geringe Nutzungs- und Zugangskosten, sondern birgt auch Gefahren in sich: Manipulation, Spionage oder Sabotage von Informationen und Informationssystemen sind eine akute Gefahr bei der Nutzung elektronischer Informationsund Kommunikationsdienste. Es l¨asst sich feststellen, dass Informationen und Daten von Unternehmungen in zunehmendem Maße IT-Sicherheitsrisiken ausgesetzt sind.14 Eine Umfrage des Computer Security Institute (CSI) und des Federal Bureau of Investigation (FBI) zeigte, dass Computerviren in den USA im Jahr 2005 unter den Befragten (n=639) einen Schaden in H¨ohe von ca. 43 Millionen US-Dollar erzeugten.15 Die Studie signalisierte eine Verringerung erfolgreicher Angriffe in den meisten Angriffskategorien zwischen 1999 bis 2005. Andere Studien verweisen hingegen auf eine gegens¨atzliche Ent¨ wicklung.16 Zudem verweisen mehrere Berichte auf eine Anderung des Verhaltens von Angreifern. Demnach werden die ungerichteten Masseninfektionen von IT-Systemen mit Schadsoftware (z.B. Viren, W¨ urmer, Trojaner) abnehmen – stattdessen werden Systeme und Netzwerke zu Spionagezwecken gezielt infiltriert.17 Des Weiteren werden sogenannte Distributed Denial-of-Service (DDoS) Angriffe genutzt, um Unternehmungen zu erpressen oder zur Gesch¨aftsaufgabe zu zwingen.18 Risikospezialisten der Firma Mi2G haben ein 14 Vgl. Fiutak 2004; Werners/Klempt 2007. 15 Vgl. Gordon/Loeb/Lucyshyn et al. 2005: 15f. Dies ist umso erstaunlicher, wenn ber¨ ucksichtigt wird, dass 96% der Befragten Antivirus-Software einsetzten. Die Aussagekraft der CSI/FBI-Studie ist nur gering ausgepr¨agt, da nahezu alle Befragten Mitglied im CSI und daher u ur ¨ berdurchschnittlich f¨ IT-Sicherheit sensibilisiert sind, vgl. Gordon/Loeb/Lucyshyn et al. 2005: 5. 16 Beispielsweise BSI 2005e: 33. 17 Vgl. Gaßner 2006; Ohne Verfasser 2006. Dabei existieren in diesem Zusammenhang h¨aufig Verbindungen zur organisierten Kriminalit¨ at. Vgl. Kr¨ uger 2006; BSI 2005e: 33. 18 Vgl. Curtis 2006. Zu diesem Zweck wird eine große Anzahl an Computern von (h¨aufig privaten) Internetnutzern ohne deren Kenntnis mit einer speziellen Software pr¨apariert, welche die Fernsteuerung einiger Funktionen bietet (sogenannte Bot-Netze). Dazu geh¨ ort in der Regel das ferngesteuerte Aufrufen von Webseiten. Die infizierten Computer (bis zu mehreren 1.000) rufen in einer konzertierten Aktion immer wieder die Webseiten einer Unternehmung auf oder versenden kontinuierlich E-Mails

10

2 IT-Sicherheit in Unternehmungen

realisiertes Schadensvolumen von 169 bis 204 Milliarden US-Dollar durch Schadsoftware (Viren, W¨ urmer, Trojaner) f¨ ur das Jahr 2004 ermittelt.19 Laut der Arbeitsgemeinschaft f¨ ur Sicherheit der Wirtschaft e.V. (ASW) haben Untersuchungen ergeben, dass nur drei Prozent der Spionageangriffe erkannt werden.20 Vor diesem Hintergrund kann die Aussage aus Studien in Frage gestellt werden, dass nur 3% der kleinen und mittleren Unternehmungen und 6% der großen Unternehmungen im Jahr 2004/2005 einen Datendiebstahl“ erlitten haben.21 Das Bundesamt f¨ ur Sicherheit ” in der Informationstechnik (BSI) merkt dazu an: Gef¨ahrdet von Wirtschafts- und Kon” kurrenzspionage sind nahezu alle Unternehmensbereiche, wobei Forschungs- und Entwicklungsabteilungen am st¨arksten bedroht sind. Unternehmen mit großen, werthaltigen Entwicklungsbereichen wie beispielsweise Pharmaunternehmen, Unternehmen der Automobilindustrie sowie Softwarefirmen sind besonders gef¨ahrdet.22 Dem Schutz von geistigem Eigentum wird in vielen Bereichen kein ausreichender Stellenwert zugewiesen, was daran liegt, dass auf Managementebene das Bewusstsein f¨ ur IT-gest¨ utzte Wirtschaftsspionage nicht ausreichend ausgepr¨agt ist.“ 23 Es existiert ein weiteres Motiv f¨ ur Unternehmungen, die Gefahren von Spionage zu verharmlosen, zu ignorieren oder Spionagef¨alle in der eigenen Unternehmung zu verschweigen. Bei der Bekanntgabe eines erfolgreichen Aussp¨ahens von Daten in der eigenen Unternehmung droht ein Reputationsverlust, der sich negativ auf die Gesch¨aftst¨atigkeit auswirken kann. Im Folgenden werden die begrifflichen, organisatorischen, technischen und rechtlichen Grundlagen f¨ ur die Etablierung und Aufrechterhaltung von IT-Sicherheit in Unternehmungen dargestellt.

2.1 IT-Sicherheit IT-Sicherheit besch¨aftigt sich haupts¨achlich mit der Sicherheit von Informationen bzw. der sicheren Kommunikation. Die IT-Sicherheit wird h¨aufig dem Begriff Unternehmenssicherheit untergeordnet. Diese Klassifikation wird zum Teil in der Weise rezipiert, dass es sich hierbei um die interne Absicherung von Informationen einer Unternehmung handelt. Die IT-Sicherheit einer Unternehmung muss jedoch s¨amtliche Beziehungen, Akteure an eine Unternehmung. Die IT-Systeme der betroffenen Unternehmung werden dadurch h¨aufig derart belastet, dass sie nicht mehr f¨ ur Anwender und/oder Kunden verf¨ ugbar sind. 19 Vgl. Seiler 2006: 18. 20 Vgl. ASW 2003: 40. 21 Vgl. silicon.de 2005: 7. 22 Vgl. BSI 2003. 23 BSI 2005e: 32.

2.1 IT-Sicherheit

11

und Prozesse umfassen, damit sie wirksam wird und den Schutz relevanter Informationen zuverl¨assig gew¨ahrleisten kann.24 Die Absicherung von Prozessen – auch in unternehmens¨ ubergreifenden Wertsch¨opfungsketten – gestaltet sich sehr komplex. Nicht nur die infrastrukturellen Bestandteile (u.a. Netzwerke, Systeme, Applikationen), sondern auch die organisatorischen Faktoren (Schaffung von Verantwortlichkeiten, Weiterbildung/Sensibilisierung der Mitarbeiter, Rollen und Berechtigungen etc.) m¨ ussen ber¨ ucksichtigt werden. Die Dimensionierung der ITSicherheitsmaßnahmen muss dem Wert der zu sch¨ utzenden G¨ utern und Informationen angepasst werden.

2.1.1 Einfu ¨ hrung und Begriffsdefinition Der Begriff Sicherheit wird kontextabh¨angig unterschiedlich interpretiert. Im Kontext Risikogesellschaft (Soziologie) wird Sicherheit anders ausgelegt als z.B. in der Entscheidungstheorie (Wirtschaftswissenschaft), der Individualpsychologie oder im Bauingenieurwesen. Im angloamerikanischen Sprachraum existiert die Unterscheidung der Termini Safety und Security. Safety bezeichnet dabei die Funktionssicherheit unter gegebenen (normalen) Parametern und bezieht sich in erster Linie auf physikalische Aspekte (z.B. Arbeits- oder Insassenschutz). Security hingegen beschreibt die Informationssicherheit, die die unautorisierte Informationsgewinnung oder -ver¨anderung verhindern soll.25 Die Informationssicherheit bezieht sich auf Informationen in jedweder Form wie Papier, CDs, Magnetb¨ander, Tageslichtprojektorfolien, etc.. IT-Sicherheit (oder auch Informationssystemsicherheit26 ) wird hier verstanden als umfassende Betrachtung der Absicherung von elektronischen Informationen in den technischen und nicht-technischen Dimensionen Software, Hardware, Infrastruktur, Personen, Organisation und Umwelt (Abb. 2.1). Informationen bewegen sich – in Form von Prozessen – in dieser Abbildung sowohl zwischen als auch innerhalb der einzelnen Schichten. IT-Sicherheit beinhaltet in dieser Betrachtungsweise sowohl Produkt- als auch Prozesseigenschaften. Der Produktcharakter findet sich z.B. in intangiblen G¨ utern wie Software, oder in den tangiblen Bestandteilen wie z.B. Computerbauteilen, Schließanlagen, L¨oschsystemen, Sicherheitst¨ uren oder Netzwerkequipment. Der Prozesscharakter manifestiert sich u ¨berwiegend in organisatorischen Rahmenbedingungen wie z.B. Verantwort24 Dies wird h¨aufig mit eine Kette ist nur so stark wie ihr schw¨ achstes Glied“ umschrieben. ” 25 Vgl. Eckert 2004: 4f. 26 Vgl. Hoppe/Prieß 2003: 21f.

12

2 IT-Sicherheit in Unternehmungen

Umwelt Organisation Personen

Hardware Infrastruktur Software

Informationen Prozesse

Abbildung 2.1: Dimensionen der IT-Sicherheit lichkeiten, Weiterbildungs- und Qualifizierungsmaßnahmen, Wertsch¨opfungsketten oder Berechtigungskonzepten. IT-Sicherheit ist ein Kompositum, welches sich aus verschiedenen Bestandteilen und Disziplinen zusammensetzt. Untermengen der IT-Sicherheit sind u.a. Betriebssystemsicherheit, Anwendungssicherheit, Kommunikationssicherheit, Netzwerksicherheit, Internetsicherheit, Transaktionssicherheit, Datenbanksicherheit und Datensicherheit.27 Der Datenschutz ist nicht origin¨arer, sondern komplement¨arer Bestandteil der IT-Sicherheit, der die gesetzlichen Vorgaben im Umgang mit personenbezogenen Daten realisiert.

2.1.2 Schutzziele der IT-Sicherheit Die Gef¨ahrdung von Werten einer Organisation wird in der IT-Sicherheit durch drei maßgebliche Schutzziele dargestellt:28 • Vertraulichkeit (Confidentiality). Die Informationen k¨onnen nur von autorisierten Akteuren, Objekten oder Prozessen eingesehen werden. Die Kommunikation wird nicht von Dritten beobachtet. • Integrit¨at (Integrity). Die Informationen sind nicht manipuliert. 27 Vgl. Hoppe/Prieß 2003: 25f. 28 Vgl. u.a. BSI 2005: Abschnitt 2.2; Cole/Matzer 1999: 19f.; Denning 1999: 31; Eckert 2004: 6ff.; G¨ortz/Stolp 1999: 24f.; Holznagel 2003: 12ff.; Hoppe/Prieß 2003: 24f.; Krampert 2003: 20; Krutz/Vines 2004: 5; Rannenberg 1998: 19f.; Schaum¨ uller-Bichl 1992: 17; Werners/Klempt 2005: 4.

2.1 IT-Sicherheit

13

• Verf¨ugbarkeit (Availability). Die Informationen stehen gem¨aß den eigenen Vorgaben zur Verf¨ ugung.29 Ziel der IT-Sicherheit ist es, diese Schutzziele je nach Anwendbarkeit und gew¨ unschtem Zielerreichungsgrad zu gew¨ahrleisten. Zum Teil werden diese Ziele durch weitere Ziele erg¨anzt: • Zurechenbarkeit (Accountability),30 • Authentizit¨at (Authenticity),31 • Qualit¨atspr¨ufung bzw. -best¨atigung (Assurance),32 • Verbindlichkeit (Non-Repudiation),33 • Anonymisierung und Pseudonymisierung (Anonymity and Pseudonymity).34 In der Regel werden in der Praxis nur die drei klassischen“ Schutzziele betrachtet. Das ” nachgeordnete Schutzziel Verbindlichkeit wird zum Teil explizit in die Sicherheitsbetrachtung einbezogen, h¨aufiger jedoch wird es als inh¨arentes Unterziel von Integrit¨at angesehen. Dies ist abh¨angig von dem Gesch¨aftsmodell und den Kommunikationsstrukturen der Unternehmung. Wenn z.B. verbindliche Vertr¨age oder finanzielle Transaktionen u ¨ber ¨offentliche Kommunikationsnetze realisiert werden, dann sollte Verbindlichkeit als eigenes Schutzziel betrachtet werden. Die Reduktion auf drei Ziele dient in erster Linie der ¨ Ubersichtlichkeit bei der Identifikation von Risiken.35 In einer abstrakteren Betrachtungsweise lassen sich weitere funktionale Kriterien in L¨osungen zur Etablierung der IT-Sicherheit abgrenzen, zu denen beispielsweise Performanz, Widerstandsf¨ahigkeit/Ausfallsicherheit (Resilience) oder Skalierbarkeit (Scalability) geh¨oren.

2.1.3 Klassifizierung und Gef¨ ahrdung von Werten Der Schutz von Informationen und deren impliziter Werte ist Intention und Aufgabe der IT-Sicherheit. In der Regel wird der Wert von Informationen nicht monet¨ar – und 29 Verf¨ ugbarkeit als Ziel impliziert nicht, dass die Informationen jederzeit ad hoc zur Verf¨ ugung stehen m¨ ussen. Verf¨ ugbarkeit kann auch bedeuten, dass die Information z.B. lediglich innerhalb gesetzlicher ¨ Fristen (bspw. § 21 Abs. 2, 4 TKUV) zur Verf¨ ugung stehen muss. 30 Vgl. Rannenberg 1998: 19f.; Eckert 2004: 11; Krutz/Vines 2004: 6. 31 Vgl. Holznagel 2003: 12; Krampert 2003: 21; Eckert 2004: 7; Werners/Klempt 2005: 4. 32 Vgl. Holznagel 2003: 12. 33 Vgl. Krampert 2003: 21; Eckert 2004: 11; Hoppe/Prieß 2003: 25; Werners/Klempt 2005: 5. 34 Vgl. Eckert 2004: 12. 35 Ausf¨ uhrlich zur Begriffsbildung vgl. Federrath/Pfitzmann 2000.

14

Klasse ¨ Offentlich Intern Vertraulich

Geheim

2 IT-Sicherheit in Unternehmungen

Beschreibung Informationen, die keinerlei Restriktionen unterliegen – z.B. ¨offentlicher Internetauftritt oder Presseinformationen. Informationen, die nur innerhalb der Unternehmung ver¨offentlicht werden d¨ urfen – z.B. Telefonlisten. Informationen, deren Kenntnisnahme, Manipulation oder Sabotage durch Unbefugte das Erreichen von Produkt- und Projektzielen gef¨ahrden k¨onnen – z.B. Produktionsplanung. Informationen, deren Kenntnisnahme, Manipulation oder Sabotage durch Unbefugte das Erreichen von Unternehmungszielen nachhaltig gef¨ahrden k¨onnen – z.B. strategische Planungen oder Prototypen. Tabelle 2.1: Klassifikation von Informationen

damit stetig –, sondern als diskrete Merkmalsauspr¨agung in Klassen ausgewiesen. Dies vereinfacht die Einstufung von Informationen in erheblichem Maße. Der international am h¨aufigsten eingesetzte Standard zur IT-Sicherheit in Organisationen, BS 7799 bzw. ISO 17799, definiert einen Wert (engl. asset) als anything that has a value to the organi” zation“.36 In der Praxis hat sich die Bildung von vier Klassen durchgesetzt (siehe Tab. 2.1).37 Die Bewertung wird in der Regel im Alltag durch den Informationseigent¨ umer durchgef¨ uhrt, da Dritte in vielen F¨allen den (fach- oder abteilungsspezifischen) Wert der Information nicht einsch¨atzen k¨onnen. Gef¨ahrdet sind die Werte durch Spionage (unbefugte Kenntnisnahme)38 , Manipulation (unbefugte Ver¨anderung) und Sabotage (unbefugte Einschr¨ankung der Verf¨ ugbarkeit oder Funktion). Die Gef¨ahrdung von Werten l¨asst sich in die Bereiche Angriff und St¨orung unterteilen. Ein Angriff ist die vors¨atzliche intentionale Verletzung von Schutzzielen der IT-Sicherheit. Eine St¨orung ist eine nicht-intentionale 36 ISO/IEC FDIS 17799:2005(E): 13. 37 Die Beschreibung der Klassen ist stark von den Unternehmungszielen abh¨angig. Im ¨offentlichen Dienst, geheimdienstlichen und milit¨ arischen Kontexten wird in der Regel eine f¨ unfstufige Klassifizierung von ur den Dienstgebrauch, Verschlusssache vertraulich, geheim bis zu ¨offentlich, Verschlusssache nur f¨ streng geheim, vorgenommen. Vgl. Gesetz u ¨ ber die Voraussetzungen und das Verfahren von Sicher¨ heits¨ uberpr¨ ufungen des Bundes (SUG) § 4 vom 20. April 1994 (Bundesgesetzblatt (BGBl.) I, S. 867), zuletzt ge¨andert durch Art. 4 G vom 21. Juni 2005 (BGBl. I, S. 1818). 38 H¨aufig wird in dies als Datendiebstahl bezeichnet. Diese Umschreibung trifft nur ungen¨ ugend auf den Sachverhalt zu, da die Daten nur in den seltensten F¨ allen entwendet (d.h. von ihrem Ursprungsort entfernt) werden. Vielmehr handelt es sich um das Delikt Aussp¨ahen von Daten gem¨aß § 202a StGB, wobei der Begriff des Datums alle elektronisch, magnetisch oder sonst nicht mittelbar wahrnehmbar gespeicherte oder u ¨ bermittelte Informationen umfasst. Vgl. Holznagel 2003: 106f.

2.1 IT-Sicherheit

15

¨ Verletzung dieser Schutzziele, z.B. durch Fahrl¨assigkeit oder h¨ohere Gewalt. Einen Uber39 blick u ber einige potenzielle Gef¨ a hrdungen zeigt Abb. 2.2. ¨ Gefährdungen

Störung

Angriff

Berechtigte Akteure

Unberechtigte Akteure

Fahrlässigkeit

Höhere Gewalt

Eigene Mitarbeiter

Eigene Mitarbeiter

Unsachgemäße Bedienung

Fremde Mitarbeiter

Fremde Mitarbeiter

Missachtung von Vorschriften

Stromausfall

Vertragspartner

Vertragspartner

Mangelhaftes Systemdesign

Hitze- u. Brandschäden

Script Kiddies

Organisatorische Mängel

Wasser u. Feuchtigkeit

Techn. Defekt

Kriminelle

Überspannung

Hacker

Verschmutzung

Wettbewerber

Naturkatastrophen

Geheimdienste

¨ Abbildung 2.2: Uberblick u ¨ber potenzielle Gef¨ahrdungen (in Anlehnung an Hoppe/Prieß 2003: 32f.) Die Qualifikation und der Mitteleinsatz der Angreifer sind sehr heterogen ausgepr¨agt. ¨ als eine wesentliche Bedrohung darstelW¨ahrend sog. Script Kiddies40 eher ein Argernis len, k¨onnen versierte Hacker selbst in gesicherte Netzwerke eindringen. Geheimdienste stellen vor allem durch ihre Ausstattung in Personal, finanziellen Ressourcen und Technik eine Gef¨ahrdung dar. Der Anteil der Innent¨ater an erfolgten IT-Sicherheitsverletzungen wird als relativ hoch – je nach Studie zwischen 55 und 90% – angesehen.41 Die enorme Streuung der Ergebnisse der Studien l¨asst vermuten, dass entweder unterschiedliche (und eventuell unpassende) statistische Verfahren verwendet wurden oder auch die Datenlage/Stichprobe unzureichend war. Einige neuere Studien aus dem Jahr 2005 von z.B. 39 In Anlehnung an Hoppe/Prieß 2003: 32f. 40 Script Kiddies ist eine Sammelbezeichnung f¨ ur meist jugendliche Angreifer, die vorgefertigte Software, z.B. Rootkits, Viren, Trojaner, etc., nutzen oder nach im Internet verf¨ ugbaren Anleitungen f¨ ur Angriffe vorgehen und u ugen. ¨ber keine herausragenden Programmierf¨ahigkeiten oder Netzwerkkenntnisse verf¨ 41 Vgl. Heitmann/Neuber 2004: 211.

16

2 IT-Sicherheit in Unternehmungen

silicon.de oder kes42 nehmen die Unterscheidung in Innen- und Außent¨ater nicht mehr explizit vor. Das Ph¨anomen der Innent¨ater wurde in den ersten gr¨oßeren empirischen Studien Mitte der neunziger Jahre besonders exponiert, da ein Großteil der getroffenen Sicherheitsmaßnahmen zum Schutz der Informationssysteme auf externe Angreifer ausgerichtet worden war. W¨ahrend externe Angreifer sich zuerst Informationen u ¨ ber ihr Angriffsziel beschaffen m¨ ussen, stehen Innent¨atern eine Vielzahl von internen Informationsquellen zur Verf¨ ugung. Zum Teil kann es sich dabei auch um Systeme handeln, die von dem Innent¨ater selbst (mit-)gestaltet worden sind oder von ihm administriert werden. Das Innent¨aterph¨anomen ist bisher nicht hinl¨anglich erforscht, sondern es wird vielmehr angenommen, dass es sich in erster Linie um frustrierte oder indignierte Mitarbeiter handelt. Ebenso k¨onnen externe Berater oder Zeitarbeiter (Besch¨aftigte die f¨ ur einen bestimmten Zeitraum an eine Unternehmung vermittelt werden) als interne Mitarbeiter und als Risikoquelle betrachtet werden. Es existiert keine 100%ige Sicherheit. Vielmehr ist es Aufgabe der IT-Sicherheit Produkte, Prozesse und darin enthaltene Informationen so abzusichern, dass bestehende Risiken auf ein annehmbares Maß reduziert werden.

2.2 Risikomanagement in der IT-Sicherheit Wirtschaftliche Aktivit¨aten von Unternehmungen sind untrennbar mit Risiken verbunden. Unternehmerische Entscheidungen sind stets zukunftsorientiert und gepr¨agt durch Unsicherheit, Unbestimmtheit und Unvollst¨andigkeit, da k¨ unftige Entwicklungen (z.B. auf dem Produkt- oder Finanzmarkt, neue Kundenpr¨aferenzen) nicht eindeutig vorhersehbar sind und die Bewertung einer Entscheidung gegebenenfalls erst ex-post erfolgen kann.43 Dabei l¨asst sich unterscheiden zwischen ursache- und wirkungsbezogenen Risiken. Die Vieldeutigkeit k¨ unftiger Entwicklungen mit verschiedenen Szenarien und unterschiedlichen Wahrscheinlichkeiten wird als ursachebezogenes Risiko bezeichnet. Demgegen¨ uber stellt ein wirkungsbezogenes Risiko die Gefahr eines unerw¨ unschten Ereignisses dar. Dieses wirkungsbezogene Risiko kann wiederum unterschieden werden in symmetrische und asymmetrische Risiken. Symmetrische Risiken k¨onnen sich sowohl positiv als auch negativ auf den Zielerreichung auswirken, w¨ahrend asymmetrische Risiken ausschließlich negative Konsequenzen auf den Grad der Zielerf¨ ullung aufweisen.44 In der IT-Sicherheit sind Risiken im Allgemeinen asymmetrisch und wirkungsbezogen.

42 Vgl. silicon.de 2005; kes 2004a und 2004b. 43 Vgl. Neub¨ urger 1989: 29.; H¨ olscher 2002: 5. 44 Vgl. H¨olscher 2002: 5f.

2.2 Risikomanagement in der IT-Sicherheit

17

Risiko wird hier verstanden als die Existenz eines potenziellen Schadensereignisses (Abweichung von einer festgelegten oder erwarteten Zielgr¨oße) in Bezug auf das Handeln oder Nicht-Handeln von Akteuren – also als M¨oglichkeit, dass ein Wert durch das Ausnutzen einer Schwachstelle gef¨ahrdet ist und potenziell gesch¨adigt werden kann.45 Das Nicht-Handeln eines Akteurs ist hierbei von besonderer Bedeutung. Es muss unterschieden werden zwischen der bewussten Entscheidung, eine Handlung zu unterlassen, und der nicht getroffenen Entscheidung auf Grund von nicht erfassten Risiken und Handlungsoptionen. Die Entscheidung, ein Handeln zu unterlassen, wird als Restrisiko bezeichnet, beschreibt also jenes Risiko, welches der Akteur gewillt ist einzugehen. Dies l¨asst sich auch mit dem Term kalkuliertes Risiko umschreiben. Die zweite Variante, das Nicht-Handeln auf Grund von fehlenden Informationen oder mangelhaften Analysen, wurde bisher in der IT-Sicherheit nicht oder nur oberfl¨achlich betrachtet. Erst aus einem rezipierten Risiko kann der betroffene Akteur eine Bedrohung ableiten. Oder mit anderen Worten: Wenn das Risiko erkannt und als relevante Gef¨ahrdung f¨ ur Unternehmungswerte eingestuft wird, kann dies als Bedrohung wahrgenommen werden. W¨ahrend das Risiko die (objektive) mathematisch-statistische Berechnung einer Schadenswahrscheinlichkeit und -h¨ohe darstellt, ist die Bedrohung die subjektive (und damit evtl. irrationale) Wahrnehmung eines Risikos.46 Demgegen¨ uber bezeichnet eine Gef¨ahrdung die potenzielle Ausnutzbarkeit einer Schwachstelle oder Verwundbarkeit in technischen und/oder nicht-technischen Systemen.

45 Dies entspricht dem Risikoverst¨ andnis der Informatik. Die Betriebs- oder Ingenieurswissenschaft agiert mit anderen Interpretationen des Risikobegriffs. 46 Die Begrifflichkeiten Risiko und Bedrohung werden im Allgemeinen in der Literatur nur ¨außerst selten klar definiert und voneinander abgegrenzt. Eckert (2004: 13ff.) unterscheidet zwischen Schwachstellen/Verwundbarkeiten, Bedrohung und Risiko. Dort wird unter einer Bedrohung die gezielte Ausnutzung einer Schwachstelle oder Verwundbarkeit in Systemen verstanden. F¨ ur das BSI ist eine Bedrohung ein Ereignis oder Umstand, durch den ein Schaden entstehen kann. Die hier vorgenommene Unterscheidung zwischen objektivem statistischem Risiko und der subjektiven Wahrnehmung einer Bedrohung begr¨ undet sich in der Tatsache, dass die Perzeption eines Risikos eine gewichtige Rolle in der Analyse und Ausgestaltung von IT-Sicherheit aufweist und zwar besonders dann, wenn Risiken nicht oder nur ungenau bekannt sind und daher u ¨ ber- oder untersch¨atzt werden. So muss z.B. die statistische Wahrscheinlichkeit Opfer eines Terroraktes zu werden, nicht mit der subjektiv wahrgenommenen Bedrohung korrelieren, sondern kann diametral ausfallen. Dar¨ uber hinaus impliziert eine Bedrohung einen oder mehrere Akteure, w¨ ahrend eine Gef¨ ahrdung die M¨oglichkeit ausdr¨ uckt, dass eine sch¨adliche Situation eintreten kann.

18

2 IT-Sicherheit in Unternehmungen

Eine zentrale Frage in der Auseinandersetzung mit dem Begriff des Risikos ist unter anderem eine Frage nach der Wahrnehmung. So konstatiert der Soziologe Ulrich Beck: Es ist nie klar, ob sich die Risiken versch¨arft haben oder unser Blick f¨ ur sie.“ 47 Diese ” Aussage gilt in erster Linie f¨ ur nicht oder mathematisch nur schwer erfassbare Risiken.48 Risiken werden in diesem Abschnitt u ¨berwiegend unter IT-Risiko-Aspekten vorgestellt. Weitere organisatorische und/oder betriebliche Perspektiven wie finanzielle oder Marktrisiken werden hier nicht weiter betrachtet. Die Risikoanalyse hat die Aufgabe, folgende f¨ unf Parameter sequenziell zu untersuchen:49 1. Werte: Welche Werte lassen sich identifizieren und wie relevant sind diese f¨ ur die Unternehmung? 2. Gef¨ahrdungen: Sind die Werte durch ein Risiko gef¨ahrdet? 3. Schwachstellen: Existieren Schwachstellen? Lassen sich existente Schwachstellen ausnutzen und, wenn ja, von wem und wie? 4. Schaden: Welcher Schaden kann im Eintrittsfall realisiert werden? 5. Maßnahmen: M¨ ussen Gegenmaßnahmen getroffen werden, um das Schadensausmaß zu minimieren oder zu eliminieren und, wenn ja, welche? In Bezug auf den Umgang mit dem m¨oglichen Verlust von Werten (Sch¨aden) existieren f¨ unf Handlungsoptionen:50 • Risikovermeidung, • Risikoreduktion, • Risikoeliminierung, • Risikotransfer (z.B. Outsourcing, Schadenersatz, Versicherung) und • Risikoakzeptanz (Restrisiko). Je nach Schadensh¨ohe und -h¨aufigkeit bleibt es den Akteuren u ¨ berlassen, welche Handlungsoptionen wahrgenommen werden sollen. Dies reicht vom Verzicht auf Maßnahmen ¨ (z.B. bei sehr geringen Werten), u alzungsmaßnahmen ¨ ber pr¨aventive, ex-post und Uberw¨ bis hin zu akzeptierten Restrisiken. 47 Beck 1986: 73. 48 Dies ist u.a. der Fall bei sog. Risiken zweiter Ordnung, bei denen der Schadensverlauf sich auf die Schadensursache auswirkt und das ausl¨ osende System insgesamt ver¨andert (z.B. Kernschmelzen). Vgl. Japp 2000: 8. 49 In Anlehnung an M¨ uller 2004a: 56f. 50 Vgl. Grimme 2005.

2.2 Risikomanagement in der IT-Sicherheit

19

Die Risikoanalyse ist essenzieller und unverzichtbarer Bestandteil der IT-Sicherheit. In betriebswirtschaftlichen Zusammenh¨angen ist sie als konstitutives Element zur Begr¨ undung der IT-Sicherheit anzusehen. Die Identifikation von Risiken dient der systematischen Erfassung von Gef¨ahrdungen und der Selektion von geeigneten Maßnahmen zur Reduktion von Risiken.

2.2.1 Verfahren zur Risikoidentifikation und -analyse Im privaten Alltag werden Risiken vorwiegend subjektiv bewertet. Studien haben gezeigt, dass Individuen, selbst wenn sie mit ausreichenden Informationen versorgt werden, Risiken in der Regel falsch einsch¨atzen. Dabei werden die Risiken u ¨bersch¨atzt, die außerhalb des Einflussbereiches einer Person liegen (z.B. Wahrscheinlichkeit mit dem Flugzeug abzust¨ urzen) oder die von den Medien dramatisiert (z.B. Wahrscheinlichkeit einer Straftat zum Opfer zu fallen) werden. Untersch¨atzt werden hingegen allt¨agliche und gew¨ohnliche Risiken wie die Wahrscheinlichkeit eines Unfalls im Straßenverkehr oder im Haushalt.51 Im gesch¨aftlichen Umfeld m¨ ussen Risiken so objektiv wie m¨oglich erfasst werden, um materielle und immaterielle Sch¨aden einer Handlung (oder auch nicht vorgenommenen Handlung) zu bewerten und eventuelle Maßnahmen abzuleiten. Die Risikoanalyse und -bew¨altigung muss dabei versuchen, das Verh¨altnis von Flexibilit¨at/Usability, Sicherheit und Kosten zu optimieren. M¨ogliche Sch¨aden lassen sich in direkte und Folgesch¨aden untergliedern:52 Direkte Sch¨aden: • Kosten Wiederbeschaffung, • Kosten Wiederherstellung/Reparatur, • Verlust der Geheimhaltung und Integrit¨at, • Diebstahl von Rechenzeit. Folgesch¨aden: • Stillstandskosten, • Auswirkungen auf andere Systeme und Komponenten, • Imageverlust, • Anspruchskosten. 51 Vgl. Schneier 2001: 250; Schneier 2006. 52 Vgl. Schaum¨ uller-Bichl 1992: 23ff.

20

2 IT-Sicherheit in Unternehmungen

Diese informationszentrierte Sichtweise wird hier beibehalten. Daneben existieren andere Perspektiven wie z.B. humanzentrierte Auffassungen, deren oberste Priorit¨at dem Erhalt von Leib und Leben gilt. Solche Szenarien werden hier nachrangig betrachtet, da sie bei den untersuchten privatwirtschaftlichen Zusammenh¨angen in der Automobilindustrie bisher nicht in Erscheinung getreten sind.53 Der Risikomanagementprozess wird u ¨blicherweise in die Phasen Identifikation, Analy¨ se, Steuerung und Uberwachung segmentiert. In der Phase der Risikoidentifikation wird versucht, potenzielle Risiken f¨ ur die Unternehmung zu erkennen. In der Analysephase werden die m¨oglichen Folgen der einzelnen Risiken f¨ ur die Unternehmung untersucht, um im Abschnitt der Risikosteuerung die Einflussm¨oglichkeiten auf Risiken und deren Folgen dergestalt umzusetzen, dass diese f¨ ur die Unternehmung trag- respektive beeinflussbar ¨ werden. Die Risiko¨ uberwachung dient der kontinuierlichen Uberpr¨ ufung der Risikoparameter, um sowohl das Risiko selbst als auch die Zusammensetzung von Einflussgr¨oßen auf ein Risiko zu u ¨berwachen. Die Summe dieser vier Phasen wird als Risikomanagement bezeichnet.54 Die Analyse von Risiken kann entweder mittels eines Top-Down- oder eines BottomUp-Ansatzes erfolgen. In der Top-Down-Vorgehensweise werden potenzielle Folgen von Risiken f¨ ur die Unternehmung ermittelt und die m¨oglichen Ursachen gesucht. Der BottomUp-Ansatz identifiziert Gef¨ahrdungen und Schwachstellen und bewertet die erdenklichen Folgen. Es existiert eine Vielzahl von Methoden, um Risiken zu ermitteln und zu analysieren. Die genutzten Methoden stammen aus unterschiedlichen Fachgebieten, haupts¨achlich aus der Sozialwissenschaft/Statistik, der Mathematik sowie Bereichen der Wirtschaftswissenschaft wie z.B. der Entscheidungstheorie. Die Instrumente der Risikoidentifikation lassen sich generell aufteilen in Kollektionsmethoden (z.B. Checklisten, Self-Assessments, Risikoidentifikationsmatrix) und Suchmethoden. Letztere lassen sich unterteilen in analytische Methoden (z.B. Fragenkataloge, morphologische Verfahren, FMEA, Baumanalyse, etc.) und Kreativit¨atsmethoden (z.B. Brainstorming, Delphi-Methode, Synektik). Kollektionsmethoden dienen der Identifikation bestehender und offensichtlicher Risiken, w¨ahrend Suchmethoden zur Identifikation zuk¨ unftiger und unbekannter Risikopotenziale geeignet sind. Eine empirische Studie zur Wahrnehmung und Steuerung von Risiken unter Chief Information Officers (CIO) in Deutschland von Junginger/Krcmar im Jahr 2004 ergab, dass das wichtigste Instrument zur Risikoidentifikation das Brainstorming mit Mitarbei53 Solche Szenarien werden nur dann betrachtet, wenn gesetzliche Vorgaben bestehen, wie z.B. Brandschutzbestimmungen. Eine Gef¨ ahrdung von Leib und Leben kann z.B. dann entstehen, wenn die Leistungsb¨ undel von sogenannten Kritischen Infrastrukturen stark beeintr¨achtigt werden oder nicht mehr erbracht werden k¨ onnen. Vgl. dazu u.a. Geiger 2000; Dunn/Metzger/Wenger 2002. 54 Die Themen Risikosteuerung und Risiko¨ uberwachung werden in Abschnitt 2.2.4 behandelt.

2.2 Risikomanagement in der IT-Sicherheit

21

tern der IT ist.55 Weitere eingesetzte Methoden sind Riskokataloge, Szenarioanalysen, Expertenbefragungen, Schadensfalldaten bisheriger Sch¨aden, Brainstorming mit Anwendern und Brainstorming mit der Unternehmungsf¨ uhrung. Die Auswirkungen der identifizierten Risiken werden anhand ihrer Eintrittwahrscheinlichkeit und der potenziellen Schadensh¨ohe analysiert (Risikoanalyse). Es werden hier die g¨angigen Verfahren zur Risikoanalyse vorgestellt, ohne die mathematisch-statistischen Grundlagen weiter auszuf¨ uhren. Die Datenbasis der Risikoanalyse sollte56 • objektiv messbar bzw. begr¨ undbar sein, • durch empirische Daten fundiert sein sowie • eine geringe Varianz (Unsicherheit) und eine hohe Erwartungstreue aufweisen. Die Risikoanalyse in Unternehmungen bedient sich in der Praxis in der Regel verschiedener Methoden.57 Die am h¨aufigsten eingesetzte Methode ist die Sch¨atzung der Eintrittswahrscheinlichkeiten und Schadensh¨ohen durch interne Experten. Danach folgen die Analysen anhand von erfahrenen Sch¨aden, Sch¨atzungen auf Grundlage bekannt gewordener Sch¨aden bei anderen Organisationen (z.B. durch die Fachpresse), Sch¨atzungen durch beauftragte externe Experten, Nutzung externer Schadensfalldatenbanken und Einsatz von Simulationen wie die Monte-Carlo-Simulation. Eine gemeinhin bekannte Methode ist, Risiko als Produkt von Eintrittswahrscheinlichkeit und Schaden zu betrachten (siehe Gleichung 2.1). R=W ·S

(2.1)

Diese kardinale Risikobewertung summiert die direkten und die Folgesch¨aden (S) und multipliziert sie mit der Wahrscheinlichkeit/H¨aufigkeit des Ereigniseintritts (W ). Wenn z.B. der m¨ogliche Schaden eines Ereignisses 800.000,- Euro betr¨agt und die Wahrscheinlichkeit des Ereignisses mit einmal in 16 Jahren angegeben wird, so ergibt dies ein j¨ahrliches Risiko von 50.000,- Euro (siehe Gleichung 2.2). 800.000 Euro · 0, 0625 Jahre = 50.000 Euro per annum

(2.2)

Seinen Ursprung hat diese Methode in der FIPS 65 (Federal Information Processing Standards Publication No. 65) des NIST (National Institute of Standards and Technology). 55 Vgl. Junginger/Krcmar 2004: 18. 56 Vgl. Gleißner 2001: 112. 57 Vgl. Junginger/Krcmar 2004: 19f.

22

2 IT-Sicherheit in Unternehmungen

Dort wird die Annual Loss Expectancy (j¨ahrliche Verlustrate, ALE) durch den Schaden I(Oi ) und die H¨aufigkeit Fi ebenfalls derart berechnet (siehe Gleichung 2.3).58 ALE =

n
i=1

I(Oi )Fi

(2.3)

wobei: {O1 , . . . , On } = Sch¨adliche Ereignisse I(Oi ) = Finanzielle Auswirkung des Ereignisses i Fi = H¨aufigkeit des Ereignisses i Der Standard wurde 1995 von der NIST ersatzlos gestrichen und der ALE-Ansatz gilt mittlerweile als gescheitert, da das Bedrohungsmodell zu komplex und die Abh¨angigkeit von einer fundierten Datenbasis zu groß ist. Dar¨ uber hinaus setzt ein solches vollst¨andig deterministisches Modell voraus, dass alle Gr¨oßen ex-ante bekannt sind.59 Eine kardinale Risikoanalyse beschreibt ein Risiko u ¨ ber die stetigen Merkmalswerte Zeit und finanzieller Schaden und ist quantitativ ausgepr¨agt. Eine ordinale Risikobewertung hingegen beschreibt ein Risiko diskret und ist st¨arker qualitativ orientiert. Folgendes Beispiel zeigt eine ordinale Risikobewertung (siehe Abb. 2.3). Untragbares Risiko

Serverdiebstahl Laptopdiebstahl

Tragbares Risiko

Externer Hackerangriff Sehr wahrscheinlich

Sehr unwahrscheinlich

Abbildung 2.3: Ordinale Risikobewertung Dieses Verfahren tr¨agt der Tatsache Rechnung, dass nicht allen Schadensauswirkungen ein eindeutiger finanzieller Wert zugewiesen und die Eintrittswahrscheinlichkeit eines Ereignisses nicht immer exakt bestimmt werden kann. 58 Vgl. NIST 1979. 59 Vgl. Nowey/Federrath/Klein et al. 2005: 17.

2.2 Risikomanagement in der IT-Sicherheit

23

Unbekannte Erwartungswerte (Ereignisse, bei denen eine Angabe von Eintrittswahrscheinlichkeiten nicht oder nur unvollst¨andig m¨oglich ist) k¨onnen allenfalls abgesch¨atzt werden.60 Es l¨asst sich unterscheiden zwischen stochastischer Unsicherheit und Unsch¨arfe.61 Die stochastische Unsicherheit kann unterteilt werden in Unsicherheit im engeren Sinne und Risiko. Unsicherheit im engeren Sinn charakterisiert den Umstand, dass mehrere Ereignisse eintreten k¨onnen, aber keine Aussage u ¨ber die Eintrittswahrscheinlichkeit getroffen werden kann. Risiko bedeutet in diesem Zusammenhang, dass den potenziellen Ereignissen zumindest diskrete Eintrittswahrscheinlichkeiten zugeordnet werden k¨onnen.62 Diese Unterscheidungen sind aus wissenschaftlicher Sicht (z.B. Entscheidungs- oder Spieltheorie) oder in spezifischen Kontexten (z.B. Kapitalmarkt-, Wertpapiermarkt- oder Preisrisiken) sinnvoll, finden jedoch in der Praxis der IT-Sicherheit kaum eine bzw. keine Ber¨ ucksichtigung, da der Aufwand einer solchen Risikoabsch¨atzung sehr hoch ausf¨allt. Deshalb wird realiter h¨aufig auf die Expertise fachlich kompetenter (interner oder externer) Experten zur¨ uckgegriffen, die eine derartige Analyse z.B. nach der Delphi-Methode vornehmen. Es existiert eine Vielzahl weiterer Risikoanalysemethoden wie z.B. CRAMM, OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation Framework), NIST SP 800-30, Microsoft Solutions Framework - Risk Management Discipline, VAM (Vulnerability Assessment and Mitigation), Failure Modes and Effects Analysis (FMEA), MARION (M´ethode d’Analyse de Risques Informatiques et d’Optimisation par Niveau), das Information Risk Management der KPMG, Common Criteria for Information Technology Security Evaluation (CC) oder die Risikoanalysemethode des BSI. Stellvertretend werden hier nur die beiden Methoden vorgestellt, die zumindest f¨ ur den deutschsprachigen Raum die h¨ochste Verbreitung gefunden haben: Die Methode des BSI IT-Grundschutzhandbuches sowie die ISO/IEC 17799:2005 bzw. ISO/IEC TR 13335-3:1998. Sie werden in den Abschnitten 2.6.2 bzw. 2.6.3 vorgestellt. Die anderen genannten Methoden basieren zum Teil auf der monet¨aren Bewertung von Risiken und/oder sind zu aufw¨andig, um sie f¨ ur eine Risikoanalyse komplexer Organisationen in Bezug auf die IT-Sicherheit zu nutzen.

60 G¨angige Verfahren sind z.B. die Maximin-, Maximax- oder Pessimismus-Optimismus-Regel nach Hurwicz. Die Stabilit¨at des Ereignisses l¨ asst sich anhand von Sensitivit¨atsanalysen oder der Methode der kritischen Werte ermitteln. Vgl. Gleißner/Wolfrum 2001: 141ff. 61 Auf das Problem der Unsch¨ arfe aus der Fuzzy-Set-Theorie wird hier nicht weiter eingegangen. Weiterf¨ uhrend dazu Zadeh/Kacprzyk 1999. Es existiert ein Ansatz zur Risikoanalyse und Auswahl von Sicherheitsmaßnahmen, welcher auf der Fuzzy-Set-Theorie basiert. Vgl. Werners/Klempt 2005b. 62 Vgl. Gleißner/Wolrum 2001: 140.

24

2 IT-Sicherheit in Unternehmungen

2.2.2 Methodische Probleme in der Identifikation und Analyse von Risiken Die Ergebnisse der Risikoanalyse bestimmen den Grad des zu etablierenden Schutzes f¨ ur die untersuchten Informationen und Prozesse. Die Korrektheit und Vollst¨andigkeit dieser Analyse wird damit zum Fundament der IT-Sicherheitsbestrebungen einer Organisation. Umso wichtiger scheint es daher, die theoretischen und praktischen Probleme in einer Risikoanalyse genauer zu betrachten. Die Korrektheit der Ergebnisse einer Risikoanalyse korreliert sehr stark mit der richtigen Auswahl und Anwendung eines Analyseverfahrens. Die gesch¨atzte oder auch statistische Wahrscheinlichkeit p f¨allt umso genauer aus, je h¨oher die Anzahl n ist bzw. je besser die Stichprobe die Grundgesamtheit abbildet. Stichproben werden genutzt, wenn die Erhebung der Grundgesamtheit nicht oder nur unter gr¨oßeren Aufwendungen realisierbar ist und induktiv allgemeing¨ ultige Aussagen formuliert werden sollen (sog. Inferenzstatistik).63 Dabei ist zu pr¨ ufen, ob z.B. die Variablen g¨ ultig operationalisiert worden sind, die korrekten Skalen ausgew¨ahlt wurden, das Ergebnis falsifizierbar ist, um ein valide Aussage zu erreichen, die das Risiko (ann¨ahernd) realit¨atsgetreu abbildet. Hier wird nicht weiter auf grundlegende Praxisprobleme in der Anwendung statistischer Verfahren eingegangen, statt dessen werden verfahrensbezogene Fehlerquellen aufgezeigt.64 Viele der vorgestellten Analysemethoden setzen die monet¨are Bewertung von Systemen und deren Bestandteilen bzw. Informationen voraus oder haben diese zum Ziel.65 Die Erfassung von m¨oglichen Sch¨aden und deren monet¨are Bewertung ist aus diversen Gr¨ unden schwierig zu realisieren: 1. Zeit und Wissen: Der monet¨are Wert einer Information bezieht sich auf direkte Kosten und Folgekosten bei Verlust von Integrit¨at, Vertraulichkeit oder Verf¨ ugbarkeit derselben. Jede Information m¨ usste auf die Kosten dieser drei Verlustszenarien u ¨ berpr¨ uft werden. Durchschnittliche Mitarbeiter sind mit dieser Aufgabe im Allgemeinen sowohl zeitlich als auch fachlich u ¨ berfordert, zumal in gr¨oßeren Unternehmungen die mit der Fachaufgabe betraute Abteilung und der Systembetreiber/Systembetreuer nur selten identisch sind. Weiterhin ist die Menge an verarbeiteten Informationen in der Regel viel zu groß, um einzelne Analysen durchf¨ uhren zu k¨onnen. 63 Vgl. Bortz 1993: 83. 64 So kann das Bayessche Erwartungswertprinzip nur auf sich h¨ aufig wiederholende Vorg¨ange mit bekannten Wahrscheinlichkeiten angewendet werden – die Risikobereitschaft der Akteure hingegen wird nicht weiter ber¨ ucksichtigt. Weitere methodische und lexikale Probleme in der Technikforschung und der Informatik finden sich u.a. bei Rolf 2003. 65 Eine Risikobewertung, die mit monet¨ aren Gr¨ oßen unterlegt worden ist, wird von den Rezipienten als sehr pr¨agnant empfunden, vgl. Stelzer 1995: 123.

2.2 Risikomanagement in der IT-Sicherheit

25

2. Kumulierungseffekte, Interdependenzen und Komplexit¨at: Moderne IT-Systeme sind in der Regel komplex und hochgradig vernetzt, so dass der Ausfall von Teilen einer Infrastruktur (z.B. ein einzelner Service oder eine Anzahl von Computern oder Leitungen) unbedachte Auswirkungen auf andere Bestandteile oder das Gesamtsystem haben kann. Ein IT-System, das einen komplexen Gesch¨aftsprozess managen soll, muss ¨ahnlich komplex sein wie der Gesch¨aftsprozess selbst. Diese Komplexit¨at ist weder transparent noch eindeutig beherrschbar.66 3. Insuffiziente Datenlage: Die Datenbasis f¨ ur die regionale oder lokale Anzahl und Dauer von Naturkatastrophen erlaubt relativ pr¨azise Vorhersagen u ¨ ber deren Eintrittswahrscheinlichkeiten. Die H¨aufigkeit von IT-Sicherheitsvorf¨allen und das zu erwartende Schadensmaß werden jedoch nur selten oder gar nicht erhoben. Dies begr¨ undet sich in der Tatsache, dass Sicherheitsvorf¨alle in Unternehmungen im Allgemeinen nicht publiziert werden, da ein Imageschaden bef¨ urchtet wird. Ohne solide Datenbasis l¨asst sich ein Risiko jedoch nur unzureichend kalkulieren. ¨ 4. Immaterielle Werte: Ubergeordnete Werte, z.B. Firmenkultur oder Reputation, k¨onnen ebenfalls bei Sicherheitsvorf¨allen besch¨adigt werden. Das Ausmaß eines solchen Schadens ist monet¨ar ¨außerst schwierig zu erfassen. Romeike/Finke sehen im Thema Risikomanagement ein Paradigma f¨ ur mangelhaft strukturierte Probleme mit unbekannten Ursache-Wirkungs-Beziehungen.67 Dabei unterscheiden sie zwischen vier verschiedenen Defekten“: ” 1. Wirkungsdefekt. Die Beziehung zwischen Stimulus und Resultat innerhalb des Systems und der Interaktion zwischen Umwelt und System ist h¨aufig nicht genau bekannt, da IT-Systeme und deren Vernetzung zu komplex sind. 2. Bewertungsdefekt. Die Anzahl der m¨oglichen Zust¨ande eines Systems sind ¨außerst umfangreich. Ein System mit zehn Elementen und jeweils sechs Zust¨anden kann 610 Systemzust¨ande annehmen. Ferner sind IT-Risiken nicht vollst¨andig quantifizierbar.68 3. Zielsetzungsdefekt. Zielgr¨oßen sind mehrdimensional ausgepr¨agt oder unbekannt. Die IT-Sicherheit steht im Zielkonflikt mit dem Unternehmungsziel Wirtschaftlichkeit. Die Wirkungs- und Bewertungsdefekte haben zur Folge, dass das Sicherheitsniveau nie mehr als eine grobe Sch¨atzung darstellen kann. 66 Vgl. Ashby 1956: 202ff; Werners/Klempt 2005a: 3f. 67 Vgl. Romeike/Finke 2003: 50ff. 68 Vgl. auch Vossbein/Vossbein/Henze 2000: 45. Insbesondere bei kardinalen Risikobewertungen kann es sich daher nur um eine Scheingenauigkeit handeln. Quantitative Analysen suggerieren exakte Werte. Dies kann dazu f¨ uhren, dass Verantwortliche den scheinbar korrekten Werten vertrauen und auf Basis dieser Informationen suboptimale Entscheidungen treffen. Vgl. Werners/Zimmermann 1989: 1744.

26

2 IT-Sicherheit in Unternehmungen

4. L¨osungsdefekt. Es existieren keine hinreichend effizienten und/oder exakten L¨osungsverfahren, sondern es findet eine Orientierung an Erfahrungswerten statt. Quantitative Ans¨atze zur Risikoanalyse werden in der Praxis daher nur selten genutzt. Qualitative Ans¨atze – die sich h¨aufig der Methode des Expertenwissens bedienen – sind ebenfalls nicht immer zuverl¨assig. Expertenmeinungen sind subjektive Aussagen, die auf Erfahrungen beruhen. Um die Datenqualit¨at zu steigern, sollten diese Aussagen detailliert diskutiert und begr¨ undet werden und Sch¨atzungen nachtr¨aglich auf ihre Plausibilit¨at u uft werden.69 Die Selektion und Analyse von Risiken in spezifischen Kontexten ¨berpr¨ durch Experten ist ebenfalls sowohl individuell als auch subjektiv.70 Dies f¨ uhrt einerseits dazu, dass die Wahrnehmung des Experten in die Risikobewertung mehr oder minder stark einfließt. Andererseits besteht die Gefahr, dass Risiken durch einen Experten bewusst dramatisiert oder konstruiert werden. Dieser Aspekt wird mit Fear, Uncertainty and Doubt (FUD) umschrieben; d.h., dass ein Berater oder eine Sicherheitsunternehmung eine Kommunikationsstrategie nutzt, die bei dem Kunden Furcht, Ungewissheit und Zweifel hervorrufen und dieser m¨oglicherweise dadurch eine suboptimale Entscheidung trifft. Die Risikowahrnehmung und die Risikobereitschaft oder auch Risikoneigung eines Entscheiders oder Analysten beeinflussen die Ergebnisse einer Risikoanalyse maßgeblich. Es ist daher darauf zu achten, dass eine Risikoanalyse dem Vier-Augen-Prinzip folgt, d.h. dass mindestens eine weitere Person die Analyse, Ergebnisse und Schlussfolgerungen u ¨ berpr¨ uft, um sog. blinde Flecken“ oder Fehleinsch¨atzungen identifizieren und korrigieren zu ” k¨onnen. Ein weiterer wesentlicher Punkt in der Gestaltung und Anwendung von Informationstechnologien ist die Verg¨anglichkeit von Erfahrungen.71 Durch die Schnelllebigkeit von Technologien und den damit einhergehenden kurzen Lebenszyklen existieren kaum Akteure, die mit den neuesten Technologien vertraut sind und ad¨aquate Erfahrungen vorweisen k¨onnen.72 Je l¨anger eine Unternehmung jedoch mit der Einf¨ uhrung von neuen Technologien wartet (um z.B. Planungsfehler zu minimieren), desto eher verliert sie einen potenziellen Wettbewerbsvorteil bzw. es stellt sich die Frage, ob sich der Einsatz einer veralteten“ Technologie sinnvoll oder rentabel gestalten l¨asst. Dieses Erfahrungsdilem” ma wirkt sich auch auf die IT-Sicherheit aus, da kein oder nur wenig Wissen zu den Risiken neuer Technologien vorhanden ist und ein solches bestenfalls aus anderen, ¨ahnlichen Technologien abgeleitet werden kann. Der Innovations- und Wettbewerbsdruck f¨ uhrt gerade in der Automobilindustrie dazu, dass IT-Projekte mit sehr kurzen Zeitvorgaben durchgef¨ uhrt werden, trotz der eventuell vorhandenen Sicherheitsrisiken. 69 Vgl. Gleißner 2001: 112. 70 Vgl. Japp 2000: 16ff. 71 Vgl. Paulus 2000: 383. 72 Vgl. Junginger/Balduin/Krcmar 2003: 357.

2.2 Risikomanagement in der IT-Sicherheit

27

In der praktischen Ausgestaltung wird mitunter darauf hingewiesen, dass mit steigenden Aufwandskosten f¨ ur den Angreifer die Wahrscheinlichkeit des Angriffs auf ein System sinkt. In dieser Sichtweise wird eine Rentabilit¨atsbetrachtung des Angriffs vorausgesetzt, in der der Angreifer maximal soviel Aufwand investiert, wie er als Ertrag erzielen kann. Diese Betrachtungsweise vernachl¨assigt, dass Kosten (z.B. in Form von Zeit) teilweise nur eine untergeordnete Rolle spielen. Die Motivation eines Angreifers kann z.B. auch in der Herausforderung, eine besonders gute Absicherung zu umgehen, bestehen. In der Rentabilit¨atsthese wird dem Angreifer ein rationales und/oder gewinnmaximierendes Kalk¨ ul unterstellt. Dieses Konzept ist auch deshalb fragw¨ urdig, weil es u ¨bersieht, dass der Angreifer bereits investieren muss, bevor er Aufwand und Ertrag absch¨atzen kann.73 Besonders evident ist die m¨ogliche negative Korrelation von Aufwand und (monet¨arem) Ertrag in Zusammenhang mit international bekannten Unternehmungen oder staatlichen Organisationen, bei denen ein Angriff auf IT-Systeme und/oder Infrastruktur politischen, religi¨osen oder pers¨onlichen (z.B. ver¨argerter Kunde) Charakter aufweist.

2.2.3 Kosten und Nutzen der IT-Sicherheit Kosten und Nutzen der IT-Sicherheit sind ein integraler Bestandteil des Risikomanagements, da eine Sicherheitsmaßnahme ¨okonomisch legitimiert sein muss.74 Der Bereich der IT-Sicherheit in Unternehmungen wird h¨aufig als reiner Kostenfaktor betrachtet, da dort im Allgemeinen keine Erl¨ose generiert werden.75 Es wurde jedoch dargestellt, dass die Beeintr¨achtigung von Vertraulichkeit, Integrit¨at und Verf¨ ugbarkeit zu (teilweise erheblichen) wirtschaftlichen Nachteilen f¨ uhren kann. Das Ziel einer Kosten-Nutzen-Analyse bez¨ uglich der IT-Sicherheit in Unternehmungen ist, die Kosten einer Maßnahme dem Nutzen gegen¨ uber zu stellen und somit die Effizienz einer Maßnahme ex-ante zu bewerten. Kosten sind in diesem Zusammenhang Aufwendungen f¨ ur z.B. IT-Sicherheitsmanagement, physikalischen Schutz des Rechenzentrums, Hard- und Software, externe Dienstleistungen, Administration, Benutzerschulungen und -trainings oder Einf¨ uhrung von Produkten bzw. Prozessen. Der Nutzen einer Sicherheitsmaßnahme 73 Ein zielgerichteter Angriff beginnt in der Regel mit der Beschaffung von Informationen u ¨ ber das Ziel, z.B. verwendete Hardware, Netzstruktur, Sicherungsmaßnahmen, verwendete Software und Betriebssysteme, Emailadressen, Telefonnummern, etc. 74 Im vorliegenden Abschnitt findet ausschließlich eine Betrachtung aus betriebswirtschaftlicher Perspektive statt. Gesamtwirtschaftliche Aspekte sind nicht Bestandteil der Untersuchung. 75 Der Einsatz von Informationstechnik wurde fr¨ uher ebenfalls als reiner Kostenfaktor angesehen. Erst in den letzten Jahren hat sich die Ansicht durchgesetzt, dass erst durch den Einsatz von IT bestimmte Prozesse erm¨oglicht werden, bzw. durch deren Unterst¨ utzung Kosten reduziert werden k¨onnen. Es bleibt zu hoffen, dass die Bedeutung der IT-Sicherheit einen ¨ ahnlichen Wandel erf¨ahrt.

28

2 IT-Sicherheit in Unternehmungen

l¨asst sich grob aufteilen in generische und spezielle Nutzenkomponenten. Generische Nutzenkomponenten sind in Maßnahmen wie z.B. der Erstellung einer IT-Sicherheitspolitik oder der Einrichtung eines IT-Sicherheitsmanagements enthalten. Diese Maßnahmen dienen der Etablierung und Durchsetzung von strategischen IT-Sicherheitszielen. Demgegen¨ uber weisen andere Maßnahmen spezielle Nutzenkomponenten auf, die gezielt bestimmte Schadenseintrittswahrscheinlichkeiten oder Schadensausmaße minimieren wie etwa die Nutzung einer Firewall, der Roll-out von Anti-Viren-Software oder der Einbau einer Gasl¨oschanlage in einem Rechenzentrum. Ganz allgemein besteht der Nutzen in der Verhinderung bzw. Minimierung von Sch¨aden. Der Nutzen der IT-Sicherheit l¨asst sich nur selten monet¨ar quantifizieren. Deshalb wird hier vorrangig auf den (qualitativen) Nutzen eingegangen, welcher in der Gew¨ahrleistung der Schutzziele der IT-Sicherheit besteht.76 Daraus lassen sich mehrere Kosten- und Nutzenkomponenten ableiten:77 • Reduzierung von Sch¨aden und deren Kosten: Die Schadenseintrittswahrscheinlichkeit wird durch IT-Sicherheit reduziert. Die Schadensh¨ohe kann ebenso verringert werden.78 • Imagegewinn: Eine Unternehmung kann den erreichten Grad der IT-Sicherheit an Kunden und Kooperationspartner kommunizieren, um ein h¨oheres Maß an Vertrauen zu erreichen.79 Insbesondere bei dem Einsatz von E-Business-Anwendungen ist dies von Bedeutung. • Begrenzung des Know-how-Verlustes: Die unfreiwillige Wissensdiffusion wird eingeschr¨ankt, was vor allem bei forschungs- und entwicklungsintensiven Branchen und Produkten von Bedeutung ist. • Verbesserte Wirtschaftlichkeit: Die Aufrechterhaltung der Verf¨ ugbarkeit kann Stillstandskosten reduzieren. Dar¨ uber hinaus kann z.B. der Einsatz eines Identity und Access Managements (IAM)80 nicht nur zu einem h¨oheren Sicherheitsniveau f¨ uhren, sondern auch Kosten durch effizientere Verwaltung und Administration senken. • Pr¨aziserer Informationsfluss: Durch die Einhaltung des Need-to-Know -Prinzips er76 Nutzen ist als abstraktes Konstrukt immer qualitativ. Auch quantifizierende Betrachtungen setzen im Regelfall qualifizierende Aspekte voraus. 77 Vgl. Vossbein/Vossbein/Henze 2000: 118f. 78 Als Beispiel kann die Verschl¨ usselung von Datenbanken dienen. Selbst wenn es einem Angreifer gelingt, die Datens¨atze nach einem Einbruch in ein System zu kopieren, kann er den Inhalt nicht nutzen. 79 Fluggesellschaften nutzen eine positive Unfallstatistik als Marketinginstrument gegen¨ uber Kunden. In jenem Bereich ist dies wirkungsvoller als bei der IT-Sicherheit, da der Schutz von Leib und Leben thematisiert wird. 80 Das Konzept des IAM wird ausf¨ uhrlich in Abschnitt 5.5.2 vorgestellt.

2.2 Risikomanagement in der IT-Sicherheit

29

halten die Mitarbeiter nur genau die Informationen, die sie zur Erf¨ ullung ihrer Aufgaben ben¨otigen.81 • Erschließung neuer Gesch¨aftsfelder : IT-Sicherheit erm¨oglicht neue Gesch¨aftsfelder und Absatzkan¨ale.82 • Verbesserung der Produktqualit¨at: Die Produktqualit¨at kann ggf. erh¨oht werden, wenn die Integrit¨at der Daten gew¨ahrleistet werden kann. Der Aufwand zur Gestaltung und Aufrechterhaltung der Sicherheit muss in Relation zu den vermiedenen Nachteilen gesetzt werden. Die Vor- und Nachteile lassen sich jedoch nicht saldieren, da sich Sch¨aden erstens nicht immer quantifizieren lassen und es sich zweitens dabei um Sch¨aden handelt, die eventuell auftreten w¨ urden, wenn keine Investitionen in die IT-Sicherheit get¨atigt worden w¨aren. Hier gilt das sogenannte SicherheitsParadoxon: Die Gew¨ahrleistung der Sicherheit eines Systems vermeidet Sch¨aden. Durch das Nichtauftreten von Sch¨aden erscheinen die Sicherheitsmaßnahmen als u ussig, ¨berfl¨ d.h. die Glaubw¨ urdigkeit der Sicherheit steigt mit der Zunahme von Sicherheitsverst¨oßen und Sch¨aden.83 Eine m¨oglichst realistische Kosten-Nutzen-Analyse ist f¨ ur Sicherheitsverantwortliche in Unternehmungen von großer Bedeutung, da angeforderte Projekt- und Budgetmittel fundiert gerechtfertigt werden k¨onnten. Ein Sicherheitsmanagement muss in der Regel einen Zielkonflikt aufl¨osen: Es gilt, mit m¨oglichst geringen Kosten ein angemessenes Sicherheitsniveau f¨ ur die Unternehmung zu realisieren.84 Die Kosten und der Nutzen der IT-Sicherheit k¨onnen als konkurrierende Ziele dargestellt werden, wie die Abb. 2.4 verdeutlicht.85 Betriebswirtschaftlich sind mehrere Aspekte bei der Einf¨ uhrung und Etablierung von IT-Sicherheit von Bedeutung. Dazu geh¨oren u.a. die Betriebsgr¨oße, die jeweilige Branche, die Anforderungen an das zu realisierende unternehmungsspezifische IT-Sicherheitsniveau und der aktuell erreichte Grad an IT-Sicherheit. Die Erfassung und Bewertung von betriebswirtschaftlichen Gr¨oßen wird im Allgemeinen u ¨ber die Mechanismen des moder81 Das Need-to-Know“-Prinzip l¨ asst sich mit so wenig Informationen wie m¨oglich und so viel Informa” tionen wie n¨otig umschreiben. Die Akteure haben nur zu den Informationen Zugang, die sie f¨ ur die Erf¨ ullung ihrer Aufgaben ben¨ otigen. Hierbei handelt es sich nicht um den Schutz der Mitarbeiter vor zu vielen Informationen (Information Overload ). Vielmehr steht die Berechtigung der Mitarbeiter, bestimmte Informationen einzusehen, im Fokus. 82 Beispielsweise die Nutzung von E-Businessl¨ osungen, wie der Vertrieb von G¨ utern u ¨ ber Plattformen im Internet. 83 Vgl. Vossbein/Vossbein/Henze 2000: 14. 84 Vgl. Werners/Klempt 2005: 7; Hoppe/Prieß 2003: 277. 85 Der Verlauf der Kurven ist von den spezifischen Gegebenheiten in einer Unternehmung (bspw. Schutzbedarf) abh¨angig.

30

2 IT-Sicherheit in Unternehmungen

Gesamtwert der zu schützenden Systemkomponenten

Kosten

Gesamtkosten

Optimales KostenNutzen-Verhältnis

Kosten durch Schäden

Kosten für Sicherheitsmaßnahmen Sicherheitsniveau

Abbildung 2.4: Kosten-Nutzen-Verh¨altnis von IT-Sicherheitsmaßnahmen (Hoppe/Prieß 2003: 280) nen Controllings durchgef¨ uhrt.86 Dabei l¨asst sich unterscheiden zwischen operativem und strategischem Controlling. Das strategische Controlling soll die IT-Strategie der Unternehmung mit ihren Zielen synchronisieren und dabei Transparenz u ¨ber Kosten und Leistungen herstellen sowie Priorit¨aten bei der Initiierung und Planung von IT-Projekten bilden, um die strategische Position der Unternehmung durch den optimierten Einsatz der IT zu verbessern.87 Ziel eines IT-Sicherheitscontrolling sind einerseits Accounting-orientierte Ziele und andererseits planungs- und steuerungsorientierte Ziele. Zu den Accounting-orientierten Zielen geh¨ort u.a. die Unterscheidung in Gemein- und Einzelkosten, die Erfassung und Zuordnung von Ist-Kosten und die Verteilung der Gemeinkosten und Zurechnung der direkt zurechnungsf¨ahigen Kosten. Zu den planungs- und steuerungsorientierten Zielen geh¨oren u.a. der Input f¨ ur das Berichtswesen und f¨ ur Kostenplanungen im Sinne der Plankostenrechnung, die Grundlagen zur Ermittlung von Differenzen und daraus abgeleiteten Korrekturmaßnahmen und die Grundlagen f¨ ur Kostenver88 gleichsrechnungen und Zeitvergleiche. Eine Analyse hat gezeigt, dass die Prozesskostenrechnung und Methoden der Investitionsrechnung zur Wirtschaftlichkeitsmessung nicht oder nur sehr eingeschr¨ankt nutzbar sind. Die Prozesskostenrechnung erscheint nicht geeignet, da die Generierung von IT-Sicherheit eher aus Kostenelementen in einem vereinten Basisprozess besteht, deren Isolierung problematisch ist. Die Wirtschaftlichkeitsmessung 86 Vgl. Vossbein/Vossbein/Henze 2000: 27. Vertiefend zum Begriff des Controllings siehe Horvath 2003; K¨ upper 2005. 87 Vgl. Tiemeyer 2005: 4f. Das operative Controlling wird hier nicht weiter betrachtet. 88 Vgl. Vossbein/Vossbein/Henze 2000: 40.

2.2 Risikomanagement in der IT-Sicherheit

31

durch Methoden der Investitionsrechnung ist nur zum Teil nutzbar. Dynamische Methoden wie die Kapitalwertmethode erscheinen nicht angemessen, da die mit starker Ungewissheit behafteten Daten nur eingeschr¨ankt f¨ ur eine zuverl¨assige Projektion auf kommende Perioden verwendbar sind. Bei den statistischen Methoden der Investitionsrechnung ist die Kostenvergleichsrechnung dazu geeignet, um z.B. eine Auswahlentscheidung zwischen verschiedenen Verfahren vorzunehmen.89 Der Themenkomplex der IT-Sicherheit weist in dem vorliegenden Zusammenhang einige Besonderheiten auf. So steht z.B. in der Investitionsrechnung einer Anschaffungsauszahlung u ¨blicherweise ein Nutzen als Strom von Einzahlungen gegen¨ uber. Der Nutzen der IT-Sicherheit besteht jedoch in der Verhinderung von Auszahlungen, welche durch Sch¨aden aus mangelnder IT-Sicherheit entstehen k¨onnten. Zudem ist die H¨ohe der potenziellen Sch¨aden ebenso unsicher wie die H¨aufigkeit des Schadensereignisses.90 Kosten werden hier nicht als Kosten im Sinne der Kosten- und Leistungsrechnung verstanden.91 Sie sind in den vorliegenden Zusammenh¨angen vielmehr als Kosten im Sinne eines ¨okonomischen Nachteils zu verstehen. Um diese Problematik zu illustrieren, werden im Folgenden einige der Probleme in der Erfassung der Kosten der IT-Sicherheit dargestellt. Haupts¨achlich basieren diese Komplikationen auf den methodischen Problemen der Identifikation und Analyse von Risiken, die in Abschnitt 2.2.2 vorgestellt wurden. So lassen sich z.B. vorrangig die Kosten tangibler G¨ uter erfassen, w¨ahrend die Kosten intangibler G¨ uter, z.B. Besch¨adigung der Markenreputation oder Verlust von geistigem Eigentum, nur sehr schwierig zu erfassen sind. Die Kosten zur Wiederbeschaffung einer Information aus der F&E lassen sich in vielen F¨allen nicht exakt beziffern. Problematisch ist im Themenkomplex IT-Sicherheit beispielsweise die Zurechenbarkeit der Kosten zu einer Kostenstelle. Voraussetzung ist, dass entweder eine institutionelle Kostenstelle oder eine funktionale Kostenstelle (mit einem sichtlich zurechenbaren Anteil) die Sicherheitsaufgaben wahrnimmt. Da Sicherheitsaufgaben in großen Unternehmungen in der Regel verteilt bearbeitet werden und einzelne Akteure diese neben ihren Hauptaufgaben wahrnehmen, sind die Kosten kaum quantifizierbar, erfassbar oder zurechenbar. Im Rahmen einer internen Kosten- und Leistungsverrechnung k¨onnen bestimmte Kosten den Kostenstellen zugerechnet werden.92 Darunter fallen u.a. Kosten, die f¨ ur alle ITAnwender anfallen, z.B. Lizenz- oder Produktkosten f¨ ur Anti-Viren-Software, Personal 89 Vgl. Vossbein/Vossbein/Henze 2000: 37ff. 90 Vgl. Nowey/Federrath/Klein et al. 2005: 16. 91 Vertiefend zur Kosten- und Leistungsrechnung vgl. Coenenberg 1999; Plinke/Rese 2002; Adams/Oligschl¨ager/Schenkelberg et al. 1993. 92 Vgl. Tiemeyer 2005: 40.

32

2 IT-Sicherheit in Unternehmungen

Firewalls, Smartcards etc.. Derartige Kosten fallen pro Benutzer an und k¨onnen auf die entsprechende Kostenstelle gebucht werden. Die Kostentr¨agerrechnung l¨asst sich dann gut anwenden, wenn Sicherheitsaufgaben als Sicherheitsprojekte definiert werden oder wenn die Aufgaben an Dritte ausgelagert wurden. Dies l¨asst sich jedoch nicht umfassend realisieren, da viele Aufgaben keinen Projektcharakter aufweisen.93 Daher sind die Kosten der IT-Sicherheit (wenn sie nicht einem einzelnen oder anteilig mehreren Kostentr¨agern zugerechnet werden k¨onnen) als Gemeinkosten aufzufassen. Die Methoden des internen Rechnungswesens und des Controllings sind prinzipiell dazu geeignet, die betriebswirtschaftlichen Gr¨oßen in der IT-Sicherheit zu erfassen. Jedoch ist die Bewertung im Sinne einer Kosten-Nutzen-Abw¨agung nur sehr schwierig bzw. unter Einschr¨ankungen m¨oglich. Die Kosten der IT-Sicherheit m¨ ussen den entsprechenden Leistungen (Nutzen) gegen¨ ubergestellt werden, um eine Aussage u ¨ber die Effizienz der geplanten oder get¨atigten Investitionen der IT-Sicherheit treffen zu k¨onnen. Die Leistung der IT-Sicherheit besteht haupts¨achlich in der Vereitelung von Sch¨aden, aus denen Kosten enstehen k¨onnen. Vossbein/Vossbein/Henze bezeichnen die hierin liegenden prognosti” schen Probleme [als] evident“.94 Die Kosten der IT-Sicherheit sind wesentlich einfacher zu erfassen, als ihr Nutzen. Da die Methoden des internen Rechnungswesens nicht ausreichend geeignet erscheinen, um die Kosten und den Nutzen von IT-Sicherheitsmaßnahmen zu analysieren und zu bewerten, wurden spezielle Ans¨atze geschaffen, die im folgenden Abschnitt vorgestellt werden.

2.2.3.1 Ausgew¨ ahlte Methoden f¨ ur eine Kosten-Nutzen-Analyse der IT-Sicherheit Zur monet¨aren Analyse im Bereich der Informationstechnik existieren mehrere Methoden. Dabei muss stark unterschieden werden zwischen den generischen kosten- und wertorientierten Ans¨atzen und jenen speziellen, die eine Kosten-Nutzen-Analyse der IT-Sicherheit gew¨ahrleisten sollen. Zu den kostenorientierten Ans¨atzen in der IT geh¨oren u.a. die Total Cost of Ownership (TCO) und die Real Cost of Ownership (RCO).95 Zu den wertorientierten Ans¨atzen 93 Vgl. Vossbein/Vossbein/Henze 2000: 35f. 94 Vgl. Vossbein/Vossbein/Henze 2000: 27. 95 Die Methode TCO wurde von der Gartner Group 1987 vorgestellt und dient der Berechnung von betrieblichen Gesamtkosten beim Einsatz von elektronischer Datenverarbeitung. Dies war der erste Ansatz, um derartige Kosten zu erfassen. Die RCO wurden von der Meta Group entwickelt, welche 2005 von der Gartner Group u ¨ bernommen wurde. Es ist daher unwahrscheinlich, dass dieser Ansatz parallel zur TCO-Methode weiterentwickelt wird.

2.2 Risikomanagement in der IT-Sicherheit

33

geh¨oren z.B. der Total Economic Impact (TEI), Rapid Economic Justification (REJ) und der Total Value of Opportunity (TVO). Die kostenorientierten Ans¨atze ber¨ ucksichtigen nicht explizit die Kosten der IT-Sicherheit f¨ ur ein Projekt, ein Produkt oder einen Prozess. Die wertorientierten Ans¨atze stellen den Wert eines Assets in den Mittelpunkt der Betrachtung und ignorieren dabei ein wesentliches Merkmal der Risikobewertung: Ohne das Wissen um die Wahrscheinlichkeit eines Ereigniseintrittes und der daraus folgenden ¨okonomischen Sch¨aden, l¨asst sich die Effizienz einer Gegenmaßnahme nicht belegen. Die genannten Verfahren sind daher nicht dazu geeignet, die Kosten und den Nutzen der IT-Sicherheit zu analysieren. Eine Risikobewertung ist die Grundlage einer Kosten-Nutzen-Analyse. Im Rahmen des Risikobewertungsprozesses gilt es, die Risiken zu identifizieren, zu charakterisieren und – vor allem – zu verstehen. Dabei werden Pr¨aferenzen evaluiert, Konsequenzen von unerw¨ unschten Ereignissen analysiert, die Wahrscheinlichkeit solcher Ereignisse vorausberechnet und der Einfluss von verschiedenen Gegenmaßnahmen gepr¨ uft.96 Es lassen sich drei Generationen von Ans¨atzen f¨ ur eine Kosten-Nutzen-Analyse der IT-Sicherheit unterscheiden. Erstens die Modelle, die im Wesentlichen auf dem Konzept der Annual Loss Expectancy (ALE) basieren. Zweitens die nachfolgenden Modelle, die als Reaktion auf die Unzul¨anglichkeiten der ersten Generation entstanden sind. Drittens die aktuellen Modelle, die mit neuen Ans¨atzen eine Kosten-Nutzen-Analyse erm¨oglichen wollen.97 Das Modell der ALE hat den betr¨achtlichen Nachteil, dass auf Basis des Ergebnisses nicht zwischen (a) h¨aufigen Ereignissen mit geringen Sch¨aden und (b) seltenen Ereignissen mit hohen Sch¨aden unterschieden werden kann.98 W¨ahrend (a) akzeptabel sein kann, ist (b) in der Regel nicht tolerierbar. In den 1980er Jahren wurde ALE in einer Reihe von Workshops der NIST weiterentwickelt. Drei fundamentale Unzul¨anglichkeiten sind verantwortlich f¨ ur das Scheitern des ALE-Konzeptes und seiner darauf basierenden Nachfolger: 1. Die verwendete Methode ist ¨außerst aufw¨andig. Ein derartiges Modell muss eine Balance zwischen Simplizit¨at und realit¨atsgetreuer Abbildung finden. Das Modell der ALE ist in seiner sp¨ateren Auspr¨agung sehr detailliert angelegt, so dass die Anzahl von untersuchten Szenarien mit jedem neuen Element beinahe exponentiell ansteigt. Die hohe Komplexit¨at der Methode erweist sich in der Praxis als nicht beherrschbar. 2. Der vollst¨andige Determinismus des Modells nimmt an, dass alle Elemente und Wahrscheinlichkeiten bekannt sind. Variablen bekommen feste Werte zugewiesen 96 Vgl. Soo Hoo 2000: 3. 97 Vgl. auch im Folgenden Soo Hoo 2000. 98 Das Konzept der ALE wurde in Abschnitt 2.2.1 vorgestellt.

34

2 IT-Sicherheit in Unternehmungen

an Stelle von Wertebereichen oder Intervallen. Damit ignoriert das Modell reale Unsicherheiten. 3. Die Resultate eines Modells sind sehr stark abh¨angig von der Genauigkeit und Aussagekraft der Informationen, mit denen es konfrontiert wird. Die empirische Datenlage (Sch¨aden, H¨aufigkeiten, Wirksamkeit von Maßnahmen etc.) ist in den meisten Dimensionen der IT-Sicherheit nicht ausreichend, um valide Aussagen zu erstellen. Die Modelle der zweiten Generation begegnen der Komplexit¨at des ALE-Modells mit einer starken Simplifizierung. Unsicherheiten werden teilweise nicht betrachtet oder es werden rein qualitative Analysen durchgef¨ uhrt. Unter den Ans¨atzen der zweiten Generation finden sich z.B. das Integrated Business Risk Management Framework, rein wertorientierte Methoden, die sich exklusiv an den zu sch¨ utzenden Werten orientieren, Szenario-Analysen sowie Best-Practice-Ans¨atze. Diese Modelle weisen nicht die F¨ahigkeit auf, Sicherheitsmaßnahmen nachhaltig ¨okonomisch zu bewerten, deren Effizienz zu kontrollieren oder zuk¨ unftige Trends vorherzusagen und sind bestenfalls als Zwischenl¨osung geeignet.99 Drei treibende Kr¨afte werden die Motivation f¨ ur neue quantitative Ans¨atze schaffen: Bed¨ urfnisse von Versicherungsunternehmungen, Haftpflichtrisiken und Wettbewerb am Markt. Insbesondere der Wettbewerb am Markt vermag die Entwicklung neuer quantitativer Ans¨atze zu forcieren, da Kosteneffizienz den Unternehmungen zu Wettbewerbsvorteilen verhelfen kann. Die Modelle der dritten Generation sind von unterschiedlicher Komplexit¨at gepr¨agt. Diese Ans¨atze versuchen anhand der Verkn¨ upfung von Methoden (Soo Hoo), spieltheoretischen Grundlagen (Cavusoglu/Mishra/Raghunathan) oder auf Basis von Verteilungsfunktionen (Gordon/Loeb) das Kosten-Nutzen-Verh¨altnis der Sicherheitsinvestitionen zu bestimmen.100 Sie eignen sich nur bedingt f¨ ur eine Berechnung des Kosten-Nutzen-Verh¨altnisses, da sie z.T. sehr umfangreich sind und/oder nicht die Interdependenzen von Sicherheitsl¨osungen ber¨ ucksichtigen, was z.B. beim Ansatz von SooHoo der Fall ist.101 Keines dieser neuen Modelle hat in Wissenschaft oder Praxis eine besondere Bedeutung erlangt. Lediglich ein neuerer Ansatz hat eine gr¨oßere Verbreitung gefunden: der Return on Se99 Vgl. Nowey/Federrath/Klein et al. 2005: 17f.; Soo Hoo 2000: 9ff. Aus diesem Grund werden die Ans¨atze nicht weiter ausgef¨ uhrt. Soo Hoo sieht die Verbreitung von Best-Practice-Ans¨atzen (wie der ISO 17799) unter anderem in einer juristischen Dimension: Insbesondere in den USA kann bei einem Gerichtsverfahren (z.B. Haftung wegen fehlender Sicherheitsmaßnahmen) darauf hingewiesen werden, dass die Unternehmung ein allgemein anerkanntes Verfahren zur Sicherung der IT-Infrastruktur angewendet hat. Dadurch lassen sich gesetzliche oder vertragliche Schadensersatzanspr¨ uche h¨aufig mindern oder abwenden. 100 Vgl. Soo Hoo 2000: 15ff.; Cavusoglu/Mishra/Raghunathan 2004; Gordon/Loeb 2002. 101 Die Modelle der dritten Generation werden hier nicht weiter dargestellt, da sie f¨ ur den Einsatz in den zu untersuchenden komplexen Zusammenh¨ angen ungeeignet erscheinen.

2.2 Risikomanagement in der IT-Sicherheit

35

curity Investment (ROSI). Aufgrund seiner Verbreitung wird dieser Ansatz im Folgenden genauer betrachtet. ROSI soll eine Rentabilit¨atsbetrachtung in Anlehnung an das Konzept des Return on Investment (ROI) darstellen.102 Das urspr¨ ungliche Konzept des Return on Security Investment wurde an der Universit¨at von Idaho entwickelt und erlangte durch einen Artikel103 im CIO Magazine im Jahr 2002 eine gr¨oßere Aufmerksamkeit. Im Wesentlichen handelt es sich dabei um eine Erweiterung des ALE-Modells (siehe Gleichung 2.4). (R − E) + T = ALE

und

R − ALE = ROSI

(2.4)

wobei: R = J¨ahrliche Kosten zur Beseitigung eines Angriffs E = Reduzierung der Schadenskosten durch gestoppte Angriffe T = H¨ohe der entsprechenden Sicherheitsinvestition(en) ALE = J¨ahrliche Verlusterwartung durch verbliebene Sch¨aden ROSI = Ertrag der Sicherheitsinvestition(en)

Am Beispiel eines Intrusion Detection Systems (IDS) hatte die Forschergruppe der Universit¨at Idaho ihr Modell demonstriert.104 Angenommen wurde ein Schaden (ALE) ohne IDS mit einer Schadensh¨aufigkeit von einmal in zwei Jahren in H¨ohe von $200.000. Ein IDS, welches den Schaden mit 85%iger Wahrscheinlichkeit verhindern kann (Reduzierung des Schadens auf $15.000 pro Jahr), kostet j¨ahrlich $40.000. Damit h¨atte die Unternehmung ihre j¨ahrlichen Sch¨aden – nach Abzug der Investitions-/Betriebskosten und den verbleibenden Sch¨aden – um $45.000 reduziert (siehe Tab. 2.2). $200.000 · $200.000 · $40.000

1 2 1 2

· (1 − 0, 85)

ALE ohne IDS ALE mit IDS J¨ahrliche Kosten des IDS ROSI

$100.000 - $15.000 - $40.000 $45.000

Tabelle 2.2: Beispiel f¨ ur eine ROSI-Kalkulation 102 Im Grunde handelt es sich nicht um eine Rentabilit¨ atsbetrachtung wie dem ROI, da es sich bei dem ROI um eine Kennzahl (Quotient aus Periodengewinn und Kaptialeinsatz) handelt und ROSI eine Nutzendarstellung u ahrlichen Verlusterwartung von den j¨ahrlichen Kosten ¨ber die Substraktion der j¨ zur Beseitigung eines Angriffs erreichen m¨ ochte. 103 Vgl. Berinato 2002. 104 Vgl. Berinato 2002.

36

2 IT-Sicherheit in Unternehmungen

Als Erweiterung des ALE-Modells unterliegt ROSI denselben Restriktionen wie das ALEModell selbst. ROSI verdichtet lediglich vorangegangene quantitative Betrachtungen, in denen Wahrscheinlichkeitsverteilungen gr¨oßtenteils ignoriert werden und vorausgesetzt wird, dass die relevanten Einflussfaktoren monet¨ar quantifiziert werden k¨onnen.105 Es wird nicht ber¨ ucksichtigt, wie sich die Schadensh¨aufigkeit oder das potenzielle Schadensausmaß pro Schaden in den kommenden Perioden entwickeln k¨onnte. So kann z.B. f¨ ur eine Firewall die Annahme gelten, dass sie eine bestimmte Anzahl und gewisse Arten von Angriffen unterbinden kann. Es l¨asst sich jedoch beobachten, dass die breite Einf¨ uhrung neuer Sicherheitsmaßnahmen im Allgemeinen neue Angriffsarten hervorbringt, die die neuen Abwehrtechniken teilweise kompromittieren k¨onnen. Dies kann die Auspr¨agungen der Variablen im ROSI-Konzept erheblich ver¨andern. Die f¨ unf Parameter der Risikoanalyse (Wert, Gef¨ahrdung, Schwachstelle, Schaden und Maßnahme) sind zum Teil voneinander abh¨angig und in der Regel dynamisch. Die Faktoren daf¨ ur k¨onnen vielf¨altig sein: Konso¨ lidierung von Systemen, Anderungen in der Netzwerkinfrastruktur, Zuwachs an Nutzern oder Kunden, ver¨anderte gesetzliche Anforderungen, neue Angriffsmethoden, ver¨anderte Angreiferprofile und -motive, Wertberichtigungen bei den zu sch¨ utzenden Werten und vieles mehr. Als weiterer unber¨ ucksichtigter Einflussfaktor kann die Tatsache gelten, dass (insbesondere große) Unternehmungen in der Regel nicht nur eine Sicherheitsmaßnahme f¨ ur eine Gef¨ahrdung implementiert haben, sondern Sicherheit durch mehrstufige Maßnahmen erzielt wird. Demnach muss die Schadensreduktion auf die jeweiligen (interdependenten) Maßnahmen verteilt werden. Eine eindeutige Zuordnung von Kosten und Nutzen wird hierdurch erschwert. Die Kernaussage von ROSI ist, dass eine Investition in eine IT-Sicherheitsmaßnahmen dann lohnenswert ist, wenn die Sicherheitsmaßnahme den zu erwartenden Schaden um mindestens die Kosten f¨ ur die Investition reduziert. Da die Schadensreduktion eine dynamische Gr¨oße ist, l¨asst sie sich bestenfalls ex-post nach der Einf¨ uhrung der Maßnahme bestimmen, womit ROSI als Prognoseinstrument nur sehr bedingt geeignet erscheint. 2.2.3.2 Fazit Wie in den Abschnitten 2.2.1 und 2.2.2 bereits dargestellt wurde, ist eine monet¨are Erfassung eines Risikos um so ungenauer, je komplexer der Gegenstand des Risikos ist und je weniger Erfahrungswerte vorliegen. Eine pr¨azise Erfassung von Kosten und Nutzen der IT-Sicherheit ist nur selten m¨oglich, da es sich um eine Messung vermiedener Kosten handelt: Sicherheit produziert keine Erl¨ose, sondern minimiert Verluste. Im Qualit¨atsmanagement l¨asst sich z.B. messen, ob eine Maßnahme die Dauer der Nachbearbeitung eines Werksst¨ uckes minimiert oder die Anzahl der Ausschussproduktion re105 Vgl. Nowey/Federrath/Klein et al. 2005: 21.

2.2 Risikomanagement in der IT-Sicherheit

37

duziert.106 Da es sich bei der Produktion von Werkst¨ ucken in der Regel um konforme und repetitive T¨atigkeiten mit nahezu identischen Arbeitsabl¨aufen und quantitativ gemessenen Erfahrungen handelt, ist die Erwartungssicherheit bei der Gestaltung und Umsetzung einer Maßnahme wesentlich h¨oher als im Themenkomplex IT-Sicherheit. Kooperationen mit Dritten verlangen z.B. ein h¨oheres Maß an adaptiven F¨ahigkeiten, da h¨aufiger unbekannte Situationen auftreten k¨onnen, die individuelles Handeln erfordern. Der stetige Fortschritt der Technologie, steigende Komplexit¨at, Interdependenzen von Software und die Weiterentwicklung der Angriffstechniken tragen maßgeblich dazu bei, dass die Effizienz von Schutzmaßnahmen im Risikomanagement nicht durch eine quantitativ erhobene Datenbasis unterst¨ utzt werden kann. Es ist mit den oben genannten Modellen und Methoden nicht m¨oglich, unbekannte Risiken zu adressieren, die erstmalig in der n¨achsten Betrachtungsperiode auftauchen k¨onnten und deshalb noch gar nicht publik sind. Dagegen k¨onnen z.B. die Anbieter von Kraftfahrzeugversicherungen auf valide Erfahrungs- und Erwartungswerte hinsichtlich der Schadensh¨ohe und -eintrittswahrscheinlichkeit (beispielsweise in Abh¨angigkeit von dem Fahrzeugtyp und dem Alter des Fahrers) zur¨ uckgreifen, wodurch die Risiken kalkulierbar werden.107 Es ist h¨ochst unwahrscheinlich, dass vollst¨andig neue Unfallformen die Bilanzen der Kraftfahrzeugversicherer u ¨berm¨aßig belasten werden. Die meisten Unternehmungen sind hingegen nicht dazu bereit, IT-Sicherheitsvorf¨alle zu ver¨offentlichen. Die daraus entstehende insuffiziente Datenlage f¨ uhrt zu einer Erwartungsunsicherheit, da Risiken nicht empirisch belegt werden k¨onnen. Das Kerngesch¨aft von Versicherungsunternehmungen ist das Risikomanagement. Der betriebswirtschaftliche Gewinn der Versicherer ist haupts¨achlich davon abh¨angig, ob die ex-ante Risikokalkulation mit den ex-post eintreffenden Ereignissen im Wesentlichen u ¨bereinstimmt. Versicherungen gegen IT-Sicherheitsrisiken aus Angriffen sind nahezu nicht existent – dies kann als ein Indiz f¨ ur die Unberechenbarkeit dieser Risiken herangezogen werden.108 Risiken weisen stets eine Unsicherheit auf, die sich durch die Unkenntnis zuk¨ unftiger Entwicklungen begr¨ undet. Dies ist auch bei vielen Risiken im Themenkomplex IT-Sicherheit der Fall. Die Messung des Nutzens und damit der Effektivit¨at von ITSicherheitsmaßnahmen ist nur dann m¨oglich, wenn die Maßnahmen reaktiv und nicht pr¨aventiv eingef¨ uhrt worden sind. Der Verlust in einem Betrachtungszeitraum vor der Einf¨ uhrung der Maßnahme kann den nicht eingetretenen Sch¨aden nach der Maßnahmen106 Teilweise ist eine derartige Analyse erst ex-post m¨ oglich. 107 Zus¨atzlich ist eine Vielzahl von Informationen verf¨ ugbar, wie z.B. Anzahl der Unf¨alle, Anzahl der Diebst¨ahle, Neuwert des Fahrzeugs, Zeitwert des Fahrzeugs, etc. Die wenigsten Unternehmungen k¨onnten den Wiederbeschaffungswert einer Information beziffern, da kaum Vergleichswerte vorliegen bzw. ein Vergleich h¨aufig nicht m¨ oglich ist. Dies erschwert eine Harmonisierung der Bewertung. 108 Es existieren in erster Linie sog. Elektronikversicherungen, die die elektronischen Ger¨ate des Versiche¨ rungsnehmers gegen gel¨ aufige Risiken, z.B. Wasser- oder Uberspannungssch¨ aden, versichern. Zu den praktischen Problemen bei der Versicherung von IT-Risiken vgl. Reinhardt 2002.

38

2 IT-Sicherheit in Unternehmungen

realisierung gegen¨ ubergestellt werden. Mit anderen Worten: Es k¨onnen nur vermiedene Sch¨aden gemessen werden, wenn diese vorher aufgetreten (und gemessen worden) sind. Die meisten vorgestellten Ans¨atze zur Berechnung von Kosten-Nutzen-Relationen sind monokausal, d.h. ein Risiko wird durch eine Maßnahme beseitigt. In der Praxis werden in der Regel Maßnahmenb¨ undel angewandt, die in Summe potenzielle Sch¨aden vermeiden sollen. Mehrstufige Sicherheitsmaßnahmen sind in der Regel holistisch zu betrachten, d.h. dass der Gesamtschutz durch mehrere einzelne Maßnahmen h¨oher ist als der Schutz durch die Summe der Einzelmaßnahmen. Kosten-Nutzen-Analysen, die diese Tatsachen nicht ber¨ ucksichtigen, sind daher wenig geeignet.109 Ziel der IT-Sicherheit in Unternehmungen ist die Verhinderung aller erfolgreichen Angriffe, und nicht die Reduktion der erfolgreichen Angriffe um einen gewissen Prozentsatz.110 Dies bezieht sich auf die Tatsache, dass Sch¨aden in Bezug auf die Anzahl der Angriffe in aller Regel keinen linearen Verlauf aufweisen; d.h., dass in einer Unternehmung beispielsweise bei 100 erfolgreichen Angriffen mit einer Schadenssumme von eine Million Euro 99 Angriffe einen Gesamtschaden von 50.000 Euro und ein Angriff einen Schaden von 950.000 Euro erzeugen k¨onnen. Die Elimination der 99 Angriffe mit einem vergleichsweise geringen Gesamtschaden w¨are in einem derartigen Fall als nachrangig zu betrachten. Die Schwierigkeit, eine Rentabilit¨atsbetrachtung f¨ ur IT-Sicherheitsmaßnahmen durchzuf¨ uhren, l¨asst sich am Beispiel eines Feuerl¨oschers oder eines T¨ urschlosses illustrieren. Kaum eine Unternehmung w¨ urde f¨ ur solche Maßnahmen eine Rentabilit¨atsanalyse fordern. Auch Brandversicherungen werden nicht aus Rentabilit¨ats¨ uberlegungen, sondern aus Gr¨ unden der Vorsorge und Risikoreduktion abgeschlossen.111 Heiser kommentiert den ROSI-Ansatz folgendermaßen: The premise behind ROSI is that spending on security increases productivity. ” Sadly, it doesn’t. Firewalls don’t increase network bandwidth. VPNs don’t increase throughput. Changing passwords every 60 days doesn’t make end users more efficient. Security is overhead, just like the automatic fire sprinklers and air conditioning in the server room. Face it: It’s a necessary evil.“ 112 Die Rechtfertigung von Investitionen mittels eines quantifizierbaren Zahlenwerks ist dennoch f¨ ur viele Sicherheitsverantwortliche ein attraktiver Ansatz, um Budgets zu rechtfer109 Bestimmte Investitionen weisen einen Sicherheitsanteil auf, der als solcher gar nicht Bestandteil der Investitionsentscheidung war, wie z.B. der Kauf eines Switches, welcher das Extensible Authentication Protocol (EAP) 802.1x unterst¨ utzt. Wenn diese Technik genutzt wird, dann kann dadurch die Sicherheit verbessert werden. Dieser Sicherheitsanteil an der Gesamtinvestition ist sehr schwierig monet¨ar zu erfassen bzw. zu bewerten. 110 Vgl. Dynes/Brechb¨ uhl/Johnson 2005. 111 Vgl. Schmeh/Uebelacker 2004. 112 Heiser 2002.

2.2 Risikomanagement in der IT-Sicherheit

39

tigen. Modelle werden maßgeblich eingesetzt, um Zusammenh¨ange (abstrahiert) aufzuzeigen und zuk¨ unftige Entwicklungen zu prognostizieren. Keines der betrachteten Modelle ist in der Lage, dies ohne einen immensen Aufwand zu gew¨ahrleisten. Insbesondere Kollateralsch¨aden (z.B. Imageverlust oder Opportunit¨atskosten) k¨onnen kaum erfasst werden. Ein Modell wie ROSI suggeriert jedoch diese M¨oglichkeiten, obwohl im Kern nicht Rentabilit¨at, sondern vermiedene Kosten betrachtet werden. Zudem wird nicht ber¨ ucksichtigt, dass IT-Sicherheit bestimmte Gesch¨aftst¨atigkeiten erst erm¨oglicht; d.h., dass die IT-basierte Gesch¨aftst¨atigkeit zwischen Unternehmungen oder zwischen Unternehmungen und Kunden ohne IT-Sicherheitsmaßnahmen evtl. m¨oglich w¨are, jedoch nur eine geringe Akzeptanz finden w¨ urde. Ein IT-Sicherheitscontrolling ist nur dann sinnvoll, wenn die zugrundeliegenden Daten vollst¨andig und vor allem valide sind. Dies ist in der Regel nur mit einem hohen initialen Aufwand erreichbar. Falls Kernprozesse existieren, sollten deren Daten vorrangig erhoben und u uft werden. Die Datenlage in einer Unternehmung zu IT-Sicherheitsvorf¨allen ¨ berpr¨ kann durch mehrere Maßnahmen verbessert werden: • Einrichtung eines Honeypots oder Honeynets.113 • Definierte Prozesse f¨ ur die Meldung von Sicherheitsvorf¨allen an eine zentrale Stelle und organisatorische Richtlinien, die die Mitarbeiter zu einer Meldung verpflichten. • Einrichtung eines Intrusion Detection Systems (IDS), sowohl host- als auch netzbasiert. Einbruchs- oder Angriffsversuche sollten an einen zentralen Loggingserver gesandt werden, wo die Meldungen konsolidert und aufbereitet werden. Obwohl die Erfassung der Daten den statistischen Grunds¨atzen der großen Zahlen unterliegt (d.h., dass eine Vielzahl von F¨allen notwendig ist, um eine valide Aussage treffen zu k¨onnen), kann die Auswertung dieser Daten einen Aufschluss u ¨ber das bisher erreichte Sicherheitsniveau und zu treffende Maßnahmen geben. Zumindest die Wirksamkeit der Summe der Maßnahmen ließe sich dar¨ uber ann¨ahernd bestimmen. Die ex-post Analyse von IT-Sicherheitsmaßnahmen l¨asst sich mit vorhandenen Ans¨atzen durchf¨ uhren. Wichtiger erscheint jedoch eine Analyse, die Investitionen in die IT-Sicherheit zur Durchsetzung der Schutzziele hinsichtlich ihres Nutzens ex-ante bewerten kann. Zur Zeit existieren keine Ans¨atze, die eine derartige aussagekr¨aftige, realistische Analysemethode als Prognoseinstrument anbieten k¨onnen. 113 Honeypots sind IT-Systeme, die gezielt in ein Netzwerk gestellt und mit vermeintlich interessanten (gef¨alschten) Informationen versehen werden, um Angreifer zu k¨odern. F¨ ur den Angreifer sieht das System normal aus, beinhaltet aber erweiterte Loggingm¨ oglichkeiten, mit denen sich das Vorgehen des Angreifers verfolgen l¨ asst. Mit diesen Erkenntnissen entsteht eine Grundlage f¨ ur den weiteren Schutz der anderen Systeme. Vgl. Spitzner 2002; Honeynet Project 2004.

40

2 IT-Sicherheit in Unternehmungen

Die aktuelle Situation zur Analyse der Kosten und des Nutzens von IT-Sicherheit ist unbefriedigend. Wissenschaft und Praxis haben derzeit noch keine zufriedenstellenden L¨osungsans¨atze entwickelt. Es bleibt zu hoffen, dass in der Zukunft praxisgerechte Ans¨atze geschaffen werden, die es erm¨oglichen, eine Kosten-Nutzen-Analyse im Themenkomplex der IT-Sicherheit durchzuf¨ uhren.

2.2.4 Risikomanagement und Reduktion von Risiken Risikoidentifikation, -analyse, -steuerung und -¨ uberwachung sind Bestandteile einer u ¨ bergeordneten Vorgehensweise, dem Risikomanagement. Der Ursprung des Risikomanagements liegt in dem Bem¨ uhen US-amerikanischer Unternehmungen, die gezielt versuchten, Versicherungspr¨amien zu reduzieren. Dies m¨ undete in die Forderung der Versicherungsunternehmungen nach unternehmungsinternen Sicherheitsmaßnahmen zur Reduzierung des Risikos. In den 1970er Jahren fand das Konzept des Risikomanagements auch in Europa Beachtung.114 Risikomanagement wird vor allem im Zusammenhang mit der Erzeugung von Energie mittels nuklearer Stoffe ( Kernkraftwerke“) betrieben, wobei dort h¨aufig mit ” Fehler- und Ereignisb¨aumen gearbeitet wird, um alle Eventualit¨aten abzudecken.115 Das Risikomanagement kann verschiedene Einzelrisiken isoliert oder auch in Kombination oder Summe betrachten (siehe Abb. 2.5).

114 Vgl. Wolf/Runzheimer 1999: 19. 115 Vgl. Soo Hoo 2000: 3.

2.2 Risikomanagement in der IT-Sicherheit

41

en ik is sr ng ru en ik äh is W sr ur en nk ik tie ris s Ak ng n ru ke de si lri än al ns sf Zi en Au s ik Ri he en is c ik lit ris Po kt ar n M ke isi tsr ch en Re ik ris en on n rs e ik Pe ris n ch ge Sa un

Li

qu

id

Er

itä

fol

ts

qu

Li

rk wi gs

ri

si

ke

n

n

ge

un

irk

tsw

tä

idi

Leistungswirtschaftliche Risiken Finanzwirtschaftliche Risiken

Gesamtrisiko der Unternehmung

Abbildung 2.5: Dreidimensionale Risikokategorisierung (vgl. Kremers 2002: 55)

Der Bereich der Risikoidentifikation und -analyse sowie deren Probleme wurde in den vorhergehenden Abschnitten behandelt. Die Risikosteuerung hat zur Aufgabe, Gegenmaßnahmen zu Risiken zu planen und umzusetzen. Zu diesem Zweck muss eine Risikopriorit¨atenliste vorhanden sein, die die Notwendigkeit zur Bew¨altigung von Risiken in einer Rangliste ordnet. Im Prozessabschnitt der Risikosteuerung m¨ ussen entsprechende Zeitpl¨ane erstellt, Verantwortlichkeiten zugewiesen und finanzielle Mittel zugeteilt werden. Die Risiko¨ uberwachung und -verfolgung dokumentiert den Fortschritt und etwaige Komplikationen in der Implementierung der Sicherheitsmaßnahmen sowie Ver¨anderungen in der Risikolage. Die Thematik Risikomanagement l¨asst sich anhand einer Alltagssituation darstellen (siehe Abb. 2.6). Mittlerweile ist die Forderung nach einem Risikomanagement in deutschen Unternehmungen auch gesetzlich verankert, u.a. durch das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG). Die Begr¨ undung f¨ ur die Forderung nach einem ITRisikomanagement ergibt sich aus der Abh¨angigkeit der Unternehmungsprozesse von ITAnwendungen und IT-Systemen. Die Funktionalit¨at der Systeme und die Vertraulichkeit, Integrit¨at und Verf¨ ugbarkeit der elektronisch verarbeiteten Informationen k¨onnen kritisch f¨ ur den Unternehmungserfolg sein. Fehlfunktionen oder Ausf¨alle k¨onnen immense materielle und immaterielle Sch¨aden verursachen.116 Aus dem umfangreichen Themengebiet 116 Vgl. Rauschen/Disterer 2004: 19.

42

2 IT-Sicherheit in Unternehmungen

Prozess: Risikomanagement:

¨ Das Uberqueren einer Straße. Analyse der potenziellen Gefahren und Alternativen. ¨ • Die direkte Uberquerung der Straße verschafft einen Zeitgewinn, aber der Akteur kann m¨ oglicherweise zu Schaden kommen. • Die Nutzung einer Ampel ist sicherer, f¨ uhrt aber zu Zeitverlusten.

Sicherheitsregeln:

Regeln aus Erfahrung. • An der Straße die aktuelle Situation erfassen und ggf. die Straße u ¨berqueren. • Bei stark befahrener Straße die Ampel nutzen und auf das gr¨ une Leuchtzeichen warten.

Business Continuity Management:

Sicherstellen, dass die Straße u ¨berquert werden kann (z.B. durch mobile Ampeln als Notfallkonzept, Zebrastreifen, etc.).

Abbildung 2.6: Beispiel des Risikomanagements anhand einer Alltagssituation des Risikomanagements wird hier ausschließlich das IT-Risikomanagement betrachtet. Zu den Risikokategorien im IT-Risikomanagement geh¨oren:117 • Risiken aus dem Management der IT, • organisatorische Risiken, • technische Risiken, • Sicherheitsrisiken, • projektbezogene Risiken, • kosten- und leistungsbezogene Risiken, • infrastrukturelle Risiken und • anwendungs- und prozessbezogene Risiken. ¨ Ahnlich wie in der Risikoanalyse existieren verschiedene Modelle und Methoden zum Management von IT-Risiken. Rauschen/Disterer haben acht verschiedene Methoden des IT-Risikomanagements unter Ber¨ ucksichtigung verschiedener Anwendungsbereiche miteinander verglichen (vgl. Tab. 2.3). Daraus geht hervor, dass es nicht den einen allumfassenden Ansatz f¨ ur das ITRisikomanagement gibt. Vielmehr werden ein eklektizistischer Ansatz oder mehrere Ans¨atze in Kombination zur Bew¨altigung der Risiken in Unternehmungen ben¨otigt. Dies wiederum bewirkt, dass die Auswahl der Datenbasis zwischen den eingesetzten Methoden 117 Vgl. Romeike 2000: 604; KPMG 1998: 38ff.

2.2 Risikomanagement in der IT-Sicherheit

Risikoidentifikation/ -analyse ❂

Control Objectives for Information and Related Technology (CobiT) IT-Grundschutzhandbuch (GSHB) ❍ Common Criteria for Information Technology Se❍ curity Evaluation (CC) Code of Practice for Information Security Mana❍ gement (CoP) Richtlinie zur Informationssicherheit in der ❍ B¨ urokommunikation (Richtlinie 5002) MARION (M´ ethode d’Analyse de Risques Infor● matiques et d’Optimisation par Niveau) Information Risk Management von KPMG ● Risk Review von PWC ● ● anwendbar ❂ bedingt anwendbar

43

IT-Pr¨ ufung

●

Sicherheitskonzept ❍

Sicherheitshandbuch ❍

●

❍ ❍

● ❂

● ❍

❍ ❍

❂

●

❍

❂

❍

●

●

❍

❍

●

❍

❍

❍ ❍

❍ ❍

● ●

❍ ❍ ❍ nicht anwendbar

Healthcheck

Tabelle 2.3: Anwendungsbereiche verschiedener Methoden im IT-Risikomanagement (vgl. Rauschen/Disterer 2004: 31) abgeglichen und u uft werden muss, damit an den Schnittstellen zwischen den einzel¨ berpr¨ nen Verfahren keine Informationen verloren gehen bzw. ihren Aussagegehalt einb¨ ußen. IT-Risikomanagement kann als IT-Risikoprozessmanagement realisiert werden. Beispielsweise kann sich der Ausschnitt zum Gesamtlebenszyklus von IT-Gestaltungsprozessen (Plan, Build, Run) folgendermaßen gestalten (vgl. Abb. 2.7). Ein Gesch¨aftsprozess definiert sich als eine logisch zusammenh¨angende Kette von Teilpro” zessen, die auf das Erreichen eines bestimmten Zieles ausgerichtet sind. Ausgel¨ost durch ein definiertes Ereignis wird ein Input durch den Einsatz materieller und immaterieller G¨ uter unter Beachtung bestimmter Regeln und der verschiedenen unternehmensinternen und -externen Faktoren zu einem Output transformiert. Der Prozess ist in ein System von umliegenden Prozessen eingegliedert, kann jedoch als eine selbst¨andige, von anderen Prozessen isolierte Einheit, die unabh¨angig von Abteilungs- und Funktionsgrenzen ist, betrachtet werden.“ 118 Legt man die Wettbewerbsstrategie der Wertsch¨opfungskette nach Michael E. Porter zu Grunde, dann findet sich die IT-Sicherheit in allen unterst¨ utzenden Aktivit¨aten der Unternehmung wieder.119 Die Fokussierung der IT-Sicherheit auf Prozesse ist vor allem dann notwendig, wenn diese Kernaufgaben der Unternehmung darstellen. All jene Prozesse, die f¨ ur den Fortbestand der Unternehmung unmittelbar wichtig sind, m¨ ussen vorrangig abgesichert werden. Der Begriff des IT-Risikomanagements ist hier stark mit dem des Business Continuity Management verkn¨ upft. Das Business Continuity Ma118 Schwickert/Fischer 1996: 10f. 119 Porter unterscheidet in seiner Wertsch¨ opfungskette zwischen prim¨aren (wertsch¨opfenden) und sekund¨aren (unterst¨ utzenden) Aktivit¨ aten. Die sekund¨ aren Aktivit¨aten dienen der Aufrechterhaltung der prim¨aren Aktivit¨ aten und werden permanent ben¨ otigt, vgl. Porter 1992: 59f.

44

2 IT-Sicherheit in Unternehmungen

IT-Prozesse Projektmanagement, Qualitätsmanagement, Service Delivery Prozesse, Service Support Prozesse, Lizenzmanagement, Datenschutzmanagement, Sicherheitsmanagement, Personalmanagement

Beantragung

Planung

Anforderungsspezifikation

Technisches Konzept

Test, EntFreigabe, wicklung Inbetriebnahme

Betrieb

Außerbetriebnahme

Sicherheitselemente Business Impact Analyse, Berechtigungskonzept, Datensicherungskonzept, Archivierungskonzept, Notfall- und Katastrophenvorsorgeplanung, Security-Konzept, Testkonzept, Betriebsführungshandbuch/Betriebsinformationsportal

Abbildung 2.7: Sicherheitselemente im Lebenszyklus von IT-Prozessen (vgl. M¨ uller 2004)

nagement muss die Weiterf¨ uhrung der zentralen gesch¨aftlichen T¨atigkeiten gew¨ahrleisten (siehe Abb. 2.8).120 IT-Sicherheit generell aus einer Prozessperspektive zu betreiben, ist in großen Unternehmungen scheinbar nicht oder nur mit erheblichem Aufwand m¨oglich. Daher sollten nur die Kernprozesse einer solchen Analyse unterzogen werden. Die meisten Prozesse verwenden Daten, die jeweils unterschiedlich klassifiziert (siehe Tab. 2.1, S. 14) worden sind. Dies bedeutet, dass z.B. in einem Prozess auf Daten der Personalverwaltung, der Lohnbuchhaltung, des firmeninternen Telefonverzeichnises und auf die ¨offentlichen Webseiten der Unternehmung zugegriffen wird bzw. diese ver¨andert werden. Innerhalb eines Prozesses werden somit Daten verwendet, die den Klassifizierungen geheim (Personalverwaltung, Lohnbuchhaltung),121 intern (Telefonverzeichnis) und ¨offentlich (Internetpr¨asenz) entsprechen. W¨are der beschriebene Prozess eine unternehmungswichtige Kernaufgabe die st¨andige Verf¨ ugbarkeit erfordert, w¨ urde aus Sicht des Business Continuity Management f¨ ur alle Bestandteile eine hohe Verf¨ ugbarkeit garantiert werden m¨ ussen, obwohl die Da120 Bei den Automobilherstellern geh¨ort die eigentliche Produktion von Automobilen zu den essenziellen Prozessen, da ein Ausfall der Produktion hohe Kosten verursacht. 121 Dies sind personenbezogene Daten, die z.B. nach Bundesdatenschutzgesetz (BDSG) gesch¨ utzt werden m¨ ussen.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit

45

Business Continuity Management (BCM) IT-Risikomanagementprozess Identifikation

Business Continuity Planning (BCP)

Assessment

Daten, Systeme, Risikokonditionen, beeinträchtigtes Applikationen, Geschäftsfeld, Prozesse, ProzessRangkriterien, eigentümer, Risikonkontext Infrastruktur

Verlustpotenzial, Sicherheitsbewertung

Planning Risikostrategie (vorbeugen, beheben, etc.), Maßnahmen

Track&Report

Überwachung mögl. Auslöser, Eskalation

Control

Überwachung, Korrektur von Maßnahmen

Informationsquellen: Konfigurationsmanagement, Help Desk, Produkthersteller, Asset Management, etc. Risiko, Prozesse, IT-Sicherheit Katastrophenfall Verfügbarkeit

Status und Resultate

Priorisierung nach Schäden

Etablieren des BCP

Prüfung des BCP

Aktionen für ein BCM

Informationsquellen: Risikomanagement Datenbank

Abbildung 2.8: Prozesse im Business Continuity Management ur ten in separater Betrachtung unterschiedliche Verf¨ ugbarkeitsanforderungen haben.122 F¨ Prozesse, die keine wettbewerbsrelevante Funktion f¨ ur die Unternehmung haben und nicht zu den Kernprozessen geh¨oren, ist es h¨aufig einfacher, tabellarische Strukturen anzuwenden, wie es das IT-Grundschutzhandbuch des BSI vorschl¨agt. Am pr¨azisesten w¨are eine Festlegung des Schutzbedarfes der verschiedenen Informationen und Daten verbunden mit einer anschließenden Prozessanalyse, da nur diese die Bedeutsamkeit der Daten in einem Gesamtkontext erfassen kann. Dieses Vorgehen ist allerdings in der Praxis un¨ ublich, da der Aufwand zur Erhebung und Analyse der notwendigen Informationen betr¨achtlich ausf¨allt. M¨ogliche Modelle f¨ ur ein IT-Sicherheitsrisikomanagement in Unternehmungen werden in Abschnitt 2.6 vorgestellt.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit Neben den betriebswirtschaftlichen Zw¨angen zur Etablierung von IT-Sicherheit existieren gesetzliche Anforderungen auf nationaler und internationaler Ebene, weshalb die Legitimation der IT-Sicherheit in Unternehmungen in zunehmenden Maße in juristischen Dimensionen stattfindet.123 Nationale und internationale Gesetze, Richtlinien und Verordnungen verlangen teilweise die Einrichtung eines Risiko- oder IT-Sicherheitsmanagements ¨ 122 Der Ausfall des internen elektronischen Telefonbuchs f¨ ur einige Stunden ist f¨ ur das Uberleben einer Unternehmung in der Regel nicht relevant. 123 Vgl. Rauschen/Disterer 2004: 19. Dementsprechend m¨ ussen Sicherheitsfachleute verst¨ arkt auch juristisches Know-how vorweisen k¨onnen. Vgl. H¨onicke 2005.

46

2 IT-Sicherheit in Unternehmungen

¨ in Unternehmungen. Die Er¨offnung einer Gefahrenquelle (z.B. Offnung des Intranets zum Internet oder Nutzung von E-Mail) durch eine Unternehmung f¨ uhrt nach dem Verursacherprinzip zu einer Verkehrssicherungspflicht.124 Dies kann besonders f¨ ur multinationale Unternehmungen eine Herausforderung darstellen, wenn diese gesetzliche Auflagen diverser Staaten erf¨ ullen m¨ ussen, die zueinander heterogen oder gar inkompatibel ausfallen k¨onnen. Gesetze und Verordnungen sind als ein weiteres konstitutives Element der IT-Sicherheit in Unternehmungen anzusehen. Die hier aufgef¨ uhrten rechtlichen Rahmenbedingungen sind eine Auswahl von gesetzlichen Regelungen, die die Etablierung und Gestaltung von IT-Sicherheit in Unternehmungen betreffen. Der gew¨ahlte Querschnitt erhebt weder in Auswahl noch Ausgestaltung einen Anspruch auf Vollst¨andigkeit.

2.3.1 Bundesdatenschutzgesetz (BDSG) Das Bundesdatenschutzgesetz (BDSG) trat am 1.1.1978 in Kraft. Eine wesentliche ausgestaltende Bedeutung kam der Entscheidung des Bundesverfassungsgerichts (BVerfG) zum Volksz¨ahlungsgesetz aus dem Jahr 1983 zu, in der das Recht auf informationelle Selbstbestimmung aus dem allgemeinen Pers¨onlichkeitsrecht abgeleitet wird.125 Das BDSG126 regelt sowohl die automatisierte als auch die anderweitige Erhebung, Ver¨ wendung, Nutzung und Verarbeitung (Speicherung, Ver¨anderung, Ubermittlung, Sperrung, L¨oschung) von personenbezogenen Daten in ¨offentlichen und nicht-¨offentlichen Stellen. Dabei steht der Schutz vor Beeintr¨achtigungen der Pers¨onlichkeitsrechte des Einzelnen durch den Umgang mit seinen pers¨onlichen Daten im Vordergrund. Die wichtigsten Eckpfeiler des Gesetzes sind:127 • Verbot mit Erlaubnisvorbehalt. Die Erhebung, Verwendung, Nutzung und Verarbeitung von personenbezogenen Daten ist grunds¨atzlich verboten, es sei denn, der Betroffene hat seine Einwilligung erteilt oder das BDSG oder eine andere Rechtsvorschrift weisen eine Erlaubnis oder Anordnung dazu auf. • Transparenzgebot bzw. Kontrollrecht. D.h., der Betroffene hat einen Auskunftsanspruch gegen¨ uber der datenerhebenden Stelle. • Die datenverarbeitende Stelle ist verpflichtet, dem Betroffenen mitzuteilen, wer welche Daten und zu welchem Zweck speichert bzw. verarbeitet. 124 Vgl. Speichert 2004: 75; Bundesgerichtshof (BGH) Neue Juristische Wochenschrift (NJW) 1990, 1236, 1237. 125 Entscheidungssammlung des Bundesverfassungsgerichts (BVerfGE) 65, 1ff. 126 Bundesdatenschutzgesetz vom 20. Dezember 1990 (Bundesgesetzblatt (BGBl.) I, 3108), in der Neufassung der Bekanntmachung vom 14. Januar 2003 (BGBl. I, 66). 127 Vgl. Holznagel 2003: 169ff.; Hoppe/Prieß 2003: 313f. Hier wird ausschließlich der Datenschutz in den sogenannten nicht-¨offentlichen Stellen vorgestellt.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit

47

• Es gilt das Gebot der Datenvermeidung und Datensparsamkeit (§ 3a BDSG). • Wenn m¨oglich, sollen die Daten anonymisiert oder pseudonymisiert werden. • Die Verarbeitung der Daten darf nur dann stattfinden, wenn dadurch der inh¨arente Zweck der Erhebung verfolgt wird. • Regelung von zivilrechtlichen Haftungsfragen (z.B. Schadensersatzanspr¨ uche128 ) und Straftatbest¨anden. • Datenverarbeitende Stellen unterliegen der staatlichen Aufsicht, die ggf. Sanktionen bei Nichtbeachtung der gesetzlichen Vorschriften verh¨angen kann. • Ernennung eines Datenschutzbeauftragten, wenn die Erhebung, Verarbeitung und Nutzung personenbezogener Daten unter Einsatz von Datenverarbeitungsanlagen ” stattfindet oder Daten in oder aus nicht-automatisierten Dateien verarbeitet oder genutzt werden“.129 Die Kontrolle privatwirtschaftlicher Unternehmungen u ¨bernehmen nach § 38 Abs. 6 BDSG die jeweiligen Bundesl¨ander, die daf¨ ur entsprechende Aufsichtsbeh¨orden installiert haben.130 Des Weiteren gelten die jeweiligen bereichsspezifischen Bundes- und Landesgesetze und/oder Landesdatenschutzgesetze (LDSG). Weitere Regelungen zum Datenschutz finden sich u.a. in der Telekommunikationsdatenschutzverordnung (TDSV), im Telekommunikationsgesetz (TKG), im Mediendienstestaatsvertrag (MDStV), Teledienstedatenschutzgesetz (TDDSG) oder im Melderechtsrahmengesetz (MRRG).131 Dar¨ uber hinaus existiert die EU-Datenschutzrichtlinie f¨ ur Mitglieder der Europ¨aischen Union. Aus einem schuldhaftem Verstoß gegen Datenschutzgesetze k¨onnen Schadensersatzpflichuche133 entstehen. ten132 oder andere Anspr¨ Aus IT-Sicherheitsperspektive ist besonders § 9 des BDSG von Bedeutung, da hier technische und organisatorische Maßnahmen zur Datensicherheit gefordert werden. Diese sind jedoch nur dann erforderlich, wenn der angestrebte Schutzzweck und der notwendige Aufwand in einem angemessenen Verh¨altnis zueinander stehen. Gola/Jaspers erkennen acht 128 Vgl. §§ 7, 8 BDSG. 129 Holznagel 2003: 173. Rein pers¨ onliche oder famili¨ are T¨ atigkeiten sind von dieser Regelung ausgenommen. 130 Vgl. Gola/Klug 2003: 105ff. F¨ ur private Unternehmungen gilt ausschließlich das BDSG und nicht die jeweiligen Landesdatenschutzgesetze. 131 Ausf¨ uhrlich dazu Holznagel 2003: 180ff.; Geis/Helfrich 2003. 132 Z.B. aus § 7 BDSG oder §§ 3, 4 Nr. 11 Gesetz gegen den unlauteren Wettbewerb (UWG). 133 Beispielweise aus den Bußgeld- und Strafvorschriften in §§ 43, 44 BDSG.

48

2 IT-Sicherheit in Unternehmungen

Gebote der Datensicherheit134 , welche sich aus § 9 BDSG ergeben: Zugangskontrolle, Auftragskontrolle, Eingabekontrolle, Verf¨ ugbarkeitskontrolle, Gebot der Datentrennung, Weitergabekontrolle, Zugriffskontrolle und Zutrittskontrolle.135

2.3.2 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) Das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) trat am 1.5.1998 in Kraft und pr¨azisiert als Artikelgesetz mehrere Vorschriften aus dem Handelsund Gesellschaftsrecht.136 Ziel des Gesetzes ist eine Erh¨ohung der Transparenz und Kontrolleffizienz in Unternehmungen. Betroffen von dem Gesetz sind neben b¨orsennotierten Aktiengesellschaften auch solche Gesellschaften, die zwei der drei folgenden Kriterien in mindestens zwei aufeinander folgenden Jahren erf¨ ullen:137 • Bilanzsumme > 3,438 Mio. Euro, • Umsatz > 6,875 Mio. Euro, • Mitarbeiterzahl > 50. Kernpunkt des Gesetzes ist die erweiterte, uneingeschr¨ankte und pers¨onliche Haftung von Aufsichtsr¨aten, Vorst¨anden, Gesch¨aftsf¨ uhrung und Wirtschaftspr¨ ufern in Unternehmungen f¨ ur Sch¨aden gegen¨ uber derselben.138 Dies gilt insbesondere dann, wenn die Gesch¨aftsf¨ uhrung kein geeignetes Risikofr¨ uherkennungssystem eingerichtet hat, mit welchem solche Entwicklungen vorzeitig erkannt werden, die den Fortbestand der Gesellschaft gef¨ahrden k¨onnen.139 Laut der amtlichen Begr¨ undung des KonTraG ergibt sich der 134 Gola/Jaspers sprechen hier missverst¨ andlich von Datensicherung, unter der im Allgemeinen die Replikation von Daten aus Sicherheitsgr¨ unden verstanden wird. 135 Vgl. Gola/Jaspers 2003: 39ff. Es muss jedoch kritisch angemerkt werden, dass die dortige Erl¨auterung der Begriffe teilweise nicht der u ¨ blichen fachspezifischen Verwendung bzw. Terminologie entspricht. 136 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) vom 30. April 1998 (BGBl. I, 786). 137 Vgl. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. 2005a: 22; Speichert 2004: 222. Die Grunds¨ atze gelten ebenso f¨ ur die GmbH und GmbH & Co KG. 138 Vgl. Sch¨affter 2002: 10; §§ 93 Abs. 2 und 116 Aktiengesetz (AktG), § 43 Abs. 2 Gesetz betreffend die Gesellschaften mit beschr¨ ankter Haftung (GmbHG). 139 Vgl. § 91 Abs. 2 AktG. Analog begr¨ undet sich dies f¨ ur Gesch¨aftsf¨ uhrer einer GmbH durch die Vorgabe der Sorgfalt eines ordentlichen Gesch¨ aftmannes“ in § 43 GmbHG oder auch durch § 347 ” (Sorgfaltspflicht der Kaufleute) Handelsgesetzbuch (HGB). Es ist zu erwarten, dass § 91 Abs. 2 AktG als Schutzgesetz im Sinne des § 823 Abs. 2 B¨ urgerliches Gesetzbuch (BGB) eingestuft wird und dadurch etwaige Schadensersatzanspr¨ uche auch von Gl¨ aubigern an die Unternehmungsf¨ uhrung gerichtet werden k¨onnen, vgl. Freg 2000. Die Beweislast, ob die Sorgfalt eines ordentlichen Gesch¨aftsmannes angewandt worden ist, liegt bei den pflichtverletzenden Vorstandsmitgliedern, vgl. § 93 Abs. 2 AktG.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit

49

Umfang dieser Pflichten aus der Gr¨oße, Branche und Struktur der Unternehmung. Im ¨ Allgemeinen wird unter einem solchen Uberwachungssystem die Einrichtung eines Risikomanagementsystems und damit auch eines IT-Sicherheitsmanagements verstanden.140 Um die Risiken zu dokumentieren, ist der geforderte Lagebericht aus § 289 Abs. 1 HGB um einen Risiko- und Prognosebericht erweitert worden, welcher u.a. die Risikomanagementziele und -methoden der Gesellschaft und die voraussichtliche Entwicklung der Risikolandschaft darstellen soll. Im Handelsgesetzbuch (HGB) ist festgelegt, dass der Abschlusspr¨ ufer bei b¨orsennotierten Aktiengesellschaften festzustellen hat, ob der Vorstand dieser Pflicht nachgekommen ist.141 Dar¨ uber hinaus muss der Abschlusspr¨ ufer die Maßnahmen beurteilen, im Pr¨ ufbericht gesondert darstellen und ggf. Vorschl¨age f¨ ur Verbesserungsmaßnahmen unterbreiten.142 Die Haftung des Vorstands wird teilweise durch eine Umkehr der Darlegungs- und Beweislast erg¨anzt, da der Antragsteller auf Schadensersatzanspr¨ uche in der Regel keinen Einblick in die internen Abl¨aufe der Unternehmung besitzt. Daher ist die Erf¨ ullung der Risikovorsorgepflichten des Vorstandes detailliert zu dokumentieren, um Darlegungs- und Beweislasten nachkommen zu k¨onnen.143 EDV-Leiter und Administratoren haften nicht nach KonTraG.

2.3.3 Zivil- und Strafrecht Nicht nur auf Vorstands- und Gesch¨aftsf¨ uhrungsebene existiert ein erh¨ohtes Risiko f¨ ur das eigene Handeln oder Nicht-Handeln in Regress genommen zu werden. Jeder Mitarbeiter einer Unternehmung u ¨bernimmt im Rahmen der ihm u ¨ bertragenen Aufgaben eine Sorgfaltspflicht. Im deutschen Zivilrecht wird bei der Frage nach einem Verschulden der Begriff der Fahrl¨assigkeit genutzt. Nach § 276 Abs. 2 BGB handelt fahrl¨assig, wer die im Verkehr erforderliche Sorgfaltspflicht außer Acht l¨asst.“ 144 Dabei wird unter” schieden zwischen der bewussten und unbewussten Fahrl¨assigkeit. Wenn der Handelnde mit dem m¨oglichen Eintritt eines Schadens rechnet, aber darauf vertraut, dass dieser nicht eintreten wird, dann handelt er bewusst fahrl¨assig. Wird der Schadenseintritt billigend in Kauf genommen, dann liegt bedingter Vorsatz vor. 140 Vgl. Menzel 2001. Allerdings existieren keine allgemeing¨ ultig rechtlich anerkannten Standards. 141 Vgl. § 317 Abs. 4 HGB. Die Pr¨ ufung erfolgt hinsichtlich Bestehen, Eignung und Wirksamkeit eines Risikomanagementsystems. 142 Vgl. § 321 HGB. 143 Vgl. Speichert 2004: 227f. 144 B¨ urgerliches Gesetzbuch in der Fassung der Bekanntmachung vom 2. Januar 2002 (BGBl. I S. 42, 2909; 2003 I S. 738), zuletzt ge¨ andert durch Artikel 123 des Gesetzes vom 19. April 2006 (BGBl. I S. 866).

50

2 IT-Sicherheit in Unternehmungen

Die unbewusste Fahrl¨assigkeit ist dadurch charakterisiert, dass der Handelnde den m¨oglichen Schadenseintritt nicht vorhersieht, ihn aber bei der zumutbaren und im Verkehr erforderlichen Sorgfalt h¨atte erkennen und verhindern k¨onnen. Bei unbewusster Fahrl¨assigkeit ist keine Haftung gegeben, es sei denn ein Gesetz sieht dies f¨ ur einen Straftatbestand vor.145 Im Strafrecht muss zus¨atzlich unterschieden werden zwischen Absicht, direktem Vorsatz und Eventualvorsatz. Der Eventualvorsatz ist von der bewussten Fahrl¨assigkeit nur schwierig abzugrenzen. Die Straftatbest¨ande k¨onnten auch schon bei Eventualvorsatz verwirklicht werden, wenn der T¨ater es ernstlich f¨ ur m¨oglich h¨alt und sich damit abfindet, dass sein Verhalten den gesetzlichen Tatbestand erf¨ ullt. Die Haftung bei rechtswidriger vors¨atzlicher IT-Nutzung ist vor allem gegeben bei Straftatbest¨anden wie dem • Aussp¨ahen von Daten (§ 202a StGB), • Datenver¨anderung (§ 303a StGB), • Computersabotage (§ 303b StGB), • F¨alschung beweiserheblicher Daten (§ 269 StGB), • Unterdr¨ ucken beweiserheblicher Daten (§ 274 Abs. 1 Nr. 2 StGB), • F¨alschung technischer Aufzeichnungen (§ 268 StGB) oder • Unterdr¨ ucken technischer Aufzeichnungen (§ 274 Abs. 1 Nr. 1 2. Alt. StGB),146 • Verrat von Gesch¨afts- oder Betriebsgeheimnissen (§ 17 UWG). Dar¨ uber hinaus kann die Unternehmung bzw. das Management bei mangelnder Kontrolle ebenfalls haftbar gemacht werden.147 Eine zivilrechtliche Haftung kann gegen¨ uber Dritten mit oder auch ohne Vertrag entstehen. Voraussetzung f¨ ur die Haftung nach § 823 BGB (Schadensersatzpflicht) ist die Verletzung von Rechtsg¨ utern.148 Daten besitzen nach herrschender Meinung Sacheigenschaft, sofern sie auf einem Datentr¨ager gespeichert sind.149 In der Folge handelt es sich um eine Eigentumsverletzung, wenn Daten ver¨andert oder in ihrer Verf¨ ugbarkeit beeintr¨achtigt werden.150 Wenn z.B. Viren oder Trojaner auf den Computer eines Nutzers durch den Besuch einer von Dritten manipulierten Unternehmungswebseite gelangen und dadurch 145 Vgl. Strafgesetzbuch (StGB) § 15. 146 Vgl. Holznagel 2003: 106ff. 147 Z.B. § 100 Gesetz u ¨ber Urheberrecht und verwandte Schutzrechte (UrhG), Mitt¨aterschaft, Beihilfe. 148 Neben dieser gesetzlichen Schadensersatzpflicht existiert die vertragliche Schadensersatzpflicht aus Verletzung von Haupt- oder Nebenpflichten. 149 Vgl. BGH NJW 1993, 2436, 2437f. 150 Vgl. Speichert 2004: 82.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit

51

ein Schaden entsteht, ist die Unternehmung schadensersatzpflichtig. Des Weiteren k¨onnen sich solche Anspr¨ uche aus § 823 BGB auch in Kooperationen von Unternehmungen ergeben, wenn der Kooperationspartner z.B. Viren in die andere Unternehmung einbringt oder anderweitig St¨orungen in der Infrastruktur des Partners hervorruft. Die Verbreitung von Viren durch fehlenden oder nicht aktuellen Virenschutz f¨ uhrt ebenfalls zur Schadensersatzpflicht.151 EDV-Leiter und Administratoren k¨onnen ebenfalls nach § 823 BGB schadensersatzpflichtig gemacht werden. Hinzu kommen in der Regel arbeitsrechtliche Konsequenzen, welche sich aus der fahrl¨assigen Handlung und dem Pflichtenumfang des Arbeitsvertrages herleiten lassen. Bei leichter Fahrl¨assigkeit existiert keine Haftung und bei mittlerer Fahrl¨assigkeit eine quotale Schadensteilung. Bei grober Fahrl¨assigkeit oder gar Vorsatz kommt die volle Haftung zur Geltung. Neben dem Schadensersatz besteht die M¨oglichkeit einer Abmahnung oder gar K¨ undigung des Mitarbeiters. Mitarbeiter in leitenden Positionen haben in der Regel h¨ohere Sorgfaltspflichten als untergebene Mitarbeiter und haften gegebenenfalls auch mit ihrem Privatverm¨ogen.152 Die Nicht-Einrichtung eines IT-Sicherheitsmanagementsystems kann auch in kleineren Szenarien zu wirtschaftlichen Nachteilen f¨ uhren. Das Oberlandesgericht Hamm hat einem Reiseb¨ uro 14.000,- Euro Schadensersatz verweigert, da es keine geeigneten Maßnahmen zur Datensicherung vorweisen konnte. Bei der Reparatur an einem Server des Reiseb¨ uros durch eine dritte Unternehmung wurden Daten unwiederbringlich gel¨oscht. Das Reiseb¨ uro hatte die Daten nicht einmal monatlich gesichert – nach Ansicht des Gerichts h¨atte eine Datensicherung t¨aglich erfolgen m¨ ussen, die Vollsicherung mindestens ” einmal w¨ochentlich“. Der IT-Verantwortliche war nach Ansicht des Gerichts seinen Pflichten nicht nachgekommen und handelte grob fahrl¨assig (blau¨augig)“, weshalb das Gericht ” die Schadensersatzanspr¨ uche an die Reparaturunternehmung ablehnte.153

2.3.4 Service-Level-Agreement (SLA) Service-Level-Agreements (SLAs) fallen nur indirekt in die Kategorie rechtliche Regelungen, da es sich um Vertr¨age zwischen (mindestens) zwei Parteien handelt. Sie regeln den Umfang und die Ausgestaltung von vereinbarten Leistungen der beteiligten Parteien sowie deren Rechte und Pflichten. Hier werden SLAs im Zusammenhang mit dem sogenannten Outsourcing, also der Auslagerung einer bisher unternehmungsinternen Leistungserstel151 Vgl. Landgericht (LG) Hamburg Computer und Recht (CR) 2001, 677f. 152 Vgl. Sch¨affter 2002. 153 Vgl. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. 2005: 4; Oberlandesgericht (OLG) Hamm, AZ 13 U 133/03.

52

2 IT-Sicherheit in Unternehmungen

lung an Dritte, betrachtet. SLAs sind deshalb von besonderem Interesse, da Outsourcing in den letzten Jahren verst¨arkt von Unternehmungen betrieben worden ist. F¨ ur die Dom¨ane der IT-Sicherheit existieren sogenannte Managed Security Service Provider (MSSP), welche im Jahr 2004 insbesondere in den Themenbereichen Entsorgung von Datentr¨agern, Managed Firewalls, Managed Intrusion-Detection-Systeme und der Pflege von Netzwerken und Betriebssystemen f¨ ur Unternehmungen t¨atig wurden.154 Die Leistungserstellung im Bereich Informations- und Kommunikationstechnologie bedarf bei einer Auslagerung eine Abw¨agung des Nutzens und eine genaue Betrachtung der vereinbarten Leistungen. Neben dem ben¨otigten Sicherheitsniveau sollten folgende Leistungen aus ITSicherheitssicht in einem SLA definiert werden:155 • Definition der geregelten und u ¨berwachten Bereiche, • Verantwortlichkeiten, Rechte und Pflichten, Ansprechpartner, • Administration, Change Management und Konfigurationsmanagement, • Verf¨ ugbarkeit der Services, maximale Ausfallzeiten, Wartungsfenster, • Reaktions- und Supportzeiten, • Reporting (H¨aufigkeit, Form, evtl. Sonderberichte bei Vorf¨allen), Dokumentation, Monitoring, • Haftungsbeschr¨ankungen, Versicherungen, gesetzliche Auflagen (z.B. Datenschutz), • Geheimhaltungsvereinbarung, • Zugangs-, Zugriffs- und Zutrittsregelungen, • physikalische und organisatorische Sicherheit des Rechenzentrums, • Alarm-Konzepte, • Prozedere bei Notf¨allen, Disaster-Recovery, Backup-Konzept, • Kontrollrechte. Dar¨ uber hinaus sind Entlohnung, K¨ undigungsfristen, Konventionalstrafen und Schadensersatz vertraglich zu regeln. Ein wichtiges Detail ist die Verf¨ ugbarkeit von Systemen und Daten, welche sich klassifizieren lassen (siehe Tab. 2.4). Gut gestaltete SLAs sind eindeutig und unmissverst¨andlich. Sie beschreiben sowohl die technischen als auch die organisatorischen Rahmenbedingungen und legen alle involvierten Prozesse offen, bieten also mithin vollst¨andige Transparenz. Daher muss der pr¨azisen 154 Vgl. Lindner 2005. 155 Vgl. Lindner 2005; B¨ ukow 2003.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit

BSI

Schadensauswirkung

53

Verf¨ ugbarkeitskategorien

Ausfallzeit pro Jahr

Verf¨ ugbarkeit in %

-

keine/ gering

nicht verf¨ ugbar

∼36,5 t

90

niedrig/ mittel

begrenzt und u ¨ berschaubar

verwaltet verf¨ ugbar verf¨ ugbar

∼3,7 t ∼9 h

99 99,9

hoch

betr¨ achtlich

hochverf¨ ugbar h¨ochstverf¨ ugbar

∼1 h ∼5 min

99,99 99,999

sehr hoch

existenziell, bedrohlich, katastrophal

unterbrechungsarm unterbrechungsfrei

∼30 s ∼3 s

99,9999 99,99999

Tabelle 2.4: Klassifikation der Verf¨ ugbarkeit (in Anlehnung an Bernhard 2003: 237) Ausformulierung des SLAs ein ausreichender Zeitrahmen einger¨aumt werden, damit bei evtl. auftretenden Sicherheitsproblemen die Verantwortlichkeiten gekl¨art sind und die Beweislast nicht beim Kunden liegt. Der Outsourcing-Anbieter sollte seine Expertise u ¨ber entsprechende Zertifikate (z.B. ITIL, BS 7799, IT-Grundschutzhandbuch, CobiT) und Referenzen darstellen k¨onnen und dem Kunden das Recht einr¨aumen, regelm¨aßige ITRevisionen beim Leistungserbringer durchf¨ uhren zu k¨onnen. Das Reporting ist einer der elementaren Bestandteile des SLAs, da dieses die Grundlage f¨ ur die Verifikation der vereinbarten Leistung bildet.156 Ausgelagerte Leistungen k¨onnen nicht oder nur unter hohen Aufwendungen wieder in die Unternehmung integriert werden.157 Dies erhebt die Entscheidung f¨ ur oder gegen ein Outsourcing in eine strategische Dimension.158 Aus diesem Grund ist auch die wirtschaftliche Situation des potenziellen Leistungserstellers von Bedeutung, da die Bindung an diesen in der Regel langfristig erfolgt und die Kontinuit¨at der Gesch¨aftst¨atigkeit gew¨ahrleistet sein muss. In einer IT-Sicherheitsstudie wurden Unternehmungen u ¨ber die Nutzung von ausgelagerten Dienstleistungen befragt (vgl. Tab. 2.5).159 Dabei war der Trend zur Nutzung von Outsourcing-Dienstleistungen im Jahr 2004 (52%) geringer als im Jahr 2002 (73%). Es sollte nicht nur eine Frage der Wirtschaftlichkeit sein, ob die Sicherheit von Unternehmungsdaten durch eine externe Unternehmung gew¨ahrleistet werden soll. Der Verbleib oder die Auslagerung von hochsensiblen Unternehmungs- und Produktinformationen im eigenen/aus dem eigenen Hoheitsgebiet“ ist nicht nur eine Frage betriebswirtschaftlicher ” Kosten einer eigenen Leistungserstellung, sondern ebenso eine essenzielle Frage, ob und 156 Vgl. Lindner 2005. 157 Vgl. Vatter 1999: 10f. 158 Vgl. Bliesener 1994: 277. 159 Vgl. kes 2004b.

54

2 IT-Sicherheit in Unternehmungen

Genutzte Outsourcing-Dienstleistungen Entsorgung von Datentr¨agern (Papier, EDV) Managed Firewall/IDS Betriebssystempflege Netzwerkmanagement Datensicherung, Backup-L¨osungen Gesamtes Rechenzentrum Datenbanksysteme, Werkzeuge Online-Anwendungssysteme Sonstiges Auftragsentwurf, Arbeitsvorbereitung, Operating Notfallvorsorge, Business Continuity Verwaltung, Dokumentation, Archivierung Personaleinsatz, Personalentwicklung, Mitarbeiterweiterbildung Haustechnik ¨ Uberwachung, Kontrolle, Qualit¨atssicherung Datenschutz gem¨aß BDSG

Prozent 63% 32% 29% 28% 26% 23% 23% 21% 21% 15% 15% 13% 13% 13% 12% 11%

Tabelle 2.5: Nutzung von Outsourcing-Dienstleistungen im Jahr 2004 (vgl. kes 2004b) wieviel Vertrauen eine Unternehmung in das eigene Sicherheits-Know-how hat und wieviel Vertrauen sie einem Dritten gegen¨ uber hervorbringen kann. Hier wird die Meinung vertreten, dass bestimmte Sicherheitsleistungen von Dritten erstellt werden k¨onnen, insbesondere solche, welche ein fundiertes und aktuelles Know-how ben¨otigen wie z.B. SicherheitsMonitoring in Echtzeit, Intrusion-Detection-Systeme (IDS), Intrusion-Prevention-Systeme (IPS) oder Firewalls. Wenn in diesen Bereichen das Wissen in der Unternehmung nur rudiment¨ar vorhanden ist und nicht aufgebaut werden kann, dann verschafft die Eigenerstellung der Leistung nur eine tr¨ ugerische Sicherheit. Die Existenz der Technik allein reduziert das Risiko kaum – erst die korrekte Anwendung und das Wissen um Angreifer, aktuelle Sicherheitsl¨ ucken, Exploits etc. kann die Sicherheit von Informationen in der Unternehmung verbessern. Andere Leistungen hingegen, wie z.B. die Erstellung von IT-Sicherheitsregel-, IT-Sicherheitsrahmenwerken oder andere sogenannte IT-Governance-Aufgaben, m¨ussen in der Unternehmung verbleiben, da sie sehr stark mit unternehmungsinternen Prozessen, Informationen, Zielen und Organisationsstrukturen verbunden sind.160 Die Unternehmung w¨ urde mit einer solchen Auslagerung die Hoheit u ¨ber ihre eigenen Prozesse verlieren und w¨are – zumindest teilweise – fremdgesteuert. 160 Ausf¨ uhrlich zum Begriff der IT-Governance vgl. Meyer/Zarnekow/Kolbe 2003.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit

55

2.3.5 Weitere ausgew¨ ahlte rechtliche Regelungen zur IT-Sicherheit An dieser Stelle werden weitere Regelungen bzw. rechtliche Herausforderungen im Rahmen der Etablierung von IT-Sicherheit in Unternehmungen vorgestellt.161 Ein Problem in der Praxis kann die staatliche Regulierung des Einsatzes von kryptografischen Algorithmen darstellen. Nicht jeder Staat erlaubt den Import, Export oder die Anwendung von Verschl¨ usselungsverfahren. Wesentlich sind in diesem Zusammenhang die Regelungen der EU und des Wassenaar-Abkommens bez¨ uglich des Exports und nationale Regelungen, die Anweisungen zur Anwendung von kryptografischen Algorithmen beinhalten. Der kommerzielle Einsatz von kryptografischen Algorithmen ist in einigen Staaten genehmigungspflichtig.162 Dies kann in der Praxis zu Problemen f¨ uhren, wenn z.B. die Daten der Standleitung zwischen der Unternehmungszentrale und einer ausl¨andischen Niederlassung durch Virtual Private Network (VPN) Gateways verschl¨ usselt werden soll. Zum 1. Januar 2007 soll eine Neuregelung des Bankenaufsichtsrechts, der neue Baseler Akkord Basel II, in Kraft treten, der die alte Regelung vom Juli 1988 ersetzt.163 Kernpunkt ist die Neugestaltung der Eigenkapitalvorschriften f¨ ur Kreditinstitute, die sich st¨arker an betriebswirtschaftlichen Prinzipien des Risikomanagements orientieren sollen, damit sie ihre Wettbewerbsposition sichern k¨onnen.164 Die Banken, die sich bereits an der neuen Regelung orientieren, m¨ ussen in der Kreditvergabe einen Teil des Kredites mit Eigenkapital unterlegen. Je nach Risikoeinsch¨atzung des Kreditnehmers durch interne oder externe Ratings kann der Prozentsatz der Eigenkapitalsicherung der Bank f¨ ur den Kredit zwischen 1,6 und 12 Prozent ausfallen.165 Die daraus resultierenden Vor- oder Nachteile der Banken finden sich entsprechend in den Kreditkonditionen des Kreditnehmers wieder. Basel 161 Es werden nicht alle gesetzlichen Regelungen betrachtet. Teilweise ist die Anwendbarkeit z.B. auf bestimmte Gesellschaftsformen (z.B. Aktiengesellschaft, Gesellschaft mit beschr¨ankter Haftung, etc.) oder Branchen beschr¨ ankt. Zu den weiteren nationalen gesetzlichen Regelungen geh¨oren unter anderem die Grunds¨atze ordnungsm¨ aßiger DV-gest¨ utzter Buchf¨ uhrungssysteme (GoBS), der Pr¨ ufstandard 330 des Instituts der Wirtschaftspr¨ ufer in Deutschland e.V. (IDW PS 330) und die Grunds¨atze zum Datenzugriff und zur Pr¨ ufbarkeit digitaler Unterlagen (GDPdU). F¨ ur Unternehmungen, die in den USA t¨atig sind, gelten zum Teil neben den hier erw¨ ahnten Vorschriften und Gesetzen der GrammLeach-Bliley Act (GLBA), der Health Insurance Portability and Accountability Act (HIPAA) und die Current Good Manufacturing Practices (CGMP). 162 Vgl. Koops 2005. 163 Vgl. Sch¨affter 2002: 12. 164 Vgl. KPMG 2004. 165 Vgl. Behlmer 2001: 27.

56

2 IT-Sicherheit in Unternehmungen

II ist zwar eine interne Bankvorschrift, jedoch wird erwartet, dass die Kreditinstitute die Maßst¨abe von Basel II an ihre Kunden weitergeben werden.166 IT-Sicherheit in Form von IT-Risikomanagement ist in Basel II ein qualitatives Kriterium und wird als Unterkategorie der operationellen Risiken betrachtet. Schwerpunkt in diesem Bereich von Basel II ist die Herstellung von Transparenz in IT-gest¨ utzten Prozessen sowie die Erarbeitung von Business Continuity Pl¨anen und weniger der Bereich der IT-Sicherheit, der sich mit dem Verlust der Vertraulichkeit besch¨aftigt. Obwohl der erreichte Grad an IT-Sicherheit nur einen geringen Einfluss auf das Rating von Kreditnehmern besitzt, wird Basel II sehr h¨aufig von IT-Sicherheitsberatungsunternehmungen als wichtiges Motiv zur Einrichtung eines IT-Risikomanagements angef¨ uhrt. Der Einfluss der IT-Sicherheit auf das Rating f¨ ur den Kreditnehmer betr¨agt sch¨atzungsweise (je nach Gesch¨aftsmodell des Kreditnehmers) 0 bis 3% – das bedeutet nicht, dass sich die Kreditkonditionen um bis zu drei Prozentpunkte verschlechtern.167 Die generellen Auswirkungen von Basel II auf kleinere und mittlere Unternehmungen sind nach einer Studie als gering und sogar eher positiv einzusch¨atzen.168 Im Jahr 2002 trat das Gesetz Public Company Accounting Reform and Investor Protection of 2002 in den USA in Kraft, welches auch Sarbanes-Oxley Act (SOX) – nach den Initiatoren des Gesetzes Paul Sarbanes und Michael Oxley – genannt wird. Betroffen sind alle Unternehmungen, die der Aufsicht durch die U.S. Securities and Exchange Commission (SEC, US-amerikanische B¨orsenaufsichtsbeh¨orde) unterliegen. Hintergrund der Gesetzesinitiative waren Unregelm¨aßigkeiten und Intransparenz in der Unternehmungskommunikation und den finanziellen Transaktionen von Unternehmungen wie z.B. bei Enron oder Worldcom. SOX verpflichtet die Unternehmungen unter anderem zu Folgendem:169 • Der Vorstandsvorsitzende und der Vorstand f¨ ur Finanzen m¨ ussen den Finanzbericht getrennt voneinander u ufen und abzeichnen, ¨ berpr¨ • Einberufung eines Audit Komitees mit speziellen Rechten und Pflichten, • der Verdacht auf Insidergesch¨afte muss zeitnah gemeldet werden, • Ver¨offentlichung der Bez¨ uge des Vorstandsvorsitzenden und des Finanzvorstands, • Unabh¨angigkeit der Auditoren,170 166 Vgl. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. 2005a: 22f. 167 In den meisten Publikationen zu Basel II und dessen Ratingverfahren wird die Sicherheit der IT nicht einmal erw¨ahnt, geschweige denn als wichtiges Kriterium erachtet. 168 Vgl. PWC 2004: 97; Schwaiger 2004: 42ff. 169 Vgl. Conference of State Bank Supervisors 2002; Schnell 2004; Ostler 2005. 170 Auditoren respektive deren Unternehmungen d¨ urfen f¨ ur die zu u ufende Unternehmung nicht in ¨ berpr¨ anderen Bereichen t¨atig sein, wie z.B. technische oder juristische Beratungst¨atigkeiten.

2.3 Rechtliche Rahmenbedingungen zur IT-Sicherheit

57

• Nachweis eines internen Kontrollsystems, u ¨ber dessen Funktionsf¨ahigkeit und Effektivit¨at ein gesonderter Bericht zu ver¨offentlichen ist (f¨ ur Unternehmungen außerhalb der USA mindestens j¨ahrlich). Im letztgenannten Punkt fordert SOX (h¨aufig als SOX 404 Compliance bezeichnet) – ¨ahnlich wie das KonTraG – ein Management von Risiken, welches durch Indikatoren und Fr¨ uhwarnsysteme m¨ogliche Beeintr¨achtigungen der Gesch¨aftst¨atigkeit dokumentiert. Dabei haben die PCAOB (Public Company Accounting Oversight Board) und die SEC, die die Vorgaben erstellen, weder festgelegt, wie die Controls getestet werden sollen, noch gegen welche Kriterien.171 Als Standardrahmenwerk zur Revision der internen Kontrollsysteme hat sich das Enterprise Risk Management (ERM) des Committee of Sponsoring Organizations of the Treadway Commission (COSO) durchgesetzt. Des Weiteren kommen unter Sicherheitsaspekten auch CobiT und ISO/IEC 17799 zum Einsatz.172 Der IT-Bereich ist von SOX vor allem bei der Datenarchivierung und der Integrit¨at, Nachweisbarkeit und Verbindlichkeit von Informationen und Daten (insbesondere Transaktionen) betroffen. In Deutschland m¨ ussen zur Zeit (Stichtag 31.12.2004) 22 Unternehmungen SOX erf¨ ullen.173 Die Anzahl der SOX-pflichtigen Unternehmungen kann durch Outsourcing und Unternehmungspartnerschaften steigen – in diesen speziellen F¨allen muss keine di¨ rekte Aufsicht durch die SEC gegeben sein. Die Ubereinstimmung mit SOX 404 ist die gr¨oßte Herausforderung, da die internen Kontrollen und deren Kennzahlen, Messgr¨oßen etc. nicht definiert sind.174 Es ist kritisch anzumerken, dass keine Harmonisierung in der internationalen Gesetzgebung vorliegt. Dies hat zur Folge, dass sich gesetzliche Regelungen widersprechen. Die franz¨osische Datenschutzbeh¨orde Commission Nationale de l’Informatique et des Libert´es (CNIL) hat einige US-Firmen wegen des Verstoßes gegen das franz¨osische Datenschutzrecht zur Verantwortung gezogen.175 Grund war die vom Sarbanes-Oxley Act verlangte Einrichtung einer anonymen Hotline, die Mitarbeiter nutzen sollen, um auf rechtliche Verst¨oße aufmerksam zu machen. Des Weiteren kollidieren das Wirtschaftspr¨ ufergesetz und SOX, da das deutsche Gesetz die Weitergabe von vertraulichen Informationen durch Wirtschaftspr¨ ufer verbietet, w¨ahrend SOX die Weitergabe an die SEC fordert. Die Einhaltung von SOX verst¨oßt gegen eine ganze Reihe von nationalen respektive EU-weiten Da171 Vgl. Sabett 2004. 172 Vgl. Sabett 2004. 173 Vgl. U.S. Securities and Exchange Commission 2004: 18. Die DaimlerChrysler AG ist der einzige deutsche Automobilhersteller, der der Aufsicht der SEC unterliegt. 174 Dar¨ uber hinaus kann die Einhaltung von SOX ein kostenintensives Unterfangen darstellen. BASF sch¨atzt die Kosten auf 30 bis 40 Millionen US-Dollar, vgl. Howarth 2005. 175 Vgl. Ermert 2005.

58

2 IT-Sicherheit in Unternehmungen

tenschutzregelungen.176 Die Erf¨ ullung einer gesetzlichen Anforderung eines Landes kann den Verstoß gegen eine gesetzliche Regelung einer anderen Nation zur Folge haben.

2.4 Ausgew¨ ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen Im Folgenden werden einige ausgew¨ahlte Aspekte zum Schutz von Informations- und Kommunikationssystemen vorgestellt. Insbesondere die technischen Aspekte werden nur kurz vorgestellt, da die Technik einem steten Wandel unterliegt. Neue Sicherheitstechnologien bringen in der Regel neue Tools und Methoden zur Umgehung derselben hervor: Die Verbreitung von Firewalls f¨ uhrte zu einer Technik namens Firewalking, mit der Angriffe durch die Firewall hindurch m¨oglich wurden. Die Einf¨ uhrung von Personal Iden¨ tification Number (PIN) und Transaction Number (TAN) – z.B. bei Uberweisungen im Internetbanking – f¨ uhrte zum Phishing, womit Angreifer vertrauliche Informationen zur missbr¨auchlichen Verwendung erlangen konnten. Attacks always get better; they never ” get worse.“ 177 Diese Feststellung legitimiert die Aussage, dass InformationstechnologieManagement vor allem ein Management des Wandels ist.178 Dies l¨asst sich auch an den reduzierten Reaktionszeiten erkennen. Wird eine Sicherheitsl¨ ucke in einem Betriebssystem, einem Dienst oder einer Applikation durch ein speziell daf¨ ur geschaffenes Programm oder Verfahren ausgenutzt, so bezeichnet man dies als einen Exploit. Die Reaktionszeit von der Entdeckung einer Schwachstelle bis zu einem Exploit hat sich in der Vergangenheit dramatisch verk¨ urzt. Bei dem Wurm Nimda im Jahr 2001 waren es 336 Tage, bei Sasser im Jahr 2004 hingegen nur noch 17 Tage, bis eine Schwachstelle ausgenutzt werden konnte. Die hier vorgenommene Trennung zwischen technischer und organisatorischer ITSicherheit existiert in der Praxis nur sehr selten. In den meisten F¨allen verhalten sich die beiden Elemente komplement¨ar zueinander. Zumindest die technischen L¨osungen kommen in der Regel nicht ohne eine organisatorische Unterst¨ utzung aus. So m¨ ussen beispielsweise Firewalls administriert werden oder es muss eine organisatorische Regel existieren, ¨ die vorgibt, welche Prozesse ablaufen, wenn ein Uberwachungssystem einen physischen Einbruchsversuch im Rechenzentrum detektiert. Die exemplarisch vorgestellten Problembereiche m¨ ussen in einer Risikoanalyse untersucht werden und es m¨ ussen, falls eine signifikante Gef¨ahrdung besteht, entsprechende Maß176 Vgl. Europ¨aische Kommission 2003: 68. 177 Schneier 2005. 178 Vgl. Paulus 2000: 384.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

59

nahmen zur Reduzierung der Eintrittswahrscheinlichkeit oder der Auswirkungen getroffen werden. Auf Grund der Tatsache, dass IT-Sicherheit in all ihren Dimensionen hochkomplex und umfangreich ist, k¨onnen nicht alle Details vertiefend dargestellt werden. Es werden vor allem solche Bereiche vorgestellt, die in der Literatur i.d.R. nur eine geringe Aufmerksamkeit finden.

2.4.1 Technische IT-Sicherheit Die technische IT-Sicherheit befasst sich mit technischen L¨osungen f¨ ur zu sichernde Informationen. Darunter wird auch der physikalische Schutz von Informationen verstanden, welcher beispielsweise verhindert, dass unbefugte Personen Datentr¨ager entwenden oder sich Zutritt zum Rechenzentrum verschaffen. Zur genaueren begrifflichen Differenzierung muss zwischen Zutritts-, Zugangs- und Zugriffskontrolle unterschieden werden:179 • Zutrittskontrolle: Eine Zutrittskontrolle ist dann erforderlich, wenn Personen gesicherte Areale (Geb¨aude oder R¨aume) betreten wollen. Typischerweise wird die Zutrittsberechtigung u ¨ ber Identifikations- und/oder Verifikationsmerkmale wie Passw¨orter, Ausweise, Schl¨ ussel oder Biometrie gepr¨ uft. • Zugangskontrolle: Eine Zugangskontrolle ist in der Regel ein Authentifikationsverfahren180 , welches den Zugang zu Systemen, Applikationen und Diensten steuert. • Zugriffskontrolle: Eine Zugriffskontrolle regelt u ¨ ber Berechtigungen (lesen, schreiben, l¨oschen, ausf¨ uhren) den Zugriff auf einzelne Informationen, welche dem Nutzer durch die Authentifikation zugewiesen werden. Der physikalische Schutz der IT-Infrastruktur sollte nach M¨oglichkeit bereits in der Planungsphase dieser Infrastrukturen ber¨ ucksichtigt werden, da es ungleich problematischer ist, z.B. bauliche Maßnahmen durchzuf¨ uhren, wenn ein System bereits in Betrieb ist. Zu den physikalischen Schutzmaßnahmen geh¨oren nicht nur Maßnahmen, welche den Zutritt kontrollieren, sondern auch solche, die gegen Brand/Verrauchung, Fehlfunktionen in der Klimatisierung, Wassereinbruch, oder zur Aufrechterhaltung von elektrischer Versorgung, Geb¨audestruktur, Raumstruktur oder Verkabelung notwendig sind.181 ¨ Ein Uberspannungsschutz (Grob-, Mittel- und Feinschutz), der auch in der Lage ist, Spannungsspitzen herauszufiltern, ist ebenso wichtig wie eine unterbrechungsfreie Stromversorgung f¨ ur zentrale Systeme und Dienste oder ein Schutz gegen Unterspannung bzw. 179 Vgl. Campo 2005: 14. 180 Unterschieden wird zwischen Authentisierung und Authentifikation: Ein Benutzer authentisiert (identifiziert) sich an einem System, von welchem er authentifiziert (verifiziert) wird. 181 Vgl. Friedl 1998.

60

2 IT-Sicherheit in Unternehmungen

Spannungsschwankungen. Empirisch betrachtet geht die gr¨oßte Gef¨ahrdung der EDV in ¨ IT-R¨aumen182 von elektrischer Energie (beispielsweise Blitz/Uberspannung) aus.183 Bestimmte elektrische Ger¨ate sollten nicht in IT-R¨aumen aufgestellt werden, da sie, laut der Schadenerfahrung von Versicherungen, h¨aufiger Br¨ande ausl¨osen, wie z.B. Kopierger¨ate, Schalt- und Stromverteilerschr¨anke oder Drucker. Daneben sollten auch private Ger¨ate wie Kaffeemaschinen, K¨ uhlschr¨anke, Heizplatten, Tauchsieder etc. nicht in ITR¨aumen betrieben werden.184 Eine unterbrechungsfreie Stromversorgung (USV) kann – je nach Leistungsbedarf der EDV und Leistungsf¨ahigkeit bzw. Dimensionierung der USV – den IT-Betrieb mehrere Minuten oder sogar Stunden aufrecht erhalten. Die USV sollte es erm¨oglichen, bei einem l¨anger andauernden Ausfall der elektrischen Versorgung die IT-Systeme kontrolliert herunterzufahren, um Inkonsistenzen (vor allem in Datenbanken) und Datenverlust zu vermeiden. F¨ ur den Fall, dass die IT-Infrastruktur eine hohe Verf¨ ugbarkeit aufweisen muss, ist die Bereitstellung einer korrekt dimensionierten Netzersatzanlage (NEA) vorzusehen, die in der Regel aus USVs und Notstromdieselaggregaten besteht. Um die Wahrscheinlichkeit einer Unterbrechung der Stromversorgung zu minimieren (z.B. durch Aushubarbeiten mit einem Bagger), werden Rechenzentren aus verschiedenen Quellen (Elektrizit¨at und Datenkabel) gespeist. Dabei wird eine Einspeisung auf verschiedenen Seiten des Rechenzentrumgeb¨audes (z.B. Einspeisung auf der Nord- und der S¨ udseite des Geb¨audes) vorgenommen, die idealerweise durch unterschiedliche Energieversorger/Provider erfolgt oder mindestens unabh¨angige Kabelf¨ uhrungen (z.B. u ¨ber unterschiedliche Umspannwerke) aufweist. In oder unter der Decke der IT-R¨aume sollten keine Gas-, Wasser- oder Abwasserleitungen verlaufen, da diese brechen oder lecken k¨onnen. Sollte dies dennoch der Fall sein, so ist sicherzustellen, dass entsprechende Maßnahmen f¨ ur den Eintritt eines solchen Ereignisses getroffen werden. Die Lage der IT-R¨aume im Geb¨aude ist von großer Bedeutung. Im Erdgeschoss liegende R¨aume sind von außen leichter zug¨anglich (vor allem wenn Fenster vorhanden sind) als R¨aume in h¨oheren Geschossen. IT-R¨aume in Kellern m¨ ussen eventuell gegen Hochwasser gesch¨ utzt werden. S¨amtliche baulichen Maßnahmen m¨ ussen eine ¨ Aquivalenz aufweisen. Eine T¨ ur der Klasse ET3 ist wenig sinnvoll, wenn die angrenzenden W¨ande nicht aus Kalksandstein, sondern aus Gipskarton bestehen. Fenster k¨onnen ¨ z.B. mit einer Offnungs¨ uberwachung, Alarmdrahtspinnen, Metallgittern sowie durchwurfoder durchschusshemmendem Glas ausgestattet werden. Eine sicherheitstechnische elek¨ tronische Uberwachung ist immer dann sinnvoll, wenn die zu sichernden Bereiche nicht 182 Unter IT-R¨aumen werden hier die R¨ aume verstanden, die die IT (Server, Switche, Telekommunikationsanlagen etc.) beherbergen. 183 Vgl. Hohe/Matz 1999: 234ff.; Friedl 1998: 21ff. Andere Gef¨ ahrdungen, wie Wasser, Einbruch/Diebstahl oder Sturm sind ebenfalls zu ber¨ ucksichtigen. 184 Vgl. Friedl 1998: 28f.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

61

¨ st¨andig bewacht werden.185 Uberwachungssysteme sollten stets mit einer Einbruch- und Brandmeldezentrale (EMZ bzw. BMZ) verbunden sein. Brandschutzbestimmungen beeinflussen die bauliche und mechanische Infrastruktur, da Zufahrten, Fluchtwege oder M¨oglichkeiten zur Anleiterung entsprechend anzulegen sind. Des Weiteren legen Brandschutzbestimmungen die einzuhaltenden Brandlasten fest oder schreiben vor, welche Gase in automatischen L¨oschanlagen verwendet werden d¨ urfen und welche nicht.186 Die Verkabelung (Daten- und Elektrizit¨atsleitungen) sollte in Kabelsch¨achten verlegt sein, welche ein Mindestmaß an Feuerbest¨andigkeit (F 30 bis F 90)187 und ordungsgem¨aß ausgef¨ uhrte Brandschottungen aufweisen. Weiterhin ist darauf zu achten, dass z.B. Askareltransformatoren oder PVC-haltige Kabelummantelungen bei Br¨anden extrem gesundheitsgef¨ahrliche Stoffe, z.B. Dioxine, freisetzen k¨onnen.188 Dies gef¨ahrdet m¨oglicherweise nicht nur die Gesundheit der Mitarbeiter und Einsatzkr¨afte, sondern kann auch zu l¨angeren Betriebsunterbrechungen durch eine notwendige Dekontamination f¨ uhren. Korrosive Gase k¨onnen elektronische Bauteile und Platinen massiv belasten und diese sogar zerst¨oren.189 Die Auswahl der Datenkabel hat Einfluss auf die Angriffsm¨oglichkeiten. Kupferkabel besitzen eine elekromagnetische Abstrahlung und es lassen sich – vorausgesetzt, dass ein physikalischer Zugriff auf das Kabel vorhanden ist – vergleichsweise einfach Ger¨ate unbefugt in ein Netzwerk integrieren. Glasfaserkabel besitzen hingegen keine elektromagnetische Abstrahlung und die Integration unbefugter Ger¨ate in den Leitungsstrang (z.B. 185 Der Einsatz von Kameras sollte stets genau geplant werden. Wenn die dazugeh¨origen Monitore nicht 24/7 u ¨ berwacht, sondern nur Kamerabilder aufgezeichnet werden, dann kann dies nur dazu dienen, ¨ Einbr¨ uche oder Einbruchsversuche zu dokumentieren. Falls die Bilder der Uberwachungskameras kontinuierlich u ¨ berwacht werden, so ist darauf zu achten, dass keine toten Winkel durch die Anordnung der Kameras entstehen und die u achen gut ausgeleuchtet sind. ¨ berwachten Fl¨ 186 Bestimmte Gase, wie z.B. Halone, sind in Brandl¨ oschanlagen verboten, andere inerte Gase oder Gasgemische, wie Argon, FM200 oder Inergen, erlaubt. 187 Es existiert ein erheblicher Unterschied zwischen F 90 nach Deutsches Institut f¨ ur Normung e.V. (DIN) 4102 und nach Europ¨aischer Norm (EN) 1047-2. Die DIN 4102 besagt, dass eine F 90 Brandschutzwand einem Brand mit einer Temperatur von ca. 1100˚C 90 Minuten standhalten muss. Die Temperatur des Raumes auf der gegen¨ uberliegenden Seite der Wand wird nicht weiter ber¨ ucksichtigt, obwohl die Temperatur dort bis zu 200˚C ansteigen und die Brandschutzwand, je nach Alter der Bausubstanz, ganz erhebliche Mengen an Wasser absondern kann. Demgegen¨ uber ber¨ ucksichtigt die EN 1047-2 die Raumtemperatur durch die maximalen Belastungswerte f¨ ur Systeme mit einer max. Temperatur von 70˚C und einer maximalen Luftfeuchtigkeit von 85%. 188 Vgl. Friedl 1998: 9. 189 Bei der Verbrennung von 1 kg PVC (z.B. aus Kabelummantelungen) kann ein Raumvolumen von 5.800 m3 mit korrosiv wirkenden Gasen verunreinigt werden, da in PVC ca. 55% Chlor enthalten ist, welches sich als Chlorwasserstoffs¨ aure (HCl, Salzs¨ aure) ab einer Temperatur von 120˚C abspaltet. Dieses Gasgemisch wirkt bereits ab einer Konzentration von 5% korrosiv.

62

2 IT-Sicherheit in Unternehmungen

mittels eines Y-Kabels) erfordert ein h¨oheres Maß an Know-how und Equipment. Wenn Kabelstr¨ange in der Vertikalen (in Steigleitungen) gef¨ uhrt werden, so sind diese unter Umst¨anden gegen Durchsteigen zu sichern, damit ein Angreifer die Sch¨achte nicht daf¨ ur nutzen kann, um in gesch¨ utzte Bereiche auf anderen Etagen vorzudringen. Es ist sinnvoll ein physikalisch getrenntes Netzwerk f¨ ur Produktions- und B¨ uroumgebungen zu schaffen, um z.B. die Verbreitung von b¨osartiger Software (sog. Malicious Software oder kurz Malware) auf Systeme in der Produktion (beispielsweise Industrieroboter) zu verhindern.190 Es existieren mehrere Normen, nach denen sich Planer und IT-Sicherheitsverantwortliche richten k¨onnen bzw. m¨ ussen – darunter auch solche, welche L¨osungen oder Produkte in Sicherheitsklassen einteilen. Der Verband der Schadenversicherer (VdS) unterscheidet zwischen drei Kategorien, A bis C, wobei Klasse C die h¨ochsten und Klasse A die niedrigsten Anforderungen stellt. Der Einsatz von L¨osungen oder Produkten der Klasse C wirkt sich dementsprechend positiver auf Versicherungspr¨amien aus als der Einsatz von L¨osungen oder Produkten der Klasse A. Weitere Normen und gesetzliche Vorgaben, z.B. DIN 18095 Teil 2 (Rauchschutzt¨ uren), EN 1047-1/2 (Klassifizierung und Methoden zur Pr¨ ufung des Widerstandes gegen Brand) oder die Normenreihe EN V 1627ff. (Anforderungen und Klassifizierungen einbruchhemmender Bauelemente), k¨onnen Architekten, IT-Sicherheitsverantwortlichen und anderen Projektbeteiligten bei der Planung und Umsetzung von physikalischer Sicherheit behilflich sein. Je nachdem, welchen Stellenwert die IT-Infrastruktur f¨ ur die Prozesse und den Erfolg der Unternehmung einnimmt, kann es notwendig sein, Teile oder die Summe der zentralen IT redundant vorzuhalten. Dabei wird unterschieden zwischen internem und externem Backup. Letzteres kann unterteilt werden in die Kategorien kaltes, warmes und heißes Backup-Rechenzentrum. Ein internes Backup bezeichnet in diesem Fall den Vorhalt eines identischen Systems am selben Standort wie z.B. einen Server mit einer Applikation oder die Replikation einer Datenbank auf einen anderen Server. Dies bietet Redundanz vor Ort, sch¨ utzt aber nicht vor gr¨oßeren Katastrophenf¨allen, die die IT vor Ort in ihrer Gesamtheit betreffen. Ein externes Backup-Rechenzentrum, welches sich an einem anderen Standort befindet, kann derartige Risiken wesentlich reduzieren.191 Ein kaltes Backup-Rechenzentrum kann z.B. aus einem Raum bestehen, der die notwendigen infrastrukturellen Voraussetzun190 Der Ursprung in der Verbreitung von Malware findet sich h¨ aufig in B¨ uroumgebungen. 191 Die Entfernung zwischen einem Rechenzentrum und dem dazugeh¨origen Backup-Rechenzentrum ist in der Praxis unterschiedlich ausgepr¨ agt und von der Risikolage abh¨angig. So besitzen manche Unternehmungen ein Backup-Rechenzentrum, welches sich auf einem anderen Kontinent als das Rechenzentrum befindet. Dadurch sind die Daten der Unternehmung vor vielen denkbaren Katastrophen, wie z.B. Naturkatastrophen, wie der Hurrikan Katrina, oder milit¨arischen Operationen, gesch¨ utzt.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

63

gen wie Klimaanlage, Datenleitungen, Doppelboden, Stromversorgung und entsprechende EDV-Stellfl¨ache bietet. Dieser Raum kann anderweitig genutzt werden, muss aber im Katastrophenfall schnell ger¨aumt werden k¨onnen, um Ersatzger¨ate aufzustellen. Die Beschaffung der Ger¨ate muss vorher pr¨azise geplant werden.192 Die Wartungskosten f¨ ur ein kaltes Backup-Rechenzentrum sind relativ gering. Eine weitere L¨osungsm¨oglichkeit stellen die mobilen Rechenzentren dar (z.B. in Containern), die innerhalb weniger Stunden oder Tage vor Ort einsatzbereit sein k¨onnen. Je nach Gr¨oße betr¨agt die Aufbauzeit inklusive Anfahrt ca. 24 bis 120 Stunden.193 Hinzu kommen Aufbau- und Anlaufzeit f¨ ur die EDVGer¨ate. Nachteilig an einem kalten Backup-Rechenzentrum sind die hohen Mietkosten, die relativ lange Aufbauphase, die komplexe Planung und Umsetzung der Hardwarebeschaffung sowie die impraktikable Durchf¨ uhrung von Katastrophen¨ ubungen. Ein warmes Backup-Rechenzentrum verf¨ ugt u ¨ ber kompatible Hardware, die teilweise anderweitig genutzt werden kann. Im Katastrophenfall werden die bisher genutzten Systeme und Anwendungen auf das notwendigste reduziert oder abgeschaltet. Einige Serviceanbieter haben sich darauf spezialisiert, warme Backup-Rechenzentren Kunden anzubieten. Daf¨ ur fallen in der Regel Vorhaltegeb¨ uhren und Geb¨ uhren f¨ ur den Nutzungsfall an. Das heiße Backup-Rechenzentrum ist die kostenintensivste Form der Katastrophenvorsorge. Es wird ein Rechenzentrum samt Hardware vorgehalten und im Idealfall werden die Daten des Rechenzentrums in das Backup-Rechenzentrum permanent oder zyklisch repliziert. Die Ausgestaltung mechanischer oder baulicher Infrastrukturen oder der Katastrophenfallvorsorge h¨angt maßgeblich von den zu sichernden Werten ab. Nicht jeder EDV-Raum muss gegen das Einbringen von gef¨ahrlichen (z.B. ¨atzenden) Gasen gesch¨ utzt werden und nicht jedes Rechenzentrum muss mit Zwangsvereinzelungsschleusen ausgestattet werden oder ein heißes Backup-Rechenzentrum vorhalten. Dies zu eruieren, ist die Aufgabe einer detaillierten Risikoanalyse. Die Zugangskontrolle findet durch Authentifikation anhand von Merkmalen statt. Die G¨ ute der Authentifizierung richtet sich nach der Anzahl und Kombination von Merkmalen. Authentifikationsmerkmale k¨onnen sein: • Wissen (z.B. Passwort oder PIN), • Besitz (z.B. Hardware-Token, elektronisch lesbarer Ausweis oder Signaturkarte), • Eigenschaft (biometrische Eigenschaften wie z.B. Fingerabdruck oder Handgeometrie) und 192 Es gilt z.B. die Frage zu kl¨ aren, welcher Lieferant die erforderlichen Ger¨ate innerhalb kurzer Fristen beschaffen kann. 193 Vgl. Friedl 1998: 220.

64

2 IT-Sicherheit in Unternehmungen

• Dimension (z.B. zeitliche oder r¨aumliche Einschr¨ankungen, transaktionsbasierte Einschr¨ankung). Diese vier unterschiedlichen Merkmalsklassen werden auch als Faktoren bezeichnet – eine Kombination aus Wissen und Besitz wird demnach als Zwei-Faktor-Authentifikation bezeichnet und gilt als starke Authentifikation. Authentifikationen k¨onnen in mehrere Klassen eingeteilt werden, je nachdem, welche Merkmale in welcher Kombination auf ihre Korrektheit u uft werden. Es ist sinnvoll, solche Authentifikationsklassen mit der ¨berpr¨ Datenklassifizierung zu verkn¨ upfen, um nicht bei jedem weiteren System eine erneute Analyse erstellen zu m¨ ussen. Die Tabelle 2.6 zeigt eine m¨ogliche Variante. Authentifikationsklasse

Datenklassifizierung

Sehr schwache Authentifikation

¨ Offentlich

Authentifikationsmerkmale

• Selbst definierte User-ID mit Passwort • Zentral definierte User-ID mit Passwort

Schwache Authentifikation

Intern • Softwarezertifikat mit Passphrase • Hardware-Token

Starke Authentifikattion

Vertraulich • Passwort und Hardwaretoken mit PIN-Pad • Qualifizierte oder fortgeschrittene Signatur mittels PKIKarte

Sehr starke Authentifikation

Geheim • Passwort und Hardwaretoken mit PIN-Pad und zeitlicher Einschr¨ ankung/biometrischem Merkmal • Qualifizierte oder fortgeschrittene Signatur mittels PKIKarte und biometrischem Merkmal

Tabelle 2.6: Authentifikationsklassen in Kombination mit einer Datenklassifizierung Vertrauliche Informationen sollten generell nur nach mindestens einer Zwei-Faktor-, geheime Informationen nur nach mindestens einer Zwei-Faktor- oder sogar Drei-FaktorAuthentifikation zur Verf¨ ugung stehen.194 Je h¨oher die Anzahl der Faktoren, desto besser ist der Zugang gesch¨ utzt. Dies gilt nat¨ urlich nur solange, wie die Merkmale eine gewisse 194 Aufgrund des Risikos, dass Passw¨ orter ausspioniert werden k¨ onnen (z.B. durch das sog. Phishing), ist die Kombination einer E-Mailadresse und eines Passwortes f¨ ur einen Zugriff auf ein gesch¨ utztes System aus Sicht der aktuellen Rechtsprechung nicht ausreichend. Vgl. dazu u.a. Arbeitsgericht Erfurt, Urteil

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

65

Resistenz gegen Plagiate (also Einzigartigkeit) aufweisen und ein verantwortungsvoller Umgang den Diebstahl respektive das Aussp¨ahen verhindern. Plagiate bzw. Einzigartigkeit sind vor allem in der Biometrie von Bedeutung. Biometrische Merkmale195 weisen in ¨ der Uberpr¨ ufung eine False Acceptance Rate (FAR, Akzeptanz des Merkmals, obwohl es falsch ist) und eine False Rejection Rate (FRR, Ablehnung, obwohl das Merkmal echt ist) auf, die sich erheblich unterscheiden k¨onnen, je nachdem welches Merkmal von welchem Produkt u uft wird. Umfangreiche Studien mit Feldtests wie z.B. BioP I und BioP II ¨berpr¨ des BSI haben gezeigt, dass viele Systeme nicht unmittelbar f¨ ur alle Einsatzzwecke geeignet sind. Ein System mit einer FAR von 0,1 Prozent gilt in einem realistischen Einsatzszenario als akzeptables Sicherheitsniveau.196 Die Studie BioP II hat gezeigt, dass in der Praxis bei einer FAR von 0,1% eine FRR von 0,6% bis 23,4% auftritt.197 Dies bedeutet, dass im gravierendsten Fall nahezu jede vierte Person nicht korrekt verifiziert und abgewiesen wird. Die BioP II Studie hat ausschließlich 1-zu-1-Verifikationen zugelassen, d.h. dass sich jeder Nutzer an einem System identifiziert und exakt diese eine Identit¨at anhand von biometrischen Merkmalen verifiziert wird. Die FRR kann bei 1-zu-n-Identifikationssystemen mit einer großen Anzahl von Nutzern wesentlich h¨oher ausfallen.198 Des Weiteren existiert eine Failure-To-Enrol Rate (FTE), die angibt, wie hoch der Anteil von Personen ist, die nicht von einem biometrischen System erfasst werden konnten. Dies ist z.B. bei geringer Merkmalsauspr¨agung m¨oglich. Mehrere Publikationen aus Hackerkreisen lassen darauf schließen, dass viele Fingerabdruckscanner nur bedingt hohen Sicherheitsanforderungen gen¨ ugen, da sie im Allgemeinen leicht zu umgehen sind. Die Authentifikation anhand von biometrischen Merkmalen eignet sich eher f¨ ur geschlossene Nutzergruppen mittleren Umfangs, da beispielsweise eine FRR von nur 2% bei 1000 Nutzern 20 Nutzer zu Unrecht abweist und manuelle Nachkontrollen erfordert.

vom 14. September 2001, Wiebe 2002; Landgericht Bonn, Urteil vom 19. Dezember 2003, Mankowski 2004; Landgericht Magdeburg, Urteil vom 21. Oktober 2003, Winter 2005. 195 In der Praxis werden am h¨ aufigsten Gesichtserkennung, Fingerabdruck- und Handgeometriescanner verwendet. Iris- und Retinascanner werden nur selten eingesetzt, w¨ahrend Handschriften- oder Stimmerkennung im praktischen Einsatz nahezu keine Rolle spielen. 196 Vgl. BSI 2005a: 149. Dies bedeutet, dass eine von tausend Personen als berechtigt akzeptiert wird, obwohl sie nicht die erforderlichen Merkmale aufweist. F¨ ur sensible oder hochsensible Bereiche ist eine FAR von 0,1 Prozent jedoch zu gering. 197 Vgl. BSI 2005a: 120. Die hier verwendeten Prozentangaben erstrecken sich u ¨ ber alle Nutzerprofile. Wenignutzer erzeugen i.d.R. h¨ ohere FRRs als Vielnutzer. 198 1-zu-n Systeme identifizieren eine Person, ohne dass diese sich vorab zu erkennen gibt, d.h., dass das System die Person im unvorteilhaftesten Fall gegen alle zur Verf¨ ugung stehenden Profile pr¨ ufen muss. Die Grundlagen von biometrischen Systemen werden ausf¨ uhrlich z.B. bei Behrens/Roth 2001a dargestellt.

66

2 IT-Sicherheit in Unternehmungen

Weitere Authentikationsprotokolle, -dienste oder -konzepte wie z.B. Kerberos, RADIUS, SESAME, One-Time-Password, Single-Sign-On oder Challenge-Response-Verfahren werden hier nicht n¨aher betrachtet.199 Software und Appliances k¨onnen die drei klassischen Schutzziele der IT-Sicherheit, Integrit¨at, Vertraulichkeit und Verf¨ ugbarkeit, unter anderem durch folgende L¨osungsm¨oglichkeiten unterst¨ utzen: • Integrit¨at: Digitale Signaturen, Hashwerte, Checksummen. • Vertraulichkeit: Verschl¨ usselung, Berechtigungskonzepte, Authentifikationsverfahren. • Verf¨ugbarkeit: Redundanz, Load Balancing, Datensicherung, Disaster Recovery Management. Digitale Signaturen und Verschl¨ usselung basieren auf kryptografischen Methoden, auf deren Funktionsweise hier nicht n¨aher eingegangen wird.200 Es kann zwischen drei Klassen von Verschl¨ usselungsverfahren unterschieden werden: Symmetrische, asymmetrische und hybride Verfahren. • Symmetrische Verfahren (oder auch Secret-Key-Kryptografie) arbeiten mit zwei identischen Schl¨ usseln, die von den Beteiligten gegen unbefugte Einsichtnahme gesch¨ utzt werden m¨ ussen. Jeder Akteur, der den Schl¨ ussel besitzt, kann die Kommunikation entschl¨ usseln. Verbreitete Verfahren sind Blockchiffren wie der Data Encryption Standard (DES), 3DES, Advanced Encryption Standard (AES) und die Stromchiffre Ron’s Cipher 4 (RC4). • Asymmetrische Verfahren (oder auch Public-Key-Kryptografie) nutzen zwei verschiedene Schl¨ ussel: einen ¨offentlichen und einen privaten Schl¨ ussel. Der ¨offentliche Schl¨ ussel muss nicht geheim gehalten werden, sondern wird in der Regel ¨offentlich publiziert. Er wird vom Sender genutzt, um die Informationen f¨ ur den Empf¨anger zu chiffrieren. Der Empf¨anger kann die Informationen mittels des geheim zu haltenden privaten Schl¨ ussels dechiffrieren. Verbreitete Verfahren sind RSA (benannt nach den Erfindern Rivest, Shamir und Adleman), Diffie-Hellmann und Elliptic Curve Cryptography (ECC). • Hybride Verfahren nutzen den Geschwindigkeitsvorteil von symmetrischen Verfahren und das sichere Schl¨ usselaustauschverfahren der asymmetrischen Kryptogra199 Vertiefend hierzu Eckert 2004: 437ff.; Meyers/Harris 2003: 66ff. 200 Es handelt sich um mathematische Methoden, die im Wesentlichen auf dem Problem der Faktorisierung des Produkts zweier großer Primzahlen oder dem diskreten Logarithmusproblem beruhen. Vertiefend dazu vgl. Schneier 1996; Menezes/Oorschot/Vanstone 1997. Eine Einf¨ uhrung findet sich z.B. bei Schmeh 2001 oder Eckert 2004: 281ff.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

67

¨ fie.201 Uber eine asymmetrische Verschl¨ usselung wird ein Sitzungsschl¨ ussel (Session Key) f¨ ur ein symmetrisches Verfahren u bermittelt, mit dem die weiteren Nutzdaten ¨ verschl¨ usselt werden. Diese Kombination aus zwei Verfahren wird h¨aufig im Internet eingesetzt, beispielsweise bei dem Secure Socket Layer (SSL). Des Weiteren existieren sogenannte Hashfunktionen, wie z.B. RACE Integrity Primitives Evaluation Message Digest 160 (RIPEMD-160) oder Secure Hash Algorithm 1 (SHA1). Diese berechnen eine komprimierte Repr¨asentation elektronischer Daten. Die Verarbeitung durch die Hashfunktion ergibt einen Hashwert oder auch Message Digest, der, abh¨angig vom Algorithmus, immer dieselbe L¨ange aufweist. Hashfunktionen sind sogenannte Einwegfunktionen, d.h. es sind keine inhaltlichen R¨ uckschl¨ usse vom Hashwert auf den Inhalt des Quelldokumentes m¨oglich. Hashfunktionen werden zur Signierung von elektronischen Dokumenten (digitale Signatur) ben¨otigt. Notwendige Eigenschaften einer Hashfunktion sind:202 • Kollisionsfreiheit (es darf nicht effizient m¨oglich sein, zwei Texte mit gleichem Hashwert zu finden), • Einwegfunktionalit¨at (keine inverse Funktion, d.h. es darf nicht effizient m¨oglich sein, zu einem gegebenen Hashwert die Ursprungsdaten zu finden), • Kompression (die Ausgabe ist stets ein Wert gleicher L¨ange) und • Pseudozuf¨alligkeit (¨ahnliche Texte m¨ ussen v¨ollig unterschiedliche Hashwerte ergeben). Die unterschiedlichen mathematischen Algorithmen zur Verschl¨ usselung und/oder Signierung von Informationen sind nicht alle gleichwertig. So wurden z.B. in der Hashfunktion MD4 ebenso wie in ihrem Nachfolger MD5 signifikante Schwachstellen entdeckt, die eine weitere Verwendung dieses Algorithmus’ nicht ratsam erscheinen lassen.203 Bedeutsam ist neben dem Verfahren die Schl¨ ussell¨ange. Ein symmetrisches Verfahren wie der DES Algorithmus mit 56 Bit Schl¨ ussell¨ange gilt heutzutage als unsicher, war jedoch das symmetrische Standardverfahren in den 1980er und 1990er Jahren. Die gestiegene Rechenleistung moderner Prozessoren und deren breite Verf¨ ugbarkeit erm¨oglichte es, DES-Schl¨ ussel 201 In Softwarerealisierung sind symmetrische Verfahren ca. 100 mal schneller, als asymmetrische Verfahren. Eine hardwarerealisierte symmetrische Verschl¨ usselung kann um den Faktor 1000 schneller sein, als ein vergleichbares asymmetrisches Verfahren. Vgl. Eckert 2004: 335. ¨ 202 Ahnlich dazu Hoppe/Prieß 2003: 101f.; Eckert 2004: 354ff.; Schmeh 2001: 133ff. 203 Es muss unterschieden werden zwischen einer Kollisionsattacke und einem Pre-Image-Angriff. Ein gutes Hashverfahren sollte u.a. kollisionsfrei sein, das bedeutet, dass zwei unterschiedliche Nachrichten niemals denselben Hashwert erzeugen d¨ urfen. Weitaus gef¨ ahrlicher w¨are ein erfolgreicher Pre-ImageAngriff, bei dem ein gegebener Text einen gew¨ unschten Hashwert erzeugt. Eine Schwachstelle muss jedoch nicht gleichzeitig bedeuten, dass das Verfahren obsolet ist. Vgl. Schneier 2005.

68

2 IT-Sicherheit in Unternehmungen

mittels Brute-Force-Attacken204 zu recherchieren. Neue symmetrische Verfahren wie der AES arbeiten mit Schl¨ ussell¨angen bis zu 256 Bit, welche mit Brute-Force-Attacken auf Grund des großen Schl¨ usselraumes nicht sinnvoll angreifbar sind.205 Die Verwendung des asymmetrischen RSA-Verfahrens mit einer Schl¨ ussell¨ange von 512 Bit wird seit geraumer Zeit ebenfalls nicht mehr empfohlen. Es sollten generell nur offengelegte und von der Fach¨offentlichkeit gepr¨ ufte Verfahren eingesetzt werden.206 Kriterien f¨ ur ein gutes Verschl¨ usselungsverfahren sind gute Implementierbarkeit, hinreichende Geschwindigkeit, großer Schl¨ usselraum, gute Diffusion der Klartext- und Schl¨ ussel-Bits, Bestehen statistischer Tests und kryptanalytischer Angriffe und Resistenz gegen bekannte Attacken.207 Eine Verschl¨ usselung kann auf verschiedenen Verbindungsarten durchgef¨ uhrt werden: Punkt-zu-Punkt, Punkt-zu-Netz oder Netz-zu-Netz. Diese verschl¨ usseln mindestens die Nutzdaten einer Verbindung und werden als sogenannte virtuelle private Netzwerke (VPN) bezeichnet, welche auf Protokollebene ein privates Netzwerk auf Basis von tempor¨aren Verbindungen mit nicht-statischen Routen u ¨ber das Internet etablieren.208 Oftmals wird f¨ ur eine Punkt-zu-Netz- oder Netz-zu-Netz-Verbindung in gr¨oßeren Unternehmungen Internet Protocol Security (IPSec) als VPN-Protokoll verwendet, welches auf der Open Systems Interconnection Reference Modell (OSI) Schicht 3 (Vermittlungsschicht) etabliert ist.209 Durch die hohe Komplexit¨at ist IPSec fehleranf¨allig und Software und Appliances von verschiedenen Herstellern sind selten kompatibel zueinander. Als L¨osung f¨ ur insbesondere Punkt-zu-Punkt- und Punkt-zu-Netz-Verbindungen gewinnt SSL immer mehr Einfluss, welches transparent arbeitet und somit andere Protokolle ohne eigene Sicherheitsmechanismen – z.B. Hypertext Transfer Protcol (HTTP) oder Simple Mail Transfer Protocol (SMTP) – absichern kann. Dar¨ uber hinaus lassen sich Informationen (beispielsweise Dateien oder E-Mails) individuell f¨ ur bestimmte Empf¨anger nicht nur ver-

204 Systematisches Testen aller potenziellen L¨ osungen, sogenannte vollst¨andige Schl¨ usselsuche, z.B. AAA, AAB, AAC, etc. 205 Dies kann sich durch den Einsatz neuer Technik, wie z.B. Quantencomputer, ¨andern. 206 Dieser Hinweis findet sich auch im Grundschutzhandbuch des BSI. Das BSI nutzt jedoch in den SINAVerschl¨ usselungsboxen (u.a. im Einsatz in den deutschen diplomatischen Einrichtungen weltweit) ein eigenentwickeltes Verfahren namens Libelle. Das Kerckhoffs-Prinzip besagt, dass die Sicherheit eines kryptografischen Algorithmus’ auch dann gegeben sein soll, wenn dieser bekannt ist. Die Sicherheit definiert sich u ussels und nicht u ¨ ber die Geheimhaltung des Schl¨ ¨ ber die Geheimhaltung des Algorithmus’. Vgl. Hartung/Kutter 1999: 1080; Eckert 2003: 291. 207 Vgl. Eckert 2003: 299ff. 208 Vgl. Scott/Wolfe/Erwin 1999: 2; Clark 1999: 22ff. 209 Alternativ kann auch ein VPN auf der OSI-Schicht 2 eingesetzt werden. Die g¨angigen Protokolle sind das Point-to-Point Tunneling Protocol (PPTP) und das Layer 2 Tunneling Protocol (L2TP), vgl. Hoppe/Prieß 2003: 166f.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

69

bindungsorientiert verschl¨ usseln. Dies kann entweder mittels asymmetrischer oder auch symmetrischer Kryptografie durchgef¨ uhrt werden. Die Erstellung und Verwaltung von kryptografischen Schl¨ usseln f¨ ur gr¨oßere Unternehmungen obliegt in der Regel einer Public-Key-Infrastruktur (PKI). Solche Leistungen k¨onnen sowohl von Dritten zugekauft als auch selbst betrieben werden. F¨ ur große Unternehmungen ist es h¨aufig auf lange Sicht kosteng¨ unstiger, eine eigene PKI zu betreiben, wenn entsprechend viele kryptografische Schl¨ ussel und Zertifikate ben¨otigt werden.210 Verzichtet eine Unternehmung auf die Eigenerstellung der Leistung und bezieht diese von Dritten, dann ist darauf zu achten, dass der PKI-Betreiber die gesetzlichen Vorgaben zur Erstellung digitaler Signaturen (fortgeschrittene und/oder qualifizierte Signatur) beachtet. In einem Rechtsstreit z.B. u ultigkeit einer digitalen Transaktion kann die Gesetzes¨ ber die G¨ konformit¨at nach Signaturgesetz die Beweiskraft einer Signatur erheblich verbessern.211 Eine weitere Form von technischer IT-Sicherheit ist die Vermeidung von Manipulationsund Kopieroptionen f¨ ur den Endanwender. M¨oglich ist dies z.B. durch den Ausbau oder die Deaktivierung von Wechseldatentr¨agerlaufwerken und Schnittstellen (Floppy, CD-/DVD-Laufwerke, USB- oder externe SCSI-Schnittstellen), mit denen Anwender nicht freigegebene Software in Systeme einbringen oder Daten auf externe Medien kopieren k¨onnen. Dies l¨asst sich teilweise auch u ¨ber Berechtigungen realisieren.212 W¨ahrend eine Zugangskontrolle den Zugang zu Systemen, Applikationen und Diensten steuert, regelt eine Zugriffskontrolle u uhren) den Zugriff ¨ber Berechtigungen (lesen, schreiben, l¨oschen, ausf¨ auf einzelne Informationen, welche dem Nutzer durch die Authentifikation zugewiesen werden. Dabei sollte das Need-to-know -Prinzip Anwendung finden, nach dem der Nutzer nur den Zugriff erh¨alt, den er zur Erf¨ ullung seiner Aufgaben ben¨otigt. In den meisten F¨allen ergibt sich die Form der Zugriffskontrolle aus der Entscheidung f¨ ur ein Betriebssystem oder eine Nutzerverwaltung. Da jedoch immer mehr Software f¨ ur spezifische Einsatzzwecke maßgeschneidert wird oder werden muss (z.B. f¨ ur Migrationen), wird hier detaillierter auf die Grundlagen der Zugriffskontrolle eingegangen. Es existiert ein Klassifikationsschema f¨ ur Sicherheitsmodelle bez¨ uglich der Zugriffsbeschr¨ankungen (siehe Abb. 2.9). In der Abbildung werden die Modelle hinsichtlich ihrer F¨ahigkeit klassifiziert, Vertraulichkeits- und Integrit¨atsanforderungen umsetzen und flexibel anwendungsbezogende Anforderungen adaptieren zu k¨onnen.213 Die Dimensionen des 210 Die Fremderstellung der Leistung kann zu gr¨ oßeren Problemen f¨ uhren, wenn der PKI-Betreiber insolvent wird. Ein Automobilhersteller war von dieser Problematik betroffen. 211 In Abschnitt 5.5.1.2 wird dies ausf¨ uhrlicher dargestellt. 212 In diesem Zusammenhang existieren Applikationen, die Schnittstellen sperren oder u ¨ berwachen k¨onnen und selbst den versehentlichen oder versuchten Missbrauch an eine administrative Stelle melden. 213 Vergl. auch im Folgenden Eckert 2003: 239ff.

70

2 IT-Sicherheit in Unternehmungen

Klassifikationsschemas ergeben sich mit der Festlegung der agierenden Subjekte214 und abzusichernden Objekte, der potenziellen Erfassbarkeit von Zugriffsbeschr¨ankungen, der zu verwaltenden Zugriffsrechte und des Spektrums der modellierbaren Sicherheitsstraegien. Subjekte grob anwendungsspezifische Subjekte grob

Objekte 1 1 2 2 DAC RBAC

3 3 4 4

grobgranulare Objekte 3 1 3 3 1 3 4 2 4 4 2 4 DAC RBAC

MAC

Zugriffsstrategie

IF

3 3 4 4

DAC RBAC

MAC

Zugriffsstrategie

einfache Regeln IF = Informationsflussstrategie MAC = Manadatory Access Control

1 1 2 2

IF

Zugriffsrechte anwendungsspezifische Objekte 3 3 1 3 3 3 1 3 4 4 2 4 4 4 2 4 DAC RBAC

MAC

Zugriffsstrategie

komplexe Regeln

IF

3 3 4 4

universelle Rechte objektspezifische Rechte

MAC

Zugriffsstrategie

IF

einfache Regeln

DAC = Discretionary Access Control RBAC = Role Based Access Control

Modellklassen: 1: geringe Integrität, keine Vertraulichkeit 3: hohe Vertraulichkeit, geringe globale Integrität

2: hohe Integrität, keine Vertraulichkeit 4: hohe Vertraulichkeit, hohe Integrität

Abbildung 2.9: Klassifikationsschema f¨ ur Sicherheitsmodelle (Eckert 2003: 245) Grobk¨ornige Modellierung bedeutet f¨ ur Objekte, dass Zugriffskontrollen nur f¨ ur festgelegte zu sch¨ utzende Objekte durchgef¨ uhrt werden. Andere Objekte unterliegen keiner weiteren Kontrolle, was zu Sicherheitsl¨ ucken f¨ uhren kann. Diese Art der Modellierung dient eher der Gruppierung von Objekten und nicht der Invidualisierung. Die grobe Granularit¨at von Objekten auf Basis von Dateien hat den Vorteil, dass klassische Betriebssysteme die Zugriffsbeschr¨ankungen und -kontrollen effizient realisieren k¨onnen. Analog dazu bedeutet dies f¨ ur Subjekte die Zusammenfassung von Nutzern in Gruppen, ohne dass die individuellen Bed¨ urfnisse ber¨ ucksichtigt werden.215 Bei anwendungsspezifischen Objekten k¨onnen die zu Zugriffe und Beschr¨ankungen auf zu sch¨ utzende Objekte je nach Anwendung modelliert werden. Ebenso k¨onnen feingranulare Subjekte modelliert werden (z.B. u ¨ ber Access Control Lists, ACL), bei denen benutzerspezifische Zugriffsrechte anwendungsbezogen vergeben werden k¨onnen. Zugriffsrechte sind dann universell, wenn sie allgemein und nicht objektspezifisch sind wie z.B. Read- oder Write-Rechte f¨ ur Dateien. Objektspezifische Rechte k¨onnen hingegen die Zugriffsm¨oglichkeiten auf ein Objekt u ¨ber einen funktionalen Kontext festlegen. Dadurch kann das Objekt nur innerhalb der festgelegten Semantik einer Operation manipuliert 214 Der Terminus Subjekt ist hier im Sinne von Akteur zu verstehen und kann ebenso bedeuten, dass es sich um einen Prozess handelt. 215 In der Praxis werden in der Regel somit zu viele Rechte vergeben, was eine potenzielle Gef¨ahrdung der Sicherheit darstellt.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

71

werden. Die Zugriffsbeschr¨ankungen k¨onnen einfach oder komplex sein. Einfache Zugriffsbeschr¨ankungen definieren sich durch das Recht des Subjektes f¨ ur den Zugriff auf ein Objekt ohne weitere Bedingungen. Komplexe Beschr¨ankungen weisen zus¨atzliche Bedingungen auf, wie globale Bedingungen (z.B. Zugriff nur w¨ahrend des Arbeitszeitkorridors) oder objektlokale Bedingungen (z.B. Zugriff nicht h¨aufiger als dreimal pro Stunde). Bez¨ uglich der Sicherheitsstrategien l¨asst sich unterscheiden zwischen Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role Based Access Control (RBAC) und Informationsfluss-Strategien (IF).216 DAC ist ein offenes Modell, welches dem Eigent¨ umer eines Objekts erlaubt, zu bestimmen, wer wie auf dessen Ressourcen zugreifen kann. Prominentes Beispiel f¨ ur ein solches offenes DAC-Zugriffskontrollmodell sind die Windows-Plattformen von Microsoft. Charakteristisch f¨ ur DAC-Modelle ist, dass der Zugriff alleinig auf die Rolle und die Identit¨at des Anwenders ausgerichtet ist und nur der Objekteigent¨ umer bestimmt, wer die Ressource nutzt. Geschlossene Zugriffskontrollsysteme (MAC) weisen Objekten eine Sicherheitskennung (security label) zu und jedes Subjekt besitzt ein Freigabeniveau f¨ ur bestimmte Datenklassifizierungen (z.B. darf vertrauliche ” und geheime Informationen einsehen“). Die Freigabe des Subjekts muss gleich oder h¨oher sein als die Sicherheitskennung des Objektes. Dar¨ uber hinaus enth¨alt die Sicherheitskennung Kategorien, also Gruppen, denen das Subjekt angeh¨oren muss, um Zugriff zu erlangen. In rollenbasierten Zugriffskontrollmodellen (RBAC) wird nicht dem Subjekt ein Zugriff auf ein Objekt gew¨ahrt, sondern Rechte und Privilegien werden vordefinierten Rollen oder Gruppen u ¨bertragen, die diese Rechte an die ihnen zugewiesenen Subjekte ¨ implizit vererben. Ublicherweise orientieren sich die Rollen an den Funktionen und Positionen in Unternehmungen (z.B. Mitarbeiter Lohnbuchhaltung, Leiter der Produktion etc.). Nach der Entscheidung f¨ ur ein Zugriffsmodell (DAC, MAC oder RBAC) m¨ ussen potenzielle Zugriffskontrolltechniken betrachtet werden, die f¨ ur das jeweils gew¨ahlte Modell verf¨ ugbar sind. Als Zugriffskontrolltechniken gelten: • Eingeschr¨ankte Anwenderschnittstellen, • Zugriffs- und Berechtigungslisten, • inhaltsabh¨angige Zugriffskontrolle und • differenzierte Zugriffskontrollen. Eingeschr¨ankte Anwenderschnittstellen stellen dem Nutzer nicht die volle Funktionalit¨at eines Systems oder einer Applikation zur Verf¨ ugung. Beispiele hierf¨ ur sind die Benutzer216 Vgl. Meyers/Harris 2003: 86ff.; Eckert 2003: 242ff.

72

2 IT-Sicherheit in Unternehmungen

profile in Betriebssystemen, die relationale Sicht auf Datenbanken (sog. Database Views) oder physikalische Einschr¨ankungen der Funktionalit¨at wie bei Geldautomaten.217 Zugriffs- und Berechtigungslisten bilden Zugriffsrechte eines Subjektes auf ein Objekt ab. Eine Zugriffsmatrix zeigt in einer Tabelle die Rechte eines Subjektes (Berechtigungstabelle) auf die jeweiligen Objekte (Zugriffsliste). Die Summe der Rechte auf ein Objekt (Spalte) wird als Access Control List (ACL) bezeichnet (siehe Tab. 2.7). Subjekt Hr. Meier Fr. M¨ uller Fr. Schulz Prozess A

Datei 1 Lesen Lesen/Schreiben Vollzugriff Schreiben

Datei 2 Vollzugriff Lesen/Schreiben Lesen/Schreiben Lesen

Datei 3 Kein Zugriff Kein Zugriff Vollzugriff Kein Zugriff

Tabelle 2.7: Beispiel f¨ ur eine Zugriffskontrollmatrix Sicherheitsmodelle oder auch Zugriffskontrollmodelle218 wie Bell-La-Padula, ClarkWilson, Chinese Wall (Brewer-Nash), Informationsfluss oder Graham-Denning werden hier nicht weiter betrachtet.219 Weitere Maßnahmen zur Etablierung und Aufrechterhaltung der IT-Sicherheit in Unternehmungen sind der Einsatz von (pers¨onlichen und/oder zentralen) Firewalls, AntivirenSoftware (sowohl auf Gateways und Servern als auch auch auf Clients) und Intrusion Detection bzw. Intrusion Prevention Systemen (IDS bzw. IPS), welche unterst¨ utzend Angriffe erkennen und verhindern k¨onnen. Dazu geh¨oren auch weitere Maßnahmen wie ACLs, Ap¨ plikationen zur Uberpr¨ ufung der Passwortg¨ ute oder Leitungsverschl¨ usselung (OSI-Schicht 1), z.B. zwischen physikalisch getrennten Unternehmungsstandorten. Ein essenzieller Faktor in der Gestaltung der Sicherheitsmaßnahmen ist, dass diese aus mehreren Schichten bestehen (oft als Layered Security bezeichnet). Die Sicherheitsmaßnahmen einer Unternehmung d¨ urfen keinen Single Point of Failure“ aufweisen, dessen Ausfall die Sicherheit ” der Unternehmung maßgeblich gef¨ahrdet. Daher ist es ratsam, sich nicht auf eine einzelne Appliance zu verlassen, die IDS, Antivirus, Firewall, Spamfilter, SSL/VPN und andere Funktionen in einem Ger¨at kombiniert, sondern mehrere Ger¨ate einzusetzen, die jeweils monofunktional sind.220 Diese L¨osung ist zwar kostenintensiver, bietet jedoch mehr Si217 Vgl. Meyers/Harris 2003: 90f. Geldautomaten besitzen ein vollwertiges Betriebssystem (z.B. OS/2), aber lassen sich durch die ¨ offentlich zug¨angliche Nutzerschnittstelle (Tastatur) nur eingeschr¨ ankt nutzen. 218 Vgl. Meyers/Harris 2003: 132. 219 Vgl. weiterf¨ uhrend Eckert 2004: 261ff.; Schier 2000: 125ff.; Hoppe/Prieß 2003: 215ff. 220 Die Zusammenfassung von mehreren Funktionen in einer Appliance oder auf einer Plattform wird auch als Unified Threat Management (UTM) bezeichnet. Der Vorteil einer derartigen L¨ osung liegt in

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

73

cherheit, da der Ausfall eines Ger¨ates nur den Ausfall einer Funktion bedeutet. Eine geschichtete Sicherheit bedeutet zudem, unterschiedliche Produkte einzusetzen und das an verschiedenen Stellen. Es ist z.B. sinnvoll, zentrale Firewallkomponenten durch lokale Firewalls auf den Endger¨aten zu erg¨anzen. Eine Antiviren-L¨osung auf einem Gateway sollte nicht vom selben Hersteller sein wie die Antiviren-L¨osung auf den PCs der Endbenutzer. Sonst ist es sehr wahrscheinlich, dass ein Viruspattern, welches auf dem Gateway nicht erkannt wird, auch auf den Endger¨aten nicht erkannt wird, da der Hersteller in der Regel f¨ ur beide Produkte (nahezu) identische Virussignaturen verwendet. Zudem k¨onnen lokale Virenscanner auf manchen Systemen nicht verwendet werden. Einige Hersteller von Produktionssystemen definieren genau, welche Software auf den Steuerungssystemen vorhanden sein darf. Besonders in Systemen, die auf die zeitnahe Verarbeitung von Informationen (Realtime) angewiesen sind, werden lokale Virenscanner vom Systemhersteller nur selten zugelassen, da diese die Integrit¨at und Funktionalit¨at von propriet¨aren Systemen gef¨ahrden k¨onnen. Mehrere Untersuchungen best¨atigen den Trend, dass Viren, W¨ urmer und vor allem Trojaner st¨arker zielgerichtet verbreitet werden.221 Dazu geh¨oren zum Beispiel maßgeschneiderte Trojaner, die systematisch an Zielpersonen, -systeme oder -unternehmungen verschickt werden, um diese zu infiltrieren und an Informationen zu gelangen. Gegen solche individuell gestalteten Angriffe helfen Antivirusl¨osungen auf Basis von Virensignaturen nur begrenzt bis gar nicht. Sie sind nur dann hilfreich, wenn es sich bei der Malware um die Variante einer bereits bekannten Art handelt und die heuristische Erkennung dies registriert.222 Die Masseninfektionen mit Malware geh¨oren damit allerdings nicht der Vergangenheit an, sondern es ist zu bef¨ urchten, dass derartige Epidemien und Pandemien weiterhin auftreten werden. Die neue Variante, die weniger durch ungerichteten Vandalismus, sondern kriminelle Ziele gepr¨agt ist, ließe sich mit dem Oberbegriff Crimware (Criminal Software) bezeichnen. In vielen Industrien existiert ein Trade-Off zwischen der Time-to-Market und dem Reifegrad eines Produktes. Dies ist im Umfeld der IT-Sicherheit nur selten sinnvoll. Eine vorzeitige Inbetriebnahme eines Systems ohne die Etablierung von Sicherheitsmaßnahmen kann katastrophale Auswirkungen haben.

dem geringeren Administrationsaufwand und vor allem in der konsolidierten Logdateien-Analyse, vgl. Stiel 2005: 21ff. 221 Vgl. MessageLabs 2005. 222 Vgl. Knop 2006.

74

2 IT-Sicherheit in Unternehmungen

2.4.2 Organisatorische IT-Sicherheit Die organisatorische Sicherheit erg¨anzt die technische Sicherheit teilweise komplement¨ar. Dies l¨asst sich an folgendem Beispiel verdeutlichen: Die technische L¨osung, Informationen auf Bandlaufwerken als sog. Backup zu sichern, ist als isolierte Maßnahme wenig wirkungsvoll. Nur die Erg¨anzung durch Verfahrensanweisungen, die beschreiben, welche Daten (Selektion) wann (t¨aglich, w¨ochentlich, monatlich) und mit welchem Verfahren (inkrementell oder komplett) wo (Ort) zu sichern sind, kann das Sicherheitsniveau erh¨ohen. Dar¨ uber hinaus m¨ ussen Regelungen existieren, wie und wo die beschriebenen B¨ander abgelegt bzw. aufbewahrt werden.223 Dieses Beispiel verdeutlicht, dass eine Trennung von technischer und organisatorischer Sicherheit in vielen F¨allen nicht oder nur wenig trennscharf vorgenommen werden kann. Die Frage, ob eine Sicherung der Daten inkrementell oder als Vollbackup durchzuf¨ uhren ist, hat durchaus einen technischen Hintergrund, welcher die Wahl eines der Verfahren begr¨ undet. Die aus dieser Begr¨ undung entstehende Regelung oder Verfahrensanweisung ist jedoch organisatorischer Natur. Im weiteren Verlauf dieses Abschnitts werden die wichtigsten Themenbereiche in Unternehmungen vorgestellt, die einer organisatorischen Regelung bed¨ urfen. Grundlage der organisatorischen Regelungen ist die Datenklassifikation (siehe Tab. 2.1, S. 14), die Informationen nach ihrer Bedeutung und ihrem Wert gruppiert. Weitere Regelungen schaffen einen Bezug zum Schutz und Umgang mit diesen Werten, so z.B. die Verbindung von Datenklasse und Authenifizierungsverfahren. Fokus in allen Regelungen sollte stets der angemessene Umgang mit Informationen gem¨aß Datenklassifikation sein. Generell ist die Bildung von Klassen in Themenbereichen hilfreich, da so ein Baukastensystem mit standardisierten L¨osungen erarbeitet wird und als Entscheidungsgrundlage dienen kann. Eine technische L¨osung zur kryptografischen Verschl¨ usselung von Informationen muss immer durch eine organisatorische Richtlinie oder Verfahrensanweisung komplettiert werden, die den Einsatz und den Umgang mit der Technik regeln. So muss beispielsweise f¨ ur den Anwendern transparent dargestellt werden, welche Informationen zu verschl¨ usseln sind (z.B. gem¨aß Datenklassifikation). Des Weiteren muss f¨ ur Systemersteller (Programmierer, IT-Projektleiter, etc.) eine Regelung vorhanden sein, die die Auswahl kryptografischer Algorithmen eingrenzt und die zu nutzenden Schl¨ ussell¨angen – je nach Datenklassifikation – vorschreibt. Eine m¨ogliche Kombination zeigt die Tabelle 2.8.

223 Die B¨ander der Datensicherung (sog. Backup-Tapes) m¨ ussen physikalisch getrennt von den Ursprungsdaten aufbewahrt werden. Hierf¨ ur existieren spezielle feuerbest¨andige Schr¨anke, die idealerweise in einem anderen Geb¨aude oder Brandabschnitt aufgestellt werden sollten.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

Datenklassifikation ¨ Offentlich

75

Beschreibung des Verfahrens

Verschl¨ usselungsklasse

Keine Verschl¨ usselung

Keine Verschl¨ usselung

Intern • Symmetrische Verschl¨ usselung: 56-111 Bit

Schwache Verschl¨ usselung

• Asymmetrische Verschl¨ usselung: 512-1023 Bit • ECC: 128-159 Bit • Hashverfahren: MD 5 Vertraulich • Symmetrische Verschl¨ usselung: 112-256 Bit

Starke Verschl¨ usselung

• Asymmetrische Verschl¨ usselung: 1024-2048 Bit • ECC: 160-191 Bit • Hashverfahren: RIPEMD-160, SHA-1 Geheim • Symmetrische Verschl¨ usselung: ≥ 256 Bit

Sehr starke Verschl¨ usselung

• Asymmetrische Verschl¨ usselung: ≥ 2048 Bit • ECC: ≥ 192 Bit • Hashverfahren: SHA-2

Tabelle 2.8: Beispiel f¨ ur eine Kombination aus Datenklassifikation und kryptografischen Algorithmen/Schl¨ ussell¨angen Die Tabelle 2.8 dient als Beispiel. Sie ist nicht derart zu interpretieren, dass z.B. Informationen gem¨aß der Klassifikation intern immer nach dem angegebenen Verfahren ¨ verschl¨ usselt werden m¨ ussen. Vielmehr ist dies z.B. von der Ubertragungsstrecke (z.B. per E-Mail durch das Internet) und dem Empf¨anger abh¨angig. Zus¨atzlich zu der Tabelle m¨ ussen Algorithmen definiert werden, die in der Unternehmung eingesetzt werden d¨ urfen. Dies k¨onnten f¨ ur die symmetrische Verschl¨ usselung bspw. die Algorithmen AES, IDEA, 3DES, RC5 und Blowfish sein.

76

2 IT-Sicherheit in Unternehmungen

Die Einf¨ uhrung von Verschl¨ usselung in Unternehmungen oder u ¨ber Unternehmungsgrenzen hinaus birgt erhebliche Problempotenziale. Je gr¨oßer, geografisch verteilter und komplexer eine Unternehmung ist, desto schwieriger wird es, ad¨aquate Produkte zu finden und generell akzeptierte Prozesse zu etablieren. Zu den vorrangigen Bereichen, in denen Verschl¨ usselung eingesetzt wird, geh¨oren die E-Mail-, Laptop- und Datenbankverschl¨ usselung sowie die Verschl¨ usselung mobiler Datentr¨ager. Die Ende-zu-Ende-Verschl¨ usselung von E-Mails verhindert, dass zentrale Antivirus-L¨osungen auf Mailservern oder Gateways den Inhalt der Mails auf Malware kontrollieren k¨onnen. Der Anwender ist auf eine funktionsf¨ahige und aktuelle Antiviren-Software auf dem Client angewiesen. Des Weiteren ist eine Schl¨ usselhinterlegung (sog. Key Escrow) ratsam, damit auf den Inhalt verschl¨ usselter E-Mails auch im Falle des Verlustes des privaten Schl¨ ussels zugegriffen werden kann. Die Schl¨ ussel m¨ ussen so hinterlegt sein, dass Integrit¨at und Vertraulichkeit gewahrt sind und entsprechende Prozesse m¨ ussen sicherstellen, dass nur der Inhaber oder andere befugte Personen und Stellen (z.B. Revision) Zugriff erlangen k¨onnen. Dies ist ein grundlegendes Problem in allen Prozessen, in denen Verschl¨ usselungsverfahren eingesetzt werden. Problematisch kann sich auch die Langzeitarchivierung von elektronischen Dokumenten darstellen, wenn diese verschl¨ usselt oder digital signiert sind. Da Zertifikate in der Regel keine unbegrenzte G¨ ultigkeit aufweisen und kryptografische Algorithmen gebrochen werden bzw. bestimmte Schl¨ ussell¨angen eines Algorithmus’ nicht mehr hinreichend sicher sein k¨onnen, kann es notwendig sein, Archive umzuschl¨ usseln. Dies muss bei der Gestaltung entsprechender Systeme ber¨ ucksichtigt werden. F¨ ur die Laptopverschl¨ usselung m¨ ussen Prozesse definiert werden, wie mit dem Verlust von Authentifikationsmerkmalen (beispielsweise vergessene Passw¨orter oder verlorene Hardwaretokens) umgegangen wird, damit der Mitarbeiter z.B. bei l¨angeren Auslandsaufenthalten stets auf seine auf dem Laptop gespeicherten Daten zugreifen kann. Wenn mobile Datentr¨ager u ¨ber die Unternehmungsgrenzen hinaus transportiert werden, sollte deren Inhalt ebenfalls verschl¨ usselt werden, wenn der Informationsgehalt mindestens als vertraulich einzustufen ist. Dabei muss sichergestellt werden, dass der berechtigte Empf¨anger (und nur dieser) die Informationen entschl¨ usseln kann. Des Weiteren muss der Empf¨anger den privaten oder den symmetrischen Schl¨ ussel sicher aufbewahren. Dies ist vor allem dann problematisch, wenn der Empf¨anger aus Sicht des Informationseigent¨ umers (Sender) als Dritter betrachtet werden muss, er also nicht Mitarbeiter der Unternehmung des Senders ist. Falls Sicherheitsaudits nicht zu dem vertraglichen Umfang der Kooperation und den Rechten des Auftraggebers geh¨oren, muss der Informationsinhaber dem Auftragnehmer bez¨ uglich der sicheren Aufbewahrung von Schl¨ usseln und Informationen vertrauen.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

77

Ein immens wichtiger Bestandteil der IT-Sicherheit ist das Patchmanagement. Ein Patch ist eine Korrektur f¨ ur eine Software – z.B. eine Applikation oder ein Betriebssystem, mit der ein oder mehrere Fehler eliminiert werden. Besonders in Betriebssystemen k¨onnen fehlerhafte Bestandteile die Sicherheit gef¨ahrden und unter Umst¨anden einem Angreifer die vollst¨andige Kontrolle u ¨ber das System gew¨ahren.224 Im Folgenden wird unter dem Begriff Patch“ eine Behebung von Schwachstellen und Sicherheitsl¨ ucken in Software durch ” Verbesserung bzw. Aktualisierung verstanden. Herstellerseitig werden Patches zur Schließung bekannter potenzieller Sicherheitsl¨ ucken ver¨offentlicht – teilweise bevor und teilweise nachdem die Sicherheitsl¨ ucken ¨offentlich geworden sind. Es ist jedoch nicht sinnvoll, alle Patches direkt nach ihrer Ver¨offentlichung in die Systeme oder Appliances einzuspielen. Die verantwortliche Stelle in der Unternehmung muss u ¨ber den Einsatz in Abh¨angigkeit vom Risiko u ¨ ber die Verwendung des Patches entscheiden. In der Regel ist die verantwortliche Stelle in der Unternehmung jene Einheit, die die betroffenen Systeme betreibt. Optimal ist dieses Vorgehen in Kombination mit den IT-Sicherheitsverantwortlichen, die eine Risikobewertung gemeinsam mit der Betreiberstelle vornehmen. Die Informationen u ¨ber eine Sicherheitsl¨ ucke bzw. einen vorhandenen Patch erh¨alt die Unternehmung entweder u ¨ber den Hersteller der Software, einen darauf spezialisierten Dienstleister, ein Computer Emergency Response Team (CERT) oder u ¨ ber nicht-kommerzielle Mailing-Listen oder Foren im Internet. Es ist zu beachten, dass die Quelle f¨ ur einen Patch uneingeschr¨ankt vertrauensw¨ urdig sein sollte, damit keine Malware u ber einen Patch in die Unterneh¨ mungsnetzwerke gelangt. Große Unternehmungen besitzen im Allgemeinen eine sehr heterogene IT-Landschaft, d.h. dass Systeme stark in Hardware, Software, Konnektivit¨at und verwendeten Konfigurationen differieren. Eine verantwortliche Stelle in der Unternehmung muss eine Inventarisierung der verwendeten Hardware, eingesetzten Applikationen und deren Versionsst¨ande vornehmen und stets aktuell halten. Da dies bereits in mittelst¨andischen Unternehmungen nicht mehr sinnvoll h¨andisch zu erledigen ist, verwendet man in der Regel hostund/oder netzwerkbasierte Systeme, die diese Erfassung zyklisch durchf¨ uhren. Auf diese Weise l¨asst sich effizient feststellen, welche Systeme von einer Schwachstelle betroffen sind. Die Erstellung eines Patches – insbesondere bei gef¨ahrlichen Schwachstellen – geschieht unter starkem Zeitdruck, so dass die Softwarehersteller in der Regel wenig Zeit haben, den Patch sorgf¨altig f¨ ur viele potenzielle Konfigurationen zu testen. Daher muss gepr¨ uft werden, ob wirklich die Notwendigkeit gegeben ist, den Patch einzuspielen. Patches k¨onnen mitunter mehr Schaden als Nutzen anrichten, weil die Anzahl der m¨oglichen Interdependenzen von verwendeter Software und eingesetzten Konfigurationen die Testf¨ahigkeit der Softwarehersteller u ¨bersteigt und Patches teilweise selbst fehlerhaft sein k¨onnen. Patches 224 Ein Betriebssystem wie Windows 2000 von Microsoft besteht aus mehr als 35 Millionen Zeilen Code, vgl. Obert 2003: 26. Software in dieser Komplexit¨ at ist stets mit Fehlern behaftet.

78

2 IT-Sicherheit in Unternehmungen

sollten vor ihrer Verwendung stets auf die Kompatibilit¨at mit dem Zielsystem in einer Testumgebung u uft werden. Unternehmungen sollten zu diesem Zweck eine eigene ¨berpr¨ Testumgebung aufbauen, welche physikalisch von den Produktivsystemen getrennt und mit diesen weitestgehend identisch ist. Diese L¨osung ist, besonders in sehr heterogenen IT-Infrastrukturen, relativ kostenintensiv. Daher kann es von Vorteil sein, virtuelle Umgebungen zur Kontrolle der Interoperabilit¨at zu nutzen, welche das jeweilige Zielsystem in Software nachbilden. ¨ Bei der Uberpr¨ ufung der Notwendigkeit f¨ ur das Einspielen eines Patches k¨onnen sich eventuell Alternativen zur Beseitigung der Sicherheitsl¨ ucke erschließen, wie z.B. das Sperren einzelner Ports oder die Deaktivierung nicht zwingend ben¨otigter Dienste. Derartige L¨osungen k¨onnen auf manchen Systemen bis zu 50% aller Patchinstallationen vermeiden.225 Eine empirische Studie zum Thema Patchmanagement ergab, dass die beiden optimalen Zeitpunkte zur Installation eines Patches der zehnte und der 30. Tag nach Bekanntgabe einer Sicherheitsl¨ ucke sind.226 Der prototypische Ablauf des Patchmanagements bzw. des Patchprozesses kann sich folgendermaßen gestalten:227 • Einstufung der Relevanz der Applikation/des Dienstes f¨ ur den IT-Betrieb und den Unternehmungserfolg, • Definition von Verantwortlichen f¨ ur die jeweilig eingesetzte Software, • Evaluation der Patchbeschreibung und der Sicherheitsl¨ ucke, – Kontrolle, ob der Patch eingespielt werden muss, ob Alternativen oder bekannte Probleme existieren, – Pr¨ ufung der Abh¨angigkeiten, – Pr¨ ufung, ob das Verhalten der Komponente durch den Patch modifiziert wird, • Kl¨arung des Patchsupports bei Applikationen von Drittherstellern, • Test des Patches in Testumgebungen, • Vorbereitung des Rollouts auf die Produktivsysteme, • Unternehmungsweiter Rollout. Die ersten beiden Punkte des Vorgehens sollten bereits im Vorfeld festgelegt werden. Besondere Aufmerksamkeit verdienen die Kl¨arung des Patchsupports bei Applikationen von Drittherstellern sowie die Vorbereitung des Rollouts auf die Produktivsysteme. Einige 225 Vgl. Fr¨obe 2004: 4. 226 Vgl. Beattie/Arnold/Cowan et al. 2002: 109. 227 In Anlehnung an Fr¨obe 2004: 3.

2.4 Ausgew¨ahlte Aspekte und Maßnahmen zum Schutz von IuK-Systemen

79

Applikationen werden von ihren Herstellern ausschließlich f¨ ur den Betrieb auf speziell konfigurierten Plattformen ausgelegt.228 Unternehmungen riskieren den Verlust des Supportvertrages, wenn sie eigenm¨achtig einen vom Hersteller der Applikation nicht freigegebenen Patch einspielen.229 In der Regel testen die Hersteller der Applikation solche Patches zeitnah. Dennoch kann es bei Zero-Day-Exploits230 auf kritischen Systemen notwendig sein, diese sofort zu patchen oder andernfalls abzuschalten. Systeme sollten sog. Wartungsfenster aufweisen, also einen Zeitrahmen in dem Wartungsarbeiten durchgef¨ uhrt werden k¨onnen. W¨ahrend der Wartungsoperationen kann es vorkommen, dass das System nicht oder nur eingeschr¨ankt verf¨ ugbar ist. F¨ ur essenzielle Systeme, bei denen hohe Anforderungen an die Verf¨ ugbarkeit erforderlich ist, muss nach dem Patchen nicht nur die Stabilit¨at des Systems gew¨ahrleistet, sondern die Dienste sollten auch m¨oglichst ohne Neustart weiterhin verf¨ ugbar sein. In Umgebungen mit Lastenausgleich (Load Balancing) k¨onnen Systeme einzeln außerhalb der Hauptbelastungszeiten gewartet werden oder in Clusterumgebungen mittels Failover auf andere Systeme im Cluster umgeleitet werden, um Patches einzuspielen.231 Einige Systeme lassen sich nicht oder nur mit hohem Aufwand patchen. Dazu geh¨oren insbesondere propriet¨are Systeme in Produktionsumgebungen, die zum Teil auch eingebettete Betriebssysteme (Embedded Systems) nutzen. Des Weiteren existieren Produktionssysteme, die mit ¨alteren Betriebssystemen operieren, f¨ ur die die Unterst¨ utzung seitens des Betriebssystemherstellers nicht mehr existiert. Wenn in solchen F¨allen Verwundbarkeiten und Schwachstellen identifiziert werden, muss eine entsprechende L¨osung gefunden werden wie beispielsweise der Einsatz eines Sicherheitsgateways (z.B. Intrusion Prevention System und Firewall). Passw¨orter liegen zwischen organisatorischer und technischer IT-Sicherheit. Einerseits muss der Anwender aufgekl¨art werden, wie ein gutes Passwort gebildet wird und dass dieses geheim gehalten werden muss. Andererseits muss die Technik sicherstellen, dass Passw¨orter nicht im Klartext u ¨ber Datennetze u ¨bertragen werden und eine systemtechnische Unterst¨ utzung der Anwender hinsichtlich der Passwortg¨ ute232 erfolgt. Der fachgerechten sicherheitstechnischen Entsorgung von Datentr¨agern ist ein hohes Maß an Relevanz zuzumessen. Am Ende des Lebenszyklusses von Datentr¨agern m¨ ussen diese 228 Dabei handelt es sich im Allgemeinen um komplexe Applikationen oder Systeme, wie von SAP oder PeopleSoft, Firewalls oder Public-Key-Infrastrukturen. 229 Z.B. ein Patch f¨ ur ein Betriebssystem oder eine Datenbank, auf dem die Applikation l¨auft. 230 Bei Zero-Day-Exploits handelt es sich um Schwachstellen, die bei deren Bekanntgabe sofort ausgenutzt werden k¨onnen und somit ein betr¨ achtliches Risiko darstellen k¨ onnen. 231 Vgl. Johansson 2004. 232 Die Passwortg¨ ute bezeichnet die Qualit¨ at eines Passwortes, beispielweise eine Mindestl¨ange von x Zeichen und Vorgaben zur Verwendung und Anzahl von Buchstaben, Ziffern und Sonderzeichen.

80

2 IT-Sicherheit in Unternehmungen

entweder nach einer anerkannten Methode gel¨oscht oder physikalisch zerst¨ort werden. In einer Studie zur Datensicherheit wurden 100 Festplatten mit einer Gesamtkapazit¨at von 526 Gigabyte im Internet u ublicher ¨ber Auktionen ersteigert und es wurde mit handels¨ Software versucht, die enthaltenen Daten zu lesen bzw. zu rekonstruieren. Von 100 Festplatten waren 15 technisch defekt und zehn sicher gel¨oscht. Aus den restlichen 75 Festplatten ließen sich mehr 590.000 Dateien mit einer Gesamtgr¨oße von ca. 186 Gigabyte rekonstruieren, darunter eingescannte Unterschriften und Zeugnisse, Bankvollmachten, private und berufliche Emails, Originallizenzen f¨ ur Software, pornografisches Material, Musik- und Videodateien etc.. Dar¨ uber hinaus enthielt eine Festplatte, welche offensichtlich vorher bei einer gesetzlichen Krankenkasse im Einsatz war, Dienstanweisungen zu Kosten¨ ubernahmen, internen Mailverkehr, Unternehmungsstrategien sowie den Schrift¨ verkehr mit behandelnden Arzten einschließlich der Patientendaten.233 Als organisatorische Sicherheit l¨asst sich der gesamte Bereich der Vereinbarungen und Vertr¨age mit Mitarbeitern und Kooperationspartnern begreifen. Es ist unter anderem notwendig, die private Nutzung des Internets durch Mitarbeiter entweder strikt zu verbieten oder die Nutzungsbedingungen genau zu definieren. In diesem Zusammenhang m¨ ussen Mitarbeiter auf ihre Rechte und (Sicherheits- bzw. Sorgfalts-) Pflichten bez¨ uglich der Nutzung von Kommunikations- und Datennetzen sowie unternehmungseigenen Informationen, hingewiesen werden. Ebenso sollten Kooperationspartner auf die Sicherheitsregelwerke der Unternehmung und deren Einhaltung hingewiesen werden. Letzteres sollte sich schriftlich fixiert in den vertraglichen Kooperationsbedingungen niederschlagen. Ein zentraler und eminent wichtiger Bestandteil der organisatorischen Sicherheit ist ihre Integration in die Organisationsstrukturen. Die Leitung der Informationssicherheit obliegt im Allgemeinen dem Chief Information Security Officer (CISO), der derartige Belange in der Unternehmung vertritt. Idealerweise sollte der CISO weisungsunabh¨angig sein und direkt der Gesch¨aftsleitung respektive dem Vorstand berichten. Von einer Integration dieser Funktion in den Bereich Informationstechnologien mit Bericht an den Chief Information Officer (CIO) ist abzusehen, da der CISO den CIO in Teilbereichen kontrollieren muss und es zu Interessenskollisionen kommen kann. Sinnvoller ist es, die Funktion des IT-Sicherheitsbeauftragten in den Stab der Gesch¨aftsleitung einzugliedern. Die interne Revision ist hierf¨ ur nicht geeignet, da sie keine Richtlinien erl¨asst, deren Einhaltung sie ¨ selber pr¨ uft. Zudem ist sie durch das KonTraG auf die Uberpr¨ ufung des Risikomanagementsystems beschr¨ankt. Eine Stabsstelle kann dazu dienen, anderen Fachbereichen als kompetente Schnittstelle zur Verf¨ ugung zu stehen, alle Informationen zu b¨ undeln und zu bewerten und als direkter Ansprechpartner f¨ ur den (juristisch verantwortlichen) Vorstand zu fungieren. F¨ ur alle Bereiche der IT-Sicherheit m¨ ussen Verantwortlichkeiten, Berichts233 Vgl. Kehrer 2004: 3ff.

2.5 IT-Anwender

81

und ggf. Eskalationswege definiert werden. Die viel beschworene Formel IT-Sicherheit ” ist Chefsache“ bezieht sich auf die Tatsache, dass die Einf¨uhrung der IT-Sicherheit in Unternehmungen von der Gesch¨aftsleitung betrieben werden muss.234 Ohne die explizite Zustimmung und die Unterst¨ utzung des Managements sind die notwendigen Prozesse und Verantwortlichkeiten nur unter erheblichem Aufwand und mit zu erwartenden Widerst¨anden aus verschiedenen Unternehmungsbereichen zu etablieren.

2.4.3 Ganzheitliche IT-Sicherheit als Prozess Falls Sie glauben, dass Technologie Ihre Sicherheitsprobleme l¨osen kann, verstehen Sie ” die Probleme nicht, und Sie haben von Technologie keine Ahnung.“ 235 Diese Aussage des US-amerikanischen IT-Sicherheitsspezialisten Bruce Schneier soll belegen, dass die ITSicherheit in Unternehmungen stets ganzheitlich betrachtet werden muss. Dies beinhaltet die gegenseitige Unterst¨ utzung von technischen und organisatorischen Maßnahmen sowie die Betrachtung der signifikanten Unternehmungsprozesse. Die Informations- und Kommunikationstechnik in Unternehmungen ist in seiner Gesamtheit ein soziotechnisches System. Mensch-Maschine-Interaktionen sind ein wesentlicher Bestandteil dieses Gesamtsystems. Daher ist eine ganzheitliche Betrachtung der IT-Sicherheit vonn¨oten, d.h. organisatorische und technische Aspekte m¨ ussen stets gemeinsam betrachtet werden. IT-Sicherheit ist ein iterativer Prozess, dessen Ergebnisse kontinuierlich kontrolliert und reflektiert werden m¨ ussen.236 Es gilt unter anderem zu erarbeiten, ob sich die Werte der Unternehmung ver¨andert haben, ob neue Gef¨ahrdungen und Schwachstellen existieren und ob die bisherigen Maßnahmen zur Reduzierung von potenziellen Sch¨aden aktuell und angemessen sind. Weiterhin muss u uft werden, ob ¨berpr¨ beschlossene Maßnahmen ausnahmslos umgesetzt worden sind. Sicherheitsverantwortliche sollten stets die Risiken bei der Nicht-Umsetzung einer Maßnahme betrachten. Es gilt: In dubio pro securitate – im Zweifel f¨ ur die Sicherheit.

2.5 IT-Anwender Der Anwender ist im Kontext der IT-Sicherheit in Unternehmungen nicht nur eine Residualkategorie, sondern muss im Fokus der Betrachtung stehen. Die Sensibilit¨at der Nutzer f¨ ur den Themenbereich der IT-Sicherheit ist von zentraler Bedeutung, da ein Großteil 234 Vgl. M¨ uhlenbrock 2003: 150. 235 Schneier 2001: X. 236 Ein Projekt hat einen definierten Start und ein definiertes Ende. IT-Sicherheit kann zwar als Projekt initiiert werden, muss dann aber in einen Prozess u uhrt werden. Vgl. M¨ uhlenbrock 2003: 36. ¨berf¨

82

2 IT-Sicherheit in Unternehmungen

der IT-Sicherheitsverletzungen von Anwendern begangen wird. Dies geschieht nicht allein durch Vorsatz oder Fahrl¨assigkeit, sondern teilweise durch Unkenntnis. Es wird davon ausgegangen, dass bei Sicherheitsvorf¨allen der Anteil der Innent¨ater bei 55% bis 90% (je nach Studie) liegt.237 Eine Studie von ICM Research f¨ ur die Sicherheitsunternehmung McAfee hat unter anderem folgendes ergeben:238 • 51% aller Anwender verbinden ihre pers¨onlichen Ger¨ate (Mobiltelefone, PDAs, USBSticks, etc.) mit ihrem PC am Arbeitsplatz. • Mehr als 25% f¨ uhren dies jeden Tag durch. • Jeder f¨ unfte Anwender gew¨ahrt der Familie oder Freunden Zugriff auf das Internet u ¨ber unternehmungseigene PCs und Laptops. • Ca. 60% aller Anwender speichern private Daten auf dem PC am Arbeitsplatz. • Jeder zehnte Anwender gesteht ein, dass er Inhalte aus dem Internet l¨adt, von denen er weiß, dass er sie nicht herunterladen sollte. • Mehr als 60% geben zu, dass sie sehr wenig oder gar keine Kenntniss u ¨ber ITSicherheit haben. • Jeder zweite Anwender weiß nicht, wie er die Antiviren-Software bzw. deren Signaturen aktualisieren kann. • 5% sagen, dass sie Zugang zu Systemen h¨atten, zu denen sie keinen Zugang haben d¨ urften. Anwender sollten nicht nur zur Kenntnis nehmen, dass IT-Sicherheit ein strategisch wich¨ tiger Faktor zur Sicherung der Uberlebensf¨ ahigkeit einer Unternehmung ist, sondern sie m¨ ussen dar¨ uber hinaus m¨oglichst intrinsisch motiviert werden, das Sicherheitsregelwerk einer Unternehmung einzuhalten.239 Dabei ist die Unternehmung dazu angehalten, die IT-Sicherheitsrichtlinien wenn m¨oglich so zu gestalten, dass diese mit keinem oder einem vertretbaren Mehraufwand von den Besch¨aftigten zu erf¨ ullen ist. Andernfalls kann es dazu kommen, dass die Mitarbeiter die Umsetzung bzw. den Einsatz im Arbeitsalltag boykottieren. Sensibilisierungskampagnen und Trainings f¨ ur Mitarbeiter sind insbesondere deshalb sinnvoll, da Angreifer u ber das sog. Social Engineering wichtige Informationen relativ einfach ¨ erhalten k¨onnen. Social Engineering umschreibt das Erlangen von Informationen durch Ausnutzung von menschlichen Schw¨achen, Unsicherheiten und organisatorischen M¨angeln. Darunter fallen Techniken wie z.B. das sog. Dumpster Diving (Durchsuchen von Abf¨allen, 237 Vgl. Heitmann/Neuber 2004: 211. 238 Vgl. Leyden 2005. 239 Vgl. M¨ uhlenbrock 2003: 152.

2.5 IT-Anwender

83

wie z.B. Papiercontainer, nach verwertbaren Informationen) oder das Vort¨auschen falscher Tatsachen. Dabei gibt sich der Angreifer z.B. als Systemadministrator aus und verlangt vom Benutzer die Preisgabe des pers¨onlichen Passwortes f¨ ur ein System. Angreifer, die in dieser Technik versiert sind, haben in der Regel ausgezeichnete empathische F¨ahigkeiten und k¨onnen Menschen sehr gut manipulieren.240

2.5.1 Theoretische Ans¨ atze Es existiert eine Vielzahl von Theorien, die menschliches Verhalten er¨ortern. Exemplarisch werden hier zwei Theorien vorgestellt und in Bezug zur Sensibilisierung der Mitarbeiter im Bereich IT-Sicherheit gesetzt. Die Nutzung des Internets durch die Mitarbeiter in einer Unternehmung kann als Kollektivgut angesehen werden. Mancur Olsons Kollektivg¨ utertheorie postuliert, dass in latenten Gruppen (Gruppengr¨oße, bei der der Beitrag des Einzelnen nicht mehr wahrgenommen wird) die Gruppenmitglieder dazu tendieren, ihren eigenen Nutzen zu maximieren. Eine Organisation kann dieses Verhalten u ¨ ber selektive Anreize steuern, um kollektives Handeln zu erm¨oglichen.241 Im vorliegenden Fall muss eine Unternehmung positive oder negative Anreize bieten, damit die Mitarbeiter die Sicherheitsregeln im Umgang mit elektronischen Medien befolgen. Informationen k¨onnen nach der Theorie der kognitiven Dissonanz zueinander konsonant, dissonant oder irrelevant sein.242 Konsonante Informationen sind relativ deckungsgleich mit dem eigenen Standpunkt eines Akteurs, w¨ahrend dissonante Informationen nicht mit der pers¨onlichen Meinung eines Akteurs u ¨bereinstimmen. Daher werden dissonante Informationen eher vermieden bzw. ausgeblendet und konsonante Informationen bevorzugt. Akteure werten dissonante Informationen zu einer bereits getroffenen Entscheidung ab, w¨ahrend konsonante Informationen tendenziell u ¨bersch¨atzt werden. Entscheidungen werden nur dann revidiert, wenn die innere Spannung durch viele dissonante Informationen einen individuellen Schwellenwert u ¨bersteigt. Angewandt auf die Planer, Betreiber und Anwender von Informations- und Kommunikationstechnik in Unternehmungen bedeutet dies, dass eine eventuell vorhandene negative Einstellung zur IT-Sicherheit (z.B. IT” Sicherheit ist nicht meine Aufgabe/betrifft mich nicht“) nicht mit dem einmaligen Verteilen einer Brosch¨ ure radikal ge¨andert werden kann. Vielmehr ist eine breite Streuung der Information u ¨ber verschiedene Medien und einen l¨angeren Zeitraum notwendig, um vorhandene negative Einstellungen zur IT-Sicherheit zu eliminieren. 240 Vgl. Mitnick/Simon 2002. 241 Vgl. Olson 1968. 242 Vgl. Festinger/Irle/M¨ ontmann 1978.

84

2 IT-Sicherheit in Unternehmungen

2.5.2 Einflussfaktoren zur Sensibilisierung der IT-Anwender Die Sensibilisierung der Mitarbeiter f¨ ur IT-Sicherheit in Unternehmungen soll sicherheitsrelevante Informationen und F¨ahigkeiten vermitteln. Ziel ist es, das Mitarbeiterverhalten dergestalt zu beeinflussen, dass die Einhaltung der IT-Sicherheitsregeln ein Bestandteil der t¨aglichen Arbeitsroutine wird und jeder Mitarbeiter die Notwendigkeit einer pers¨onlichen Verantwortung f¨ ur die Aufrechterhaltung der IT-Sicherheit akzeptiert. Dieser Zustand wird mit dem Ausdruck gelebte Sicherheit“ umschrieben. ” Die Plausibilit¨at und (technische) Eindeutigkeit von Regeln steht dabei im Vordergrund. Sicherheitsregeln f¨ ur durchschnittliche Anwender m¨ ussen verst¨andlich kommuniziert werden und durch die Beschreibung m¨oglicher Sch¨aden bei Nichtbeachtung der Sicherheitsregeln kann deren Sinnhaftigkeit transportiert werden.243 Das Management muss eine Vorbildfunktion aus¨ uben und IT-Sicherheit nicht nur verordnen, sondern sie auch selbst praktizieren.244 Es ist sinnvoll neue Mitarbeiter im Umgang mit elektronischen Informationen zu schulen und sie in diesem Zusammenhang f¨ ur IT-Sicherheitsregelungen zu sensibilisieren. Weit schwieriger ist es, den gesamten Personalbestand nachtr¨aglich zu schulen. In großen Unternehmungen, in denen sich eine nachtr¨agliche Schulung zu aufw¨andig und kostenintensiv gestaltet, bieten sich daher andere Maßnahmen an. Das mittlere und obere Management k¨onnen nach einer Schulung als Multiplikatoren dienen und das gewonnene Wissen, etwa in Abteilungsbesprechungen, weitergeben und propagieren. Ein indirekter Einflussfaktor f¨ ur die Sensibilisierung bez¨ uglich der IT-Sicherheit ist die vorhandene Unternehmungskultur.245 In einer offenen, kommunikativen Unternehmungskultur k¨onnen Mitarbeiter sich eher zu nichtintentionalen Sicherheitsverletzungen (z.B. versehentliches L¨oschen von Dateien auf Gruppenlaufwerken) bekennen als in repressiven Kulturen. Negative Sanktionen sind nur dann wirksam, wenn Mitarbeiter ex ante den Tatbestand der Sicherheitsverletzung als solchen grunds¨atzlich kennen respektive seine Bedeutsamkeit erfassen k¨onnen. 243 Die Schadensszenarien sollten dennoch abstrakt bleiben, um etwaigen Innent¨atern keine konkrete Anleitung zur Schadensverursachung zu liefern. 244 In vielen Unternehmungen sind Mobilfunktelefone mit Kameras verboten, da mit diesen Aufnahmen von sensiblen Fertigungsbereichen oder Prototypen angefertigt werden k¨onnen. In einer Automobilunternehmung bekamen die F¨ uhrungskr¨ afte speziell pr¨ aparierte Mobiltelefone, bei denen die eingebaute Kamera hardwaretechnisch stillgelegt wurde. Diese (teureren) Sonderanfertigungen besaßen jedoch noch die entsprechenden Eintr¨ age im Bedienmen¨ u, welche auf die Kamerafunktion verwiesen. Da die Kamera nach Aufrufen der Funktion im Men¨ u nicht funktionierte, deklarierten einige F¨ uhrungskr¨afte ihre Telefone als defekt, sendeten sie dem Hersteller zur¨ uck und bekamen Mobilfunktelefone mit funktionsf¨ahigen Kameras zur¨ uck. 245 Vgl. M¨ uhlenbrock 2003: 31.

2.5 IT-Anwender

85

Ziel der Sensibilisierung ist es, relevante IT-Sicherheitsinformationen und -f¨ahigkeiten an die Mitarbeiter zu vermitteln und das Engagement und die Motivation der Mitarbeiter zu erh¨ohen. Allgemeine Prinzipien der internen Kommunikation gestalten die internen Kommunikationsrichtlinien mit Aufgaben und Zielen:246 • Prinzip der Vollst¨andigkeit, • Prinzip der aktiven Einbindung aller Mitarbeiter, • Prinzip der Offenheit, • Prinzip der Fr¨ uhzeitigkeit, • Prinzip der Wahrheit, • Prinzip des Vertrauens, • Prinzip der internen Kunden und • Prinzip der Identit¨at von Kommunikation und Verhalten. Dabei l¨asst sich die interne Unternehmungskommunikation in individuelle und Massenkommunikationsmaßnahmen unterteilen. Eine systematische Gliederung der Kommunikationsinstrumente findet sich in Tabelle 2.9. Die Maßnahmen m¨ ussen mit den Kommunikationszielen korrespondieren und z.B. nach den Kriterien Erscheinungsform, Kosten, Nutzen und Akzeptanzgrad bei den Mitarbeitern bewertet werden. Nur der geplante Einsatz und die wirkungsvolle Kombination von Kommunikationsinstrumenten mit kompetenter Koordination f¨ uhren zum Kommunikationserfolg.247 Optimal ist eine zielgruppenspezifische Kommunikation, die die Informationsvorspr¨ unge, -defizite und -bed¨ urfnisse der jeweiligen Gruppen ber¨ ucksichtigt. Zu diesem Zweck sollte eine entsprechende Informationsbeschaffung u ¨ber die interne Marktforschung stattfinden, die z.B. u ¨ber das Instrument Mitarbeiterbefragung“ die Wertvorstellungen, ” ¨ Bed¨ urfnisse, Angste etc. erhebt und auswertet.248 In der sich anschließenden Segmentierung in unterschiedliche, m¨oglichst homogene Gruppen werden Abgrenzungsmerkmale entwickelt.249 Die Segmentierung erm¨oglicht eine individuellere Ansprache und erh¨oht die Wahrscheinlichkeit, dass die Kommunikation als positiv erlebt wird und die Bereitschaft zur Aufnahme und Umsetzung der u ¨ bermittelten Botschaft steigt.250

246 Vgl. Bruhn 1998: 1059f.; Kl¨ ofer 1999: 19ff.; Beger/G¨ artner/Mathes 1989: 123ff. 247 Vgl. Mast 2002: 270; Dotzler 1999: 669. 248 Vgl. Collins/Payene 1991: 156; Schulze 1992: 117. 249 Vgl. Meffert 2000: 186f. 250 Vgl. Bruhn 2003: 149.

86

2 IT-Sicherheit in Unternehmungen

Pers¨ onliche Kommunikation Interne Individualkommunikation

Schriftliche Kommunikation

Elektronische Kommunikation

• Internes Training

• Anschreiben

• Email

• interne interaktive Kommunikation

• Arbeitsplatzanweisungen

• Videokonferenz

• Open-Door-Policy

• Beschwerdebriefkasten

• Mitarbeitergespr¨ ache • Dialoge zw. Kollegen

• betriebliches schlagswesen

• Unterweisungen

• Mitarbeiterbefragung

Vor-

• Seminare • Workshops Interne Massenkommunikation

• Konferenzen

• Mitarbeiterzeitung

• Intranet

• Vortr¨ age

• Rundschreiben

• Firmenvideos

• Diskussionsforen

• Schwarzes Brett

• Unternehmungs-TV

• Abteilungssitzungen

• Firmenbrosch¨ ure

• Direkt Mailings

• Betriebsversammlungen

• Informationsunterlagen

• Newsletter • Web-based Training

• Handb¨ ucher • Unternehmungsrichtlinien

• Computer-based Training • Lehrvideos

• Werbung • Public Relation • Poster

Tabelle 2.9: Kommunikationsinstrumente der Individual- und Massenkommunikation (vgl. Subei 2004: 27) Neben demografischen, sozio¨okonomischen, psychografischen und Verhaltensmerkmalen ist f¨ ur eine zielgruppengerechte Segmentierung zur Sensibilisierung der Mitarbeiter von Interesse, welche Kontaktart, -h¨aufigkeit und -intensit¨at diese im Rahmen ihrer T¨atigkeiten in der Unternehmung mit Informations- und Kommunikationstechnologien und IT-Sicherheit aufweisen.251 Die Ergebnisse bestimmen die Kommunikationsform und -art und deren Detaillierungsgrad pro ermittelte Zielgruppe.252 Die Implementierung der Maß251 Vgl. Schweiger/Schrattenecker 2001: 50; Steffenhagen 2000: 47ff. 252 Dadurch wird auch die operative Maßnahmenplanung bestimmt, welche sich mit der visuellen Ge-

2.5 IT-Anwender

87

nahmen zur Sensibilisierung ist h¨aufig mit Schwierigkeiten verbunden. Es gilt, m¨ogliche Barrieren im Vorfeld zu identifizieren und analysieren, um diesen erfolgreich begegnen zu k¨onnen. Dabei kann zwischen drei Kategorien von Implementierungshindernissen unterschieden werden:253 • inhaltlich-konzeptionelle Barrieren, • organsiatorisch-strukturelle Barrieren, • personell-kulturelle Barrieren. Nach einer Identifikation der Probleme bei der Implementierung m¨ ussen Strategien zur L¨osung derselben erarbeitet werden.254 Hilfreich ist dabei ein Vorgehen in vier Phasen: Verpflichtung des Managements, Kommunikation mit den Mitarbeitern, Vermittlung des erforderlichen Know-hows und die Verpflichtung der Mitarbeiter.255 Eine Erfolgskontrolle der Maßnahmen und die Bestimmung des Zielerreichungsgrades ist ¨ in Sensibilisierungskonzepten problematisch, da es sich um verhaltensrelevante Anderungen handelt. Es ist jedoch m¨oglich, eine Erfolgskontrolle anhand quantitativer Kriterien zu realisieren wie z.B. die Anzahl interner Sicherheitsvorf¨alle u ¨ber einen definierten Zeitraum. Die Aussagekraft solcher Messzahlen wird umso gr¨oßer, je l¨anger der Betrachtungszeitraum gew¨ahlt wird. Ziel einer Sensibilisierungskampagne ist es unter anderem die Mitarbeiter zu motivieren, bestimmte Verhaltensweisen dauerhaft anzunehmen. Das US-amerikanische National Institute of Standards and Technology (NIST) hat eine Leitlinie entwickelt, welche nicht nur Sensibilisierungskonzepte (engl. awareness) f¨ ur den Bereich IT-Sicherheit, sondern auch Trainingsmaßnahmen enth¨alt.256 Der Nutzen von Sensibilisierungsmaßnahmen ist nicht unumstritten. Trotz vieler Maßnahmen und Kampagnen ¨offnen Anwender immer noch E-Mailanh¨ange aus dubiosen Quellen, infizieren auf diese Weise ihren Computer mit Malware und tragen eventuell zu einer Verbreitung der Malware bei.257 staltung, Erstellung, Produktion und Distribution der kommunikativen Maßnahmen besch¨aftigt. Vgl. Bruhn 2003: 267; Bruhn 1998: 1049. 253 Vgl. Plinke 1996: 50ff.; Bruhn 1995: 395f.; Bruhn 2002: 25. 254 Vgl. Piercy 2003: 547ff. 255 Vgl. Bruhn 2003a: 247ff. 256 Vgl. National Institute of Standards and Technology 2003. 257 Vgl. Ranum 2005.

88

2 IT-Sicherheit in Unternehmungen

2.6 Standardwerke zur IT-Sicherheit Die IT-Sicherheit in Unternehmungen sollte nach nachvollziehbaren Kriterien gestaltet werden. Im Allgemeinen richten sich Unternehmungen bei der Umsetzung der ITSicherheit nach national oder international anerkannten Standards. Es existiert eine Vielzahl von Gr¨ unden, warum eine Unternehmung sich f¨ ur die Nutzung eines Standardwerks zur IT-Sicherheit entscheiden sollte. Internationale Standards werden im Rahmen juristischer Auseinandersetzungen am ehesten akzeptiert und schaffen die Grundlage f¨ ur eine Gesetzeskonformit¨at in vielen Staaten.258 Gegen¨ uber Lieferanten und Kunden kann die Einhaltung eines Standards als Qualit¨atsmerkmal dienen. Dar¨ uber hinaus bieten viele Standards eine Option zur Zertifizierung und somit eine M¨oglichkeit, sich die Einhaltung eines Standards von unabh¨angiger Stelle best¨atigen zu lassen. Unternehmungsintern bietet die Ausrichtung an internationalen Standards einen Investitionsschutz, wenn der gew¨ahlte Standard von Experten aus der Praxis geschaffen oder zumindest evaluiert worden ist, da die Wahrscheinlichkeit einer fehlerhaften Strategie und/oder Implementierung wesentlich geringer ausf¨allt. Die Nutzung eines Standards erm¨oglicht Benchmarks zwischen Unternehmungen und Branchen, da einheitliche Merkmale und Messgr¨oßen zugrunde liegen. Mittlerweile existieren viele Richtlinien, Normen und Standards zur Etablierung und Aufrechterhaltung der IT-Sicherheit in Organisationen. Die Wahl, welcher Standard der optimale zur Sicherung der Werte einer Unternehmung ist, sollte auf der Grundlage von Faktoren wie Unternehmungsgr¨oße, Branche, Grad des IT-Einsatzes und der Vernetzung, Internationalit¨at der Unternehmung etc. erfolgen. Die Initiative D21 hat einen Vergleich verschiedener IT-Sicherheitsstandards und -kriterien erarbeitet und diese in Bezug gesetzt zu den Polen produktbezogen - systembezogen und technisch - nichttechnisch (siehe Abb. 2.10). Der rechte obere Quadrant ist geeignet, die strategischen Aspekte der IT-Sicherheit zu fundieren. Normative Werke wie FIPS-140 oder Common Criteria sind eher dazu geeignet, Produkte zu evaluieren oder zu zertifizieren. Eine derartiges Zertifikat kann teilweise auch tr¨ ugerisch wirken. So entspricht eine Zertifizierung eines Produktes nach Evaluation Assurance Level (EAL) 4 ungef¨ahr einem ISO 9000-Zertifikat. Dies bedeutet, dass das Produkt nach einem gewissen Qualit¨atsstandard entwickelt wurde (z.B. Dokumentation). Gleichzeitig bedeutet dies aber nicht, dass das Produkt h¨ohere Sicherheitsanforderungen erf¨ ullt oder gar als sicher“ zu bezeichnen ist.259 ”

258 Dies ist insbesondere f¨ ur Unternehmungen von Bedeutung, die u ¨ berwiegend international agieren. 259 So ist z.B. Microsoft Windows XP Professional mit Service Pack 2 nach Common Criteria EAL 4+ zertifiziert.

systembezogen

2.6 Standardwerke zur IT-Sicherheit

IT-GSHB

Task Force

produktbezogen

89

ISO 9000 ISO 13335 ISO 17799 CobiT

DS-Produktaudit

FIPS 140 ITSEC / CC

technisch

nichttechnisch

Abbildung 2.10: IT-Sicherheitskriterienwerke im Vergleich (vgl. Initiative D21 2001: 7.) Es existieren weitere Richtlinien oder Standards wie z.B. NIST 800er Serie, The Standard, MARION oder die Information Security Standards, Guidelines and Procedures der Information Systems Audit and Control Association (ISACA). Der Schweizer Arm der ISACA hat eine Studie zum Methodenvergleich von Code of Practice (CoP, ISO/IEC 17799), CobiT, Marion und IT-GSHB durchgef¨ uhrt und deren Einsatz respektive Nut260 zen in der Praxis empirisch u berpr¨ u ft. Ein zentraler Faktor f¨ ur die Auswahl eines ¨ IT-Sicherheitsstandards ist, dass sich diese auf die Gegebenheiten und Bed¨ urfnisse der Unternehmung abbilden bzw. anpassen lassen muss. In den folgenden Abschnitten werden die beiden Standards vorgestellt, die eine gr¨oßere Verbreitung erfahren haben: Der British Standard (BS) 7799 und das ITGrundschutzhandbuch des BSI. Der BS 7799 besteht aus zwei Teilen: 1. Sicherheitsvorgaben und Methoden, die sich als best practices“ bew¨ahrt haben (BS ” 7799-1) und 2. Vorgaben zur Zertifizierung von IT-Sicherheit in Unternehmungen (BS 7799-2). Der erste Teil wurde in die ISO/IEC 17799 (im Folgenden als ISO 17799 bezeichnet) u uhrt.261 Es f¨ uhrt oftmals zu Verwirrungen, dass der zweite Teil des BS 7799 die ¨berf¨ Grundlage f¨ ur den ersten Teil bildet. Zur Zeit findet ein umfassende Reform statt. Die 260 Vgl. Information Systems Audit and Control Association 1998. 261 Vgl. M¨ uhlenbrock 2003: 224.

90

2 IT-Sicherheit in Unternehmungen

verschiedenen Standards zum IT-Sicherheitsmanagement werden in eine ISO 27000- Familie u uhrt. Dies geschieht in Anlehnung an andere Managementsysteme wie z.B. die ¨berf¨ ISO 9000-Familie. Als erstes wurde im Oktober 2005 der BS 7799-2 als ISO-Standard 27001 zur Zertifizierung verabschiedet. Die ISO 17799:2005 soll im Fr¨ uhjahr 2007 folgen.262 Die IT Infrastructure Library (ITIL) verweist zum Themenbereich Management der IT-Sicherheit ebenfalls auf den BS 7799.

2.6.1 British Standard 7799-2 Der zweite Teil des BS 7799 bietet ein Modell zur Erstellung und Leitung eines effektiven Managementsystems f¨ ur Informationssicherheit (Information Security Management System, ISMS). Dabei folgt das Modell einem Prozessansatz, der Prozesse und deren Interaktionen und Interdependenzen in Unternehmungen identifiziert und ein entsprechendes Managementmodell etabliert. Dabei sind folgende Punkte besonders zu beachten: • Verst¨andnis der Anforderungen an betriebliche Informationssicherheit und der Notwendigkeit Richtlinien und Ziele f¨ ur Informationssicherheit zu etablieren. • Implementierung und Nutzung von Steuerungsmerkmalen (Controls) im Zusammenhang mit dem Risikomanagement in einer Unternehmung. ¨ ¨ • Uberwachung und Uberpr¨ ufung der Effektivit¨at und Effizienz eines ISMS. • Kontinuierliche Verbesserung basierend auf objektiven Messungen. Dieses Modell folgt dem Plan-Do-Check-Act Modell263 und kann auf alle ISMS-Prozesse angewandt werden (siehe Abb. 2.11). In der Planungsphase m¨ ussen Ziele, Prozesse, eine Sicherheitspolitik und Verfahren etabliert werden, die geeignet sind, Risiken zu steuern und die Informationssicherheit in ¨ Ubereinstimmung mit (anderen) unternehmungsweiten Zielen und Richtlinien zu verbessern. Es wird gefordert, dass Risiken identifiziert und bewertet werden und dass aus dieser Aufstellung ein Maßnahmenplan zur Reduzierung des Risikos mit Terminen und Priorit¨aten erarbeitet wird. Die Implementierung und der Betrieb einer Sicherheitspolitik, der Controls, Prozesse und Verfahren geschieht in der Umsetzungsphase. Dabei ist sicherzustellen, dass gen¨ ugend Ressourcen alloziiert wurden, vollst¨andige Dokumentationen angefertigt werden und Sensibilisierungskonzepte und Trainings zur IT-Sicherheit realisiert werden. Falls Risiken auf Dritte u ¨bertragen wurden (z.B. bei Ousourcing), muss sichergestellt werden, dass diese die Natur der Risiken verstehen und in der Lage sind, diese zu beherrschen. 262 Vgl. M¨ unch 2005: 6. 263 Planen, umsetzen, u ufen, handeln. ¨berpr¨

91

Plan (planen) Einführung eines ISMS Do (umsetzen) Implementation und Betrieb des ISMS

Entwicklungs- , Wartungs- und Verbesserungszyklus

Aufrechterhaltung und Verbesserung des ISMS Act (handeln)

Beteiligte Parteien Managed IT Security

Beteiligte Parteien Anforderungen und Erwartungen an die IT-Sicherheit

2.6 Standardwerke zur IT-Sicherheit

Überwachung und Überprüfung des ISMS Check (überprüfen)

Abbildung 2.11: Managementsystem f¨ ur Informationssicherheit, ISMS (BS 7799-2: 2) ¨ In der Uberpr¨ ufungsphase werden Bewertungen (Assessments) und, wenn anwendbar, eine Kontrolle der Prozessperformanz gegen die Sicherheitspolitik, Ziele und praktische Erfahrungen durchgef¨ uhrt und an das Management berichtet. Dazu geh¨oren z.B. auch Routine¨ uberpr¨ ufungen oder die sogenannten Self-policing Procedures. Dies sind Verfahren, deren Konstruktionsprinzip jeden Fehler oder jedes Versagen automatisch detektiert und entsprechend alarmiert. Des Weiteren wird die Bedeutung eines unternehmungs¨ ubergreifenden Austauschs u ¨ ber ein ISMS unterstrichen. Mindestens einmal im Jahr sollte in einem Audit gepr¨ uft werden, dass die Sicherheitspolitik immer noch die Gesch¨aftsziele reflektiert, dass eine angemessene Risikobewertungsmethode genutzt wird, dass festgelegte und dokumentierte Verfahren genutzt werden und ihre Ziele erf¨ ullen, dass alle technischen Maßnahmen vorhanden, korrekt konfiguriert und funktionsbereit sind, dass Restrisiken korrekt bewertet wurden und in dieser Form immer noch akzeptiert werden, dass die abgestimmten Maßnahmen als Folge des letzten Audits umgesetzt worden sind und dass das ISMS mit dem BS 7799-2 konform ist. Mindestens einmal im Jahr sollte das ISMS auf Effektivit¨at u uft werden, so dass ggf. Verbesserungen durchgef¨ uhrt werden ¨berpr¨ k¨onnen. Eine Trendanalyse kann dabei helfen, kommende Herausforderungen fr¨ uhzeitig zu erkennen. In der letzten Phase werden pr¨aventive und korrektive Maßnahmen auf der Basis der ¨ Managementberichte aus der Uberpr¨ ufungsphase durchgef¨ uhrt, um eine kontinuierliche Verbesserung des ISMS zu gew¨ahrleisten.

92

2 IT-Sicherheit in Unternehmungen

Die Beschreibung des Standards umfasst lediglich ca. zehn Seiten. In den Anh¨angen finden sich unter anderem alle Steuerungsziele und -merkmale aus der ISO 17799. Ein wesentlicher Kritikpunkt an dem BS 7799-2 ist das Fehlen von Performanzindikatoren. Es wird lediglich gepr¨ uft, ob ein Prozess etabliert worden ist und nicht, ob damit ein optima¨ les Ergebnis verwirklicht worden ist.264 Mit der Uberarbeitung des Standards im Jahr 2002 wurde der BS 7799-2 mit der ISO 9000 (Quality Management Systems) und der ISO 14000 (Environmental Management Systems) harmonisiert, indem deren Gliederung analog u ¨bernommen wurde. Ferner orientiert sich die Definition der Begriffe des Risikomanagements an dem ISO Guide 73 (Risk Management – Vocabulary – Guidelines for Use in Standards). Die Leits¨atze der OECD (OECD Guidelines for the Security of Information Systems and Networks) finden sich nun ebenfalls in dem BS 7799-2. Durch die Zertifizierung nach BS 7799-2 bzw. ISO 27001 demonstrieren Unternehmungen die Einhaltung der oben genannten Richtlinien.265

2.6.2 ISO/IEC 17799:2005 Die ISO/IEC 17799 ist das am h¨aufigsten verwendete Modell zur Umsetzung der Vorgaben f¨ ur ein Managementsystem der Informationssicherheit aus dem BS 7799-2. Es beschreibt generelle Prinzipien zur Initiierung, Implementierung, Aufrechterhaltung und Verbesserung eines Information Security Management Systems.266 Seine Bedeutung in der Praxis hat die ISO 17799 respektive der zugrundeliegende BS 7799-1 dadurch erlangt, dass sie Informationssicherheit als einen Prozess definiert, der u ¨ber rein technische Maßnahmen hinausgeht, der Unterst¨ utzung des Managements bedarf und der sich auf die Bed¨ urfnisse der Unternehmung adaptieren l¨asst.267 Die ISO 17799 besteht aus elf Hauptgruppen“ (security control clauses), welche insge” samt 39 Untergruppen und eine Einleitung zum Thema Risikobewertung und -behandlung beinhalten. Erst mit der Neufassung im Jahr 2005 wurde die ISO 17799 um die elfte Hauptgruppe erg¨anzt, haupts¨achlich um eine Harmonisierung mit der ISO/IEC TR 18044 Information Security Incident Management zu erreichen.268 Die elf Hauptgruppen bestehen aus den folgenden Themengebieten (mit der jeweiligen Anzahl der Untergruppen in Klammern):

264 Vgl. M¨ unch 2005: 7. 265 Vgl. V¨olker 2005: 10. 266 Oft wird dieser Standard auch als Code of Practice for Information Security Management bezeichnet. Die vorliegende Beschreibung bezieht sich ausschließlich auf die ISO/IEC 17799:2005. 267 Vgl. Geschonneck 2006: 114. 268 Vgl. Geschonneck 2006: 114; Jaschob 2006: 52.

2.6 Standardwerke zur IT-Sicherheit

93

• Security Policy (1), • Organizing Information Security (2), • Asset Management (2), • Human Resources Security (3), • Physical and Environmental Security (2), • Communications ans Operations Management (10), • Access Control (7), • Information Systems Acquisition, Development and Maintenance (6), • Information Security Incident Management (2), • Business Continuity Management (1) und • Compliance (3). Jede der Untergruppen enth¨alt ein Ziel (Control Objective), das erreicht werden soll, und ¨ ein oder mehrere Steuerungsmerkmale (Controls) zur Uberpr¨ ufung der Zielerreichung. Die ¨ Steuerungsmerkmale gliedern sich in (a) Steuerungsmerkmale, die zur Uberpr¨ ufung der Zielerreichung dienen, (b) Implementierungshilfen (Implementation Guidance) mit tiefergehenden Informationen zur Implementierung der Steuerungsmerkmale und (c) anderen Informationen, die eventuell zu ber¨ ucksichtigen sind, wie z.B. juristische Erw¨agungen oder Referenzierungen auf andere Standards. Die Umsetzung der ISO 17799 stellt eine von mehreren Optionen dar, die Anforderungen des BS 7799-2 bzw. des ISO-Standards 27001 zu erf¨ ullen.

2.6.2.1 Risikoanalyse nach ISO/IEC TR 13335-3 Die ISO 17799 verweist f¨ ur eine Risikoanalyse auf die Vorgehensweise in der ISO/IEC Technical Report 13335 Teil 3 (im Folgenden als ISO 13335-3 bezeichnet), die keine konkrete Handlungsanweisungen bietet, sondern vielmehr grobe Richtlinien zur Identifizierung von Risiken in vier Ans¨atze unterteilt. Von den insgesamt zw¨olf Kapiteln besch¨aftigen sich haupts¨achlich die Kapitel acht (Corporate Risk Analysis Strategy Options) und neun mit der eigentlichen Risikoanalyse. Eine Unternehmung muss vor einer Risikoanalyse eine entsprechende Strategie mit konstituierenden Elementen (z.B. Methoden, Techniken) fixieren, innerhalb der Unternehmung koordinieren und in der IT-Sicherheitspolitik dokumentieren. Dies soll garantieren, dass der gew¨ahlte Ansatz den Bed¨ urfnissen der Unternehmung gerecht wird und den Fokus auf die Bereiche/Prozesse setzt, die IT-Sicherheit wirklich ben¨otigen. Die ISO 13335-3

94

2 IT-Sicherheit in Unternehmungen

unterscheidet vier verschiedene Ans¨atze zur Risikoanalyse, die sich lediglich in der Detaillierungstiefe unterscheiden. Da eine ausf¨ uhrliche Analyse aller IT-Systeme zu kosten- und zeitintensiv und eine generelle, oberfl¨achliche Analyse zu ungenau ist, muss eine Balance gefunden werden. Die vier methodischen Ans¨atze werden wie folgt segmentiert:269 • Baseline Approach: Einf¨ uhrung eines allgemeinen Sicherheitsstandards, welcher spezielle Risiken bestimmter Systeme ignoriert und dadurch akzeptiert, dass der Grad der IT-Sicherheit nicht immer angemessen ist. Der Vorteil dieser L¨osung ist der geringe Ressourcenbedarf (Zeit, Personal und Kosten). Nachteilig ist die schwierige Ausgestaltung des Basisstandards, der weder zu hoch noch zu niedrig sein darf. Spezielle Sicherheitsbed¨ urfnisse bestimmter Systeme lassen sich mit solch einem Ansatz nicht ber¨ ucksichtigen. • Informal Approach: Risikoanalyse mit Konzentration auf Systeme, von denen angenommen wird, dass sie einem hohen Risiko ausgesetzt sind. Basis ist keine strukturierte Methode, sondern das Wissen und die Erfahrung einzelner Akteure. Dieser Ansatz erfordert relativ wenig Ressourcen, weist aber einige Nachteile auf. Ohne eine formale Methode ist die Wahrscheinlichkeit h¨oher, wichtige Details zu u ¨bersehen. Der Erfolg dieses Verfahrens ist sehr stark abh¨angig von dem Wissen der beteiligten Akteure (ist also subjektiv) – dies kann zu Problemen f¨ uhren, wenn die Akteure, die die Analyse durchf¨ uhren, die Unternehmung verlassen. • Detailed Risk Analysis: Detaillierte Risikoanalyse f¨ ur alle Systeme einer Unternehmung. Dies beinhaltet eine tiefgehende Identifikation und Evaluierung aller Werte, eine Analyse der potenziellen Gef¨ahrdungen der Werte sowie m¨oglicher Schwachstellen und die daraus folgende Empfehlung f¨ ur zu treffende Maßnahmen zur Risikoreduzierung (siehe Abb. 2.12). Vorteilig ist, dass angemessene Maßnahmen f¨ ur alle Systeme identifiziert werden ¨ und die Resultate im Sicherheitsmanagement (z.B. Anderungsoder Change Management) verwendet werden k¨onnen. Von Nachteil sind der hohe Bedarf an Zeit und Personal und die damit einhergehenden Kosten.

269 Vgl. ISO TR 13335-3 1998: 7ff.

2.6 Standardwerke zur IT-Sicherheit

95

Festlegung des Umfangs und der Ziele

Risikoanalyse Identifikation von Werten

Evaluierung von Werten und Einstufung der Abhängigkeiten der Werte untereinander

Gefährdungsanalyse

Schwachstellenanalyse

Identifikation von vorhandenen / geplanten Sicherheitsmaßnahmen

Bewertung des Risikos

Identifikation / Bewertung von Beschränkungen Auswahl der Maßnahmen

Akzeptanz des (Rest-) Risikos

Ja

Nein

IT System Sicherheitsrichtlinie

IT Sicherheitsplan

Abbildung 2.12: Risikomanagement mit detaillierter Risikoanalyse (ISO/IEC TR 13335-3 1998: 12) • Combined Approach: Durchf¨ uhrung einer initialen oberfl¨achlicheren Risikoanalyse, um Systeme zu identifizieren, die einem hohen Risiko ausgesetzt und/oder kritisch f¨ ur die Erreichung der Gesch¨aftsziele sind. Darauf folgt eine detaillierte Risikoanalyse f¨ ur die identifizierten Systeme und die Anwendung eines allgemeinen Sicherheitsstandards auf alle u ¨ brigen Systeme. Ein initial schneller und einfacher Ansatz findet h¨aufig Unterst¨ utzung im Management und liefert rasch erste Resultate. Ressourcen k¨onnen im weiteren Verlauf der Analyse gezielt dort eingesetzt werden, wo Werte gef¨ahrdet sind. Der einzige Nachteil dieses Ansatz ist, dass in der ersten oberfl¨achlichen Analyse eventuell nicht jedes System erkannt wird, das eine detailliertere Risikoanalyse ben¨otigt. Die ISO 13335-3 empfiehlt den kombinierten Ansatz (Combined Approach) zur Durchf¨ uhrung einer Risikoanalyse f¨ ur Unternehmungen wie vorangehend beschrieben.

96

2 IT-Sicherheit in Unternehmungen

Nach der oberfl¨achlichen Analyse aller Systeme werden die identifizierten kritischen Systeme einer detaillierten Risikoanalyse unterzogen (siehe Abb. 2.13). Danach folgt die Anwendung des allgemeinen Sicherheitsstandards auf alle anderen Systeme. 2.6.2.2 Hauptgruppen nach ISO 17799 ¨ Im Folgenden wird eine Ubersicht u ¨ber die elf Hauptgruppen und ihre Untergruppen der ISO 17799 vorgestellt, um einen Eindruck u ¨ber den Umfang bei der Anwendung des Standards zu vermitteln. 1. Security Policy Dieser Abschnitt besch¨aftigt sich mit der Notwendigkeit der schriftlichen Fixierung einer Sicherheitspolitik in der Unternehmung. 2. Organizing Information Security Dieser Abschnitt besch¨aftigt sich mit der Organisation der Informationssicherheit aus zwei Perspektiven. Einerseits wird die unternehmungsinterne Organisation (Internal Organization) der Informationssicherheit und deren Erfordernisse beschrieben. Andererseits wird im Bereich externe Partner (External Parties) die Vorgehensweise im Umgang mit Risiken bei und durch Lieferanten und Kooperationspartner sowie Kunden n¨aher definiert. 3. Asset Management Hier wird ein Vorgehen zum Umgang mit Unternehmungswerten vorgeschlagen. Dazu geh¨oren sowohl die Verantwortlichkeiten f¨ ur diese Unternehmungswerte (Responsibility for Assets), als auch die Klassifizierung dieser Werte (Information Classification). 4. Human Resources Security Dieser Abschnitt teilt den Prozess des Umgangs mit Mitarbeitern in drei Phasen. Den Bereich vor der Einstellung eines Mitarbeiters (Prior to Employment), die Phase der Besch¨aftigung (During Employment) und die Beendigung des Arbeitsverh¨altnisses mit einem Mitarbeiter oder dessen Wechsel in einen anderen Bereich der Unternehmung (Termination or Change of Employment). 5. Physical and Environmental Security Der physikalische und umgebungsbezogene Schutz von Informationen wird auf sichere Umgebung (Secure Areas) und Sicherheit des Equipments (Equipment Security) aufgeteilt.

2.6 Standardwerke zur IT-Sicherheit

97

IT-Sicherheitsziele, -strategie und -politik IT-Sicherheitsziele und -strategie Unternehmensweite IT-Sicherheitspolitik

Optionen zur Strategie der Risikoanalyse Basis Ansatz

Informeller Ansatz

Kombinierter Ansatz

Detaillierte Risiko Analyse

Kombinierter Ansatz Oberflächliche Risikoanalyse Basis Ansatz

Detaillierte Risikoanalyse

Auswahl der Sicherheitsmaßnahmen Akzeptanz des verbleibenden Risikos IT System Sicherheitspolitik IT-Sicherheitsplan

Implementierung IT-Sicherheitsplan Implementierung Sicherheitsmaßnahmen

Sicherheitsbewusstsein

Sicherheitstraining

Genehmigung der IT-Systeme

Folgeaktivitäten Sicherheitscompliance Prüfung Veränderungsmanagement

Monitoring Wartung Sicherheitsvorfall Behandlung

Abbildung 2.13: Management der IT-Sicherheit (ISO/IEC TR 13335-3 1998: 2)

98

2 IT-Sicherheit in Unternehmungen

6. Communications and Operations Management Einer der umfangreichsten Abschnitte ist der Bereich, der sich mit dem Management der Informations- und Kommunikationstechnik und dem strategischen und operationalen Betreiben der IT befasst. Die Trennung von Verantwortlichkeiten, das Change Management und die Dokumentation von Prozeduren m¨ ussen vorgenommen werden (Operational Procedures and Responsibilities). Bei der Leistungserstellung durch Dritte m¨ ussen die Leistungen u ¨ berwacht werden und ggf. in das Ver¨anderungsmanagement einbezogen werden (Third Party Service Delivery Management). Die Bereiche Systemplanung (System Planning and Acceptance), Schutz vor b¨osartigem Code (Protection Against Malicious and Mobile Code) und Datensicherung (Back-Up) sind ebenfalls zu ber¨ ucksichtigen. Die Untergruppe Netzwerksicherheit (Network Security Management) definiert Controls f¨ ur die Sicherheit von Netzwerken und deren Diensten. Im Bereich Media Handling werden der Umgang mit Speichermedien, Dokumentationen der Systemsicherheit, Verfahrensanweisungen und deren Entsorgung behandelt. Der Austausch von Informationen (Exchange of Information) l¨asst sich unterteilen in Richtlinien, Verfahren und Vereinbarungen zum Austausch von Informationen, Transport von physischen Medien, elektronische Nachrichten und Gesch¨aftsinformationssysteme. Ebenso sind alle elektronischen Gesch¨aftst¨atigkeiten (Electronic Commerce Services) abzusichern und Verfahren zur Aufzeichnung von Aktivit¨aten umzusetzen (Monitoring). 7. Access Control Der Abschnitt mit dem zweitgr¨oßten Umfang besch¨aftigt sich mit der Zugangs- und Zugriffskontrolle. Darin werden Richtlinien anhand der gesch¨aftlichen Anforderungen (Business Requirements for Access Control ) ebenso definiert wie ein Management der Zug¨ange und -griffe von Benutzern (User Access Management) und die Verantwortlichkeiten der Benutzer (User Responsibilities). Der Zugang zu Netzwerken (Network Access Control) und zu Systemen (Operating System Access Control) wird ebenfalls er¨ortert. Der Abschnitt endet mit den Controls zum Themenbereich Zugriff auf Applikationen und Informationen (Application and Information Access Control) und der Untergruppe Telearbeit und mobiles Arbeiten (Mobile Computing and Teleworking). 8. Information Systems Acquisition, Development and Maintenance Inhalt dieses Abschnitts sind die Sicherheitsanforderungen von Informationssystemen (Security Requirements of Information Systems), die Validit¨at und Integrit¨at von Daten in Anwendungen (Correct Processing in Applications) und der Schutz von Vertraulichkeit, Authentizit¨at und/oder Integrit¨at von Informationen durch Kryptografie (Cryptographic Controls). Des Weiteren werden die Sicherheit von Systemdateien (Security of System Files), der Entwicklungs- und Supportprozess (Securi-

2.6 Standardwerke zur IT-Sicherheit

99

ty in Development and Support Processes) und das Management von technischen Schwachstellen (Technical Vulnerability Management) behandelt. 9. Information Security Incident Management Der Abschnitt zum Vorgehen bei Sicherheitsvorf¨allen ist erst seit der Verabschiedung der neuen Version der ISO 17799 im Jahr 2005 Bestandteil der Betrachtung. Er legt fest, dass Berichtswege f¨ ur Sicherheitsvorf¨alle und Schwachstellen existieren m¨ ussen (Reporting Information Security Events and Weaknesses). Des Weiteren m¨ ussen Verantwortlichkeiten und Verfahren f¨ ur Sicherheitsvorf¨alle festgelegt werden sowie ein Verfahren f¨ ur die Umsetzung von Erkenntnissen und Verbesserungsoptionen aus diesen Vorf¨allen (Management of Information Security Incidents and Improvements). 10. Business Continuity Management Hier werden Aspekte der Informationssicherheit in Hinsicht auf die Aufrechterhaltung der Gesch¨aftst¨atigkeit (Information Security Aspects of Business Continuity Management) behandelt. 11. Compliance Im letzten Abschnitt der ISO 17799 wird die Einhaltung bestimmter Gesetze (Compliance With Legal Requirements) und Standards (Compliance With Security Policies and Standards and Technical Compliance) er¨ortert, er schließt mit den Controls f¨ ur die Audits von Informationssystemen (Information Systems Audit Considerations). Am Beispiel der Hauptgruppe Sicherheitspolitik soll hier das Vorgehen in der Umsetzung nach ISO 17799 verdeutlicht werden. Formuliertes Ziel ist es, eine Richtungsvorgabe f¨ ur und damit eine Unterst¨ utzung durch das Management in der Informationssicherheit im Einklang mit Gesch¨aftszielen und relevanten Gesetzen und Regelungen zu erhalten. Dabei ¨ sollte das Management eine klare Richtung in der Sicherheitspolitik in Ubereinstimmung mit den Gesch¨aftszielen vorgeben und ihre Zustimmung zur IT-Sicherheit durch organisationsweite Ver¨offentlichungen und Aufrechthaltung einer Sicherheitspolitik zeigen. Das Control f¨ ur dieses Ziel sagt aus, dass das Dokument Informationssicherheitspolitik“ ” vom Management genehmigt und an alle Mitarbeiter und relevante Dritte kommuniziert werden sollte. Zur Implementierungshilfe werden die Themen genannt, die in der Sicherheitspolitik adressiert werden sollten – mit dem Hinweis, dass das Dokument in einer Form an die Anwender verteilt wird, die relevant, verst¨andlich und erreichbar ist. Unter Weitere Information wird abschließend darauf hingewiesen, dass die Informationssicherheitspolitik Teil eines generellen Richtliniendokumentes sein kann und dass bei der Verteilung der Sicherheitspolitik an Dritte sichergestellt werden muss, dass keine sensiblen Informationen enthalten sind.

100

2 IT-Sicherheit in Unternehmungen

Der wesentliche Vorteil der ISO 17799 ist der hohe Freiheitsgrad in der Auswahl und Umsetzung von Maßnahmen. Dadurch l¨asst sich die Umsetzung/Erf¨ ullung des Standards an die Bed¨ urfnisse von Unternehmungen individuell anpassen. Diese Tatsache wird teilweise negativ bewertet, da er den Anwendern einen zu hohen Freiheitsgrad gew¨ahrt und keinerlei Hilfestellung bei der Auswahl der Maßnahmen bietet. Aus diesem Grund wird in der Praxis teilweise eine Kombination aus ISO 17799 und GSHB angewandt. Eine Zertifizierung nach ISO 17799 ist nicht m¨oglich. Organisationen k¨onnen sich jedoch nach BS 7799-2 respektive ISO 27001 zertifizieren lassen.

2.6.3 BSI IT-Grundschutzhandbuch Zur Zeit befindet sich das IT-Grundschutzhandbuch in einem fundamentalen Umbruch, da es erkl¨artes Ziel des BSI ist, das GSHB mit anderen internationalen Standards zu konsolidieren. Die vorliegende Erl¨auterung beschreibt das GSHB im Stand von Oktober 2005. Das IT-Grundschutzhandbuch hat zum Ziel, einen grundlegenden Schutz in einer Organisation zu erreichen, um niedrigen bzw. mittleren Schutzbed¨ urfnissen gerecht zu werden. Zu diesem Zweck sind mehrere, aufeinander aufbauende Analysen notwendig.270 Der prozessuale Ablauf einer strukturierten Anwendung des IT-Grundschutzhandbuches gestaltet sich wie in Abb. 2.14 dargestellt. Der g¨angige sequenzielle Ablauf in der Anwendung des GSHB gestaltet sich im Anschluss an die Festlegung des Untersuchungsgegenstandes271 folgendermaßen: 1. IT-Strukturanalyse:272 Erfassung der beteiligten Komponenten. Dazu geh¨oren der bereinigte Netzplan, eine Liste der IT-Systeme mit dazugeh¨origen Informationen sowie eine Liste der wichtigsten IT-Anwendungen in Abh¨angigkeit von IT-Systemen. ur IT2. Schutzbedarfsfeststellung:273 Zuerst wird die Schutzbedarfsfeststellung f¨ Anwendungen und der dazugeh¨origen Daten anhand der drei Schutzziele der ITSicherheit durchgef¨ uhrt. Danach folgt die Schutzbedarfsfeststellung f¨ ur IT-Systeme und anschließend die f¨ ur Kommunikationsverbindungen. Zuletzt findet die Schutzbedarfsfeststellung f¨ ur IT-R¨aume statt.

270 Vgl. Humpert 2004: 9. 271 In der Nomenklatur des BSI ist dies ein IT-Verbund, der mindestens die Informationstechnik eines Gesch¨aftsprozesses, einer Organisationseinheit oder einer Fachaufgabe umfasst, welche nicht nur Computer und Netze, sondern auch die gesamte Telekommunikationstechnik beinhaltet. 272 Vgl. BSI 2005: Abschnitt 2.1. 273 Vgl. BSI 2005: Abschnitt 2.2.

2.6 Standardwerke zur IT-Sicherheit

101

Initiierung des IT-Sicherheitsprozesses - Erstellung IT-Sicherheitsleitlinie - Einrichtung IT-Sicherheitsmanagements

Erstellung eines IT-Sicherheitskonzepts IT-Strukturanalyse - Erfassung der IT und der IT-Anwendungen - Gruppenbildung

Schutzbedarfsfeststellung

IT-Grundschutzanalyse - Modellierung nach IT-Grundschutz - Basis-Sicherheitscheck mit Soll-Ist-Vergleich

Ergänzende Sicherheitanalyse - bei hohem Schutzbedarf - bei zusätzlichem Analysebedarf

Realisierungsplanung - Konsolidierung der Maßnahmen - Umsetzungsplan

Umsetzung Realisierung fehlender Maßnahmen in den Bereichen Infrastruktur, Organisation, Personal, Technik, Kommunikation und Notfallvorsorge, insbesondere - Sensibilisierung für IT-Sicherheit - Schulung zur IT-Sicherheit

Aufrechterhaltung im laufenden Betrieb

Abbildung 2.14: Schematischer Ablauf nach GSHB (in Anlehnung an BSI 2004: Kapitel 2)

102

2 IT-Sicherheit in Unternehmungen

Im folgenden Abschnitt wird der detaillierte Ablauf der Schutzbedarfsfeststellung vorgestellt. 2.6.3.1 Schutzbedarfsfeststellung nach IT-Grundschutzhandbuch Die Analyse von Risiken erfolgt im IT-Grundschutzhandbuch (GSHB) u ¨ber Gef¨ahrdungskataloge und darauf abgestimmte Maßnahmenb¨ undel, die die jeweilige Gef¨ahrdung bzw. das Risiko reduzieren sollen.274 Dieses Verfahren eignet sich haupts¨achlich f¨ ur kleinere und mittlere Organisationen, da der Aufwand relativ gering und weniger fachliches ITSicherheitswissen notwendig ist, als bei anderen Verfahren. Die Vorgehensweise sieht vor, dass nach der Festlegung des Untersuchungsgegenstandes eine IT-Strukturanalyse mittels Netzpl¨anen erfolgt, die um unwesentliche Informationen bereinigt wird. Darauf folgt die Erhebung der IT-Systeme, der Anwendungen und zugeh¨origer Informa¨ tionen, die tabellarisch erfasst werden. Anhand der daraus entstandenen Ubersicht findet eine Schutzbedarfsfeststellung in vier Schritten statt. Ziel ist es, f¨ ur jede relevante Anwendung und ihre Daten den notwendigen Schutzbedarf bez¨ uglich der Vertraulichkeit, Integrit¨at und Verf¨ ugbarkeit festzustellen.275 1. Definition der Schutzbedarfskategorien. Es wird unterschieden zwischen sechs m¨oglichen und kombinierbaren Schadenstypen, die bei der Verletzung der Schutzziele entstehen k¨onnen: • Verstoß gegen Gesetze/Vorschriften/Vertr¨age, ” • Beeintr¨achtigung des informationellen Selbstbestimmungsrechts, • Beeintr¨achtigung der pers¨onlichen Unversehrtheit, • Beeintr¨achtigung der Aufgabenerf¨ ullung, • negative Außenwirkung und • finanzielle Auswirkungen.“ 276 Das BSI verweist auf die schlechte Quantifizierbarkeit von Schutzbedarfen und schl¨agt deshalb eine dreistufige qualitative Einteilung vor (siehe Tab. 2.10).

274 Vgl. BSI 2004. 275 Vgl. BSI 2005. 276 BSI 2005.

2.6 Standardwerke zur IT-Sicherheit

Kategorie Niedrig bis mittel Hoch Sehr hoch

103

Beschreibung Die Schadensauswirkungen sind begrenzt und u ¨ berschaubar. Die Schadensauswirkungen k¨onnen betr¨achtlich sein. Die Schadensauswirkungen k¨onnen ein existenziell bedrohliches, katastrophales Ausmaß erreichen.

Tabelle 2.10: Schutzbedarfskategorien gem¨aß GSHB (vgl. BSI 2005) Diese Kategorien werden den sechs m¨oglichen Schadenstypen zugeordnet, z.B. f¨ ur die Schutzkategorie Hoch“ (siehe Tab. 2.11). ” Schadenstyp Verstoß gegen Gesetze, Vorschriften & Vertr¨age

Beschreibung bei Schutzkategorie Hoch“ ” • Verst¨oße gegen Vorschriften und Gesetze mit erheblichen Konsequenzen. • Vertragsverletzungen mit hohen Konventionalstrafen.

Beeintr¨achtigung der Aufgabenerf¨ ullung

• Die Beeintr¨achtigung w¨ urde von einzelnen Betroffenen als nicht tolerabel eingesch¨atzt.

Negative Außenwirkung

• Eine breite Ansehens- oder Vertrauensbeeintr¨achtigung ist zu erwarten.

Finanzielle Auswirkungen

• Der Schaden bewirkt beachtliche finanzielle Verluste, ist jedoch nicht existenzbedrohend.

• Die maximal tolerierbare Ausfallzeit liegt zwischen einer und 24 Stunden.

Tabelle 2.11: Beispiele f¨ ur Schutzbedarfskategorien in Bezug auf Schadenstypen (BSI 2005) Das Resultat ist eine Beschreibung der Schutzbedarfskategorien, die hier noch losgel¨ost von den Anwendungen betrachtet wird. Dies kann deshalb von Vorteil sein, da hier noch kein konkreter Bezug auf existente oder geplante Systeme genommen wird. Eine solche abstrakte Entwicklung von Schutzbedarfen verhindert eine eventuelle Abwehrhaltung von betroffenen Systemstellen in der Unternehmung und kann helfen den tats¨achlichen Schutzbedarf zu ermitteln.

104

2 IT-Sicherheit in Unternehmungen

2. Ermittlung des Schutzbedarfs von IT-Anwendungen anhand von Schadensszenarien. In diesem Schritt werden aus Sicht der Anwender Szenarien entwickelt, die sich an den Schadenstypen und dem Verlust von Vertraulichkeit, Integrit¨at und/oder Verf¨ ugbarkeit orientieren. Dies dient der Ermittlung der potenziellen materiellen und immateriellen Sch¨aden. Zu diesem Zweck bietet das GSHB Leitfragen, die keinen Anspruch auf Vollst¨andigkeit erheben. Als Beispiel dienen folgende Fragen zum Verlust der Vertraulichkeit: • Kann die Ver¨offentlichung vertraulicher Informationen Regressforderungen ” nach sich ziehen? • Gibt es in der IT-Anwendung Daten, aus deren Kenntnis ein Dritter (z.B. Konkurrenzunternehmen) finanzielle Vorteile ziehen kann?“ 277 3. Ableitung des Schutzbedarfs der beteiligten IT-Systeme. Der aus Schritt zwei abgeleitete Schutzbedarf der IT-Systeme wird in Tabellen dokumentiert. Wichtig ist, dass die Ergebnisse entsprechend dokumentiert und zur Nachvollziehbarkeit erl¨autert oder begr¨ undet werden (Beispiel siehe Tab. 2.12). IT Anwendung

Schutzbedarfsfeststellung

Nr.

Bezeichnung

pers. Daten

Grundwert

Schutzbedarf

Begr¨ undung

A1

Lohnkostenabrechnung

X

Vertraulichkeit

hoch

Enth¨ alt besonders schutzbed¨ urftige personenbezogene Daten, deren Ver¨ offentlichung den Betroffenen erheblich schaden kann.

Integrit¨at

mittel

Fehler k¨ onnen registriert und nachtr¨ aglich korrigiert werden.

Verf¨ ugbarkeit

niedrig

Ein Ausfall kann bis zu zwei Wochen (notfalls mit Abschlagszahlungen) u uckt werden. ¨ berbr¨

Tabelle 2.12: Beispiel f¨ ur die Schutzbedarfsfeststellung einer IT-Anwendung Die Schutzbedarfsfeststellung einer IT-Anwendung muss zwingend mit der Bedeutung f¨ ur die Fachaufgabe bzw. den Gesch¨aftsprozess korrespondieren. • niedrig bis mittel: Die Fachaufgabe bzw. der Gesch¨aftsprozess kann mit anderen Mitteln und annehmbaren Mehraufwand durchgef¨ uhrt werden. 277 BSI 2005.

2.6 Standardwerke zur IT-Sicherheit

105

• hoch: Die Fachaufgabe bzw. der Gesch¨aftsprozess kann mit anderen Mitteln nur mit signifikantem Mehraufwand durchgef¨ uhrt werden. • sehr hoch: F¨ ur die Erf¨ ullung der Fachaufgabe bzw. des Gesch¨aftsprozesses ist die IT-Anwendung zwingend notwendig und nicht substituierbar. Das Gef¨ahrdungspotenzial der IT-Anwendungen muss nun auf die IT-Systeme u ¨ bertragen werden, mit denen die Applikationen in Verbindung stehen. Dies ist in erster Linie der Server, auf dem die Applikation l¨auft. Dabei ist folgendes zu beachten: • Maximum-Prinzip: Der Schaden bzw. die Summe der Sch¨aden mit den folgenschwersten Auswirkungen bestimmt im Wesentlichen den Schutzbedarf. • Kumulationseffekte: Wenn auf einem IT-System mehrere Anwendungen betrieben werden, so kann die Auswirkung eines Ausfalls/einer Sch¨adigung einer Anwendung gering sein. Wenn aber alle Anwendungen auf einem System ausfallen, dann kann der Gesamtschaden h¨oher sein, als die Summe der Einzelsch¨aden. • Dependenzen und Interdependenzen: Verteilte Systeme k¨onnen bewirken, dass Applikation A auf Ergebnisse von Applikation B angewiesen ist.278 In diesem Fall gilt f¨ ur beide Systeme derselbe Schutzbedarf, da in dem genannten Beispiel Applikation A ohne Applikation B ihre Funktion nicht erf¨ ullen kann. Gegebenenfalls, bei unterschiedlichem Schutzbedarf der beiden Systeme, ist der h¨ohere Schutzbedarf f¨ ur beide Systeme zu w¨ahlen. • Verteilungseffekte: Wenn eine Anwendung einen hohen Schutzbedarf aufweist, dann muss der Schutzbedarf f¨ ur ausgelagerte Teilbereiche der Applikation nicht zwingend identisch sein. Dies w¨ urde bedeuten, dass das System, auf dem der ausgelagerte Teilbereich der Applikation l¨auft, eventuell einen niedrigeren Schutzbedarf aufweist. ¨ 4. Ableitung des Schutzbedarfs f¨ ur involvierte Ubertragungsstrecken und IT-R¨aume. Nach der Schutzbedarfsfeststellung f¨ ur IT-Systeme werden die dazugeh¨origen Daten¨ ubertragungsstrecken untersucht. Grundlage hierf¨ ur ist der Netzplan aus der IT-Strukturanalyse. Es ist u.a. festzustellen, welche Kommunikationsstrecken redundant ausgelegt (Schutzziel Verf¨ ugbarkeit) und ob kryptografische Maßnahmen (Schutzziel Vertraulichkeit/Integrit¨at) ergriffen werden m¨ ussen. Dabei ist auf eine vollst¨andige Erfassung aller Kommunikationsstrecken zu achten, da bereits eine einzige u ¨bersehene kritische Verbindung das Sicherheitskonzept unterlaufen kann.279 278 Dies k¨onnen ganz unwesentlich scheinende Bestandteile sein, die z.B. nur den R¨ uckgabewert einer Funktion liefern. 279 Dies k¨onnen z.B. Verbindungen u ¨ ber Modems sein.

106

2 IT-Sicherheit in Unternehmungen

Schließlich m¨ ussen noch die IT-R¨aume (Datentr¨agerarchive, Serverr¨aume, Schutzschr¨anke, B¨ uror¨aume, etc.) betrachtet werden, in den die IT-Komponenten untergebracht sind. Der Ablauf der Schutzbedarfsfeststellung nach der Methode des BSI gestaltet sich wie in Abbildung 2.15 dargestellt. Anwendungen / Informationen

haben

Schutzbedarf

laufen / liegen auf IT-Räume / Verbindungsstrecken

stehen in / sind verbunden über

IT-System(e)

wird übertragen auf

werden geschützt durch werden geschützt durch

BSI-Bausteine / Maßnahmen

Abbildung 2.15: Prozess der Schutzbedarfsfeststellung nach GSHB (Erweiterung des Modells von Friberg/Gerhardt/Luttenberger 2003: 69) Bei der Erfassung und Bearbeitung der Daten aus den o.g. Schritten ist darauf zu achten, dass bereits von Beginn an alle notwendigen Daten erhoben werden, wie z.B. der Standort eines Systems, der Server, auf dem die Applikation l¨auft, und eine entsprechend eindeutige Nomenklatur gew¨ahlt wird. Das BSI bietet seit Februar 2004 zus¨atzlich eine Methode zur Risikoanalyse an, welche auf dem GSHB basiert. Der Adressatenkreis f¨ ur die erg¨anzende Risikoanalyse sind solche Organisationen, welche entweder in mindestens einem der drei Schutzziele einen hohen oder sehr hohen Schutzbedarf festgestellt haben, der in der Regel nicht vom GSHB abgedeckt wird, oder welche Komponenten betreiben, die nicht im GSHB behandelt werden.280 2.6.3.2 Weitere Vorgehensweise im Grundschutzhandbuch Nach den beiden Phasen IT-Strukturanalyse und Schutzbedarfsfeststellung folgen vier weitere Phasen:

280 Vgl. BSI 2004.

2.6 Standardwerke zur IT-Sicherheit

107

3. Modellierung:281 In der Phase der Modellierung werden die Sicherheitsaspekte gruppiert nach Themengebieten282 auf Zielobjekte (Komponenten, Systeme, Organisationseinheiten, Geb¨aude, etc.) abgebildet. Die Zuordnung erfolgt tabellarisch mit vier Spalten unter (1) Angabe der Nummer und des Bausteintitels, (2) des Zielobjekts oder der Zielgruppe, (3) des Ansprechpartners283 und schließlich (4) Hinweisen, Begr¨ undungen und Randinformationen als Erl¨auterung und zur Dokumentation. Es ist zu unterscheiden zwischen der Modellierung eines existenten IT-Verbundes (Modellierung als Pr¨ ufplan) und derjenigen eines intendierten IT-Verbundes (Modellierung als Entwicklungsplan). 4. Basis-Sicherheitscheck:284 Der Basis-Sicherheitscheck nutzt die Ergebnisse der Modellierung als Pr¨ ufplan, um in einem Soll-Ist-Vergleich zu analysieren, welche Maßnahmen ausreichend und welche unzureichend umgesetzt worden sind. In einem ersten Schritt werden organisatorische Vorbereitungen, z.B. Identifikation der relevanten Ansprechpartner, getroffen. In einem zweiten Schritt findet der Soll-IstVergleich durch Interviews und stichprobenartige Kontrollen statt, um im letzten Schritt die Ergebnisse einschließlich Begr¨ undungen zu dokumentieren. 5. Erg¨anzende Sicherheitsanalyse:285 Sollte sich in der Schutzbedarfsfeststellung ein ¨ hoher oder sehr hoher Schutzbedarf f¨ ur ein System, eine Applikation oder Ahnliches ergeben, m¨ ussten erg¨anzende Sicherheitsanalysen durchgef¨ uhrt werden, um geeignete Maßnahmen zum Schutz zu identifizieren. Solche Analysen k¨onnen beispielsweise aus Risikoanalysen oder Penetrationstests bestehen und erfordern im Allgemeinen ein exzellentes Know-how f¨ ur das jeweilige Fachgebiet. 6. Realisierung von IT-Sicherheitsmaßnahmen:286 Zuerst sollten fehlende oder nur teilweise umgesetzte Sicherheitsmaßnahmen aus den vorherigen Schritten erfasst, ausgewertet und priorisiert werden. Es folgt die Konsolidierung der Maßnahmen, in der festgestellt wird, ob h¨oherwertige Maßnahmen geringerwertige Maßnahmen ersetzen (k¨onnen). Dabei muss eruiert und dokumentiert werden, ob die Maßnahmen f¨ ur die bestehenden Strukturen und Prozesse geeignet sind. Vor der Umsetzung der Maßnahmen muss eine Kosten- und Aufwandssch¨atzung durchgef¨ uhrt werden. Sollte das Budget nicht ausreichen um alle Maßnahmen umzusetzen, muss eine Priorisie281 Vgl. BSI 2005: Abschnitt 2.3. ¨ 282 Zur Zeit existieren sieben Themengebiete bzw. – wie vom BSI bezeichnet – Bausteine: Ubergeordnete Komponenten, Infrastruktur, nicht vernetzte IT-Systeme/Clients, vernetzte Systeme, Daten¨ ubertragungseinrichtungen, Telekommunikation, sonstige IT-Komponenten. 283 In der Modellierungsphase dient dies nur als Platzhalter. 284 Vgl. BSI 2005: Abschnitt 2.4. 285 Vgl. BSI 2005: Abschnitt 2.5. 286 Vgl. BSI 2005: Abschnitt 2.6.

108

2 IT-Sicherheit in Unternehmungen

rung zur Festlegung der Umsetzungsreihenfolge (nach Schadenskategorien) vorgenommen werden. In der Festlegung der Verantwortlichkeiten muss fixiert werden, wer bis wann welche Maßnahmen zu realisieren hat und an wen der Fortschritt bzw. Abschluss der Umsetzung zu berichten ist. Begleitend sollten notwendige Sensibilisierungsmaßnahmen oder Schulungen rechtzeitig konzipiert und in die Realisierung eingeplant werden. Als Ergebnis einer derartigen Analyse entsteht so ein Realisierungsplan f¨ ur die Unternehmung (siehe Tab. 2.13). Zielobjekt

Baustein

Maßnahme

Umsetzung bis

Server FE216

6.5

1.8.2007

Laptops trolling

5.3

M 1.28 Lokale USV M 4.29 Festplattenverschl¨ usselung

Con-

30.4.2007

Verantwortlich (Umsetzung, Kontrolle) U: Hr. Vogt K: Hr. M¨ uhr U: Hr. Kuhlmann K: Hr. M¨ uhr

Budgetrahmen (Invest, Betrieb p.a.) I: 2.500,B: 1.800,I: 23.000,B: 1.600,-

Bemerkung

Verschl¨ usselung mit AES oder IDEA mind. 128 Bit

Tabelle 2.13: Beispiel f¨ ur einen Realisierungsplan nach GSHB Die Tabelle 2.13 stellt dabei nur einen Ausschnitt aus einem potenziellen Realisierungsplan dar. In der Praxis fallen derartige Pl¨ane wesentlich umfangreicher aus. Der elementare Vorteil des GSHB ist, dass der Gef¨ahrdungskatalog f¨ ur jede einzelne Gef¨ahrdung auf einen entsprechenden Maßnahmenkatalog mit Handlungsanweisungen zur Reduzierung der Gef¨ahrdung verweist. Dieses Baukastenprinzip“ des GSHB erm¨oglicht es in kleineren ” Infrastrukturen, in relativ kurzer Zeit einen grundlegenden Schutz zu erreichen. Dieses Verfahren kann die sonst u ¨blichen Aufw¨ande bei Risikoanalysen reduzieren. Im Dezember 2005 hat das BSI das GSHB u ¨berarbeitet, um eine Konformit¨at zur European Cooperation for Accreditation (EA) 7/03 herzustellen.287 Damit wurden die Voraussetzungen f¨ ur eine Kompatibilit¨at zur ISO 27001 geschaffen. Die Empfehlungen der ISO-Standards 17799 und 13335 werden ebenfalls ber¨ ucksichtigt. Das neue GSHB ist dreiteilig:288 • BSI 100-1: Managementsysteme f¨ ur Informationssicherheit (ISMS). Die beschriebenen Anforderungen sind kompatibel zur ISO 27001 und ber¨ ucksichtigen die ISOStandards 17799 und 13335. • BSI 100-2: IT-Grundschutz-Vorgehensweise. Aufbau und Betrieb eines ISMS in der Praxis mit konkreten Umsetzungshinweisen. 287 Die EA 7/03 enth¨alt Richtlinien f¨ ur die Akkreditierung der Zertifizierungsinstanzen von Informationsmanagementsystemen. 288 Vgl. BSI 2005b; BSI 2005c; BSI 2004; M¨ unch 2005: 7f.

2.6 Standardwerke zur IT-Sicherheit

109

• BSI 100-3: Risikoanalyse auf der Basis von IT-Grundschutz. Erg¨anzung zur bisherigen Risikoanalyse nach GSHB. Dadurch wird der Bereich IT-Sicherheitsmanagement st¨arker von der praktischen Umsetzung der Maßnahmen (also den IT-Grundschutzkatalogen) getrennt. Eine Zertifizierung nach GSHB beinhaltet nach dem neuen Modell gleichzeitig eine offizielle Zertifizierung nach ISO 27001.289

2.6.4 Erg¨ anzende Normen, Regelwerke und Standards Es existieren weitere Normen, Regelwerke und Standards, welche die IT-Sicherheit in Unternehmungen begleitend unterst¨ utzen k¨onnen. Dies kann z.B. dann sinnvoll sein, wenn die Umsetzung von Maßnahmen gegen Gef¨ahrdungen nicht dichotom ausgepr¨agt ist, sondern der Zielerreichungsgrad beispielsweise in Prozentwerten ausgedr¨ uckt werden kann. Good-Practice-Modelle“ wie Capability Maturity Model Integration (CMMI) oder Soft” ware Process Improvement Capability dEtermination (SPICE) bzw. ISO 15504 k¨onnen besonders in Projekten dabei helfen, den Rahmen f¨ ur eine erfolgreiche Anwendung von Vorgehensmodellen in der IT zu definieren und den Reifegrad von Prozessen aufzuzeigen. Die IT Infrastructure Library (ITIL) dient der Gestaltung, Implementierung und dem Management von Steuerungsprozessen in der IT und hat sich als Standard weltweit etabliert. ITIL stellt zu diesem Zweck Verfahrensbibliotheken anhand von Best Practices zur Verf¨ ugung, welche Unternehmungen nutzen k¨onnen, um ihre Organisation prozess-, service- und kundenorientiert auszurichten.290 Dabei ist die ITIL generisch gehalten und unabh¨angig von Technologien und Anbietern. Der Themenbereich IT-Sicherheit wird in der ITIL nicht eigenst¨andig behandelt. Stattdessen wird auf den BS 7799 respektive die ISO 17799 verwiesen. Dennoch bietet ITIL die Chance, das Management der IT-Sicherheit effizienter zu gestalten, da die Managementsysteme f¨ ur Sicherheit, Services und Qualit¨at enger miteinander verbunden werden und sich Zusammenh¨ange transparenter pr¨asentieren. H¨aufig werden die Kosten f¨ ur IT und IT-Sicherheit als Gemeinkosten betrachtet. ITIL bietet durch die Zuordnung zu Prozessen und Produkten die M¨oglichkeit, derartige Kosten als St¨ uckkosten auszuweisen.291 Bei einer Einf¨ uhrung von ITIL in Unternehmungen sollte das Sicherheitsmanagement fr¨ uhzeitig beteiligt werden, um sich in die Gestaltungsprozesse zu integrieren. 289 Vgl. M¨ unch 2005: 9. 290 Vgl. BSI 2005d: 5. 291 Vgl. BSI 2005d: 9.

110

2 IT-Sicherheit in Unternehmungen

2.6.5 Fazit In Deutschland wird die Vorgehensweise bei der Initiierung, Etablierung und Aufrechterhaltung eines Managementsystems f¨ ur Informationssicherheit maßgeblich durch die beiden Teile des BS 7799 und seinen Nachfolgern sowie durch das GSHB gepr¨agt. International ist der BS 7799 der Quasistandard zur Informationssicherheit. Andere Standards und Regelwerke wie die NIST 800er Serie, The Standard, CoBIT, FIPS-140, Common Criteria etc. sind in ihrer Bedeutung – zumindest f¨ ur die Automobilindustrie – nachrangig.292 Das BSI hat durch die Umgestaltung des GSHB auf eine bessere Referenzierung zu anderen Normen und Standards einen Beitrag zur praktischen Umsetzung von IT-Sicherheit in Organisationen geleistet. Die Grundlagen werden zwar nach wie vor durch die ISO 27001 und ISO 17799 vorgegeben, aber das GSHB liefert Hinweise und Hilfen zur Implementierung der Standards und ist dadurch weniger abstrakt und deutlich detaillierter. Vor allem f¨ ur Einsteiger und Fortgeschrittene aus den Bereichen IT und IT-Sicherheit ist die Unterst¨ utzung durch das GSHB sinnvoll, da die Controls ausf¨ uhrlicher beschrieben werden und Gef¨ahrdungskataloge mit entsprechenden Gegenmaßnahmen existieren.293 Eine BSI-Zertifizierung u uft sowohl das ISMS als auch die konkreten Sicherheitsmaßnah¨berpr¨ men nach IT-Grundschutz und beinhaltet in der neuen Fassung immer ein offizielles ISO 27001 Zertifikat.294 W¨ unschenswert ist (aus Sicht internationaler Unternehmungen) ei¨ ne stets aktuelle Ubersetzung in englischer Sprache, um das Normenwerk des BSI auch ausl¨andischen Unternehmungen zug¨anglich zu machen und dadurch den Verbreitungsgrad zu erh¨ohen. Eine Kombination aus GSHB, BS 7799 und ITIL scheint der bestm¨ogliche Ansatz, um nicht nur die Kontinuit¨at der IT-Sicherheit in Unternehmungen zu gew¨ahrleisten, sondern dabei gleichzeitig die Transparenz zu erh¨ohen. Eine gleichzeitige Einf¨ uhrung der drei Ans¨atze ist jedoch ein sehr komplexer Ver¨anderungsprozess, der in der Umsetzung erheblichen Risiken unterworfen ist und deshalb stufenweise mit objektiven und realistischen Zielen durchgef¨ uhrt werden sollte. Zur Zeit befinden sich die folgenden Themen im Standardisierungsverfahren der ISO:295 • ISO/IEC 27000 – ISMS Principles and Vocabulary, • ISO/IEC 27001 – ISMS Requirements (bereits ver¨offentlicht), • ISO/IEC 27002 – Code of Practice for ISMS (bisher ISO 17799), • ISO/IEC 27003 – ISMS Implementation Guidance, 292 CoBIT wird beispielsweise h¨ aufiger im Bankenumfeld eingesetzt. 293 Vgl. Campo 2005. 294 Vgl. M¨ unch 2005: 9. 295 Vgl. Jaschob 2006: 52.

2.6 Standardwerke zur IT-Sicherheit

111

• ISO/IEC 27004 – ISMS Metrics and Measurement, • ISO/IEC 27005 – ISMS Risk Standard. Dieses umfassende Rahmenwerk wird voraussichtlich dazu beitragen, Sicherheitsstrategien und deren Umsetzung in Unternehmungen zu strukturieren, harmonisieren und vergleichsf¨ahiger zu gestalten. Zur Zeit wird die Richtlinie 7/03 der European co-operation for Accreditation (EA) u ¨ berarbeitet und soll als ISO/IEC 27006 in die 27000-Familie integriert werden. Diese Richtlinie beschreibt den Prozess und die Vorgaben, die f¨ ur die Akkreditierung von Stellen, welche als Zertifizierunginstitutionen f¨ ur Informationssicherheitsmanagementsysteme agieren wollen, notwendig sind. An dieser Stelle soll noch einmal explizit daraufhin gewiesen werden, dass die Einhaltung der genannten Standards keine umfassende IT-Sicherheit garantieren kann. Es ist beispielsweise m¨oglich, dass eine Unternehmung die ISO 27001 erf¨ ullt und dennoch un” sicher“ ist. Im folgenden Kapitel werden die Charakteristika der Automobilindustrie dargestellt, um die Struktur und die Prozesse zu verdeutlichen und deren Sicherheitsbedarf zu veranschaulichen.

3 Struktur und Organisation der Automobilindustrie Die Automobilindustrie ist sowohl in ihren Prozessen als auch in ihren Strukturen sehr komplex. Die Beziehungen der Akteure auf vertikaler und horizontaler Ebene ver¨andern sich durch den enormen globalen Wettbewerbsdruck st¨andig. Die Problematik der IT-Sicherheit in F&E-Kooperationen zwischen Automobilhersteller und Zulieferer entstand aus den technischen, organisatorischen und strukturellen Ver¨anderungsprozessen in der Automobilwirtschaft. Daher ist es zur Darstellung der Problematik unerl¨asslich, die Evolution der Kooperationen und deren Treiber zu skizzieren.

3.1 Die gegenw¨ artige Automobilindustrie Die Automobilindustrie befindet sich in einem andauernden und teilweise fundamentalen Reorganisationsprozess, dessen strukturelle Ver¨anderungen sich sowohl auf einzelwirtschaftlicher als auch auf gesamtwirtschaftlicher Ebene auswirken.296 Die Umstrukturierungen basieren auf mehreren Faktoren, welche nicht zeitgleich, sondern sukzessive initiiert worden sind und erst in der Summe wirksam wurden. Folgende Elemente werden hier als bedeutsam angesehen: • Plattform-, Modul- und Gleichteilestrategie • Integration von IT in Wertsch¨opfungsprozesse • Verringerung der Fertigungstiefe Im Folgenden werden diese Faktoren n¨aher erl¨autert.

3.1.1 Plattform- und Gleichteilestrategie Die Plattform- und Gleichteilestrategie greift in Grundz¨ ugen Henry Fords Ansatz der Austauschbarkeit und Standardisierung von Bauteilen wieder auf. Dabei werden Syner296 Vgl. Reeg 1998: 26.

114

3 Struktur und Organisation der Automobilindustrie

gieeffekte genutzt, indem – auch komplexe – Komponenten in mehreren Fahrzeugmodellen eingesetzt werden (Gleichteilestrategie). Typische Beispiele der Gleichteilestrategie sind Motoren und Achsen. Damit lassen sich die Kosten in der Beschaffung reduzieren (Economies of Scale), sowie F&E-Aufwendungen effizienter nutzen (Economies of Scope). Durch die Verwendung von erprobten und gereiften Teilen l¨asst sich eine h¨ohere Qualit¨at erzielen.297 Wird die Gleichteilestrategie systematisch auf m¨oglichst viele, f¨ ur den Endkunden ¨außerlich nicht-sichbare Bestandteile angewandt, so l¨asst sich von einer Plattformstrategie sprechen.298 Unterschiedliche Fahrzeugmodelle einer Unternehmung k¨onnen zum Teil auf identischen Plattformen basieren. Die Plattformstrategie beinhaltet eine Vereinheitlichung bei gleichzeitiger Ausdifferenzierung. Eine Plattform besteht, z.B. bei Volkswagen, aus Antriebsbereich, K¨ uhler, Ventilatoren, Motorblock, Lenks¨aule, Getriebekasten, Bremsen und Kabel, Benzintank, Auspuffsystem, R¨ader sowie Vorder- und Hinterachsen. W¨ahrend dieser Bestandteil bei verschiedenen Modellen und Marken vereinheitlicht ist, wird die Ausdifferenzierung u ute (z.B. Sitze, Armaturen, Karosserie oder Stoßd¨ampfer) ¨ber die sogenannten H¨ betrieben. Dadurch kann die Markenidentit¨at gewahrt werden.299 BMW beispielsweise baut seine neue 1er-Serie auf Basis der 3er-Serie. Diese Strategie reduziert Kosten unter anderem in F&E, Beschaffung und Produktion – vor allem in Form verminderter Informations-, Such-, Kommunikations- und Kontrollkosten. Die Diversifikation wurde trotz der Gleichteilestrategie erheblich ausgeweitet: W¨ahrend das erste Ford T-Modell nur in einer Ausstattung erh¨altlich war, existieren allein beim Audi A4 u ¨ber 72 Varianten des Schalthebels und 70 verschiedene Kombiinstrumente.300 Die Automobilhersteller reagieren mit dieser Vielfalt auf Kundenw¨ unsche hinsichtlich individueller Fahrzeuge. Die Diversifikation geht im Allgemeinen in der Automobilindustrie mit einer Preisdifferenzierung einher, da so die unterschiedliche Leistungserwartung und Preisbereitschaft der Nachfragersegmente ausgenutzt werden kann. Der Endkunde nimmt eine Variantenvielfalt wahr, die innerhalb der Unternehmung jedoch nicht zu einer ad¨aquat erh¨ohten Komplexit¨at f¨ uhrt.301

297 Vgl. Gehrke/Scheibler 1998: 17. 298 Vgl. Jaeger/Kempis 1999: 373. 299 Vgl. Bl¨ocker 2001: 69. 300 Allein f¨ ur den Golf V existiert ein Spektrum von neun Motoren, vier Getrieben, zwei Karosserien, drei Basisausstattungslinien und zwei Antriebsversionen – insgesamt 98 m¨ogliche Varianten. In der Kombination mit den 171 Gestaltungsm¨ oglichkeiten bei Innenraumtrim und Lackton wird eine Variantenvielfalt von 16.758 verschieden Modellen erreicht (vgl. Volkswagen AG 2004). 301 Vgl. Jaeger/Kempis 1999: 371.

3.1 Die gegenw¨artige Automobilindustrie

115

Als Konsequenz dieser Entwicklung hat sich die Anzahl der Marktsegmente von 9 (Jahr 1987) auf 30 (Jahr 2000) kontinuierlich erweitert.302 Die erweiterte Modellpalette bedeutet jedoch in der Regel ein geringeres Produktionsvolumen pro Fahrzeugmodell bei gleichzeitig h¨oheren Kosten durch die der Produktdifferenzierung inh¨arenten Kosten in F&E, Marketing, Produktentwicklung etc..303 Durch die Verwendung von Plattformen und Gleichteilen konnten diese Kosten erheblich reduziert werden.

3.1.2 Integration von IT in Wertsch¨ opfungsprozesse Die Integration der IT in Wertsch¨opfungsprozesse fand in Ans¨atzen bereits w¨ahrend der sog. zweiten Revolution der Automobilindustrie statt,304 doch erst mit der quasiubiquit¨aren Verf¨ ugbarkeit ¨offentlicher Netze wie dem Internet und ab einem gewissen Grad der Marktpenetration mit Informations- und Kommunikationstechnologien konnte die IT entlang der Wertsch¨opfungskette zur Optimierung derselben eingesetzt werden.305 Die Entwicklungszeit eines Automobils von der strategischen Projektvorbereitung bis zum Start of Production (SOP) hat sich in den letzten Jahren signifikant verk¨ urzt.306 Die Ursachen f¨ ur die Optimierung sind teilweise in den IT-gest¨ utzten Prozessen zu finden, da erst durch IT-Unterst¨ utzung die Leistungsf¨ahigkeit von beispielsweise Rapid Prototyping oder Simultaneous Engineering voll ausgesch¨opft werden konnte. 307 Gleichzeitig bedeutet die zunehmende Elektronisierung von Gesch¨aftsprozessen eine verst¨arkte Abh¨angigkeit von der IT-Unterst¨ utzung. Die Risiken eines Ausfalls der IT, ob in Teilen oder in Summe, m¨ ussen entsprechend technisch, organisatorisch und juristisch abgesichert werden, um Produktivit¨atsausf¨allen vorzubeugen. Gerade in nicht-lokalen Kooperationen, in denen der Austausch von Informationen synchron oder zeitnah und u ¨ber elektronische Netze erfolgt, ist dies von Bedeutung. Die Produktdifferenzierung hat dazu gef¨ uhrt, dass kaum ein Fahrzeug in der Ausstattung dem anderen gleicht. Diese Ver¨anderung hatte Auswirkungen auf die Fahrzeugproduktion, da das Just-in-Time-Verfahren (JIT) in erster Linie geeignet ist, um gleiche Bauteile 302 Vgl. Sanz 2001. 303 Vgl. J¨ urgens 2003: 17. 304 Vgl. Womack/Jones/Roos 1994: 199ff. 305 BMW hat seine Produktionsstandorte derart ausgerichtet, dass durch zentrale Steuerung die Produktion jedes Modells in nahezu jedem Werk m¨ oglich ist. 306 Die Zeitdauer zur Entwicklung eines Automobils hat sich in den letzten Jahren von f¨ unf bis sechs Jahren auf zwei bis drei Jahre verk¨ urzt. Vgl. J¨ urgens 2003: 17. 307 Wertsch¨opfungsaktivit¨ aten sind zunehmend informations- und kommunikationsgepr¨agt, weshalb sich die unternehmerische Wertsch¨ opfung immer mehr in die Informationssph¨are verlagert, vgl. Picot/Reichwald/Wigand 2001: 14.

116

3 Struktur und Organisation der Automobilindustrie

zeitnah zur Montage zu liefern. Die konsequente Weiterentwicklung Just-in-Sequence (JIS) liefert die ben¨otigten Bauteile zeitnah und in der richtigen Reihenfolge. F¨ ur diese Form der Zulieferung ist eine enge Koordination zwischen Hersteller und Lieferant zwingend notwendig, da die Dauer der Lieferzeiten sich erheblich verk¨ urzt hat.308 In den letzten Jahrzehnten hat die Bedeutung von EDI (Electronic Data Interchange) und dessen Nachrichtenformaten (z.B. EDIFACT – Electronic Data Interchange for Administration, Transport and Commerce – und dessen Subsets) stetig zugenommen und ¨ abgel¨ost. W¨ahrend EDI fr¨ die klassische Datenfern¨ ubertragung (DFU) uher u ¨ ber W¨ahloder Standleitungen vorgenommen wurde, findet heute der Austausch dieser Nachrichten ¨ verst¨arkt u ¨ber das Internet statt, um dessen Kostenvorteile zu nutzen.309 Die Ubertragung von Informationen u ¨ber ¨offentliche Netze (wie das Internet) ist jedoch erheblichen Sicherheitsrisiken ausgesetzt, welche zu eliminieren oder mindestens auf ein annehmbares Maß zu reduzieren sind.

3.1.3 Verringerung der Fertigungstiefe Seit der MIT-Studie310 und dem darin beschriebenen Konzept der Lean Production gilt eine geringe Fertigungstiefe als wesentliches Merkmal einer erfolgreichen Unternehmung.311 Die Fertigungstiefe beschreibt die in der Unternehmung erbrachte Wertsch¨opfung, welche sich durch die kumulierten Aufwendungen, die nicht Vorleistungscharakter besitzen, messen l¨asst. Des Weiteren l¨asst sich durch die Fertigungstiefe der vertikale Integrationsgrad einer Unternehmung bestimmen.312 Die Automobilhersteller reduzieren zunehmend die Fertigungstiefe, d.h. sie u ¨bertragen Funktionen auf vorgelagerte Stufen der Wertsch¨opfungskette. Dieses sogenannte Outsourcing betrifft unter anderem den kapitalintensiven Bereich Forschung und Entwicklung und wird vor allem in diesem Bereich vermehrt durchgef¨ uhrt.313 Die zunehmende Variantenvielfalt der Fahrzeuge verlangen ein hohes Maß an Koordinationsverm¨ogen seitens der Automobilhersteller. Durch die stetige Verlagerung von Produktions- und Entwicklungsumf¨angen auf die Zulieferer k¨onnen sich die Automobilhersteller auf ihr Kerngesch¨aft und ihre Kernkompetenzen konzentrieren und die Komple308 Vgl. Hertwig/M¨ uhge/Pries/Tackenberg 2002: 4. 309 Zur speziellen Problematik von Web-EDI vgl. Heitmann/Neuber 2004. 310 Womack/Jones/Roos 1994. 311 Vgl. Womack/Jones/Roos 1994: 163f. 312 Vgl. M¨ uller-Stewens/Gocke 1995: 12. 313 Vgl. Radtke/Abele/Zielke 2004: 168; Schlenker 2000: 50.

3.1 Die gegenw¨artige Automobilindustrie

117

xit¨at der Leistungserstellungsprozesse innerhalb der eigenen Unternehmung vermindern. Die Verringerung der Fertigungstiefe geht einher mit der Reduzierung der Anzahl direkter Zulieferer und erm¨oglicht teilweise die Senkung der Kosten.314 Dadurch entstandene Flexibilit¨atsgewinne und Kosteneinsparungen m¨ ussen jedoch zus¨atzlichen Kostenbelastungen in Form von Logistik- und Transaktionskosten gegen¨ ubergestellt werden.315 Die Externalisierung von Produktionsbereichen seitens der Automobilhersteller beinhaltet ¨ die Ubertragung jener Volumina auf die Wirtschaftsstufe der Automobilzulieferer. Mit der Verringerung der Fertigungstiefe der Hersteller w¨achst ceteris paribus das Marktvolumen der Zulieferer.316 W¨ahrend die nominale Fertigungstiefe (Anteil der Bruttowertsch¨opfung an der Gesamtleistung) der deutschen Automobilhersteller 1980 noch bei ca. 37% lag, reduzierte sie sich bis 2001 auf unter 25%.317 . Im gleichen Zeitraum stiegen die Ums¨atze der Automobilzulieferindustrie von knapp 14 Mrd. auf nahezu 340 Mrd. Euro.318 Diese Umsatzentwicklung ist nicht nur auf die Reduzierung der Fertigungstiefe zur¨ uckzuf¨ uhren: Die Ausstattung der Fahrzeuge ist umfangreicher, es werden wesentlich mehr Fahrzeuge abgesetzt und die Leistungserstellung unterliegt teilweise h¨oheren Produktionskosten (bspw. Ressourcen wie Roh¨ol, Stahl, etc.). Die Senkung der Wertsch¨opfungstiefe durch Auslagerung von Entwicklungs- oder Produktionsbereichen hat zur Folge, dass der Unternehmungserfolg von einer erfolgreichen Kooperation mit den Zulieferern abh¨angig ist. Eine ineffiziente Beziehung zwischen den Akteuren kann zu verminderter Produktqualit¨at, geringer Liefertermintreue, Unterversorgung, hohen Beschaffungskosten, langen Entwicklungszyklen, langsamer Reaktionszeit und Inflexibilit¨at f¨ uhren.319 Bei der Auswahl des Lieferanten muss dessen finanzielle Stabilit¨at gepr¨ uft werden (z.B. u ¨ber Bonit¨at, Cash-Flow, Kundenstruktur etc.), da er einerseits robust gegen Absatzschwankungen sein muss und andererseits Vorfinanzierungen bei der Entwicklung neuer Produkte oder dem Ausbau von Produktionskapazit¨aten leisten k¨onnen muss. Handelt es sich bei dem Leistungsb¨ undel des Lieferanten um eine nicht-substituierbare Spezialit¨at, 314 Vgl. Maroscheck 1998: 50. 315 Vgl. Wertz 2000: 22. Durch Modular Sourcing Strategien (siehe Abschnitt 3.2.2, S. 124) kann die Anzahl der Beschaffungsobjekte, und damit die H¨ ohe der Transaktions- und Logistikkosten, geringer ausfallen. Vgl. Large 2000: 79. 316 Vgl. Reeg 1998: 61. 317 Vgl. VDA 2003: 65. 318 Vgl. VDA 2004: 59. 319 Vgl. Verbeck/Ziegenbein/Erni 2003: 50ff.

118

3 Struktur und Organisation der Automobilindustrie

so kann der Ausfall eines Lieferanten, z.B. durch Konkurs oder Insolvenz, zu einem Stopp der Produktion beim Abnehmer f¨ uhren.320

3.2 Automobilhersteller Weltweit existieren zur Zeit (Stand Nov. 2004) 16 unabh¨angige Automobilhersteller und die Branche konnte im Jahr 2002 weltweit ein Absatzvolumen von 56,1 Millionen Fahrzeugen vorweisen.321

3.2.1 Einfu ¨ hrung und Abgrenzung Als Automobilhersteller sind Unternehmungen zu bezeichnen, deren vorrangiges Unternehmungsziel die Entwicklung und Produktion sowie der Absatz und Vertrieb von Kraftfahrzeugen ist.322 Demgegen¨ uber sind Kraftfahrzeugproduzenten ohne Marke323 nicht gleichzusetzen mit Automobilherstellern, da Unternehmungen wie die Wilhelm Karmann GmbH oder Magna Steyr Inc. im Auftrag der Automobilhersteller zwar Fahrzeuge entwickeln und produzieren, sie aber nicht selbst¨andig vertreiben.324 Die Anzahl der unabh¨angigen Automobilhersteller325 ist seit 1980 signifikant gesunken (siehe Abb. 3.1).326 Typischerweise werden Automobilhersteller entweder nach ihrer Positionierung in den verschiedenen Marktsegmenten327 oder u ¨ber ihr produziertes Volumen unterschie320 Zum Begriff des Leistungsb¨ undels siehe Engelhardt/Kleinaltenkamp/Reckenfelderb¨aumer 1993: 406f. 321 Vgl. VDA 2003: 22. 322 Der Zusatz vorrangig ist deshalb von Bedeutung, da nahezu alle Automobilhersteller ebenso Finanzoder andere Dienstleistungen anbieten. Der Vertrieb der Produkte des Herstellers kann sowohl u ¨ ber den Handel als auch an den Endkunden (Direktvertrieb) erfolgen. 323 Sogenannte 0,5-Tier-Lieferanten, vgl. K¨ oth 2003: 40. 324 Magna Steyr hat 2003 fast 50.000 Fahrzeuge komplett produziert, d.h. auch die Beschaffung und Logistik geplant und durchgef¨ uhrt. Darunter den Mercedes E 42x, E 4Matic, G-Klasse, das Saab 93 Cabrio und den BMW X3. Wenn diejenigen Fahrzeuge mit einbezogen werden, die Magna Steyr nur montiert hat, dann erh¨ oht sich der Fahrzeugausstoß im Jahr 2003 auf nahezu 120.000 Fahrzeuge. Eine weitere Fertigungsunternehmung, die Wilhelm Karmann GmbH in Osnabr¨ uck, produzierte im Jahr 2003 u ¨ ber 73.000 Fahrzeuge. Die Porsche AG hat, zum Vergleich, im selben Zeitraum ebenfalls ca. 73.000 Fahrzeuge gefertigt. Vgl. Dr. Ing. h.c. Porsche AG 2003; Magna International Inc. 2003. 325 Unabh¨angigkeit wird hier derart definiert, dass kein dritter Automobilhersteller eine Kapitalbeteiligung von u ¨ber 50% an der Unternehmung besitzt. 326 Von der Betrachtung ausgenommen sind sehr kleine, unabh¨ angige Automobilhersteller, die weniger als 2500 Fahrzeuge pro Jahr produzieren und keinem gr¨ oßeren Automobilhersteller angeh¨oren, wie z.B. Caterham, Marcos, TVR, FBS, Invicta, Noble oder Shelby. 327 Unter Marktsegmentierung versteht man die Zerteilung eines heterogenen Gesamtmarktes in homogenere Teilm¨arkte. Vgl. Steiner/Baumgartner 2004: 617.

3.2 Automobilhersteller

119

1980

29

Alfa Romeo AMC Aston Martin BMW Chrysler Daimler-Benz de Tomaso Fiat Ford Subaru General Motors Honda Isuzu Lamborghini Lotus Mazda Mitsubishi Nissan Porsche PSA Peugeot Citroën Renault Rolls-Royce Saab Seat Suzuki Talbot/Matra Toyota Volvo Volkswagen

1990

21

BMW Chrysler Daewoo Daimler-Benz Fiat Ford General Motors Honda Hyundai Isuzu Mitsubishi Nissan Porsche PSA Peugeot Citroën Renault Rolls-Royce Rover Suzuki Toyota Volvo Volkswagen

2000

15

BMW Daimler-Chrysler Fiat Ford General Motors Honda Hyundai/Kia Mitsubishi Porsche Proton PSA Peugeot Citroën Renault-Nissan Suzuki Toyota Volkswagen

2010 (Prognose)

8

BMW Daimler-Chrysler Ford General Motors PSA Peugeot Citroën Renault-Nissan Toyota Volkswagen

Abbildung 3.1: Konsolidierung bei Automobilherstellern (vgl. Tietze 2003: 71) den.328 Sogenannte Premiumhersteller haben im Allgemeinen einen kundenorientierten Vertriebs- und Build-to-Order-Produktionsprozess, in dem sie wesentlich flexibler auf uhere dichotome Unterscheidung zwischen Kundenw¨ unsche reagieren k¨onnen.329 Die fr¨ Volumen- und Nischenproduzenten erscheint wenig sinnvoll, da sich der Markt und das Verhalten der Automobilhersteller stark ver¨andert haben. Ausschließliche, unabh¨angige Nischenproduzenten, die sich nur auf ein kleines, exklusives Marktsegment konzentrieren (z.B. Lotus, Lamborghini oder Rolls-Royce), existieren kaum noch eigenst¨andig, sondern geh¨oren in der Regel zum Portfolio großer Automobilkonzerne. Die Automobilhersteller verfolgen mit der Integration von Nischenproduzenten im Wesentlichen drei Ziele: ¨ 1. Integration des Markenimages der akquirierten Unternehmung: Durch die Ubernahme eines Nischenproduzenten erhofft sich der Automobilhersteller einen Zugewinn 328 Vgl. Tietze 2003: 18. 329 Der Automobilhersteller BMW kann das bestellte Fahrzeug des Kunden sogar noch sechs Tage vor Auslieferung auf dessen Wunsch teilweise individualisieren. Vgl. o.V. 2005a.

120

3 Struktur und Organisation der Automobilindustrie

f¨ ur das eigene Markenimage. Das Image der Marke Ferrari soll z.B. das Image der Marke Fiat mit Attributen wie Sportlichkeit oder Leistung anreichern.330 2. Integration des Know-hows: Der Automobilhersteller akquiriert einen Nischenproduzenten, um von dessen Know-how, z.B. Prozesswissen oder technologischer Vorsprung, zu profitieren. 3. Integration zur Vervollst¨andigung des eigenen Modellangebots: Die Automobilhersteller sind durch eine steigende Marktsegmentierung und der damit einhergehenden Verringerung der Marktanteile pro Segment dazu gezwungen, ihr Produktportfolio kontinuierlich auszubauen.331 Die Vereinfachung der Unterteilung in Volumen- und Nischenproduzenten respektive hinsichtlich der Markenpositionierung in Bezug auf den Preis des Produkts scheint durch den Anstieg der Marktsegmente nicht mehr angemessen. Zudem existiert keine Einigkeit u ¨ber die Segmentierung des Marktes: Im Jahr 1987 existierten neun Marktsegmente f¨ ur den Bereich PKW oder Light Vehicles“ – bis zum Jahr 2000 ist dieser Bereich auf 30 Markt” segmente angewachsen.332 Der World Car Industry Forecast Report von Global Insight unterteilt den globalen Markt in 27 Segmente.333 Diese Segmentierung des Marktes weist einige M¨angel auf, da sie sich auf mehrere Faktoren aus den Bereichen Fahrzeugspezifikation, Konsumentenwahrnehmung und den Preis als zus¨atzliches Differenzierungskriterium st¨ utzt.334 Die Kombination vernachl¨assigt dabei die Ausdifferenzierungen in den einzelnen Segmenten/Fahrzeugplattformen, so dass sich z.B. die 3er-Serie von BMW komplett in einem Segment befindet. Egal ob Cabrio, Coup´e, Touring oder Limousine und unabh¨angig von den Ausstattungslinien (insbesondere Motorisierung): Alle Modelle geh¨oren einem Segment an, obwohl die Preisspanne von 25.900,- (318i, Limousine, Basisausstattung) bis u ¨ber 65.000,- Euro (330Ci, Cabrio, Vollausstattung) reicht und die Modelle sich in ihrer Zielgruppenkonzeption erheblich unterscheiden.335 Das Kraftfahrzeugbundesamt (KBA) teilt den Markt in lediglich 11 Segmente ein.336 330 Ausf¨ uhrlicher zum Einfluss von Markentransferstrategien auf den Unternehmungswert vgl. Tomczak/Sch¨ogel/Sauer 2003. 331 Als Beispiel kann der Bereich der Light Trucks“ (unter anderem Sport Utility Vehicles (SUV), ” Gel¨andefahrzeuge, etc.) dienen: W¨ ahrend dies fr¨ uher ein Nischensegment war, hat der Anteil der Neuzulassungen dieser Fahrzeuge in den USA, den der Light Vehicles“ u ¨bertroffen. ” 332 Vgl. Sanz 2001. 333 Vgl. Global Insight 2004: 482ff. 334 Vgl. Global Insight 2004: 482f. 335 Alle Preise Stand Juli 2006, http://www.bmw.de. 336 Vgl. Kraftfahrzeugbundesamt 2003. Eine Conjoint-Analyse zur Benefitsegmentierung k¨onnte hier den Markt voraussichtlich besser aufgliedern, vgl. Steiner/Baumgartner 2004.

3.2 Automobilhersteller

121

Erst die Plattform- und Gleichteilestrategie337 erm¨oglichte den Schritt in eine kosteng¨ unstige Diversifikation des Angebots der Automobilhersteller und ver¨anderte gleichzeitig und nachhaltig die Beschaffungsstrategien der Hersteller.

3.2.2 Beschaffungsprozesse der Automobilhersteller Die f¨ ur den Leistungserstellungsprozess338 ben¨otigten Bestandteile (Rohstoffe, Teile, Entwicklungsdaten etc.) werden von den Automobilherstellern u ¨ ber Zulieferer beschafft, sofern die Bestandteile nicht durch die Hersteller selbst erstellt werden k¨onnen oder sollen.339 Beschaffung soll hier in Anlehnung an Wolters als Beschaffung von Leistungsb¨ undeln f¨ ur den Planungs- und Produktionsprozess verstanden werden.340 Diese umfassen sowohl Roh-, Hilfs- und Betriebsstoffe als auch Halbfertig- und Fertigfabrikate sowie Dienstleistungen (z.B. Ergebnisse aus Forschung und Entwicklung), nicht aber den Bezug von Maschinen und Anlagen. Die Beschaffungsbeziehung zwischen Hersteller und Zulieferer l¨asst sich u ¨ber zwei verschiedene Ans¨atze darstellen:341 1. Adversative Ans¨atze: Hersteller und Zulieferer haben gegens¨atzliche Ziele. Die Beschaffungsbeziehung wird u ¨ber Preis, Menge und Qualit¨at gesteuert, wodurch das Hauptaugenmerk des Ansatzes auf die Grenzproduktivit¨at gerichtet ist: das Streben der Unternehmungen nach Gewinnmaximierung durch m¨oglichst geringe Kosten f¨ ur eine gegebene Produktmenge. Nachteilig ist der ausschließliche Bezug auf momentane Kosten, w¨ahrend nicht kostenbezogene Einfl¨ usse, z.B. strategische Faktoren (Image der Eigenerstellung, Zuverl¨assigkeit der Bereitstellung, Qualit¨atssicherung etc.), Opportunit¨atskosten oder Erfahrungskurveneffekte, nicht in die Betrachtung einbezogen werden. 2. Kooperative Ans¨atze: Die Beziehung zwischen Hersteller und Zulieferer wird nicht nur u ¨ ber ¨okonomische Kriterien (Preis, Menge und Qualit¨at) definiert, sondern es werden zus¨atzliche (qualitative) Determinanten in die Betrachtung integriert. Die 337 Vgl. Abschnitt 3.1.1, S. 113. 338 Die vorliegende Untersuchung bezieht sich dabei nicht auf Anlagen oder andere Investitionsg¨ uter im engeren Sinne. 339 Die Make-or-Buy-Problematik in Bezug auf F&E wird in den Abschnitten 4.1 und 4.2 behandelt. 340 Vgl. Wolters 1995: 34. 341 Vgl. Wolters 1995: 37ff.; Schmidt 1997: 8f. Die Betrachtung von vertikalen Kooperationen unter ITSicherheitsgesichtspunkten legt es nahe, kooperative Ans¨ atze vorzuziehen, da diese eine – f¨ ur die Gestaltungs- und Handlungsempfehlungen zwingend notwendige – strategische Orientierung aufweisen.

122

3 Struktur und Organisation der Automobilindustrie

Koordination zwischen Hersteller und Zulieferer findet, auch unter strategischen Perspektiven, in einem kontinuierlichen Interaktionsprozess statt. Die Wahl des Lieferanten in der Beschaffungsdisposition ist von materiellen, finanziellen, raum-zeitlichen und rechtlichen Variablen determiniert. Darunter sind unter anderem nachfolgende Elemente zu verstehen: • Anzahl der potenziellen Lieferanten und Marktstruktur, • geografische und logistische Faktoren (lokal, regional, global, Vorratshaltung, Justin-Time, Just-in-Sequence, Standorte, Infrastruktur etc.), • Produktions- und Entwicklungskompetenz (Zugang des Lieferanten zu Produktionsfaktoren, wie z.B. Rohstoffe, spezielle Anlagen oder Know-how), • Position des Lieferanten in der Wertsch¨opfungskette, • Wertigkeit/Beschaffenheit der zu beschaffenden G¨ uter (z.B. Teile, Komponenten, Module, Systeme oder Know-how; verderbliche oder fragile G¨ uter, etc.; Commodities oder G¨ uter mit hoher Spezifit¨at; Wert pro Einheit und in Summe; technische Komplexit¨at), • Stand der Entwicklung oder Produktion (etablierte, neue oder zuk¨ unftige G¨ uter/Produkte) • juristische Faktoren (Verf¨ ugungsrechte, Patente, etc.), • Bonit¨at/Liquidit¨at des Lieferanten, • Konditionen, Preise und Kosten, • Dauer und Umfang der Beschaffung (einmalig, periodisch, unregelm¨aßig oder kontinuierlich; Kleinstmengen oder große St¨ uckzahlen), • Vertrauensverh¨altnisse und Erfahrungen, • Make-or-Buy-Entscheidungen, • Qualit¨atsanforderungen (Zertfikate, Qualifikationen) und • ¨okologische Faktoren (Zertifikate, Einhaltung von Umweltstandards). Aus oben genannten Faktoren lassen sich unternehmungs- oder produktspezifische Beschaffungsstrategien ableiten, die die Art der Beschaffung manifestieren. In der Beschaffung werden in der Regel G¨ uter zu Warengruppen zusammengefasst, die in ihrer Technologie- und Funktionsorientierung weitestgehend homogen sind.342 Die einzelnen Warengruppen weisen dabei spezifische Beschaffungscharakteristika auf, die f¨ ur den Gesch¨aftserfolg ausschlaggebend sein k¨onnen (vgl. Abb. 3.2). 342 Vgl. Large 2000: 57ff.

3.2 Automobilhersteller

Einfluss auf den Geschäftserfolg

hoch

123

Schlüsselprodukte

Strategische Produkte

z.B. mechanische Einzelteile, elektromechanische und pneumatische Baugruppen

IV

III

z.B. Vision-System

mittel Standardprodukte

Engpassprodukte

I

z.B. elektronische Komponenten, Tantal

z.B. Verbindungselemente, Pneumatikkomponenten

II

gering unkritisch

mittel

kritisch

Beschaffungsmarktcharakteristik

Abbildung 3.2: Abh¨angigkeit des Gesch¨aftserfolgs von den Beschaffungsmarktcharakteristika (Verbeck/Ziegenbein/Erni 2003: 52) Strebt der Automobilhersteller die Kostenf¨ uhrerschaft an, dann haben jene Warengruppen, deren Bestandteile einen erheblichen Anteil an den Gesamtkosten des Endproduktes ausmachen, einen st¨arkeren Einfluss auf den Gesch¨aftserfolg. Die Kombination aus Einfluss auf den Gesch¨aftserfolg und Beschaffungsmarktcharakteristik erlaubt die Einteilung der Warengruppen in Standard-, Schl¨ ussel-, Engpass- und strategische Produkte und die Beschaffung in jeder dieser vier Klassen unterliegt unterschiedlichen Kriterien hinsichtlich der Lieferantenauswahl.343 Es wird im Allgemeinen zwischen mehreren Formen der Beschaffung differenziert, welche im Einzelnen n¨aher erl¨autert werden sollen.344 Die folgenden Begriffe nehmen eine Unterscheidung des Beschaffungsprozesses hinsichtlich des Ortes, der Anzahl der Zulieferer und des Verfahrens vor, wobei die Begriffe zum Teil miteinander kombiniert werden k¨onnen.345 • Single, Dual und Modular Sourcing: Die Automobilhersteller streben nicht nur eine Reduzierung der Anzahl von Direktlieferanten an, sondern verringern auch in zunehmenden Maße die Fertigungstiefe. Resultat der Bestrebungen ist eine Ausweitung 343 Vgl. Verbeck/Ziegenbein/Erni 2003: 52ff. 344 Die Besonderheiten der Beschaffungsprozesse der Automobilhersteller in F&E (z.B. das Ziel Technologief¨ uhrerschaft ) werden in Kapitel 4 behandelt. 345 Beispielsweise kann ein Global Sourcing sinnvoll mit einem Electronic Procurement kombiniert werden.

124

3 Struktur und Organisation der Automobilindustrie

des sog. Single Sourcing, bei dem der Automobilhersteller identische Leistungen nicht u ¨ber mehrere (Multiple Sourcing), sondern nur u ¨ ber einen (Single Sourcing) oder zwei (Dual Sourcing) Lieferanten bezieht. Der Vorteil dieser Strategie ist die Reduzierung von Informations-, Such-, Kommunikations-, Kontroll- und Logistikkosten. Der gr¨oßte Nachteil des Single Sourcing ist die gestiegene Abh¨angigkeit des Automobilherstellers von den Leistungsb¨ undeln seines Lieferanten.346 Daher tendieren die Hersteller teilweise dazu, strategisch wichtige Produkte mit hoher Spezifit¨at u ¨ber zwei Zulieferer zu beziehen, da der Wechsel eines Partners mit hohen Kosten verbunden ist.347 Dabei ist dennoch zu beachten, dass in einer Dual Sourcing Konstellation mit hohen St¨ uckzahlen bei einem Ausfall eines Partners der verbleibende Partner in der Regel nicht ad hoc die geforderten Losmengen liefern kann, sondern eine gewisse Anlaufzeit – je nach Komplexit¨at der Komponenten, Module oder Systeme und je vorhandener Kapazit¨at – ben¨otigt. Aus diesem Grund findet bei dem Single oder Dual Sourcing von Spezialit¨aten h¨aufig eine langfristige Bindung der Partner u ¨ber 348 den gesamten Produktlebenszyklus statt. Das Modular Sourcing hat einen erheblichen Anteil an der Reduzierung der Anzahl der Zulieferer. Ein Modul- oder Systemlieferant liefert vormontierte Module oder Systeme an den Hersteller und verringert damit die Anzahl der Beschaffungsobjekte und Schnittstellen des Automobilherstellers (siehe Abb. 3.3).349 • Forward Sourcing: Ein wesentliches Merkmal des Forward Sourcing ist die fr¨ uhzeitige Einbindung des Lieferanten in den Entwicklungsprozess. Dadurch k¨onnen die Anforderungen exakter definiert und sowohl technische als auch ¨okonomische Optimierungspotenziale identifiziert und in der Entwicklung ber¨ ucksichtigt werden. Diese Form der Beschaffung eignet sich vor allem f¨ ur Neuteile und kann z.B. durch den OEM als Konzeptwettbewerb initiiert werden.350 Die durch die fr¨ uhe Zusammenarbeit entstandenen gemeinsamen Entwicklungen, f¨ uhren im Allgemeinen zu einer l¨angerfristigen Bindung von OEM und Zulieferer. • Global Sourcing: Der Begriff des Global Sourcing ist als weltweit ausgerichtete Beschaffungsstrategie zu verstehen.351 Dabei weiten die Hersteller ihre Beschaffungsak346 Zu weiteren Nachteilen siehe Abschnitt 3.1.3, S. 116. 347 Vgl. Bitzenhofer 1996: 69. 348 Sogenannte Life-Cycle-Vertr¨ age, vgl. Adolphs 1997: 23ff. und Schindele 1996: 77. 349 Vgl. Eicke/Femerling 1990a: 50; Eicke/Femerling 1990b: wig/M¨ uhge/Pries/Tackenberg 2002: 4 und Wertz 2000: 22. 350 Vgl. Sanz 2001: 8. 351 Vgl. Haslinger/Ilmert 2003: 50.

17;

Reeg

1998:

66f.;

Hert-

3.2 Automobilhersteller

125

Traditionelle Beschaffung

Lieferant 1

Modular Sourcing

Lieferant 1

Lieferant 2

Lieferant 2 Hersteller

Lieferant 3

Lieferant 3

Lieferant 4

Lieferant 4

Modul-/ SystemLieferant

Hersteller

Abbildung 3.3: Traditionelle Beschaffung und Modular Sourcing (in Anlehnung an Reeg 1998: 67) tivit¨aten global aus, um – zumeist lohnkostenbedingte – Preisvorteile zu realisieren oder um einer nationalen Angebotsenge auszuweichen. Diese Strategie setzt f¨ ur materielle G¨ uter ein erh¨ohtes Know-how in der Logistik voraus und eignet sich nur bedingt f¨ ur die produktionssynchrone Anlieferung. Mittels Global Sourcing werden haupts¨achlich Commodities (Standard- und Normteile) oder Dienstleistungen beschafft. Dabei k¨onnen die Automobilhersteller diese Form der Beschaffung als Strategie w¨ahlen, um den Wettbewerb zwischen nationalen und internationalen Zulieferern zu intensivieren.352 • Local Sourcing: Local Sourcing beschreibt die Beschaffung mit dem Fokus auf geografischer N¨ahe und wird zum Teil auch als nationale Beschaffung interpretiert.353 Gr¨ unde f¨ ur ein Local Sourcing k¨onnen unter anderem nationale Local-ContentBestimmungen sein, die einen prozentualen Bezug von einheimischen G¨ utern vorschreiben oder Importz¨olle zur Protektion des heimischen Marktes, die eventuelle Preisvorteile einer globalen Beschaffung egalisieren. • Electronic Procurement und Electronic Sourcing : Die Begriffe Electronic Procurement (eProcurement) und Electronic Sourcing, teilweise auch Digital Sourcing genannt, beschreiben den Beschaffungsprozess u ¨ber elektronische Netzwerke. Haupts¨achlich findet der Beschaffungsprozess u ¨ ber elektronische Beschaffungsmarktpl¨atze im Internet statt.354 Wettbewerbsvorteile lassen sich in den Dimensionen Kosten und Zeit (u.a. Steigerung der Beschaffungsproduktivit¨at) realisieren, 352 Vgl. Reeg 1998: 63. 353 Vgl. Arnold 1997: 111. 354 Vgl. Wirtz 2001: 274.

126

3 Struktur und Organisation der Automobilindustrie

da sich die elektronische Beschaffung flexibel einsetzen l¨asst. Die elektronische Beschaffung stellt eine Querschnittsfunktion dar, da sie in Kombination mit anderen Formen der Beschaffung eingesetzt werden kann. Die Attribute des Beschaffungsgutes sollten g¨anzlich erfassbar sein, um z.B. auch qualitative Faktoren ber¨ ucksichtigen zu k¨onnen.

3.2.3 Fazit und Ausblick Die deutschen Automobilhersteller sind technologische Weltmarktf¨ uhrer – dies verdanken sie ihren eigenen Ingenieuren und der Kooperation mit den Zulieferern.355 Die Arbeitsproduktivit¨at in Deutschland liegt jedoch unter dem Niveau franz¨osischer, USamerikanischer und japanischer Automobilhersteller.356 Neben den reduzierten Verwaltungskosten und dem geringeren Arbeitseinsatz pro Fahrzeug sind u.a. Unterschiede in der vertikalen Wertsch¨opfungstiefe auszumachen. W¨ahrend die deutschen OEMs den Anteil an der Wertsch¨opfung zwischen 1996 und 1999 um 13% reduzierten, sank die Anzahl der Besch¨aftigten lediglich um 6%.357 Als Folge der reduzierten Wertsch¨opfungstiefe und der inh¨arenten Verlagerung von Aufgaben an Zulieferunternehmungen sinkt der Beitrag der OEMs an der Fahrzeugentwicklung. Die drei Schutzziele der IT-Sicherheit m¨ ussen die verbleibenden (Kern-) Kompetenzen und das korrespondierende Know-how sch¨ utzen – dies gilt auch f¨ ur ausgelagerte Aufgaben, die von Zulieferern wahrgenommen werden. Teilweise u ¨ bernehmen Zulieferer zwar die Leistungserstellung, erhalten jedoch vom OEM nur partielle Aufgaben. Dieses Wissen um bestimmte Teilprozesse oder Vorleistungen erm¨oglicht es dem Zulieferer im Allgemeinen nicht, sich das umfassende Know-how f¨ ur den Gesamtprozess anzueignen. Die Ver¨anderungen in den Beschaffungsprozessen sind in den letzten Jahren im Wesentlichen von der Digitalisierung und Vernetzung getrieben worden. Insbesondere das Electronic Sourcing hat durch die Handelsplattformen an Bedeutung gewonnen. Grundlage f¨ ur diesen Trend sind die Gesch¨aftsprozessoptimierung und die daraus folgende Transaktionskostenreduzierung mit einer hohen Preistransparenz.358 Die Art der Beschaffung ist abh¨angig von den zu beschaffenden Leistungsb¨ undeln. Im Bereich F&E ist der Beschaffungsprozess selten als elektronische Beschaffung u ¨ber Han355 Die Anzahl der Ingenieure pro Fertigungsarbeiter in der Automobilindustrie ist in Deutschland doppelt so hoch wie in den USA. Vgl. Radtke/Abele/Zielke 2004: 165. 356 Als Arbeitsproduktivit¨ at wird der Wert der Produktion abz¨ uglich der Vorleistungen dividiert durch die Anzahl der Arbeitsstunden bezeichnet. 357 Vgl. Radtke/Abele/Zielke 2004: 166f. Die franz¨ osischen OEMs haben bei gleichbleibender Wertsch¨opfungstiefe 7% weniger Arbeitnehmer besch¨ aftigt. 358 Vgl. Wirtz 2001: 274.

3.2 Automobilhersteller

127

delsplattformen gestaltet, da Zulieferer teilweise bereits vor einer Ausschreibung beteiligt sind, z.B. um Anforderungen an das Produkt pr¨azise zu spezifizieren und im Lastenheft zu dokumentieren. Zudem w¨ urde der OEM durch eine ¨offentliche Ausschreibung sein Interesse an einer bestimmten Technologie artikulieren, wodurch eventuell R¨ uckschl¨ usse auf seine Produktstrategie geschlossen werden k¨onnten. Aus Sicht der IT-Sicherheit sind alle Formen der Beschaffung relevant, die u ¨ ber elektronische Netze vorbereitet oder durchgef¨ uhrt werden. W¨ahrend der Vorbereitungsphase der Beschaffung werden Lastenhefte oder andere Details der zu beschaffenden Leistungsb¨ undel elektronisch ausgetauscht. Derartige Informationen sind zum Teil als vertraulich oder geheim einzustufen und somit gegen Manipulation oder Einsichtnahme zu sch¨ utzen. Automobilhersteller sollten stets ihre elektronische Logistikkommunikation mit ihren Zulieferern absichern. Vor allem das Schutzziel Integrit¨at steht hier im Vordergrund. Falls es ¨ einem Angreifer gelingt, z.B. Lieferabrufe zu manipulieren, kann dies zu Uberkapazit¨ aten oder zu Unterversorgung f¨ uhren. Ein Angreifer k¨onnte z.B. die Anzahl der zu liefernden Teile manipulieren. Ein Lieferabruf f¨ ur 100 Teile k¨onnte so in einen Lieferabruf f¨ ur 100.000 Teile ver¨andert werden. Dies l¨asst sich ggf. systemtechnisch unterbinden, indem nur realistische Parameter vom IT-System entgegengenommen werden. Dennoch ließen sich in einem solchen Fall beispielsweise die Teilenummer (z.B. Automatik- statt Schaltgetriebebox) oder Ausstattungsdetails (z.B. Farbe der anzuliefernden Außenspiegel) ¨andern. Die Verf¨ ugbarkeit der Kommunikation ist ebenfalls von Bedeutung, da ohne Kommunikation keine Lieferabrufe realisierbar sind. Daher m¨ ussen R¨ uckfalll¨osungen bestehen, in denen Lieferabrufe manuell get¨atigt werden k¨onnen (z.B. per Fax oder Telefon). In der F&E handelt es sich in der Regel um eine Verbesserung bestehender Produkte oder um die Neuentwicklung von Produkten. In der Automobilindustrie entstehen 90% der Innovationen im Bereich Elektronik, wovon 80% auf den Bereich Software entfallen. 359 Softwareinnovationen sind besonders anf¨allig f¨ ur Urheberrechtsverletzungen, da bestimmte softwaretechnische L¨osungen relativ einfach kopiert oder imitiert werden k¨onnen, wenn der Quelltext (Source Code) verf¨ ugbar ist oder die bin¨are Datei disassembliert werden kann. Die Erstellung von Software geh¨ort in der Regel nicht zu den Kernkompetenzen von Automobilherstellern, weshalb diese Leistungen h¨aufig von Zulieferern erbracht werden. Kooperationen in solchen besonders innovativen Themengebieten, bed¨ urfen deshalb eines starken Schutzes der Kommunikation. Es ist davon auszugehen, dass die Informationssicherheit in großen Unternehmungen st¨arker ausgepr¨agt ist als in kleinen und mittleren 359 Vgl. Rinke 2001: 26. Die Automobilindustrie profitiert von den sinkenden Preisen f¨ ur Speichermodule. 1975 kostete ein dynamischer Schreib-Lese-Speicher (DRAM) mit einer Speicherkapazit¨at von 1 MBit ca. 75.000 Euro, w¨ahrend der Preis f¨ ur dieselbe Speicherkapazit¨at 2005 ca. 0,03 Euro betrug. Vgl. Robert Bosch 2002: 312.

128

3 Struktur und Organisation der Automobilindustrie

Unternehmungen (KMU).360 Daher werden im Folgenden die Charakteristika von Zulieferunternehmungen und die Strukturen der Zuliefererbranche in der Automobilindustrie betrachtet.

3.3 Zulieferunternehmungen Es existiert keine einheitliche Definition des Begriffs Zulieferunternehmung361 in der Automobilindustrie, da die Heterogenit¨at der Branche hinsichtlich Struktur, Gr¨oße und Ausgestaltung der Liefer- und Leistungsbeziehungen eine Abgrenzung erschwert.362 Allen gemein ist, dass Zulieferunternehmungen f¨ ur eine in der Wertsch¨opfungskette nachgelagerte Unternehmung ein Leistungsb¨ undel erstellen, welches erst durch die Integration in andere Produkte oder Leistungen seine volle Eigenschaft erf¨ ullt.363 Ein weiteres gemeinsames Merkmal ist die rechtliche Selbst¨andigkeit der Transaktionspartner.364 In Anlehnung an Ittermann/M¨ uhge/Schumann wird der Begriff der Automobilzulieferindustrie folgendermaßen abgegrenzt:365 Automobilzulieferer sind Unternehmungen, welche Leistungsb¨ undel anbieten, die direkt oder indirekt im Automobil montiert bzw. integriert werden. Die Unternehmungen stehen in einmaligen oder regelm¨aßigen Lieferbeziehungen zu den Endherstellern oder deren Zulieferern und sind rechtlich selbst¨andig. Zum Leistungsb¨ undel der Zulieferunternehmungen geh¨oren neben dem eigentlichen Zulieferprodukt teilweise zus¨atzliche Leistungen wie z.B. Materialwirtschaft, Lagerhaltung, Logistik oder Entwicklungsleistungen.366 360 Vgl. u.a. Briney/Prince 2002; Deloitte 2004: 11. 361 Die Begriffe Zulieferer, Lieferant und der angloamerikanische Begriff des Supplier“ werden im Fol” genden synonym behandelt. 362 Vgl. Schmoeckel/Liebler/Schindele 1996: 537. 363 Vgl. Reeg 1998: 28. 364 Vgl. Gehrke 2003: 11. 365 Vgl. Ittermann/M¨ uhge/Schumann 2003: 14. Dort wird u.a. die Abgrenzung vorgenommen, dass Automobilzulieferer mindestens 30% ihres Umsatzes in der Automobilindustrie erzielen m¨ ussen, w¨ahrend die Verbundinitiative Automobilwirtschaft (vgl. Verbundinitiative Automobilwirtschaft 1997: 11) dagegen mehr als 50%“ als Grundlage zur Zugeh¨ origkeit einer Unternehmung zur Automobilzulie” ferindustrie voraussetzt. Keine dieser Prozentangaben wird jedoch begr¨ undet, weshalb hier auf eine Umsatzvoraussetzung verzichtet wird. 366 Vgl. Gehrke 2003: 11.

3.3 Zulieferunternehmungen

129

3.3.1 Typologie der Zulieferunternehmungen Bisher wurden Zulieferer in der Regel anhand von zwei Faktoren unterschieden:367 1. nach Art der Kooperation mit dem Fahrzeughersteller oder 2. nach ihrer Position in der Wertsch¨opfungskette. Die Typologie der Zulieferunternehmungen nach Art der Zusammenarbeit unterscheidet zwischen drei Zuliefertypen: a) dem Entwicklungslieferant, der nach Rahmenvorgaben in eigener Verantwortung Teile und Baugruppen entwickelt, b) dem Produktionslieferant, der Teile und Baugruppen ohne eigene Entwicklungsleistungen gem¨aß den Vorgaben produziert, und c) dem kombinierten Entwicklungs- und Produktionslieferant, der teilweise Teile und Baugruppen entwickelt und diese f¨ ur die Automobilproduktion fertigt.368 Die Typologie nach der Position der Zulieferunternehmungen in der Wertsch¨opfungskette ist ein hierarchischer Ansatz, der die Lieferbeziehungen linear abbildet. Der OEM bezieht Produkte/Leistungen vom First-Tier-Lieferanten, welcher Produkte/Leistungen vom Second-Tier-Lieferanten erh¨alt, der wiederum die ben¨otigten Produkte/Leistungen vom Third-Tier-Lieferanten bezieht usw..369 In der Unterscheidung von Zuliefertypen hat sich eine Kombination aus oben genannten Faktoren weitestgehend durchgesetzt, die in einer pyramidalen Struktur einerseits die Art der Kooperation andererseits die Stellung in der Wertsch¨opfungskette ber¨ ucksichtigt (siehe Abb. 3.4). Die Automobilhersteller streben eine dreistufige pyramidale Struktur des Zulieferwesens an. Diese Bestrebungen gehen einher mit der Verringerung der Fertigungstiefe und der Reduktion von Direktzulieferern. Obwohl dieser Trend von den OEMs initiiert worden ist, bestehen einige Vorbehalte hinsichtlich einer konsequenten Umsetzung dieser Strategie, weshalb weiterhin Direktzulieferer aus den unteren Schichten existieren. Dies hat mehrere Gr¨ unde: 1. Quasimonopolstellung einiger Zulieferer : Modul- und Systemlieferanten k¨onnen bei sehr komplexen Bauteilen oder bei Bauteilen, f¨ ur deren Erstellung spezielles Wissen (z.B. Beherrschung bestimmter chemischer oder physikalischer Prozesse, wie f¨ ur Lacke oder Legierungen) oder der Zugang zu spezifischen Hochtechnologien (z.B. spezielle Prozessoren oder Anlagen/Systeme) notwendig ist, den Markt mit ihren 367 Vgl. Reeg 1998: 28ff.; Tietze 2003: 19; Wolters 1995: 7. 368 Vgl. Wolters 1995: 7. 369 Die Begriffe First-, Second- und Third-Tier sind gleichzusetzen mit System- bzw. Modul-, Komponenten- und Teilelieferanten.

130

3 Struktur und Organisation der Automobilindustrie

OEM Modul- & SystemLieferanten Komponentenlieferanten Teilelieferanten

Abbildung 3.4: Lieferantenstruktur eines OEM

Leistungsangeboten dominieren und somit die Verhandlungsposition im Beschaffungsprozess der Automobilhersteller stark beeinflussen.370 2. Flexibilit¨at der Beschaffung respektive Langfristigkeit der Liefervertr¨age: Durch die Reduzierung der Anzahl der direkten Zulieferer verlieren die Automobilhersteller die Flexibilit¨at in der Beschaffung, da die Reduzierung in der Regel mit langfristigen Liefervertr¨agen u ¨ ber den Produktlebenszyklus des Automobils einhergeht.371 Hier existiert ein starker Zusammenhang zwischen der Best¨andigkeit des Vertragsverh¨altnisses und der Spezifit¨at der Investitionen bzw. der Zeitdauer der Amortisation. Langfristige Vertr¨age signalisieren das Interesse der Vertragspartner an einer dauerhaften Gesch¨aftsbeziehung.372 3. Fehlende Kostentransparenz : Bei der Beschaffung komplexer Systeme k¨onnen Informationsasymmetrien zwischen Zulieferer und Automobilhersteller zu einer fehlenden Kostentransparenz f¨ uhren, die den Abnehmer (evtl. langfristig) benachteiligt.373 370 Verhandlungen bieten die Gelegenheit zu eigennutzorientiertem Verhalten, insbesondere bei relationalen (also unvollkommenen) Vertr¨agen. Informationsasymmetrien k¨ onnen es einem Vertragspartner erm¨oglichen, jene Quasi-Renten des Partners abzusch¨opfen, die aus der gemeinsamen Beziehung resultieren. Vgl. Williamson 1990: 60ff. 371 Vgl. Adolphs 1997: 23ff.; Schindele 1996: 77. 372 Vgl. Richter 1992: 147f.; Hanke 1993: 161f.; Schindele 1996: 77. 373 Vgl. Haslinger/Ilmert 2003: 11. Mangelnde Transparenz in Folge von versteckten Informationen (hidden information), versteckten Aktionen (hidden action) oder einer Kombination aus beidem (Infor-

3.3 Zulieferunternehmungen

131

4. Aufrechterhaltung des Wettbewerbs: Trotz des verst¨arkten Single-Sourcings wollen die Automobilhersteller den (Preis-) Wettbewerb in den Marktsegmenten der Zulieferindustrie aufrecht erhalten.374 5. Marktmacht: Die Automobilhersteller k¨onnen auf Grund ihrer Marktmacht teilweise niedrigere Preise mit Sublieferanten aushandeln, als die Zulieferer untereinander.375 Allerdings sind mittlerweile einige Zulieferer umsatzst¨arker als die Automobilhersteller. Der Umsatz des Gesch¨aftsbereichs Kraftfahrzeugtechnik der Bosch-Gruppe betrug im Gesch¨aftsjahr 2003 23,6 Milliarden Euro (bzw. 36,36 Mrd. Euro u ¨ber alle Gesch¨aftsbereiche), w¨ahrend der japanische Automobilhersteller Mazda im selben Zeitraum lediglich einen Umsatz von ca. 21,34 Mrd. Euro vorweisen konnte.376

3.3.2 Definition der Zulieferunternehmungen gem¨ aß der Typologie Ausgehend von der dargestellten Struktur (siehe Abb. 3.4, S. 130) werden die Lieferund Leistungsumf¨ange der einzelnen Zuliefertypen wie folgt unterschieden. Dabei ist zu ber¨ ucksichtigen, dass trotz der angestrebten pyramidalen Struktur die Zulieferer in der Praxis mehrere Positionen besetzen, also z.B. sowohl als Komponenten- wie auch als System- oder Modulzulieferer agieren k¨onnen.377 3.3.2.1 Teilelieferanten Die unterste Stufe der Pyramide stellen die Teilelieferanten dar, die die u ¨bergeordneten Stufen mit DIN- und Normteilen, Rohmaterialien und Halbfabrikaten beliefern.378 Es handelt sich im Allgemeinen um standardisierte Produkte (Commodities), deren Erzeugung kein spezielles Wissen voraussetzt (z.B. Schrauben, Kabel, Karosserieumf¨ange) und die in der Regel nicht weiter zerlegbar sind.379 Diese Eigenschaft signalisiert eine niedrige mationsasymmetrie) k¨ onnen die Quasi-Renten des schlechter informierten Partners aus der Beziehung absch¨opfen. 374 Vgl. VDA 2003: 64. 375 Die M¨oglichkeit der Automobilhersteller in Preisverhandlungen mit Zulieferern ihre Marktmacht zu nutzen und niedrigere Preise durchzusetzen wird, in Bezug auf Jos´e Ignacio L´ opez de Arriort´ ua, ehemaliger Konzernvorstand Beschaffung der Volkswagen AG, auch als Lopez-Effekt bezeichnet, z.B. bei Dudenh¨offer 2001: 153. Zus¨ atzliche Parameter dieser Strategie waren Produktqualit¨at, Economies of Scale und globale Pr¨ asenz. 376 Vgl. Mazda Motor Corporation (2003) und Robert Bosch GmbH (2003). 377 Vgl. Gehrke 2003: 13. 378 Vgl. Haslinger/Ilmert 2003: 6. 379 Vgl. Wolters 1995: 73.

132

3 Struktur und Organisation der Automobilindustrie

Markteintrittsbarriere und erkl¨art das Bestreben der Teilelieferanten zur Kostenf¨ uhrerschaft.380 Bei dieser Produktart sinken mit steigender Produktionsmenge die St¨ uckkosten (steigende Skalenertr¨age, Economies of Scale), welche, in Verbindung mit qualitativen Kriterien, den Erfolg eines Zulieferers begr¨ unden. Das Produkt wird in der Regel vom Abnehmer entwickelt. Die Global-Sourcing-Strategien, in Verbindung mit der Beschaffung u ¨ber die InternetPlattformen der Abnehmer (in Form von Ausschreibungen), schaffen einen starken Wettbewerbsdruck in diesem Marktsegment. 3.3.2.2 Komponentenlieferanten Komponenten sind komplexer als Teile und lassen sich in der Regel nur sehr montageund lohnkostenintensiv produzieren. Sie werden im Auftrag des Abnehmers gefertigt und dienen der weiteren Integration in dessen Systeme und Module, wobei die Integralqualit¨at (passgenaue Einbauf¨ahigkeit, Schnittstellenkompatibilit¨at) gew¨ahrleistet sein muss.381 Komponenten lassen sich zwar in Commodities (schnittstellenvariante Komponenten) und Spezialit¨aten (schnittstelleninvariante Komponenten) aufteilen, jedoch ist in der Praxis der Anteil der Commodities am Gesamtvolumen als sehr gering einzusch¨atzen.382 Spezialit¨aten weisen eine hohe Spezifit¨at und einen starken Differenzierungsgrad auf, da die Produkte speziell f¨ ur die Integration in die Produkte des Abnehmers produziert werden und daher die zweitbeste Verwendung (Quasi-Rente) zu einem hohen Wertverlust f¨ uhren w¨ urde. Produzenten von schnittstelleninvarianten Komponenten haben in der Regel l¨angerfristige Vertr¨age, unterliegen einem Single oder Dual Sourcing durch den Abnehmer und es existiert die Notwendigkeit einer intensiven Zusammenarbeit zwischen Automobilhersteller und Lieferant.383 Beispiele f¨ ur Komponenten sind Kabelb¨aume, Kupplungen oder Getriebegest¨ange.384 Der Komponentenlieferant erbringt zus¨atzlich neben der Produktion Logistikleistungen (teilweise Just-in-Time).385

380 Vgl. Gehrke 2003: 14. 381 Vgl. Haslinger/Ilmert 2003: 7. 382 Der Begriff der Schnittstellenvarianz respektive Schnittstelleninvarianz wird in der Literatur nicht einheitlich verwendet (vgl. stellvertretend f¨ ur andere Adolphs 1997: 24 vs. Heinze 1997: 52). Schnittstellenvarianz soll hier bedeuten, dass der Grad der Kompatibilit¨at der Schnittstelle zu vielen verschiedenen (End-)Produkten hoch ist, w¨ ahrend die Schnittstelleninvarianz auf eine unver¨anderliche und stark nachfragerspezifische Schnittstelle hinweist. 383 Vgl. Heinze 1997: 54. 384 Vgl. Adolphs 1997: 24. 385 Vgl. Wolters 1995: 73.

3.3 Zulieferunternehmungen

133

3.3.2.3 Kernlieferanten Die Gruppe der Kernlieferanten l¨asst sich in zwei weitere Lieferantentypen unterteilen: Die Modul- und Systemlieferanten. Beide fertigen oder aggregieren komplexe G¨ uter, welche eine hohe Wertsch¨opfung beinhalten und beim Abnehmer in das Endprodukt Automobil montiert werden und u ¨bernehmen in der Regel zus¨atzliche Aufgaben wie die Logistik und die Steuerung der Sublieferanten.386 Im Allgemeinen sind die Produkte der Modul- und Systemlieferanten sehr abnehmerspezifisch ausgerichtet. Je spezifischer und komplexer das Leistungsb¨ undel des Zulieferers ist, desto langfristiger werden die Liefervertr¨age gestaltet, da die Module und Systeme u ¨ber den gesamten Produktlebenszyklus eines Fahrzeugs ben¨otigt werden.387 In der Literatur wird entweder keine Unterscheidung zwischen den Begriffen Modul und System vorgenommen388 oder die Abgrenzung geschieht u ¨ber den Anteil der Forschungsund Entwicklungsleistungen des Lieferanten.389 Auch in der Praxis definieren die Automobilhersteller und -zulieferer Module und Systeme nicht einheitlich,390 weshalb Modulund Systemlieferanten im folgenden Abschnitt definiert werden.

3.3.2.3.1 Modullieferanten Ein Modul ist eine Baugruppe, welche aus unterschiedlichen Teilen und/oder Komponenten zusammengef¨ ugt wird, wie z.B. das Frontend, das Heiz-/Klimager¨at oder der Hilfsrahmen eines Fahrzeugs.391 Laut der Definition der Volkswagen AG entwickeln und produzieren die Modulzulieferer im Allgemeinen selbst: Diese Zusammenbauten werden in ” aller Regel vom Modullieferanten selbst entwickelt und gefertigt.“ 392 Module sind in der Regel verbaupunktorientiert, d.h. sie bestehen in der Regel aus einer physischen Einheit. Die Automobilhersteller und -zulieferer definieren mehrheitlich Module als vormontierte und ¨ortlich abgrenzbare Baugruppen, wobei die spezifischen Auspr¨agungen der jeweiligen Definitionen variieren.393 386 Vgl. Wolters 1995: 73. 387 Sogenannte Life-Cycle-Vertr¨ age, vgl. Adolphs 1997: 23ff.; Schindele 1996: 77. 388 Vgl. Gehrke (2003): 16; Wolters 1995: 72. 389 Vgl. z.B. Adolphs 1997: 25. 390 Vgl. Schmoeckel/Liebler/Schindele 1996: 538. 391 Vgl. Wertz 2000: 23; Volkswagen AG 2003: Abschnitt 4.2.4.2. 392 Vgl. Volkswagen AG 2003: Abschnitt 4.2.4.2. Dies wird in der Literatur widerspr¨ uchlich dargestellt; teilweise finden sich Aussagen, dass der Modulproduzent in der Regel die Entwicklungs- und Konstruktionsdaten vom Fahrzeughersteller u ¨ bernimmt, etwa bei Adolphs 1997: 25 oder bei Wolters 1995: 73. 393 Vgl. Schmoeckel/Liebler/Schindele 1996: 538f.

134

3 Struktur und Organisation der Automobilindustrie

Reine Modulproduzenten ohne Eigenleistungen in Forschung und Entwicklung, mit ausschließlichem Fokus auf die Fertigung von Modulen, sind eher als Integratoren zu bezeichnen, da die wesentliche Leistung in dem Aggregieren/Komplettieren von Einzelbestandteilen durch Montage besteht. Im weiteren Verlauf wird daher der Modulintegrator vom Modullieferant oder -zulieferer u ¨ ber das Fehlen von F&E-Leistungen abgegrenzt.

3.3.2.3.2 Systemlieferanten Systeme unterscheiden sich durch ein wesentliches Merkmal von Modulen, n¨amlich der Funktionalit¨at und Verbaupunktorientierung: Systeme sind in der Regel funktional abgrenzbar, das heißt, dass sich die Haupteigenschaft eines Systems auf eine oder mehrere Funktionen bezieht. W¨ahrend Module verbaupunktorientiert als physische Einheit konzipiert und produziert werden, sind Systeme nicht zwingend lokal konzentriert.394 Das Bremssystem (Bremsscheiben, Bremsbel¨age, Bremsleitungen, Bremszange, Bremskolben etc.) ist im Gegensatz z.B. zum Modul Cockpit u ¨ber das Fahrzeug verteilt und orientiert sich nicht an einem einzigen Verbaupunkt. Die Forschungs- und Entwicklungsleistungen f¨ ur Systeme werden zu wesentlichen Teilen vom Systemzulieferer in enger Kooperation mit dem Automobilhersteller erbracht. Der Zulieferer tr¨agt dabei die Probleml¨osungsverantwortung f¨ ur die Integration der Systeme in das Endprodukt des Abnehmers.395 Die Volkswagen AG definiert Systemzulieferer wie folgt:396 • Der Systemlieferant ist verantwortlich f¨ ur die Entwicklung, Beschaffung, Produktion und Anlieferung einer Baugruppe, die funktional abgrenzbar ist. • Der Systemlieferant wird fr¨ uhzeitig in den Entwicklungsprozess einbezogen und sp¨atestens am Ende der Konzeptabsicherungsphase festgelegt. • Der Lieferumfang des Systemlieferanten wird f¨ ur einen gesamten Produktlebenszyklus vollst¨andig oder anteilsm¨aßig festgelegt. Der Produktlebenszyklus eines Fahrzeugs ist eine wichtige Gr¨oße zur Abstimmung der Lebensdauer von System und Fahrzeug (integrale Zeitqualit¨at)397 sowie zur Bestimmung von weiteren Faktoren wie z.B. dem Umfang von After-Sales-Services (u.a. Bevorratung von Einzelteilen).398 394 Vgl. Reeg 1998: 32. 395 Vgl. Adolphs 1997: 25; Wolters 1995: 73. 396 Vgl. Volkswagen AG 2003: Abschnitt 4.2.4.3. 397 Vgl. Adolphs 1997: 23ff. 398 Vgl. Haslinger/Ilmert 2003: 10.

3.3 Zulieferunternehmungen

135

3.3.3 Fazit und Ausblick In der Zulieferkette ist ein direkter Zusammenhang zwischen den Dimensionen Produktkomplexit¨at, Wertsch¨opfungsbeitrag und dem Eigenanteil an Forschungs- und Entwicklungsleistungen auszumachen. Die Position in der Lieferantenkette resultiert aus der Summe der genannten Einzelfaktoren (siehe Abb. 3.5).

Spezialitäten

hoch Systeme und Module

Produktkomplexität

Wertschöpfungsbeitrag

Komponenten

Standardteile gering

Commodities niedrig

Position in der Zulieferkette/ Eigenanteil an F&E

hoch

Abbildung 3.5: Zusammenhang zwischen Produktkomplexit¨at, Wertsch¨opfung, Eigenanteil an F&E und Position in der Zulieferkette Eine hohe Produktkomplexit¨at und ein hoher Wertsch¨opfungsbeitrag lassen vermuten, dass ein hoher Anteil an F&E zur Leistungserstellung notwendig ist. Je h¨oher diese Werte ausfallen, desto st¨arker ist die Absicherung durch IT-Sicherheit angebracht. Am Markt l¨asst sich eine Tendenz zur zunehmenden Konzentration und Kooperation in der Zulieferindustrie beobachten.399 Dies hat mehrere Ursachen: Die Automobilhersteller erwarten von ihren Zulieferern Produktinnovationen und ein hohes Maß an Know-how im Bereich F&E. Zu den gefragten neuen Kompetenzfeldern geh¨oren unter anderem die Produktveredelung durch Dienstleistungen, ein kurzer Timeto-Market und die Beherrschung bzw. Eingliederung in das Supply Chain Management.400 Die Automobilhersteller erwarten von den Zulieferunternehmungen in diesem Zusammen399 Vgl. u.a. Maroschek 1998: 50; H¨agele/Sch¨on 1998: 66. 400 Vgl. Dudenh¨offer 2001: 153; Dudenh¨offer/Nagel/Havermann 2002: 28. Derweil bleiben die alten Kom” petenzfelder“, z.B. Kompetenzen in den Bereichen Qualit¨at, Projektmanagement, Prozesse, Produkte, Integration, als Basisanforderung der Hersteller an die Zusammenarbeit mit Zulieferern bestehen und sind mittlerweile Grundvoraussetzung f¨ ur eine Kooperation. Vgl. Maroscheck 1998: 50ff.

136

3 Struktur und Organisation der Automobilindustrie

hang eine Just-in-Time- oder Just-in-Sequence-Anlieferung auch in den ausl¨andischen Produktionsstandorten. Der Auf- respektive Ausbau von Fertigungskapazit¨aten im Ausland (nahe den Produktionsstandorten der Automobilhersteller) ist, ebenso wie die anderen Kompetenzfelder, sehr kapitalintensiv und stellt ein großes finanzielles Risiko f¨ ur die Zulieferunternehmungen dar, da die Auslastung des Standorts im wesentlichen vom Erfolg des Automobilherstellers in den lokalen M¨arkten bestimmt wird.401 Internationale Kooperationen, z.B. in Form von Joint-Ventures, nehmen daher zu. Der Zugang zu neuen M¨arkten l¨asst sich h¨aufig einfacher durch lokale Partner realisieren, die entsprechende Vertriebs- oder Produktionskapazit¨aten vorweisen k¨onnen. Auf Grund der starken Beanspruchung finanzieller und personeller Kapazit¨aten in F&E – z.B. durch die Entwicklung von Prototypen f¨ ur den Abnehmer, ohne dass eine Lieferbeziehung garantiert ist – finden verst¨arkt Kooperationen zwischen Zulieferern statt. Dadurch kann das gemeinsame finanzielle und personelle Potenzial effektiver und effizienter genutzt werden, was bedeutet, dass nicht nur die Kosten, sondern auch die Risiken auf die Partner verteilt werden k¨onnen.402 Gemeinsam lassen sich Synergien in Beschaffung, F&E, Produktion und Vertrieb nutzen.403 Auch in diesen horizontalen Kooperationsbeziehungen ist IT-Sicherheit notwendig, um das ausgetauschte Wissen vor Spionage oder Manipulation zu sch¨ utzen. F¨ ur umsatzstarke, große Unternehmungen ist die Beschaffung auf den Kapital- und Kreditm¨arkten ungleich einfacher als f¨ ur weniger umsatzstarke, kleine Unternehmungen aus der Zulieferindustrie.404 Da ein Wachstum in der Automobilzulieferindustrie in der Regel 401 Vgl. Dudenh¨offer/Nagel/Havermann 2002: 28. Des weiteren existieren auf ausl¨andischen M¨arkten in der Regel Local-Content-Anforderungen, die z.B. festlegen, dass ein bestimmter Prozentsatz des Fahrzeugs vor Ort produziert, komplettiert oder montiert – z.B. CKD (Completely Knocked Down) oder SKD (Semi Knocked Down) – werden muss, mit dem Ziel, die heimische Marktwirtschaft zu protegieren und Arbeitspl¨atze zu schaffen (vgl. Abend 1992: 125.). Die Hersteller von Light Trucks“ (u.a. ” Gel¨andewagen oder Sport Utility Vehicles (SUV) und Kleinbusse mit einem Gesamtgewicht von unter f¨ unf Tonnen) wurden in den USA seit 1963 (seit dem Handelskonflikt zwischen Deutschland und den USA u ahnchenfleisch) vor der ausl¨andischen Kon¨ ber den Importzoll auf gefrorenes amerikanisches H¨ kurrenz durch Importz¨ olle in H¨ ohe von 25 Prozent gesch¨ utzt, was die Grundlage f¨ ur die Entscheidung von BMW und Daimler-Chrysler, den X5 respektive die M-Klasse in den USA zu fertigen, gewesen sein mag. Der Importzoll f¨ ur normale PKW betr¨ agt 2,5 Prozent. Im Jahr 2001 u ¨ berstieg der Anteil der Light Trucks unter den Neuzulassungen bei Fahrzeugen in den USA mit 8,7 Mio. erstmals den der PKW mit 8,4 Mio. Vgl. Dieter 2003: 10f. 402 Vgl. Schmoeckel/Liebler/Schindele 1995: 36. 403 Vgl. H¨agele/Sch¨on 1998: 67. ¨ 404 Uber 80 Prozent der Fremdkapitalfinanzierung von Zulieferunternehmungen in den USA und England stammen aus einer Kapitalmarktfinanzierung, w¨ ahrend dies in Deutschland zu fast 70 Prozent u ¨ ber Bankkredite realisiert wird. Im Vorgriff auf Basel-II-Richtlinien haben sich einige Großbanken erkl¨artermaßen aus der Mittelstandsfinanzierung zur¨ uckgezogen. Vgl. VDA 2003: 65ff.

3.3 Zulieferunternehmungen

137

nur u ¨ ber Investitionen (z.B. immaterielle oder Realinvestitionen) m¨oglich ist, sind Unternehmungskonzentrationen ein Mittel, um auf den Kapital- und Bankenkreditm¨arkten das notwendige Kapital f¨ ur das externe Wachstum zu beschaffen. Der Konzentrationsprozess der Zulieferindustrie gestaltet sich sowohl horizontal als auch vertikal (Forward und Backward Integration) und findet seine Auspr¨agung in Fusionen oder Insourcing. Horizontale Unternehmungskonzentrationen k¨onnen Kostenersparnisse durch Gr¨oßenvorteile (Economies of Scale) hervorbringen, w¨ahrend vertikale Konzentrationen dazu geeignet sind, Transaktionskosten zu reduzieren. Bei den europ¨aischen Zulieferern ist die vorwiegende Form der Zusammenarbeit die F&EKooperation und hier insbesondere die B¨ undelung von komplement¨arem Know-how zur Erzielung von Wettbewerbsvorteilen.405 Hierbei werden vor allem direkte Wettbewerber und Kunden als Partner bevorzugt.406 Es ist jedoch darauf zu achten, dass nur jenes Wissen zum Partner gelangt, welches der Erf¨ ullung der gemeinsamen Ziele dient. Die M¨oglichkeit einer Diffusion von unternehmungseigenem Wissen aus anderen Bereichen zum Kooperationspartner sollte mit IT-Sicherheitsmaßnahmen unterbunden werden. Zuk¨ unftig wird sich der Kostendruck auf die Zulieferer aus den unteren Stufen der Wertsch¨opfungskette durch E-Business-Aktivit¨aten in Form von Internetausschreibungen bzw. Auktionen (Plattformen wie Covisint, VW Group Supply etc.) versch¨arfen, da die Abnehmer der Leistungen eine bessere Markttransparenz erhalten, welche aus der potenziellen Beteiligung aller relevanten Marktteilnehmer resultiert.407 Nicht erst durch die Kostensenkungen, welche maßgeblich in Zusammenhang mit den Restrukturierungsprozessen der 1990er Jahre verst¨arkt betrieben wurden, sind Controlling und strategisches Kostenmanagement wichtige Erfolgsfaktoren in der Zulieferindustrie. Prozesskosten-Rechnung, Deckungsbeitragsmanagement oder Targeting Costing sind essentielle Elemente in der Unternehmungsf¨ uhrung eines Zulieferers und Bestandteil der zuk¨ unftig notwendigen Kompetenzfelder an eine Zulieferunternehmung.408 Des Weiteren nimmt die Bedeutung des Ingredient Branding zu: Automobilhersteller reichern das Image eines Fahrzeugs durch den Einbau positiv besetzter Marken von Zulieferern an, etwa durch Bose-Soundsysteme oder Recaro-Sportsitze. Dieser Trend f¨ uhrt in einigen Teilen der Zulieferindustrie zu einem verst¨arkten Markenaufbau mit dem Ziel, den Markennamen respektive das Markenimage beim Endkunden/Verbraucher zu etablieren.409 Die Reifenindustrie nimmt in dieser Hinsicht eine Vorreiterrolle ein: Diese Unter405 Vgl. Schmoeckel/Liebler/Schindele 1995: 37. 406 Vgl. Schmoeckel/Liebler/Schindele 1995: 38. 407 Vgl. Dudenh¨offer 2001: 158. 408 Vgl. Dudenh¨offer/Nagel/Havermann 2002: 28. 409 Vgl. Dudenh¨offer 2001: 157.

138

3 Struktur und Organisation der Automobilindustrie

nehmungen, z.B. Bridgestone, Michelin, Continental etc., bewerben ihre Produkte bereits seit Jahrzehnten direkt beim Endverbraucher.410 Die Strategie bietet sich nicht f¨ ur alle Lieferanten an, da nicht jedes Leistungsb¨ undel f¨ ur einen derartigen Markenaufbau geeignet ist, zumal ein erfolgreicher nachhaltiger Markenaufbau im Bereich Business-to-Consumer in der Regel hohe Werbeaufwendungen voraussetzt. Aber auch das Business-to-BusinessGesch¨aft kann von einem entsprechenden Markenaufbau bzw. einer Markenkompetenz profitieren wie z.B. die Robert Bosch GmbH mit ihrem elektronischen Stabilit¨atsprogramm (ESP) oder dem Antiblockiersystem (ABS). Aus Sicht der IT-Sicherheit ist neben der Server- und Infrastruktursicherheit (z.B. Absicherung von Switches und Routern) die Clientsicherheit bei Zulieferern von besonderer Bedeutung. So sch¨ utzt z.B. eine Ende-zu-Ende-Verschl¨ usselung gegen Spionage auf dem Transportweg – sie ist jedoch wirkungslos, wenn einer der beteiligten Clients durch Trojaner, Keylogger oder andere Malware kompromittiert worden ist. Antivirensoftware, IDS/IPS, Mailfilter, Firewalls und vor allem eingeschr¨ankte Nutzerrechte auf den Clients (z.B. keine Administratorenrechte f¨ ur einfache Benutzer) k¨onnen hier als erste Maßnahmen helfen, derartige Risiken zu minimieren.

3.4 Ausblick auf zuku ¨ nftige Entwicklungen in der Automobilindustrie Wettbewerbsvorteile lassen sich eher durch Economies of Scope und Economies of Variety realisieren, da die Organisation des Austausches von Informationen und G¨ utern im Gesamtsystem ein h¨oheres Optimierungspotenzial aufweist als die Nutzung von Economies of Scale.411 Dies ist eine fundamentale Ver¨anderung, da derartige Potenziale in der arbeits- und kapitalintensiven Automobilproduktion bisher eher u ¨ber Economies of scale realisiert wurden.412 Produktionsprozesse lassen sich nur noch dadurch effizienter gestalten, indem Prozesse u ¨ ber die gesamte Wertsch¨opfungskette der Automobilindustrie optimiert werden. Dies f¨ uhrt h¨aufig zu einer Verlagerung der Wertsch¨opfung, da die Automobilhersteller in zunehmenden Maße die Fertigungstiefe verringern, komplette Abteilungen aufl¨osen und deren Funktionen den Zulieferern u ¨bertragen.

410 Unter den 20 umsatzst¨ arksten Zulieferern finden sich nicht wenige, die PKW-Besitzern nahezu v¨ollig unbekannt sind, wie z.B. Delphi, Visteon, Johnson Controls, Dana oder Denso. 411 Vgl. Reeg 1998: 18f. 412 Vgl. Siebert 1989: 188.

3.4 Ausblick auf zuk¨ unftige Entwicklungen in der Automobilindustrie

139

Die Automobilhersteller streben eine Verk¨ urzung der Produktionszeiten an, um das Buildto-Order-Verfahren (BTO) verst¨arkt anwenden zu k¨onnen. W¨ahrend der Endkunde 1999 bei General Motors noch acht Wochen auf ein f¨ ur ihn konfiguriertes und produziertes Automobil warten musste, sollte es ab 2003 nur noch vier bis elf Tage vom Auftrag bis zur Auslieferung dauern.413 Ein anderes Szenario geht davon aus, dass einige der Automobilhersteller nur noch als Markenintegratoren agieren werden, die Design, Fahrzeugspezifikation, Marketing und Vertrieb durchf¨ uhren, aber das Fahrzeug von Dritten produzieren lassen.414 Einige Automobilhersteller haben diesen Weg bereits bestritten: Porsche hatte die Produktion des Boxsters an die finnische Unternehmung Valmet ausgelagert, BMW l¨asst den X3 im ¨osterreichischen Graz von Magna Steyr fertigen und Volkswagen l¨asst unter anderem Cabrios bei Karmann entwickeln und produzieren. Die Automobilhersteller, die diesen Weg bestreiten, werden sich zunehmend auf ihre Kern- und Markenkompetenzen konzentrieren. Die Integration der Zulieferunternehmungen wird voraussichtlich ebenso weiter ansteigen wie deren Anteil an der Wertsch¨opfung des Fahrzeugs. Besonders der Bereich F&E wird hierbei eine wichtige Rolle spielen, da der Anteil an Entwicklungsleistungen durch Zulieferer in den letzten Jahren kontinuierlich gestiegen ist.415 Das bisher vorherrschende Distributionskonzept der Automobilhersteller u ¨ber vertikale und horizontale Absatzkanalstrukturen wird ebenfalls in Frage gestellt, da Fahrzeuge mittlerweile auch u ¨ ber andere Absatzkan¨ale, z.B. klassische Warenversandh¨auser wie Quelle oder Superm¨arkte, vertrieben werden.416 Zus¨atzlich erlaubt die Neufassung der Gruppenfreistellungsverordnung (GVO, Verordnung Nr. 1400/02) den Vertragsh¨andlern nicht nur ausschließlich Fahrzeuge eines Vertragspartners zu verkaufen, sondern jedes beliebige Fahrzeug.417 Als Konsequenz k¨onnten sich Vertragsh¨andler dazu entschließen, z.B. Neufahrzeuge von Toyota, Volkswagen, Hyundai und Peugeot zu verkaufen. Die Automobilhersteller sehen in dieser Entwicklung eine Gef¨ahrdung ihrer Einflussnahme auf den Handel und deren Preisgestaltung.

413 Atzberger/Kassner/Malorny et al. 2001: 7. 414 Vgl. Atzberger/Kassner/Malorny et al. 2001: 2f. 415 Der Vorstand der Audi AG, Dr. Martin Winterkorn, berichtet, dass 50% der Entwicklungen [..] ” Fremdleistungen [sind]. Das Ziel muss sein, 60% selbst zu machen und nur noch 40% nach außen zu geben.“ Vgl. ohne Verfasser: 2004. 416 Edeka bot den Fiat Punto und Rewe den VW-K¨ afer seinen Kunden zum Kauf in den Filialen an. Obwohl diese Strategie sich nicht als erfolgreich erwies, wird sie doch von einigen Analysten als zukunftstr¨achtig angesehen. 417 Die Automobilhersteller m¨ ussen sich f¨ ur einen exklusiven oder selektiven Vertrieb entscheiden, vgl. Europ¨aische Kommission 2002.

140

3 Struktur und Organisation der Automobilindustrie

In allen Zukunftsszenarien nimmt die Sicherheit von Informationen implizit einen erheblichen Stellenwert ein. Ausgehend von den Prozessabl¨aufen wird die IT-Unterst¨ utzung dieser Prozesse stetig zunehmen und die Risiken durch Ausfall, Manipulation, unbefugter Einsichtnahme oder Diebstahl von Systemen und Informationen betr¨achtlich steigern. Dies ist nicht nur bei Kooperationen in Bezug auf das Endprodukt Fahrzeug von h¨ochster Wichtigkeit, sondern ebenso in vorgelagerten, nicht direkt produktbezogenen Prozessen wie z.B. der Planung, Produktion und dem Betrieb von Software und Systemen, die eine Kooperation erst effizient erm¨oglichen. Eine Datenbank, die z.B. die Spezifikation aller verwendeten Teile inklusive der CAx-Daten vorh¨alt, ist ein zentraler Bestandteil f¨ ur die Leistungserstellung in F&E und Produktion. Wenn der Zugriff auf eine solche Datenbank f¨ ur mehrere Stunden oder gar Tage nicht mehr m¨oglich ist, dann kann dies immense Kosten nach sich ziehen. Wird die Datenbank kompromittiert und die Daten fallen unbefugten Dritten in die H¨ande, dann kann das Ausmaß des Gesamtschadens betr¨achtliche Summen erreichen – vor allem durch immaterielle Sch¨aden wie z.B. Imageverluste bei Verbrauchern, Partnern und Kapitalgebern. Daher ist gerade in Kooperationen mit externen Unternehmungen, bei denen unternehmungs-, produkt- oder prozessspezifisches Wissen die Unternehmungsgrenzen verl¨asst, ein hohes Maß an Aufmerksamkeit bez¨ uglich der Datensicherheit angebracht. Mangelnde oder gar fehlende IT-Sicherheit kann sowohl die Qualit¨at des Produktes Automobil als auch die H¨ohe der angestrebten Marge und den Absatz gef¨ahrden. Heutzutage befinden sich in einem modernen Oberklassefahrzeug teilweise mehr als 60 Mikrocontroller, die zur Steuerung, Diagnose und Kommunikation im und mit dem Fahrzeug eingesetzt werden. Laut der Pannenstatistik des ADAC sind mehr als 40% aller Fahrzeugausf¨alle auf Fehler in der Elektronik zur¨ uck zu f¨ uhren. Oberklassemodelle wie der Phaeton von Volkswagen sind ¨außerst komplexe Systeme. Der Phaeton verf¨ ugt u ¨ber 61 Steuerger¨ate, welche u ¨ber drei Busse, Subbusse und einen optischen Bus vernetzt sind und eine kombinierte Speicherkapazit¨at von ca. 50 Megabyte aufweisen. Im Phaeton sind 2110 Einzelleitungen mit einer Gesamtl¨ange von 3860 Metern verlegt.418 Die Qualit¨at der Software in der Elektronik ist ein wesentlicher Faktor f¨ ur die Funktionsf¨ahigkeit eines Automobils. IT-Sicherheit ist ein Bestandteil der Qualit¨at von Software. Sie kann die Integrit¨at und Authentizit¨at der Software bewahren und sorgt dar¨ uber hinaus f¨ ur die Verf¨ ugbarkeit eines Systems. Angreifer, die sich Zugriff auf Entwicklungssysteme verschaffen, k¨onnen die Software unter Umst¨anden manipulieren und somit sp¨ater Fehler in der Elektronik provozieren oder Hintert¨ uren (sog. Backdoors) in der Software implementieren, um sich sp¨ater Zugang zu den Steuerger¨aten oder dem Fahrzeug zu erm¨oglichen. Dies k¨onnte z.B. dazu

418 Vgl. Heinrich/M¨ uller/Fehrling et al. 2003: 221.

3.4 Ausblick auf zuk¨ unftige Entwicklungen in der Automobilindustrie

141

f¨ uhren, dass Wegfahrsperre von Fahrzeugen von Angreifern deaktiviert und diese Fahrzeuge unbefugt entwendet werden k¨onnen. Mittlerweile existieren IT-Sicherheitsarbeitskreise, in denen OEMs und Zulieferer vertreten sind. Dort werden Sicherheitsmaßnahmen gemeinsam als Best-Practice erarbeitet und publiziert, so z.B. Security and Reduction of Risk der Organisation for Data Exchange by Teletransmission in Europe (ODETTE) als Katalog von Empfehlungen f¨ ur die Sicherheit im E-Business bei der Kommunikation von Gesch¨aftspartnern (Business-to-Business, B2B) oder auch der Arbeitskreis Flashen/Security der Herstellerinitiative Software (HIS), der die Absicherung von Software im Automobil spezifiziert.

4 Vertikale F&E-Kooperationen in der Automobilindustrie Forschungs- und Entwicklungsvorspr¨ unge haben nur tempor¨aren Charakter. Strategische Wettbewerbsvorteile und monopolartige Gewinnpotenziale auf der Basis von Informationsvorspr¨ ungen k¨onnen von Konkurrenten heute wesentlich schneller egalisiert werden. M¨oglich wurde dies vor allem durch den weitreichenden Einsatz von modernen Informations- und Kommunikationstechnologien und der Entwicklung hin zu einer Informations- und Wissensgesellschaft. Dabei verk¨ urzen sich die Produktlebenszyklen ebenso wie die Nutzungspotenziale der gewonnenen Informationen.419 Die Frage kann nicht lauten, ob, sondern wie F&E organisiert und durchgef¨ uhrt werden soll. Noch in den 1970er Jahren war die F&E, sowohl mikro- als auch makro¨okonomisch, sequenziell organisiert420 und nur 9% der Unternehmungen f¨ uhrten kooperative F&E durch.421 Die Nachfrage nach neuen und individuellen Produkten ging Ende der 1980er Jahre einher mit der rasch voranschreitenden technischen Entwicklung, deren Komplexit¨at und Interdisziplinarit¨at kooperative F&E erforderte.422 Es wurde notwendig, die Prozesse in F&E zu parallelisieren und somit zu beschleunigen, um der Nachfrage- und Wettbewerbssituation gerecht zu werden. Zeitgleich wurden die unternehmungs¨ ubergreifenden F&E-Aktivit¨aten erheblich ausgeweitet. Die Automobilhersteller sind auf Kooperationen in F&E angewiesen. So basieren z.B. zur Zeit 90% aller Innovationen im Fahrzeug auf Elektronik (80% davon sind SoftwareInnovationen). Dieser Bereich geh¨ort in der Regel nicht zu den Kernkompetenzen der Automobilhersteller und die Zulieferer sind eher in der Lage, aktuelle Trends und Forschungsergebnisse in dieser Dom¨ane in produktives“, nutzbares Wissen umzusetzen. ”

419 Vgl. Schneider/Zieringer 1991: 1. 420 Deutsche Bank Research 2003: 18. 421 Vgl. Grefermann/Sprenger 1977: 53. 422 Vgl. Teichert 1993: 1.

144

4 Vertikale F&E-Kooperationen in der Automobilindustrie

Die j¨ahrlichen Aufwendungen der Automobilhersteller f¨ ur F&E liegen zwischen 3% bis 6% des Umsatzes, die der Zulieferer zwischen 2% und 8%.423 Die Anzahl der Patentanmeldungen im Automobilsektor in Deutschland ist im internationalen Vergleich so u ¨berdurchschnittlich stark ausgepr¨agt, dass dies bereits als technologische Spezialisierung gedeutet werden kann.424

4.1 Einfu ¨ hrung und Begriffsdefinition In der Entwicklung eines komplexen Produktes wie z.B. einem Fahrzeug findet eine Zusammenarbeit zwischen Unternehmungen entlang der Wertsch¨opfungskette statt.425 Diese Entwicklungskooperationen b¨ undeln das Wissen der beteiligten Unternehmungen und k¨onnen dazu f¨ uhren, dass das gemeinsame Forschungs- oder Entwicklungsziel effizienter und effektiver erreicht wird. Eine Kooperation beinhaltet f¨ ur den vorliegenden Sachverhalt folgende konstituierende Merkmale:426 • vertraglich geregelte, freiwillige zwischenbetriebliche Zusammenarbeit, unter • Beibehaltung wirtschaftlicher Selbst¨andigkeit zur • gemeinsamen Durchf¨ uhrung oder Koordinierung von Aufgaben. Die Beziehung zwischen den Akteuren in Kooperationen ist sowohl durch Vertrauen und Kontrolle als auch durch die Koexistenz von Kooperation und Wettbewerb gepr¨agt.427 Die Auspr¨agungen der Merkmale von Kooperationen (siehe Tab. 4.1) haben sich in dem Maße verschoben, wie die Ausgestaltung von Kooperationen und deren Schwerpunkt sich u ¨ber die Zeit ver¨andert haben:428 • Preis als einziges Kriterium (Ford/Post-Fordismus, ab 1913), • Qualit¨at als zus¨atzliches Anliegen (seit den sp¨aten 1970er Jahren), • engere Zusammenarbeit mit Zulieferern (seit den 1980er Jahren), • strategische Partnerschaften, Kollaboration (seit den fr¨ uhen 1990er Jahren). 423 Vgl. ohne Verfasser 2005: 78. Die prozentualen j¨ ahrlichen Aufwendungen bezogen auf den Umsatz werden als F&E-Intensit¨at bezeichnet. Vgl. Reeg 1998: 50. 424 Vgl. Schlenker 2000: 50f. 425 Vgl. Tietze 2003: 196. 426 Vgl. Teichert 1993: 5; Tietze 2003: 196. 427 Vgl. Sydow 1992: 93f. 428 Vgl. Schmidt 1997: 7ff.

4.1 Einf¨ uhrung und Begriffsdefinition

Merkmale Ort Zeit Dauer Anzahl der Partner Interaktionsart Systemunterst¨ utzung Kooperationsebene Prozessbezug

lokal synchron langfristig individuell unstrukturiert explizit Management horizontal

145

Auspr¨agung ←→ ←→ ←→ ←→ ←→ ←→ ←→ ←→

r¨aumlich verteilt asynchron kurzfristig kollektiv strukturiert implizit Mitarbeiter vertikal

Tabelle 4.1: Merkmale der Kooperation (Abramovici/Gerhard/Langenberg 1998: 71)

Moderne elektronisch gest¨ utzte F&E-Kooperationen sind nicht in allen Merkmalsauspr¨agungen eindeutig. Sie sind in der Regel jedoch r¨aumlich verteilt, synchron, kurzoder langfristig, kollektiv, strukturiert, implizit und/oder explizit, horizontal und/oder vertikal und k¨onnen sowohl auf der Management- als auch auf der Mitarbeiterebene gesteuert werden. F&E wird hier aufgefasst als industrielle F&E. Darunter werden alle systematischen ” und planvollen T¨atigkeiten verstanden, die mit Hilfe wissenschaftlicher Methoden den Erwerb neuen wissenschaftlich-technischen Wissens zum Ziel haben bzw. die erstmalige oder neuartige Anwendung dieses Wissens anstreben.“ 429 Der Neuigkeitsgrad ist ein stetig ausgepr¨agtes, subjektives, konstitutives Merkmal von Innovationen, welcher von kleinen inkrementellen Ver¨anderungen bis hin zu radikalen neuen Produkten und Prozessen reicht.430 Das durch F&E erzielte Wissen wird mittlerweile als eigenst¨andiger Produktionsfaktor betrachtet und ist als Bestandteil des Prozesses der Sachg¨ uterproduktion zu interpretieren.431 Das Produkt der F&E ist als ein Leistungsb¨ undel anzusehen und kann sowohl u ¨berwiegend materieller als auch immaterieller Natur sein.432 Es existiert keine allgemein g¨ ultige Definition der F&E-Kooperation und einzelne Elemente verschiedener Definitionen sind durchaus diskussionsw¨ urdig. So spricht Tietze von 429 Bund 2000: 9. Dies entspricht im Wesentlichen der Definition von Kern/Schr¨oder 1977: 16. 430 Vgl. Mangold/Kunz o.J.: 4. Der Neuigkeitsgrad von Ergebnissen in F&E ist stets subjektiv, da die Neuhaftigkeit nicht absolut, sondern relativ gesehen werden muss. Die Ergebnisse k¨onnen bereits am Markt bekannt sein, sind aber f¨ ur die am F&E-Prozess Beteiligten neuartig. Ferner existiert das Ph¨anomenen der Serendipit¨ at, welches zuf¨ allige Erkenntnisse im Forschungsprozess beschreibt, vgl. Schneider/Zieringer 1991: 7f. 431 Vgl. Bund 2000: 11f. 432 Vgl. Sydow 2003: 23.

146

4 Vertikale F&E-Kooperationen in der Automobilindustrie

einer notwendigen gemeinsamen Markt- und Zielausrichtung“ der Partner.433 Dies ist ” vor allem bei Auftragsforschung nicht zwingend der Fall, da zunehmend Leistungen zugekauft werden, die nicht zum klassischen Portfolio der Hersteller oder Zulieferer geh¨oren, wie z.B. spezielle Softwareentwicklungen. In der Automobilindustrie liegt in der Regel eine kooperative F&E vor, da ein gewisses Maß an Involvement des Kunden gegeben sein muss. Durch Vorgaben (z.B. r¨aumliche Abmessungen, elektrische Eigenschaften, Zeit-, ¨ Preis- oder Mengenvorgaben) oder Beteiligung (z.B. gemeinsame Projektteams, Uber¨ pr¨ ufung von Meilensteinen und Integralqualit¨at, Uberlassung von R¨aumen, Anlagen oder Produktbestandteilen, kontinuierliche R¨ uckkopplung) ist der Auftraggeber stets in den F&E-Prozess eingebunden. Die Integration des externen Faktors in den Leistungserstellungsprozess erhebt den Kunden in den Rang eines aktiven Co-Designers, welcher auf den Verlauf und die Ergebnisqualit¨at der F&E erheblichen Einfluss nehmen kann.434 Je wichtiger die Integralqualit¨at des F&E-Ergebnisses ist, desto mehr ist die Integration des Kunden erforderlich bzw. das Management der Kooperation ein wichtiger Faktor f¨ ur das Erreichen des angestrebten Ergebnisses.435 Dies ist unabh¨angig von dem Grad der Materialit¨at des F&E-Ergebnisses. Schwerpunkt der Analyse sind die vertikalen F&E-Kooperationen in der Automobilindustrie zwischen Automobilherstellern und direkten Zulieferunternehmungen. Vertikale Kooperationen werden hier als zielgerichtete Zusammenarbeit von Unternehmungen aus unterschiedlichen Stufen der Wertsch¨opfungskette verstanden. Folgende (teilweise strategische) Optionen ergeben sich f¨ ur den Automobilhersteller bez¨ uglich der Erstellung respektive Beschaffung von F&E-Leistungen:436 • Make (F&E-Eigenerstellung), • F&E-Tochtergesellschaft, • F&E-Joint Venture, • langfristige F&E-Kooperation, • langfristige F&E-Rahmenvertr¨age, • kurz- oder mittelfristige vertragliche Regelungen, • Buy (F&E-Fremdbezug). 433 Vgl. Tietze 2003: 196. 434 Vgl. Mangold/Kunz o.J.: 2f. 435 Vgl. Diefenbach/Kreuzinger 2004: 48. Zur Problematik einer echten Integration des externen Faktors unter Ber¨ ucksichtigung von marktlichen und hierarchischen Organisationsformen siehe Sydow 2003. 436 Vgl. Bund 2000: 57.

4.1 Einf¨ uhrung und Begriffsdefinition

147

In der vorliegenden Betrachtung werden die F&E-Eigenerstellung und -Tochtergesellschaften nicht weitergehend analysiert, da dort keine vertikale Kooperation mit externen Partnern gegeben ist.437 Es lassen sich drei Arten von F&E-Kooperation klassifizieren, welche einen potenziellen Mehrwert f¨ ur die beteiligten Unternehmungen aufweisen:438 1. Kooperation als Alternative zur Eigenintegration/Selbstvermarktung: Die Forschung und Entwicklung innerhalb einer Unternehmung (mit anschließender Internalisierung) kann zu starren Strukturen f¨ uhren und die Reaktions- und Innovationsf¨ahigkeit behindern.439 Eine Kooperation wird dann als ein Kompromiss zwischen Verpflichtung und Flexibilit¨at verstanden und kann helfen, Informationsasymmetrien und Opportunit¨atskosten zu verringern. 2. Kooperation als Risikoverminderung und zur Beschleunigung von F&E-Prozessen: Einerseits l¨asst eine Kooperation ein Risk-Pooling zu. Dadurch lassen sich mehrere technische Pfade in relativ unabh¨angigen Projekten gleichzeitig verfolgen. Andererseits k¨onnen durch ein Risk-Spreading Kosten der Projekte unter den beteiligten Unternehmungen aufgeteilt werden. 3. Kooperation als Faktor f¨ ur Synergien: Es k¨onnen Synergieeffekte durch die Kombination von F&E-Ergebnissen, technologischem und marketingspezifischem Knowhow etc. entstehen. Auf unvollkommenen Kapitalm¨arkten kann eine Kooperation deshalb eine effizientere Allokation von Kapital f¨ ur die beteiligten Unternehmungen bedeuten. Trotz der oben genannten Vorteile waren F&E-Kooperationen in der Praxis, laut Jacquemin, Ende der 1980er Jahre eher selten anzutreffen.440 Zu groß waren anscheinend die Bedenken der Unternehmungen im Hinblick auf die Schwierigkeiten und Probleme einer solchen Konstellation. Problematisch wurden unter anderem die Unterschiede in l¨ander¨ ubergreifenden Kooperationen mit verschiedenen Zielsetzungen, unterschiedliche Strategien, nationale Regelungen und Beh¨orden sowie sozio-psychologische Faktoren wie 437 Aus diesem Grund werden auch andere Formen der Zusammenarbeit hier nicht ber¨ ucksichtigt, wie z.B. strategische Allianzen, Kartelle, Konsortien, etc. 438 Dies betrifft nur die Kooperation auf F&E-Ebene, nicht aber auf der Produkt- und Absatzmarktebene. Vgl. auch im Folgenden Jacquemin 1988: 552ff. 439 Als Beispiel l¨asst sich das Not-Invented-Here“-Ph¨ anomen nennen: Unternehmungen stellen nicht ” mehr die Frage nach Make-or-Buy“ hinsichtlich ihrer F&E-Aktivit¨aten, sondern forschen und entwi” ckeln ausschließlich selbst und dies sogar dann, wenn am Markt bessere und kosteng¨ unstigere Verfahren und Technologien verf¨ ugbar sind. 440 Vgl. Jacquemin 1988: 552.

148

4 Vertikale F&E-Kooperationen in der Automobilindustrie

dem Aufeinanderstoßen ungleicher (Unternehmungs-) Kulturen, Nationalgef¨ uhl oder die Angst vor Identit¨atsverlust bewertet.441 Vor allem in horizontalen Kooperationen gestaltet sich die Partnerwahl als kompliziert, da eine gewisse Balance zwischen den Unternehmungen vorherrschen muss, damit die Kooperation nicht einen Partner stark u ¨bervorteilt. Zudem ist das Management einer solchen Kooperation schwierig, da trotz aller Maßnahmen (z.B. Patente oder Vertraulichkeitsvereinbarungen) Forschungsergebnisse viele Aspekte eines ¨offentlichen Gutes aufweisen und Resultate nicht immer einfach zu internalisieren sind.442 Die USA f¨ uhrten 1984 den National Cooperative Research Act“ (NRCA) ein, w¨ahrend ” ein europ¨aisches B¨ undnis aus Staaten und Unternehmungen 1985 (als potenzielle Antwort) die European Research Cooperative Agency“ (Eureka) schuf. 1987 wurde von der EU ” eine Gruppenfreistellung f¨ ur F&E-Kooperationen geschaffen, welche derartige (in erster Linie horizontale) Kooperationen mit anschließender Verwertung der Ergebnisse unter bestimmten Bedingungen toleriert.443 Der Artikel 81 des Vertrages der Europ¨aischen Gemeinschaft (EG) enth¨alt Rechtsvorschriften bez¨ uglich der Vereinbarungen zwischen Unternehmungen mit dem Ziel der Beeintr¨achtigung des Wettbewerbs und des Handels im Gemeinsamen Markt. Danach sind solche Zusammenschl¨ usse verboten, es sei denn, ihre Verhaltensweise ist dazu geeignet, das Wohlfahrtsniveau zu verbessern und den technologischen oder wirtschaftlichen Fortschritt zu f¨ordern (Art. 81 Abs. 3 des EG-Vertrages). Die Verordnung (EG) Nr. 2659/2000 der ” Kommission vom 29. November 2000 u ¨ ber die Anwendung von Artikel 81 Absatz 3 des Vertrages auf Gruppen von Vereinbarungen u ¨ber Forschung und Entwicklung“ l¨oste die entsprechende Vorg¨angerverordnung Nr. 418/85 vom 19.12.1984 ab und trat am 1. Januar 2001 in Kraft. Laut dieser Verordnung k¨onnen F&E-Kooperationen sowie die Verwertung der potenziellen Ergebnisse u ¨ber eine Gruppenfreistellung erfolgen, wenn bestimmte Voraussetzungen erf¨ ullt sind. Dazu geh¨ort u.a. die gemeinschaftlich betriebene Forschung und Entwicklung mit freiem Zugang der Vertragspartner zu den Ergebnissen. Weiterhin kann eine gemeinschaftliche Verwertung der (evtl. bereits durch fr¨ uhere Kooperation) erzielten Ergebnisse durch eine oder mehrere Vertragsparteien erfolgen. Dabei ist es unerheblich, ob die Vertragsparteien selbst F&E betreiben, Dritte beauftragen oder eine funktionale Teilung (z.B. Vertragspartner A betreibt F&E, w¨ahrend Vertragspartner B Marketing und Vertrieb u ¨bernimmt) vornehmen. Die gemeinsame Verwertung der Ergebnisse kann jedoch nur dann erfolgen, wenn diese als geistiges Eigentum rechtlich gesch¨ utzt sind und einen wesentlichen wirtschaftlichen oder technologischen Fortschritt beinhalten. Sie m¨ ussen zu441 Vgl. H¨orte 2002: 5f. 442 Vgl. Jacquemin 1988: 553. 443 Vgl. Rutsaert 1994: 3.

4.1 Einf¨ uhrung und Begriffsdefinition

149

dem von betr¨achtlicher Bedeutung f¨ ur das gemeinsam entwickelte Produkt oder Verfahren sein. Dabei gilt die Gruppenfreistellung bei konkurrierenden Unternehmungen f¨ ur die Dauer der Kooperation und bei nicht konkurrierenden Unternehmungen, welche eine gemeinsame Verwertung der Ergebnisse anstreben, f¨ ur einen Zeitraum von weiteren sieben Jahren nach Inverkehrbringen der Produkte in den gemeinsamen Markt. Die Freistellung kann u ¨ber diesen Zeitraum hinaus gew¨ahrt werden, wenn der kollektive Anteil der beteiligten Unternehmungen 25 Prozent am relevanten Markt nicht u ¨berschreitet. Von der Gruppenfreistellung sind kategorisch solche Vereinbarungen ausgenommen, welche unter anderem eine Beschr¨ankung des Absatzes oder der Produktion, keine Lizenzerteilung an Dritte trotz (evtl. vorgesehener) Nicht-Verwertung der Ergebnisse, Durchsetzung von Marktbeschr¨ankungen (hinsichtlich Bezug und Wiederverkauf), Preisbindung oder die Beschr¨ankung der Freiheit der Unternehmungen in Anbetracht weiterer Kooperationen und F&E-Aufwendungen vorsehen. Die Verordnung ist prinzipiell geeignet, positive Wohlfahrtseffekte von F&E-Kooperationen durch die Vermeidung ineffizienter Parallelforschung, Wissensdiffusion usw. hervorzubringen. Der anvisierte Zeitraum von sieben Jahren und der kumulierte Marktanteil von 25 Prozent k¨onnen eine Einschr¨ankung des Wettbewerbs auf der Produktmarktebene allerdings nicht ausschließen. Diese m¨ogliche Einschr¨ankung wird wahrscheinlich in Kauf genommen, um Anreize f¨ ur wohlfahrtssteigernde F&E-Kooperationen zu schaffen. Es ist allerdings nicht auszuschließen, dass die beteiligten Unternehmungen die Kooperationsvereinbarungen inoffiziell dazu nutzen, um entweder ihre Kooperationspartner zu kontrollieren oder neuen Marktteilnehmern den Marktzutritt zu erschweren. Die EU-Kommission hat ca. ein Jahr nach der Verordnung Nr. 2659/2000 die Leitlinien zur Anwendbarkeit von Artikel 81 EG-Vertrag auf Verein” barungen u ¨ber horizontale Zusammenarbeit“ (Amtsblatt der EG Nr. C 3/2 vom 6.1.01) ver¨offentlicht. Diese Leitlinien sollen u.a. Unternehmungen zu erkennen helfen, ob ihre Kooperationsvereinbarungen mit den wettbewerbsrechtlichen Regeln des Art. 81 EGV u ¨bereinstimmen bzw. ob ihre Kooperation u ¨berhaupt unter Art. 81 Abs. 1 f¨allt.444 Weiterhin soll sie f¨ ur mehr Transparenz und Klarheit sorgen, eine st¨arkere Konzentration auf ¨okonomische Entscheidungskriterien legen sowie die aktuelle Entscheidungspraxis und die Rechtsprechung des Gerichtshofes ber¨ ucksichtigen. So wird z.B. nicht nur die Marktmacht im Sinne von Marktanteilen als Beurteilungskriterium herangezogen, sondern ggf. auch die Marktkonzentration mit Hilfe des Herfindahl-Hirshman-Indexes erfasst.445

444 Gem¨aß der Leitlinie fallen nur die wenigsten F&E-Kooperationsvereinbarungen unter Art. 81 Abs. 1, vgl. Bekanntmachung der Kommission 2001: 8. 445 Vertikale Kooperationen sind in der Regel nicht von Artikel 81 des EG-Vertrages betroffen, jedoch existieren sowohl auf die Zulieferer- als auf der OEM-Ebene, immer mehr horizontale Kooperationen zwischen Unternehmungen.

150

4 Vertikale F&E-Kooperationen in der Automobilindustrie

Die Akteure haben in der Praxis spezifische Anforderungen an eine Kooperation, wobei die Sicht der Hersteller und die der Zulieferer in einigen Punkten harmonieren und in anderen differieren (siehe Abb. 4.1). Hersteller

Zulieferer

Gesamtverantwortungsbewusstsein von System- und Modullieferanten Zivilcourage der Zulieferer zuzugeben, wenn sie nicht über die notwendige Kompetenz verfügen und die an sie gestellten Anforderungen zu hoch sind Transparenz bei der Auftragsgestaltung Gegenseitiges Verständnis

Vernünftige Zielvorgaben und Unterlagen der Hersteller Regelmäßiger Informations- und Ideenaustausch Regelungen für die Abgrenzungen von Verantwortung und Zuständigkeiten Gerechte Aufteilung der Vorlaufkosten Eigenständige Entwicklung auf Basis von Lastenheften Gemeinsame Organisation zwischenbetrieblicher Aktivitäten Kultureller Fit

Übereinstimmung Offenheit und Vertrauen Gewährung eines angemessenen Freiraums für die Zulieferer Frühzeitige Integration der Zulieferer in den Entwicklungsprozess Frühzeitige Abstimmung von Änderungen Faire Preisverhandlungen Einheitliche Basis bei der Kostenkalkulation Intensiver Dialog/Kommunikation Know-how-Schutz

Abbildung 4.1: Anforderungen an Kooperationen aus Sicht der Hersteller und Zulieferer (vgl. Schmoeckel/Liebler/Schindele 1996: 541)

4.2 Make-or-Buy und F&E-Outsourcing Die Eigenerstellung (Make) und die Fremderstellung (Buy) markieren die gegens¨atzlichen Pole auf der Skala der potenziellen Bezugsm¨oglichkeiten einer Leistung. Dazwischen liegen weitere intermedi¨are Organisationsformen der Leistungserstellung (siehe S. 146). Die Entscheidung zur Eigen- oder Fremderstellung kann nachhaltig die Wettbewerbsf¨ahigkeit einer Unternehmung beeinflussen. Die Leistungserstellung in Kernkompetenzfeldern sollte im Allgemeinen von der Unternehmung vorrangig selbst durchgef¨ uhrt werden, um einem Wissensverlust oder einer starken Wissensdiffusion nach außen sowie Abh¨angigkeiten

4.3 Konventionelle vertikale F&E-Kooperationen

151

vorzubeugen. Ansonsten kann die Unternehmung den Anschluss an die Forschungsspitze verlieren oder die eigene Innovationsf¨ahigkeit hemmen. Eine Abgrenzung hinsichtlich der Frage, welches die Kernkompetenzfelder einer Unternehmung sind oder welche Wissensbereiche aus strategischen Gr¨ unden zugekauft respektive selbst erschlossen werden sollten, ist in der Praxis von den Marktgegebenheiten, der prognostizierten Entwicklung und den Kosten und Ertr¨agen abh¨angig. Der Bereich IT-Sicherheit geh¨ort in der Regel nicht zu den Kernkompetenzen von Automobilherstellern oder Zulieferern. Eine komplette Fremderstellung der IT-Sicherheit birgt jedoch erhebliche Risiken: Durch die kontinuierliche Erweiterung bzw. durch Umbau der IT-Infrastruktur m¨ ussen Sicherheitsmaßnahmen zeitgleich auf diese Zusammenh¨ange und ¨ Anderungen abgestimmt werden. Zudem besteht die Herstellung eines Fahrzeugs – von der Planungsphase bis zum Vertrieb – aus einer Vielzahl komplexer Prozesse, Interaktionen und Systeme und bedarf f¨ ur Externe einer langwierigen (und damit kostenintensiven) Einarbeitungsphase. Der Hersteller w¨ urde mit einer kompletten Fremderstellung die Hoheit u ur ihn w¨are die ¨ ber die Sicherheit der eigenen Prozesse aus der Hand geben und f¨ IT-Sicherheit der eigenen Daten im Extremfall eine Black Box. Dies bedeutet nicht, dass Prozesse und Produkte im Bereich IT-Sicherheit generell eigenerstellt werden m¨ ussen. Besonders im IT-Produktbereich ist ein Fremdbezug h¨aufig sinnvoller, da die Gestaltung sicherer Soft- und Hardware ein exzellentes mathematisches und ingenieurstechnisches Wissen voraussetzt. Die Vertrauensw¨ urdigkeit der Produkte l¨asst sich u ufungen und Zertifikate, z.B. ein BSI-Zertifikat ¨ber entsprechende externe Pr¨ oder eine Evaluation nach Common Criteria, sicherstellen.

4.3 Konventionelle vertikale F&E-Kooperationen Zur genaueren Abgrenzung wird hier nicht nur die virtuelle, sondern auch die konventionelle vertikale F&E-Kooperation betrachtet. Unter konventionellen F&E-Kooperationen soll hier die ziel- und ergebnisorientierte projekt-, prozess- oder produktbezogene Zusammenarbeit zwischen Automobilhersteller und Zulieferer verstanden werden, in denen nicht oder nur unsystematisch und sporadisch elektronisch kommuniziert und/oder kollaboriert wird. Es werden in erster Linie nicht-elektronische Dokumente verwendet. Auch in konventionellen F&E-Kooperationen ist sogenanntes Simultaneous Engineering (SE) m¨oglich, wenngleich auch nicht mit derselben Effizienz. Unter dem Begriff SE wer¨ den alle Verfahren subsumiert, die durch Parallelisierung oder gr¨oßtm¨ogliche Uberlappung und Synchronisation der Produkt- und Prozessentwicklung geeignet sind, um eine

152

4 Vertikale F&E-Kooperationen in der Automobilindustrie

Durchlaufreduzierung (k¨ urzeres Time-to-Market, Verk¨ urzung von Entwicklungszeiten) zu erreichen.446 Je komplexer das Endprodukt, desto eher kann Simultaneous Engineering durch Parallelisierung der Entwicklung Kosten reduzieren, die Qualit¨at verbessern und den Zeitaufwand verringern.447 Simultaneous Engineering ist nicht prim¨ar geeignet zur Etablierung von mehr Transparenz und nur bedingt zur Reduzierung von Kosten, da mehr Planungsunsicherheit durch einen gesteigerten Koordinationsaufwand besteht.448 Die Koordination der Kooperation u ¨ bernimmt in der Regel der Automobilhersteller, wobei sich die Koordination auch auf Beobachtung oder Kontrolle beschr¨anken kann.

4.4 Kooperative virtuelle F&E Die kooperative virtuelle F&E bezeichnet die ziel- und ergebnisorientierte projekt-, prozess- oder produktbezogene Zusammenarbeit zwischen Automobilhersteller und Zulieferer, bei der systematisch und kontinuierlich elektronisch kommuniziert und/oder kollaboriert wird. Es werden in erster Linie bzw. ausschließlich elektronische Dokumente verwendet.449 Die Ausgestaltung der Kollaboration steht in direktem Zusammenhang mit den Aufgaben (und deren Verteilung), Zielen und der Komplexit¨at der Forschungs- und Entwicklungst¨atigkeiten. Das Konzept der Digitalen Fabrik“ sieht eine durchg¨angige elektro” nische Simulation des Zusammenspiels von Produkt, Produktionsprozess und Produktionsst¨atte vor.450 Die in der Entstehung begriffene VDI-Richtlinie 4499 Digitale Fabrik“ ” definiert diese als Oberbegriff f¨ ur ein umfassendes Netzwerk von digitalen Modellen, Me” thoden und Werkzeugen – unter anderem Simulation und 3D-/VR-Visualisierung – die durch ein durchg¨angiges Datenmanagement integriert werden. Ihr Ziel ist die ganzheitliche Planung, Evaluierung und laufende Verbesserung aller wesentlichen Prozesse und Ressourcen der Fabrik in Verbindung mit dem Produkt.“ 451 Die parallele oder zeitnahe Entwicklung von Produkt und Produktionsprozess beschleunigt nicht nur die Entwicklungsphase bis zum SOP, sondern dar¨ uber hinaus auch die Neuanl¨aufe und Hochlaufzeiten in der Produktion.452 Dabei wird fr¨ uhzeitig auf fertigungsgerechte“ Produktentwicklung ” 446 Vgl. Adolphs 1997: 86. 447 Vgl. Heftrich 2001: 132. 448 Vgl. R¨ uckert/Leistenschneider/Peitz 1995. 449 Dies bezieht sich auf die inhaltliche Zusammenarbeit, da das elektronische Signieren von rechtlich relevanten Dokumenten, wie z.B. Vertr¨ agen, bisher keine bedeutsame Akzeptanz vorweisen kann. 450 Vgl. H¨ ubner 2002. 451 Zitiert nach Bierschenk 2004; die Richtlinie erscheint voraussichtlich Ende 2005. Daneben existiert eine Vielzahl weiterer Definitionen, vgl. Z¨ ah/Patron/Fusch 2003: 75f. 452 Vgl. K¨oth 2003: 38ff.; G¨ ottlicher 2004; Sch¨ ottle 2004.

4.4 Kooperative virtuelle F&E

153

bereits in der Designphase geachtet – im Idealfall werden alle Stationen des Produktlebenszyklus digital geplant und abgebildet. Einhergehend findet eine fr¨ uhe Einbeziehung aller Akteure und die Vorverlagerung von Entwicklungsaufwendungen (sog. Frontloading) statt.453 Damit lassen sich bereits in fr¨ uhen Phasen der Produktentwicklung und -planung Fehler wie z.B. Bauraumkollisionen vermeiden oder Zielkonflikte identifizieren.454 Neben der Beherrschung der Informationsquantit¨at spielt die Informationsqualit¨at in Form von Integrit¨at, Vollst¨andigkeit, Verf¨ ugbarkeit, Korrektheit und Rechtzeitigkeit eine wichtige Rolle im Konzept der Digitalen Fabrik.455 Derartige Konzepte setzen voraus, dass die zugrundeliegenden Daten in digitaler Form konsistent zur Verf¨ ugung stehen.456 Daher wird bereits in der F&E versucht, Daten durchg¨angig in digitaler Form zu erstellen und zu bearbeiten und ein zentrales Datenmanagement457 zu betreiben. Dieses Vorgehen ist auch in Bezug auf Kooperationen produktiv nutzbar, da der Austausch respektive die gemeinsame Bearbeitung von Daten mit einer identischen Datenbasis ohne Medienbr¨ uche Kosten und Zeitaufw¨ande reduziert.458 Allerdings existieren keine einheitlichen Branchenstandards, so dass die Zulieferer, die f¨ ur mehrere Automobilhersteller t¨atig sind, mehrere Systeme und Applikationen vorhalten m¨ ussen.459 Dieser Sachverhalt wirkt sich negativ auf die Kosten aus und l¨asst Optimierungspotenziale hinsichtlich der Kosten externer Leistungserstellung ungenutzt. Das Simultaneous Engineering profitiert sehr stark von durchgehend digitalen Daten, da diese im Idealfall prozess- und produkt¨ ubergreifend (wieder-) verwendet werden k¨onnen. Dar¨ uber hinaus k¨onnen IT-gest¨ utzte Simulationsmethoden die aufw¨andigen Tests mit Prototypen ersetzen.460 In der kooperativen virtuellen Kooperation lassen sich verschiedene Methoden grunds¨atzlich nach ihrem zeitlichen Verlauf und ihren fokussierten Inhalten unterscheiden (siehe Abb. 4.2).

453 Vgl. Menges 2005: 25ff. 454 Vgl. Richter 2001: 2. 455 Vgl. Bullinger/Meitner 1994: 15. 456 Vgl. Atzberger/Kassner/Malorny et al. 2001: 5. 457 H¨aufig werden solche Systeme als Produktdatenmanagement- (PDM) oder als Engineering Data Management (EDM) Systeme bezeichnet. 458 Sind an der Produktentwicklung mehrere Parteien beteiligt, lassen sich weitere Kosten, z.B. durch Wegfall von Reisezeiten und -kosten, verringern. 459 In der Produktentwicklung der Automobilindustrie existiert eine CAD-Durchdringung von ca. 90%, vgl. Product Data Technology in a Network 2003b: 2. Es werden jedoch unterschiedliche Applikationen genutzt. 460 Vgl. Richter 2001: 1f.

154

4 Vertikale F&E-Kooperationen in der Automobilindustrie

Zeitlicher Verlauf Synchron

Persönliche Kommunikation

Asynchron

- Videokonferenz - Audiokonferenz

- E-Mail - Multimedia

- Shared Whiteboard / Shared Desktop - Shared Application - Shared Information Use

- Kooperativer Hypertext - Workflow - Datenaustausch

Fokus/ Inhalt Gemeinsames Material

Abbildung 4.2: Funktionalit¨at von Telekooperationssystemen (vgl. Tietze 2003: 110) Es l¨asst sich feststellen, dass die synchrone Kollaboration mit gemeinsamem Datenmaterial selten praktiziert wird und derzeit die asynchronen Kooperationsformen u ¨berwiegen. Weniger abstrakt ist die Einteilung in verschiedene Systemkategorien, die in der Automobilforschung und -entwicklung verwendet werden. Darunter fallen unter anderem:461 • rechnerbasierte Stylingsysteme, • geometrische Modellierungssysteme, • numerische Berechnungssysteme, • Systeme zur Betriebsmittelentwicklung, • wissensbasierte Systeme f¨ ur die Entwicklung von Bauteilen, • Virtual Reality-Systeme und Anwendungen, – Virtual Reality, – Digital Mock-Up (DMU), – Digital Manufacturing, – Augmented Reality, • Engineering Data Management Systeme. Aus Sicht der IT- und Informationssicherheit spielt das Format der Daten (z.B. CAxDaten oder ein Textdokument) keine wesentliche Rolle.462 Im Fokus steht vielmehr der 461 Vgl. ausf¨ uhrlich Tietze 2003: 123ff. 462 Es bestehen Ausnahmen, da das Datenformat eine Rolle spielen kann, wenn es inh¨ arente Sicherheitsfunktionen aufweist bzw. wenn konkurriende Datenformate vorhanden sind, von denen mindestens ein Format wenigstens eines der Schutzziele in irgendeiner Form gew¨ ahrleisten oder unterst¨ utzen kann.

4.5 Qualit¨atsmanagement – Bewertung von Zulieferern in Kooperationen

155

inh¨arente Wert der Daten. Es ist jedoch von Interesse, ob die Daten direkt zwischen zwei Akteuren (z.B. E-Mail) oder zwischen Akteur und System (z.B. einem Produktdatenmanagementsystem) ausgetauscht werden. Dies beeinflusst die Gestaltung von ITSicherheitsmaßnahmen. Es ist festzustellen, dass digitale Daten nicht nur einfacher auszusp¨ahen sind, sondern auch, dass Angreifer die ausgesp¨ahten Daten besser f¨ ur ihre Zwecke nutzen k¨onnen, da sie unrechtm¨aßig erworbene Daten anonym weiterreichen und verbreiten k¨onnen. In nicht oder nur einfach gesicherten Datennetzwerken ist vor allem die unbemerkte Einsicht oder Vervielf¨altigung in der Regel leichter zu bewerkstelligen, als bei nicht-elektronischen Dokumenten. Eine Zunahme der Digitalisierung beinhaltet demzufolge ein h¨oheres Risiko, Opfer des Aussp¨ahens von Daten zu werden. Die Integrit¨at und Verf¨ ugbarkeit der Daten ist in den knappen Zeitvorgaben im Produktentwicklungsprozess (PEP) der Automobilindustrie von hoher Bedeutung. Eine um sechs Monate verz¨ogerte Markteinf¨ uhrung resultiert in einem Deckungsbeitragsverlust in H¨ohe von ca. 300 Millionen Euro.463

4.5 Qualit¨ atsmanagement – Bewertung von Zulieferern in Kooperationen In Kooperationen m¨ ussen die Kooperationspartner bzw. die gemeinsamen Ergebnisse hinsichtlich verschiedener Kriterien evaluiert werden, um eine fundierte Bewertung der Kooperation vornehmen zu k¨onnen. Die Ergebnisse bilden im Allgemeinen die Entscheidungsgrundlage f¨ ur eine (evtl. ge¨anderte) Weiterf¨ uhrung oder einen Abbruch der Kooperation. Qualit¨atsmanagement wird in der Regel betrieben, da Qualit¨at als einer der strategischen Erfolgsfaktoren zur Generierung von Wettbewerbsvorteilen gilt (siehe Abb. 4.3).

463 Vgl. Tietze 2003: 94.

156

4 Vertikale F&E-Kooperationen in der Automobilindustrie

Qualität

Kunden

Zeit

Kosten

Abbildung 4.3: Strategische Erfolgsfaktoren zur Generierung von Wettbewerbsvorteilen (vgl. Keuper 2001: 12)

Die IT-Sicherheit wird f¨ ur Produkte und Services, die in relevanter Art und Weise an Kommunikation oder Kooperation beteiligt sind, zunehmend zu einem wesentlichen Qualit¨atsmerkmal.

4.5.1 Grundlagen, Aufgaben und Ziele der Zuliefererbewertung im Qualit¨ atsmanagement Um eine Bewertung von Zulieferern unter Qualit¨atsaspekten vornehmen zu k¨onnen, m¨ ussen m¨oglichst objektive Merkmale und valide Merkmalsauspr¨agungen (Messwerte) sowie ein Bewertungssystem oder -Maßstab vorliegen. Gemessen wird die Qualit¨at“, also ” ein abstraktes Konstrukt, welches sich aus mehreren Merkmalen und deren Auspr¨agungen zusammensetzen kann.464 ¨ Qualit¨at kann in diesem Sinn betrachtet werden als Grad der Ubereinstimmung zwischen ” 465 zuvor formulierten Kriterien und der erbrachten Leistung“. Die Deutsche Gesellschaft f¨ ur Qualit¨at e.V. definiert Qualit¨at als die Gesamtheit von Merkmalen (und Merkmals” werten) einer Einheit bez¨ uglich ihrer Eignung, festgelegte und vorausgesetzte Forderungen zu erf¨ ullen.“ 466 Die wesentlichen Elemente des Qualit¨atsmanagements sind Messung (Erhebung der Daten), Analyse (Auswertung) und ggf. Verbesserung. Ziel des Qualit¨atsmanagements ist die Kundenzufriedenheit. Der Kunde ist in den hier betrachteten Zusammenh¨angen der OEM und erst in zweiter Instanz der Endverbraucher. Qualit¨atsmanagement ist als iterativer Prozess und nicht als Produkt zu verstehen. 464 Zum Begriff der Qualit¨at als mehrdimensionales Konstrukt vgl. Kromrey 2001: 125. 465 Kromrey 2001: 126. 466 Zitiert nach Bruhn 2001: 27.

4.5 Qualit¨atsmanagement – Bewertung von Zulieferern in Kooperationen

157

Je h¨oher der Grad der Immaterialit¨at eines Gutes, desto problembehafteter wird die Evaluation. Gleichsam verh¨alt es sich mit der Komplexit¨at: Je umfangreicher ein zu bewertendes Leistungsb¨ undel, desto schwieriger gestaltet sich die Evaluation. Die Bewertung der intangiblen Bestandteile von Leistungen ist teilweise f¨ ur den Leistungsempf¨anger gar nicht oder nur eingeschr¨ankt durchf¨ uhrbar. Messen l¨asst sich die Qualit¨at vor allem u ¨ber metrisch (teils auch ordinal) skalierte Merkmalswerte bei Sachleistungsanteilen. So k¨onnen z.B. bei Blechteilen oder Getriebegest¨angen Dichten, Spaltmaße, Widerst¨ande, Drehmomente oder Gewichte mit gel¨aufigen Skalen, objektiven Messwerten und vorgegeben Toleranzen u uft werden (Ausf¨ uhrungsqualit¨at). ¨ berpr¨ Dagegen gestaltet sich die Bewertung der Qualit¨at von immateriellen Leistungsbestandteilen wesentlich diffuser. Software, z.B. in einem Steuerger¨at, wird im Wesentlichen nur auf die Vorgaben des Lasten-/Pflichtenheftes hin validiert und verifiziert.467 Es ist in der Regel nicht vorgesehen, dass der Leistungsempf¨anger die G¨ ute der Umsetzung (z.B. Laufzeitoder Speicherbedarfsoptimierung) g¨anzlich u uft, d.h. er kann nur das pr¨ ufen, was zu ¨berpr¨ seinem eigenen Erfahrungs- und Wissenshorizont geh¨ort. Zudem ist die Subjektivit¨at in der Bewertung von immateriellen G¨ utern generell h¨oher: Eingabemasken in Bildschirmdialogen oder andere optische Merkmale (sog. Anmutungsqualit¨at) unterliegen der subjektiven Wahrnehmung und basieren u.a. auf pers¨onlichem Geschmack, Erfahrungen oder Sichtweisen (z.B. Endanwendersicht versus Betreibersicht). Vor allem Beratungsleistungen, wie z.B. empfohlene Maßnahmen aus einer Strategieanalyse, sind ein gutes Beispiel f¨ ur die Schwierigkeit, Qualit¨at angemessen zu beurteilen. Eventuell stellt sich erst nach mehreren Jahren heraus, ob die vorgeschlagenen Maßnahmen (vermeintliche) M¨angel richtig analysiert und wirksam korrigiert haben (sog. Konzeptqualit¨at). Ebenso verh¨alt es sich mit der IT-Sicherheit in Unternehmungen: Die IT-Sicherheit wird im Idealfall von den Nutzern nur wenig als funktioneller Bestandteil von Netzwerken, Systemen oder Applikationen wahrgenommen. Erst bei Eintritt von Schadensf¨allen (z.B. Aussp¨ahung von Daten, Denial-of-Service-Angriffe, Virus- und Wurmverbreitung auf Clients, etc.) werden Qualit¨atsm¨angel offenkundig sichtbar. Dies ist sehr stark von der Testintensit¨at abh¨angig. Wenn pro Jahr nur zwei bis drei Angriffe auf ein Netzwerk oder dessen Bestandteile (Computer, Switche, Firewalls, Dial-In-Modems, etc.) stattfinden, dann ist die Anzahl und G¨ ute dieser Vorf¨alle in der Regel f¨ ur eine Bewertung der IT-Sicherheitsmaßnahmen nicht ausreichend, sondern allenfalls ein Hinweis auf einzelne Schwachstellen. Traditionell ist die Qualit¨atssicherung ein nachsorgende Kontrollinstanz, deren Selbstverst¨andnis sich im Laufe der Jahre hin zu einer proaktiven Institution mit Querschnittsaufgaben gewandelt hat. Wesentlich an dieser Ver¨anderung ist jedoch die Vorverlagerung

467 Vgl. Sch¨auffele/Zurawka 2003: 30.

158

4 Vertikale F&E-Kooperationen in der Automobilindustrie

von Qualit¨atssicherungsaufgaben an die Lieferanten.468 Diese Umschichtung hat – vor allem bei IT-Großprojekten – Auswirkungen auf das Qualit¨atsmanagement: Wenn der Auftragnehmer die Verantwortung f¨ ur die Qualit¨atssicherung u ¨bernimmt, besteht die Gefahr, dass Fehler identifiziert, aber nicht gezielt vollst¨andig eliminiert werden, da die Ziele von Projektleitung (Termintreue, Einhaltung der Kosten, Wirtschaftlichkeit) und Qualit¨atssicherung (Einhaltung von Standards, langfristige Wartbarkeit) inkongruent sein k¨onnen oder sogar konkurrieren.469 Durch dieses Spannungsfeld ist eine unabh¨angige Risikobetrachtung und Qualit¨atssicherung nicht gew¨ahrleistet. Auf Auftraggeberseite kann ein Zeit- und Kostendruck ebenfalls zur Vernachl¨assigung von Qualit¨atsgesichtpunkten f¨ uhren. Falls im Verlauf eines Projektes Anforderungen und einhergehende Qualit¨atsziele ver¨andert werden, so sollte dies dokumentiert und nicht nur informell abgesprochen werden.

4.5.2 IT-Sicherheit als weitere Dimension im Qualit¨ atsmanagement Das Ziel der Zulieferbewertung im Qualit¨atsmanagement wird hier definiert als ganzheitliche Bewertung des Zulieferers hinsichtlich der IT-Sicherheit in und von Dienst- und Sachleistungen und daran beteiligter Prozesse, Infrastrukturen und Mitarbeiter. Qualit¨atsmanagement ist stets kundenorientiert und im Zusammenhang mit der Lieferantenbewertung wird hier nicht der traditionelle Kundenbegriff verwendet, in dem Kunden alle diejenigen sind, die eine direkte Beziehung zum Produkt oder zur Leistung aufweisen. Zur Bewertung der IT-Sicherheit in einem Qualit¨atsmanagementsystem muss ein differenziertes Kundenverst¨andnis verwendet werden. Die elektronische Kommunikation in Kooperationen ist aus der Sicht der direkt beteiligten Partner mindestens bilateral. Aus externer Perspektive kann die Kommunikation aber auch als multilateral angesehen werden, da sie potenziell von Dritten beobachtet werden kann, wobei Dritte auch solche Akteure sein k¨onnen, die keinen Bezug zum Produkt, Prozess oder den beteiligten Unternehmungen aufweisen. Das Kundenverst¨andnis bezieht sich auf die Auftraggeber und -nehmer, aber um die IT-Sicherheit respektive deren Schnittstellen im Qualit¨atsmanagement zu beschreiben, muss das Verst¨andnis u ¨ber die Beteiligten an der Kommunikation dem Stakeholderansatz folgen, da potenziell jeder Akteur mit Zugang zu entsprechenden Ressourcen (bspw. Zugang zum Internet) weltweit als Angreifer fungieren kann. Die IT-Sicherheit als weitere Dimension des Qualit¨atsmanagements steht zwischen dem rationalen Qualit¨atsbegriff (ISO 9000:1994) und dem emotionalen Qualit¨atsbegriff (ISO 9000:2000 und TQM). 468 Vgl. Wertz 2000: 30. 469 Vgl. auch im Folgenden Achtert 2004: 74.

4.6 Typologisierung der F&E-Kooperationen unter Sicherheitsaspekten

159

Die IT-Sicherheit sollte – falls kein dezidiertes Risiko- oder IT-Sicherheitsmanagement vorhanden ist – als eine weitere Dimension des Qualit¨atsmanagements eingef¨ uhrt werden. Dies begr¨ undet sich u.a. in der Tatsache, dass die Prozesse zur Auditierung (z.B. Prozess-, Projekt- oder Produktaudit) im Qualit¨atsmanagement bereits definiert sind und genutzt werden k¨onnen. Nicht vorhandene IT-Sicherheit kann die Eigenschaften eines Produktes oder Services respektive die Ergebnisse einer Kooperation negativ beeinflussen. Insbesondere bei der Erstellung von Software kann ein Angreifer unerw¨ unschte Eigenschaften und Funktionen in die Software integrieren, falls kein geeignetes Instrument zur Verhinderung von Manipulation oder Sabotage genutzt wird. Es existieren mehrere Methoden, um die sichere Entwicklung von Software zu gew¨ahrleisten, z.B. Common Criteria oder FIPS-140. Ebenso kann der Reifegrad von Software durch den Einsatz der Capability Maturity Model Integration (CMMI), der Software Process Improvement Capability dEtermination (SPICE bzw. ISO 15504) oder der ISO 12207 (Prozesse im Software-Lebenszyklus) verbessert werden. Weitere Modelle und Methoden zur Etablierung von IT-Sicherheit in Organisationen, wie z.B. das Grundschutzhandbuch des BSI, der British Standard (BS) 7799 respektive die ISO 17799, The Standard, CobiT etc., k¨onnen auch im Rahmen des Qualit¨atsmanagements zur Verbesserung der Sicherheit in Kommunikationsbeziehungen wirksam genutzt werden.

4.6 Definition und Typologisierung der F&E-Kooperationen in der Automobilindustrie unter Sicherheitsaspekten Der Sicherheitsbedarf der Kommunikationsbeziehungen in F&E-Kooperationen l¨asst sich unter verschiedenen Aspekten und Risiken betrachten, die im Folgenden n¨aher erl¨autert werden sollen. Diese Aspekte sind als Bestandteil der Evaluation von Gesch¨aftsbeziehungen aus der Perspektive des Risikomanagements in Unternehmungen zu betrachten.470 470 Das Bundesministerium f¨ ur Wirtschaft und Technologie (BMWi) hat u ur Existenz¨ ber ein Portal f¨ gr¨ under einen Fragebogen bzw. Test ver¨ offentlicht, mit dem Unternehmer den Einsatz elektronischer Kooperationsformen pr¨ ufen“ k¨ onnen, vgl. BMWi 2006: 6f. Die Auswahl der Fragen und deren In” halt suggerieren jedoch, dass der Einsatz von elektronischen Kooperationen in vielen Konstellationen sinnvoll ist und die Inhalte implizieren weder eine Risikobetrachtung noch Hinweise auf notwendige Sicherheitsmaßnahmen, welche die Gefahr einer unbeabsichtigten Wissensdiffusion reduzieren k¨ onnen. Dieses Beispiel zeigt, dass IT-Sicherheit noch nicht ausreichend als Grundvoraussetzung f¨ ur elektronische Kooperationen etabliert ist.

160

4 Vertikale F&E-Kooperationen in der Automobilindustrie

4.6.1 Kooperationsumfeld Das Kooperationsumfeld bezieht sich auf alle Beziehungen des Kooperationspartners, welche die Auswahl und Ausgestaltung der Sicherheitsmaßnahmen beeinflussen. In der Regel verlangen die Automobilhersteller von den Zulieferern nicht nur eine personelle, sondern auch eine r¨aumliche Trennung der Projekte, wenn der Zulieferer auch f¨ ur Wettbewerber t¨atig ist.471 Mit dieser Maßnahme soll Wissensdiffusion vermieden werden. In diesem Zusammenhang muss auch u ¨ ber eine logische – besser noch physikalische – Trennung der IT-Netzwerke von unterschiedlichen Gruppen/Projekten entschieden werden: Eine r¨aumliche Trennung von Arbeitsgruppen, die f¨ ur konkurrierende Kunden arbeiten, impliziert auch die Trennung des Zugangs zu Informationen. In der Praxis gestaltet sich eine derartige Separation als schwierig, da Wissensdiffusion haupts¨achlich u ¨ ber pers¨onliche Kontakte stattfindet, so dass sich die Wirksamkeit einer Trennung der technischen Bewertung entzieht. In der Automobilindustrie ist es u ¨blich, dass Zulieferer zum Teil auf dem Gel¨ande des Herstellers Leistungen erbringen, z.B. die Montage von Modulen oder projektbezogene Forschungst¨atigkeiten. In der Regel ben¨otigen diese externen Mitarbeiter nicht nur einen Arbeitsplatz samt Computer, sondern auch sporadisch einen Zugang zum Netzwerk des Auftraggebers.472 Wenn mit Laptops gearbeitet wird, die Eigentum des Zulieferers sind, ergeben sich mehrere Probleme. So muss z.B. durch vertragliche/juristische Maßnahmen festgelegt werden, ob der OEM das Laptop inspizieren darf um festzustellen, inwiefern Sicherheitsmaßnahmen installiert worden sind. In manchen Unternehmungen ist der Einsatz von Fremdger¨aten in Netzwerken reglementiert oder sogar untersagt. Letzteres hat zur Folge, dass der OEM dem Zulieferer f¨ ur die Dauer der Kooperation ein Ger¨at f¨ ur die Aufgabenerf¨ ullung vor Ort zur Verf¨ ugung stellen oder anderweitige L¨osungen finden muss. Es ist auch zu kl¨aren, ob Informationen (egal in welcher Form) das Areal des OEMs verlassen d¨ urfen und wie mit den Informationen nach Beendigung der Kooperation verfahren werden soll.473

4.6.2 Produkt Die in Abschnitt 3.3.2 beschriebene Typologie der Zulieferunternehmungen klassifiziert die Lieferanten nach Komplexit¨at des Produkts. Das Produkt selbst bzw. die Produktbestandteile definieren wiederum den Sicherheitsbedarf der Kooperationbeziehungen, da der 471 Vgl. M¨ uller-Stewens/Gocke 1995: 93. 472 Zum Beispiel zur gemeinsamen Dokumentenablage, Anbindung an Produktionsnetzwerke, etc. 473 Dies kann der Fall sein, wenn externe Mitarbeiter nur zeitweise vor Ort sind und einen Teil der Aufgaben in der zuliefereigenen Umgebung durchf¨ uhren.

4.6 Typologisierung der F&E-Kooperationen unter Sicherheitsaspekten

161

inh¨arente Wert der F&E-Aufwendungen bzw. des Wissens im Produkt und/oder seiner Entstehung enthalten ist. Demzufolge sind die Kommunikationsbeziehungen zu Teilelieferanten in der Regel weniger sch¨ utzenswert, als die zu Komponenten- und/oder Modulund Systemherstellern. Eine solche Bewertung gestaltet sich besonders dann schwierig, wenn die F&E-Ziele zum Bereich der Grundlagenforschung ohne konkreten Anwendungsbezug geh¨oren. Der Wert der F&E-Ergebnisse kann hier am ehesten u ¨ber die Aufw¨ande und die Spezifit¨at der Ergebnisse gesch¨atzt werden.

4.6.3 Unternehmungszugeh¨ origkeit oder -beteiligung Automobilhersteller besitzen in der Regel Beteiligungen an mehreren Unternehmungen mit variierenden Gesch¨aftsanteilen. Es ist eine Frage des Gesellschaftervertrages, inwiefern unternehmungseigenes Know-how, welches in eine neue Gesellschaft eingebracht wird, von dieser genutzt werden kann und darf. Eine Minderheitsbeteiligung an einer Unternehmung sollte nicht dazu f¨ uhren, dass diese Unternehmung denselben Status wie z.B. eine hundertprozentige Tochterunternehmung bez¨ uglich des Zugangs zu Know-how und Wissensbest¨anden erlangt. Es ist nicht auszuschließen, dass eine horizontale F&E-Kooperation einem Partner dazu dient, sich ohne oder mit nur wenig Gegenleistung am Wissen des anderen zu bereichern. Hier wird der Ansatz der Volkswagen AG vertreten, nach der Unternehmungen an denen Anteile von weniger als 50 Prozent gehalten werden, aus Sichtweise der Informationssicherheit wie externe Unternehmungen zu bewerten sind.

4.6.4 Gr¨ oße der Unternehmung In der Praxis existiert ein signifikanter Zusammenhang zwischen der Gr¨oße einer Unternehmung und der Wahrnehmung von respektive den Aufwendungen f¨ ur IT-Sicherheit. Als Maß f¨ ur die Unternehmungsgr¨oße gilt in Deutschland die Anzahl der Mitarbeiter (siehe Tab. 4.2). Anzahl Mitarbeiter ≤ 49 50 − 499 ≥ 500

Einordnung der Unternehmung Kleine Unternehmung Mittlere Unternehmung Große Unternehmung

Tabelle 4.2: Definition der Unternehmungsgr¨oße

162

4 Vertikale F&E-Kooperationen in der Automobilindustrie

Ein signifikanter Zusammenhang zwischen Umsatzgr¨oße, bereit gestellten Mittel f¨ ur die IT-Sicherheit und die Integration der Sicherheitsziele in die Organisation wurde in mehreren Untersuchungen explizit best¨atigt.474 Ebenso zeigte eine Untersuchung des IT-Sicherheitsniveaus von kleinen und mittleren Unternehmungen, dass diese keine oder kaum Anstrengungen zum Schutz ihrer Daten unternehmen bzw. damit u ¨berfordert sind.475 Wenn eine Unternehmung mehr als vier Arbeitnehmer mit der Erhebung, Verarbeitung oder Nutzung personenbezogener Daten besch¨aftigt, dann muss sie einen Datenschutzbeauftragten schriftlich bestellen.476 Die Anzahl der Mitarbeiter ist allerdings ein unzureichendes Kriterium, um die Notwendigkeit von IT-Sicherheit oder die Verletzbarkeit der Infrastrukturen darzustellen. Aussagekr¨aftiger ist der Gr¨oßenbezug auf die Anzahl der Computer und Computernutzer in einer Unternehmung wie er z.B. in einer Erhebung im Jahr 2002 ermittelt wurde.477 In dieser Studie wurde wie folgt unterschieden (siehe Tab. 4.3): Anzahl Computer 10 − 100 100 − 1.000 1.000 − 10.000 > 10.000

Einordnung der Unternehmung kleine Unternehmungen mittlere Unternehmungen große Unternehmungen sehr große Unternehmungen

Tabelle 4.3: Definition der Unternehmungsgr¨oße nach Anzahl der Computer

Diese Einteilung l¨asst sich besser nutzen als die Segmentierung nach der Anzahl der Mitarbeiter, um das bisher umgesetzte Sicherheitsniveau einsch¨atzen zu k¨onnen. Je mehr Computer eine Unternehmung besitzt respektive nutzt, desto h¨oher ist die Wahrscheinlichkeit, dass organisatorische Verantwortlichkeiten f¨ ur den IT-Betrieb und damit auch f¨ ur die IT-Sicherheit in der Unternehmung geschaffen wurden. 474 Vgl. u.a. Briney/Prince 2002; Deloitte 2004: 11. 475 Vgl. Winkel/Hecht/Tackenberg 2001; Silicon.de 2005: 2. 476 Vgl. Bundesdatenschutzgesetz (BDSG) § 4f Abs. 1, Beauftragter f¨ ur den Datenschutz. 477 Vgl. Briney/Prince 2002. Es ist zu ber¨ ucksichtigen, dass von der Anzahl der Computer nicht zwingend die Anzahl der Nutzer abgeleitet werden kann. Als Beispiel kann hier die Frage gelten, ob ein Terminal als Computer gewertet wird oder nicht. Andernfalls wird eventuell nur ein Mainframe-Rechner erfasst, aber nicht die Clients, die einen Mainframe-Rechner nutzen. Bei dieser Z¨ahlweise kann z.B. ein Verh¨altnis von 50 Mitarbeiter auf einen Computer entstehen. Es ist weiterhin vorstellbar, dass eine Unternehmung bei einer Z¨ ahlweise pro Central Processing Unit (CPU)“ auf 10 Computer pro ” Mitarbeiter kommt, z.B. wenn diese Unternehmung Webserver vermietet.

4.6 Typologisierung der F&E-Kooperationen unter Sicherheitsaspekten

163

4.6.5 Finanzielle Situation der Unternehmung Die finanzielle Situation eines Zulieferers ist aus Sicht der IT-Sicherheit von Bedeutung. In einer F&E-Kooperation wird nicht nur neues Wissen generiert, sondern auch bestehendes Wissen – freiwillig oder unfreiwillig – ausgetauscht. Bei einem Wechsel der Eigentums¨ verh¨altnisse einer Unternehmung (z.B. durch Insolvenz oder feindliche Ubernahme) kann dieses Know-how auch an Konkurrenten gelangen. Daher sind Details zur finanziellen Situation wie Verbindlichkeiten, Eigenkapitalquote oder Gewinn vor Ertragsteuern und Zinsen (Earnings Before Interest and Tax, EBIT) in der Risikobewertung eines Zulieferers ebenso zu ber¨ ucksichtigen, wie Prognosen zu k¨ unftigen Ertragspotenzialen oder die Entwicklung spezifischer Marktsegmente.

4.6.6 Geografische/politische Lage Die geografische Lage spielt eine wichtige Rolle hinsichtlich der Sicherheit der Daten, da Naturkatastrophen die (physikalische) Existenz der Daten und deren Verf¨ ugbarkeit bedrohen k¨onnen. In diese Kategorie geh¨oren Erdbeben, Flutkatastrophen, Vulkanausbr¨ uche etc.. Wesentlich wichtiger ist die Frage nach der politischen Lage in der Region, in der ein Zulieferer residiert. Dies betrifft sowohl die Unternehmungszentrale als auch die Niederlassung mit der kooperiert wird. In politischen Krisenregionen k¨onnen z.B. Kriege, Macht¨ ubernahmen oder neue Gesetze die Sicherheit der Daten gef¨ahrden. Die gesetzliche Lage ist generell ein entscheidender Faktor, da die Rechtsprechung teilweise den Einsatz von kryptografischen Sicherheitstechnologien verbietet oder auf unsichere Algorithmen und/oder Schl¨ ussell¨angen beschr¨ankt. Einige L¨ander betreiben zudem rigoros Wirtschaftsspionage und stellen die Erkenntnisse heimischen Unternehmungen zur Verf¨ ugung. Die Weltm¨arkte werden aus Sicht der Automobilhersteller und Analysten in drei Regionen eingeteilt: • Europe, Middle East and Africa (EMEA), • Asia/Pacific (AP), • America. Dabei stellt die Volksrepublik China zur Zeit einen Sonderfall dar. Fr¨ uher mussten Unternehmungen, die in China aktiv werden wollten, Joint Ventures eingehen und dies bedeutete unter anderem, dass firmenspezifisches Wissen preisgegeben werden musste. Ohne einen Technologietransfer war ein Einstieg in chinesische M¨arkte im Allgemeinen nicht m¨oglich. Die gesetzliche Verpflichtung zu Joint-Ventures besteht mittlerweile nicht mehr

164

4 Vertikale F&E-Kooperationen in der Automobilindustrie

und dar¨ uber hinaus existieren 15 Freihandelszonen, die dort ans¨assige ausl¨andische Unternehmungen u.a. zu Im- und Export berechtigen.478 Das Urheberrecht wird in China im Gesch¨aftsalltag wenig respektiert. Dies hat zur Folge, dass viele Plagiate und Produktimitationen am Markt verf¨ ugbar sind.479 Dies trifft nicht nur auf Teile oder Komponenten zu: Ein prominentes Beispiel ist das von FAW in Changchun produzierte Fahrzeug Hongqi“, welches in Design und Technologie augenscheinlich ” dem Audi 100 nachempfunden wurde. Audi produzierte in den 1980er und 1990er Jahren den Audi 100/200 bei FAW in Changchun und verklagte FAW wegen Diebstahl geistigen Eigentums. Im Gerichtsverfahren berief sich FAW auf die geschlossenen Vertr¨age, die einen Technologietransfer ausdr¨ ucklich vorsahen und ging nahezu straffrei aus.480 In den letzten Jahren hat sich die Rechtssicherheit in China deutlich verbessert, aber es wird voraussichtlich noch einige weitere Jahre dauern, bis sich die Gesetzgebung und die Rechtsprechung in China den westlichen Standards ann¨ahert. Der Beitritt in die World Trade Organization (WTO) im Dezember 2001 verpflichtet China zur Einhaltung der Trade Related Aspects of Intellectual Property Rights (TRIPS) und wirkt sich vor allem auf die Entwicklung und Bewertung von geistigem Eigentum aus.481 Zum Schutz des (elektronisch) verf¨ ugbaren geistigen Eigentums in China sind daher strenge IT-Sicherheitsmaßnahmen angebracht, um (unbeabsichtigte) Wissensdiffusion zu vermeiden oder zumindest zu minimieren. Die Nachvollziehbarkeit der Handlungen von Akteuren steht hier ebenso im Mittelpunkt wie der selektive Zugang zu Informationen nach dem Need-to-Know“-Prinzip. ”

4.6.7 Grad des Vertrauens Eine schwierig zu objektivierende Variable ist der Grad des Vertrauens. Vertrauen ist eine Voraussetzung f¨ ur ein gewisses Maß an Erwartungssicherheit in sozialen Konfliktsituationen, wie sie z.B. die Spieltheorie umschreibt. Ein beiderseitiger hoher Vertrauensgrad in gesch¨aftlichen Beziehungen erh¨oht die Wahrscheinlichkeit f¨ ur die Ausf¨ uhrung von Win-Win-Strategien in Entscheidungssituationen. Da Vertrauen sich in erster Linie u ¨ber die Summe der Erfahrungswerte (Handeln eines Akteurs) herausbildet, ist die L¨ange und Intensit¨at (Anzahl und Qualit¨at der Erfahrungswerte) einer Beziehung ausschlaggebend. Vertrauen ist aus Sicht der IT-Sicherheit ein 478 Vgl. Behlmer 2003. 479 Vgl. Frank 2004: 43; Ohne Verfasser 2004a: 72. 480 Vgl. Behlmer/Kiefer 2003; Hein 2003. 481 Vgl. Haour/Zedtwitz 2004: 20.

4.6 Typologisierung der F&E-Kooperationen unter Sicherheitsaspekten

165

wichtiger Faktor, da sie eigentlich nur dort ben¨otigt wird, wo Akteuren und Dritten kein Vertrauen entgegengebracht werden kann.482 Je h¨oher das Vertrauen in die direkten und indirekten Akteure einer Kommunikationsbeziehung, desto weniger Sicherheitsmaßnahmen werden ben¨otigt. Das Vertrauen in die IT-Sicherheit eines Kooperationspartner kann maßgeblich durch ein renommiertes IT-Sicherheitszertifikat (z.B. nach ISO 27001) beeinflusst werden.

4.6.8 Wert der Information Die klassische Risikoanalyse bemisst den maximalen Schutzbedarf einer Information nach ihrem Wert. Der Grenznutzen der realisierten Schutzmaßnahmen ist gleich oder unterhalb des Werts der zu sch¨ utzenden Informationen.483 Der Wert der Schutzmaßnahmen ist hierbei nicht der rein monet¨are Wert f¨ ur Anschaffung und Betrieb von Systemen, sondern der Aufwand der betrieben werden muss, um unberechtigt an die gesch¨ utzten Informationen zu gelangen. Die kryptografische Verschl¨ usselung einer Datei ist mit geringen Kosten zu realisieren, w¨ahrend eine Kryptanalyse zum unberechtigten Entschl¨ usseln der Datei sehr hohe Kosten verursachen kann.484 Die Bezifferung des Werts einer Information gestaltet sich in der Praxis schwierig, da im Idealfall alle Informationen bewertet werden m¨ ussen. Hierbei ist zu unterscheiden zwischen direkten Sch¨aden (z.B. Kosten f¨ ur die Wiederbeschaffung) und Folgesch¨aden (z.B. Imageverlust). Ein direkter monet¨arer Sch¨atzwert kann einzelnen Informationen selten zugeordnet werden, da dies einen erheblichen Aufwand bedeuten w¨ urde, weshalb in der Regel mit drei bis f¨ unf Schutzbedarfsklassen oder -kategorien gearbeitet wird. Je h¨oher der Wert der zu sch¨ utzenden Informationen, desto st¨arker sollten diese Informationen gesichert werden. 482 Dabei entstehen teilweise paradoxe Situationen: Der Inhalt geheimer E-Mails sollte vertraulich, also verschl¨ usselt, ausgetauscht werden. Dies geschieht vor dem Hintergrund, dass der Transport der Nachricht transparent u offentliches Netzwerk (das Internet) stattfindet und den anderen Teil¨ ber ein ¨ nehmern des Netzwerks kein Vertrauen entgegengebracht wird. Auf der anderen Seite werden die wenigsten Telefonate und Faxnachrichten verschl¨ usselt, obwohl man nicht nur den Netzbetreibern und Leitungsinhabern, sondern auch den Telefon-, Telefonanlagenherstellern und dem Servicepersonal vertrauen muss. Das Verhalten der Akteure ist hier nur bedingt rational. 483 So sollten die Kosten f¨ ur den Schutz eines Systems mit Informationen im Gesamtwert von z.B. 500.000 Euro diese Summe nicht u ¨ berschreiten. 484 Falls ein ad¨aquater Algorithmus mit einer hinreichenden Schl¨ ussell¨ange ausgew¨ahlt worden ist.

166

4 Vertikale F&E-Kooperationen in der Automobilindustrie

4.6.9 Konnektivit¨ at Die Art der Anbindung ist ein weiterer Faktor zur Bestimmung der notwendigen Sicherheitsmaßnahmen. Grunds¨atzlich muss unterschieden werden zwischen Online- versus Offline-Kommunikation und elektronischen versus nicht-elektronischen Dokumenten, da dies erhebliche Konsequenzen auf die Maßnahmenauswahl zur Absicherung der Kommunikation hat.485 Insbesondere Kommunikationskan¨ale, welche durch ¨offentliche Netzwerke (Internet, Telefonprovider, etc.) f¨ uhren, m¨ ussen gesch¨ utzt werden. Ein h¨aufig zitiertes Beispiel, welches die Notwendigkeit dieser Maßnahmen unterstreicht, ist das Bieterverfahren um einen Hochgeschwindigkeitszug in S¨ udkorea. Die beiden aussichtsreichsten Kandidaten waren der ICE (Intercity Express) von Siemens und der TGV (Train a` Grand Vitesse) der franz¨osischen Unternehmung Alsthom. Siemens unterlag im Bieterverfahren der franz¨osischen Konkurrenz. Durch (vermutliche) Spionage des franz¨osischen Geheimdienstes Direction G´en´erale de la S´ecurit´e Ext´erieure (DGSE) war Alsthom der Preis des deutschen Angebots bekannt, wodurch der Preis des eigenen Angebots dementsprechend angepasst werden konnte. In einem anderen Fall verlor Frankreich durch Spionage einen saudiarabischen Auftrag f¨ ur R¨ ustungsg¨ uter und Airbus-Flugzeuge in zweistelliger Milliardenh¨ohe – den Zuschlag bekam der US-R¨ ustungskonzern McDonnell-Douglas.486 Unter den popul¨arsten Anbindungsarten finden sich in Deutschland (u.a.) Standleitungen, W¨ahlverbindungen (DSL, ISDN, Analog), Satellit oder Richtfunk. Sonderformen wie z.B. European Network Exchange (ENX) weisen explizit auf die Sicherheit der Daten w¨ahrend ¨ der Ubertragung hin und nutzen diese Eigenschaft als Unique Selling Proposition (USP). Auch Daten, die u ¨ ber Satellit versandt werden, k¨onnen Ziel eines Abh¨orangriffes werden.487 Elektronische Dokumente, die Offline u ¨bermittelt werden u ¨ber Speichermedien wie CD, DVD, Diskette, Flashspeicher, PC, Notebook oder Personal Digital Assistant (PDA), bed¨ urfen ebenfalls des Schutzes, damit weder Diebstahl noch unbefugte Einsichtnahme oder Manipulation (z.B. w¨ahrend des Transports) die Integrit¨at und Vertraulichkeit der Daten beeintr¨achtigen k¨onnen.

4.6.10 Standort der Applikation oder des Systems Große Unternehmungen arbeiten in der Regel nicht mehr mit der dichotomen Standortentscheidungsvariable Internet oder Intranet. H¨aufig finden sich sogenannte Extranets 485 Die vorliegende Arbeit konzentriert sich auf elektronische Dokumente. 486 Vgl. Freyermuth 1998. 487 Vgl. Adelsbach/Greveler 2005.

4.7 Fazit

167

mit eingeschr¨ankten Benutzergruppen, die auf der Basis des Transmission Control Protocol/Internet Protocol (TCP/IP) operieren. Große Unternehmungen realisieren in der Regel nicht nur Local Area Networks (LAN), sondern auch Wide-Area-Networks (WAN), die einzelne Standorte miteinander verbinden. Applikationen, Systeme oder Daten k¨onnen an unterschiedlichen Positionen in Netzwerken (physikalisch und logisch) integriert werden. W¨ahrend ¨offentliche Webserver – z.B. f¨ ur die Unternehmungsrepr¨asentation im Internet oder als Online-Shop – im Allgemeinen f¨ ur alle Internetnutzer offen stehen, sind andere Informationen nur f¨ ur einen definierten Benutzkreis bestimmt, die nur nach der erfolgreichen Verifizierung der Identit¨at eines Nutzers zur Verf¨ ugung stehen sollten. Der Nutzerkreis und der Sicherheitsbedarf der Informationen bestimmen den virtuellen Standort“ des Systems (logischer Standort), wenn ” z.B. ein Zonenschutzkonzept in der Unternehmung existiert. Der physische Standort eines Systems ist ebenfalls von Bedeutung. Sollte aus einem bestimmten Grund ein System mit hochsensiblen Daten nicht in ein gesichertes Rechenzentrum integriert werden k¨onnen, dann m¨ ussen entsprechende Maßnahmen getroffen werden wie z.B. die Verschl¨ usselung der Informationen oder die Aufbewahrung des Systems in einem Safe f¨ ur Rechnersysteme.

4.6.11 Protokolle und Kommunikation Die Auswahl eines Protokolls beeinflusst ebenfalls die zu treffenden IT-Sicherheitsmaßnahmen. Protokolle ohne eigene Sicherheitsunterst¨ utzung, wie z.B. das File Transfer Protocol (FTP), EDI oder Hypertext Transfer Protocol (HTTP), stellen ein Sicherheitsrisiko dar, weil Daten unter Umst¨anden unbemerkt verf¨alscht oder mitgelesen werden k¨onnen. F¨ ur derartige Protokolle existieren in der Regel Varianten, die Sicherheitsmechanismen beinhalten, wie z.B. FTP over SSL oder HTTP Secure (HTTPS). Protokolle, die u ugen, sollten stets getunnelt ¨ber kein sicheres Pendant verf¨ (SSL, TLS, IPSec etc.) werden, wenn der Transport der Daten durch unsichere bzw. nicht vertrauensw¨ urdige Netzwerke f¨ uhrt.

4.7 Fazit Die IT-Sicherheitsanforderungen in Kooperationen und daraus abgeleitete Maßnahmen sind maßgeblich abh¨angig von den oben genannten Einflussfaktoren. Dabei u ¨berwiegen die organisatorischen oder auch weichen“ Faktoren wie z.B. der Grad des Vertrauens ” oder das Kooperationsumfeld (siehe Abb. 4.4).

168

4 Vertikale F&E-Kooperationen in der Automobilindustrie

Organisatorische Aspekte - Unternehmenszugehörigkeit - Kooperationsumfeld - Art des Guts/Produkts - Finanzielle Situation - Grad des Vertrauens - Wert der Information - Größe der Unternehmung - Geografische/politische Lage

Technische Aspekte

- Standort des Systems/Applik.

- Konnektivität - Art Protokoll/Kommunikation

Abbildung 4.4: Zuordnung der Sicherheitsaspekte Aus IT-Sicherheitsperspektive bestimmen die organisatorischen Faktoren maßgeblich den Einsatz und die Ausgestaltung der Technik. Dennoch kann auch die verwendete Technik den Einsatz organisatorischer Maßnahmen beeinflussen. Die Analyse der organisatorischen Aspekte erfolgt in der Regel einmalig oder zyklisch und ist von weiteren Faktoren abh¨angig. Wenn der Zulieferer ein Monopol auf eine Technologie oder ein Verfahren besitzt, k¨onnen festgelegte Kriterien durch den Druck der Fachabteilungen aufgeweicht“ werden. Dies kann der Fall sein, wenn ein Monopolist (Zulieferer) ” nicht gewillt oder in der Lage ist, die IT-Sicherheitsanforderungen des OEM umzusetzen. In einem solchen Fall ist es hilfreich, wenn die entsprechende Fachabteilung, die den Einsatz eines Produktes oder eines Verfahrens trotz vorgetragener Sicherheitsbedenken bef¨ urwortet, eine Risiko¨ ubernahmeerkl¨arung unterzeichnen zu lassen. Damit tr¨agt diese Fachabteilung das Risiko und eventuell auftretende Konsequenzen.488 Die oben genannten Einflussfaktoren sind zum Teil lediglich Indizien f¨ ur die Sicherheit einer Kooperation. Da die Analyse und Akzeptanz eines Risikos von unternehmungsindividuellen Gegebenheiten abh¨angt, kann keine pauschale Aussage getroffen werden. Selbst wenn der Wert einer Information sich exakt bestimmen l¨asst, kann die Schlussfolgerung, ob die Information besonders sch¨ utzenswert ist oder nicht, unterschiedlich ausfallen.489 Ein wichtiges Indiz f¨ ur ein eingef¨ uhrtes ISMS bei einem potenziellen Kooperationspartner kann der Umsatz/Gewinn und die Anzahl der Mitarbeiter sein. Wenn der Partner 488 Im Regelfall sollte die zust¨andige Sicherheitsabteilung in der Lage sein, den Einsatz von riskanten ¨ Ubertragungsstrecken, Systemen oder Applikationen zu verbieten. Eine Risiko¨ ubernahmeerkl¨ arung ist die Ultima Ratio eines derartigen Konfliktes und dient zus¨atzlich der Sensibilisierung des entsprechenden Fachbereiches. 489 Zahlen, wie die Summe aller Verbindlichkeiten einer Unternehmung, k¨ onnen bei einer b¨ orsennotierten Aktiengesellschaft relativ einfach beschafft werden. Es ist jedoch fraglich, ob andere Kooperationspartner (z.B. eine GmbH) die Summe ihrer Verbindlichkeiten offenlegen wird.

4.7 Fazit

169

in mindestens zwei aufeinander folgenden Jahren eine Bilanzsumme von mehr als 3,438 Millionen Euro und/oder einen Umsatz von mehr als 6,875 Millionen Euro und/oder mindestens 50 Mitarbeiter aufweist, dann muss die Unternehmung das KonTraG erf¨ ullen und ein IT-Risikomanagement betreiben.490 In Wertsch¨opfungs- oder Lieferketten (Supply Chains) sind Interdependenzen und m¨ogliche Kettenreaktionen bei Sicherheitsvorf¨allen von Bedeutung. Besonders nicht-substituierbare Spezifit¨aten k¨onnen dazu f¨ uhren, dass eine Lieferkette f¨ ur ein Produkt u ¨ber mehrere Lieferanten hinweg vollst¨andig ausf¨allt.491

490 Mindestens zwei der genannten Kriterien m¨ ussen erf¨ ullt sein, vgl. Speichert 2004: 222. 491 Wenn ein Teilelieferant beispielsweise ein Teil, welches aus einer Speziallegierung besteht, nicht liefern kann, kann dies dazu f¨ uhren, dass der Modullieferant nicht produzieren/liefern und der OEM die Module nicht ins Fahrzeug integrieren kann.

5 Gestaltungsans¨ atze fu ¨r IT-Sicherheit in vertikalen F&E-Kooperationen IT-Sicherheit in Unternehmungen ist paradoxerweise von Unsicherheiten gepr¨agt: Welche Werte sind relevant, sind diese einem Risiko ausgesetzt und welche Maßnahmen k¨onnen ergriffen werden, um das Risiko auf ein akzeptables Maß zu reduzieren? Aus diesen Fragen ergeben sich weitere Fragen, z.B.: Welcher Risikomanagementansatz soll gew¨ahlt werden oder nach welchem Standard sollte sich die Unternehmung richten? Im ersten Teil diese Kapitels wird die Sicherheit in F&E-Kooperationen unter bilateralen Aspekten betrachtet. Dabei werden in erster Linie die organisatorischen Aspekte inspiziert, da diese die Basis f¨ ur die Etablierung von IT-Sicherheit bilden und nicht dem steten Wandel der Technik unterliegen. Der Ansatz konzentriert sich auf die Etablierung von IT-Sicherheit in Zulieferbetrieben, da die OEMs – zumindest in Deutschland – entsprechende Prozesse implementiert haben. Es obliegt aber den OEMs, die IT-Sicherheit in der Zusammenarbeit mit Zulieferer zu fordern und zu f¨ordern. Der zweite Teil des Kapitels besch¨aftigt sich mit mulitlateralen Ans¨atzen, also mit der Frage, welche Optionen f¨ ur die Automobilindustrie vorhanden sind, um bilaterale Verhandlungen durch ein gemeinsames Rahmenwerk zu ersetzen.

5.1 IT-Risikomanagement in vertikalen Kooperationen Die Implementation eines geeigneten Risikomanagements beginnt mit der schriftlich fixierten Unterst¨ utzung durch die Gesch¨aftsf¨ uhrung. Ohne diese Unterst¨ utzung – nicht nur ideell, sondern auch finanziell – ist die Einf¨ uhrung eines Risikomanagements und damit auch von IT-Sicherheit nicht oder nur eingeschr¨ankt m¨oglich.492 Nach einer entsprechen492 Es kann hilfreich sein, dass Management auf die gesetzlichen Vorschriften (vor allem KonTraG) und die evtl. daraus entstehende erweiterte, uneingeschr¨ ankte und pers¨onliche Haftung hinzuweisen.

172

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

den Zusage m¨ ussen Verantwortlichkeiten hergestellt werden, z.B. die Ernennung eines CISOs und ggf. eines entsprechenden Sicherheitsteams mit definierten Berichts- und Eskalationswegen. In einer Risikoanalyse werden sch¨ utzenswerte Werte und deren potenzielle Gef¨ahrdungen und Schwachstellen identifiziert, der m¨ogliche Schaden gesch¨atzt und dementsprechende Maßnahmen ergriffen. In der Automobilindustrie greifen viele Unternehmungen auf die Expertenbefragung zur¨ uck, es sind jedoch auch andere Verfahren verf¨ ugbar (siehe S. 23). Die korrekte und vollst¨andige Identifizierung und Analyse der relevanten Werte ist das essenzielle Element der Risikoanalyse. Es ist sehr wahrscheinlich, dass M¨angel in diesem Bereich zu fehlerhaften Entscheidungen in der Risikobewertung f¨ uhren. Als Risikomanagementsystem f¨ ur die Informationssicherheit in Unternehmungen hat sich in der Praxis das ISMS der BS 7799:2 bzw. ISO 27001 bew¨ahrt. Das Risikomanagement sollte sich zu Beginn auf die kritischen Gesch¨aftsprozesse fokussieren, um die Risiken in der Wertsch¨opfungskette zu minimieren, die die wertsch¨opfenden Aktivit¨aten bedrohen. Als Vorgehensmodell zur Risikoanalyse bietet sich der kombinierte Ansatz der ISO TR 13335-3 an, bei dem zuerst eine oberfl¨achliche Analyse aller Systeme vorgenommen wird, um kritische Systeme zu identifizieren und diese anschließend einer detaillierten Risikoanalyse zu unterziehen. Alle weiteren als weniger kritisch identifizierten Systeme werden mit einem Basisschutz versehen. Mit der Etablierung eines Risikomanagementsystems werden die Grundlagen f¨ ur ein ITSicherheitsregelwerk (IT Security Policy) gelegt. Das IT-Sicherheitsregelwerk in Summe ist mehrstufig ausgelegt (siehe Abb. 5.1).

Politik

Handlungsleitlinien

Regelungen

Abbildung 5.1: Dokumentation der IT-Sicherheitsrichtlinien auf drei Ebenen Auf der obersten Ebene (Politik) befinden sich allgemeine Grunds¨atze und das Bekenntnis des Managements zur IT-Sicherheit in der Unternehmung. Aus der Politik lassen sich die IT-Sicherheitsziele der Unternehmung und ihre Risikoneigung ableiten. Auf der zweiten

5.1 IT-Risikomanagement in vertikalen Kooperationen

173

Ebene wird in Handlungsleitlinien die Politik f¨ ur einzelne Nutzergruppen spezifiziert, z.B. f¨ ur Systembetreiber, Systementwickler, Anwender oder Zulieferer. Auf der untersten Ebene befinden sich Regelungen, die den Einsatz von Technologien, Architekturen und Prozessen regeln. Denkbar sind hier Vorgaben z.B. f¨ ur den Einsatz von WLAN, Verschl¨ usselung, Client-Sicherheit, Voice over IP oder Vorgaben zur elektronischen Anbindung von Kooperationspartnern. Die Regelungen sollten m¨oglichst produktneutral formuliert werden, da ein Sicherheitsregelwerk lediglich Anforderungen definieren sollte. Die Entscheidung f¨ ur ein Produkt, welches den Anforderungen entspricht, sollte dem jeweiligen Fachbereich u ur den entsprechenden Nutzerkreis ¨berlassen werden.493 All diese Regelungen sollten f¨ publiziert werden und frei zug¨anglich sein. Dies gilt nat¨ urlich nicht f¨ ur Regelungen, aus denen ein Angreifer R¨ uckschl¨ usse auf potenzielle Schwachstellen ziehen kann; jene sollten nur solchen Personen zug¨anglich sein, die diese Regelungen zur Erf¨ ullung ihrer Aufgaben ben¨otigen. Alternativ k¨onnen vereinfachte Versionen publiziert werden, die keine konkreten Hinweise auf Gef¨ahrdungen, Schwachstellen oder besondere Maßnahmen enthalten und somit f¨ ur einen gr¨oßeren Nutzerkreis zug¨anglich werden. Die Einf¨ uhrung respektive Ver¨offentlichung einer derartigen IT-Sicherheitsregelung sollte durch entsprechende Sensibilisierungskampagnen in Form von Schulungen oder Trainings f¨ ur die Mitarbeiter flankiert werden. Dabei muss den Mitarbeitern verdeutlicht werden, dass die Sicherheit von Informationen – und damit evtl. die Wettbewerbsf¨ahigkeit der Unternehmung – in den H¨anden derer liegt, die mit den Informationen umgehen, und dass der Ersteller der Information f¨ ur die Einstufung der IT-Sicherheit anhand der Datenklassifikation verantwortlich ist. Da die Nutzergruppen der IT-Sicherheitsregelungen u ¨ blicherweise sehr heterogen ausgepr¨agt sind, sollten die Regelungen soweit m¨oglich allgemein verst¨andlich gehalten werden. Eine Einleitung mit einer Problem- bzw. Risikobeschreibung kann den Rezipienten behilflich sein, die Problematik zu erfassen. Alle getroffenen Maßnahmen m¨ ussen dokumentiert und Sicherheitsvorf¨alle m¨ ussen erfasst und analysiert werden. Diese Datenbasis l¨asst sich nutzen, um bestehende (organisatorische oder technische) Maßnahmen zu optimieren oder weitere zu planen. Ex-post k¨onnen solche Analysen die Wirksamkeit von Sicherheitsmaßnahmen abbilden und vermiedene Kosten aufzeigen. Des Weiteren muss bei allen Maßnahmen periodisch u uft werden, ¨berpr¨ ob sie umgesetzt worden sind und weiterhin angewandt werden sollen oder m¨ ussen. Risikoanalyse, IT-Sicherheitsregelwerk, Maßnahmen und entsprechende Sensibilisierung und Audit folgen in einem Kreislauf aufeinander.

493 Dies sollte jedoch nicht dazu f¨ uhren, dass unterschiedliche L¨ osungen f¨ ur eine identische Problemstellung implementiert werden (wie z.B. vier verschiedene Antivirusl¨osungen), da dies in der Regel zu h¨oheren Kosten in der Anschaffung und dem Support m¨ undet.

174

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Die Abbildung 5.2 zeigt die Abl¨aufe in der Gestaltung der IT-Sicherheit in Unternehmungen, welche in eine Gesch¨afts-, Prozess- und Umsetzungsebene untergliedert werden k¨onnen. Auf der Gesch¨aftsebene werden die u ¨ bergeordneten Ziele festgelegt, die in die Prozessgestaltung integriert werden m¨ ussen. Die Prozessgestaltung hat wiederum Einfluss auf die Umsetzungsebene, auf der Maßnahmen ergriffen werden, die die Verwirklichung der Sicherheitsziele erm¨oglichen. Ziel ist es, sichere Gesch¨aftsprozesse in der Unternehmung und in der Kommunikation mit Partnern nachhaltig zu etablieren. Bei Prozessen, die u ¨ber die Unternehmungsgrenzen hinaus praktiziert werden, ist zuerst eine Klassifizierung des Partners anhand der Sicherheitsaspekte vorzunehmen (siehe Abschnitt 4.6). Der Schwerpunkt liegt dabei auf der Datenklassifikation basierend auf den Werten der jeweiligen Daten. Wenn es sich um sch¨ utzenswerte Daten handelt, sollte der Kooperationspartner davon in Kenntnis gesetzt werden, um gegebenenfalls Maßnahmen abzustimmen. Diese Abstimmung zwischen den Partner ist notwendig, da einzelne Details der eingesetzten Infrastruktur und Informationstechnologie u ¨blicherweise nicht ¨offentlich bekannt sind. Die IT-Sicherheitsmaßnahmen sind zum Teil abh¨angig von der eingesetzten Hardware und Software.494 Flankierend m¨ ussen organisatorische Maßnahmen abgestimmt bzw. eingef¨ uhrt werden, z.B. die Zutrittsregelungen f¨ ur das Unternehmungsgel¨ande oder spezielle, sensible Umgebungen (z.B. Teststrecken, Labore, etc.). Die Einhaltung von formulierten ITSicherheitskriterien sollte stets Bestandteil von Kooperationsvertr¨agen und Geheimhaltungsvereinbarungen sein. Ziel eines ISMS ist es unter anderem, IT-Sicherheit nicht mehr reaktiv, sondern pr¨aventiv zu betreiben. Die Stelle in der Unternehmung, die das Sicherheitsregelwerk erstellt und ad¨aquate Sicherheitsmaßnahmen fordert (und teilweise an der Planung beteiligt sein kann), ist von der operativen Stelle, welche die Maßnahmen umsetzt und ggf. betreibt, zwingend zu trennen. Ist dies nicht der Fall, m¨ usste die IT-Sicherheitsabteilung in der Unternehmung die selbst durchgef¨ uhrte Umsetzung auditieren. Damit w¨are die notwendige Unabh¨angigkeit nicht mehr gegeben.

494 Bestimmte Technologien lassen sich z.B. auf Mainframes nicht oder nur mit großem Aufwand integrieren.

Business Assets Kernprozesse Risikoanalyse Schwachstellenanalyse etc.

Ziele

Prozessebene

Businessebene

Risiko

Geschäftsstrategie

UmsetzungsEbene

Qualifikationen

Prozesse

Technologie

Policy

Sicherheitsservices

Audit

Vertrauensvolle Geschäftsprozesse Compliance Checks Logfile Analyse Reporterstellung Schwachstellencheck etc.

Audits

Logging

Autorisierung

Authentifizierung

Verzeichnisse

Administration

Forensik

Identifizierung

Patchmanagement Schulung & Training User & Account Management Antivirus, Firewalls, IDS Physikalische Sicherheit etc.

Maßnahmen & Sensibilisierung

Sicherheitsorganisation

Sicherheitsarchitektur

Policyerstellung Policymanagement Business Continuity etc.

Design

Risiken

Gesetze

Policy

5.1 IT-Risikomanagement in vertikalen Kooperationen 175

Abbildung 5.2: Abl¨aufe in der Gestaltung von IT-Sicherheit in Unternehmungen (vgl. Butler Group 2005: 36) Sicherheitsstrategie

176

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

5.2 Zertifizierung von Zulieferunternehmungen Der erreichte Grad an IT-Sicherheit in Unternehmungen kann zertifiziert werden. Ein renommiertes Zertifikat bescheinigt den tats¨achlichen und den potenziellen Partnern, dass der Zertifikatsinhaber vorgeschriebene organisatorische und/oder prozessuale Maßnahmen eingef¨ uhrt hat und einen Mindeststandard einh¨alt. Von einem Zertifikat profitieren beide Teilnehmer einer Kooperation. Der Zertifikatsinhaber (Zulieferer) verbessert unter Umst¨anden seine Position unter den Wettbewerbern und der Kooperationspartner (OEM) kann sich auf ein professionelles ITSicherheitsmanagement verlassen. Die verwendeten Begriffe aus dem Themenbereich der Zertifizierung werden im Folgenden voneinander abgegrenzt. Unter der Auditierung einer Unternehmung wird eine Begutachtung verstanden, die durch ein anschließendes Entscheidungsverfahren zur Erteilung eines Zertifikates (Zertifizierung) f¨ uhren kann, wenn die technischen und formalen Voraussetzungen erf¨ ullt worden sind. Damit Zertifikate anerkannt werden, die von fremden Zertfizierungsstellen ausgestellt wurden, existieren Zulassungsverfahren innerhalb einer definierten Infrastruktur f¨ ur Zertifizierungsinstanzen (Akkreditierung) und Auditoren (Lizensierung). So wird gew¨ahrleistet, dass ein Zertifikat eines akkreditierten Zertifizierers von anderen Stellen derselben Infrastruktur anerkannt wird.495 Somit ergeben sich drei grobe Teilbereiche:496 1. Akkreditierung der Zertifizierungsstellen, 2. Lizensierung der Auditoren und 3. Auditierungs- und Zertifizierungsprozess. Die Arbeitsgruppe Integraler Informationsschutz mit IT-Sicherheit, Prototypenschutz ” und Risk-Management“ 497 des VDA hat sich im Jahr 2005 dazu entschlossen, seinen Mitgliedern eine Zertifizierung nach BS 7799 zu empfehlen:498 Die Mitglieder des Arbeitskreises ’Integraler Informationsschutz mit IT” Sicherheit, Prototypenschutz und Risk-Management’ sind sich einig, dass der internationale Standard BS 7799 – erg¨anzt um die Regelungen zum Prototypenschutz – die Sicherheitsanforderungen der Automobilindustrie in geeigneter Weise abdeckt. 495 Vgl. BSI 2004a: 6. Dementsprechend kann zwischen Akkreditierungsstellen und Zertifizierungsstellen unterschieden werden. 496 Vgl. BSI 2004a: 19. 497 Beteiligt an der Arbeitsgruppe waren Vertreter von Audi, BMW, Bosch, Daimler-Chrysler, Leoni, Ford, Magna Steyr, Opel, Porsche, Serracon, VW und ZF. 498 Verband der Automobilindustrie e.V. 2005: 3.

5.2 Zertifizierung von Zulieferunternehmungen

177

• Der VDA empfiehlt seinen Mitgliedern, sich bei Anstrengungen zum Informationsschutz und zur IT-Sicherheit am internationalen Standard BS 7799, erweitert um den Bereich Prototypenschutz (auftragsbezogen), auszurichten. • Wenn bei Zulieferfirmen eine Zertifizierung auf Basis BS 7799 besteht, ¨ wird im Regelfall auf weitere Uberpr¨ ufungen seitens der OEMs verzichtet. • Projektspezifisch k¨onnen dar¨ uber hinaus gehende Sicherheitsmaßnahmen verhandelt und/oder kontrolliert werden. • Bereits erteilte Zertifizierungen durch einen akkreditierten Dienstleister werden anerkannt.“ Der Begriff der Auditierung und Zertifizierung bezieht sich daher im Folgenden stets auf die Kriterien des BS 7799-2 bzw. der ISO 27001. Damit besitzt auch ein neues Zertifikat nach GSHB des BSI G¨ ultigkeit, da ein solches gleichzeitig die Zertifizierung nach ISO 27001 beinhaltet.499 In dem Prozess der Auditierung und Zertifizierung kann unterschieden werden zwischen Zertifizierungsoptionen und der Zertifizierungstiefe, welche beliebig miteinander kombinierbar sind.

5.2.1 Optionen der Zertifizierung in F&E-Kooperationen Zur Zertifizierung der IT-Sicherheit in F&E-Kooperationen kann prinzipiell zwischen vier verschiedenen Optionen unterschieden werden: • Self Assessment: Der Zulieferer u uft sich selbst anhand offizieller Zertifizie¨berpr¨ rungskriterien und legt den Bericht dem Automobilhersteller vor. Dies setzt eine vertrauensvolle Beziehung voraus, da aus Sicht des Zulieferers Dritte einen Einblick in die Situation und ggf. Schwachstellen der eigenen IT-Sicherheit erlangen. Aus Sicht des OEMs ist Vertrauen in die F¨ahig- und Fertigkeiten der Auditoren und deren aufrichtige Bewertung der aktuellen Lage notwendig.500 • Self Assessment mit Stichproben: Es gelten dieselben Bedingungen, wie bei dem reinen Self Assessment. Zus¨atzlich wird dem OEM freigestellt, das Self Assessment durch Stichproben zu u ufen. ¨ berpr¨ 499 Vgl. M¨ unch 2005: 9. 500 In einem Fall forderte ein Automobilhersteller einen Zulieferer auf, sich eine Firewall zur Absicherung der Kommunikationsbeziehung anzuschaffen. Der mittelst¨ andische Zulieferer erbrachte den Nachweis, in dem er eine Kopie der Rechnung der Firewall-Appliance an den OEM sandte. Die Firewall wurde jedoch nicht installiert, sondern befindet sich originalverpackt in einem Schrank im B¨ uro der Gesch¨aftsf¨ uhrung.

178

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

• Zertifizierung durch Automobilhersteller : In dieser Variante u uft der OEM die ¨berpr¨ ¨ IT-Sicherheit des Zulieferers und stellt ihm – nach bestandener Uberpr¨ ufung – ein (eigenes) Zertifikat aus, das ihm einen bestimmten Reifegrad seiner IT-Sicherheit oder die Existenz eines ISMS bescheinigt. • Zertifizierung durch Dritte: Der Zulieferer l¨asst sich von einer akkreditierten Zertifizierungsinstanz u ufen und erh¨alt nach Bestehen ein offizielles Zertifikat. ¨berpr¨ Das Self Assessment hat den Charakter einer Selbstauskunft und ist nur sehr eingeschr¨ankt aussagef¨ahig, da zus¨atzlich die Professionalit¨at, Integrit¨at und das Wissen der Auditoren einen Unsicherheitsfaktor darstellen. Das Self Assessment mit Stichproben erm¨oglicht dem OEM, Teile der Selbstauskunft zu kontrollieren. Wenn in diesem Zusammenhang Unstimmigkeiten auftreten, m¨ usste der OEM seine Kontrollen ausweiten und ggf. Nachbesserungen fordern und diese abermals kontrollieren. Der OEM kann aber auch selbst eine Zertifizierung durchf¨ uhren. Die letzten beiden Optionen u ¨bersteigen jedoch in der Regel die personellen Kapazit¨aten der OEMs und dar¨ uber hinaus muss entschieden werden, wer die Kosten f¨ ur diese Leistungen tr¨agt. Eine Zertifizierung durch den OEM w¨are zudem nur dann sinnvoll, wenn dieser in der Lage w¨are, ein anerkanntes Sicherheitszertifikat zu erteilen.501 Ein Audit durch akkreditierte Zertifizierungsinstanzen ist daher die geeignetste Wahl zur Erlangung eines Zertifikats zur IT-Sicherheit.

5.2.2 Typologie der Zertifizierungstiefe Eine Zertifizierung muss nicht zwingend die gesamte Unternehmung ber¨ ucksichtigen. Gerade in großen Unternehmungen ist eine vollst¨andige Zertifizierung langwierig und kostenintensiv. Es bieten sich folgende Zertifizierungstiefen an. • Partielle Zertifizierung nach Unternehmungsbereichen: Eine partielle Zertifizierung nach Unternehmungsbereichen kann dann sinnvoll sein, wenn nur bestimmte Abteilungen von einer Kooperation betroffen sind wie z.B. die F&E, der Versuchsbau oder die dezentrale IT. • Partielle Zertifizierung nach Prozessen: Die partielle Zertifizierung nach Prozessen erm¨oglicht es, risikobehaftete (Teil-) Prozesse zertifizieren zu lassen. Dies ist besonders dann sinnvoll, wenn Prozesse bereichs¨ ubergreifend gestaltet worden sind. Diese k¨onnen dementsprechend mit einem Business Continuity Management ausgestattet werden, um die Aufrechterhaltung der Prozesst¨atigkeit zu gew¨ahrleisten. Die Zertifizierung eines Prozesses ist jedoch auf die Prozessschritte innerhalb der 501 Zur Zeit ist kein deutscher Automobilhersteller als Zertifizierungsinstanz akkreditiert und es ist sehr unwahrscheinlich, dass dies in Zukunft geschehen wird.

5.2 Zertifizierung von Zulieferunternehmungen

179

(ggf. virtuellen) Unternehmungsgrenzen begrenzt oder muss mit den anderen Teilnehmern der Prozesskette (z.B. Zulieferer) vereinbart werden. • Vollst¨andige Zertifizierung: Die vollst¨andige Zertifizierung einer Unternehmung umfasst alle Bereiche und Prozesse innerhalb einer Unternehmung. Dies ist aus Sicht der Informationssicherheit w¨ unschenswert, wird jedoch h¨aufig durch finanzielle, personelle und zeitliche Restriktionen eingeschr¨ankt. Insbesondere die partiellen Zertifizierungen weisen ein maßgebliches Problem auf: Um¨ strukturierungen in der Organisation oder Anderungen in den Prozessketten k¨onnen dazu f¨ uhren, dass das Zertifikat nicht mehr mit dem Zertifizierungsgegenstand u ¨bereinstimmt. Auf der anderen Seite kann eine partielle Zertifizierung dabei helfen, Erfahrungen mit dem Zertifizierungsprozess zu sammeln und die Erkenntnisse f¨ ur eine vollst¨andige Zertifizierung auf die gesamte Unternehmung anzuwenden, um den Zertifizierungsaufwand und eventuelle Nacharbeiten zu minimieren. Insbesondere Modullieferanten sind in der Regel Großunternehmungen mit einer ausgepr¨agten IT-Unterst¨ utzung in den meisten Prozessen. Solche Zulieferer (z.B. Bosch oder Siemens) w¨ urden mehrere Jahre ben¨otigen, um die gesamte Unternehmung zu zertifizieren.502 Einzelne Zulieferer und OEMs haben sich jedoch partiell in Bereichen und/oder Prozessen zertifizieren lassen. Die Auswahl der Zertifizierungstiefe ist prim¨ar abh¨angig von drei Bestandteilen: 1. dem Zertifizierungsgegenstand, 2. dem Sicherheitsbed¨ urfnis der Kooperation und der beteiligten Bereiche/Prozesse und 3. den monet¨aren Mitteln bzw. den zeitlichen Vorgaben.

5.2.3 Auditierung einer Unternehmung ¨ Die ISO 17799 und das neue GSHB bieten die entsprechenden Controls, um eine Uberpr¨ ufung der Sicherheitsmaßnahmen durchzuf¨ uhren. Softwaregest¨ utzte Tools erm¨oglichen dabei eine Erfassung der Daten sowie die Generierung von Reports und ggf. Benchmarks. Das Open Source Security Testing Methodology Manual (OSSTMM) des Institute for Security and Open Methodologies (ISECOM) oder auch OCTAVE bieten ein standardisiertes Vorgehen zum methodischen Testen von Systemen.503 Der Auditprozess sollte stets durch mindestens zwei gleichberechtigte Auditoren stattfinden. Das Vier-Augen-Prinzip verst¨arkt die objektive Erfassung des Untersuchungsgegenstandes und minimalisiert das Fehlerpotenzial in der Erhebung. Die Auditierung einer Unternehmung, eines Bereiches oder eines Prozesses kann in Abh¨angigkeit von der Zielsetzung betrachtet werden. Ein Audit mit der Zielsetzung einer offiziellen Zertifizierung kann nur durch akkreditierte Stellen (Certification Bodies, 502 Die Dauer einer Zertifizierung ist abh¨ angig von der Anzahl der parallel eingesetzten Auditoren. 503 Vgl. Institute for Security and Open Methodologies 2006.

180

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Zertifizierungsinstanzen) erfolgen. Eine Akkreditierung der Zertifizierungsinstanzen kann ausschließlich durch die jeweiligen nationalen Akkreditierungsstellen gem¨aß der European co-operation for Accreditation (EA), Richtlinie 7/03, erteilt werden.504 In Deutschland ist die Tr¨agergemeinschaft f¨ ur Akkreditierung GmbH (TGA) in Frankfurt zust¨andig. Gegenseitige Anerkennungsvereinbarungen zwischen den nationalen Akkreditierungsstellen garantieren die G¨ ultigkeit der Zertifikate auch in anderen L¨andern.505 Zur Zeit (Stand Mai 2006) existieren sieben g¨ ultige Zertifizierungsinstanzen f¨ ur den zweiten Teil des BS 7799 in Deutschland. Als organisatorische Grundlage einer BS 7799-2-Zertifizierung gilt die EA 7/03. Dort werden die Anforderungen an die Zertifizierungsstelle und die Auditoren sowie anderweitige Randbedingungen definiert. Der Zertifizierungsprozess kann in folgende Teilprozesse aufgeteilt werden: • Initiierung, • Vorarbeiten - Realisierung der dokumentierten Anforderungen, • Auditierung, • Dokumentation der Auditierung, • Pr¨ ufung der Auditierung auf Korrektheit, • Entscheidung u ¨ber Zertifikatsvergabe, • Ver¨offentlichung des Zertifikats, • Rezertifizierung. Das Ablaufschema einer Zertifizierung nach BS 7799-2/ISO 27001 gestaltet sich wie folgt:506 1. Die Unternehmung beauftragt eine akkreditierte Zertifizierungsinstanz mit der ¨ Uberpr¨ ufung des ISMS. 2. Ein Audit-Team wird durch die Zertifizierungsinstanz zusammengestellt. 3. Die Dokumentation wird u uft und beurteilt. ¨berpr¨ 4. Es werden Audits vor Ort durchgef¨ uhrt und die Einhaltung der Controls wird u ¨ berpr¨ uft. 5. Ein Audit-Bericht wird erstellt. 6. Das Zertifikat wird erteilt, falls der Audit-Bericht positiv ausf¨allt. 504 Vgl. European co-operation for Accreditation (EA) 2000. 505 Vgl. V¨olker 2005: 16. 506 Vgl. V¨olker 2005: 17; BSI 2004a: 7ff.

5.2 Zertifizierung von Zulieferunternehmungen

181

Das Zertifikat weist einen G¨ ultigkeitszeitraum von bis zu drei Jahren auf. Anschließend kann eine Wiederholungszertifizierung erfolgen, welche die G¨ ultigkeit um bis zu drei Jahren verl¨angert. Doch auch bei einem Self Assessment ist es ratsam, dieses durch (interne) Fachkr¨afte durchf¨ uhren zu lassen, die in den entsprechenden Kriterienwerken und Standards geschult sind.507 Dies erm¨oglicht eine h¨ohere Konformit¨at zum gew¨ahlten Standard und kann, falls zu einem sp¨ateren Zeitpunkt eine Zertifizierung anvisiert wird, diese erleichtern.508 Im Rahmen eines Self Assessment m¨ ussen die Ergebnisse dokumentiert und Ziele formuliert werden. In einem weiteren, darauf folgenden Self Assessment kann der Grad der Zielerreichung kontrolliert werden. Zur Darstellung kann z.B. ein Netzdiagramm dienen (vgl. Abb. 5.3).509 IT-Sicherheitsregelwerk Audit-Prozess Regelmäßige Penetrationstests autom. SW-Distribution Notfallkonzepte Härten der Server V erschlüsselung der Datenablage

5 4 3 2 1 0

IT-Sicherheitsorganisation V erzeichnis Systeme/Applikationen Datenklassifizierung Sensibilisierung IT-Sicherheitsvorfallbehandlung Zentrales Berichtswesen

V erschlüsselung Client/Anwendung

V irenschutz

Authentisierung

Geräte-Sicherheit

Netzwerksegmentierung Access & Identity Management

Spamfilter V erschlüsselung der Leitungen

V erschlüsselung von E-Mails

Abbildung 5.3: M¨ogliche Darstellung eines Self Assessments mit Grad der Zielerreichung

507 Zu den popul¨arsten, international anerkannten Schulungen geh¨oren unter anderem die Zertifizierung zum Certified Information Security Systems Professional (CISSP), BSI Lead Auditor, OSSTMM Professional Security Tester (OPST) oder Analyst (OPSA). Der Lead Auditor des British Institute of Standards (BSI, nicht zu verwechseln mit dem deutschen Bundesamt f¨ ur Sicherheit in der Informationstechnik) ist jedoch nicht berechtigt BS 7799 Zertifikate zu erteilen. Unter den deutschen Schulungsstandards ist vor allem der IT-Grundschutz-Auditor hervorzuheben, der sich in einem vereinfachten Verfahren als ISO 27001 Grundschutz-Auditor lizensieren lassen kann, vgl. BSI 2006. 508 Ein solches internes Self Assessment w¨ are gewissermaßen ein Pr¨a-Audit. 509 Die dickere schwarze Linie in Abbildung 5.3 stellt hier das Minimalziel dar, w¨ahrend die Fl¨ache den Ist-Zustand beschreibt. Die Auspr¨ agung (Ziffer 0 bis 5) beschreibt den Grad der Zielerreichung gem¨aß SPICE.

182

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Im Anschluss an ein Audit muss der Audit-Bericht in der Unternehmung an die relevanten Personenkreise kommuniziert werden. Dazu geh¨oren unter anderem, neben dem CISO, der CIO und der Vorstand. Sollte der Audit-Bericht Sicherheitsl¨ ucken, Gef¨ahrdungen und daraus entstehende (nicht-tragbare) Risiken enthalten, so muss dies entsprechend, ggf. mit einem Aktionsplan, mitgeteilt werden. Dieser sollte neben der Definition von durchzuf¨ uhrenden Maßnahmen die entsprechenden verantwortlichen Personen und den Zeitpunkt nennen, bis zu welchem die Maßnahmen umgesetzt sein m¨ ussen. Der Aktionsplan kann sich vorteilhaft auf die Bewilligung von Mitteln zur Reduktion der Risiken auswirken. Einige der europ¨aischen Automobilhersteller haben sich in einem Arbeitskreis zusammengeschlossen, um regelm¨aßig die Ergebnisse der Auditierungen (auf der Basis von Self Assessments) zu vergleichen, Best-Practices zu erarbeiten und interne Benchmarks zu erstellen. Zu diesem Zweck wurden mehrere Themen aus dem Bereich der IT-Sicherheit ausgew¨ahlt, die nach Einsch¨atzung des Arbeitskreises zu den vordringlichsten Aufgaben im unternehmungsweiten Risikomanagement geh¨oren. Die Themengebiete werden auf Controls/Kapitel des BS 7799-2 referenziert. 1. IT-Sicherheitsregelwerk, 2. Unternehmungsweite interne IT-Sicherheitsorganisation, 3. Verzeichnis der Systeme und Applikationen inkl. Ansprechpartner, 4. Datenklassifizierung, 5. Sensibilisierung (Konzept, Prozess, Organisation), 6. IT-Sicherheitsvorfallbehandlung und pr¨aventive Aufgaben des CERTs, 7. Zentrales IT-Sicherheitsberichtwesen, 8. Virenschutz, 9. Ger¨ate-Sicherheit (z.B. Personal Firewall, host-basiertes IDS/IPS), 10. Spamfiltering, 11. Verschl¨ usselung der Datenleitungen (nur außerhalb der Betriebsgel¨andes, z.B. Verschl¨ usselung der WANs), 12. Verschl¨ usselung von E-Mails, 13. Access and Identity Management, 14. Netzwerksegmentierung (Separierung der Segmente in verschiedene Sicherheitszonen), 15. Authentisierung gem¨aß Datenklassifikation,

5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie

183

¨ 16. Verschl¨ usselte Ubertragung zwischen Client und Anwendung (Ende-zu-Ende Verschl¨ usselung), 17. Verschl¨ usselung der Daten bei der Datenablage, 18. H¨arten der Server, 19. Notfallkonzepte, Datensicherungskonzepte, Wiederherstellungskonzepte, 20. Automatische Softwareverteilung (insbesondere Sicherheitspatches, evtl. inklusive R¨ uckdokumentation der Versionsst¨ande), 21. Test auf Verwundbarkeiten/Schwachstellen (Penetrationstests, Scanning), 22. Auditprozess (Konzept, Prozess, Organisation). Zulieferer k¨onnen diese Rangliste als ein Indiz f¨ ur die Priorisierung der eigenen IT-Sicherheitsmaßnahmen nutzen.

5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie Zur Verdeutlichung soll der Gestaltungsansatz zur IT-Sicherheit f¨ ur eine fiktive bilaterale F&E-Kooperation zwischen einem OEM und einem Zulieferer dargestellt werden. Anhand dieses Beispiels sollen Gefahrenquellen identifiziert und entsprechende Gegenmaßnahmen vorgestellt bzw. diskutiert werden. Das verwendete Beispiel wird bewusst simplifiziert, da viele Sicherheitsmaßnahmen in Abh¨angigkeit von unternehmungs- und kooperationsspezifischen Bedingungen vorgenommen werden m¨ ussen.510 Die Kooperation wird hier in die Prozessabschnitte Anforderungs-/Spezifikationsphase, Anbahnungsphase, Kooperationsphase und Abschlussphase unterteilt. 1. Anforderungs-/Spezifikationsphase: In einer fr¨ uhen Entwicklungsphase f¨ ur ein neues Fahrzeug stellt der OEM fest, dass die Lichtmaschine des Vorg¨angermodells nicht optimal geeignet ist, da sie nicht vollst¨andig den spezifizierten Anforderungen entspricht. Die Anforderungen f¨ ur die neue Lichtmaschine werden in einem Lastenheft konkretisiert. 2. Anbahnungsphase: Das Lastenheft wird elektronisch an die potenziellen Lieferanten u ¨bermittelt. Der Zulieferer analysiert das Lastenheft und kommuniziert es intern, z.B. an das Management, die Forschung und Entwicklung und den Vertrieb. Das entsprechende Angebot des Zulieferers wird an den OEM versandt, welcher, je nach 510 Es existieren Abh¨angigkeiten, z.B. von Infrastrukturen, verwendeter Technologie, Applikationen, Systemen, Dokumententypen und anderen in Abschnitt 4.6 genannten Aspekten.

184

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Sourcing-Strategie, einem oder mehreren Lieferanten den Zuschlag erteilt. In einem Pflichtenheft wird die vertraglich bindende Beschreibung der zu erf¨ ullenden Leistung detailliert. 3. Kooperationsphase: Nach Vertragsabschluss beginnen die Arbeiten an der Entwicklung der Lichtmaschine, die durch ein gemeinsames Projektteam koordiniert werden. Der Zeitrahmen des Projektes erfordert eine enge Zusammenarbeit zwischen OEM und Zulieferer und es erfolgt ein kontinuierlicher Austausch von elektronischen Dokumenten (Office-Dateien, PDF-Dateien, CAD-Daten, etc.) per E-Mail und u ¨ber Kollaborationssoftware. Nach der Abstimmung der technischen Details (z.B. elektrische Eigenschaften, Steckverbindungen, Abmessungen) werden Prototypen erstellt und getestet. 4. Abschlussphase: Nach erfolgreichen Tests beginnt die Serienproduktion der Lichtmaschine und die Auslieferung an den OEM. Die verwendeten Dokumente werden archiviert. Im Folgenden werden die Prozessabschnitte separat aus Sicht der IT-Sicherheit analysiert und bewertet. In diesem Beispiel liegt das Hauptaugenmerk aus IT-Sicherheitssicht auf dem Austausch von Daten zwischen den beiden Partnern. In einem derartigen Szenario ist sowohl die unternehmungsinterne, als auch die unternehmungs¨ ubergreifende ITSicherheit zu betrachten. Die interne IT-Sicherheit kann, wie beschrieben, durch ein ISMS gew¨ahrleistet werden. Hier wird davon ausgegangen, dass die unternehmungsinterne ITSicherheit bei dem OEM gegeben ist. Bei dem Austausch und der Bearbeitung von Daten muss jedoch die gesamte Prozess- und Lebenszykluskette von der Erstellung, Verteilung, Bearbeitung bis zur Archivierung betrachtet werden.

5.3.1 Anforderungs-/Spezifikationsphase Solange der OEM die Anforderungen ohne die Hilfe externer Partner definiert und die IT-Sicherheit durch die im ISMS spezifizierten Regeln und Prozesse gew¨ahrleistet wird, werden keine gesonderten Maßnahmen ben¨otigt.

5.3.2 Anbahnungsphase In der Anbahnungsphase wird das Lastenheft an die potenziellen Kooperationspartner/Lieferanten verschickt. Dies geschieht in der Regel elektronisch. Da ein Lastenheft (je nach Umfang der dort beschriebenen Anforderungen) bereits sensible Informationen enthalten kann, sollten diese beim Versand vor unbefugter Einsichtnahme (Schutzziel Vertraulichkeit) gesch¨ utzt werden. Dies l¨asst sich mit Hilfe kryptografischer Methoden (hier:

5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie

185

Verschl¨ usselung mit hinreichend gepr¨ uften Verfahren und angemessenen Schl¨ ussell¨angen) erreichen. Dabei stehen zwei M¨oglichkeiten zur Disposition. Zum einen kann asymmetrische Kryptografie genutzt werden, wenn der Kooperationspartner u ¨ber entsprechende Applikationen und kryptografische Schl¨ ussel verf¨ ugt. Zum anderen kann symmetrische Kryptografie genutzt werden. Dabei muss dem Partner eine Passphrase zum Entschl¨ usseln der ¨ ¨ Daten mitgeteilt werden. Die Ubertragung der verschl¨ usselten Datei(en) und die Ubertragung des Passworts zum Entschl¨ usseln der Datei(en) sollte u ¨ber unterschiedliche Kommu¨ nikationswege erfolgen, z.B. der Versand der Datei(en) per E-Mail und die Ubertragung des Passwortes per Telefon. Ein potenzieller Angreifer m¨ usste beide Kommunikationsstrecken (Telefon und Internet) u ¨berwachen, um an das Passwort und die Datei(en) zu gelangen. In der internen Kommunikation des Lieferanten muss sichergestellt werden, dass die Informationen nach dem Need-to-know-Prinzip nur den Personen zur Verf¨ ugung steht, die diese ben¨otigen. Alle folgenden vertraglichen Details d¨ urfen, um die Vertraulichkeit zu wahren, ausschließlich verschl¨ usselt zwischen OEM und Zulieferer ausgetauscht werden. Dies dient vornehmlich dem Schutz der Gesch¨aftst¨atigkeit des Zulieferers, da z.B. Preisinformationen f¨ ur Wettbewerber des Zulieferers von Interesse sein k¨onnen und andere OEMs die Informationen nutzen k¨onnen, um evtl. Preisreduzierungen zu fordern. F¨ ur beide Partner w¨ urde eine breite Ver¨offentlichung der Vertragsdetails eine Besch¨adigung der Reputation bedeuten.

5.3.3 Kooperationsphase Die Kooperationsphase ist der zentrale Bestandteil der Zusammenarbeit zwischen einem OEM und einem Lieferanten, da hier geistiges Eigentum ausgetauscht wird bzw. entsteht. Selbst bei einer vollst¨andigen Eigenentwicklung durch den Lieferanten (Buy) ben¨otigt der ¨ OEM vom Lieferanten einen stetigen Abgleich f¨ ur alle Anderungen am Leistungsb¨ undel, da jede Modifikation an einer Komponente f¨ ur das Fahrzeug von Bedeutung sein kann. Neben den elektrischen, elektronischen, physikalischen oder geometrischen Eigenschaften des Bauteils f¨ ur die Integration in das Gesamtfahrzeug sind auch andere Merkmale von Bedeutung, z.B. f¨ ur Fertigung, Simulation (u.a Bauraumkollisionen) oder Recycling. Der h¨aufig stattfindende Abgleich vervielfacht das Aufkommen an elektronischer Kommunika¨ tion, das Daten¨ ubertragungsvolumen und damit auch die Gefahr, dass Angreifer Ubertragungen abh¨oren und Einblick in die Daten erhalten. Zugleich erh¨oht eine Intensivierung des Datenverkehrs die Wahrscheinlichkeit, dass in den Prozessen involvierte Mitarbeiter Fehler begehen, wie z.B. durch den Versand unverschl¨ usselter Daten.

186

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Es ist u ¨blich, dass die Datenklassifikation den Mitarbeitern u ¨berlassen wird, d.h. dass jeder Mitarbeiter die von ihm erstellten Daten nach ihrem Schutzbedarf klassifiziert. Die Praxis zeigt, dass dies in der Regel nur in unzureichendem Umfang durchgef¨ uhrt wird, da die Mitarbeiter nicht entsprechend motiviert bzw. sensibilisiert sind.511 Neben der Sensibilisierung der Mitarbeiter ist es vorteilhaft, wenn die Prozesse zur Aufrechterhaltung einer notwendigen Integrit¨at und/oder Vertraulichkeit so gestaltet werden, dass der Mitarbeiter sie nutzen muss bzw. die Einhaltung der Regeln u ¨berwacht wird (z.B. Self-policing Procedures). Die IT-Sicherheit betrachtet den notwendigen Schutz von Daten in Abh¨angigkeit von deren Wert. Die Wissensintegration hat z.B. in 3D-CAD-Systemen kontinuierlich zugenommen. W¨ahrend fr¨ uher CAD-Systeme in erster Linie nur der primitiven“ Modellent” wicklung und -darstellung (z.B. Geometrie) dienten, enthalten heutige Systeme ein umfangreiches Know-how und Informationen, z.B. u ¨ber Berechnungen, Parameterreferenzen, Normen, Adapter, Toleranzen, Skelette, verwendete Materialien, Packaging, etc. Dies ist abh¨angig von den verwendeten Systemen, deren Nutzung und den Datenformaten. Einige Datenformate weisen dabei potenzielle inh¨arente Schutzmaßnahmen auf. Das Wissen, welches in CAD-Daten verf¨ ugbar ist, kann beispielweise u ¨ber Strukturverschattung (z.B. Skelett- und Strukturelemination) und/oder Bauteilverschattung (z.B. Shrinkwrap) reduziert werden. H¨aufig ist die Entwicklungshistorie von Daten sch¨ utzenswerter als das endg¨ ultige Modell, da das Know-how stark mit dem Entwicklungsprozess des Modells verkn¨ upft ist. Nachteilig ist jedoch, dass die Reduzierung der Informationen in der Regel h¨andisch geschehen muss. Ein potenzieller L¨osungsansatz w¨are, ein System zu schaffen, u ur die Weitergabe an Externe auschecken“ muss ¨ber welches der Entwickler die Daten f¨ ” und welches die Daten automatisch um bestimmte Detailinformationen reduziert (siehe Abb. 5.4). System zur Informationsreduzierung von CAD-Dateien

Empfänger

Sender

CAD-Dokument mit Wissensintegration

CAD-Dokument ohne Wissensintegration

Abbildung 5.4: Automatische Reduktion von Informationen in CAD-Dokumenten

511 Der Sicherheitsexperte Bruce Schneier merkt dazu an: Data classification is one of those ideas that ” sounds a lot better than it works in practice (unfortunately).“ Vgl. Schneier 2000.

5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie

187

Die Komplexit¨at einer solchen L¨osung wird durch den Einsatz unterschiedlicher Software bzw. Softwareversionen gesteigert. Im Zweifelsfall muss der Zulieferer sicherstellen, dass seine CAD-Software kompatibel zu der des Auftraggebers ist. In der Regel muss ein Zulieferer mehr als eine CAD-Software nutzen (aufgrund der T¨atigkeit f¨ ur verschiedene Auftraggeber) oder die Kooperationspartner m¨ ussen sich auf ein gemeinsames Datenformat respektive eine gemeinsame Software einigen. Wenn unterschiedliche Software oder Softwareversionen genutzt werden, muss das System zur Datenreduktion dies erkennen und entsprechend die jeweils enthaltenen Informationen auf das gew¨ unschte Maß reduzieren. Die ODETTE empfiehlt den Einsatz neutraler CAD/CAM-Formate, wie z.B. Initial Graphics Exchange Specification (IGES), Verband der Automobilindustrie Fl¨achenSchnittstelle (VDA-FS), Verband der Automobilindustrie IGES Subset (VDA-IS), Standard d’Exchange et de Transfert (SET), Standard for the Exchange of Product Model Data (STEP) und anderer.512 Auch andere Dokumentenformate k¨onnen von einer derartigen L¨osung profitieren. Manche Formate (z.B. bestimmte Office-Dokumente) beinhalten ¨ eine Historie, anhand derer Anderungen im Dokument nachverfolgt werden k¨onnen. Der Empf¨anger eines Dokuments mit aktiver Historie kann die Versionen des Dokuments einsehen, woraus ersichtlich werden kann, dass bestimmte Details (z.B. Preise) ge¨andert wurden oder welche Kommentare bestimmte Benutzer bez¨ uglich des Inhalts vorgebracht haben. Ein weiterer L¨osungsansatz geht u ur viele ¨ber den Bezug auf CAD-Daten hinaus und ist f¨ Datenformate nutzbar. Der Begriff des Digital Rights Management (DRM) steht f¨ ur einen Ansatz, der den Schutz des geistigen Eigentums durch ein Management von Zugriffs- und Nutzungs- bzw. Verwendungsrechten unter Zuhilfenahme informationstechnologischer und kryptografischer Mittel und Methoden erm¨oglicht.513 DRM hat eine gr¨oßere Verbreitung in dem Verkauf und der Distribution von digital publizierten Inhalten (haupts¨achlich Bilder, Filme, Musik und Literatur) erfahren.514 In der Dom¨ane der digitalen Dokumente im Unternehmungsbereich ist dieser L¨osungsansatz bisher wenig verbreitet. Die Grundlage der Technologie bildet die Einbettung der zu sch¨ utzenden Inhalte (z.B. Office- oder andere Dokumente) in einen Datencontainer, welcher verschl¨ usselt und mit spezifischen Rechten versehen wird. Zu den im Datencontainer definierten Rechten k¨onnen beispielsweise das 512 Vgl. ODETTE 2000. 513 Dieser Ansatz wurde fr¨ uher alternativ u.a. als Intellectual Property Rights Management (vgl. Ramanujapuram/Ram 1998) oder auch Electronic Rights Management System (vgl. Hill 1999) bezeichnet. 514 Dazu ausf¨ uhrlich G¨ unnewig 2005. In der Diskussion um DRM bei kommerziellen Inhaltanbietern aus den genannten Bereichen wird h¨ aufig auf die Verschr¨ ankung von rechtlichen und technischen Schutzmaßnahmen hingewiesen, z.B. bei Bechtold 2002: 264. Der rechtliche Aspekt tritt hier in den Hintergrund, da die Nutzung bzw. Verwertung von fremdem geistigen Eigentum ohne die entsprechenden Rechte durch das Gesetz u utzt ¨ber Urheberrecht und verwandte Schutzrechte (UrhG) gesch¨ ist. Vgl. UrhG, zuletzt ge¨ andert durch Art 1 G vom 10.09.2003 I 1774; 2004, 312.

188

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

¨ Lesen, Andern, Drucken, Speichern, Speichern unter einem anderen Namen, Kopieren ¨ (des Datencontainers oder von Texten/Objekten), der Versand per Email, das Andern bestimmter/aller Rechte oder das Ablaufdatum des Dokuments geh¨oren. Nur definierte Objekte/Personen/Gruppen k¨onnen diese Rechte f¨ ur einen Datencontainer und das darin enthaltene Dokument ¨andern. Weitere Elemente, die in einem Datencontainer enthalten sein k¨onnen, sind u.a. Informationen u ¨ber den Autor, Rechteinhaber und Nutzer, eindeutiger Identifikationscode des Containers oder der Uniform Resource Locator (URL) des Policyservers. Spezifische Metadaten k¨onnen in der Regel an den Container gebunden werden und sind nicht verschl¨ usselt.515 Der Prozess f¨ ur ein digitales Rechtemanagement ist nicht standardisiert, folgt aber den Grundprinzipien der Abb. 5.5. Lesen Ändern Drucken Speichern E-Mail Rechte

Empfänger

Applikation

2

1

3

Policy Server

4

7

5

Autor Sender

2

6

Abbildung 5.5: Funktionsprinzip von Digital Rights Management Systemen Ein Autor (z.B. ein Entwickler) kreiert ein Dokument in einer Applikation (1). F¨ ur dieses Dokument legt der Entwickler fest, welche Rechte ein definierter Empf¨anger besitzen soll (2). Der Policy Server, der die Rechte verwaltet, bettet das Dokument in einen Datencontainer und appliziert die vom Entwickler definierten Rechte f¨ ur den Empf¨anger (3). Das Dokument wird an den Empf¨anger versandt oder zur Abholung bereitgestellt (4). Beim ¨ Offnen des Containers muss sich der Empf¨anger am Policy Server authentisieren (5) und es kann gepr¨ uft werden, ob das Dokument g¨ ultig ist oder ob z.B. die Aktionen des Users geloggt werden sollen (6). Erf¨ ullen das Dokument und der Empf¨anger die spezifizierten Bedingungen, kann der Empf¨anger das Dokument so nutzen, wie die Nutzungsrechte es ihm erlauben (7). Seit Schritt (3) ist das Dokument kontinuierlich durch das Rechtemanagement und die zu Grunde liegenden kryptografischen Mechanismen gesch¨ utzt. Auch 515 Dies k¨onnten z.B. Engineering Data (ENGDAT) Nachrichten sein. Vgl. ODETTE 2006.

5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie

189

w¨ahrend oder nach der Nutzung durch den Empf¨anger ist das Dokument – in dem vorher definierten Rahmen – gesch¨ utzt. F¨ ur den Schutz des Policy Servers sollten umfangreiche Schutzmaßnahmen getroffen werden, z.B. eine H¨artung des Servers oder der Einsatz eines hostbasierten IPS, da er f¨ ur die Rechtevergabe zust¨andig ist. Abh¨angig von der Ausgestaltung der (Sicherheits-) Architektur kann ein erfolgreicher Angreifer eventuell die Kontrolle u ugbaren Datencontainer aus¨ uben. ¨ber alle im DRM-System verf¨ In DRM-Systemen m¨ ussen die Nutzer bzw. Nutzergruppen entsprechend registriert sein. Zudem ist es unerl¨asslich, dass ein derartiges System mindestens eine starke Authentifikation vorsieht, d.h., dass sich der Nutzer am Policy Server mittels einer Zwei-FaktorAuthentifikation (z.B. Besitz und Wissen in Form einer PKI-Karte und PIN oder Passwort) authentisiert.516 Es l¨asst sich h¨aufig in den Datencontainern definieren, wie lange eine Authentifikation g¨ ultig ist. Damit kann z.B. garantiert werden, dass ein Mitarbeiter auch am Wochenende oder auf Reisen ohne die M¨oglichkeit einer Netzwerkkonnektivit¨at die Dokumente lesen oder u ¨berarbeiten kann. Bei DRM-Systemen muss ein potenzieller Angreifer einen Trojaner auf einem Client des Kooperationspartners installieren, der den Bildschirminhalt wiedergibt, damit er an Informationen aus dem Datencontainer gelangen kann.517 Falls ein Angreifer in den Besitz eines DRM-gesch¨ utzten Datencontainers gelangt, ist das Wissen innerhalb des Containers durch kryptografische Mechanismen gesch¨ utzt und f¨ ur den Angreifer nicht verwertbar. Gelangt der Angreifer an die notwendigen Merkmale zur Authentisierung am Policy Server, dann kann er – unter der Voraussetzung, dass der Bestohlene den Verlust seiner PKI-Karte nicht gemeldet hat und der Angreifer die PIN kennt – zwar eventuell den Inhalt des Datencontainers einsehen, aber er hinterl¨asst Spuren am Policy Server, der die IP-Adresse und die Handlungen loggt. Je nachdem welche Rechte das Opfer auf den Datencontainer hatte, kann es dem Angreifer sogar unm¨oglich sein, die Daten z.B. aus dem Container zu entfernen, zu drucken oder zu kopieren. Wenn die Inhalte w¨ahrend des unternehmungs¨ ubergreifenden Datenaustausches nicht verschl¨ usselt sind, sollte eine Transportverschl¨ usselung (z.B. SSL oder IPSec) durchgef¨ uhrt werden, damit die Inhalte gegen Spionage und Manipulation gesch¨ utzt sind. Die potenziellen Schwachpunkte bei Ende-zu-Ende-Verschl¨ usselungen sind im Wesentlichen die Clients. Wenn es einem Angreifer gelingt, einen der Clients zu infiltrieren und z.B. mit einem Trojaner zu versehen, welcher ihm einen Zugriff auf den Client erlaubt, dann ist diese Form der Verschl¨ usselung wirkungslos, da die Daten am Endpunkt in unverschl¨ usselter Form vorliegen. Bei Netzwerk-zu-Netzwerk-Verschl¨ usselungen ist der Bereich des internen Netzwerks betroffen, der hinter der entschl¨ usselnden Netzwerkkomponente liegt. Alle dort 516 Dadurch wird das Mitlesen von Authentifikationsdaten (z.B. Benutzername und Passwort) verhindert. Idealerweise k¨onnten PKI-Karten in Verbindung mit Klasse-3-Leseger¨aten verwendet werden. 517 Voraussetzung f¨ ur diese Pr¨ amisse ist, dass die Anmeldung am Policy Server mit einer Zwei-FaktorAuthentisierung erfolgt (Besitz und Wissen bzw. biometrisches Merkmal und Wissen).

190

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

konnektierten Ger¨ate k¨onnen theoretisch, falls keine spezifischen Sicherheitsmaßnahmen getroffen wurden, die dann unverschl¨ usselten Daten ausspionieren oder manipulieren. So genannte Leased Lines sind eine weitere Option in der Gestaltung sicherer Kommunikationsprozesse. Dabei werden Datenleitungen exklusiv angemietet und es besteht die M¨oglichkeit einer Leitungsverschl¨ usselung (OSI-Schicht 1, Gateway-zu-Gateway). Es ist zu beachten, dass kein sog. Dual- oder Split-Tunnelling durchgef¨ uhrt wird. Dies w¨are der Fall, wenn ein System als Router/Gateway zwischen zwei – gleichzeitig aktiven – Netzwerksegmenten fungiert, von denen eines als unsicher eingestuft wird (z.B. Internet), wodurch die Sicherheit einer derartigen Gestaltungsmaßnahme kompromittiert werden k¨onnte.518 Eine weitere L¨osungsm¨oglichkeit ist der Einsatz von Terminal- oder virtuellen Servern. Bei diesem Ansatz stellt der OEM oder der Zulieferer einen Server oder Servercluster bereit, auf dem sich der Kooperationspartner u ¨ ber ein VPN einloggt. Eine hinreichend schnelle und stabile Netzwerkverbindung zum Server ist notwendig, damit die Mitarbeiter, die auf dem entfernten Server arbeiten, nur einen geringen bzw. keinen Unterschied zu dem Arbeiten auf dem lokalen Client sp¨ uren. Dies ist auch abh¨angig von der Anzahl gleichzeitiger Nutzer auf dem Terminalserver, deren Nutzungsverhalten und der Dimensionierung der Server-Hardware.519 Durch Policys l¨asst sich verhindern, dass Informationen oder Dokumente den Terminalserver verlassen und z.B. auf den lokalen Client kopiert werden. Ein weiterer Vorteil dieser L¨osung ist, dass Thin Clients genutzt werden k¨onnen, was bedeutet, dass die Client-Hardware nur geringe Ressourcen (CPU, Speicher, Grafikkarte etc.) ben¨otigt und deshalb weniger Kosten verursacht. Der Nachteil dieser L¨osung ist, dass sie nur mit einer Netzwerkanbindung an entsprechende Server funktioniert. Eine gewichtige Einschr¨ankung ist, dass Terminalserver nicht f¨ ur alle Einsatzgebiete geeignet sind. Sie eignen sich haupts¨achlich f¨ ur Aufgaben, die eine m¨oglichst geringe und gleichm¨aßige Prozessorauslastung erzeugen, wie z.B. das Erstellen und Bearbeiten von Office-Dokumenten. Da auf einem Terminalserver in der Regel mehrere Benutzer gleichzeitig arbeiten, ist die gleichm¨aßige Lastverteilung wichtig. Wenn einer dieser Benutzer den Prozessor des Servers stark beansprucht, wird die restliche Rechenkapazit¨at unter den u ¨brigen Benutzern aufgeteilt. Wird der Prozessor von einem Benutzer vollst¨andig ausgelastet, dann ist keine oder kaum Kapazit¨at f¨ ur die anderen Benutzer verf¨ ugbar. Terminalserver sind damit nicht geeignet f¨ ur rechenintensive Aufgaben, welche nur partiell und sporadisch die Prozessorkapazit¨aten in Anspruch nehmen, wie beim Kompilieren von Software, bei 3D-Berechnungen oder aufw¨andigen Simulationen. 518 Dies wird ausf¨ uhrlicher in Abschnitt 5.5.3.1 behandelt. 519 Die Dimensionierung wird haupts¨ achlich u ¨ber die Anzahl, Art und Taktung der Prozessoren und die Menge an Random Access Memory (RAM) und Festplattenspeicher bestimmt.

5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie

191

In Unternehmungen wird f¨ ur die interne und externe Kooperation h¨aufig sogenannte Kollaborationssoftware eingesetzt. Die Nutzung von Kollaborationssoftware dient der synchronen (Shared Whiteboard/Desktop, Shared Application, Shared Information Use) bzw. asynchronen (Datenaustausch, Shared Workflow, kooperativer Hypertext, Diskussionsforen etc.) elektronischen Kooperation mit einer gemeinsamen Datenbasis.520 Asynchrone Kollaborationssoftware kann in erster Linie als eine gemeinsame Basis f¨ ur ein Dokumentenmanagementsystem verstanden werden. Dies ist in der Regel eine serverbasierte L¨osung. Synchrone Kollaborationssoftware erm¨oglicht das gemeinsame zeitgleiche Bearbeiten von Dokumenten. Dies kann entweder auf einer gemeinsamen Serverplattform oder u ¨ber die Freigabe von Ressourcen auf einem der beteiligten Clients geschehen. Die Nutzung einer gemeinsamen Serverplattform ist aus Sicht der IT-Sicherheit unkritisch, wenn der Server entsprechend geh¨artet ist, die Daten¨ ubertragung verschl¨ usselt (SSL, IPSec etc.) stattfindet, eine angemessene Anzahl und G¨ ute von Authentifikationsmerkmalen genutzt wird und ein Logging der Nutzeraktionen stattfindet.521 Kritisch ist jedoch die Freigabe von Ressourcen auf Clients zur Kollaboration, da ein solcher Client somit f¨ ur die anderen Kooperationsteilnehmer zum Server wird. Dabei lassen sich zwei grunds¨atzliche Modi unterscheiden: Pr¨asentation und Bearbeitung. Im Modus Pr¨asentation haben alle Teilnehmer außer dem Pr¨asentierenden Leserechte, d.h. sie k¨onnen die Pr¨asentation von ihrem lokalen Client aus verfolgen. Bei einer gemeinsamen Bearbeitung eines Projektes/einer Datei (z.B. Desktop oder Application Sharing) entstehen Risiken, da jeder Benutzer ggf. ¨ Schreib-, Lese-, Anderungsund Ausf¨ uhrungsrechte besitzt. In der Regel arbeiten dabei alle Benutzer mit einem gemeinsamen Benutzerkonto, so dass im Missbrauchs- bzw. Schadensfall eine forensische Analyse erschwert wird. Es ist nicht zu erwarten, dass der durchschnittliche Benutzer, auf dessen Client die Bearbeitung stattfindet, u ¨ber das notwendige Expertenwissen verf¨ ugt, um alle Aktionen der anderen Benutzer pr¨azise u ¨berwachen zu k¨onnen. Daher sollten, falls diese Form der Kooperation unerl¨asslich ist, die Benutzer entsprechend sensibilisiert und geschult werden. Die Vergabe und Distribution von Benutzerkonten und Passw¨ortern f¨ ur eine clientbasierte Kollaboration muss u ¨ ber sichere Kan¨ale erfolgen.522 Da manche Betriebssysteme bestimmte Formen der Kollaboration unterst¨ utzen, ist sicherzustellen, dass nur Software genutzt werden darf (besser noch: kann), die von den zust¨andigen Stellen gepr¨ uft und freigegeben worden ist.

520 Vgl. Abb. 4.2 auf S. 154. 521 Diese Form der Nutzung ist vergleichbar mit der Nutzung eines Terminalservers. Der Unterschied besteht haupts¨achlich darin, dass nicht jeder Nutzer eine eigene Arbeitsoberfl¨ache (Desktop) erh¨alt, sondern die Nutzer auf einer gemeinsamen Arbeitsoberfl¨ ache operieren. 522 Vorzugsweise ist ein starkes Authentifikationsverfahren zu nutzen.

192

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

5.3.4 Abschlussphase In der Abschlussphase m¨ ussen die Dokumente – je nach vertraglicher Vereinbarung – vernichtet, zur¨ uckgesendet oder archiviert werden. Bei der Vernichtung von Daten durch Entsorgung der Datentr¨ager ist zu beachten, dass diese entweder physikalisch vollst¨andig zerst¨ort (z.B. durch schreddern) oder durch mehrfaches u ¨berschreiben (z.B. mit zuf¨alligen Bitmustern) zuverl¨assig und unwiderruflich gel¨oscht werden. Das Zur¨ ucksenden bei elektronischen Dokumenten in Kooperationen wird in der Regel nicht gesondert betrachtet. Es ist jedoch vertraglich festzulegen, was mit den Dokumenten beim Auftragnehmer geschehen soll. Der Auftraggeber sollte alle relevanten Ergebnisse erhalten und deren Integrit¨at u ufen. Falls es vertraglich festgelegt wurde, dass der ¨berpr¨ Auftragnehmer alle zugeh¨origen Dokumente eliminieren soll, dann muss der Auftragnehmer sicherstellen, dass alle Kopien und Originale vernichtet werden. Dies ist durch si” cheres L¨oschen“ zu gew¨ahrleisten, d.h. dass die Dateien gel¨oscht und der ehemals belegte Speicher mehrfach u ¨berschrieben wird, um eine Rekonstruktion der Daten zuverl¨assig zu verhindern. Es ist sehr schwierig, dies bei allen Beteiligten einer Kooperation wirkungsvoll umzusetzen. Eine Kooperationsl¨osung, die ausschließlich u ¨ ber Terminalserver oder DRMSysteme durchgef¨ uhrt wurde, kann dies gew¨ahrleisten. Wenn die Terminalserver dergestalt konfiguriert wurden, dass ein Herunterladen der Inhalte auf den Client nicht m¨oglich ist und die Server sich im Besitz des Auftraggebers befinden, dann entf¨allt dementsprechend das L¨oschen von Dokumenten auf der Clientseite. Bei einem DRM-System im Besitz des Auftraggebers m¨ ussten die Berechtigungen des Auftragnehmers f¨ ur die jeweiligen Datencontainer gel¨oscht werden. Bei der Archivierung ist zu beachten, dass ein entsprechendes Konzept vorliegt, wie mit den jeweiligen Daten zu verfahren ist. Sollten die Daten durch ein DRM-System gesch¨ utzt sein, so ist sicherzustellen, dass auf die Daten auch nach einem l¨angeren Zeitraum ein Zugriff m¨oglich ist.523 Falls Datenleitungen angemietet wurden und diese nach Ende der Kooperation nicht mehr ben¨otigt werden, dann sollte die Anmietung der Leased Line(s) aufgrund der Kosten gek¨ undigt werden. Es ist darauf zu achten, dass das Vertragsverh¨altnis mit dem Provider f¨ ur diese Leased Line(s) entsprechende K¨ undigungsfristen und -bedingungen vorsieht. F¨ ur die Anlieferung von Teilen in Just-in-Time-Konzepten werden in der Regel elektronische Lieferabrufe verwendet, die die Liefermenge und den Liefertermin bestimmen. Die Integrit¨at und Authentizit¨at der Informationen in den Lieferabrufen muss gew¨ahrleistet sein, ansonsten k¨onnte ein Angreifer Liefermengen und -termine manipulieren bzw. fingie523 Dies kann von Bedeutung sein, wenn ein Technologiewechsel stattgefunden hat, z.B. auf andere Verschl¨ usselungsalgorithmen, DRM-Systeme, Public-Key-Infrastrukturen, etc.

5.3 Fallbeispiel einer F&E-Kooperation in der Automobilindustrie

193

ren. Des Weiteren muss gew¨ahrleistet sein, dass die Systeme, die Lieferabrufe versenden bzw. entgegennehmen innerhalb eines definierten Rahmens verf¨ ugbar sind bzw. Prozesse im Rahmen eines Business-Continuity-Management einen Austausch von Informationen u ¨ber alternative Kommunikationskan¨ale vorsehen.

5.3.5 Abschließende Bewertung Die IT-Sicherheit in vertikalen F&E-Kooperationen kann mit den dargestellten Mitteln und Methoden realisiert werden. Die beschriebenen L¨osungsans¨atze sind jedoch nicht innerhalb eines kurzen Zeitrahmens zu realisieren, wenn umfangreiche heterogene ITInfrastrukturen vorhanden sind. Es wird h¨aufig verlangt, dass sich die IT-Sicherheit den etablierten Prozessen anpassen muss. Aus Gr¨ unden der Nutzerakzeptanz ist dies w¨ unschenswert, da der Erfolg der IT-Sicherheitsmaßnahmen im Wesentlichen von der Partizipation der Nutzer abh¨angig ist. Jedoch kann die Umgestaltung von Prozessen diese eventuell verschlanken und (nicht nur sicherheitstechnisch) optimieren. Der Prozessanalyse muss in der Einf¨ uhrung einer DRM-L¨osung besondere Aufmerksamkeit gegeben werden. Insbesondere das Management der Policys, der kryptografischen Schl¨ ussel und der (unternehmungs¨ ubergreifenden) Nutzer stellt ebenso eine Herausforderung dar, wie die Implementierung von DRM-Plugins in bestehende Systeme und Applikationen. Es lassen sich keine generellen Empfehlungen geben, da die optimale Gestaltung einer L¨osung von vielen Faktoren abh¨angig ist.524 Serverbasierte Kollaborationsl¨osungen sind clientbasierten vorzuziehen, da Kontrolle und Transparenz u ¨ber Einsatz und Nutzung des Systems und der Daten einfacher herzustellen sind. Es ist dabei zu beachten, dass die eingesetzten L¨osungen Rollen und Rechte fein granulieren k¨onnen, so dass die Diffusion von Inhalten (Daten) pr¨azise definiert und kontrolliert werden kann. Vertikale F&E-Kooperationen in der Automobilindustrie besitzen h¨aufig einen Projektcharakter, d.h. einen definierten Anfang und ein definiertes Ende. Es ist daher darauf zu achten, dass eine potenzielle L¨osung einen hohen Grad an Interoperabilit¨at aufweist, damit der L¨osungsansatz nicht nur in einer Kooperationsbeziehung, sondern in vielen eingesetzt werden kann. Dies gilt sowohl f¨ ur den Zulieferer als auch f¨ ur den OEM. Die Transportverschl¨ usselung ist eine Schutzmaßnahme, die zwar nur eine begrenzte Sicherheit bietet, aber daf¨ ur einen hohen Verbreitungs- und Akzeptanzgrad aufweist. Die Daten sind jedoch nur w¨ahrend des Transports gesch¨ utzt. Eine L¨osung auf der Basis von DRM 524 Generelle limitierende Faktoren sind monet¨ are Mittel, verf¨ ugbares und fachlich geeignetes Personal, angestrebter Zeitrahmen, Umfang der L¨ osung, Lizenzkosten, Anzahl und Art der zu migrierenden Systeme und Applikationen, Anzahl ben¨ otigter neuer Systeme, Applikationen und Infrastrukturelemente, Anforderungen aus den Fachbereichen, etc.

194

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

kann einen umfassenden Schutz und eine pr¨azise Kontrolle u ur ¨ber die Nutzungsoptionen f¨ Daten gew¨ahrleisten, ist jedoch stark anbieterspezifisch. Es muss umfassend gepr¨ uft werden, ob die anvisierte L¨osung die gew¨ unschten Datenformate unterst¨ utzt. Die Einf¨ uhrung einer DRM-L¨osung kann auf Widerst¨ande innerhalb einer Unternehmung stoßen, da die u uhrt werden m¨ ussen. ¨blichen Arbeitsabl¨aufe umgestellt und neue Prozesse eingef¨

5.4 Fazit IT-Sicherheit besch¨aftigt sich vordergr¨ undig mit dem Management und der Reduktion von Risiken und deren Auswirkungen. Auf den zweiten Blick l¨asst sich feststellen, dass IT-Sicherheit dem Management (und teilweise der Reduktion) von Komplexit¨at in spezifischen Bereichen einer Unternehmung dient. Durch die Nutzung von Standards und Best-Practices k¨onnen vorhandene Risiken mit geringen Aufw¨anden erheblich reduziert werden. Eine 100%ige Sicherheit l¨asst sich jedoch selbst mit gr¨oßtem Aufwand nur n¨aherungsweise erreichen. Der Einsatz des BS 7799 und seinen Nachfolgern hat sich weltweit in vielen Branchen durchgesetzt. Es ist daher sehr wahrscheinlich, dass eine zertifizierte Konformit¨at zu diesem Standard von Kooperationspartnern anerkannt wird. Es ist zu erwarten, dass die gesetzliche Regulierung bez¨ uglich der Sicherheitsanforderungen an die elektronische Da¨ tenverarbeitung in Unternehmungen weiter zunehmen wird.525 Ahnlich wie die ISO 9000Familie, die mittlerweile beinahe ein Synonym f¨ ur Qualit¨atsmanagement darstellt, wird langfristig die ISO 27000-Familie das IT-Sicherheitsmanagement in Unternehmungen dominieren. Es ist eine obligatorische Voraussetzung, dass eine Unternehmung ein internes ISMS etabliert, bevor die IT-Sicherheit von Kooperationsbeziehungen im Fokus stehen kann. Ohne die Konstituierung von Verantwortlichkeiten, die Etablierung von Prozessen und die Sensibilisierung der Mitarbeiter im bzw. f¨ ur den Themenkomplex IT-Sicherheit kann diese Aufgabe nicht realisiert werden.526 Das Fallbeispiel einer vertikalen F&E-Kooperation zwischen einem OEM und einem Zulieferer zeigt, dass unterschiedliche Optionen zur Ausgestaltung einer sicheren, unternehmungs¨ ubergreifenden Kooperation existieren. Die Wahl eines L¨osungsansatzes ist u.a. sehr stark abh¨angig von folgenden Faktoren: 525 Die IT-Sicherheit in Unternehmungen erh¨ alt mittelbar eine stetig wachsende Aufmerksamkeit, z.B. durch das KonTraG, SOX und andere gesetzliche Regelungen. Diese Regelungen haben haupts¨achlich die Kontrollm¨oglichkeiten, das Management von Risiken und die Transparenz von betriebswirtschaftlichen Belangen in Unternehmungen zum Ziel. IT-Sicherheit hat hier h¨aufig nur eine unterst¨ utzende Funktion. 526 Weitere Ans¨atze zur Risikoreduzierung in Unternehmungen enth¨alt das Dokument der Odette zu Risikoreduzierung und IT-Sicherheit, vgl. Odette 2006a.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

195

• Schutzbedarf der auszutauschenden Informationen, • verwendete Systeme und Applikationen, • Ziel(en) der Kooperation, • vorhandene Sicherheitsmaßnahmen und Infrastrukturen, • Anzahl der Kooperationspartner einer Unternehmung und • Anzahl gleichzeitig kooperierender Mitarbeiter. F¨ ur Unternehmungen ist die Planungs- und Erwartungssicherheit bei der Einf¨ uhrung einer L¨osung von großer Bedeutung, da ein h¨aufiger Systemwechsel mit hohen Kosten verbunden ist. Die L¨osungen m¨ ussen entsprechend skalierbar sein (z.B. Anzahl der Nutzer oder Ausweitung des Einsatzes auf andere Dokumente oder Bereiche), die genutzte Hardware effizient nutzen und sollten mit einem geringen Aufwand (Installation, Administration, Wartung etc.) eingef¨ uhrt und betrieben werden k¨onnen. F¨ ur einen unternehmungs¨ ubergreifenden Einsatz ist daher eine branchenweite Standardisierung von L¨osungen w¨ unschenswert, um die Kosten aller Anwender zu senken und die Planungssicherheit zu erh¨ohen.527

5.5 Ans¨ atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes Neben den oben genannten bi- und/oder multilateralen Ans¨atzen zur unternehmungs¨ ubergreifen IT-Sicherheit lassen sich noch weitere L¨osungsm¨oglichkeiten identifizieren. Diese k¨onnen als branchenweites und zum Teil als branchen¨ ubergreifendes Sicherheitskonzept angesehen bzw. genutzt werden. Bilaterale L¨osungen zur Realisierung von IT-Sicherheit sind bei einer steigenden Anzahl von Kooperationspartnern stets problembehaftet, da f¨ ur jeden einzelnen Kooperationspartner eine L¨osung ausgehandelt werden muss. Durch die gemeinsame Nutzung von Standards und L¨osungsans¨atzen lassen sich die Kosten der unternehmungs¨ ubergreifenden IT-Sicherheit signifikant senken. 527 Im Bereich der Standardisierung wird in der Automobilindustrie horizontal und vertikal h¨aufig kooperiert. Beispielhaft sind hier die Herstellerinitiative Software (HIS) und die Automotive Open System Architecture (AUTOSAR) zu nennen, welche eher fahrzeugbezogene Fragestellungen bearbeiten, vgl. http://www.automotive-his.de und http://www.autosar.org. Dar¨ uber hinaus existieren weitere Arbeitskreise, die sich mit Standardisierungsthemen besch¨ aftigen, z.B. innerhalb des VDA, der Odette oder in ISO-Gremien.

196

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Unternehmungs¨ ubergreifende Standards sollten unabh¨angig von Produkten sein, da die Gefahr einer Abh¨angigkeit von dem jeweiligen Anbieter existiert, der durch eine Entscheidung f¨ ur sein Produkt eine Quasi-Monopolstellung erhalten k¨onnte. Daher sollte keine Bindung an ein Produkt stattfinden, sondern stattdessen an einen offenen (m¨oglichst lizenzfreien) Architektur-, Verfahrens- oder Protokollstandard. Verschiedene Anbieter eines L¨osungsansatzes k¨onnen so koexistieren und ggf. konkurrieren.528 Die Konformit¨at zum Standard sollte eingehalten und eine Interoperabilit¨at zwischen den Produkten dadurch garantiert werden. Im Folgenden werden mehrere Gestaltungsans¨atze vorgestellt, die eine Grundlage f¨ ur eine sichere Kooperation bzw. den sicheren Austausch von Daten bilden. Diese sind abstrakter dargestellt, als die bilateralen L¨osungsans¨atze, da eine branchenweite Implementierung der Gestaltungsans¨atze multilateral verhandelt werden muss. Daher k¨onnen hier nur die Grundlagen der Gestaltungsans¨atze mit ihren jeweiligen Vor- und Nachteilen dargestellt werden.

5.5.1 Bestehende Ans¨ atze Es existieren erste Gestaltungsans¨atze, um IT-Sicherheit in Kooperationen und Kollaborationen gew¨ahrleisten zu k¨onnen. Dazu l¨asst sich z.B. auch der Ansatz z¨ahlen, Daten mit digitalen Wasserzeichen (Digital Watermarking) zu markieren. Dieser Ansatz hat jedoch nur einen begrenzten Effekt, da materielle G¨ uter/Produkte, die auf der Basis von ausspionierten Daten erstellt wurden, dieses Wasserzeichen nicht beinhalten.529 Ein digitales Wasserzeichen weist lediglich – verborgen oder offensichtlich – auf den Urheber der Daten hin. Dieser Nachweis kann jedoch einen Vorteil in einer gerichtlichen Auseinandersetzung um die Urheberschaft mit sich bringen, wenn sich in den Konstruktionspl¨anen der Produkte der beklagten Unternehmung entsprechende digitale Wasserzeichen finden lassen. Trusted Computing ist geeignet, um die IT-Sicherheit in Unternehmungen maßgeblich zu verbessern, wenn z.B. nur noch signierte und damit offiziell von einer Unternehmung freigegebene Applikationen genutzt werden k¨onnen. Um dies umfassend in einer Unternehmung zu realisieren, w¨are es erforderlich, dass ein Wechsel auf die entsprechende Hardware erfolgt. Vor dem Hintergrund, dass zur Zeit kaum Hardware existiert, die Trusted Computing unterst¨ utzt, ist dieser L¨osungsansatz derzeit nicht praktikabel. 528 Eine Wettbewerbssituation zwischen Anbietern hinsichtlich Preis und/oder Leistung ist in der Regel vorteilhaft f¨ ur Kunden. 529 Beispielweise Maschinen oder Blechteile.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

197

Im Folgenden werden zwei bestehende Ans¨atze mit ihren Vor- und Nachteilen vorgestellt.

5.5.1.1 PDTnet und OMG PLM Services Im Rahmen des Konsortialprojektes PDTnet (Produktdatentechnologie und Kommunikation im Netzwerk von Automobilhersteller und Zulieferer) der Automobilindustrie wurde in den Jahren 2000 bis 2003 ein Ansatz zum sicheren Austausch von Produktdaten erarbeitet.530 Der Ansatz verbindet die traditionelle“ Netzwerksicherheit, also demilitarisierte ” Zonen (DMZ), Firewalls etc., mit der Verwendung einer rollenorientierten Benutzerverwaltung sowie – je nach Anwendungsfall – der Nutzung des European Network Exchange (ENX) oder einer HTTPS-Transportverschl¨ usselung.531 Ziel ist es, Daten aus dem Produktdatenmanagement (PDM) abzusichern. Innerhalb des Projektes gelten drei Pr¨amissen, die erf¨ ullt sein m¨ ussen, damit das vorgeschlagene System seinen Sicherheitsanspr¨ uchen gerecht wird:532 1. Der Zugang zu den PDM-Systemen muss derart abgesichert sein, dass nur authentisierte Benutzer Zugriff auf Daten erlangen k¨onnen. 2. Der Transport von und zu den Systemen muss derart abgesichert sein, dass Dritte die Daten nicht einsehen k¨onnen. 3. Benutzer sollten nur auf Daten zugreifen k¨onnen, die sie zu ihrer Aufgabenerf¨ ullung ben¨otigen (Need-to-Know-Prinzip). Dabei wird darauf hingewiesen, dass alle Details stark abh¨angig von den zu betrachtenden Szenarien, der Implementation, der Transportmechanismen und der genutzten PDM-Systeme sind. Betrachtet werden im Wesentlichen zwei Anwendungsf¨alle: der dateibasierte Austausch von Daten und die Integration von PDM-Systemen auf der Basis von Internettechnologien.533 F¨ ur die Internetintegration der PDM-Systeme wird ein eigener Web-Client (Browser) zur Verf¨ ugung gestellt. PDTnet ist sehr spezifisch auf die beiden beschriebenen Szenarien angelegt und scheint somit nicht f¨ ur speziellere Anwendungsformen (z.B. synchrone Kollaboration) geeignet zu sein. Auch allgemein verf¨ ugbare Kooperationsformen wie z.B. der Austausch von Daten per E-Mail werden durch diesen Ansatz nicht abgesichert. 530 Product Data Technology in a Network 2003b. 531 Product Data Technology in a Network (PDTnet) 2003a. Das Konzept des European Network Exchange wird in Abschnitt 5.5.3.1 vorgestellt. 532 Vgl. PDTnet 2003a: 5. 533 Vgl. PDTnet 2003c; PDTnet 2003d.

198

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

PDTnet hat sich nicht umfassend als L¨osung in der Automobilindustrie durchsetzen k¨onnen, da es sich nicht um einen offiziellen Standard handelt. Die Product Lifecycle Management (PLM) Services wurden durch eine Arbeitsgruppe des Vereins Pro Standard for the Exchange of Product Model Data, Initiative zur integrierten virtuellen Produktentstehung (ProSTEP iViP) erarbeitet und von der Object Management Group (OMG), einem internationalen Konsortium zur Entwicklung von Standards f¨ ur herstellerunabh¨angige Software, als Standard akzeptiert. Die Services nutzen Extensible Markup Language (XML) Schemata und Webservices, um u ¨ber TCP/IP synchron, asynchron und plattformunabh¨angig kollaborative Entwicklung zu betreiben. Dabei sollen alle relevanten Daten aus dem Produktlebenszyklus u ¨ ber dieses Referenzmodell unternehmungs¨ ubergreifend genutzt werden k¨onnen. Die Version 2.0 der PLM Services soll im Jahr 2006 offiziell verabschiedet werden und u.a. bessere Sicherheitsmechanismen erhalten, z.B. in Kombination mit dem Java Authentication and Authorization Service (JAAS) oder der Security Assertion Markup Language (SAML).534 In der offiziellen Dokumentation des Standards535 wird die IT-Sicherheit nicht explizit behandelt und es bleibt diffus, welche Sicherheitsmechanismen tats¨achlich implementiert worden sind oder werden k¨onnen. ProSTEP iViP stellt in der Projektbeschreibung dar, dass durch die Nutzung von Webbasierten Transportmechanismen die Aspekte der Authentifikation, Autorisierung, Verschl¨ usselung und anderer Sicherheitsanforderungen an bereits vorhandene Technologien und Infrastrukturen delegiert werden k¨onnen.536 Generell sind die OMG PLM Services dazu geeignet, bestimmte Daten aus dem Produktlebenszyklusmanagement auszutauschen. Es w¨are jedoch zu begr¨ ußen, wenn spezielle Dokumente zu potenziellen Sicherheitsanforderungen und deren m¨ogliche Umsetzung existieren w¨ urden.

534 Vgl. PartMaster 2005: 7f. SAML wird ausf¨ uhrlicher in Abschnitt 5.5.2 behandelt. 535 Vgl. ProSTEP iViP 2005. 536 Using a web-based transport mechanism delegates aspects of authentication and authorization as well ” as encryption and other security requirements to already existing technologies and infrastructures.“ ProSTEP iViP 2006.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

199

5.5.1.2 European Bridge Certification Authority Ein zentrales Problem bei Authentifikationsverfahren ist die initiale Registrierung der Benutzer.537 Dies gilt insbesondere bei PKI-Karten, die einen Signaturschl¨ ussel beinhalten, mit welchem Nachrichten digital signiert werden k¨onnen. In Deutschland wird generell unterschieden zwischen:538 1. der elektronischen Signatur (z.B. eingescannte Unterschrift), 2. der fortgeschrittenen elektronischen Signatur, 3. der qualifizierten elektronischen Signatur und 4. der qualifizierten elektronischen Signatur mit Anbieterakkreditierung. Je besser (sicherer) die umgesetzte L¨osung ist, desto gr¨oßer ist die Beweiskraft einer elektronischen Signatur in einem Rechtsstreit.539 Je sicherer die L¨osung sein soll, desto h¨oher sind die Anforderungen an Soft- und Hardware, Infrastruktur und Prozesse. So wird beispielsweise bei der Ausstellung besonders vertrauensw¨ urdiger Zertifikate die ¨ Uberpr¨ ufung von Angaben einer nat¨ urlichen Person verlangt, d.h. die Person, die den Antrag auf ein Zertifikat stellt, muss sich zweifelsfrei identifizieren lassen.540 Elektronische Signaturen werden in Deutschland jedoch nur sehr selten in Unternehmungen und ihren Gesch¨aftst¨atigkeiten eingesetzt.541 Wenn der f¨ ur die Signaturerstellung notwendige kryptografische Schl¨ ussel auf einer Smartcard residiert (PKI-Karte), dann ist es sinnvoll, weitere kryptografische Schl¨ ussel mit spezifiziertem Nutzungsprofil auf dieser Karte unterzubringen. In der Regel wird mindestens einer weiterer kryptografischer Schl¨ ussel zur Ver- und Entschl¨ usselung von Daten auf der Karte untergebracht. Um eine Email f¨ ur einen Empf¨anger zu verschl¨ usseln, wird dessen ¨offentlicher Schl¨ ussel ben¨otigt. Dies ist auch notwendig, wenn die Signatur einer E-Mail u uft werden soll. ¨ berpr¨ In der Regel h¨alt die PKI einer Unternehmung jedoch nur die eigenen Zertfikate und Schl¨ ussel vor. Dies hat zur Folge, dass sich ein Benutzer vor der Verschl¨ usselung einer ¨ E-Mail an Externe oder die Uberpr¨ ufung einer signierten E-Mail von Externen deren ussel bzw. das Zertifikat beschaffen muss. Zu diesem Zweck bestehen ¨offentlichen Schl¨ 537 Bei der initialen Registrierung muss die Identit¨ at der Benutzer einwandfrei festgestellt werden, z.B. durch die Vorlage des Personalausweises. 538 Vgl. BSI 2006a: 8. 539 Die qualifizierte elektronische Signatur mit Anbieterakkreditierung wird vom Gesetzgeber als vertrauensw¨ urdigste L¨osung angesehen. 540 Beispielsweise durch das pers¨ onliche in Empfang nehmen des Zertifikats mit Feststellung der Identit¨at durch Vorlage des Personalausweises. 541 Dies k¨onnte sich ¨andern, wenn z.B. Banken und Kreditinstitute in einer kommenden Generation von Electronic Cash (EC) und/oder Kreditkarten Zertifikate f¨ ur digitale Signaturen integrieren und eine entsprechende Infrastruktur bereitstellen.

200

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Verzeichnisdienste, die Schl¨ ussel und Zertifikate der registrierten Benutzer einer PKI vorhalten. Zus¨atzlich sollten Sperrlisten (Certificate Revocation Lists, CRL) oder Dienste (z.B. Online Certificate Status Protocol, OCSP) zur Verf¨ ugung stehen, die abgelaufene oder zur¨ uckgezogene Zertifikate und Schl¨ ussel auflisten. Der Standard X.509 beschreibt folgende Gr¨ unde f¨ ur eine Sperrung von Zertifikaten:542 • Kompromittierung des Schl¨ ussels, • Kompromittierung der Certification Authorities (CA, Zertifizierungsinstanz), ¨ • Anderung des Inhaltes eines Zertifikats, • obsoletes Zertifikat (neues Zertifikat vorhanden), • ge¨andertes Verh¨altnis zum Zertifikatsinhaber (z.B. K¨ undigung) und • Suspendierung.543 Es besteht die M¨oglichkeit, eine gegenseitige Anerkennung der PKIen und deren RootZertifikaten vorzunehmen. Die daf¨ ur notwendigen bilateralen Verhandlungen sind jedoch in der Regel sehr zeitaufw¨andig, da eine sogenannte Cross-Zertifizierung eine technische L¨osung zum Ausdruck von Vertrauen darstellt und die Erstellung sowie Speicherung von Schl¨ usseln und Zertifikaten hohen Sicherheitsanforderungen gen¨ ugen muss.544 Die European Bridge Certification Authority (Bridge-CA oder auch EB-CA) bietet Organisationen mit eigenst¨andiger PKI eine multilaterale L¨osung an, in dem sie als Bindeglied zwischen den PKIen fungiert.545 Zu diesem Zweck hat sie Rahmenbedingungen f¨ ur eine Interoperabilit¨at zwischen den verschiedenen PKIen entwickelt und stellt Mindestanforderungen an die Teilnehmer u ¨ber ein Certificate Practice Statement (CPS) her. In einer CPS werden der Aufbau, die Prozesse und die weiteren Eigenschaften der PKI beschrieben. 546 Dar¨ uber hinaus wird der Erfahrungsaustausch zwischen den Mitgliedern der Bridge-CA gef¨ordert und Informationen f¨ ur Organisationen, die eine eigene PKI betreiben wollen, bereit gestellt.547 542 Vgl. Schmeh 2001: 306f. 543 Eine Suspendierung ist eine tempor¨ are Sperrung eines Zertifikats. 544 Eine Cross-Zertifizierung kann eingesetzt werden, wenn mehrere Certification Authorities mit inkongruenten Benutzerkreisen miteinander kooperieren. Dabei stellen beide Zertifizierungsinstanzen der jeweils anderen ein Zertifikat aus. Somit werden alle ¨ offentlichen Schl¨ ussel beider CAs von der jeweils anderen Seite beglaubigt. Vgl. Schmeh 2001: 289. 545 Die Bridge-CA ist eine Initiative ohne Gewinnerzielungsabsichten mit Partnern aus der Wirtschaft und der ¨offentlichen Verwaltung. Der organisatorische Betrieb wird von der TeleTrusT e.V. geleistet. Die Deutsche Telekom AG betreibt in ihrem Trustcenter im Auftrag der TeleTrusT die technische L¨osung. 546 Vgl. Chokhani/Ford/Sabett et al. 2003. Innerhalb der CPS existiert eine Certificate Policy, welche selbstverpflichtende Richtlinien der PKI f¨ ur jeden Zertifikatstyp festgelegt. 547 Vgl. TeleTrusT 2003: 3.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

201

Der wesentliche Vorteil einer Mitgliedschaft bei der Bridge-CA besteht darin, dass keine zus¨atzlichen Cross-Zertifizierungen der Teilnehmer untereinander notwendig sind, sondern nur die Anerkennung der Bridge-CA. Zudem wird von der Bridge-CA ein zentraler Verzeichnisdienst angeboten, u usselungs¨ber den die Mitarbeiter der Teilnehmer Verschl¨ zertifikate der Mitarbeiter anderer Teilnehmer erhalten k¨onnen. Zus¨atzlich wird eine CRL und ein OCSP-Dienst angeboten, welche Information u ultigkeit der Zertifikate ¨ ber die G¨ der Teilnehmer liefern. Die Bridge-CA erm¨oglicht damit den Teilnehmern, schnell, transparent und sicher an valide Zertifikatsinformationen zu gelangen. Als Gestaltungsansatz f¨ ur die Absicherung von Kooperationen ist die Bridge-CA nur bedingt geeignet, da sie lediglich eine L¨osung f¨ ur ein kleines Segment der Gesamtproblematik bietet. Da viele kleine und mittelst¨andische Unternehmungen keine eigene PKI besitzen, k¨onnen sie nicht Teilnehmer der Bridge-CA werden. Sie k¨onnen jedoch Zertifikate von solchen zertifizierten Trust Centern erwerben, welche Mitglied in der Bridge-CA sind. In der Praxis nutzen KMU jedoch seltener Secure Multipurpose Internet Mail Extensions (S/MIME), sondern auf Pretty Good Privacy (PGP) basierende Produkte, welche in der Regel nicht von Trust Centern ausgegeben werden. Die Bridge-CA stellt keine eigenst¨andige L¨osung dar, sondern ist vielmehr ein Instrument, um die Problematik der verteilten Zertifikate/PKIen und der Vertrauensstellungen zwischen PKIen zu l¨osen. Der folgende Ansatz kann von der Nutzung dieses Instruments profitieren.

5.5.2 F¨ oderales Identit¨ atsmanagement Um den Begriff des f¨oderalen Identit¨atsmanagement zu erl¨autern, muss zuerst das Identit¨atsmanagement, welches im Allgemeinen nur innerhalb einer Unternehmung realisiert wird, skizziert werden.548 IT-Infrastrukturen in Unternehmungen sind komplexe Systeme, die im Regelfall stark heterogen strukturiert sind. Ein Hauptproblem in großen Unternehmungen ist die Verwaltung der digitalen Identit¨aten (Benutzerkonten im weiteren Sinne) in heterogenen ITInfrastrukturen: Die Berechtigungen der Benutzer f¨ ur den Zugang zu unterschiedlichen Systemen und den Zugriff auf spezifische Daten werden an verschiedenen Stellen in der Unternehmung haupts¨achlich manuell definiert und verwaltet. Als Folge besitzt ein Benutzer im Allgemeinen mehrere digitale Identit¨aten mit verschiedenen Authentifikationsverfahren und/oder -merkmalen (beispielsweise diverse Benutzernamen oder Passw¨orter) und dies erzeugt hohe Betriebskosten in der Benutzer- und Zugriffsrechte-Administration. 548 Die hier dargestellten Aspekte beziehen sich ausschließlich auf die Verwendung der Technologie in Unternehmungen. Zu den soziologischen, technischen und rechtlichen Implikationen der Anwendung des Identit¨atsmanagements auf private Konsumenten siehe Unabh¨ angiges Landeszentrum f¨ ur Datenschutz Schleswig-Holstein/Studio Notarile Genghini 2003.

202

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

In gr¨oßeren, dynamischen Netzwerken l¨asst sich weder garantieren, dass die Konten eines Benutzers beim Ausscheiden aus einer Unternehmung aus allen Systemen gel¨oscht ¨ werden, noch ist ein zuverl¨assiger und schneller Uberblick u ¨ber alle Benutzerkonten und 549 Berechtigungen eines Benutzers verf¨ ugbar. Jede Unternehmung betreibt eine Form des Identit¨atsmanagements. Wird ein neuer Mitarbeiter eingestellt, so muss er sich in der Regel im Vorfeld pers¨onlich identifizieren und unter anderem seine Adressdaten und seine Bankverbindung angeben. Die Daten werden z.B. von der Personalabteilung oder der Lohnbuchhaltung verwendet. In vielen Unternehmungen erh¨alt der neue Mitarbeiter gleichzeitig ein oder mehrere Benutzerkonten f¨ ur IT-Systeme, wenn dies f¨ ur ihn zur Aufgabenerf¨ ullung notwendig ist. Im Verlauf der Besch¨aftigung eines Arbeitnehmers finden im Allgemeinen Ver¨anderungen statt. Ein Mitarbeiter wechselt die Abteilung oder den Standort, erh¨alt neue oder andere Aufgaben bzw. Projekte oder wechselt in eine h¨ohere Hierarchieebene. Nur selten werden in der Praxis zeitgleich mit derartigen Ver¨anderungen die Berechtigungen des Mitarbeiters angepasst. Dies begr¨ undet sich maßgeblich in der mangelnden intraorganisationalen Kommunikation. Zu viele Rechte bzw. verwaiste Benutzerkonten stellen ein gr¨oßeres Sicherheitsrisiko dar.550 Ohne eine prozessorientierte, toolgest¨ utzte Verwaltung von digitalen Identit¨aten ist eine Konsolidierung von Informationen u ber Benutzer und deren Berechtigungen in ¨ Systemen de facto nicht realisierbar. Diese Problematik kann – zumindest unternehmungsintern – im Rahmen eines Identit¨atsund Zugriffsmanagements551 (Identity & Access Management, IAM) gel¨ost werden. Die technisch-organisatorische Grundlage f¨ ur ein IAM stellt ein Rollen- und Rechtemanagement dar. IAM ist dabei der zusammenfassende Begriff f¨ ur Technologien, die den Prozess der Erstellung, Verwaltung, Authentifizierung und Autorisierung von digitalen Identit¨aten unterst¨ utzen und bietet die M¨oglichkeit, Akteure in diesen Prozessen klar zu definieren, Arbeitsabl¨aufe zu automatisieren und Verantwortlichkeiten herzustellen. Dadurch kann die IT-Sicherheit der Systeme und Services signifikant verbessert werden. Im idealen Fall stellt ein IAM eine unternehmungsweite Integration aller digitalen Identit¨aten eines Systemverbunds mit der Anbindung aller Zugangs- und Zugriffskontrollen dar. Die digitalen Identit¨aten werden u ¨ber ihren gesamten Lebenszyklus verwaltet. Dies beinhaltet u.a. Identit¨atserstellung und -pflege, Berechtigungs- und Richtlinienverwaltung sowie Zugangs- und Zugriffsverwaltung. Zur Definition und Umsetzung eines einheitlichen Rollen- und Rechtemanagements wird in der Regel ein rollenbasiertes Zugriffsmanagement (Role Based 549 Eine Vielzahl von Passw¨ ortern pro Benutzer f¨ uhrt h¨ aufig zu einer st¨arkeren Inanspruchnahme des Helpdesks/der Administratoren, da vergessene Passw¨ orter zur¨ uckgesetzt werden m¨ ussen. 550 Vgl. Doekmetas 2005: 80. ¨ 551 Eigentlich handelt es sich um ein Identit¨ ats-, Zugangs- und Zugriffsmanagement. Die Ubersetzung als Identit¨ats- und Zugriffsmanagement hat sich jedoch durchgesetzt.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

203

Access Control, RBAC) genutzt.552 In einem solchen Modell werden Benutzern Rollen zugeordnet, welche wiederum mit Berechtigungen assoziiert werden k¨onnen. Die Definition der Rollen wird u ¨ber die verschiedenen organisatorischen Funktionsbereiche einer Unternehmung vorgenommen und die Benutzer erhalten z.B. je nach Position, T¨atigkeit, Qualifizierung und/oder Verantwortung eine oder mehrere entsprechende Rollen zugeteilt.553 Dabei enth¨alt eine Rolle nur die Berechtigungen, die f¨ ur die Erf¨ ullung einer bestimmten Funktion oder T¨atigkeit erforderlich sind (Need-to-Know-Prinzip).554 In einer optimalen Ausbaustufe existieren determinierte Ablaufpl¨ane (Workflows) und eine oder mehrere Datenbank(en), in denen die Rollen und Rechte definiert und den Benutzern zugeordnet werden. Die Ablaufpl¨ane k¨onnen z.B. vorsehen, dass mit der Eintragung eines neuen Mitarbeiters in die Systeme der Personalverwaltung diesem Mitarbeiter automatisch ein Benutzerkonto mit den entsprechenden Rollen zugewiesen und in einer zentralen Datenbank (als sog. Meta-Directory)555 eingetragen wird. Nachfolgend werden alle anderen Systeme mit den notwendigen Informationen (Zugangs- und Zugriffsrechte) provisioniert. Durch den zentralistischen Ansatz werden Redundanzen und Inkonsistenzen, die in verteilten Systemen h¨aufig zu finden sind, vermieden.556 Der Einsatz eines IAM kann dazu f¨ uhren, dass die digitalen Identit¨aten eines Benutzers schneller und gezielter administriert werden k¨onnen. Dadurch, dass Benutzer rasch die Berechtigung auf ben¨otigte Ressourcen erhalten, k¨onnen Produktivit¨atsvorteile realisiert werden.557 H¨aufig wird ein IAM eingef¨ uhrt, um ein Single Sign On (SSO) zu nutzen, die Kosten bei der Verwaltung von Benutzerkonten zu senken und den Grad an IT-Sicherheit zu erh¨ohen.558 Ein IAM kann z.B., wie in Abb. 5.6 exemplarisch dargestellt, realisiert werden. Die Definition von Rollen ist ein komplexer und komplizierter Abschnitt in der Konzeption eines IAM.559 Die Anzahl der Rollen und Berechtigungen muss gezielt und sorgf¨altig definiert werden. Zu viele Rollen erh¨ohen den administrativen Aufwand, w¨ahrend zu wenige 552 Vgl. Bochum/Stiel 2001: 78. Die ersten Grundlagen des RBAC-Konzeptes wurden im Jahr 1992 vorgestellt, vgl. Ferraiolo/Kuhn 1992. 553 Vgl. Sandhu/Coyne/Feinstein/Youman 1996: 38. Rollen k¨ onnten z.B. Leiter der Dieselmotorenentwicklung, Mitarbeiter Beschaffung (Abteilung Interieur, Unterabteilung Verkleidungsteile) oder Mitarbeiter in der F&E (Abteilung Entwicklung A-Klasse, Unterabteilung Plattformmanagement) sein. 554 Vgl. Sergl 2001: 47. 555 Vgl. Hommel/Reiser 2005: 65. 556 Vgl. Bochum/Stiel 2001: 78. 557 Vgl. Doekmetas 2005: 80. 558 Single-Sign-On verbindet die Authentifizierung an einem Netzwerk (Zugangskontrolle) mit der Autorisierung an den Zielsystemen (Zugriffskontrolle) des Benutzers, vgl. Stiel 2005: 21. Dies bedeutet, dass ein Benutzer sich nur an einem System bzw. Netzwerk authentisieren muss, um Zugang zu allen System bzw. Zugriff auf alle Daten zu erhalten, zu denen er eine Berechtigung besitzt. 559 Vgl. IT-Research 2004: 8.

S1 S1

SAP SAP

S2 S2

SAP SAP HR HR

S3 S3

AD AD

S4 S4

TAM TAM

S5 S5

RACF RACF

S6 S6

... ...

Unix Unix Linux Linux

Authentifizierungsschicht

AutorisierungsSn schicht Sn

LDAP LDAP

Zugriffsmanagement (Portale & Applikationen)

Zugangsmanagement

Anlegen von Rollen und Berechtigungen, Globale ID

Benutzerverwaltungsschicht

Anlegen von Personen

User/Identity Management System User/Identity Management System

Personenverwaltungsschicht

Herausfiltern relevanter Informationen, Zuordnung PKI-Zertifikat

LieferantenLieferantendatenbanken datenbanken

Personenkonsolidierungsschicht

... ...

Aufgabe

Meta-Directory Meta-Directory

Importeure / Importeure / Händler Händler

Schicht

204 5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Abbildung 5.6: Exemplarische Darstellung eines Identity and Access Managements u ¨ber die gesamte interne IT-Infrastruktur einer Unternehmung

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

205

ein Sicherheitsproblem darstellen k¨onnen. Das Benutzermanagement sollte nicht die bestehenden Rollen aus allen Subsystemen, Funktionsebenen oder T¨atigkeiten in der Unternehmung replizieren, sondern vielmehr auf abstrakter Ebene abbilden. Die Rollendefinition und das Rollenmanagement muss prim¨ar aus der Gesch¨aftsprozess- und nicht aus der Technologieperspektive erfolgen; dennoch m¨ ussen technologische Aspekte betrachtet werden. Die Rollen und deren inh¨arente Berechtigungen m¨ ussen an die Zielsysteme provisioniert und in diesen abgebildet werden. Dies erfordert ggf. eine Umgestaltung/Anpassung aller betroffenen Zielsysteme und Anwendungen. Der wesentliche Vorteil dieser L¨osung ist, dass nicht wie bisher jeder Benutzer samt seiner Benutzerkonten separat administriert werden muss, sondern die Zugangs- und Zugriffsberechtigungen nur in den Rollen, welche den Benutzern zugeordnet werden, definiert werden. Zudem erhalten Benutzer nur die Rechte, die sie zur Erf¨ ullung ihrer Aufgaben ben¨otigen und die Rollen und Rechte bilden h¨aufig die hierarchische Struktur einer Unternehmung ab. Dies erh¨oht die Transparenz einer solchen L¨osung.560 Ein zentrales Benutzerverwaltungssystem561 l¨asst sich einfacher und kosteng¨ unstiger skalieren als verschiedene einzelne Systeme und reduziert die Komplexit¨at und Redundanzen sowohl in der Administration als auch in den Anwendungssystemen.562 Zentrale Systeme bergen jedoch auch Risiken, da sie einen Single Point of Failure darstellen k¨onnen. Die Verf¨ ugbarkeit eines derartigen Systems ist dabei in der Regel zu vernachl¨assigen. Ein Ausfall des Systems h¨atte lediglich zur Folge, dass Benutzer keine neuen Rollen und Rollen keine anderen Rechte zugewiesen bekommen bzw. ihnen diese nicht entzogen werden k¨onnen. Ein Angreifer, der das System erfolgreich infiltriert, hat die Kontrolle u ¨ber die Vergabe aller Rollen und Rechte, das heißt, er kann theoretisch allen Benutzern die Rollen und Rechte entziehen bzw. sich selbst Rollen und Rechte f¨ ur alle angeschlossenen Systeme zuweisen. Daher muss ein solches System besonders gegen Angriffe gesch¨ utzt werden, z.B. durch H¨artung des Servers oder Verschl¨ usselung der Datenbanken, Intrusion Detection Systeme, Firewalls, Application Level Gateways, MAC-Adressen-Filterung etc.. In unternehmungs¨ ubergreifenden Kooperationen m¨ ussen die Partner des ¨ofteren auf Systeme zugreifen, die sich im Hoheitsbereich des jeweiligen Partners oder an anderen Standorten befinden. Zudem w¨achst die IT-Infrastruktur der Unternehmung h¨aufig u ¨ber die Unternehmungsgrenzen hinaus, z.B. durch Outsourcing, die Nutzung von (Application) Service Providern, Kooperationen oder Kollaborationen. In solchen Konstellationen ist das Management von Zugangs- und Zugriffsberechtigungen besonders dann schwierig, 560 Vgl. Sergl 2001: 47. 561 Im vorliegenden Zusammenhang wird auch die Nutzung einer zentralen Datenbank als ein Benutzerverwaltungssystem bzw. dessen zentraler Bestandteil angesehen. Dies beinhaltet auch die Nutzung von Verzeichnis- oder Meta-Directory-Diensten. 562 Vgl. NIST 2002a.

206

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

wenn eine gr¨oßere Anzahl von Personen, die der Unternehmung nicht pers¨onlich bekannt sind, Zugang zu Systemen ben¨otigt und/oder diese nicht in unmittelbarer Umgebung der Unternehmung t¨atig sind. Externe, die in Kooperationen auf IT-Systeme und deren Daten zugreifen m¨ ussen, sind im Allgemeinen der Unternehmung nicht zwingend pers¨onlich bekannt. Ihre Identit¨at und ihre Vertrauensw¨ urdigkeit sind f¨ ur den Kooperationspartner als Black Box anzusehen; dennoch ben¨otigen derartige Externe ein Benutzerkonto bzw. eine Zugangsberechtigung, um auf die Daten und Systeme des Kooperationsprojektes zuzugreifen. Wenn der Mitarbeiter der Partnerunternehmung aus diesem ausscheidet oder mit anderen Projekten/Aufgaben betreut wird, dann m¨ ussen nicht mehr ben¨otigte Benutzerkonten bzw. deren Berechtigungen sowohl beim Arbeitgeber, als auch auch bei dem Kooperationspartner deaktiviert werden. Prozesse in der Unternehmung k¨onnen sicherstellen, dass die Personalabteilung das Ausscheiden eines Mitarbeiters (z.B. aus einem Projekt, einer Abteilung oder Unternehmung) an die zust¨andige IT-Abteilung kommuniziert und das Benutzerkonto stillgelegt wird. Es ist jedoch – insbesondere in großen Unternehmungen – sehr unwahrscheinlich, dass das Ausscheiden des Mitarbeiters zeitnah an die entsprechenden Kooperationspartner kommuniziert wird und die Konten dort ebenfalls deaktiviert werden. In der Regel werden derartige Ver¨anderungen weder in der eigenen Unternehmung, noch mit den betroffenen Kooperationspartner kommuniziert. Teilweise wird ein gewisser Umfang an Administrationsrechten auf Anwendungen oder Informationen an die Partnerunternehmung delegiert und von dieser selbst¨andig verwaltet (sog. delegierte Administration).563 F¨ ur den Fall, dass die Kooperationspartner jeweils ein IAM nutzen und sich gegenseitig vertrauen, k¨onnen die Systeme konnektiert werden und im Identit¨atsmanagement kooperieren. Dieses Verfahren wird als f¨oderales Identit¨atsmanagement (Federated Identity Management, FIM) bezeichnet.564 Das IAM der Partner fungiert dabei als ein sogenannter Identit¨atsprovider (Identity Provider ). Jeder Partner ist f¨ ur das Identit¨atsmanagement seiner Benutzer (Erfassung der Daten, Provisionierung der Systeme, Management der Benutzerkonten, Rollendefinitionen, Rechtemanagement etc.) selbst verantwortlich. Dadurch entfallen die Kosten f¨ ur das Management von Benutzerkonten der Mitarbeiter des Kooperationspartners, da jede Unternehmung seine Benutzerkonten eigenst¨andig pflegt. Die Kooperationspartner m¨ ussen nicht notwendigerweise ein eigenes IAM betreiben, sondern k¨onnen diese Leistungen ebenso extern, von Identit¨atsprovidern, beziehen. Ein essenzielles Merkmal f¨ ur die Auswahl eines Identit¨atsproviders ist dessen Vertrauensw¨ urdigkeit. Diese muss konsistent und m¨oglichst authentisch legitimiert sein, damit sie von Dritten (z.B. dem Kooperationspartner) anerkannt werden kann.565 Der Diensteanbieter (Service Provider, also der Applikationsbetreiber bzw. die Unterneh563 Vgl. Petersen 2005: 3. 564 Vgl. Hommel/Reiser 2005: 66. 565 F¨ ur derartige Vertrauensbeziehungen ist eine vertragliche Basis zwingend notwendig.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

207

mung, welche notwendige Daten oder Dienste vorhalten) muss ebenfalls nicht zwingend prim¨arer Bestandteil der Kooperation sein. Es ist m¨oglich, dass die Applikation oder Datenhaltung von Dritten betrieben wird. In der F&E der Automobilindustrie ist es jedoch nur selten der Fall, dass der Service Provider nicht genuiner Bestandteil der Kooperation ist, da die Automobilhersteller und -zulieferer in der Regel eher restriktiv mit dem Zugang zu ihrem Know-how verfahren. In der Abb. 5.7 wird exemplarisch ein FIM zwischen zwei Unternehmungen dargestellt. Die Menge der teilnehmenden Unternehmungen ist nicht begrenzt. Anwender aus Unternehmung A k¨onnen gleichfalls – wenn gew¨ unscht – individuell auf Systeme, Applikationen und Daten der Unternehmung B zugreifen. Eine weitere Gestaltungsoption besteht darin, dass jede Sicherheitszone (Security Domain) in der Unternehmung einen eigenen F¨oderationsserver bzw. -dienst betreibt. Unternehmung A

Unternehmung B

App App App

App

App Sicherheitszone 1 (z.B. Citrix)

Föderationsserver

Sicherheitszone 2 (z.B. SAP)

App App

App

App

App Sicherheitszone 3 (z.B. Windows) App App

Sicherheitszone x

Föderationsserver

Abbildung 5.7: FIM zwischen zwei Unternehmungen (in Anlehnung an Harding 2005: 7) Ein FIM bietet in der EDV-basierten Zusammenarbeit zwischen zwei oder mehreren Unternehmungen u.a. folgende Vorteile:566 • reduzierter Verwaltungs- und Administrationsaufwand, • Erf¨ ullung gesetzlicher Vorgaben (Compliance),567 • erh¨ohte Sicherheit durch Provisionierung von Identit¨aten, • st¨arkere Orientierung des Datenaustausches an Gesch¨aftsabl¨aufen und -risiken, • Skalierbarkeit, 566 Vgl. u.a. Donaldson 2006: 4; Petersen 2005: 9. 567 Die jeweiligen F¨oderationsserver lassen sich an unterschiedliche gesetzliche Vorgaben, z.B. Datenschutz, anpassen.

208

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

• Vermeidung redundanter Datenhaltung und inkonsistenter Informationen, • h¨ohere Produktivit¨at (beschleunigte Bereitstellung von Zugangs- und Zugriffsberechtigungen) und • erh¨ohte Akzeptanz beim Anwender durch SSO. Ein weiterer Vorteil kann entstehen, wenn sich viele Hersteller und Zulieferer auf eine Architektur bzw. interoperable Formate einigen. Dadurch werden Kosten in der Integration und Anpassung gesenkt und die Wahrscheinlichkeit einer hohen Penetration bzw. Nutzung gesteigert. Das Vertrauensverh¨altnis von Unternehmungen ist ein zentrales Element in dem f¨oderalen Identit¨atsmanagement. Der Grad an Vertrauen zwischen den Partnern bestimmt den potenziellen Nutzen von FIM. Dabei ist es vor allem eine organisatorische Herausforderung, vertrauensbildende Maßnahmen zu etablieren, wie in der Abb. 5.8 verdeutlicht wird.

Gemeinsame Sicherheitspolitik

Sicherheit

Technische Absicherung

PKI Tokenaustausch

Verträge

Geschäftsbeziehung

Organisatorischer und technischer Aufwand

Audit Akkreditierung

Vertrauen

Abbildung 5.8: Zusammenhang zwischen Sicherheit, Vertrauen und Aufwand (in Anlehnung an Burton Group)

Je sch¨ utzensw¨ urdiger die auszutauschenden Informationen sind, desto mehr Aufwand muss betrieben werden, um das notwendige Vertrauen des Kooperationspartners zu er-

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

209

langen.568 FIM ist nicht dazu geeignet, Vertrauen zu generieren – es dient lediglich der Kommunikation von bereits etabliertem Vertrauen.569 Im Wesentlichen existieren drei Ans¨atze f¨ ur FIM. Ein Ansatz wurde von der Liberty Alliance entwickelt, ein weiterer basiert auf der Security Assertion Markup Language (SAML) und der dritte (Web Services Federation Language) wurde von einem Konsortium aus IBM und Microsoft entwickelt.570 Die Auswahl eines Ansatzes h¨angt im Wesentlichen von den Anforderungen, Zielen und technischen Voraussetzungen der beteiligten Parteien ab. Als Standard setzt sich zunehmend die SAML durch, welche von der Organization for the Advancement of Structured Information Standards (OASIS) normiert wird.571 Dieses Set von Spezifikationen beschreibt Sicherheitsaussagen (SAML Assertion, Authentifikations- und Autorisierungsinformationen), die in der Extensible Markup Language (XML) kodiert werden. Des Weiteren sind Profile, die diese Sicherheitsaussagen mit diversen Protokollen und Rahmenwerken (Frameworks) verkn¨ upfen, Challenge/ResponseProtokolle zum Erlangen einer Sicherheitsaussage sowie die Bindung dieser Protokolle an verschiedene Transferprotokolle, wie z.B. SOAP (ehemals Service Oriented Architecture Protocol) oder HTTP, definiert.572 Die Sicherheitsaussagen werden von einer SAML Authority produziert und betreffen die Authentifizierung eines Subjektes, Attributsinformationen u ¨ber das Subjekt und/oder Authentifizierungsinformationen des Subjektes in Bezug auf spezifische Ressourcen.573 Um Informationen vor Spionage und Manipulation zu sch¨ utzen, lassen sich diese verschl¨ usseln und/oder signieren. Unternehmungen k¨onnten hier die Dienstleistungen der Bridge-CA in Anspruch nehmen, um eine Interoperabilit¨at von Zertifikaten zu erreichen und gemeinsame CRLs oder OCSP-Dienste zu nutzen. Dadurch wird der langwierige Prozess mehrerer Cross-Zertifizierungen vermieden. Aus einer spezifischeren Perspektive l¨asst sich unterscheiden zwischen einem f¨oderalen Identit¨atsmanagement f¨ ur Web-Applikationen und einem f¨oderalen Identit¨atsmanagement f¨ ur Web Services. Aus Sicht des Nutzers ist lediglich eine einmalige Authentisierung pro Arbeitssitzung notwendig, d.h. es entf¨allt die Authentisierung an weiteren Systemen oder Applikationen. Abbildung 5.9 stellt die Benutzerauthentisierung in Web-Applikationen mit und ohne f¨oderalem Identit¨atsmanagement gegen¨ uber.

568 Vgl. Petersen 2005: 7. 569 Vgl. Elliott/Norlin/McKenna et al. 2004: 15. 570 Vgl. Hommel/Reiser 2005: 66. IBM ist 2004 der Liberty Alliance beigetreten, vgl. Wilkens 2004. 571 Vgl. Hommel/Reiser 2005: 70. 572 Vgl. OASIS 2005a: 10. 573 Vgl. OASIS 2005a: 5. Ausf¨ uhrlich zur Sicherheit von SAML vgl. OASIS 2005.

210

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Mit föderalem Identitätsmanagement

Ohne föderales Identitätsmanagement Benutzerauthentifikation

Benutzerauthentifikation

Token A

Token A

Bereich A

Bereich A

Vertrauen

Benutzerauthentifikation

Token B

Benutzer Single Sign On

Bereich B

SAML Assertion

Token B Bereich B

Abbildung 5.9: FIM f¨ ur Web-Applikationen (vgl. Harding 2005: 6) Web Services k¨onnen ebenfalls mit FIM genutzt werden und gewinnen dabei an Sicherheit. Mittels Web Services Security (WSS) der OASIS k¨onnen SAML Assertions, Kerberos Tickets, Benutzername/Passwort oder X.509-Zertifikate an die von Web-Services genutzten SOAP-Nachrichten gebunden werden und so deren Sicherheit gegen Manipulation oder Spionage erh¨ohen.574 Deshalb l¨asst sich – analog zur Benutzerauthentisierung in Web-Applikationen – FIM auch f¨ ur Web Services abbilden (vgl. Abb. 5.10).

Ohne föderales Identitätsmanagement

Token A

Token A

BenutzerBereich A authentifikation

Token B

Token B

Benutzer- Bereich B authentifikation Vertrauen

Mit föderalem Identitätsmanagement

Token A

Token A BenutzerBereich A

authentifikation

Benutzer SSO Token B

SAML Assertion

Bereich B

Abbildung 5.10: FIM f¨ ur Web Services (vgl. Harding 2005: 7) Durch die Verwendung von Token besteht die M¨oglichkeit, Rechte auf Anwendungen anhand von Regeln dynamisch zu generieren. Das Token beinhaltet jene Informationen, die u ¨ber die Akzeptanz oder Ablehnung eines Zugangs bzw. Zugriffs entscheiden. 574 Vgl. Donaldson 2006: 8.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

211

Als wesentlicher Vorteil eines FIMs gilt, dass ausschließlich der Identit¨atsprovider die Authentifizierung des Benutzers u ¨bernimmt, w¨ahrend der Diensteanbieter entscheidet, ob der Benutzer Zugang zu Netzwerken oder Systemen erh¨alt und auf welche Daten der Benutzer zugreifen kann.575 Dadurch besitzt jeder Diensteanbieter die volle Kontrolle u ¨ber die Vergabe von Rechten auf jede seiner Ressourcen. Daraus ergeben sich mehrere Vorteile:576 • Die Verwaltung der Identity Daten obliegt dem jeweiligen Identit¨atsprovider. Dadurch entfallen Kosten bei dem Diensteanbieter. • Wenn ein Mitarbeiter aus der Unternehmung ausscheidet, wird sein Benutzerkonto bei seinem Identit¨atsprovider gesperrt, gel¨oscht oder ge¨andert, wodurch der Zugriff auf Daten eines Diensteanbieters nicht mehr m¨oglich ist.577 • Der Diensteanbieter kann Rechte dynamisch w¨ahrend der Laufzeit generieren oder ¨andern. • Es k¨onnen Policys kodiert werden, die eine Einhaltung von bestimmten Regeln (Compliance, z.B. Einhaltung von lokalen Datenschutzbestimmungen) forcieren. • Identit¨atsprovider k¨onnen durch eine schnelle Bereitstellung von Ressourcen und SSO die Produktivit¨at der Benutzer erh¨ohen. Der Erfolg des Gestaltungsansatzes eines f¨oderalen Identit¨atsmanagements ist im Wesentlichen von drei Faktoren abh¨angig. Es m¨ ussen gen¨ ugend Unternehmungen als Identit¨atsprovider agieren oder Identit¨atsprovider nutzen. Des Weiteren m¨ ussen Diensteanbieter existieren, die mit den entsprechenden Identit¨atsprovider kooperieren. Der letzte und essenziellste Faktor ist, dass sich alle Beteiligten auf interoperable Standards und Formate einigen. Ohne eine kollektive technische Basis kann sich die Integration von Unternehmungen in ein f¨oderales Identit¨atsmanagement sehr kosten- und zeitintensiv gestalten und somit die Akzeptanz und den Nutzen eines FIMs erheblich einschr¨anken. Der Ansatz eines f¨oderalen Identit¨atsmanagement ist wesentlich weiter gefasst als z.B. der Ansatz der OMG PLM Services, da sich letzterer auf Daten aus dem Produktlebenszyklusmanagement konzentriert und FIM universell f¨ ur nahezu alle Daten und Systeme einsetzbar ist. 575 Es sei denn, der Diensteanbieter hat diese Aufgabe an den Identit¨atsprovider delegiert. 576 Vgl. Petersen 2005: 8. 577 Durch die Einbeziehung der Personalverwaltungssysteme k¨ onnen solche Abl¨aufe automatisiert werden.

212

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

5.5.3 Weitere Gestaltungsans¨ atze Es existieren weitere Gestaltungsans¨atze zur IT-Sicherheit in Kooperationen und Kollaborationen, die – wie der erste Ansatz der geschlossenen Benutzergruppen“ – einen ” Grundschutz gew¨ahrleisten k¨onnen oder – wie der zweite Ansatz einer DRM-L¨osung f¨ ur die Automobilindustrie – nicht f¨ ur alle Einsatzszenarien geeignet sind. 5.5.3.1 Geschlossene Benutzergruppen Geschlossene Benutzergruppen bieten den Vorteil, dass sie nicht Bestandteil ¨offentlicher Netzwerke sind, d.h. dass Angreifer Mitglied dieses Kommunikationsverbundes sein m¨ ussen, wenn sie Daten ausspionieren, manipulieren oder sabotieren wollen. Eine M¨oglichkeit geschlossene Benutzergruppen zu bilden, ist die Anmietung bzw. Nutzung von exklusiven Datenleitungen. Nachteilig an dieser L¨osung ist, dass mit steigender Anzahl der Kommunikationspartner eine Vielzahl von Verbindungen/Datenleitungen entsteht, da es sich um 1-zu-1-Verbindungen handelt (vgl. Abb. 5.11). OEM B OEM A

OEM C

Zulieferer 4

Zulieferer 1 Zulieferer 2

Zulieferer 3

Abbildung 5.11: Kommunikationsbeziehungen u ¨ber exklusive Datenleitungen Die Anzahl der Verbindungen l¨asst sich stark reduzieren, wenn ein zentraler Knotenpunkt die Verbindungen verwaltet. Dadurch entsteht jeweils nur eine Verbindung pro Teilnehmer zum zentralen Knotenpunkt, der die Daten an den gew¨ unschten Zielort weiterleitet (vgl. Abb. 5.12). Das European Network Exchange (ENX) u ¨ bernimmt eine derartige Verwaltungsfunktion. Das ENX ist eine Koalition der europ¨aischen Automobilindustrie, bestehend aus Automobilherstellern, Zulieferern und Verb¨anden, die ein Kommunikationsnetzwerk als Alternative zum Internet und angemieteten Standleitungen bieten.578 Dadurch kann die Dauer 578 Entsprechende Zusammenschl¨ usse existieren f¨ ur Nord-Amerika (ANX), Australien (AANX), Japan

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

OEM A

OEM B

213

OEM C

Gateway / Router

Zulieferer 1

Zulieferer 2

Zulieferer 3

Zulieferer 4

Abbildung 5.12: Kommunikationsbeziehungen u ¨ber exklusive Datenleitungen und Router/Gateway (vereinfachte Darstellung) zur Einrichtung einer sicheren Verbindung zwischen Kommunikationspartnern signifikant gesenkt werden, da Verhandlungsprozesse und Informationsdefizite zur IT-Sicherheit entfallen. Prinzipiell handelt es sich dabei um einen geschlossenen Kommunikationsverbund, an dem nur teilnehmende Unternehmungen partizipieren k¨onnen. Dabei sollen feste Bandbreiten, die Authentizit¨at der Partner und ein sicherer Datenaustausch gew¨ahrleistet werden.579 Grunds¨atzlich k¨onnen nur Unternehmungen aus der Automobilindustrie und ihre Partner einen Zugang zum ENX beantragen.580 Der Antrag muss zuerst an den jeweiligen nationalen Verband der Automobilindustrie (z.B. VDA) gerichtet werden. Nach einer Zustimmung des Verbandes erfolgt die eigentliche Registrierung beim zust¨andigen Dienstleister (Certified Service Provider, CSP).581 Aus technischer Perspektive handelt es sich bei ENX um ein IP-Netzwerk als VPN auf Basis von IPSec als Netzwerk-zu-Netzwerk-Verbindung. Die entsprechenden X.509v3Zertifikate werden von Trust Centern geliefert. Die Daten werden u ¨ber Leitungen aus¨ gew¨ahlter Telekommunikations- bzw. Service Provider u ¨bertragen.582 Als Ubertragungs(JNX) und Korea (KNX). Zuk¨ unftig sollen dies Teilnetzwerke des Global Network Exchange (GNX) sein, u ¨ ber den sich die Teilnehmer weltweit austauschen k¨onnen. Zur Zeit ist dies jedoch noch nicht m¨oglich. 579 Vgl. auch im Folgenden Product Data Technology in a Network 2003: 6ff. 580 Die Teilnehmer im ENX werden als Trading Partner (TP) bezeichnet. 581 Ein Großteil der CAD-Daten wird per ODETTE File Transfer Protocol (OFTP) haupts¨ achlich u ¨ ber ISDN bzw. X.25 u ¨ bermittelt. Mittlerweile l¨asst sich OFTP auch u ¨ ber TCP/IP und damit u ¨ber ENX nutzen. 582 In Deutschland ist dies die Deutsche Telekom AG bzw. T-Systems.

214

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

technologien k¨onnen Asynchronous Transfer Mode (ATM), Frame-Relay, Integrated Services Digital Network (ISDN) und Digital Subscriber Line (DSL) genutzt werden.583 Durch die Nutzung von IPSec k¨onnen Authentizit¨at, Integrit¨at und Vertraulichkeit garantiert werden und der Einsatz von Routern (mit Zertifikaten) gew¨ahrleistet, dass die Datenpakete f¨ ur die Applikationen und Systeme hinter dem Router/Gateway transparent sind. Der Router f¨ ur den Zugang zum ENX wird vollst¨andig vom Service Provider administriert. Die Clients der teilnehmenden Unternehmung ben¨otigen eine ENX-IP-Adresse, welche durch eine dynamische Network Address Translation (NAT) oder einen Proxy konfiguriert werden kann. Im Routing muss f¨ ur jeden neuen Kooperationspartner bzw. f¨ ur jeden neuen Tunnel im ENX eine neue Route gesetzt werden. Der Austausch von Daten mit einem Kommunikationspartner muss von beiden Partnern einmalig f¨ ur die Kommunikationsverbindung zwischen zwei Routern beim Service Provider beantragt und von diesem freigeschaltet werden. Es existieren keine Spezifikationen oder Sicherheitsanforderungen f¨ ur die Teilnehmer.584 Daraus ergeben sich mehrere potenzielle Gef¨ahrdungen f¨ ur die Sicherheit des ENX und der angeschlossenen Teilnehmer, wenn keine unternehmungsinternen Sicherheitsmaßnahmen vorhanden sind. Im Allgemeinen ist ein Client nicht nur am ENX angeschlossen, sondern weist auch einen Zugang zum Internet auf. Falls ein Client mit einem Trojaner infiziert ist und u ¨ ber das interne Unternehmungsnetzwerk sowohl Zugang zum Internet als auch zum ENX besitzt, kann ein Angreifer u ¨ ber das Internet auf den Client und von dort aus u ¨ber das ENX auf andere ENX-Teilnehmer zugreifen. Daher ist es unerl¨asslich, dass die Infrastruktur der Unternehmung zumindest Basisanforderungen an die IT-Sicherheit erf¨ ullt, wenn der Client simultan sowohl mit dem ENX als auch mit dem Internet verbunden ist. Dazu geh¨oren ein mehrstufiges Firewallkonzept mit eingeschr¨ankten Kommunikationsbeziehungen585 sowie die Nutzung von Standardprotokollen und -ports (z.B. nur HTTP u ¨ber die Ports 80 und 443). Server, die u ¨ ber ENX angesprochen werden, sollten in ein Extranetz in einer DMZ ausgegliedert werden und per statischem NAT von der Firewall eine ENX-IP-Adresse erhalten. Zus¨atzlich sollten nur die ben¨otigten Ports erreichbar sein. Es ist seitens ENX sicherzustellen, dass der Zugang zum ENX nur befugten Personen (entsprechende Mitarbeiter der Zulieferer und OEMs) erteilt wird. Ebenso m¨ ussen die Teilnehmer sicherstellen, dass nur befugte Personen Zutritt und Zugang zu den angeschlossenen Clients bzw. Netzwerken erhalten. Das Konzept ist nur gegen Angriffe von Externen auf dem Transportweg gesichert. Falls ein oder mehrere teilnehmende Clients 583 Es sind sowohl W¨ahlverbindungen als auch Standleitungen im Portfolio enthalten. 584 Die IT-Sicherheit liegt, laut Aussage von ENX, in der Verantwortung der Unternehmung, welche ENX nutzt. Jedoch sollen die Service Provider den Trading Partnern Unterst¨ utzung in dem Bereich Firewalls (Auswahl Hard- und Software, Installation, Konfiguration, Management) anbieten. 585 Denkbar w¨are hier, dass nur der Proxy aus einer DMZ Zugang zum Internet bietet.

5.5 Ans¨atze zur Gestaltung eines branchenweiten Sicherheitskonzeptes

215

kompromittiert sind, ist jeder Kommunikationspartner des Clients ein potenzielles Opfer von Spionage, Sabotage oder Manipulation. Prinzipiell sind geschlossene Benutzergruppen in Verbindung mit einer Transportverschl¨ usselung und einer starken Client- bzw. Benutzerauthentifikation (mindestens ZweiFaktor-Authentifikation) dazu geeignet, Kooperationen und/oder Kollaborationen in Datennetzwerken zu sch¨ utzen. Es ist jedoch sicherzustellen, dass das interne Netzwerk der Unternehmung bzw. die angeschlossenen Clients gegen Angriffe gesch¨ utzt sind. Ein großer Vorteil von ENX ist die Interoperabilit¨at, da nicht alle Ger¨ate, die IPSec verwenden, zueinander kompatibel sind. Im ENX d¨ urfen nur getestete und zugelassene IPSec-f¨ahige Router verwendet werden. Es kann als weiterer Vorteil angesehen werden, dass die Konfiguration des Routers vom zust¨andigen Service Provider vorgenommen wird, da dies potenzielle Gef¨ahrdungen durch fehlerhafte Konfigurationen minimiert. ENX wird in Abh¨angigkeit von bestimmten Anwendungsf¨allen genutzt. Dies bedeutet, dass ENX in bestimmten Szenarien im Allgemeinen nicht genutzt wird, z.B. f¨ ur die Kommunikation per E-Mail. 5.5.3.2 Automotive DRM Ein weiterer Gestaltungsansatz ist die Nutzung eines Digital Rights Managements f¨ ur die Automobilindustrie. Dieser Ansatz folgt der in Abschnitt 5.3.3 auf Seite 187ff. vorgestellten L¨osung. Die auszutauschenden Daten werden u ¨ber die genutzte Applikation respektive das genutzte System f¨ ur die angegebenen Empf¨anger bzw. Benutzer verschl¨ usselt und mit spezifischen Nutzungsrechten versehen. Dergestalt kann, aufgrund der Datenverschl¨ usselung, auf eine Transportverschl¨ usselung verzichtet werden. Der Umfang einer DRM-basierenden L¨osung ist stark anbieterabh¨angig. Dies betrifft sowohl den Umfang an verf¨ ugbaren Konnektoren zu Applikationen und Systemen, als auch den Umfang an Funktionen. Daher kann u.a. keine generelle Aussage zu einer funktionsf¨ahigen synchronen Kollaboration in Echtzeit getroffen werden.586 Asynchrone Kollaboration wird jedoch von allen L¨osungen unterst¨ utzt, da dies eine Grundfunktionalit¨at f¨ ur DRM-Systeme im Unternehmungsumfeld darstellt. Eines der Hauptprobleme dieses Ansatzes besteht darin, dass nur Applikationen und Systeme genutzt werden k¨onnen, in denen sich eine DRM-Komponente integrieren l¨asst. Vor dem Hintergrund des Ansatzes der Digitalen Fabrik, welcher eine durchg¨angige digitale Verarbeitung von Daten vorsieht, ist entweder eine Entfernung der Daten aus dem DRMContainer oder ein perfekt strukturiertes Rechtemanagement notwendig. Insbesondere letzteres ist den komplexen Zusammenh¨angen der Automobilentwicklung und -produktion 586 Dem Verfasser sind keine L¨ osungen bekannt, die dies unterst¨ utzen w¨ urden.

216

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

nur schwierig zu realisieren. Ein zweites Hauptproblem besteht in der Tatsache, dass Benutzer in der Regel ihre Arbeitsgewohnheiten nur widerwillig aufgeben. Ein durchg¨angiges DRM erfordert eine genaue Kenntnis dar¨ uber, wer der Empf¨anger oder Nutzer der Informationen sein wird. Dar¨ uber hinaus ist ein weiterer Arbeitschritt notwendig, da eben diese Kenntnis u ¨ber den Empf¨anger der Information in den DRM-Datencontainer einfließen muss, damit dieser die Daten nutzen kann und dies wird vom Sender manuell verwaltet.587 Zudem kann der Autor/Absender nicht nachvollziehen, in welcher Weise sich der Empf¨anger authentisiert hat. Einer Authentifikation mittels Benutzernamen und Passwort muss weniger Vertrauen entgegen gebracht werden als einer Authentifikation mittels Besitz und Wissen. Die notwendigen Lizenzserver, die das Rechtemanagement verwalten, sollten sich in der Hoheit der jeweiligen Unternehmung befinden, welches die Daten/Informationen zur Verf¨ ugung stellt. Die Einf¨ uhrung und der Betrieb eines DRMs ist von hoher Komplexit¨at gepr¨agt und scheint daher nur f¨ ur klar abgrenzbare Einsatzszenarien geeignet zu sein. Darunter fallen geheime Informationen, die nur einem kleinen Nutzerkreis zur Verf¨ ugung gestellt werden sollen – beispielsweise Dokumente zur Unternehmensstrategie auf Vorstandsebene. Aufgrund der fehlenden einheitlichen (und vor allem frei verf¨ ugbaren) Standards im Bereich DRM existieren im Verein Pro Standard for the Exchange of Product Model Data, ¨ Initiative zur integrierten virtuellen Produktentstehung (ProSTEP iViP) Uberlegungen, ein entsprechendes Projekt zu etablieren.

5.6 Fazit Die hier vorgestellten Konzepte sind prinzipiell dazu geeignet, spezifische IT-Sicherheitsprobleme in unternehmens¨ ubergreifenden Kooperationen zu l¨osen. Keiner der Gestaltungsans¨atze ist jedoch geeignet, um allen Problemen der Absicherung von Informationen in vertikalen F&E-Kooperationen zu begegnen. Die Ans¨atze sind als potenzielle Bestandteile einer u ¨bergeordneten Sicherheitsstrategie zu verstehen, welche in einem definierten Umfang die Sicherheit von Informationen gew¨ahrleisten k¨onnen. Welcher Gestaltungsansatz gew¨ahlt wird, ist von einer solchen Anforderungs- und Risikoanalyse und dem daraus resultierenden Maß an Schutzbedarfen der Informationen abh¨angig.588 Dar¨ uber hinaus m¨ ussen die Systeme, Prozesse und Applikationen f¨ ur den 587 Es existiert generell die Option, Benutzergruppen als Sender/Empf¨anger einzurichten. Dies kann jedoch dazu f¨ uhren, dass viele Benutzer zu viele Rechte erhalten. 588 Siehe auch Abschnitt 5.4, Seite 194.

5.6 Fazit

217

gew¨ahlten Technologieansatz geeignet sein. Eine DRM-Plattform in Kombination mit einer starken Authentifikation und FIM sowie der Bridge-CA scheint vordergr¨ undig ein guter Ansatz f¨ ur einen nahezu allumfassenden Schutz des Informationsaustausches in Kooperationen. Der wesentliche Nachteil an dieser L¨osung ist ihre Komplexit¨at. Es w¨aren ¨ wesentliche Anderungen an den Applikationen und Systemen erforderlich und die Benutzer m¨ ussten ihre Arbeitsweise erheblich umstellen. Zudem existiert f¨ ur DRM kein geeigneter offener Standard und DRM-L¨osungen sind in der Regel nicht interoperabel, so dass die L¨osung eines Anbieters genutzt werden muss.589 Da umfangreiche Investitionen f¨ ur die Implementierung eines derartigen L¨osungsansatzes notwendig sind, steht vor allem die Zukunfts- und Anpassungsf¨ahigkeit der Investitionsentscheidung f¨ ur einen Ansatz im Fokus. Ebenso sind geringe Folgekosten, z.B. in Support, Wartung oder Betrieb, von Interesse f¨ ur die Unternehmungen. Die Ausgestaltung des Ansatzes sollte sich an Service-orientierten Architekturen (SOA), standardisierten Komponenten und offenen Web-konformen Basisarchitekuren orientieren, sie sollte Prozesse abbilden k¨onnen, plattformunabh¨angig, skalierbar, interoperabel und gegen Angriffe resistent sein.590 Diese Anforderungen stellen den Einsatz eines DRM-Systems in den dargestellten Zusammenh¨angen in Frage. Ein aussichtsreicher Ansatz f¨ ur eine unternehmungs¨ ubergreifende L¨osung ist das f¨oderale Identit¨atsmanagement im Verbund mit der Bridge-CA, einer Transportverschl¨ usselung und digitaler Signierung der Nachrichten. Dieser Ansatz ist sowohl geeignet, die internen Kosten zu senken, als auch, den Schutz von Informationen zu gew¨ahrleisten. Dies setzt voraus, dass alle Kooperationspartner ein gewisses Sicherheitsniveau vorweisen k¨onnen. Eine potenzielle Schwachstelle aller Ans¨atze ist die Sicherheit des internen Unternehmungsnetzwerks und der daran angeschlossenen Clients und Server. Ohne einen funktionsf¨ahigen – und m¨oglichst l¨ uckenlosen – Schutz der IT-Infrastruktur der Unternehmungen sind nahezu alle Gestaltungsans¨atze kompromittierbar. Die Zertifizierung der IT-Sicherheit u ¨ber ein ISO 27001-Zertifikat ist eine geeignete Methode zur Gew¨ahrleistung der Vertraulichkeit, Integrit¨at und Verf¨ ugbarkeit in Unternehmungen. Die Anwender m¨ ussen zudem bez¨ uglich der IT-Sicherheit entsprechend geschult werden, da der Faktor Mensch zu den gr¨oßten Gef¨ahrdungen der Schutzziele der IT-Sicherheit z¨ahlt. Auf dieser Grundlage k¨onnen die vorgestellten Gestaltungsans¨atze ihre volle Wirkung entfalten. 589 Es existiert zwar ein korrespondierendes Open-Source-Projekt namens Open Intellectual Property Management and Protection (OpenIPMP), welches jedoch auf Audio- und Videoinhalte fixiert ist. 590 Vgl. Gottwald 2006. Diese Anforderungen entsprechen denen f¨ ur die n¨achste Generation von Enterprise Resource Planning Systemen, sind jedoch auf andere Systeme, Architekturen und L¨osungsans¨atze u ¨ bertragbar. Die Ausgestaltung eines Ansatzes ist aktuellen Trends unterworfen und die skizzierten generellen Anforderungen stehen zur Zeit im Fokus vieler IT-Gestaltungsans¨atze, L¨osungen und Implementierungen.

218

5 Gestaltungsans¨atze f¨ ur IT-Sicherheit in vertikalen F&E-Kooperationen

Es lassen sich die folgenden grundlegenden Elemente der IT-Sicherheit in unternehmungs¨ ubergreifenden Kooperationen und Kollaborationen identifizieren: • Jeder Teilnehmer hat f¨ ur die Gew¨ahrleistung der eigenen unternehmungsinternen IT-Sicherheit zu sorgen. – Ein ISMS ist mit Unterst¨ utzung des Managements einzurichten. – Eine Sensibilisierung der Anwender ist hinsichtlich technischer, organisatorischer und auch sozialer“ 591 IT-Sicherheitsbelange vorzunehmen. ” – Es sollten stets starke Authentifikationsmechanismen zum Einsatz kommen (mindestens Besitz und Wissen). – Die Netzwerkinfrastruktur ist mit geeigneten Maßnahmen (Firewalls, IDS/IPS, Content-Scanner, ACLs, DMZ, etc.) vor unbefugtem Zugang und Zugriff zu sch¨ utzen. – Die Clients und die Server sind vor unbefugtem Zugang und Zugriff zu sch¨ utzen (H¨artung der Server, Antivirus-Konzept, Personal Firewalls, Abschalten nicht ben¨otigter Dienste, Passwortrichtlinien, etc.) – Gew¨ahrleistung der physischen“ IT-Sicherheit (Schließsysteme, Zutritts¨ uber” wachung, BMZ, EMZ, Gasl¨oschanlagen, etc.). – Das Need-to-know-Prinzip sollte stets Anwendung finden. – Eine periodische Auditierung und kontinuierliche Weiterentwicklung der ITSicherheit ist zwingend erforderlich. • Es ist ein generisches Rahmenwerk notwendig, mit welchem Sicherheitanforderungen an Applikationen, Systeme und Prozesse im Rahmen des Risikomanagements einfach gestellt und u uft werden k¨onnen.592 ¨ berpr¨ • Grunds¨atzlich sollten alle Gestaltungsans¨atze eine Daten- oder Transportverschl¨ usselung vorsehen.593 • Eingesetzte Protokolle, Methoden, Verfahren und kryptografischen Schl¨ ussel sollten sicher, nicht kompromittiert und fehlerfrei implementiert sein. • Eine Verbindung mit Netzwerken anderer Unternehmungen sollte nur unter Auflagen erfolgen bzw. technisch und/oder organisatorisch entsprechend abgesichert werden. • Synchrone Kooperation oder Kollaboration sollte stets Server-basiert erfolgen. 591 Als Maßnahme gegen Social Engineering. 592 Beispielsweise in Form von Checklisten. 593 F¨ ur die lokale Datenhaltung gilt, dass die Notwendigkeit der Verschl¨ usselung der Datenablagen umso dringlicher ist, wenn das eigene Netzwerk als unsicher angesehen wird.

5.6 Fazit

219

• E-Mails mit vertraulichem oder geheimem Inhalt sollten stets verschl¨ usselt werden. Eine Transportverschl¨ usselung der E-Mails kann u ¨ber SSL oder Simple Mail Transfer Protocol (SMTP) zwischen den Mailservern oder Gateways erfolgen. Es w¨are f¨ ur alle Beteiligten von Vorteil, wenn die Mailserver oder Gateways mit Zertifikaten arbeiten w¨ urden, um eine Absenderauthentifizierung vornehmen zu k¨onnen. Wenn die 20 gr¨oßten Unternehmungen in der Automobilindustrie in Deutschland ihre Mailserver/Gateways auf ein derartiges Verfahren umstellen w¨ urden, dann k¨onnte ein signifikanter Anteil der E-Mailkommunikation zwischen OEMs und Zulieferern vor Spionage und Manipulation auf dem Transportweg durch das Internet gesch¨ utzt werden. Die Kosten in der Implementierung und in dem Betrieb sind f¨ ur ein derartiges Verfahren, verglichen mit der fl¨achendeckenden Ende-zu-Ende E-Mailverschl¨ usselung, gering. Unternehmungs¨ ubergreifende bzw. branchenweite Standards sind dazu geeignet, die Kosten aller Beteiligten zu senken, da keine bilateralen Verhandlungen notwendig sind. Zudem sinkt das Risiko von Sunk Costs, da die Wahrscheinlichkeit von fehlerhaften Investitionsentscheidungen geringer ist, wenn sich die Entscheidung an allgemein akzeptierten Standards orientiert. Es existieren verschiedene Beweggr¨ unde, warum Unternehmungen eine Einf¨ uhrung der beschriebenen Ans¨atze ablehnen, verhindern oder verz¨ogern. Da sich die IT sowohl innerhalb der Unternehmungen als auch aus der unternehmungs¨ ubergreifenden Perspektive als sehr heterogen darstellt, wird ein gemeinsamer Ansatz auf wesentliche H¨ urden in der Implementierung stoßen. Die Kosten f¨ ur eine branchenweite Umsetzung sind jedoch das gr¨oßte Hindernis f¨ ur eine Verbreitung eines Ansatzes. Ein weiterer Faktor ist die inhomogene Risikowahrnehmung in Großunternehmungen und KMU. Die Politik, Verb¨ande und Gewerkschaften k¨onnten eine Multiplikatorenrolle einnehmen und die Verbreitung der IT-Sicherheit propagieren und f¨ordern. Dar¨ uber hinaus sollten L¨osungsans¨atze, die in der Automobilindustrie unternehmungs¨ ubergreifende oder branchenweite Bedeutung aufweisen, in nationale und internationale Standardisierungsprozesse (z.B. ISO) eingegliedert werden. Mit der Entscheidung des Arbeitskreises Integraler Informationsschutz mit IT-Sicherheit, ” Prototypenschutz und Risk-Management“ des VDA, den BS 7799 bzw. die ISO 27001 als branchenweiten Standard zu akzeptieren, ist ein erster Schritt in die richtige Richtung erfolgt.

6 Schlussbetrachtung und Ausblick Die Informationstechnik hat die F&E und die Logistik der Automobilindustrie substanziell beeinflusst. Wesentliche Prozesse, die die Entwicklung und Produktion von Kraftfahrzeugen maßgeblich beschleunigt haben, w¨aren ohne den Einsatz von IT unm¨oglich oder ineffizient. Dasselbe gilt ebenso f¨ ur die vielf¨altige Nutzung von ¨offentlichen Netzwerken, welche neue Optimierungspotenziale in Leistungserstellungs- und Leistungsaustauschprozessen erschlossen haben. Diese fundamentalen Ver¨anderungen haben jedoch zur Folge, dass Daten in Unternehmungen bedeutend schneller und einfacher von Dritten eingesehen oder manipuliert werden k¨onnen. Hieraus ergibt sich die Notwendigkeit, Prozesse gegen Spionage, Sabotage und Manipulation zu sch¨ utzen. Es ist Aufgabe der IT-Sicherheit die Vertraulichkeit, Integrit¨at und Verf¨ ugbarkeit von Daten in Unternehmungen zu gew¨ahrleisten. Die Bedeutung der unternehmungs¨ ubergreifenden IT-Sicherheit w¨achst mit der Zunahme der interorganisationalen Zusammenarbeit. Noch vor wenigen Jahren bedeutete ITSicherheit in erster Linie die Absicherung der Unternehmungsgrenzen gegen¨ uber Angreifern. Diese Form der IT-Sicherheit wird h¨aufig als Perimeter Security bezeichnet. Es wurde in den letzten Jahren h¨aufig das Ende der Perimeter-Sicherheit beschworen, da diese Form der Verteidigung gegen Angriffe von außen nicht den aktuellen Anforderungen an die IT-Sicherheit entspricht.594 Sie ist zur Zeit immer noch von Bedeutung – es sind jedoch neue Konzepte notwendig, um dem Ph¨anomen des Extended Enterprise zu begegnen. Die bisherigen Konzepte sind isoliert nur bedingt geeignet, um unternehmungs¨ ubergreifende Kooperationen und Kollaborationen abzusichern. Technologien und L¨osungsans¨atze, wie VPNs, SSL, Leased Lines etc., k¨onnen zwar bilaterale Kooperationen absichern, sind aber nur einzelne Elemente eines notwendigen, umfassenden Rahmenwerkes zur Sicherung von Unternehmungswerten durch die IT-Sicherheit. Im Einzelfall ist eine Anforderungs- und Risikoanalyse f¨ ur die bestehenden Zusammenh¨ange zu erstellen. In den vorliegenden Zusammenh¨angen der Automobilindustrie wird eine derartige Analyse durch die heterogenen IT-Infrastrukturen und -Applikationen erschwert. Standards sind prinzipiell dazu geeignet, heterogene Strukturen zu konsolidieren und Kosten zu senken. Zur Zeit existiert kein allgemeing¨ ultig akzeptierter Standard, 594 Perimeter Security ist bei unternehmungs¨ ubergreifenden Prozessen nur bedingt geeignet.

222

6 Schlussbetrachtung und Ausblick

der in der Lage w¨are, den Datenaustausch in Kooperationen in allen erdenklichen Szenarien vor Angriffen effizient zu sch¨ utzen.595 Die in Abschnitt 5.5 dargestellten Ans¨atze – vor allem das f¨oderale Identit¨atsmanagement – sind prinzipiell dazu geeignet, unternehmungs¨ ubergreifende IT-Sicherheit zu erm¨oglichen. Eine der gr¨oßten Gef¨ahrdungen f¨ ur die IT-Sicherheit in Unternehmungsnetzwerken und Kooperationen stellen der Client und sein Benutzer dar. Transportverschl¨ usselungen sind nicht wirkungsvoll, wenn ein Client kompromittiert und von einem Angreifer beispielsweise mit einem Trojaner ausgestattet wurde. Es fehlen daher umsetzungsf¨ahige Konzepte, die Clients wirkungsvoll sch¨ utzen k¨onnen. Die Ans¨atze aus dem Bereich Trusted Computing sind zwar vielversprechend, weisen aber noch einige Defizite im Einsatz in der Praxis auf. Da der Markt solche L¨osungen fordert, kann davon ausgegangen werden, dass funktionsf¨ahige L¨osungen in wenigen Jahren zur Verf¨ ugung stehen. Obwohl mittlerweile selbst die Tagespresse u ¨ ber die Gef¨ahrdungen durch Malware – z.B. in E-Mails – berichtet, ¨offnen Anwender weltweit E-Mailanh¨ange oder Software aus unbekannten Quellen und gef¨ahrden damit ihren Client-PC in der Unternehmung und alle anderen konnektierten Systeme. Die Situation wird voraussichtlich vor allem dann weiter eskalieren, wenn immer mehr individualisierte Malware an spezifische Zielunternehmungen, -systeme und -personen gerichtet wird. Da f¨ ur individuelle Malware keine Signaturen f¨ ur Virenscanner existieren, werden andere Maßnahmen notwendig werden, um z.B. Industriespionage abzuwehren. Verantwortliche in der IT-Sicherheit m¨ ussen die Grenzen und Schwachstellen ihrer Konzepte kennen. Kein Konzept kann wirkungsvoll die Weitergabe von Informationen durch Innent¨ater verhindern. Es existieren Applikationen/Systeme, die in der Lage sind, den Transfer von Informationen auf externe Medien (z.B. Ausdruck, USB-Sticks, externe Festplatten, CD/DVD etc.) zu u ¨berwachen oder, wie DRM-Systeme, die Erstellung eines Bildschirmfotos durch das Betriebssystem oder eine Applikation (Screenshot) zu verhindern. Doch auch diese Maßnahmen verhindern nicht, dass Innent¨ater die Informationen vom Bildschirm exzerpieren oder aus dem Ged¨achtnis rekapitulieren. Umso wichtiger erscheint in diesem Zusammenhang die Loyalit¨at der Mitarbeiter. Die IT-Sicherheit ist nur so stark, wie das schw¨achste Glied in ihrer Kette. In der Zusammenarbeit u ¨ ber die Grenzen einer Unternehmung hinaus erh¨alt diese Aussage eine besondere Bedeutung: Jede Unternehmung, die Teil einer elektronisch gest¨ utzten Wertsch¨opfungskette ist, muss die Sicherheit ihrer Daten und Systeme gew¨ahrleisten k¨onnen, damit Spionage, Manipulation und Sabotage verhindert oder zumindest erschwert werden. Das geeignetste Mittel zur Wahrung der Schutzziele der IT-Sicherheit ist die 595 Die breite Implementierung eines potenziellen zuk¨ unftigen Standards wird einige Jahre ben¨otigen, da die Kosten einer solchen Implementierung generell ein großes Hindernis darstellen.

6 Schlussbetrachtung und Ausblick

223

Etablierung und Aufrechterhaltung eines ISMS in jeder Unternehmung. Es bleibt zu hoffen, dass die ISO 27001-Familie denselben Stellenwert einnehmen wird, wie die ISO 9000-Familie und damit eine weitgehende Verbreitung erf¨ahrt. Die Automobilindustrie sollte in Kooperation mit staatlichen Stellen daf¨ ur Sorge tragen, dass die Entwicklung von offenen Standards im Bereich IT-Sicherheit vorangetrieben wird. Haupts¨achlich betrifft dies den Bereich DRM, welcher besonders dazu geeignet ist, geheime Inhalte zu sch¨ utzen. Das f¨oderale Identit¨atsmanagement profitiert von offenen Standards und Interoperabilit¨at. Durch eine kostenlose Bereitstellung bestimmter Komponenten f¨ ur Zulieferer und andere OEMs kann die Marktpenetration und damit der Nutzen f¨ ur alle Beteiligten erheblich gesteigert werden. Weiterer Forschungsbedarf ist bez¨ uglich des Wissens um die Zusammenh¨ange von interorganisationalem Vertrauen und IT-Sicherheit notwendig. Insbesondere die Frage, wie Vertrauen etabliert werden kann und welche technischen L¨osungen dieses Vertrauen abbilden oder begr¨ unden k¨onnen, ist noch nicht umfassend erforscht worden. Hier werden interdisziplin¨are Forschungsans¨atze ben¨otigt, die geeignet sind, Methoden und Erkenntnisse – u.a. aus Psychologie, Soziologie, Informatik, Wirtschaftswissenschaft und Ingenieurwissenschaft – miteinander zu kombinieren. Eine weitere Forschungsl¨ ucke zeigt sich in der ¨okonomischen Analyse der IT-Sicherheit: Ohne eine statistisch valide Datenbasis wird eine ¨okonomische Kosten-Nutzen-Analyse von IT-Sicherheitsmaßnahmen nur bedingt m¨oglich sein. Es ist jedoch nicht zu erwarten, dass Unternehmungen in Zukunft (empirische) Informationen u ¨ber ihren Datenverkehr oder erfolgreiche bzw. missgl¨ uckte Angriffe auf die Datensicherheit zur Verf¨ ugung stellen werden. Dadurch wird eine Analyse der Kosten und des Nutzens von IT-Sicherheit ex-ante als Unterst¨ utzung f¨ ur eine Investitionsentscheidung kaum m¨oglich. Insbesondere in diesen Zusammenh¨angen ist weiterer Forschungsbedarf vorhanden. Die potenziellen L¨osungsans¨atze m¨ ussen den Bed¨ urfnissen der Praxis gerecht werden und z.B. die Interdependenzen von IT-Schutzmaßnahmen ber¨ ucksichtigen. Des Weiteren sollten die f¨ unf Parameter der Risikoanalyse (Wert, Gef¨ahrdung, Schwachstelle, Schaden und Maßnahme) abgebildet werden. Funktionsf¨ahige und aussagekr¨aftige Modelle w¨aren in der Lage, die Analyse und Steuerung der IT-Sicherheit in Unternehmungen zu revolutionieren. Ein solches Modell w¨ urde es Unternehmungen erstmals erlauben, die Kosten und den Nutzen der IT-Sicherheit fundiert darzustellen und dabei zuk¨ unftige Entwicklungen zu ber¨ ucksichtigen. ¨ Die Aufgabe weiterer wissenschaftlicher Forschung ist die empirische Uberpr¨ ufung der in Abschnitt 5.6 auf Seite 218f. formulierten grundlegenden Elemente der IT-Sicherheit in unternehmungs¨ ubergreifenden Kooperationen und Kollaborationen. Eine empirische Analyse kann diese Elemente als Thesen nutzen und die Zusammenh¨ange und Gesetzm¨aßig-

224

6 Schlussbetrachtung und Ausblick

keiten deduktiv u ufen. Die Ergebnisse k¨onnten wesentlich zum weiteren Ausbau der ¨ berpr¨ Theoriebildung bez¨ uglich der IT-Sicherheit in und zwischen Unternehmungen beitragen.

Literaturverzeichnis Abend, Jens M. (1992): Strukturwandel in der Automobilindustrie und strategische Optionen mittelst¨andischer Zulieferer. Eine explorative Studie. VVF: M¨ unchen, zugl. Diss., Universit¨at Augsburg. Abramovici, M.; Gerhard, D.; Langenberg, L. (1998): Unterst¨ utzung verteilter Entwicklungsprozesse durch EDM/PDM, in: Verein Deutscher Ingenieure (VDI) (Hrsg.): Prozessketten f¨ ur die virtuelle Produktentwicklung in verteilter Umgebung, VDI Berichte 1435, D¨ usseldorf: VDI Verlag, S. 69-86. Achtert, Werner (2004): Die Quality Factory, in: IT Management 1/2004, S. 72-77. Adams, Manfred; Oligschl¨ager, Josef; Schenkelberg, Hermann et al. (1993): Wirtschaftsrechnen Industrie. 4. Aufl., K¨oln: Stam. Adelsbach, Andr´e; Greveler, Ulrich (2005): Satellite Communication without Privacy Attacker’s Paradise, GI Fachtagung ’Sicherheit 2005’, 5.-8. April 2005, Regensburg. Adolphs, Britta (1997): Stabile und effiziente Gesch¨aftsbeziehungen. Eine Betrachtung von vertikalen Koordinationsstrukturen in der deutschen Automobilindustrie. Josef Eul Verlag: K¨oln, zugl. Diss., Universit¨at M¨ unster. Arbeitsgemeinschaft f¨ ur Sicherheit der Wirtschaft e.V. (2003): Anmerkungen zur Sicherheitslage der deutschen Wirtschaft 2002/2003, http://www.asw-online.de/ asw_lage.doc am 02.01.2004. Arnold, Ulli (1997): Beschaffungsmanagement. 2. Auflage, Stuttgart: Sch¨affer-Poeschel. Ashby, W. Ross (1956): An Introduction to Cybernetics. London: Chapman & Hall. Atzberger, Alexander; Kassner, Sven; Malorny, Christian; et al. (2001): Automobil: auf dem Weg zu einer neuen Rollenverteilung, http://www.mckinsey.

226

Literaturverzeichnis

de/_downloads/kompetenz/bbp/DT_NTV_AUTOMOBILINDUSTRIE.PDF 02.11.2004.

am

Baker, Michael J. (Hrsg.) (2003): The Marketing Book, 5th edition, Oxford: Butterworth/Heinemann. Baseler Ausschuss f¨ ur Bankenaufsicht (2003): Die Neue Baseler Eigenkapitalvereinba¨ rung. Konsultationspapier, Ubersetzung der Deutschen Bundesbank, http:// www.kpmg.de/topics/5387.htm am 22.09.2004. Beattie, Steve; Arnold, Seth; Cowan, Crispin et al. (2002): Timing the Application of Security Patches for Optimal Uptime. Proceedings of LISA 2002, 16th Systems Administration Conference, 3.-8. November, Philadelphia/PA, S. 101-110. Bechtold, Stefan (2002): Vom Urheber- zum Informationsrecht. Implikationen des Digital Rights Management, M¨ unchen: CH Beck. Beck, Ulrich (1986): Risikogesellschaft. Auf dem Weg in eine andere Moderne, Frankfurt am Main: Suhrkamp. Beger, Rudolf; G¨artner, Hans-Dieter; Mathes, Rainer (1989): Unternehmenskommunikation. Grundlagen, Strategien, Instrumente, Frankfurt am Main: Gabler. Behlmer, Arne (2001): Gutes Rating ist teuer, in: Automobil-Industrie 7-8/2001, S. 2632. Behlmer, Arne (2003): Ab in die Mitte, in: Automobil-Industrie 10/2003, S. 32-36. Behlmer, Arne; Kiefer, Thomas (2003): Dunkle Gesch¨afte, in: Automobil-Industrie 10/2003, S. 42-43. Behrens, Michael; Roth, Richard (Hrsg.) (2001): Biometrische Identifikation. Grundlagen, Verfahren, Perspektiven, Wiesbaden: Vieweg. Behrens, Michael; Roth, Richard (2001a): Grundlagen und Perspektiven der biometrischen Identifikation, in: Behrens, Michael; Roth, Richard (Hrsg.): Biometrische Identifikation, Wiesbaden: Vieweg, S. 8-26. Bekanntmachung der Kommission (2001): Leitlinien zur Anwendbarkeit von Artikel 81 EG-Vertrag auf Vereinbarungen u ¨ber horizontale Zusammenarbeit,

Literaturverzeichnis

227

2001/C 3/02. In: Amtsblatt der Europ¨aischen Gemeinschaften, C 3, Jg. 44, 6.01.2001, S. 2-30, http://europa.eu.int/eur-lex/de/archive/2001/c_ 00320010106de.html am 24.04.03. Berinato, Scott (2002): Finally, a Real Return on Security Spending, in: CIO 4/2002, http://www.cio.com/archive/021502/security.html am 13.08.2004. Bernhard, Martin G. (2003): Das Projektmodell: Service-Level-Agreements und die notwendigen Prozesse einf¨ uhren, in: Bernhard, Martin G.; Mann, Hartmut; Lewandowski, Winfried et al. (Hrsg.): Praxishandbuch Service-Level-Management, D¨ usseldorf: Symposion Publishing, S. 203-262. Bernhard, Martin G.; Mann, Hartmut; Lewandowski, Winfried et al. (Hrsg.) (2003): Praxishandbuch Service-Level-Management. Die IT als Dienstleistung organisieren, D¨ usseldorf: Symposion Publishing. Bierschenk, Sabine (2004): Aus digitalen Wurzeln w¨achst die Fabrik der Zukunft, in: VDI nachrichten 24/2004, S. 25. Bitzenhofer, Torsten H. (1996): Single System Sourcing - Potentiale und Risiken, in: IOManagement 6/1996, Jg. 65, S. 68-70. Bliesener, Max-Michael (1994): Outsourcing als m¨ogliche Strategie zur Kostensenkung, in: Betriebswirtschaftliche Forschung und Praxis 4/1994, S. 277-289. Bloch, Michael; Pigneur, Yves (1995): The Extended Enterprise. A Descriptive Framework, Some Enabling Technologies and Case Studies in the Lotus Notes Environment, http://www.hec.unil.ch/yp/Pub/PAPER_EE/PAPER_EE.HTM am 26.07.2005. Bl¨ocker, Antje (2001): Reorganisationsmuster von Forschung und Entwicklung in der Automobilindustrie am Beispiel von BMW, Mercedes-Benz und Volkswagen. Ein Beitrag zum Wandel von Innovationssystemen, Aachen: Shaker, zugl. Diss., Technische Universit¨at Braunschweig. Bochum, Udo; Stiel, Hadi (2001): Meta Directory als Sicherheitsstrategie, in: kes 6/2001, S. 78ff.

228

Literaturverzeichnis

Bort, Julie (2003): Extended Enterprises Take Root, in: Network World 2003, http://www.networkworld.com/ee/2003/eeopen.html vom 17.02.2003 am 11.02.2005. Bortz, J¨ urgen (1993): Statistik f¨ ur Sozialwissenschaftler, 4. Aufl., Berlin; Heidelberg; New York; London; Paris; Tokyo; Hong Kong; Barcelona; Budapest: Springer. Briney, Andrew; Prince, Frank (2002): Does Size Matter? in: Information Security 9/2002, S. 36-54. Bruhn, Manfred (1995): Internes Marketing als Forschungsgebiet der Marketingwissenschaft. Eine Einf¨ uhrung in die theoretischen und praktischen Probleme, in: Bruhn, Manfred (Hrsg.): Internes Marketing, Wiesbaden: Gabler, S. 13-61. Bruhn, Manfred (Hrsg.) (1995a): Internes Marketing. Integration der Kunden- und Mitarbeiterorientierung, Wiesbaden: Gabler. Bruhn, Manfred (1998): Interne Kommunikation, in: Meyer, Anton (Hrsg.): Handbuch Dienstleistungsmarketing, Stuttgart: Sch¨affer-Poeschel, S. 1045-1062. Bruhn, Manfred (Hrsg.) (1999): Internes Marketing. Integration der Kunden- und Mitarbeiterorientierung, 2. Aufl., Wiesbaden: Gabler. Bruhn, Manfred (2001): Qualit¨atsmanagement f¨ ur Dienstleistungen. Grundlagen, Konzepte, Methoden, 3. Aufl., Berlin; Heidelberg; New York; Barcelona; Hongkong; London; Mailand; Paris; Tokio: Springer. Bruhn, Manfred (2002): Integrierte Kundenorientierung. Implementierung einer kundenorientierten Unternehmensf¨ uhrung, Wiesbaden: Gabler. Bruhn, Manfred (2003): Kommunikationspolitik. Systematischer Einsatz der Kommunikation f¨ ur Unternehmen, 2. Aufl., M¨ unchen: Vahlen. Bruhn, Manfred (2003a): Kundenorientierung. Bausteine eines exzellenten Unternehmens, M¨ unchen: DTB. B¨ ukow, Oliver (2003): Risikokontrolle beim Outsourcing, in: kes 4/2003, S. 71ff. Bullinger, Hans-J¨org; Meitner, Helmut (1994): Ohne Information l¨auft nichts, in: Gablers Magazin 3/1994, S. 14-17.

Literaturverzeichnis

229

Bund, Martina (2000): F&E-Outsourcing. Planung - Kontrolle - Integration. Wiesbaden: Deutscher Universit¨ats-Verlag. Bundesamt f¨ ur Sicherheit in der Informationstechnik (Hrsg.) (2003): Kommunikationsund Informationstechnik 2010+3. Neue Trends und Entwicklungen in Technologie, Anwendungen und Sicherheit, Bonn: SecuMedia. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2004): Risikoanalyse auf Basis von IT-Grundschutz, Version 1.0, http://www.bsi.de/gshb/risikoanalyse/ risiko.pdf am 08.08.2005 bzw. BSI-Standard 100-3, http://www.bsi.de/ literat/bsi_standard/standard_1003.pdf am 15.02.2006. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2004a): Studie zu ISONormungsaktivit¨aten ISO/BPM. Vergleich der Audit- und Zertifizierungsschemata f¨ ur IT-Grundschutz und BS 7799-2, http://www.bsi.bund.de/literat/ studien/gshb/ISO-BPM-ISMS_040305.pdf am 08.12.2005. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2005): IT-Grundschutzhandbuch, http://www.bsi.de/gshb/index.htm am 02.08.2005. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2005a): Untersuchung der Leis¨ tungsf¨ahigkeit von biometrischen Verifikationssystemen - BioP II. Offentlicher Abschlussbericht, Bonn, http://www.bsi.bund.de/literat/studien/ biop/biopabschluss2.pdf am 23.11.2005. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2005b): Managementsysteme f¨ ur Informationssicherheit (ISMS), BSI-Standard 100-1, Version 1.0, Dezember 2005, http://www.bsi.de/literat/bsi_standard/standard_1001.pdf am 15.02.2006. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2005c): IT-GrundschutzVorgehensweise, BSI-Standard 100-2, Version 1.0, Dezember 2005, http://www. bsi.de/literat/bsi_standard/standard_1002.pdf am 15.02.2006. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2005d): ITIL und Informationssicherheit. M¨oglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und IT-Service-Management, Bonn, http://www.bsi.bund.de/ literat/studien/ITinf/itil.pdf am 12.01.2006.

230

Literaturverzeichnis

Bundesamt f¨ ur Sicherheit in der Informationstechnik (2005e): Die Lage der ITSicherheit in Deutschland 2005, http://www.bsi.de/literat/lagebericht/ lagebericht2005.pdf am 23.11.2005. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2006): BSI erteilt Zertifikate nach ISO 27001 auf der Basis von IT-Grundschutz, http://www.bsi.bund.de/ presse/pressinf/270106zertiso.htm am 28.02.2006. Bundesamt f¨ ur Sicherheit in der Informationstechnik (2006a): Grundlagen der elektronischen Signatur. Bonn: SecuMedia. Bundesministerium f¨ ur Wirtschaft und Technologie (2006): E-Kooperation, ef@cts - Informationen zum E-Business, Nr. 12, aktualisierte Ausgabe, http://www.existenzgruender.de/imperia/md/content/pdf/checklisten/ checkliste_nr35.pdf am 16.04.2006. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) (2005): Matrix der Haftungsrisiken. IT-Sicherheit - Pflichten und Risiken, Version 1.1, http://www.bitkom.org/files/documents/BITKOM_Leitfaden_ Matrix_der_Haftungsrisiken-V1.1f.pdf am 15.05.2005. Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM) (2005a): Kompass der IT-Sicherheitsstandards. Ein Leitfaden f¨ ur mittelst¨andische Unternehmen, http://www.bitkom.org/files/documents/ BITKOM_Broschuere_Sicherheitsstandard_V1.1f.pdf am 22.07.2005. Butler Group (2005): Security Management. Integrating People, Processes and Technology, http://www.butlergroup.com. Campo,

Markus a (2005): Kombinierte Sicherheit. ISO Grundschutzhandbuch im Duett, in: kes 6/2005, S. 13-15.

17799

und

BSI-

Canzler, Weert; Schmidt, Gert (Hrsg.) (2003): Das zweite Jahrhundert des Automobils. Technische Innovationen, ¨okonomische Dynamik und kulturelle Aspekte, Berlin: edition sigma. Cavusoglu, Huseyin; Mishra, Birendra; Raghunathan, Srinivasan (2004): A Model for Evaluating IT Security Investments, in: Communications of the ACM, Bd. 47, Nr. 7, New York: ACM Press, S. 87-92.

Literaturverzeichnis

231

Chokhani, S.; Ford, W.; Sabett, R. et al. (2003): Internet X.509 Public Key Infrastructure, Certificate Policy and Certification Practices Framework. Request for Comment Nr. 3647, http://www.ietf.org/rfc/rfc3647.txt am 03.09.2004. Clark, David Leon (1999): IT Manager’s Guide to Virtual Private Networks. New York: McGraw-Hill. Coenenberg, Adolf G. (1999): Kostenrechnung und Kostenanalyse, 4. Aufl., Landsberg am Lech: Moderne Industrie. Cole, Tim; Matzer, Michael (1999): Managementaufgabe Sicherheit. Sch¨ utzen Sie Ihr Unternehmen gegen die Risiken im Online-Zeitalter, M¨ unchen; Wien: Hanser Verlag. Collins, B.; Payene, A. (1991): Internal Marketing. A New Perspective for HRM, in: European Management Journal 3/1991, S. 156-163. Conference of State Bank Supervisors (2002): Executive Summary of the Sarbanes-Oxley Act of 2002, P.L. 107-204, http://www.csbs.org/government/legislative/ misc/2002_sarbanes-oxley_summary.htm am 26.10.2005. Curtis, Jason (2006): Spammer-Mafia siegt u ¨ber Antispam-Unternehmen, http://www. zdnet.de/security/news/0,39029460,39143616,00.htm vom 17.05.2005 am 18.05.2006. Dangelmaier, Wilhelm; Kaschula, Daniel; Neumann, Juliane (Hrsg.) (2004): Supply Chain Management in der Automobil- und Zulieferindustrie, Tagungsband zur 6. Paderborner Fr¨ uhjahrstagung 2004, Paderborn. Davis, Edward W.; Spekman, Robert E. (2003): The Extended Enterprise. Gaining Competitive Advantage Through Collaborative Supply Chains, New York, NY: Financial Times Prentice Hall. Deloitte (2004): Sicherheitsstudie 2004. Der Stand der IT-Sicherheit in der Finanzdienstleistungsbranche, http://www.deloitte.com/dtt/cda/doc/content/de_ wp_ers_Sicherheitsstudie2004_140704(1).pdf, am 06.08.2005. Denning, Dorothy E. (1999): Information Warefare And Security. Reading/MA; Harlow/GB; Menlo Park/CA; Sydney; Bonn; Amsterdam; Tokio; Mexico City: Addison-Wesley.

232

Literaturverzeichnis

Deutsche Bank Research (2003): Mehr Wachstum f¨ ur Deutschland. Innovationsstandort D: Mind the gap! Nr. 12, Frankfurt am Main. Diefenbach, Peter; Kreuzinger, Jochen (2004): Herausforderungen an den Test von Automotive-Komponenten, in: Elektronik Automotive 6/2004, S. 48-51. Dieter, Heribert (2003): Der H¨ahnchenkrieg und Amerikas Laster. US-Protektionismus f¨ ur Gel¨ande- und Lieferwagen, in: Wuppertal Bulletin zu Instrumenten des Klimaund Umweltschutzes (WB) 2/2003, Jg. 6, S. 10-12. Doekmetas, Mustafa (2005): Ein ideales Paar. Zugriffskontrolle und Business-Service-Management im Verbund, in: kes 6/2005, S. 80ff. D¨orner, Dietrich; Horv´ath, P´eter; Kagermann, Henning (Hrsg.) (2000): Praxis der Risikomanagements. Grundlagen, Kategorien, branchenspezifische und strukturelle Apekte, Stuttgart: Sch¨affer-Poeschel. Donaldson, Mike (2006): How to Strengthen Your Partner Relationships with Federated Identity, Version 1.0, March 2006, http://www.pingidentity.com am 22.05.2006. Dotzler, Hans-J¨ urgen (1999): Gestaltung der internen Kommunikation als Grundlage marktorientierter Ver¨anderungsprozesse, in: Bruhn, Manfred (Hrsg.): Internes Marketing, 2. Aufl., Wiesbaden: Gabler, S. 665-681. Dr. Ing. h.c. Porsche AG (2003): Gesch¨aftsbericht 2002/2003, http://www2.porsche. de/german/deu/company/annualreport/download/texts/bilder/Porsche_ Geschaeftsbericht72.pdf am 15.10.04. Dudenh¨offer, Ferdinand (2001): Ein neues Bild der Automobil-Zulieferindustrie, in: GAK Gummi Fasern Kunststoffe 3/2001, Jg. 54, S. 153-159. Dudenh¨offer, Ferdinand; Nagel, Peter; Havermann, Christoph (2002): Autozulieferer: Stellschrauben f¨ ur vitales Wachstum, in: Absatzwirtschaft 3/2002, Jg. 45, S. 2630. Dunn, Myriam; Metzger, Jan; Wenger, Andreas (2002): Critical Information Infrastructure Protection, Z¨ urich: Center for Security Studies and Conflict Research.

Literaturverzeichnis

233

Dynes, Scott; Brechb¨ uhl, Hans; Johnson, M. Eric (2005): Information Security in the Extended Enterprise. Some Initial Results From a Field Study of an Industrial Firm, 4th Workshop on the Economics of Information Security, 2.-3. June 2005, Harvard University, http://infosecon.net/workshop/pdf/51.pdf am 18.09.2005. Eckert, Claudia (2004): IT-Sicherheit. Konzepte - Verfahren - Protokolle, 3. u ¨berarb. und erw. Aufl., M¨ unchen; Wien: Oldenbourg. Eicke, Henning von; Femerling, Christian (1990a): Eine neue Phase der Arbeitsteilung, in: Produktion 35/1990, S. 50. Eicke, Henning von; Femerling, Christian (1990b): Konsolidierung in den Zulieferstr¨omen, in: Produktion 36/1990, S. 17. Elliott, Linda; Norlin, Eric; McKenna, Thomas et al. (2004): Scenarios for Identity Federation & Drivers of the Identity Network, http://www.pingidentity.com am 11.02.2006. Engelhardt, Werner H.; Kleinaltenkamp, Michael; Reckenfelderb¨aumer, Martin (1993): ¨ Leistungsb¨ undel als Absatzobjekte. Ein Ansatz zur Uberwindung der Dichotomie von Sach- und Dienstleistungen, in: Zeitschrift f¨ ur betriebswirtschaftliche Forschung 5/1993, S. 395-426. Ermert, Monika (2005): RSA-Konferenz: Der Markt versagt bei Sicherheit im Netz, 20.10.2005, http://www.heise.de/newsticker/meldung/65128/ am 26.10.2005. Europ¨aische Kommission (2000): Verordnung (EG) Nr. 2659/2000 der Kommission vom 29. November 2000 u ¨ber die Anwendung von Art. 81 Abs. 3 des Vertrages auf Gruppen von Vereinbarungen u ¨ ber Forschung und Entwicklung. In: Amtsblatt der Europ¨aischen Gemeinschaften, L 304, Jg. 43, 5.12.2000, S. 7-12, http://europa. eu.int/eur-lex/de/archive/2000/l_30420001205de.html am 23.4.03. Europ¨aische Kommission (2001): Leitlinien zur Anwendbarkeit von Artikel 81 EGVertrag auf Vereinbarungen u ¨ber horizontale Zusammenarbeit, 2001/C 3/02. In: Amtsblatt der Europ¨aischen Gemeinschaften, C 3, Jg. 44, 6.01.2001, S. 2-30, http://europa.eu.int/eur-lex/de/archive/2001/c_00320010106de. html am 24.04.03. Europ¨aische Kommission (2002): Verordnung (EG) Nr. 1400/02 der Kommission vom 31. Juli 2002 u ¨ber die Anwendung von Artikel 81 Absatz 3 des Vertrags auf Grup-

234

Literaturverzeichnis

pen von vertikalen Vereinbarungen und aufeinander abgestimmten Verhaltensweisen im Kraftfahrzeugsektor. In: Amtsblatt der Europ¨aischen Gemeinschaften, L203/30, Jg. 45, 1.8.2002, S. 30-41. Europ¨aische Kommission (2003): Report on United States Barriers to Trade and Investment, http://trade-info.cec.eu.int/doclib/docs/2003/december/ tradoc_115383.pdf, Br¨ ussel. European co-operation for Accreditation (2000): EA Guidelines for the Accreditation of Bodies Operating Certification/ Registration of Information Security Management Systems. Feb. 2000, http://www.european-accreditation.org/ content/publications/default.htm am 12.03.2006. Federrath, Hannes; Pfitzmann, Andreas (2000): Gliederung und Systematisierung von Schutzzielen in IT-Systemen, in: Datenschutz und Datensicherheit (DuD) 12/2000, Jg. 24, S. 704-710. Federrath, Hannes (Hrsg.) (2005): Sicherheit 2005. Beitr¨age der 2. Jahrestagung des GIFachbereichs Sicherheit, Lecture Notes in Informatics (P-62), Bonn: K¨ollen. Feige, A.; Neumann, A. (2001): Eintauchen in das Modell. Virtual Reality ersetzt physikalische Prototypen, in: Automobil-Industrie 11/2001, Jg. 46, S. 28-32. Ferraiolo, David; Kuhn, Richard (1992): Role-Based Access Control, in: Proceedings of 15th National Computer Security Conference, Baltimore/MD, October 13-16, pp. 554-563. Festinger, Leon; Irle, Martin; M¨ontmann, Volker (1978): Theorie der kognitiven Dissonanz. G¨ottingen: Huber. Fiutak, Martin (2004): IT-St¨orf¨alle in Unternehmen nehmen massiv zu, http://www. zdnet.de/news/software/0,39023144,39127884,00.htm vom 19.11.2004, am 12.10.2005. Frank, Sergey (2004): Ungeduld f¨ uhrt in China auf den Holzweg, in: New Management 7-8/2004, S. 39-43. Freg, Michael C. (2000): Die Haftung der Unternehmensf¨ uhrer nach KonTraG, http: //www.der-syndikus.de/briefings/gs/gs_009.htm am 11.10.2005.

Literaturverzeichnis

235

Freyermuth, Gundolf S. (1998): Warum hast du so große Ohren? In: Neue Z¨ uricher Zeitung Folio 7/1998, S. 38-43. Friberg, Christian; Gerhardt, Carsten; Luttenberger, Norbert (2003): Die Integration von Schutzbedarfsanalyse und IT-Grundschutz nach BSI, in: Gora, Walter; Krampert, Thomas (Hrsg.): Handbuch IT-Sicherheit, M¨ unchen: Addison-Wesley, S. 65-80. Friedl, Wolfgang J. (1998): Rechenzentrumssicherheit. Sicherheitstechnische Beurteilung, Maßnahmen gegen Gef¨ahrdungen, Berlin; Heidelberg; New York; Barecelona; Budapest; Hongkong; Mailand; Paris; Santa Clara; Singapur: Springer-Verlag. Fr¨obe, Bj¨orn (2004): Grundlagen eines effizienten Patchmanagements, in: Security Journal 11/2004, S. 1-4. Gahlen, Bernhard; Meyer, Bernd; Schumann, Jochen (Hrsg.) (1989): Wirtschaftswachstum, Strukturwandel und dynamischer Wettbewerb: Ernst Helmst¨adter zum 65. Geburtstag, Berlin; Heidelberg; New York; London; Paris; Tokyo: Springer. Gaßner, Sibylle (2006): Gefahren 2006: Spionage, Erpressung, Gift-Attacken, Krieg, http://www.silicon.de/enid/security_management/18610/ vom 11.04.2006 am 29.05.2006. Gehrke, Gunter (2003): Kundenbindungsstrategien industrieller Zulieferer. Eine empirische Studie in der Automobilindustrie, Aachen: Shaker. Gehrke, U.; Scheibler, M. (1998): Ein effektives Produktdatenmanagement - R¨ uckgrat f¨ ur die virtuelle Produktentwicklung, in: VDI (Hrsg.): Prozessketten f¨ ur die virtuelle Produktentwicklung in verteilter Umgebung, VDI-Berichte 1435, D¨ usseldorf: VDI-Verlag, S. 13-30. Geiger, Gebhard (Hrsg.) (2000): Sicherheit in der Informationsgesellschaft, Baden-Baden: Nomos. Geis, Ivo; Helfrich, Marcus (Hrsg.) (2003): Datenschutzrecht, M¨ unchen: Beck. Geschonneck, Alexander (2006): Messbar. Neue Standards f¨ ur Informationssicherheit, in: iX 1/2006, S. 114-115.

236

Literaturverzeichnis

Gleißner, Werner (2001): Identifikation, Messung und Aggregation von Risiken, in: Gleißner, Werner; Meier, G¨ unter (Hrsg.): Wertorientiertes Risiko-Management f¨ ur Industrie und Handel, Wiesbaden: Gabler, S. 111-137. Gleißner, Werner; Meier, G¨ unter (Hrsg.) (2001): Wertorientiertes Risiko-Management f¨ ur Industrie und Handel. Methoden, Fallbeispiele, Checklisten, Wiesbaden: Gabler. Gleißner, Werner; Wolfrum, Marco (2001): Risiko: Grundlagen aus Statistik, Entscheidungs- und Kapitalmarkttheorie, in: Gleißner, Werner; Meier, G¨ unter (Hrsg.): Wertorientiertes Risiko-Management f¨ ur Industrie und Handel, Wiesbaden: Gabler, S. 139-160. Global Insight (2004): World Car Industry Forecast Report. March 2004, Waltham/MA. G¨ortz, Horst; Stolp, Jutta (1999): Informationssicherheit in Unternehmen. Sicherheitskonzepte und -l¨osungen in der Praxis, Bonn; Reading (Mass.): Addison-Wesley. G¨ottlicher, Christoph (2004): ’Wir nehmen die Menschen mit’, in: Automobil-Produktion 06/2004, S. 10-11. ¨ Gola, Peter; Jaspers, Andreas (2002): Das neue BDSG im Uberblick. Erl¨auterungen, Schaubilder und Organisationshilfen zum BDSG 2001 f¨ ur die Datenschutzpraxis, 2. Aufl., K¨onigsdorf-Frechen: Datakontext. Gola, Peter; Klug, Christoph (2003): Grundz¨ uge des Datenschutzrechts, M¨ unchen: Beck. Gottwald, Michael (2006): ERP II – die Zukunft hat erst begonnen, in: Computerwoche, 25/2006, S. 30-31. Gora, Walter; Krampert, Thomas (Hrsg.) (2003): Handbuch IT-Sicherheit, M¨ unchen: Addison-Wesley. Gordon, Lawrence A.; Loeb, Martin P. (2002): The Economics of Information Security Investment, in: ACM Transactions on Information and System Security (TISSEC), Bd. 5, No. 4, New York: ACM Press, pp. 438-457. Gordon, Lawrence A.; Loeb, Martin P.; Lucyshyn, William et al. (2005): CSI/FBI Computer Crime and Security Survey, http://www.GoCSI.com/ am 24.04.2006.

Literaturverzeichnis

237

Grefermann, Klaus; Sprenger, Rolf-Ulrich (1977): Probleme der Innovationspraxis in der Industrie. Ansatzpunkte f¨ ur eine Kooperation zwischen Wirtschaft und Staat, Schriftenreihe des IFO-Instituts f¨ ur Wirtschaftsforschung Nr. 94, Berlin [u.a.]: Duncker Humblot. Grimme, Katharina (2005): Risikomanagement als Bestandteil einer Sourcing-Strategie, 09.11.2005, http://www.silicon.de/enid/cio_und_karriere_32.html\c_id= 15466 am 10.11.2005. G¨ unnewig, Dirk (2004): Architecture is Policy. Politikwissenschaftliche Herleitung und Analyse eines Steuerungskonzeptes f¨ ur digitale Informations- und Kommunikationstechnologien am Fallbeispiel von Digital Rights Management Systemen, zugl. Diss., Fakult¨at f¨ ur Sozialwissenschaft, Ruhr-Universit¨at Bochum. ¨ H¨agele, Thomas; Sch¨on, Wolf-Uli (1998): Uberleben durch Kooperieren, in: AutomobilIndustrie 1/1998, S. 66-68. Hanke, J¨ urgen (1993): Hybride Koordinationsstrukturen. Liefer- und Leistungsbeziehungen kleiner und mittlerer Unternehmen der Automobilzulieferindustrie aus transaktionskostentheoretischer Sicht, K¨oln: Josef Eul. Haour, Georges; Zedtwitz, Max von (2004): China auf dem Weg zum globalen Innovationslabor, in: New Management 4/2004, S. 16-20. Harding, Patrick (2005): Recommended Architecture for Implementing and Managing Identity Federation, Version 1.0, September 2005, http://www.pingidentity. com. Hartung, Frank; Kutter, Martin (1999): Multimedia Watermarking Techniques, in: Proceedings of the IEEE, Vol. 87, No. 7, pp. 1079-1107. Haslinger, Thomas; Ilmert, Alexander (2003): Strukturiertes, inhaltliches Konzept eines zukunftsorientierten Lieferantenbewertungssystems, Diplomarbeit, Fachhochschule Rosenheim. Heftrich, Frank (2001): Moderne F&E-Zusammenarbeiten in der Automobilindustrie. Organisation und Instrumente, zugl. Diss., Universit¨at Siegen. Hein, Christoph (2003): Dreiste Autof¨alscher am Werk, in: Automobilwoche 21/2003, S. 8.

238

Literaturverzeichnis

Heinrich, A.; M¨ uller, K.; Fehrling, J. et al. (2003): Versionsmanagement f¨ ur Transparenz und Prozesssicherheit in der Steuerger¨ate-Entwicklung, in: VDI-Gesellschaft Fahrzeug- und Verkehrstechnik (Hrsg.): VDI-Berichte Nr. 1789, Elektronik im Kraftfahrzeug, Tagung, Baden-Baden 25.-26.09.2003, Baden-Baden: VDI-Verlag, S. 219-230. Heinze, Hendrik (1997): Ein virtuell-flexibles Zuliefermodell. Neue Positionen f¨ ur Automobilzulieferunternehmen, Frankfurt/Main; New York; Berlin; Bern; Paris, Wien: Peter Lang. Heiser, Jay (2002): Security Through ROSI-colored Glasses, in: Information Security 7/2002, http://infosecuritymag.techtarget.com/2002/jul/curmudgeons_ corner.shtml am 22.04.2005. Heitmann, Marcus; Neuber, Susanne (2004): Chancen und Risiken des Web-EDI-Einsatzes im Supply Chain Management von Zulieferer-OEM-Beziehungen, in: Dangelmaier, Wilhelm; Kaschula, Daniel; Neumann, Juliane (Hrsg.): Supply Chain Management in der Automobil- und Zulieferindustrie, Tagungsband zur 6. Paderborner Fr¨ uhjahrstagung 2004, Paderborn: S. 208-216. Hertwig, Markus; M¨ uhge, Gernot; Pries, Ludger; Tackenberg, Hellen (2002): Chancen und Risiken von E-Business in der Automobilzulieferindustrie. WorkshopDokumentation Arbeiten und Lernen im E-Business“, AK-Forum zur ” Wirtschafts- und Strukturpolitik, Arbeitskammer des Saarlandes, Saarbr¨ ucken. Hill, Linda L.; Janee, Greg; Dolin, Ron et al. (1999): Collection Metadata Solutions for Digital Library Applications, in: Journal of the American Society of Information Science 13/1999, Jg. 50, pp. 1169-1181. H¨olscher, Reinhold (2002): Von der Versicherung zur integrativen Risikobew¨altigung: Die Konzeption eines modernen Risikomanagements. in: H¨olscher, Reinhold; Elfgen, Ralph (Hrsg.): Herausforderung Risikomanagement, Wiesbaden: Gabler, S. 331. H¨olscher, Reinhold; Elfgen, Ralph (Hrsg.) (2002): Herausforderung Risikomanagement. Identifikation, Bewertung und Steuerung industrieller Risiken, Wiesbaden: Gabler.

Literaturverzeichnis

239

H¨onicke, Ina (2005): Sicherheitsprofis: Juristisches Know-how immer st¨arker gefragt, 10.06.2005 http://www.zdnet.de/security/print_this.htm= pid39133939-39001544c am 15.06.2005. H¨orte, Sven ˚ Ake (2002): Knowledge Spillover Aspects of Co-operation and Competition. Beitrag zum International Workshop on Knowledge Spillovers and Knowledge ” Management in Economic Networks and Industrial Clusters“ vom 19.-21. September 2002 in Ljungby, Schweden. Hohe, Gerhard; Matz, Friedhelm (1999): Elektrische Sicherheit. Einf¨ uhrung in Schadensrisiken, Schutzkonzepte und sicherheitstechnische Regelwerke, Berlin; Offenbach: VDE. Hommel, Wolfgang; Reiser, Helmut (2005): Federated Identity Management: Die Notwendigkeit zentraler Koordinationsdienste, in: M¨ uller, Paul; Gotzhein, Reinhard; Schmitt, Jens B. (Hrsg.): Kommunikation in verteilen Systemen, Lecture Notes in Informatics, Gesellschaft f¨ ur Informatik, P-61, Bonn: Bonner K¨ollen Verlag, S. 65-72. Honeynet Project (2004): Know Your Enemy. Learning About Security Threats, 2 th ed., Addison-Wesley Professional. Hoppe, Gabriela; Prieß, Andreas (2003): Sicherheit von Informationssystemen. Gefahren, Maßnahmen und Management im IT-Bereich, Herne; Berlin: Neue Wirtschaftsbriefe. Holznagel, Bernd (2003): Recht der IT-Sicherheit, M¨ unchen: Beck. Horv´ath, Peter (2003): Controlling, 9. Aufl., M¨ unchen: Vahlen. Howarth, Fran (2005): Anti Orbanes-Oxley mood rises in Europe, 11.01.2005, http://www.theregister.co.uk/2005/01/11/europeans_slam_sarbox/ am 25.10.2005. H¨ ubner, Sonja (2002): Die Digitale Fabrik wird Chefsache im Automobilbau, in: VDI nachrichten 28/2002, S. 9. Humpert, Frederik (2004): IT-Sicherheit, in: M¨orike, Michael (Hrsg.): IT-Sicherheit, Praxis der Wirtschaftsinformatik, HMD 236, Heidelberg: dpunkt.verlag, S. 7-18.

240

Literaturverzeichnis

Information Systems Audit and Control Association (1998): CoP, CobiT, Marion, ITGrundschutzhandbuch. 4 Methoden im Vergleich, Z¨ urich, http://www.isaca. ch/files/igcop_broschuere.pdf am 27.03.2004. Institute for Security and Open Methodologies (2006): Open Source Security Testing Methodology Manual. Version 3.0, http://www.isecom.org/osstmm/. ISO/IEC 17799:2005(E). Information technology – Security techniques – Code of practice for information security management. ISO/IEC TR 13335-3:1998. Information technology – Guidelines for the Management of IT Security – Part 3: Techniques for the management of IT Security. IT Research (2003): eProvisioning & Identity Management. Business Value, Markt und Anbieter, Strategic Bulletin, http://www.it-research.net am 22.08.2005. Ittermann, Peter; M¨ uhge, Gernot; Schumann, Diana (2003): Organisationswandel in der deutschen Automobilindustrie. Neue Abh¨angigkeiten und/oder Netzwerkkooperation, Arbeitsbericht, Lehrstuhl f¨ ur Arbeitsorganisation und Mitbestimmung, Fakult¨at f¨ ur Sozialwissenschaft, Ruhr-Universit¨at Bochum. Jacquemin, Alexis (1988): Cooperative Agreements in R&D and European Antitrust Policy, in: European Economic Review 1988, Jg. 32, S. 551-560. Jaeger, M.; Kempis, R. D. (1999): Plattformstrategien und Modulbauweisen im Karosseriebau. Wachstumschancen und Risiken f¨ ur die Automobilzuliefererindustrie, in: 8. Aachener Kolloquium Fahrzeug- und Motorentechnik, Aachen, S. 369-387. Japp, Klaus Peter (2000): Risiko, Bielefeld: transcript. Jaschob, Angelika (2006): ISO-27001-Zertifizierung auf der Basis von IT-Grundschutz, in: kes 1/2006, S. 52-55. Johansson, Jesper M. (2004): Oh Patch How I Hate Thee; Let Me Count the Ways, vom 15.04.2004, http://www.microsoft.com/technet/community/columns/ secmgmt/sm0404.mspx am 08.06.2004. J¨ urgens, Ulrich (2003): Industriegovernance und Produktionskonzepte. in: Canzler, Weert; Schmidt, Gert (Hrsg.): Das zweite Jahrhundert des Automobils, Berlin: edition sigma, S. 15-41.

Literaturverzeichnis

241

Junginger, Markus; Balduin, Alexander von; Krcmar, Helmut (2003): Operational Value at Risk und Management von IT-Risiken, in: wisu - das Wirtschaftsstudium 3/2003, S. 356-364. Junginger, Markus; Krcmar, Helmut (2004): Wahrnehmung und Steuerung von Risiken im Informationsmanagement. Eine Befragung deutscher IT-F¨ uhrungskr¨afte, Arbeitspapier Nr. 1, Lehrstuhl f¨ ur Wirtschaftsinformatik, TU M¨ unchen, http: //www.winfobase.de am 29.09.2005. Kehrer, Olaf (2004): Deutschland Deine Daten, April 2004, http://www.oo-software. com/de/studie/Deutschland_Deine_Daten.pdf am 17. Oktober 2004. Kern Werner; Schr¨oder Hans-Horst (1977): Forschung und Entwicklung in der Unternehmung, Reinbeck b. Hamburg: Rororo. kes (2004a): Lagebericht zur Informations-Sicherheit, Teil 1, in: kes 4/2004, S. 6ff. kes (2004b): Lagebericht zur Informations-Sicherheit, Teil 2, in: kes 5/2004, S. 6ff. Keuper, Frank (2001): Strategisches Management, M¨ unchen: Oldenbourg. Kleinaltenkamp, Michael; Fließ, Sabine; Jacob, Frank (Hrsg.) (1996): Customer Integration. Von der Kundenorientierung zur Kundenintegration, Wiesbaden: Gabler. Kl¨ofer, Franz (1999): Erfolgreich durch interne Kommunikation. Mitarbeiter informieren, motivieren und aktivieren, Neuwied: Luchterhand. Knop, Dirk (2006): Tiefenanalyse. Viren am Verhalten erkennen, in: c’t magazin f¨ ur computertechnik, 14/2006, S. 222-225. K¨oth, Claus-Peter (2003): Die Branche vor der n¨achsten Revolution, in: AutomobilIndustrie 7-8/2003, S. 38-44. Koops, Bert-Jaap (2005): Crypto Law Survey, http://rechten.uvt.nl/koops/cryptolaw/.

Version

22.3, January 2005,

KPMG (1998): Integriertes Risikomanagement, http://www.kpmg.de/library/pdf/ 980902_irm_integriertes_risikomanagement_de.pdf am 02.09.2005. KPMG (2004): Basel II, http://www.kpmg.de/topics/9306.htm am 23.09.2004.

242

Literaturverzeichnis

Kraftfahrzeugbundesamt (2003): Bestand an Personenkraftwagen nach Segmenten. Pressemitteilung, http://www.kraftfahrzeugbundesamt.de/Stabsstelle/ Presseservice/Pressemitteilungen/pressemitteilungen2003/Segmente_ Typgruppen/segmente_01_2003_Bestand.pdf am 03.11.2004. Krampert, Thomas (2003): Holistischer Ansatz zur IT-Sicherheit, in: Gora, Walter; Krampert, Thomas (Hrsg.): Handbuch IT-Sicherheit, M¨ unchen: Addison-Wesley, S. 1935. Kremers, Markus (2002): Risiko¨ ubernahme in Industrieunternehmen. Der Value at Risk als Steuerungsgr¨oße f¨ ur das industrielle Risikomanagement dargestellt am Beispiel des Investitionsrisikos, in: H¨olscher, Reinhard (Hrsg.): Schriftenreihe Finanzmanagement, Bd. 7, Berlin: Sternenfels, zugl. Diss. Technische Universit¨at Kaiserslautern. Kr¨ uger, Alfred (2006): Den Teufel mit dem Beelzebub austreiben. Warum Anti-SpamFirma Blue Security scheitern musste, http://www.heise.de/tp/r4/artikel/ 22/22711/1.html vom 21.05.2006 am 24.05.2006. Krutz, Ronald L.; Vines, Russell Dean (2004): The CISSP Prep Guide. Mastering the CISSP and ISSEP Exams, Indianapolis/IN: Wiley. K¨ upper, Hans-Ulrich (2005): Controlling. Konzeption, Aufgaben, Instrumente, 4. Aufl., Stuttgart: Sch¨affer-Poeschel. Large, Rudolf (2000): Strategisches Beschaffungsmanagement. Eine praxisorientierte Einf¨ uhrung, 2. Aufl., Wiesbaden: Gabler. Leyden, John (2005): The Enemy Within, vom 15.12.2005, http://www.theregister. co.uk/2005/12/15/mcafee_internal_security_survey/ am 16.01.2006. Lindner, Olaf (2005): Vertrauen ist gut ... . Was bei Service Level Agreements zu beachten ist, in: kes 3/2005, S. 16ff. Magna International Inc. (2003): Annual Report 2003, http://media.corporate-ir. net/media_files/NYS/MGA/reports/AR03.pdf am 26.09.04. Mangold, Marc; Kunz, Werner H. (ohne Jahresangabe): Kundenintegration in Innovationsprozesse im Kontext eines Medienunternehmens. Arbeitsbericht zum Projekt Wissensintensive Dienstleistungen zur Integration von Kunden in

Literaturverzeichnis

243

Innovationsprozesse, http://www.aib.wiso.tu-muenchen.de/contentseiten/ winserv/Arbeitsberichte/06_Dienstleistung.pdf am 17.01.2005. Mankowski, Peter (2004):Sofortkauf-Option bei eBay. Landgericht Bonn, Urteil vom 19.12.2003 – 2 O 472/03 (rechtskr¨aftig), in: Multimedia und Recht, 03/2004, S. 179-183. Maroscheck, Christoph (1998): Die Schl¨ usselkompetenzen von Automobilzulieferern, in: Automotive Engineering Partners 2/1998, S. 50-53. Mast, Claudia (2002): Unternehmenskommunikation, Stuttgart: Lucius & Lucius. Mazda Motor Corporation (2004): Annual Report 2003, http://www.mazda.com/ investors/04hokoku/annu/pdf/mazda_aro03_e.zip am 10.10.04. Meffert,

Heribert (2000): Marketing. mensf¨ uhrung, Wiesbaden: Gabler.

Grundlagen

marktorientierter

Unterneh-

Menezes, Alfred J.; Oorschot, Paul C. van; Vanstone, Scott A. (1997): Handbook of Applied Cryptography, Boca Raton: CRC Press. Menges, Raimund (2005): Fr¨ uhzeitige Produktbeeinflussung und Prozessabsicherung, in: Zeitschrift f¨ ur wirtschaftlichen Fabrikbetrieb (ZWF) 1-2/2005, Jg. 100, S. 25-31. Menzel, Michael (2001): IT-Sicherheitsmanagement bei Aktiengesellschaften, in JurReport 05/2001, http://www.it-sicherheitsmanagement.de/jurrepeort/ 052001.htm am 13.10.2005. Mercer Management Consulting; HypoVereinsbank (2001): Automobiltechnologie 2010. Technologische Ver¨anderungen im Automobil und ihre Konsequenzen f¨ ur Hersteller, Zulieferer und Ausr¨ uster, M¨ unchen. MessageLabs (2005): MessageLabs Intelligence – Sicherheitsbericht 2005, http://www. messagelabs.com/Threat_Watch/Intelligence_Reports/ am 02.05.2006. Meyer, Anton (Hrsg.) (1998): Handbuch Dienstleistungsmarketing. Grundlagen, Management, Umsetzung, Branchenkonzepte und Praxisbeispiele, Band 1, Stuttgart: Sch¨affer-Poeschel.

244

Literaturverzeichnis

Meyer, Matthias; Zarnekow, R¨ udiger; Kolbe, Lutz M. (2003): IT-Governance – Begriff, Status quo und Bedeutung, in: Wirtschaftsinformatik 4/2003, Jg. 45, S. 445448. Meyers, Mike; Harris, Shon (2003): CISSP, Bonn: mitp. Mitnick, Kevin D.; Simon, William L. (2002): The Art of Deception: Controlling the Human Element of Security, Wiley Publishing. M¨orike, Michael (Hrsg.) (2004): IT-Sicherheit. Praxis der Wirtschaftsinformatik, HMD 236, Heidelberg: dpunkt.Verlag. M¨ uhlenbrock, Frank (2003): IT-Sicherheit. Effektive Richtlinien und Standards im Unternehmens-Netzwerk, Kilchberg/CH: Smartbooks. M¨ uller, Fabian (2004a): Entwurf eines standardisierten IT-Risikomanagements demonstriert an einem prototypischen Industrieunternehmen, Dipl.-Arbeit, Universit¨at Hamburg. M¨ uller, Klaus-Rainer (2004): Lebenszyklus- und prozessimanente IT-Sicherheit, in: kes 3/2004, S. 72ff. M¨ uller, Paul; Gotzhein, Reinhard; Schmitt, Jens B. (Hrsg.) (2005): Kommunikation in verteilen Systemen, Lecture Notes in Informatics, Gesellschaft f¨ ur Informatik, Kurzbeitr¨age und Workshop der 14. GI/TG-Fachtagung in Kaiserslautern, P-61, Bonn: Bonner K¨ollen Verlag. M¨ uller-Kohlenberg, Hildegard; M¨ unstermann, Klaus (Hrsg.) (2000): Qualit¨at von Humandienstleistungen, Opladen: Leske+Budrich. M¨ uller-Stewens, G¨ unter; Gocke, Andreas (1995): Kooperation und Konzentration in der Automobilindustrie. Strategien f¨ ur Zulieferer und Hersteller, Chur: G+B Verlag Fakultas. M¨ unch, Isabel (2005): Neue Grundschutz-Generation. Vom IT-Grundschutzhandbuch zu den BSI-Standards f¨ ur das IT-Sicherheitsmanagement, in: kes 6/2005, S. 6-12. National Institute of Standards and Technology (1979): Guideline for Automatic Data Processing Risk Analysis. Federal Information Processing Standards Publication, No. 65, zur¨ uckgezogen am 25.08.1995.

Literaturverzeichnis

245

National Institute of Standards and Technology (2002): Risk Management Guide for Information Technology. NIST Special Publication 800-30, http://csrc.ncsl.nist. gov/publications/nistpubs/800-30/sp800-30.pdf, am 12.08.2005. National Institute of Standards and Technology (2002a): The Economic Impact of RoleBased Access Control, NIST Planning Report 02-1, http://www.nist.gov/ director/prog-ofc/report02-1.pdf am 17.07.2004. National Institute of Standards and Technology (2003): Building an Information Technology Security Awareness Program, NIST Special Publication 800-50, Washington, http://csrc.nist.gov/publications/nistpubs/ 800-50/NIST-SP800-50.pdf am 23.06.2004. Neub¨ urger, Klaus W. (1989): Chancen und Risikobeurteilung im strategischen Management. Die informatorische L¨ ucke, Stuttgart: Sch¨affer. Nowey, Thomas; Federrath, Hannes; Klein, Christian et al. (2005): Ans¨atze zur Evaluierung von Sicherheitsinvestitionen, in: Federrath, Hannes (Hrsg.): Sicherheit 2005. Beitr¨age der 2. Jahrestagung des GI-Fachbereichs Sicherheit, Lecture Notes in Informatics (P-62), Bonn: K¨ollen, S. 15-26. Obert, Thomas (2003): Patchwork. Sicherheitsupdates: Zehnkampf f¨ ur Administratoren, in: kes 4/2003, S. 26ff. ODETTE (2000): Guidelines for CAD-CAM Data Exchange Agreement, http://www.odette.org/publications/pdf/03_CADCAM_Data/01_CADCAM_ Data_Exchange_Agreement.pdf am 14.04.2006. ODETTE (2006): ENGDAT V3. SASIG XMTD - Exchange and Management of Technical Data Guideline, http://www.odette.org/publications/pdf/03_CADCAM_ Data/03_ENGDAT_V3.pdf am 12.05.2006. ODETTE (2006a): Security and Risk Reduction, http://www.odette.org/ publications/pdf/05_B2B/S2R_V1.pdf am 10.05.2006. Ohne Verfasser (2004): ’Ein Billigauto ist in Deutschland nicht darstellbar’, S¨ uddeutsche Zeitung Online vom 22.03.2004, http://www.sueddeutsche.de/wirtschaft/ artikel/890/28862/ am 12.06.2004.

246

Literaturverzeichnis

Ohne Verfasser (2004a): Vabanque-Spiel im Reich der Mitte, in: Automobil-Produktion 5/2004, S. 67-72. Ohne Verfasser (2005): F&E 2004, in: Technology Review 1/2005, S. 70-78. Ohne Verfasser (2005a): Wer schl¨aft, erh¨alt die Quittung, Leipziger Volkszeitung vom 21.09.2005, http://www.lvz-online.de/lvz-heute/8137.html am 22.09.2005. Ohne Verfasser (2006): Gefahren aus dem Netz, Financial Times Deutschland, http: //www.ftd.de/technik/it_telekommunikation/73857.html am 01.06.2006. Olson, Mancur (2004): Die Logik des kollektiven Handelns. Kollektivg¨ uter und die Theorie der Gruppen, 5. Aufl., T¨ ubingen: Mohr Siebeck. Organization for the Advancement of Structured Information Standards (2005): Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15. March 2005, http://docs.oasis-open. org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf am 22.12.2006. Organization for the Advancement of Structured Information Standards (2005a): Glossary for the OASIS Security Assertion Markup Language (SAML), OASIS Standard, 15. March 2005, http://docs.oasis-open.org/security/saml/v2.0/ saml-glossary-2.0-os.pdf am 22.12.2005. Ostler, Ulrike (2005): Gut gemeint und teuer: SOX in IT und Organisationen, 22.02.2005, http://www.silicon.de/cpo/hgr-wipo/detail.php?nr=18773 am 28.06.2005. PartMaster GmbH (2005): Produktdatenintegration auf Basis des PLM Services“” Standard. White Paper, 26.08.2005, http://www.partmaster.de/uploads/88/ 12/PLMServicesMasterWhitePaper.pdf am 12.05.2006. Paulus, Sachar (2000): Risiken beim Einsatz von Informationstechnologie, in: D¨orner, Dietrich; Horv´ath, P´eter; Kagermann, Henning (Hrsg.): Praxis des Risikomanagements, Stuttgart: Sch¨affer-Poeschel, S. 379-413. Petersen, Jens (2005): Federated Identity Management. Definition, Ziele und Einsatzm¨oglichkeiten in der Automobilindustrie, Wolfsburg, internes Dokument.

Literaturverzeichnis

247

Picot, Arnold; Reichwald, Ralf (1994): Aufkl¨arung der Unternehmung, in: Zeitschrift f¨ ur Betriebswirtschaft (ZfB) 5/1994, Jg. 64, S. 547-570. Picot, Arnold; Reichwald, Ralf; Wigand, Rolf T. (2001): Die grenzenlose Unternehmung. Information, Organisation und Management, 4. Aufl., Wiesbaden: Gabler. Piercy, Nigel F. (2003): Marketing implementation, organizational change and internal marketing strategy, in: Baker, Michael J. (Hrsg.): The Marketing Book, 5th edition, Oxford: Butterworth/Heinemann, pp. 531-560. Plinke, Wulff (1996): Kundenorientierung als Voraussetzung der Customer Integration, in: Kleinaltenkamp, Michael; Fließ, Sabine; Jacob, Frank (Hrsg.): Customer Integration – von der Kundenorientierung zur Kundenintegration, Wiesbaden: Gabler, S. 41-56. Plinke, Wulff; Rese, Mario (2002): Industrielle Kostenrechnung. Eine Einf¨ uhrung, 6. Aufl., Berlin u.a.: Springer. Pointner, Wolfgang (2004): Umbruch in der Automobilindustrie? Von den Grenzen des Outsourcing, Frankfurt am Main: Peter Lang. Porter, Michael E. (1992): Wettbewerbsstrategie. Methoden zur Analyse von Branchen und Konkurrenten, 7. Aufl., Frankfurt am Main: Campus. Product Data Technology in a Network (2003): ENX Best Practices. Technical Aspects of the ENX Network, Version 2.0a, http://www.prostep.org/file/17291. PDTnet_2 am 13.11.2005. Product Data Technology in a Network (2003a): White Paper for PDTnet. Authorization and Security Concepts, http://www.prostep.org/file/17291.PDTnet_3 am 13.11.2005. Product Data Technology in a Network (2003b): Produktdatentechnologie und Kommunikation im Netzwerk von Automobilhersteller und Zulieferer. Abschlussbericht, http://www.prostep.org/file/15730.FinalRep am 13.11.2005. Product Data Technology in a Network (2003c): Product Data Technology and Communication in an OEM and Supplier Network. Application Scenario 1: PDM Data Exchange, http://www.prostep.org/file/15730.Fly_AP1 am 13.11.2005.

248

Literaturverzeichnis

Product Data Technology in a Network (2003d): Product Data Technology and Communication in an OEM and Supplier Network. Application Scenario 1: PDM Web Integration, http://www.prostep.org/file/15730.Fly_AP2 am 13.11.2005. ProSTEP iViP (2005): Product Lifecycle Management Services. Convenience Document, dtc/05-03-08, M¨arz 2005, http://www.omg.org/cgi-bin/apps/doc?dtc/ 05-03-08.pdf am 12.10.2005. ProSTEP iViP (2006): OMG PLM Services – A Leap forward in Product Data Communication, http://www.prostep.org/en/standards/plmservices/ am 12.05.2006. PWC (2004): Study on the financial and macroeconomic consequences of the draft proposed new capital requirements for banks and investment firms in the EU, PriceWaterhouseCoopers, Br¨ ussel, http://europa.eu.int/comm/internal_market/ regcapital/index_en.htm#consequences am 10.05.2005. Radtke, Philipp; Abele, Eberhard; Zielke, Andreas E. (2004): Die smarte Revolution in der Automobilindustrie, Frankfurt/Wien: Redline Wirtschaft bei ueberreuter. Ramanujapuram, Arun; Ram, Prasad (1998): Digital Content and Intellectual Property Rights, in: Dr. Dobb’s Journal 292/1998, pp. 20-27. Rannenberg, Kai (1998): Zertifizierung mehrseitiger Sicherheit. Kriterien und organisatorische Rahmenbedingungen, Braunschweig; Wiesbaden: Vieweg. Ranum, Marcus J. (2005): The Six Dumbest Ideas in Computer Security, 01.09.2005, http://www.ranum.com/security/computer_security/editorials/dumb/ am 22.10.2005. Rauschen, Thomas; Disterer, Georg (2004): Identifikation und Analyse von Risiken im IT-Bereich, in: M¨orike, Michael (Hrsg.): IT-Sicherheit, Praxis der Wirtschaftsinformatik, HMD 236, Heidelberg: dpunkt, S. 19-32. Reeg, Marcus (1998): Liefer- und Leistungsbeziehungen in der deutschen Automobilindustrie. Strukturelle Ver¨anderungen aus unternehmerischer und wirtschaftspolitischer Sicht, Berlin: Duncker und Humblot. Reinhardt, Andreas (2002): IT-Ver-un-sicherung, in: kes 2002, S. 60ff.

Literaturverzeichnis

Richter,

Klaus (2001): Digitale Revolution in der Entwicklung, //www.digitaltransformation.mckinsey.de/pdf/2776751_digital_ transformation_modul2_entwicklung.pdf am 13.05.2005.

249

http:

Richter, Wolf (1992): Die kombinierte Auslagerungs- und Verbundstrategie im industriellen Zulieferwesen, K¨oln, zugl. Diss, Universit¨at K¨oln. Rinka, S¨oren (2001): Entwicklungs- und Beschaffungsstrategie von Elektronik und Elektronikbauteilen in der Automobilindustrie, Diplomarbeit, Fachhochschule Lausitz. Robert Bosch GmbH (Hrsg.) (2002): Autoelektrik und Autoelektronik, 4. Aufl., Wiesbaden; Braunschweig: Vieweg. Robert Bosch GmbH (2003): Gesch¨aftsbericht 2003, http://www.bosch.com/de/ download/GB2003_DE.pdf am 10.10.04. Rolf, Arno (2003): Interdisziplin¨are Technikforschung und Informatik – ein Angebot f¨ ur einen analytischen Orientierungsrahmen, in: Technikfolgenabsch¨atzung 3/4/2003, Jg. 12, S. 59-67, http://www.itas.fzk.de/tatup/033/rolf03a.htm am 20.10.04. Romeike, Frank (2000): IT-Risiken und Grenzen traditioneller Risikofinanzierungsprodukte, in: Zeitschrift f¨ ur Versicherungswesen 17/2000, Jg. 51, S. 603-610. Romeike, Frank; Finke, Robert B. (2003): Erfolgsfaktor Risiko-Management. Chance f¨ ur Industrie und Handel, Wiesbaden: Gabler. R¨ uckert, Edvard; Leistenschneider, Gerd; Peitz, J¨ urgen (1995): Gemeinsam zu neuer Innovationskraft, Teil 1, http://www.ak-online.de/de/KnowledgeBase/Archiv/ 1995/4/2/ am 08.11.2004. Rutsaert, Pauline (1994): To Promote R&D Cooperation: A Strategic Trade Policy? MERIT Research Memorandum 2/94-014, http://www.merit.unimaas.nl/ publications/rmpdf/1994/rm94_014.pdf am 29.4.03. Sabett, Randy V. (2004): The Real Deal with Sarbanes-Oxley – Perspectives for the Security Manager, 19.03.2004, http://searchcio.techtarget.com/tip/1,289483, sid19_gci966927,00.html am 24.10.2005.

250

Literaturverzeichnis

Sandhu, Ravi S.; Coyne, Edward J.; Feinstein, Hal L. et al. (1996): Role-Based Access Control Models, in: IEEE Computer, Vol. 29, No. 2, pp. 38-47. Sanz, Francisco J. Garcia (2001): Neue Konzepte des Lieferantenmanagements. Zuk¨ unftige Strukturen der Supply Chain im Volkswagen-Konzern, internes Dokument, Wolfsburg. Sch¨affter, Markus (2002): IT-Entscheider in der Verantwortung, in: kes 4/2002, S. 10ff. Sch¨auffele, J¨org; Zurawka, Thomas (2003): Automotive Software Engineering. Grundlagen, Prozesse, Methoden und Werkzeuge, Wiesbaden: Vieweg. Schaum¨ uller-Bichl, Ingrid (1992): Sicherheitsmanagement. Risikobew¨altigung in informationstechnologischen Systemen. Reihe: Horster, Patrick (Hrsg.): Sicherheit in der Informations- und Kommunikationstechnik, Bd. 1, Mannheim; Leipzig; Wien; Z¨ urich: BI Wissenschaftsverlag. Schier, Kathrin (2000): Sicherheit f¨ ur multifunktionale Chipkarten, Frankfurt am Main: Knapp. Schindele, Sylvia (1996): Entwicklungs- und Produktionsverb¨ unde in der deutschen Automobil- und -zulieferindustrie unter Ber¨ ucksichtigung des Systemgedankens. Berichte aus Produktion und Umformtechnik, Bd. 34, Aachen: Shaker. Schlenker, Frederik (2000): Internationalisierung von F&E und Produktentwicklung. Das Beispiel der Automobilindustrie, Wiesbaden: Deutscher Universit¨ats-Verlag. Schmeh, Klaus (2001): Kryptografie und Public-key-Infrastrukturen im Internet, 2. Aufl., Heidelberg: dpunkt. Schmeh, Klaus; Uebelacker, Hubert (2004): Sicherheit, die sich rechnet. Returnon-Investment in der IT-Security, http://www.telepolis.de/r4/artikel/18/ 18954/1.html am 07.12.2004. Schmidt, Bernd Ivo (1997): Changing Patterns in the Automobile Manufacturing Industry and its Supply Networks, Cambridge, zugl. Masters Thesis, Cambridge University.

Literaturverzeichnis

251

Schmoeckel, Dieter; Liebler, Bertram C.; Schindele, Sylvia (1995): Kooperation zwischen Unternehmen der Zulieferindustrie, in: VDI-Z Integrierte Produktion 5/1995, S. 36-38. Schmoeckel, Dieter; Liebler, Bertram C.; Schindele, Sylvia (1996): System- und Modullieferanten als Entwicklungs- und Produktionspartner in der Automobilindustrie, in: wt – Produktion und Management 86/1996, S. 537-542. Schneider, Dietram; Zieringer, Carmen (1991): Make-or-Buy Strategien f¨ ur F&E. Trans¨ aktionskostenorientierte Uberlegungen, Wiesbaden: Gabler Verlag. Schneier, Bruce (1996): Applied Cryptography. Protocols, Algorithms, and Source Code in C, New York: Wiley. Schneier, Bruce (2000): Ask the Author, 29.12.2000, http://www2.cio.com/ask/author/ 2000/questions/question131.html am 29.11.2004. Schneier, Bruce (2001): Secrets & Lies. IT-Sicherheit in einer vernetzten Welt, Heidelberg: dpunkt. Schneier, Bruce (2005): New Cryptanalytic Results Against SHA-1, 17.08.2005, http://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html am 19.08.2005. Schneier, Bruce (2006): Movie Plot Threat Contest: Status Report, 22.04.2006, http://www.schneier.com/blog/archives/2006/04/movie_plot_thre.html am 23.04.2006. Schnell, Simone (2004): Compliance: Keine Angst vor kryptischen Begriffen, vom 16.09.2004 http://www.silicon.de/cpo/hgr-b2b/detail.php?nr=16531 am 22.09.2004. Sch¨ottle, Markus (2004): Im Plan 2005, in: Automobil-Produktion Juni/2004, S. 4-5. Schulze, Henning S. (1992): Internes Marketing von Dienstleistungsunternehmen. Fundierungsm¨oglichkeiten mittels ausgew¨ahlter Konzepte der Transaktionsanalyse, Frankfurt am Main; Berlin; Bern; New York; Paris; Wien: Lang, zugl. Diss., Universit¨at Hannover.

252

Literaturverzeichnis

Schwaiger, Walter S. A. (2004): Basel II Impact Study, in: Wirtschaft und Management 1/2004, Jg. 1, S. 29-52. Schweiger, G¨ unther.; Schrattenecker, Gertraud (2001): Werbung, 5. Aufl., Stuttgart: Lucius & Lucius. Schwickert, Axel C.; Fischer, Kim (1996): Der Gesch¨aftsprozess als formaler Prozess. Definition, Eigenschaften und Arten, Lehrstuhl f¨ ur allg. BWL und Wirtschaftsinformatik, Arbeitspapiere Wirtschaftsinformatik Nr. 4, Universit¨at Mainz. Scott, Charlie; Wolfe, Paul; Erwin, Mike (1999): Virtuelle private Netzwerke, K¨oln: O’Reilly. Seiler, Martin (2006): Viren schaden der IT am meisten, in: Computerwoche, 26/2006, S. 18. Sergl, Marita Gabriele (2001): Konzepte und Komponenten f¨ ur die Zugriffskontrolle in verteilten, heterogenen Krankenhaus-Informationssytemen am Beispiel des Mainzer Universit¨atsklinikums, zugl. Diss., Universit¨at Mainz. Siebert, Horst (1989): Anpassungsprobleme in einer offenen Volkswirtschaft, in: Gahlen, Bernhard; Meyer, Bernd; Schumann, Jochen (Hrsg.): Wirtschaftswachstum, Strukturwandel und dynamischer Wettbewerb: Ernst Helmst¨adter zum 65. Geburtstag, Berlin; Heidelberg; New York; London; Paris; Tokyo: Springer, S. 187199. Silicon.de (2005): IT-Sicherheit 2005. Ringen mit dem steigenden Aufwand, http: //www.silicon.de/downloads/siliconDEStudie_IT_Sicherheit2005.pdf am 07.08.2005. Soo Hoo, Kevin J. (2000): How Much Is Enough? A Risk-Management Approach to Computer Security. Doctoral dissertation, Consortium for Research on Information Security and Policy (CRISP), Stanford University, http://iis-db.stanford. edu/pubs/11900/soohoo.pdf am 08.01.2005. Speichert, Horst (2004): Praxis des IT-Rechts. Praktische Rechtsfragen der Internetnutzung und IT-Security, Wiesbaden: Vieweg. Spitzner, Lance (2002): Honeypots. Tracking Hackers, Addison-Wesley Professional.

Literaturverzeichnis

253

Steffenhagen, Hartwig (2000): Marketing, Stuttgart: Kohlhammer. Steiner, Winfried J.; Baumgartner, Bernhard (2004): Conjoint-Analyse und Marktsegmentierung, in: Zeitschrift f¨ ur Betriebswirtschaft (ZfB) 6/2004, Jg. 74, S. 611-635. Stelzer, Dirk (1995): Konzepte auf Basis von Risikoanalysen, in: Vossbein, Reinhard (Hrsg.): Organisation sicherer Informationsverarbeitungssysteme: Konzepte und L¨osungen, M¨ unchen; Wien: Oldenbourg, S. 115-128. Stiel, Hadi (2005): IAM, UTM etc., Identity-, Access- und Unified-Threat-Management als Unterst¨ utzer einer Sicherheitsstrategie von innen“, in: kes 5/2005, S. 21ff. ” Subei, Mai-Britt (2004): Planung und Umsetzung eines Sensibilisierungskonzeptes f¨ ur IT-Sicherheit am Beispiel der Volkswagen AG, Diplomarbeit, Universit¨at Oldenburg. Sydow, J¨org (1992): Strategische Netzwerke. Evolution und Organisation, Wiesbaden: Gabler. Sydow, J¨org (2000): Management von Dienstleistungsbeziehungen. Kundenintegration in organisations- und netzwerktheoretischer Perpektive, in: Witt, Frank H. (Hrsg.): Unternehmung und Informationsgesellschaft, Wiesbaden: Gabler, S. 21-33. Szyperski, Norbert (Hrsg.) (1989): Handw¨orterbuch der Planung, Stuttgart: Poeschel. Teichert, Thorsten Andreas (1994): Erfolgspotential internationaler F&E-Kooperationen, Wiesbaden: Deutscher Universit¨atsverlag. TeleTrusT Deutschland e.V. (2003): Bridge-CA. Certificate Practice Statement (CPS), Version 1.02, vom 05.06.2003, http://www.bridge-ca.org/eb-ca/downloads/ BCA_CPS_1_1_02.pdfam 25.09.2005. Tiemeyer, Ernst (2005): IT-Controlling kompakt, M¨ unchen: Elsevier. Tietze, Oliver (2003): Strategische Positionierung in der Automobilbranche. Der Einsatz von virtueller Produktentwicklung und Wertsch¨opfungsnetzwerken, Wiesbaden: Deutscher Universit¨atsverlag. Tomczak, Torsten; Sch¨ogel, Marcus; Sauer, Achim (2003): Die Automobilmarke als Cash Cow? In: Zeitschrift f¨ ur Automobilwirtschaft (ZfAW) 1/2003, S. 13-21.

254

Literaturverzeichnis

Unabh¨angiges Landeszentrum f¨ ur Datenschutz Schleswig-Holstein; Studio Notarile Genghini (2003): Identity Management Systems (IMS): Identification and Comparison Study, http://www.datenschutzzentrum.de/idmanage/study/ICPP_SNG_ IMS-Study.pdf am 14.08.2005. U.S. Securities and Exchange Commission (2004): Foreign Companies Registered and Reporting with the U.S. Securities and Exchange Commission, http://www. sec.gov/divisions/corpfin/internatl/foreigngeographic2004.pdf am 26.10.2005. Vahrenkamp, Richard; Siepermann, Christoph (Hrsg.) (2007): Risikomanagement in Supply Chains, Berlin: Schmidt. Vatter, Jochen (1999): Outsourcing: Kernkompetenzen und Risikobetrachtung, Diplomarbeit, N¨ urtingen: Fachhochschule N¨ urtingen. VDI-Gesellschaft Fahrzeug- und Verkehrstechnik (Hrsg.) (2003): VDI-Berichte Nr. 1789, Elektronik im Kraftfahrzeug, Tagung, Baden-Baden 25.-26.09.2003, BadenBaden: VDI-Verlag. Verband der Automobilindustrie e.V. (2003): Jahresbericht 2003, Frankfurt/Main. Verband der Automobilindustrie e.V. (2005): Telegramm – Nachrichten und Informationen f¨ ur die Entwicklungspartner der Automobilhersteller, 18/2005, Jg. 36. Verbeck, Alexander; Ziegenbein, Arne; Erni, Phillippe (2003): Risiken bei der Beschaffung gezielt reduzieren, in: New Management 11/2003, S. 50-55. Verbundinitiative Automobilwirtschaft (1997): Marktchancen und -strategien f¨ ur deutsche Automobilzulieferer in Nordamerika, D¨ usseldorf. Verein Deutscher Ingenieure (VDI) (Hrsg.) (1998): Prozessketten f¨ ur die virtuelle Produktentwicklung in verteilter Umgebung, VDI-Berichte 1435, D¨ usseldorf: VDI Verlag. V¨olker, J¨org (2005): BS 7799 - Von ’Best Practice’ zum Standard, Secorvo White Paper, Version 1.3, http://www.secorvo.de/whitepapers/secorvo-wp10.pdf. Volkswagen AG (2003): Beschaffung online, Handbuch Version 2.0, internes Dokument.

Literaturverzeichnis

255

Volkswagen AG (2004): Golf-Spektrum auf 98 Versionen erweitert, Pressemitteilung vom 05.08.2004. Vossbein, Reinhard (Hrsg.) (1995): Organisation sicherer Informationsverarbeitungssysteme: Konzepte und L¨osungen, M¨ unchen; Wien: Oldenbourg. Vossbein, Reinhard; Vossbein, J¨orn; Henze, Dirk (2000): Kosten und Nutzen der ITSicherheit. Studie des BSI zur Technikfolgen-Absch¨atzung, Ingelheim: SecuMedia. Werners, Brigitte; Klempt, Philipp (2005): Standards und Kriterienwerke zur Zertifizierung von IT-Sicherheit, Arbeitsbericht Nr. 9, Institut f¨ ur Sicherheit im E-Business (ISEB), Ruhr-Universit¨at Bochum. Werners, Brigitte; Klempt, Philipp (2005a): Verfahren zur Evaluation der IT-Sicherheit eines Unternehmens, Arbeitsbericht Nr. 12, Institut f¨ ur Sicherheit im E-Business (ISEB), Ruhr-Universit¨at Bochum. Werners, Brigitte; Klempt, Philipp (2005b): Risikoanalyse und Auswahl von Maßnahmen zur Gew¨ahrleistung der IT-Sicherheit, in: Haasis, Hans-Dietrich; Kopfer, Herbert; Sch¨onberger, J¨orn (Hrsg.): Operations Research Proceedings, S. 545-550. Werners, Brigitte; Klempt, Philipp (2007): Management von Risiken in Supply Chains, in: Vahrenkamp, Richard; Siepermann, Christoph (Hrsg.): Risikomanagement in Supply Chains, Berlin: Schmidt. Werners, Brigitte; Zimmermann, Hans-J¨ urgen (1989): Risikoanalyse, in: Szyperski, Norbert (Hrsg.): Handw¨orterbuch der Planung, Stuttgart, S. 1743-1750. Wertz, Boris (2000): Management von Lieferanten-Produzenten-Beziehungen. Eine Analyse in der deutschen Automobilindustrie, Wiesbaden: Deutscher Universit¨atsverlag. Wiebe, Andreas (2002): Nachweis der Authentizit¨at bei Internettransaktionen. Arbeitsgericht Erfurt, Urteil vom 14.09.2001 – 28 C 2354/01 (rechtskr¨aftig), in: Multimedia und Recht, 02/2002, S. 127-129. Wilkens, Andreas (2004): IBM tritt der Liberty Alliance bei, vom 21.10.2004, http:// www.heise.de/newsticker/meldung/52416 am 13.01.2005.

256

Literaturverzeichnis

Williamson, Oliver E. (1990): Die ¨okonomischen Institutionen des Kapitalismus, T¨ ubingen: Mohr Siebeck. Winkel, Olaf; Hecht, Volker; Tackenberg, Hellen (2001): IT-Sicherheit in KMU – Absch¨atzung des vordringlichen wirtschaftspolitischen Handlungsbedarfs. Studie im Auftrag des Bundesministeriums f¨ ur Wirtschaft (nicht mehr verf¨ ugbar). Winter, Ralf (2005): Beweislastverteilung f¨ ur Vertragsschluss via Online-Auktion, Landgericht Magdeburg vom 21.10.2003 – 6 O 1721/03 (321) (rechtskr¨aftig), in: Computer und Recht, 06/2005, S. 466. Wirtz, Bernd W. (2001): Electronic Business, 2. Aufl., Wiesbaden: Gabler. Witt, Frank H. (Hrsg.) (2000): Unternehmung und Informationsgesellschaft. Management – Organisation – Trends, Wiesbaden: Gabler. Wolf, Klaus; Runzheimer, Bodo (1999): Risikomanagement und KonTraG. Konzeption und Implementierung, Wiesbaden: Gabler. Wolters, Heiko (1995): Modul- und Systembeschaffung in der Automobilindustrie. Gestaltung der Kooperation zwischen europ¨aischen Hersteller- und Zulieferunternehmen, Wiesbaden: Gabler. Womack, James P.; Jones, Daniel T.; Roos, Daniel (1994): Die zweite Revolution in der Automobilindustrie. Konsequenzen aus der weltweiten Studie des Massachusetts Institute of Technology, 8. Aufl., Frankfurt/Main; New York: Campus. Zadeh, Lofti A.; Kacprzyk, Janusz (Hrsg.) (1999): Computing with Words in Information/Intelligent Systems, Part 1: Foundations. Studies in Fuzziness and Soft Computing, Vol. 33, Heidelberg: Physica. Z¨ah, Michael F.; Patron, Christian; Fusch, Thomas (2003): Die Digitale Fabrik, in: Zeitschrift f¨ ur wirtschaftlichen Fabrikbetrieb (ZWF) 3/2003, Jg. 98, S. 75-77.