CVSS Common Vulnerability Scoring System

Das Common Vulnerability Scoring System CVSS dient in der IT Security nicht nur der Klassifizierung des Schweregrads von Software-Schwachstellen. Dieses CVSS-Framework wird auch genutzt, um diese Schwachstellen zu charakterisieren und einheitlich zu einzuschätzen.

Lernen Sie dieses Common Vulnerability Scoring System CVSS verstehen und damit die Meldungen der NIST. Diese Meldungen sollten Sie als Hersteller (z.B. von Medizinprodukten) kontinuierlich überwachen, um Risiken für Ihre Produkte einschätzen und beherrschen zu können. Das hilft Ihnen, die gesetzlichen Vorgaben zu erfüllen.

1. Wie das Common Vulnerability Scoring System hilft, sichere Produkte zu entwickeln

a) IT-Sicherheitslücken einheitlich bewerten

Vulnerability Scores klassifizieren die Art und Schwere von Software-Sicherheitslücken (Vulnerabilities) in der IT Security. Damit verfügen verschiedene Parteien (z.B. Hersteller, Sicherheitsforscher, benannte Stellen, Behörden, Penetration-Tester) über eine einheitliche Definition der Schweregrade.

b) Inputs für die Risikoanalyse liefern

Die Scores sind allerdings noch kein(!) Maß für die Risiken im Sinne der ISO 14971, die von einer kompromittierbaren Software ausgehen.

• Vielmehr helfen die Scores abzuschätzen, wie und wie wahrscheinlich sich eine Software nicht spezifikationsgemäß verhalten wird.
• Das wiederum erlaubt eine Abschätzung, wie und wie wahrscheinlich sich das Produkt nicht spezifikationsgemäß verhält.
• Und das wiederum erlaubt Schlüsse darauf, wie hoch die Risiken (Wahrscheinlichkeit und Schweregrad von Schäden) für Patienten sind.

Die Scores sind somit hilfreich, geeignete Maßnahmen zu ergreifen und damit sichere Produkte zu entwickeln.

c) Schwachstellen und IT-Sicherheitslücken kommunizieren (Interoperabilität)

Schwachstellen sind nicht nur über deren Score, sondern auch über weitere Attribute charakterisiert:

• Eindeutige ID der Schwachstelle
• Betroffenes Produkt (z.B. Betriebssystem, Bibliothek)
• Betroffene Version des Produkts
• Problemtyp
• Beschreibung der Schwachstelle
• Status
• Datum der initialen Meldung
• Datum der letzten Überarbeitung
• Referenzen

Die eindeutige Nummerierung der Schwachstelle erfolgt über die CVE ID. CVE steht für Common Vulnerabilities and Exposure. Dieses Nummernschema verwendet auch die National Vulnerability Database (NVD) des NIST (s. Abb. 2).

Als Austauschformat dient beispielsweise das XML-basierte Format, wie es das Common Vulnerability Reporting Framework (CVRF) spezifiziert. Die NIST nutzt ein anderes Format und speichert andere Attribute. Das erschwert Interoperabilität etwas. Zum Glück verweisen die beiden „Datenbanken“ (CVE und NIST) bei den jeweiligen Einträgen aufeinander (s. Abb. 2).

2. Welche Metriken einfließen und wie sich die Scores berechnen

Das Common Vulnerability Scoring System kennt mehrere Scores, die sich sogar gegenseitig beeinflussen:

• Base Metric Scores
• Temporal Metric Scores
• Enviriomental Metric Scores

Wenn eine Schwachstelle neu entdeckt wurde, sind meist nur die „Base Score Metrics“ bekannt (in Abb. 3 mit rotem Hintergrund markiert).

Die Scores können jeweils Werte zwischen 0 und 10 (höchste Verwundbarkeit, höchster Schweregrad) annehmen.

a) CVSS Base Score

Der CVSS „Base Score“ berechnet sich aus den „Base Score Metrics“. Zu diesen Metriken zählen:

• Attack Vector: Diese Metrik gibt an, wie „nah“ ein Angreifer am Objekt sein muss. Bedarf es im einen Extrem eines physischen Zugriffs (AV:P)? Oder ist das Objekt im anderen Extrem über das Netzwerk angreifbar?
• Attack Complexity: Wie leicht kommt der Angreifer ans Ziel? Liegt das innerhalb seiner Kontrolle?
• Privileges Required: Braucht der Angreifer bereits Privilegien (Autorisierung), bevor er seinen Angriff ausüben kann? Wenn das der Fall ist, ist der Score niedriger, andernfalls höher.
• User Interaction: Muss erst noch ein Benutzer handeln, damit der Angreifer das Ziel erreicht? Wenn der Benutzer z.B. erst einen Link anklicken muss, wäre der Wert „required“ (UI:R).
• Scope: Der Scope beschreibt, ob die Auswirkungen eines Angriffs „nur“ die verwundbare Komponente oder andere Komponenten betrifft. Im letzteren Fall („Changed“ S:C) erhöht sich der Scope Score den Base Score, falls letzterer nicht bereits den Maximalwert von 10 erreicht hat.
• Confidentiality Impact: Diese Metrik gibt an, wie hoch der Angriff die Vertraulichkeit beeinträchtigt. Ein Wert von „High“ (C:H) bedeutet, dass die Vertraulichkeit vollständig verloren wird.
• Integrity Impact: Analog beschreibt diese Metrik den Einfluss auf die Integrität der Daten. Wenn beispielsweise der Angreifer alle Dateien modifizieren könnte, wäre der Impact auf „high“ zu setzen (I:H).
• Availability Impact: Auch dieses Maß gleicht sehr den anderen „Impact Metrics“: Falls es dem Angreifer gelingt oder gelingen könnte, die Verfügbarkeit der Komponente zu unterbinden, sodass man nicht mehr auf sie zugreifen kann, wäre das maximale Wert „high“ (A:H) erreicht.

Die Berechnung erfolgt nach einer Formel, die Sie beispielsweise für den Angriffsvektor „AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H“ hier finden. Die Bedeutung dieses Vektors erläutert die Abbildung 4.

Im konkreten Fall nimmt der Base Score den Wert 8,8 an (s. Abb. 5).

b) Temporal Score

Der Tempoaral Score ist ein Maß dafür, wie gut die Schwachstelle zum aktuellen Zeitpunkt ausgenutzt werden kann, z.B. weil es bereits fertige Exploit Kits gibt, was den Score erhöhen würde. Existierende Patches hingegen würden ihn erniedrigen.

• Exploit Code Maturity (E): Diese Metrik gibt an, wie leicht die Schwachstelle mit Hilfe von Exploit Kits ausgenutzt werden kann. Sie ist auch ein Maß für die „Güte und Usability“ dieser Exploits.
• Remediation Level (RL): Der Remediation Level ist hingegen eher ein Maß für die Güte der Gegenmaßnahme, z.B. in Form eines Software Patches.
• Report Confidence (RC): Diese Metrik gibt an, wie sicher es ist, dass die Schwachstelle tatsächlich existiert. Die höchsten Werte für den „Temporal Score“ erreicht man, wenn man die Werte auf „Confirmed“ bzw. auf „Not Defined“ setzt.

c) Environmental Score

Die „Environmental Metric Group“ umfasst vordergründig die meisten Metriken. Es sind letztlich aber nur die bereits bekannten Metriken, die für den konkreten Anwendungskontext einer Firma oder eines Systems bestimmt werden. D.h., diese Werte legt nicht das NIST fest, sondern der Analyst für einen spezifischen Kontext, z.B. ein Krankenhaus mit einer bestimmten Infrastruktur und bestimmten Anforderungen an die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Informationstechnik. Sprich: an die IT-Sicherheit.

3. Wie die Vulnerability Scores und das Risikomanagement zusammenspielen

