Für viele ist CVSS der (einzige) Schlüssel
CVSS steht für Common Vulnerability Scoring System. Seit der Veröffentlichung durch FIRST (Forum for Incident Response and Security Teams) wird es industrieübergreifend verwendet, um das Risiko von Sicherheitslücken zu klassifizieren und zu priorisieren. Es basiert auf verschiedenen Metriken wie «Auswirkung», «Ausnutzbarkeit» und «Kontext berücksichtigen».
Die zentrale Schwachstelle von CVSS ist jedoch, dass es trotz seiner Granularität das effektive Risiko in einer bestimmten Umgebung nur unzureichend berücksichtigen kann. Kurz gesagt: Es kommt durchaus häufiger vor, dass eine Schwachstelle mit einem tiefen CVSS Score in der realen Umgebung tatsächlich ein wesentlich höheres unmittelbares Risiko darstellt, als eine Schwachstelle mit einem wesentlich höheren Score und umgekehrt. Die Folge sind zunehmend überforderte IT-Abteilungen und, damit einhergehend, das stete Risiko, eine Schwachstelle zu übersehen.
Wenn CVSS allein für eine Bewertung nicht ausreichend ist, stellt sich die Frage, was hier Abhilfe schaffen kann. Zunächst ist es wichtig, die Faktoren zu verstehen, die eine Schwachstelle ausmachen und vor allem, welche davon wir tatsächlich beeinflussen können. Das Risiko einer Schwachstelle wird hauptsächlich von drei Faktoren bestimmt: Erstens, dem Vorhandensein der Schwachstelle (Vulnerability) selbst; zweitens, einem Angreifer (Threat), der diese Schwachstelle ausnutzt; sowie, drittens, von der tatsächlichen Zugänglichkeit dieser Schwachstelle für einen Angreifer (genannt Exposure). Diese drei Faktoren lassen sich entsprechend auch in einer einfachen Formel darstellen.
Risiko = Vulnerability x Threat x Exposure
Trotz weiterhin enormer Anstrengungen von Herstellern bleiben Schwachstellen eine natürliche Begleiterscheinung der zunehmend vernetzten und digitalisierten Welt.
An der Zahl von auftretenden Vulnerabilities und den damit einhergehenden Threats können wir wenig ändern. Aber was ist mit der Exposure? In der Realität können wir tatsächlich nur einen Faktor wirkungsvoll beeinflussen, um das Risiko massgeblich zu senken: die Zugänglichkeit einer Schwachstelle.
Gemäss dem Rapid 7 Vulnerability Intelligence Report 2022 lag die durchschnittliche Zeitspanne zwischen dem Bekanntwerden und dem Ausnutzen einer Schwachstelle (TTKE = Time To Known Exploitation) bei 24.5 Tagen. Das klingt erst einmal noch nicht alarmierend, verbirgt aber den Fakt, dass etwas mehr als die Hälfte aller Schwachstellen bereits innerhalb der ersten Tage nach deren Veröffentlichung ausgenutzt wird (siehe Grafik):
Paradigmenwechsel: Stakeholder Specific Vulnerability Classification (SSVC)
Nicht zuletzt dieser Umstand hat die CISA im 2021 veranlasst, mit dem SSVC einen erweiterten Ansatz zu veröffentlichen. Die CISA Stakeholder-Specific Vulnerability Categorization (SSVC) stellt einerseits eine Methode sowie andererseits einen Leitfaden zur Priorisierung und Reaktion auf Schwachstellen in Bezug auf die jeweils spezifischen Gegebenheiten einer Organisation zur Verfügung. Ziel ist es, die Effizienz und Effektivität das Schwachstellenmanagements zu verbessern.
(State of) Exploitation |
Stellt fest, ob eine Schwachstelle zum gegebenen Zeitpunkt aktiv ausgenutzt wird. Diese Bewertung kann sich über die Zeit ändern. |
Technical Impact |
Entspricht weitgehend der Bewertung einer Schwachstelle, wie sie im CVSS gebräuchlich ist. Sie wird jedoch nicht allgemein, sondern im tatsächlichen Kontext ermittelt, das heisst, unter Berücksichtigung der Bedeutung und Abhängigkeiten einer Komponente im konkreten Umfeld. |
Automatability |
Bewertet, inwiefern es möglich ist, eine Schwachstelle durch automatisierte Prozesse zu erkennen bzw. auszunutzen. Je höher die Automatisierbarkeit, für einen Angreifer, desto grösser die Gefahr, welche von ihr ausgeht. |
Mission Prevalence |
Bewertet die Bedeutung des betroffenen Assets in Bezug auf kritische Geschäftsprozesse einer Organisation. |
Public Well-Being Impact |
Bewertet Schwachstellen auf ihren möglichen Einfluss auf die öffentliche Sicherheit und/oder Gesundheit. |
Mitigation Status |
Bewertet den Status der aktuellen Mitigation. Im Kontext der Risikoformel weiter oben bedeutet dies, dass die Schwachstelle zwar noch nicht behoben, aber die Exploitability reduziert ist. |
Track, Attend, Act
Das SSVC stellt zudem ein vereinfachtes Bewertungssystem für Schwachstellen zur Verfügung. Dieses ist weniger auf die technischen Aspekte, sondern mehr auf den Handlungsbedarf ausgelegt, den eine entsprechende Schwachstelle erfordert. Es unterscheidet dabei zwischen Schwachstellen, die im Rahmen des «normalen» Patch- und Update-Cycles adressiert werden (Track), sowie Schwachstellen, welche ausserhalb des üblichen Cycles angegangen werden (Attend bzw. Act).
Vulnerability Management ist gut – aber Resilient Design ist besser
Auch wenn es durchaus möglich ist, mit einer zielgerichteten Bewertung die Effizienz und Effektivität des Vulnerability Managements zu verbessern, bleibt es letztlich Symptombekämpfung. Wesentlich effektiver sind diejenigen Massnahmen, welche darauf abzielen, mehr Resilienz gegenüber Schwachstellen bereits im System mit zu berücksichtigen. Dabei zu erwähnen ist die Veröffentlichung der Principles and Approaches for Security by Design and Default, welche die CISA gemeinsam mit weiteren internationalen und europäischen Cyber-Behörden im April dieses Jahres veröffentlicht hat. Diese setzt primär bei den Herstellern von Hard- und Software an. Aber auch unsere IT-Architekturen haben einen massgeblichen Einfluss darauf, wie viele Ressourcen Unternehmen für die Behebung von Schwachstellen einsetzen müssen. Zero Trust bietet hierzu wesentliche Ansätze.
Mehr dazu finden Sie in unserer Trilogie zum Thema Zero Trust sowie im Beitrag zur Post-quantum sicheren Verschlüsselung.
Quellen:
- https://nvd.nist.gov/
- https://www.rapid7.com/info/vulnerability-intelligence-report-2022-edition/
- https://www.first.org/cvss/
- https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
- https://www.cisa.gov/sites/default/files/2023-04/principles_approaches_for_security-by-design-default_508_0.pdf