{"id":32454,"date":"2025-08-03T11:00:06","date_gmt":"2025-08-03T09:00:06","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=32454"},"modified":"2025-08-04T10:44:55","modified_gmt":"2025-08-04T08:44:55","slug":"cvss-rbvm-vulnerability-management","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/cvss-rbvm-vulnerability-management\/32454\/","title":{"rendered":"Von CVSS zu RBVM: Schwachstellen richtig priorisieren"},"content":{"rendered":"

Bei einem ersten Blick auf das CVSS<\/u><\/a> (Common Vulnerability Scoring System) k\u00f6nnte man denken, dass es sich um das perfekte Tool f\u00fcr die Untersuchung und Priorisierung von Schwachstellen handelt. Demnach ist ein h\u00f6heres Scoring gleichbedeutend mit einer kritischeren Schwachstelle. Leider funktioniert dieser Ansatz in der Realit\u00e4t nicht so ganz. Jedes Jahr steigt die Anzahl an Schwachstellen mit hohen CVSS-Scorings. F\u00fcr Sicherheitsteams ist es gar nicht zu schaffen, diese alle rechtzeitig zu beheben. Gleichzeitig wird der Gro\u00dfteil dieser Schwachstellen aber auch nie durch Angriffe in der realen Welt ausgenutzt. Stattdessen nutzen Angreifer h\u00e4ufig eher weniger auff\u00e4llige Schwachstellen mit niedrigeren Scorings aus. Es gibt auch andere versteckte Fallstricke \u2013 von rein technischen Problemen wie widerspr\u00fcchliche CVSS-Bewertungen bis hin zu konzeptionellen Problemen wie fehlendem Business-Kontext.<\/p>\n

Diese sollte man nicht unbedingt als konzeptuelle M\u00e4ngel 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.<\/p>\n

CVSS-Widerspr\u00fcche<\/h2>\n

Es kann durchaus vorkommen, dass ein und dieselbe Schwachstelle je nach verf\u00fcgbarer 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\u00f6nnen sich \u00fcber die Gefahr, die von der Ausnutzung des Fehlers ausgeht, durchaus uneinig sein. So existieren m\u00f6glicherweise unterschiedliche Vorstellungen dar\u00fcber, mit welchen Berechtigungen eine betroffene Anwendung in freier Wildahn ausgef\u00fchrt wird oder ob sie mit dem Internet kommuniziert. Ein Software-Hersteller kann f\u00fcr eine Einsch\u00e4tzung beispielsweise die von ihm empfohlenen Best\u00a0Practices zu Grunde legen. Ein Sicherheitsforscher wiederum ber\u00fccksichtigt m\u00f6glicherweise die Anwendungskonfigurationen so, wie sie in realen Unternehmen tats\u00e4chlich auftreten. Je nach Schwerpunkt eines Forschers sch\u00e4tzt einer die Komplexit\u00e4t des Exploits vielleicht als hoch ein, ein anderer eher als gering. Und so eine Situation ist mitnichten eine Seltenheit. Eine Studie von Vulncheck<\/a> aus dem Jahr\u00a02023 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\u00fcchlich waren.<\/p>\n

H\u00e4ufige Anwendungsfehler von CVSS<\/h2>\n

Bereits seit \u00fcber einem Jahrzehnt setzt sich FIRST<\/a> f\u00fcr die methodisch korrekte Anwendung von CVSS ein. Dennoch machen Organisationen, die CVSS-Scorings in ihre Prozesse zum Schwachstellen-Management einflie\u00dfen lassen, nach wie vor typische Fehler:<\/p>\n

    \n
  1. Verwendung des CVSS-Basis-Scores als prim\u00e4ren Risikoindikator. CVSS gibt den Schweregrad einer Schwachstelle an \u2013 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\u00df angelegter Ransomware-Angriff die Folge einer scheinbar harmlosen Schwachstelle mit einem CVSS-Score von 6 sein.<\/li>\n
  2. Anwendung des CVSS-Basis-Scores ohne Ber\u00fccksichtigung der Threat\/Temporal- und Environmental-Metriken. Die Verf\u00fcgbarkeit von Patches, \u00f6ffentlichen Exploits und Kompensationsma\u00dfnahmen hat einen gro\u00dfen Einfluss darauf, wie und mit welcher Dringlichkeit eine Schwachstelle geschlossen werden sollte.<\/li>\n
  3. Ausschlie\u00dfliches Beheben von Schwachstellen oberhalb eines bestimmten Scorings-Grenzwerts. Dieser Ansatz wird manchmal von Regierungen oder branchennahen Aufsichtsbeh\u00f6rden eingefordert (\u201eAller Schwachstellen mit einem CVSS-Scoring gr\u00f6\u00dfer gleich\u00a08 sind innerhalb eines Monats zu beheben\u201c). Das Resultat davon ist, dass Cybersicherheitsteams mit einer st\u00e4ndig wachsenden Arbeitsbelastung konfrontiert werden, deren Abarbeitung die Infrastruktur aber nicht wirklich sicherer macht. Die Anzahl der j\u00e4hrlich identifizierten Schwachstellen mit hohem CVSS-Scoring hat in den letzten 10\u00a0Jahren stark zugenommen<\/a>.<\/li>\n
  4. Anwenden des CVSS-Scorings zur Vorhersage der Ausnutzungswahrscheinlichkeit. Hier sollte man eher keinen Zusammenhang sehen: gerade mal 17\u00a0% der kritischen Schwachstellen<\/a> werden jemals wirklich f\u00fcr Angriffe ausgenutzt.<\/li>\n
  5. Alleiniges Verwenden des CVSS-Scorings. Die standardisierte Vektorzeichenfolge wurde in CVSS eingef\u00fchrt, damit die Sicherheitsexperten die Details einer Schwachstelle verstehen und deren Auswirkungen auf die Beschaffenheiten ihrer eigenen Organisation kalkulieren k\u00f6nnen. CVSS\u00a04.0 wurde speziell \u00fcberarbeitet, um den eigenen Business-Kontext mithilfe zus\u00e4tzlicher Metriken einfacher in die Berechnung einzubeziehen. Jegliche Bem\u00fchungen, ein rein auf numerischen Scorings basierendes Schwachstellen-Management zu etablieren, sind weitestgehend ineffektiv.<\/li>\n
  6. Ignorieren weiterer Informationsquellen. Es reicht nicht aus, sich nur auf eine einzige Schwachstellendatenbank zu verlassen und CVSSs zu analysieren. Wenn Informationen zu verf\u00fcgbaren Patches, funktionierenden Proof-of-Concepts und bekannten F\u00e4llen einer realen Ausnutzung fehlen, erschwert dies die Entscheidung, wie Schwachstellen geschlossen werden sollen.<\/li>\n<\/ol>\n

    Was CVSS \u00fcber eine Schwachstelle verschweigt<\/h2>\n

    CVSS ist zwar der Industriestandard f\u00fcr die Beschreibung des Schweregrades einer Schwachstelle und gibt die Bedingungen, unter denen sie ausgenutzt werden kann, und die m\u00f6glichen Auswirkungen auf ein anf\u00e4lliges System an. Abgesehen von dieser Beschreibung (und dem CVSS-Basis-Score) existieren jedoch noch viele Fragen, die durch CVSS nicht abgedeckt werden:<\/p>\n