Mit <kes>+ lesen

Der neue CVSS-Standard: Alles andere als einfach

Das Forum of Incident Response and Security Teams (FIRST) hat die mit Spannung erwartete CVSS v4.0 vorgestellt. Das ist die erste größere Überarbeitung des Standards seit mehr als acht Jahren. Die neue Version bietet nun weit mehr als ein rein numerisches Schweregrad-Ranking.

Lesezeit 7 Min.

Im Allgemeinen ist es hilfreich zu wissen, ob etwas potenziell gefährlich ist. Noch hilfreicher ist es, mehr über die Gefahr selbst zu erfahren. Für wen oder was besteht sie? Worin besteht sie genau? Welche Art von Schaden kann entstehen und unter welchen Umständen? Ein ähnliches Prinzip gilt für die Einstufung von Softwareschwachstellen. Es ist selbstverständlich hilfreich zu wissen, ob sie als trivial oder schwerwiegend eingestuft werden. Das allein reicht allerdings nicht. Je nachdem, in welcher Branche oder in welchen Bereichen ein Unternehmen tätig ist, wie es seine Anwendungen und Systeme nutzt und wie verlässlich die Verteidigungsmaßnahmen sind, mag selbst eine als schwerwiegend eingestufte Sicherheitslücke möglicherweise kein Grund zur Sorge sein. Unter anderen Bedingungen wiederum kann eine als moderat eingestufte Schwachstelle kritisch werden.

Genau damit befasst sich die aktuelle Version des CVSS-Standards (Common Vulnerability Scoring System). Im Juni 2023 bekamen die Teilnehmer der 35. FIRST-Jahreskonferenz in Montréal, Kanada, einen ersten Einblick in die neue Version 4.0 des Common Vulnerability Scoring System. Gefolgt von einer jeweils zweimonatigen Phase der Kommentierung und anschließenden Überarbeitung wurde die neue Version CVSS 4.0 offiziell veröffentlicht. Laut dem Forum of Incident Response and Security Teams (FIRST), der Institution, die das CVSS-System verwaltet, stellt es einen „offenen Rahmen für die Kommunikation der Merkmale und des Schweregrads von Softwareschwachstellen“  bereit – mit einer Skala von 0 bis 10. CVSS 4.0 ist die erste größere Überarbeitung des Standards seit über acht Jahren und wurde von FIRST Anfang November auf den Weg gebracht. Diese neueste Version bietet deutlich mehr als ein rein numerisches Schweregrad-Ranking. Vielleicht sogar ein bisschen zu viel, wenn man bedenkt, dass jede Woche zwischen 450 und 600 Softwareschwachstellen entdeckt werden.

CVSS 4.0 „soll sowohl der Industrie als auch der Öffentlichkeit die bestmögliche Bewertung von Schwachstellen erlauben“, heißt es sinngemäß in einer Erklärung von FIRST und weiter, dass „angesichts der immer komplexer werdenden Bedrohungslandschaft diese neue CVSS-Version für die Branche ein entscheidender Schritt sein wird“. Dabei spielt der Kontext eine zentrale Rolle. Neben einer feineren Granularität der Basis-Metriken wird auch die Effektivität der Bewertung für bestimmte unternehmensspezifische Sicherheitsanforderungen berücksichtigt.

Neue Metrikgruppen

Schwachstellen werden jetzt auf andere Weise bewertet als lediglich mittels der sogenannten „Basismetrik“, die sich auf „die inhärenten Eigenschaften einer Schwachstelle bezieht, die im Laufe der Zeit und in verschiedenen Benutzerumgebungen konstant sind“.

In CVSS 4.0 treten drei weitere Metrikgruppen hinzu:

  • Environmental: Betrifft die Merkmale einer Schwachstelle, die in der digitalen Umgebung eines Benutzers einzigartig sind.
  • Threat: Betrifft die Merkmale einer Schwachstelle, die sich im Laufe der Zeit ändern können.
  • Supplemental: Zusätzliche Informationen, die sich nicht auf die endgültige Bewertung auswirken, aber einen besseren Einblick in die Merkmale einer Schwachstelle geben. Ein Beispiel: „Eine DoS-Schwachstelle (Denial of Service), die sofort behoben und das System wiederhergestellt werden kann, hat die gleiche numerische Punktzahl wie eine DoS-Schwachstelle, die dafür sorgt, dass ein System nicht verfügbar ist, bis ein Administrator das System neu startet“, so FIRST. Die Auswirkungen auf die Betriebsdauer können jedoch sehr unterschiedlich sein und sollten bei der Planung von Maßnahmen zur Behebung berücksichtigt werden.“

