Zusammenfassung

  • Der MITRE-Fortschrittsbericht von 2002 datiert den öffentlichen Start auf September 1999 und nennt 321 ursprüngliche Einträge. Die Liste sollte eine logische Brücke zwischen vorhandenen Werkzeugen und Datenbanken sein.
  • Die MITRE-Autoren beschrieben 1999, dass paarweise Verbindungen zwischen N Schwachstellen-Datenbanken ungefähr N² Zuordnungen erfordern. Ein gemeinsamer Index senkt die Zahl auf N. Schweregrad, lokale Einstellungen und Werkzeugqualität gehören nicht in den Namen.

Drei Werkzeuge, drei Bezeichnungen

Jeder Sicherheitsanbieter pflegte eine eigene Datenbank und eigene Begriffe. Ein Scannerfund und ein Herstellerhinweis konnten dieselbe Lücke meinen, ohne dass die Texte sich leicht zusammenführen ließen. MITREs ursprüngliche Analyse setzte genau dort an: Ohne gemeinsame Bezeichnung lassen sich Werkzeuge schlecht vergleichen und Ergebnisse schlecht mit Hinweisen verknüpfen. Die erste Aufgabe war, die Identität des Problems zu klären.

Die vorgeschlagene gemeinsame Schicht war bewusst klein. Ein eindeutiger Name und eine kurze unterscheidbare Beschreibung genügten. Jedes Produkt durfte seine eigene Forschung und Einordnung behalten, musste aber seinen Datensatz dem gemeinsamen Eintrag zuweisen können. Sonst brauchte jedes Datenbankpaar eine eigene Übersetzung. Mit einer zentralen Konkordanz brauchte jede Datenbank nur eine Zuordnung. Das Verhältnis N² zu N beschrieb den Verbindungsaufwand, nicht die Zahl der existierenden Sicherheitslücken.

Die Autoren wollten auch keine allgemeine Taxonomie vorgeben. Sie nannten CVE einen Index. Unterschiedliche Produkte konnten denselben Fehler unterschiedlich bewerten und trotzdem denselben Namen verwenden. Gerade weil der gemeinsame Teil so wenig über die Welt behauptete, konnten konkurrierende Werkzeuge ihn übernehmen, ohne ihre gesamte Datenstruktur abzugeben.

Eine Kennung ist kein Urteil

Präfix, Jahr und laufende Zahl sehen nach einem amtlichen Befund aus. Die Arbeit von 1999 schloss aber zwei Lesarten ausdrücklich aus: Die Zahl bezeichnet weder die zeitliche Entdeckung noch den Schweregrad. Sie sagt auch nicht, ob eine konkrete Installation angreifbar ist oder ob ein bestimmter Scanner zuverlässig prüft. Lokale Konfiguration, Sicherheitsregeln und Risiko bleiben Aufgaben außerhalb des Verzeichnisses.

Die scheinbar einfache Vergabe kostete dennoch Entscheidungen. Für einen Vorschlag gab es zunächst eine vorläufige CAN-Kennung. Der Redaktionsausschuss konnte ihn als Duplikat ablehnen, überarbeiten, mit einem anderen Fall vereinen oder in mehrere Fälle trennen. Der MITRE-Text dokumentiert diese Möglichkeiten. Eine Kennung erfordert ein Urteil darüber, was als ein Problem zählt. Sie prüft keinen Patch in einer laufenden Anwendung.

Der Bericht von 2002 schildert die öffentliche Vorstellung der ersten 321 Einträge im September 1999. MITRE wollte eine logische Brücke statt eines Konkurrenzprodukts für alle Datenbanken. Ein Sicherheitswerkzeug, ein Advisory und die Update-Seite eines Herstellers konnten dieselbe Kennung tragen. Der Betreiber musste danach noch die installierte Version feststellen, das passende Update wählen und den Dienst nach der Änderung testen.

Die 321 Einträge waren eine Startmenge, keine Vollzählung aller bekannten Fehler und schon gar kein Reparaturstand. CVE machte es möglich, mit drei Berichten auf denselben Riss zu zeigen. Den Riss schließen musste jemand anders.