Common Vulnerabilities and Exposures: So schützen Sie Ihre IT-Infrastruktur

Common Vulnerabilities and Exposures (CVE) bildet seit 1999 das Fundament für die systematische Identifizierung und Katalogisierung von Sicherheitslücken in Software- und Hardwarekomponenten. Das CVE-Programm definiert Schwachstellen als „Schwächen in der Computerlogik von Software- und Hardwarekomponenten, die bei Ausnutzung negative Folgen für Vertraulichkeit, Integrität oder Verfügbarkeit haben können.“ Wir erläutern Ihnen, wie Common Vulnerabilities and Exposures funktionieren, welche Kriterien für die Aufnahme in die CVE-Liste gelten und wie Sie dieses System für den Schutz Ihrer IT-Infrastruktur nutzen können. Zusätzlich betrachten wir die Rolle des Common Vulnerability Scoring System (CVSS) bei der Risikobewertung von Schwachstellen.

Was sind Common Vulnerabilities and Exposures (CVE)?

Common Vulnerabilities and Exposures entstand als Konzept durch David E. Mann und Steven M. Christey von der MITRE Corporation. Ihre Idee präsentierten sie erstmals in einem Whitepaper mit dem Titel “Towards a Common Enumeration of Vulnerabilities” im Januar 1999 bei einem Workshop an der Purdue University. Diese Initiative führte zur Bildung einer Arbeitsgruppe, die sich zum ersten 19-köpfigen CVE Editorial Board entwickelte.

Die wachsende Bedrohungslandschaft stellt Unternehmen vor die Herausforderung, ihre IT-Systeme umfassend vor Cyberangriffen zu schützen. CVEs ermöglichen Organisationen den strukturierten Austausch von Sicherheitsinformationen und die einheitliche Bewertung von Schwachstellen. Dabei werden jährlich tausende CVE-IDs vergeben – ein einzelnes komplexes System wie ein Betriebssystem kann hunderte CVEs ansammeln. CVE-Einträge bleiben jedoch bewusst knappgehalten und enthalten keine detaillierten technischen Daten oder spezifische Lösungsansätze. Die offizielle Veröffentlichung der CVE-Liste erfolgte im September 1999 mit 321 ursprünglichen Einträgen.

CVE: der Ursprung

Das CVE-Programm wird vom United States’ Homeland Security Systems Engineering and Development Institute FFRDC betrieben, das unter der Verwaltung der MITRE Corporation steht. Die Finanzierung stellt die US National Cyber Security Division des US Department of Homeland Security bereit. Das Hauptziel besteht darin, eine standardisierte Methode zur Identifizierung und Katalogisierung öffentlich bekannter Cybersicherheitslücken zu schaffen. Diese einheitliche „Sprache“ ermöglicht den effektiven Austausch von Sicherheitsinformationen zwischen verschiedenen Datenbanken und Tools.

Unterschied zwischen Schwachstelle und Gefährdung

Eine Schwachstelle stellt eine Schwäche in einem System dar – eine potenzielle Angriffsfläche, die unter bestimmten Umständen ausgenutzt werden kann. Eine Gefährdung (Exposure) hingegen beschreibt einen konkreten Vorfall, bei dem eine Schwachstelle tatsächlich ausgenutzt wurde. Schwachstellen existieren als theoretische Schwächen, die erst unter den richtigen Bedingungen zu einer realen Bedrohung werden.

Schwachstellen finden sich in Netzwerkhardware und -software, Betriebssystemen, Prozessen und sogar bei Mitarbeitern einer Organisation. Eine Gefährdung entsteht erst dann, wenn eine Schwachstelle auf reale Bedingungen trifft, die ihre Ausnutzung ermöglichen.

Beispielhafte CVE-IDs und deren Aufbau

Eine CVE-ID folgt einem einheitlichen, alphanumerischen Format, das vom CVE-Programm zugewiesen wird:

• CVE-Präfix + Jahr + Beliebige Ziffern

Der Jahresanteil bezeichnet das Jahr, in dem die CVE-ID reserviert oder die Sicherheitslücke öffentlich gemacht wurde – nicht das Jahr der ursprünglichen Entdeckung. Der Ziffernblock umfasst mindestens vier Stellen.

Welche Sicherheitslücken qualifizieren sich für eine CVE-ID?

