Schwachstellenbewertung

Orientierung im Security-Babylon

Ob Hacker-Gruppen oder Schad-Software – fast immer gibt es mehr als einen Namen

Das macht vieles unnötig kompliziert

TLDR: "Nenn es dann, wie du willst [...] Name ist Schall und Rauch" – im Zweifelsfall schlag bei Malpedia nach.

Es passiert immer wieder so oder so ähnlich

Microsoft präsentiert Informationen, wie die Hacker-Gruppe "Strontium" versucht, die US-Wahlen zu beeinflussen.
Doch nur Eingeweihte bekommen mit, dass das dieselben sind, die bereits die letzten US-Wahlen manipuliert haben und 2015 in den Bundestag eingebrochen sind.

Denn in den Berichten zum Bundestag-Hack war typischerweise von "Sofacy" die Rede.

Oder von "Fancy Bear".
Andere Berichte über die Aktivitäten der vermutlich russischen Elite-Hacker reden von APT28, Sednit, Pawn Storm oder Tsar Team.
Alles Namen für die gleiche Gruppe.
In der Security-Szene herrscht ein geradezu babylonisches Sprachwirrwarr, das nicht selten dazu führt, dass Menschen wichtige Zusammenhänge nicht erkennen oder aneinander vorbeireden.

"MITRE listet mittlerweile 107 Gruppierungen als aktive Bedrohung; viele davon haben einen staatlichen Hintergrund."

MITRE listet mittlerweile 107 Gruppierungen als aktive Cyber-Bedrohung; viele davon haben einen staatlichen Hintergrund.

Das Viren-Chaos

Dieses Namenswirrwarr hat Tradition

So konnten sich schon die Hersteller von Antiviren-Software nicht auf gemeinsame Namen für die von ihnen entdeckten Schädlinge einigen.
Je nach Hersteller hieß der Virus da LoveSan, MSBlast oder auch Blaster (und war eigentlich gar kein Virus, sondern ein Wurm – aber das ist eine andere Geschichte).

Das Problem war und ist, dass die Schad-Programme beziehungsweise bösartige Aktivitäten zumeist von verschiedenen Malware-Analysten unabhängig voneinander entdeckt werden, die sie dann auch gleich mit einem Namen versehen.

Und bei dem bleiben sie dann in aller Regel auch.

Neben dem Stolz, der es nicht zulässt, einfach den Namen der Konkurrenz zu übernehmen, kommt da auch ein weiterer Faktor hinzu

Eigentlich ist es ja ein tolles Alleinstellungsmerkmal, wenn man schreiben kann, dass die eigene Software den neuen "SuperDestroyer" bereits entdeckt und stoppen kann, während die Konkurrenz zu dem Thema nichts vorzuweisen hat.
Dass die das Teil unter dem Namen "DataKiller" führen, muss man dem Kunden ja nicht auf die Nase binden.

Die NSA hat viele Namen

Ähnlich läuft es bei den Hacking-Aktivitäten und der dabei eingesetzten Malware

Hätten Sie gewusst, dass die Aktivitäten von NSA/CIA sowohl unter dem Label "The Equation Group" (Kaspersky) als auch als "The Lamberts" (ebenfalls Kaspersky) oder "Longhorn" (Symantec) diskutiert werden? Oder dass die Ransomware Dharma (Microsoft, Trend Micro u.a.) auch unter Crysis (u.a. McAfee, Malwarebytes) firmiert?

"Wenn es um APT, Cybercrime oder Malware geht, gibt Malpedia einen guten Einstieg in die weitere Recherche."

Wenn es um APT, Cybercrime oder Malware geht, gibt Malpedia einen guten Einstieg in die weitere Recherche.

Erschwerend hinzu kommt, dass die Cybercrime-Szene sehr unübersichtlich geworden ist.

Wer mal eben ganz unbefangen meinen Artikel zu Cybercrime: Erpressung auf neuem Niveau [1] liest, wird sehr schnell mit Begriffen wie Trickbot, Ryuk, Maze, Ragnar Locker, REvil und DoppelPaymer konfrontiert.
Das sind die Namen von (verschiedenen) Cybercrime-Banden beziehungsweise der von ihnen eingesetzten Schad-Software.
Und das sind nur die Bekanntesten; dahinter folgt eine kaum mehr überschaubare Heerschar von Newcomern und Nachahmern.
Auch die Zahl der bekannten APT-Akteure wie Sofacy & Co wächst ständig.
Allein hier listet etwa die MITRE mittlerweile 107 verschiedene Gruppen.

