Bestandsaufnahme Risikomanagement (3) : Problemzonen und Lösungsansätze

Das NIST geht in SP 800-30 Rev. 1 [6] einen anderen Weg (vgl. Anhang E, Tabelle E-2 und E-3) und betrachtet statt Gefährdungen – teilweise recht spezifische – Bedrohungsereignisse (Abb. 1). Das dort postulierte Risiko-Modeling hält der Autor aus bereits dargelegten Gründen für eher ineffizient – dennoch lässt sich einiges an wertvoller Information aus der Norm herausziehen.

Schwachstellen in Abläufen

Kernprobleme in Bezug auf die Informationssicherheit sind Autorisation und Authentifikation: Wer (oder was) darf eine Prozedur initiieren und wie stellt man sicher, dass der Initiator (und natürlich auch alle anderen Beteiligten) auch der ist, für den er sich ausgibt?! Das Thema Autorisation führt schnurstracks zur nächsten wesentlichen Frage: Verantwortlichkeit und Prozesseigentümerschaft –Wer ist dafür verantwortlich, dass ein Prozess oder eine Prozedur die definierten Ziele erreicht? Wer ist Eigentümer und wer trägt welches Risiko? Häufig kann es hier helfen, Prozesse als Konzepte endlicher Zustandsautomaten (Finite-State-Machines) anzusehen und über Ablauf-, Flussdiagramme oder Entscheidungsbäume zu visualisieren.

Schwachstellen unterstützender Werte

Schwachstellen unterstützender Werte sind sehr vielgestaltig – wie spezifisch oder generisch man hier arbeiten will, hängt im Wesentlichen von Scope und Schwerpunkt ab. Der Autor bevorzugt hier eher einen generischen Ansatz; kurzlebigen komponenten-spezifischen technischen Schwachstellen, wie man sie etwa in CVEAdvisories findet, steht er skeptisch gegenüber.

Oft genügen eine oder wenige Schwachstellen, um einen Use-Case abzubilden, beispielsweise die generische Schwäche „kritische Anfälligkeit durch Softwarefehler“. Die Häufigkeit solcher Fehler lässt sich auf Basis einschlägiger Datenbanken sogar quantitativ erheben – fast ein Unikum in der IT-Sicherheit. Vom Vorhandensein einer solchen Schwachstelle ist immer auszugehen, sofern man nicht das Gegenteil beweisen kann. Ebenso ist vom Vorliegen einer „kritischen Anfälligkeit durch Benutzer- und Konfigurationsfehler“ auszugehen.

Auch andere Schwächen wie „kritische Belastung von Systemen/Funktionen“, „kritische (externe) Abhängigkeit von limitierten/störungsanfälligen Ressourcen“ (Klima, Strom, Gebäude, Plattenplatz …), „schwache Authentifikation“, „schwache Autorisationsvalidierung“ sowie auf der physischen Seite „elektrische oder mechanische Alterung“, „physisch entfernbar“ und „physisch zerstörbar“ sind nahezu universell anwendbar – eine weitere Ausdetaillierung ist nicht in jedem Fall sinnvoll.

Die ISO 27005:2018 enthält im Anhang D.1 eine Aufstellung sowohl technischer als auch organisatorischer Schwachstellen, die man als Hilfestellung heranziehen kann. Eine detailliertere Definition ist nach Einschätzung des Autors geboten, wenn ein spezifisches Gefahrenpotenzial oder ein möglicher Schaden von besonders großem Interesse ist, beispielsweise weil er im jeweiligen Use-Case mit einer hohen Kritikalität einhergeht.

Nebenläufigkeit und Persistenz

Technischer ist das Thema Nebenläufigkeit/Parallelität (Concurrency) – in der Praxis ein durchaus schwieriges Thema, wo die Parallelität von Abläufen leider so gut wie nie Beachtung findet. In 25 Jahren IT ist dem Autor kein einziger Prozess untergekommen, der diese Themen hinreichend berücksichtigt. Dabei sind entsprechende Planungen im Rahmen des Service-Delivery für den Themenkreis des Capacity-Managements, der Verfügbarkeit und gegebenenfalls auch für Operational- oder Service Level-Agreements (OLAs/SLAs) von wesentlicher Bedeutung. Die Auslastung von Ressourcen und ihre konkurrierende Nutzung sind dabei nur beispielhafte Schwierigkeiten, die durch eine Nebenläufigkeit von Prozessen auftreten können.

