Von CVSS zu RBVM: Schwachstellen richtig priorisieren

Bei einem ersten Blick auf das CVSS (Common Vulnerability Scoring System) könnte man denken, dass es sich um das perfekte Tool für die Untersuchung und Priorisierung von Schwachstellen handelt. Demnach ist ein höheres Scoring gleichbedeutend mit einer kritischeren Schwachstelle. Leider funktioniert dieser Ansatz in der Realität nicht so ganz. Jedes Jahr steigt die Anzahl an Schwachstellen mit hohen CVSS-Scorings. Für Sicherheitsteams ist es gar nicht zu schaffen, diese alle rechtzeitig zu beheben. Gleichzeitig wird der Großteil dieser Schwachstellen aber auch nie durch Angriffe in der realen Welt ausgenutzt. Stattdessen nutzen Angreifer häufig eher weniger auffällige Schwachstellen mit niedrigeren Scorings aus. Es gibt auch andere versteckte Fallstricke – von rein technischen Problemen wie widersprüchliche CVSS-Bewertungen bis hin zu konzeptionellen Problemen wie fehlendem Business-Kontext.

Diese sollte man nicht unbedingt als konzeptuelle Mängel von CVSS verstehen. Es unterstreicht aber die Notwendigkeit, nicht alleinig auf dieses System zu setzen, sondern vielmehr seinen Platz im Rahmen eines umfassenderen Schwachstellenmanagements zu kennen und es gezielt zu nutzen.

CVSS-Widersprüche

Es kann durchaus vorkommen, dass ein und dieselbe Schwachstelle je nach verfügbarer Quelle unterschiedliche Schweregrade aufweist. Beispielsweise das Scoring von dem Sicherheitsforscher, der sie entdeckt hat, ein weiteres von dem Entwickler der betroffenen Software und noch eins von einem nationalen Schwachstellen-Register. Denn ein einfacher Fehler bleibt je nach Sichtweise eben nicht nur ein einfacher Fehler. Verschiedene Experten können sich über die Gefahr, die von der Ausnutzung des Fehlers ausgeht, durchaus uneinig sein. So existieren möglicherweise unterschiedliche Vorstellungen darüber, mit welchen Berechtigungen eine betroffene Anwendung in freier Wildahn ausgeführt wird oder ob sie mit dem Internet kommuniziert. Ein Software-Hersteller kann für eine Einschätzung beispielsweise die von ihm empfohlenen Best Practices zu Grunde legen. Ein Sicherheitsforscher wiederum berücksichtigt möglicherweise die Anwendungskonfigurationen so, wie sie in realen Unternehmen tatsächlich auftreten. Je nach Schwerpunkt eines Forschers schätzt einer die Komplexität des Exploits vielleicht als hoch ein, ein anderer eher als gering. Und so eine Situation ist mitnichten eine Seltenheit. Eine Studie von Vulncheck aus dem Jahr 2023 ergab, dass 20% der Schwachstellen in der National Vulnerability Database (NVD) zwei CVSS3-Scorings aus verschiedenen Quellen aufwiesen und 56% dieser Scoring-Paare zueinander widersprüchlich waren.

Häufige Anwendungsfehler von CVSS

Bereits seit über einem Jahrzehnt setzt sich FIRST für die methodisch korrekte Anwendung von CVSS ein. Dennoch machen Organisationen, die CVSS-Scorings in ihre Prozesse zum Schwachstellen-Management einfließen lassen, nach wie vor typische Fehler:

1. Verwendung des CVSS-Basis-Scores als primären Risikoindikator. CVSS gibt den Schweregrad einer Schwachstelle an – nicht aber die Situation, in der sie ausgenutzt wird, und die Auswirkungen ihrer Ausnutzung auf ein angegriffenes Unternehmen. Eine kritische Schwachstelle kann in einer bestimmten Unternehmensumgebung harmlos sein, wenn sie sich in unbedeutenden oder isolierten Systemen befindet. Umgekehrt kann ein groß angelegter Ransomware-Angriff die Folge einer scheinbar harmlosen Schwachstelle mit einem CVSS-Score von 6 sein.
2. Anwendung des CVSS-Basis-Scores ohne Berücksichtigung der Threat/Temporal- und Environmental-Metriken. Die Verfügbarkeit von Patches, öffentlichen Exploits und Kompensationsmaßnahmen hat einen großen Einfluss darauf, wie und mit welcher Dringlichkeit eine Schwachstelle geschlossen werden sollte.
3. Ausschließliches Beheben von Schwachstellen oberhalb eines bestimmten Scorings-Grenzwerts. Dieser Ansatz wird manchmal von Regierungen oder branchennahen Aufsichtsbehörden eingefordert („Aller Schwachstellen mit einem CVSS-Scoring größer gleich 8 sind innerhalb eines Monats zu beheben“). Das Resultat davon ist, dass Cybersicherheitsteams mit einer ständig wachsenden Arbeitsbelastung konfrontiert werden, deren Abarbeitung die Infrastruktur aber nicht wirklich sicherer macht. Die Anzahl der jährlich identifizierten Schwachstellen mit hohem CVSS-Scoring hat in den letzten 10 Jahren stark zugenommen.
4. Anwenden des CVSS-Scorings zur Vorhersage der Ausnutzungswahrscheinlichkeit. Hier sollte man eher keinen Zusammenhang sehen: gerade mal 17 % der kritischen Schwachstellen werden jemals wirklich für Angriffe ausgenutzt.
5. Alleiniges Verwenden des CVSS-Scorings. Die standardisierte Vektorzeichenfolge wurde in CVSS eingeführt, damit die Sicherheitsexperten die Details einer Schwachstelle verstehen und deren Auswirkungen auf die Beschaffenheiten ihrer eigenen Organisation kalkulieren können. CVSS 4.0 wurde speziell überarbeitet, um den eigenen Business-Kontext mithilfe zusätzlicher Metriken einfacher in die Berechnung einzubeziehen. Jegliche Bemühungen, ein rein auf numerischen Scorings basierendes Schwachstellen-Management zu etablieren, sind weitestgehend ineffektiv.
6. Ignorieren weiterer Informationsquellen. Es reicht nicht aus, sich nur auf eine einzige Schwachstellendatenbank zu verlassen und CVSSs zu analysieren. Wenn Informationen zu verfügbaren Patches, funktionierenden Proof-of-Concepts und bekannten Fällen einer realen Ausnutzung fehlen, erschwert dies die Entscheidung, wie Schwachstellen geschlossen werden sollen.

Was CVSS über eine Schwachstelle verschweigt

CVSS ist zwar der Industriestandard für die Beschreibung des Schweregrades einer Schwachstelle und gibt die Bedingungen, unter denen sie ausgenutzt werden kann, und die möglichen Auswirkungen auf ein anfälliges System an. Abgesehen von dieser Beschreibung (und dem CVSS-Basis-Score) existieren jedoch noch viele Fragen, die durch CVSS nicht abgedeckt werden:

• Wer hat die Schwachstelle gefunden? War es der Software-Hersteller selbst, ein Sicherheitsforscher, der den Fehler gemeldet und auf einen Patch gewartet hat, oder ein böswilliger Akteur?
• Existiert ein öffentlich verfügbares Exploit? Oder mit anderen Worten: Gibt es leicht zugänglichen Code, um die Schwachstelle auszunutzen?
• Wie praktisch ist das Ausnutzen dieser Schwachstelle in Echtwelt-Szenarien?
• Existiert ein Patch? Deckt dieser alle betroffenen Versionen einer Software ab und welche Nebeneffekte können auftreten?
• Sollte das eigene Unternehmen die Schwachstelle selber schließen? Oder ist dafür eher ein Cloud-Dienst (SaaS) zuständig, bei dem sich der Anbieter automatisch um die Fehlerbehebung kümmert?
• Existieren Anzeichen über eine bekannte Ausnutzung in freier Wildbahn?
• Wenn keine Anzeichen vorhanden: Wie hoch ist die Wahrscheinlichkeit, dass Angreifer diese Schwachstelle in Zukunft ausnutzen werden?
• Welche spezifischen Systeme im eigenen Unternehmen sind dafür anfällig?
• Ist das Exploit für einen Angreifer praktisch zugänglich? Ein betroffenes System kann beispielsweise der Webserver eines Unternehmens sein, auf den jedermann online zugreifen kann. Ein Gegenbeispiel wäre ein anfälliger Büro-Drucker, der nur physisch mit einem einzelnen Computer ohne Netzwerkzugriff verbunden ist und von außen quasi nie erreicht werden kann. Ein komplexeres Beispiel könnte eine Business-Anwendung sein, die eine Software-Komponente nutzt, in einer deren Methoden sich eine Schwachstelle befindet. Trotz der Nutzung dieser Software kann es sein, dass die Business-Anwendung die betroffene Methode niemals aufruft.
• Was wären die Folgen, wenn die anfälligen Systeme kompromittiert würden?
• Was würde solch ein Vorfall dem Unternehmen finanziell kosten?

All diese Faktoren haben maßgeblichen Einfluss auf die Entscheidung, wann und wie eine Schwachstelle zu beheben ist – oder sogar, ob eine Schwachstelle überhaupt behoben werden muss.

Wie kann man mehr aus CVSS herausholen? RBVM hat die Antwort!

Viele Faktoren, die innerhalb der Grenzen von CVSS oft nur schwer zu erklären sind, stehen im Mittelpunkt eines beliebten Ansatzes, der als risikobasiertes Schwachstellenmanagement (Risk-Based Vulnerability Management – RBVM) bekannt ist.

