Warum der Blast Radius einer Schwachstelle eine Eigenschaft des Graphen ist UND nicht des Scanners

Im Manifest habe ich behauptet, dass in der Sicherheit selten das teuerste System den größten Schaden trägt, sondern das am besten vernetzte. Das ist eine hübsche These. Aber eine These bleibt eine Behauptung, solange bis man sie an einem konkreten Fall zeigt. Also fangen wir damit an. 

Dieser Beitrag ist der erste einer kommenden ganzen Reihe von Beiträgen, in denen ich genau solche Fragen thematisiere: nicht mit Bauchgefühl, sondern mit einer deterministischen Herleitung, die man nachvollziehen und angreifen kann.

Und die erste ist unbequem:

Die gefährlichste Schwachstelle in deinem System hat vielleicht den niedrigsten CVSS-Score.

Das klingt im ersten Moment falsch. Es widerspricht grundlegend der Art, wie die meisten Organisationen gewohnt sind zu priorisieren: Nämlich nach dem Schweregrad. Von kritisch – hoch bis unkritisch – niedrig und die rote Liste zuerst. Und trotzdem stimmt etwas nicht, sobald man aufhört, Schwachstellen einzeln zu betrachten. Sehen wir uns an, warum.

Was ein Score misst — und was nicht

Der CVSS-Score, das Common Vulnerability Scoring System, ist ein nützliches Werkzeug. Er bewertet eine Schwachstelle nach nachvollziehbaren Kriterien: Wie leicht lässt sie sich ausnutzen? Braucht der Angreifer bereits Zugang, oder geht es aus der Ferne? Wie groß ist der Schaden an Vertraulichkeit, Integrität und Verfügbarkeit am betroffenen Punkt?

Diese letzten drei Worte sind der Haken. Am betroffenen Punkt. Der Score bewertet die Schwachstelle so, als stünde das verwundbare System allein auf der Welt. Er beantwortet die Frage: Wie schlimm ist es, wenn genau dieses Bauteil fällt? Er beantwortet nicht die Frage, die in einem realen Netzwerk fast immer wichtiger ist: Was fällt noch mit ihm?

Diese zweite Frage, die Reichweitenfrage, steht in keinem Scanner-Report. Nicht, weil sie unwichtig wäre, sondern weil sie sich nicht an der einzelnen Schwachstelle ablesen lässt. Sie ist keine Eigenschaft der Lücke sondern sie ist eine Eigenschaft ihrer Lage (Position).

Warum Systeme Graphen sind

Um die Lage zu verstehen, muss man aufhören, ein System als Punkt zu sehen sondern als Inventar von Servern, Diensten und Bibliotheken, das man Zeile für Zeile abarbeitet. Ein System ist ein Geflecht.

Komponenten hängen voneinander ab. Zum Beispiel: Ein Webdienst ruft einen Authentifizierungsdienst auf, der wiederum eine Datenbankschicht nutzt, die ihrerseits auf einer Handvoll gemeinsam genutzter Bibliotheken aufsetzt. Hosts vertrauen einander, damit sie ohne ständige Neuanmeldung kommunizieren können. Dienste teilen sich eine Infrastruktur. Jede dieser Beziehungen ist eine gerichtete Verbindung: A hängt von B ab, B von C.

Das ist die mathematische Struktur eines gerichteten Graphen: Knoten, verbunden durch Pfeile. Und in einem Graphen gilt ein Prinzip, das der listenbasierten Intuition zuwiderläuft: Die Bedeutung eines Knotens ergibt sich nicht aus ihm selbst, sondern aus seiner Position. Ein unscheinbarer Knoten, von dem viele andere abhängen, ist strukturell wichtiger als ein prominenter Knoten, der für sich isoliert dasteht, ganz gleich, wie hoch seine eigene Bewertung auch ausfällt.

Wer schon einmal die Eigenvektor-Zentralität gesehen hat, das ist das Prinzip hinter Googles ursprünglichem Seitenrang-Algorithmus, kennt den Gedanken: Ein Knoten ist so wichtig wie die Knoten, die auf ihn verweisen. Wichtigkeit ist ansteckend, sie fließt durch die einzelnen Kanten. Der Blast Radius ist die roheste, direkteste Ausprägung dieser Idee.

Blast Radius: die transitive Hülle

Die Reichweite eines Knotens hat einen Namen: der Blast Radius. Er umfasst alles, was von einem Punkt aus erreichbar ist. Aber auch in die andere Richtung gelesen, alles, was von ihm abhängig ist.