Man stelle sich zum Beispiel vor, dass eine Firma zwei Klienten betreut: Kunde A führt alle 30 Tage einen Zahlungslauf (as a Service) durch und lässt Gehaltszettel und Rechnungen ausdrucken – Kunde B macht das alle 4 Wochen (28 Tage). Das klappt jahrelang wunderbar, bis es zu dem denkwürdigen Tag kommt, an dem die Ausführung beider Aufträge auf den gleichen Termin fällt: Plötzlich ist die Datenbank überlastet, das File-System des Spool-Servers voll, das Netzwerk „irgendwie“ langsam und auch Tinte und Papier sind nicht in ausreichender Menge vorhanden. Ganz wie bei „Turings Fahrradkette“, die nur dann absprang, wenn die zwei Zustände „defekter Zahn A“ und „verbogenes Kettenglied B“ aufeinandertrafen – der Legende nach wusste er seine Kette so zu platzierten, dass dieses Ereignis nur im größtmöglichen Intervall eintrat.

Vergleichbare Effekte können sowohl durch die mehrfache Instanziierung eines Ablaufs als auch durch die konkurrierende Nutzung von Ressourcen durch unterschiedliche Prozesse auftreten. Zu beachten ist dabei, dass die Effizienz parallelisierter Prozesse mit der Annäherung an die Belastungsgrenzen des Systems zunehmend abnimmt.

Steigende Parallelität steigert auch den Aufwand in Bezug auf Synchronisation und Ressourcensteuerung (Management), was technisch wie organisatorisch zu neuen Risiken führt.

Auch hier hilft es, einen Prozess als endlichen Zustandsautomaten zu sehen: Mit jeder Instanziierung wird eine neue „Maschine“ bereitgestellt, genutzt und schließlich stillgelegt. Die Tätigkeit dieser Maschine führt bei jedem Durchlauf (Iteration) sowohl flüchtige (ephemere) wie beständige (persistente) Zustände herbei. Persistente Zustände und Eigenschaften können dabei sowohl nachfolgende Prozesse als auch erneute Iterationen desselben Prozesses beeinflussen, sie werden „vererbt“ und „geerbt“.

Neben der Persistenz von Zuständen ist die Wirkbreite von Interesse: Aus Gründen der Effizienz (oder Synergie) werden sich sehr oft mehrere parallellaufende Maschinen unterschiedlicher Art und Funktion Ressourcen-Pools teilen. Auch hier sind Wechselwirkungen zu erwarten, die über den Scope einer einzelnen Maschinen-Instanz hinausgehen – ein Effekt, der im Bereich Cloud-Computing die treffende Begrifflichkeit des „Noisy Neighbours“ geprägt hat. Homogene Prozesslandschaften sind zwar überschaubarer, da sie jedoch bis „hinunter aufs Blech“ die gleichen Ressourcen-Anforderungen stellen, sind sie auch eher von Flaschenhälsen betroffen als heterogene oder „chaotische“ Prozesslandschaften.

Dabei gibt es drei Wirkungsräume für die Breite und Tiefe von Risiken, wie die Abbildungen 2 und 3 veranschaulichen: eine einzelne Instanz oder Iteration eines Prozesses oder einer Prozesskette (Wirkbreite gering, Wirktiefe gering), alle folgenden Iterationen derselben Prozesskette einschließlich der laufenden (hohe Wirktiefe) und alle folgenden Iterationen sowie weitere parallellaufende in Beziehung stehende Prozesse einschließlich laufender Instanzen (hohe Wirkbreite, hohe Wirktiefe).

Standardisierung von Risiken