Tipps zu Orientierung

Wer das alles im Kopf hat, lernt vermutlich auch zum Frühstück Telefonbücher auswendig – könnte man ja mal brauchen.

Für alle anderen folgen hier ein paar praktische Tipps, sich einen Überblick zu verschaffen beziehungsweise im Zweifelsfall die richtigen Querverbindungen aufzuspüren.

Auf der bereits erwähnten Seite zu MITRE ATT&CK Groups [2] gibt es einen Überblick zu den Namen mit kurzen Beschreibungen der Gruppen.
- Leider wird man da etwa bei Trickbot oder Emotet nicht fündig.
- Denn die listet MITRE nur unter Software.
Im Rahmen der MISP Threat Sharing Plattform zum Austausch von Security-Informationen sind die MISP Galaxy Cluster entstanden.
- Im Prinzip ist das eine riesige Datenbank mit allen in diesem Bereich relevanten Begriffen und deren Beziehungen untereinander.
- Man kann die entweder über eine gigantische HTML-Seite [3] oder die MISP-Software nutzen.
- Beides ist für "mal eben schnell was nachschauen" nicht wirklich praktisch.
Das Fraunhofer FKIE betreibt mit Malpedia eine Web-Site, die einen sehr guten Zugang zu Informationen rund um Malware und deren Profiteure [4] bietet.
- Ihr Datenbestand beruht auf den MISP Galaxys.
- Tippt man in das Suchfeld etwa Strontium ein, landet man direkt beim Eintrag für Sofacy, erhält eine Liste aller Aliases der Gruppe und eine Liste von ausgewählten Veröffentlichungen, die sich auf deren Aktivitäten beziehen.

Das alles löst natürlich längst nicht alle Probleme, die sich aus dem babylonischen Sprachwirrwarr ergeben.

Die Leute werden auch weiter aneinander vorbeireden oder wichtige Zusammenhänge nicht verstehen.
Eigentlich will man eine einheitliche Nomenklatur, die das vermeidet.
Aber das ist schon bei den Viren nicht gelungen und ich habe wenig Hoffnung, dass es jetzt klappen wird.

Doch zumindest kann man mit Diensten wie Malpedia [5] das Beste aus dieser Situation machen.

Ich jedenfalls habe mir angewöhnt, bei Berichten von Security-Firmen die verwendeten Namen dort abzufragen.
Und das ergab schon die eine oder andere Erleuchtung.

Links

Das CVE-System im Überblick

MITREs Common Vulnerabilities and Exposures System (CVE) ist der gängige Standard zur Verwaltung von Schwachstellen.

Bereits im letzten Jahrtausend gestaltete sich die Kommunikation über Sicherheitslücken zunehmend schwierig

Wer von "die Sicherheitslücke im Internet Explorer" sprach, adressierte oftmals mehr als ein Dutzend aktueller Bugs.
Eingrenzungen à la "die Lücke mit ActiveX" halfen kaum weiter, da das immer noch auf viele zutraf.

Um Missverständnisse zu vermeiden und sicherzustellen, dass alle vom gleichen Problem sprachen, musste eine herstellerübergeifende, einheitliche Strategie zur Erfassung und Verwaltung von Schwachstellen her.

1999 begann man daher mit einer systematischen Durchnummerierung

Das CVE (Common Vulnerabilities and Exposures)-System war geboren und hat sich seither als weltweit führender Industriestandard durchgesetzt.
Betreut und verwaltet wird es von der gemeinnützigen MITRE Corporation, finanziert mit Mitteln der US-Sicherheitsbehörden CISA (Cybersecurity and Infrastructure Security Agency) und DHS (Department of Homeland Security).

CVE-YYYY-NNNNN

CVE-Nummern beziehungsweise -IDs im Format CVE-YYYY-NNNNN dürften jedem schonmal begegnet sein

der sich mit Schwachstellen befasst hat – etwa auf der Suche nach Sicherheitsupdates für ein bestimmtes Produkt oder auch beim Lesen von Alerts bei heise Security.

