Die wichtigsten Änderungen der neuen Schwachstellenbewertung CVSS 4.0

Inhaltsverzeichnis

Oberflächlich betrachtet bilden CVSS-Scores den Schweregrad einer Sicherheitslücke primär über einen Wert zwischen 0.0 ("None") und 10.0 ("Critical") ab. Dahinter steht mit dem Common Vulnerability Scoring System (CVSS) allerdings ein komplexes Bewertungssystem, das beim Errechnen des Scores zahlreiche Kriterien, sogenannte Metriken, einbezieht. Der resultierende CVSS-Vektor kann die wesentlichen Merkmale einer Schwachstelle differenziert beschreiben und IT-Verantwortliche letztlich dabei unterstützen, die Bedrohungslage richtig einzuschätzen und angemessen zu handeln.

Für den 31. Oktober 2023 ist mit CVSS 4.0 die Veröffentlichung einer neuen Version des de-facto-Standards geplant. Geschraubt hat das für CVSS verantwortliche Forum of Incident Response and Security Teams (FIRST), ein Zusammenschluss internationaler Sicherheits- und Incident-Response-Teams, sowohl an den Basis-Metriken als auch an den ergänzenden Metrikgruppen. Außerdem möchte es mit einer neuen Nomenklatur künftig eine deutlichere Abgrenzung zwischen Base Score und zusätzlichen Scores schaffen.

Wer mit CVSS arbeitet, muss sich nach dem Versionsupdate auf Änderungen sowohl beim Berechnen der Scores als auch beim Lesen und Interpretieren bestehender CVSS-Vektoren einstellen. Unser Artikel fasst anhand der öffentlichen Vorschau (Public Preview) auf v4.0 die für die praktische Anwendung wichtigsten Änderungen gegenüber der Vorgängerversion 3.1 zusammen. Zusätzlich verweist er auf weiterführende Quellen und Beispiele für alle, die sich noch tiefer in die Materie einarbeiten möchten beziehungsweise müssen. Bei Bedarf hilft der ältere heisec-Hintergrundartikel "Von niedrig bis kritisch: Schwachstellenbewertung mit CVSS" beim Auffrischen des vorausgesetzten CVSS-Grundlagenwissens.

CVSS-Möglichkeiten voll ausschöpfen

Wenn in öffentlichen Quellen wie der National Vulnerability Database (NVD), auf einer Hersteller-Website oder auch in IT-Security-Nachrichten ein CVSS-Score auftaucht, handelt es sich meist um den Base Score. Dieser Wert, den der Schwachstellen-Entdecker, ein Produkthersteller oder das koordinierenden CERT berechnet, misst den Schweregrad einer Schwachstelle anhand allgemeingültiger Merkmale. Dazu zählt etwa der Angriffsweg oder die Frage, ob für eine Attacke eine Nutzerinteraktion erforderlich ist. Er bildet demzufolge das konstante Kernstück der Schwachstellenbewertung.

Was der Base Score allerdings nicht leisten kann, ist eine abschließende Bewertung des tatsächlichen Risikos, das von einer Sicherheitslücke ausgeht. Denn dieses ist zeitlich veränderlich und kann sich unter anderem drastisch erhöhen, wenn ein Exploit in freier Wildbahn auftaucht. Zudem ist es auch abhängig von individuellen Faktoren, wie der Vertrauenswürdigkeit und Zuverlässigkeit des betroffenen Systems und seiner Umgebung in einem spezifischen Unternehmen.

Um diesem Defizit zu begegnen, umfasst CVSS schon seit Längerem zwei zusätzliche Metrikgruppen, die zeitliche und Umgebungsfaktoren berücksichtigen. Damit können Firmen und Organisationen entsprechend individueller Gegebenheiten ergänzende Teilscores berechnen. In Kombination mit dem Base Score entsteht ein angepasster Gesamtscore, der die tatsächliche Gefahrenlage deutlich realistischer abbilden soll.

