CVSS: Die 5 größten Irrtümer bei der Risiko-Bewertung

28.05.2024

CVSS: Die 5 größten Irrtümer bei der Risiko-Bewertung

Das Common Vulnerability Scoring System (CVSS) ist ein etablierter Standard zur Bewertung von Schwachstellen. CVSS wird standardmäßig zur Bewertung von bekannten Schwachstellen in der CVE-Datenbank (Common Vulnerabilities and Exposures) verwendet und findet auch Anwendung bei der Bewertung von Schwachstellen, die aus einem Pentest resultieren.

In diesem Blog-Eintrag möchte ich über 5 Irrtümer aufklären, die in der Praxis häufig missverstanden werden. Der Blog-Eintrag basiert auf CVSS 4.0 und referenziert einige Fachbegriffe, die es seit v4.0 gibt (z.B. CVSS-BT statt Temporal Score, Threat Metrics, Exploitability Metrics). Grundsätzlich gelten die Aussagen jedoch auch für CVSS 3.0 und 3.1.

Irrtum #1: Der CVSS-Score stellt das Risiko dar

Der CVSS-Score bewertet gemäß dem Standard explizit nicht das Risiko, sondern den technischen Schweregrad einer Schwachstelle. Was heißt das genau?

CVSS betrachtet nur den „Technical Impact“, nicht den „Business Impact“

CVSS betrachtet die technischen Auswirkungen auf die Vertraulichkeit und Integrität der Daten sowie die Verfügbarkeit des Systems. Die daraus resultierenden Konsequenzen für die individuelle Situation eines Unternehmens und dessen Geschäftsprozesse werden nicht bewertet. Dazu zählt die offizielle CVSS-Dokumentation zum Beispiel folgende Kriterien auf, die zusätzlich betrachtet werden müssen: „[…] regulatory requirements, number of customers impacted, monetary losses due to a breach, life or property threatened, or reputational impacts“. ⁽¹⁾

CVSS bewertet nicht die Wahrscheinlichkeit für einen Angriff

Auch ohne Business Impact könnte CVSS aber doch immerhin das technische Risiko bestimmen? Dazu müsste die Wahrscheinlichkeit für die Ausnutzung einer Schwachstelle berücksichtigt werden (Risiko = Wahrscheinlichkeit * Schweregrad). Die Wahrscheinlichkeit betrachtet CVSS jedoch nicht ausreichend, denn wichtige Faktoren fehlen. Insbesondere der CVSS-Base-Score soll laut Standard bewusst nur Faktoren bewerten, die unabhängig von der zeitlichen Komponente und dem individuellen Kontext oder der Umgebung, in der sich die Schwachstelle befindet, sind. Nur so ist ein CVSS-Score zu jedem Zeitpunkt für alle Firmen anwendbar. So fehlen beispielsweise folgende Faktoren, die für die Betrachtung eine Wahrscheinlichkeit notwendig wären:

Erreichbarkeit des Systems aus dem Internet vs. Intranet (Fun Fact: Intranet bedeutet nicht Adjacent bei Attack Vector)
Größe der potentiellen Angreifergruppe
Vertrauensverhältnis zur Angreifergruppe (Mitarbeiter vs. Kunden)
Schwierigkeitsgrad, die Schwachstelle zu finden
Bekanntheitsgrad der Schwachstelle

Was bewertet dann CVSS bei den Exploitability Metrics?

Die Faktoren, die CVSS berücksichtigt, betrachten vielmehr die technischen Voraussetzungen bzw. die technische Ausnutzbarkeit einer Schwachstelle. Die Faktoren für die Ausnutzbarkeit (z.B. Attack Complexity, Privileges Required und User Interaction) haben zudem einen geringen Einfluss auf den CVSS-Score. Denn CVSS hat den Fokus auf den Schweregrad, wie das folgende Beispiel verdeutlicht:

Annahme:
Wir haben eine Schwachstelle, für die bei den Impact Metrics mind. 2 der CIA-Faktoren mit high bewertet werden. In dem Fall betrifft dies die Vertraulichkeit und Integrität der Daten. Der CVSS-Base-Score beträgt somit 9.3. ⁽²⁾