Auf das "CVE" am Anfang folgt stets eine Jahresangabe

Bei dieser handelt es laut MITRE allerdings nicht (unbedingt) um das Jahr, in dem die Lücke entdeckt, sondern vielmehr um jenes, in dem sie publik gemacht beziehungsweise in dem die Nummer vergeben wurde.

Der letzte Teil der ID mit der eigentlichen Nummer war mit Einführung des CVE-Systems Ende 1999 noch auf vier Ziffern beschränkt

Da 9999 mögliche einzigartige IDs pro Jahr irgendwann aber nicht mehr ausreichten, wurde die Syntax Anfang 2014 geändert [1].
Eine maximale Länge des "NNNNN"-Parts der IDs gibt es nun nicht mehr; sie orientiert sich am Bedarf im jeweiligen Kalenderjahr.
Lediglich das Minimum wurde auf vier Ziffern festgeschrieben.

ID-Vergabe durch CNAs

Natürlich sorgt eine einheitliche Syntax allein nicht für Ordnung.

Damit CVE-IDs nicht unkontrolliert vergeben werden, haben nur bestimmte Personen, Organisationen und Unternehmen, so genannte CVE Numbering Authorities (CNAs), die Befugnis zur CVE-Vergabe.
Diese wiederum teilen die Zuständigkeit für verschiedene Produkte und Projekte klar unter sich auf.

Übergeordnete (Top-Level) Root CNAs, sind derzeit das MITRE CVE-Team, CISA und und das japanische JPCERT/CC.

Ihnen untergeordnet sind "normale" CNAs, deren Befugnisse unterschiedlich weit reichen können.
So befinden sich darunter etwa Soft- und Hardware-Hersteller, die CVE-IDs nur für ihre eigenen Produkte vergeben dürfen, aber auch CERTs, die die Vergabe für jeweils mehrere Unternehmen koordinieren.

Unabhängige Forscher, Forscherteams oder IT-Sicherheitsunternehmen (z. B.

die Zero Day Initiative oder auch Rapid7) können, teilweise im Rahmen von Bug Bounty-Programmen, auch herstellerübergreifend als CNA für Produkte agieren, die nicht im Verantwortungsbereich einer anderen CNA liegen.
Ähnliches gilt für so genannte CNAs of Last Resort (CNA-LR).

Wer eine Schwachstelle in einem bestimmten Produkt entdeckt und diese melden will, findet die jeweils zuständige Anlaufstelle in einer CNA-Übersicht auf MITREs CVE-Website [2].

Die CNA kümmert sich im nächsten Schritt um die Reservierung einer CVE-ID.
Die landet in MITREs fortlaufend geführter CVE-Liste [3]– typischerweise zunächst mit dem Vermerk "Reserved".
Später vervollständigen eine Schwachstellen-Beschreibung und meist auch Verlinkungen zu weiterführenden Informationen den CVE-Eintrag.

CVE-Nutzung durch heise Security

Auch heise Security verwendet wo immer es sinnvoll möglich ist CVE-Nummern.

Wir betten diese etwa in unsere Alert-Meldungen mit ein, um später eine gezieltes Suche nach einer bestimmten Lücke zu ermöglichen.
Die Links auf die eigentlichen CVE-Seiten bringen zum Zeitpunkt, zu dem unsere Meldungen erscheinen, oftmals nur wenig Mehrwert, da sich die ID mitunter noch im "Reserved"-Status befindet.
Um unsere Leser nicht in diese Sackgasse zu schicken, lassen wir die Links daher auch häufig weg und erwähnen lediglich die CVE-Nummer.

Bei Sammeladvisories beschränken wir uns auf die zentralen Lücken, die in der weiteren Berichterstattung am wahrscheinlichsten eine Rolle spielen werden.

Sonst müssten wir etwa bei einem Oracle Critical Patch Update mal eben 400 IDs in unsere Artikel pressen – und der Mehrwert für unsere Leser wäre gleich Null.

Zusatz-Infos in der NVD

Sind dagegen bereits weiterführende Informationen verfügbar, bieten sich statt einer Verlinkung auf MITREs CVE-Liste alternativ auch Verweise auf die so genannte National Vulnerability Database (NVD) [4] an.