Ein nützliches Werkzeug also, das aus Sicht von FIRST bislang zu wenig genutzt wird. Denn für IT-Verantwortliche bedeuten die eigenen, ergänzenden Berechnungen einen Mehraufwand gegenüber dem bloßen Konsumieren bestehender Base Scores. Um die Wichtigkeit der Zusatzmetriken für die Risikobewertung zu betonen, führt die Organisation mit v4.0 eine neue, abgrenzende Nomenklatur ein. Der User Guide zur neuen Version empfiehlt, künftig konsequent die folgenden Bezeichner zu verwenden, wann immer irgendwo ein CVSS-Score veröffentlicht oder kommuniziert wird:

• CVSS-B: Base Metrics
• CVSS-BE: Base + Environmental Metrics
• CVSS-BT: Base + Threat Metrics
• CVSS-BTE: Base + Threat + Environmental Metrics

Zusatzmetriken umbenannt und ergänzt

Routinierte CVSS-Anwender dürften sich beim Betrachten der neuen Nomenklatur fragen, was aus den "Temporal Metrics" geworden ist. Die Antwort ist simpel: In v4.0 heißt diese Gruppe "Threat Metrics". Die einzige in ihr enthaltene Metrik, "Exploit Maturity", gibt an, ob und in welcher Form – etwa als Proof-of-Concept oder als Angriff in freier Wildbahn – Exploit-Code für den Schwachstellen-Angriff verfügbar ist. Exploit Maturity ersetzt vereinfachend drei Metriken, die in CVSS v3.1 Bestandteil der Temporal Metrics waren: "Remediation Level", "Report Confidence" und "Exploit Code Maturity".

Die Gruppe der Environmental Metrics wurde in CVSS v4.0 gegenüber der Vorgängerversion stark erweitert. Unter anderem enthält sie nicht mehr nur Metriken, die sich auf das primäre verwundbare System beziehen, sondern auch solche, die eine Risikobewertung für Folgesysteme ("Subsequent Systems") erlauben. Wenn etwa eine Schwachstelle in einer virtuellen Maschine Zugriff auf vertrauliche Daten des Hostsystems ermöglicht, ist die VM das eigentliche "Vulnerable System" und der Host das "Subsequent System". Ein weiteres von mehreren Beispielen aus dem User Guide zu v4: Eine verwundbare Webanwendung ("Vulnerable System") macht den Browser als "Subsequent System" anfällig für Angriffe wie Cross-Site-Scripting oder unerwünschte Redirects.

In v4.0 komplett neu hinzugekommen ist die Gruppe der "Supplemental Metrics". Im Unterschied zu den Environmental Metrics und Threat Metrics haben diese der Definition nach keinen Einfluss auf den Gesamtscore. Vielmehr ist die Idee hinter ihnen, für CVSS-"Konsumenten", also IT-Verantwortliche oder Endnutzer verwundbarer Produkte, zusätzliche Informationen zur jeweiligen Schwachstelle bereitzustellen, die in den bestehenden Metriken nicht auftauchen.

Sie sollen bei der Risikoanalyse helfen, indem sie etwa verraten, ob bekanntermaßen automatisierte Exploits durchführbar sind ("Automatable") oder indem sie einen vom Anbieter des verwundbaren Produkts festgelegten Dringlichkeits-Level ("Provider Urgency") wiedergeben. Besonders erwähnenswert ist auch die Metrik "Safety", die bewerten hilft, ob eine Schwachstelle Gefahren für Leib und Leben bergen kann. Sie illustriert die Bemühungen von FIRST, mit v4.0 die Anwendbarkeit von CVSS über IT-Systeme hinaus speziell auch auf Industrielle Steuerungssysteme (Industrial Control Systems, ICS), Operational Technology (OT) und das Internet of Things zu verbessern.

Basismetriken verfeinert: Vektoren im Vergleich

Bei den für die CVSS-Score-Berechnung obligatorischen Basismetriken hat sich ebenfalls einiges getan: Unverändert bleiben in v4.0 gegenüber v3.1 die Metriken Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR) und User Interaction (UI). Neu hinzugekommen ist Attack Requirements (AT), das die vorhandene Metrik Attack Complexity (AC) ergänzen soll. AC bildete bereits ab, wie anspruchsvoll das Entwickeln eines funktionierenden Exploits angesichts vorhandener Sicherheitsmaßnahmen ist. Mit AT lässt sich nun zusätzlich festlegen, ob sich eine verwundbare Komponente gerade in einem bestimmten Zustand befinden muss, damit ein Angriff gelingen kann. Auswahlmöglichkeiten sind "None" und "Present".

