Risikoanalyse im IT-Grundschutz

Von Christian Friedrich und Robert Manuel Beck, Berlin

Bei vielen Sicherheitskonzepten nach BSI-Standard 100-x wurden Risikoanalysen bisher als notwendiges Übel erachtet. Neben Strukturanalyse, Schutzbedarfsfeststellung, Interviews in den Basissicherheitschecks und der Umsetzung von Sicherheitsmaßnahmen kam mit der Risikoanalyse weiterer Abstimmungsaufwand hinzu. Ein Grund hierfür war vor allem, dass in der vorherrschenden Praxis des BSI-Standards 100-3 oft hunderte Gefährdungen der Gefährdungskataloge ausgewertet wurden. Mit der Einführung der Elementargefährdungen hat sich diese Komplexität deutlich vermindert – ein Schritt in die richtige Richtung! Dennoch wurde im Rahmen der ergänzenden Sicherheitsanalyse streng auf die Notwendigkeit von Risikoanalysen geachtet, um den Erhebungsaufwand zu minimieren.

Mit der neuen IT-Grundschutz-Vorgehensweise nach BSI-Standard 200-2 fällt die ergänzende Sicherheitsanalyse weg und Risikoanalysen sind unter den entsprechenden Voraussetzungen nunmehr verpflichtend. Hier stellen der BSI-Standard 200-3 sowie möglicherweise auch alternative Standards eine sinnvolle Ergänzung dar, welche die Risikoanalysen zu einem effektiven Werkzeug machen.

Bedeutung

Obwohl der IT-Grundschutz nach eigener Aussage „vollständig kompatibel mit der Norm ISO/IEC 27001“ ist, spielt die Risikoanalyse in den beiden Vorgehensweisen eine leicht unterschiedliche Rolle. Während bei der ISO/IEC 27001 die Risikoanalyse das zentrale Element bei der Definition notwendiger Maßnahmen ist, erfolgt die Maßnahmendefinition beim IT-Grundschutz durch die Auswahl der relevanten IT-Grundschutzbausteine. Bei der Erstellung dieser Bausteine wurde bereits eine Risikoanalyse für die typischen Einsatzszenarien des jeweiligen Zielobjekts bei normalem Schutzbedarf durchgeführt, sodass grundlegende Maßnahmen bereits feststehen.

Die Aufgabe der Risikoanalyse im IT-Grundschutz besteht jetzt darin, für alle Zielobjekte mit höherem Schutzbedarf, ohne passende IT-Grundschutzbausteine oder mit besonderem Einsatzszenario die jeweiligen Gefährdungen im Hinblick auf die Eintrittswahrscheinlichkeit und Schadenshöhen zu analysieren. Es soll bewertet werden, ob die zugeordneten Basis- und Standardanforderungen genügen, um die jeweiligen Gefährdungen ausreichend zu mindern. Bei der Bewertung der Anforderungen ist es an dieser Stelle unerheblich, ob sie bereits umgesetzt sind. Sofern sie zu einem späteren Zeitpunkt umgesetzt werden sollen, interessiert nur, ob über diese Anforderungen hinaus noch weitere Schritte zur Risikobehandlung notwendig sind.

Für die Risikobehandlung stehen vier Vorgehensweisen zur Verfügung:

• Risikovermeidung (Umstrukturierung des Geschäftsprozesses oder des Informationsverbunds)
• Risikoreduktion (Umsetzung geeigneter Sicherheitsmaßnahmen)
• Risikotransfer (Auslagerung der Dienstleistung oder Abschließen einer Versicherung)
• Risikoakzeptanz (Akzeptieren der bestehenden Restrisiken)

In der Regel wird versucht, zusätzliche Maßnahmen zu finden – etwa die sogenannten „Hochschutzmaßnahmen“ aus den IT-Grundschutzbausteinen oder aber individuelle Vorkehrungen.

Die Risikoanalyse ist für die Verantwortlichen eine gute Gelegenheit, das Zusammenspiel von Maßnahmen bei den unterschiedlichen Zielobjekten zu hinterfragen. Durch zusätzliche Maßnahmen lassen sich dann die generischen Anforderungen des IT-Grundschutzes auf die jeweiligen Verbünde individuell anzupassen.