Neben der Standardisierung von Gefährdungen kann es durchaus Sinn ergeben, daraus Umschreibungen und Maßnahmenempfehlungen abzuleiten und somit das Risikomanagement selbst von einem reinen „Inventar“ hin zum technisch und organisatorisch unterstützenden Werkzeug zu entwickeln. Dies ist initial sicherlich mit einem erhöhten Aufwand verbunden, allerdings relativiert sich dieser durch die Reduktion an Aufwand bei individuellen Assessments durch die Standardisierung sehr schnell – zumindest, wenn das angestrebte Schutzziel nicht wesentlich von einem Grundschutzniveau abweicht. Zu dem vom Autor auf dieser Basis entwickelten Verfahren liegen bereits Erfahrungen aus einer 16-monatigen Anwendung in über etwa 20 Organisationseinheiten vor.

Diese Erfahrungen zeigen, dass die Betrachtung individueller Schutzziele (z. B. C/I/A) dabei – von wenigen Ausnahmen abgesehen – eher theoretischer Natur ist. Das assoziierte Risiko sollte kurz und treffend, aber gleichzeitig sowohl für technisches Personal als auch für die organisatorische Verwaltung ausreichend klar beschrieben werden. Technische Tiefe und Details sind hier weniger gefragt – sie sind in einem Known-Error-, Problem- oder auch Schwachstellen-Management besser aufgehoben. Eher sollte man hier auf interne wie externe Anforderungen und Standards (oder Best Practices) verweisen. Neben dem assoziierten Risiko wurden deshalb im Risiko-Tooling auch „Empfehlungen zur Umsetzung der Anforderung“ hinterlegt – teilweise basierend auf NIST, BSI-Grundschutz oder ISO 27002.

Auf eine Analyse interner Regularien mit Bezug auf Informationssicherheit in der IT folgte dann ein Mapping auf einen standardisierten Anforderungskatalog. Wo sich eine Organisation bereits weitgehend an der ISO 27001 ausgerichtet hat, dürfte das kaum Probleme aufwerfen. Im nächsten Schritt wurde analysiert, welchen (möglichen) Risiken man durch die geforderten Maßnahmen und Abläufe klassischerweise begegnen will. Dies ist kein 1:1-Mapping und Maßnahmen unterliegen dabei immer dem PDCA-Zyklus (DemingKreis)!

Ein Punkt, den der Autor an ISO 27001 und COBIT (5) kritisiert, ist der Mangel einer solchen Aufstellung, die gerade unterhalb der strategischen Ebene einer Organisation das Arbeiten mit dem Standard erleichtern und böswilliges Argumentieren („Das steht ja so nicht da.“) deutlich erschweren würde. Dies lässt sich mit der ISO 27002 teilweise kompensieren – zudem unterstützten frei verfügbare Mappings zwischen ISO27001 und BSI-Grundschutz sowie PCI-DSS bei dieser Aufgabe deutlich.

Als Beispiel mit Bezug zum Thema Protokolldaten in der ISO 27001 mag das folgende assoziierte Risiko dienen: „A failure in management of sensitive information (logging and monitoring data, telemetry data) could result in a broad range of critical scenarios. The legal (compliances, GDPR), commercial (billing, controlling, taxing) and technical (service health and security monitoring) status of your service or application might be compromised.“ Als Maßnahmenempfehlungen dient dann etwa: „Log relevant protocol information offsite of the supporting asset, e. g. in a centralized data sink, to reduce the opportunities of altering log-information and to enable a centralized management of this data (e. g. in regards of access, retention period, storage size, encryption, backup, enrichment and obfuscation). […] Consult ISO/IEC 27001 Annex A or ISO/IEC 27002 A.12.1.1, A.12.1.4, A.12.3.1, A.12.4, A.16.1.3, A.18.1.4, A.18.2.2 for detailed information.“

Von einer Standardisierung der Kritikalität und der Schadenswerte von Risiken rät der Autor hingegen eher ab: Hier ist zwingend der Kontext des Gefahren- und damit verbundenen Schadenspotenzials zu betrachten. Teils lassen sich allerdings Richtwerte definieren – etwa dann, wenn es um den Themenkreis „Legal & Compliance“ geht, oder dort, wo Haftungsobergrenzen definiert oder Haftung/Regress generell vertraglich ausgeschlossen werden (z. B. durch Risikoübernahme). In allen anderen Fällen sollte man aus dem Kontext des Prozesses, den Werten, unterstützenden Werten und der Wirkung auf die Prozesskette eine Analyse zur Risikoerhebung durchführen.

