Wege zur Risikoanalyse

„Wer den Schaden hat, braucht für den Spott nicht zu sorgen“, weiß der Volksmund – doch wie riskant ist der Spott, wie wahrscheinlich der Schaden? Hierzu kann der Volksmund keine exakte Definition beisteuern. Gemeinhin wird „Risiko“ jedoch oft als Produkt von Eintrittswahrscheinlichkeit und Schadenshöhe verstanden – eine grob vereinfachte Form des sogenannten Erwartungswerts der Statistik.

Die internationale Risikomanagement-Norm ISO 31000 definiert Risiko hingegen genau wie der IT-Risikomanagement-Standard ISO 27005 als die Auswirkung von Unsicherheit auf das Erreichen gesetzter Ziele. Abweichungen können dabei sowohl positiv als auch negativ ausfallen, sodass das „Risiko“ hier auch als Dimension von Chancen fungieren kann.

„Risikomanagement“ umfasst in diesem Rahmen die Gesamtheit der systematischen Aktivitäten zur Steuerung des Risikos in einer Organisation, während „Risikoanalyse“ denjenigen Teil davon meint, der Risiken identifiziert, versteht und bewertet. Ein mehr oder minder mathematischer Erwartungswert ist dabei nur eine von vielen möglichen Methoden.

Qualitativ oder quantitativ?

Am häufigsten entbrennen Glaubenskriege beim Thema Risikoanalyse an der Frage, ob die Bewertung qualitativ oder quantitativ vorzunehmen ist. Sowohl ISO 31000 als auch ISO 27005 erlauben beides, sodass auch keine Vorgabe zwingend auf die ISO 27001 abfärbt. Allerdings sind die Unterschiede in der Praxis kleiner, als es zunächst scheint: Am Ende bedarf es ja immer einer Abbildung, also einer exakten Zuordnung zu einem Risikolevel. Diese muss zwar nicht durch Multiplikation geschehen, aber auch hinter den in der Regel genutzten Risikomatrizen stecken mathematisch gesehen meist entweder implizites „Malnehmen“ oder andere einfache Rechenoperationen.

Diejenigen Risikomatrizen, die sogar noch häufiger eingesetzt werden als multiplikative (z. B. wie in Tab. 1), beruhen sogar lediglich auf einer simplen Addition (z. B wie in Tab. 2). Vermutlich sind sie deshalb so weit verbreitet, weil sie sich grafisch leicht durch Ziehen von Geraden erzeugen lassen, sie also – anders ausgedrückt – „gerade“ erscheinen. Wahre multiplikative Risikomatrizen beruhen hingegen auf Hyperbeln, also Kurven, der Form y := r/x (da x · y ja konstant sein soll).

All das hat den theoretisch interessanten Effekt, dass ein Großteil der Anwender von Risikoanalysemethoden meint, eine Definition des Risikos als Produkt zugrunde zu legen, aber in der Praxis Werkzeuge verwendet, die das Risiko als Summe modellieren. Der praktische Effekt ist, dass das Summen-Risiko vor allem seltene, aber fatale, sowie sehr häufige, aber unkritische Ereignisse überbewertet (siehe fett gedruckte Felder in Tab. 2) und daher tendenziell zur Vergeudung von Ressourcen beitragen kann.

Auch bei sogenannten qualitativen Skalen lässt sich beobachten, dass typische Vertreter etwa für die Eintrittswahrscheinlichkeit oder für bestimmte Kategorien von Schadensereignissen (z. B. finanzielle Schäden) meist quantitative Aussagen enthalten, etwa zur Eintrittswahrscheinlichkeit:

• Stufe 1: seltener als einmal alle 10 Jahre
• Stufe 2: seltener als einmal im Jahr
• Stufe 3: seltener als einmal im Monat
• Stufe 4: häufiger als einmal im Monat

Im Grenzwert, also bei Erhöhung der Anzahl der Stufen, würde sich ein solches Verfahren dem quantitativen immer weiter annähern. Im Unterschied zur quantitativen Risikoanalyse, bei der die Schwierigkeit im Bestimmen genauer Werte liegt, verschiebt sich hier das Problem auf die Zuordnung der Grenzfälle zu den Stufen, was in der Praxis ebenfalls gravierende Auswirkungen haben und ein gewisses Maß an Willkür – positiv ausgedrückt „Gestaltungsspielraum“ – bedeuten kann

Arten der Risikoanalyse

Gnadenlos: Mindestanforderungen

Die einfachste Form der Risikoanalyse ist: keine Risikoanalyse – Abbildung 1: Security-Level nach IEC/TS 62443-1-1 zumindest keine, die selbst durchzuführen wäre. Mindestanforderungen zeichnen sich dadurch aus, dass sie für den jeweiligen Scope grundsätzlich und vollständig umzusetzen sind. Möglicherweise hat jemand bei der Erstellung einmal eine (abstrakte) Risikoanalyse vorgenommen; dem Anwender bleibt diese Arbeit (und damit auch die Wahl) dann nicht mehr. Dies trifft etwa für einen großen Teil der De-facto-Standards in der RFC-Dokumentenserie (Requests for Comments) der Internet Engineering Task Force (IETF) zu – ebenso wie für viele domänenspezifische Standarddokumente.