Eine Besonderheit stellt der Realisierungsplan für die nicht umgesetzten Maßnahmen dar: Laut BSI-Standard 200-2 muss für nicht umgesetzte Maßnahmen das „Restrisiko aufgezeigt“ und eine „Entscheidung der Leitungsebene“ eingeholt werden. Die Nachvollziehbarkeit dieser bestehenden Risiken ist laut Auditplan auch im Rahmen einer Zertifizierung durch einen Auditor zu prüfen. Außer der Anforderung, dass diese Risiken „nachvollziehbar“ sein müssen, gibt es keine Vorgaben – dementsprechend könnte man auch ein simples Verfahren wie die einfache Beschreibung der Restrisiken definieren und anwenden. Es empfiehlt sich aber zur besseren Kategorisierung eine qualitative Bewertung der vorhandenen Risiken vorzunehmen. Dies könnten beispielsweise die Stufen hoch („Es besteht eine unmittelbare Gefahr für die Organisation.“) und mittel („Eine langfristige Gefährdung kann nicht ausgeschlossen werden.“) sein.

Alternativen zu BSI 200-3

Die IT-Grundschutz-Vorgehensweise nach BSI-Standard 200-2 lässt grundsätzlich offen, welche Risikomanagementmethode eingesetzt wird. Die Methode nach BSI-Standard 200-3 stellt hier lediglich eine Empfehlung dar – diese wurde allerdings speziell für die IT-Grundschutz-Vorgehensweise entwickelt und ist dementsprechend optimal in die Vorgehensweise eingebettet. Aber auch andere Methoden lassen sich in die IT-Grundschutz-Vorgehensweise integrieren und können somit die Methode nach BSI-Standard 200-3 ersetzen.

Berücksichtigung von Abhängigkeiten

Die konkrete Auswahl einer alternativen Methode wird in der Regel abhängig von unterschiedlichen Anforderungen und Parametern der jeweils anwendenden Organisation sein. Allem voran dürften die voraussichtlich vorhandenen Strukturen des Unternehmensrisikomanagements (z. B. Schnittstelle zum operationellen Risikomanagement) die Auswahl beeinflussen. Darüber hinaus können aber auch andere Aspekte, wie die Organisationsstruktur oder verfügbare personelle Ressourcen, für die Auswahl relevant sein.

Einbettung in die IT-Grundschutz-Vorgehensweise

Bei der Auswahl, Anpassung und Einbettung einer alternativen Methode gilt es, die Hintergründe und Anforderungen der IT-Grundschutz-Vorgehensweise zu berücksichtigen. Nach der IT-Grundschutz-Vorgehensweise werden die Zielobjekte eines Verbundes identifiziert (IT-Strukturanalyse), ihr Schutzbedarf bewertet (Schutzbedarfsfeststellung), Anforderungen aus den IT-Grundschutz-Bausteinen zugeordnet (Modellierung) sowie Maßnahmen abgeleitet. Diese Anforderungen entsprechen bei einer Standard- oder Kernabsicherung mindestens einem „normalen“ Schutzbedarf. Darüber hinaus werden im Rahmen des IT-Grundschutz-Kompendiums auch exemplarische Anforderungen für einen erhöhten Schutzbedarf zugeordnet.

Ein erhöhter Schutzbedarf leitet sich aber in der Regel aus individuellen Parametern der jeweiligen Organisation her: Die Definition der Schutzbedarfsklassen und die Einschätzung der jeweiligen Zielobjekte sind normalerweise in jeder Organisation anders. Für Zielobjekte mit einem höherem Schutzbedarf muss man daher überprüfen, ob der durch die Modellierung individuell zusammengestellte Anforderungs- beziehungsweise Maßnahmenkatalog auch für die eigene Definition des höheren Schutzbedarfs ausreichend ist. Das dadurch bestehende Restrisiko soll transparent gemacht und eine entsprechende Risikobehandlung geplant werden – dazu dient im Rahmen der IT-Grundschutz-Vorgehensweise die Risikoanalyse.

