In unserem zweiten Beitrag zu Cyber Risk Modelling soll es um zwei der aufgeworfenen Fragestellungen aus dem letzten Artikel gehen:
- Welche Schadenbilder resultieren aus welchen Szenarien? Lassen sich Schadenbilder clustern?
- Wie bekomme ich technisches Know-how für eine mögliche Risikomodellierung aufbereitet?
Aus der technischen Perspektive lassen sich zwischen den unterschiedlichen Schadenbildern Gemeinsamkeiten erkennen. Eine Clusterung kann in vier Bereiche erfolgen.
IT-Virus & Malware fasst Schadenszenarien zusammen, bei denen durch Schadsoftware ein Problem in der IT-Infrastruktur verursacht wird. Hierbei ist die technische Betrachtung von IT-Sicherheitsmechanismen ein starker Indikator.
Klassischerweise werden hierbei die Angriffsoberfläche, also die Erreichbarkeit der Systeme, sowie die Rechtevergabe (Stichwort Minimalismus) bewertet. Ein weiterer Einflussfaktor ist die sogenannten Patch Cadence beziehungsweise der Reifegrad an Patch Management. Sicherheitsupdates zu neu aufgedeckten Vulnerabilities müssen möglichst unverzüglich eingespielt werden, da Angreifer ansonsten Schwachstellen ausnutzen, um sich Backdoors auf den Systemen zu installieren. Nachgelagerte beziehungsweise verspätete Patches können damit ihre Wirksamkeit verlieren.
Um das Risiko einer erfolgreichen Virus- oder Malware-Attacke bewerten zu können, braucht es also unterschiedlichste technische Parameter, die nach Einzelbewertung einen guten Gesamtindikator für eine Risikobewertung geben können.
Data Breach bezeichnet ein Cluster an Szenarien, in dem Daten aus interner Infrastruktur entwendet werden.
Die größten Indikatoren hierbei sind die Qualität und Quantität der Daten. Je nach Ausprägung dieser Faktoren muss bewertet werden, wie hoch ein finanzielles Risiko eingeschätzt werden kann. Handelt es sich beispielsweise um Namen, Adressen und andere Kontaktinformationen, so könnte man das Risiko geringer bewerten als zum Beispiel bei der Entwendung von Onlinebanking-Daten, Sozialversicherungsnummern oder anderen Daten, die auch einen Identitätsdiebstahl oder anderes ermöglichen könnten.
Zusätzliche Informationen bezüglich der im Exposure berücksichtigten Datentöpfe könnten als „Quer“-Indikatoren verwendet werden, um die Güte der Daten zusätzlich einschätzen zu können. Dabei beeinflussen erfahrungsgemäß Querbeziehungen und Verknüpfungen von multiplen Datenquellen die statistische Güte und Aussagekraft.
In der Kategorie IT-Provider-Ausfall werden Szenarien subsummiert, bei denen durch unterschiedliche Ursachen ein produktionsrelevanter IT-Provider nicht zur Verfügung steht. Dadurch können Ausfallzeiten entstehen, die zu beträchtlichen Schäden sowohl operativ als auch immateriell führen können.
In diesen Fällen ist es interessant, die IT-Provider-Strukturen der jeweiligen Exposures zu kennen. Meist wird zur Policierung ein Fragebogen erstellt, der teilweise Fragen zu den Providern enthält. Dies berücksichtigt aber häufig nicht, dass der angegebene IT-Provider auch wieder externe Ressourcen nutzt, um seine Dienste anbieten zu können. Daraus kann eine komplexe Kette von Dienstleistern entstehen, die auch durch Kundenangaben nicht immer vollständig erfasst beziehungsweise durchblickt werden kann.
Hier gibt es technische Analysemöglichkeiten, die diese Informationen teilweise bereitstellen können. Dadurch lässt sich eine Art Baum erstellen, der zeigen kann, welcher Service-Provider seine Services in welcher Lokation hostet. Aktuell ist die Vervollständigung noch manuell zu bewerkstelligen, aber auch hier gibt es Ideen zur technischen Unterstützung.
Aufbauend darauf lassen sich Kumul-Risiken identifizieren. Laufen beispielsweise nach Identifikation der Äste alle Service-Provider eines oder mehrerer Exposures in der AWS-Cloud oder auf Microsoft-Servern, ist für das Portfolio ein verstecktes Kumul-Risiko zu berücksichtigen.
Die letzte Kategorie Ausfall kritischer Ressourcen behandelt keine direkten IT-Ressourcen, sondern versucht, Umwelteinflüsse auf die IT-Infrastrukturen zu berücksichtigen. Hierbei geht es beispielsweise um Energie- oder Rohstofflieferanten. Sollte das nahestehende Kraftwerk ausfallen und so zum Ausfall der IT-Systeme führen, so würde auch dies mit hoher Wahrscheinlichkeit eine signifikante Einschränkung des operativen Betriebs zur Folge haben.
Weitere kritische Ressourcen lassen sich in den Bereichen Wasser, Transport, Finanzdienstleistungen oder ähnlichem finden.
Um hier gute Indikatoren zu finden, lassen sich am besten Szenarien entwickeln (zum Beispiel Ausfall einer spezifischen Ressource). Betrachtet man nun die IT-Landschaft des Exposures, so lassen sich Auswirkungen identifizieren, die wiederum zu einer Risikobewertung beitragen können.
Man kann erkennen, dass die Trennung der oben gelisteten Cluster nicht trennscharf erfolgt. Für die Betrachtung kann es aber hilfreich sein, einzelne Exposures in einem oder mehreren der genannten Cluster zu kategorisieren, um dann über unterschiedlichste Möglichkeiten an zusätzliche Indikatoren zur Risikobetrachtung zu gelangen.
Dabei sind die gelisteten Perspektiven eher als Impuls denn als umfängliche Gebrauchsanweisung zu verstehen. Des Weiteren wird in Diskussionen schnell klar, dass keiner der gelisteten Ansätze allein ausreichend ist, um als Basis für eine funktionierende Risikomodellierung zu dienen. Eher könnte man ein Unterstützernetz an Modellen und Methoden aufbauen, um die diversen technischen Einflüsse auf ein Exposure zu berücksichtigen.
In unserem nächsten Beitrag wollen wir uns mit bereits bestehenden mathematischen Modellen beschäftigen und diese auf ihre Voraussetzungen und Anwendbarkeit durchleuchten. Eventuell lassen sich Limitationen der bestehenden Modelle durch passende technische Unterstützermechanismen aufweichen. Wie bei der oben beschriebenen Clusterbildung gibt es auch hierzu unterschiedlichste Perspektiven und mögliche Ansätze.
Wir freuen uns auf den Austausch mit Ihnen – kommen Sie gerne auf uns zu.
Gastautoren: Matthias Blum, David Oliver Michalski