Relativiert wird die Strenge von Mindestanforderungen häufig durch eine ebenfalls im RFC-Prozess genauestens definierte Sprachregelung: Anforderungen, die mit dem Verb „sollte(n) (nicht)“ (engl. „shall [not]“ und lt. RFC beim definitorischen Einsatz VERSAL zu setzen) einhergehen, sind ebenso umzusetzen wie solche mit „muss (nicht)“ und „darf (nicht)“ – es sei denn, man kann begründen, warum dies nicht möglich ist. Ob dies nun eher eine Aufweichung der Anforderungen oder eine notwendige Anpassung der Standardisierung oder Zertifizierung an die Realität bedeutet, lässt sich trefflich diskutieren. Sicher ist, dass hier ein Stück Praxistauglichkeit erzeugt wird – auf Kosten einer Zwei- (oder Drei-) Klassengesellschaft von Anforderungen.

Viel Arbeit: Explizite Risikoanalyse

Was vielen Experten als „Kür“ der Security gilt – eine explizite Risikoanalyse –, ist in der Praxis sehr viel Arbeit: Denn sie umfasst die Bestimmung aller zu schützenden Werte sowie die Betrachtung aller relevanten Bedrohungen für jeden einzelnen davon. Wie immer, wenn mehrere Dimensionen – hier (Anzahl der) Assets mal (Anzahl der) Bedrohungen – ins Spiel kommen, ergibt sich großer Aufwand.

Dafür besteht bei diesem Vorgehen maximale Kontrolle über den Prozess, und die Erfahrung von Experten – sofern vor Ort vorhanden – kann konkret eingehen. Zudem gibt es eine ganze Reihe handwerklicher Tricks wie etwa das Clustering von Assets, um den Aufwand doch etwas zu verringern.

In der ISO 27001 etwa wird zwar per Verweis auf die Grundsätze der ISO 31000 keine bestimmte Methode vorgegeben, aber es ist in jedem Fall eine Risikoanalyse durchzuführen, die bestimmten Kriterien entspricht.

Pareto-Prinzip: IT-Grundschutz

Der IT-Grundschutz als spezifisch deutsche Variante der ISO 27001 versucht, den Aufwand durch eine Kombination der bei- den Methoden zu begrenzen: Der Basisschutz wird im Wesentlichen als Mindestanforderungen definiert, einschließlich der Möglichkeit, Maßnahmen als „entbehrlich“ wegzuargumentieren. Für höheren Schutzbedarf und besondere Anwendungsfälle ist aber nach wie vor eine Risikoanalyse durchzuführen.

Die IT-Grundschutz-Methode impliziert, dass die Risikoanalyse für „normalen“ Schutzbedarf durch die Autoren des Standards pro Zielobjekttyp einmal a priori generisch durchgeführt worden ist. Die 80:20-Methode kann in der Praxis tatsächlich erheblichen Aufwand beim Sicherheitskonzept einsparen.

Mehrstufig: Security-Level

Denkt man das Modell der Mindestanforderungen in Richtung höheren Schutzbedarfs weiter, so kann man versuchen, weitere Stufen der Absicherung zuzuschneiden und in Maßnahmenpakete zu verpacken, deren Anwendung eine explizite Risikoanalyse bei Einhaltung der jeweiligen Normalparameter ersparen soll. Dieses Modell der Security Levels (SL), das von den Safety-Integrity-Levels (SIL) aus der Safety bekannt ist, hat in der Industrial Security etwa in Teilen der Normenreihe IEC 62443 „Industrial communication networks – Network and system security“ Einzug gehalten (vgl. Abb. 1)

Diese Vorgehensweise zielt auf ein „Best of Both Worlds“, indem sie dem Anwender die konkrete Risikoanalyse der einzelnen Assets erspart. Dieser hat lediglich Risikoanalysen aggregierter Strukturen (in IEC 62443-3-3 einer Anlage, in IEC 62443-4-2 einer Komponente) vorzunehmen – die Auswahl der Maßnahmen ergibt sich dann automatisch.

Drei Dinge fallen daran auf:

