Vulnerability Management ist ein elementares Werkzeug, um die Sicherheit in einem System bzw. einer Umgebung gewährleisten zu können. Durch das Zusammentragen relevanter Informationen soll die Grundlage für Entscheidungen getroffen werden. Was sich auf den ersten Blick einfach anhört, stellt sich bei näherer Betrachtung als aufwändige und komplexe Aufgabe heraus. Dieser Beitrag beleuchtet die verschiedenen Aspekte und wie diese angegangen werden können, um ein professionelles Vulnerability Management etablieren zu können.

Um Vulnerability Management betreiben zu können, müssen in einem ersten Schritt Informationen zu Schwachstellen (engl. vulnerabilities) gesammelt werden. In den 1990er Jahren waren Security-Mailinglisten, Researcher und Hersteller haben dort ihre Erkenntnisse veröffentlich, die Hauptquelle hierfür. Diese gelten aber seit Jahren als archaisch und sind über die Zeit hinweg buchstäblich ausgetrocknet. Durch die zunehmende Professionalisierung von Cybersecurity orientierte man sich fortan an den offiziellen Advisories, die durch die Hersteller betroffener Produkte herausgegeben wurden.

Sammeln von Sicherheitslücken

Das Zusammentragen von Informationen zu Schwachstellen ist enorm aufwändig, da es nicht unüblich ist, dass in einer Umgebung mehrere Hundert oder gar Tausend verschiedene Produkte zum Einsatz kommen. Mit der Einführung des CVE-Programms wurde eine Standardisierung und Zentralisierung erreicht. Ursprünglich ausschliesslich durch MITRE bewirtschaftet, werden dort veröffentlichte Schwachstellen mit eindeutigen Identifikatoren, den sogenannten CVEs, versehen. Seit einigen Jahren nehmen verschiedene CVE Numbering Authorities (CNA) am Projekt teil, die im Rahmen ihres Scopes ebenfalls CVEs zuweisen können. In erster Linie handelt es sich dabei um die Hersteller selbst, die entsprechende Hoheit über ihre Produkte haben. Es gibt aber auch herstellerunabhängige CNA, wie zum Beispiel CISA ICS-CERT und VulDB, die CVEs an verschiedenen Produkttypen zuweisen können.

Die Anzahl der veröffentlichten Schwachstellen hat in den vergangenen Jahrzehnten stetig zugenommen. Wurden im Jahr 2020 noch knapp über 18’000 Schwachstellen katalogisiert, kündigt sich die Prognose für das Jahr 2025 bei rund 48’000 Schwachstellen an. Das ist mehr als eine Verdoppelung in 5 Jahren. Die Gründe hierfür sind vielfältig: Einerseits schreitet die Technologisierung voran, die ein Mehr an Komplexität und Angriffsfläche mitbringt. Andererseits werden Schwachstellen konsequenter gesucht und dokumentiert. Die Aufgabe des Vulnerability Managements wird dadurch aber definitiv nicht einfacher.

Viele Nutzer pflegen den CVE-Stream zu heranzuziehen, um über aktuelle Schwachstellen auf dem Laufenden zu bleiben. Damit wird ein solides Grundgerüst gewährleistet. Die durch NIST betriebene NVD (National Vulnerability Database) übernimmt die Daten von CVE und reichert diese mit zusätzlichen Attributen an. In erster Linie sind ihre CPE-Definitionen (Zuweisung betroffener Produkte) und CVSS-Einschätzungen (Berechnung des Risikos) sehr geschätzt. Doch NVD kommt mit dem erhöhten Aufkommen neuer Einträge seit Jahren nicht mehr zurecht. Aus diesem Grund wird die Bearbeitung teilweise erst Jahre später oder gar nicht mehr vorgenommen. Dass auch das CVE-Programm immer wieder durch Budgetprobleme eingeschränkt wird, führt zu einem fragilen, trägen und unzuverlässigen Konstrukt.