Diese zusätzlichen Metrikgruppen sind jedoch nur ein Element dessen, was FIRST bei der Beschreibung von Schwachstellen als „feinere Granularität“ bezeichnet. Diese Granularität findet ihren Ausdruck allerdings in einer langen Liste von Abkürzungen für die unterschiedliche Merkmale und Auswirkungen von Schwachstellen.

Zunächst müssen die von FIRST genannten Schwachstellen anhand der Metriken ermittelt werden, die zu ihrer Entstehung verwendet wurden. So muss eine Schwachstelle, die Basis- und Umgebungsmetriken verwendet, als CVSS-BE bezeichnet werden; solche, die Basis- und Bedrohungsmetriken verwenden, als CVSS-BT; und solche, die Basis-, Bedrohungs- und Umgebungsmetriken verwenden, als CVSS-BTE. Soweit die neue Nomenklatur.

Schweregrad ist nicht gleich Risiko

FIRST weist ausdrücklich darauf hin, dass die Benutzer ein Verständnis dafür entwickeln sollten, dass der Schweregrad nicht unbedingt mit dem potenziell damit verbundenen Risiko gleichzusetzen ist. Die Base Scores „sollten nicht allein zur Risikobewertung verwendet werden“, heißt es in der Benutzeranleitung. Trotzdem hat die Basismetrik natürlich ihren Sinn. Die Punktzahl ergibt sich aus der Einschätzung, wie einfach es für einen Angreifer ist, die Schwachstelle auszunutzen und welche potenziellen Auswirkungen ein Angriff hat.

CVSS 4.0 fordert darüber hinaus noch ein halbes Dutzend weiterer Bewertungsmethoden, darunter:

  • Sicherheit: Wenn ein System „einen sicherheitsorientierten Verwendungszweck oder eine sicherheitsorientierte Eignung für einen bestimmten Zweck hat“.
  • Automatisierbar: Wenn eine Schwachstelle einen automatisierten Angriff ermöglicht, z. B. eine unbefugte Remotecodeausführung oder Code Injection.
  • Wiederherstellung: Wie gut ein System oder eine Komponente in der Lage ist, Leistungsfähigkeit und Verfügbarkeit nach einem Angriff wiederherzustellen. Hier unterscheidet die Metrik drei Stufen: „Automatisch“, „durch den Benutzer“ (erfordert manuelles Eingreifen) und „Nicht wiederherstellbar“.
  • Wertdichte: Eine Schwachstelle gilt als „diffus“, wenn sie eine große Gruppe von Benutzern betrifft (E-Mail- oder Bankkonten), oder sie gilt als „konzentriert“, wenn sie eine Komponente oder ein System betrifft, das von einem Betreiber kontrolliert wird.
  • Maßnahmen zur Reaktion auf Schwachstellen: Damit wird bewertet, wie schwierig es für einen Nutzer ist, für die in der jeweiligen Infrastruktur eingesetzten Produkte und Dienste eine erste Reaktion auf die Auswirkungen von Schwachstellen umzusetzen.
  • Dringlichkeit für Anbieter: Dies bezieht sich auf Anbieter, die mithilfe von Sicherheitshinweisen zu ihren Produkten zusätzliche Schweregrade zur Verfügung stellen.

Aber es gibt noch weit mehr Bewertungsmethoden. Etwa den jeweiligen Angriffsvektor, die Komplexität des Angriffs, die Anforderungen für einen Angriff, die Notwendigkeit einer Benutzerinteraktion, die Auswirkungen einer Schwachstelle auf Vertraulichkeit, Integrität und Verfügbarkeit von Daten sowie mögliche Auswirkungen auf sogenannte „Folgesysteme“, die mit einem anfälligen System verbunden sind.