Mehrdimensionale Risikolandschaft

Die Schwierigkeit der Mehrdimensionalität von Risiken wurde bereits mehrfach angesprochen – im Folgenden soll sie noch kurz von mathematischer Seite betrachtet werden.

Mapping zwischen qualitativen und quantitativen Skalen

Ein in der Praxis häufig anzutreffendes Mapping zwischen qualitativen (z. B. selten, gering, mittel, hoch, sehr hoch) und quantitativen Kategorien wird durch Risikokategorien mit abweichenden quantitativen Wertspannen komplex und fehleranfällig (z. B. Eintrittswahscheinlichkeit 1x in 5 Jahren, 1x im Jahr, 1x im Quartal, 1x im Monat, >1x im Monat oder bzgl. Schäden 0–10.000 €, 10.000–100.000 €, 100.000–250.000 €, 250.000–500.000 €, >500.000 €).

Generell ist ein solches hartes Mapping wenig zielführend, denn es widerspricht dem originären Ansatz der qualitativen Risikoanalyse. Diese ist für ein planvolles Handeln an sich fast immer ausreichend – eine höhere Trefferrate wird man durch ein Mapping auf quantitative Werten in der Regel nicht erreichen. Ohne dieses Mapping sitzt man jedoch in der „Falle der Ordinalskala“ fest, die ein wissenschaftlich/mathematisch korrektes Arbeiten leider sehr stark einschränkt, wie das nachfolgende Beispiel illustrieren mag, das die Möglichkeit eines Schadenseintritts sowie die Schadenshöhe betrachtet, die Detektionswahrscheinlichkeit zugunsten einer geringeren Komplexität jedoch außer Acht lässt.

Die Erwartungshaltung ist, dass bei einer Zusammenfassung von zwei Ereignissen die Wahrscheinlichkeit des Eintritts des aggregierten Ereignisses steigt, da die Summe beider Ereignisse die Anzahl der Ereignisse des aggregierten Typs ergibt. Für diese Variable eine Zusammenfassung zu treffen, erscheint zunächst legitim.

Erfahrungswerte belegen: Es existiert eine hohe Wahrscheinlichkeit für einen Virenbefall mit einer Beeinträchtigung der Verfügbarkeit, aber ohne Beeinträchtigung der Vertraulichkeit sowie eine mittlere Wahrscheinlichkeit eines Virenbefalls mit einer Beeinträchtigung von sowohl Vertraulichkeit als auch Verfügbarkeit. Ob dies in Summe eine hohe oder sehr hohe Wahrscheinlichkeit für einen Virenbefall mit Einfluss auf die Verfügbarkeit ergibt, lässt sich nicht bestimmen, da das Intervall der qualitativen Klassifizierung unklar ist. Mit qualitativen Kategorien lässt sich halt nicht rechnen – die Summe von „vielleicht“ und „unwahrscheinlich“ bleibt immer unbekannt.

Kompensation durch Trendindikatoren

Um sich dem dennoch anzunähern, kann in diesem Use-Case beispielsweise ein Trendindikator zur Deklaration angenommener Veränderungen Verwendung finden, der eine erwartete Zu- oder Abnahme bei den einzelnen Risikoparametern indiziert (vgl. Abb. 4). Wird dieses Vorgehen sauber umgesetzt, erzielt man zumindest einen Mehrwert im Hinblick auf Transparenz und Änderungshistorie.

Alternativ besteht die Möglichkeit, dieses aggregierte Risiko einer erneuten Analyse und Bewertung zu unterziehen, wie es auch NIST SP 800-30 Rev. 1 [6] vorschlägt. Auch hierbei unterstützt die Verwendung von Tendenzindikatoren: Durch die sie begleitende Historie wird ersichtlich, für welche Risiken eine Neubewertung priorisiert durchzuführen ist. Das ist etwa dann der Fall, wenn widersprüchliche Indikatoren bestehen oder mehrere identische Indikatoren ein Risiko stark auf- oder abwerten.