Mathematisch ist das die transitive Hülle. Das Wort klingt sperrig, der Vorgang selbst ist aber simpel: Man setzt den Finger auf einen Knoten und folgt den Pfeilen. Jeder erreichte Knoten kommt auf die Liste. Von dort folgt man weiter, zu deren Nachbarn, und deren Nachbarn, immer weiter, bis kein neuer Knoten mehr hinzukommt. Was am Ende auf der Liste steht, ist der Blast Radius. Das ist keine Magie es ist nur konsequentes Verfolgen von Abhängigkeiten, bis nichts mehr übrigbleibt.

Der Grund, warum Menschen das systematisch unterschätzen, liegt in genau diesem „immer weiter“. Wir sehen die direkten Nachbarn eines Systems recht gut. Was wir nicht sehen, sind die Nachbarn der Nachbarn der Nachbarn, eben die dritte, vierte, fünfte Ebene, die sich der Anschauung entzieht. Und genau dort, in der Tiefe der Kette, sammelt sich die eigentliche Reichweite an. Transitivität ist der blinde Fleck in unserer Intuition.

Ein Beispiel aus dem Alltag macht es deutlicher. Wenn in einem Bürogebäude eine einzelne Hauptwasserleitung im Keller bricht, interessiert niemanden, dass das Leck selbst nur handtellergroß ist. Was zählt ist, wie viele Stockwerke von dieser einen Leitung gespeist werden. Ein winziger Schaden an genau der richtigen Stelle kann das ganze Haus trockenlegen, während ein vergleichsweises großes Leck in einer Leitung, die nur eine einzige Toilette versorgt, kaum jemand bemerken würde. Die Größe des Lecks ist der CVSS-Score. Die Zahl der abhängigen Stockwerke ist der Blast Radius. Und kein Klempner der Welt würde die Leitungen nach der Größe ihrer Lecks priorisieren, ohne zu fragen, was an ihnen hängt.

Ein Zahlenbeispiel, das man im Kopf überprüfen kann

Machen wir es konkret. Stell dir eine kleine und überschaubare Landschaft aus acht Komponenten vor: ein Web-Frontend, ein Authentifizierungsdienst, ein Zahlungs-API, einen Datenbank-Konnektor, einen Batch-Worker, ein Reporting-Modul, ein Admin-Werkzeug — und eine Logging-Bibliothek, welche von vielen der anderen mitgenutzt wird.

Jetzt tauchen zwei Schwachstellen auf, und wir müssen entscheiden, welche zuerst behoben wird.

Schwachstelle A steckt in einem Admin-Werkzeug. Der Scanner meldet CVSS 9.1 — Kritisch. Ein Volltreffer, sauber rot. Aber das Admin-Werkzeug steht am Rand der Landschaft: Es nutzt andere Dienste, doch kein anderer Dienst hängt von ihm ab. Sein Blast Radius, gemessen an den Systemen, die mit ihm fallen würden, umfasst null weitere Komponenten. Fällt es, fällt nur eines.

Schwachstelle B steckt in der Logging-Bibliothek. Der Scanner meldet CVSS 5.3 — und damit Mittel. Kaum der Rede wert, gelb, kommt später dran. Aber die Bibliothek liegt im Zentrum: Frontend, Auth-Dienst, Zahlungs-API, Datenbank-Konnektor, Batch-Worker, Reporting, sie alle nutzen sie, direkt oder über eine Zwischenschicht indirekt. Verfolgt man die transitive Hülle, stehen am Ende sieben betroffene Komponenten auf der Liste. Praktisch die gesamte übrige Landschaft.

Zwei Zahlen, die alles auf den Kopf stellen: Die rot markierte Schwachstelle hat eine Reichweite von null. Die gelb markierte eine Reichweite von sieben. Wer nach Score priorisiert, behebt zuerst die, die nichts mitreißt und lässt die liegen, die alles trägt. Und das ist kein konstruierter Ausnahmefall. Es ist das Grundmuster fast jeder Infrastruktur, in der einige wenige Bausteine von vielen geteilt werden.

Das reale Lehrstück: Log4Shell

Wer das für ein akademisches Gedankenspiel hält, war im Dezember 2021 nicht im Dienst. Die Schwachstelle, die unter dem Namen Log4Shell bekannt wurde, steckte in Log4j. Das ist eine Logging-Bibliothek für Java. Grundsätzlich kein wirklich prestigeträchtiges Ziel, kein glamouröses System. Einfach nur ein Stück Infrastruktur, das im Hintergrund Meldungen wegschreibt, so unauffällig wie Wasserleitungen in einem Gebäudekomplex.