Die Vergabe von CVE-IDs folgt strukturierten Kriterien, um die Relevanz und Qualität der erfassten Sicherheitslücken sicherzustellen. Nicht jedes identifizierte Sicherheitsproblem erhält automatisch eine CVE-Kennung. Diese systematische Herangehensweise gewährleistet, dass die CVE-Liste als zentrale Referenz für bedeutsame Schwachstellen fungiert.

Kriterien für die Aufnahme in die CVE-Liste

Eine Sicherheitslücke muss vier wesentliche Anforderungen erfüllen, um eine CVE-ID zu erhalten:

Unabhängige Behebbarkeit:
Die Schwachstelle muss separat von anderen Fehlern behoben werden können. Diese Abgrenzung stellt sicher, dass jede CVE-ID eine eigenständige Sicherheitslücke repräsentiert.

Herstelleranerkennung oder Dokumentation:
Der verantwortliche Hersteller muss die Schwachstelle bestätigen und deren Sicherheitsauswirkungen anerkennen. Alternativ genügt ein fundierter Schwachstellenbericht, der sowohl die negative Auswirkung als auch den Verstoß gegen Sicherheitsrichtlinien des betroffenen Systems belegt.

Einzelne Codebasis:
Die Schwachstelle darf nur ein Produkt betreffen. Fehler in mehreren Produkten erhalten für jedes betroffene System separate CVE-IDs.

Eindeutige Sicherheitsauswirkung:
Die Schwachstelle muss messbare Auswirkungen auf die Systemsicherheit haben.

Typische Beispiele: XSS, RCE, SQL-Injection

Die folgenden Schwachstellentypen qualifizieren sich regelmäßig für CVE-IDs:

• Buffer Overflows in weit verbreiteter Software
• SQL-Injection-Schwachstellen in Webanwendungen mit unbefugtem Datenbankzugriff
• Remote Code Execution (RCE) für beliebige Codeausführung auf entfernten Systemen
• Authentication Bypass zur Umgehung von Authentifizierungsmechanismen
• Cross-Site Scripting (XSS) für das Einschleusen schädlichen Codes in Webseiten

Ausschlusskriterien: interne Software, physischer Zugriff

Bestimmte Sicherheitsprobleme bleiben von der CVE-Liste ausgeschlossen:

• Schwachstellen in maßgeschneiderten internen Anwendungen
• Probleme, die physischen Systemzugriff erfordern
• Theoretische Schwachstellen ohne Proof-of-Concept
• Mehrfachschwachstellen, die mit einem einzigen Patch behebbar sind

Cloud-Dienste ohne Kundenkontrolle fallen häufig durch die Aufnahmekriterien, insbesondere aufgrund der INC3-Regel, die kundenkontrollierte oder kundeninstallierbare Schwachstellen fordert. Umstrittene Sicherheitslücken können als „DISPUTED“ gekennzeichnet werden.

Wie funktioniert die Zuweisung durch CVE Numbering Authorities (CNAs)?

Die Vergabe von CVE-IDs erfolgt über ein hierarchisches System von CVE Numbering Authorities (CNAs), das die strukturierte Erfassung und Verwaltung von Sicherheitslücken gewährleistet. Diese Organisation stellt sicher, dass jede Schwachstelle systematisch dokumentiert und eindeutig identifiziert werden kann.

Rolle von MITRE und CISA als Root-CNAs

Das CVE-System wird von zwei Top-Level Root CNAs geleitet: der MITRE Corporation und der Cybersecurity and Infrastructure Security Agency (CISA). MITRE fungiert als CVE-Programm-Sekretariat und übernimmt die Rolle als Top-Level Root sowie als CNA of Last Resort (CNA-LR). Unter der MITRE TL-Root-Hierarchie operieren sechs weitere Roots, darunter ENISA, Google, INCIBE, JPCERT/CC, Red Hat und die Thales Group.

CISA konzentriert sich seit ihrer Ernennung zum Top-Level Root auf industrielle Kontrollsysteme (ICS) und medizinische Geräte. Diese Spezialisierung umfasst die Beaufsichtigung von sieben CNAs, einschließlich Alias Robotics, ABB, CERT@VDE, Johnson Controls, Bosch, Siemens und der Gallagher Group.

Ablauf der CVE-Reservierung und Veröffentlichung