Ein anderes Beispiel liefert der Versuch einer Zusammenfassung einzelner Risiken hinsichtlich von Schaden/Impact: Einen Durchschnitt aus den Kategorie-Werten zu Schaden/Impact von Verfügbarkeit und Vertraulichkeit zu bilden (z. B. [„gering“=1 + „hoch“=4] : 2 = 2,5), ist nicht nur im Hinblick auf die qualitative Analyse methodisch falsch, es verfälscht bei einem quantitativen Vorgehen auf Basis ungleicher Intervalle auf der Werteskala auch die Kategorisierung – bei den oben genannten Werten hätte beispielsweise Kategorie 2 eine Spanne von 90.000 e, Kategorie 4 aber von 250.000 e. Fügt man weitere Dimensionen, beispielsweise die Nichtabstreitbarkeit und Nachweisbarkeit, hinzu, so verstärken sich die Fehler noch weiter.

Summe statt Produkt

Ein zusätzliches Problem in Bezug auf die Mehrdimensionalität begründet die Erfahrung, dass bei der Anwendung des klassischen Risikomodells (Impact x Probability x Detection-Probability) viele Risikowerte sehr eng beieinander liegen. Andererseits können aber schon kleine Änderungen erhebliche Auswirkungen auf den Risikowert haben (vgl. [7,8]) – ein großer methodischer Fehler, der eine Priorisierung bei beschränkten Budgets und Ressourcen erschwert.

Nutzt man jedoch statt des Produkts der Werte pro Risikodimension (im Beispiel vereinfacht: Wahrscheinlichkeit und Schaden) deren Summe, erhält man bessere Ergebnisse. Als zusätzliche Information sollten bei der Addition der Summanden die Standardabweichung (Quadratwurzel der Varianz des Risikowerte) angegeben werden (vgl. Abb. 6): Verhältnismäßig hohe Standardabweichungen sind bei diesem Vorgehen ein wichtiger Indikator für Risiken, die vor der Priorisierung einer genaueren Betrachtung bedürfen. Dieses Vorgehen kann durch prozentuale Schwellwerte für das Verhältnis zwischen Risikowert und festgestellter Standardabweichung gestützt werden. Auch dies ist zwar nur ein Hilfsmittel, das den Anforderungen in Bezug auf eine statistische Korrektheit im mathematischen Sinne nicht genügt – dennoch mildert es einen nennenswerten Teil der Schwächen bei der Erhebung von Risikowerten.

Ein Beispiel in Zahlen: Aus dem mehrdimensionalen Risiko mit Werten für „Verfügbarkeit = 20“, „Vertraulichkeit=15“ und „Nichtabstreitbarkeit = 5“ ergibt sich als Summe der Risikowerte 40 – die Varianz der Gruppe beträgt 5,93, die Standardabweichung 2,45. Letztere dienen als Indikatoren, um Risiken erkennen zu können, die nur in einem Teil der Dimensionen stark ausgeprägt sind. Bei der klassischen Herangehensweise würde die ermittelte Diversität des zusammengefassten Risikos verloren gehen und ein Wert entstehen, der in Teildimensionen markant ausgeprägte Risiken stark auf- oder abwertet und damit das reale Risiko verschleiert. Im Beispiel wäre der durchschnittliche Risikowert 40:3 = 13,3, was das markante Verfügbarkeits- und geringe Nichtabstreitbarkeitsrisiko nicht mehr erkennen ließe.

Bei einer Priorisierung sollten Ereignisse mit hoher Eintrittswahrscheinlichkeit/-frequenz und sehr hohem Schadenspotenzial in allen Dimension von größter Relevanz sein, gefolgt von Ereignissen mit einem hohen Risikowert in der Mehrzahl der Dimensionen – erst dann folgen Risiken mit mittleren und schließlich niedrigen Risikowerten in den jeweiligen Dimensionen. Edge-Case ist die „Katastrophe“ (Impact >5, Likelihood <1), welche die Impact-Skala sprengt und sich mit „Likelihood“ kaum bis gar nicht erfassen lässt- sie ist ein Thema für das Bussiness-Continuity-Management (BCM).