• Zum einen wird die Anzahl der Stufen zumindest potenziell immer weiter erhöht: Noch spricht der Standard an den meisten Stellen von vier SLs, aber konzeptionell sind Security-Levels bereits als Vektoren mit sieben Komponenten gedacht – und zwar mit einem SL-Wert je sogenanntem „Foundational Requirement“, dass in etwa Sicherheitszielen entspricht (Authentifizierung, Vertraulichkeit, Verfügbarkeit, Integrität, Responsefähigkeit etc.). Theoretisch sind also 4 7 = 16 384 verschiedene SLs möglich, was in den meisten Fällen die Anzahl der (aggregierten) Assets deutlich übersteigen dürfte.
• Zweitens wird im Teilstandard IEC 62443-3-2 darauf hinge – arbeitet, dass die Bestimmung der SLs gleichzeitig mit der Erstellung des Zonenkonzepts vorgenommen werden soll und individuell je Zone erfolgt. Genauer gesagt bedeutet eine Risikoanalyse nach Teil 3-2 eine untrennbare Einheit dieser beiden Arbeitsschritte.
• Außerdem kommen inzwischen noch weitere, nämlich prozessuale Dimensionen zu den SLs hinzu: In die sogenannten Protection-Levels (PL) fließen demnach neben technischen Anforderungen auch ISMS-Reifegrade mit ein.

Insgesamt zeigt sich also, dass eine einfache Einstufung in SLs allein heute immer weniger als ausreichend angesehen wird. Anstatt sich auf die ISO 27001 zurückzubesinnen und eine asset- oder prozessbasierte Risikoanalyse zu fordern, verfolgt die IEC 62443 aber dennoch den Weg, das Konzept der SLs immer weiter auszubauen.

Fazit

Bis heute hat sich nicht „die eine“ allgemein akzeptierte Risikoanalysemethodik herausgebildet. An dieser Stelle gibt sich die Security-Zunft eher wie ein Handwerk, wenn nicht gar eine Kunst. Das muss nicht schlecht sein, denn so wird immer ein Experte benötigt, der hoffentlich möglichst viel von seinem Wissen und seiner Erfahrung in den jeweiligen Prozess einfließen lässt. Und der IT-Grundschutz bietet demjenigen, der ein gutes Stück der Arbeit selbst machen möchte, mehr als genug Vorgaben und Material, um eine Basissicherheit zu schaffen.

Andererseits zeigen die fort – dauernden Diskussionen und Weiterentwicklungen der Methodik in der IEC 62443, dass zumindest im Bereich der Automatisierung noch Bedarf an neuen Konzepten und der Schärfung vorhandener Begrifflichkeiten besteht. Spannend bleibt, was daraus nach eingehender Prüfung für die allgemeine Security verwendbar sein wird – hier ist also die Industrial-Security einmal theoretische Vorreiterin der IT-Sicherheit.

Bedarf an neuen Risikoanalyseverfahren besteht jedenfalls auch anderweitig – hier seien abschließend nur drei Beispiele genannt:

• Die voranschreitende Auslagerung in die Cloud stellt das Prinzip, den Schutzbedarf zunächst für Informationen und Prozesse zu erheben und diesen dann auf die Infrastruktur zu vererben, zunehmend infrage.
• Schwachstellen in Prozessoren (Meltdown, Spectre & Co.) so – wie Backdoors in Befehlssätzen (Intel „God Mode“) deuten darauf hin, dass Assets modularer verstanden und analysiert werden müssen.
• „Intelligente“ Systeme wie Autos oder Herzschrittmacher müssen auch Jahre nach ihrer Auslieferung noch sicher betrieben werden können – den Asset-Typ „I(I)oT-De – vice“ deckt die IEC 62443 mit Stand heute jedoch noch gar nicht ab.
• Wenn die Beschäftigung mit der IEC 62443 den Nachwuchs dazu bringen könnte, sich stärker für das spannende und wichtige Thema Risikoanalyse zu interessieren, wäre jedoch schon viel gewonnen.

David Fuhr ist Head of Research bei der HiSolutions AG.

Literatur

[1] Ingrid Dubois, Die Umsetzung des IT-Sicherheitsgesetzes, Einblicke in den Entwurf einer Verordnung zur Bestimmung kritischer Infrastrukturen nach dem BSI-Gesetz, 2016# 1, S. 64 [2] Ingrid Dubois, BSI-KritisV – Version 2.0 ß, Zur Anpassung der Verordnung zur Bestimmung kritischer Infrastrukturen nach dem BSI-Gesetz, 2017# 1, S. 60

[3] Bundesamt für Sicherheit in der Informationstechnik (BSI), Orientierungshilfe zu Inhalten und Anforderungen an branchenspezifische Sicherheitsstandards (B3S) gemäß § 8a (2) BSIG, Version 1.0, Januar 2018, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/IT_SiG/b3s_Orientierungshilfe_1_0.html

[4] Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), Bankaufsichtliche Anforderungen an die IT (BAIT), Rundschreiben 10/2017 (BA), November 2017, www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2017/meldung_171106_ BAIT.html

[5] Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), Versicherungsaufsichtliche Anforderungen an die IT (VAIT), Konsultation 04- 2018, März 2018, www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Konsultation/2018/kon_0418_ vait_va.html