Der Zuweisungsprozess basiert auf dem “Recht der ersten Ablehnung”-Prinzip. Die CNA mit dem passendsten Zuständigkeitsbereich muss zuerst kontaktiert werden. Softwarehersteller, die als CNA agieren, haben Vorrang bei Anfragen zu ihren eigenen Produkten.

Erfolgt eine Ablehnung oder bleibt eine Antwort innerhalb von 72 Stunden aus, übernimmt ein Root die Schwachstellenbewertung und beauftragt gegebenenfalls eine CNA-LR mit der Zuweisung. Nach erfolgter Zuweisung sollen CNAs den CVE-Eintrag idealerweise innerhalb von 24 Stunden nach öffentlicher Bekanntgabe veröffentlichen, spätestens jedoch nach 72 Stunden.

Veröffentlichungsstatus: Reserviert, Veröffentlicht, Abgelehnt

Jeder CVE-Datensatz durchläuft einen definierten Statusverlauf:

Reserviert kennzeichnet die initiale Phase, wenn eine CNA eine CVE-ID reserviert hat, die Details jedoch noch nicht öffentlich verfügbar sind. Diese Phase ermöglicht die frühzeitige Koordination und Verwaltung der Schwachstelle.

Veröffentlicht signalisiert, dass die CNA alle relevanten Daten zur CVE-ID bereitgestellt und den Datensatz publiziert hat. Mindestanforderungen umfassen die Angabe betroffener Produkte, Versionen, den Schwachstellentyp und öffentliche Referenzen.

Abgelehnt markiert CVE-Datensätze, die nicht als gültige Einträge akzeptiert wurden. Häufige Ablehnungsgründe sind Duplikate, Rücknahme durch den Antragsteller oder fehlerhafte Zuweisungen. Abgelehnte Datensätze verbleiben im Verzeichnis zur eindeutigen Kennzeichnung ihrer Ungültigkeit.

Wie hilft CVSS bei der Bewertung von CVEs?

Das Common Vulnerability Scoring System (CVSS) ermöglicht Organisationen eine standardisierte Bewertung der Schwere von Sicherheitslücken. Mit numerischen Werten zwischen 0,0 und 10,0 schafft es die Grundlage für fundierte Entscheidungen im Schwachstellenmanagement. Diese einheitliche Bewertung unterstützt Unternehmen dabei, ihre Ressourcen gezielt für die kritischsten Bedrohungen einzusetzen.

CVSS-Basismetriken: Angriffsvektor, Komplexität, Rechte

Die Basismetriken bilden das Fundament der CVSS-Bewertung und erfassen die wesentlichen Eigenschaften einer Schwachstelle:

• Angriffsvektor (AV): Bestimmt die Erreichbarkeit – von Netzwerk (N) über lokal (L) bis physisch (P)
• Angriffskomplexität (AC): Bewertet den Aufwand für eine erfolgreiche Ausnutzung
• Erforderliche Rechte (PR): Definiert die notwendigen Zugriffsrechte für einen Angriff
• Benutzerinteraktion (UI): Gibt an, ob Benutzeraktionen zur Ausnutzung erforderlich sind

Zeitliche und umgebungsbezogene Metriken

Zeitliche Metriken berücksichtigen die Entwicklung einer Bedrohung über die Zeit:

• Exploit-Code-Reife: Reicht von theoretischen Konzepten bis zu funktionsfähigen Exploits
• Verfügbare Abhilfemaßnahmen: Von temporären Workarounds bis zu offiziellen Patches
• Bestätigungsgrad: Spiegelt die Verlässlichkeit der Schwachstellenmeldung wider

Umgebungsbezogene Metriken passen die Bewertung an organisationsspezifische Gegebenheiten an und berücksichtigen individuelle Sicherheitsanforderungen.

CVSS-Skala: von 0.0 bis 10.0

Die CVSS-Bewertung gliedert sich in fünf Schweregrade:

• Keine (0,0)
• Niedrig (0,1-3,9)
• Mittel (4,0-6,9)
• Hoch (7,0-8,9)
• Kritisch (9,0-10,0)

Während viele Organisationen ausschließlich den Basiswert verwenden, liefern zeitliche und umgebungsbezogene Faktoren ein präziseres Bild der tatsächlichen Bedrohungslage. Wir empfehlen, alle Metriken in die Risikobewertung einzubeziehen, um fundierte Prioritätsentscheidungen zu treffen.