Improved Risk-PriorityNumber (IRPN)

Diese Problematik fachlich korrekt aufzulösen ist nicht einfach und obendrein unbequem: Zunächst müssen maßgeschneiderte Basisskalen erstellt werden, welche die Anforderungen an Verhältnisskalen erfüllen – also einen definierten Startpunkt und Intervalle besitzen, die in einem mathematisch definierbaren Verhältnis zueinander stehen, also etwa logarithmisch sind. Diese Skala gilt es gezielt für den jeweiligen Anwendungsfall zu entwickeln! Um eine Übertragbarkeit der Werte zwischen unterschiedlichen Betrachtungsräumen herzustellen, muss man darüber hinaus eine Adaption der Skalen zwischen diesen Räumen erstellen.

Am einfachsten ist es, den kleinsten / kürzesten / geringsten zu betrachtenden Wert als Intervall zu nutzen – beispielsweise 1000 e für den Impact oder „monatlich“ für die Eintrittsfrequenz. Die Größe dieser Intervalle definiert die maximale Auflösung oder Genauigkeit. Allerdings bräuchte man für eine Abdeckung des Spektrums bis 500.000 e sowie einen Betrachtungszeitraum über 5 Jahre (60 Monate) dann eine erhebliche Menge (30 000) möglicher Kombinationen, was nicht unbedingt zweckmäßig ist. Selbst wenn man diese Liste um redundante Risikowerte bereinigt, bleibt immer noch eine unbeherrschbare Zahl möglicher Fälle pro Dimension übrig.

Eine überhöhte Zahl von Szenarien ist nach Erfahrung des Autors oft ein Indiz dafür, dass die Wertspanne und damit das zugrunde liegende Scoping nicht zweckdienlich gewählt wurden. Eine Lösung kann sein, den Service, die Organisation oder den Prozess in Teilkomponenten zu zerlegen und/oder die Intervalle sinnvoll zu vergröbern. An dieser Stelle ist eine normalisierte (d. h. redundanzfreie) Skala mit definierten Szenarien auf quantitativer Basis verfügbar.

Alternative Lösungsansätze für zu lange Skalen veranschaulichen etwa die Definitionen der Dezibel- oder Richter-Skala auf Basis eines logarithmischen Verhältnisses zwischen Intervallen und/oder Skalen unterschiedlicher organisatorischer Ebenen (Level) oder Bereiche (Kategorien). Das ermöglicht es, dem Betrachtungsraum angemessene Risikowertskalen zu verwenden, ohne dabei gänzlich auf eine globale Kohärenz verzichten zu müssen.

Im zweiten Schritt gilt es, den als relevant identifizierten Ereignissen Koordinaten auf dieser Skala zuzuweisen – unterschiedliche Ereignisse mit identischen Risikowerten sind dann gleichbedeutend mit identischen Skalen-Werten. Kurzum: Ein solches Vorgehen ist statistisch korrekt, erlaubt also das „richtige“ Rechnen mit ermittelten Daten – es bringt aber auch alle bereits geschilderten Probleme quantitativer Risikobewertung mit sich und stellt in Bereichen und Organisationen, die nicht bereits FMEA-Verfahren anwenden, einen spürbaren Mehraufwand dar.

Anwendung der Monte-Carlo-Simulation

Aufgrund der Komplexität der von Stanislaw Ulam, Nicholas Metropolis und John von Neumann in den 1940er-Jahren entwickelten Methode sei an dieser Stelle im Wesentlichen auf die Literatur verwiesen (siehe etwa [9,10,11,12]). Grob gesagt lässt sich die Monte-CarloSimulation einsetzen, um die Wahrscheinlichkeit des Auftretens von Risiken in den jeweiligen Schadenskategorien (z. B. fünf Gruppen mit definiertem Werteumfang) in den Dimensionen Verfügbarkeit, Vertraulichkeit und Integrität zu ermitteln.