Sie ist ein unabhängiges, 2005 vom National Institute of Standards and Technology (NIST) ins Leben gerufenes Projekt, das wie das CVE-System von den US-Behörden CISA und DHS gesponsert wird.

Die NVD speist sich aus MITREs CVE-Liste, fügt den eher knappen Beschreibungen allerdings wertvolle Zusatzinformationen etwa zu Sicherheitsrisiken oder verfügbaren Updates hinzu.

Zur einheitlichen Beschreibung von Schwachstellen-Eigenschaften nutzt (nicht nur) die NVD wiederum ein spezielles System, mit dem unter anderem man einen Schweregrad von "Low" bis "Critical" zuweisen und Aussagen zu Angriffsweg, -komplexität und Co.

anhand vordefinierter Kriterien treffen kann.
Dieses so genannte Common Vulnerability Scoring System (CVSS) hat einen eigenen Hintergrundartikel verdient, der demnächst bei heise Security erscheinen soll.

URL dieses Artikels

https://www.heise.de/-4940478

Links in diesem Artikel

Schwachstellenbewertung mit CVSS

Das Common Vulnerability Scoring System hilft bei der Bewertung von Schwachstellen

Beim Common Vulnerability Scoring System (CVSS) geht es hauptsächlich darum, die Gefahr zu bewerten, die von einer Sicherheitslücke ausgeht.

In einigen Fällen geht das recht leicht.
Bei der Ende 2019 als "Shitrix" bekannt gewordenen Schwachstelle in Citrix-Produkten konnten unauthentifizierte Angreifer betroffene Systeme aus der Ferne angreifen und mit nur wenig Aufwand unter ihre Kontrolle bringen (CVE 2019-19781).
Im Laufe des Jahres 2020 wurden über Shitrix zahlreiche Systeme infiziert und mit Backdoors versehen.
Diese wurden anschließend vielfach zum Einschleusen von Ransomware verwendet.
Im Falle der Universitätsklinik Düsseldorf etwa forderte die Ransomware "DoppelPaymer" ein Lösegeld [1].
Es liegt auf der Hand, dass Shitrix eine "kritische" Lücke ist.

Die Sachlage ist jedoch nicht immer so eindeutig.

Der 2014 bekannt gewordenen POODLE-Angriff auf HTTPS-Verschlüsselung [2], nutzte sehr trickreich Schwächen im SSL-Protokoll und sorgte für viel Aufsehen (CVE-2014-3566).

Doch so genial der Angriff in der Theorie war, so schwierig war dann die Ausführung unter realen Bedingungen?

Der Aufwand war hoch und der Schaden beschränkte sich auf das Byte-weise Auslesen von Daten aus den Browsern einzelner Nutzer.
Gefühlt ist POODLE also deutlich weniger gefährlich Shitrix.
Doch wie lässt sich dieses Bauchgefühl quantifizieren?

Risiko = Eintrittswahrscheinlichkeit x Schaden

Bei der systematischen Bewertung von Schwachstellen macht man sich das allgemeine Prinzip der Risikoanalyse zunutze.

Dabei identifiziert man Schadensereignisse und schätzt ab, wie wahrscheinlich diese Ereignisse eintreten und wie hoch die daraus resultierenden Schäden sein könnten.
In der Praxis lassen solche Einschätzungen jedoch viel Interpretationsspielraum zu.

Systeme zur Schwachstellenbewertung helfen mit vordefinierten Faktoren, Wahrscheinlichkeit und Schadensausmaß möglichst objektiv zu beziffern.

Ein solches System ist das Common Vulnerability Scoring System (CVSS), das sich international zunehmend als De-facto-Standard etabliert, um wesentliche Merkmale einer Schwachstelle zu beschreiben und deren Schweregrad zu bestimmen.

Die Anfänge von CVSS reichen bis ins Jahr 2005 zurück, als das US National Infrastructure Advisory Council (NIAC) eine erste Entwurfsfassung veröffentlichte.

Die Verantwortung für CVSS ging seitdem an das Forum of Incident Response and Security Teams (FIRST) über, ein Zusammenschluss internationaler Sicherheits- und Incident-Response-Teams aus Regierungen, Industrie und Wissenschaft.
Bei FIRST kümmert sich seitdem die CVSS Special Interest Group (SIG) um die Weiterentwicklung von CVSS.
Die heute gültige Version 3.1 stammt aus dem Jahr 2019.