Dementsprechend sollte man eine Risikomanagementmethode wählen, die sich in die IT-Grundschutz-Vorgehensweise einbetten lässt. Hierzu sollte es die auszuwählende Methode ermöglichen, anhand der vorhandenen Maßnahmen aus den IT-Grundschutz-Bausteinen das Restrisiko zu bewerten und dadurch die geeigneten Behandlungsalternativen (Risikovermeidung, Risikoreduktion, Risikotransfer oder Risikoakzeptanz) auszuwählen. Die Maßnahmen für die Risikoreduktion sollten dann wiederum in die weiteren Phasen der IT-Grundschutz-Vorgehensweise überführt werden können, um so deren Nachverfolgung integriert im Risikobehandlungsplan oder als dessen Ergänzung zu ermöglichen. Darüber hinaus empfiehlt es sich zu prüfen, ob sich Ergebnisse der vorangegangenen Phasen der IT-Grundschutz-Vorgehensweise (z. B. IT-Strukturanalyse oder Schutzbedarfsfeststellung) sinnvoll als Input nutzen lassen.

Ein guter Indikator für die mögliche Einbettung in die IT-Grundschutz-Vorgehensweise könnte auch die internationale Norm ISO/IEC 27005 bieten. Entgegen einer weitverbreiteten Meinung enthält die ISO/IEC 27005 keine konkrete Risikoanalyse-Methode: Vielmehr stellt sie eine generische Vorgehensweise für das Informationssicherheitsrisikomanagement dar, welche die Risikoanalysemethode selbst offenlässt. Die Norm stellt lediglich in Anhang E beispielhaft zwei Risikoanalyse- beziehungsweise -bewertungsmethoden vor.

Der BSI-Standard 200-3 ist in diesem Zusammenhang mit der allgemeinen Vorgehensweise der ISO/IEC 27005 weitestgehend kompatibel. Dementsprechend sind auch viele Methoden weitestgehend in die generische Vorgehensweise nach ISO/IEC 27005 integrierbar, welche die folgenden Schritte vorsieht:

• Kontext etablieren
• Risikoidentifikation
• Risikoanalyse
• Risikobewertung
• Risikobehandlung
• Risikoakzeptanz
• Risikokommunikation und -beratung
• Überwachung und Überprüfung

Viele Details der ISO/IEC 27005 werden durch die Vorgehensweise nach BSI-Standard 200-3 ebenfalls umgesetzt, jedoch nicht alle (beispielsweise erfolgt nach BSI-Standard 200-3 eine Identifikation von Bedrohungen und Schwachstellen nicht separat, sondern implizit durch die eher allgemein gefassten Gefährdungen). Dennoch stellt die Kompatibilität einer alternativ auszuwählenden Risikomanagementmethode zur ISO/IEC 27005 einen guten Indikator für die Möglichkeit zur Anwendung im Rahmen der IT-Grundschutz-Vorgehensweise dar.

Weiterhin sollte man berücksichtigen, ob die ausgewählte Methode eine Bewertung anhand der Erhebung und Verarbeitung konkreter Zahlenwerte (quantitative Bewertung) oder anhand von Bewertungsklassen oder nominalen Parametern (qualitative Bewertung) vorsieht. Eine quantitative Methode ist zumeist detaillierter und aussagekräftiger, bedeutet dafür in der Regel aber auch einen höheren Erhebungs- und Verarbeitungsaufwand.

Demgegenüber sind qualitative Methoden oftmals einfacher einzusetzen, die Ergebnisse jedoch unschärfer. Die Methode nach BSI-Standard 200-3 ist zwar eine qualitative Methode, für den Einsatz im Rahmen des IT-Grundschutzes eignen sich aber beide Prinzipen.

Alternative Risikoanalyse-Methoden

Drei beispielhafte alternative Risikoanalyse-Methoden sind in Tabelle 1 skizziert. Die genannten Methoden sehen grundsätzlich die Bewertung der vorhandenen Maßnahmen vor und ermöglichen es so, neue Maßnahmen zu identifizieren.

Je nach Auswahl und Anwendung kann eine alternative Methode gegenüber dem BSI-Standard 200-3 Vorteile bringen:

• Die Methode könnte einfacher und effizienter in der Anwendung sein.
• Sie kann transparenter und aussagekräftiger sein.
• Die Methode könnte sich besser in das bereits vorhandene Risikomanagement der Organisation integrieren.
• Die Methode könnte im vorhandenen ISMS-Tool bereits implementiert und in den IT-Grundschutz integrierbar sein.

Allerdings könnten sich hierbei auch Nachteile ergeben:

• Die Dokumentation und weitere Ressourcen zu alternativen Standards könnten nur eingeschränkt oder kostenpflichtig verfügbar sein.
• Das jeweils verwendete ISMS-Tool könnte ggf. nicht in der Lage sein, den gewünschten Standard umzusetzen und so Medienbrüche erfordern.
• Die alternative Methode könnte aufwendiger sein.
• Sie könnte weniger transparent und weniger aussagekräftig sein.
• Die Methode könnte sich schlechter in das bereits vorhandene Risikomanagement der Organisation integrieren.

Für den BSI-Standard 200-3 spricht, dass die Dokumentation kostenlos im Internet zur Verfügung steht. Zudem ist die Methode in den meisten IT-Grundschutz-Risikoanalyse-Tools bereits implementiert. Hierbei sind teilweise auch Mechanismen enthalten, bei denen beispielsweise Gefährdungen (hier: Elementargefährdungen) und implementierte IT-Grundschutz-Maßnahmen (über Kreuzreferenztabellen) automatisiert herangezogen werden – das bietet Effizienzvorteile.

Praktische Hinweise

Unabhängig von der angewendeten Methode kommt es bei der praktischen Durchführung von Risikoanalysen immer wieder zu Herausforderungen, bei denen die nachfolgenden Hinweise hilfreich sein können.

Die Grundlage einer jeden Risikoanalyse stellt die Auswahl der befragten Personen dar. Hier kann es sinnvoll sein, zwischen der Schadensbewertung und der Bewertung der Eintrittswahrscheinlichkeit aufzuteilen: Die fachlich Verantwortlichen können meist am besten beurteilen, wie sich Schäden hinsichtlich Vertraulichkeit, Integrität, Verfügbarkeit oder ergänzender Grundwerte auf Geschäftsprozesse oder die verarbeiteten Informationen auswirken. Demgegenüber sollte die Bewertung der Eintrittswahrscheinlichkeit durch technische oder Asset-Verantwortliche erfolgen, die besser einschätzen können, ob der aktuelle Zustand überhaupt zum Schadensszenario führen kann.

Risiken auch als Chancen sehen

Es ist unbedingt darauf zu achten, den Befragten von vornherein etwaige Ängste zu nehmen: Denn für viele Mitarbeiter erscheint eine solche Befragung wie eine Bewertung ihrer Leistung. Sie haben zudem oft das Gefühl, die möglichen Auswirkungen nicht vertreten zu können. Zu Beginn der Risikoanalysen sollte daher eine gesunde Fehlerkultur eingeführt sein und der kontinuierliche Verbesserungsprozess beginnen. Dies bedeutet allerdings, dass ein perfekter erster Wurf in der Regel nicht möglich ist. Zudem verändern sich die Rahmenparameter in der Regel ständig: Daher sollte man – analog zu einem ISMS – grundsätzlich akzeptieren, dass Risikomanagement und -analysen in regelmäßigen Korrekturzyklen angepasst, korrigiert und optimiert werden müssen. Es sollte immer klar sein, dass gefundene Risiken etwas Positives für die jeweilige Organisation sind, da nun reagiert werden kann. Gleichzeitig ist dies eine Möglichkeit für Mitarbeiter, bekannte Missstände zu dokumentieren und Gegenmaßnahmen vorzuschlagen.

Hinreichend konkret und praxisnah

Zudem müssen sowohl im Vorfeld die Kriterien als auch nach der Bewertung die Risiken gut beschrieben sein und eine ausreichende Kommentierung erfolgen. Hier sollte man darauf achten, dass der sprichwörtliche „sachverständige Dritte“ alles nachvollziehen kann. Es sollten möglichst konkrete Werte für die Einschätzung von Schadenshöhen (z. B. 500.000 €, mehr als 10 % vom Jahresumsatz etc.) und Eintrittswahrscheinlichkeiten (z. B. „öfter als zweimal pro Monat“, „täglich“ etc.) gewählt werden.