Bedingung 1:
Die Ausnutzung der Schwachstelle ist sehr komplex und es müssen weitere Voraussetzungen erfüllt sein. Zum Beispiel muss der Angreifer zuvor eine AES-Verschlüsselung knacken und es muss eine Race Condition erfüllt sein, aber der Angriff kann nicht automatisiert werden. In dem Fall sind die Faktoren „Attack Complexity“ und „Attack Requirements“ jeweils High. Welche Auswirkungen hat dies nun auf den CVSS-Base-Score? Fast keine: 9,2. ⁽³⁾

Bedingung 2:
Die Schwachstelle ist nur im Admin-Panel einer Anwendung zugänglich (Privileges Required = High). Die Anwendung ist nur aus dem internen Netzwerk erreichbar (nicht darstellbar). Die Anwendung ist zudem nur über einen Jump Server erreichbar (Attack Vector = Adjacent). Welche Auswirkungen hat dies nun auf den CVSS-Base-Score? Geringfügig: 8,5. ⁽⁴⁾

Tatsächlich ist es beim CVSS-Base-Score nicht möglich, eine Schwachstelle auf Medium (<7.0) herabzustufen, sobald mind. 2 Faktoren bei CIA mit high bewertet werden, egal wie die Exploitability Metrics bewertet werden. Andere Risikomodelle, wie z.B. das OWASP Risk Rating, würden auch bei einem hohen Schweregrad noch ein Gesamtrisiko von Medium vorsehen, insofern die Wahrscheinlichkeit gering ist. Aber: CVSS bewertet eben nicht die Wahrscheinlichkeit.

^{Abbildung: Risikomatrix nach OWASP}⁽⁵⁾

Fazit

Wenn man den CVSS-Base-Score nutzt, muss man wissen, dass der technische Schweregrad im Fokus ist. Auswirkungen auf das Business sowie die Wahrscheinlichkeit für das Ausnutzen der Schwachstelle werden nicht ausreichend bewertet.

Hinweis: Mit dem CVSS-BTE-Score wird zusätzlich der Bedrohungsgrad (Threat Metrics, früher Temporal) als auch die individuellen Sicherheitsanforderungen des Kunden (Environmental) betrachtet. Der CVSS-Standard sagt selbst: “[…] the resulting CVSS-BTE score can be considered much closer to “Risk”. ⁽⁶⁾

Irrtum #2: CVSS ist für die Bewertung von allen Pentest-Befunden geeignet

Die Vorteile von CVSS liegen auf der Hand: Eine transparente, nachvollziehbare, standardisierte und zudem noch anpassbare Bewertung von Schwachstellen ist wichtig und wertvoll. Das alles bietet CVSS. Für die Bewertung von Pentest-Befunden hat CVSS jedoch auch zwei große Nachteile.

CVSS unterscheidet nicht zwischen ausnutzbaren Schwachstellen und Härtungsmaßnahmen.
CVSS (und insbesondere CVSS 4.0) geht von veröffentlichten Schwachstellen aus

Härtungsmaßnahmen zu niedrig oder zu hoch eingestuft

Üblicherweise werden in einem Pentest oder anderen Security Assessments nicht nur Schwachstellen, sondern auch Härtungsmaßnahmen gemeldet. Härtungsmaßnahmen können an sich nicht direkt ausgenutzt werden, erschweren aber einen Angriff, insofern eine andere Schwachstelle ausgenutzt werden sollte. Beispiele dafür sind Information Leakages von Versionsnummern, der fehlende Einsatz von TLS 1.3 oder zusätzliche Schutzmaßnahmen wie 2FA bei OWA (Outlook Web App) und Applocker auf Windows Systemen.

Das sind Befunde, die in sich nicht ausnutzbar oder die Ursache für Angriffe sind. Aber die damit verbundenen Maßnahmen können Angriffe erschweren, wenn sie umgesetzt sind.

Derartige Härtungsmaßnahmen haben bei CVSS entweder keinen Schweregrad (CIA = None) und hätten somit einen CVSS-Score von 0 oder werden mit einem niedrigen Schweregrad bewertet (CIA = Low), was häufig in einem CVSS-Score zwischen 4 und 6 endet. Damit werden derartige Härtungsmaßnahmen gleichgestellt mit ausnutzbaren Schwachstellen wie XSS und wären manchmal deutlich zu hoch eingestuft. Auch die Nachvollziehbarkeit geht verloren, weil nicht mehr klar ist, warum das Fehlen von TLS 1.3 nun Auswirkungen auf die Vertraulichkeit hat. Meistens ist es eher ein Compliance-Thema.

