Schubladen für Schwachstellen: Das CVE-System im Überblick

Inhaltsverzeichnis

Bereits im letzten Jahrtausend gestaltete sich die Kommunikation über Sicherheitslücken zunehmend schwierig: Wer von "die Sicherheitslücke im Internet Explorer" sprach, adressierte oftmals mehr als ein Dutzend aktueller Bugs. Eingrenzungen à la "die Lücke mit ActiveX" halfen kaum weiter, da das immer noch auf viele zutraf.

Um Missverständnisse zu vermeiden und sicherzustellen, dass alle vom gleichen Problem sprachen, musste eine herstellerübergeifende, einheitliche Strategie zur Erfassung und Verwaltung von Schwachstellen her. 1999 begann man daher mit einer systematischen Durchnummerierung: Das CVE (Common Vulnerabilities and Exposures)-System war geboren und hat sich seither als weltweit führender Industriestandard durchgesetzt.

Betreut und verwaltet wird es von der gemeinnützigen MITRE Corporation, finanziert mit Mitteln der US-Sicherheitsbehörden CISA (Cybersecurity and Infrastructure Security Agency) und DHS (Department of Homeland Security).

CVE-YYYY-NNNNN

CVE-Nummern beziehungsweise -IDs im Format CVE-YYYY-NNNNN dürften jedem schonmal begegnet sein, der sich mit Schwachstellen befasst hat – etwa auf der Suche nach Sicherheitsupdates für ein bestimmtes Produkt oder auch beim Lesen von Alerts bei heise Security.

Auf das "CVE" am Anfang folgt stets eine Jahresangabe. Bei dieser handelt es laut MITRE allerdings nicht (unbedingt) um das Jahr, in dem die Lücke entdeckt, sondern vielmehr um jenes, in dem sie publik gemacht beziehungsweise in dem die Nummer vergeben wurde.

Der letzte Teil der ID mit der eigentlichen Nummer war mit Einführung des CVE-Systems Ende 1999 noch auf vier Ziffern beschränkt. Da 9999 mögliche einzigartige IDs pro Jahr irgendwann aber nicht mehr ausreichten, wurde die Syntax Anfang 2014 geändert. Eine maximale Länge des "NNNNN"-Parts der IDs gibt es nun nicht mehr; sie orientiert sich am Bedarf im jeweiligen Kalenderjahr. Lediglich das Minimum wurde auf vier Ziffern festgeschrieben.

ID-Vergabe durch CNAs

Natürlich sorgt eine einheitliche Syntax allein nicht für Ordnung. Damit CVE-IDs nicht unkontrolliert vergeben werden, haben nur bestimmte Personen, Organisationen und Unternehmen, so genannte CVE Numbering Authorities (CNAs), die Befugnis zur CVE-Vergabe. Diese wiederum teilen die Zuständigkeit für verschiedene Produkte und Projekte klar unter sich auf.

Übergeordnete (Top-Level) Root CNAs, sind derzeit das MITRE CVE-Team, CISA und und das japanische JPCERT/CC. Ihnen untergeordnet sind "normale" CNAs, deren Befugnisse unterschiedlich weit reichen können. So befinden sich darunter etwa Soft- und Hardware-Hersteller, die CVE-IDs nur für ihre eigenen Produkte vergeben dürfen, aber auch CERTs, die die Vergabe für jeweils mehrere Unternehmen koordinieren.

Unabhängige Forscher, Forscherteams oder IT-Sicherheitsunternehmen (z.B. die Zero Day Initiative oder auch Rapid7) können, teilweise im Rahmen von Bug Bounty-Programmen, auch herstellerübergreifend als CNA für Produkte agieren, die nicht im Verantwortungsbereich einer anderen CNA liegen. Ähnliches gilt für so genannte CNAs of Last Resort (CNA-LR).

Wer eine Schwachstelle in einem bestimmten Produkt entdeckt und diese melden will, findet die jeweils zuständige Anlaufstelle in einer CNA-Übersicht auf MITREs CVE-Website. Die CNA kümmert sich im nächsten Schritt um die Reservierung einer CVE-ID. Die landet in MITREs fortlaufend geführter CVE-Liste– typischerweise zunächst mit dem Vermerk "Reserved". Später vervollständigen eine Schwachstellen-Beschreibung und meist auch Verlinkungen zu weiterführenden Informationen den CVE-Eintrag.

CVE-Nutzung durch heise Security

Auch heise Security verwendet wo immer es sinnvoll möglich ist CVE-Nummern. Wir betten diese etwa in unsere Alert-Meldungen mit ein, um später eine gezieltes Suche nach einer bestimmten Lücke zu ermöglichen. Die Links auf die eigentlichen CVE-Seiten bringen zum Zeitpunkt, zu dem unsere Meldungen erscheinen, oftmals nur wenig Mehrwert, da sich die ID mitunter noch im "Reserved"-Status befindet. Um unsere Leser nicht in diese Sackgasse zu schicken, lassen wir die Links daher auch häufig weg und erwähnen lediglich die CVE-Nummer.

Bei Sammeladvisories beschränken wir uns auf die zentralen Lücken, die in der weiteren Berichterstattung am wahrscheinlichsten eine Rolle spielen werden. Sonst müssten wir etwa bei einem Oracle Critical Patch Update mal eben 400 IDs in unsere Artikel pressen – und der Mehrwert für unsere Leser wäre gleich Null.

Zusatz-Infos in der NVD

Sind dagegen bereits weiterführende Informationen verfügbar, bieten sich statt einer Verlinkung auf MITREs CVE-Liste alternativ auch Verweise auf die so genannte National Vulnerability Database (NVD) an. Sie ist ein unabhängiges, 2005 vom National Institute of Standards and Technology (NIST) ins Leben gerufenes Projekt, das wie das CVE-System von den US-Behörden CISA und DHS gesponsert wird.

Die NVD speist sich aus MITREs CVE-Liste, fügt den eher knappen Beschreibungen allerdings wertvolle Zusatzinformationen etwa zu Sicherheitsrisiken oder verfügbaren Updates hinzu.

Zur einheitlichen Beschreibung von Schwachstellen-Eigenschaften nutzt (nicht nur) die NVD wiederum ein spezielles System, mit dem unter anderem man einen Schweregrad von "Low" bis "Critical" zuweisen und Aussagen zu Angriffsweg, -komplexität und Co. anhand vordefinierter Kriterien treffen kann. Dieses so genannte Common Vulnerability Scoring System (CVSS) hat einen eigenen Hintergrundartikel verdient, der demnächst bei heise Security erscheinen soll.

(ovw)