Metriken zur differenzierten Bewertung

Die Bewertung von Schwachstellen erfolgt bei CVSS anhand verschiedener Kriterien, sogenannter Metriken.

Für jede Metrik gibt es vordefinierte Wahlmöglichkeiten.
Aus denen errechnet sich ein Schweregrad von 0.0 bis 10.0, wobei 10.0 dem höchsten Schweregrad entspricht.
Diesen Zahlenwerten werden anschließend die auch aus Schwachstellen-Meldungen bekannten qualitativen Kategorien ("None", "Low", "Medium", "High" und "Critical") zugeordnet.

Die Metriken zur Bestimmung des Schweregrads sind dabei in drei Gruppen unterteilt: Base Metrics, Temporal Metrics und Environmental Metrics. Basis-Metriken (Base Metrics) beschreiben die wesentlichen technischen und unveränderlichen Merkmale einer Schwachstelle.

Aus ihnen lässt sich ein sogenannter "Base Score" errechnen, der für den technischen Schweregrad einer Schwachstelle steht.
Er kann später nachjustiert und an zeitliche Veränderungen (Temporal Metrics) oder die jeweilige Umgebung des betroffenen Systems (Environmental Metrics) angepasst werden.

Datei:Bild3.png

Die CVSS-Metriken gliedern sich, wie hier abgebildet, in drei Gruppen.

(Bild: first.org [3])

Den Base Score einer Schwachstelle errechnet in der Regel deren Entdecker oder aber der Hersteller des betroffenen Produkts beziehungsweise ein CERT, das die Behebung der Schwachstelle koordiniert.

Für Schwachstellen in öffentlichen Standard-Produkten wird meist auch eine CVE-ID als eindeutige Schwachstellenbezeichung im Format CVE-YYYY-NNNNN beantragt beziehungsweise vergeben.

Viele Leser von Schwachstellen-Meldungen dürften das CVE-System, dem wir einen separaten Hintergrundartikel gewidmet haben [4], und CVSS bisher als untrennbare Einheit wahrgenommen haben.
In Wirklichkeit sind CVE und CVSS jedoch zwei völlig voneinander unabhängige Systeme: Eine CVE-ID ist keine zwingende Voraussetzung zur CVSS-Verwendung.
Während CVE das Ziel verfolgt, Schwachstellen eindeutige Bezeichner zuzuweisen und zu verwalten, möchte CVSS den Schwachstellen einen Schweregrad zuteilen.

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) [5] des National Institute of Standards and Technology (NIST) zu jeder bekannt gewordenen Schwachstelle den CVSS Base Score.

Nachträgliche Feinjustierung

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.

Gesamtschweregrad und CVSS-Vektor

Datei:Bild4.png

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.

Datei:Bild5.png

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 [6-Anwendung [7]].

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.

Datei:Bild6.png

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

(Bild: Andreas Kurtz)

Kritik an CVSS

Wie jedes System zur Schwachstellenbewertung hat auch CVSS seine Tücken

Eine der Hauptkritikpunkte ist die intransparente Herleitung der Formeln zur Berechnung der Scores.
Beispielsweise legt die Spezifikation fest, dass eine Low Attack Complexity (AC:L) immer genau mit dem Faktor 0.77 gewichtet werden soll.
Wie diese Faktoren im Detail zustande kamen, bleibt genauso unklar wie wissenschaftliche Belege dafür fehlen, dass die Formeln empirisch oder theoretisch fundiert sind.

Wie bereits erwähnt gibt es auch an den Temporal Metrics Kritik

So ist laut Spezifikation sinnvollerweise vorgesehen, dass eine Schwachstelle kritischer zu betrachten ist, sobald ein öffentlicher Exploit auftaucht.
Über Temporal Metrics lässt sich der Base Score aber lediglich absenken und nicht erhöhen.

Genauso diskussionswürdig ist, ob beziehungsweise wie das Vorhandensein eines Hersteller-Updates (Remediation Level: Official Fix) den Schweregrad einer Schwachstelle absenkt