Die schiere Menge der täglich gemeldeten Schwachstellen macht es unumgänglich, mit einem professionellen Partner zusammenzuarbeiten. Es gibt Anbieter wie VulDB, die Daten verschiedener Quellen aggregieren und bei jeder Veröffentlichung die unmittelbare Verfügbarkeit dieser Daten gewährleisten. Ebenso werden darin Schwachstellen dokumentiert, die keine CVE erhalten, da sie durch die gegebenen CNA Operational Rules von MITRE ausgeschlossen werden. Durch diese zusätzliche Abdeckung und die zeitnahe Anreicherung mit weiteren Informationen kann sehr unkompliziert auf relevanten Daten zugegriffen werden. Der Zugriff kann dabei wahlweise über das Webfrontend oder zwecks Automatisierung über die API stattfinden.

Zentralisiertes Vulnerability Management

Bei grösseren Unternehmen ist in der Regel ein dediziertes Vulnerability Management Team für die Beobachtung von Schwachstellen verantwortlich. In kleineren Unternehmen kann dies direkt durch einzelne Abteilungen oder Administratoren gemacht werden. Verschiedene Quellen werden dabei auf Schwachstellen beobachtet, die für das Unternehmen relevant sein können. Naheliegende Beispiele sind:

• Herstellerseiten
• Mailinglisten
• Verwundbarkeitsdatenbanken
• News-Seiten
• Soziale Netze

Das manuelle Beobachten und Analysieren der Quellen über einen Webbrowser ist einfach und komfortabel. Es ist aber nicht skalierbar und wird deshalb in professionellen Umgebungen nur bei dedizierten Recherchen bevorzugt. Stattdessen werden die Daten automatisiert über eine API aggregiert. Dies kann zum Beispiel in Splunk oder einem Ticketing-System geschehen. Von dort aus findet dann die Weiterverarbeitung der lokalen Daten statt. Dies kann sowohl automatisiert (z.B. Filtern und Priorisieren) oder manuell erfolgen (z.B. Zuweisung an Teams).

Ermitteln betroffener Produkte

Die Daten müssen in einem frühen Schritt auf der Basis eines Software-Inventars des Unternehmens auf betroffene Produkte gefiltert werden. Schwachstellen, die für eine Organisation relevant sind, werden in einem nächsten Schritt den jeweiligen Produkt-Teams zugewiesen und durch diese abgearbeitet. Dies können Teams für Produkte (z.B. Windows), Hersteller (z.B. Microsoft) oder Produkttypen (z.B. Betriebssysteme) sein.

Um zu wissen, welche Schwachstellen das Unternehmen überhaupt betreffen könnten, muss ein möglichst exaktes Filtern nach Produkten stattfinden können. Diese Herausforderung beginnt mit dem Vorhandensein einer aktuellen Produkteliste. Dies ist eigentlich eine simple Aufgabe, die sich aber als erstaunlich komplex erweist. Mit höchster Disziplin müssen sämtliche Produkte im Unternehmen während der sogenannten Asset Discovery identifiziert und dann dokumentiert werden. Im Idealfall wird die aktuelle Versionierung oder gar der Patchstand festgehalten. Sobald dieser geändert wird (z.B. durch Updates), müsste die Liste nachgeführt werden. Nur die wenigsten Unternehmen weisen diesbezüglich einen hohen Maturitätsgrad auf. Gezeigt ist ein Beispiel der verschiedenen Generationen von Windows-Clients.

Oftmals wird die Notwendigkeit des Erstellens und peniblen Nachführens einer solchen Liste nicht verstanden und die erforderliche Dokumentation vernachlässigt. Es gibt zwar Software-Lösungen, die durch Automatisierung eine Inventarisierung vereinfachen sollen. Die Schwierigkeit der Installation und des Betriebs solcher Produkte darf aber nicht unterschätzt werden. Nachweislich bleibt ein aktuelles Software-Inventar eine elementare Grundlage für professionelles Vulnerability Management.