RBVM steht für einen ganzheitlichen, zyklischen Prozess mit mehreren Schlüsselphasen, die sich regelmäßig wiederholen:

• Inventarisierung aller IT-Assets des eigenen Unternehmens. Das schließt alles von Computern, Servern und Software bis hin zu Cloud-Diensten und IoT-Geräten mit ein.
• Priorisieren der Assets nach Wichtigkeit und Identifizieren der „Crown Jewels“.
• Untersuchung der Assets auf bekannte Schwachstellen.
• Anreichern der Informationen zu Schwachstellen. Dazu gehört das Verfeinern von CVSS-B- und CVSS-BT-Scorings, das Einbeziehen von Bedrohungsdaten und die Einschätzung der Wahrscheinlichkeit einer Ausnutzung. Zwei beliebte Tools, mit denen die Möglichkeit einer Ausnutzung beurteilt werden kann, sind EPSS (ein weiteres FIRST-Scoring für die meisten Schwachstellen, das eine prozentuale Wahrscheinlichkeit der Ausnutzung angibt) und Consulting-Datenbanken wie CISA KEV, die Informationen über Schwachstellen enthalten, die von Angreifern aktiv ausgenutzt werden.
• Definition des Business-Kontexts: Einschätzen und Verstehen der potenziellen Auswirkungen eines Exploits auf verwundbare Systeme im eigenen Unternehmen unter Berücksichtigung ihrer Konfigurationen und Verwendung.
• Bestimmen, wie die Schwachstelle entweder durch Patches oder Kompensationsmaßnahmen neutralisiert werden kann.
• Der interessanteste Teil: die Bewertung des Geschäftsrisikos und das Festlegen von Prioritäten auf der Grundlage aller gesammelten Daten. Die Schwachstellen mit den höchsten Wahrscheinlichkeiten einer Ausnutzung und den größten möglichen Auswirkungen auf die wichtigsten IT-Assets werden priorisiert. Zur Einstufung der Schwachstellen kann entweder der CVSS-BTE (wobei alle gesammelten Daten in der Environmental-Komponente integriert werden) oder eine alternative Scoring-Methode verwendet werden. Auch regulatorische Aspekte nehmen Einfluss auf die Priorisierung.
• Festlegen von Fristen für die Behebung jeder Schwachstelle basierend auf der Risikostufe und betrieblichen Erwägungen, z. B. dem günstigsten Update-Zeitpunkt. Wenn keine Updates oder Patches verfügbar sind oder deren Implementierungen neue Risiken und Schwierigkeiten bergen, werden anstelle von direkten Korrekturen zumindest Kompensationsmaßnahmen ergriffen. Es kann vorkommen, dass die Kosten für das Schließen einer Schwachstelle das mit ihr verbundene Risiko überwiegen, sodass man zu dem Schluss kommt, diese Schwachstelle gar nicht erst zu beheben. In solchen Fällen nimmt ein Unternehmen die Risiken, die mit der Ausnutzung der Schwachstelle einhergehen, bewusst in Kauf.

Zusätzlich zu dem oben Genannten, ist es wichtig, die Schwachstellenlandschaft und die IT-Infrastruktur des eigenen Unternehmens regelmäßig zu analysieren. Nach einer solchen Analyse sollte man Maßnahmen zur Stärkung der Cybersicherheit einleiten, durch welche die Ausnutzung ganzer Klassen von Schwachstellen verhindert wird oder durch die sich die Gesamtsicherheit bestimmter IT-Systeme erheblich erhöht. Diese Maßnahmen können beispielsweise die Mikrosegmentierung des Netzwerks, die Implementierung des Ansatzes der geringsten Berechtigungen und die Einführung strengerer Richtlinien für die Kontoverwaltung sein.

Ein richtig umgesetzter RBVM-Prozess trägt erheblich zur Reduzierung der Belastung der IT- und Sicherheitsteams bei. Diese nutzen ihre Zeit in solchen Umgebungen effektiver, da sie ihre Bemühungen in erster Linie auf Schwachstellen konzentrieren können, die eine echte Bedrohung für das Unternehmen darstellen. Einen Überblick über das Ausmaß dieser Effizienzsteigerungen und eingesparten Ressourcen bietet diese FIRST-Studie. Bei einer Priorisierung von Schwachstellen durch ausschließliche Nutzung von EPSS muss man sich nur auf 3% der Schwachstellen konzentrieren und erzielt gleichzeitig eine Effizienz von 65%. Im Gegensatz dazu erfordert eine Priorisierung nach CVSS-B die Behebung von 57% der Schwachstellen bei einer erschreckend niedrigen Effektivität von 4%. „Effizienz“ bezieht sich hier auf die erfolgreiche Behebung von Schwachstellen, die tatsächlich in freier Wildbahn ausgenutzt wurden.