Dazu benötigt man Zufallswerte für Impact und Likelihood in den jeweiligen Dimensionen, errechnet aus diesen paarweise nach dem klassischen Modell einen Risikowert und weist diese wiederum mittels Vergleichsoperatoren einer der fünf definierten Kategorien zu – abschließend wird deren Verteilung ausgewertet. Noch interessanter ist dabei die Frage nach dem Auftreten von Mehrfachschäden, also von Gefahren, deren Eintreten ein Risiko für mehrere Schutzziele darstellt und gegen die man daher priorisiert Maßnahmen ergreifen sollte.

Veränderung von Werten über Zeit

Nicht zu vergessen ist bei der Risikobetrachtung, dass die Verkehrswerte und Bedeutsamkeit von unterstützenden wie auch primären Werten sich entlang der Zeitachse verändern: Typischerweise verlieren unterstützende Werte an materiellem Wert, etwa durch Abschreibung und Alterung. Bei primären Werte hingegen ist oft zu beobachten, dass diese an Wert (oder Toxizität) zunehmen.

Hier kann sich etwa ein schleichender Zuwachs an Datenvolumen – etwa in einem Webshop mit anfänglich wenigen Dutzend Datensätzen von Kunden, Produkten und Geschäftsvorfällen – über die Jahre zu enormen Mengen aufsummieren. Durch ein steigendes Volumen nimmt zwar nicht der individuelle Wert eines Datensatzes zu, wohl aber der Gesamtwert. Ein anderes Beispiel ist die Datengüte, die anfänglich schlecht sein kann, durch manuelle oder automatisierte „Pflege“ aber immer besser und verlässlicher wird – hier steigen sowohl der Wert einzelner Datensätze als auch der Gesamtwert.

Ähnliches gilt auch für Informationen der Metaebene, wie sie etwa Erfahrungswerte oder Protokolldaten darstellen: Haben sich größere Mengen angesammelt, erhalten diese etwa dadurch einen Wert, dass sie Big-DataAnalysen oder andere Formen statistischer Auswertung ermöglichen. Auch ein Prozess im Sinne eines Vorgehens nimmt mit zunehmendem Reifegrad an Wert zu. Diesen Umstand betrachtet die ISO 27005:2018 indirekt und leitet hieraus die Zielsetzung ab, Risiken und ihre Bestandteile kontinuierlich zu beobachten.

Fazit

Aus Perspektive des Autors ist aktuell das in NIST SP 800-30 Rev. 1 [6] vorgeschlagene Vorgehen der durchdachteste Ansatz unter den RisikomanagementMethoden. Am wenigstens konnte – aus der Perspektive eines Technikers – das Risikomanagement nach COBIT (5) überzeugen.

Die meisten Ansätze bleiben im Detail recht generisch (z. B. bei der Risikoidentifikation und Analyse), was in der Praxis erheblichen Implementierungsaufwand und große Unsicherheit im Sinne von Interpretationsspielraum bedeutet. Kein Ansatz ist wirklich integrativ und deckt von der Organisation über die Prozesse bis hin zur Technik alle Ebenen in einem einzigen Modell ab.

Vor- und Nachteil zugleich ist die gute und freie Verfügbarkeit in deutscher Sprache von Anforderungskatalogen an das Informationssicherheits- und Risikomanagement durch BSI-Standards (200-1, 200-2, 200-3) sowie Veröffentlichungen der Bundesanstalt für Finanzdienstleistungsaufsicht BaFin (MaRisk, BAIT) – „Lost in Translation“ ist hier ausgeschlossen. Andererseits findet man kaum internationale Informationen zu Best-Practice- (oder Lowest-Effort-) Implementierungen zu diesen Standards. Das bedeutet auch: Wer noch kein Expertenteam für diese Managementsysteme und/oder RisikomanagementMethoden hat, muss mit vergleichsweise hohen Kosten, herausfordernder Personalbeschaffung und längeren Vorlaufzeiten als etwa bei einer ISO-27001/ISO-27005-Integration rechnen.