In der neuen CVSS-Version entfällt mit "Scope" (S) eine Basismetrik, die FIRST in Präsentationsfolien zu CVSS v4.0 als die "möglicherweise unbeliebteste und am wenigsten verstandene Metrik" bezeichnet, die jemals existiert hat. Sinn und Zweck von Scope war es, zu bewerten, ob von einer Schwachstelle systemübergreifende Gefahren ausgingen. Auch hier lässt sich wieder das Beispiel von VM und Hostsystem anwenden: War auch das Hostsystem betroffen, so fand beim Übergreifen auf den Host ein "Scope Change" statt. Als Auswahlmöglichkeiten bot Scope lediglich "Changed" und "Unchanged"; Details zu den Konsequenzen für das zweite System konnte man somit nicht angeben.

Um "Scope" sinnvoll zu ersetzen, nutzt FIRST in v4.0, genau wie bei den Environmental Metrics, die Unterscheidung zwischen "Vulnerable System" (V) und "Subsequent System" (S). Für beide Systeme lassen sich die Auswirkungen einer Schwachstellen-Ausnutzung auf die Vertraulichkeit (Confidentiality, C), Integrität (Integrity, I) und Verfügbarkeit (Availibility, A) dort gespeicherter Informationen nun separat definieren. Also als VC, VI und VA beziehungsweise SC, SI und SA.

Beispiele dafür, wie sich CVSS-Vektoren beider Versionen unterscheiden, liefert First auf einer eigens angelegten "Examples"-Seite zu v4.0. Dort dargestellte Vektoren (Base Score) für die Schwachstelle CVE-2022-41741 sehen folgendermaßen aus:

v3.1: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (CVSS-B: 7.0)
v4.0: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (CVSS-B: 7.3)

Fazit und weiterführende Links

CVSS v4.0 erlaubt mit neu hinzugekommenen sowie bereits bekannten, jedoch kleinteiliger aufgespaltenen Metriken eine differenziertere Schwachstellenbewertung als die Vorgängerversion. Die neue Version hat somit Potenzial für aussagekräftigere Bewertungen. In der Praxis wird die tatsächliche Aussagekraft allerdings stark davon abhängen, wie gewissenhaft Schwachstellen-Entdecker, CERTs und Hersteller bei der Anwendung vorgehen und ob sie sich vorab ausreichend mit den zahlreichen Metriken auseinandersetzen. Davon also ab, ob sie die neuen Auswahlmöglichkeiten als Chance oder als Zeitverschwendung betrachten.

Um sich selbst ein Bild von der neuen Version zu machen und mit den Metriken vertraut zu werden, können Sie sich mit der Public Preview des CVSS v4.0 Calculators nach Lust und Laune eigene Vektoren zusammenklicken. Eine detaillierte Aufschlüsselung und Beschreibung aller Metrikgruppen und Metriken in Textform bietet das Specification Document zu v4.0.

Wer sich primär für die Veränderungen gegenüber v3.1 interessiert, wird im User Guide fündig. Sehr ausführlich erläutert dieser unter anderem auch die neu eingeführte Unterscheidung zwischen Vulnerable System and Subsequent System. Kürzer und knackiger fassen die Präsentationsfolien zu CVSS v4.0 zentrale Neuerungen zusammen, wobei sie diese recht anschaulich mit bestehenden Kritikpunkten an der Vorgängerversion begründen.

Schließlich schlüsselt die Examples-Seite Gemeinsamkeiten und Unterschiede bestehender CVSS 4.0- und 3.1-Vektoren auf. Hier finden sich etwa auch Anwendungsbeispiele der Metrik "Safety" auf Schwachstellen in einem industriellen Steuerungssystem und in einem Produkt aus dem Healthcare-Bereich.

(des)