a) Die Scores sind kein Maß für Risiken

„CVSS Measures Severity, not Risk“ betont sogar der offizielle „User Guide“. Das stimmt für Medizinprodukte in einer weiteren Hinsicht:

Der Scores sind eher ein Maß für die Wahrscheinlichkeit, dass eine Komponente kompromittiert wird und sich daher nicht spezifikationsgemäß verhält. Sie sind weder ein Maß für die Wahrscheinlichkeit noch den Schweregrad von (physischen) Schäden. Und daher kein Maß für das Risiko im Sinne einer ISO 14971.

b) Die Scores helfen, Risiken zu bewerten

Allerdings bieten die Scores eine Metrik, um die Wahrscheinlichkeit von Schäden bzw. Systemfehlverhalten besser abzuschätzen (s. auch Abb. 1). Besonders die Anpassung dieser Metriken über die „Environmental Metrik Group“ – d.h. den spezifischen Kontext – hilft bei dieser Abschätzung.

c) Die Scores in der „Post-Market Phase“

Das CVSS hat für Hersteller besonders in der „Post-Market Phase“ eine hohe Bedeutung: Die Hersteller müssen die Meldungen über Schwachstellen kontinuierlich nachverfolgen und entscheiden, ob Maßnahmen notwendig sind. Genau bei dieser Entscheidung und bei der Priorisierung von Maßnahmen unterstützen die Scores:

Ein Produkt mit einer Schwachstelle, die nur bei physischem Zugriff auf das Produkt ausnutzbar ist, hat offensichtlich nicht die gleiche Priorität wie ein Produkt, das aus der Ferne über das Netzwerk ohne das Zutun eines Anwenders angegriffen werden kann.

Auditoren und Inspektoren werden bei Prüfungen die Schwachstellen mit dem höchsten Score auswählen, um zu überprüfen, ob der Hersteller zeitnah und wirksam die Schwachstelle erkannt und beseitigt hat. Die gesetzeskonforme Kommunikation der Maßnahmen an die Anwender und ggf. Behörden ist Gegenstand dieser Prüfungen.

d) Vulnerabilities in der Risikomangementakte

Es ergibt keinen Sinn, jede gemeldete Schwachstelle in der „Risikotabelle“ zu dokumentieren. Diese würde damit völlig überfrachtet. Allerdings sollten die Hersteller für jede dieser Schwachstellen das Folgende prüfen:

1. Vollständigkeit der analysierten Komponenten
   Das Fehlverhalten der betroffenen Komponente wird in der Risikotabelle bereits analysiert. Andernfalls wäre das nachzutragen. Als Methode zur Risikoanalyse bietet sich die FMEA an.
2. Korrektheit der geschätzten Wahrscheinlichkeiten
   Die in der Risikotabelle abgeschätzten Wahrscheinlichkeiten stimmen mit den tatsächlichen Ereignissen und der Bewertung durch das CVSS überein. Andernfalls sind diese zu korrigieren und damit die Risiken neu zu bewerten.
3. Korrektheit des antizipierten Fehlverhaltens
   Das Fehlverhalten der Komponente, das durch die Schwachstelle entstehen kann, wird in der Risikotabelle korrekt bewertet. Beispielsweise könnte es sein, dass der Hersteller bereits erkannt hat, dass die Komponente bei einem Cyberangriff verfälschte Daten zur Verfügung stellt (Integritätsproblem), aber nicht betrachtet hat, dass der Angriff ein Memory-Leak verursachen kann, der das ganze System zum Abstürzen bringt (Verfügbarkeitsproblem). Auch das gälte es in der Risikotabelle zu ergänzen und die Risiken neu zu bewerten.

e) Verfahrens- oder Arbeitsanweisungen

Somit ist es sinnvoll, in zwei Schritten und damit ggf. sogar mit zwei Arbeits- oder Verfahrensanweisungen zu operieren:

