Seite 3: CVE-Einträge ohne CPE

Inhaltsverzeichnis

Die CVE-Feeds enthalten 2864 CVEs ohne CPE-ID. Beispielsweise hat der CVE-Eintrag CVE-2018-0149 (eine XSS-Schwachstelle in der Web-Management-Schnittstelle eines Cisco-Produkts) bis zum Zeitpunkt der Evaluierung keine CPE-ID bekommen. In Abbildung 3 wurde eine Verwundbarkeitsanalyse skizziert, in der die Suche von CVEs für eine Software auf der zugewiesenen CPE-ID des Produkts basiert. Ohne Berücksichtigung der Tatsache, dass CVEs ohne CPE existieren, könnte so eine Analyse fehlerhafte Resultate liefern, da in vielen Fällen keine Beziehung zwischen einer CVE- und der CPE-ID einer Software möglich ist.

Veraltete Einträge in der CPE-Dictionary

CPE-Einträge können aus drei Gründen veraltet sein:

1. Die CPE-ID hat einen Tippfehler oder stimmt nicht.
2. Die CPE wird nicht länger benutzt und muss entfernt werden.
3. Neue Informationen zu einem IT-Produkt sind hinzuzufügen.

Die veralteten CPEs werden mit dem XML-Element cpe-23:deprecation gekennzeichnet. Es enthält ein Kind-Element (cpe-23:deprecated-by), das gegebenenfalls zeigt, durch welche CPE die veraltete CPE ersetzt wurde. Außerdem wird der Grund der "Deprecation" anhand des Attributs "name" angegeben.

Zum Zeitpunkt der Evaluierung gab es 2939 veraltete CPEs. Alle waren wegen der Namenskorrektur veraltet. Das nachfolgende Bild zeigt einen veralteten CPE-Eintrag aus der CPE-Dictionary. Diese CPE ist veraltet, da der Name des Produkts falsch geschrieben wurde: "morbtay" statt "mortbay".

Die Tatsache, dass eine beträchtliche Menge von CPEs wegen Namenskorrektur "veraltet" sind, deutet darauf hin, dass sich während einer Verwundbarkeitsanalyse eine inkorrekte CPE-ID zu einer Software zuweisen ließe. Wie Abbildung 5 zeigt, gibt es einen Zeitraum, in dem die Zuordnung einer falschen CPE zu einer Software stattfinden kann. Wenn das nicht berücksichtigt wird, könnte die CVE-Suche einer VA falsche Ergebnisse liefern, da sie auf der zugewiesenen CPE-ID basiert.

Synchronisation zwischen der CPE-Dictionary und den CVE-Feeds

Zum Zeitpunkt der Evaluierung gab es in den CVE-Feeds 130.036 CPE-IDs, die nicht in der CPE-Dictionary waren. Die Autoren haben folgende Gründe dafür festgestellt:

• Die Versionen einiger IT-Produkte wurden noch nicht in der CPE-Dictionary eingetragen. Ein Beispiel hierfür ist die Version 3.5 des Produkts Red Hat Enterprise Virtualization. Es gibt keinen CPE-Eintrag in der CPE-Dictionary, obwohl dieses Release verwundbar ist und eine CPE dafür in den CVE-Feeds existiert (s. CVE-2008-3522).
• Eine CPE-ID wird aus einer Menge von Attributen wie Name, Version oder Update erzeugt (s. CPE-Benennungsspezifikation). In den CVE-Feeds gibt es CPE-IDs, die nicht in der CPE-Dictionary sind, weil unterschiedliche Werte für diese Attribute verwendet wurden. Im nachfolgend aufgeführten Beispiel wurde in der CPE-ID innerhalb der CPE-Dictionary der Wert "beta2" auf das Attribut "Update" gesetzt. Andererseits hatte man in den CVE-Feeds den String "beta2" mit der Version des Produkts ("1.2.0_beta2") konkateniert. Daraus ergeben sich zwei unterschiedliche CPE-IDs für das gleiche Produkt:

CPE-ID in der CPE-Dictionary: cpe:/a:digium:asterisk:1.2.0:beta2
CPE-ID in der CVE-Feeds: cpe:/a:digium:asterisk:1.2.0_beta2

• Es gibt IT-Produkte ohne CPE-Eintrag in der CPE-Dictionary. Zum Beispiel hat der Microsoft Search Server noch keinen Eintrag. Es gibt jedoch eine Sicherheitslücke (CVE-2008-4032), die die Version 2008 (x32- und x64-Architektur) der Software betrifft.

Die beschriebenen Punkte zeigen, dass keine Synchronisierung zwischen der CPE-Dictionary und den CVE-Feeds besteht, obwohl dieselbe Organisation beide Datenbanken betreibt. Für die Implementierung einer Verwundbarkeitsanalyse (wie in Abb. 3 skizziert) ist dieser Aspekt in Betracht zu ziehen, da die Ergebnisse stark vom Zusammenhang zwischen beiden Datenbanken abhängen.