Neu bei CVSS 4.0: Nicht veröffentlichte Schwachstellen grundsätzlich sehr niedrig eingestuft

Ein Pentest identifiziert üblicherweise Schwachstellen, die im Nachgang vertraulich dem Kunden gemeldet, aber nicht veröffentlicht werden. Der CVSS-Base-Score ist sowohl für veröffentlichte Schwachstellen als auch nicht veröffentlichte Schwachstellen anwendbar. Die Anwendung des Base-Scores ist daher in beiden Fällen praktikabel.

Wenn man allerdings nun den BT-Score (Threat Metrics, früher Temporal) und damit die Anfälligkeit für einen Exploit bewerten möchte, kommt mit CVSS 4.0 eine spannende Änderung. Die dort eingeführte Threat Metrics hat einen höheren Einfluss auf den Gesamtscore, berücksichtigt jedoch nur noch veröffentlichte Proof of Concepts. Das bedeutet, dass dazu natürlich auch die Schwachstelle bereits öffentlich bekannt sein muss. Da dies bei Pentests selten der Fall ist, könnten Pentest-Befunde grundsätzlich deutlich heruntergestuft werden, unabhängig davon, wie einfach es ist, die Schwachstelle zu finden (wie wir wissen, betrachtet das CVSS nicht).

Es bleibt abzuwarten, wie der BT-Score in der Praxis für nicht veröffentlichte Pentest-Befunde verwendet und welche Auswirkungen dieser haben wird.

Fazit

Es kommt letztendlich auf die Art des Pentests oder Security Assessments an. Liegt der Fokus auf ausnutzbare Schwachstellen, ist CVSS ein geeignetes Bewertungsschema für den Schweregrad. Sollen auch Härtungsmaßnahmen bewertet werden, ist CVSS nur bedingt geeignet und es sollte entschieden werden, wie derartige Befunde evtl. differenziert betrachtet werden können.

Bei der Anwendung von CVSS 4.0 sollte die Verwendung des CVSS-BT-Scores intern evaluiert werden und klar entschieden werden, wie und ob man diesen für nicht veröffentlichte Schwachstellen einsetzt.

Irrtum #3: Der CVSS-Score kann zur Priorisierung von Schwachstellen verwendet werden

Der CVSS-Base-Score sollte nicht direkt zur Priorisierung von Maßnahmen verwendet werden. Er sagt vielmehr aus, was aus technischer Sicht passieren könnte. Bei der Priorisierung sollten folgende Aspekte berücksichtigt werden:

Bei der Bewertung von Härtungsmaßnahmen sollte eine interne Neubewertung des Risikos und des Kosten-Nutzen Verhältnisses erfolgen. Denn wir haben bereits gelernt, dass CVSS reine Härtungsmaßnahmen nicht ausreichend betrachtet.
Der CVSS-Base-Score soll mit dem CVSS-BTE-Score (Threat und Environmental Metrics) durch den Kunden ergänzt werden, um die Schwachstelle im spezifischen Kontext betrachten zu können. Bei der Anwendung von CVSS 4.0 muss die Verwendung des CVSS-BT-Scores vorab intern evaluiert werden, siehe #2. Der BT-Score muss regelmäßig berechnet werden, insofern er für die Priorisierung von Schwachstellen verwendet wird.
Anhand des CVSS-Scores muss das tatsächliche und konkrete Risiko für das Unternehmen abgeleitet werden. Neben dem CVSS-BTE-Score ist es ratsam, weitere Faktoren für die Wahrscheinlichkeit der Ausnutzung und für den Business Impact zu betrachten, die von CVSS nicht berücksichtigt werden.

CVSS erfordert eine Nachbearbeitung für die eigene Situation und Bewertung des konkreten Risikos, um daraus eine Priorisierung abzuleiten. Wenn der CVSS-BT-Score zur Depriorisierung verwendet wird, muss dieser zudem regelmäßig neu berechnet werden, um die Gefahr für zu niedrig bewertete Schwachstellen auszuschließen.

Irrtum #4: Der CVSS-Score wird ausschließlich vom Dienstleister berechnet

Üblicherweise gibt es 3 Beteiligte bei der Bewertung von CVSS

