Die bei Sicherheitsüberprüfungen gefundenen Schwachstellen werden nach Möglichkeiten eingestuft. Dies kann beispielsweise in Bezug auf Schweregrad (Severity), Risiko, Eintrittswahrscheinlichkeit und Auswirkungen geschehen. Wir pflegen das Risiko mit den folgenden vier Abstufungen darzulegen:

CVSS Einführung

Die Einstufung von Schwachstellen kann sehr unterschiedlich ausfallen, je nachdem welche Aussage getroffen werden will und welche Metrik eingesetzt wird. Um diesem Problem entgegenzuwirken, wurde CVSS eingeführt. Das Common Vulnerability Scoring System ist darum bemüht eine vereinheitlichte formale Herleitung einer Einstufung zu ermöglichen. Dabei werden unterschiedliche Metrik-Gruppen verwendet:

• Base: Die grundlegende und allgemein gültige Einstufung der Schwachstelle.
• Temporal: Die über die Zeit variable Einstufung der Schwachstelle (z.B. Patch, Exploits, Würmer).
• Environmental: Die kundenspezifische und umgebungsabhängige Einstufung der Schwachstelle (z.B. Netzwerktopologie).

Die jeweiligen Einstufung der einzelnen Metrik-Gruppen werden aus verschiedenen Parametern berechnet. Zum Beispiel beihaltet der Base-Score die folgenden Eigeschaften:

• Exploitability Metrics
  • Access Vector (AV)
    • Local (L)
    • Adjacent Network (A)
    • Network (N)
  • Access Complexity (AC)
    • High (H)
    • Medium (M)
    • Low (L)
  • Authentication (Au)
    • Multiple (M)
    • Single (S)
    • None (N)
• Impact Metrics
  • Confidentiality Impact (C)
    • None (N)
    • Partial (P)
    • Complete (C)
  • Integrity Impact (I)
    • None (N)
    • Partial (P)
    • Complete (C)
  • Availability Impact (A)
    • None (N)
    • Partial (P)
    • Complete (C)

In erster Linie wollen wir uns mit diesem Base-Score auseinandersetzen und damit die Einschränkungen des Systems im Rahmen allgemeiner Sicherheitsüberprüfungen aufzeigen. Grundsätzlich gestaltet sich das Einstufen von ausnutzbaren Schwachstellen, die wir in unserer Metrik als High oder Emergency taxieren, relativ einfach:

Auswertungen ohne Score

Probleme treten jedoch dann auf, wenn Schwachstellen bewertet werden wollen, die keine echten ausnutzbaren Sicherheitslücken darstellen. Also all jene, die wir als Low (oder Medium) einstufen:

Es ist zu sehen, dass der CVSSv2 Base-Score für die ersten beiden Schwachstellen eigentlich 0.0 lauten müsste. Der Grund dafür ist, dass alle drei Impact Metrics auf None gesetzt werden. Der Exploitable Subscore beträgt zwar 8.6, aufgrund der fehlenden Impact Metrics wird dieser jedoch auf 0 zurückgesetzt. Die meisten Kunden werden einen solch niedrigen bzw. nicht-existenten Base-Score so verstehen (wollen), dass kein Risiko besteht. Dies ist jedoch nicht der Fall (ein Risiko >0 besteht immer).

Auswertungen plötzlich gleichwertig

Die Folge davon bei der Einstufung wäre, dass mindestens eine der Impact Metrics auf !=None – also Partial oder Complete – gesetzt wird. Der neue CVSSv2-Score gestaltet sich sodann wie folgt, wenn jeweils Confidentiality Impact auf Partial gesetzt wird:

Das Problem ist aber nun, dass die ersten beiden Schwachstellen ebenso mit 5.0 bewertet werden, wie die dritte Schwachstelle. Das Auslesen und Identifizieren eines Applikation-Banners ist aber offensichtlich schwerwiegender als Ping und Traceroute.

Berücksichtigen von Environmental

Abhilfe in diesem Fall, also das nachvollziehbare Abbilden der Realität, schaffen in diesem Fall nur, wenn der Base-Score um Temporal- und Environmental-Score erweitert werden:

Hierbei ist zu sehen, dass die Distanz zwischen den einzelnen Schwachstellen eher nachvollzogen werden kann. Das damit verbleibende Problem ist jedoch, dass Environmental- und Temporal-Einstufungen zusätzlichen Aufwand bedeuten. So kann der Base-Score für alle Schwachstellen berechnet und in verschiedene Projekte übertragen werden. Der Environmental-Score muss jedoch bei jedem Kunden neu berechnet werden. Und will man auch noch den Temporal-Score berücksichtigen, gilt es diesen regelmässig zu aktualisieren (z.B. wenn ein neuer Exploit verfügbar ist).

Verteilung, Lücken und Treppeneffekte

In einer statistischen Analyse haben wir untersucht, welche CVSS-Werte möglich sind. Die nachfolgende Grafik illustriet die Verteilung im Base-Score.

Insgesamt sind 730 unterschiedliche Base-Scores möglich. Der niedrigste ist 0 (27 Stück) und der höchste ist 10 (1 Stück). Und hier sticht schon die erste Auffälligkeit hervor. Und zwar ist der kleinste Base-Score grösser als 0 schon bei 0.8 festgesetzt.

In verschiedenen Bereichen gibt es kleinere Lücken. So gibt es zum Beispiel keine Base-Scores mit den Werten 0.9, 1.1, 1.6 und 2.0. Besonders am oberen Ende der Skala sind solche Lücken frappant. Dort fehlen zum Beispiel ganze Sub-Bereiche wie 9.1 bis 9.2 sowie 9.8 bis 9.9.

In ähnlicher Weise verhält es sich mit Treppeneffekten, die dann auftreten, wenn von gewissen Scores nur einer möglich ist, von anderen aber viele mehr. Die optisch eindrückliste Stufe findet sich bei 5.1 (1 Stück) zu 5.2 (17 Stück). Und später auch nochmal bei 6.8 (28 Stück).

Hierbei handelt es sich soweit nur um eine theoretische Betrachtung. Von praktischerem Nutzen ist die statistische Analyse, die auf cvedetails.com bereitgestellt wird. Hierbei werden sämtliche durch CVE dokumentierten Schwachstellen mit einem CVSS Base-Score versehen und statistisch untersucht, wie die Verteilung dessen aussieht.

Hierbei ist zu sehen, dass keine gleichmässige oder nachvollziehbare Verteilung zustande kommt. Gerade die enormen Einbrüche der Scores 3-4 und 8-9 irritieren. Diese Abweichungen können verschiedene Gründe haben. Einerseits kann es nunmal ein statistisches Merkmal der bisher gefundenen Schwachstellen sein, dass diese gerade weniger in diesen Bereichen eingestuft werden. Oder – was naheliegender ist – die Abstufung des CVSS Scoring Systems sieht sich nicht in der Lage, die aktuell katalogisierten Schwachstellen in gerechter Weise abzubilden. Serkan Özkan, der Betreiber von cvedetails.com, tendiert ebenfalls zu letzterem:

I think this question should be asked to the people that developed the equation. Maybe they should have made some more statistical analysis. (…) Some may argue that this distribution is caused by NVD scoring process. But I don’t think that’s the reason.

Fazit

Das Common Vulnerability Scoring System ist ein interessantes Hilfsmittel, welches bei der Einstufung von Sicherheitslücken helfen kann. Das richtige Einsetzen des Systems ist jedoch mit relativ viel Aufwand verbunden, der sich gerade bei breitflächigen Vulnerability Assessments wirtschaftlich nicht rechtfertigen lässt. Nur mit erheblichem Aufwand kann in diesem Bezug die gewünschte Qualität erreicht werden.

Da wir unsere Sicherheitsüberprüfungen mit einem datenbankbasierten Expertensystem umsetzen, können wir diese Aufwände minimieren. Durch das zentrale Speichern der Base- und Temporal-Scores und das dynamische Hinzufügen der Environmental-Scores wird es möglich, das Maximum zu erreichen. Aber auch wir pflegen uns aus den genannten Gründen in erster Linie auf unsere eigene Metrik oder die klassische Risikoeinstufung Eintrittswahrscheinlichkeit/Auswirkungen zu verlassen. In optionalen Severity Maps bieten wir den Kunden die Mölichkeit, einen direkten Vergleich der unterschiedlichen Vulnerability Scanner und Risikometriken anzustellen.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• http://nvd.nist.gov/cvsseq2.htm
• http://twitter.com/#!/mruef/status/10312038362390528
• http://www.cvedetails.com
• http://www.cvedetails.com/cvss-score-distribution.php
• http://www.first.org/cvss/cvss-guide.html
• http://www.first.org/cvss/cvss-guide.html#i2.1