Modul
Management der
Informationssicherheit
Studienbrief 1: Einleitung und Motivation
Studienbrief 2: Governance im Bereich der IS
Studienbrief 3: Risikomanagement im Bereich IS
Studienbrief 4: Umsetzung im IS-Programm
Studienbrief 5: Vorfallsmanagement im Bereich der IS
Studienbrief 6: Vorgehensweise nach BSI IT-Grundschutz
Studienbrief 7: Zusammenfassung und Fazit
Autor:
Dr. Christoph Wegener,
CCSK, CISA, CISM, CRISC, GDDcert
1. Auflage
Ruhr-Universität Bochum
© 2014 Dr. Christoph Wegener
Ruhr-Universität Bochum
Fakultät für Elektrotechnik und Informationstechnik
Gebäude ID 1/148
44780 Bochum
1. Auflage (1. Oktober 2014)
Didaktische und redaktionelle Bearbeitung:
Der Autor bedankt sich bei zahlreichen Personen, die ihn durch konstruktive
Kritik bei der Erarbeitung des vorliegenden Moduls unterstützt haben.
Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne
Zustimmung der Verfasser unzulässig und strafbar. Das gilt insbesondere
für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung
der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen deshalb darauf hin, dass die Verwendung der männlichen Form explizit als
geschlechtsunabhängig verstanden werden soll.
Inhaltsverzeichnis
Seite 3
Inhaltsverzeichnis
Einleitung zu den Studienbriefen
I.
Abkürzungen der Randsymbole und Farbkodierungen . . . . . . . . . . . . . . . . . . . . . . . .
II. Zu den Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III. Modullehrziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Studienbrief 1 Einleitung und Motivation
1.1 Informationssicherheit vs. IT-Sicherheit .
1.2 Standards zur Informationssicherheit . .
1.3 BSI-Standards zur Informationssicherheit
1.4 Wichtige Prinzipien . . . . . . . . . . . .
1.5 Ausblick auf die folgenden Kapitel . . .
1.6 Studienbegleitende Literatur . . . . . .
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Studienbrief 2 Governance im Bereich der IS
2.1 Aufbau und Aufrechterhaltung einer IS-Strategie . . . . . . . .
2.2 Aufbau und Aufrechterhaltung eines IS-Governance Frameworks
2.3 Integration der IS-Governance in die Corporate Governance . .
2.4 Aufbau und Fortschreibung eines IS-Policy Frameworks . . . . .
2.5 Business Cases - Entwicklung von praxisnahen Beispielen . . .
2.6 Berücksichtigung von internen und externen Faktoren . . . . .
2.7 Einholen der Unterstützung des Managements . . . . . . . . .
2.8 Festlegen von Rollen und Verantwortlichkeiten . . . . . . . . .
2.9 Grundlagen für die Kommunikation mit dem Management . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Studienbrief 3 Risikomanagement im Bereich IS
3.1 Prozess zur Klassifizierung der Informationswerte . . . .
3.2 Rechtliche und regulatorische Randbedingungen . . . .
3.3 Regelmäßiges Risikoassessment . . . . . . . . . . . . .
3.4 Möglichkeiten der Risikominimierung . . . . . . . . . . .
3.5 Kontrollen im Bereich Informationssicherheit . . . . . . .
3.6 Der Prozess des Risikomanagements . . . . . . . . . . .
3.7 Einbindung in die normalen “Prozesse” der Organisation
3.8 Monitoring von Risiken . . . . . . . . . . . . . . . . . . .
3.9 Bericht von Compliance-Verletzungen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Studienbrief 4 Umsetzung im IS-Programm
4.1 Ausrichtung des IS-Programms an den übrigen “Prozessen” der Organisation
4.2 Bestimmung von internen und externen Ressourcen . . . . . . . . . . . . .
4.3 Architektur der Informationssicherheit . . . . . . . . . . . . . . . . . . . . .
4.4 Standards, Arbeitsanweisungen und Handlungsempfehlungen . . . . . . . .
4.5 Security Awareness und Security Training . . . . . . . . . . . . . . . . . . .
4.6 Integration in die Geschäftsprozesse . . . . . . . . . . . . . . . . . . . . . .
4.7 Berücksichtigung von Verträgen . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Aufbau eines Monitoring- und Reportingsystems unter Nutzung von Metriken
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Studienbrief 5 Vorfallsmanagement im Bereich der IS
5.1 Festlegung “Was ist ein Sicherheitsvorfall?” . . . . . . . . . . . . . . . .
5.2 Entwicklung und Aufrechterhaltung eines Incident Response-Plans . . .
5.3 Aufbau eines Prozesses, der die Erkennung von Vorfällen sicher stellt . .
5.4 Aufbau eines Prozesses zur Untersuchung von Sicherheitsvorfällen . . .
5.5 Aufbau eines Prozesses zur Eskalation und Kommunikation von Vorfällen
5.6 Aufbau und Training der Incident Response-Teams . . . . . . . . . . . . .
5.7 Regelmäßige Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8 Aufbau von Kommunikationsprozessen . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
7
9
11
12
13
13
14
15
21
23
23
24
27
29
31
32
34
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
45
46
47
48
50
50
51
52
53
55
56
57
57
62
63
66
69
73
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
75
77
78
79
80
81
82
Seite 4
Inhaltsverzeichnis
5.9 Durchführen von Nachvorfallsbehandlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10Integration in Desaster Recovery- und Business Continuity-Prozesse . . . . . . . . . . . . . . . .
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
6.1 Initiierung des Informationssicherheitsprozesses . . . .
6.2 Erstellung einer Sicherheitskonzeption . . . . . . . . . .
6.3 Schutzbedarfsfeststellung . . . . . . . . . . . . . . . . .
6.4 Umsetzung der Sicherheitskonzeption . . . . . . . . . .
6.5 Aufrechterhaltung und Verbesserung . . . . . . . . . . .
6.6 Zertifizierung . . . . . . . . . . . . . . . . . . . . . . . .
Studienbrief 7 Zusammenfassung und Fazit
83
84
85
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
94
95
99
101
103
105
Verzeichnisse
107
8.1 Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.2 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Einleitung zu den Studienbriefen
Seite 5
Einleitung zu den Studienbriefen
I. Abkürzungen der Randsymbole und Farbkodierungen
Axiom
A
Beispiel
B
Definition
D
Exkurs
E
Kontrollaufgabe
K
Merksatz
M
Quelle
Q
Satz
S
Übung
Ü
Seite 6
Einleitung zu den Studienbriefen
II. Zu den Autoren
Dr. Christoph Wegener (CCSK, CISA, CISM, CRISC, GDDcert) ist seit 1999
als freiberuflicher Berater mit der wecon.it-consulting in den Bereichen Informationssicherheit, Datenschutz und Open Source aktiv. Zudem ist er nach
mehr als achtjähriger Tätigkeit am Horst Görtz Institut für IT-Sicherheit (HGI)
an der Ruhr-Universität Bochum nun der IT-Leiter der dortigen Fakultät für
Elektrotechnik und Informationstechnik. In dieser Position verantwortet er
insbesondere die Themen Informationssicherheit und Datenschutz.
Herr Dr. Wegener ist Autor zahlreicher Fachbeiträge und Sprecher auf nationalen und internationalen Konferenzen und engagiert sich in der Ausbildung
im Bereich der Informationssicherheit. Darüber hinaus ist er Mitglied des Beirats
der Zeitschrift "Datenschutz und Datensicherheit – DuD", Gründungsmitglied der
Arbeitsgruppe Identitätsschutz im Internet (a-i3) und des German Chapters der
Cloud Security Alliance (CSA) und dort, sowie von 2007 bis 2014 in der German
Unix User Group (GUUG), Mitglied des Vorstands.
Modullehrziele
Seite 7
III. Modullehrziele
Informationssicherheit ist mehr als (die Umsetzung der technischen Aspekte im Rahmen der) IT-Sicherheit.
Neben den technischen Fragen müssen auch die Aspekte “Personen” und “Prozesse” mit berücksichtigt
werden. Darüber hinaus stehen jeder Organisation nur begrenzte Ressourcen zur Verfügung, allein dies
schließt das Erreichen von 100 %iger Sicherheit aus und macht deutlich, dass Informationssicherheit
wie IT-Sicherheit als Dienstleistungsfunktionen verstanden werden müssen, die sich dem eigentlichen
“Geschäftsprozess” einer Organisation unterordnen.
Im Rahmen dieses Moduls sollen nun -auf Basis der Vorgehensweisen der amerikanischen Information Systems Audit and Control Association (kurz: ISACA) [7] bzw. der des deutschen “Bundesamts für Sicherheit
in der Informationstechnik” (kurz: “BSI”) [2]- die Grundlagen des Managements der Informationssicherheit
vermittelt werden. Dazu gehört zunächst ein Verständnis für die Fragen der “Governance”, damit die
Informationssicherheit von vorneherein an den Prozessen der Organisation ausgerichtet wird. Daneben
spielt auch das “Risikomanagement” eine wichtige Rolle, das die Grundlagen für die zahlreichen Entscheidungen im Kontext “Wann sollen welche Maßnahmen wie umgesetzt werden?” und damit im Bereich des
Managements der Informationssicherheit liefert.
Auf dieser Basis wird dann vermittelt, wie die Informationssicherheit in der Organisation verankert
werden kann, es wird ein “Programm zur Informationssicherheit” etabliert. Da es aber -allen Vorbereitungen
zum Trotz- dennoch zu Sicherheitsvorfällen kommen kann, muss die Organisation auch darauf entsprechend
vorbereitet sein. Hierzu wird auf Grundlage der Frage rund um den Aspekt “Was ist ein Sicherheitsvorfall?”
vermittelt, was zu einer angemessenen Vorbereitung auf diese Problemfälle zu zählen ist.
Schließlich gibt es mit dem BSI-Standard 100-2 eine -insbesondere in Deutschland- etablierte Vorgehensweise
für die Umsetzung der Informationssicherheit, dessen Grudnzüge ebefalls vermittelt werden.
Studienbrief 1 Einleitung und Motivation
Seite 9
Studienbrief 1 Einleitung und Motivation
Obwohl schwer “greifbar”, stellen Informationen die eigentlichen Werte für Unternehmen und Behörden dar. Gehen Informationen verloren, drohen Unternehmen
und Behörden nicht nur entsprechende rechtliche Konsequenzen oder ein schwer
messbarer Imageschaden, auch der Betrieb an sich wird negativ beeinträchtigt und
das, obwohl die die Informationen verarbeitenden Systeme vielleicht sogar noch
völlig intakt sind.
Informationen repräsentieren enorme Werte
Interessanterweise bestreitet heute niemand mehr, dass die Systeme, die die Informationen verarbeiten, also die Informationstechnologie (IT) im Unternehmen
entsprechend zu schützen sind. Informationen liegen aber eben gerade nicht nur
als Bits und Bytes auf den Speichermedien der IT vor, sondern tauchen in Unternehmen und Behörden an vielfältigen Stellen auf. Beispielhaft seien hier die
immer noch existierenden Papierakten und sonstige Informationen auf Papier oder
auch die Informationen in den Köpfen der Mitarbeiter genannt. Da mit den oben
genannten Auswirkungen des Verlustes von Informationen regelmäßig auch hohe
Kosten verbunden sein werden, sind Informationen daher in allen Phasen der
Prozesse einer Organisation und an allen Stellen der Organisation zu schützen.
Informationen finden sich
an vielfältigen Stellen
Die Vergangenheit hat allerdings gezeigt, dass ein adäquates Sicherheitsniveau
für Informationswerte oft nicht vorhanden ist. Dies hat vorrangig damit zu tun,
dass Informationen - im Gegensatz zur eigentlichen IT - nur schwer greifbar sind.
Daher findet man häufig gute technische Schutzvorkehrungen für die technischen
Systeme (und ggf. damit auch für die auf den Systemen befindlichen Informationswerte), für Informationen in anderen Phasen der betrieblichen Prozesse liegt aber
meist kein oder zumindest kein adäquates Sicherheitsmanagement vor. Oftmals
verbessert aber gerade die Einführung bzw. die Optimierung des Sicherheitsmanagements die Informationssicherheit in einem höheren Ausmaße bzw. trägt zu
einer Effektivitätssteigerung der Informationssicherheit bei.
Sicherheitsniveau ist oft
nicht angemessen
Bevor die Fragen des angemessenen Sicherheitsniveaus betrachtet werden, soll die
Informationssicherheit nun von der IT-Sicherheit (in technischer Sicht) abgegrenzt
werden.
1.1 Informationssicherheit vs. IT-Sicherheit
IT-Sicherheit steht zunächst einmal für den Schutz der IT-Systeme, spricht also vor
allem technische Maßnahmen an und beschäftigt sich damit schwerpunktmäßig
mit dem Schutz elektronisch gespeicherter Informationen und deren Verarbeitung.
Wenngleich der Begriff IT-Sicherheit oft synonym für den Begriff Informationssicherheit verwendet wird, soll hier doch klar zwischen beiden Begrifflichkeiten
unterschieden werden, wenn im Rahmen eines modernen Sicherheitsmanagements
von Sicherheitsmaßnahmen die Rede ist.
Informationssicherheit ist im Vergleich zur IT-Sicherheit nicht auf den Schutz
elektronisch gespeicherter Informationen beschränkt, sondern berücksichtigt Informationen in allen Phasen der Geschäftsprozesse. Dabei werden als klassische
Grundwerte der Informationssicherheit häufig die drei Begriffe Vertraulichkeit,
Integrität und Verfügbarkeit bezeichnet. Im englischen Sprachraum fasst man diese
drei Begriffe auch unter dem Akronym CIA-Triade (vgl. Abbildung 1.1) zusammen,
als Kurzform für die Anfangsbuchstaben der englischen Begriffe confidentiality,
integrity und availability.
Informationssicherheit vs.
IT-Sicherheit
CIA-Triade
Seite 10
Abb. 1.1: Illustration der
CIA-Triade zur Darstellung der drei Schutzziele
Vertraulichkeit, Integrität und Verfügbarkeit.
Studienbrief 1 Einleitung und Motivation
C I A
onfidentiality
ntegrity
vailability
• Vertraulichkeit (engl.: confidentiality) bezeichnet den Umstand, dass Informationen nur Berechtigten zur Verfügung stehen. Durch Schutzmaßnahmen
wie beispielsweise einer angemessenen Zugriffskontrolle wird dabei verhindert, dass Nicht-Berechtigte Zugriff auf Informationen erhalten.
• Integrität (engl.: integrity) bezeichnet die Unversehrtheit einer Information.
Dabei kann allerdings nicht der Umstand der Unversehrtheit selbst, sondern nur die Nicht-Erkennung der Verletzung der Unversehrtheit durch
Maßnahmen ermöglicht werden.
• Verfügbarkeit (engl.: availability) bezeichnet den Umstand, dass Informationen den Berechtigten (vgl. dazu auch Vertraulichkeit) innerhalb einer
angemessenen Zeit zur Verfügung stehen.
Mögliche Verletzung
der Schuztziele
Für mögliche Verletzungen der genannten Schutzziele geben wir nun einige ausgewählte Beispiele an, die stellvertretend für die Vielzahl von potentiellen Gefährdungen stehen:
• Fälle, in denen die Verfügbarkeit beeinträchtigt wird, sind: Datenträger
und/oder IT-Systeme werden durch höhere Gewalt zerstört; nach einem
notwendigen Software-Update funktionieren wichtige Anwendungen nicht
mehr; ein Mitarbeiter erkrankt, dadurch verzögert sich ein wichtiger Geschäftsprozess.
• Fälle, in denen aufgrund einer fehlenden Integritätssicherungsmaßnahme
die Integrität der Daten beeinträchtigt wird, sind: Ein (böswilliger) Mitarbeiter manipuliert wichtige Produktionsdaten, dadurch entsteht wirtschaftlicher Schaden, da die produzierten Güter nicht verwertbar sind.
• Fälle, in denen die Vertraulichkeit der Daten beeinträchtigt wird, sind: Vertrauliche Informationen werden unverschlüsselt über das Internet übertragen; personenbezogene Daten werden unverschlüsselt auf einem USB-Stick
verschickt, dieser geht jedoch auf dem Transportweg verloren.
Zutritts-, Zugriffs- und
Zugangskontrollen
Zur Sicherherstellung der Schutzziele kommen zudem unterschiedliche Kontrollen
in Frage, die im weiteren Verlauf dieses Moduls noch eine wichtige Rolle spielen
werden und daher bereits an dieser Stelle kurz erläutert werden sollen:
• Zutritt (engl.: physical access) bezeichnet die Möglichkeit des Betretens bspw.
eines Serverraums. Allgemeiner kann man Zutritt auch damit erklären,
dass der Zutritt jemanden in die Lage versetzt, die Gegenstände im Raum
anfassen zu können. Eine typische Zutrittskontrolle stelle ein Schloss an der
Tür zum Serverraum dar.
• Zugang (engl.: logical access) bezeichnet die Möglichkeit, sich an einem System, bspw. dem Betriebssystem eines Rechners, anmelden zu können. Eine
typische Zugriffskontrolle ist bspw. die Passwort-Eingabe bei der Anmeldung am Betriebssystem.
• Zugriff (engl.: data access) bezeichnet die Möglichkeit, Zugriff auf die Daten
auf einem System nehmen zu können. Eine typische Zugriffskontrolle ist
die Abbildung der entsprechenden Dateirechte im Dateisystem und deren
Kontrolle durch die Sicherheitsfunktionen des Betriebssystems
1.2 Standards zur Informationssicherheit
Seite 11
Die Schutzziele können dabei sowohl durch vorsätzliche Handlungen (gezieltes
Abhören/Abfangen von Informationen) als auch Formen von “höherer Gewalt”
beeinträchtigt werden. Da die Verarbeitung von Informationen in der heutigen
Zeit meist elektronisch erfolgt und nahezu alle Lebensbereiche durchdrungen
hat, macht eine Unterscheidung, ob Informationen elektronisch mit Hilfe von ITSystemen, mittels Kommunikationstechnik oder auf Papier verarbeitet werden,
keinen Sinn mehr.
Abb. 1.2: Darstellung des
Säulen-Modells zur Informationssicherheit: Die
Informationssicherheit
fußt auf den drei Säulen
“Personen”, “Prozesse”
und “Technik”.
Technik
Prozesse
Informationssicherheit
Personen
Mögliche Gefährdungen
Daher geht man vom Begriff der IT-Sicherheit über zum Begriff der Informationssicherheit, die sich auf alle Informationen in allen Phasen des Geschäftsprozesses
bezieht. Dabei werden Aspekte der drei Säulen berücksichtigt, neben der rein technischen Sicht (Säule: “Technik”) auch die Fragestellungen bzgl. der Geschäftsprozesse (Säule: “Prozesse”) und der Mitarbeiter (Säule: “Mensch”).
Drei Säulen-Modell
1.2 Standards zur Informationssicherheit
Im Bereich Informationssicherheit haben sich seit längerer Zeit einige (internationale) Standards etabliert, die im Folgenden kurz vorgestellt werden sollen. Auch
wenn diese Standards aufgrund ihrer historischen Entwicklung zum Teil unterschiedliche Ausrichtung haben, so erleichtern sie doch die strukturierte Planung
und Umsetzung der Informationssicherheit in einer Organisation.
Standards zur
Informationssicherheit
Im Bereich der Internationalen Organisation für Normung (kurz: ISO) existiert
eine ganze Reihe von Standards im Bereich der Informationssicherheit, die so
genannten 27000er-Reihe.
ISO-Standards zur
Informationssicherheit
• ISO 27000 “Information security management systems - Overview and vocabulary”
gibt einen Überblick über Managementsysteme für Informationssicherheit
(ISMS) und die Zusammenhänge zwischen den Standards der 2700x-Reihe.
Zudem werden in der ISO 27000 die wesentlichen Begriffe, Definitionen
und Prinzipien für ISMS erläutert.
ISO 27000
• ISO 27001 “Information technology - Security techniques - Information security
management systems - Requirements” beschreibt auf knappen zehn Seiten die
Anforderungen an die Einführung, den Betrieb und die ständige Verbesserung eines dokumentierten Managementsystems zur Informationssicherheit
(ISMS) und bildet die Grundlage für eine Zertifizierung. Dabei werden auch
die Risiken für die Informationssicherheit innerhalb der gesamten Organisation berücksichtigt. Der Standard selbst gibt keine Kontrollmaßnahmen
ISO 27001
Seite 12
Studienbrief 1 Einleitung und Motivation
zur Erreichung dieses Zieles an (diese werden vielmehr im Standard ISO
27002 beschrieben), sondern spricht lediglich allgemeine Empfehlungen
zum Einsatz eines ISMS aus.
ISO 27002
• ISO 27002 “Code of practice for information security management” ergänzt die
ISO 27001 und beinhaltet Empfehlungen für diverse Kontrollmechanismen.
Da es sich hierbei aber um reine Empfehlungen handelt, ist eine Zertifizierung auf Grundlage dieses Standards grundsätzlich nicht möglich, diese
erfolgt immer auf Grundlage der ISO 27001.
Weitere ISO-Normen
Darüber hinaus gibt es noch weitere Normen, die hier nur der Vollständigkeit
halber kurz erwähnt werden sollen. Dazu gehören die ISO 27003 “Information
security management systems - Implementation Guidelines”, die ISO 27004 “Information
security management measurements”, die ISO 27005 “Information security risk management”, die ISO 27006 “Information technology - Security techniques - Requirements
for bodies providing audit and certification of information security management systems”,
die ISO 27007 “Information technology - Security techniques - Guidelines for information
security management systems auditing” und die ISO TR 27008 “Information technology
- Security techniques - Guidance for auditors on information security management systems
controls”.
Weitere Subnormen
Hinzu kommen die Normen ISO 27010 bis ISO 27019, die als fachspezifische
Subnormen die ISO 27002 ergänzen. Darunter finden sich mit der ISO TR 27016
“Auditing and Reviews” eher allgemein gehaltene Normen, aber auch sehr spezielle,
wie bspw. die ISO 27017 “Security techniques — Code of practice for information security
controls for cloud computing services”.
Normen für
technische Aspekte
Die Normen ISO 27030 bis ISO 27044 sollen schließlich die technischen Aspekte
der IS abdecken, dazu gehören bspw. ISO 27031 “Business Continuity” oder ISO
27033-1 bis 27033-5 zu den Themen der Netzwerksicherheit.
1.3 BSI-Standards zur Informationssicherheit
IT-Grundschutzhandbuch
BSI-Standards zur
Informationssicherheit
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat mit dem ITGrundschutzhandbuch eine Vorgehensweise entwickelt, die Betreiber der IT innerhalb einer Organisation dabei unterstützt, Sicherheitsmaßnahmen zu identifizieren
und umzusetzen. Zielsetzung ist dabei nicht eine 100 %ige Sicherheit zu erreichen,
sondern vielmehr Maßnahmen zu ergreifen, die angemessen sind und ein ausreichendes Schutzniveau realisieren. Im Rahmen der Umstrukturierung im Jahre
2006 wurden die Standards von den IT-Grundschutz-Katalogen separiert.
Aktuell gibt es insgesamt die folgenden vier Standards:
• BSI-Standard 100-1 “Managementsysteme für Informationssicherheit (ISMS)” [1]
• BSI-Standard 100-2 “IT-Grundschutz-Vorgehensweise” [2]
• BSI-Standard 100-3 “Risikoanalyse auf der Basis von IT-Grundschutz” [3]
• BSI-Standard 100-4 “Notfallmanagement” [4]
Auf den BSI-Standard 100-2 “IT-Grundschutz-Vorgehensweise” gehen wir in Studienbrief 6 noch gesondert im Detail ein.
1.4 Wichtige Prinzipien
Seite 13
1.4 Wichtige Prinzipien
Im Rahmen der Umsetzung der Informationssicherheit spielen einige wesentliche
Konzepte immer wieder eine Rolle. Im Folgenden sollen drei ausgewählte Konzepte, auf die wir im Verlauf dieses Moduls noch zurück kommen werden, kurz
erläutert werden.
Grundlegende Konzepte
Oft wird Informationssicherheit als (singuläres) Projekt betrachtet - doch dies
erweist sich allerdings als der grundlegend falsche Ansatz. Wird Informationssicherheit nicht als kontinuierlicher Prozess verstanden, so läuft eine Organisation
Gefahr, dass die Informationssicherheit zwar zu einem definierten Zeitpunkt ausreichend war, danach aber immer weniger den Anforderungen der Organisation
genügt, da sich die Randbedingungen stetig ändern, die Maßnahmen im Bereich
der Informationssicherheit aber aufgrund des fehlenden Prozessansatzes nicht
oder nur in unzureichendem Maße angepasst werden.
Lebenszyklus
Informationssicherheit
als Prozess
Ein weiterer wichtiger und häufig diskutierter Aspekt ist die Frage nach der angemessene Sicherheit. 100 %ige Sicherheit ist allein aufgrund der begrenzten Ressourcen und einem dabei ins unermessliche steigenden Aufwand nicht erreichbar. Auf
diese Fragestellung gehen wir bspw. in Studienbrief 3 und Studienbrief 6 nochmals
genauer ein.
Angemessene Sicherheit
Auch das Konzept der “Verteidung in mehreren Ebenen” (engl.: Layered Defense)
ist ein wichtiger Grundsatz im Rahmen der Informationssicherheit. Es bedeutet,
dass nicht auf singuläre Schutzmechanismen gesetzt, sondern vielmehr versucht
wird, Maßnahmen auf unterschiedlichen Ebenen parallel umzusetzen. Es ähnelt
damit dem mittelalterlichen Ansatz der Verteidigung von Burganlagen, bei dem
auch ein Burggraben, eine hohe Mauer und ggf. noch weitere Abwehrmaßnahmen
parallel eingesetzt wurden. Zielsetzung ist wie damals auch, dass dem Angreifer,
der eine Maßnahme überwunden hat, dennoch der Weg -in usnerem Fall also
bspw. der Zugriff auf die Informationen- verbaut ist. Auf diesen Ansatz gehen wir
im Studienbrief 2 nochmals genauer ein.
Konzept der Layered
Defense
Darüber hinaus ist bspw. noch der Ansatz des “Need-to-know-Prinzips” zu nennen,
nach dem Informationen bzw. Zugriffsrechte auf dieselbem nur im zur Ausführung
der zugewiesenen Prozesse bzw. Tatigkeiten erforderlichen Umfang und nur an
die wirklich Berechtigten zugeteilt werden.
Need-to-know-Prinzip
Zusätzlich wären zahlreiche weitere Konzepte zu nennen, was den Rahmen dieses
Studienbriefs sprengen würde. Der interessieret Leser wird in diesem Zusammenhang insbesondere auf die Grundlagenliteratur, bspw. die des BSI [1], verwiesen.
Weitere Konzepte
1.5 Ausblick auf die folgenden Kapitel
Nun folgt ein kurzer Überblick über die folgenden Studienbriefe dieses Moduls:
Ausblick auf die folgenden Kapitel
• Im Studienbrief 2 “Governance im Bereich der IS” lernen wir die wesentlichen Konzepte und Ideen der Governance im Bereich der Informationssicherheit kennen. Dabei werden sowohl die wesentlichen Elemente der
Governance behandelt als auch aufgezeigt, wie eine effektive Governance
betrieben werden kann.
Governance im Bereich
der IS
• Im Studienbrief 3 “Risikomanagement im Bereich der IS” lernen wir anschließend die Grundzüge des Risikomanagements kennen. Nach einem
einleitenden Teil, der unter anderem die grundlegenden Begrifflichkeiten
Risikomanagement im
Bereich der IS
Seite 14
Studienbrief 1 Einleitung und Motivation
vermittelt, wird dabei aufgezeigt, wie der Prozess des Risikomanagements
im Bereich der Informationssicherheit betrieben werden sollte.
Umsetzung im
IS-Programm
• Nach einführenden Überlegungen zum Thema IS-Programm gliedert sich
der Studienbrief 4 “Umsetzung im IS-Programm” in zwei wesentliche
Abschnitte. Dabei wird zunächst der Prozess der “Entwicklung eines ISProgramms” behandelt. In diesem Abschnitt wird vermittelt, aus welchen
Komponenten ein IS-Programm besteht und was beim Aufbau eines ISProgramms beachtet werden muss. Anschließend geht der zweite Abschnitt
auf das Thema “Management eines IS-Programms” ein. Dabei werden unter anderem die Fragen, wie ein IS-Programm aufrecht erhalten werden
kann und welche Prozesse dafür aufzubauen sind, behandelt. Insbesondere
wird aber auch thematisiert, wie gewährleistet werden kann, dass die zur
Verfügung stehenden Ressourcen möglichst effizient eingesetzt werden.
Vorfallsmanagement
im Bereich der IS
• Im Studienbrief 5 “Vorfallsmanagement im Bereich der IS” wird vermittelt,
was “im Falle eines Falles” zu tun ist. Dabei werden vor allem die Fallkonstellationen behandelt, die im Rahmen des Risikomanagement nicht bzw.
nicht ausreichend berücksichtigt werden konnten und die somit “unvorhergesehene” Ereignisse darstellen.
Vorgehensweise nach
BSI IT-Grundschutz
• Im Studienbrief 6 “Vorgehensweise nach BSI IT-Grundschutz” wird abschließend vermittelt, was beim Aufbau eines InformationssicherheitsManagementsystems auf Basis von BSI IT-Grundschutz zu beachten ist.
1.6 Studienbegleitende Literatur
Grundlagen
dieses Moduls
Studienbrief 2 bis Studienbrief 5 dieses Moduls sind im Rahmen des Aufbaus
eines IS-Managements eng an die etablierten Vorgehensweise der amerikanischen
Information Systems Audit and Control Association (kurz: ISACA) [7] angelehnt1 , der
Studienbrief 6 orientiert sich an den Vorgaben des “Bundesamts für Sicherheit in
der Informationstechnik” (kurz: “BSI”) nach BSI-Standard 100-2 “IT-GrundschutzVorgehensweise” [2].
Begleitende Literatur
Daher wird die studienbegleitende Lektüre der zugehörigen Literatur empfohlen. Darüber hinaus ist es für ein tieferes Verständnis der Thematik hilfreich, die
grundlegenden Fragestellungen der “Governance” und des “Risikomanagements”
anhand weiterer einschlägiger Literatur zu erarbeiten.
1 Im
Rahmen der Ausbildung zum Certified Information Security Manager (kurz: CISM) wird diese
Vorgehensweise seit vielen Jahren erfolgreich angewendet.
Studienbrief 2 Governance im Bereich der IS
Seite 15
Studienbrief 2 Governance im Bereich der IS
In diesem Kapitel soll ein Verständnis für die Anforderungen einer effektiven
Information Security Governance (kurz: IS-Governance), sowie Kenntnis der Elemente und Vorgehensweisen bei der Entwicklung und Implementierung einer
Information Security Strategie (kurz: IS-Strategie) vermittelt werden. Damit wird in
diesem Kapitel auch die Grundlage für eine angemessene Betrachtung von Risiken
gelegt, und die Voraussetzungen dafür geschaffen, dass das IS-Management die
notwendige Rückendeckung bei der Entwicklung und Implementierung einer organisationsweiten Informationssicherheit von Seiten des Management bekommt.
Ziele dieses Kapitels
Grundlagen der Information Security Governance
Unter Information Security Governance versteht man eine Sammlung von Verantwortlichkeiten (engl.: responsibilities) und Vorgehensweisen (engl.: practices) des
Vorstands bzw. der Aufsichtsgremien und dem Management (engl.: board) bzw.
der Geschäftsführung (engl.: executive managament) einer Organisation, die die
Zielsetzung haben, die Organisation in der Art und Weise strategisch auszurichten, dass die (betrieblichen) Ziele der Organisation erreicht werden und dabei
gleichzeitig die Risiken gemanagt und alle Ressourcen verantwortungsbewusst
eingesetzt werden.
Begrifflichkeit
Information Security
Governance
In diesem Kapitel werden wir - wie bereits der Beschreibung der Ziele zu entnehmen - die Grundlagen kennen lernen, auf deren Basis die IS organisationsweit
effektiv aufgebaut werden kann. Der Manager der Informationssicherheit, kurz:
IS-Manager1 , treibt diesen Prozess voran und ist dafür verantwortlich, dass die hier
zunächst zusammenfassend dargestellten und in den folgenden Abschnitten weiter
ausgeführten Teilschritte umgesetzt werden. Dabei (vgl. dazu auch [7]) handelt es
sich um
Wichtige Teilschritte zum
Aufbau der IS
1. die Erstellung einer Strategie im Bereich der Informationssicherheit, die an
den Geschäftszielen und den Geschäftszwecken des Unternehmens ausgerichtet ist,
2. den Aufbau und die Aufrechterhaltung eines IS-Rahmenwerks, das alle Aktivitäten so steuert, dass sie die IS-Strategie unterstützen,
3. die Ausrichtung der IS-Strategie an der Unternehmensstrategie
(engl.: Corporate Governance),
4. den Aufbau und Aufrechterhaltung von IS-Leitlinien,
5. die Entwicklung von geschäftlich relevanten Fällen, die die IS-Investitionen
stützen und rechtfertigen,
6. die Identifizierung aktueller und zukünftig möglicher rechtlicher und regulatorischer Anforderungen bzw. Randbedingungen bei der IS-Einführung,
7. die Identifizierung möglicher treibender Kräfte,
8. die Definition von Rollen und Verantwortlichkeiten und
1 Der
Begriff “Informationssicherheit” wird im weiteren Verlauf des Textes insbesondere aufgrund
der besseren Lesbarkeit durch die Abkürzung “IS” ersetzt.
Koordination durch den
IS-Manager
Seite 16
Studienbrief 2 Governance im Bereich der IS
9. den Aufbau von internen und externen Kommunikationskanälen.
Die weiteren Abschnitte dieses Kapitels gehen nun auf die konkreten Fragen bei
der Umsetzung dieser einzelnen Teilschritte ein. Dabei werden wir uns zunächst
mit der Frage beschäftigen, warum eine IS-Governance notwendig ist, welche
Aufgaben der IS-Manager übernehmen muss und welche spezifischen Aufgaben
im Bereich der IS-Governance eine Rolle spielen. Zur besseren Einordnung in den
Gesamtkontext werden wir auch die wesentlichen Sicherheitskonzepte nochmals
kurz stichpunktartig wiederholen.
Die Idee des Managementprozesses
Phasen eines
Managementprozesses
Jeder Managementprozess besteht aus vier grundlegenden, in der nachfolgenden
Abbildung 2.1 dargestellten Schritten.
Planung
a) Jeder Zyklus eines Managementprozesses beginnt mit der Planung. In diesem
Teilschritt werden die Anforderungen, die der Prozess erfüllen soll erhoben
und auf Basis dieser die Leistungsmerkmal des Prozesses festgelegt. Gleichzeitig wird auch definiert, wie eine nachfolgende Bewertung des Erfolgs bei
der Umsetzung des Prozesses erfolgen soll.
Vorbereitung
zur Umsetzung
Umsetzung
Kontrolle
b) Nach der im ersten Schritt beschriebenen Planungsphase folgt die konkrete
Vorbereitung zur Umsetzung.
c) Hieran schließt sich die Phase der Umsetzung an.
d) Der letzte Schritt besteht aus der Kontrolle der Umsetzung und der Reaktion
auf geänderte Rahmenbedingungen. Wichtig ist aber nun, dass mit dieser
Phase der Prozess nicht zu Ende ist. Vielmehr entsteht ein Kreislauf: Der
Gesamtzyklus wird, wenn immer es notwendig ist, wiederholt. Dadurch
erreicht man eine kontinuierliche Anpassung des Prozesses an geänderte
Bedingungen und somit einen kontinuierlichen Verbesserungsprozess.
Abb. 2.1: Schematische
Darstellung des PDCAZyklus mit den vier
Phasen “Plan”, “Do”,
“Check” und “Act” [5].
Plan
Act
Do
Check
PDCA-Zyklus
Dieser Managementprozess wird alternativ oft auch als PDCA-Zyklus beschrieben,
wenngleich die Bezeichnung der einzelnen Phasen hier etwas anders definiert ist.
Von William Edwards Deming [5] auf Grundlage der Arbeiten von Walter Andrew
Shewhart [10] eingeführt, beschreibt der PDCA-Kreislauf mit seinen vier Phasen
“Plan”, “Do”, “Check” und “Act” einen ähnlichen Ansatz.
Studienbrief 2 Governance im Bereich der IS
Seite 17
Ursprünglich ging es Deming darum, betriebswirtschaftlich sinnvolle Abläufe bei
der Einführung von Software im Unternehmen zu schaffen2 . Es liegt auf der Hand,
dass vor Entwicklung der Software eine Erhebung stattfinden sollte, was die Software überhaupt leisten soll (“Plan”). Im anschließenden “Do” ist dann -entgegen
der häufig getroffenen Annahme- nicht das Roll-out gemeint, vielmehr geht es
darum, die Anforderungen und die Leistungsfähigkeit der Software abzugleichen
und potentielle Lücken zu identifizieren. Man kann daher beim “Do” auch von
einem Test in kleiner Umgebung sprechen, dieser Tatsache wird heute im Bereich
der IT durch Testumgebungen Rechnung getragen. Der Teilschritt des “Check”
überprüft nun, ob die im “Plan” gesetzten Anforderungen durch die im “Do”
ausgerollte Software erfüllt werden können. Erst im folgenden Schritt des “Act”
hat Deming vorgesehen, dass die Software nunmehr ausgerollt wird, nachdem
die während des “Check” aufgedeckten Defizite beseitigt wurden. Der Kreislauf
schließt sich und der Prozess ist - ebenso wie im klassischen Managementprozess kontinuierlich. Dieser Aspekt ist gerade im Bereich der IT besonders relevant, da
hier bedingt durch neue IT-Prozess und beispielsweise durch Software-Releases
häufig geänderte Bedingungen vorliegen.
Historie des PDCA-Zyklus
Nachdem nun klar geworden ist, warum das Management der IT und insbesondere
auch der IS keine einmalige Angelegenheit ist, sondern einen kontinuierlichen
Prozess darstellt, bleibt noch offen, wie oft die Phasen der Vorbereitung der Umsetzung, der Umsetzung und der Kontrolle der Umsetzung durchlaufen werden
sollen. Dies ist eine oft und zudem kontrovers diskutierte Frage, denn letztendlich benötigt auch der Management-Prozess Ressourcen und darf daher nicht
überstrapaziert werden.
IS ist ein Prozess
Als “Goldene Regel” hat sich folgendes Vorgehen etabliert: Immer wenn es zu
Änderungen in den Geschäftsprozessen kommt, mindestens aber einmal pro Jahr,
werden alle Managamentprozesse auf ihre Wirksamkeit hin überprüft. Bei der
Vielzahl der in einer Organisation anzutreffenden Teilprozesse muss dabei aber
ebenfalls strategisch vorgegangen werden: Es ist eine “priorisierte Liste” notwendig,
da ansonsten nicht sicher gestellt werden kann, dass bei der Vielzahl der Prozesse
auch wirklich alle wesentlichen Prozesse angemessen berücksichtigt werden. Die
Priorisierung innerhalb dieser Liste kann wiederum auf unterschiedlichsten Parametern beruhen, beispielsweise der Relevanz des zu betrachtenden Prozesses für
das Unternehmen.
Goldenen Regel:
Wie oft wird ein PDCAZyklus durchlaufen?
Bei der Umsetzung einer IS-Governance leistet der IS-Manager Hilfestellung. Damit dies sinnvoll funktionieren kann, sollte er einige Voraussetzungen erfüllen:
Zunächst ist die Kenntnis der Anforderungen des Geschäftsbetriebs eine unabdingbare Voraussetzung für den Aufbau einer IS-Governance und den sich daraus
ergebenden weiteren Aspekten im Bereich IS-Management. Wenngleich oft falsch
verstanden, verfolgt die IT einer Organisation keinen Selbstzweck - sie dient vielmehr zur Unterstützung des Geschäftsbetriebs und erfüllt damit eine Dienstleitung.
Dadurch folgt sie den Anforderungen, die sich aus den Anforderungen der Organisation ergeben. Selbiges gilt nun auch für die IS, die sowohl der IT als auch
den Anforderungen aus dem Geschäftsbetrieb folgt - und ebenfalls keinen Selbstzweck verfolgt. Dieser Grundsatz muss bei allen weiteren Planungen entsprechend
berücksichtigt werden.
2 Eine
gute Übersicht zur Entwicklungsgeschichte des Deming-Zyklus findet sich unter
http://apiweb.org/circling-back.pdf
Priorisierung notwendig
IT und IS sind kein
Selbstzweck, sondern
Dienstleistungsfunktionen
Seite 18
Studienbrief 2 Governance im Bereich der IS
Die Rolle des IS-Managers
Aufgaben des IS-Manager
Leitlinien, Standards und Co.
Verständnis für den
Geschäftsbetrieb
Rolle des IS-Manager
Eine der wesentlichen Aufgaben des IS-Manager ist es, dafür Sorge zu tragen,
dass die Maßnahmen im Rahmen des Aufbaus des ISMS umgesetzt werden, und
zudem fortlaufend zu kontrollieren, dass die Sicherheitsleitlinien, -standards und
-arbeitsanweisungen die Geschäftsziele des Unternehmens unterstützen und damit
an der Geschäftsstrategie ausgerichtet sind. Dazu muss der IS-Manager natürlicherweise die Anforderungen des Geschäftsbetriebs verstehen und -das ist jetzt
der wesentliche Schritt- diese in Bezug auf das Thema Sicherheit so umsetzen,
dass die notwendigen Sicherheitsmaßnahmen etabliert werden. Neben dem "Verständnis"der Governance muss der IS-Manager zudem dazu in der Lage sein, die
entsprechenden Anforderungen an die Beteiligten kommunizieren zu können.
Dieser Aspekt ist vor allem deswegen relevant, weil nicht der IS-Manager alle notwendigen Schritte selbst umsetzen wird. Vielmehr ist er der Vermittler (zwischen
den Anforderungen des Geschäftsbetriebs und den eigentlichen Akteuren) und
Kontrolleur (der Einhaltung der Anforderungen, die sich aus der IS-Governance
ergeben).
IS-Governance im Überblick
IS-Governance
im Überblick
Im Rahmen der IS-Governance werden alle (am Prozess) Beteiligten darüber informiert, was von ihnen erwartet wird und welche Regeln dabei einzuhalten sind.
Damit wird gleichzeitig die Basis für kontinuierliche und wiederholbare Prozesse
in der Organisation gelegt. Da die Anforderungen dokumentiert sind, wird zugleich auch ein “moving target” vermieden und es stehen entsprechende Kriterien
für ein Audit zur Verfügung. Darüber hinaus übernimmt die Managementebene
auch die Verantwortung und demonstriert ggb. Mitarbeitern, Geschäftspartner,
Kunden und weiteren Interessensgruppen die “angemessene Sorgfalt” (engl.: due
care).
Zahlreiche
Governance-Aktivitäten
Entsprechende Governance-Aktivitäten, insbesondere die Festlegung formalisierter Regeln, sind in allen (Geschäfts-)prozessen einer Organisation unabdingbar,
bspw. in den Ein- und Verkaufsprozessen oder den Prozessen zur Neu-Anstellung
bzw. Versetzung von Mitarbeitern. Dies gilt auch -sogar insbesondere- im Bereich
der IS, wo die Komplexität der Regeln höher ist und daher ein besonderes Augenmerk darauf zu legen ist, diese den Mitarbeitern “nahe zu bringen” (Stichwort:
Training und Awareness).
Governance ist
Technik-neutral
Beachtet werden muss dabei aber, dass Governance auf Prinzipien bzw. Grundsätzen basiert, die “Technologie-neutral” und vielmehr in “vernünftigen” Zielen und
Idealen verankert sind. So ist bspw. die Anforderung, dass “Informationswerte
vor unbefugtem Zugriff zu schützen sind”, Technologie-neutral formuliert und
geht vielmehr davon aus, dass zum jeweiligen Zeitpunkt eine dazu angemessene
Technologie (früher rein Passwort-basierte Systeme, heute eher Systeme mit einer
Zwei-Faktor-Authentifizierung) eingesetzt wird.
Finanzierung der
Governance-Aktivitäten
Wer in der Organisation die Aktivitäten im Bereich der IS-Governance finanziert,
an wen also der Verantwortliche für den Bereich IS berichtet, hängt von der Eingliederung der IS in der Organisation ab. Generell gilt, dass das Reporting so
hoch wie möglich im Management angesiedelt sein sollte. Allerdings wird dies je
nach Organisationsstruktur unterschiedlch gehandhabt, teilweise berichten die
IS-Verantwortlichen (engl.: Chief Information Security Officer) dem Security-Komittee
oder der Rechtsabteilung, häufig aber auch direkt an die Geschäftsführung bzw.
Leitungsspitze.
Studienbrief 2 Governance im Bereich der IS
Zu den wesentlichen Zielen der IS-Governance zählen
Seite 19
Wesentliche Ziele der
IS-Governance
a) Strategische Ausrichtung (engl.: strategic alignment) an der Strategie der Organisation, um auch im Rahmen der IS die Ziele der Strategie der Organisation
zu unterstützen.
Strategische Ausrichtung
b) Risikomanagement (engl.: risk management), das dazu dient, die Risiken so
weit zu reduzieren, dass ihre Auswirkungen “tragbar” sind.
Risikomanagement
c) Schaffung von Mehrwerten (engl.: value delivery) durch Investitionen in IS,
die die (strategischen) Ziele der Organisation optimal unterstützen.
Mehrwerte schaffen
d) Ressourcenmanagement (engl.: ressource management), dass dazu dient, Wissen und Infrastruktur im Bereich der IS effektiv und effzient zu nutzen.
Ressourcenmanagement
e) Messen der Leistung (engl.: performance management), um die Zielerreichung
durch regelmäßige/kontinuierliche Überwachung und Dokumentation sicher zu stellen.
Leistung messen
f) Einbinden von “Sicherungsfunktionen” (engl.: assurance integration), um
sicher zu stellen, dass die Prozesse wie vorgesehen funktionieren.
Sicherheitsfunktionen
Wichtige Sicherheitskonzepte
Da die Umsetzung des IS-Prozesses ohne entsprechende Maßnahmen nicht möglich ist, diese aber auf grundlegenden Sicherheitskonzepten beruhen, ist ein Verstädnis dieser Konzepte für eine effektive Arbeit des IS-Managers eine unerlässliche
Voraussetzung. Daher wollen wir im Folgenden die wichtigsten Konzepte kurz
zuammenfassend darstellen:
Wichtige
Sicherheitskonzepte
• Vertraulichkeit (engl.: confidentiality) ist die Tatsache, dass sicher gestellt
werden kann, dass nur Berechtigte Zugriff auf Informationen haben. Zur
Sicherstellung der Vertraulichkeit werden häufig kryptographische Mechanismen (bspw. Verschlüsselung) eingesetzt.
Vertraulichkeit
• Integrität (engl.: integrity) ist das Verhindern von unbemerkten Veränderungen durch Integritätssicherungsmaßnahmen. Diese stellen sicher, dass es
nicht zu unbemerkten Veränderungen während sämtlicher Phasen des Lebenszyklusses von Daten kommen kann. Wichtig ist, dass die Veränderung
selber nicht verhindert werden kann, wohl aber Methoden zur Verfügung
gestellt werden können, die es erlauben, eine Veränderung zu bemerken.
Häufig kommen zur Sicherstellung der Integrität kryptographische Maßnahmen, beispielsweise im Zuge einer Digitale Signatur, zum Einsatz.
Integrität
• Verfügbarkeit (engl.: availability) :Im Rahmen der Verfügbarkeit muss sicher
gestellt werden, dass Befugte in angemessener Zeit auf die Daten zugreifen
können. Wichtig sind hier die Aspekte, dass der Zugriff nur für Befugte
möglich sein darf, und dass die Frage, wie schnell auf die Daten zugegriffen
werden können muss, von der Kritikalität des Geschäftsprozesses abhängt,
der diese Daten benötigt.
Verfügbarkeit
• Nicht-Abstreitbarkeit (engl.: non-repudiation) beinhaltet zwei Aussagen: Der
empfangende Kommunikationspartner kann sicher sein, dass die Nachricht
auch tatsächlich vom Absender stammt, und dieser kann nicht bestreiten,
die Nachricht verschickt zu haben. Zur Umsetzung der Nicht-Abstreitbarkeit
Nicht-Abstreitbarkeit
Seite 20
Studienbrief 2 Governance im Bereich der IS
werden häufig kryptographische Mechanismen, insbesondere Digitale Signaturen, eingesetzt.
• Authentifizierung (engl.: authentication) ist die Überprüfung der Identität.
Dies kann anhand von “Wissen” (etwa einem Passwort), “Besitz” (etwa
einer Chipkarte) oder “Sein” (etwa einem Fingerabdruck) geschehen. Je nach
Anzahl der verwendeten Merkmale spricht man von einer Einfaktor- oder
Zwei-/Mehrfaktorauthentifizierung. Der Unterschied zur Authentisierung
besteht darin, dass die agierende Partei eine andere ist. Während sich der
Nutzer an einem System “authentisiert”, “authentifiziert” das System den
Nutzer.
Zugangskontrolle
• Zugangskontrolle (engl.: access control) meint im Deutschen i.d.R. die Überprüfung von Berechtigungen an einem System, also beispielsweise den
Login-Prozess an einem Betriebssystem. Soll dieser Sachverhalt im Englischen ausgedrückt werden, so spricht man -um Missverständnisse zu
vermeiden- auch von “logical access control”. Demgegenüber steht die Zutrittskontrolle (engl.: physical access control), die beim Zutritt zu Räumlichkeiten zum Einsatz kommt. Der eigentliche Zugriff auf Daten wird durch
die Zugriffskontrolle (engl.: data access control) beschränkt.
Authorisierung
• Authorisierung (engl.: authorization) legt fest, welches Subjekt wie auf welches Objekt zugreifen bzw. wie es dieses benutzen darf. Authorisierungsinformationen werden bspw. im Betriebssystem (etwa in Form der Metadaten
im Dateisystem) abgelegt und dann im Rahmen des Zugriffsversuchs überprüft. Dazu muss sicher 1gestellt sein, dass das Subjekt
einwandfrei iden3
tifiziert worden ist - was durch eine ordnungsgemäße Authentifizierung
FW
erreicht werden kann. FW
IDS
IDS
• Layered Defense ist der Ansatz in der IS, Sicherheitsmaßnahmen in unterschiedlichen Schichten des Gesamtsystems einzubringen. Betrachtet man
4
dazu etwa das ISO/OSI-Modell, 2so bedeutet Layered Defense
in diesem Fall,
dass bspw. sowohl auf der Vermittlungsschicht (engl.: network layer, Layer
3), als auch auf der Transportschicht (engl.: transport layer, Layer 4) und der
Anwendungsschicht (engl.: application layer, Layer 7) Sicherheitsmaßnahmen
eingesetzt werden. Dadurch wird sicher gestellt, dass bei Versagen einer
der Sicherheitsmaßnahmen weiterhin verhindert wird, dass ein Angreifer
auf die “Nutzdaten” zugreifen kann. Zu beachten ist dabei allerdings, dass
ein Versagen von Sicherheitsmaßnahmen in einer der unteren Schichten
nicht mehr durch Sicherheitsmaßnahmen in einer der höheren Schichten
kompensiert werden kann.
Layered Defense
DMZ
Abb. 2.2: ”Layered Defense” am Beispiel
der Absicherung oberhalb und unterhalb der
Betriebssystemebene.
Applikation
Zugriffskontrolle
Middleware
Absicherung der DB
Betriebssystem
LAN
Authentifizierung
Zugangskontrolle
Hardware
Zutrittskontrolle
Netzwerk
Network Admission Control
Ein weiteres Besipiel ist in Abbildung 2.2 gezeigt, bei dem in Sicherheitsmechanismen nicht nur im Betriebssystem, sondern auch in den darunter und
darüber liegenden Schichten eingebracht werden.
2.1 Aufbau und Aufrechterhaltung einer IS-Strategie
• Auditierbarkeit (engl.: auditabiliy) :Ein Audit ist ein Instrument für eine systematische, unabhängige und dokumentierte Untersuchung bei der festgestellt
werden soll, ob die geplanten Anforderungen und Ziele eingehalten werden.
Der Begriff Auditierbarkeit bezeichnet also die Tatsache, dass das Auditobjekt über klar definierte Merkmale verfügt und dass entsprechende Kriterien
zur Überprüfung bereits im Vorfeld eines Audits festgelegt werden. Im Rahmen der Auditierbarkeit spielt auch die so genannten Policy-Pyramide eine
Rolle.
Seite 21
Auditierbarkeit
Die Policy-Pyramide
Wie bereits angesprochen bilden die IS-Leitlinie, IS-Standards, sowie ISArbeitsanweisung und IS-Handlungsempfehlungen die so genannte PolicyPyramide3 . Von der Spitze zur Basis nimmt die Änderungshäufigkeit und der
Detailgrad der Dokumente zu. Die IS-Leitlinie ist demnach eher allgemein und
übergreifend formuliert und wird sich -auch weil sie aus der IS-Strategie abgeleitet
ist- eher im 3-5 Jahrestakt ändern. Aufgrund des geringen Detailgrads reichen die
Vorgaben der IS-Leitlinie aber somit auch nicht für ein Audit aus. Im Gegensatz
dazu geben die IS-Arbeitsanweisungen im Detail an, wie die Mitarbeiter vorzugehen haben; sie definieren also, wie die Mitarbeiter die Anforderungen, die sich
aus IS-Standards und letztendlich auch aus der IS-Leitlinie ergeben, zu verstehen
haben. Daraus wird auch ersichtlich, dass sich die IS-Arbeitsanweisungen häufiger
ändern werden, etwa, weil sich die Parametrisierung von kryptographischen
Algorithmen geändert hat. Auditierbarkeit ist ab der Ebene der IS-Standards
gegeben, IS-Handlungsempfehlungen werden als “echte” Empfehlung verstanden
und müssen nicht zwingend befolgt werden.
Policy-Pyramide
Beispielhafte Eigenschaften
Wenden wir uns -nach dieser Darstellung der Grundlagen im Bereich ISGovernance- im nächsten Abschnitt nun den anfangs bereits angesprochenen
Teilschritten zu.
2.1 Aufbau und Aufrechterhaltung einer IS-Strategie
Der Aufbau und die Aufrechterhaltung einer an den Unternehmenszwecken und
vor allem Unternehemnszielen ausgerichteten IS-Strategie ist eines der Kernkonzepte im Bereich des ISMS und vor allem während des Aufbaus eines ISMS wichtig.
Ausgehend von der IS-Strategie wird das IS-Programm aufgebaut und entsprechend fortgeschrieben. Somit bildet die IS-Strategie die wesentliche Grundlage für
alle Elemente des IS-Programms. Unterlaufen dem IS-Manager bzw. den sonstigen
Verantwortlichen bei der Entwicklung der IS-Strategie Fehler, so pflanzen sich
diese in allen Elementen des IS-Programms fort und verursachen damit erhebliche
Korrekturaufwände.
Von der IS-Strategie zum
IS-Programm
Grundlegend ist zunächst die Frage, was überhaupt als Strategie verstanden wird.
Dass sich die IS-Strategie aus der Unternehmensstrategie ableitet, wurde bereits
erwähnt. Was aber bedeutet “Strategie” in diesem Fall? Hier kann man unterschiedliche Perspektiven der Bedeutung aufzeigen: Zum einen ist eine Strategie
im Gegensatz zu taktischen und operativen Maßnahmen grundsätzlich durch
einen übergreifenden, längerfristigen und großflächigeren Ansatz geprägt. Auf der
anderen Seite bezeichnet eine Strategie aber auch in weniger formaler Hinsicht eine
Was ist die IS-Strategie?
3 Für
die detaillierte Diskussion zur IS-Policy-Pyramide siehe auch Abschnitt “Aufbau und Fortschreibung eines IS-Policy Frameworks“
Seite 22
Studienbrief 2 Governance im Bereich der IS
Sammlung von Sicherheitszielen, Prozessen sowie Methoden, Werkzeugen und
technischen Verfahren. Letztendlich führen aber beide Bedeutungen im Bereich des
ISMS in die gleiche Richtung: Der Schaffung von übergreifenden Lösungsansätzen
für spezifische Probleme.
IS-Strategie ist kongruent
zur Geschäftsstrategie
Anerkennung durch
die Mitarbeiter
Ein wichtiger Aspekt ist, dass sich die IS-Strategie kongruent zur Geschäftsstrategie und damit zu den übrigen Geschäftsprozessen ausrichten muss. Konträre
oder nicht angemessene Ansätze sind zum Scheitern verurteilt, da die Notwendigkeit nicht erkannt bzw. die Ansätze als Hemmnisse gesehen werden. So würde
Sicherheit auf einem Niveau, das typischerweise im Bankensektor vorzufinden
ist, von großen Teilen der mittelständischen Industrie schlichtweg nicht akzeptiert
werden. Im Gegensatz dazu begünstigt eine an den sonstigen Geschäftsprozessen ausgerichtete IS-Strategie (und damit auch ein entsprechend ausgerichtetes
IS-Programm) die Akzeptanz und damit letztendlich auch die (finanzielle) Unterstützung durch das Management. Nicht weniger wichtig ist aber auch der Aspekt,
dass auch die Mitarbeiter einer Organisation erkennen, dass die Elemente eines
ISMS sie nicht bei ihrer Arbeit hemmen, sondern letztendlich die Geschäftsprozesse sogar unterstützen. Erst dadurch wird die IS auch von den IT-Nutzern und den
Mitarbeitern umgesetzt, sie wird im Unternehmen gelebt.
Anforderungen an
den IS-Manager
Damit das Ziel, die IS-Strategie an der Unternehmensstrategie auszurichten, erreicht werden kann, muss der IS-Manager derjenige sein, der allen voran ein
Verständnis für die Sichtweise, den Auftrag und die Werte des Geschäftsbetriebs
entwickelt. Insbesondere ist es auch wichtig, dass er die Geschäftsziele und die
dazu notwendigen (kritischen) Geschäftsprozesse versteht. Nur dadurch kann
letztendlich auch die IS-Strategie sinnvoll an den Geschäftszielen ausgerichtet
werden. Informationen zur Geschäftsstrategie finden sich in Unternehmen in unterschiedlichsten Bereichen, meist existiert aber keine spezielle Beschreibung der
Unternehmensstrategie bzw. keine Übersicht zu den bereits vorhandenen Informationen.
Elemente der Strategie
Einzelne und ggf. auch explizite Aussagen zur Strategie finden sich aber etwa in
unterschiedlichen Äußerungen des Unternehmens. So kann als interne Quelle etwa
das Mitarbeiterhandbuch dienen, als externe zugängliche Quelle kommen etwa
Aussagen in den Jahresabschlüssen oder auch auf der Webseite des Unternehmens
in Frage. Eine besondere Schwierigkeit für den IS-Manager stellt nun die Sichtung
all dieser Aussagen dar, denn häufig werden sich die Verfasser der einzelnen Quellen nicht mehr daran erinnern, dass sie Aussagen zur Strategie der Organisation
getroffen haben. Neben “echten” strategischen Elementen können auch eher technische Fragestellungen im Kontext des IS-Management als strategisch bezeichnet
werden. Dies trifft beispielsweise für die Aspekte der Authentifizierung (Stichwort:
Identity Management), der Authorisierung (Stichwort: rollenbasiert) oder auch der
Administration (Stichwort: Einsatz eines Helpdesk) zu. Darüber hinaus kommen
aber eher übergeordnete Aspekte, wie etwa die Frage von “Enabling Technologies”
oder der Organisationsstruktur (etwa anhand der Fragestellung “Wo ist der CISO
angesiedelt?”) in Betracht.
Strategische Elemente
Desired State
Abbildung der Strategie
Die IS-Strategie bildet -wie bereist erläutert- die längerfristige Perspektive im
Bereich des ISMS ab. Zur konkreten Umsetzung ist es nun aber erforderlich, Werkzeuge zu nutzen, die die Abbildung der strategischen Ziele messbar machen. Dazu
können unterschiedlichste Ansätze genutzt werden, bspw. die der ISO 27000erSerie, die Vorgaben im Bereich IS aus den Control Objectives for IT (COBIT) [6], dem
Ansatz der Balanced Scorecard [8] oder auch nach dem Capability Maturity Model
(CMM) [11].
Mögliche Probleme
Wie immer kann es auch bei der Entwicklung der IS-Strategie zu Problemen kommen. Insbesondere im Falle, dass der IS-Manager die strategische Ausrichtung
2.2 Aufbau und Aufrechterhaltung eines IS-Governance Frameworks
Seite 23
und Ziele der Organisation nicht oder falsch verstanden hat, wird die IS-Strategie
in die falsche Richtung laufen. Hier kann aber auch fehlendes Engagement der
Geschäftsleitung ein Problem sein, wenn diese nicht genügend Input bei der Ableitung der IS-Strategie liefert. Umgekehrt ist es auch problematisch, wenn der
IS-Manager seine Ergebnisse nicht oder in falscher Form an das Management
zurück kommuniziert. Letztendlich führen beide Aspekte in der Regel früher oder
später zu dem Problem, dass das Management nicht genügend Unterstützung gibt
und im Krisenfall die Aspekte der IS nicht ausreichend Berücksichtigung finden.
2.2 Aufbau und Aufrechterhaltung eines IS-Governance
Frameworks
Zur Umsetzung der aus der IS-Strategie abgeleiteten Aktivitäten ist ein Governance
Framework sehr hilfreich. Diese unterstützt den IS-Manager bei der Aufgabe, die
einzelnen Aktivitäten so zu lenken, dass sicher gestellt werden kann, dass es nicht
zu konträren Entwicklungen kommt. Zu diesem Governance Framework gehören
mehrere Komponenten:
Unterstützung durch ein
IS-Governance Framework
a) Eine übergreifende Sicherheitsstrategie, die mit den Geschäftszielen verknüpft ist und die Unterstützung (im Sinne von Entscheidungsbefugnissen
und Ressourcen) durch das Management erfährt,
IS-Strategie
b) Sicherheitsleitlinien, die alle Aspekte der Strategie adressieren,
IS-Leitlinien
c) Standards zu jeder Leitlinie, die sicherstellen, dass die aus dem Standard
abgeleiteten Arbeitsanweisungen und Orientierungshilfen zur Leitlinie und
damit auch zur Strategie passen, und
IS-Standards
d) Metriken und Monitoring-Prozesse, die sicher stellen, dass kontinuierlich
und prozessbasiert die Effektivität der Umsetzung der IS-Strategie gemessen
werden kann und dem Management dadurch eine Entscheidungsgrundlage
zur Verfügung gestellt wird.
IS-Metriken
IS-Monitoring
Auf die einzelnen Elemente dieses Governance Frameworks gehen wir in den
weiteren Abschnitte noch im Detail ein.
Probleme in diesem Bereich sind häufig durch ein mangelhaftes Verständnis der
Geschäftsziele und Geschäftszwecke begründet. Dies führt i.d.R. dazu, dass die ISStrategie nicht oder nur unzureichend an der Geschäftsstrategie ausgerichtet ist. Ein
weiteres Problem besteht in einem mangelnden Verständnis der regulatorischen
Anforderungen.
Mögliche Probleme
2.3 Integration der IS-Governance in die Corporate
Governance
Effektive Prozesse im Bereich der IS lassen sich dadurch schaffen, dass die Prozesse
der IS in die Standardprozesse der Organisation integriert werden. Dadurch kann
letztendlich sicher gestellt werden, dass das IS Programm die Ziele und Zwecke der
Organisation unterstützt - es wird vermieden, dass sich eine Parallelwelt entwickelt,
in der die IS ihr Ding macht. Stattdessen versucht man nun, bereits existierende
Prozesse wieder zu benutzen.
Grundlage einer
effektiven IS
Seite 24
Studienbrief 2 Governance im Bereich der IS
Vorhandene Strukturen nutzen
Entwicklungsstand
IS-Governance
Vorteile der Ausrichtung an der Corporate Governance
So haben viele Organisation aufgrund der Corporate Governance bereits ein verabschiedetes Governance Framework. Dazu gehören definierte Strukturen, Prozesse
also bspw. entsprechende Freigabe- und Zustimmungsmechanismen, zugeordnete
Verantwortlichkeiten und Eigentümerschaften. Diese Strukturen können und sollten im Bereich der IS-Governance nun wieder aufgriffen werden. Wenngleich die
IS-Governance an der Corporate Governance ausgerichtet sein sollte, stellt man
doch immer wieder fest, dass die IS-Governance in Organisationen am weitesten
entwickelt ist. Die Gründe hierfür liegen vor allem in den zahlreichen rechtlichen und regulatorischen Anforderungen im Bereich der IT und der IS. So kann
unter Umständen auch die IS-Governance als Vorbild für Elemente der Corporate Governance dienen, in IT-spezifischen Feldern einer Organisation, aber auch
außerhalb.
Falls es gelingt, die IS-Governance an der Corporate Governance auszurichten,
resultieren daraus eine Reihe von Vorteilen, die in unterschiedlichen Ebenen der
Organisation anzusiedeln sind. Dazu gehören bspw.
• eine erweiterte Möglichkeit der Steuerung und des Monitoring von Prozessen,
• reduzierte Kosten durch eine höhere Standardisierung,
• eine größere Akzeptanz durch Anwendung anerkannter Standards,
• eine Steigerung des (nutzbaren) Potentials der Mitarbeiter durch angemessenes Training sowie
• die Reduktion bzw. Vermeidung von Fehlern und Risiken.
Mögliche Probleme
Das Hauptproblem in diesem Bereich besteht darin, dass die Anforderungen der
Organisation nicht ausreichend in der IS-Governance berücksichtigt sind oder dass
die kritischen Anforderungen im Bereich der IS nicht ausreichend berücksichtigt
werden, weil die Aspekte der Governance nicht verstanden bzw. nicht akzeptiert
sind oder schlichtweg ignoriert werden. Ein weiteres Problem besteht darin, dass
bereits bestehende Prozesse (bspw. für Reviews oder Updates) oder auch die
vorhandene Infrastruktur nicht genutzt werden.
2.4 Aufbau und Fortschreibung eines IS-Policy Frameworks
Policy Framework
Zur Kommunikation der vom Management der Organisation aufgestellten Leitlinien an die Arbeitsebene und damit letztendlich auch zur Umsetzung der in den
Leitlinien vorgegebenen Ziele ist ein Policy Framework unverzichtbar. Erst durch
die Erstellung von angepassten Standards, Arbeitsanweisungen und Handlungsempfehlungen kommen die notwendigen Konzepte bei den Mitarbeitern der Organisation an, die diese auch in der Praxis umsetzen müssen. Die IS-Policy-Pyramide4
bildet gleichzeitig aber auch die Grundlage dafür, dass dokumentierte, sowie messund wiederholbare IS-Prozess in einer Organisation geschaffen werden. Erst durch
formale IS-Prozesse wird wiederum die Grundlage für eine effektive und effiziente
Umsetzung der Ziele im Bereich der IS gelegt.
Policy-Pyramide
Innerhalb der Policy-Pyramide bestehen unterschiedliche Ebenen, die nun im
folgenden näher batrchtet werden sollen. Abbildung 2.3 stellt die Policy-Pyramide
schematisch dar.
4 Im
Folgenden verwenden wir den Begriff “Policy-Pyramide” synonym für “IS-Policy-Pyramide”,
sowie die Bezeichnungen der einzelnen Ebenen der Policy-Pyramide in gleichwertiger Form ohne
den Zusatz “IS”.
2.4 Aufbau und Fortschreibung eines IS-Policy Frameworks
Gehen wir nun im Detail auf die einzelnen Elementen der Policy-Pyramide ein:
Seite 25
Elemente der
Policy-Pyramide
Leitlinen
• Die zweite Ebene der Policy-Pyramide bilden die Standards (engl.: standards),
die die Grundlagen zur Umsetzung der Leitlinien liefern. Standards müssen
so geschrieben sein, dass sie die Leitlinien vollständig abdecken und keinerlei Widersprüche erzeugen. Gleichzeitig bieten Standards auch messbare
Kriterien (vgl. dazu auch Abbildung 2.4), mit denen sich die Effektivität und
Effizienz der Prozesse im Bereich der IS bestimmen lässt.
Standards
• Auf der dritten Ebene liegen die Arbeitsanweisungen (engl.: procedures).
Diese enthalten konkrete Anweisungen zur Umsetzung der Standards.
Arbeitsanweisungen
• Auf der untersten Ebene finden sich schließlich die Handlungsempfehlungen (engl.: guidelines) in denen Hilfestellungen zur Umsetzung der Arbeitsanweisungen gegeben werden.
Handlungsempfehlungen
zunehmende
Detaillierung
Policy
Standards
Procedures
zunehmende
Änderungshäufigkeit
• Auf der ersten Ebene und damit an der Spitze einer Policy-Pyramide stehen die Leitlinien (engl.: policies), die die wesentliche Ziele im Bereich der
Informationssicherheit wiederspiegeln; sie werden von der Leitung der
Organisation verabschiedet.
Abb. 2.3: Schematische
Darstellung der PolicyPyramide mit den vier
Elementen “Policies”,
“Standards”, “Procedures” und “Guidelines”.
Guidelines
Darüber hinaus gibt es auch die Darstellungsvariante, in der die IS-Strategie auf
oberster Ebene oberhalb der Pyramide steht. Damit wird zusätzlich verdeutlicht,
dass die IS-Strategie letztendlich die Grundlage zur Ableitung der Dokumente der
Policy-Pyramide darstellt.
IS-Strategie als Basis
Bei der Erstellung der Dokumente der Policy-Pyramide sind zunächst einige grundlegende Anforderungen zu berücksichtigen, die im weiteren noch im Detail beschrieben werden. Wichtiges Kriterium ist unter anderem, dass die Dokumente
der unteren Hierachieebenen so gestaltet werden müssen, dass sie die Dokumente
der jeweils darüber liegende Ebene vollständig abdecken und dabei auch keinerlei inhaltliche Widersprüche entstehen. So muss etwa für jede Leitlinie ein Satz
von Standards geschaffen werden, der die Ziele der Leitlinie verdeutlicht und
gleichzeitig eine Schnittstelle zur Umsetzung der Leitlinie mit Hilfe von Arbeitsanweisungen und Handlungsempfehlungen schafft. Für jeden Standard ist wiederum
ein Satz von Arbeitsanweisungen zu erstellen, der nunmehr konkret vorgibt, wie
die Anforderungen aus den Standards und damit letztendlich die Ziele der Leitlinie in der Praxis realisiert werden sollen. Die Handlungsempfehlungen schließlich
geben denjenigen, die die Arbeitsanweisungen umsetzen, weitere Hilfestellung,
wie dies möglichst effizient realisiert werden kann.
Anforderungen an die
Dokumente der PolicyPyramide
Während die Leitlinien allgemeine Aussagen treffen und daher einen eher geringen
Detailgrad aufweisen, nimmt der Detaillierungsgrad bis zu den unterliegenden
Detaillierungsgrad
Seite 26
Studienbrief 2 Governance im Bereich der IS
Durchführung
von Änderungen
Basisdokumenten, bspw. den Handlungsempfehlungen, immer weiter zu. Gleichzeitig werden diese Dokumente, die ja auch die Basis der Policy-Pyramide bilden,
auch wesentlich häufiger geändert werden. Dies ergibt sich nicht zuletzt auch
aus dem Umstand, dass in den Arbeitsanweisungen und Handlungsempfehlungen bspw. detaillierte Konfigurationen der verwendeten Software dokumentiert
sind, die sich aber mit einem Update der Software ändern können. In der Folge sind dann etwa die Handlungsempfehlungen anzupassen, wobei darauf zu
achten ist, dass die geänderten Handlungsempfehlungen immer noch die Arbeitsanweisungen abdecken. Sollte dies nicht mehr der Fall sein, sind zunächst die
Handlungsempfehlungen zu überarbeiten. Falls auch dadurch keine Kongruenz
zu den Arbeitsanweisungen mehr erreicht werden kann, sind die Arbeitsanweisungen selbst zu überarbeiten. Dabei ist wiederum darauf zu achten, dass diese
Änderungen nicht dazu führen, dass die Arbeitsanweisungen nicht mehr kongruent zu den Standards sind. Für die Standards gilt wiederum das gleich in Bezug
auf die Leitlinien.
Messbarkeit
der Umsetzung
Die Leitlinien enthalten - wie bereits weiter oben beschrieben - Anforderungen auf
einem hohen Abstraktionsgrad. Dadurch bedingt lässt sich der Umsetzungsgrad
dieser Anforderungen aber nicht mehr direkt messen, es fehlen schlichtweg sinnvolle Kriterien. Erst mit den Standards werden messbare Kriterien eingeführt, die
dazu dienen können, den Umsetzungsgrad und auch die Effektivität und Effizienz
der IS-Prozesse zu bestimmen. Dieser Vorgang wird im Rahmen der Betrachtung
des IS-Programms noch von wesentlicher Bedeutung sein.
Verpflichtung
oder Empfehlung
Auch bezüglich der Frage, bis zu welcher Ebene der Policy-Pyramide die Anforderungen in den Dokumenten auch tatsächlich verpflichtend umzusetzen sind,
lässt sich häufig keine scharfe Grenze ziehen, Abbildung 2.4 verdeutlicht diesen
Sachverhalt. Während die Anforderungen der Leitlinien in jedem Fall verpflichtend
(enlgl.: must comply) umzusetzen sind, werden Teile der Standards und die Arbeitsanweisungen häufig nur noch als eine mögliche Form der Umsetzung verstanden
werden (engl.: should comply).
Guidelines
freiwillig
Procedures
Standards
verpflichtend
Policy
Abb. 2.4: Veranschaulichung der Kriterien
“Umsetzungsverpflichtung” und “Messbarkeit”
für die einzelnen Elemente der Policy-Pyramide.
Vorgaben sind messbar
Damit wird ein gewisser Spielraum bei der konkreten Umsetzung der Anforderungen aus den Leitlinien eingeräumt. Die Handlungsempfehlungen sind schließlich
als reine Empfehlung zu verstehen, die eine effiziente Umsetzung der Anforderungen aus den Arbeitsanweisungen ermöglicht.
Gestaltung einer
Policy-Pyramide
Die Bezeichnungen der Dokumente der einzelnen Ebenen der Policy-Pyramide
variieren durchaus von Organisation zu Organisation. Eine Hilfestellung, welcher
Ebene ein konkretes Dokument zuzuordnen ist, kann vielmehr aus der Fragestellung entnommen werden, wie der Detailgrad des Dokumentes ggb. anderen
2.5 Business Cases - Entwicklung von praxisnahen Beispielen
Seite 27
Dokumenten aus der Policy-Pyramide ist und ob die konkrete Umsetzung verpflichtend ist. Auch die Anzahl der durch Dokumente manifestierten Ebenen einer
Policy-Pyramide ist in gewissen Grenzen variabel; dabei sollte es aber aus Gründen
der Übersichtlichkeit und Handhabbarkeit im Normalfall nicht weniger als zwei
und nicht mehr als vier Ebenen geben.
Probleme in diesem Bereich sind häufig durch eine fehlende Einbindung der
Anforderungen im Bereich der IS begründet. Dadurch kommt es bereits bei der
Entwicklung der IS Leitlinien zu Fehlern, die sich dann in allen Dokumenten
auswirken. Bei der Erstellung der Leitlinien muss daher besonders sorgsam und
überlegt vorgegangen werden, um sehr zeitaufwendige Korrekturen in den darunter liegenden Dokumenthierarchien zu vermeiden. Zudem mangelt es häufig
auch an ausreichendem Verständnis der grundlegenden Prozesse. Dadurch wiederum werden falsche Zielvorstellungen kommuniziert, die sich ebenfalls durch
fehlerhafte Leitlinien manifestieren.
Mögliche Probleme
2.5 Business Cases - Entwicklung von praxisnahen
Beispielen
Ressourcen sind in jeder Organisation ein knappes Gut. Allein aus dieser einfachen,
aber im Einzelfall sehr häufig übersehenen Tatsache ergibt sich die Notwendigkeit,
bei der Umsetzung der Anforderungen der IS möglichst effektiv und effizient
vorzugehen. Dazu sind als Basis bspw. auch die Ergebnisse des Risikomanagement
ein wichtiger Faktor, die im folgenden Kapitel erarbeitet werden sollen. In dem
folgenden Abschnitt gehen wir zunächst auf die Frage ein, wie der IS-Manager
das Management von der Notwendigkeit und Sinnhaftigkeit von Maßnahmen im
Bereich der IS überzeugen kann.
Notwendigkeit von
Business Cases
Um das Management von der Notwendigkeit der Finanzierung von Maßnahmen
im Bereich der IS oder im allgemeinen von der Bereitstellung von Ressourcen zu
überzeugen, muss der IS-Manager in allererster Linie die richtige Sprache treffen.
Es nützt im Allgemeinen nur sehr wenig, wenn dem Management die technischen
Vorzüge einzelner Maßnahmen erläutert werden und das Gesamtbild für die Organisation dabei auf der Strecke bleibt. Viel sinnvoller ist es, die Lösungen für
Probleme im Bereich der IS anhand von konkreten und aus Sicht des Managements sinnvollen Praxisbeispielen (engl.: Business Case) aufzuzeigen; dabei sollte
möglichst prägnant dargestellt werden, dass der Nutzen die Kosten übersteigt.
Meist taucht dabei doch das Problem auf, dass sich die Kosten für Maßnahmen im
Bereich der IS in der Regel einfacher angeben lassen, als deren konkreter Nutzen;
auf diesen Sachverhalt werden wir bei der Betrachtung des Return on Security
Investment (kurz: RoSI) noch genauer eingehen.
Überzeugung des
Managements
Zudem ist bei der Betrachtung der Vorteile der Maßnahmen im Bereich des ISManagement zwischen quantifizierbaren Kosteneinsparungen, quantifizierbaren
Reduktion von Risiken und rein qualitativ messbaren Vorteilen zu unterscheiden.
Fall 1 “quantifizierbaren Kosteneinsparungen” stellt die optimale Ausgangsbasis
für einen Business Case dar, Beispiele sind etwa eine automatisierte Nutzerverwaltung bzw. generell Werkzeuge, die quantifizierbare Vorteile (im Bereich ISManagement) haben. Fall 2 “quantifizierbaren Reduktion von Risiken” bedeutet in
der Regel, dass durch die Maßnahmen im IS-Management die Wahrscheinlichkeit
des erfolgreichen Ausnutzens spezifischer Sicherheitslücken und/oder das Auftreten von Sicherheitsverstößen reduziert wird. Hier lassen sich aber keine direkten
Einsparungen messen, vielmehr handelt es sich um indirekte Einsparungen bzw.
Quantifizierbare Kosteneinsparungen
Quantifizierbare Reduktion von Risiken
Seite 28
Studienbrief 2 Governance im Bereich der IS
Rein qualitativ
messbare Vorteile
das reine Vermeiden von Wertabflüssen. Fall 3 mit “rein qualitativ messbaren Vorteilen” bietet zwar bzgl. der Überzeugung des Managements die größten Probleme.
Auf der anderen Seite lassen sich für diesen Fall aber auch die meisten Beispiele
finden (hohe Integrität der Daten, schnelle Reaktion auf Sicherheitsvorfälle, ...).
Vielfältige
Einflussfaktoren
Im Rahmen der Erstellung eines Business Case sind vielfältige Einflussfaktoren
zu berücksichtigen. Wichtigen Input liefern unter anderem die Ergebnisse des
Monitoring bzw. Auditing, etwa von Compliance-relevanten Prozessen. Gerade
Compliance-relevanten Fragestellungen finden Gehör auf der Entscheiderebene,
da mittlerweile bekannt ist, welche Verpflichtungen und Verantwortlichkeiten in
diesem Bereich angesiedelt sind. Der IS-Manager kann so auch seine Belange im
Bereich der IS besser platzieren, da eine entsprechende Kommunikationsstruktur
beim Management bereits vorhanden ist. Für die konkrete Darstellung des Business
Case sind zudem weitere Faktoren wichtig. So müssen auch Voraussetzungen -wie
bspw. bereits definierte Verantwortlichkeiten und Zuständigkeiten- sowie mögliche
Folgen der Investitionen in den Bereich IS berücksichtigt werden. Zu letzterem
gehören etwa die Notwendigkeit für Schulungs- und Trainingsmaßnahmen und
die Definition von Meilensteinen und Ermittlung der notwendigen Ressourcen.
Entwicklung und
Gestaltung eines
Business Cases
Da der Business Case dazu dient, die notwendigen Ressourcen für die Umsetzung
von Sicherheitsmaßnahmen zu bekommen und sich daher an die Entscheiderebene im Unternehmen wendet, ist bei der Zusammenstellung des Business Case
besonderes Augenmerk auf “Verständlichkeit” zu richten. Vor allem technische
Details sollten eine untergeordnete Rolle spielen und eher ergänzend betrachtet
werden. Die Überzeugung und Unterstützung durch das Management kann positiv beeinflusst werden, wenn der Praxisbezug des Business Case hoch ist und
erkennbar ist, dass er an den Geschäftszielen des Unternehmens ausgerichtet ist.
Weiter unterstützend wirken sich die Anwendung von allgemein anerkannten
Messkriterien aus, hier sind Scorecard-Modelle und die Kennzahlen RoI bzw. RoSI
zu nennen.
Zur Ableitung des RoSI
Um eine Kennzahl für den (positiven) Nutzen von Maßnahmen im Bereich der
Informationssicherheit zu haben, wurde die Kennzahl des Return on Security Investment (kurz: RoSI) entwickelt. Diese ist angelehnt an den Return on Investment (RoI)
und gibt letztendlich an, wie hoch die Rendite einer Investition -in unserem Falle
im Bereich der IS- ist. In einfachster Betrachtung lässt sich der RoSI dabei wie folgt
bestimmen: Wenn S der (durch den Einsatz der Sicherheitsmaßnahmen) vermiedene Schaden (engl.: savings) ist, und T die Kosten für die Sicherheitsmaßnahmen
(engl.: toolcosts), dann gilt RoSI = S - T. Vom vermiedenen Schaden (den Savings)
müssen noch die Kosten (die Toolcosts) abgezogen werden und so erhält man den
Return on Security Investment.
Aufbau eines
Business Case
Jeder Business Case besteht i.d.R. aus wiederkehrenden Elementen: Nach einem
Executive Summary, die dem Management in knapper Form die wesentliche Inhalte und damit eine erste Entscheidungsgrundlage liefern soll, wird zunächst
das Problem anhand der Beschreibung des aktuellen Zustandes geschildert. Die
folgende Projektbeschreibung gibt die einzelnen Schritte des geplanten Projektes
wieder und zeigt die Lösung für die anfangs geschilderten Probleme auf. Zur
besseren Einschätzung durch das Management wird die Projektplanung durch
eine Kosten-Nutzen-Analyse und einen Zeitplan zur Umsetzung ergänzt. Eine
kritische Betrachtung und Risikobewertung, sowie abschließende Empfehlungen
bilden die letzten Bestandteile eines Business Case.
Bestimmung
der Toolcosts
Die Kosten, die bei Umsetzung der zu betrachtenden Sicherheitsmaßnahmen entstehen, sind meist einfach zu bestimmen. Lediglich bei den Kosten, die nur anteilig
anfallen, ist eine Abgrenzung ggb. den normalen “Betriebskosten” ohne Sicherheitsmaßnahmen oft nicht einfach zu realisieren. In der Praxis ist aber vor allem die
Bestimmung der Savings
2.6 Berücksichtigung von internen und externen Faktoren
Bestimmung des vermiedenen Schadens schwierig, denn Sicherheitsinvestitionen
haben in den allermeisten Fällen keinen unmittelbar quantifizierbaren Nutzen,
sondern vermeiden lediglich Wertabflüsse. Zudem sind für die Ermittlung des
vermiedenen Schadens regelmäßig die Ergebnisse einer Risikoanalyse notwendig. Für eine sinnvolle Risikoabschätzung werden aber -neben Bedrohungen und
Schwachstellen- Eintrittswahrscheinlichkeiten von Schadenereignissen benötigt,
die häufig nicht oder nur unzureichend vorliegen. Dadurch wird aber auch die
Ermittlung des Schadenswertes, der durch ein eingetretenes Risiko verursacht
werden kann, nur schwer kalkulierbar. Auf diese Problematik gehen wir im Studienbrief 3 “Risikomanagement” noch genauer ein.
Neben den angesprochenen Schwierigkeiten bei der Bestimmung und Bewertung
der Maßzahlen im Bereich der Sicherheitsinvestitionen besteht ein weiteres Hauptproblem bei der Darstellung des Business Case und Kommunikation desselben
mit dem Management. Insbesondere wenn der IS-Manager technischen Hintergrund hat, muss unbedingt darauf geachtet werden, dass technische Details im
Business Case nicht die entscheidende Rolle spielen. Ohne ausreichende KostenNutzen-Analyse, die einen quantifizierbaren Nutzen darlegt, wird das Projekt in
vielen Fällen nicht akzeptiert werden. Ursache ist aber meist nicht der fehlende,
quantifizierbare Nutzen, Ursache ist vielmehr eine fehlerhafte Kommunikation mit
Konzentration auf Nicht-Management-Faktoren. Rein qualitative Aspekte zählen
nicht, sie werden das Management nicht von der Sinnhaftigkeit überzeugen.
Seite 29
Problem:
Eintrittswahrscheinlichkeiten
Mögliche Probleme
2.6 Berücksichtigung von internen und externen Faktoren
Neben der Berücksichtigung von Geschäftszielen und der zugrunde liegenden
Geschäftsstrategie gibt es eine Reihe weiterer interner, aber auch externer Einflussfaktoren, die bei der Entwicklung der IS-Strategie eine Rolle spielen. Dazu zählen
zum einen Faktoren, die direkte Auswirkungen auf die Sicherheitsfragestellungen
in den Unternehmen haben, aber auch Faktoren, bei denen eine eher indirekte
Beeinflussung gegeben ist.
Interne und externe
Einflussfaktoren
Direkten Einfluss auf die Sicherheitsfragestellungen in der Organisation haben
sowohl wirtschaftliche, als auch technologische Fragestellungen.
Wirtschaftliche und
technische Aspekte
• Zu den eher wirtschaftlichen Aspekten zählen in erster Linie die Aspekte Fusionen und Zukäufe, sowie die Thematik rund um das Outsourcing.
Neben diesen Aspekten sind aber auch die Fragen rund um die Risikotoleranz, sowie des gesamten Risikoprofils der Organisation zu betrachten,
hinzu kommen aber auch aktuelle Sicherheitstrends (hier aus der nichttechnischen Seite), die die Organisation zu einer Anpassung ihrer eigenen
Sicherheitsmaßnahmen veranlassen.
• Bei den technischen Aspekten ist vor allem der Bereich der “Sicherheit” der
genutzten Betriebsumgebung und der verwendeten Werkzeuge zu nennen,
auch der Reifegrad der IT-Umgebung spielt eine Rolle. Hinzu kommen weitere technische Aspekte, wie beispielsweise die Netzwerkanbindung (sowohl
intern als auch extern), aber die auch die Verwendung von Sicherheitstools.
Neben diesen wirtschaftlichen und technischen Aspekten spielen im Rahmen
der IS-Governance einer Organisation auch die rechtlichen und regulatorischen
Fragen eine immer größere Rolle. Der IS-Manager hat dabei Sorge zu tragen, dass
die möglichen Auswirkungen der zahlreichen rechtlichen und regulatorischen
Aspekte im Bereich der IS entsprechend berücksichtigt werden. Er hat zudem
sicher zu stellen, dass die entsprechenden Regeln umgesetzt werden - er überwacht
Rechtliche und
regulatorische Aspekte
Seite 30
Studienbrief 2 Governance im Bereich der IS
also diejenigen, die die Umsetzung selbst vornehmen. Insbesondere im Bereich
Datenschutz und Datensicherheit sind in den letzten Jahren die Anforderungen
gestiegen. Dies ist zum einen auf direkte gesetzliche Regelungen zurück zu führen,
zum anderen haben sich aber auch in verschiedenen Bereichen der IT-Wirtschaft
industriespezifische Compliance-Anforderungen etabliert.
PCI DSS als Beispiel einer
industriespezifischen
Compliance-Anforderung
Im Rahmen der industriespezifischen Compliance-Anforderungen ist vor allem
der Payment Card Industrie Data Security Standard (PCI DSS) [9] des PCI Council zu
nennen. Er legt die Sicherheitsmaßnahmen fest, die Organisationen, die Kreditkartendaten prozessieren (wollen), umsetzen müssen, damit sie nicht für etwaige
Schäden voll haften und wird federführend von den beiden Kreditkartenunternehmen Mastercard und VISA vorangetrieben. PCI DSS beinhaltet strenge Regelungen
für den Aufbau der IT, die die Kreditkartendaten prozessieren soll, und beinhaltet
die folgenden sechs wesentlichen Bereiche:
• Aufbau und Weiterentwicklung eines sicheren Netzwerkes, bspw. durch
Nutzung einer Firewall und Ersetzen der Hersteller-spezifischen DefaultPassworte
• Schutz der Kreditkarteninformationen, bspw. durch Schutz der Kreditkarteninformationen durch Verschlüsselung während Transport und Speicherung
• Aufbau eines Programms zum Management von Schwachstellen, bspw.
durch Einsatz von Anti-Malware-Programmen und dem Einsatz sicherer
Software
• Einsatz von starken Mechanismen zur Zugangskontrolle, bspw. durch strikte
Umsetzung des Need-to-know-Prinzips beim Zugriff auf die Kreditkarteninformationen
• Regelmäßiges Monitoring und Test der Netzwerkinfrastruktur, bspw. durch
Einsatz einer automatisierten Netzwerküberwachung mittels Softwaretools
• Einsatz einer Security Policy, bspw. durch Entwicklung einer Policy, die auch
die Sicherheitsanforderungen bei eigenen Angestellten aber auch Vertragspartner mit berücksichtigt
Weitere rechtliche und
regulatorische Aspekte
Neben den bereits genannten Anforderungen im Bereich des Datenschutzes spielen
weitere rechtliche Fragestellungen eine nicht weniger wichtige Rolle. Die Priorität
der hier im einzelnen genannten Anforderungen ist dabei natürlich stark von
der Ausrichtung der aktuell betrachteten Organisation abhängig. Zu nennen sind
etwa:
• Steuerrechtliche Fragestellungen, bspw. im Rahmen etwaiger Aufbewahrungsfristen und der langfristigen Datenspeicherung
• Regeln bzgl. des Im- und Exports von Waren und Dienstleistungen, bspw.
im Rahmen des Kriegswaffenkontrollgesetzes oder der Kryptoregulierung
• Aspekte der Patentregelungen und Urheberrechtsfragen, bspw. bei der allgemeinen Nutzung von Informationen
• Spezielle nationale Standards, bspw. im Rahmen internationaler Geschäftsprozesse im Bereich Datenschutz
• Aspekte bzgl. der Fragen der Lawful Interception, bspw. im Rahmen der Bereitstellung von entsprechenden Zugriffsmechanismen für staatliche Stellen
Mögliche Probleme
Auch mögliche Problemstellungen in diesem Bereich können vielfältiger Natur
sein. Besonders relevant ist - gerade aufgrund der vielfältigen Einflussfaktoren
2.7 Einholen der Unterstützung des Managements
- eine unzureichende Weitsicht des IS-Manager und eine daraus resultierende
Fehlentwicklung im Bereich der IS. Hinzu kommen mögliche Probleme durch eine
verminderte Sicherheit der Organisation, die sich durch Änderungen - interne wie
externe - ergeben, weil nicht (rechtzeitig) auf diese Veränderungen reagiert worden
ist. Nicht zuletzt spielen auch Aspekte der Non-Compliance eine große Rolle,
die für eine Organisation in unterschiedlichen finanziellen Verlusten resultieren
können.
Seite 31
Aspekt
Non-Compliance
2.7 Einholen der Unterstützung des Managements
Im Rahmen der Einführung der IS-Strategie spielt die Unterstützung durch das
Senior Management der Organisation eine entscheidende Rolle. Nur wenn das
Senior Management in Zusammenarbeit mit allen anderen wichtigen Akteuren
die Einführung und Umsetzung der IS-Strategie unterstützt, wird diese auch
Erfolg haben können. Im folgenden Abschnitt wird nun erläutert, warum diese
Unterstützung so wichtig ist und wie der IS-Manager sie bekommen kann.
Unterstützung durch das
Management
als Erfolgfaktor
Im Rahmen der Unterstützung durch das Management einer Organisation wird
gerne auch von einem so genannten Top-Down-Ansatz gesprochen. Dies bedeutet,
dass die obere Management-Ebene der Organisation die Richtung vorgibt und
die Einführung und Umsetzung der IS-Strategie in der Organisation treiben muss.
Neben den CxO sollten -je nach Form der Organisation- auch ein möglicher Beirat,
Aufsichtsrat oder andere Kontrollgremien mit eingebunden werden. Dadurch wird
sicher gestellt, dass alle wesentlichen Interessenvertreter innerhalb der Unternehmung die IS-Strategie mit tragen und so auch zu einer erfolgreichen Umsetzung
beitragen. Darüber hinaus kann die Einbindung dieser Aufsichtsgremien im Konfliktfall auch dazu genutzt werden, einen Interessensausgleich, etwa zwischen
Betrieb und IS herbeizuführen.
Top-Down-Ansatz als
Erfolgsfaktor
Existieren in der Organisation zudem entsprechende Kommunikationskanäle, findet dann auch eine - mehr oder weniger gefilterte - Weitergabe der Grundzüge
der IS-Strategie an das mittlere und letztendlich auch das untere Management
statt. Dies begünstigt die konkrete Umsetzung der IS-Strategie weiter, da die Anforderungen zum einen von der nächst höheren -und damit weisungsbefugtenManagement-Ebene kommen, zum anderen aber auch, weil die Sprache stimmt,
da hier Management mit Management redet. Bei all diesen Vorzügen muss allerdings auch berücksichtigt werden, dass es dadurch zu einer Aufweichung der
IS-Strategie kommen kann, hier muss der IS-Manager ggf. entsprechend regulierend eingreifen.
Kommunikation der
IS-Strategie
Unterstützung bekommt dieser Ansatz durch die konsequente Anwendung von
grundlegenden Management-Prinzipien, bspw. durch die Annahme, dass letztendlich eine Verantwortlichkeit (des Managements) existiert, und der Einführung
von Kontrollen, die dem jeweiligen Risikoniveau angemessen sind. Neben diesen
indirekten Mechanismen kann das Management seine Unterstützung aber auch
ganz konkret ausdrücken. Dazu gehört etwa die Möglichkeit, dem Bereich der IS
ausreichende Ressourcen zuzuweisen und im Konfliktfall eine ausgewogene Entscheidung zu treffen. Weitere Möglichkeiten sind eine regelmäßige Überprüfung
der Effizienz der IS und die generelle Einbindung der IS in das ManagementFramework und die Mechanismen der Management-Kontrollen.
Einsatz grundlegender
Management-Prinzipien
Die Gründe für eine fehlende oder mangelhafte Unterstützung durch das Senior Management sind vielfältig. Insbesondere die Komplexität der IS verbunden
damit, dass das Management in der Regel ganz andere Aufgaben hat, spielt eine
wesentliche Rolle. Durch Unverständnis beim Management wird IS häufig als
Gründe für fehlende
Unterstützung des
Management
Seite 32
Studienbrief 2 Governance im Bereich der IS
reiner Kostenfaktor angesehen, fehlende Sicherheitsvorfälle suggerieren zudem
ein falsches Gefühl von Sicherheit. Das Unverständnis selbst ist meist durch einen
unzureichenden Zugang des IS-Manager zum Management begründet, der ISManager hat nicht die richtige “Position” im Unternehmen, sondern ist in der
Hierarchie zu weit unten angesiedelt. Darüber hinaus kann aber auch eine falsche
Kommunikationsform der komplexen Inhalte eine Ursache sein, bspw. wenn die
Strategie zu wenig fokussiert oder viel zu technisch dargestellt wird.
Überzeugung des Senior Management
Es gibt aber einige Mechanismen, die dem IS-Manager erleichtern, die Unterstützung durch das Management sicher zu stellen. Zunächst ist es förderlich, wenn der
IS-Manager die Anforderungen im Bereich der IS dem Management in Form von
praxisnahen Fällen -möglichst aus der eigenen Organisation- darstellt. Dadurch
kann er die Ausrichtung der IS am Geschäftsprozess zeigen und dem Management
vermitteln, dass die IS zu den Geschäftsprozessen dazu gehört. Die Anwendung
von allgemein anerkannten Metriken erleichtert das Verständnis beim Management, dies gilt insbesondere, wenn die Metriken auch aus dem Nicht-IS-Bereich
bekannt sind. Zudem sollten auch alle Projekte im Bereich der IS wie ein normales
Projekt der Organisation gemanagt werden; dies beinhaltet bspw. die Zuordnung
von Zurechenbarkeiten, das Aufstellen von Meilensteinen und Auditkriterien zu
Beginn des Projektes.
Einbindung des
Management
Auch eine kontinuierliche Einbindung des Managements sichert seine Unterstützung für Projekte im Bereich der IS. Dazu gehört sowohl der Aufbau eines entsprechend zugeschnittenen Awareness-Programms, aber auch die regelmäßige
Teilnahme des IS-Manager an Abteilungs-, Bereichs- und Geschäftsführungsmeetings. So bekommt der IS-Manager die Möglichkeit, die Interessen der IS frühzeitig
zu kommunizieren und dabei auch Fehlentwicklungen und Missverständnissen
vorzubeugen.
Mögliche Probleme
Die Hauptprobleme bei der Sicherstellung der Unterstützung durch das Management liegen in dem meist zu kleinen Zeitfenster, das das Management dem Thema
IS einräumt. Dadurch werden die üblichen Probleme, denen sich der IS-Manager
in der Kommunikation mit dem Management konfrontiert sieht, weiter verstärkt.
Letztendlich führt die daraus resultierende mangelhafte Unterstützung dann zu
unzureichender Ressourcen-Zuteilung und damit auch zu einer unzureichenden
Compliance. Gerade der letzte Aspekt ist aber auch wieder ein Punkt, den der
IS-Manager nutzen kann, um für das Verständnis beim Management zu werben.
2.8 Festlegen von Rollen und Verantwortlichkeiten
Rollen und
Verantwortlichkeiten
Um klare Zuständigkeiten bzw. entsprecheden Zurechenbarkeiten (engl.: accountability) etablieren zu können, ist die Definition und Kommunikation von Rollen und
Verantwortlichkeiten in der gesamten Organisation wichtig. Die Verantwortlichkeit
für die IS bildet dabei eine Ausnahme: Während die meisten anderen Bereiche
einer Organisation Einzelpersonen und/oder kleinen Gruppen zugeordnet sind,
liegt die IS im Verantwortungsbereich von allen Mitarbeitern und Partnern einer
Organisation.
Verantwortlichkeiten der Beteiligten
Dabei werden den unterschiedlichen Akteuren unterschiedliche Teilverantwortlichkeiten zugeschrieben:
• Das Executive Management hat die übergreifende Verantwortung, die Sicherheit der Informationswerte der Organisation sicher zu stellen.
2.8 Festlegen von Rollen und Verantwortlichkeiten
Seite 33
• Die Prozessverantwortlichen (engl.: process owner) stellen sicher, dass die
Sicherheitsmaßnahmen in den von ihnen verantworteten Prozessen in Übereinstimmung mit der Leitlinie sind und aufrecht erhalten werden.
• Die Dateneigner (engl.: data owner) legen die Klassifizierungsstufe der Informationswerte fest und stellen damit sicher, dass diese mit angemessenen
Maßnahmen vor Verlust der Vertraulichkeit, Integrität und/oder Verfügbarkeit geschützt werden.
• IT-Entwickler berücksichtigen die Anforderungen im Bereich der IS bereits
bei der System-/Anwendungsprogrammierung.
• Die Anwender akzeptieren und befolgen die Leitlinie und die daraus abgeleiteten Dokumente der Policy-Pyramide, sie beachten die Arbeitsanweisungen
und Handlungsempfehlungen.
• Auditoren stellen eine unabhängige Expertise bzw. Bewertung der Angemessenheit und Effektivität/Effizienz der Ziele im Bereich der IS zur Verfügung.
• Das Security Steering Committee besteht aus Vertretern aller Interessensgruppen und sorgt dafür, dass die Anforderungen im Bereich der IS sinnvoll
gestaltet und im Sinne der Organisation umgesetzt werden.
Im Rahmen der Sicherheitsorganisation, also der Frage, wie die IS in der Organisation organisiert werden soll, sind einige Aspekte zu beachten. Wichtig ist, dass das
Thema IS im Management möglichst hoch aufgehängt werden sollte. Dadurch wird
gewährleistet, dass die Durchsetzungskraft -insbesondere bei Eskalationsfällen,
wenn Vorgaben nicht befolgt werden- sicher gestellt ist. Darüber hinaus sollte das
Thema entsprechend unabhängig aufgehängt sein, um Interessenskonflikte von
vorne herein möglichst ausschließen zu können.
Die IS-Organisation
Ausgangspunkt für die IS-Organisation ist die IS-Governance, in einem ersten
Schritt werden dabei die Schutzziele festgestellt und mit der Unternehmensstrategie in Übereinstimmung gebracht. Dazu werden dann globale Leitlinien, Standards,
Arbeitsanweisungen und Handlungsempfehlungen entwickelt und implementiert.
Ggf. sind dazu weitere Rollen und Verantwortlichkeiten zu schaffen.
Ausgangspunkt ISGovernance
Ein wichtiger Aspekt ist außerdem die Awareness für die Mitarbeiter, insbesondere für neu eingestellte oder innerhalb der Organisation versetzte Mitarbeiter.
Auch wenn Sätze wie “IS geht alle an!” mehr als abgedroschen wirken, stellen
sie eines der wesentlichen Konzepte im Bereich der IS dar, dass nämlich alle in
ihren jeweiligen Bereichen zur IS beitragen müssen. Um die Mitarbeiter dabei zu
unterstützen, sollten die IS relevanten Themen in die Arbeitsplatzbeschreibungen
mit aufgenommen werden. Bei der Vergabe/Ausgabe von Authentisierungstoken
bzw. Nutzerberechtigungen sollten ebenfalls Hinweise erteilt werden, wie die Organisation den ordnungsgemäßen Umgang damit geregelt hat. Zudem können
auch Hinweise bei der (täglichen) Nutzung -etwa durch Pop-up-Meldungen- die
Awareness stärken und zu einem sicherheitsbewussten Umgang führen.
Awareness
Die wesentliche Fragestellung bei der Etablierung der Sicherheitsfunktionen innerhalb der Organisation besteht in der Entscheidung, ob diese zentral oder dezentral
aufgehängt sein soll. Dabei sind unterschiedliche Aspekte zu berücksichtigen:
Zentrale vs. dezentrale
Organisation
• Für eine zentrale Organisation der IS spricht, dass sich Leitlinien besser
durchsetzen lassen und der Umsetzungsgrad besser kontrolliert werden
kann. Zudem ist durch eine zentrale Vorgabe auch sicher gestellt, dass die
Vorgaben aus dem Gesamtkontext der Organisation entwickelt werden.
Nachteilig ist, dass die Anforderungen “weit weg von den lokalen Anforderungen” sind und daher ggf. die Akzeptanz bei den Mitarbeitern leidet.
Zentrale IS
Seite 34
Studienbrief 2 Governance im Bereich der IS
Dezentrale IS
• Für eine dezentrale Organisation der IS spricht, dass die Anforderungen
in den einzelnen Lokationen schneller umgesetzt werden können. Darüber
hinaus ist die IS näher am Prozess, was in der Regel zu einer erhöhten
Akzeptanz bei den Mitarbeitern führt - aber auch die Gefahr birgt, dass
jede Lokation ihre eigenen -ggf. deutlich schwächer ausgeprägten und rein
auf die lokalen Gegebenheiten abgestimmten- Vorgaben umsetzt, die für
die jeweiligen Gefährdungen im Gesamtkontext nicht angemessen sind.
Dadurch kann auch schnell ein Zustand der “Anarchie” entstehen.
Wahl gut überlegen
Die Entscheidung muss allerdings gut überlegt sein, wirkt sie sich doch auf eine
ganze Reihe von Bereichen aus, bspw. die Mechanismen zur Authentifizierung
und Authorisierung, das Patch-Management und Change-Managament oder auch
die IS-Monitoring- und Incident Response-Prozesse. Bei der Entscheidung sollte
zudem die Struktur der Organisation im Rahmen der sonstigen Prozessen berücksichtigt werden, damit Synergien möglichst genutzt werden.
Mögliche Probleme
Ein wesentliches Problem besteht darin, dass die (Anforderungen der) Sicherheit
nicht respektiert wird. Dadurch ergeben sich Folgeprobleme, bspw. dass die erforderlichen und festgelegten Maßnahmen nicht befolgt und die Informationswerte
der Organisation dadurch ggf. gefährdet werden. Voraussetzung für die Akzeptanz der IS ist allerdings, dass die Mitarbeiter die Anforderungen und die sich
daraus für sie ergebenden Verpflichtungen überhaupt kennen. Hinzu kommt, dass
das Management die Umsetzung der Anforderungen auch durchsetzen muss inklusive der Tatsache, dies auch im Konflikfall entsprechend zu vertreten.
2.9 Grundlagen für die Kommunikation mit dem
Management
Direkte Kommunikation
mit dem Management
Um das Management mit Daten bzgl. der Effektivität und Effizienz der Umsetzung
der IS-Strategie zu versorgen, muss der IS-Manager entsprechende Metriken aufbauen, monitoren und regelmäßig auswerten. Die Kommunikationskanäle zum
Management sollten dabei so gestaltet sein, dass die Informationen möglichst
ungefiltert auf einer möglichst hohen Hierechiestufe ankommen. Dazu sind bspw.
Treffen der Abteilungsleiter bzw. Vorstandsmitglieder, Treffen des Audit- und/oder Sicherheitskomitees geeignet, wobei der IS-Manager dann die entsprechenden,
geeigneten Metriken wählen sollte, um seine Informationen zu präsentieren. Neben der Kommunikation mit dem Management darf aber die Kommunikation mit
den Mitarbeitern der Organisation nicht außer acht gelassen werden, hier eignen
sich bspw. (regelmäßige) Newsletter, Darstellungen der Aktivitäten im Bereich der
IS im Intranet der Organisation und auch Schulungsmaßnahmen.
Security SteeringKomitee
Eine entscheidende Funktion kommt dem so genannten Security Steering-Komitee
zu. Dieses agiert analog zum IT Steering-Komitee und besteht aus Vertretern der
einzelnen Geschäftsbereiche, häufig aus den Geschäftsbereichsleitern selbst, und
lenkt und unterstützt den IS-Prozess. Gleichzeitig steigert es auch das so genannte
“buy in” im IS-Bereich und unterstütz beim Risikomanagement bzw. den daraus
notwendigen Entscheidungen. Ermöglicht wird dies, da das Security Steering Komitee ein hervorragender Mechanismus ist, um den Geschäftsbereichsleitern einen
Kontakt zum Thema IS zu bieten. Dadurch erhalten sie nicht nur Informationen
und eine verbesserte Awareness, sondern bekommen auch die Gelegenheit, ihre
Bedenken bzgl. des Einsatzes der IS zu kommunizieren. Dem IS-Manager ermöglicht es auf der anderen Seite, die Anforderungen, die sich aus dem Bereich der
IS ergeben, zu kommunizieren und bei Bedenken bzgl. ihrer Umsetzung direkt
Alternativvorschläge zu unterbreiten bzw. weitere Erläuterungen abzugeben.
2.9 Grundlagen für die Kommunikation mit dem Management
Im folgenden sollen drei wesentliche Ansätze kurz dargestellt werden:
Seite 35
Beispielhafte Metriken
• Key Goal Indikatoren (kurz: KGI), die dem Management aufzeigen, ob ein
Prozess die Anforderungen erfüllt. Sie können erst nachgelagert erfasst
werden und tragen daher auch die engl. Bezeichnung lag indicator.
KGI
• Key Performance-Indikatoren (kurz: KPI), die bestimmen lassen, wie gut
die Umsetzungsgeschwindigkeit eines Prozesses bei der Zielerreichung ist.
Als so genannte Frühindikatoren bieten sie die Möglichkeit, noch während
des Prozesses festzustellen, ob ein Ziel erreicht wird oder nicht; sie werden
im Englischen auch als lead indicators bezeichnet.
KPI
• Key Risk-Indikatoren (kurz: ), die als Frühwarnparameter das Risiko eines
Prozesses messen lassen. Im Gegensatz zum KPI (der aufzeigt, wie gut etwas
ist) zeigt ein KRI (die Wahrscheinlichkeit für) eine mögliche zukünftige
negative Auswirkung an.
KRI
Ohne entsprechende Kommunikation der Aktivitäten im Bereich der IS wird die
Unterstützung durch das Management nur von kurzer Dauer sein, es gilt das Motto
“Tu Gutes und rede darüber”. Wenn der IS-Manager nicht ausreichend erklärt, was
er tut und wofür seine Tätigkeit überhaupt gut ist (also was sie der Organisation
ganz konkret bringt), wird dies in einer unzureichenden Unterstützung durch
das Management, aber auch in unzureichender Umsetzung der Anforderungen
der IS durch die Mitarbeiter und einer damit einhergehenden unzureichenden
Compliance resultieren.
Mögliche Probleme
Zusammenfassung dieses Studienbriefs
Die IS-Governance richtet sich an der IS-Strategie der Organisation aus und schafft
damit die Grundlage, die Aktivitäten im Bereich der IS im Sinne der Organisation zu steuern. Erst dadurch wird eine effektive und effiziente Umsetzung der
Anforderungen im Bereich der IS möglich, die die Prozesse der Organisation voll
unterstützt. Die IS-Governance schafft das dazu notwendige Framework, bspw.
durch die Dokumentenhierarchie der Policy-Pyramide. Im nächsten Studienbrief
werden wir nun die Grundlagen des Risikomanagements kennen lernen, das als
Steuerungsinstrument verstanden wird und durch das die Entscheidungsgrundlage für eine effektive und effiziente IS gelegt wird.
Zusammenfassung
Studienbrief 3 Risikomanagement im Bereich IS
Seite 37
Studienbrief 3 Risikomanagement im Bereich IS
Wie bereits im Studienbrief 2 “IS-Governance” angesprochen, spielt die Frage der
zielgerichteten Investition auch im Bereich der IS eine entscheidende Rolle. Insbesondere bei der Fragestellung, wie das Management nachhaltig von den -zunächst
als oft als nutzlose Belastung gesehen- Ausgaben für den Bereich IS überzeugt
werden kann, ist es wichtig, die konkreten Vorteile dieser für die Organisation
aufzuzeigen. Auf diesen Sachverhalt wurde bereits detailliert eingegangen. In
diesem Kapitel soll nun das Risikomanagement (engl.: risk management)im Unternehmen näher betrachtet werden. Dies ermöglicht, Investitionen zielgerichtet dort
vorzunehmen, wo die potentiellen Schäden für die Organisation am größten sind.
Die Risikobewertung, auf im Rahmen dieses Kapitels noch im Detail eingegangen
werden wird, ist einer der wesentlichen Faktoren für eine effektive IS-Strategie.
Beim Risikomanagement spielt der Umsetzungsgrad der im Studienbrief 2 angesprochenen IS-Governance allerdings nur eine untergeordnete Rolle, vielmehr sind
die Risiken unabhängig davon zu betrachten.
Risikomanagement als
Grundlage für zielgerichtete Investitionen
Grundlagen des Risikomanagements
Unter Risikomanagement versteht man nun im Allgemeinen einen Prozess, der
gewährleistet, dass die Auswirkungen von auf Bedrohungen abzielenden Schwachstellen für die Organisation innerhalb von akzeptablen Grenzen, also in einfachster
Betrachtung bei akzeptablen Kosten, bleiben. Risiken sind allerdings inhärenter
Bestandteil jeglicher Aktivität - sie lassen sich daher auch niemals auf Null reduzieren. Vielmehr geht es darum, möglichst alle Risiken zu erfassen und sie
dann so zu managen, dass die Geschäftsprozesse der Organisation nicht erheblich
beeinträchtigt werden. Die wesentlichen Ergebnisse eines (effektiven) Risikomanagements sind unterschiedlicher Natur. Neben einem allgemeinen Verständnis für
das Risikoprofil, dem sich eine Organisation ausgesetzt sieht, und den entsprechenden Bedrohungen und Schwachstellen spielt auch das Bewusstsein für mögliche
Konsequenzen einer Kompromittierung von Systemen und Informationen der Organisation eine wichtige Rolle. Weiterhin schafft ein adäquates Risikomanagement
auch das Bewusstsein für die Priorisierung von Maßnahmen und die Akzeptanz
von Restrisiken - und damit auch die Grundlage für zielgerichtete und nachhaltige
Investitionen im Bereich der IS. Obwohl in diesem Abschnitt die Methoden des
Risikomanagements allgemein gehalten sind und damit auf unterschiedlichste
Geschäftsprozesse und Bereiche der Organisation angewendet werden könnten,
werden wir uns auf die Risiken im IS-Bereich konzentrieren.
Im Fokus des Risikomanagements steht im Bereich der IS der Schutz der Informationswerte einer Organisation, hier sind insbesondere die klassischen drei Sicherheitsziele Vertraulichkeit, Integrität und Verfügbarkeit zu nennen. Die Aspekte, mit
denen sich das Risikomanagement beschäftigt, sind vor allem die Frage nach den
wesentlichen Risiken im Bereich der IS verbunden mit möglichen Auswirkungen
dieser Risiken auf die Organisation, die Frage nach Maßnahmen, die ergriffen
werden, um diese Risiken auf einem akzeptablen Niveau zu halten, und die Frage nach der Funktionalität und Effektivität des Risikomanagementprogramms.
Das Risikomanagementprogramm hat dabei die Aufgabe, ein Rahmenwerk für
das Management von Risiken zu geben und dafür Leitlinien und Standards zu
entwickeln. Die Standards haben dabei die Aufgabe, die Leitlinie mit Leben zu
füllen und dabei für die Ausrichtung des Risikomanagements anhand der Strategie
der Organisation zu ermöglichen. Gerade der Aspekt “Wann ist ein Restrisiko
akzeptabel?” spielt dabei eine wesentliche Rolle und damit geben die Standards
Definition
Risikomanagement
Risikoprofil
Akzeptanz
von Restrisiken
Schutz der
Informationswerte
hier im Fokus
Risikomanagementprogramm
Standards für das
Risikomanagement
Seite 38
Studienbrief 3 Risikomanagement im Bereich IS
den Verantwortlichen in den einzelnen Bereichen der Organisation eine wichtige
Hilfestellung bei der Beantwortung dieser oft schwer zu entscheidenden Fragestellung. Die Standards legen darüber hinaus aber auch fest, wer der Verantwortliche
für das Risikomanagement ist.
Wesentliche Elemente
des Risikomanagements
Das Themenfeld des Risikomanagements beinhaltet einige wichtige Elemente, die
im zunächst als Grundlage für die folgenden Abschnitte kurz erläutert werden
sollen. Allgemein gesprochen wägt das Risikomanagement die Folgekosten der
Risikobelastung gegen die Kosten der Risikominderungsstrategie, also die Kosten,
die durch die Maßnahmen zur Verminderung von Risiken entstehen, ab. Um die
Risiken auf ein für die Organisation akzeptables Niveau zusenken, werden sowohl
Kontrollen als auch Gegenmaßnahmen genutzt. Während Kontrollen einen eher
allgemeinen Charakter haben und bspw. beschreiben, wie auf Prozessebene Risiken reduziert werden können, sind Gegenmaßnahmen spezifische Mechanismen,
Risiken im konkreten Fall, bspw. durch eine spezifische technische Maßnahme, zu
reduzieren.
Verwirrende Terminologie
Bedauerlicherweise kommt es beim Thema Risikomanagement aber immer wieder
zu Missverständnissen, die häufig in unklaren Definitionen und falsch benutzten
Terminologien ihre Ursache haben. Zunächst ist klar zwischen Risiken, Bedrohungen und Schwachstellen zu unterscheiden. Weiterhin muss auch berücksichtigt
werden, dass es unterschiedliche Ansätze bei der Ermittlung von Risiken gibt, hier
kann grob zwischen einer qualitativen und einer quantitativen Vorgehensweise
unterschieden werden. Erschwerend kommt hinzu, dass das Thema Risikomanagement auch innerhalb einer Organisation völlig unterschiedlich verstanden
werden kann und sich zudem auch noch auf unterschiedlichen Ebenen (strategisch,
operationell, projektbasiert) abspielt. All dies macht das Thema Risikomanagement
daher häufig zu einem Problemfeld innerhalb der Organisation, der IS-Manager
hat hier dann die Aufgabe, klare Strukturen und Vorgehensweisen vorzugeben
und zudem die einzelnen Beteiligten bei der Kommunikation zu unterstützen und
dadurch Missverständnissen vorzubeugen.
Risiken, Bedrohungen
und Schwachstellen
Aufgabe des IS-Managers
Wichtige Begrifflichkeiten
Um im weiteren Verlauf dieses Studienbriefs mit bekannten und vor allem einheitlichen Begrifflichkeiten arbeiten zu können, sollen diese im Folgenden eingeführt
werden:
Wirtschaftsgut
• Als Wirtschaftsgut (engl.: asset) bezeichnen wir etwas, das einen materiellen
oder immateriellen Wert für die Organisation hat, den es zu schützen gilt.
Bedrohung
• Eine Bedrohung (engl.: threat) ist eine mögliche Ursache für ein nicht gewolltes Ereignis (engl. incident), das der Organisation Schaden zufügen kann.
Schwachstelle
• Eine Schwachstelle (engl.: vulnerability) ist eine Schwäche eines Systems, die
von einer Bedrohung “ausgenutzt” werden kann.
Ereignis
• Ein Ereignis (engl.: event) ist eine Begebenheit oder Situation, die an einem
bestimmten Ort zu einer bestimmten Zeit auftritt.
inhärente Risiken
• Inhärente Risiken (engl.: inherent risks) sind Risiken, die dem normalen
Geschäftsprozess innewohnen und spezifisch für den jeweiligen Prozess
sind.
Restrisiken
• Restrisiken (engl.: residual risks) sind die Risiken, die auch nach Einsatz der
ausgewählten Kontrollen und Gegenmaßnahmen übrig bleiben.
Begriff des Risikos
Diese Begrifflichkeiten helfen uns nun, den Begriff des Risikos besser zu verstehen
bzw. definieren zu können. Als Risiko bezeichnen wir “die Möglichkeit, dass eine
Bedrohung eine Schwachstelle für einen Unternehmenswert oder eine Gruppe
von Unternehmenswerten ausnutzt”. Die Auswirkung bzw. Schwere eines Risi-
Studienbrief 3 Risikomanagement im Bereich IS
Seite 39
kos ist proportional zum möglichen Schaden und damit proportional zum Wert
des betroffenen Unternehmenswertes und der Häufigkeit der Bedrohung. Ein
Risiko kann also in Form der Auswirkung (eines einzelnen Ereignisses) und der
Wahrscheinlichkeit (des Eintritts des Ereignisses) gemessen werden.
Es bleiben allerdings zwei Dinge festzuhalten:
1. Es gibt keinen Geschäftsprozess ohne jegliches Risiko, Risiken gehören zum
alltäglichen Leben und damit auch Geschäftsleben einfach dazu.
Kein Prozess ohne Risiko
2. Es gibt keinen Geschäftsprozess ohne Restrisiko: Irgendwann ist der Grenznutzen der Gegenmaßnahmen erreicht, d.h. eine weitere Maßnahme würde
das Risiko zwar noch weiter senken, der Wert des vermiedenen Risikos wäre
aber kleiner als die Kosten für diese weitere Maßnahme. Damit wird die Gegenmaßnahme unwirtschaftlich und sollte demzufolge nicht durchgeführt
werden. Somit verbleibt ein -allerdings akzeptables- Restrisiko.
Kein Prozess mit null
Restrisiko
Teilschritte des Risikomanagements
Bevor wir uns den einzelnen Schritten im Rahmen des Risikomanagements zuwenden, wollen wir noch einige etablierte Ansätze im Bereich des Risikomanagements
aufzeigen. Ein Risikomanagementprogramm im Bereich der IS besteht in der Regel
aus unterschiedlichen Teilschritten. Dazu gehören (vgl. dazu auch [7]) bspw.
Teilschritte des Risikomanagements
• die Festlegung und Definition von Zweck und Umfang der Aktivitäten,
• die Identifizierung und Klassifizierung von Informationswerten,
• die Identifizierung von Bedrohungen und Schwachstellen,
• die Analyse des Risikos als Faktor aus Wahrscheinlichkeit und Auswirkung,
• die Evaluierung aller Risiken inklusive Priorisierung,
• das Management der Risiken durch zielgerichtete Kontrollen und Maßnahmen,
• das Monitoring des Gesamtprozesses, regelmäßige Reviews und
• die regelmäßige Kommunikation der Ergebnisse.
Eine Basis-Risikoanalyse beinhaltet im Wesentlichen zwei Komponenten: Der
Bestimmung der (Eintritts-)wahrscheinlichkeit, die immer mit Unsicherheiten
behaftet sein wird, und der Ermittlung des Ausmaßes eines möglichen Schadens,
falls dieses Risiko “Realität wird”.
Elemente der BasisRisikoanalyse
Die weitere Analyse konzentriert sich dann vor allem auf die Risiken mit großem
Potential, also solche mit einer hohen Eintrittswahrscheinlichkeit oder einem
hohen potentiellen Schaden. Bei etwaigen Maßnahmen sind immer die Kosten
gegen das Risiko (bzw. den sich aus dem Risiko möglicherweise ergebenden
Schaden) abzuwägen.
Hohe Risiken im Fokus
Abbildung 3.1 zeigt schematisch die Bewertung von Risiken anhande der Eintrittswahrscheinlichkeit und der möglichen Auswirkungen. Insbesondere die Risiken,
die rechts oberhalb der (in diesem Fall nur exemplarisch gelegten) gestrichelten
Linie liegen, müssen im Rahmen des Risikomanagaments mit hoher Priorität betrachtet werden, dabei gilt: je weiter rechts und je höher das Risiko liegt, desto
höher sollte seine Behandlung priorisiert werden.
Risikobewertung
Seite 40
Studienbrief 3 Risikomanagement im Bereich IS
Abb. 3.1: Risikobewertung anhand der Parameter “Eintrittswahrscheinlichkeit” und “Auswirkungen” (angelehnt an [7]).
Risikobewertung
Hoch
Mittel
Hoch
Auswirkung
Niedrig
Mittel
Niedrig
Niedrig
Mögliche Auswirkungen
Eintrittswahrscheinlichkeit
Hoch
Die möglichen Auswirkungen sind sehr vielfältiger Natur, bspw.
• direkter finanzieller Verlust oder Strafzahlungen, bspw. wegen ComplianceVerstößen,
• Rechtsverstöße und sich daraus ergebende straf- und zivilrechtliche Konsequenzen, sowie
• Verlust der Reputation oder Verlust von Marktanteilen und dadurch bedingte Verringerung des Aktienkurses
T
und vielen weiteren möglichen Aspekten. Zu beachten ist, dass in der Regel vor
allem die Auswirkungen, die sich erminate
nicht oder nur schwer quantitativ erfassen lassen
ransfer
(bspw. Verluste durch Imageschäden),
die potentiell größten Schäden verursachen
reat
können.
olerate
NIST 800-30 als Beispiel
Der Standard
NIST 800-30
Ein bekannter Standard in diesem Bereich ist etwa der Standard NIST 800-30 “Risk
Management Guide for Information Technology Systems” des National Institute for
Standards and Technology (NIST)1 . Dieser gliedert den Risikomanagementprozess
in insgesamt neun Teile, die im folgenden jeweils kurz dargestellt werden sollen.
Abbildung 3.2 stellt die Abfolge im Rahmen des NIST 800-30 dar; gehen wir nun
auf die Bedeutungen der einzelnen Schritte im Detail ein.
System charakterisieren
1. Charakterisierung des betreffenden Systems
In diesem Teilschritt werden zunächst alle verfügbaren Informationen über
das betreffenden System. Dazu zählen Informationen über die auf diesem
System gespeicherten Daten, die genutzte Hard- und Software, die vom
System angebotenen Dienste, zugehörige Dokumente und das zum Betrieb
benötigte Personal. Ergebnis ist das “Verständnis” für das entsprechende
IT-System, das die Voraussetzung für die weiteren Schritte im Rahmen des
Risikomangementprozesses ist.
Bedrohungen
identifizieren
2. Identifizierung der Bedrohungen
Zu den Bedrohungen gehören potentiell alle Ereignisse, die möglicherweise
Schaden an den IT-Systemen bzw. Informationswerten verursachen können. Zu den Bedrohungen zählen insbesondere mögliche Systemfehler (engl.
errors) und -ausfälle (engl. hardware failure), durch Menschen verursachte
1 Wir
stellen hier aus didaktischen Gründen bewusst die alte Version dieses Standards vor.
Studienbrief 3 Risikomanagement im Bereich IS
1
4
Charakterisierung
des Systems
Analyse der
Kontrollen
Seite 41
7
Ermittlung der
Risiken
2
5
8
Analyse der
Bedrohungen
Ermittlung der
Eintrittswahrscheinlichkeit
Empfehlungen
zu Kontrollen
3
Analyse der
Schwachstellen
6
9
Analyse der
Auswirkungen
Dokumentation
der Ergebnisse
Abb. 3.2: Schematische
Darstellung der neun
Schritte beim Risikomanagement nach dem
Standard “NIST 800-30”
(Stand: Juli 2002) [12].
bösartige Handlungen (engl. malicious damage/attack), sowie Diebstahl (engl.
theft) und Betrug (engl. fraud) oder auch Ereignisse höhere Gewalt, wie bspw.
Naturkatastrophen. Ergebnis dieses Teilschrittes ist eine möglichst vollständige Liste aller Bedrohungen; ob diese Liste nur Bedrohungen enthält, zu denen
sich in Schritt 3 auch eine Schwachstelle finden lässt, oder grundsätzlich alle
möglichen Bedrohungen auflistet, wird unterschiedlich diskutiert.
3. Identifizierung der Schwachstellen
Zu den Schwachstellen zählen alle Eigenschaften von Informationsressourcen, die durch Bedrohungen ausgenutzt werden können, wodurch letztendlich ein Schaden für die Organisation entsteht. Beispiele für Schwachstellen
sind etwa der Zugang eines entlassenen Mitarbeiters, der nicht rechtzeitig
gesperrt wurde oder auch fehlerhafte Firewall-Regelsätze. Ergebnis dieses
Teilschrittes ist eine Liste aller Schwachstellen; ggf. erfolgt nach diesem Schritt
eine Abbildung der gefundenen Schwachstellen auf die in Teilschritt 2 identifizierten Bedrohungen, daraus ergibt sich dann die effektive Bedrohungsliste.
Schwachstellen
identifizieren
4. Analyse bereits bestehender Kontrollen und Gegenmaßnahmen
Anhand der in Teilschritt 2 bzw. 3 identifizierten Bedrohungen wird nun überprüft, inwieweit bereits existierende, aber auch zukünftig geplante Kontrollen
und Gegenmaßnahmen die möglichen Risiken reduzieren. Die Kontrollen
lassen sich entsprechend kategorisieren, wir unterscheiden zwischen
Kontrollen
analysieren
• aufdeckenden (engl.: detective) Kontrollen, bspw. Logging,
• vorbeugenden (engl.: preventive) Kontrollen, bspw. Zugriffskontrollen,
• korrigierenden (engl.: corrective) Kontrollen, bspw. dynamische
Firewall-Regeln und
• abschreckenden (engl.: deterrent) Kontrollen, bspw. PerimeterschutzMechanismen.
5. Ermittlung der Eintrittswahrscheinlichkeiten
Um die Wahrscheinlichkeit zu bestimmen, mit der sich eine Bedrohung
im Kontext einer Schwachstelle auswirkt, sind die in Teilschritt 2 ermittelten Bedrohungen und deren Ursachen, die in Teilschritt 3 identifizierten
Schwachstellen und die in Teilschritt 4 ermittelten Kontrollen und Gegenmaßnahmen zu berücksichtigen. Die Wahrscheinlichkeiten werden dabei in
Wahrscheinlichkeiten
ermitteln
Seite 42
Studienbrief 3 Risikomanagement im Bereich IS
aller Regel qualitativ angegeben, verbreitet ist eine dreistufige Skala “niedrig/mittel/hoch”. Eine hohe Wahrscheinlichkeit liegt bspw. dann vor, wenn
eine Bedrohung eine Schwachstelle ausnutzen kann und die vorhandenen
Kontrollen nicht ausreichend sind. Ergebnis dieses Teilschritts ist dann eine
Liste der Bewertung von Wahrscheinlichkeiten für einzelne Bedrohungen
bzw. Schwachstellen.
Auswirkungen
analysieren
Sensitivität
und Kritikalität
Weitere Kriterien
6. Analyse der möglichen Auswirkungen
Zur Bestimmung möglicher Auswirkungen ist zunächst einmal eine Klassifizierung der Informationen bzgl. ihrer Vertraulichkeit, Integrität und Verfügbarkeit erforderlich, denn nur so kann beurteilt werden, welche Auswirkungen ein Verlust dieser Schutzziele haben könnte. Neben diesen drei klassischen Schutzzielen wird häufig auch die Sensitivität (engl. sensitivity), die
die Vertraulichkeitsanforderungen repräsentiert, und die Kritikalität (engl.
criticality), die für die Verfügbarkeitsanforderungen steht, durch quantitative
und qualitative Methoden ermittelt. Bei der Klassifizierung der Informationswerte bietet es sich dabei generell an, Informationswerte soweit möglich
zu gruppieren und dadurch die Übersichtlichkeit erheblich zu steigern. Die
Gruppierung kann bspw. abteilungsbezogen aber auch prozessorientiert vorgenommen werden; wird ein Informationswert an unterschiedlichen Stellen
in der Organisation verwendet, sollte das Maximumsprinzip berücksichtigt
werden. Zusätzlich sollten auch zu jedem Informationswert der jeweilige
Informationseigner (engl.: information owner) ermittelt und neben den Einstufungen bzgl. der Schutzanforderungen tabellarisch dargestellt werden.
Dadurch wird eine schnelle Zuordnung von Verantwortlichkeiten und damit
Zuordnung von möglichen Maßnahmen erreicht. Neben den drei klassischen
Schutzzielen, die den primären Beurteilungsmaßstab für die Beurteilung
möglicher Auswirkungen darstellen, können unterschiedliche weitere Kriterien herangezogen werden. Dazu zählen bspw. mögliche Rechtsverstöße,
Verlust der Reputation, Unterbrechung des Geschäftsbetriebs und auch direkte finanzielle Verluste. Ergebnis dieses Teilschritts ist daher eine Liste der
Informationswerte mit den jeweiligen Klassifizierungen der Auswirkungen
anhand einer qualitativen Skala, bspw. mit den Parametern “niedrig/mittel/hoch”.
Risiken bestimmen
7. Bestimmung der resultierenden Risiken
Die Bestimmung des resultierenden Risikos auf Grundlage einer spezifischen
Kombination von Bedrohung und Schwachstelle erfolgt in der Regel durch
die Ermittlung der Wahrscheinlichkeit, mit der eine Bedrohung die Schwachstelle ausnutzen kann, der Größe der daraus resultierenden Beeinträchtigung,
wenn die Bedrohung die Schwachstelle ausnutzt und der Betrachtung der Angemessenheit der bereits vorhandenen oder noch geplanten Kontrollen und
Maßnahmen. Nachdem in Teilschritt 6 die jeweiligen Auswirkungen ermittelt
wurden, steht als Ergebnis von Schritt 7 nun eine Liste der spezifischen Risikoniveaus. Dies ermöglicht dem IS-Manager daraus eine priorisierte Liste zu
erstellen, die dann auch als Grundlage für den Umsetzungsplan eingesetzt
werden kann.
Weiteres Vorgehen
8. Empfehlungen für das weitere Vorgehen
In diesem Teilschritt werden nun Kontrollen und Gegenmaßnahmen identifiziert, die das Risiko auf ein akzeptables Niveau reduzieren können. Im
Rahmen der Risikominderung (engl.: risk mitigation) kommen unterschiedliche Herangehensweisen in Frage, die auch mit als “4-T”-Maßnahmen (vgl.
dazu auch Abbildung 3.4) bezeichnet werden.
• Risiken können vermieden werden, indem bspw. der zugrundeliegen-
Studienbrief 3 Risikomanagement im Bereich IS
Seite 43
de Geschäftsprozess eingestellt (engl.: terminate) wird; dieser Fall wird
in der Praxis allerdings eher selten vorkommen.
• Eine weitere Möglichkeit besteht, Risiken wie bereits angesprochen
durch Kontrollen und Maßnahmen auf ein akzeptables Niveau zu
reduzieren (engl.: treat), dabei ist allerdings das Aufwand-NutzenVerhältnis zu berücksichtigen.
• Risiken können zudem auf eine andere Partei transferiert (engl.: transfer) werden, bspw. durch den Abschluss einer Versicherung gegen ein
spezifisches Risiko.
• Darüber hinaus können Risiken auch schlichtweg toleriert werden
(engl.: tolerate), ohne dass weitere Maßnahmen ergriffen werden.
Nach einer erfolgten Risikominderung bleibt dann noch die Frage, ob das
nun noch verbliebene Restrisiko (engl. residual risk) für die Organisation tragbar ist. Die Akzeptanz der Restrisiken hängt dabei von unterschiedlichen
Faktoren ab, zu nennen sind bspw. die Anforderungen durch die Leitlinie
der Organisation, mögliche Unsicherheiten im Rahmen der Risikoermittlung und -bewertung oder auch die Frage, wie hoch die Kosten für etwaige
(weitere) Kontrollen und Maßnahmen sind und wie effektiv diese Kontrollen und Maßnahmen sind. Ergebnis dieses Teilschritts ist somit eine Liste
von Empfehlungen zu möglichen Kontrollen und weiteren Methoden zur
Risikominimierung.
Akzeptanz
des Restrisikos
9. Dokumentation der Ergebnisse
Der so genannte “Risk Assessment Report” listet nun alle in den vorhergehenden Schritten ermittelten Bedrohungen und Schwachstellenauf, beschreibt
die für die weitere Analyse genutzten Risikoniveaus und stellt dann die aus
diesen Grundlagen ermittelten Risiken und deren mögliche Auswirkungen
zusammenfassend dar. Auf Basis dieser Daten werden dann Empfehlungen
für Kontrollen und Maßnahmen ausgesprochen, die dazu geeignet sind, die
Risiken auf effiziente Art und Weise auf ein für die Organisation bzw. die
einzelnen Geschäftsprozesse akzeptables Niveau zu senken.
Ergebnisse
dokumentieren
Der Standard NIST 800-30 gibt also in seinen einzelnen Teilschritten viele wertvolle
Hinweise, wie der Prozess zum Risikomanagement in einer Organisation gestaltet
werden kann und stellt auch für den bisher nicht mit dieser Thematik befassten
IS-Manager einen recht guten Leitfaden dar. Einige Aspekte werden aber nicht oder
nur unzureichend adressiert. Dazu gehört bspw. die Frage der Angemessenheit
von Kontrollen und Maßnahmen oder auch die Frage, wo und wie der Prozess
des Risikomanagements in der Organisation verankert werden kann. Um diesen
Aspekt nicht zu vernachlässigen und die übrigen Aspekte besser im Gesamtkontext
einordnen zu können, wollen wir in den folgenden Abschnitte auf die einzelne
Teilaspekte nochmals gesondert eingehen.
NIST 800-30 als Leitfaden
Weitere Gliederung des Studienbriefs
Zum Themenkomplex “Management von IS-Risiken” gehören im Wesentlichen
die folgenden Teilaspekte (vgl. dazu auch [7]):
1. Aufbau und Aufrechterhaltung eines Prozesses zur Klassifizierung der Informationswerte, damit sicher gestellt wird, dass die getroffenen Maßnahmen
angemessen sind
Aspekte des
Risikomanagements
Seite 44
Studienbrief 3 Risikomanagement im Bereich IS
2. Identifizierung von rechtlichen, regulatorischen, organisatorischen und ggf.
weiteren Anforderungen, damit das Risiko einer Compliance-Verletzung auf
einem akzeptablen Niveau gehalten werden kann
3. Sicherstellen, dass im Rahmen der Risikoanalyse eine konsistente Risikobewertung sowie regelmäßige Bedrohungsanalysen und Schwachstellenbewertungen stattfinden
4. Ermittlung der angemessenen Optionen für die Behandlung von Risiken
5. Bewertung der IS-Kontrollen, um festzustellen, ob diese angemessen sind
und die Risiken effektiv auf ein akzeptables Niveau senken
6. Identifizierung der Differenzen zwischen dem aktuellen und dem gewünschten Risikoniveau, um die verbleibenden Risiken durch ein adäquates Risikomanagement auf ein akzeptables Niveau zu senken
7. Einbindung des Risikomanagement in die sonstigen Prozesse innerhalb der
Organisation, um einen konsistenten und übergreifenden Risikomanagementprozess zu etablieren
8. Beobachtung der Risiken, um Änderungen rechtzeitig erkennen und angemessen behandeln zu können
9. Bericht von Compliance-Verletzungen und Änderungen von Risiken, um das
Management bei der Entscheidung im Risikomanagementprozess unterstützen zu können
In den folgenden Abschnitten werden wir nun diese Punkte im Detail behandeln.
3.1 Prozess zur Klassifizierung der Informationswerte
Identifizierung von
Informationswerten
Bildung von Informationsklassen
Klassifizierung und
Informationseigner
Um sicher zu stellen, dass die im Rahmen des Risikomanagementprozesses getroffenen Maßnahmen proportional zum Wert der betreffenden Informationswerte
sind, ist es zunächst erforderlich, eine Klassifizierung der Informationswerte vorzunehmen. Grundlage dafür ist wiederum, dass es eine Liste aller Informationswerte
gibt. Ggf. ist also in einem ersten Schritt ein Prozess aufzusetzen, der alle für die
Organisation relevanten internen wie externen Informationswerte identifiziert und
daraus eine vollständige Liste erstellt. Dabei leuchtet es ein, dass dies nicht für
jeden einzelnen Informationswert geschehen kann, da dies den Aufwand aufgrund
der Vielzahl an Informationen und Informationswerten in den meisten Organisationen ins Unermessliche treiben würde. Die Einteilung in verschiedene Klassen
von Informationswerten kann dabei -je nach Geschmack der Organisation- anhand
unterschiedlicher Kriterien erfolgen. Wichtig ist dabei, dass die Einteilung einer
der jeweiligen Organisation angepassten, sinnvollen Struktur folgt und diese auch
konsequent eingehalten wird, die Art der Einteilung selbst spielt eine eher untergeordnete Rolle. Durch die Klassifizierung wird die Grundlage zur Beurteilung der
Risiken für die einzelnen Informationswerte bzw. der Informationswertegruppen
gelegt. Dies stellt sicher, dass in den folgenden Schritten -also nach Ermittlung
der möglichen Kontrollen und Maßnahmen- die angemessenen Kontrollen und
Maßnahmen ausgewählt werden.
Im Rahmen des Klassifizierungsprozesses wird zeitgleich auch die Rolle des Informationseigners (engl.: information owner) eingeführt, der für die Klassifizierung der
Informationswerte zuständig ist. Meist ist der Informationseigner derjenige, der
3.2 Rechtliche und regulatorische Randbedingungen
Seite 45
die Informationswerte in (s)einem Geschäftsprozess generiert hat und daher ihren
Schutzbedarf -ggf. in Absprache mit weiteren Prozessverantwortlichen- am besten
einordnen kann. Häufig gibt es in Unternehmen darüber hinaus auch noch die
Rolle eines Informationsverwalters (engl.: data custodian), der für die Umsetzung
der für die einzelnen Informationswerte notwendigen Kontrollen und Maßnahmen
verantwortlich ist. Der Informationseigner legt somit durch seine Klassifizierung
die wesentliche Grundlage für alle nachfolgenden Schritte.
Bei der Klassifizierung der Informationswerte ist darauf zu achten, dass das Schema, das zur Klassifizierung genutzt wird, angemessen ist. Bewährt hat sich ein
dreistufiges Schema, etwa mit der Einteilung “niedrig/mittel/hoch”. Ein einstufiges Schema entspricht nicht dem typischen Bestand an Informationswerten der
meisten Organisationen, denn jede Organisation hat öffentliche (bspw. Webseiteninhalte) und nicht-öffentliche (bspw. Buchhaltungsdaten) Datenbestände.
Assetgruppe
Finanzen
Personal
Produktion
Vertrieb
…
Integrität
Verfügbarkeit
Vertraulichkeit
…
++
+
+
+
…
+
o
+
+
…
+
++
+
o
…
…
…
…
…
…
Klassifizierungsstufen
Abb. 3.3: Mögliche Vorgehensweise bei der Klassifizierung von Informationswerten durch Einsatz
einer Gruppierung.
Stehen auf der andere Seite zu viele Stufen zur Auswahl, so führt dies in aller
Regel dazu, dass die Informationswerte ausschließlich in der höchsten oder der
niedrigsten Stufe einsortiert werden, da das Schema für die Informationseigner zu
komplex ist. In Abbildung 3.3 ist ein Schema gezeigt, dass die Informationswerte
vor der Klassifizierung zusätzlich entsprechenden Gruppen zuordnet. Dadurch
wird der Vorgang deutlich vereinfacht, da nur für diese Gruppen die entsprechenden Anforderungen bzgl. der drei Schutzziele ermittelt werden müssen.
Viele Organisation kämpfen bereits mit einer einfach erscheinenden Frage: Was
ist eigentlich als Informationswert zu betrachten? Erst wenn man sich zu dieser
Frage, etwa im Rahmen des Prozesses zur Klassifizierung der Informationswerte,
Gedanken macht, stellt man fest, wie vielfältig Informationswerte in einer Organisation sind. Dies betrifft sowohl die Anzahl, aber auch die Arten der vorhandenen
Informationswerte. Weitere Probleme ergeben sich aufgrund unklarer Zuständigkeiten von Informationseigner und -verwalter und aus einem nicht angemessenen
Klassifizierungsschemas.
Mögliche Probleme
3.2 Rechtliche und regulatorische Randbedingungen
Die Identifizierung rechtlicher, regulatorischer, organisatorischer und weiterer
Anforderungen spielt im Rahmen des Risikomanagements einer Organisation
ebenfalls eine bedeutende Rolle. Nur wenn die zahlreichen Anforderungen identifiziert und verstanden sind, lassen sich die für die Organisation daraus ergebenden
Risiken ermitteln und damit auch Kontrollen und Maßnahmen auswählen, die das
Risiko der Non-Compliance auf einem für die Organisation akzeptablen Niveau
halten.
Rechtliche,
regulatorische,
organisatorische und
weitere Anforderungen
Für jede der Anforderungen in diesem Bereich ist festzulegen, welcher Grad von
Non-Compliance toleriert werden kann; anders herum muss also festgelegt werden, welche Kontrollen und Maßnahmen mit welcher Priorisierung umgesetzt
werden müssen, damit das Restrisiko auf einem für die Organisation bzw. den
betreffenden Geschäftsprozess akzeptablen Niveau bleibt. Die Abschätzung des
Wieviel Non-Compliance
ist tolerierbar?
Seite 46
Studienbrief 3 Risikomanagement im Bereich IS
für eine Organisation bestehenden Grades an Compliance bzw. Non-Compliance
bildet für das Management die Entscheidungsgrundlage, in welchem Umfang
weitere Kontrollen und Maßnahmen notwendig sind.
Mögliche Probleme
In diesem Schritt sind zwei Problemfelder entscheidend: Zum einen fehlt es häufig
an einem Prozess, der den aktuellen Compliance-Zustand ermitteln kann, zum
anderen fehlt oft das Verständnis für die sich aus Non-Compliance ergebenden
Risiken. Letzteres hat seine Ursache oft in einer fehlerhaften Interpretation bzw. in
Unkenntnis der Compliance-Anforderungen. Beide Aspekte lassen sich letztendlich nur durch ein strukturiertes Vorgehen beseitigen.
3.3 Regelmäßiges Risikoassessment
Risikoassessment als
wiederkehrender Prozess
Neben der Klassifizierung der Informationswerte und der Ermittlung und Bewertung der vielfältigen Compliance-Anforderungen besteht ein weiterer wesentlicher
Aspekt des Risikomanagements in einem regelmäßigen Risikoassessment. Dabei
soll sicher gestellt werden, dass zur Ermittlung der Risiken für die Informationswerte der Organisation regelmäßige und konsistente Risikobewertungen durchgeführt
werden. Für diese Risikobewertungen sind -wie wir bereits in der Beschreibung des
Standards NIST 800-30 kennen gelernt haben- entsprechende Bedrohungsanalysen
und Schwachstellenbewertungen erforderlich.
Umfassender
Risikomanagementprozess
Die Bestimmung des angemessenen IS-Niveaus ist abhängig von den potentiellen
Risiken, die sich eine Organisation ausgesetzt sieht. Der Prozess des Risikomanagements darf dabei aber nicht nur den aktuellen Zustand der Organisation, sondern
muss auch mögliche Veränderungen berücksichtigen, die zu einer geänderten
Risikolage führen können. Im Rahmen eines kontinuierlichen, aber gleichzeitig dynamischen Prozesses müssen so Änderungen innerhalb der Organisation, wie auch
in den äußeren Rahmenbedingungen berücksichtigt werden. Zu letzterem zählt
bspw. auch die technische Weiterentwicklung, etwa im Rahmen von möglichen
Angriffsvektoren, zu ersterem vor allem geschäftliche bzw. betriebswirtschaftliche
Änderungen.
Individuelles Risikoprofil
Jede Organisation hat prinzipiell ein individuelles Risikoprofil, wenngleich Organisationen, die aus einem ähnlichem Bereich stammen, sicherlich ein ähnliches
Profil aufweisen werden. Zum Risikoprofil zählen alle Arten von Risiken, etwa
Risiken, die sich aus der (technischen) Ausstattung einer Organisation ergeben,
Risiken, die in den (Geschäfts-)Prozessen begründet sind, oder auch Risiken, die
sich aus Geschäftsentscheidungen ergeben. Das Risikoprofil besteht also aus der
Gesamtheit der Vielfalt möglicher Risiken.
Risk Assessment-Prozess
Grundlage für den weiteren Risikoassessmentprozess sind nun die abgeschlossenen Schritte der Identifizierung und Klassifizierung von Informationswerten,
ein Verständnis für die Anforderungen, die sich aus den Schutzwerten Vertraulichkeit, Integrität und Verfügbarkeit, sowie weiteren möglichen Anforderungen
der Organisation ergeben. Im nächsten Schritt müssen nun die Bedrohungen und
Schwachstellen identifiziert, analysiert und evaluiert werden, um daraus schlussendlich Kontrollen und Maßnahmen abzuleiten, die geeignet sind, die Risiken
auf einem für die Organisation akzeptablen Niveau zu halten.
Bedrohungs- und
Schwachstellenassessment
Bei der Ermittlung der Bedrohungen, die sich eine Organisation ausgesetzt sieht,
bietet sich ein Brainstorming aller wesentlichen Geschäftsprozessverantwortlichen
an. Die dabei ermittelten Bedrohungen müssen dann nach eindeutig definierten
3.4 Möglichkeiten der Risikominimierung
Kategorien klassifiziert werden. Liegen keine eindeutigen Kategorien für die Bedrohungen vor, kommt es zu einer willkürlichen und nicht reproduzierbaren Einordnung, wodurch eine kontinuierliche Risikobeobachtung wesentlich erschwert wird.
Mögliche Kategorien sind bspw. intern/extern, ausstattungs- bzw. umgebungsbedingt/menschlich oder auch unfallartig/vorsätzlich. Bei der Zusammenstellung
der Bedrohungen sollten alle Beteiligten zunächst unvoreingenommen an die Sache heran gehen. Es kommt sonst häufig vor, dass man Bedrohungen kategorisch
als nicht-relevant einstuft, weil noch keine passenden Schwachstellen identifiziert
wurden. Damit wäre der nächste Schritt dann aber eine selbsterfüllende Prophezeiung, denn man wird nicht nach Schwachstellen suchen, bei denen man die
relevante Bedrohung bereits ausgeschlossen hat.
Seite 47
Kategorien für Bedrohungen
Nach Ermittlung der möglichen Bedrohungen sollten alle möglichen Schwachstellen ermittelt werden. Auch hier bietet es sich an, nicht nur zielgerichtet zu den
bereits ermittelten Bedrohungen (spezifische) Schwachstellen zu suchen, sondern
ebenso wie bei der Ermittlung der möglichen Bedrohungen unvoreingenommen
vorzugehen. Die Ermittlung von Schwachstellen kann durch weitere Maßnahmen
unterstützt werden. Dazu zählen (automatisierte) Penetrationstests und Schwachstellenscans, Audits durch unabhängige Auditoren, aber auch frei verfügbare
Informationen, bspw. die Newsletter der CERT zu neu entdeckten Schwachstellen.
Im Rahmen von Penetrationstest, Audits und automatisierten Schwachstellenscans sollte dabei auch immer die Entwicklung der Art und Anzahl gefundener
Schwachstellen mit berücksichtigt werden. Während sich technisch orientierte
Schwachstellen meist recht zügig finden lassen, sieht sich der IS-Manager bei
Schwachstellen, deren Ursache meist in fehlerhaften Prozessen liegt, häufig einer
höheren Komplexität gegenüber. Hier ist die Unterstützung durch die Prozessverantwortlichen ein wichtiges Hilfsmittel.
Ermittlung der Schwachstellen
Es sollte allerdings nicht unerwähnt bleiben, dass die beiden Prozesse der Ermittlung von Bedrohungen und Schwachstellen nicht strikt voneinander getrennt
werden können. Es liegt in der Natur der Sache, dass bei der Ermittlung von
Schwachstellen auch neue Bedrohungen entdeckt werden können, umgekehrt
sieht es ähnlich aus. Man wird also zum Abschluss der Ermittlung von Bedrohungen und Schwachstellen genau bewerten müssen, welche Bedrohungen welche
Schwachstellen ausnutzen können und wie es mit den bereits existierenden Kontrollen und Maßnahmen aussieht. Nur so lässt sich das Risikoprofil einer Organisation
möglichst vollständig bestimmen. Weiterhin darf dieser Prozess auch nicht als singulärer Prozess verstanden werden, darauf werden wir in Abschnitt “Monitoring
von Risiken” nochmals genauer eingehen.
Verzahntes Vorgehen
Im Rahmen des regelmäßigen Risikoassessment bestehen eine Vielzahl von Problemen. Wichtiger Aspekt ist, dass die Verantwortlichen der Geschäftsprozesse die
Bedrohungen und Schwachstellen für die Organisation nicht verstehen und damit
übergreifende Risikoaspekte außen vor bleiben. Desweiteren wird die Vollständigkeit der ermittelten Bedrohungen und Schwachstellen meist völlig überschätzt:
Ohne einen iterativen Prozess und die Beteiligung aller relevanten Geschäftsprozessverantwortlichen wird man das Risikoprofil einer Organisation niemals vollständig ermitteln können.
Penetrationstests
Technische und organisatorische Schwachstellen
Voraussetzung für ein
vollständiges Risikoprofil
Mögliche Probleme
3.4 Möglichkeiten der Risikominimierung
Im nächsten Schritt sind nun die möglichen Optionen zu ermitteln, die prinzipiell
eingesetzt werden können, um die Risiken für die Organisation auf einem akzeptables Niveau zu managen.
Hierbei kann -wie bereits weiter oben erwähnt- zwischen den “4-T”-Maßnahmen
Die “4-T”-Maßnahmen
Seite 48
Studienbrief 3 Risikomanagement im Bereich IS
Abb. 3.4: Illustration der
“4-T”-Maßnahmen, der
vier Möglichkeiten, Risiken zu “behandeln”.
T
erminate
ransfer
reat
olerate
unterschieden werden, die Abbildung 3.4 nochmals illustriert: Risiken lassen sich
reduzieren (engl.: treat), übertragen (engl.: transfer), auflösen (engl.: terminate) oder
tolerieren (engl.: tolerate). Sollen Risiken toleriert werden, so ist in jedem Fall die
explizite Zustimmung des Managaments einzuholen.
Mögliche Probleme
Die Notwendigkeit einer expliziten Zustimmung durch das Management, falls
Risiken toleriert werden sollen, wird dann deutlich, wenn das Management sich
die Sache plötzlich anders überlegt, weil es persönlich Verantwortung für diesen
Schritt übernehmen soll. Ein weiteres Problem liegt darin, dass die Geschäftsprozessverantwortlichen die Gefährdungslage häufig nicht (vollständig) überblicken
und die Bedeutung von entsprechenden Kontrollen und Maßnahmen deshalb
falsch einschätzen. Nicht zuletzt liegt ein Problem auch darin, dass der Prozess
der Tolerierung bzw. Akzeptanz von Risiken missbraucht wird, da dann keine
weiteren Maßnahmen erforderlich sind - und so eine scheinbar kostengünstige
Lösung gefunden wurde.
3.5 Kontrollen im Bereich Informationssicherheit
Mögliche Kontrollen
Nachdem nun mögliche Risiken für die Organisation ermittelt wurden und klar
ist, welche prinzipiellen Möglichkeiten bestehen, diese Risiken auf einem für die
Organisation akzeptablen Niveau zu managen, werden nun die einzelnen Kontrollen und Maßnahmen hinsichtlich ihrer Eignung analysiert. Mögliche Kontrollen
lassen sich dabei generell in die vier folgenden Kategorien einteilen, die bereits
kurz angesprochen wurden:
vorbeugen
1. Vorbeugende Kontrollen, um vor (den Auswirkungen von) Schwachstellen
zu schützen und einen Angriff damit ganz unwirksam zu machen oder
zumindest zu schwächen.
aufdecken
2. Aufeckende Kontrollen, um Angriffe oder Vorbereitungen für Angriffe zu
erkennen und dann vorbeugende oder korrigierende Kontrollen anzustoßen.
korrigieren
3. Korrigierende Kontrollen, um die Auswirkungen eines erfolgreichen Angriffs
zu reduzieren und das System ggf. wieder in einen sicheren Zustand zu
bringen.
abschrecken
4. Abschreckende Kontrollen, um die Wahrscheinlichkeit eines Angriff zu reduzieren.
Maßnahmen
sind nicht immer
eindeutig zuzuordnen
Häufig lassen sich Kontrollen nicht nur einer Kategorie zuordnen. So ist bspw.
eine Anti-Malware-Software in unterschiedliche Kategorien einzuordnen, da diese
sowohl einen aufdeckenden Anteil (im Rahmen der Malware-Erkennung), einen
3.5 Kontrollen im Bereich Informationssicherheit
Seite 49
vorbeugenden Anteil (im Rahmen der Verhinderung des Zugriffs auf eine Malwareinfizierte Datei), aber auch einen korrigierenden Anteil (im Rahmen der Löschung
der Malware) enthält.
Zu den möglichen Kontrollen und Maßnahmen zählen die unterschiedlichsten
Mechanismen:
• Firewallregeln und weitere Netzwerk-Perimeter Kontrollen
• Intrusion Detection und Prevention Systeme
• Einsatz von Verschlüsselungsmechanismen
• Sicherheitsmaßnahmen in Betriebssystem, Middleware und Applikationen
• Physische Sicherheitsmaßnahmen
Es gilt nun aus der Vielzahl der möglichen Maßnahmen diejenigen herauszusuchen,
die in punkto Kosten-Nutzen-Analyse möglichst gut abschneiden. Dabei kann der
IS-Manager die Kosten für die spezifische Maßnahmen, also im wesentlichen die
Kosten für den Einsatz der im spezifischen Fall gewählten IS-Technik, gegen die
durch die Risiken für die Informationswerte begründeten potentiellen Verluste
abwägen. Wenn die Gesamtkosten der Kontrollen und Maßnahmen den Wert
der Informationsressource übersteigen, fehlt der Business Case - eine Umsetzung
dieses Kontroll- und Maßnahmenbündels ist somit nicht wirtschaftlich. In einem
iterativen Prozess wird so ermittelt, welche Kontrollen und Maßnahmen sinnvoll
sind. Der IS-Manager geht dabei nach einer priorisierten Liste vor, die auf Basis
des Risikoassessments ermittelt wurde.
Spezifische KostenNutzen-Analyse
Da die Beurteilung von Kontrollen und Maßnahmen für einzelnen Risiken ein aufwändiger Prozess ist, kann alternativ auch ein Ansatz gewählt werden, der zunächst
einen so genannten “IS-Grundschutz” (engl.: Security Baseline) umsetzt. Dabei wird
im Gegensatz zu einer formalen Risikobewertung der einzelnen Geschäftsprozesse
und Systeme ein definierter Grundschutz für jeden Geschäftsprozess bzw. jedes
System umgesetzt. Dadurch erreicht man eine Grundabsicherung in der Fläche
und vermeidet, dass einzelne Geschäftsprozesse bzw. Systeme bei der formalen
Risikoanalyse übersehen werden. Das gewählte Niveau dieser Basisabsicherung
muss natürlich an das Risikoprofil der Organisation angepasst sein und sollte
auch eine unterschiedliche Klassifizierung der Informationswerte berücksichtigen.
Damit wirkt eine Security Baseline eher prozess- bzw. systemübergreifend, aber
nichts zwangsweise für alle Informationsressourcen gleich.
Security Baseline
Im Anschluss an die Umsetzung der Security Baseline können die Risiken, die
während des Risikoassessments als besonders wichtig identifiziert wurden, mit
weiteren spezifischen Kontrollen und Maßnahmen so weit reduziert werden, dass
ein für die Organisation akzeptables Niveau erreicht wird.
Spezifische Risiken
zusätzlich absichern
Größtes Problem bei der Auswahl der Kontrollen und Maßnahmen ist eine Fehleinschätzung der damit erreichten Risikominderung. Da Investitionen im Bereich der
IS zunächst nur als Kosten wahrgenommen werden und die Vorteile durch mehr
IS nur schwer zu quantifizieren sind, besteht die Gefahr, dass der IS-Manager die
notwendigen Kontrollen beim Management nicht durchgesetzt bekommt. Hier hilft
es, wenn dem Management klar Entscheidungsvorlagen -vorzugsweise auf Basis
praktischer Beispiele aus dem Umfeld der eigenen Organisation- gegeben werden.
Dabei ist es wichtig, das Management nochmals auf seine Verantwortlichkeit bzgl.
der Übernahme von Risiken für die Organisation hinzuweisen.
Mögliche Probleme
Bei Anwendung einer Security Baseline stellt sich häufig das Problem, dass den
Kontrollen bzw. Maßnahmen dieser Security Baseline zu viel Vertrauen geschenkt
Fehlender Business Case
Anpassung an das
Risikoprofil
Seite 50
Studienbrief 3 Risikomanagement im Bereich IS
wird. Wenngleich die Anwendung einer Security Baseline aus den bereits weiter
oben genannten Gründen sehr sinnvoll ist, wird kaum eine Organisation ohne
zusätzliche Kontrollen für einige ihrer Geschäftsprozesse auskommen können zumindest dann nicht, wenn die Security Baseline eine echte Baseline ist und keine
hochspezifischen Kontrollen und Maßnahmen mit beinhaltet.
3.6 Der Prozess des Risikomanagements
Prozess des Risikomanagements
Gap-Analyse
Der wesentliche Aspekt im Risikomanagementprozess ist das Managen der Risiken durch Identifizierung des aktuellen und maximal tolerierbaren Risikoniveaus.
Durch diese so genannte Gap-Analyse wird die Voraussetzung geschaffen, die
verbleibenden Risiken durch ein adäquates Risikomanagement auf ein akzeptables Niveau zu bringen. Der IS-Manager muss nun dem Management über die
Ergebnisse der Gap-Analyse berichten, bspw. mit regelmäßigen Treffen, bei denen
er über den Status der IS in der Organisation informiert. In diesem Bericht müssen
alle signifikanten Änderungen des Risikoprofils der Organisation enthalten sein,
damit dem Management die Gelegenheit gegeben wird, auf diese zu reagieren
und die entsprechenden Entscheidungen bzgl. des Umgang mit diesen Risiken
zu treffen. Grundlage dafür ist eine kontinuierliche Neubewertung der Risiken in
Kombination mit Ereignis-basierten Berichten, bspw. bei Malware-Vorfällen.
Risikoregister
Das Risikoregister (engl.: risk register)stellt letztendlich die formale Dokumentation
der Risiken einer Organisation dar und ist somit das Ergebnis des Risikoassessments. Im Risikoregister sind dabei alle Risiken mit ihren Ursachen, etwaigen vorhandenen Kontrollen und Maßnahmen, der Wahrscheinlichkeit und den Auswirkungen des Risikos aufzunehmen - es ist somit die Grundlage der Gap-Analyse.
Erstellung eines Zeitplans
Nach erfolgter Gap-Analyse müssen nun etwaige Problemstellen behoben werden.
Mit den Details der zu etablierenden Kontrollen bzw. Maßnahmen wird ein definierter Zeitplan erstellt, nach dem die Implementierung erfolgen soll. Dazu sind
jeweils der Verantwortliche zu benennen, es sind die benötigten Ressourcen zu
ermitteln und -vom Management- ein entsprechendes Budget zuzuweisen. Damit
können dann die Risiken der Organisation auf ein akzeptables Niveau gesenkt
werden, wobei gleichzeitig keine unangemessenen Invesititionen in Kontrollen
und Maßnahmen getätigt werden.
Mögliche Probleme
Eine mögliche Gefahr liegt in diesem Bereich definitiv darin, dass die dem Management übergebenen Reports nicht (mehr) dem aktuellen Risikoprofil entsprechen.
Damit werden die Entscheidungen des Management auf einer falschen Informationsbasis getroffen und können zu fehlerhaften Investitionen und/oder zu nicht
adäquaten Restrisiken führen.
3.7 Einbindung in die normalen “Prozesse” der Organisation
Risikomanagement
als “normaler” Prozess
Ohne Einbindung des Risikomanagementprozesses in die “normalen” Geschäftsprozesse der Organisation steigt allerdings die Gefahr, dass der Risikomanagementprozess zu einer einmaligen und damit nicht dauerhaft angelegten Aktion
wird. Zudem steigt die Gefahr, dass unterschiedliche Bereiche in der Organisation
unterschiedlich und nicht wiederholbar vorgehen. Damit ist eine Vergleichbarkeit
innerhalb der Organisation und im Zeitverlauf nicht gegeben, was das Lernen aus
potentiellen Fehlern erheblich erschwert.
3.8 Monitoring von Risiken
Seite 51
Zur Integration in die normalen Geschäftsprozesse bieten sich unterschiedliche
Vorgehensweisen an. Eine Möglichkeit besteht darin, den Systementwicklungszyklus (engl.: System Development Lify Cycle mit den Phasen Initiierung, Design,
Entwicklung, Implementierung, Betrieb und Aussonderung dazu zu nutzen, das
Risikomanagement in den laufenden Betrieb mit zu integrieren. Bei diesem Ansatz
können alle Phasen dazu genutzt werden, neue Risiken zu evaluieren bzw. bereits
bestehende Risiken neu zu bewerten. Je eher das Risikomanagement dabei im Life
Cycle integriert wird, desto eher lassen sich mögliche Auswirkungen erfassen und
damit auch frühzeitig korrigieren.
Mögliche Einstiegspunkte
Eine weitere Möglichkeit besteht darin, das Risikomanagement an das ChangeManagement in der Organisation anzukoppeln. Damit wird sicher gestellt, dass
jegliche Änderung in der Organisation direkt auf ihre Auswirkungen bzgl. möglicher Risiken hin analysiert wird. Vorteil dieses Ansatzes ist, dass die in einer
lebendigen Organisation recht häufigen Änderungen bzgl. ihrer (neuen) Risiken
nicht vernachlässigt werden können, da die Bewertung von Risiken integraler
Bestandteil des Change-Managements ist. Außerdem kann auch der “Einkaufsprozess” ein guter Anknüpfungspunkt für die Anbindung des Risikomanagements
sein. Welcher dieser Mechanismen tatsächlich für die Anbindung des Risikomanagements genutzt wird, hängt auch von der Art der Organisation ab.
Ankopplung an das
Change-Management
In diesem Bereich kommt es häufig zu Problemen bei der Integration des Risikomanagements. Eine Ursache ist bspw., dass den Anforderungen des Geschäftsbetriebs
eine deutlich höhere Priorität eingeräumt wird, insbesondere bei der Einführung
von neuen oder Änderungen an bereits bestehenden Systemen. Dadurch wird die
Risikobewertung erschwert oder ganz unmöglich gemacht, was sich letztendlich
in einer falschen Einschätzung der Risiken niederschlägt.
Mögliche Probleme
3.8 Monitoring von Risiken
Das Monitoring der Risiken stellt in einer Organisation einen weiteren Eckpfeiler
für einen erfolgreichen Risikomanagementprozess dar. Es dient dazu, Änderungen
rechtzeitig zu erkennen und so angemessen auf die geänderte Risikolage reagieren
zu können. Eine Business Impact Analyse (kurz: BIA) kann dabei sehr hilfreich sein,
denn sie stellt die Auswirkungen auf die Geschäftsprozesse dar und bewertet diese.
Häufig ist eine BIA auf den Verlust von Informationen, also auf eine Verletzung des
Schutzziels der Verfügbarkeit, gerichtet. Damit rücken Parameter wie die Recovery
Time Objective (kurz: RTO) bzw. die Recovery Point Objective (kurz: RPO) in den
Fokus. Die RTO gibt dabei an, wie schnell das letzte Backup wieder restauriert
werden kann, während die RPO angibt, wie alt die Daten aus dem letzten Backup
sind.
Monitoring als Eckpfeiler
Das Monitoring der Risiken sollte wie auch das gesamte Risikomanagement in
einer Organisation auf unterschiedlichen Ebenen angewendet und dabei sollten
sowohl strategische, aber auch operationale Projekte in der Organisation berücksichtigt werden. Zudem sollte es auch bei spezifischen (kleineren) Projekten, spezifischen Entscheidungen (des Managements) und spezifischen Prozessen zum
Tragen kommen.
Unterschiedliche Ebenen
Ein Problem ist hauptsächlich, dass die Aufwände für ein kontinuierliches Monitoring der Risiken einer Organisation völlig unterschätzt wird. Dies führt zu
viel zu geringen Ressourcen und damit zu “Engpässen”. Kombiniert mit einer
Priorisierung des Geschäftsbetriebs, den wir weiter oben schon angesprochen hatten, mündet dies in einem Prozess, der die Änderungen und Neuerungen (durch
Mögliche Probleme
Seite 52
Studienbrief 3 Risikomanagement im Bereich IS
die geänderten und/oder neuen Geschäftsprozesse) nicht ausreichend berücksichtigt. Fehlt ein formaler Prozess zur Risikobewertung, so werden die Risiken
nicht konsistent bewertet, da die Entscheidungen aus dem Bauch heraus, aber
nicht systematisch getroffen werden. Weitere Probleme ergeben sich, wenn die Geschäftsprozessverantwortlichen die notwendigen Sicherheitsanforderungen bzw.
die Bedeutung fehlender Kontrollen nicht verstehen. Und wie immer ist zur Sicherstellung von Ressourcen und Übernahme der Verantwortung eine angemessene
Beteiligung des Managements unablässlich.
3.9 Bericht von Compliance-Verletzungen
Non-Compliance
als Grundlage
Der Bericht von Non-Compliance-Zuständen und Änderungen bzgl. der Risiken
dient dazu, dem Management eine Entscheidungsgrundlage für den Risikomanagementprozess zu liefern. Non-Compliance-Zustände, bspw. Verletzung der
Sicherheitsleitlinien, können durch unterschiedliche Maßnahmen ermittelt werden.
So leisten bspw. die Ergebnisse von Audits und Reviews, die in der Organisation
durchgeführt wurden, einen guten Beitrag, Missstände aufzudecken, hinzu kommen spezifische Schwachstellenscans, aber auch Aktivitäten im Bereich der Due
Diligence, etwa beim Zukauf.
Schnittstelle
Security Baseline
Insbesondere Vorfälle, die die Security Baseline betreffen, sind zu monitoren, da
durch den Baseline-Ansatz dann direkt eine Vielzahl von Prozessen in der Organisation betroffen sein werden - Vorfälle bzgl. der Security Baseline haben sozusagen
einen Multiplikatorfunktion. Dabei muss auch hinterfragt werden, ob eine Neubewertung der gesamten Baseline notwendig wird. Änderungen an der Security
Baseline können dabei aus unterschiedlichsten Gründen erforderlich werden, bspw.
wenn ein Hersteller seine Parametrisierung angepasst hat, neue Software-Versionen
und/oder Patche verfügbar geworden sind oder externe Faktoren eine Erhöhung
des “Grundschutzniveaus” durch die Security Baseline erforderlich machen.
Mögliche Probleme
Insbesondere die Anwendung eines nicht (Management-)geeigneten Berichtswesens trägt immer wieder zu Problemen in diesem Bereich bei, hinzu kommt ein
falscher oder gänzlich fehlender Prozess zur Ermittlung der Non-ComplianceZustände und damit eine nicht reproduzierbare Bewertungsgrundlage.
Zusammenfassung dieses Studienbriefs
Zusammenfassung
Ein adäquates Risikomanagement bildet die Grundlage für effektive und effiziente
Maßnahmen im Bereich der IS. Damit ist es auch eine Grundvoraussetzung für die
Planung und Implementierung des IS-Programms, in dem die Maßnahmen, die
sich aus den Ergebnissen des Risikomanagements ableiten, umgesetzt werden. Auf
die Gestaltung des Prozesses zur Planung und Implementierung des IS-Programms
gehen wir nun im nächsten Studienbrief im Detail ein.
Studienbrief 4 Umsetzung im IS-Programm
Seite 53
Studienbrief 4 Umsetzung im IS-Programm
In diesem Abschnitt geht es nun um die Erstellung und Aufrechterhaltung des
Programms zur Umsetzung der Informationssicherheit (kurz: IS-Programm, engl.:
security program). Dabei soll auch sicher gestellt werden, dass ein Verständnis
für die vielfältigen Anforderungen und Aktivitäten bei der Umsetzung des Sicherheitsprogramms geschaffen wird und damit überhaupt die Voraussetzung
entsteht, die Anforderungen aus der Sicherheitsstrategie durch Etablieren des
Sicherheitsprogramms in der Organisation umzusetzen.
Ziele dieses Kapitels
Im Rahmen der Erstellung und Umsetzung des Sicherheitsprogramms, das letztendlich zum Ziel hat, die Risiken im Bereich der IS effektiv und effizient zu managen, sind vielfältige Aufgaben zu erledigen. Dazu gehören unter anderem die
Erstellung einer Sicherheitsarchitektur, die Entwicklung von Standards, Arbeitsanweisungen und weiteren “Policy-Elementen”, die Entwicklung eines IS-Plans,
die Entwicklung von Sicherheitstrainings und Awarenessprogrammen und die
Einführung von Metriken zur Bewertung des Sicherheitsprogramms.
Erstellung und Umsetzung des Sicherheitsprogramms
Grundlagen zum Informationssicherheitsprogramm
Damit die Vorgaben der IS-Strategie sinnvoll in der Organisation umgesetzt werden
können, muss ein Sicherheitsprogramm erstellt werden, das konsequent an der
IS-Strategie ausgerichtet ist. Bereits im Rahmen der Einführung der IS-Governance
(vgl. dazu auch Studienbrief 2) wurden die IS-Strategie und IS-Organisation festgelegt, die Zustimmung des Managements der Organisation zum Rahmenkonzept
im Bereich der IS-Governance eingeholt und anschließend das Rahmenkonzept
zur IS-Governance umgesetzt. Nun müssen alle Details zur Entwicklung und Aufrechterhaltung des IS-Programms berücksichtigt werden, man könnte auch sagen,
damit werden die Anforderungen durch die IS-Governance auf die Arbeitsebene
gebracht und in der Organisation “gelebt”.
Von der Strategie
zum Programm
Durch den Aufbau und die kontinuierliche Weiterentwicklung des IS-Programms
sollen im wesentlichen fünf Grundziele erreicht werden: Die “strategische Ausrichtung” des IS-Programms an den Zielen der Organisation und damit auch an den
Vorgaben der IS-Strategie, die Etablierung eines Risikomanagements und Berücksichtigung der Ergebnisse bei der Umsetzung des IS Programms, um die Risiken
auf einem für die Organisation vertretbaren Niveau zu managen, die Schaffung
von Mehrwerten durch das Einbringen von IS im Rahmen der Umsetzung des
IS-Programms, ein sinnvolles Ressourcenmanagement bei der Etablierung des ISProgramms und eine kontinuierliche Messung der Performance des IS-Programms,
damit sicher gestellt werden kann, dass die Ressourcen der Organisation effektiv
und effizient eingesetzt werden.
Wesentliche Ziele
Das IS-Programm darf allerdings nicht wie ein singulärer Prozess, sondern muss
vielmehr als Kreislauf verstanden werden, ein Vergleich mit dem PDCA-Kreislauf
ist durchaus sinnvoll. Im Rahmen des IS-Programms wird aus der IS-Strategie
das Policy-Rahmenwerk abgeleitet, das seinerseits über entsprechende Awareness die Grundlage für die Implementierung von IS-Maßnahmen schafft. Im Rahmen der Implementierung findet sich wiederum ein PDCA-artiger Kreislauf, diesmal bestehend aus den Elementen “Prävention”, “Detektion” und “Korrigieren”
von Schwachstellen und Verwundbarkeiten. Nach erfolgreicher Implementierung
schließt sich die Phase des Monitorings an, das gleichzeitig auch die Grundlage
für die (Überprüfung der) Compliance liefert.
Lebenszyklus des ISProgramms
Seite 54
Studienbrief 4 Umsetzung im IS-Programm
Aufgaben des
IS-Managers
während der Strategieentwicklung
...während der
Implementierung
...während des
Monitoring
Mögliche Probleme
Im Rahmen dieser Teilschritte hat der IS-Manager unterschiedliche Aufgaben zu
übernehmen. In der Phase der Strategieentwicklung beobachtet er die Industry
Best Practices vergleichbarer Organisationen und erstellt daraus Vorschläge für die
Erstellung der Strategie. In der Phase der Erstellung des Policy Frameworks erstellt
der IS-Manager die Leitlinen, sowie die daraus abgeleiteten Dokumente (bspw.
Standards, Arbeitsanweisungen, ...). Diese bilden gleichzeitig auch einen Teil der
Inhalte der Awarenessmaßnahmen, die der IS-Manager koordiniert (bspw. indem
er die Gruppen von Mitarbeitern zusammen stellt und die passenden Inhalte aussucht). In der Phase der Implementierung (der Sicherheitsmaßnahmen) ist der
IS-Manager dann im Rahmen des Security Review-Prozesses oder im Rahmen von
Sicherheits-spezifischen Projekten für die Bereitstellung der Sicherheitsarchitektur,
des Designs der Sicherheitsmaßnahmen und der Strategie zu deren Umsetzung zuständig. Für die Phase des Monitorings stellt der IS-Manager schließlich Metriken
zur Bewertung der Sicherheitsmaßnahmen zusammen und analysiert regelmäßig
die Wirksamkeit bzw. Umsetzung der Maßnahmen. Bei Compliance-Verstößen
ist der IS-Manager schließlich die Eskalationsstelle und übernimmt die Aufgabe,
Sicherheitsverstöße zu untersuchen und entsprechende Empfehlungen für die
Anpassung der Strategie zu geben.
Häufig wird jedoch unterschätzt, welche Aufgaben auf den IS-Manager im Rahmen
der Erstellung und Umsetzung des IS-Programms zukommen. Neben der strategischen Komponente, die vor allem dazu dient, eine Ausrichtung des IS-Programms
an der IS Strategie und damit auch an der Strategie der Organisation zu erreichen,
beinhaltet das IS-Programm viele Detailaspekte, die -etwa im Rahmen der Umsetzung von Sicherheitsmaßnahmen- berücksichtigt werden müssen. Ein weiteres
Problem besteht auch darin, dass kein Risiko-basierter Ansatz bei der Auswahl
und Umsetzung von Kontrollen und Maßnahmen genutzt wird.
Weitere Gliederung des Studienbriefs
Erforderliche Teilschritte
Dabei betrachten wir die folgenden, wesentlichen Teilschritte, die im Rahmen des
Aufbaus und der Aufrechterhaltung des IS-Programms erforderlich sind (vgl. dazu
auch [7]):
1. Sicherstellen, dass das IS-Programm konsequent an der IS-Strategie ausgerichtet ist und eine Integration (und Ausrichtung) des IS-Programms in
die/an den übrigen Geschäftsprozesse/n gewährleistet ist.
2. Anforderungen für interne und externe Ressourcen, die für die Umsetzung
des IS-Programms notwendig sind, ermitteln und beschaffen, sowie einen
entsprechenden Managementprozess etablieren.
3. Aufbau und Aufrechterhaltung einer IS-Architektur (unter Berücksichtigung
der drei Elemente Menschen, Prozesse und Technik), die die Umsetzung des
IS-Programms unterstützt.
4. Aufbau, Kommunikation und Aufrechterhaltung von IS-Standards,
IS-Arbeitsanweisungen (engl.: information security procedures) und ISHandlungsempfehlungen (engl.: information security guidelines) sowie weitere
Dokumentation, um die Übereinstimmung mit den IS-Leitlinien (engl.:
information security policies) zu unterstützen und zu steuern.
5. Aufbau und Aufrechterhaltung eines Awareness- und Training-Programms,
um ein sicheres Arbeitsumfeld und eine effektive Sicherheitskultur zu fördern.
4.1 Ausrichtung des IS-Programms an den übrigen “Prozessen” der Organisation
Seite 55
6. Einbindung der IS-Anforderungen in die übrigen organisatorischen bzw.
geschäftlichen Prozesse (bspw. Change-Management, Beschaffung, ...), um
die Security Baseline aufrecht zu erhalten.
7. Einbindung der IS-Anforderungen in das Vertragsmanagement und das
Management der Beauftragung Dritter (bspw. beim Outsourcing), um die
Security Baseline auch bei diesen (ggf. ausgelagerten) Prozessen aufrecht zu
erhalten.
8. Aufbau eines Monitoring und regelmäßige Berichte von Metriken zum Management und zum Betrieb des IS-Programms, um die Effektivität und Effizienz
des IS-Programms zu bewerten.
Die weiteren Abschnitt dieses Studienbriefs gehen nun auf die konkreten Fragen bei
der Umsetzung der einzelnen Teilschritte ein. Dabei werden wir uns zunächst mit
der Frage beschäftigen, wie das IS-Programm an den übrigen Geschäftsprozessen
der Organisation ausgerichtet werden kann.
4.1 Ausrichtung des IS-Programms an den übrigen
“Prozessen” der Organisation
Nachdem in der Einleitung bereits beschrieben wurde, was die Ziele des ISProgramms sind, welche Aufgaben der IS-Manager übernehmen muss und welche
spezifischen Aufgaben im Rahmen des Aufbaus und der Aufrechterhaltung des
IS-Programms berücksichtigt werden müssen, soll nun der Teilprozess “Integration in die Geschäftsprozesse” betrachtet werden. Dieser Aspekt trägt entscheident
zum Gelingen eines IS-Programms bei und um ihn bestmöglich zu gewährleisten,
muss zunächst einmal sicher gestellt werden, dass das IS-Programm überhaupt
an den übrigen Geschäftsprozessen in der Organisation ausgerichtet ist. Dazu
gehört insbesondere eine Integration des IS-Programms in die Prozesse in den
Bereichen Personalwesen (engl.: human ressources), Buchhaltung (engl.: accounting) und Beschaffung (engl.: procurement), da diese gute Anknüpfungspunkte für
Sicherheitsmaßnahmen bilden.
Integration als Eckpfeiler
des IS-Programms
Im Rahmen des bereits erwähnten PDCA-Kreislaufs finden sich vielfältige Möglichkeiten für die Einbindung der üblichen Geschäftsprozesse einer Organisation,
wobei jeweils unterschiedliche Akteure mit eingebunden werden können. Dabei
werden zum Teil nur einzelnen Bereiche (so bspw. bei der Entwicklung der Strategie das Technology Steering Commitee) berücksichtigt, teils findet die Unterstützung
auch durch mehrere Akteure statt (so bspw. im Rahmen des Awareness durch das
Personalwesen und die Verantwortlichen für die Geschäftsprozess), in anderen
Bereichen wiederum sollten hingegen alle Beteiligten mit eingebunden werden (so
bspw. bei der Entwicklung von Leitlinien).
Vielfältige Anknüpfungspunkte
Bei der Integration der “Sicherheit” in die üblichen Geschäftsprozesse stellt sich
vor allem das Problem, dass diese Integration bzw. die Zusammenarbeit mit den betreffenden Bereichen nicht ausreichend ist. Dadurch kann es zu einem fehlerhaften
Zusammenspiel der einzelnen Bereiche und damit auch zu einer mangelhaften Koordination beim Aufbau und der Umsetzung des IS-Programms kommen. Zudem
kann die Umsetzung des IS-Programms auch von Machtkämpfen innerhalb der
Organisation überschattet werden, so dass letztendlich Ressourcen weder effektiv
noch effizient genutzt werden.
Mögliche Probleme
Seite 56
Studienbrief 4 Umsetzung im IS-Programm
4.2 Bestimmung von internen und externen Ressourcen
Vielfältige Ressourcen
Zur Umsetzung des IS-Programms sind die benötigten internen oder externen
Ressourcen zu definieren, zu identifizieren, anzufordern und entsprechend zu
managen. Dabei kommen unterschiedlichste Ressourcen bzw. Querverbindungen
zu anderen Bereichen der Organisation in Frage, bspw. aus dem Bereich der Informationssicherheit, aus dem Bereich der Verwaltung interner Ressourcen (wie etwa
der Finanzverwaltung, des Personalwesens oder auch des Projektmanagements)
oder auch im Rahmen der Zusammenarbeit mit “Externen”.
Bereich “Sicherheit”
Ressourcen bzw. Anbindungen im Bereich “Sicherheit” liegen vor allem in der
Administration von Datenbanken und Systemen, sowie denjenigen Ressourcen,
die durch externe Quellen zur Verfügung gestellt werden - zu diesem Bereich
zählen etwa Lieferanten von Sicherheitssoft- und -hardware, Berater, aber auch
Institutionen aus der Sicherheitsforschung oder Standardisierung.
Bereich “Finanz- und
Projektmanagement”
Im Bereich der Verwaltung interner Ressourcen sind die genauen Anknüpfungspunkte unterschiedlicher Natur: Im Bereich Finanzverwaltung und Projektmanagement kann auf die dortigen Erfahrungen für Budgetierungen, Zeitplanung,
Beschaffungen und auch der Messung von TCO und RoI zurück gegriffen werden.
Das Personalwesen unterstützt im Wesentlichen durch die Arbeitsplatzbeschreibungen bereits vorhandener Mitarbeiter, beim Prozess der Neueinstellung bzw,
Versetzung, bei der Zeiterfassung und Gehaltsabrechnung oder auch im Rahmen
der Mitarbeiterentwicklung.
Bereich “Externe”
Auch die Bereiche Service Provider bieten wichtige Anknüpfungspunkte. Insbesondere ist zu berücksichtigen, dass “Dritte” (als Dienstleister) ebenfalls ein nicht
unbedeutendes Risiko für die Informationswerte der Organisation darstellen. Dabei sind insbesondere die Aspekte “Vertraulichkeitsveeinbarungen” und “angemessene Nutzung” (engl.: acceptable use policy) zu berücksichtigen. Die sorgfältige
Prüfung (engl.: Due Diligence) von Verträgen und vereinbarungen sollte die beiden
genannten Aspekte mit einschließen, Sicherheitsüberprüfungen sollten regelmäßig
die Einhaltung der Vorgaben überprüfen.
Bereich
“Managed Security Services”
Zudem sollte der IS-Manager nicht unberücksichtigt lassen, dass im Bereich “Sicherheit” immer mehr Dienstleister eingesetzt werden, man spricht dann auch von
Managed Security Services. Dies gilt insbesondere für Dienste im Bereich Netzwerkmanagement, bspw. bei der Einbruchserkennung (engl.: intrusion detection) (wo
häufig die Auswertung der Protokolldaten ausgelagert wird) oder auch bei der
Schwachstellenerkennung.
Mögliche Probleme
Neben dem Vorteil, bereits existierende Prozesse und Strukturen innerhalb der
Organisation weiter verwenden zu können (und damit zu einem effektiven Einsatz
der Ressourcen beizutragen), bringt dies aber auch Probleme mit sich. Grundsätzlich kann es natürlich vorkommen dass die oben angesprochenen Bereiche
die notwendigen Teilaktivitäten nur unzureichend bzw. überhaupt noch nicht
haben. Das führt dazu, dass der IS-Manager die entsprechenden Tätigkeiten dann
entweder selbst implementieren bzw. durchführen muss (sehr ineffizient) oder
die Bereiche dazu bringen muss, die notwendigen Tätigkeiten in ihre Prozesse
zu integrieren. Neben dem zeitlichen Aspekt ist dabei dann naturgemäß einiges
an Überzeugungsarbeit zu leisten, denn natürlicherweise werden die Bereiche
die Mehrarbeit zunächst ablehnen und für ihren eigenen Bereich auch für nicht
notwendig erachten - eine gute Unterstützung durch die Compliance-Abteilung
kann dem IS-Manager hier wichtige Hilfestellung geben. Darüber hinaus können
auch unangemessen komplizierte Beschaffungsprozesse hinderlich sein, die Einbindung von Dienstleistern verstärkt zudem den Effekt der Gleichgültigkeit bei
4.3 Architektur der Informationssicherheit
Seite 57
den eigenen Mitarbeitern (“Dafür haben wir doch einen Dienstleister!”), der zu
den allgemeinen Problemen im Bereich des Outsouring zählt.
4.3 Architektur der Informationssicherheit
Auch die Architektur der Informationssicherheit stellt einen wichtigen Baustein
im Rahmen der Entwicklung und Aufrechterhaltung des Informationssicherheitsprogramms dar und besteht dabei aus den drei üblichen Komponenten Personen,
Prozesse und Technologie. Sicherheitsarchitekturen kommen dabei für eine Vielzahl von Technologien in Betracht, bspw. für den Bereich Netzwerksicherheit mit
Firewall und IDS/IPS, Webanwendungen, Datenbanken und Authentifizierungssysteme.
Unterschiedliche Betrachtungsweisen
Im Allgemein bezeichnet die Architektur die Bauweise von Gebäuden und Räumen. Im Bereich der IS ist allerdings eher der Aufbau von IS-relevanten Systemen
gemeint. Die Architektur stellt dann bspw. den Aufbau und die Funktion von
IT-Systemen und der zugehörigen IS-Maßnahmen dar und kann von einem Überblicksbild des Netzwerks bis hin zu einem sehr detailreichen Prozessdiagramm
reichen.
Architektur
1
3
FW
IDS
FW
IDS
4
LAN
DMZ
2
Abb. 4.1: Darstellung einer Netzwerk-Architektur
mit möglichen Positionen zum Einsatz von
IS-Maßnahmen.
Abbildung 4.1 zeigt das Beispiel einer Netzwerk-Architektur, in der durch die
nummerierten die zum Einsatz möglicher IS-Maßnahmen (wie DMZ, Firewall,
IDS/IPS, ...) sinnvollen Positionen dargestellt sind. Anhand dieses Schaubildes
kann nun ermittelt werden, ob alle wesentlichen Kommunikationsverbindungen
und Informationsressourcen durch entsprechende Maßnahmen abgesichert sind.
Als mögliches Problem in diesem Bereich ist vor allem eine falsche und/oder
Applikation
Zugriffskontrolle
unvollständige Architektur bzw. ein fehlerhaftes
Design derselben zu nennen.
Dies führt dann -aufgrund von falschen Voraussetzungen- zu einem fehlerhaft
Middleware
derfehlendes
DB
umgesetzten IS-Programm.
Darüber hinausAbsicherung
stellt auch ein
oder unzureichendes Design der IS ein mögliches Problem dar.
Betriebssystem
Zugangskontrolle
Mögliche Probleme
Zutrittskontrolle
Hardware
4.4 Standards, Arbeitsanweisungen und
Handlungsempfehlungen
Network Admission Control
Netzwerk
Damit die Verfahren und Prozesse einer Organisation die IS-Leitlinien unterstützen
und Sicherheit damit auch gelebt wird, müssen vor allem Standards, Arbeitsanweisungen und Handlungsempfehlungen sowie weitere Dokumente erstellt, in der
Organisation kommuniziert und letztendlich auch aufrechterhalten, d.h. fortlaufend weiter entwickelt werden. Dabei sind die entsprechenden Dokumente jeweils
unterschiedlichen Ebenen der Policy-Pyramide zugeordnet.
Von der Leitlinie zur
Praxis
Seite 58
Studienbrief 4 Umsetzung im IS-Programm
Leitlinie
Freigabe durch das
Senior Management
Standards
Wichtige Aspekte
Im ersten Schritt muss die IS-Leitlinie erstellt werden, die den groben Rahmen
der IS in der Organisation beschreibt und damit auch die Basis für die weiteren
Ebenen der Dokumentenhierarchie darstellt. Insofern kommt der Entwicklung der
IS-Leitlinie eine besondere Bedeutung zu, wirken sich die Inhalte der Leitlinie letztendlich auch auf die konkreten Handlungsempfehlungen bzw. Orientierungshilfen
und damit auch auf das tägliche “Doing” in der Organisation aus. Die Leitlinie
wird grundsätzlich vom Senior Management bzw. dem zuständigen Aufsichtsgremium der Organisation freigegeben und von diesem unterstützt. Allerdings
meint “unterstützt” hier mehr als “per Brief mit Unterschrift” verteilt und ist eher
im Sinne von “gelebt” zu verstehen, d.h. das Management geht selbst mit gutem
Beispiel voran und ordnet sich den sich aus den Leitlinien ergebenden Regeln
unter. Die Freigabe durch das Senior Management bewirkt dabei auch, dass alle
Verantwortlichen in der Organisation die Regeln unterstützen und somit im Falle
eines Konfliktes auch sinnvoll abwägen, ob nun eine Ausnahme zur Regel notwendig ist (weil ggf. der entsprechenden Sachverhalt bei der Erstellung der Regel nicht
bedacht wurde) oder der Prozesse an die Vorgabe der Regel anzupassen ist.
Während die aus der Sicherheitsstrategie abgeleitete Leitlinie eine grobe Richtung
vorgibt, bilden die Standards die erste Ebene, die auch tatsächlich in Metriken abgebildet werden kann und damit auch dazu geeignet ist, die Umsetzung der Vorgaben
im Bereich der IS zu messen. Für Organisationen stehen dabei mit den gängigen
Standards im Bereich der IS-Werkzeuge zur Verfügung, die als Ausgangspunkt
für die Entwicklung der weiteren Elemente der eigenen Policy Pyramide dienen
können. Dazu zählen etwa die ISO 27000er-Reihe, die Standards des National Institute for Standards and Technology (kurz: NIST), sowie die Vorgaben durch ITIL oder
auch COBIT (wobei bei letzteren die Aspekte der Security gemeint sind). Zu einem
IS-Standard gehören dabei unter anderem die Aspekte der Datenklassifizierung,
der Risikoanalyse und -bewertung, der Zutritts-, Zugangs- und Zugriffskontrolle,
der Netzwerksicherheit, des Umgangs mit mobilen Geräten, des Change Managements, der Sicherheitsvorfallsbehandlung, aber auch des Datenschutzes und der
Schulung von Mitarbeitern. Betrachtet man diese Auflistung, so wird auch hier
das Drei-Säulen-Modell “Personen, Prozesse und Technik” deutlich.
“One size
DOESN’T fit all!”
Damit die (allgemein einsetzbaren) Vorgaben der Standards auch in der eigenen
Organisation sinnvoll eingesetzt werden können, müssen diese entsprechende
den Anforderungen der eigenen Organisation angepasst werden. Dabei sind die
Anforderungen, die sich aus dem Risikomanagement ergeben haben, aber auch
die Vorgaben bzgl. der Kultur der Organisation zu berücksichtigen. Zudem ist
unter Einsatz des PDCA-Zyklusses eine regelmäßige Überprüfung des ComplianceStatus vorzunehmen und dabei die Effektivität der Leitlinie zu ermitteln. Auf Basis
dieser Ergebnisse werden dann entweder die Methoden angepasst oder die Leitlinien entsprechend überarbeitet. Zu berücksichtigen ist, dass die unteren Ebenen
der Policy Pyramide den größten Aufwand darstellen - dies gilt sowohl für die
Erstellung der zugehörigen Dokumente, die Implementierung der entsprechenden
Vorgaben und auch für die Überprüfung der Einhaltung derselben.
Darstellung
Im Rahmen der Dokumentenstruktur der Policy Pyramide werden zumeist zahlreiche Dokumente erstellt, die den betreffenden Personen in der Organisation auf
sinnvolle Art und Weise zur Verfügung gestellt werden müssen. Dazu sind insbesondere Web-basierte Dokumente geeignet, die durch ihre Hypertext-Struktur
auch die Verlinkung von unterschiedlichen Dokumenten ermöglichen. Dadurch
kann bspw. in einem Standard direkt auf die notwendigen Handlungsanweisungen
und Orientierungshilfen verwiesen werden, was das Handling für die Personen,
die die Anforderungen tatsächlich implementieren müssen, deutlich vereinfacht.
Dabei können auch weitere Hinweise, bspw. Links für Downloads von Sicherheitssoftware eingebunden werden.
4.4 Standards, Arbeitsanweisungen und Handlungsempfehlungen
Seite 59
Während die Leitlinie die übergeordnete Hierarchie darstellt, bilden die Standards
wie bereits erwähnt die Schicht, die erste messbare Anforderungen vorgibt. “Gefüllt” werden die Standards dann mit Arbeitsanweisungen (engl.: procedures), die
vorgeben, was getan werden muss, um die Vorgaben der Standards (und damit
auch die der Leitlinie) zu erfüllen. Diese Arbeitsanweisungen werden ggf. noch
um Handlungsempfehlungen (engl.: guidelines) ergänzt, die Vorschläge machen,
wie die Anforderungen “einfach” umgesetzt werden können. Diese Vorschläge
sind allerdings nicht verpflichtend umzusetzen, aber dennoch wünschenswert, da
dadurch eine möglichst einheitliche Arbeitsweise gefördert wird.
Arbeitsanweisungen
und
Handlungsempfehlungen
Arbeitsanweisungen und Orientierungshilfen sind für alle Bereiche der Organisation entsprechend den Vorgaben der Leitlinien bzw. der Standards zu erstellen,
damit eine Implementierung der Leitlinie in der Fläche erfolgt. Typischerweise
werden dabei Arbeitsanweisungen und Orientierungshilfen für die Sicherheit in
den Bereichen Netzwerk, Betriebssystem, Datenbank, Anwendungen, im Bereich
der Virtualisierung, der physischen Sicherheit und auch der Administration und
des Change-Management erstellt.
Implementierung in der
Fläche
Arbeitsanweisungen helfen der “Arbeitsebene” die Anforderungen, die sich aus der
Leitlinie und den Standards ergeben, tatsächlich im täglichen Einsatz auch “leben”
zu können. Sie stellen damit auch die Dokumentenhierarchie dar, die von den
Mitarbeitern tatsächlich gelesen werden sollte. Während die Leitlinien allgemein,
aber eben für diesen Einsatzzweck zu allgemein formuliert sind und damit zu
viel Interpretationsspielraum eröffnen, geben die Arbeitsanweisungen konkrete
Vorgaben und sind so formuliert, dass sie von der Arbeitsebene der Organisation
auch ohne Probleme verstanden werden. Dabei ist allerdings sicher zu stellen, dass
die Arbeitsanweisungen (genau so wie die Orientierungshilfen) kongruent zu den
Standards sind und keine widersprüchlichen Aussagen dazu treffen.
Unterstützung bei der
Umsetzung der Anforderungen aus der
IS-Leitlinie
Damit die Arbeitsanweisungen auch effektiv sind und sinnvoll in der Organisation
umgesetzt werden können, müssen sie vor allem klar und unmissverständlich
formuliert sein, um möglichst keinen Interpretationsspielraum zu lassen. Zudem
müssen sie zielgruppenorientiert geschrieben sein, bspw. sollten die Arbeitsanweisungen für Mitarbeiter aus der IT andere Formulierungen enthalten als die
für Anwender aus der Finanzabteilung. Die Erreichbarkeit der Dokumente ist ein
weiteres wichtiges Kriterium. Dazu zählt die Bekanntmachung der Dokumente,
aber auch die Möglichkeit, diese während der täglichen Arbeit abrufen zu können
- Webtechnologien bieten sich an. Zur Sicherstellung der Compliance ist zudem
ein kontinuierliches Monitoring der Arbeitsanweisungen notwendig, da hier Abweichung am ehesten erkannt werden können. Dazu sind formale Audits, aber
auch Self-Assessments ein mögliches Mittel.
Effektive Arbeitsanweisungen
Obwohl die Arbeitsanweisungen gut dokumentiert und klar beschrieben sind, können die Mitarbeiter Probleme bei der Umsetzung haben. Zur Unterstützung können
hier Awareness-Programme, spezielles Help-Desk-Personal und/oder auch eine
Security-Help-Line geschaffen werden. Auch bei diesen ergänzenden Maßnahmen
ist eine Unterstützung durch das Management von herausragender Bedeutung.
Nicht zuletzt tragen auch die bereits angesprochenen Orientierungshilfen zu einem
besseren Verständnis der Arbeitsanweisungen bei.
Unterstützung bei der
Umsetzung
Darüber hinaus fördern auch automatisierte Prozesse die Umsetzung der Vorgaben aus den Arbeitsanweisungen und die Kontrolle derselben. Dies gilt für die
Verwaltung von Benutzerkonten, der Verwaltung von Zugriffe auf Daten und Applikationen sowie den Prozessen zum Monitoring und Reporting. Unterstützend
können hier auch Web-basierte Mechanismen eingesetzt werden, etwa Webseiten
für die Beantragung von Zugriffsrechten und/oder Meldung von Sicherheitsvorfällen. Der dadurch erreichbare erhöhte Komfort führt zu einer besseren Compliance
Automatisierte Prozesse
Erreichbarkeit und
Bekanntmachung
Seite 60
Studienbrief 4 Umsetzung im IS-Programm
und meist auch zu einer besseren Qualität der (Geschäfts-)Prozesse. Zudem wird
die Erstellung und Nutzung von Metriken durch automatisierte Prozesse deutlich
vereinfacht.
Technische Unterstützung
Datenschutz beachten
Auch durch technische Maßnahmen kann die Durchsetzung von Arbeitsanweisungen unterstützt werden. Dazu zählen Managementsysteme für Anti-Malware und
der Lizenzierung von Softwarekomponenten. Proxy-Server und Web-Filter können
Regeln zum Zugriff auf Websites durchsetzen, bspw. mittels reinem Monitoring der
Zugriff oder auch durch expliziten Einsatz von Filtermechanismen (Datenschutzrechtliche Fragen beachten!). Zentralisierte Managementsysteme kommen darüber
hinaus auch im Bereich der Zugriffskontrolle oder dem Reporting von Ausnahmeregeln zum Einsatz und erhöhen - ähnlich wie die automatisierten Prozesse die Wahrscheinlichkeit die Leitlinien und Standards bzw. die Arbeitsanweisungen einzuhalten und damit auch Lösungsansätze mit schlechterer Qualität zu
reduzieren.
Mögliche Realisierungen Beispiel Security Baseline
Bei der Erstellung der Dokumente der Policy-Pyramide sind prinzipiell unterschiedliche Ansätze denkbar. Eine häufig zu findende Umsetzung basiert auf
einem zweistufigen Konzept: Stufe A stellen so genannte Security Baselines dar,
Stufe B deckt anschließend Bereiche mit einem höheren Risiko ab und geht dabei
auf die spezifischen Gefährdungen ein.
Baseline = minimal akzeptierbares Niveau
Die Security Baseline legt dabei das grundlegende, minimal akzeptierbare Sicherheitsniveau fest, das auf jeden Fall umgesetzt wird. Sie stellt damit ein Grundniveau
dar, dass auch dazu geeignet ist, in einem prozessorientierten Ansatz die Anforderungen, die sich aus der IS-Governance ergeben, in funktionale Anforderungen
abzubilden. Baselines, insbesondere Security Baselines, werden häufig auch von
Hard- und Softwarelieferanten festgelegt. In dem bereits erwähnten zweistufigen
Konzept würden durch die Security Baseline zunächst alle Server der Organisation mit entsprechenden Maßnahmen vor den grundlegenden Gefahren geschützt.
Diese Maßnahmen sind ausreichend, um die grundlegenden Gefährdungen von
Systemen mit einem normalen Risiko abzusichern. Bei Systemen mit erhöhtem
Risiko, bspw. Server mit Internetanbindung, sind weitere, dann aber spezielle
Maßnahmen erforderlich.
Zweistufiges Vorgehen
Baselines als “Netz
und doppelter Boden”
Security Baselines senken so das Risiko, das sich durch neue oder geänderte Systeme und Anwendungen ergeben könnte, falls die Mechanismen des ChangeManagements einmal versagen sollten. Zudem steigern sie auch die Effizienz von
Sicherheitsmaßnahmen und ermöglichen die Konzentration auf Bereiche mit einem erhöhtem Risiko. Als “Standard” schaffen sie zudem die Voraussetzung dafür,
Sicherheit in die Fläche zu bringen.
Ausnahmen
Im produktiven Einsatz werden in der Regel aber auch beim Einsatz von Security
Baselines punktuelle Ausnahmeregelungen erforderlich werden. Für diese Ausnahmen von den Standards bzw. den Security Baselines im produktiven Betrieb
wird dabei ein klar definiertes Vorgehen mit einem definierten Freigabeprozess benötigt. Im Rahmen der Freigabe ist zu berücksichtigen, dass die richtige Person mit
entsprechender Berechtigung gefunden werden muss. Hier können klar definierte
Rollen und Verantwortlichkeiten den Prozess deutlich vereinfachen. Bei jeder Genehmigung einer Ausnahmeregelung müssen zudem kompensierende Kontrollen
festgelegt werden, zudem ist die Genehmigung zeitlich beschränkt zu erteilen. Dadurch wird sicher gestellt, dass die Risiken, die sich durch die Ausnahme ergeben,
regelmäßig kontrolliert werden. Wichtig ist zudem ein adäquates Reporting der
Ausnahmeregelungen, das dafür Sorge trägt, dass die Ausnahmen von der Security Baseline nicht als einfacher Bypass-Prozess zum Standard-Sicherheitsprozess
eingesetzt werden können.
Ausnahmen erfordern kompensierende Kontrollen
Reporting der
Ausnahmen
4.4 Standards, Arbeitsanweisungen und Handlungsempfehlungen
Seite 61
Damit die Einbindung der Sicherheitsvorgaben in den Geschäftsprozessen möglichst reibungslos verläuft, können zentrale Prozesse dazu genutzt werden, die
Sicherheitsmechanismen bei jedem Prozesse mit zu verankern. Dazu zählen bspw.
die Prozesse zum Change-Management und Patch-Management, die eine gute
Einbindung der Fragen zur Sicherheit mit sich bringen. Auf diesen Aspekt werden
wir im weiteren Verlauf dieses Studienbriefs noch genauer eingehen.
Einbindung in andere
Prozesse
Neben diesem zweistufigen Ansatz sind natürlich auch Alternativen denkbar.
Da unterschiedliche Organisationen (Banken vs. Industrieunternehmen) unterschiedliche Sicherheitsanforderungen haben, stellen diese neben dem Aspekt der
Unterstützung und Akzeptanz durch das Management das wesentliche Entscheidungskriterium dar, welcher Ansatz der richtige ist.
Weitere Ansätze
Damit Arbeitsanweisungen möglichst gut angenommen werden und damit effektiv und effizient sind, ist es erforderlich bereichsabhängig spezifische Inhalte zu
generieren. Im folgenden betrachten wir drei unterschiedliche Bereiche einer Organisation, die durch entsprechenden Arbeitsanweisungen abgedeckt sein sollten.
Arbeitsanweisungen
in unterschiedlichen
Bereichen
• Arbeitsanweisungen für Geschäftsanwendungen
Sie beinhalten unter anderem das Erzeugen und Löschen von Nutzerkonten,
die Administration von Passworten, ein regelmäßiges Monitoring, insbesondere der Zugriffe.
• Arbeitsanweisungen für Webservices
Sie regeln, wie Mitarbeitern und Kunden die Daten zur Verfügung gestellt
werden (Stichwort: Kiosk-Mode), durch wen und wie inhaltliche Änderungen vorgenommen werden dürfen und stellen zudem sicher, dass die Dienste
regelmäßig gemonitort werden.
• Arbeitsanweisungen - weitere Einsatzbereiche
Neben den beiden Beispielen sind auch Arbeitsanweisungen für weitere Bereiche einer Organisation notwendig. Dazu zählen etwa das Help Desk bzw.
die Mitarbeiter im IT-Support, die Mitarbeiter im Bereich der Installation
und Administration, der Bereich Incident Response und vor allem auch der
“einfache” IT-Anwender.
Dazu gehören etwa Anweisungen für den Umgang mit E-Mail (“Welche Inhalte
dürfen verschickt werden?”, “Ist eine private Nutzung erlaubt?”), mit Passwörtern
(“Dürfen Passwörter weiter gegeben werden?”, “Welche Anforderungen gelten
für Passwörter?”), mit dem Netzwerk (“Wann und wie darf der Internetzugang zu
welchen Zwecken genutzt werden?”), mit mobilen Geräten (“Wie müssen mobile
Geräte konfiguriert sein?”, “Ist eine private Nutzung der mobilen Geräte erlaubt?”)
oder auch bzgl. der Nutzung von Software (“Dürfen Softwarekomponenten auch
zu privaten Zwecken eingesetzt werden?”, “Ist die Nutzung von Dritt-AnbieterSoftware erlaubt?”).
Beispielhafte Regeln für
den Anwender
Probleme, die sich im Rahmen der Erstellung, Kommunikation und Nutzung der
Arbeitsanweisungen und etwaiger Orientierungshilfen ergeben, haben zum Teil
weitreichende Auswirkungen, was sich vor allem daraus ergibt, dass sie beim
täglichen Einsatz in der Fläche Anwendung finden. Daher ist es wichtig, sich
von vorneherein mit möglichen Problemen auseinander zu setzen, damit diese
frühzeitig erkannt und bestenfalls vollständig vermieden werden können.
Mögliche Probleme
Insbesondere bei der Durchsetzung der Vorgaben kommt es immer wieder zu
Problemen. Zum einen entstehen durch die Umsetzung Kosten, die irgendjemand
tragen muss, zum anderen gibt es häufig (Datenschutz-)rechtliche Probleme. Ein
weiteres Hindernis in diesem Kontext stellen fehlende Kapazitäten für die Bearbeitung von Ausnahmeregelungen und Eskalationen und die Fortschreibung der
Probleme
bei der Umsetzung
Seite 62
Studienbrief 4 Umsetzung im IS-Programm
Dynamische
Techniklandschaft
Arbeitsanweisungen
bleiben wirkungslos
Arbeitsanweisungen, sowie ein fehlendes Problemverständnis des Managements
für Compliance-Verletzungen dar, insbesondere, wenn das Management die Regeln
selbst nicht einhält bzw. Sonderregeln für sich selbst einfordert. Insbesondere eine
sich rasch ändernde technische Landschaft vergrößert die genannten Schwierigkeiten noch, da es dann immer schwieriger wird, die Arbeitsanweisungen zeitnah an
die geänderten technischen Vorgaben anzupassen. Hier kann der weiter oben beschriebene Einsatz einer Baseline Security helfen, etwas mehr zeitlichen Spielraum
zu schaffen und die Probleme damit abzumildern.
Ein weiteres Problemfeld stellen eine fehlerhafte Kommunikation und Aufbereitung der Arbeitsanweisungen dar, etwa weil Papier-basierte Dokumente zu schnell
veralten oder die Mitarbeiter, vor allem die Nicht-IT-Mitarbeiter, die Dokumente im Intranet nicht finden. Weitere Probleme sind eher inhaltlicher Natur, weil
die Geschäftsprozess nur unzureichend berücksichtigt wurden - was im Extremfall in einer völligen Ignoranz seitens der Geschäftseinheiten resultieren kann.
Hinzu kommen falsche Formulierungen, die zu viel Interpretationsspielraum
ermöglichen und/oder den Eindruck erwecken, die Anweisungen seien nicht
verbindlich.
4.5 Security Awareness und Security Training
Awareness und Traning
als wichtig(st)e Säule
Um eine sichere Arbeitsumgebung und eine effektive Sicherheitskultur zu fördern,
ist der Aufbau und die Weiterentwicklung eines Programms für IS-Awareness
und -Training unerlässlich und stellt daher auch eine Bestandteil im Rahmen
des Security-Programms dar. Das Security Awareness-Programm stellt dabei die
Aspekte zum Schutz von Informationsressourcen der Organisation in den Vordergrund und muss in Übereinstimmung mit der Leitlinie entwickelt werden.
Damit die Awareness-Aktivitäten zielführend sind, muss bei der Entwicklung
der Inhalte besonderer Wert auf die “zweideutigen” Bereiche der Standards und
Arbeitsanweisungen gelegt werden, da diese die größten Probleme verursachen.
Es wendet sich an alle Mitarbeiter der Organisation und Dritte, die Zugang zu
Informationsressourcen der Organisation haben und daher auch ein angemessenes
Sicherheitstraining erhalten sollten.
Kontinuierliches
Vorgehen
Punktuelle Einzelaktionen sind aufgrund der fehlenden Nachhaltigkeit nicht zielführend. Vielmehr müssen die Awareness-Aktivitäten im Rahmen eines kontinuierlichen Programms umgesetzt werden. Dies gilt auch deshalb, weil gerade neue
Mitarbeiter eine der wesentlichen Zielgruppen darstellen. Hinzu kommen Mitarbeiter, die gerade ihre Funktion in der Organisation gewechselt haben und daher
ein spezifisches, auf die neue Funktion zugeschnittenes Awareness-Training benötigen. Darüber hinaus sind auch die in der IT häufig wechselnden Prozesse und
sich daraus ergebenden neuen Gefährdungen ein Grund, warum ein AwarenessProgramm als kontinuierliche Maßnahme implementiert werden muss.
Inhaltliche Aspekte
Bei der inhaltlichen Ausgestaltung muss zwischen Awareness für die ITSpezialisten der Organisation und Awareness als grundlegende Ausbildung
für alle Mitarbeiter (einschließlich Vorgesetzte und Management) unterschieden
werden. Wichtig ist in jedem Fall eine Zielgruppen-gerechte Ansprache und
Aufbereitung der Inhalte. Nach der formellen Präsentation - bspw. in einem
Kick-off Meeting oder in Form einer formellen Schulung - ist es ein wesentliches
Ziel des Awareness-Programms, die fortlaufende, regelmäßige Aufmerksamkeit
aller Beteiligten zu erzielen.
Umfassende Inhalte
Als Inhalte kommen prinzipiell alle Bereiche der Organisation in Frage, die durch
Arbeitsanweisungen abgedeckt sind und Bezug zum Themengebiet IS aufweisen.
4.6 Integration in die Geschäftsprozesse
Seite 63
Insbesondere sollten Themenbereiche wie die Anforderungen im Bereich der IS
(Anti-Malware, Firewalls, Intrusion Detection, ...), rechtliche Fragestellungen (Datenschutz, Urheberrecht, ...) und die Aspekte der angemessenen Verwendung der
Informationsressourcen (E-Mail- und Internetanbindung, kritische Geschäftsressourcen, ...) im Programm berücksichtigt werden.
Bei der Umsetzung des Awareness- und Training-Programms stehen prinzipiell unterschiedliche Ansätze zur Verfügung. Welcher davon geeignet ist, hängt
maßgeblich von der konkreten Situation ab und kann nicht pauschal beantwortet
werden. Wichtig ist aber in jedem Fall, dass ein methodischer Ansatz gewählt wird,
der die folgenden Aspekte berücksichtigt:
Methodische Ansätze
• Wer ist das Zielpublikum (Management, Mitarbeiter, IT-Mitarbeiter, ...)?
Zielpublikum
• Was ist die beabsichtigte Botschaft (Kenntnis über aktuelle Vorfälle, Arbeitsanweisungen, ...)?
Botschaft
• Was ist die beabsichtigte Wirkung (Verbesserung der Compliance, Verhaltensänderung, ...)?
Wirkung
• Welche Kommunikationsform wird genutzt (Intranet, Newsletter, ...)?
Kommunikationsform
Als Mechanismen kommen IS-bezogene, schriftlich fixierte Leitlinien und Arbeitsanweisungen in Frage, die gleichzeitig aber auch Grundlage für weitere AwarenessMaßnahmen sind. Zu den “schriftlichen” Awareness-Maßnahmen zählen dabei
auch die von allen Mitarbeitern unterschriebenen Vertraulichkeitsvereinbarungen,
die unter Umständen auch aus Datenschutz-rechtlichen Erwägungen geboten sein
können. Daneben ist auch der Einsatz moderner Medien denkbar, bspw. mittels
(E-Mail-)Newsletter, spezieller Webseiten und/oder Web-based Trainings. Aber
auch die sichtbare (=für die Mitarbeiter realisierbare!) Durchsetzung von Sicherheitsregeln kann als Mechanismus im Bereich der Security Awareness eingesetzt
werden. Periodische Audits ergänzen diese ggf. gegenüber einzelnen Mitarbeitern
ausgeübte Durchsetzung von Sicherheitsregeln und erzeugen bei den Mitarbeitern
ein Gefühl, dass Sicherheit ernst genommen wird.
Unterschiedliche Mechanismen
Die wesentlichen Probleme im Bereich der Awareness bestehen darin, dass das Programm nicht die erforderliche Kontinuität aufweist und/oder nicht Zielgruppenorientiert umgesetzt wird. Bei letzerem liegt das Problem häufig auch am Trainer
selbst, daher ist frühzeitig nach Beginn einer Maßnahmen und sodann regelmäßig
durch geeignete Maßnahmen zu überprüfen, ob und ggf. wie die Nachricht bei
der Zielgruppe ankommt. Nur so können Fehlinvestitionen - vor allem im Rahmen
der Zeitaufwendungen durch die eigenen Mitarbeiter - vermieden werden. Die
fehlende Kontinuität wirkt sich insbesondere in einer schlechten Umsetzung der
Sicherheitsanforderungen bei den Mitarbeitern aus, die neu in die Organisation
gekommen sind, oder die Abteilung gewechselt haben. Zu strenge Kontrollen
können allerdings auch gegenteilig wirken und dafür sorgen, dass die Mitarbeiter
das Thema Sicherheit nur als Hindernis wahrnehmen.
Mögliche Probleme
Einsatz moderner Medien
4.6 Integration in die Geschäftsprozesse
Um die Security Baseline durchsetzen zu können, ist es notwendig, die Anforderungen aus dem Bereich IS in die organisatorischen Prozesse einzubinden.
Insbesondere ist dabei zu beachten, dass IS während aller Phasen des Lebenszyklus der Geschäftsprozesse berücksichtigt werden. Hier können Techniken
des Projektmanagements wichtige Hilfestellung bieten und dafür Sorge tragen, die Anforderungen umzusetzen. Berücksichtigt werden sollte dabei, dass
IS in allen Phasen
berücksichtigen
Seite 64
Studienbrief 4 Umsetzung im IS-Programm
unterschiedliche Organisationen bzw. Bereiche innerhalb einer Organisation
unterschiedliche Entwicklungsmethoden (bspw. agile Softwareentwicklung vs.
traditionellen SDLC-Ansätze) nutzen und die Möglichkeiten, wann und wie
Sicherheit im Rahmen dieses Prozesses integriert werden kann, stark von der
gewählten Methodik abhängen.
Abb. 4.2: Illustration des SDLC als
Wasserfall-Diagramm
(engl.: waterfall chart).
Feasibility
Requirements
Design
Development
Testing
Implementation
Phasen des Lebenszyklus
Um ein besseres Verständnis für die Integration in den Lebenszyklus eines Geschäftsprozesses geben zu können, sollen nun kurz die verschiedenen Phasen
eines System/Software Development Life Cycle (SDLC) betrachtet werden.
Machbarkeit
1. Machbarkeit (engl.: feasibility): In dieser ersten Phase werden die Vorteile,
die sich aus dem geplanten Projekt ergeben können, ermittelt. Zu nennen
sind hier bspw. mögliche Produktivitätssteigerungen oder Möglichkeiten
zur Kostenreduktion.
Anforderung
2. Anforderungen (engl.: requirements): In dieser Phase werden die funktionalen
Anforderungen des Systems festgelegt.
Design
3. Design (engl.: design): Nachdem die funktionalen Anforderungen ermittelt
wurden, erfolgt nun die Festlegung des technischen und funktionalen Designs. Dazu gehört auch eine Beschreibung der einzelnen Systemkomponenten,
deren Zusammenspiel und der möglichen Umsetzung des Gesamtsystems.
Entwicklung
4. Entwicklung (engl.: development): In diesem Schritt wird nun auf Basis der
Vorgaben der Programmcode entwickelt und durch entsprechende Tests
nachgewiesen, dass dieser den Anforderungen genügt.
Test
5. Test (engl.: testing): Im Gegensatz zu Phase 4 geht es in diesem Teilschritt
nicht um die funktionale Korrektheit des Programmcodes, sondern vielmehr
um die Akzeptanz durch die Anwender. Daher wird diese Phase manchmal
auch als Akzeptanztest (engl.: user acceptance testing) bezeichnet.
Implementierung
6. Implementierung (engl.: implementation): Final erfolgt dann nach erfolgreichem Test in Phase 5 die eigentliche Implementierung des Systems, also
der Übergang vom Testsystem zum Produktivsystem, also dem eigentlichen
Betrieb. Dieser Übergang erfolgt vorzugsweise nach einem abschließenden
Akzeptanztest durch die Anwender (ggf. mit formaler Abnahme). Diese abschließende Phase beinhaltet auch die Akkreditierung, also die Abnahme
4.6 Integration in die Geschäftsprozesse
Seite 65
durch das Management der Organisation, und ggf. auch eine Zertifizierung
nach anerkannten Standards durch eine externe Organisation.
Die IS kann nun in unterschiedlichen Phasen des oben beschriebenen Prozesses
eingebunden werden. Dabei gilt grundsätzlich, dass die Einbindung möglichst
frühzeitig erfolgen sollte, da dadurch Fehlentwicklungen vermieden und so letztendlich Ressourcen eingespart werden können. So sollte das Thema IS bereits bei
der Initiierung des Projekts mit berücksichtigt werden, mögliche Anforderungen
bzgl. IS sollten frühzeitig formuliert werden. Im Rahmen der Design-Phase (vgl.
Phase 3 des SDLC) ist sicher zu stellen, dass das System-Design auch die Vorgaben
der IS erfüllt. Eine weitere Einbindung der IS findet bspw. als Review-Prozess vor
und nach der Implementierung, bzw. als regelmäßiges Follow-up-Review statt.
Auch in die Entscheidung zum “Go-live” ist der Bereich IS mit einzubinden.
Frühzeitige
Einbindung der IS
Für die Erstellung des Security Designs ist in der Regel die entsprechende Entwicklungsabteilung zuständig. Auch wenn diese häufig davon ausgeht, dass das
Security Design von der IS übernommen wird, steht die IS vorrangig nur beratend
zur Seite. Dabei unterstützt sie das Entwicklungsteam bei der Umsetzung der Vorgaben durch die IS Governance. Die notwendigen Rollen und Verantwortlichkeiten
sollten dabei definiert und im Projektplan fixiert sein, damit Missverständnisse,
wer welche Aufgabe zu übernehmen hat, von vorneherein vermieden werden.
Security Design
Beim Review des von der Entwicklungsabteilung vorgeschlagenen Security Designs spielen insbesondere die Maßnahmen zur Identifizierung und Authentifizierung im Fokus. Darüber hinaus spielen Sicherheitsmaßnahmen auf Netzwerkebene
(bspw. Firewall-Regeln, VPN-Nutzung) und die Anwendung von kryptographischen Mechanismen eine Rolle.
Review des Designs
Die Einbindung der IS in die Entwicklungsprozesse bietet sich vor allem im Bereich
des Projektmanagements und des Change-Managements an. Bereits im Rahmen
des klassischen Projektmanagements können definierte Maßnahmen für den Bereich IS sehr hilfreich dabei sein, dass das Thema IS rechtzeitig bedacht wird.
Beispiele sind etwa ein entsprechendes Risikomanagement bei der Initiierung
eines Projekts, die Anforderung, ein Security Design zu erstellen und dies von der
IS abnehmen zu lassen, ein explizites Testen der geplanten und ggf. implementierten Sicherheitsmaßnahme sowie die sichere Implementierung in der Produktion
und die Vorgabe, dass nur System, die den Sicherheitsvorgaben genügen, in die
Produktion überführt werden dürfen.
Einbindung in spezielle
Prozesse
Dabei ist die IS in den einzelnen Projektphasen zu integrieren, darüber hinaus
ist sicher zu stellen, dass die Sicherheitsanforderungen in allen Phasen des Life
Cycle berücksichtigt und entsprechend dokumentiert werden. Zusätzlich zu den
“normalen” Freigaben (bspw. durch den Business Owner und/oder die Anwender)
sollte auch eine explizite Freigabe durch die IS vorgesehen werden.
Explizite Freigabe
durch IS
Wird das Thema Sicherheit nicht angemessen in die Prozesse der System/Software-Entwicklung bzw. des Change-Managements eingebunden, führt dies
im Laufe der Zeit zu immer schwächer werdenden Kontrollen. Diese äußern sich
in
Fehlende Einbindung
verursacht Probleme
• Nichteinhaltung von Standards und Arbeitsanweisungen,
• (unkontrollierten) Änderungen in der Organisation, bspw. der unkontrollierten Einführung neuer Technologien und/oder neuer Firewallregeln, die
den Zugang zu internen Ressourcen aus dem Internet eröffnen, sowie
• möglichen Schwachstellen, die ggf. ausgenutzt werden können.
Seite 66
Studienbrief 4 Umsetzung im IS-Programm
Die Aufgabe des IS-Manager besteht hier vorrangig darin, sich einen Überblick
über die Prozesse des Change-Managements und des Konfigurationsmanagements
zu verschaffen, die Prozesse zu verstehen und dann dafür Sorge zu tragen, dass
der Einfluss von Änderungen auf die Sicherheit angemessen gereviewt werden
kann, bevor die Änderungen an sich durchgeführt werden.
Notfalländerungen
Um sicher zu stellen, dass die Verfügbarkeit des Geschäftsbetriebes auch in Notfällen nicht durch für diese Situation zu langwierige Änderungsprozesse beeinträchtigt wird, ist ein spezieller Änderungsprozess für den Notfall (engl.: emergency
change process) notwendig. Dabei muss aber gewährleistet werden, dass dieser
Änderungsprozess nur nach erfolgreicher Authentisierung für authorisierte Mitarbeiter zu Verfügung steht.
Firecall Acoounts
Dies kann bspw. durch Nutzung eines so genannten Notfall-Acoounts (engl.: firecall
account) realisiert werden, das die Nutzung eines speziellen Passwortes erfordert
und sich nach einmaliger Nutzung von selbst resettet und damit sperrt, bis ein
manueller Eingriff das Account wieder reaktiviert. Dabei sind allerdings mögliche
Denial-of-Service-Szenarien im Vorfeld zu bedenken.
Notfalländerungsprozess
In jedem Fall sollten alle Aktivitäten, die im Rahmen des Notfalländerungsprozesses vorgenommen werden, protokolliert und entsprechend gereviewt werden.
Empfehlenswert ist zudem, die Anforderungen und Maßnahmen im standardmäßigen Änderungsprozess nachzuholen, sobald der Notfall beendet ist.
Mögliche Probleme
Das wesentliche Problem bei der Einbindung der IS in die Entwicklungs- und
Änderungsprozesse in der Organisation besteht darin, dass die IS bei wesentlichen
Entwicklungen und/oder Änderungen in der Organisation nicht berücksichtigt
wird oder -insbesondere bei einer verteilten Organisation- nicht alle Teilbereiche
die notwendigen Prozesse implementiert haben.
Fehlender Änderungsprozess
Ein ähnliches Problem besteht darin, dass häufig überhaupt kein bzw. kein angemessener Änderungsprozess oder Life Cycle-Prozess in der Organisation besteht,
Änderungen dann auf “ad hoc”-Basis und damit völlig unkontrolliert und ungeregelt stattfinden. Alternativ besteht die Gefahr, dass die Notfalländerungsprozesse
missbraucht werden und so der Notfallprozess zum Standardprozess verkommt.
Mangelnde Akzeptanz
Darüber hinaus besteht die Gefahr, dass -insbesondere bei der Einführung neuer
Technologien- relevante Sicherheitsstandards nicht oder nur unzureichend Berücksichtigung finden. Die Akzeptanz leidet zudem darunter, dass nicht akzeptable
Sicherheitslösungen designt, angeschafft oder implementiert werden - häufig, weil
den Akzeptanztests durch die Anwender zu wenig Aufmerksamkeit geschenkt werden. Der Gesamtprozess der Einbindung der IS in die Geschäftsprozesse ist ohne
entsprechende Unterstützung durch das Management zum Scheitern verurteilt.
4.7 Berücksichtigung von Verträgen
Aktivitäten Dritter
berücksichtigen
Die Anforderungen der IS müssen auch in Verträgen und sonstigen Aktivitäten
mit Dritten angemessen eingebunden werden, damit die Security Baseline der Organisation auch in diesem Bereich umgesetzt wird. Die gilt etwa beim Einsatz von
externen Beratern, beim Outsourcing der bzw. von Teilen der IT der Organisation
(insbesondere im Falle des Cloud-basierten Outsourcings), bei der Bildung eines
Gemeinschaftsunternehmens sowie gegenüber weiteren Geschäftspartnern und
Kunden.
4.7 Berücksichtigung von Verträgen
Seite 67
Dabei bietet es sich an, dass bereits bei der Vertragsverhandlung bzw. bei der
Erstellung des ersten Vertragsentwurfs die Service Level der Dienstleister mit den
Anforderungen der Organisation in Übereinstimmung gebracht werden. Dies ist
insbesondere deswegen relevant, damit nicht erst nach Vertragsabschluss oder
zu einem sehr späten Zeitpunkt im Prozess der Vertragsgestaltung wesentliche
Missstände aufgedeckt werden, die dann nur noch schwer (d.h. mit einem hohen
zeitlichen und ggf. auch finanziellen Aufwand) zu beheben sind. Dazu benötigt
der IS-Manager Kenntnisse in der Bewertung der Dienstleister und der eingesetzten bzw. geplanten Sicherheitstechnologien. Der dazu notwendige Prozess kann
bspw. durch Erstellen einer Bewertungsmatrix, in der die Anforderungen mit
den konkreten Leistungen des Anbieters gegenüber gestellt werden, unterstützt
werden.
Vertragsverwaltung
Im Rahmen “moderner” Geschäftsprozesse besteht eine wachsende Notwendigkeit,
auch Externen immer mehr Zugriff auf (einen Teil der) Informationsressourcen der
Organisation zu geben. Zu diesen “externen” Stellen gehören neben Geschäftspartnern, Lieferanten und Kunden ggf. auch öffentliche bzw. regulatorische Stellen. Im
jeweiligen Vertrag mit dem/den Dienstleister/n bzw. in den zugehörigen Service
Level Agreements (kurz: SLA) müssen auch spezifische Aspekte dieses Zugriffs
geregelt werden. Zielsetzung ist dabei, dass die Compliance (beim Dienstleister)
mit den Regularien der (beauftragenden) Organisation sicher gestellt wird.
Einbindung Externer
• Geschäftspartner und Lieferanten
Gegenüber den “klassischen” Geschäftspartner sollte vertraglich vereinbart werden, auf welche Daten der jeweilige Geschäftspartner zugreifen
muss bzw. darf. In der Regel ist ein eingeschränkter, auf den jeweiligen
Geschäftsprozess zugeschnittener Zugriff völlig ausreichend. Die Einschränkung sollte dabei aber nicht nur schriftlich fixiert, sondern auch technisch
durchgesetzt und auf die Berechtigten eingeschränkt werden. Dazu kommen
Technologien wie Firewalls und VPN-Lösungen, aber auch Mechanismen
zur starken Authentifizierung in Frage. Der Zugriff auf die im Geschäftsprozess notwendigen Systeme und Daten sollte zudem durch Regeln zur akzeptablen Nutzung (engl.: acceptable use policy) reglementiert werden.
Geschäftspartner und
Lieferanten
• Regulatorische Stellen
Regulatorische Stellen haben typischerweise umfangreiche Rechte, auf Systeme und/oder Daten der Organisation zuzugreifen - die allerdings von
Land zu Land durchaus sehr unterschiedlich sein können. Gerade bei internationalen Verträgen sind dabei auch die möglichen Zugriffsmöglichkeiten
der regulatorischen Stellen des Vertragspartners im Vorfeld des Vertragsschlusses genau zu prüfen. In keinem Fall sollte einer regulatorischen Stelle
aber uneingeschränkter Zugriff gewährt werden. Vielmehr ist es ratsam,
sich im Vorfeld über die genauen Zugriffsanforderungen zu informieren
und dies technisch durchzusetzen, das heißt, alle weiteren potentiellen Zugriffe möglichst technisch zu unterbinden. Problematisch ist in der Regel
aber, dass regulatorische Stellen keine Vereinbarungen zu “akzeptablen”
Nutzung unterzeichnen werden.
Regulatorische Stellen
• Kunden
Beim Umgang mit Kunden besteht die Herausforderung darin, dass man sie
zum einen mit der Organisation interagieren lassen möchte (um Geschäft zu
generieren), der Kunde sich also “willkommen” fühlen soll, auf der anderen
Seite der Zugriff auf die Informationsressourcen der Organisation so weit
wie möglich eingeschränkt werden muss, damit die Anforderungen seitens
der IS eingehalten werden können. Da man in der Regel dem Kunden aus besagtem Grunde keine strikten Regeln zur aktzeptablen Nutzung auferlegen
wird, besteht ein häufiges Vorgehen darin, dass man den Zugang bzw. Zugriff des Kunden durch technische Maßnahmen entsprechend eingeschränkt.
Kunden
Seite 68
Studienbrief 4 Umsetzung im IS-Programm
Dazu kommen vielfach isolierte Systeme, bspw. durch Firewalls, Härtung
von Servern und/oder Nutzung von DMZ-Strukturen, starke Authentifizierungsmechanismen und ein detailliertes Monitoring zur frühzeitigen
Erkennung von missbräuchlicher Nutzung zum Einsatz. Dabei bietet ein
detailliertes Risikoassessment eine gute Hilfestellung, das “Wohlbefinden”
des Kunden auf der einen Seite und die Sicherheit der System und Daten
der Organisation auf der anderen Seite durch angemessene, ausgewogene
Sicherheitsmaßnahmen sicher zu stellen.
Outsourcing-Partner
• Outsourcing-Partner
Auch Outsourcing-Partner sind entsprechend zu berücksichtigen und spielen in den meisten Fällen sogar die wichtigste Rolle. Berücksichtigt werden
müssen dabei sowohl Dienstleister, die dem Auftraggeber Hard-/Software
zur Verfügung stellen, die spezielle Dienste und/oder Anwendungen für
den Auftraggeber hosten oder ihm Zugriff auf spezielle Applikationen bieten (die allerdings dann nach wie vor dem Auftragnehmer gehören). In allen
Fällen ist die Organisation durch Mängel in der Sicherheit beim OutsourcingDienstleister angreifbar; insbesondere bei Cloud-artigen Diensten ist ein
Verständnis für die spezifischen Risiken notwendig, um die sich ggf. aus
dem Outsourcing ergebenden Risiken richtig abschätzen und damit die
Sicherheit für die Organisation sicher stellen zu können.
Outsourcer sind
besonders kritisch
Der Sicherheit beim Outsourcer kommt also eine besondere Bedeutung zu - gleichzeitig wirft sie aber auch die meisten Probleme auf. Wird der Aspekt der Sicherheit
nicht frühzeitig mit in die Anforderungsliste aufgenommen, so ergeben sich hinterher Mehrkosten, die den Erfolg eines Outsourcing-Projekts erheblich beeinträchtigen können. Dies betrifft vor allem in Verstößen gegen die internen Vorgaben
(Leitlinie, Standards, Arbeitsanweisungen) der (beauftragenden) Organisation. Die
Möglichkeit, dass der Dienstleister weitere Kunden ggf. sogar aus dem Kreise der
Konkurrenten der Organisation hat, muss gesondert berücksichtigt werden. Darüber hinaus besteht die Gefahr, dass die Mitarbeiter der Organisation sich selbst
nicht mehr um das Thema Sicherheit kümmern (weil dafür ja nun der Dienstleister
zuständig ist).
SLA und SSLA
Um die Sicherheit beim Outsourcer in angemessener Art und Weise sicher zu
stellen, sind daher SLA notwendig, die die spezifischen Anforderungen auch im
Bereich Sicherheit beschreiben. Bei umfangreichen Anforderungen kann es ratsam
sein, diese in ein spezielles Security Service Level Agreement (SSLA) auszugliedern;
dadurch ist eine schnellere Reaktion auf sich ändernde Anforderungen möglich, da
nicht jedes Mal das SLA neu verhandelt werden muss. Nur durch solche Regelungen kann klar gestellt werden, wer im Verhältnis Auftraggeber-Auftragnehmer für
welche Aspekte der Sicherheit zuständig ist und welche Voraussetzungen dazu bei
der jeweils anderen Partei geschaffen werden müssen. Fehlen solche Regelungen,
verlässt sich jeder auf den anderen - und die Sicherheit bleibt außen vor.
Verhältnis Auftraggeber
zu Auftragnehmer
Aspekte des SSLA
Wichtige zu regelnde Aspekte umfassen detaillierte Arbeitsanweisungen und Metriken für den Betrieb, Regelungen und Anweisungen für das Krisenmanagement
und Eskalationsszenarien und Vorgaben für Audits.
Überprüfung
der Vorgaben
Um die Einhaltung der Vorgaben überprüfen zu können, muss die beauftragende
Organisation allerdings selbst entsprechendes Know-how vorhalten, um regelmäßige und auch auf ad-hoc-Basis stattfindende Überprüfungen sinnvoll durchführen
zu können. Ggf. kann dies auch von einem externen Auditor vorgenommen werden,
der allerdings ebenfalls “kontrolliert” werden muss.
Mögliche Probleme
Wird Sicherheit nicht als Bestandteil des Vertragsprozesse verstanden bzw. gelebt,
so führt dies ggf. dazu, dass sich außer der Organisation selbst niemand um die
4.8 Aufbau eines Monitoring- und Reportingsystems unter Nutzung von Metriken
Seite 69
Themen der IS kümmert. Fehlen aber die entsprechenden Security-Vereinbarungen
mit Dritten, so kann dies auch die Sicherheit der eigenen Systeme bzw. der dort
verarbeiteten Daten erheblich beeinträchtigen.
Weitere Probleme sind eine unzureichende Zusammenarbeit mit der Rechtsabteilung bzw. unzureichende Kenntnisse des Prozesses der Vertragsgestaltung und
damit verbundene langwierige Abstimmungsprozesse und/oder Fehlentscheidungen. Im Rahmen der Abstimmung wird dabei auch oft nicht ausreichend berücksichtigt, wer für den Service bezahlt und wer diesen zu erbringen hat - sprich, das
Verhältnis von Auftraggeber und -nehmer ist nicht ausreichend geklärt.
Fehlende interne
Zusammenarbeit
4.8 Aufbau eines Monitoring- und Reportingsystems unter
Nutzung von Metriken
Um die Effektivität und Effizienz des IS-Programms bewerten zu können, ist
der Aufbau und die Weiterentwicklung eines Monitoring- und Reportingsystems
und passender Metriken erforderlich. Nur dadurch kann der Fortschritt in der
Entwicklung des IS-Programms ermittelt, können Missstände rechtzeitig erkannt
und frühzeitig Gegenmaßnahmen ergriffen werden. Ein Monitoring und Reporting
kann zudem dazu dienen, die besondere Beachtung des Themas Sicherheit aufrecht
zu erhalten. Verbesserungen sollten zudem durch das Management honoriert
werden, damit die Mitarbeiter entsprechend motiviert sind, sich einzubringen.
Monitoring als
Kontrollinstrument
Die aus den Ergebnissen des Monitorings erstellten Berichte müssen dabei auf
den jeweiligen Empfänger zugeschnitten sein. Während das Management in der
Regel eher an einem Bewertungsschema in Form eines Ampelsystems (grün gelb - rot) interessiert sein dürfte und die technischen Details nicht im Fokus
stehen, sind diese für die Mitarbeiter im Bereich der IS der wesentliche Aspekt.
Für entsprechende Metriken gibt es eine Reihe von Hilfestellungen, so bspw. das
Systems Security Engineering CMM der Carnegie Mellon University (kurz: SSECMM). Auch das NIST hat einen entsprechenden Leitfaden zur Entwicklung von
Security-Metriken.
Berichte für das
Management
Etwaige Metriken sollten grundsätzlich die SMART-Kriterien erfüllen: Sie sollten
spezifisch (also aussagekräftig, engl.: specific), messbar (sonst bringt der beste
Messwert nichts, engl.: measurable), erreichbar (damit die Ziele auch durchsetzbar
sind, engl.: achievable), wiederholbar (um eine kontinuierliche Anwendung und
Vergleichbarkeit zu ermöglichen, engl.: repeatable) und zeitabhängig (damit die
vorgegebenen Ziele klare Ziel-Zeitpunkte haben können, engl.: time-bound) sein.
SMART-Kriterien
Je nach Einsatzgebiet sind unterschiedliche Metriken sinnvoll. Die folgenden Beispiele geben eine erste Auswahl möglicher Metriken an:
Beispielhafte Vorgehensweisen
• Zeitraum, der benötigt wird, um Sicherheitsprobleme zu beheben
• Anzahl der Passwortänderungen pro Zeiteinheit
• Anzahl der Accountänderungen pro Zeiteinheit
• Anzahl der erkannten Sicherheitsverstöße pro Zeitraum
Insbesondere beim letzten Beispiel in der obigen Liste ist Vorsicht geboten, da hier
natürlich nur die erkannten Verstöße berücksichtigt werden - die Dunkelziffer aber
der eigentlich interessante Parameter ist. Eine hohe Zahl ist hier ggf. ein Merkmal
für funktionierende Erkennungsprozesse, eine niedrige Zahl sagt aber auf der
Aussagekraft von
Metriken
Seite 70
Studienbrief 4 Umsetzung im IS-Programm
anderen Seite nur wenig über das akute Sicherheitsniveau in der Organisation
aus.
Self Assessments
Neben spezifischen Metriken können auch allgemeine Aussagen, bspw. durch
(regelmäßige) Self Assesments wichtige Aussagen über den Fortschritt im Rahmen des IS Programms liefern. Grundlage dafür bieten Checklisten, die von den
Anwendern abgearbeitet werden - und so die notwendigen Kriterien liefern. Die
Ergebnisse sollten übergreifend aufgezeichnet werden und können so dabei unterstützen, Probleme aufzudecken und Lösungen herbeiführen, bevor “echte” Audits
die Probleme aufdecken und daraus ggf. größere Probleme resultieren, bspw. weil
Kunden dies als Negativ-Merkmal werten.
Kontinuität, Konsolidierung und Korrelation
Da in der Regel von modernen IT-Systemen eine 24/7-Verfügbarkeit erwartet
wird, müssen auch die Monitoring- und Reporting-Systeme kontinuierlich zur
Verfügung stehen. Während die Aufzeichnung von Ereignisdaten im Normalfall
tatsächlich 24/7 durchgeführt werden wird, kann die Alarmbereitschaft bzw. der
Auswertungszeitraum der Logdaten an die Kritikalität des Systems angepasst werden. So wird man an ein Geschäfts-kritisches Server-System, das weltweit Daten
zur Verfügung stellen muss, sicherlich höhere Anforderungen stellen, als an den
PC eines einzelnen Mitarbeiters. Darüber hinaus ist es natürlich möglich, auch außerhalb der Standard-Arbeitszeit die Mitarbeiter mittels spezieller Alarmkriterien
über ungewöhnliche Zustände zu informieren, die eine sofortige Reaktion erfordern. Gerade beim 24/7-Monitoring und -Reporting wird man um den Einsatz
automatisierter Werkzeuge nicht herum kommen.
Korrelation von
Ereignisdaten
Diese Werkzeuge können dann auch zur Konsolidierung und Korrelation von
Ereignismeldungen aus unterschiedlichen Bereichen eingesetzt werden. Ereignisdaten plattform- und netzwerkübergreifend an zentraler Stelle zu verarbeiten,
bietet die Möglichkeit, Probleme und ggf. Angriffe möglichst schnell erkennen zu
können, während diese bei Nutzung einer einzigen Quelle vielleicht im Verborgenen bleiben würden. Automatisierte Werkzeuge, die dabei unterstützen können,
bieten eine Zeitsynchronisierung der Ereignisdaten, ein zentrales Logging, ggf.
eine offline Datenhaltung, eine (halb)automatisierte Auswertung der Daten und
eine zentrale Schnittstelle für die Alarmierung oder sonstige Benachrichtigung der
Verantwortlichen im Problemfall.
Mögliche Probleme
Insbesondere ein unzureichendes oder vollständig fehlendes Monitoring und
Reporting -oft in unzureichender Zuteilung von Ressourcen begründet- führt
zu nicht entdeckten Misständen. Dies ist zunächst aus Sicht der Compliance ein
Problem, kann aber auch dazu führen, dass diese Mängel schlussendlich für einen
Angriff ausgenutzt werden. Häufig kommen zudem ungeeignete Metriken zum
Einsatz, die letztendlich nicht die notwendigen Aussagen geben. Der umfangreiche
Einsatz (spezieller) Metriken birgt auf der anderen Seite die Gefahr, dass sich das
IS Programm auf Details fokussiert, anstatt das Gesamtsystem im Blick zu halten
und die Umsetzung der Maßnahmen anhand der 80/20-Regel zu steuern.
Zusammenfassung dieses Studienbriefs
Zusammenfassung
Die besten Vorgaben nützen nichts, wenn sie nicht bei der Arbeitsebene ankommen
und von dieser auch gelebt, sprich umgesetzt, werden. In diesem Abschnitt haben
wir uns mit dem Aufbau und der Aufrechterhaltung eines IS-Programms beschäftigt, das dazu dient, die Vorgaben aus der IS-Governance in der Organisation in
der Praxis umzusetzen. Betrachtet wurden dabei die unterschiedlichen Teilaspekte
im Rahmen des IS-Programms, angefangen von der Definition der Ziele, über die
Anwendung von IS-Baselines bis hin zur Definition und Auswertung von Metriken.
4.8 Aufbau eines Monitoring- und Reportingsystems unter Nutzung von Metriken
Im folgenden Studienbrief mit dem Thema Information Security Incident Managament gehen wir nun auf die Aspekte ein, die zum Tragen kommen, wenn es -trotz
aller Vorkehrungen- zu einem Sicherheitsvorfall kommt.
Seite 71
Studienbrief 5 Vorfallsmanagement im Bereich der IS
Seite 73
Studienbrief 5 Vorfallsmanagement im Bereich der IS
Im Rahmen des IS-Managements spielt auch die Frage der Reaktion auf Vorfälle im
Bereich der Informationssicherheit eine wichtige Rolle. Dies ist zum einen damit
begründet, dass eine Organisation im Falle des Falles möglichst gut vorbereitet
sein sollte, um die Auswirkungen begrenzen und den Normalbetrieb möglichst
schnell wieder herstellen zu können. Neben dieser Schadensbegrenzung ist aber
auch der durch Sicherheitsvorfälle erzielbare Lerneffekt relevant. In diesem Kapitel
wird daher im Rahmen des Information Security Incident Response Management (kurz:
ISIRM oder IRM) die Fähigkeit der Organisation, auf unerwartete und störende
Ereignisse zu reagieren, betrachtet.
Ziele dieses Abschnitts
Grundlagen des IRM
Wesentliches Merkmal des IS Incident Response-Managements ist es also, die
Auswirkungen zu minimieren und den normalen Betrieb soweit möglich aufrecht
zu erhalten bzw. innerhalb eines vorgegebenen, von der Organisation tolerierbaren Zeitlimits wiederherzustellen. Dafür sind ebenfalls entsprechende Leitlinien
zu schaffen, die die Reaktionen auf die störenden Ereignisse bereits im Voraus
festlegen und somit eine kontrollierte Reaktion ermöglichen.
Ziele des
IS Incident ResponseManagements
Damit die Organisation in die Lage versetzt werden kann, den Betrieb auch im Falle
einer Störung oder einer versuchten Störung bzw. die IT auch während bzw. nach
einer Unterbrechung fortsetzen zu können, ist sowohl eine gründliche Planung
im Vorfeld und die Zusage von entsprechenden Ressourcen unabdingbar - beides
erfordert die Unterstützung durch das Senior Management. Zudem ist auch ein
Prozess notwendig, der eindeutig feststellt, ob eine Reaktion (im Sinne des IS
Incident Response-Management) überhaupt erforderlich ist.
Gründliche Planung und
Vorbereitung
Bei der Bewältigung von Sicherheitsvorfällen bzw. im gesamten Bereich des IS
Incident Response-Managements sind Kenntnisse einiger wesentlicher Methoden
hilfreich. Dazu zählen Vorgehensweisen eines Computer Emergency Response Teams
(CERT), des (allgemeinen) Incident Management und auch der (Digitalen) Forensik. Zudem ist es - insbesondere bei der Aufarbeitung von Sicherheitsvorfällen
mit Straftatcharakter - wichtig, ein Verständnis der Prozesse im Bereich der Zusammenarbeit mit staatlichen Stellen (bspw. Polizei oder Verfassungsschutz) zu
haben.
Sinnvolle Hilfsmittel
Eindeutige Feststellung eines Incidents
notwendig
Weitere Gliederung dieses Studienbriefs
Im weiteren Verlauf dieses Studienbriefs betrachten wir nun die folgenden wesentlichen Teilschritte (vgl. dazu auch [7]), die im Rahmen des Aufbaus und der
Aufrechterhaltung der Maßnahmen rund um das Thema “IS Incident ResponseManagement” erforderlich sind:
1. Aufbau und Aufrechterhaltung der Definition von Sicherheitsvorfällen (engl.:
security incidents) und Festlegung der Schweregrade (engl.: severity level),
damit eine korrekte Erkennung und angemessene Behandlung von Sicherheitsvorfällen ermöglicht wird.
Wesentliche Teilschritte
Seite 74
Studienbrief 5 Vorfallsmanagement im Bereich der IS
2. Aufbau und Aufrechterhaltung eines Plans zum Incident Response (engl.
incident response plan), um eine rechtzeitige und effektive Reaktion zu ermöglichen.
3. Entwicklung und Umsetzung eines Prozesses, der die zeitnahe Feststellung
eines Sicherheitsvorfalls sicher stellt.
4. Aufbau und Dokumentation eines Prozesses zur Behandlung von Sicherheitsvorfällen, um eine angemessene Reaktion und Ermittlung der Ursachen
sicher zu stellen und dabei die rechtlichen, regulatorischen und organisatorischen Anforderungen einzuhalten.
5. Aufbau und Aufrechterhaltung eines Prozesses zur Meldung und Eskalation
von Sicherheitsvorfällen, damit die zuständigen Interessensgruppen in den
Prozess eingebunden sind.
6. Organisation, Ausrüstung und Training von Incident Response-Teams, um
eine Reaktion auf Sicherheitsvorfälle in angemessener Zeit sicher stellen zu
können.
7. Regelmäßige Tests und Überprüfungen des Incident Response-Plans, damit
die Reaktionsmöglichkeiten kontinuierlich verbessert werden und so eine
effektive Reaktion sicher gestellt werden kann.
8. Aufbau und Aufrechterhaltung von Kommunikationsplänen und -prozessen
mit internen und externen Einheiten bzw. Organisationen.
9. Durchführung von Nachvorfallsbehandlungen, um die Ursache zu ermitteln
und daraus korrigierende Maßnahmen zu entwickeln, die Risiken sowie die
Effektivität der Reaktionen zu bewerten und für Abhilfe zu sorgen.
10. Aufbau und Aufrechterhaltung der inhaltlichen Abstimmung von Incident
Response-Plan, Desaster Recovery-Plan und Business Continuity-Plan, damit
die Reaktion auf Sicherheitsvorfälle organisationsweit abgestimmt ist und
somit effektiv und effizient erfolgen kann.
Die weiteren Abschnitt dieses Studienbriefs gehen nun auf die konkreten Fragen
bei der Umsetzung der einzelnen Teilschritt ein. Dabei werden wir uns zunächst
mit der Frage beschäftigen, warum ein Incident Response-Prozess notwendig ist,
welche Aufgaben der IS-Manager übernehmen muss und welche spezifischen
Aufgaben dabei eine Rolle spielen.
5.1 Festlegung “Was ist ein Sicherheitsvorfall?”
Klare Definition
als Arbeitsgrundlage
Vergleich mit ähnlichen Organisationen
Ein wichtiger Aspekt beim Aufbau eines IS Incident Response-Managements ist
die Erstellung und Weiterentwicklung einer (organisationseigenen) Definition von
einem Sicherheitsvorfall und zugehörigen Schweregraden (engl.: severity hierarchy).
Erst eine klare Festlegung ermöglicht eine klare Entscheidung, ob es sich um einen
Sicherheitsvorfall handelt und somit auch entsprechende Einleitung von Maßnahmen. Dabei sollte aber auch berücksichtigt werden, dass die genaue Definition für
einen Sicherheitsvorfall für jede Organisation unterschiedlich sein kann. Trotzdem
können andere Organisationen aus der gleichen Branche natürlich einen guten
Anhaltspunkt liefern, wie ein Sicherheitsvorfall und welche Schweregrade definiert
werden können.
5.2 Entwicklung und Aufrechterhaltung eines Incident Response-Plans
Diese Festlegung eines Sicherheitsvorfalls ist aber als Definition und auch als
Entscheidung im konkreten Fall alles andere als einfach. Bei der Definition eines
Sicherheitsvorfalls ist zu berücksichtigen, dass es viele Szenarien gibt, die sowohl
gutartig sein, aber auch auf einen möglichen Angriff hinweisen können. In diese
Kategorie fällt etwa ein ICMP “Echo Request”, der zur Fehlersuche eingesetzt wird,
aber auch von Angreifern verwendet werden kann, um die Ziele im Bereich der IT
auszukundschaften. Weitere Probleme treten durch mögliche falsch-positive Meldungen (engl. false positives) auf. Das eigentliche Problem dabei besteht nicht darin,
dass ein Event fälschlicherweise als Angriff gewertet wird, es liegt vielmehr in den
daraus resultierenden Reaktionen der Organisation. Werden Notfallmaßnahmen
angetriggert, ohne dass tatsächlich der Notfall vorliegt, so kostet dies zum einen
Ressourcen, da Mitarbeiter nun in das Notfallteam abberufen werden und nicht
mehr ihrer eigentlichen Aufgabe nachkommen können, zum anderen kann auch
durch die Notfallsituation selbst die Handlungsfähigkeit der Organisation negativ
beeinträchtigt werden. Insofern ist es wichtig, die Anzahl der falsch-positiven
Ereignisse möglichst zu minimieren, auf der anderen Seite aber möglichst keine
Ereignisse fälschlicherweise als Nicht-Angriff zu bewerten.
Seite 75
Definition
Sicherheitsvorfall
Falsche Reaktionen
wirken sich negativ aus
Neben der korrekten Feststellung eines Sicherheitsvorfalls ist auch die Einordnung desselben ein wichtiges Kriterium. Die Entscheidung, ob es sich eher um
eine kleine Unterbrechung einer vielleicht nicht so wichtigen Funktion innerhalb
der Organisation handelt oder ob ein katastrophales Ereignis besteht, entscheidet
auch über die zu treffenden Maßnahmen. So ist in einem Fall der Anruf bei einem
Administrator völlig ausreichend, während in einem anderen Fall vielleicht alle
Personen aus dem Gebäude evakuiert werden müssen. Die vorherige Festlegung
der Schwere eines Sicherheitsvorfalls und der Einordnung in Kategorien mit entsprechendem Schweregrad ist damit für die angemessene Reaktion unabdingbar.
Wie wir auch im weiteren Verlauf dieses Abschnitts noch näher diskutieren werden,
muss dies auch vor dem Eintritt des Ereignisses selbst geschehen, da sonst im
Eifer des Gefechts schnell eine falsche Entscheidung getroffen wird, die vielleicht
größere Schäden als der eigentliche Vorfall hervorrufen kann.
Kategorisierung
Zu möglichen Sicherheitsvorfällen gehören bspw. der unberechtigte Zugang zu
Systemen und Diensten und/oder Zugriff auf Daten, missbräuchliche Verwendung
von Systemen, Diensten und/oder Daten, Denial-of-Service-Angriffe (kurz: DoS), ESpionage, Fraud, Social Engineering, der Ausfall von Versorgungssystemen wie Kälte,
Klima, Lüftung, Heizung, aber auch das Auftreten von Feuer, Überschwemmung,
Flutung oder anderen Ereignissen höherer Gewalt.
Typen von
Sicherheitsvorfällen
Die größte Schwierigkeit bei der Festlegung der Definition eines Sicherheitsvorfalls sowie der Schweregrade liegt in einer nicht sauberen Trennung zwischen
einem Ereignis und einer Störung. Zudem trägt eine zu geringe Detailtiefe bei
der Beschreibung dazu bei, dass die Definitionen im realen Fall nicht ausreichend
sind und somit keine klaren Entscheidungswege vorgeben. Wie bei vielen anderen
Bereichen spielt auch hier die Unterstützung durch das Management der Organisation eine entscheidende Rolle, denn häufig werden die Entscheidungen zu stark
durch die “Politik” der Organisation beeinflusst.
Mögliche Probleme
Angemessene Reaktion
erfordert Planung
5.2 Entwicklung und Aufrechterhaltung eines Incident
Response-Plans
Nachdem die Definition eines Sicherheitsvorfalls und die Festlegung von Schweregraden erfolgt ist, ist nun ein Incident Response-Plan aufzustellen und kontinuierlich weiter zu entwickeln, der sicher stellt, dass eine effektive und rechtzeitige
Reaktion auf Vorfälle im Bereich der Informationssicherheit erfolgt. Dazu sind
Geplante Grundlage
Seite 76
Studienbrief 5 Vorfallsmanagement im Bereich der IS
(schriftlich fixierte) Anweisungen erforderlich, die vorgeben, welche Schritte wie
unternommen werden müssen und welche Personen und/oder Teams dazu einzubinden sind. Insbesondere die Frage, wer der finale Entscheider im Falle eines
Sicherheitsvorfalls ist, muss vorher geklärt sein. Dabei ist es auch nicht ungewöhnlich, dass im Rahmen eines Sicherheitsvorfalls weitreichende Kompetenzen auf
diese Person übertragen werden und/oder nicht mehr die Geschäftsführung der
Organisation die letzte Entscheidung trifft.
Lenken und beobachten
Im Falle eine Vorfalles ist aber nicht nur die Frage des Entscheidungsträger ein
wichtiger Aspekt. Damit der Prozess überhaupt vorangetrieben wird, muss ebenfalls eine verantwortliche Person benannt sein, die sich um den Fortgang des
Prozesses kümmert und als “Treiber” agiert. Diese Person hat im wesentlichen
die Aufgabe, die Durchführung der verschiedenen Teilschritte im Rahmen des
Incident Response-Prozesses zu koordinieren, deren Ausführung zu überwachen,
eventuelle Entscheidungen zu treffen und/oder herbeizuführen und die Zusammenarbeit mit dem Management zu koordinieren - diese Aufgabe kann, aber muss
nicht vom IS-Manager wahrgenommen werden.
Beobachtung durch
unabhängige Stelle
Neben dieser treibenden Kraft ist auch der Einsatz eines reinen Beobachters zu
empfehlen. Abseits des eigentlichen Prozesses hat dieser nur die Aufgabe, den
Prozess selbst zu beobachten und alle durchgeführten Aktivitäten zu protokollieren. Erst durch Einsatz eines solchen unabhängigen Beobachters besteht die
Chance, nach Beendigung des Vorfalls alle Aktivitäten nochmals auf Konsistenz
mit dem Incident Response-Plan zu untersuchen und ggf. eine Änderung des
Plans anzustoßen. Verlässt man sich nur auf die während der Reaktion auf den
Vorfall von den Beteiligten erstellten Aufzeichnungen, so werden viele Aspekte
nicht berücksichtigt werden können; insbesondere die nicht ordnungsgemäße
Durchführung von Teilschritten lässt sich nur durch einen unabhängigen (=nicht
am Prozess beteiligten) Beobachter realisieren.
Incident
Response-Prozess
Der Prozess des Incident Response (kurz: IR-Prozess) gliedert sich in unterschiedliche Teilaspekte, die aber nicht vollständig bei jedem Vorfall berücksichtigt werden
müssen. Darüber hinaus kann es auch in der zeitlichen Abfolge Variationen geben,
die durch die konkrete Situation bedingt sind. So wird in einigen Fällen der Wiederherstellung der Funktionalität ggb. der Ermittlung der Täter eine höhere Priorität
eingeräumt werden, etwa wenn die Ermittlung der Täter sowieso aussichtslos
erscheint.
Teilschritte des
IR-Prozesses
Zu den Teilschritten im Rahmen eines Incident Response-Prozesses gehören unter
anderem:
• Informationen einholen, die den Vorfall als solchen bestätigen (können)
• Umfang, Ausmaß der betroffenen Umgebung ermitteln
(Räume, Netzwerk, Systeme, Dienste, Daten)
• Mögliche Verluste, Veränderungen und/oder Beschädigungen bestimmen
• Bestimmen, ob eine Reaktion erforderlich ist
• Sicherung/Backups von allen möglichen Beweisquellen erstellen
• Wiederherstellen der Funktionsfähigkeit der betroffenen Umgebung
• Mögliche Wege des Angreifers ermitteln
Kenntnisse der
Digitalen Forensik
Die Gestaltung dieses Prozesses erfordert also auch Grundkenntnisse im Bereich
der Forensik, etwa weil sichergestellt werden muss, dass die Beweiskette (engl.:
chain of custody) aufrecht erhalten wird und entsprechende Analysen somit grundsätzlich nur an Backups der eigentlichen Daten vorgenommen werden. Kenntnisse
5.3 Aufbau eines Prozesses, der die Erkennung von Vorfällen sicher stellt
Seite 77
über Maßnahmen im Bereich der Erstreaktion auf Vorfälle (engl.: first response)
gehören ebenfalls dazu, bieten gerade diese doch die Möglichkeit, viele Fehler zu
machen und das weitere Vorgehen damit negativ zu beeinflussen.
Um auch nach einem Vorfall eine detaillierte Dokumentation der Vorgehensweise
während der Ausführung der einzelnen Schritte des Incident Response-Plans zur
Verfügung zu haben, ist das Anlegen eines Logbuchs, in dem alle Aktivitäten
entsprechend protokolliert werden, eine wichtige Maßnahme. Zu den im Logbuch
festgehaltenen Informationen gehören eine kurze Zusammenfassung des Vorfalls
und seiner Einstufung, die Auflistung der durchgeführten Aktionen mit Datum,
Uhrzeit und Akteur zu jeder Aktion, die Angabe von Kontaktinformationen, eine
Liste von “Beweisen”, die während der “Ermittlung” erhoben wurden, ggf. Kommentare und Hinweise durch alle beteiligten Personen sowie mögliche nächste
Schritte.
Dokumentation
Ein wesentliches Problem im Rahmen der Erstellung eines Incident Response-Plans
liegt bereits in der Frage, wann und in welcher Form ein Sicherheitsvorfall vorliegt.
Aus einer fehlerhaften Einschätzung des Problems resultieren dann auch oft falsche
Erstreaktionen, die in der Folge dann auch zu weiteren Problemen führen können,
verstärkt wird dies auch durch eine Unwissenheit bzgl. des Umfangs der aus dem
Sicherheitsvorfall resultierenden Probleme.
Mögliche Probleme
Weitere Problemfelder sind bspw. eine unzureichende Unterstützung durch das
Management, die zu einer unzureichenden Ausstattung mit den für den Incident
Response-Plan notwendigen Ressourcen führen kann, häufig korreliert mit dem
Umstand, dass es schwierig ist, die notwendigen Ressourcen (im Vorfeld) genau
festzulegen. Nicht zuletzt spielen auch Mängel aufgrund eines unzureichenden
Verständnisses des Prozesses und unzureichender Arbeitsanweisungen eine Rolle.
Zudem kommt es “im Eifer des Gefechts” immer wieder dazu, dass die Beteiligten
keine oder zu wenig Dokumentation erstellen.
Unzureichende
Unterstützung
5.3 Aufbau eines Prozesses, der die Erkennung von
Vorfällen sicher stellt
Eine wesentliche Voraussetzung für das Funktionieren des Incident Response-Plans
ist die Erkennung und letztendlich dann auch Feststellung eine Vorfalls. Auch
hierzu ist es notwendig, einen Prozess zu schaffen, der die zeitnahe Erkennung
eines Vorfalls im Bereich der Informationssicherheit sicherstellt und damit auch
dessen Eingrenzung ermöglicht.
Prozess zur Erkennung
eines Vorfalls
Zur Entdeckung von Sicherheitsvorfällen kommen prinzipiell unterschiedliche
Mechanismen und Informationsquellen in Betracht. Dazu zählen die Beobachtung
von externen Quellen, wie bspw. Incindent Reporting Websites, Security-Bulletins
von Hard-/Softwarelieferanten und den Meldungen der einschlägigen CERT. Auch
Dienstleister, die über sicherheitsrelevante Vorfälle berichten, sollten mit einbezogen werden. Ergänzend lassen sich Intrusion Detection-Systeme (IDS) einsetzen,
die (teil)automatisch Angriffe erkennen und entsprechend melden. Auf Grundlage
dieser automatisierten Meldungen können dann nachgelagerte manuelle Aktionen
getriggert werden, deren Ziel eine bessere Einschätzung, ob ein falsch-positives
Ereignis vorliegt, bzw. des Schweregrads des Vorfalls, ist. IDS lassen sich dabei
sowohl inhouse, als auch gemanagt als IDS-Service betreiben.
Entdeckung
Im Rahmen der auf die Vorfallserkennung folgenden Analyse ist zunächst festzustellen, welche Auswirkungen der Vorfall haben kann und wie diese Auswirkungen
im Kontext der Organisation zu bewerten sind. Zielsetzung ist dabei, angemessen
(Erst-)Analyse
Intrusion DetectionSysteme
Seite 78
Studienbrief 5 Vorfallsmanagement im Bereich der IS
auf den Vorfall zu reagieren, aber auch daraus zu lernen. Dabei sollen die Ergebnisse der Vorfallsbehandlung in das Sicherheitsprogramm mit einbezogen werden,
bspw. durch Anpassung von Schwellwerten, der Kommunikation von kritischen
Ereignissen und ggf. auch in der Abstimmung zur Frage, was denn tatsächlich
ein Sicherheitsvorfall ist. Um aber letztendlich einen echten Nutzen (im Rahmen
der Anpassung des Sicherheitsprogramms) ziehen zu können, sind umfangreiche
Detailinformationen über den Vorfall und insbesondere über den Umgang mit
demselben notwendig.
Mögliche Probleme
Hauptproblem bei der Erkennung von Sicherheitsvorfällen ist, dass sie stattfinden, aber nicht (rechtzeitig) erkannt werden. Die Gründe dafür sind vielschichtig,
angefangen von schlechter Awareness innerhalb der Organisation, schlechter Kommunikation des Vorfalls oder auch einer unzureichenden Charakterisierung von
möglichen Vorfallstypen. Zudem mangelt es oft an einer ausreichenden Dokumentation zur Behandlung des Vorfalls, wodurch der Lerneffekt behindert oder ganz
unmöglich wird.
5.4 Aufbau eines Prozesses zur Untersuchung von
Sicherheitsvorfällen
Planung eines Prozesses
als Grundlage
Nach der Erkennung eines Sicherheitsvorfalls stellt sich die Frage, wie jetzt weiter
damit umzugehen ist. Dazu ist im Vorfeld ein Prozess zur Untersuchung und
Dokumentation von Sicherheitsvorfällen zu schaffen, der sicher stellt, dass eine
angemessene Reaktion stattfindet, die Ursachen ermittelt und dabei die rechtlichen
und regulatorischen Rahmenbedingungen berücksichtigt werden.
Live Response vs.
Post Mortem-Analyse
Bei der Untersuchung von Sicherheitsvorfällen werden grob zwei unterschiedliche
Herangehensweisen unterschieden. Der Ansatz des Live Respose wird immer
dann genutzt, wenn eine kurzfristige Untersuchung notwendig ist, da sonst die
wesentlichen (flüchtigen) Daten verloren sind, bspw. bei Netzwerk- oder Webserverbasierten Vorfällen. Im Gegensatz dazu kommt die Post Mortem-Analyse nachgelagert zum Einsatz und ist damit nur für eine Analyse geeignet, die kein Live-System
mehr benötigt, bietet aber den Vorteil, dass prinzipiell deutlich mehr Zeit für
die Analyse zur Verfügung steht. Bei beiden Methoden stehen eine Vielzahl von
möglichen Tools zur Verfügung, angefangen von einfachen KommandozeilenWerkzeugen bis hin zu Spezialsoftware.
Abb. 5.1: Illustration
der drei Phasen “Secure”, “Analyse” und
“Present”, die sich im
Rahmen der Digitalen
Forensik etabliert haben.
3
Present
2
Analyse
1
Secure
Abbildung 5.1 zeigt die drei wesentlichen Teilprozesse im Rahmen der Digitalen
Forensik: In Phase 1 “Secure” werden zunächst alle Daten und beweise gesichert,
um in der anschließenden Phase 2 “Analyse” ausgewertet zu werden. In der finalen
Phase 3 “Present” werden die Ergebnisse dieser Analyse dann -zielgruppengerecht
aufbereitet- vorgestellt.
5.5 Aufbau eines Prozesses zur Eskalation und Kommunikation von Vorfällen
Seite 79
Während der Analyse sind alle anlassbezogenen Informationen entsprechend zu sichern, dabei sind Grundkenntnisse im Bereich der Digitalen Forensik sehr hilfreich.
Insbesondere sollte darauf geachtet werden, dass entsprechende forensische Werkzeuge zum Einsatz kommen und alle Aktivitäten im Detail protokolliert werden.
Sämtliche Datenanalysen sind dabei ausschließlich an Kopien der Originaldaten
vorzunehmen, damit hat man für die spätere Verwendung immer noch einen
nicht-veränderten Originaldatenbestand. Bei der Erzeugung der notwendigen
Datenkopien müssen ebenfalls forensische Werkzeuge benutzt werden, die eine
vollständige und unveränderte Kopie des Datenträgers erstellen, hierzu werden
“bit stream copy”-Werkzeuge mit “write blocker”-Mechanismen eingesetzt.
Beweissammlungen
Nicht weniger relevant ist die Berücksichtigung der rechtlichen und regulatorischen Anforderungen bei der Sammlung und Erhebung von Beweisen. Insbesondere wenn die Beweise in einem späteren Gerichtsverfahren genutzt werden sollen,
sollte bereits im Vorfeld geklärt werden, wie die Anforderungen sind, was die
Zulässigkeit und Qualität bzw. Vollständigkeit von Beweisen betrifft.
Anforderungen an
Beweissammlungen
Um weitere Informationen über den Vorfall bzw. den Ablauf desselben zu erlangen,
können Interviews mit den Beteiligten innerhalb und außerhalb der Organisation
sinnvoll sein. Mögliche Aspekte dabei sind bspw., wer den Vorfall entdeckte, wie
der Vorfall entdeckt wurde, wann der Vorfall passiert ist, welcher Schaden entstanden ist. Alle diese Informationen helfen, ein Gesamtbild zu erstellen, dass eine
Bewertung des Vorfalls ermöglicht und zudem bei der Ermittlung der Ursachen
hilfreich sein kann.
Interviews mit den
Beteiligten
Häufig werden bei der Analyse der Daten keine oder keine sachgerecht erstellten
Kopien der Originaldatenträger verwendet. Dies führt -ebenso wie die Verwendung nicht sachgerechter Untersuchungsmethoden und -werkzeuge- häufig dazu,
dass die Beweise für einen Gerichtsprozess nahezu wertlos werden. Auch im Rahmen der (forensischen) Untersuchung von Sicherheitsvorfällen sollte entsprechend
geschultes und trainiertes Personal vorhanden sein, um Kardinalsfehler zu vermeiden und so letztendlich auch aus dem negativen Ereignis “Sicherheitsvorfall”
noch etwas lernen zu können.
Mögliche Probleme
5.5 Aufbau eines Prozesses zur Eskalation und
Kommunikation von Vorfällen
Um sicher zu stellen, dass die zuständigen Interessensvertreter innerhalb der Organisation angemessen in das Incident Response-Management eingebunden sind,
wird ein Prozess zur Benachrichtigung über und zur Eskalation von Vorfällen im
Informationssicherheitsbereich geschaffen und kontinuierlich weiter entwickelt.
Benachrichtigungsprozess
Falls es in der Organisation zu einem Vorfall im Informationssicherheitsbereich
kommt, kann es je nach Schwere des Vorfalls durchaus erforderlich sein, unterschiedliche Stellen -von der IT-Abteilung bis hin zur Geschäftsführung- in der
Organisation zu informieren. Dieser Eskalationsprozess muss immer auf Grundlage von im Vorfeld festgelegten Kriterien erfolgen, dabei ist auch die Priorisierung
der Informationen zu berücksichtigen. Zudem ist festzulegen, wer wann welche
Informationen erhalten soll. Auch die große Vielfalt möglicher Zielgruppen (Geschäftsführung, Öffentlichkeit, Anteilseigner, Anbieter und Kunden, öffentliche
Stellen und Aufsichtsbehörden) ist dabei angemessen zu berücksichtigen.
Eskalation
Neben festgelegten Eskalationsstrategien ist vor allem ein zielgerichteter Benachrichtigungsprozess beim Auftreten von Sicherheitsvorfällen ein entscheidender
Baustein. Dieser Prozess sollte möglichst dort ansetzen, wo die Informationen
Kommunikation
Seite 80
Studienbrief 5 Vorfallsmanagement im Bereich der IS
Helpdesk-Personal
Mögliche Probleme
über potentielle Vorfälle als erstes ankommen; falls ein Helpdesk für die Anwender existiert, ist dies also ein guter Einstiegspunkt. Dabei muss der Prozess so
gestaltet sein, dass das Helpdesk-Personal eine gute Entscheidungsbasis für die
Entscheidung hat, ob es sich überhaupt um einen Sicherheitsvorfall handelt. Zudem ist festzulegen, wie der weitere Prozess organisiert werden soll und wie die
Verantwortlichkeiten der Beteiligten (bspw. IT-Mitarbeiter, Helpdesk-Personal,
Geschäftsprozessverantwortliche, ...) sind.
In erster Linie ist das Problem der Entscheidung, ob es sich tatsächlich um einen
Sicherheitsvorfall handelt, zu nennen. Hier sind regelmäßige Schulungen und
ausreichendes Training für das Helpdesk-Personal ein wichtiges Kriterium, um
dieses auf den Ernstfall vorzubereiten. Dazu gehört auch, die Prozesse so festzulegen, dass die entsprechenden Personen diese im Ernstfall auch anwenden können.
Weitere Probleme ergeben sich häufig dadurch, dass die Kommunikationswege
nicht oder nicht klar definiert sind und so die falschen Personen benachrichtigt
werden. Dadurch entsteht nicht nur die Gefahr, dass die Information stecken bleibt,
in jedem Fall geht wertvolle Zeit für die Eindämmung des Sicherheitsvorfalls
verloren. Auch das Fehlen von Entscheidungsträgern führt dazu, dass wertvolle
Zeit verloren geht, bspw. wenn der Ansprechpartner nicht im Hause ist und nun
niemand weiß, was zu tun ist bzw. niemand die Verantwortung für die weiteren
Aktionen übernehmen will.
5.6 Aufbau und Training der Incident Response-Teams
Incident Response-Teams
Neben den prozessualen Vorbereitungen gehört auch der Aufbau, das Training und
die entsprechende Ausstattung (mit den notwendigen Ressourcen) von Incident
Resposne-Teams zu den wesentlichen Voraussetzungen für einen erfolgreichen
Incident Response-Prozess. Letztendlich soll damit sicher gestellt werden, dass
die Organisation in angemessener Zeit effektiv auf Vorfälle im Bereich der Informatiossicherheit reagieren kann.
Verschiedene
Schwerpunkte
Innerhalb der Organisation wird dazu allerdings nicht ein alleinstehendes Team
gebildet, vielmehr werden Spezialteams geformt, die jeweils ihre Aufgabe haben,
aber natürlich auch im Verbund koordiniert werden müssen, da es kaum Vorfälle
geben wird, bei dem ein Team allein eingebunden ist. So gibt es spezielle Teams,
bspw. für die Themen Incident Management und Emergency Response, für die Bereiche Netzwerke, Betriebssysteme und Anwendungssysteme, die zu Teil wiederum
untergliedert werden können (bspw. in die Administration von Betriebssystem,
Middleware (Datenbanken) und Anwendungen).
Abb. 5.2: Bei einem virtuellen Team werden
die Mitarbeiter aus unterschiedlichen Bereichen zu einem “physisch
nicht-existenten” Team
zusammen gezogen.
Virtuelle Teams
Dabei sind auch virtuelle Teams denkbar, bei denen die Mitglieder in unterschiedlichen Bereichen der Organisation sitzen und dann im Bedarfsfall zusammen agieren
(können, aber nicht zwingend zusammen sitzen müssen; Abbildung 5.2 illustriert
diesen Sachverhalt.
5.7 Regelmäßige Übungen
Seite 81
Ergänzt werden diese Teams häufig durch ein Team im Bereich der Informationssicherheit bzw. des Informationssicherheitsmanagement. Natürlicherweise sind die
Aufgaben der einzelnen Teams nicht immer klar voneinander zu trennen, daher ist
die Koordinierung durch den IS-Manager eine wichtige Aufgabe, um unnötigen
Einsatz von Ressourcen zu vermeiden.
Ergänzung durch IS-Team
Wichtige Voraussetzung für den effektiven Einsatz der Incident Response-Teams
ist, dass die richtigen Leute im richtigen Team sind. Es ist also bereits im Vorfeld zu
ermitteln, welche Personen welche Schwerpunkte haben bzw. übernehmen möchten und diese dann in die passende Teamstruktur einzugliedern. Darüber hinaus
muss den Mitgliedern der einzelnen Teams auch genügend Gelegenheit gegeben
werden, sich laufend auf dem aktuellen Stand zu halten. Dies ist ein Aspekt, der
in vielen Organisationen übersehen wird, liegt hier doch der Großteil des Ressourceneinsatzes versteckt: Zu Vorfällen kommt es in den meisten Organisationen recht
selten, alle Teammitglieder müssen aber trotzdem ausreichend Freiraum in der täglichen Arbeit bekommen, ihre Fähigkeiten auf dem aktuellen Stand zu halten. Ein
weiteres Problem besteht natürlich darin, dass im Vorfeld überhaupt keine Teams
gebildet werden, denn dann muss in der akuten Situation eines Sicherheitsvorfalls
entschieden werden, wer welche Aufgabe übernehmen soll, es müssen Personen,
die bisher noch nicht miteinander gearbeitet haben, nun unter Stress zusammen
arbeiten und daraus werden in der Regel Fehlentscheidungen bzw. -reaktionen
folgen. Etwas Ähnliches droht übrigens auch, wenn zwar Teams geformt wurden
und die Team-Mitglieder “up-to-date” sind, aber im Vorfeld nicht ausreichend
Zeit für das Training der Situation eingeräumt bekommen haben.
Mögliche Probleme
Fehlende Teams
5.7 Regelmäßige Übungen
Wie bereits im vorhergehenden Abschnitt angesprochen, sind regelmäßige Übungen der Reaktionen im Falle eine Sicherheitsvorfalls und zum Einsatz der Incident
Response-Teams ein wichtiger Baustein für einen erfolgreichen Incident ResponseProzess. Nur durch eine regelmäßige Überprüfung des Incident Response-Plans im
Rahmen von Tests und konkreten Übungen an praxisnahen Beispielen kann sicher
gestellt werden, dass eine effektive Reaktion auf Sicherheitsvorfälle stattfindet.
Und nur durch Behebung der während dieser Übungen aufgedeckten Misstände
lässt sich der Incident Response-Prozess kontinuierlich verbessern - und damit
letztendlich effektiver und effizienter gestalten.
Erfolg durch praktische
Übungen
Damit die Übungen effektiv stattfinden können und vor allem auch bewertbar
sind, müssen die Tests und Übungen im Vorfeld geplant werden. Dazu gehört
auch, die Inhalte festzulegen und bereits vor der Durchführung die Ziele der Tests
und Übungen zu definieren. Werden die Ziele erst nach Durchführung festgelegt,
wird eine neutrale und wiederholbare Bewertung der Ergebnisse kaum möglich
sein, da die Ziele dann in der Regel nach dem Erfolg der Übung festgelegt werden.
Anhand dieser im Vorfeld festgelegten Kriterien erfolgt dann die Bewertung der
Tests und Übungen, deren Ergebnis letztendlich in einer Verbesserung des Incident
Response-Prozesses münden soll.
Regelmäßige Übungen
Dazu ist aber ebenfalls ein entsprechender Prozess notwendig, der die Ergebnisse
auch tatsächlich in die Neugestaltung der Incident Response-Pläne mit einfließen
lässt. Dazu ist ein Meilensteinplan aufzustellen und die Umsetzung fortlaufend zu
kontrollieren, da sonst die Gefahr besteht, dass die Umsetzung mittendrin stecken
bleibt bzw. überhaupt nicht erfolgt.
Lessons learned
Ein weitere wichtiger Aspekt ist aber auch die Sicherstellung der Vertraulichkeit
Vertraulichkeit
sicher stellen
Seite 82
Studienbrief 5 Vorfallsmanagement im Bereich der IS
der Berichte zu Tests und Übungen, die ggf. entsprechend kritische Ergebnisse
beinhalten. Natürlich müssen diese an die Verantwortlichen in der Organisation
kommuniziert werden, es muss aber gleichzeitig vermieden werden, dass die Informationen vor dem Schließen der entsprechenden Sicherheitslücke an potentielle
Angreifer durchsickern. Eine angemessene Information von Kunden und Partnern
sollte aber erwogen werden, wenn durch die aufgedeckte Sicherheitslücke auch
diese direkt betroffen sind.
Mögliche Probleme
Leider wird die Durchführung von Tests und Übungen als Einmal-Aktion gesehen
- und damit der zeitliche und personelle Aufwand, der eigentlich notwendig ist,
völlig unterschätzt. Dies resultiert dann häufig darin, dass die Unterstützung
durch die Geschäftsleitung nicht ausreichend ist und daher die Durchführung von
Test und Übungen immer zu Gunsten des täglichen Betriebs vernachlässigt wird.
Dies rächt sich spätestens dann, wenn es zum Sicherheitsvorfall kommt und dann
festgestellt werden muss, dass die Incident Response-Pläne nicht mehr aktuell
sind, bspw. weil sich die Prozesse der Organisation geändert haben, in den Plänen
genannte Personen nicht mehr im entsprechenden Team oder gar nicht mehr in
der Organisation sind.
Problemfeld “Rivalitäten”
Ein weiteres Problem stellen Rivalitäten zwischen Teammitgliedern bzw. ganzen
Teams dar, wenn es während der Tests und Übungen zu Problemen kommt, die
ggf. den Produktivbetrieb stören. Hier sollte das Klima im Team bzw. zwischen
den Teams von vorneherein so geprägt sein, dass klar ist, dass die Geschäftsleitung auch dieses Problem “mit trägt” Dazu sollte sie aber natürlich im Vorfeld
im Rahmen einer allgemeinen Risikobetrachtung über die möglichen Probleme
während/durch Tests und Übungen informiert worden sein und die Entscheidung
aktiv und nachvollziehbar getroffen haben.
Problemfeld “Kein
Lessons-learned”
Letztendlich sind aber Tests und Übungen völlig sinnlos und damit eine reine
Vergeudung von Ressourcen, wenn die Ergebnisse nicht auch in die Incident
Respone-Pläne zurück fließen und damit dazu beitragen, den Incident ResponseProzess kontinuierlich zu verbessern. Ziel ist es ja, die Incident Response-Pläne so
zu gestalten, dass diese möglichst effektiv und effizient umgesetzt werden können
und somit wertvolle Ressourcen eingespart werden können.
5.8 Aufbau von Kommunikationsprozessen
Gezielte Kommunikation
Um die Kommunikation zu internen und externen Stellen im Falle eines Sicherheitsvorfalls koordiniert vorantreiben zu können, ist im Vorfeld ein entsprechender
Prozess aufzubauen und kontinuierlich weiter zu entwickeln.
Vielfältige Kommunikation
Dabei ist die Kommunikation zu unterschiedlichsten Bereichen zu berücksichtigen.
Dazu gehören bspw. die Geschäftsleitung, die Mitarbeiter und die wesentlichen
Abteilungen (etwa Rechtsabteilung, Kommunikationsabteilung, ...) der Organisation selbst, aber auch zu externen Stellen, wie bspw. Kunden und Geschäftspartnern,
Behörden (etwa Strafverfolgungs- und Aufsichtsbehörden) und ggf. auch der Öffentlichkeit.
Mögliche Probleme
Wichtig ist für jegliche Kommunikation, dass im Vorfeld für die jeweiligen Kommunikationspartner Verantwortliche festgelegt werden, die dann auch darüber
entscheiden, welche Informationen weiter gegeben werden. So wird vermieden,
dass die falschen Leute die Kommunikation übernehmen und dadurch bspw. eine
uneinheitliche Kommunikation entsteht. Somit werden in Krisensituationen sehr
schädliche Gerüchte vermieden. Zudem muss strikt darauf geachtet werden, dass
5.9 Durchführen von Nachvorfallsbehandlungen
Seite 83
nur freigegebene Informationen heraus gegeben werden, auch dies wird durch die
Definition klarer Verantwortlichkeiten unterstützt.
Problematisch ist für jede Organisation, wenn externe Stellen - ggf. auch die Öffentlichkeit - nicht von der Organisation selbst, sondern unkontrolliert aus den
Nachrichten von den Problemen erfahren, denn auf diesem Wege gestreute Informationen lassen sich nicht mehr zurück rufen, ob sie nun wahr sind oder nicht.
Problemfeld “Unkontrollierte Verbreitung von
Informationen”
5.9 Durchführen von Nachvorfallsbehandlungen
Damit nach dem Eintreten eines Vorfalls im Bereich der Informationssicherheit
sicher gestellt werden kann, dass die Ursache für den Vorfall aufgeklärt wird,
entsprechenden korrigierende Maßnahmen entwickelt, die Risiken neu bewertet
und letztendlich die Ursachen für den Vorfall beseitigt werden, sind entsprechende
Nachvorfallsbetrachtungen (engl.: post-incident reviews) durchzuführen.
Aus Problemen lernen
Dazu sollte ein Event Review-Team etabliert werden, das aus Personen aus den
jeweils am Vorfall beteiligten Teams, aber auch aus Personen aus wichtigen Bereichen des Unternehmens besteht. Dieses analysiert die vom Incident Response-Team
ermittelten Ursachen anhand der gesammelten Beweise und entwickelt entsprechende Empfehlungen, die die Defizite korrigieren sollen.
Event Review-Team
Dazu muss das Event Review-Team allerdings konsistente Methoden anwenden,
seine Aktionen sollen sowohl wiederholbar, aber auch sinnvoll bewertbar sein.
Wesentliche Aufgabe des Event Review-Teams ist es, unter Berücksichtigung aller
Hinweise und Beweise, die sich aus den diversen Dokumentationen zum Vorfall
ergeben, die Ursache (engl.: root cause) für den Vorfall zu ermitteln, also Ursachenforschung zu betrieben. Ziel ist es, Maßnahmen zu entwickeln und anhand
eines Aktionsplans umzusetzen, die ein erneutes Auftreten desgleichen oder eines
ähnlich gelagerten Vorfalls verhindern.
Ursachenforschung
Ohne Unterstützung durch das Management ist diese Aufgabe allerdings nicht
zu bewerkstelligen, denn spätestens wenn es darum geht, die entwickelten Maßnahmen auch in die Praxis umzusetzen, werden Ressourcen erforderlich, die ohne
einen entsprechende Unterstützung in der Regel nicht bereit gestellt werden.
Managementunterstützung
Das Event Review-Team erstellt dazu einen Bericht, der im Groben aus zwei Teilen
besteht: der Zusammenfassung von Ereignis, Ursache und notwendigen Maßnahmen -diese wird hauptsächlich von der Geschäftsleitung gelesen- und einem
Detailreport, der die zur Umsetzung von Maßnahmen notwendigen Einzelheiten
und den Aktionsplan beinhaltet. Im Bericht sollten auch Kostenschätzungen und
sinnvolle Metriken enthalten sein, damit der Geschäftsleitung eine Entscheidungsgrundlage gegeben wird, um eine risikobasierte Entscheidung zur Umsetzung der
Maßnahmen treffen zu können.
Bericht zum Vorfall
Insbesondere eine zu frühe Auflösung der Incident Response-Teams führt dazu,
dass kein angemessenes Event Review-Team vorhanden ist, letztendlich ist auch
dies ein Ressourcenproblem, das durch eine entsprechende Unterstützung durch
die Geschäftsleitung vermieden werden kann. Diese ist -wie in den vorhergehenden
Abschnitten bereits erwähnt- auch notwendig, damit die sich aus der Analyse
ergebenden Maßnahmen auch tatsächlich in der betrieblichen Praxis umgesetzt
werden. Die verwendeten Metriken sollten zudem aufbewahrt werden, damit die
Entscheidungen auch im Nachhinein nachvollzogen werden können und bei einem
erneuten Vorfall zudem eine Vergleichsmöglichkeit gegeben ist.
Mögliche Probleme
Seite 84
Studienbrief 5 Vorfallsmanagement im Bereich der IS
5.10 Integration in Desaster Recovery- und Business
Continuity-Prozesse
Überschneidungen vermeiden
Nicht zuletzt sollten die Aktivitäten im Bereich des Incident Response auch in die
im Bereich Desaster Recovery und Business Continuity integriert werden. Nur so
kann sicher gestellt werden, dass es nicht zu unnötigen Überschneidungen oder
gar Behinderungen kommt, etwa weil Zuständigkeiten nicht eindeutig geklärt
sind.
Wesentliche Schritte
im Bereich DR und BC
Zu den wesentlichen Aspekten im Bereich des Desaster Recovery bzw. Business
Continuity gehören bspw. die Erstellung einer Business Impact-Analyse mit Festlegung und Priorisierung von Prozessen und sonstigen Ressourcen, die Entwicklung
eines detaillierten Desaster Recovery- und Business Continuity-Plans, Training der
Mitarbeiter und regelmäßiges Testen der Pläne, eine regelmäßige Überarbeitung
bzw. Anpassung der Pläne an die aktuelle Situation, sowie auch ein regelmäßiges
Audit der Pläne durch unabhängige Stellen. Zudem muss sicher gestellt werden,
dass die Unterlagen an sicherer Stelle verwahrt werden - und so im Falle des Falles
auch bei Einschränkung des IT-Betriebs und/oder einem nicht möglichen Zutritt
zum Gebäude immer noch greifbar sind.
Klare Abgrenzung notwendig
Um eine klare Trennung zwischen einem Vorfall und einem Desaster zu haben,
müssen die beiden Begrifflichkeiten eindeutig voneinander abgegrenzt werden.
Jede Organisation muss dazu eine angemessene Definition für beide Begrifflichkeiten festlegen und diese an alle Beteiligten kommunizieren, die Definition selbst
kann und wird sich aber von Organisation zu Organisation stark unterscheiden.
Mögliche Probleme
Insbesondere, wenn ein Vorfall im Bereich der Informationssicherheit zu einem
Desaster wird, ist eine Einbindung der Prozesse des Desaster Recovery und Business Continuity unabdingbar. Dies bedingt gleichzeitig eine gute Abstimmung der
einzelnen Teams untereinander und auch eine realistische Einschätzung der Lage.
So muss das Incident Response-Team auch akzeptieren, dass es die Verantwortung
ggf. abgeben muss und darf nicht aufgrund von hier völlig inakzeptabler Arroganz
am Prozess kleben.
Zusammenfassung dieses Studienbriefs
Zusammenfassung
Der Incident Response-Prozess sorgt dafür, dass die Organisation auf (unerwartete)
Vorfälle im Bereich der IS vorbereitet ist und damit “umgehen” kann. Dazu gehört
eine klare Definition von möglichen Ereignissen, der möglichen Schweregrade
und die Definition und Implementierung entsprechender Subprozesse, die eine
zeitnahe und effektive Reaktion auf einen Sicherheitsvorfall ermöglichen. Als
wichtiger Aspekt wurde auch die Phase des “Lessons learned” heraus gearbeitet:
Dadurch wird die Grundlage geschaffen, dass die Maßnahmen im Bereich der IS
kontinuierlich verbessert werden und damit eine Wiederholung desgleichen oder
eines ähnlichen Vorfalls verhindert wird.
Ausblick
Nachdem wir nun die Grundlagen für die einzelnen Komponenten und Prozesse im
Rahmen eines organisationsweiten IS-Managements geschaffen haben, gehen wir
im folgenden Studienbrief exemplarisch auf die Umsetzung eines IS-Managements
mittels des Ansatzes nach “BSI IT-Grundschutz” ein.
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
Seite 85
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
Nachdem in den vorhergehenden Kapiteln die Grundlagen für die IS in einer
Organisation besprochen wurden, soll in diesem Kapitel nun der Ansatz nach dem
Vorgehensmodell des IT-Grundschutzes (IT-GS) vom Bundesamt für Sicherheit
in der Informationstechnik (BSI) thematisiert werden. Dabei werden wir auf die
einzelnen Teilschritte eingehen, die notwendig sind, um die Organisation bzw.
Teile davon nach IT-GS abzusichern und ggf. auch entsprechend zertifizieren zu
lassen. Hier orientieren wir uns an dem BSI-Standard BSI-100-2 “IT-GrundschutzVorgehensweise” [2], der -wie der Titel bereits nahelegt- die Vorgehensweise bei
der Umsetzung der Anforderungen nach IT-GS in einer Organisation beschreibt. In
diesem Kapitel geben wir allerdings nur einen groben Überblick, der interessierte
Leser wird für die weiteren Details auf die Lektüre des/der entsprechenden BSIStandards verwiesen.
Überblick über die
Thematik
Inhaltlich ist dieses Kapitel wie folgt gegliedert: Nach einer kurzen Einführung beschäftigen wir uns im wesentlichen mit dem Sicherheitsprozess an sich und zeigen
dabei auf, wie dieser von der Ermittlung der Anforderungen über die Erstellung
der IS-Leitlinien, der Bereitstellung von Ressourcen bis hin zur Einbindung der
Mitarbeiter der Organisation nach Ansicht des BSI gestaltet werden sollte. Bei der
Betrachtung wird auch der Aspekt der Verantwortung von und der Unterstützung
durch die Leitungsebene von zentraler Bedeutung sein.
Übersicht BSI-Standard
100-2
Im folgenden Abschnitt gehen wir dann auf die Erstellung einer Sicherheitskonzeption nach BSI IT-GS ein. Dabei zeigen wir auf, wie die Initiierung des
IS-Prozesses gestaltet werden kann, welche Organisationsstrukturen dafür in
der jeweiligen Organisation sinnvoll sein können und wie ein funktionierendes Informationssicherheits-Managementsystems (kurz: ISMS) initial und fortlaufend weiter entwickelt werden kann. Im anschließenden Kapitel wird dann
das zugehörige Konzept dazu erstellt. Dabei werden zunächst die wesentlichen
Informationen zur Organisation erhoben und anschließend -basierend auf einer
Schutzbedarfsfeststellung- die notwendigen Maßnahmen -ggf. ergänzt durch weitere Risikoanalysen- ermittelt.
Prozess Erstellung der
Sicherheitskonzeption
Danach wird die Umsetzung der erkannten Maßnahmen beschrieben und die Fragen rund um die Aufrechterhaltung der IS innerhalb einer Organisation beleuchtet.
Ein kurzer Ausblick auf eine mögliche Zertifizierung schließt diesen Studienbrief
dann ab.
Umsetzung und
Zertifizierung
Konzeption des ISMS
Übersicht zum Vorgehen nach IT-GS
Zur Einführung wollen wir zunächst kurz eine Übersicht zum Vorgehen nach
IT-GS geben und dabei die wesentlichen Aspekte kurz beschreiben.
Vorgehen nach IT-GS
• IS ist mehr als IT-Sicherheit und berücksichtigt die drei Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit bei Personen, Prozessen und Technik.
IT-Sicherheit hingegen berücksichtigt im wesentlichen nur den technischen
Aspekt.
IS vs. IT-Sicherheit
• Die Verantwortung liegt bei der Leitungsebene der Organisation. Ist sich
diese ihrer Verantwortung nicht bewusst, ist zunächst eine entsprechende
Sensibilisierung (ggf. durch den IS-Manager) erforderlich.
Leitungsebene hat
Verantwortung
Seite 86
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
Abb. 6.1: Schematische Darstellung der
einzelnen Teilschritte
im Rahmen der Vorgehensweise nach BSI ITGrundschutz nach [2].
Strukturanalyse des IT-Verbundes
Analyse des IST-Zustandes
Feststellung des Schutzbedarfs
Modellierung des IT-Verbunds
Basis-Sicherheitscheck
Ergänzende Sicherheitsanalyse
80%
20%
Risikoanalyse
Konsolidierung der Maßnahmen
(Erneuter) Basis-Sicherheitscheck
Realisierung der Maßnahmen
IS-Management als Basis
• IS-Management bildet die Basis für eine wirksame IS. Punktuelle Maßnahmen sind nicht zielführend, nur bei Beteiligung aller ist IS insgesamt
wirksam.
Schritte des IS-Prozesses
• Der IS-Prozess besteht aus mehreren Schritten: Nach der Initiierung des Prozesses (durch die Leitungsebene) wird zunächst das Konzept zur IS auf Basis
der Anforderungen erstellt. Im folgenden Schritt wird dieses umgesetzt,
dabei erfolgt auch die Analyse, welche Maßnahmen noch umzusetzen sind.
Als letzter, aber nicht weniger wichtiger Schritt folgt die Aufrechterhaltung
und (kontinuierliche) Verbesserung des IS-Prozesses. Erst dadurch wird gewährleistet, dass die Maßnahmen an die sich stetig ändernden Bedingungen
angepasst werden.
Hilfe durch die
GS-Kataloge
• Die GS-Kataloge enthalten Implementierungshilfen und vereinfachen damit die Umsetzung der erforderlichen Maßnahmen. Durch Kombination
von Maßnahmen auf organisatorischer, personeller und technischer Ebene
wird so ein Grundschutz umgesetzt. Reicht dieser Grundschutz nicht aus,
sind weitere Maßnahmen erforderlich, die eine spezifische Risikoanalyse
bedingen. Nach BSI IT-GS umgesetzte Maßnahmen sind zudem auch gegen
die Anforderungen aus den GS-Bausteinen prüfbar.
Strategische und
operative Ebene
• Die GS-Kataloge gliedern sich von der strategischen bis zur operativen Ebene.
Dies entspricht auch dem Vorgehen bei der Anwendung der Kataloge. Das
6.1 Initiierung des Informationssicherheitsprozesses
Seite 87
Baukastenprinzip gibt zudem bereits eine (einheitliche) Struktur vor, was
die Umsetzung auch für nicht-geübte Anwender vereinfacht.
Abbildung 6.1 zeigt die einzelnen Teilschritte in der Übersicht. Nach dieser kurzen Einleitung und Übersicht gehen wir jetzt auf diese einzelnen Teilschritte des
Prozesses und die zugehörigen inhaltlichen Fragestellungen im Detail ein.
6.1 Initiierung des Informationssicherheitsprozesses
Mit der Initiierung des Informationssicherheitsprozesses wird der Grundstein
zum Aufbau des ISMS nach BSI IT-GS gelegt. Alles beginnt mit der Übernahme
der Verantwortung durch die Leitungsebene. Diese ergibt sich schon allein daraus,
dass die Leitungsebene die Verantwortung für die ordnungsgemäße Funktion
der Geschäftsbereiche einer Organisation hat. Dies kann sich unter Umständen
auch aus gesetzlichen Regelungen oder Branchenvereinbarungen ergeben. Da die
Geschäftsprozesse einer modernen Organisation in der Regel nicht mehr ohne den
Einsatz von IT vorstellbar sind, kommt also auch der ordnungsgemäß funktionierenden IT und damit auch der Informationssicherheit eine besondere Bedeutung
zu.
Grundstein des ISMS
Kein Prozess ohne IT
Übernahme der Verantwortung durch die Leitungsebene
Durch die Übernahme der Verantwortung werden -wie auch in den vorhergehenden Kapiteln erläutert- im wesentlichen zwei Ziele erreicht: Die Sicherstellung
der Ressourcen und die Unterstützung im Konfliktfall. Die Leitungsebene kann
dabei die sich ergebenden Aufgaben bzw. Teilaufgaben delegieren, die Gesamtverantwortung, dass diese ordnungsgemäß erledigt werden, verbleibt jedoch bei
ihr.
Zielsetzung
Häufig ist der Leitungsebene nicht bekannt, dass sie -neben den üblichen geschäftlichen Aktivitäten- auch die Verantwortung für die Prävention und Behandlung von
Risiken im Bereich der Informationssicherheit hat. Daher sollte eine rechtzeitige
Information über die Risiken in diesem Bereich gegeben werden. Dazu gehören
Informationen über
Informationsdefizit der
Leitungsebene
• die Sicherheitsrisiken der Organisation,
• die Auswirkungen von Sicherheitsrisiken auf kritische Geschäftsprozesse
und
• die Anforderungen, die sich im Bereich IS aus den gesetzlichen, regulatorischen und vertraglichen Vorgaben ergeben sowie
• die für die jeweilige Branche üblichen Vorgehensweisen im Bereich der IS
und
• die Vorteile, die sich aus der Umsetzung dieser Vorgaben ergeben können.
Die Leitungsebene einer Organisation initiiert, steuert und kontrolliert zwar den
gesamten IS-Prozess, eine Beteiligung aller Beschäftigten der Organisation ist aber
Voraussetzung für den Erfolg der gesamten Maßnahme. Idealerweise sollten im
gesamten Prozess die folgenden Prinzipien eingehalten werden:
• Die Leitungsebene initiiert den Prozess der IS,
Erfolgsfaktoren
Seite 88
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
• die Gesamtverantwortung verbleibt bei der Leitungsebene,
• die Umsetzung der IS wird durch die Leitungsebene aktiv unterstützt,
• die Leitungsebene benennt für die IS zuständige Mitarbeiter und
• die Leitungsebene übernimmt im Bereich IS eine Vorbildfunktion.
Konzeption und Planung des IS-Prozesses
Wie sehen die konkreten Rahmenbedingungen aus?
Interne Aspekte
In diesem Abschnitt gehen wir nun auf die Aspekte der Konzeption des ISProzesses ein. Grundlage für ein erfolgreiches IS-Management ist die Kenntnis
der Rahmenbedingungen, der die Organisation unterliegt; dabei sind sowohl interne wie auch externe Einflüsse zu berücksichtigen. Auch für den Bereich der IS
bilden die grundsätzlichen Ziele und Aufgaben der Organisation die Grundlage.
Letztendlich lassen sich über die Beschreibung der Prozesse einer Organisation
Aussagen über die Auswirkungen von Sicherheitsvorfällen ableiten. Daher sollte
eine Organisation ihre wichtigsten Prozesse und Aufgaben ermitteln, um dann
darauf aufbauend den Bedarf an IS ermitteln zu können.
Bei der Analyse der internen Prozesse werden die folgenden Fragen adressiert:
• Welche Prozesse gibt es in der Organisation und wie hängen diese mit den
Zielen der Organisation zusammen?
• Welche dieser Prozesse hängen von einer funktionierenden IT ab?
• Welche Informationen werden von diesen Prozessen verarbeitet?
• Wie sieht es mit den Anforderungen bzgl. der Vertraulichkeit, Integrität und
Verfügbarkeit für (diese) Informationen aus?
Externe Aspekte
Auch externe Aspekte spielen eine Rolle, bspw. durch gesetzliche Rahmenbedingungen und branchenspezifischen Standards, Umwelteinflüsse oder auch Anforderungen von Geschäftspartnern.
Formulierung der IS-Ziele
Bereits zu Beginn des IS-Prozesses müssen die Ziele der IS festgelegt werden. Dabei
ist hohe Sorgfalt geboten, damit nicht IS-Ansätze entwickelt werden, die nicht zu
den Zielen der Organisation passen - und damit ggf. nicht vertretbare Risiken
eingegangen oder Ressourcen ineffizient eingesetzt werden. Die (allgemeinen)
IS-Ziele werden daher zunächst aus den grundsätzlichen Zielen der Organisation abgeleitet und im späteren Verlauf zu konkreten IS-Anforderungen weiter
entwickelt. Beispiele für Sicherheitsziele allgemeiner Natur sind eine hohe Verlässlichkeit des Handelns der Organisation, Gewährleistung des guten Rufs, Erhaltung
der investierten Werte, Sicherung der Informationen, Gewährleistung gesetzlicher Vorgaben, Reduzierung der Risiken und auch Sicherstellung der Kontinuität.
Diese Festlegung (allgemeiner) Sicherheitsziele stellt jedoch nur den Anfang des
IS-Prozesses dar. Im weiteren Verlauf werden daraus -auch auf Basis der Anforderungen an die in den einzelnen Prozessen notwendige Vertraulichkeit, Integrität
und Verfügbarkeit- konkrete Maßnahmen abgeleitet und die zur Umsetzung notwendigen Ressourcen und Aktivitäten von der Leitungsebene bewilligt.
Beispiele für allgemeine Sicherheitsziele
Festlegung ist
nur der Anfang
Bestimmung des
angemessenen Sicherheitsniveaus
Zur besseren Verständlichkeit der IS-Ziele kann es hilfreich sein, die Anforderungen einzelner Prozesse gesondert zu betrachten und das angemessene Sicherheitsniveau festzulegen. Die daraus gewonnenen Informationen können im späteren
Verlauf bei der detaillierten Sicherheitskonzeption hilfreich sein. Allerdings handelt es sich bisher nur um eine grobe Richtung und nicht um eine detaillierte
Schutzbedarfsfeststellung, die im späteren Verlauf noch relevant sein wird.
6.1 Initiierung des Informationssicherheitsprozesses
Seite 89
Mögliche, aber nicht zwingend bedarfsgerechte Kriterien für die Einordnung in
das Niveau “sehr hoch”, “hoch” bzw. “normal” sind bspw. die folgenden:
1. Niveau “sehr hoch”
Ein Ausfall der IT führt zum Zusammenbruch der Organisation:
Niveau “Sehr hoch”
• Vertraulichkeit muss unbedingt gewährleistet sein.
• Integrität muss unbedingt gewährleistet sein.
• Ausfallzeiten sind nicht akzeptabel.
• Durch Datenlecks kann das Leben der betroffenen Personen gefährdet
sein.
2. Niveau “hoch”
Schäden haben erhebliche Beeinträchtigungen der Organisation zur Folge:
Niveau “Hoch”
• Vertraulichkeit muss in hohem Maße gewährleistet werden.
• Datenveränderungen und Verarbeitungsfehler müssen erkennbar sein.
• Kurze Ausfallzeiten sind tolerierbar.
• Durch Datenlecks kann die wirtschaftliche Existenz der betroffenen
Personen gefährdet sein.
3. Niveau “normal”
Schäden haben Beeinträchtigungen der Organisation zur Folge:
Niveau “Normal”
• Schutz von internen Informationen muss gewährleistet sein.
• Kleine Fehler können toleriert werden, müssen aber erkennbar sein,
wenn sie die Aufgabenerfüllung erheblich beeinträchtigen.
• Ausfallzeiten, die zu Terminüberschreitungen führen, sind nicht zulässig.
• Durch Datenlecks kann die gesellschaftliche Stellung der betroffenen
Personen beeinträchtigt werden.
Da bei der Bestimmung des angemessenen Sicherheitsniveaus auch die Aufwände
für die Umsetzung der sich daraus ergebenden Anforderungen deutlich werden,
sollte bei der Festlegung des angemessenen Schutzbedarfs ein Vertreter der Leitungsebene eingebunden sein. Die Hinzuziehung eines externen IS-Experten kann
zudem sicher stellen, dass die Festlegung “neutral” und angemessen im Sinne des
Prozesses erfolgt.
Einbeziehung der
Leitungsebene
Erstellung einer Leitlinie
Im nächsten Schritt wird nun die Leitlinie zur IS erstellt. Sie beschreibt allgemeinverständlich, warum und wie die IS innerhalb der Organisation umgesetzt werden
soll. Durch sie wird dokumentiert, welches Sicherheitsniveau die Organisation
anstrebt und welche strategische Position die Leitungsebene bzgl. der Umsetzung
einnimmt. Bei der Erstellung der Leitlinie sollten möglichst frühzeitig viele Bereiche der Organisation eingebunden werden. Dabei empfiehlt es sich, das Fachwissen
der einzelnen Bereiche mit einzubinden, um die Akzeptanz der IS-Leitlinie zu
stärken.
Leitlinie als Orientierung
Seite 90
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
IS-Entwicklungsgruppe
Aspekte der IS-Leitlinie
Dabei bietet es sich an, eine Arbeitsgruppe zur Entwicklung der IS-Leitlinie
ins Leben zu rufen. Hat die Organisation das Thema IS-Management bereits erkannt und ein IS-Managementteam aufgebaut, kann dieses auch die Rolle der
IS-Entwicklungsgruppe einnehmen. Steht die Organisation aber erst am Anfang, so kann das neu zu gründende IS-Entwicklungsteam später in das ISManagementteam überführt werden. Wichtige Mitglieder in diesem Team sind
Vertreter der IT-Anwender, Vertreter des IT-Betriebs und auch Vertreter der Leitungsebene.
Die Leitlinie sollte möglichst kurz, aber dennoch unmissverständlich formuliert
werden. Wichtige Aspekte sind
• der Stellenwert der IS und die Bedeutung der IT für die Organisation,
• der Bezug der IS-Ziele zu den Zielen der Organisation,
• die Sicherheitsziele und Kernelemente der IS-Strategie,
• die Übernahme der Verantwortung durch die Leitungsebene, verbunden mit
der Zusage, dass die IS-Leitlinie von ihr durchgesetzt und die Umsetzung
kontrolliert wird und
• die Beschreibung der für die Umsetzung des IS-Prozesses erforderlichen
Organisationsstruktur.
Geltungsbereich
der IS-Leitlinie
Ein wichtiges Merkmal der IS-Leitlinie ist ihr Geltungsbereich; dieser reicht von
kleinen Organisationseinheiten bis hin zur gesamten Organisation. Häufig handelt
es sich um einen gestuften Prozess, bei dem man den Geltungsbereich schrittweise
von einer exemplarischen Abteilung auf die gesamte Organisation ausweitet.
Bekanntmachung
der IS-Leitlinie
Die beste IS-Leitlinie ist allerdings nutz- und wirkungslos, wenn sie nimenad
kennt. Daher gehört zum Prozess der Entwicklung einer IS-Leitlinie auch deren
Bekanntmachung. Im Zuge der Bekanntmachung unterstreicht die Leitungsebene
gleichzeitig nochmals die Bedeutung der IS für die Organisation, insbesondere
durch ihre formelle Zustimmung, bspw. durch Unterschrift auf der schriftlichen
Fassung. Die Leitlinie sollte innerhalb der Organisation einfach zugreifbar sein, alle
Mitarbeiter sollten dadurch die Inhalte der IS-Leitlinie kennen. Neuen Mitarbeitern
muss sie jedoch erläutert werden, bevor diese Zugang zu den IT-Systeme bzw.
Zugriff auf die Daten erhalten.
Aktualisierung
der IS-Leitlinie
Damit die IS-Leitlinie nicht veraltet, ist eine regelmäßige Überprüfung notwendig.
Erst dadurch wird sicher gestellt, dass die IS-Leitlinie an geänderte Ziele der
Organisation, an geänderte IT bzw. IT-Verfahren oder bspw. an eine geänderte
Organisationsstruktur angepasst werden kann. Dadurch entwickelt sich die ISLeitlinie mit der Organisation weiter: die Ziele der IS bleiben mit den Zielen der
Organisation in Übereinstimmung.
Die Organisation des IS-Prozesses
Organisationsweiter IS-Prozess
Randbedingungen
für den IS-Prozess
Das angestrebte Sicherheitsniveau kann in der Regel nur erricht werden, wenn der
IS-Prozess organisationsweit umgesetzt wird. Dieser übergreifende Charakter des
IS-Prozesses macht es dann auch erforderlich, innerhalb der Organisation Rollen
mit entsprechenden Aufgaben festzulegen. Diese Rollen sind dann entsprechend
qualifizierten Mitarbeitern zu übertragen und von diesen auszufüllen. Nur durch
diese IS-Organisation lässt sich (auf Dauer) gewährleisten, dass alle wichtigen
Aufgaben im Bereich der IS effizient und dauerhaft erledigt werden. Wieviele
Personen beteiligt sind und ob bspw. einer Person mehrere Rollen zugeordnet
6.1 Initiierung des Informationssicherheitsprozesses
Seite 91
werden (müssen), hängt ganz von der Größe und Art der Organisation ab. In
jedem Fall sollte ein zentraler Ansprechpartner, der IS-Beauftragte, benannt sein,
der die Koordination, die Verwaltung und die Kommunikation des IS-Prozesses
übernimmt.
Damit die beteiligten Personen möglichst direkten Zugang zur Leitungsebene
haben -etwa um Risiken unverfälscht kommunizieren oder auch Bewilligungen für
Ressourcen neutral einholen zu können- sollten die Personen in einer Stabsstelle
organisiert sein, die der Leitungsebene direkt unterstellt ist. Innerhalb der Leitungsebene sollte ein Manager benannt sein, der direkter Ansprechpartner für die
IS-Stabsstelle ist. Beim Aufbau der IS-Organisation und der Definition der Rollen
ist zu berücksichtigen, dass die Gesamtverantwortung für die IS bei der Leitungsebene liegt, (mindestens) eine Person zu benennen ist, die den IS-Prozess fördert
und jeder einzelne Mitarbeiter der Organisation gleichermaßen für die Aufrechterhaltung der IS an seinem Arbeitsplatz und in seiner Umgebung verantwortlich
ist.
Zugang zur
Leitungsebene
Da sich das IS-Management auf nahezu alle Bereiche einer Organisation direkt oder
indirekt auswirkt, bietet es sich an, es in die organisationseigenen Prozessen zu
integrieren. Nur dadurch kann letztendlich sicher gestellt werden, dass es nicht nur
bei einzelnen Maßnahmen, sondern auch bei allen strategischen Entscheidungen
entsprechend berücksichtigt wird. Dies gilt insbesondere für Bereiche, die keinen
direkten Bezug zur IT haben oder ausgelagert sind. Existiert in der Organisation
bereits ein übergreifendes Risikomanagement, sollten die IS-Risiken als weitere
Risiken berücksichtigt und in das bereits existierende Management integriert
werden.
Integration in die organisationseigenen
Abläufe
Der genaue Aufbau der IS-Organisation hängt natürlich auch von der Größe einer
Organisation und ihrem Tätigkeitsbereich ab. Während bei einer großen Organisation Koordinierungsausschüsse für die Themen IT und IS, sowie eine Gliederung
der Aufgaben in den Bereichen Gesamtorganisation, Bereichsorganisation und
Projektorganisation notwendig und sinnvoll sind, werden diese Funktionsbereiche
bei einer kleinen Organisation allein aufgrund der verfügbaren Mitarbeiter zusammengefasst werden. Auch bei größeren Organisationen besteht keine Verpflichtung
und unbedingte Notwendigkeit, die zentralen Rollen auf unterschiedliche Personen zu verteilen. Je nach Organisationskultur kann es sogar hilfreich sein, mehrere
ausgewählte Rollen in ein und derselben Person zu vereinen. Die Planung ist
aber in jedem Fall so durchzuführen, dass die gesteckten IS-Ziele auch tatsächlich
erreicht werden können.
Aufbau der
IS-Organisation
Die zentralen Rollen der IS-Organisation, vor allem der IT-Sicherheitsbeauftragte
und das IS-Management-Team, müssen klar definierte Aufgaben, Verantwortung
und Kompetenzen haben, die von der Leitungsebene festgelegt werden. Zudem
müssen die mit diesen Rollen betrauten Personen an allen relevanten Entscheidungen der Organisation beteiligt werden, damit sie ihrer Aufgabe überhaupt
nachkommen können. Zudem muss durch die Aufhängung in der IS-Organisation
sicher gestellt werden, dass eine Kommunikation untereinander möglich ist.
Aufgaben, Verantwortung
und Kompetenzen in IS
Organisation
Zu den wichtigen Rollen im Rahmen der IS-Organisation zählen:
Wichtige Rollen
• Der IS-Beauftragte, der für alle belange der IS in der Organisation zuständig
ist. Er sollte daher die notwendigen Kenntnisse und Fähigkeiten mitbringen,
insbesondere in den Gebieten IT und IS, sowie dem Projekt- und Konfliktmanagement. Die Position des IS-Beauftragten sollte möglichst als Stabstelle
ausgestaltet sein und dadurch entsprechend unabhängig sein, so dass auch
“unliebsame” Entscheidungen getroffen werden können.
Grundregeln der
IS-Organisation
Risikomanagement
Unterschiedliche Organisationen bedingen
eine unterschiedliche
IS-Organisation
IS-Beauftragte
Seite 92
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
IS-Managementteam
• Das IS-Managementteam, das den IS-Beauftragten bei übergreifenden Maßnahmen unterstützt. Die Mitglieder des Teams sollten Kenntnisse im Bereich der IT und IS mitbringen und die unterschiedlichen Aufgabenbereiche
der Organisation wiederspiegeln. Vertreten sein sollten mindestens der ISBeauftragte, ein Anwendervertreter und ein IT-Verantwortlicher, sowie ggf.
der Datenschutzbeauftragte der Organisation.
Weitere Beauftragte
• Ggf. weitere Beauftrage, die auf Bereichs- und/oder Projektebene agieren
und den IS-Beauftragten bei seiner Tätigkeit unterstützen und dazu fundierte und detaillierte Kenntnisse in ihren Bereichen mitbringen.
IT-Koordinierungsausschuss
• Der IT-Koordinierungsausschuss, der meist nur bei Bedarf einberufen wird
und die Zusammenarbeit zwischen dem IS-Bereich, Anwendern und ITVerantwortlichen koordiniert.
Datenschutzbeauftragte
• Der Datenschutzbeauftragte, der sich um alle datenschutzrechtlichen Belange innerhalb der Organisation kümmert. Er muss über die erforderlich
Fachkompetenz verfügen und ist an allen datenschutzrechtlichen Vorgängen
(frühzeitig) zu beteiligen.
Bereitstellung der Ressourcen für die IS
Steuerung von
Prozessen und Kosten
Den Kosten, die durch Schäden entstehen können, stehen immer die Kosten für die
Maßnahmen zur Vermeidung dieser Schäden gegenüber. Ein effektives Risikomanagement hilft dabei, diese Kosten zu steuern und sorgt dafür, dass die Kosten für
die Maßnahmen die Kosten durch Schäden nicht übersteigen und die Maßnahmen
damit wirtschaftlich bleiben.
Kosteneffizienz
Dabei spielt der Kosten-Nutzen-Aspekt eine wichtige Rolle. Insbesondere ist zu
bedenken, dass absolute Sicherheit nicht bezahlbar ist, weil die Kosten für die
Sicherheit weiter erhöhende Schutzmaßnahmen immer mehr steigen, je mehr Maßnahmen man bereits umgesetzt hat.
100%
sehr hoch
hoch
normal
Sicherheit
Abb. 6.2: Schematische Darstellung
der Kosten-NutzenRelation im Bereich der
IS (angelehnt an [2]).
Grundschutz
erhöht
maximal
Aufwand
Daher tragen gerade einfache und kostengünstige organisatorische Maßnahmen zu
einer erheblichen Verbesserung des Sicherheitsniveaus bei, während sehr spezifische technische Maßnahmen sehr teuer sind und die Sicherheit oft nur marginal verbessern. Zudem lösen rein technische Maßnahmen allein keine Probleme, sondern
6.1 Initiierung des Informationssicherheitsprozesses
Seite 93
müssen immer im Kontext von personellen und organisatorischen Maßnahmen
betrachtet werden.
Zu den Ressourcen im Berich der IS zählen auch die für die IS-Organisation.
Dazu sind etwa die Aufwendungen für den IS-Beauftragten und bei größeren
Organisationen auch die des IS-Managementteams zu rechnen. Neben den reinen
Personalkosten sind aber ggf. auch weitere Kosten, etwa durch externe Experten,
zu berücksichtigen. Darüber hinaus sind auch Ressourcen für die Überprüfung
der IS einzuplanen. Durch diese wird zum einen sicher gestellt, dass die Wirksamkeit und Eignung von getroffenen Sicherheitsmaßnahmen gegeben ist, zum
anderen können die Maßnahmen auch direkt auf ihre Wirtschaftlichkeit hin untersucht werden. Dadurch ergibt sich auch die Chance, frühzeitig Alternativen
zu finden, wenn die eingesetzten oder geplanten Maßnahmen unwirtschaftlich
erscheinen. Nicht zuletzt fallen auch im Bereich des IT-Betriebs Kosten an, denn
ein ordnungsgemäßer IT-Betrieb ist die Grundvoraussetzung für einen sicheren
IT-Betrieb. Daher müssen ausreichend Ressourcen bereit gestellt werden, damit
typische Fehlerquellen wie überlastete Administratoren oder eine unstrukturierte
IT-Landschaft vermieden werden.
Ressourcen für die
IS-Organisation
Ressourcen für die
Überprüfung der IS
Ressourcen für den
IT-Betrieb
Einbindung aller Mitarbeiter in den IS-Prozess
Das Thema IS betrifft alle Mitarbeiter einer Organisation - dies gilt ohne Ausnahme für die Leitungsebene und die Mitarbeiter in den einzelnen Abteilungen.
Die Sensibilisierung jedes einzelnen Mitarbeiters ist ein wichtiger Baustein im
Gesamtkonzept der IS, denn ohne entsprechende Beteiligung der Mitarbeiter werden Investitionen in technische Maßnahmen sehr schnell zu einer Fehlinvestition.
Zudem beeinflusst auch das Arbeitsklima, die (in der Organisation gelebten) Wertvorstellungen und das Engagement der Mitarbeiter entscheidend die IS.
IS geht alle an
Daher müssen bei allen Mitarbeitern, internen und externen, vom Beginn der
Tätigkeit bis zum Ausscheiden aus der Organisation die Aspekte der IS mit berücksichtigt werden. Bei der Schulung und Sensibilisierung der Mitarbeiter sind
entsprechende Schulungskonzepte zu erstellen, die die unterschiedlichen Zielgruppen und Schulungsinhalte berücksichtigen und -soweit vorhanden- in das
bereits bestehenden Schulungskonzept der übrigen Schulungsmaßnahmen der Organisation integriert werden. Zudem muss sicher gestellt sein, dass alle Mitarbeiter
entsprechend ihrer Position und ihrem Status in der Organisation berücksichtigt
werden. So ist insbesondere bei Neueinstellungen und Mitarbeitern, die ihre Position gewechselt haben, darauf zu achten, dass sie alle für ihre Tätigkeit relevanten
Sicherheitsaspekte vermittelt bekommen. Aber auch alle “erfahrenen” Mitarbeiter
sollten regelmäßig Schulungen erhalten, damit sie für die IS sensibilisiert werden
und ihr Wissen im Bereich der IS aktuell bleibt. Die Sensibilisierung kann zudem
dadurch gesteigert werden, dass die Organisation bspw. ein Sicherheitsforum einrichtet, in dem die Mitarbeiter Tipps zur IS bekommen, in dem aber auch über
akute Sicherheitsvorfälle und ihre Lösungen berichtet wird.
Schulungskonzepte und
-maßnahmen
Die Mitarbeiter sind vor allem über den Sinn und Zweck von IS-Maßnahmen
zu informieren. Dies gilt insbesondere dann, wenn die Maßnahmen Komfortoder Funktionseinbußen zur Folge haben und dadurch ggf. auch ein “Mehraufwand” bei den Mitarbeitern notwendig wird. Zudem können IS-Maßnahmen auch
mitbestimmungspflichtig sein, was eine Einbindung der Mitarbeiter bzw. der
Mitarbeitervertretung unabdingbar macht. Eine frühe Einbindung und ggf. Mitgestaltungsmöglichkeit bei der Auswahl und Implementierung von IS-Maßnahmen
wirkt sich zudem förderlich auf die Akzeptant von Sicherheitsmaßnahmen aus.
Einbindung der Mitarbeiter
Alle Mitarbeiter
berücksichtigen
Sensibilisierung
Seite 94
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
Festlegung von
Meldewegen
Auch nach Durchführung der konkreten Schulungsmaßnahmen dürfen die Mitarbeiter den Bezug zur IS nicht verlieren. Daher sind Ansprechpartner festzulegen
und den Mitarbeitern bekannt zu geben, damit diese wissen, an wen sie sich bei
Fragen im Bereich der IS wenden können. Darüber hinaus sind auch definierte
Meldewege notwendig, die sicher stellen, dass jeder Mitarbeiter bei einem Verdacht
auf einen Sicherheitsvorfall weiß, wen er informieren muss und wie er sich zu
verhalten hat.
Aufgabenwechsel und Weggang
von Mitarbeitern
Gerade bei einem Aufgabenwechsel oder Weggang von Mitarbeitern ergeben sich
Risiken im Bereich der IS, etwa durch geänderte oder vergessene Zutritts-, Zugangsund Zugriffsberechtigungen. Daher sind diese Vorgänge durch entsprechende
Sicherheitsmaßnahmen zu begleiten und alle beteiligten Stellen in geeigneter Art
und Weise zu informieren. Klar definierte Prozesse, etwa in Form von Checklisten bzgl. des Berechtigungsmanagements, können helfen, Sicherheitsrisiken zu
vermeiden.
6.2 Erstellung einer Sicherheitskonzeption
Schritt für Schritt
zum IS-Konzept
In diesem Abschnitt skizzieren wir nun die einzelnen Schritte, die notwendig
sind, um die Sicherheitskonzeption für die Organisation bzw. den ausgewählten
Teilbereich der Organisation zu erstellen. Für die Details verweisen wir nochmals
auf den BSI-Standard 100-2 [2] und konzentrieren uns im Folgenden vielmehr auf
eine übersichtliche Zusammenfassung der notwendigen Aspekte.
Methodik des ITGrundschutzes
Im Rahmen des IT-GS-Ansatzes sind bereits die Bedrohungen ermittelt und entsprechende Eintrittswahrscheinlichkeiten bewertet und aufbauend darauf die Schutzmaßnahmen abgeleitet worden. Daher sind diese Teilschritte -im Gegensatz zu
einer herkömmlichen Risikoanalyse- im Rahmen der IT-GS-Vorgehensweise nicht
mehr erforderlich. Die Analyse reduziert sich dadurch auf einen Soll-Ist-Vergleich,
der die bestehenden Anforderungen (nach IT-GS) mit den bereits umgesetzten
Maßnahmen vergleicht. In diesem Rahmen als fehlend oder nur unzureichend
umgesetzt ermittelte Maßnahmen müssen durch die empfohlenen Maßnahmen
ergänzt werden. Erst bei einem höheren Schutzbedarf muss eine ergänzende Sicherheitsanalyse durchgeführt werden, bei der die Kosten-Nutzen-Aspekte zu beachten
sind. Im BSI-Standard 100-3 “Risikoanalyse auf Basis von IT-Grundschutz” [3]
wird dazu eine im Vergleich zur herkömmlichen Risikoanalyse stark vereinfachte
Vorgehensweise vorgestellt.
Höherer Schutzbedarf
Definition des Geltungsbereichs
Teilbereiche
als Startpunkt
Eindeutige Abgrenzung
Da die Umsetzung der Anforderungen nach BSI IT-GS für die Organisation insgesamt ein sehr großer Schritt ist, kann es empfehlenswert sein, diesen Prozess
in viele kleine Schritte zu zerlegen und die Umsetzung zunächst nur in einem
Teilbereich durchzuführen. Die Festlegung des Geltungsbereiches, in dem die
Umsetzung von BSI IT-GS erfolgen soll und der auch als Informationsverbund
bezeichnet wird, stellt damit den ersten Schritt dar. Dabei sind vor allem die beiden
folgenden Aspekte relevant: Die Festlegung, welche Teile der Organisation und
welche Prozesse der Geltungsbereich beinhaltet, wobei neben den technischen
auch die organisatorischen Aspekte berücksichtigt werden sollten. Darüber hinaus
ist auch eine eindeutige Abgrenzung des Geltungsbereichs und Beschreibung der
Schnittstellen zu Externen erforderlich, damit es nicht zu Problemen im Verlauf
der Sicherheitskonzeption kommt, etwa weil Schnittstellen zu Externen nicht klar
genug definiert sind.
6.3 Schutzbedarfsfeststellung
Seite 95
Strukturanalyse
Ohne eine detaillierte Analyse und Dokumentation der Prozesse der Organisation, des Zusammenspiels der Prozesse und der bestehenden IT ist die Erstellung
der Sicherheitskonzeption und die Anwendung der IT-GS-Kataloge nicht sinnvoll.
Dabei bietet sich die Netzwerktopologie als Ausgangsbasis für die weitere Analyse der technischen Aspekte an. Dabei sind die betriebenen Anwendungen, die
personellen Rahmenbedingungen, die eingesetzten vernetzt und nicht-vernetzt
betriebenen IT-Systeme, die Kommunikationsverbindungen nach innen und außen
sowie die bereits vorhandene Infrastruktur zu berücksichtigen.
Vom Netzwerk zum Raum
Die Strukturanalyse liefert eine wichtige Grundlage für die Erstellung der Sicherheitskonzeption. Sie erfasst in der Regel eine Vielzahl von Einzelobjekten, muss
aber dennoch übersichtlich bleiben. Dies kann erreicht werden, indem a) gleichartiger Objekte zusammengefasst und b) jeweils Typ und Anzahl der gleichartiger
Objekte dokumentiert werden. Am Beispiel von PC-Clients wird ein solches Vorgehen sofort verständlich, denn es würde keine Zusatzinformation liefern, wenn
hunderte gleichwertiger PC-Clients einzeln aufgenommen würden.
Zusammenfassen von
von Objekten
Ausgehend von den Prozessen bzw. Aufgaben des bzw. aller Teilbereiche des Geltungsbereichs müssen nun die dabei genutzten Anwendungen und verarbeiteten
Informationen identifiziert werden. Dabei soll eine möglichst hohe Transparenz
und Effizienz erreicht werden, die Granularität kann sich zudem auch an den
IT-GS-Bausteinen orientieren.
Erfassung der Anwendungen und der verarbeiteten Informationen
Nachdem die Anwendungen und die von ihnen verarbeiteten Daten identifiziert
wurden, erfolgt im nächsten Schritt die weitere technische Analyse. Dazu stellen
die Netzwerkpläne der Organisation einen geeigneten Ausgangspunkt dar, da aus
inen auch Rückschlüsse auf die Informationsflüsse innerhalb und außerhalb der
Organisation gezogen werden können.
Erhebung der Netzwerktopologien
Eine wesentliche Grundlage für die Schutzbedarfsfeststellung und Modellierung
des IT-Verbundes ist die Erfassung aller IT-Systeme, also aller PC-Clients und Server, am Netzwerk angeschlossenen Komponenten und weiteren (nicht-vernetzten)
Komponenten, bspw. auch die der TK-Anlage. Die Erfassung sollte dabei in einer
möglichst übersichtlichen Form erfolgen.
Erhebung der IT-Systeme
Da die Ausführung von Prozessen der Organisation und die Verarbeitung von
Informationen nicht nur auf IT-Systemen erfolgt, sondern in der räumlichen Infrastruktur stattfinden, sind auch die Räumlichkeiten -also Räume, Gebäude und ggf.
auch Liegenschaften der Organisation- zu erfassen. Dies geschieht in Ergänzung
der bereits bei der Erhebung der IT-Systeme erfassten Aufstellorte.
Erhebung der Räume
Anwendungen und
IT-Systeme
6.3 Schutzbedarfsfeststellung
Im Rahmen der Schutzbedarfsfeststellung wird nun ermittelt, welchen Schutzbedarf die einzelnen Objekte des Informationsverbundes bzgl. der Vertraulichkeit,
Integrität und Verfügbarkeit haben. Der Schutzbedarf hängt dabei immer von den
möglichen Schäden durch eine Beeinträchtigung der Anwendungen und Prozesse
der Organisation ab.
Schäden bestimmen den
Schutzbedarf
Bei der Beschreibung und Beurteilung des Schutzbedarfs kommen naturgemäß nur
qualitative Aussagen in Betracht; der IT-GS unterscheidet dabei die Kategorien
Definition der Schutzbedarfskategorien
Seite 96
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
• “sehr hoch” - Schadensauswirkungen sind existenzbedrohend
und katastrophal,
• “hoch” - Schadensauswirkungen sind beträchtlich und
• “normal” - Schadensauswirkungen sind begrenzt und überschaubar.
Die genaue Zuordnung von Schadensfällen zu den einzelnen Kategorien hängt
dabei auch stark von der Ausprägung der Organisation ab. Zudem sollte man
versuchen, Grenzen für die einzelnen Schadensszenarien festzulegen, um die
Schutzbedarfskategorien voneinander abzugrenzen zu können.
Schutzbedarfsfeststellung für Anwendungen
Die Schäden und Folgeschäden, die sich aus einer möglichen Verletzung der Vertraulichkeit, Integrität oder Verfügbarkeit von Anwendungen bzw. den darin verarbeiteten Informationen ergeben, bestimmen auch den Schutzbedarf, der für
die jeweilige Anwendung notwendig ist. In die dazu notwendige Analyse möglicher Schäden sollte dabei immer die Verantwortlichen mit einbezogen werden,
da diese am besten abschätzen können, welche Schäden und insbesondere auch
Folgeschäden überhaupt entstehen können.
Schutzbedarfsfeststellung für IT-Systeme
Nachdem eine Liste der Anwendungen und dem für sie notwendigen Schutzbedarf vorliegt, können nun die IT-Systeme kategorisiert werden. Dazu wird pro
IT-System betrachtet, welche Anwendungen davon ausgeführt werden und in Abhängigkeit des Schutzbedarfs der Anwendung der Schutzbedarf des IT-Systems
festgelegt. Werden auf einem IT-System mehrere Anwendungen unterschiedlichen
Schutzbedarfs ausgeführt, so kommt das Maximumsprinzip zum Tragen. Dabei
bestimmen die Anwendung bzw. die Gruppe von Anwendungen mit den schwerwiegendsten Auswirkungen den Schutzbedarf des IT-Systems. Bei der Betrachtung
der möglichen Schäden muss mit berücksichtigt werden, dass ein Schaden an
einer Anwendung 1 auch eine andere Anwendung 2 beeinträchtigen kann, bspw.
weil diese dann nicht mehr die benötigten (Input-)Daten zur Verfügung stehen.
Dann muss der Schutzbedarf -falls dieser bei der nachfolgenden Anwendung 2
höher ist- auf Anwendung 1 übertragen werden. Werden mehrere Anwendungen
auf einem IT-System betrachtet, so muss noch berücksichtigt werden, dass sich
-bedingt durch den Kumulationseffekt- auch mehrere kleinere Schäden zu einem
größeren Schaden summieren können und daher der Schutzbedarf des IT-Systems
höher anzusetzen ist. Umgekehrt kann auch ein Verteilungseffekt eintreten, wenn
eine Anwendung, die insgesamt einen hohen Schutzbedarf besitzt, diesen nicht
auf ein IT-System überträgt, weil dort nur unwesentliche Teile der Anwendung
laufen.
Maximumsprinzip
Berücksichtigung
von Abhängigkeiten
Kumulation- und
Verteilungseffekte
Schutzbedarfsfeststellung für Räume
Ähnlich zur Vorgehensweise bei der Ermittlung des Schutzbedarfs der IT-Systeme,
wird der Schutzbedarf der Räumlichkeiten aus dem der Anwendungen und ITSysteme -ggf. unter Berücksichtigung von Abhängigkeiten, des Maximumsprinzips
sowie etwaiger Kumulations- und Verteilungseffekte abgeleitet.
Schutzbedarfsfeststellung für Kommunikationsverbindungen
Nach der Schutzbedarfsfeststellung für die Anwendungen, IT-Systeme und Räume
wird nun der Schutzbedarf der Kommunikationsverbindungen ermittelt. Eine
typische Vorgehensweise zu diesem Teilprozess beinhaltet dabei die folgenden
Zusammenfassung
Auf Grundlage der ermittelten Schutzbedarfe können nun die weiteren Schritte
der Sicherheitskonzeption erfolgen. Bezüglich der Schutzbedarfskategorien wird
dabei im Rahmen der Umsetzung von BSI IT-GS von folgendem Sachverhalt ausgegangen:
• Schutzbedarfskategorie “normal”: Die Maßnahmen nach IT-GS sind ausreichend.
6.3 Schutzbedarfsfeststellung
Seite 97
• Schutzbedarfskategorie “hoch”: Die Maßnahmen nach IT-GS bieten einen
Basisschutz, müssen aber ggf. durch die in der erweiterten Sicherheitsanalyse ermittelten Maßnahmen ergänzt werden.
• Schutzbedarfskategorie “sehr hoch”: Die Maßnahmen nach IT-GS bieten
einen Basisschutz, müssen aber durch weitere Maßnahmen ergänzt werden,
die durch eine individuelle, ergänzende Sicherheitsanalyse zu ermitteln
sind.
Um zu verhindern, dass einzelne, aber stark vernetzte Anwendungen mit hohem
Schutzbedarf durch Anwendung des Maximumsprinzips dazu führen, dass alle
Anwendungen den Anforderungen für hohen Schutzbedarf genügen müssen, ist
zu prüfen, ob Sicherheitszonen gebildet werden können.
Bildung von Sicherheitszonen
Auswahl und Anpassung von Maßnahmen
Nach erfolgter Schutzbedarfsfeststellung besteht der nächste Schritt darin, den
IT-Verbund mit Hilfe der Bausteine des IT-GS nachzubilden. Als Ergebnis dieser
"Modellierungërhält man ein IT-GS-Modell des IT-Verbundes, das aus unterschiedlichen, teilweise mehrfach verwendeten Bausteinen des IT-GS besteht.
Nachbilden des ITVerbundes
Die IT-GS-Kataloge bestehen aus
IT-GS-Kataloge
• Bausteinen, die für verschiedene Objekte die Gefährdungslage und Maßnahmenempfehlungen zusammenfassend darstellen, und in die logischen
Schichten “B1: Übergreifende Aspekte”, “B2: Infrastruktur”, “B3: ITSysteme”, “B4: Netze” und “B5: Anwendungen” gegliedert sind,
Bausteine
• Gefährdungskatalogen, die ausführliche Beschreibungen der Gefährdungen enthalten, die wiederum in die fünf Bereiche “G1: Höhere Gewalt”,
“G2: Organisatorische Mängel”, “G3: Menschliche Fehlhandlungen”, “G4:
Technisches Versagen” und “G5: Vorsätzliche Handlungen” gegliedert sind,
und
Gefährdungen
• Maßnahmenkataloge, die die in den Bausteinen referenzierten Sicherheitsmaßnahmen ausführlich beschreiben und in die sechs Bereiche “M1: Infrastruktur”, “M2: Organisation”, “M3: Personal”, “M4: Hard- und Software”,
“M5: Kommunikation” und “M6: Notfallvorsorge” untergliedert sind.
Maßnahmen
Basis-Sicherheitscheck
Auf Basis der Ergebnisse der vorhergehenden Schritte und auf Grundlage der
Modellierung kann nun ein Prüfplan erstellt werden, der mittels eines Soll-IstVergleichs ermittelt, welche Standard-Sicherheitsmaßnahmen nach IT-GS umgesetzt bzw. nicht ausreichend umgesetzt sind.
Erstellung eines
Prüfplans
In einem ersten Schritt müssen dazu die notwendigen Vorbereitungen getroffen
werden, wobei ein wichtiger Aspekt auf der Auswahl der entsprechenden Ansprechpartner liegt, die die notwendigen Informationen für und Entscheidungen
im Soll-Ist-Vergleich geben bzw. treffen können. In einem Interview wird dann
unter anderem beantworten, ob und ggf. in welchem Umfang die während der
Modellierung als erforderlich identifizierten Maßnahmen umgesetzt sind. Dabei
bietet es sich an, Interview-Teams zu bilden, die bspw. aus zwei Personen bestehen,
von denen eine die Befragung durchführt und die andere die Antworten notiert.
Organisatorische
Vorarbeiten
Seite 98
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
Soll-Ist-Vergleich
Nachdem die organisatorischen Vorarbeiten erledigt sind, kann mit dem eigentlichen Soll-Ist-Vergleich durch Führen der angesprochenen Interviews begonnen
werden. Dabei werden die Maßnahmen der jeweiligen Bausteine nach und nach
abgearbeitet und als Ergebnis der Umsetzungsstatus, bspw. in Form von
• “entbehrlich” - die Maßnahme ist nicht notwendig,
• “ja” - die Maßnahme wurde umgesetzt,
• “teilweise” - die Maßnahme wurde nur teilweise umgesetzt und
• “nein” - die Maßnahme wurde noch nicht umgesetzt
aufgenommen. Die Tiefe der Interviews hängt dabei vor allem vom Kenntnisstand
der Interviewpartner ab. Ist die Befragung abgeschlossen und das Ergebnis entsprechend aufbereitet, sollte dem Interviewten die Analyse übermittelt werden.
Dokumentation
der Ergebnisse
Alle Ergebnisse sind so zu dokumentieren, dass sie für alle am Prozess Beteiligten
nachvollziehbar sind und zudem als Grundlage für die weiteren Schritte, bspw.
die Umsetzung noch fehlender Sicherheitsmaßnahmen, dienen können. Da die
Erstellung der notwendigen Dokumentenhierarchie, die von unterschiedlichen
Anwender editiert werden müssen, eine durchaus umfangreiche Aufgabe ist, stellt
das BSI selbst dazu mit dem GS-Tool und den GS-Formularen entsprechende
Hilfsmittel zur Verfügung. Darüber hinaus sind auch weitere Tools verfügbar,
bspw. verinice, ein freies GS-Tool der sernet GmbH, sowie weitere kommerzielle
Werkzeuge.
Ergänzende Sicherheitsanalyse
Konkreter Schutzbedarf
bestimmt Maßnahmen
Für typische Prozesse einer Organisation, die einen normalen Schutzbedarf haben, sind die Standard-Maßnahmen ausreichend. Prozesse mit einem erhöhten
Schutzbedarf benötigen aber ggf. weitere Maßnahmen, die in der ergänzenden
Sicherheitsanalyse ermittelt werden müssen. Diese zweistufiger Ansatz des ITGS wird aus Effizienzgründen einer Sicherheitsanalyse für jedes Schutzobjekt
vorgezogen.
Notwendigkeit einer ergänzenden Sicherheitsanalyse
Eine ergänzende Sicherheitsanalyse ist für die Objekte des IT-Verbundes durchzuführen, bei denen mindestens eines der folgenden Kriterien zutrifft:
• Das Objekt hat einen hohen oder sehr hohen Schutzbedarf in mindestens
einem der Schutzziele Vertraulichkeit, Integrität der Verfügbarkeit.
• Das Objekt ist mit den existierenden Bausteinen nicht zufriedenstellend
abbildbar.
• Das Objekt wird in einem Einsatzszenario betrieben, das im IT-GS nicht
vorgesehen ist.
Gruppenbildung
Management-Report
Auch hier sollte aus Effizienzgründen eine geeignete Gruppenbildung vorgenommen werden. In einem Management-Report werden die Ergebnisse der ergänzenden Sicherheitsanalyse zusammen gefasst. In diesem soll für jedes Objekt, das im
Rahmen der ergänzenden Sicherheitsanalyse betrachtet werden muss, also eine
der obigen Eigenschaften erfüllt, stichhaltig begründet werden, ob eine weitere
Risikobetrachtung erforderlich ist. Der Management-Report ist dem Management
vorzulegen und muss von diesem verabschiedet werden, womit das Management
6.4 Umsetzung der Sicherheitskonzeption
Seite 99
gleichzeitig die Verantwortung übernimmt. Viele weitere Detailaspekte einer ergänzenden Sicherheitsanalyse sind im BSI-Standard 100-3 “Risikoanalyse auf der
Basis von IT-Grundschutz” [3] beschrieben.
6.4 Umsetzung der Sicherheitskonzeption
Nachdem im Rahmen der Erstellung der Sicherheitskonzeption die Strukturanalyse, die Schutzbedarfsfeststellung und die Modellierung erfolgt sind, steht jetzt
die Umsetzung der Ergebnisse an. Aufbauend auf der Soll-Ist-Analyse aus dem
Basis-Sicherheitscheck und ggf. zusätzlich durchgeführten Risikoanalysen werden
jetzt die einzelnen Maßnahmen im Detail geplant und anschließend umgesetzt.
Vom Konzept zur
Maßnahmenumsetzung
Sichtung der Ergebnisse
Da für die Umsetzung der Sicherheitsmaßnahmen generell nur begrenzte Ressourcen zur Verfügung stehen, ist eine sorgsame Planung zur effizienten Umsetzung
der erforderlichen Maßnahmen notwendig. Zunächst sollten dabei die Maßnahmen adressiert werden, die nach Ergebnis der Soll-Ist-Analyse noch fehlen oder
erst teilweise umgesetzt sind. Diese lassen sich aus dem Basis-Sicherheitscheck
extrahieren und tabellarisch zusammen fassen. Hinzu kommen ggf. Maßnahmen,
die aufgrund einer Risikoanalyse erforderlich sind.
Zielsetzung:
Effiziente Umsetzung
Konsolidierung der Maßnahmen
Die sich ggf. aus den zusätzlichen Risikoanalysen ergebenden Maßnahmen werden
nun mit den Maßnahmen nach BSI IT-GS zusammen gefasst. Dies kann bedeuten,
dass GS-Maßnahmen entfallen können, wenn sie durch gleich- oder höherwertige
Maßnahmen ersetzt werden. Da zudem jede Organisation ihre Eigenheiten hat, der
IT-GS aber nur generelle Empfehlungen geben kann, kann es zudem vorkommen,
dass GS-Maßnahmen durch Maßnahmen ersetzt werden, die gleichwertig sind,
aber besser zur Organisation passen. Dies kann bspw. der Fall sein, wenn die
Maßnahme nach BSI IT-GS nicht wirtschaftlich erscheint oder die baulichen Gegebenheiten eine Umsetzung nicht zulassen. Die hierbei getroffenen Entscheidungen
müssen nachvollziehbar dokumentiert werden.
Zusammenfassen von
Maßnahmen
Kosten-/Aufwandsabschätzung
Wie bereits angesprochen, sind die Ressourcen einer Organisation begrenzt.
Insofern ist es notwendig, auch bei der Umsetzung der Maßnahmen eine
Kosten/Nutzen-Analyse zu erstellen, die als Basis für die weiteren Entscheidungen
fungiert. Dazu werden für jede zu realisierende Maßnahme mögliche Investitionen
und Personalaufwendungen dokumentiert. Dabei sollte auch zwischen einmaligen
und wiederkehrenden Kosten unterschieden werden. Werden dabei Maßnahmen
identifiziert, die aus wirtschaftlichen Aspekten nicht umsetzbar sind, muss überlegt werden, welche Ersatzmaßnahmen denkbar sind. Die Entscheidungen sind
ebenfalls nachvollziehbar zu dokumentieren.
Kosten/Nutzen-Analyse
Seite 100
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
Budgetzuweisung
Falls prinzipiell die entsprechenden Ressourcen zur Umsetzung zur Verfügung
stehen, muss über die Zuteilung zu einzelnen Maßnahmen und über die Reihenfolge der Umsetzung von Maßnahmen entschieden werden. Die Entscheidung
wird häufig auf Basis einer Präsentation durchgeführt, die der Leitungsebene
die Ergebnisse der Sicherheitsanalyse aufzeigt und eine Entscheidungsgrundlage
gibt.
Risiken bei fehlendem Budget
Ist jedoch kein ausreichendes Budget vorhanden, können Maßnahmen also nicht
oder nur punktuell umgesetzt werden, so sind die dadurch entstehenden Risiken
an die Leitungsebene zu kommunizieren. Dazu können bspw. die Kreuzreferenztabellen aus dem IT-GS genutzt werden, die die Maßnahmen den entsprechenden
Gefährdungen gegenüberstellen.
Umsetzungsreihenfolge festlegen
Priorisierung
von Maßnahmen
Insbesondere wenn das Budget nicht ausreicht, alle Maßnahmen sofort umzusetzen, müssen die Maßnahmen bzgl. ihrer Umsetzungsreihenfolge priorisiert
werden. Die Festlegung der Reihenfolge orientiert sich dabei bspw. an den folgenden Kriterien:
Lebenszyklus
• Lebenszyklus der Maßnahme: Maßnahmen aus der Kategorie “Planung
und Konzeption” sollten sinnvollerweise vor Maßnahmen aus der Kategorie
“Umsetzung” durchgeführt werden.
Verknüpfung
• Logische Zusammenhänge zwischen einzelnen Maßnahmen, die die Reihenfolge beeinflussen.
Breitenwirkung
• Breitenwirkung der Maßnahmen: Maßnahmen mit (strategischer) Breitenwirkung sollten vor Maßnahmen mit rein punktueller Wirkung umgesetzt
werden.
Einfluss
• Einfluss auf das Sicherheitsniveau: Einige Bausteine haben einen größeren
Einfluss als andere und sollten bevorzugt umgesetzt werden.
Anzahl
fehlender Maßnahmen
• Anzahl nicht umgesetzter Maßnahmen pro Baustein: Maßnahmen aus Bausteine mit vielen nicht umgesetzten Maßnahmen sollten priorisiert behandelt
werden.
Einstufung
• Einstufung der Maßnahme nach BSI IT-GS: Maßnahmen der unterschiedlichen Kategorien sollten A (Einstieg), B (Aufbau), C (Zertifizierung), Z
(Zusatzmaßnahmen) und W (Wissen) umgesetzt werden. Dieser Aspekt ist
inbesondere dann interessant, wenn eine (spätere) Qualifizierung nach BSI
IT-GS angestrebt wird.
Entscheidungen
dokumentieren
Die Entscheidung, welche Maßnahmen ergriffen bzw. auf einen späteren Zeitpunkt
verschoben und damit die Restrisiken akzeptiert werden, ist nachvollziehbar zu
dokumentieren. Dabei kann auch eine zweite Meinung eingeholt werden, um im
Problemfall die angemessene Sorgfalt bei der Entscheidung dokumentieren zu
können.
Festlegung von Aufgaben und Verantwortung
Wer setzt Maßnahmen bis wann um?
Damit die Umsetzung von Maßnahmen auch sicher gestellt wird, sollte nach der
Entscheidung, welche Maßnahmen in welcher Reihenfolge umgesetzt werden, auch
festgelegt werden, wer die Maßnahmen bis wann umsetzen muss. Ebenso sollte
6.5 Aufrechterhaltung und Verbesserung
Seite 101
zu jeder Maßnahme auch festgelegt werden, wer die Umsetzung überwacht und
als Ansprechpartner für Probleme, aber auch für die “Fertigmeldung” ist. Bleiben
diese Festlegungen aus, läuft die Organisation Gefahr, dass die Maßnahmen zwar
begonnen, aber nicht zielführend umgesetzt werden.
Als Ergebnis steht dann der so genannte Realisierungsplan, der (mindestens) die
folgenden Informationen beinhaltet: a) Beschreibung des Zielobjekts, bei dem die
Maßnahme durchgeführt wird, b) Maßnahmentitel und -beschreibung, c) Terminplan und zugewiesenes Budget und d) Verantwortlicher für die Umsetzung und
die Überwachung derselben.
Realisierungsplan
Begleitende Maßnahmen
Neben den eigentlichen Maßnahmen, die sich aus dem Basis-Sicherheitscheck ergeben haben, sind auch Maßnahmen zu berücksichtigen, die eher eine begleitende
Funktion erfüllen. Dazu zählen insbesondere Sensibilisierungsmaßnahmen und
Schulungen, die auch über die Konsequenzen der durchgeführten Maßnahmen
unterrichten. Ohne solch begleitende Schulungen verfehlen viele Maßnahmen
ihre Wirkung, bspw. weil sich die Mitarbeiter uninformiert fühlen und dann eine
negative Haltung ggb. der Maßnahme einnehmen.
Awareness und Training
6.5 Aufrechterhaltung und Verbesserung
Um den IS-Prozess aufrecht zu erhalten und kontinuierlich zu verbessern, reicht
es nicht aus, die (notwendigen) Maßnahmen zu implementieren und die Dokumentation laufend zu aktualisieren. Vielmehr muss auch der IS-Prozess selbst auf
seine Wirksamkeit und Effizienz überprüft werden. Dabei sollte auch eine Erfolgskontrolle und Bewertung des IS-Prozesses durch die Leitungsebene stattfinden,
die Ergebnisse sind nachvollziehbar zu dokumentieren. Die Überprüfung findet
dabei sowohl auf regelmäßiger Basis statt als auch bei Bedarf, bspw. wenn sich
Sicherheitsvorfälle häufen oder gravierende Änderungen festgestellt wurden.
Kontinuierliche Verbesserung
Überprüfung des IS-Prozesses
Die Überprüfung des IS-Prozesses verfolgt im wesentlichen zwei Ziele: Bisher
nicht bekannte Schwachstellen aufzudecken und den Prozess weiter zu optimieren. Zur Überprüfung des IS-Prozesses kommen unterschiedliche Methoden in
Betracht. Dazu zählen etwa a) die Erkennung, Dokumentation und Auswertung
von Sicherheitsvorfällen, b) die Durchführung von Übungen im Bereich der IS, c)
interne und externe Audits und Datenschutzkontrollen sowie d) Zertifizierungen
nach festgelegten Kriterien. Die Überprüfung sollte dabei in jedem Fall von einer
unabhängigen -ggf. externen- Stelle durchgeführt werden, insbesondere nicht von
demjenigen, der die IS-Konzeption entwickelt hat.
Methoden zur
Überprüfung
Auf Grundlage des Realisierungsplans kann überprüft werden, inwieweit dieser
eingehalten wurde. Dabei spielt die Ressourcenplanung eine wichtige Rolle, da
ohne diese keine (fristgerechte) Umsetzung der Maßnahmen erzielbar ist. Hinzu
kommt die Überprüfung der Akzeptanz der getroffenen Maßnahmen, um Misserfolge -insbesondere bei neu eingeführten Maßnahmen- möglichst zu vermeiden.
Auch eine Zertifizierung, bspw. auf Basis nach IT-GS, kann zur Überprüfung der
Zielerreichung eingesetzt werden.
Überprüfung der Umsetzung des Realisierungsplans
Unabhängige Überprüfung notwendig
Zertifizierung
Seite 102
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
Eignung der IS-Strategie
Aktualität
Wirtschaftlichkeit
Rückmeldungen
Übernahme der Ergebnisse in den IS-Prozess
Richtlinie zur
Überprüfung
Für eine effiziente Steuerung des IS-Prozesses muss die Leitungsebene die ISStrategie kontinuierlich auf ihre Eignung zur Erreichung der Sicherheitsziele kontrollieren. Dabei sind sowohl die Aktualität der Sicherheitsziele, als auch der Rahmenbedingungen ein wichtiger Aspekt. Gerade in schnelllebigen Branchen kommt
es oft zu betrieblichen Änderungen, die einen Einfluss auf die IS haben. Daneben
spielt auch die Wirtschaftlichkeit der IS-Strategie und einzelner Sicherheitsmaßnahmen eine wichtige Rolle. Durch eine regelmäßige Kosten/Nutzen-Analyse
und einem Vergleich der aktuellen mit den ehemals geplanten Kosten können
Fehlinvestitionen vermieden und gleichzeitig ein optimierter Ressourceneinsatz
realisiert werden. Rückmeldungen über Fehler und Schwachstellen kommen in
der Regel nicht nur von den direkt beteiligten Stellen, sondern werden auch von
weiteren internen oder externen Stellen gegeben. Gerade für die Rückmeldung von
Externen muss die Organisation daher im Vorfeld entsprechende Mechanismen
festlegen, damit es nicht zu negativen Reaktionen kommt. Dies gilt insbesondere
für die Meldung von Problemen durch die eigenen Mitarbeiter. Hier ist darauf zu
achten, dass es nicht zu Unzufriedenheit kommt, die dann ggf. in einem schlechten
Klima der IS endet.
Fließen die Ergebnisse der Erfolgskontrolle nicht in den Prozess zurück, ist keine
Verbesserung möglich. Dabei sollte dieser Prozess so offen gestaltet sein, dass
im Extremfall die IS-Prozesse grundlegend überdacht werden können. Dies ist
bspw. dann der Fall, wenn die Überprüfung ergibt, dass Sicherheitsziele unter den
aktuellen Rahmenbedingungen nicht oder nur mit großem, unwirtschaftlichem
Ressourceneinsatz erreichbar sind. Werden größere Veränderungen vorgenommen
oder Verbesserungen umgesetzt, so schließt sich der Management-Kreislauf und
es folgt eine erneute Planungsphase. Wie bereits angedeutet, dürfen die Überprüfungen nur von unabhängigen Stellen und keinesfalls durch die Ersteller der
Konzepte selbst durchgeführt werden. Zudem ist es sinnvoll, den Überprüfungsprozess mit einer Richtlinie zu untermauern. Diese sollte insbesondere regeln, wie
(interne) Audits durchzuführen sind und wie die Ergebnisse in den IS-Prozess
zurückfließen. Die Prüfberichte sind in der Regel als vertraulich zu betrachten (da
sie unter Umständen gravierende Schwachstellen im IS-Prozess aufzeigen) und
daher entsprechend zu schützen.
Informationsfluss im IS-Prozess
Verfügbarkeit und
Verständlichkeit
der Informationen
Der gesamte IS-Prozess beinhaltet auch Berichte unterschiedlicher Form. Dies
gilt insbesondere für die Teilprozesse der Überprüfung und Verbesserung des ISProzesses, bspw. in Form von Audit-Reports, Ergebnisse von Sicherheitstests oder
auch Meldungen über sicherheitsrelevante Ereignisse. Diese Dokumente müssen
zum einen für die jeweilige Zielgruppe verständlich und verfügbar sein, zum
anderen ist es die Aufgabe des IS-Beauftragten, diese auch für die Leitungsebene
in verständlicher Form zusammen zu fassen und zur Verfügung zu stellen.
Berichte an die
Leitungsebene
Dies ist vor allem deswegen notwendig, damit die Leitungsebene eine solide
Informationsbasis hat und damit die richtigen Entscheidungen bei der Steuerung
des IS-Prozesses treffen kann. Dazu sollten die Eckpunkte in einem ManagementBericht aufbereitet werden, der zumindest die folgenden Aspekte abdeckt:
• Ergebnisse von IS- und Datenschutz-Audits
• Berichte über Sicherheitsvorfälle
• Berichte über Erfolge und Probleme beim IS-Prozess
6.6 Zertifizierung
Seite 103
Die Leitungsebene wird von der IS-Organisation, allen voran dem IS-Beauftragten
mit den notwendigen Berichten versorgt, nimmt diese zur Kenntnis und veranlasst
die notwendigen Maßnahmen.
Neben dieser Dokumentation ist auch die Dokumentation des IS-Prozesses selbst
entscheidend für seinen Erfolg. Nur durch aussagekräftige Dokumentation kann
sicher gestellt werden, dass die getroffenen Entscheidungen nachvollziehbar werden, Prozesse wiederholbar und standardisiert sind und Schwächen und Fehler
frühzeitig erkannt und zukünftig vermieden werden. Die Dokumentation an sich
kann in verschiedene Arten unterteilt werden, die jeweils eine unterschiedliche
Zielsetzung haben. Dazu gehören
Dokumentation des
IS-Prozesses
Arten der Dokumentation
• die technische Dokumentation und die Dokumentation von Prozessen. Diese
richten sich an Experten und beschreiben den aktuellen Stand der Prozesse
innerhalb der Organisation und der damit verbundenen IT-Systeme.
Technische
Dokumentation
• Anleitungen, wie bspw. Arbeitsabläufe oder Richtlinien, die sich an Mitarbeiter richten. Sie beschreiben die Sicherheitsmaßnahmen in einer für die
Mitarbeiter verständlichen Form und sorgen auch dafür, dass die Mitarbeiter
über die Sicherheitsmaßnahmen informiert sind.
Anleitungen
• Aufzeichnungen der Entscheidungen des Managements. Diese richten sich
an die Leitungsebene und dokumentieren die wesentlichen Entscheidungen
im Rahmen des IS-Prozesses.
Managemententscheidungen
• Gesetze und sonstige verbindliche Regularien. Diese richten sich ebenfalls
an die Leitungsebene und dokumentieren, welche besonderen Gesetze und
Regularien besondere Anforderungen an die Prozesse der Organisation
stellen und welche Konsequenzen sich daraus ergeben.
Gesetze und Regularien
Der Prozess der Dokumentation muss zudem in den (standardisierten) Änderungsprozess der Organisation einbezogen werden. Nur so kann sicher gestellt werden,
dass sämtliche Dokumentation auf einem aktuellen Stand ist.
Wie bereits erläutert wurde, sind ein ordnungsgemäßer Informationsfluss und entsprechende Meldewege unverzichtbar für einen funktionierenden IS-Prozess. Zur
Verbesserung des Informationsflusses können wiederum die Ergebnisse von Sicherheitstests, Sicherheitsvorfällen und Audits mit einbezogen werden. Die Gestaltung
der Meldewege sollte dabei so vorgenommen werden, dass mögliche Synergien
mit anderen Prozessen der Organisation genutzt werden bzw. eine Integration
in die übrigen Prozesse stattfindet. Zudem kann es hilfreich sein, eine Richtlinie
zum Informationsfluss un den Meldewegen zu erstellen, die die Vorgehensweisen
dokumentiert und von der Leitungsebene verabschiedet wird. Dabei sollte klar
zwischen den Parteien, die etwas liefern müssen, und denen, die etwas einfordern
müssen, unterschieden werden.
Informationsfluss und
Meldewege
Richtlinie zum Informationsfluss und den
Meldewegen
6.6 Zertifizierung
Wie bereits erwähnt, kann die Zertifizierung des IS-Prozesses dazu beitragen, seine
Umsetzung nach außen transparent zu machen und gleichzeitig auch Kriterien
für die (interne) Überprüfung schaffen. Über ein entsprechendes Zertifikat wird
zunächst nachgewiesen, dass
• IS für die Organisation ein anerkannter Wert ist,
• in der Organisation ein funktionierendes IS-Management vorhanden ist und
Ziel einer Zertifizierung
Seite 104
Studienbrief 6 Vorgehensweise nach BSI IT-Grundschutz
• zu einem bestimmten Zeitpunkt (der Auditierung) ein definiertes Sicherheitsniveau erreicht wurde.
Weitere Vorund Nachteile
Ob eine Organisation tatsächlich eine Zertifizierung anstreben sollte, sollte allerdings ein wohlüberlegter Prozess sein, da die Erfüllung der damit verbundenen
Anforderungen in der Regel mit erheblichem Aufwand verbunden sein wird. Auf
der anderen Seite stellt der Anspruch, die Zertifizierung zu erreichen, aber auch
ein klares Ziel dar, das dafür sorgt, dass der IS-Prozess mit der notwendigen
Konsequenz vorangetrieben und nicht nur halbherzig betrieben wird.
Zusammenfassung dieses Studienbriefs
Zusammenfassung
In diesem Kapitel haben wir -aufbauend auf den Grundlagen der vorhergehenden
Kapitel- den Aufbau eines ISMS am Beispiel des BSI IT-GS exemplarisch vorgestellt.
Diese Zusammenfassung ersetzt allerdings nicht das Studium des BSI-Standards
100-2 [2], in dem die Details zum Aufbau eines ISMS, insbesondere zu Erstellung
des Sicherheitskonzepts, vorgestellt werden. Ergänzt werden sollten die dort vorhandenen Informationen und Handlungsempfehlungen durch die Inhalte vom
BSI-Standard 100-1 “Managementsysteme für Informationssicherheit (ISMS)” [1]
und 100-3 “Risikoanalyse auf der Basis von IT-Grundschutz” [3].
Studienbrief 7 Zusammenfassung und Fazit
Seite 105
Studienbrief 7 Zusammenfassung und Fazit
Informationssicherheit ist mehr als IT-Sicherheit, denn neben den technischen
Aspekten sind eine Fülle weiterer Fragen aus den Bereichen “Personen” und “Prozesse” zu berücksichtigen. Das Ziel einer kontinuierlich verbesserten, an die aktuellen Änderungen angepassten IS kann allerdings nur erreicht werden, wenn ein
Prozess zum Management der IS aufgebaut wird. Ein weiterer wichtiger Erfolgsfaktor ist die Akzeptanz der Maßnahmen. Dazu muss gewährleistet werden, dass
diese angemessen sind und im Sinne des “Geschäftsbetriebs” der Organisation
ausgerichtete sind. Nicht zuletzt spielt auch die Unterstützung durch das Management eine wesentliche Rolle für den Erfolg der IS. Nur wenn das Management
auch im Konfliktfall “Business vs. Security” eine Risiko-basierte Entscheidung
trifft und die Ziele der IS unterstützt, wird das IS-Management langfristig von
Erfolg gekrönt sein. Dazu ist aber wiederum die Beteiligung aller Mitarbeiter und
vor allem die Unterstützung durch das Management erforderlich. Dieses Modul
soll die Grundlagen dazu legen.
Informationssicherheit
vs.
IT-Sicherheit
In der Einleitung (Studienbrief 1) haben wir zunächst eine kurze Einführung in
die Thematik gegeben und dargelegt, warum ein IS-Management der richtige
Ansatz ist. Studienbrief 2 geht dann im Detail auf die Aspekte der IS-Governance
ein. Dabei wurde die notwendige Ausrichtung an den “Geschäftszielen” betont
und die wesentlichen Vorteile einer IS Governance aufgezeigt. Im Studienbrief 3
haben wir mit dem Thema “Risikomanagement” die Grundlage für den Aufbau
des IS-Programms gelegt. Erst ein effektives und effizientes Risikomanagement
gibt der Organisation die Chance, trotz begrenzter Ressourcen die Maßnahmen zu
implementieren, die in Bezug auf die IS den größten Mehrwert bieten. Gleichzeitig
gibt das Risikomanagement dem IS-Manager auch Argumente an die Hand, die
Leitungsebene von der Sinnhaftigkeit der IS zu überzeugen.
IS-Governance als Motivator
Der Studienbrief 4 ging dann auf die Planung und den Aufbau des IS-Programms
ein. Erst durch das IS-Programm werden die auf Grundlage des Risikomanagements ermittelten Maßnahmen in “die Fläche” gebracht und auf der Arbeitsebene
implementiert. Gleichzeitig bietet das IS-Programm die Möglichkeit, die IS in den
Standardprozessen der Organisation zu verankern und zu einer hohen Effizienz,
aber auch Akzeptanz der IS beizutragen. Studienbrief 5 beschäftigte sich schließlich mit der Frage, wie man sich auf mögliche Vorfälle vorbereitet, die trotz eines
umfangreichen Risikomanagements bisher nicht entsprechend abgefedert wurden - etwa, weil sie nicht bedacht wurden oder als zu unwahrscheinlich erachtet
wurden.
Umsetzung im ISProgramm
In Studienbrief 6 haben wir dann den Ansatz nach dem BSI IT-GS exemplarisch
kennne gelernt und die einzelnen Schritte beschrieben, die notwendig sind, um
ein ISMS nach IT-GS aufzubauen. Dieser Studienbrief hat allerdings nicht den
Anspruch, die Standards 100-1, 100-2 und 100-3 des BSI zu ersetzen. Vielmehr
steht es für eine “zusammenfassende” Darstellung des Standards 100-2, der die
Implementierung eines ISMS nach IT-GS beschreibt.
IS-Management mit
BSI IT-Grundschutz
Abschließend muss aber betont werden, dass dieses Modul nur die theoretische
Grundlage für den Betrieb eines ISMS liefert. Die Umsetzung ist in der Praxis
aber -gemäß dem Spruch “Theorie und Praxis”- häufig mit erheblichen Problemen
verbunden, die in diesem Moduel nur ansatzweise angesprochen werden können.
Erfahrung ist daher nach wie vor das Kriterium, das einen guten IS-Manager
auszeichnet - und ihn dann auch alle Widrigkeiten meistern lässt.
Zusammenfassung
Risikomanagement als
Entscheidungsbasis
Pläne für das Ungeplante
Erfahrung macht den
Meister
Verzeichnisse
Seite 107
Verzeichnisse
8.1 Abbildungen
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
1.1:
1.2:
2.1:
2.2:
2.3:
2.4:
3.1:
3.2:
3.3:
3.4:
4.1:
4.2:
5.1:
5.2:
6.1:
6.2:
Illustration der CIA-Triade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Drei-Säulen-Modell der Informationssicherheit . . . . . . . . . . . . . . . . . .
PDCA-Zyklus nach Deming . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konzept der “Layered Defense” . . . . . . . . . . . . . . . . . . . . . . . . . .
Schematische Darstellung der Policy-Pyramide . . . . . . . . . . . . . . . . . .
Veranschaulichung der Kriterien “Umsetzungsverpflichtung” und “Messbarkeit”
Risikobewertung mittels “Eintrittswahrscheinlichkeit” und “Auswirkungen” . . .
Risikomanagement nach dem Standard “NIST 800-30” . . . . . . . . . . . . . .
Klassifizierung von Informationswerten durch Gruppierung . . . . . . . . . . .
Illustration der “4-T”-Maßnahmen . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel einer Netzwerk-Architektur . . . . . . . . . . . . . . . . . . . . . . . .
SDLC als Wasserfall-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration des SAP-Konzepts der Digitalen Forensik . . . . . . . . . . . . . . .
Illustration eines “virtuellen Teams” . . . . . . . . . . . . . . . . . . . . . . . .
Vorgehensweise nach BSI IT-Grundschutz . . . . . . . . . . . . . . . . . . . . .
Kosten-Nutzen-Relation im Bereich der IS . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
11
16
20
25
26
40
41
45
48
57
64
78
80
86
92
8.2 Literatur
[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn. BSI-Standard 100-1: Managementsysteme für
Informationssicherheit (ISMS), Version 1.5, Mai 2008.
[2] Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn. BSI-Standard 100-2: IT-GrundschutzVorgehensweise, Version 2.0, Mai 2008.
[3] Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn. BSI-Standard 100-3: Risikoanalyse auf der
Basis IT-Grundschutz, Version 2.5, Mai 2008.
[4] Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn. BSI-Standard 100-4: Notfallmanagement,
Version 1.0, November 2008.
[5] W.E. Deming. Out of the Crisis. The MIT Press, Cambridge (USA), 1. Auflage, 1982.
[6] Information Systems Audit and Control Association (ISACA), Rolling Meadows (USA). Control Objectives for
Information and Related Technology (COBIT), Version 5, April 2012.
[7] Information Systems Audit and Control Association (ISACA), Rolling Meadows (USA). Certified Information
Security Manager (CISM) Review Manual, Version 11, 2013.
[8] R.S. Kaplan, D.P. Norton und P. Horváth. Balanced Scorecard: Strategien erfolgreich umsetzen. Schäffer-Poeschel
Verlag, Stuttgart, 1. Auflage, September 1997.
[9] Payment Card Industry (PCI) Security Standards Council, Wakefield (USA). PCI Data Security Standard (PCI
DSS), Version 3.0, November 2013.
[10] W.A. Shewhart. Statistical Method from the Viewpoint of Quality Control. Dover Pubn Inc, 1. Auflage, November
1986.
Seite 108
Verzeichnisse
[11] Software Engineering Institute (SEI), Carnegie Mellon University, Pittsburgh (USA). Capability Maturity
Model Integration (CMMI), Version 1.3, 2010.
[12] R. Stoneburner, A. Feringa und A. Goguen. Risk Management Guide for Information Technology Systems. National
Institute of Standards and Technology, Gaithersburg (USA), Version 1.0, Juli 2002.

Rundbrief Nr. 4 von Lene Wagner

Folder downloaden

Haus Engl Maria in Kirchberg in Tirol

Denkanstoss Nr. 415 Anzeige 30. April 2015

Kreisfeuerwehrverband Meißen e. V.

Sichere mobile Kommunikation IT Recht und Datenschutz Sicherheit

KREUZWORTRÄTSEL

Was bedeutet Sicherheit - HDG Security

Programm 14. Deutscher IT-Sicherheitskongress - BSI

Invitation officielle - eb