Das im vorangegangenen Beitrag beschriebene Assetmanagement ist eine grundlegende Voraussetzung für ein funktionierendes Risikomanagement. Wer seine Assets nicht kennt, kann auch kaum Risiken mit Bezug zu diesen Assets identifizieren. Die ISO 27001 ist in diesem Zusammenhang nicht sonderlich hilfreich. In Kapitel 6.1.2 wird nur gefordert einen Prozess zur Informationssicherheitsrisikobeurteilung festzulegen und anzuwenden, der c) die Informationssicherheitsrisiken identifiziert. Dazu muss der Prozess Risiken im Zusammenhang mit dem Verlust der Vertraulichkeit, Integrität und Verfügbarkeit innerhalb des Anwendungsbereichs des ISMS und die Risikoeigentümer identifizieren. Wie das gehen soll, steht da aber nicht.
Das ist gut – und schlecht. Schlecht ist es, weil damit dem Einsteiger die Arbeit erschwert wird, denn wer noch nie Risikomanagement betrieben hat (und auch etliche die es schon getan haben) bekommen hier keinerlei Anleitung geboten. Gut ist aber, dass jeder die Möglichkeit hat seinen eigenen Prozess zur Risikobeurteilung (ich mag den Begriff Risikoanalyse lieber) zu definieren und anzuwenden und solange die Methode schlüssig ist und das Ergebnis der Norm entspricht, muss ein Auditor damit zufrieden sein.
Zum besseren Verständnis des Gesamtprozesses Risikomanagement ist es wichtig die Zusammenhänge und die verwendeten Begrifflichkeiten zu verstehen.
Zäumen wir das Pferd von hinten auf. Was ist denn das geforderte Ergebnis oder die geforderten Ergebnisse?
Beginnen wir mit der Risikoanalyse (in der Norm auch Informationssicherheitsrisikobeurteilung genannt). In der Reihenfolge der Norm (die nicht unbedingt chronologisch ist) sind die folgenden Punkte als Ergebnis der Risikoanalyse zu liefern:
- Eine Liste an Risiken und die dazugehörigen Risikoeigentümer
- die Abschätzung der Eintrittswahrscheinlichkeiten und der Auswirkung und die daraus resultiernden Risikoniveaus
- eine Priorisierung der Risiken für die Risikobehandlung
Wie aus der schematischen Darstellung ersichtlich ist entsteht ein Risiko wenn eine Bedrohung auf die Schwachstelle eines Wertes trifft und damit die Informationssicherheit dieses Wertes negativ beeinträchtigt. Ein sehr wissenschaftlicher Satz ist das. Ich will es an einem Beispiel verdeutlichen:
Wert = Fahrrad
Bedrohung = Dieb
Schwachstelle = Schloss
Spielen wir die verschiedenen Möglichkeiten mal durch:
Möglichkeit 1: Mein Fahrrad ist ein altes klappriges Damenrad vom Sperrmüll. D. h. es stellt für mich keinen tatsächlichen Wert dar. Der Verlust des Fahrrads wäre für mich allerhöchstens unangenehm aber kein wirklicher Verlust. Ein Dieb könnte kommen und es stehlen und aufgrund des geringes Wertes würde ich auch kein 100-Euro Schloss an das Fahrrad machen. Effektiv wäre der Verlust des geknackten Schlosses größer als der Verlus des Fahrrads. Es gibt also kein wirkliches Risiko für das ich Maßnahmen ergreifen müsste. Ergebnis: Kein Wert = kein Risiko!
Möglichkeit 2: Ich habe ein 8000-Euro Rad. Der Verlust bei einem Diebstahl wäre enorm. Aufgrund des Wertes ist auch die Bedrohungslage eine andere, denn ich kann davon ausgehen, dass ein teures Rad mehr mögliche Diebe auf den Plan ruft, als ein billiges Rad. Die Bedrohung (Dieb) an sich ändert sich dadurch aber nicht. Hätte ich ein billiges Schloss oder sogar gar kein Schloss, dann kann diese Schwachstelle natürlich von jedem halbwegs versierten Dieb ausgenutzt werden. Allerdings könnte ich natürlich auch die Schwachstelle eliminieren und z.B. das Fahrrad nie sichtbar irgendwo stehen lasse und es auch in der eigenen abgesperrten Garage mit einem hochwertigen Schloss versehen und eine Alarmanlage zur Überwachung anbringen. (im Übrigen eine Mischung aus verschiedenen technischen und organisatorischen Maßnahmen!) Ergebnis: keine Schwachstelle = kein Risiko!
Möglichkeit 3: Wir würden in einer Welt ohne Diebe leben. Ich könnte mein Fahrrad komplett ohne Schloss überall stehen lassen und müsste mir keine Sorgen machen. Wert und Schwachstelle wären immer noch da, aber keine Bedrohung mehr. Ergebnis: keine Bedrohung = kein Risiko!
Diese Überlegung zeit: Nur da wo eine Bedrohung auf die Schwachstelle eines Wertes trifft entsteht ein Risiko. Wenn [Bedrohung|Schwachstelle|Wert] fehlt, kann es auch kein Risiko geben. Für die Risikoidentifikation müssen also nicht nur die Werte bekannt sein (Assetinventar), sondern auch die Schwachstellen und die Bedrohungen. Werden diese übereinandergelegt entsteht eine Liste der tatsächlichen Risiken.
Ausgangspunkt für diese Aufgabe ist das Assetinventar. Das Assetinventar listet alle Werte auf, die durch das ISMS zu schützen sind. Ein Zwischenschritt der in der Norm ISO 27001 fehlt, ist die Bewertung des Schutzbedarfs der Werte. Diesen Zwischenschritt empfehle ich aber dringend, denn wie im Beispiel Fahrrad aufgezeigt, besteht kein Risiko wenn das Fahrrad keinen Wert hat. Das Assetinventar listet aber alle Werte gleichwertig auf.
Zur Erläuterung können wir annehmen, dass das Assetinventar 4 Werte auflistet: Fahrrad, PKW, LKW, Panzer.
Würden diese 4 Werte gleichwertig in der Risikoidentifikation behandeln, würden für jedes dieser 4 Werte auch tatsächliche Risiken identifiziert werden. In der nachfolgenden Priorisierung der Risikobehandlung würden jedoch Maßnahmen bzgl. Fahrräder wahrscheinlich niedriger priorisiert werden, denn solange die Risiken bzgl. Panzer, LKW und PKW nicht behandelt sind werden kaum Ressourcen für die Risikobehandlung für Fahrrad verwendet werden. Dieses Ergebnis kann vorweggenommen werden, indem die Assets erst hinsichtlich des Schutzbedarfs bewertet werden. Dadurch können in übertragenem Sinn alle Risiken in Verbindung mit dem Asset Fahrrad akzeptiert werden und auf die Risikoidentifikation verzichtet werden. Spart Arbeit.
Das Assetinvetar dass zur Identifikation von Risiken herangezogen wird enthält dann nur noch die Werte, die auch tatsächlich einen hohen Schutzbedarf aufweisen. Auf diese Werte muss im nächsten Schritt eine Zuordnung von Bedrohungen und Schwachstellen erfolgen. Um ein gültiges, nachvollziehbares und wiederholbares Ergebnis zu erzielen sollte eine standardisierte Liste an Bedrohungen und Schwachstellen zugrundegelegt werden. Dazu gibt es verschiedene Vorlagen z.B. vom BSI oder auch von Branchenverbänden. Meine Listen sehen ungefähr so aus:
Schwachstellen:
Komplizierte Benutzerinterfaces, nicht dokumentierte Software
Entsorgung von Speichermedien, ohne zu löschen
Geräteempfindlichkeit (Strom/Spannung, Feuchtigkeit, Verschmutzung, Temperatur etc.)
Unzureichende Sicherheit in der Verkabelung
Unzureichendes Kapazitätsmanagement
Unzureichendes Change Management (Gewaltenteilung, Spezifikation für Entwicklung, Test, Testdaten, Trennung von Test und Betrieb etc.)
Unzureichende Klassifizierung von Informationen
Unzureichende Kontrolle des physischen Zugangs
Unzureichende Wartung/Pflege/Verwaltung von informationsverarbeitenden Einrichtungen
Unzureichendes Netzwerkmanagement
Mangelhaftes oder unregelmäßiges Backup
Unzureichendes Passwort-Management (Standartpasswörter, Benutzerrechtereview, Ausscheiden von Mitarbeitern etc.)
Unzureichender physische Schutz
Unzureichender Schutz von kryptographischen Schlüsseln
Unzureichende Ersatz älterer Anlagen
Unzureichendes Sicherheitsbewusstsein, Ausbildung, Motivation
Unzureichende Kontrolle der Mitarbeiter/Anbieter
Mangelnde Zugangs- und Zugriffskontrollrichtlinien
Keine Clear-Desk und Clear-Screen Policy
Mangel an Kontrolle über die Eingangs-und Ausgangsdaten
Mangelnde interne Dokumentation
Fehlende oder mangelhafte Umsetzung der internen Revision
Keine Richtlinie für die Nutzung von Kryptographie
Mangel an Schutz für mobile Geräte
Mangel an Redundanz, Diversifizierung
Fehlen von Systemen zur Identifizierung und Authentifizierung
Fehlen der Validierung der verarbeiteten Daten
Lage anfällig für externe Bedrohungen (Überschwemmungen, Explosion etc.)
Unkontrolliertes Kopieren von Daten
Unkontrollierter Nutzung des Internet
Unzureichender Schutz vor Schadsoftware
Unkontrollierter Einsatz von Informationssystemen
Ungeschützte öffentliche Netzwerkverbindungen
Unzureichende HR Prozesse
Unzureichendes Legal Management
Bedrohungen:
Verletzung von vertraglichen Regelungen
Verletzung von Rechtsvorschriften (Lizenzverstöße, Urheberrechtsverletzungen, BDSG)
Verletzung von Unternehmensrichtlinien
Kompromittierung vertraulicher Informationen, Offenlegung von Information, Informationsleck
Verschleierung der Benutzeridentität, Offenlegung von Passwörtern, Social Engineering
Schäden, die durch Dritte verursacht wurden (Vandalismus, Zerstörung von Aufzeichnungen etc.)
Fehler bei der Wartung (Fehlkonfiguration, Updates, Penetrationstests etc.)
Ausfall von Kommunikationsverbindungen
Fälschung von Aufzeichnungen
Unterbrechung der Geschäftsprozesse (Bombendrohung, Pandemie, Feuer, Stromausfall etc.)
Fehlfunktionen von Geräten
bösartiger Code (Viren, Trojaner etc.)
Software-Fehler
Diebstahl, Betrug, Unterschlagung, Lauschangriff, Industriespionage
Unberechtigter Zugriff auf das Informationssystem, Mißbrauch von Informationssystemen
Nicht autorisierte Änderungen von Datensätzen
Unerlaubte Installation von Software
Unbefugter physischer Zugang
Anwenderfehler (Eingabefehler etc.)
Diese Bedrohungen und Schwachstellen sind bewusst generisch gehalten. Dadurch sind sie allgemein anwendbar.
Werden jetzt die Assets mit den Schwachstellen kombiniert entsteht ein klares Bild des Angriffsvektors. Werden darauf dann die Bedrohungen angewandt kann schnell erkannt werden, welche tatsächlichen Risiken existieren. Dabei soll natürlich der Blick für das Wesentliche nicht verloren gehen. Es sollen nur Bedrohungen angenommen werden, die auch tatsächlich existieren. Ein Fahrrad kann kaum von einem Software-Fehler betroffen werden. Bei einem Panzer können die Folgen jedoch verhehrend sein. Software-Fehler können durch verschiedene Schwachstellen begünstigt werden, z.B. Unkontrollierter Nutzung des Internet, Unzureichendes Change Management, Unzureichendes Sicherheitsbewusstsein, Ausbildung, Motivation oder Unzureichende Kontrolle der Mitarbeiter/Anbieter. Existieren diese Schwachstellen entsteht dadurch das Risiko, dass der Panzer durch einen Softwarefehler unkontolliert durch die Gegend fährt und Gebäude platt macht oder wild um sich schießt. Beides hätte drastische Folgen und wäre ein Verletzung der Informationssicherheit.
Ein letzter Punkt zur Risikoidentifikation. Es ist wirklich wichtig eine klare Unterscheidung zwischen Schwachstelle, Bedrohung und Risiko zu haben. In vielen Unternehmen werden Schwachstellen bereits als Risiko gesehen oder die Begriffe werden vermischt. Für die anschließende Risikobehandlung ist es aber essentiell diese Begriffe sauber zu trennen, denn die Behandlung von Risiken kostet Zeit und Geld und soll zielgerichtet sein. Maßnahmen können sich gegen Schwachstellen richten, Folgen oder Eintrittswahrscheinlichkeit reduzieren oder sogar Bedrohungen ausschalten. Je genauer das spezifiziert werden kann umso höher die Erfolgchancen.