Aber genau diese Unauffälligkeit war dann auch das Problem. Log4j war überall. Über die Abhängigkeitsketten der Java-Welt betraf die Lücke Zehntausende Softwarepakete direkt  und noch ein Vielfaches davon indirekt, weil diese Pakete selbst wiederrum in anderen Anwendungen steckten. Der Befund: Ein einziger Fund in einer einzigen Bibliothek löste eine der größten koordinierten Notfall-Übungen der jüngeren IT-Geschichte aus. Nicht, weil die Lücke technisch besonders raffiniert gewesen wäre, sie war es kaum, sondern weil ihr Blast Radius planetarisch war.

Log4Shell war die transitive Hülle mit Weltereignishorizont. Und es hat uns konkret vorgeführt, was der Scanner-Score allein uns nie hätte aufzeigen können: Die Gefahr saß nicht in der Schwere der Lücke, sondern in der Lage der Bibliothek.

Zwei Richtungen, dieselbe Mathematik

Das vielleicht Schönste an diesem Gedanken ist, dass er in beide Richtungen lesbar ist und dabei zwei scheinbar getrennte Sicherheitsdisziplinen und Sichtweisen als dasselbe Problem entlarvt.

Vorwärts gelesen, entlang der Abhängigkeiten, entspricht der Blast Radius der Frage der Lieferketten: Was bricht, wenn diese Komponente bricht? Welche Dienste stehen still, wenn diese Bibliothek eine Lücke hat? Das ist die klassische Supply-Chain-Perspektive und die Sorge des Verteidigers um die eigene Fragilität.

Rückwärts gelesen, vom Einbruchspunkt eines Angreifers aus, ist derselbe Blast Radius die Frage der Möglichkeiten bei der lateralen Bewegung: Was kann man von hier aus alles erreichen? Sitzt der Angreifer erst einmal auf diesem kompromittierten Host, welche Dienste sind dann von dort aus erreichbar, weil Systeme vertrauen zu diesem Host haben und wie tief kann er sich noch vorarbeiten? Das ist die Angreifer-Perspektive.

Zwei Fragen, die normalerweise in getrennten Abteilungen, mit getrennten Werkzeugen, von getrennten Teams bearbeitet werden aber im Grunde genommen dieselbe Erreichbarkeitsrechnung auf demselben Graphen darstellen. Nur die „Zeige“-Richtung des Fingers auf den Pfeilen verändert sich. Das ist der Moment, in dem die Mathematik ihre stille Stärke zeigt: Sie deckt auf, dass zwei Probleme, die man für absolut verschieden gehalten hat, in Wirklichkeit eines sind.

Was ein Praktiker daraus mitnimmt

Die Konsequenz lässt sich in einem Satz zusammenfassen, und sie verändert die Priorisierungsbemühungen spürbar:

Risiko ist nicht Schwere allein sondern es ist die  Schwere mal Reichweite.

Wer ausschließlich nach CVSS-Score priorisiert, übersieht systematisch die mittelmäßig bewertete Komponente mit gigantischem Blast Radius. Allerdings übersieht man damit auch den billigsten und größten Hebel im ganzen Portfolio: Ein einziger Patch an einer zentralen, aber viel genutzten Bibliothek, senkt das Risiko allerdings über viele Dutzende davon abhängiger Systeme gleichzeitig, während dieselbe Mühe an einem isolierten, aber kritischen Fund nur genau diesen einen Punkt mitigieren wird.

Ich will es aber auch ganz deutlich sagen: Das ist keine Aufforderung und es bedeutet auch nicht, den Score zu ignorieren. Es bedeutet, ihn um diese zusätzliche Dimension zu ergänzen, welche er durch die Art und Weise wie er konstruiert wurde, einfach nicht kennen kann. Die Schwere sagt dir, wie schlimm ein einzelner Bruch ist. Die Reichweite sagt dir, wie viele Folgebrüche ein einzelner Bruch auslöst. Erst beide zusammen ergeben ein gesamtes Bild, das die Entscheidung auch tragen kann.

Woher man den Graphen bekommt

Die häufigste Reaktion an dieser Stelle ist berechtigt: Schön und gut, aber ich habe keine saubere Karte meiner Abhängigkeiten. Das stimmt fast immer. Es ist aber kein Grund, den Gedanken zu verwerfen, sondern ein Grund damit anzufangen. Klein anzufangen.

Für Software-Abhängigkeiten gibt es ein Werkzeug, das in den letzten Jahren stark an Bedeutung gewonnen hat: die Software Bill of Materials, kurz SBOM. Das ist eine maschinenlesbare Stückliste all dessen, was in einer Anwendung steckt, inklusive der Bibliotheken, die die Bibliotheken mitbringen. Genau nach Log4Shell wurde sie von einem Nice-to-have zur ernsthaften Forderung, und der Grund ist exakt der dieses Beitrags: Ohne die Stückliste sieht man die transitiven Abhängigkeiten nicht, und ohne die sieht man den Blast Radius nicht. Ein schöner Nebeneffekt dabei ist: CRA und DORA verlangen für Compliance genau so eine SBOM.