Denn nur durch das Vorhandensein eines Patches ist er auf den betroffenen Systemen noch lange nicht eingespielt.
Und wenn man bedenkt, dass Angreifer häufig Patches analysieren, um so die Schwachstellen besser zu verstehen (Patch Diffing), könnte man auch argumentieren, der Schweregrad müsste durch das Vorhandensein eines Patches eher zunehmen.

Neben der Kritik an CVSS selbst gibt es auch Einwände zur Verwendung in der Praxis

Häufig wird der CVSS Score nämlich eins zu eins als Risiko interpretiert.
Hier ist aber wichtig zu verstehen, dass der Base Score lediglich einen technischen Schweregrad abbildet und nicht etwa ein konkretes Risiko aufzeigen kann.
Ein aus dem Kontext gegriffener technischer Schweregrad sagt nur wenig über das tatsächlich mit einer Schwachstelle einhergehende Risiko für das betroffene System, für die darauf abgebildeten Geschäftsprozesse und letztendlich für das Unternehmen aus.
Auch bereits vorhandene Gegenmaßnahmen, die eine Ausnutzung möglicherweise erschweren oder verhindern, werden im Base Score nicht berücksichtigt.

Unterschiedliche Interessen – unterschiedliche Bewertung?

Zwar sollen Schwachstellen möglichst unvoreingenommen bewertet werden, dennoch dürften auch die Interessen der bewertenden Person eine große Rolle spielen

Ein Security Researcher verspricht sich im Zweifel mehr Hype um eine entdeckte Schwachstelle, wenn sie möglichst hoch bewertet wird.
Hersteller hingegen argumentieren, über eine bessere Informationsgrundlage zu verfügen, um den tatsächlichen Schweregrad verlässlicher bewerten zu können.

Andererseits kann es durchaus vorkommen, dass Hersteller versuchen, Schwachstellen möglichst kleinzureden, um schlechte Presse zu vermeiden.

Diskussionen innerhalb der Security Community und auch unabhängige Bewertungen des NIST sorgen hier in der Regel allerdings für eine selbstkorrigierende Wirkung und Hersteller haben daher – nicht zuletzt auch aus Haftungsgründen – ein Interesse an seriösen Bewertungen.

Inwieweit CVSS dahin gehend verlässlich ist, dass unterschiedliche Personen zu einheitlichen Bewertungen kommen, untersucht derzeit eine Forschungsgruppe der Universität Erlangen-Nürnberg in einer Online-Umfrage [8]

Die Umfrage richtet sich an Experten, die regelmäßig CVSS verwenden.
In der Umfrage werden Hintergrundkenntnisse zu CVSS abgefragt, bevor dann vier vorgegebene Schwachstellen mittels CVSS bewertet werden sollen.

Fazit und Ausblick

Trotz der genannten Kritikpunkte ist CVSS nach bald zwei Jahrzehnten aus der Welt des Schwachstellen-Managements – nicht nur mangels Alternativen – heute nicht mehr wegzudenken.

Es ersetzt zwar keine individuelle Risikoanalyse, bei der in der Regel weit mehr Faktoren als nur der Schweregrad einer Schwachstelle betrachtet werden.
Insbesondere erweitert um den Environmental Score kann der CVSS Base Score aber als wichtiges Merkmal mit in eine solche Analyse einfließen.

Wie ein Blick in die Liste der möglichen Verbesserungen für CVSS v4.0 [9] zeigt, arbeiten die Autoren der CVSS SIG bereits mit Hochdruck an der nächsten Version.

Darin sollen auch einige der genannten Kritikpunkte in Angriff genommen werden.
Die Temporal Metrics sollen nachgebessert werden und es wird auch diskutiert, Nutzern ein Best-Practice-Dokument an die Hand zu geben, wie der CVSS-Score als Input in einer Gesamtrisikobewertung verwendet werden kann.

Wer tiefer in das Thema CVSS einsteigen möchte, dem sei die CVSS-v3-Spezifikation [10] ans Herz gelegt.

Hier werden sämtliche Metriken, die vordefinierten Wahlmöglichkeiten und die Berechnungsformeln detailliert erläutert.
Ein User Guide gibt zusätzliche Hinweise zur Verwendung von CVSS [11].
Ein erstes Gefühl für das Zustandekommen von CVSS-Werten bekommt man schon mit wenigen Klicks im CVSS Calculator [12].

Links