Willkommen zum vierten und letzten Artikel unserer Reihe. Der vorherige Artikel schloss mit dem Gedanken ab, dass Cyberrisiken aktuell nicht mit den „klassischen Ansätzen“ der aktuariellen Risikomodellierung bewertet werden können. Es fehlen die Grundlagen wie große historische Datenpools mit homogenen Risiken und entsprechenden Schadenerfahrungen sowie Expertenwissen sowohl für faktorbasierte Ansätze als auch für probabilistische Modelle. In der aktuellen Lage bleiben also nur Näherungslösungen, die mit der Zeit systematisch ausgebaut werden können.
Zur Unterstützung einer solchen Lösung wurde eine Idee aus der CAT-Risk-Modellierung adaptiert. Für die Modellierung solcher Risiken werden im Allgemeinen zusätzliche Modelle wie Klima- oder andere geophysikalische Betrachtungen hinzugezogen.
Könnte man also einen ähnlichen Ansatz für Cyberrisiken verwenden, indem man etwa unterschiedliche IT-Infrastruktur-Topologien betrachtet und versucht, diese in ihrer Entwicklung in eine Art Modell zu bringen?
Diese Perspektive wirft direkt neue tiefergehende Fragestellungen auf:

  1. Lassen sich IT-Infrastrukturen so schematisieren, dass sie sich homogenen Clustern zuordnen lassen?
  2. Lassen sich Entwicklungen/Veränderungen solcher Strukturen modellieren?
  3. Je nach Ausprägungen solcher Infrastrukturen gibt es unterschiedliche Angriffspunkte. Sind diese zu benennen und wie sehen mögliche Angriffsszenarien aus?

Wichtig hierbei ist: Die Lösung muss nicht perfekt sein – sie muss nur ausreichend sein, um über die aktuelle Problematik der fehlenden Erfahrungswerte (https://insurance-experts.ppi.de/cyber-risk-modelling-wie-gut-funktionieren-klassische-modellierungsansaetze/) hinwegzuhelfen. Im Folgenden wollen wir die aufgeworfenen Fragen weiter beleuchten.

  1. Lassen sich IT-Infrastrukturen so schematisieren, dass sie sich homogenen Clustern zuordnen lassen?
    IT-Architekturmodelle bestehen aus einer Reihe von Systemen (Betriebssysteme, Fachsoftware, Datenbanken, …) und entsprechenden Schnittstellen.
    Gibt es grundlegende Technologien, die die Kommunikationsbasis der Systeme untereinander bilden, so kann dies entsprechend berücksichtigt werden. Gleiches gilt für die Art der zu berücksichtigenden Systeme. Handelt es sich um Standardsoftwarelösungen oder Eigenentwicklungen? Wie sind hier die jeweiligen Sicherheitsstandards?
    Eine Möglichkeit wäre, unterschiedliche Messgrößen für eine Betrachtung zu definieren und dadurch eine Indikation für eine Risikomodellierung zu gewinnen. Eventuell lassen sich so modellierungsrelevante Schemata identifizieren und Muster erkennen.
    .
  2. Lassen sich Entwicklungen/Veränderungen solcher Strukturen modellieren?
    IT-Architekturen stehen unter hohem Digitalisierungsdruck. Es gehen immer mehr Prozesse in die Automatisierung, die Betrachtung wird zunehmend kundenzentriert und Anpassungen sowie Neuerungen werden immer schneller benötigt, um mit dem Markt Schritt halten zu können.
    Es gibt folglich einen Prozess, den jede IT-Architektur im Einzelnen durchschreitet. Je nach Fortschritt lassen sich mögliche nächste Schritte benennen, die benötigt werden, um aktuellen Trends gerecht zu werden.
    Versucht man nun, diesen Entwicklungsprozess von der spezifischen Architektur zu lösen, könnte dadurch ein Modell entstehen, das für den oben genannten Zweck geeignet erscheint.
    Diese Betrachtung ist allerdings nur eine der Perspektiven. Eine weitere und vielleicht sogar wichtigere ist die der Pflege- und Update-Prozesse der Einzelkomponenten einer Landschaft. Hierbei kommt die Dimension Mensch mit in die Betrachtung. Für eine Modellierung könnten hier SLAs (Service-Level-Agreement) und andere Grundlagen wie zum Beispiel Release- und Softwarezyklen für die Pflege der Systemlandschaft herangezogen werden.
    .
  3. Je nach Ausprägungen solcher Infrastrukturen gibt es unterschiedliche Angriffspunkte. Sind diese zu benennen und wie sehen mögliche Angriffsszenarien aus?
    Es gibt viele Möglichkeiten, diese Frage zu beantworten. Wir wollen an dieser Stelle keine tiefergehende Analyse fahren, sondern eher auf vorhandene Fachliteratur (1) verweisen. Der für uns wichtigste Aspekt ist hier die Bildung von Clustern, um eine Grundlage für eine Risikomodellierung zu schaffen. Beispiel für homogene Cluster wären in diesem Fall On-Premise-Windows-Domänen mit Active Directory, Exchange Server und Outlook.
    Abhängig von der Tiefe des Modells für die IT-Architektur eines Exposures bieten sich unterschiedliche Ansätze an. Sie haben gemeinsam, dass Know-how aus Bereichen der IT-Architektur, der IT-Sicherheit, der Cyberrisikomodellierung, aber auch der Fachlichkeit der jeweiligen Branche Berücksichtigung finden muss.PPI ist ein starker Partner sowohl in tiefergehendem Fach-Know-how als auch in der Moderation und Lösungsgestaltung zwischen den unterschiedlichsten Bereichen und Wissenden …

(1) MITRE Enterprise Matrix

Gastautoren: Matthias Blum, David Oliver Michalski

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwandte Artikel