CVSS liefert numerische Vulnerability-Severity-Ratings, wird aber häufig missverstanden. Lerne was CVSS tatsächlich misst und wo es Schwächen hat.
Das Common Vulnerability Scoring System versucht, konsistente Severity-Ratings für Security-Vulnerabilities zu liefern. In der Praxis werden CVSS-Scores häufig missverstanden und missbraucht. Dieser Guide erklärt, was CVSS tatsächlich misst und wo es Schwächen hat.
CVSS bietet einen numerischen Score von 0 bis 10, der Vulnerability-Severity repräsentiert. Die aktuelle Version, CVSSv3.1, berechnet diesen Score aus acht Base-Metriken. Diese Metriken decken ab, wie die Vulnerability exploited werden kann (Attack Vector, Attack Complexity, Privileges Required, User Interaction Required), was der Impact ist (Confidentiality, Integrity, Availability), und ob die Vulnerability Ressourcen jenseits ihres unmittelbaren Scope beeinflussen kann.
Die Metriken fließen in eine Formel ein, die den Base Score produziert. Die Formel ist öffentlich dokumentiert, obwohl wenige Leute Scores manuell berechnen. Die meisten nutzen automatisierte Calculator, die von NIST oder Vendors bereitgestellt werden.
CVSS-Scores mappen zu Severity-Ratings. Scores von 0.1 bis 3.9 sind Low. Scores von 4.0 bis 6.9 sind Medium. Scores von 7.0 bis 8.9 sind High. Scores von 9.0 bis 10.0 sind Critical. Diese Ranges sind arbiträr, aber weit adoptiert.
Ein Score von 6.9 und 7.0 könnte minimalen praktischen Unterschied haben, aber sie kreuzen die Medium/High-Boundary. Organisationen, die Score-Thresholds für Priorisierung nutzen, müssen diese Arbitrarität verstehen. Die Boundary zwischen Kategorien repräsentiert keine fundamentale Änderung in Vulnerability-Natur.
Jenseits des Base Scores beinhaltet CVSS Temporal und Environmental Metrics, die Organisationen nutzen können, um Scores anzupassen. Temporal Metrics reflektieren Faktoren, die sich über Zeit ändern, wie Exploit-Availability, Remediation-Status und Confidence im Report. Environmental Metrics lassen Organisationen Scores basierend auf ihrer spezifischen Umgebung anpassen, wie kritisch das betroffene System ist oder welche compensating Controls existieren.
In der Praxis nutzen die meisten Organisationen nur Base Scores. Temporal und Environmental Scores zu berechnen erfordert Effort, den wenige Teams investieren. Base Scores sind readily available von Vendors und Vulnerability-Datenbanken. Custom Scoring erfordert Security-Expertise und Zeit, die vielen Organisationen fehlen.
CVSS misst Vulnerability-Severity isoliert. Es berücksichtigt nicht, ob das vulnerable System internet-facing ist, wie viele Systeme betroffen sind, ob compensating Controls existieren, den Wert von Daten auf dem System oder das Threat Model deiner Organisation. Eine CVSS 9.8 Vulnerability in einem isolierten Lab-System könnte Low Risk für deine Organisation sein. Eine CVSS 5.0 Vulnerability in deinem Authentication-System könnte critical sein.
Scores sind nicht direkt vergleichbar über Vulnerability-Typen. Ein CVSS 7.5 in einer Web-Application ist nicht notwendigerweise äquivalent zu einem CVSS 7.5 in einem Operating-System-Kernel. Das Scoring berücksichtigt verschiedene Faktoren, und praktische Exploitation-Difficulty variiert signifikant.
Hohe Scores bedeuten nicht immer einfache Exploitation. Eine Vulnerability könnte CVSS 9.0 scoren, weil sie hohen potentiellen Impact hat, selbst wenn Exploitation extensive Preconditions erfordert, die in der Praxis selten präsent sind. Der Score reflektiert, was passieren könnte, wenn exploited, nicht wie wahrscheinlich Exploitation ist.
Die Attack-Vector-Metrik verursacht häufige Scoring-Errors. Network bedeutet, die Vulnerability ist remote über ein Netzwerk exploitierbar ohne Preconditions. Das ist der Worst Case für Exploitability und generiert die höchsten Scores.
Adjacent erfordert, dass der Angreifer auf demselben Netzwerk-Segment ist. Sie müssen auf demselben VLAN oder WiFi-Network sein. Das ist nicht remote über das Internet exploitierbar, was Risk für viele Organisationen signifikant reduziert.
Local erfordert lokalen Zugriff auf das vulnerable System. Der Angreifer muss bereits einen Foothold haben, entweder durch physischen Zugriff oder vorherige Compromise. Physical erfordert physischen Zugriff auf das vulnerable Device selbst.
Ich sehe regelmäßig Scores, die lokale Vulnerabilities als network exploitable klassifizieren, was den Severity-Score dramatisch aufbläst und das tatsächliche Risk misrepräsentiert.
Privileges Required adressiert, welche Privileges ein Angreifer auf dem Target-System braucht, bevor er die Vulnerability exploiten kann. None bedeutet, ein unprivilegierter Angreifer kann sie direkt exploiten. Low bedeutet, Basic-User-Privileges werden benötigt. High bedeutet, Administrative Privileges sind erforderlich.
User Interaction adressiert, ob Exploitation erfordert, dass ein Victim eine Aktion durchführt wie einen Link zu klicken oder eine Datei zu öffnen. None bedeutet, die Vulnerability kann ohne Victim-Interaction exploited werden. Required bedeutet, jemand muss etwas tun, damit Exploitation erfolgreich ist.
Diese sind unabhängige Metriken. Eine Vulnerability könnte keine Privileges brauchen, aber User-Interaction benötigen, wie viele Cross-Site-Scripting-Issues. Eine andere könnte hohe Privileges brauchen, aber keine User-Interaction, wie einige Local-Privilege-Escalation-Bugs.
Die Scope-Metrik beeinflusst Scores signifikant. Ein Scope Change bedeutet, die Vulnerability erlaubt einem Angreifer, Ressourcen jenseits des Security-Scope der vulnerable Component zu beeinflussen. Das klassische Beispiel ist ein Virtual-Machine-Escape, der einem Angreifer erlaubt, den Hypervisor und andere VMs zu impacten.
Die meisten Vulnerabilities involvieren keine Scope Changes. Nimm nicht an, dass sie das tun, nur weil der Impact signifikant ist. Scope Changes repräsentieren ein spezifisches technisches Szenario, wo Security-Boundaries gekreuzt werden.
Einige Vulnerabilities passen nicht gut zu CVSS. Denial-of-Service-Issues haben Availability-Impact, der von CVSS gecaptured wird, aber es unterscheidet nicht zwischen einem DoS, der einen Service einmal crashed, und einem, der permanent alle Ressourcen konsumiert und manuelle Intervention erfordert. Praktische Severity unterscheidet sich signifikant.
Information Disclosure bekommt Basic-Treatment. CVSS captured nicht, welche Information disclosed wird. Server-Version-Numbers zu exposen scored ähnlich wie User-Credentials zu exposen, obwohl das Risk sich dramatisch unterscheidet.
Logic Flaws mappen oft nicht gut zu CVSS-Kategorien. Ein Flaw, der Usern erlaubt, gratis Produkte zu bekommen, könnte niedrige CVSS-Scores durch die technischen Metriken haben, aber hohen Business-Impact. CVSS wurde nicht designed, um Business-Logic-Issues zu capturen.
Scores kommen von verschiedenen Quellen. NIST's National Vulnerability Database scored CVEs, obwohl mit signifikanter Verzögerung, die Wochen oder Monate sein kann. Vendors publizieren oft Scores beim Release von Security-Updates. Forscher könnten Scores berechnen, wenn sie Vulnerabilities melden. Dein eigenes Team kann Scores basierend auf deiner spezifischen Umgebung berechnen.
Verschiedene Parteien weisen manchmal verschiedene Scores derselben Vulnerability zu. Es gibt keinen einzelnen autoritativen Score. Der NVD-Score könnte vom Vendor-Score differieren, und beide könnten von deinem internen Assessment differieren.
Behandle CVSS als Input zu deinem Risk-Assessment, nicht als finalen Output. Nutze es, um Priorisierung zu informieren, aber automatisiere Remediation-Entscheidungen nicht solely basierend auf CVSS-Scores ohne Context zu berücksichtigen.
Berechne Base Scores konsistent für alle deine Vulnerabilities, um Vergleich zu ermöglichen. Adjustiere basierend auf Environmental Factors wie Exposure, compensating Controls und System-Criticality. Nutze Scores zum Kategorisieren und initial Priorisieren, aber reviewe High-Impact-Vulnerabilities unabhängig vom CVSS-Score. Einige kritische Issues scoren niedriger, als ihr tatsächliches Risk rechtfertigt.
Rejecte Findings nicht automatisch unterhalb eines bestimmten CVSS-Threshold. Behandle CVSS 7.0 nicht als fundamental verschieden von 6.9. Nimm nicht an, dass alle Critical Vulnerabilities sofortige Attention brauchen ohne deine spezifische Situation zu berücksichtigen. Ignoriere niemals Business-Context zugunsten von automatisiertem Scoring.
Einige Organisationen nutzen alternative Scoring-Systeme. SSVC (Stakeholder-Specific Vulnerability Categorization) fokussiert auf Decision-Making statt abstrakter Severity. EPSS (Exploit Prediction Scoring System) predicted die Probability, dass eine Vulnerability in the Wild exploited wird, basierend auf beobachteter Exploit-Activity. Einige Organisationen entwickeln interne Severity-Matrices, die Business-Faktoren inkorporieren.
Diese sind keine Replacements für CVSS. Sie sind Supplements, die CVSS-Limitations adressieren. CVSS bleibt useful für standardisierte Kommunikation über Vulnerability-Severity, selbst wenn es nicht dein einziger Input zu Risk-Entscheidungen sein sollte.
CVSS v4.0 wurde 2023 released, aber Adoption bleibt langsam. Es fügt Metriken für Operational Technology, Safety Impacts hinzu und handhabt komplexe Attack-Chains besser. Aber die meisten Organisationen nutzen noch CVSSv3.1, weil das ist, was Vendors und Datenbanken bereitstellen.
Wenn v4.0 Standard wird, bleiben die Core-Prinzipien dieselben. Es ist eine Severity-Metrik, keine Risk-Metrik. Dieselben Cautions über Overreliance und Need für contextual Assessment gelten.
Wenn du Vulnerabilities scorest, die du entdeckst, err auf der Seite von Objektivität. Scores zu inflaten, um Importance zu betonen, backfired, wenn Stakeholder lernen, deine Assessments zu discounten. Nutze den offiziellen CVSS-Calculator statt zu raten. Die Scoring-Rubric hat Nuancen, die nicht obvious sind ohne sorgfältiges Lesen.
Dokumentiere dein Reasoning für jede Metrik. "Network Attack Vector, weil es auf dem Intranet exposed ist" erklärt dein Denken, falls jemand den Score später hinterfragt. Diese Dokumentation proves wertvoller als der Score selbst für das Verstehen des tatsächlichen Risk.
CVSS captured nicht Exploit-Difficulty jenseits Basic-Complexity-Metriken. Es berücksichtigt keine Attack-Prerequisites jenseits von Privileges und User-Interaction. Es berücksichtigt nicht den Wert oder Sensitivity betroffener Daten. Es berücksichtigt keine compensating Controls, die du implementiert hast. Es reflektiert nicht Angreifer-Motivation oder Capability-Requirements.
Organisationen, die CVSS als comprehensive Risk-Assessment behandeln, missverstehen fundamental seinen Purpose. Es ist ein Input in Risk-Entscheidungen, der einen standardisierten Weg bietet, Severity zu kommunizieren. Es ist nicht das komplette Picture von Risk, und es war nie intended zu sein.
Ein technischer Vergleich von Vulnerability Disclosure Ansätzen von security.txt bis zu Full Bug Bounty Plattformen. Die Security Trade-offs auf jeder Reifestufe verstehen.
Ein technischer Vergleich von Vulnerability Disclosure Ansätzen von security.txt bis zu Full Bug Bounty Plattformen. Die Security Trade-offs auf jeder Reifestufe verstehen.
Klarer Scope in deiner Vulnerability-Disclosure-Policy bestimmt, was Forscher testen sollen. Mach es falsch und du wirst valide Research entmutigen oder mit ungewolltem Testing umgehen müssen.
Get the latest security research insights and vulnerability disclosure best practices delivered to your inbox.