Das Assoziieren von Schwachstellen mit Produkten erfolgt im Idealfall vollautomatisch. Hierzu wurde CPE (Common Platform Enumeration) eingeführt, das eine systematische und automatische Identifikation von Produkten zulässt. Das Nachführen des zugrundeliegenden Dictionaries ist sehr aufwändig, weshalb NIST die neu erforderlichen Einträge oft träge oder gar nicht zur Verfügung stellt. Zudem treten weitere Herausforderungen auf, wie unterschiedliche Schreibweisen, das Umbenennen von Produkten oder Anpassungen bei Firmenübernahmen. Die Einfachheit und Nützlichkeit von CPE funktioniert auf dem Papier hervorragend, wird aber in Bezug auf die Nutzung in der Realität stark überschätzt.

Risikobeurteilung

Erfahrene Vulnerability Management Teams führen eine erste Risikobeurteilung der gesammelten Schwachstellen durch, bevor diese an den jeweiligen Produkte-Teams zugewiesen werden. Es kann aber auch sein, dass die Risikobeurteilung den Produkte-Teams überlassen wird. Es ist jedoch nicht empfohlen, dass diese ausschliesslich eine solche Risikobewertung vornehmen. Denn gerne wird die Einfachheit im Betrieb bevorzugt und deshalb Schwachstellen geringer bewertet, als dass es nötig wäre.

Es gibt verschiedene Metriken, wie das Risiko oder der Schweregrad einer Schwachstelle bestimmt werden kann. Klassischerweise kommt CVSS (Common Vulnerability Scoring System) zum Tragen, das sich als Industriestandard etabliert hat. Durch diesen wird ein Wert von 0.0 bis 10.0 generiert, wobei ein hoher Wert einen hohen Schweregrad ausweist. Als Grundlage für die Berechnung wird ein Vektor genommen, der die Attribute einer Schwachstelle zusammenfasst. Dazu gehören Voraussetzungen und Auswirkungen einer erfolgreichen Attacke. Mit dem Base Vector wird der grundlegende Schweregrad der Schwachstelle berechnet, der sich über die Zeit nicht ändert. Beim erweiterten Temp Vector werden Aspekte berücksichtigt, die sich über Zeit ändern können. Wie zum Beispiel die Verfügbarkeit eines Exploits oder das Vorhandensein einer Gegenmassnahme.

CVSS steht mittlerweile als Version 4 zur Verfügung, die einige grundlegende terminologische, strukturelle und mathematische Anpassungen eingeführt hat und als umstritten gilt. Obwohl CVSS sehr hilfreich ist, wird die Fähigkeit zur Standardisierung überschätzt. Unterschiedliche Interpretationen können zu verschiedenen Vektoren und damit zu unterschiedlichen Scores führen. VulDB führt unter anderem genau deswegen die CVSS-Daten verschiedener Quellen auf. Zudem wird ein Meta-Score berechnet, der eine Harmonisierung der verschiedenen Quellen ermöglicht.

Zusätzlich werden ermittelte und berechnete Exploit-Preise ausgewiesen. Dies hilft zu erkennen, wie grosses Interesse böswillige Akteure am Ausnutzen einer spezifischen Schwachstelle haben. In diesen Berechnungen werden neue Erkenntnisse bedeutend schneller zur Verfügung gestellt, als mit CVSS.

Das Mitberücksichtigen des Known Exploited Vulnerabilities Catalog (KEV), der durch CISA bewirtschaftet wird, hilft schnell zu identifizieren, für welche Schwachstellen ein zielgerichtetes oder breitflächiges Exploiting bekannt geworden ist. Diese Schwachstellen müssen mit einem Mehr an Aufmerksamkeit bearbeitet werden, da das Risiko einer konkreten Kompromittierung nachgewiesen ist und jederzeit eintreten kann.

