Der neue CVSS-Standard: Alles andere als einfach

• 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.