Mit <kes>+ lesen

Risiken und ihre Begrifflichkeiten in Theorie und Praxis (2)

Im täglichen Umgang und selbst in der Literatur begegnet man nicht selten unklar, bisweilen sogar falsch verwendeten Begrifflichkeiten zur Risikoanalyse. Der erste Teil des vorliegenden Beitrags [1] hat daher zunächst klare Definitionen geliefert und die Terminologie verdeutlicht – der jetzige zweite Teil geht hingegen auf die Anwendung für Risikoanalysen in der betrieblichen Praxis ein.

Häufig ist es gar nicht so einfach zu entscheiden, welche Art einer Bedrohung (Threat) vorliegt und was in einem IT-Szenario eine Schwachstelle (Vulnerability) oder eine Sicherheitslücke (Security-Gap) ist. Diese Begriffe sind eng verknüpft mit den Assets, die in der Informationstechnologie und Informationssicherheit beispielsweise gemäß der ISO/IEC 27001 oder ISO 27005 in einem Geltungsbereich adressiert werden. Dabei unterscheidet die Norm zwischen primären und „supporting“ Assets (ISO/IEC 27005, Anhang B):

  • Bei primären Assets handelt es sich um Informationen, die eine Handlung auslösen sowie um Prozesse/Geschäftsprozesse (GP) in Anlehnung an ISO 9001.
  • Bei supporting Assets handelt es sich um organisatorische, personelle, technische und infrastrukturelle Assets. Oft verwendet man hierfür auch den Begriff Ressourcen.
Abbildung 5: Menge der Assets A einer Organisation, die gegebenenfalls Bedrohungen und Schwachstellen unterworfen sind (Venn-Diagramm)

Den Zusammenhang zwischen den primären und supporting Assets stellt das Prozessmodell her, auf das weiter unten näher eingegangen wird. Abbildung 5 illustriert Assets als abstrakte (Teil-)Mengen mit bestimmten Eigenschaften. Die Menge aller Assets einer Organisation sei A, ihre Mächtigkeit (Zahl der Elemente) ist |A| sie kann in einem konkreten Fall unbekannt sein kann, ist aber abzählbar und endlich.

Für die verschiedenen (primären oder supporting) Assets a ∈ A* sind die folgenden drei generellen Zustände möglich, die durch Zuordnung zu den Teilmengen A, Av und At bezeichnet werden:

  • a ∈ A: Asset, das keinerlei Bedrohung ausgesetzt ist und für das noch keine Schwachstelle erkannt worden ist. Diese Assets erfüllen die Bedingungen eines sicheren Betriebs bezüglich der Schutzziele (Integrität, Vertraulichkeit, Verfügbarkeit, Authentizität).
  • at ∈ At : Die Assets dieser Teilmenge sind einer oder mehreren Bedrohungen (tn) ausgesetzt – die Assets erfüllen dennoch die Bedingungen eines sicheren Betriebs bezüglich der Schutzziele.
  • av ∈ Av : Die Assets dieser Teilmenge weisen eine oder mehrere Schwachstellen auf – die Assets erfüllen nicht die Bedingungen eines sicheren Betriebs bezüglich der Schutzziele und müssen „gepatcht“ werden.
  • az ∈ At ∩ Av : Diese Teilmenge von Assets ist die Schnittmenge der Assets, die sowohl einer oder mehreren Bedrohungen ausgesetzt sind als auch gleichzeitig Schwachstellen aufweisen. Diese Assets sind in einem unsicheren Betriebszustand bezüglich eines oder mehrerer Schutzziele.
Abbildung 6: Risiko-Szenarien-Diagramm mit Wahrscheinlichkeitsverteilungen

Sind Assets sowohl Bedrohungen ausgesetzt als auch Schwachstellen unterworfen, stellt sich die Frage wie wahrscheinlich P(az) diese Assets einer oder mehreren Kompromittierungen erliegen beziehungsweise Schäden Da (in Euro) bewirken. Da hier kein Würfelexperiment vorliegt, in dem das Werfen der Augenzahlen gleichwahrscheinlich ist, muss eine Wahrscheinlichkeitsfunktion zu Hilfe genommen werden (vgl. Wahrscheinlichkeitsverteilungen in Abb. 6).