Bearbeiten der Schwachstellen

Die Produkteverantwortlichen sollen dann in einem nächsten Schritt die Schwachstelle bearbeiten. Hierbei haben sich typische Remediation-Timelines etabliert, die sich je nach Branche unterscheiden können:

Eine aufgenommene Schwachstelle kann verschiedene Zustände haben, die jeweils nachzuführen sind:

Das Resultat dieser Bearbeitung wird in der Regel an das Vulnerability Management Team zurückgemeldet. Dieses führt dann eine formale oder gar technische Kontrolle (z.B. Security Audit oder Penetration Test) durch, um die korrekte Abarbeitung als solche dokumentieren zu können.

Dabei ist wichtig sämtliche Entscheidungen und Schritte zu dokumentieren. Dies bedeutet, dass auch Meldungen dokumentiert werden müssen, die als Not Applicable klassifiziert oder vor einer Meldung im Rahmen des regulären Vulnerability Management-Prozesses als Fixed zurückgelassen werden konnten. Dies hat zwei Gründe: Einerseits wird durch einen solchen Audit Trail die Nachvollziehbark gewährleistet. Missverständnisse oder Irrtümer können so nachträglich nachvollzogen werden. Andererseits hilt eine lückenlose Dokumentation dabei, die mehrfache Bearbeitung der gleichen Schwachstellen zu verhindern.

Fazit

Ohne Vulnerability Management kann kein System sicher betrieben werden. Durch das Zusammentragen von Schwachstellen, dem Abgleichen mit dem eigenen Software-Inventar und einer Priorisierung kann die Sicherheit einer Umgebung massgeblich verbessert werden. Je nach Grösse eines Unternehmens ist es unablässig, ein eigenständiges Vulnerability Management Team zu etablieren, das diese Aufgabe zentralisiert und professionalisiert. Die stete Zunahme veröffentlichter Schwachstellen führt dazu, dass auch kleinere Unternehmen diesen Weg beschreiten müssen, um das weitreichende und komplexe Datenaufkommen in den Griff zu kriegen. Die Wahl des richtigen Partners, der bei dieser Aufgabe unterstützen kann, ist unerlässlich.

Eine häufige Empfehlung in Sicherheitsbeurteilungen lautet, ein Management von Sicherheitsrisiken zu etablieren oder zu verbessern. Solche und ähnliche Empfehlungen können praxisfremd und realitätsfern klingen und der Nutzen erschliesst sich auf den ersten Blick manchmal nur schwer. Risikomanagement besteht einfach gesagt aus den beiden Schritten Identifikation von Risiken und dann Umgang mit diesen Risiken. Dieser Beitrag beleuchtet die häufigsten Begriffe und zeigt mit einfachen Schritten ein mögliches Vorgehen für einen einfachen, praxisorientierten Einstieg ins Thema Risikomanagement.

Im allgemeinen Sprachgebrauch taucht der Begriff Risiko häufig auf und doch wird er ziemlich unterschiedlich angewendet und verstanden. Im Kontext der Informationssicherheit hat sich eine Begriffsverwendung gemäss folgendem Muster bewährt. Ein Risiko ist ein Umstand oder ein Faktor, der dazu führen kann, dass erwünschte Funktionen oder Eigenschaften eines Objekts beeinträchtigt werden oder nicht mehr zur Verfügung stehen. Dabei steht Objekt stellvertretend für das, was es zu schützen gilt, beziehungsweise worauf das sich das Risiko bezieht, das kann ein Unternehmen, eine Abteilung, ein Prozess, ein Computersystem, eine Anwendung usw. sein. Konkret könnte man sich als Objekt etwa eine Webapplikation vorstellen, wobei erwünschte Eigenschaften Leistungsfähigkeit, Zuverlässigkeit, korrekte Datenverarbeitung und Schutz vertraulicher Inhalte sein könnten. Risiken können nicht losgelöst und für sich allein existieren, sie beziehen sich immer auf Objekte, diese werden auch als Schutzobjekte bezeichnet.