1. Die erste Anweisung enthält eine Beschreibung, wie bei der o.g. Analyse vorgegangen werden muss. Sie sollte für jede Schwachstelle einen kurzen schriftlichen Hinweis verlangen, ob die bisherige Risikoanalyse alles abdeckt. Falls ja, genügt die Referenz auf die „Risk ID“; falls nein, wäre es ein Hinweis auf die Änderung der Risikomanagementakte. Diese Beschreibung ist spezifisch für die IT-Sicherheit.
2. Die zweite Anweisung liefert eine Vorgabe, wie neue oder geänderte Risiken in der Risikomanagementakte zu dokumentieren sind. Diese Vorgabe ist weitgehend unspezifisch für die IT-Sicherheit.

4. CVSS bei Medizinprodukten

Die MITRE Cooperation hat einen Leitfaden veröffentlicht, der Herstellern bei der Festlegung der Scores speziell bei Medizinprodukten helfen soll.

Der Leitfaden nennt für jede der oben beschriebenen Metriken Beispiele, Kommentare und Handlungsanweisungen, z.T. in Form von Leitfragen und Entscheidungsbäumen (s. Abb. 6).

PII in obiger Abbildung steht für „personally identifiable information“, PHI für „protected health information“. Ebenfalls vom MITRE stammt die folgende Präsentation zu den CVSS im Kontext von Medizinprodukten.

Danke an Thomas Schulze für den Hinweis auf diese Unterlagen.

5. Fazit

a) Schlussfolgerungen

Hersteller von Medizinprodukten, die Software enthalten oder Software sind, müssen die Datenbanken mit den Schwachstellen (z.B. NIST) kontinuierlich überwachen. Um die dort publizierten Meldungen einordnen zu können, ist es unerlässlich, die Metriken des Common Vulnerability Scoring Systems zu verstehen.

Es gibt manchmal Tausende Meldungen pro Monat; diese lassen sich sinnvoll nur noch automatisiert überwachen.

Wie verwundbar ein System (z.B. ein Medizinprodukt) ist, kann das Common Vulnerability Scoring System CVSS nur bedingt bewerten. Hier müssen Hersteller den spezifischen Kontext und damit die „Environmental Metric Group“ betrachten. Welche Werte diese Metriken annehmen, das bestimmen beispielsweise die konkrete Systemarchitektur und der klinische Kontext.

b) Aufgaben

Damit ergeben sich für die Hersteller folgende Aufgaben:

1. Den klinischen Kontext in der Zweckbestimmung und den Begleitmaterialien präzise festlegen. Das ist auch eine Forderung der MDR.
2. Die Anforderungen an die IT-Sicherheit des Produkts ableiten und eine Systemarchitektur entwerfen, die möglichst inert gegen Cyber-Angriffe ist. Bei beidem hilft der kostenlose Leitfaden IT-Sicherheit, den die benannten Stellen inzwischen übernommen haben.
3. Komponenten wählen, deren Schwachstellen vom Hersteller möglichst schnell behoben werden.
4. Post-Market Surveillance Plan für jedes Produkt erstellen, der u.a. festlegt, wie der Hersteller abhängig vom CVSS auf die Meldungen reagiert.
5. SOP zur Post-Market Surveillance (PMS) erstellen und überarbeiten, die u.a. genau diese Maßnahmen fordert oder beschreibt. Diese SOP sollte die unter 3.e) genannten Verfahrens- bzw. Arbeitsanweisungen enthalten oder referenzieren.
6. IT-System aufsetzen, das automatisiert Meldungen über Schwachstellen sammelt (oder Post-Market Radar nutzen, das zudem weitere Informationsquellen auswertet und damit den Herstellern viel Arbeit bei der PMS abnimmt).

---

Änderungshistorie

• 2019-11: Erste Version des Beitrags
• 2021-02: Hinweis zur Übersetzung des Begriffs „Vulnerability“ ergänzt. Mindmap korrigiert (Scope-Score dem Impact zu geordnet)