Für die Bewertung der Risiken ist ein „realistischer Worst Case“ gefragt. Dementsprechend sollte im Rahmen der Risikoanalyse nicht davon ausgegangen werden, dass immer alles gut wird – dies führt nur dazu, dass scheinbar gar keine Risiken vorhanden sind. Man sollte aber auch nicht zu viele Abhängigkeiten mit in die Betrachtung einbeziehen (z. B. „Wenn es anfängt zu brennen und wenn der Feuermelder nicht auslöst und wenn der Wachschutz gerade im anderen Gebäude patrouilliert, kann ein sehr hoher Schaden entstehen.“), sonst erhält man unrealistische Ergebnisse und kann zur Abschreckung der Befragten beitragen.

Es kann ebenfalls geschehen, dass Gefährdungen in unterschiedlichen Szenarien betrachtet werden müssen: So hat ein Diebstahl von Server-Systemen zum Beispiel eine geringe Wahrscheinlichkeit, aber dafür potenziell einen hohen Schaden – der Diebstahl von Notebooks ist hingegen recht wahrscheinlich, bedeutet aber gegebenenfalls nur einen geringen Schaden, wenn die Datenträger verschlüsselt sind. Diese beiden Szenarien sind unterschiedlich zu betrachten und machen gegebenenfalls auch unterschiedliche Maßnahmen erforderlich.

Darüber hinaus ist eine Einigung empfehlenswert, wie nach der Bruttobewertung die Nettobewertung von Risiken erfolgt, also die Bewertung nach Zuordnung zusätzlicher Maßnahmen. Hierbei gibt es unterschiedliche Philosophien hinsichtlich der Wirkung zusätzlicher Sicherheitsmaßnahmen: Senken beispielsweise redundante Rechenzentren maßgeblich die Eintrittswahrscheinlichkeit oder auch den Schaden eines Ausfalls? Hier gibt es unterschiedliche Interpretationen, die aber im Vorfeld festgelegt werden sollten, um zu einheitlichen und vergleichbaren Ergebnissen zu führen.

Allgemeine Erfahrungen

• Um die Bewertung transparenter zu gestalten, hat sich die „klassische Statistikregel“ für Umfragen bewährt: Man sollte eine gerade Anzahl von Bewertungsstufen wählen, sodass es keine „Mitte“ gibt, die im Zweifel gerne gewählt wird – so muss sich der jeweilige Verantwortliche zumindest für eine Tendenz entscheiden.
• Für die Bewertung des Schadenspotenzials sollte immer auch der bereits bewertete Schutzbedarf herangezogen, allem voran auf eine Plausibilität von Schutzbedarf und Schadensbewertung geachtet werden. Der Schutzbedarf stellt ja schlussendlich eine Obergrenze für das Schadenspotenzial dar – es sollte also nicht passieren, dass ein Risiko hinsichtlich des Schadens höher eingeschätzt wird als der initiale Schutzbedarf.
• Um eine grundlegende Einheitlichkeit am Anfang zu erreichen, ist es sinnvoll, Risikoanalysen zunächst in gelenkten Workshops durchzuführen. Hierbei werden die jeweiligen Mitarbeiter eingebunden, bis ein einheitliches Verständnis von Vorgehensweise, Dokumentation und Bewertung entsteht.
• Die bisherigen Erfahrungswerte über eingetretene Schadensfälle sind ein wichtiges Indiz für die Bewertung der Eintrittswahrscheinlichkeit. Sie dürfen aber nicht das Einzige sein: Gab es beispielsweise bisher keine Einbrüche, lässt sich daraus nicht folgern, dass das auch zukünftig so bleibt.
• Für eine Vereinfachung der Risikoanalyse kann es sinnvoll sein, diese auf einer höheren Ebene der IT-Grundschutzschichten durchzuführen und dabei die darunterliegenden Schichten zu berücksichtigen. Eine Risikoanalyse könnte etwa am Geschäftsprozess oder an den Anwendungen durchgeführt werden und die darunterliegenden Zielobjekte mit betrachten. Dadurch wird im Rahmen der Risikoanalyse eine ganzheitlichere Sicht ermöglicht. Wenn beispielsweise hinsichtlich der Vertraulichkeit ein höherer Schutzbedarf besteht, lässt sich so besser entscheiden, ob eine Verbindungsverschlüsselung in der Anwendung (z. B. per SSL), auf dem System (z. B. per integriertem IPSec-Tunnel) oder über einen VPN-Tunnel einer Netzwerkkomponente implementiert werden soll.