Für Vertrauensbeziehungen zwischen Hosts bei denen geregelt wird welcher Server sich ohne erneute Anmeldung mit welchem anderen Server verbinden darf, ist die Lage schwieriger, weil diese Beziehungen historisch gewachsen und selten dokumentiert sind. Aber auch hier gilt: Man muss nicht das gesamte Netzwerk voll kartieren. Es genügt, von den Kronjuwelen aus rückwärtszufragen, wer sie erreichen kann. Ebenso von den typischen Einbruchspunkten aus vorwärts gefragt, was sich von dort aus alles noch öffnet. Der wertvollste Teilgraph ist oft erstaunlich klein.  Ein Nachmittag mit den Leuten, die die Umgebung wirklich kennen, bringt oft mehr zutage als ein teures Automatisierungsprojekt.

Der Punkt ist nicht, den perfekten Graphen zu besitzen. Der Punkt ist, überhaupt anzufangen, in Graphen zu denken, statt mit Listen zu hantieren. Schon eine grobe Karte verschiebt die Priorisierungsthematik von „welcher Score ist am höchsten“ zu „was hängt woran“. Das ist der entscheidende Schritt.

Die ehrliche Grenze

Ich wäre nicht ehrlich, wenn ich es bei der schönen Pointe beließe. Der Blast Radius hat zwei Grenzen, und beide gehören auf den Tisch.

Erstens: Man muss den Graphen kennen. Die ganze Rechnung setzt voraus, dass die Abhängigkeits- und Vertrauensketten bekannt sind. Software-Abhängigkeiten lassen sich mit einer Stückliste, einer Software Bill of Materials, zumindest annähernd erfüllen. Vertrauensbeziehungen zwischen Hosts sind oft historisch gewachsen und nirgends sauber dokumentiert. Der Graph wird einem selten geschenkt. Aber, und das ist der Trost, man braucht ihn nicht vollständig. Für die Kronjuwelen genügt oft ein Nachmittag am Whiteboard mit den Leuten, die die Umgebung kennen.

Zweitens: Die Knotenzahl ist nicht das ganze Bild. Die bloße Größe des Blast Radius zählt betroffene Knoten, nicht deren Wert. Eine kleine Reichweite, die ausgerechnet die Kronjuwelen trifft, wiegt schwerer als eine riesige aus lauter Belanglosigkeiten. Die reine Knotenzahl ist ein erster Näherungswert, allerdings ein sehr guter, weil er sofort die krassen Fehlpriorisierungen sichtbar macht. Aber die nächste Verfeinerung liegt sofort auf der Hand: Man muss jeden Knoten mit seinem Wert gewichten, statt ihn nur zu zählen. Aus „wie viele Systeme“ wird „wie viel Wert“. Das ist bereits der elegante Übergang vom Asset Management hin zur Risikoquantifizierung. Das ist aber ein Thema für einen eigenen Beitrag.

Woher wir das wissen

Die transitive Hülle ist kein Modephänomen und keine Erfindung der Cybersecurity. Sie ist ein Jahrzehnte altes, wohlverstandenes Konzept der Graphentheorie, mit sauber bewiesenen Eigenschaften und effizienten Algorithmen, die sie berechenbar machen. Wenn ich sage, dass die Reichweite einer Schwachstelle sieben Systeme umfasst, dann ist das keine Schätzung und auch kein Gefühl, sondern es ist das Ergebnis, einer Rechnung, die jedem das gleiche Ergebnis liefert, der sie durchführt. Das ist der wichtigste Punkt, um den es mir hier geht: Es geht nicht darum, dass diese Aussage von mir kommt, sondern dass sie von niemandem abhängig ist. Sie ist allgemeingültig.

Und damit schließt sich der Kreis zur unbequemen Anfangsbehauptung. Die gefährlichste Schwachstelle mit dem niedrigsten Score ist kein Paradox. Sie ist die logische Folge davon, dass wir Schwere messen und Reichweite ignorieren. Dass wir das eine im Scanner stehen haben und das andere im Graphen, und meistens nur in den Scanner schauen.

Die Schwere einer Schwachstelle steht im Scanner. Ihre Reichweite steht im Graphen. Wir kennen nur eine der beiden Zahlen – meistens.

Gewichtet ihr bereits die Reichweite in eurer Infrastruktur oder dominiert noch der Score?