Security Researcher: Er meldet eine Schwachstelle dem Hersteller (Supplier)
Supplier: Er besitzt ein Produkt, in dem sich die Schwachstelle befindet
Consumer: Er nutzt das Produkt, in dem sich die Schwachstelle befindet

Der CVSS-Standard sieht vor, dass lediglich der CVSS-Base-Score durch den „Supplier“ oder „Security Researcher“ berechnet wird. Der CVSS-BT- und CVSS-BTE-Score muss durch den Consumer, also üblicherweise dem Kunden, berechnet werden, da dort der individuelle Kontext der Umgebung und der aktuelle Zeitpunkt berücksichtigt werden. So hat der Kunde über CVSS-BTE die Möglichkeit, die individuellen Sicherheitsanforderungen an das Produkt und den aktuellen Bedrohungsgrad für die Schwachstelle zum Zeitpunkt der Bewertung einfließen zu lassen.
Hinweis: Werden die zusätzlichen Faktoren im BT- und BTE-Score (z.B., Exploit Maturity) nicht bewertet, entspricht ein „Not-Defined“ immer dem höchsten Wert (z.B. Security Requirements = „High“ und Exploit Maturity = „Attacked“). Demzufolge kann der CVSS-Base-Score durch die weiteren Faktoren grundsätzlich nur nach unten korrigiert werden.

Fazit

CVSS sieht vor, dass der Kunde den CVSS-BTE-Score berechnet, um die Schwachstelle im individuellen Kontext betrachten zu können.

Irrtum #5: CVSS bietet eine feingranulare Bewertung

Die unterschiedlichen Faktoren gewährleisten, dass bei der Bewertung von Schwachstellen mehrere relevante Aspekte berücksichtigt werden. In der Bewertung der einzelnen Faktoren ist CVSS jedoch nicht immer besonders flexibel. So gibt es bei der Bewertung des Schweregrads und der damit verbundenen Vertraulichkeit, Integrität und Verfügbarkeit nur die Auswahl zwischen „None“, „Low“ und „High“. Man muss sich also zwischen einem niedrigen oder hohen Schweregrad entscheiden. Ein Cross-Site-Scripting ist daher bei Vertraulichkeit häufig genauso hoch bewertet wie die Existenz einer Software-Versionsnummer im HTTP-Header. Ähnlich ist es bei „Attack Complexity“ und „Attack Requirements“. Diese können ebenfalls nur „low“ und „high“ sein.

Fazit

Manchmal würde man sich bei der Bewertung einen Graubereich wünschen anstelle sich für schwarz oder weiß entscheiden zu müssen, um verschiedene Schwachstellen noch besser voneinander abstufen zu können.

Zusammenfassung

CVSS ist ein sehr gutes Werkzeug, um aus bekannten Schwachstellen die Schwachstellen mit dem höchsten Schweregrad zu extrahieren, Handlungsbedarf zu identifizieren und um anschließend das konkrete Risiko für die Schwachstelle in der eigenen Umgebung bestimmen zu können. Dabei können auch weitere Informationen wie der EPSS-Score (Exploit Prediction Scoring System) hilfreich sein. ⁽⁷⁾

Für die Anwendung bei nicht bekannten und nicht veröffentlichen Schwachstellen, ist es allerdings wichtig, auch die Grenzen von CVSS zu kennen, um daraus die richtigen Prioritäten und Maßnahmen ableiten zu können.
Gerne beraten wir - die fernao security force – Sie dabei, CVSS in Ihrem Unternehmen anzuwenden und daraus konkrete Risiken ableiten zu können oder auf Alternativen zur Risikobewertung umzustellen. Gerne zeigen wir Ihnen auch, wie wir die Risikobewertung in unseren Pentests umsetzen.

Quellen

¹ ^-^{https://www.first.org/cvss/specification-document}^{→ Introduction}
^{2 -}^{https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N}
³ - ^{https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N}
^{4 -}^{https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N}
^{5 -}^{https://owasp.org/www-community/OWASP_Risk_Rating_Methodology}
⁶ ^-^{https://www.first.org/cvss/v4.0/user-guide}^{→ Chapter 2.2 - Weitere Infos dazu unter Punkt 4}
⁷ ^-^{https://www.first.org/epss/}

< Zurück zur Übersicht

fernao.com | Insights | Blog | CVSS: Die 5 größten Irrtümer bei der Risiko-Bewertung