Fazit

Risikoanalysen im IT-Grundschutz dienen insbesondere dazu, die mögliche Lücke der IT-Grundschutz-Maßnahmen zum individuell notwendigen Sicherheitsniveau bei höherem Schutzbedarf, bei fehlenden IT-Grundschutz-Bausteinen oder bei speziellen Einsatzszenarien zu schließen. Zudem ermöglichen sie es, verbleibende Restrisiken transparent darzustellen und somit eine Übersicht über das Sicherheitsniveau eines Konzepts zu geben.

Hierbei muss allerdings unterschieden werden: Risikoanalysen beschreiben in der IT-Grundschutz-Vorgehensweise die Restrisiken im Soll-Sicherheitsniveau eines Informationsverbunds. Demgegenüber umfasst der Risikobehandlungsplan (bzw. Realisierungsplan) die Restrisiken aus den offenen Maßnahmen der IT-Grundschutzbausteine und der Risikoanalysen und somit das Ist-Sicherheitsniveau. Dementsprechend ist es auch sinnvoll, langfristig zu behandelnde Risiken bereits in den Risikoanalysen zu betrachten und kurz- bis mittelfristig zu behandelnde Risiken über die Maßnahmen im Risikobehandlungsplan.

Eine Methode für die Risikoanalysen stellt der BSI-Standard 200-3 dar, der durch seine Integration in die IT-Grundschutz-Vorgehensweise gut geeignet ist. Dies gilt vor allem dann, wenn keine spezifischen Vorgaben existieren oder keine Basis vorhanden ist. Zudem steht der Standard kostenlos zur Verfügung und ist in einigen IT-Grundschutz-kompatiblen Software-Tools bereits integriert.

Grundsätzlich kann die Integration einer alternativen Methode aufwendig sein (z. B. Tool-Integration), aber je nach Organisation sogar zu einem besseren Ergebnis führen – vor allem bei vorhandenen und etablierten Methoden kann man damit aufschlussreiche Antworten über die Risikosituation einer Organisation erhalten. Die richtige Wahl kann eine Organisation nur selbst treffen – sie sollte aber gut durchdacht sein.

Christian Friedrich ist Senior Expert, Robert Manuel Beck ist Team Manager und Managing Consultant im Bereich Security Consulting der HiSolutions GmbH.

Literatur

[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), BSI-Standards, https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzStandards/ITGrundschutzStandards_node.html
[2] Carnegie Mellon University Software Engineering Institute, OCTAVE-Related Assets, https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=309051
[3] Karl Pausch, Risikoanalyse per OCTAVE, <kes> 2005#4, S. 15, online auf http://previous.kes.info/archiv/heft/abonnent/05-4/05-4-015.htm
[4] OpenGroup, Security Standards zu Risk Taxonomy (O-RT) und Risk Analysis (O-RA), verfügbar über https://publications.opengroup.org/standards/security
[5] OpenGroup, Open FAIR – ISO/IEC 27005 Cookbook, Technical Guide, https://publications.opengroup.org/c103
[6] Deutsche Gesellschaft für Qualität e. V. (DGQ), FMEA – Fehlermöglichkeits- und Einflussanalyse, DGQ-Band 13-11, Mai 2012, ISBN 3-410-32333-3
[7] Matthew Barsalou, Dipl.-Ing. Heinz Günter Kehl, Grundlagen der Fehlermöglichkeits- und Einfluss-Analyse, QZ-Online, www.qz-online.de/qualitaets-management/qm-basics/methoden/fmea/artikel/grundlagen-der-fehlermoeglichkeits-und-einfluss-analyse-903982.html