Für konkrete Ereignisse (Schadensereignisse D(a) in €) entsteht ein kartesisches Produkt (×). In dem daraus entstehenden Koordinatensystem sind die einzelnen Assets a ∈ A* mittels der linearen Funktion Rsza in konkrete Risikoszenarien einem Schadensereignis Da mittels einer Wahrscheinlichkeitsfunktion P(e) zugeordnet:

Rsz(a) [€] = P(e) × D(a) [€]

Überträgt man diese Funktionen in ein Koordinatensystem, entsteht exemplarisch Abbildung 6: Auf der Abszisse (x-Achse) ist die Wahrscheinlichkeit der Schadenszunahme für ein Asset (D(a)) eingetragen. Diese ist gemäß den Axiomen von Kolmogorov [2] zwischen 1 und 0 aufgespannt. Dabei ist P(Da) = 1 das „sichere Ereignis“ und im Gegensatz dazu P(D(a)) = 0 das „unsichere“ Ereignis. Auf der Ordinate (y-Achse) ist der mögliche Schaden für die Assets in vier (monetären) Stufen eingetragen. Die Wahrscheinlichkeitsverteilungen für die Assets a(z) sind gestrichelt gezeichnet: Die Darstellungen geben wieder, dass häufig kleinere (lokale) Schäden (weiter links auf der x-Achse), aber seltener große und umfangreiche Schäden von regionalen und überregionalen Auswirkungen entstehen.

Im Koordinatensystem der Abbildung 6 sind dazu exemplarisch drei Risikoszenarien aus der Schnittmenge az ∈ At ∪ eingezeichnet. Das Szenario-Beispiel Rsza1 im Bereich der Stufe 1 und P(D(a1)) ≈ 0,8 könnte mit dem ersten Risikoszenario aus dem zweiten Beispiel in [1] verknüpft werden (Auto fährt mit ungewarteten Bremsen in ländlicher Umgebung) – das mittlere Szenario- Beispiel Rsza2 in Stufe 3 und P(D(a2)) ≈ 0,5 mit dem zweiten Szenario dieses Beispiels (Fahrt durch die Autobahnbaustelle). Das Szenario-Beispiel Rsza3 im Bereich der Stufe 4 und P(D(a3)) ≈ 0,2 ließe sich hingegen mit dem ersten Beispiel aus Teil 1 dieses Artikels (Sturmschaden am Hausdach) verknüpfen.

Darüber hinaus sind in Abbildung 6 noch mögliche Reaktionen mit Managementsystemen skizziert: Für das Szenario „links unten“ wird ein präventives System – ein Informationssicherheits-Managementsystem (ISMS) gemäß ISO 27001 – favorisiert, während für das Szenario „rechts oben“ ein reaktives System – ein Business-Continuity-Managementsystem (BCMS) – geeignet sein dürfte. Die Pfeile deuten auf mögliche Risikobehandlungen hin, die entweder auf die Eintrittswahrscheinlichkeit oder auf die Höhe des Schadens einwirken können – ideal wäre die Kombination aus beidem (gestrichelte Pfeile).

Prozessgestaltung im Unternehmen

Abbildung 7: Ende-zu-Ende-Prozessgestaltunggemäß ISO-9001-Darstellung