Mit dieser verbesserten Granularität reagierte FIRST nun auf Kritik an der vorhergehenden CVSS-Version. Benutzer hatten die begrenzte Zahl an Metriken bemängelt. Wie schon gesagt, was für die eine Firma vergleichsweise trivial sein mag, ist für eine andere von entscheidender Bedeutung. Ein Vorfall, der kritische Infrastrukturen betrifft, hätte weitaus schwerwiegendere Auswirkungen als ein Vorfall, der nur eine einzelne Organisation betrifft.

Der Schweregrad einer Schwachstelle hängt auch von der Qualität der Verteidigungsmaßnahmen sowie der Detection-und Responsefähigkeiten im Hinblick auf ein Angriffsziel ab. Im Benutzerhandbuch heißt es zu einer hypothetischen Schwachstelle: „Die Angriffskomplexität [also wie schwierig es für einen Angreifer wäre, diese Schwachstelle auszunutzen] dieser Schwachstelle ist bei einem älteren Betriebssystem geringer. Bei einem aktuelleren Betriebssystem mit neuen inhärenten Schutzfunktionen wird die Angriffskomplexität jedoch auf „Hoch“ gesetzt. Diese Varianz führt letztlich zu unterschiedlichen CVSS-B-Scores für dieselbe Schwachstelle bei diesen beiden Betriebssystemen.“

Einfach ist anders

Wer kein ausgewiesener Experte auf dem Gebiet der Schwachstellenbewertung ist, auf den kann die schiere Zahl von Bezeichnungen durchaus einschüchternd wirken. Und das, obwohl eines der erklärten Ziele von FIRST darin besteht, die „Bedrohungsmetriken zu vereinfachen“. Schon das folgende Beispiel aus dem Benutzerhandbuch für die Einstufung einer hypothetischen Schwachstelle wirkt alles andere als simpel. Es sieht wie folgt aus: CVSS-B Score: 8.8 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N)

Das sind 11 Abkürzungen nach CVSS:4.0, aber was bedeuten sie im Einzelnen? Hier ist eine grobe Übersetzung für das, was zwischen den Schrägstrichen steht.

AV:N — Der Angriff kann remote erfolgen und erfordert keinen physischen oder lokalen Zugriff.

AC:L — Die Komplexität für einen Angriff ist niedrig – ein Vorteil für einen Angreifer.

AT:N — Keine Angriffsvoraussetzungen, d. h. der Angreifer kann eine Schwachstelle in sämtlichen oder in den meisten aller Fälle ausnutzen.

PR:N — Keine Privilegien erforderlich – ein weiterer Vorteil für einen Angreifer.

UI:N — Es ist keine Benutzerinteraktion erforderlich, was einen Angriff ebenfalls erleichtert.

VC:N — Keine Auswirkungen auf die Vertraulichkeit, d. h. es werden keine Informationen weitergegeben.

VI:N — Keine Beeinträchtigung der Datenintegrität.

VA:H — Das Risiko eines Verfügbarkeitsverlusts ist hoch, d. h. ein Angreifer kann dem Opfer den Zugriff auf seine Daten verweigern.

SC:N — Kein Risiko eines Vertraulichkeitsverlustes in einem nachgelagerten System, das mit dem gefährdeten System verbunden ist.

SI:N — Kein Risiko eines Integritätsverlustes bei Daten in einem nachgelagerten System.

SA:N — Keine Auswirkungen auf die Verfügbarkeit der Daten in einem nachgelagerten System.

All das liefert einen hilfreichen Kontext für eine Schwachstelle, die mit einem Basiswert von 8.8 als schwerwiegend eingestuft wird. Trotzdem kann die Ausformung dieser Norm einen Benutzer schwindlig machen. Sollte man wirklich davon ausgehen, dass die überwiegende Zahl der Nutzer „Vektor-Strings“ wie diese für Hunderte bis Tausende von Sicherheitslücken übersetzen können, ohne jedes Mal alles nachzuschlagen?

Die Metriken sind, vorsichtig ausgedrückt, einigermaßen detailliert. Es wird also darauf ankommen, wie effektiv das Endergebnis tatsächlich ist und, ob die Benutzer dieser Bewertung mit allem, was dazugehört, vertrauen.

Boris Cipot ist Senior Security Engineer bei Synopsys.