Um den Zusammenhang zwischen Schutzobjekten und sich darauf beziehenden Risiken genauer zu erfassen, braucht es zwei weitere Begriffe, und zwar Bedrohung und Schwachstelle. Schutzobjekte sind nie perfekt. Eine Anwendung kann Fehler (Bugs) enthalten, ein Prozess kann ausfallen, ein Computersystem kann unsichere Zugänge aufweisen usw. Solche Eigenschaften von Schutzobjekten werden als Schwachstellen bezeichnet. Ein Schutzobjekt mit Schwachstellen muss nicht unbedingt ein Problem darstellen, es kann aber eins entstehen, sobald die Schwachstelle einer Bedrohung ausgesetzt ist oder davon ausgenutzt wird.

Die Vorstellung eines Risikos ergibt sich also ausgehend von einem schützenswerten Objekt, indem man sich vor Augen führt, welche Bedrohungen dafür relevant sind, welche Schwachstellen vorhanden sein können und wie schlimm es wäre, wenn diese ausgenützt würden. Damit werden zwei weitere wichtige Begriffe ersichtlich. Die Wahrscheinlichkeit, dass ein Ereignis eintritt und das Schadensausmass dieses Ereignisses. Diese beiden Parameter zusammen ergeben schliesslich das Ausmass des Risikos. Was kann geschehen, wie schlimm ist es und wie wahrscheinlich ist es, dass es tatsächlich geschieht?

Die nachfolgenden Abschnitte gehen etwas genauer auf diese Elemente ein und zeigen ein mögliches Vorgehen zu Risikobestimmung auf.

Geltungsbereich und Schutzobjekte festlegen

Für alle Betrachtungen im Risikomanagement muss definiert werden, worauf sie sich beziehen. Es muss also ein Geltungsbereich (Scope) festgelegt werden, der die Summe der Schutzobjekte enthält. Der Geltungsbereich kann grundsätzlich frei gewählt werden, wie es im konkreten Fall nützlich erscheint. Er kann die Informationssicherheit einer gesamten Organisation umfassen oder sich auf Teile davon beziehen oder nur einzelne Systeme oder auch ein Projekt beinhalten. Es sollte darauf geachtet werden, keine signifikanten Bereiche wegzulassen oder zu vergessen. Aus praktischen Gründen kann es nützlich sein, mehrere durch verschiedene Organisationsbereiche gepflegte Geltungsbereiche zu verwenden und das entsprechende Risikomanagement an einer übergeordneten Stelle zu konsolidieren.

Innerhalb des Geltungsbereichs werden die einzelnen Schutzobjekte oder schützenswerter Ziele bestimmt. Diese können wiederum frei definiert werden, wobei es sich lohnt, dafür eine sinnvolle Granularität zu überlegen. Ein Schutzobjekt kann etwas Konkretes, Greifbares sein wie ein System oder eine Anwendung, aber auch eine einzelne Funktion oder ein Prozess. Die Schutzobjekte werden später mit Bedrohungen, Risiken und Massnahmen in Bezug gesetzt. Man kann sich somit hinsichtlich einer sinnvollen Anzahl Schutzobjekte vorausschauend überlegen, mit welcher Granularität Risiken verwaltet werden sollen, wobei dies insbesondere auch die Risikorapportierung, die Kommunikation und die Zuweisung von Risiken und Massnahmen zu Eigentümern (Owners) beinhaltet.

Bedrohungen identifizieren

