Man muss nicht in der IT-Security arbeiten, um mit dem CVSS-Score in Kontakt zu kommen, mindestens jede*r Systemadministor*in, aber auch die meisten Entwickler*innen dürften schon einmal mit dem offenen Standard zur Schwachstellenbewertung und den abgeleiteten Kritikalitäten (Low, Medium, High, Critical) in Kontakt gekommen sein.
Allein 2022 wurden über 25.000 Schwachstellen mit einem CVE-Eintrag veröffentlicht. Alle fürs Patchen von Software Verantwortlichen stellt dies vor riesige Probleme. Wo fange ich an? Wie priorisiere ich, wenn es nicht möglich ist, alle Schwachstellen zu schließen?
Priorisierung muss her
Häufig lautet die Antwort: richten wir uns nach dem CVSS-Base-Score. Beispielsweise könnte der Entschluss lauten, nur Schwachstellen mit einer Kritikalität von High und Critical zu patchen oder nur alle Schwachstellen mit einem CVSS-Base-Score von 8.0-10.0. Alle anderen Schwachstellen werden ignoriert, es sei denn sie werden als “Beifang” eines Patchpaketes einer Schwachstelle mit höherer Kritikalität behoben.
Diese Herangehensweise birgt eine ganze Reihe von Problemen.
Selbst die CVSS-Spezifikation in der aktuellen Version 3.1 sieht neben dem Base-Score noch zwei Werte vor, die als Modifikatoren eingesetzt werden:
- Temporal Score: in diesen Wert geht der Reifegrad von ggf. vorhandenem Exploits, die zur Verfügung stehenden Patches bzw. Workarounds sowie die Zuverlässigkeit der Berichte bzw. Meldung der Schwachstelle ein
- Environmental Score: die Modifikatoren sind hier die Sicherheitsanforderungen der Umgebung sowie modifizierte Werte für den Basis-Score (z.B. da sich in der eigenen Umgebung durch zusätzliche oder fehlende Sicherheitsmaßnahmen Abweichungen zu Bewertungen im Base-Score ergeben)
Nicht so einfach…
Allein diese beiden Modifikatoren machen bereits klar, dass eine Arbeit allein mit dem statischen CVSS-Base-Score nie einer sich verändernden Welt bzw. einer individuellen Umgebung gerecht werden kann. Es macht nun mal einen Unterschied, ob ein Exploit nur ein theoretisches Konstrukt in einem akademischen Paper ist, oder ob es sich (fast) jede*r einen funktionierenden Exploit zusammenklicken kann. Ebenso wird eine Schwachstelle in einem Webserver im Regelfall kritischer bewertet werden, wenn der Webserver im Internet erreichbar ist, als bei einem Server, der nur einem begrenzten Nutzerkreis im Intranet zur Verfügung steht.
Gerade der Faktor eines leicht funktionierenden Exploits darf nicht unterschätzt werden. Die meisten Angreifer berücksichtigen auch Kosten und Nutzen bei ihrem Vorgehen. Einen komplett eigenen Exploit werden in den meisten Fällen nur von Staaten gesteuerte APT-Gruppen entwickeln. Für die meisten anderen Angreifer gibt es auch keine Notwendigkeit hierfür. Warum die Mühe machen das Türschloss zu knacken, wenn das Fenster weit offen steht?
Auch Threat Modelling ist ein relevanter Aspekt. Wenn man potentielle Angreifertypen und -gruppen kennt, kann man das Wissen über das Vorgehen dieser Gruppen (z.B. nach MITRE ATT&CK) für eine Priorisierung von Schwachstellen nutzen.
Andere Wege
Vulnerability Management Lösungen
Für mittlere bis große Unternehmen kann ein Weg ein Vulnerability Management Tools eines Herstellers sein. Wenn ein gut gepflegtes Asset-Inventory vorhanden ist und die Wichtigkeit von Systemen und den gespeicherten Daten mit den Schwachstellendaten sowie Threat-Intelligence kombiniert werden kann, erhält man eine Arbeitsbasis für eine Priorisierung der Schwachstellen und geht vielleicht erste Schritte hin zu einer weitgehenden Automatisierung des Schwachstellenmanagements.
Penetration Tests
Ein weiteres Hilfsmittel für besonders wichtige oder exponierte Umgebung kann ein Penetration Test sein. So können Schwachstellen priorisiert werden, die von einem Angreifer (leicht) entdeckt und ausgenutzt werden können. Pentests können natürlich kein Vulnerability Management ersetzen, es aber ergänzen oder Aufmerksamkeit für technische und prozessuale Schwachstellen erzeugen – und damit auch ggf. ein höheres Budget für IT-Sicherheitsmaßnahmen rechtfertigen.
Risikostufen für Schwachstellen nach BSI
Das deutsche Bundesamt für Sicherheit in der Informationstechnik hat zusammen mit CERTs ein Klassifizierungsschema für Schwachstellen entwickelt. Allerdings besticht der Entwurf nicht gerade durch Einfachheit und dürfte für Unternehmen, die keine größeren, spezialisierten Teams bereithalten, eher schwer in die Praxis umzusetzen sein.
Stakeholder-Specific Vulnerability Categorization (SSVC)
Die Cybersicherheitsagentur der US-Regierung (CISA) schlägt mit der Stakeholder-Specific Vulnerability Categorization (SSVC) ein Modell zur Priorisierung von Schwachstellen vor. Im Vergleich zum BSI-Entwurf besticht SSVC durch seine Einfachheit, insbesondere wenn man sich das zur Verfügung gestellte Entscheidungsdiagramm anschaut, das eine einfache Bewertung der Schwachstellen per Klick ermöglicht, auch wenn die Bewertung im aktuellen Entwicklungsstand vom Wortlaut teilweise sehr auf Regierungs- bzw. Kritische Infrastruktur bezieht.
Fazit
Schwachstellenpriorisierung ist alles andere als einfach. Ein wichtiger Aspekt bei der Priorisierung ist allerdings, dass Unternehmen wissen, welche Assets sie vorhalten und insbesondere, welche Assets besonders kritisch bzw. wichtig sind. Sind “die Hausaufgaben nicht gemacht” und liegt diese Information nicht vor, ist eine Priorisierung von Schwachstellen nahezu unmöglich.
Wer sinnvoll Schwachstellen bewerten will, kommt neben einem guten Asset-Inventory auch an weiteren Faktoren wie Exploitability, Threat Intelligence und Threat Modelling vorbei.
Wenn Sie Unterstützung im Bereich Vulnerability Management benötigen, zögern Sie nicht, uns anzusprechen. Mit unserer jahrelangen Erfahrung im Schwachstellen Management helfen wir Ihnen gerne weiter.
P.S.: wir planen die Veröffentlichung eines ausführlichen Beitrags zu den Faktoren, die für die Bewertung von Schwachstellen relevant sind. Sobald er veröffentlicht wurde, verlinken wir ihn hier ebenfalls.