Für einen konkreten Anwendungsfall soll nun (in drei Detaillierungsstufen) eine Ende-zu-Ende-Prozesskette eines Unternehmens dargestellt und anhand dieser eine Risikoanalyse gemäß ISO/IEC 27005 vorgenommen werden. Abbildung 7 ist von links nach rechts zu lesen und ist eine klassische ISO-9001 Darstellung mit der typischen Dreiteilung die oben die Führungsprozesse (FP, auch Steuerungsprozesse genannt), in der Mitte die Geschäftsprozesse (GP) mit dem eigentlichen Geschäftszweck und im unteren Teil die unterstützenden Prozesse (UP) aufführt. Die Geschäftsprozesse sind klassisch mit einem Vertriebsprozess (GP.0), zwei Kernprozessen (GP.1, GP.2), die für die Produktion zuständig sind, und einem Abrechnungsprozess (GP.3) ausgestattet. Diese Grafik stellt die oberste Ebene dar und wird auch als Level-1-Darstellung bezeichnet.

Abbildung 8: Prozesskette GP.2.1 bis GP.2.4 als Zyklus

Betrachtet man nun einen Geschäftsprozess (bspw. GP.2) näher, so eröffnet sich eine zweite Ebene (Level 2), in der dieser Prozess in GP.2.2.1 bis GP.2.2.4 weiter unterteilt wird. Es handelt sich dabei um die eigentlichen Betriebsprozesse, die zyklisch ausgerichtet sind (Abb. 8). Diese Aufschlüsselung in Elemente genügt bereits, um exemplarisch eine Risikoanalyse vorzunehmen – die Elemente sind bereits die Detailebene, auf sich eine Risikoanalyse durchführen lässt.

Abbildung 9: Beispielhaftes Prozessmodell und seine Elemente für den GP.2.2

Das in Abbildung 9 skizzierte dreiteilige Modell – mit Steuerungsebene oben, Durchführungsebene mittig und Arbeitsebene unten – umfasst primäre sowie supporting Assets (geschweifte Klammern) und zeigt die innere Struktur eines Prozesses. Der Prozess umfasst beispielhaft 13 Prozessschritte (Workflow) für die Transformation vom Input hin zum Output – durchgeführt wird diese Transformation durch die Arbeitsebene mit den supporting Assets.

Für den exemplarisch illustrierten Prozess (Abb. 9) ist gemäß ISO/IEC 27005:2022 eine Risikoanalyse im Kontext der wertschöpfenden Prozesse und bezogen auf die in Teil 1 eingeführten Schadenskategorien D(e1) bis D(e5) durchzuführen. Dabei müssen in geeigneter Weise sowohl die primären Assets (Geschäftsprozess-Logik und -Informationen) als auch die supporting Assets (Durchführung auf der Arbeitsebene) in der Risikoanalyse berücksichtigt werden.

Praxisbeispiel mit Excel-Tabelle

Abbildung 10: Anwendung der linearen Risikogleichung mittels Excel-Tabellenblatt