Als nächster Schritt muss überlegt werden, welche Bedrohungen für die Schutzobjekte überhaupt relevant sind. Es gibt generische Listen von Bedrohungen wie höhere Gewalt, Fehlmanipulation, usw. die als Ausgangspunkt hilfreich sein können. Bei der Betrachtung von Bedrohungen gilt es, sich auf die tatsächlichen Schutzobjekte zu fokussieren und realistisch zu sein. Wenn ein Schutzobjekt beispielsweise eine neue Webapplikation ist, sind Cyberattacken aus dem Internet eine realistische Bedrohung. Hingegen sind Erbeben zwar immer eine Bedrohung, für die Webapplikation ist das aber nicht direkt relevant (für ein Rechenzentrum aber schon).

Ermitteln von Schwachstellen

Schutzobjekte können Schwachstellen aufweisen, die durch Bedrohungen ausgenützt werden könnten. Schwachstellen können einerseits tatsächlich vorhandene Umstände sein, beispielsweise eine bekannte Schwachstelle in einem Produkt oder ein unsicherer Prozess. Zusätzlich geht man von realistischerweise möglichen Schwachstellen aus, von denen man aber nicht sicher weiss, ob sie tatsächlich vorhanden sind oder künftig vorhanden sein werden. Wenn wir beim Beispiel der Webapplikation bleiben. Es ist gut möglich, dass diese anfällig ist für gängige Angriffe wie Cross-Site-Scripting, CSRF oder SQL-Injection, aber sicher weiss man dies nicht unbedingt. Ein weiteres Beispiel ist die realistische Annahme, dass beim Vorhandensein einer Anmeldefunktion Angreifer versuchen werden, dort einzudringen oder eventuell anderweitig beschaffte Zugangsdaten für unberechtigten Zugang zu missbrauchen.
Schwachstellen zu ermitteln ist häufig eine der aufwendigsten Tätigkeiten beim Management von Cyberrisiken kann den Beizug externer Expertise erfordern, beispielsweise für vertieftes Sachverständnis oder spezifische Prüfungen wie Penetration Tests.

Schätzen von Wahrscheinlichkeiten

Eine Schwachstelle wird nur dann zum Problem, wenn sie durch eine Bedrohung ausgenützt wird. Man muss also eine Vorstellung davon gewinnen, wie wahrscheinlich dies ist. Das ist oft nicht einfach, einerseits weil selten verlässliche Daten vorliegen, andererseits ist der Mensch von Natur aus schlecht im Schätzen von Wahrscheinlichkeiten. Man muss also pragmatisch vorgehen und soweit wie möglich objektiv bleiben. Scheinbegründungen wie “uns geschieht schon nichts” oder “das betrifft nur die anderen” müssen vermieden werden. Die Schätzung von Wahrscheinlichkeiten erfordert Fachkenntnisse über die für das betrachtete Schutzobjekt relevanten Schwachstellen und Bedrohungen. Wahrscheinlichkeiten können nach einem Muster von “häufig (einmal pro Monat)” oder ähnlich ausgedrückt werden, wobei meist etwa vier Stufen unterschieden werden.

Schätzen des Schadenspotentials

Hier stellt man sich die Frage, wie schlimm es wäre, wenn eine Bedrohung tatsächlich eine Schwachstelle ausnützt, beispielsweise der externe Angreifer, der es fertigbringt, auf die Dateninhalte einer Applikation zuzugreifen oder die Geschäftsanwendung, die eine Weile ausfällt. Dabei werden üblicherweise mehrere Dimensionen wie finanzieller Schaden, rechtliche Konsequenzen und Auswirkungen auf die Reputation betrachtet. Die Summe dieser Dimensionen ergibt dann das Schadenspotential, ausgedrückt z.B. als “ernsthaft” oder “gering”, auch hier üblicherweise in vier oder fünf Stufen ausgedrückt. Das Schätzen von Schadenspotentialen (Business Impact) erfordert ein gutes Verständnis der Zusammenhänge zwischen den Schutzobjekten und den davon abhängenden Geschäftsprozessen. Es ist nicht selten der Fall, dass sich eine Schätzung aus technischer IT-Sicht deutlich von derjenigen aus Business-Sicht unterscheidet, ein entsprechender Austausch muss deshalb gepflegt werden.