Diese Kritik trifft auch auf die Vornormen DIN VDE V 0831-101:2011-05 „Elektrische Bahn-Signalanlagen – Teil 101: Semi-quantitative Verfahren zur Risikoanalyse technischer Funktionen in der Eisenbahnsignaltechnik“ und DIN VDE V 0831-103:2014-11 „Elektrische Bahn-Signalanlagen – Teil 103: Ermittlung von Sicherheitsanforderungen an technische Funktionen in der Eisenbahnsignaltechnik“ zu. Beide Dokumente stellen einen Versuch dar, die Schwächen der FME(C)A-Methodik bei der Erhebung von Risikoprioritätswerten zu ergänzen und als Verfahren zu normieren.

Generelle Empfehlungen

Vermeiden Sie eine Überspezifikation und meiden Sie das Arbeiten mit unbekannten Faktoren. Fokussieren Sie sich auf Komponenten, Funktionen, Informationen und Daten mit Relevanz – betrachten Sie keine Gefahren, deren Verwaltung mehr Arbeitszeit erfordert als ein möglicher Schadenseintritt. Qualifizieren Sie Parameter überall dort, wo keine klare Faktenlage vorliegt – bei der Qualifizierung von Schadenspotenzialen sollte im gesamten Betrachtungsraum derselbe Kontext zugrunde liegen. Bemessen Sie den Betrachtungsraum zweckmäßig: Ein komplettes Unternehmen ist in der Regel kein sinnvoller Scope.

Kulturell neigen wir alle dazu, Risiken in unserer Verantwortlichkeit überzubewerten – vermeiden Sie das, bleiben Sie bei einer realistischen Einschätzung, vertrauen Sie Ihrer Erfahrung. Gestehen Sie Wissenslücken offen und ehrlich ein, vermeiden Sie es zu raten und binden Sie bei Bedarf Experten anderer Fachrichtungen ein (z. B. Kaufleute, Manager, Juristen und Techniker). Treten Sie auch ruhig an Hersteller oder Supplier heran: Viele große IT-Unternehmen wie Microsoft, Oracle oder auch AWS bieten im Rahmen von Integrationsprojekten speziell für Risikoanalysen umfassende Unterstützung an – vom Whitepaper bis zum Analysten-Team.

Bastian Angerstein (T.I.S.P, ISO 27001 Lead Auditor) ist ehemaliger Softwareentwickler und seit 2008 zunehmend im Bereich der Informationssicherheit und Risikoverwaltung tätig – heute im Cloud-Umfeld bei der Robert Bosch GmbH.

Literatur

[1] Bastian Angerstein, Bestandsaufnahme Risikomanagement (1), Problemzonen und Lösungsansätze, <kes> 2019#4, S. 42
[2] Bastian Angerstein, Bestandsaufnahme Risikomanagement (2), Problemzonen und Lösungsansätze, <kes> 2019#5, S. 49
[3] OpenStack Security Group, Security/OSSA-Metrics, STRIDE/DREAD, Wikipage, https://wiki.openstack.org/wiki/Security/OSSA-Metrics#STRIDE
[4] Adam Shostack, Experiences Threat Modeling at Microsoft, 2008, https://adam.shostack.org/modsec08/Shostack-ModSec08-Experiences-Threat-Modeling-At-Microsoft.pdf
[5] Loren Kohnfelder, Praerit Garg, The threats to our products, April 1999, https://adam.shostack.org/microsoft/The-Threats-To-Our-Products.docx
[6] National Institute of Standards and Technology (NIST), Guide for Conducting Risk Assessments, NIST SP 800-30 Rev. 1, September 2012, https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
[7] Jens Braband, Definition and Analysis of a New Risk Priority Number Concept, in: Cornelia Spitzer, Ulrich Schmocker, Vinh N. Dang (Hrsg.), Probabilistic Safety Assessment and Management PSAM 7 — ESREL ‚04, Volume 6, S. 2006, Springer, Juni 2004, ISBN 978-1-4471-1057-6
[8] John Bowles, An Assessment of RPN Prioritization in a Failure Modes Effects and Criticality Analysis, in: Proceedings of RAMS 2003, S. 380, IEEE, Januar 2003, ISBN 978-0-7803-7717-2
[9] Prof. Dr. Werner Gleißner, Wie geht man bei der Monte-Carlo-Simulation vor?, Lexikonbeitrag in: Haufe Finance Office Professional, www.haufe.de/finance/finance-office-professional/m