Von niedrig bis kritisch: Schwachstellenbewertung mit CVSS

Seite 2: Den Base Score bestimmen

Inhaltsverzeichnis

Nun aber zurück zum Base Score: Die zur Berechnung verwendeten Basis-Metriken bewerten zum einen die Voraussetzungen für einen Angriff (Exploitability Metrics) und zum anderen auch die aus einer Ausnutzung resultierenden Konsequenzen (Impact Metrics).

Bei den Voraussetzungen wird beispielsweise hinterfragt, ob ein Angriff über das Internet durchgeführt werden kann oder ob ein Angreifer physischen Zugriff auf ein Gerät benötigt (Attack Vector). Weiter wird abgeschätzt, wie komplex die Durchführung eines Angriffs ist (Attack Complexity) und ob ein Angriff unauthentifiziert durchgeführt werden kann oder ob ein Angreifer über ein gültiges Benutzerkonto mit bestimmten Privilegien verfügen muss (Privileges Required). Zudem fließt mit ein, ob für eine erfolgreiche Ausnutzung die Interaktion mit einem Benutzer erforderlich ist (User Interaction).

Zur Bewertung der Konsequenzen eines erfolgreichen Angriffs ist entscheidend, inwieweit Daten von dem betroffenen System ausgelesen oder verändert werden können oder das System in seiner Verfügbarkeit eingeschränkt werden kann. Ermittelt wird also, wie stark durch eine erfolgreiche Ausnutzung die Schutzziele Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability) beeinträchtigt werden.

Eine gewisse Sonderstellung nimmt die Scope-Metrik ein, die mit CVSS v3.0 eingeführt wurde. Über sie lässt sich erfassen, wenn zwar eine bestimmte Komponente verwundbar ist (Vulnerable Component), sich die Ausnutzung einer Schwachstelle aber unmittelbar auf eine andere, physisch oder logisch abgetrennte Komponente auswirkt (Impacted Component). Ein sogenannter "Scope Change" tritt beispielsweise auf, wenn eine Schwachstelle in einer virtuellen Maschine (Vulnerable Component) einem Angreifer ermöglicht, Dateien auf dem Host-Betriebssystem (Impacted Component) zu lesen oder zu verändern. Die Überwindung der logischen Sicherheitsbarriere verursacht einen Scope-Wechsel und hat für die Bewertung der Schwachstelle einen höheren Schweregrad zur Folge.

Die ermittelten Basis-Metriken werden schließlich miteinander verrechnet und ergeben den Base Score. Im Internet veröffentlichte CVSS-Bewertungen nutzen zumeist diesen Score. So nennt etwa auch die National Vulnerability Database (NVD) des National Institute of Standards and Technology (NIST) zu jeder bekannt gewordenen Schwachstelle den CVSS Base Score.

Der Base Score kann später nachjustiert und an zeitliche Veränderungen (Temporal Metrics) oder die jeweilige Umgebung des betroffenen Systems (Environmental Metrics) angepasst werden.

Zeitliche Veränderungen liegen zum Beispiel dann vor, wenn nicht mehr nur vage Textbeschreibungen zu einer abstrakten Schwachstelle vorliegen, sondern ein voll funktionsfähiger Exploit in freier Wildbahn auftaucht (Exploit Code Maturity). Ähnliches gilt, wenn eine Schwachstelle, über die zunächst nur spekuliert wurde, beispielsweise durch den Hersteller bestätigt wurde (Report Confidence). Die Gefahr kann auch abnehmen, etwa wenn für die Schwachstelle ein Workaround oder ein offizieller Hersteller-Fix zur Verfügung steht (Remediation Level).

Diese Änderung der Gefahrenlage bildet CVSS etwas gewöhnungsbedürftig ab: Temporal Metrics können nämlich den Base Score immer nur nachträglich absenken, ihn aber nicht anheben. CVSS geht zunächst also immer vom Worst-Case-Szenario aus – ein Sachverhalt, der im Rahmen der Kritik an CVSS weiter unten noch genauer diskutiert wird.

Die Environmental Metrics wiederum ermöglichen, den Score unternehmensintern an die jeweils vorherrschende IT-Umgebung anzupassen. Je nachdem, wie wichtig oder unwichtig das von einer Schwachstelle betroffene System für ein Unternehmen ist, wird der Base Score auf- oder abgewertet. So ist für ein Unternehmen eine bestimmte Schwachstelle in der Speiseplan-App der Kantine sicherlich weniger schlimm, als wenn sie das unternehmenseigene Data Warehouse betrifft. Mit den Environmental Metrics werden Vertraulichkeits-, Verfügbarkeits- und Integritätsanforderungen an das konkrete System festgelegt. Auch können möglicherweise bereits vorhandene Gegenmaßnahmen innerhalb der Umgebung für die Bewertung berücksichtigt werden.

CVSS Scores werden qualitative Schweregrade zugeordnet.

(Bild: first.org)

Am Ende werden Base Score, Temporal Score und Environmental Score zu einem Gesamt-Score verrechnet. Für jeden einzelnen Score (Base, Temporal, Environmental) sowie für den Gesamt-Score ergibt sich so ein Zahlenwert. Diese Zahlenwerte werden in qualitative Schweregrad-Kategorien von "None" bis "Critical" unterteilt. Diese qualitative Zuordnung ist optional und soll vorrangig Unternehmen bei ihrem internen Schwachstellen-Management unterstützen.

Zusätzlich werden die Metriken in einer textuellen Kurzform zusammengefasst, dem sogenannten CVSS-Vektor. Dieser Vektor enthält alle Informationen über die vorangegangenen Einstufungen und wird stets mit dem Score veröffentlicht.

Der CVSS-Calculator zeigt hier die Bewertung der Shitrix-Schwachstelle.

(Bild: first.org (Screenshot))

Einen kompakten Überblick über den Aufbau des CVSS-Vektors liefert die CVSS Calculator-Anwendung. In der Praxis erleichtert sie übrigens auch die Bewertung: Über eine Weboberfläche lassen sich dort Metriken einfach "zusammenklicken" und Scores sowie Vektoren direkt ablesen. Auch bereits vorhandene Basis-Vektoren können eingelesen werden, um dann etwa Temporal oder Environmental Metrics anzupassen.

Zurück zu den Schwachstellen-Beispielen vom Anfang: Die Shitrix-Schwachstelle kommt auf einen Base Score von 9.8, was einem kritischen Schweregrad entspricht. Die dem Poodle-Angriff zugrundeliegende Schwachstelle erhält einen Base Score von 3.1, also ein niedriger Schweregrad. Das drückt das eingangs formulierte Gefühl recht gut in Zahlen aus.

Zwei ganz unterschiedliche Beispiele für CVSS-Vektoren liefern Shitrix und POODLE.

(Bild: Andreas Kurtz)