Bestandsaufnahme Risikomanagement (2) : Problemzonen und Lösungsansätze
Heute übliche Vorgehensweisen im IT-Risikomanagement haben deutliche Schwächen, mahnt unser Autor und ergründet ausführlich Probleme und Lösungsansätze aus der Perspektive des Praktikers. Der zweite Teil behandelt weitere Aspekte der Risiko-Analyse inklusive einer Diskussion der Gefahren für die Informations-Sicherheit.
Der erste Teil dieser Reihe hat allem voran wesentliche Schwächen bei häufig eingesetzten Methoden zur Risikoidentifikation sowie Probleme durch verteilte Verantwortlichkeiten identifiziert und für die folgenden Teile einen Werte- und Risikobegriff definiert. Außerdem wurde ein Ansatz zur Risikoidentifikation grundlegend eingeführt, der „top-down“ vorgeht.
Quantitative und qualitative Risikoanalyse
Quantitative Ansätze zum Risikomanagement sind dort sinnvoll, wo man auf eine Menge gesicherter Erfahrungswerte zugreifen kann, sich etwa valide Erkenntnisse zu Ausfällen (z. B. Defektraten elektronischer oder mechanischer Bauteile) erheben lassen oder diese bereits vorliegen. Wo man über kein ausreichendes Volumen qualitätsgesicherter Daten für eine quantitative Risikoanalyse verfügt (und das wird bei der Informationssicherheit der Regelfall sein), bleibt der Rückgriff auf ein qualitatives Vorgehen.
Der Unterschied wird am Beispiel klarer: „Server X fällt oft für kurze Zeit aus“ ist eine qualitative Beschreibung, „Server X fällt 3 mal pro Woche für 5 Minuten aus“ eine quantitative Beschreibung. Auf den ersten Blick wirkt die quantitative Beschreibung deutlich präziser – und wenn man diese Ausfallrate und -dauer auf Basis langfristiger Beobachtungen festgestellt und sich nichts an der Situation geändert hat, dann ist sie das auch. Zieht man hierfür jedoch nur die Daten einer einzigen Woche heran, entsteht ein stark verzerrtes Bild der Ausfallrate.
Auch der Umfang der Prüfgruppe ist von großer Wichtigkeit (Stichwort „Gesetz der großen Zahl“): Im einen Extrem liegt eine sehr große heterogene Messgruppe vor, beispielsweise Erfahrungsdaten von 20 000 unterschiedlichen Servern über 10 Jahre – dann besitzt eine hieraus gewonnene Aussage eine gewisse Allgemeingültigkeit. Im anderen Extrem könnte man ein Modell für einen einzigen, sehr spezifischen Server betrachten. Datenqualität ist jedoch ein weitläufiges Feld, das ein Fachbeitrag wie dieser unmöglich in aller Tiefe behandeln kann. Eine zentrale Schwäche der qualitativen Risikoanalyse soll allerdings nicht unerwähnt bleiben: Die qualitative Bewertung fußt auf einer Ordinalskala, deren Intervall jedoch in aller Regel nicht klar zu benennen ist.
Sowohl quantitative als auch qualitative Methoden stützen sich auf die Wahrscheinlichkeit des Eintretens (Feasibility, Probability, Likelihood etc.) eines Risikos und den resultierenden Schaden (Damage, Impact, Consequence). Eine weitere relevante Größe (aus der FMEA-Methode) ist die Detektionswahrscheinlichkeit: ein qualitativer Wert für die Wahrscheinlichkeit der Entdeckung eines Fehlers vor der Manifestation eines Risikos. Ein Beispiel: Vor Antritt einer Fahrt mit einem PKW ist der Fahrer angehalten, eine Sichtprüfung des Fahrzeugs vorzunehmen, unter anderem des Zustands und Drucks der Reifen. Hält man sich daran, ist die Detektionswahrscheinlichkeit eines Reifendefekts sehr hoch (und erhält damit den Wert 1 „sicher“ oder 2 „sehr wahrscheinlich“, s. u.) – die Wahrscheinlichkeit des Eintritts eines katastrophalen Schadens durch ein Reifenproblem wird (mittelbar) reduziert.
Zu beachten ist, dass die Detektionswahrscheinlichkeitskennzahl mit einer absteigenden Wahrscheinlichkeit ansteigt: Bei einem Wertbereich von 1–5 entspricht eine „sichere“ Detektion dem Wert „1“, ist eine Detektion hingegen „unmöglich“, wird der Wert „5“ verwendet. Das Produkt aus Risikohöhe, Auftritts- und Detektionswahrscheinlichkeitswert stellt in der klassischen „Failure Mode and Effects Analysis“ (FMEA, [1,2] – vgl. Kasten auf S. 52) den sogenannten Risikoprioritätswert dar. Eine bekannte Schwäche hängt dabei mit dem Algorithmus zur Ermittlung dieses Wertes zusammen – diese lässt sich aber, wie in [3] beschrieben, recht einfach umgehen.
Weder qualitative noch quantitative Methoden sagen übrigens etwas zur Ursache (Root-Cause) oder zur Bedeutung für den Prozess aus (qualitativ: „macht nix, startet ja gleich wieder“ – quantitativ: „wir verlieren ca. 20 Mann-Minuten pro Monat“), der den betreffenden Wert integriert.
Statistische Erfahrungswerte
Das logische Vorgehen zur Planung des Risikomanagements wäre, zunächst qualitativ hochwertige statistische Daten zu beschaffen und zu analysieren. Entscheidend für die Planung wären die Frequenz von Ereignissen und Verteilung nach Schweregraden, idealerweise in Organisationen, die vergleichbar zum eigenen Haus sind. Die verfügbare Menge belastbarer Daten fällt bei der Cyber-Sicherheit jedoch erstaunlich gering aus.
Sollte man den Schutz vor häufigen kleinen Vorfällen demjenigen von seltenen großen Vorfällen vorziehen? Arbeitet man besser auf eine Absenkung des Schweregrads hin oder sollte eine Reduktion der Summe an Vorfällen im Mittelpunkt stehen? Sind große Vorfälle überhaupt seltener als kleine? All das sind eigentlich Fragestellungen, die jeder Anwender der ISO 27001 zur Gestaltung des ISMS nach dem Paradigma der Angemessenheit zwingend klären sollte. Umso überraschender ist es, dass solche essenziellen Daten nur in fragmentarischen Teilbetrachtungen auffindbar sind (etwa in Verizons Data Breach Investigation Reports [4], Accentures Cost of Cyber Crime [5] oder IBMs Cost of a Data Breach Studies [6] oder auch den <kes>-Sicherheitsstudien für den deutschsprachigen Raum).
Als besonders hilfreiche Quelle soll hier „An Empirical Analysis of Cyber Security Incidents at a Large Organization“ [7] genannt sein: Auch wenn die Darstellung für Nicht-Mathematiker nicht gerade eingängig ist, ermöglicht das Papier doch interessante Rückschlüsse sowohl in Hinblick auf die Dimensionierung der technischen Forensik wie auch der strategischen Ausrichtung der SecOp-Teams. Hierzu wurden 60 000 „echte“, mit quantitativen Daten unterlegte Vorfälle aus einem Zeitraum von über 6 Jahren betrachtet – einschränkend ist allerdings auch hier anzumerken, dass es sich um Daten einer einzigen Organisation aus einer nicht genannten Branche handelt. Und branchenspezifische Unterschiede sind sehr wohl vorhanden und signifikant, wie etwa die Durchsicht des DBIR 2018 [4] zeigt – auch wenn dort wiederum ein so geringes Volumen von Werten betrachtet wurde, dass Ergebnisse dieser statistischen Analyse mit Vorsicht zu genießen sind.
Scoping
Um die Größe oder das Gewicht eines Risikos zu erheben, ist seitens der Prozessarchitektur eine horizontale und gegebenenfalls auch eine vertikale Begrenzung des Betrachtungsraums (Scope) vorzunehmen, um eine transparente, schlüssige und folgerichtige Bewertung zu erhalten.
Für das Scoping ist der Risiko-Horizont entscheidend: Alles was davor liegt, können wir im Detail überblicken – das schließt Abhängigkeiten, Auswirkungen, Kosten, Schäden und Folgeschäden ein. Liegen Prozesse oder Prozessanteile hinter dem Risiko-Horizont, lassen sich diese Parameter nicht oder nicht ohne Weiteres erkennen – sie liegen zum Beispiel außerhalb der Organisation oder des Unternehmens.
Innerhalb des Horizonts liegen jedoch auch (und dies ist von Bedeutung!) Leistungen, die von externen Organisationen für den betrachteten Service zugeliefert werden: Auch wenn der Gesamtprozess zur Erbringung dieser Leistungen außerhalb der eigenen Sichtlinie liegt, sind doch zumindest die Schnittstelle sowie ihre Zustände und Parameter transparent zu erhalten. Allerdings wird das Stichwort „Lieferantenmanagement“ in ISMS-Standards wie der ISO/IEC 27001:2015 leider nur angeschnitten.
Es ist jedenfalls wichtig, sich des Risiko-Horizonts bewusst zu sein! Gegebenenfalls ist es sogar empfehlenswert, einen künstlichen Horizont, etwa auf vertraglicher Basis (z. B. per Leistungsbeschreibung) zu definieren. Einige konkrete Beispiele benennt Tabelle 1.
FMEA zur Risikoidentifikation und -analyse
Die „Failure Mode and Effects Analysis“ (FMEA) ist eine Gruppe von Methoden zur Vermeidung von Fehlern und Steigerung der Zuverlässigkeit, die vergleichsweise einfach zu erlernen und anzuwenden sind ([1,2], s. a. www.risknet.de/wissen/rm-methoden/fmea/). FMEA-Methoden können auch in kleinen Gruppen genutzt werden, um wertvolle Erkenntnisse zu Fehlerbildern und damit verbundenen Risiken zu erheben. Das vorrangige Ziel ist die Vermeidung von Fehlern und Schwachstellen sowie hieraus entstehenden Konsequenzen.
Der mit einer FMEA verbundene Arbeitsaufwand hängt stark von dem betrachteten Produkt oder Prozess sowie der Tiefe der Analyse ab. Die Methodik wird typischerweise bereits in der Design-, Planungs- oder Entwicklungsphase angestoßen, um (kritische) Fehler, Schwachstellen und Konsequenzen kosten- und aufwandsoptimiert zu erkennen und ihnen zu begegnen. Eine spätere Anwendung ist zwar weniger effizient, die Effektivität bleibt jedoch gewahrt.
Passendes Arbeitsmaterial von Excel-Sheets bis zu unterstützenden Modellierungswerkzeugen findet man teilweise auch kostenlos und in guter Qualität im Internet (siehe etwa www.business-wissen.de/hb/werkzeuge-fuer-das-fmea-projekt/ oder https://www.kvp.de/fmea/). Es ist dabei immer hilfreich, einen erfahrenen „Verfahrensmoderator“ in die Gruppe aufzunehmen: Seine Aufgaben sind die Überwachung der formalen Richtigkeit in der Anwendung der Methode, die Dokumentation (z. B. in Spezialsoftware) sowie allem voran die Moderation der Gruppe in Bezug auf Themenrelevanz, Redezeiten und Teilnehmerkreis.
Kriterien, Gewichtung und Kritikalität
Die Anzahl der Verbindungen (Referenzen) im Prozessdiagramm zu einem Wert der Organisation, einer Funktion, Prozedur oder Schnittstelle ist, wie schon in Teil 1 angemerkt, ein Indikator, der für eine Gewichtung herangezogen werden kann. Eine hohe Anzahl von Verbindungen zu einer Funktion deutet auf eine tiefe Integration und einen hohen Grad von Abhängigkeiten hin. Prozessseitig ist die Position eines Werts in dieser Topografie ebenfalls ein Indikator: Typischerweise sind Funktionen, die weit vorne in Prozessketten beziehungsweise unten in der Prozesshierarchie (nahe der Wurzel) stehen, höher zu gewichten. Dies trifft meist auf „fundamentale“ Funktionen zu – ein Beispiel für einen solchen unterstützenden Wert wären typische Basisdienste der IT, etwa das Standort-LAN. Die Relevanz einer Funktion, Prozedur oder eines Prozesses für ein oder mehrere Prozessketten ist ein Parameter, der manuell erhoben werden muss. Hierzu können nach NIST SP 800-30 ein Tier-2-Assessment oder die FMEA-Methode Anwendung finden (vgl. Kasten). Zu klären ist, ob der integrierende übergeordnete Prozess seine Funktion erfüllen kann, wenn die untergeordnete Prozedur beeinträchtigt ist, oder ob diese obligatorisch für die Erreichung des Prozessziels ist (vgl. Abb. 1).
Ist eine Funktion von erheblicher Relevanz für das Erreichen eines Prozessziels, ist diese Abhängigkeit entsprechend hoch zu gewichten – ist eine untergeordnete Prozedur hingegen von geringer Relevanz oder irrelevant für die Zielerreichung, kann eine Abwertung erfolgen. Lässt sich eine Prozedur durch eine andere substituieren, besteht also Redundanz, kann ebenfalls eine Abwertung erfolgen.
Abhängigkeiten über die Zeitachse
Zeitliche Größen spielen in solchen Abläufen ebenfalls eine große Rolle: Nicht jeder Verlust einer Funktion hat gleich eine unmittelbare Auswirkung auf eine Prozesskette. Zwei Zeitfenster sind hier von besonderem Interesse: Time to Impact: Zeitraum vom Eintreten eines Funktionsverlusts bis zu einer spürbaren Auswirkung auf die Prozesskette oder den Prozess höherer Ordnung Time to Occurrence of Risk: Zeitraum vom Eintreten eines Funktionsverlusts bis zum Auftreten eines Risikoeintritts in der Prozesskette oder dem Prozess höherer Ordnung In Anbetracht der zeitlichen Koordinate tritt die bereits vorgestellte Detection-Probability erneut ins Rampenlicht: Eine hohe Detektionswahrscheinlichkeit wirkt abwertend auf die Kritikalität, eine geringe Wahrscheinlichkeit aufwertend.
Einordnung in Risikokategorien
Eine sinnvolle Granularität der Risikokategorien sowie die Berücksichtigung weiterer Faktoren neben monetären Auswirkungen (z. B. Gefahren für Leib und Leben) ergibt sich aus dem Scoping. In der Praxis findet man typischerweise 3–5 Kategorien, die bei quantitativem Vorgehen entweder durch Schwellenwerte oder eine Wertespanne definiert sind. Von Bedeutung ist hierbei die Entscheidung, konstante oder inkonsistente Intervalle einzusetzen:
- konstante Intervalle vereinfachen die Arbeit mit Risikowerten deutlich, reduzieren die Komplexität und erhöhen die Präzision
- inkonsistente Intervalle erleichtern hingegen oft eine Kategorisierung von Risiken
Ein häufig auftretender Fehler bei der quantitativen Definition von Risikoklassen ist eine zu niedrigschwellige Definition, beispielsweise schon ab 0 €: Ist denn ein Schaden von wenigen Euro wirklich ein Risiko für Unternehmensziele? Alles, was als Risiko erfasst wird, muss man schließlich auch verwalten, validieren, wiederholt prüfen, evaluieren und (ggf. kostspielig) behandeln, vermeiden oder transferieren. Daher sollte als untere Grenze ein Schwellenwert dienen, der auch tatsächlich ein (kleines) Risiko für den Prozesserfolg darstellt! Einen geringfügigen Schaden wird man hingegen ignorieren oder schlicht tragen – als erste quantitative Risikokategorie wäre so beispielsweise 2.500–10.000 € denkbar.
Immer wieder Diskussionsgegenstand sind Reputationsschäden, deren (qualitative oder quantitative) Klassifizierung in der Praxis kaum möglich erscheint. Wo keine eindeutigen und ernst zu nehmenden Hinweise auf einen möglichen Reputationsschaden durch ein Sicherheitsrisiko vorliegen, empfiehlt es sich, von einer Betrachtung dieser Größe gänzlich abzusehen.
Bei einem qualitativen Vorgehen definiert man indessen eine Ordinalskala. Intervalle oder Schwellenwerte lassen sich dabei nicht nutzen, Relationen sind aber durchaus verwendbar – beispielsweise hinsichtlich von „Tragweite“ oder „Konsequenzen“. Ein semiquantitatives Vorgehen, das etwa die Tragweite auf Basis des Volumens betroffener Kunden/Nutzer definiert, ist sogar recht üblich und lässt sich oft gut quantifizieren, da zugehörige Werte technisch oder buchhalterisch vielfach gut zu ermitteln sind.
Holistische Risikoanalyse
Für eine holistische qualitative Risikoanalyse sollte man eine Reihe von Informationen zu den Werten (Informationen), den unterstützenden Werten (z. B. Server, Personal, Gebäude) sowie mitwirkenden Prozessen und Organisationen zusammentragen. Ein Inventar der konsumierten Prozesse, der eingebundenen unterstützenden Werte sowie Informationen (bzw. zu verarbeitenden Informationskategorien) stellen hier einen guten Ausgangspunkt dar.
Es bietet sich an, mittels Methoden aus dem FMEA-Umfeld die folgenden Daten zu erheben: Relevanz (bzw. funktionale Kritikalität), Gewichtung und Kritikalität wertebezogener Sicherheitsziele, die Zeitfenster vom Eintreten eines Ereignisses bis zu dem Eintreten (a) einer Auswirkung, (b) eines Risikos sowie (c) der Wiedererreichung des Zielzustands, Aufwand und Kosten zur Wiedererreichung des Zielzustands sowie zur Behandlung der Folgen eines Ereignisses, schließlich die Detektionswahrscheinlichkeit eines Ereignisses.
Tabelle 2 liefert einige Beispiele hierzu.
Risikomodell
Ein Risiko besteht auch in der Informationssicherheit immer aus einem Trigger/Auslöser (Bedrohung, Threat), einer Anfälligkeit, Schwäche oder Schwachstelle (Vulnerability) eines unterstützenden Werts oder einer Funktion (Supporting Asset) und einem Schadenspotenzial (Damage-Potential). Nur wenn Bedrohung, Verwundbarkeiten, Gefährdungs- und Schadenspotenzial zusammentreffen, besteht ein Risiko. Ohne Schadenspotenzial gibt es kein Risiko, ohne Schwachstelle ebenfalls nicht, ohne Gefährdungspotenzial ist eine Schwachstelle irrelevant und so weiter.
Dabei ist zu beachten, dass es zwar in der Natur von primären Werten (Primary Assets) liegt, Schwächen aufzuweisen, man auf diese jedoch nicht unmittelbar einwirken kann. Die Anfälligkeiten eines primären Werts entstammen den Zielparametern (z. B. Verfügbarkeit, Integrität, Vertraulichkeit), mit denen wir ihn attribuieren und können pauschal als „Veränderlichkeit von Eigenschaften“ aggregiert werden.
Die Einwirkung durch Bedrohungen erfolgt vielmehr, wie in Abbildung 2 visualisiert, mittelbar über Schwachstellen (technischer wie organisatorischer Natur), die unterstützende Werte und Funktionen aufweisen. Unabhängig von ihrer Auswirkung auf primäre Werte können unterstützende Werte zudem auch einen „eigenen“ Schaden (DP) erleiden, der aufgrund eines Gefahrenszenarios (PH) ausgelöst wird.
Der umschließende Prozess (siehe Abb. 3) besitzt darüber hinaus eine steuernde Rolle, er regelt die Exposition von (unterstützenden) Werten zur Minimierung von Risiken und Ermöglichung von Chancen – außerdem kann er auch selbst Schwachstellen und Schadenspotenzial besitzen. Wer noch genauer modellieren möchte, kann in das Beziehungsmodell weitere unterstützende Werte und wirkneutrale Objekte als sogenannte Forwarder (F) aufnehmen oder/und es um technisch/organisatorische Maßnahmen zur Risikoreduktion (Mitigation) erweitern, die als Widerstandsfaktoren (R) zwischen verschiedenen Assets wirken.
Ob eine identifizierte Kette von einer Bedrohung bis hin zum Schadenspotenzial für den Scope ein Risiko im unternehmerischen Sinne darstellt, legt man letztlich über die quantitativen Schwellenwerte oder qualitativen Kategorien fest. Neben der Höhe eines individuellen Schadens wird oft die Häufigkeit des (voraussichtlichen) Auftretens herangezogen, um die Gesamtschadenshöhe innerhalb eines Zeitfensters zu antizipieren – etwa qualitativ „sehr selten, selten, gelegentlich, regelmäßig, häufig, sehr häufig“ oder quantitativ „jährlich, monatlich, wöchentlich, täglich, stündlich“.
Wo keine umfänglichen historischen und idealerweise organisationsspezifischen Daten herangezogen werden können, ist allerdings auch dieses Vorgehen oft mehr „Kaffeesatzleserei“ als „Wissenschaft“. Als zeitlichen Horizont findet man in der Praxis dabei alles zwischen einem und zehn Jahren. Nach den Erfahrungen des Autors sollte man jedoch eine Zeitspanne von mindestens fünf Jahren ansetzen – das ist dann übrigens auch konform zum Risikomanagement nach BSI 200-3.
Bedrohungsanalyse
Hinsichtlich der Bedrohungen sei an dieser Stelle nur angemerkt, dass sich (auch) ein Cyber-Threat aus unterschiedlichen Aspekten zusammensetzt (vgl. Abb. 2), von denen zwar Täter/Akteur, Befähigung, Motivation und Gelegenheit an sich die Wichtigsten sind – entsprechende Betrachtungen in der Praxis allerdings oft eher akademisch bleiben: Zu viele unbekannte Faktoren liegen dabei außerhalb jeder organisatorischen Kontrolle – Sichtbarkeit und Messbarkeit spielen hierbei eine zu große Rolle. Und um die schnelllebigen Faktoren der IT-Welt zu betrachten, ist ein Risikomanagement oft zu träge.
Außerdem gehören zu den prominentesten Vertretern der Tätergruppe das „Raumzeitkontinuum“ und unveränderliche physikalisch-chemische Eigenschaften der Materie, die zu Gefahren durch Alterung von Systemen und Algorithmen (bis hin zu kryptografischen Verfahren), aber oft auch schlicht zu Abnutzung, statischer Entladung, Überflutung et cetera führen – hinzu kommen Fahrlässigkeit und menschliches Versagen als wichtige „Täter“. Für all das ist eine Ausmodellierung der Bedrohungen kaum zielführend.
Lohnende Quellen für die Suche nach IT-Bedrohungen sind neben den bereits angesprochenen „Fallstudien“ [4, 5, 6] auch die jährlich veröffentlichten Analysen des BSI [8] und der ENISA [9] sowie der „Cisco Annual Cybersecurity Report“ [10].
Gefahren für Informationen
Die drei Klassiker unter den Gefahren für die Informationssicherheit sind der Verlust der Verfügbarkeit (Availability), Integrität (Integrity) und/oder Vertraulichkeit (Confidentiality). Im Kontext einer Organisation können weitere Attribute eine Rolle spielen, unter anderen etwa Nicht-Abstreitbarkeit, Authentizität, Zuverlässigkeit, Nachweisbarkeit (z. B. in der Buchhaltung), Pünktlichkeit (z. B. bei Transaktionen), Korrektheit und Genauigkeit (Abweichung, Toleranz, Varianz). Die Gefahr besteht immer in einem Verlust, einer Minderung oder Beeinträchtigung gegenüber einem definierten Zielwert mit einem (ggf. potenziell) negativen oder auch unbekannten Effekt auf das Ergebnis oder die Zielerreichung.
Gleichlauf von Schutzzielen
Verfügbarkeit bedeutet, dass eine Information erhebbar oder zugänglich ist; sie kann in Wissen und Besitz übergehen. Das verlangt eine Interpretation, also die Verknüpfung aus Kontext und Datum (vgl. Kasten). Integrität ist als ein abstrahiertes Attribut zu verstehen – auf der Metaebene der „Makellosigkeit“ umfasst sie etwa Nachvollziehbarkeit und Korrektheit. Die genaue Definition erschließt sich nur aus dem Kontext.
Der Verlust der Verfügbarkeit sowie der Verlust der Integrität des primären Wertes „Information“ führen beide zu einem Verlust der Information – beziehungsweise zu einem Zustand, der ihre Erhebung unmöglich macht. Die Integrität und Verfügbarkeit von Information lassen sich über Aspekte der Repräsentation von Daten, Kontext und Interpretation beeinflussen – jede Modifikation dieser Aspekte verändert die resultierende Information.
Die Ähnlichkeiten zwischen den beiden Schutzwerten zeigen sich auch bei Schäden durch Kryptotrojaner (Ransomware): Handelt es sich dabei vorrangig um einen Verlust der Verfügbarkeit von Daten oder einen Integritätsverlust? Beide Perspektiven sind legitim, für den Weg entlang der Kausalkette jedoch irrelevant – und die Folgen bleiben identisch. Auch in vielen anderen Szenarien führt eine Zusammenfassung der Schutzziele Integrität und Verfügbarkeit zu einem deutlich einfacheren (und für Laien verständlicheren) Vorgehen.
Ein Verlust der Vertraulichkeit einer Information ist eine Folge des Verlusts der Kontrolle über die Information oder der Steuerbarkeit ihrer Erhebbarkeit/Auswertung – anders ausgedrückt eine Veränderung der vorgesehenen Verarbeitung, also der Integrität des verarbeitenden „Systems“. Die Vertraulichkeit einer Information ist jedoch erst dann kompromittiert, wenn Unbefugte neben der Kontrolle über gespeicherte Daten auch die Befähigung zu deren Interpretation erlangt haben (aber Achtung: teilweise ist eine Rekonstruktion dieses Wissens durch Korrelation oder Beobachtung möglich).
Den Übergang (durch Interpretation) von Daten, Kontext und Wissen zu Information auszuschließen, ist nach einem (ggf. auch nur teilweisen) Verlust der Kontrolle nur bedingt möglich, jedoch ist die Wahrscheinlichkeit hierfür beeinflussbar. Sie hängt unter anderem von der Repräsentation der Daten, dem Grad ihrer Abstraktion, dem Grad der Entfremdung zwischen Kontext und Datum (Transparenz/Evidenz/Intuitivität oder Verborgenheit des Zwecks) sowie der Obskurität (Umfang des aus den Daten selbst erhebbaren Kontexts) ab.
Bewertung von Informationen
Der Wert einer Information und der Wert ihrer Qualitäten und Eigenschaften (C/I/A) ist oft sehr schwer zu quantifizieren. Information gilt als neue Währung – das bedeutet aber auch, dass der Markt ihren Wert bestimmt. Eine häufig genannte „Dimension“ dieses Werts sind die Kosten der Informationsgewinnung (z. B. Forschung und Entwicklung oder der Aufwand hinsichtlich der Validierung von Daten).
Aus der Perspektive des Angreifers und somit auch aus dem Blickwinkel des Informations-Sicherheits-Managements sind die folgenden Dimensionen ebenfalls von besonderem Interesse:
- Vielseitigkeit: Kann man die Information in einer Vielzahl möglicher Prozesse (bzw. Use-Cases) verwenden – ist sie vielseitig anwendbar oder eröffnet sie besonders vielfältige und große Chancen?
- Detaillierungs-/Reifegrad sowie Tiefe: Ist die Information holotisch (vollständig/abgeschlossen, z. B. Benutzername und Passwort), fragmentarisch (z. B. Benutzername oder Passwort) oder auch synonym (z. B. Eigenschaften eines Fingerabdrucks, Checksumme eines Passworts oder Ciphertext)?
Informationen mit hoher Detailtiefe und hoher Vielseitigkeit (z. B. umfassende Nutzerprofile oder Bonitätsbewertungen) stellen einen höheren Wert dar als reine Sammlungen von Klar- und Nutzernamen oder E-Mail-Adressen. Je tiefer, spezifischer und/oder reifer eine Information ist, desto größer ist in der Regel der Mangel am „Markt“ – weniger Personen/Organisationen haben Zugang zu dieser Information, verfügen über sie oder sind fähig, sie zu erzeugen.
Zur Visualisierung kann man ein „magisches Quadrat“ bilden (nach der Boston Consulting Group auch als BCG-Matrix bekannt), in dem die X-Achse die Vielseitigkeit und die Y-Achse die Informationstiefe repräsentiert (Abb. 4). Dann sind unsere „Stars“ Informationen, die in beiden Bereichen hohe Werte erzielen und somit große Chancen eröffnen (z. B. umfassende Fertigungsdaten) – „Cashcows“ sind vielseitig verwendbar (z. B. validierte Adress- und Kreditkartendaten oder Benutzerprofile). Bei „Poor Dogs“ handelt es sich hingegen um unspezifische oder als solche wertlose Informationen (z. B. Handbücher). „Questionmarks“ sind Informationen mit hoher Tiefe (bzw. hohen Erhebungskosten), deren praktische Anwendbarkeit jedoch – zumindest noch – unbekannt ist (z. B. aktuelle Forschungsdaten oder auch unveröffentlichte Pressemitteilungen).
Aus diesen „Marktwerten“ ergibt sich einerseits ein Schutzwert und andererseits – bei wirtschaftlicher Betrachtung – auch der maximal sinnvolle Einsatz für die Beschaffung der bewussten Information. Aus dem Blickwinkel der Akteure staatlich oder privatwirtschaftlich finanzierter Wirtschaftsspionage muss der „dunkle Kanal“ gegenüber der klassischen Erhebung der Information (z. B. durch Forschung/Entwicklung oder Akquise) Vorteile bieten, also etwa schneller, zuverlässiger oder günstiger sein.
Das Ziel der Informations-Sicherheit in Wirtschaft und Industrie ist es daher auch, die Wirtschaftlichkeit missbräuchlicher Methoden zur Informationsbeschaffung über diesen Kostenfaktor zu regulieren und so einzugrenzen oder dem Akteur Motivation oder Geschäftsmodell zu entziehen, indem man dafür sorgt, dass (Angriffs-) Kosten oder Zeit den Nutzen übersteigen (evtl. auch durch Androhung/Anwendung rechtlicher Mittel). Hierbei können neben dem Erschweren des direkten Wegs zur Information auch ein „Spiel auf Zeit“ oder gezielt gestreute/platzierte Desinformation (Honigtöpfe) helfen.
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.
Der dritte und letzte Teil der Reihe wird in der nächsten <kes> auf Gefährdungen von unterstützenden Werten und Prozessen sowie Standardisierungsaspekte eingehen.
Literatur
[1] Deutsche Gesellschaft für Qualität (DGQ, Hrsg.), FMEA – Fehlermöglichkeits- und Einflussanalyse, Beuth, 2012, ISBN 978-3-410-32333-4
[2] Martin Werdich (Hrsg.), FMEA – Einführung und Moderation, Durch systematische Entwicklung zur übersichtlichen Risikominimierung, Springer Vieweg, 2012, ISBN 978-3- 8348-1787-7
[3] Jens Braband, A Remedy for a Serious Flaw in the Risk Priority Number Concept, Vortragsfolien, Februar 2004, www.rvs.uni-bielefeld.de/Bieleschweig/third/Braband-B3-2004.pdf
[4] Verizon, Data Breach Investigations Report, Portalseite, https://enterprise.verizon.com/de-de/resources/reports/dbir/
[5] Accenture, Cost of Cybercrime Study, Portalseite, www.accenture.com/us-en/insights/security/costcybercrime-study
[6] IBM, Cost of a Data Breach Report, Portalseite, https://www.ibm.com/security/data-breach
[7] Marshall A. Kuypers, Thomas Maillart, Elisabeth Paté-Cornell, An Empirical Analysis of Cyber Security Incidents at a Large Organization, Working Paper, 2016, https://fsi.stanford.edu/publication/empiricalanalysis-cyber-security-incidentslarge-organization
[8] BSI, Die Lage der IT-Sicherheit in Deutschland, Portalseite, www.bsi.bund.de/Lageberichte/
[9] ENISA, Threat Landscape, Portalseite, www.enisa.europa.eu/topics/threat-risk-management/threatsand-trends/enisa-threat-landscape
[10] Cisco, Annual Cybersecurity Report, Portalseite, www.cisco.com/c/de_de/products/security/securityreports.html