CVE als Baustein für effektives Schwachstellenmanagement

Die systematische Nutzung von Common Vulnerabilities and Exposures stellt einen wesentlichen Baustein für effektives Schwachstellenmanagement dar. Unternehmen können durch die strukturierte Überwachung von CVE-Einträgen ihre Reaktionszeit bei kritischen Sicherheitslücken erheblich verkürzen und damit potenzielle Schäden minimieren.

Wir empfehlen Ihnen die Integration von CVE-Monitoring in bestehende Sicherheitsprozesse. Dabei sollten Sie Prioritäten anhand der CVSS-Bewertungen setzen und Ressourcen für die Behebung kritischer Schwachstellen entsprechend zuweisen. Die hierarchische Struktur der CVE Numbering Authorities gewährleistet dabei eine zuverlässige Informationsquelle für Ihre Sicherheitsteams.

Praktische Schritte für die Implementierung sind z. B. die Etablierung regelmäßiger CVE-Datenbankabfragen für eingesetzte Systeme, die Schulung der IT-Teams zur Bewertung von CVE-Einträgen und CVSS-Scores oder auch die Integration von CVE-Informationen in bestehende Patch-Management-Verfahren. Die Entwicklung von Eskalationsprozessen für kritische Schwachstellen sollte ebenfalls Teil der Implementierung sein.

Die Geschwindigkeit, mit der Sie auf bekannt gewordene Schwachstellen reagieren, bestimmt maßgeblich das Sicherheitsniveau Ihrer gesamten IT-Infrastruktur. Durch proaktive CVE-Überwachung können Sie das Risikopotenzial deutlich reduzieren und das Vertrauen von Kunden und Partnern in Ihre Sicherheitsmaßnahmen stärken.

Wir stehen Ihnen bei der Implementierung eines strukturierten Schwachstellenmanagements gerne zur Seite.

FAQs – Häufige Fragen zu CVE

Was sind die Hauptziele der IT-Sicherheit?

Die primären Schutzziele der IT-Sicherheit sind Verfügbarkeit, Integrität und Vertraulichkeit. Zusätzlich können Authentizität, Zurechenbarkeit und Verlässlichkeit als erweiterte Ziele betrachtet werden. Diese Ziele bilden die Grundlage für effektive IT-Sicherheitsmaßnahmen in Organisationen.

Wie können Unternehmen Sicherheitslücken effektiv managen?

Unternehmen sollten regelmäßig Schwachstellenanalysen durchführen, fortschrittliche Scan-Tools einsetzen und das Bewusstsein ihrer Mitarbeiter für IT-Sicherheit schärfen. Zudem ist es wichtig, CVE-Datenbanken regelmäßig auf relevante Einträge zu überprüfen und ein effektives Patch-Management zu implementieren.

Was ist der Unterschied zwischen einer Schwachstelle und einer Gefährdung?

Eine Schwachstelle ist eine potenzielle Schwäche in einem System, die ausgenutzt werden könnte. Eine Gefährdung hingegen ist ein konkreter Vorfall, bei dem eine Schwachstelle tatsächlich ausgenutzt wurde. Das Verständnis dieses Unterschieds ist wichtig für die Entwicklung angemessener Schutzstrategien.

Wie funktioniert das Common Vulnerability Scoring System (CVSS)?

Das CVSS bewertet Sicherheitslücken auf einer Skala von 0,0 bis 10,0. Es berücksichtigt Basismetriken wie Angriffsvektor und Komplexität sowie zeitliche und umgebungsbezogene Faktoren. Diese Bewertung hilft Organisationen, die Schwere von Schwachstellen einzuschätzen und Ressourcen für deren Behebung zu priorisieren.

Warum ist die Überwachung von CVE-Einträgen wichtig?

Die regelmäßige Überwachung von CVE-Einträgen ermöglicht es Unternehmen, schnell auf potenzielle Bedrohungen zu reagieren. Es hilft bei der Identifizierung von Schwachstellen in verwendeten Systemen und unterstützt bei der Priorisierung von Sicherheitsmaßnahmen. Eine proaktive CVE-Überwachung ist ein wesentlicher Bestandteil eines umfassenden IT-Sicherheitskonzepts.

Autorin Joanna Lang-Recht