Risikoeinstufung

Es ist einleuchtend, dass etwas Wahrscheinliches mit grossem Schadenspotential ein grosses Risiko bedeutet, während unwahrscheinliche Ereignisse und geringe Schäden tiefe Risiken bedeuten. Genau so erfolgt die Einstufung von Risiken: Man setzt diese beiden Dimensionen Schadenspotential und Eintrittswahrscheinlichkeit in Bezug, woraus sich die qualitative Risikoeinschätzung (z.B. klein, mittel, gross) ergibt. Dazu wird üblicherweise eine Risikomatrix in der Art der folgenden Abbildung verwendet, in der sich die Risikoeinstufung direkt ablesen lässt.

Risikoregister

Nachdem die Risiken identifiziert, beschrieben und bewertet sind, sollten Verantwortlichkeiten zugewiesen werden und die Risiken sollten in eine für die weitere Verwendung möglichst nützliche Form gebracht werden. Bewährt hat sich die Zusammenstellung in einem Risikoregister, dies kann in einfacher Form mit gängigen Tools wie Excel erfolgen oder es können eventuell bereits vorhandene Anwendungen benutzt werden. Es sollte darauf geachtet werden, die weiteren Prozesse und dabei insbesondere die Risikobehandlung möglichst gut zu unterstützen. Ein einfaches Beispiel ist nachfolgend abgebildet.

Umgang mit Risiken

Der Umgang mit Risiken wird als Risikobehandlung (Risk Treatment) bezeichnet. Möglichkeiten dafür sind Reduktion durch Ergreifen von Massnahmen, Risikoakzeptanz (man lebt damit), Transfer (z.B. Abschluss einer Versicherung) oder Vermeidung, z.B. durch Aufgabe der riskanten Tätigkeit. Welches Vorgehen für die einzelnen Risiken am besten geeignet ist, lässt sich nur durch sorgfältige Betrachtung der jeweiligen Risiken sowie der organisatorischen, regulatorischen und gesetzlichen Gegebenheiten bestimmen. Ein paar Rahmenbedingungen dazu sollte jede Organisation definieren, dazu gehört vor auch die Quantifizierung des akzeptablen Restrisikos, also des Risikoappetits.

Die Reduktion bestehender Risiken auf ein akzeptables Restrisiko erfolgt durch Ergreifen von Massnahmen. Diese müssen einerseits wirksam sein und andererseits einen Bezug zum Risikoausmass haben: Das Ausmass des Risikos rechtfertigt den Aufwand und die Kosten der Massnahme zu seiner Bewältigung. Ein Risiko setzt ein Schutzobjekt mit einer Schwachstelle und einer Bedrohung in Bezug und quantifiziert die möglichen Auswirkungen. Diese Zusammenhänge sind für indirekt Beteiligte oft nicht leicht ersichtlich und es ist wichtig, die Überlegungen möglichst transparent, klar und nachvollziehbar darzustellen. Dies insbesondere im Hinblick darauf, dass die Aufwände zur Bewältigung von Risiken bzw. die Kosten von Massnahmen in den meisten Organisationen von Gremien bewilligt werden, die nicht inhaltlich tief in den Risikoüberlegungen involviert sind.
Auch für die Massnahmen müssen Verantwortlichkeiten definiert werden und es muss ein Umsetzungsplan mit Terminen erstellt werden, das kann wie folgt aussehen.

Zusammenfassung

An obigen Ausführungen zeigt sich, dass es beim Management von Risiken in der Informationssicherheit zu einem grossen Teil darum geht, praxisbezogen vorzugehen. Es lohnt sich, die Betrachtungen in Form von verständlichen Risikoszenarien durchzuführen. Man versetzt sich dabei gedanklich in eine möglichst konkrete Situation und betrachtet, was tatsächlich geschehen könnte und wie wahrscheinlich dies ist. Risikoszenarien sollten so beschrieben werden, dass sie auch für nicht direkt Beteiligte einfach verständlich und nachvollziehbar sind. Zusammengefasst sind die einzelnen Schritte folgende:

• Identifikation von Rahmenbedingungen
• Wahl geeigneter Methoden und Werkzeuge, z.B. für das Risikoregister
• Definition des Geltungsbereichs und der Schutzobjekte
• Identifikation von Bedrohungen, Schwachstellen und Risikoszenarien
• Einstufung der Risiken anhand Eintrittswahrscheinlichkeiten und Schadenspotential
• Definition von Massnahmen
• Zuweisung von Eigentümerschaft, Verantwortlichkeiten und Terminen
• Umsetzungsüberwachung
• Rapportierung

Vereinfacht gesagt könnte man Risikomanagement in einem Satz zusammenfassen: Risikomanagement ist das bewusste Treffen von Entscheidungen. Das erfordert, über die nötigen Informationen zu verfügen, die Sachzwänge und Rahmenbedingungen zu kennen, fehlende Informationen zu beschaffen und auf dieser Grundlage Vor- und Nachteile gegeneinander abzuwägen und konkrete Pläne zur Risikobewältigung zu definieren.

Weiterführende Informationen

Zum Risikomanagement in der Informationssicherheit wurde viel publiziert und es ist eine grosse Menge an Informationen frei verfügbar. Ein paar nützliche Links dazu sind:

• Standard 200-3 des deutschen Bundesamts für Sicherheit in der Informationstechnik BSI
• ISO/IEC Standard 27005 betreffend Information Security Risk Management
• Informationen der Agentur der Europäischen Union für Cybersicherheit ENISA zum Bedrohungs- und Risikomanagement
• Methode für das Risikoassessment des Center for Internet Security
• Secure Controls Framework, ein umfassendes Metaframework zu Sicherheitsvorkehrungen

• Deepfake-as-a-Service 2025 – How Voice Cloning and Synthetic Media Fraud Are Changing Enterprise Defenses (darknet.org.uk)
• Generative artificial intelligence models outperform students on divergent and convergent thinking assessments (nature.com)
• Is AI moving faster than its safety net? (malwarebytes.com)
• Why prioritizing vulnerabilities based on NVD leaves you at risk (tenable.com)
• Apple security bounty evolved (security.apple.com)
• Satellites leak voice calls, text messages and more (malwarebytes.com)
• Anthropic AI Releases Petri: An Open-Source Framework for Automated Auditing by Using AI Agents to Test the Behaviors of Target Models on Diverse Scenarios (marktechpost.com)
• You can now upgrade a retro Casio watch with Bluetooth, step tracking, and games (theverge.com)
• Your passwords don’t need so many fiddly characters, NIST says (malwarebytes.com)
• LLM Black Markets in 2025 – Prompt Injection, Jailbreak Sales & Model Leaks (darknet.org.uk)
• Evidence Preservation: Why iPhone Data Can Expire (blog.elcomsoft.com)
• Google DeepMind introduces new AI agent for code security (deepmind.google)
• From threats to apology, hackers pull child data offline after public backlash (malwarebytes.com)
• China Requires 1-Hour Cybersecurity-Incident Reports (darkreading.com)
• AI in Digital Forensics: a Tool, not an Oracle (blog.elcomsoft.com)
• Data & Society Scam GPT (datasociety.net)
• Building more helpful ChatGPT experiences for everyone | OpenAI (openai.com)
• OpenAI Augmenting ChatGPT With An Online Network Of Human Therapists Will Skyrocket The Need For Mental Health Professionals (forbes.com)
• AI-Generated “Workslop” Is Destroying Productivity (hbr.org)
• AI vs. AI: Detecting an AI-obfuscated phishing campaign (microsoft.com)