Um abschließend den gesamten zusammengetragenen theoretischen Überbau für die betriebliche Praxis in eine einfache Tabelle zu überführen, werden in den Zeilen eines Excel-Arbeitsblatts die einzelnen Risikoszenarien (Rsza bzw. RSZ#) horizontal erfasst – in den vertikalen Spalten wird die lineare Risikogleichung mit ihren Komponenten sowie den Sicherheitszielen und einer Brutto-/Netto-Betrachtung der Schadensereignisse eingetragen (Abb. 10).

Excel hat bekanntermaßen drei Sichten (bzw. Schichten): die Datensicht, die Informationsvisualisierung und die Datenlogik (Berechnungsvorschrift):

  • Die Informationsvisualisierung entspricht dem Excel-Tabellenblatt mit den ausgewählten Risikoszenarien (Darstellungsschicht).
  • Die Datensicht entspricht den Eintragungen für die Bedrohungen, Schwachstellen, Schadenskategorien, Eintrittswahrscheinlichkeiten et cetera (Datenschicht).
  • Die Datenlogik entspricht einer Berechnungsvorschrift, die bei Excel häufig in der ersten Kopfzeile eingegeben wird und welche die Zellen über eine Formel miteinander zusammenführt (Geschäftsschicht).

Will man allerdings den heutigen Bedrohungen und Schwachstellen, denen Unternehmen ausgesetzt sind, Rechnung tragen, so wird schnell offensichtlich, dass eine derart einfache Risikoanalyse nur der erste Schritt sein kann, um neuralgische Punkte abzusichern. Es wird mehr und mehr deutlich, dass gerade im Bereich der wertschöpfenden Prozesse Systeme zur Angriffserkennung (SzA) installiert werden müssen, um komplexen Attack-Trees entsprechend begegnen zu können (siehe auch [3,4,5,6]).

Abbildung 11: Angriffspfad durch komplexe Sicherheitsmaßnahmen hindurch

In Abbildung 11 ist als rote Linie ein Angriffspfad illustriert, der sich einen Weg (Pfad) durch verschiedene Schwachstellen bei infrastrukturellen, organisatorischen, personellen und technischen Maßnahmen erschließt. Ein derart komplexer Angriffspfad ist in der Regel nur mit einem Advanced Persistent-Threat-(APT)-Angriff zu realisieren, der über eine große Zeitspanne abläuft – hierfür sind (nur) SzA-Systeme eine mögliche Gegenwehr.

Einordnung in die Normenwelt

Um die einfachen Beispiele aus dem Straßenverkehr in [1] sowie die hier dargestellten Erkenntnisse auf ein ISMS gemäß ISO 27001:2022 zu übertragen, sind folgende Hinweise hilfreich:

  • Der Kontext im Kapitel 4 der Norm bestimmt den Anwendungsbereich eines ISMS und damit auch den Rahmen für das Risikomanagement gemäß ISO/IEC 31000 beziehungsweise ISO/IEC 27005:2022. Hierzu ist es hilfreich, die ISO 27022:20221 zu berücksichtigen, denn dort sind die ISMS Prozesse beschrieben.
  • Das Kapitel 8.1 der Norm erwartet eine prozessuale Betrachtung der Wertschöpfung unterteilt in Führungsprozesse (FP), Kernprozesse (KP) und unterstützende Prozesse (UP).
  • Aus der wichtigen Erkenntnis der Verbindung zwischen einem Ergebnis und einem Ereignis (siehe [1]), die durch eine Zufallsvariable (Funktion) gegeben ist, manifestiert sich die Grundlage für eine Risikoanalyse.
  • Ein Risiko ist ein mögliches Ereignis, das noch in der Zukunft liegt und gegebenenfalls irgendwann die Gegenwart erreicht – bis dahin sind noch Handlungsoptionen gegeben, indem man entweder auf Schwachstellen oder auf Schadenshöhen einwirkt.
  • Als Ergebnis müssen aus dem Kontext (Kap. 4, Kap. 8.1) entsprechend geeignete Schadenskategorien ermittelt werden. Diesen Schadenskategorien sind entsprechende Wahrscheinlichkeitsverteilungen zuzuordnen. Diese Wahrscheinlichkeitsbetrachtungen müssen gemäß ISO 27001:2022 (Kap. 6.1.2.d Nr. 2) realistisch sein.

Abschließend sei auch die Frage aufgeworfen: Warum führt man überhaupt eine Risikoanalyse durch? Wenn man darüber nachdenkt und zur Antwort gelangt „Ich will nicht überrascht werden!“, hat man den tieferen Sinn das Risikomanagements verstanden. Erneut sei zudem gemahnt: Die Betrachtung eines komplexen Attack-Trees zeigt schnell, dass eine reine Risikoanalyse nur der erste Schritt sein kann und letztlich für den Anwendungsbereich eines ISMS auch eine Security-Information-und-Event-Lösung (SIEM) gefragt ist.

 

Dr. Wolfgang Böhmer ist Alumni der Universität Hamburg sowie der TU Chemnitz und war langjähriger Lehrbeauftragter im Fachbereich Informatik der TU Darmstadt. Er ist unter anderem akkreditierter Auditor für ISM nach ISO/ IEC 27001 und selbstständiger Consultant und Coach für digitale Prozesse sowie IT-/Informationssicherheit in kritischen Infrastrukturen (https://wolfgang-boehmer.eu).

Diesen Beitrag teilen: