Sie sind nützlich, sie sind einfach nicht nützlich, um Exploits zu erstellen. Sie sind auch nicht nützlich, um festzustellen, wie fehlerhaft eine Software ist ... Die Anzahl der CVEs hat keine starke Korrelation mit der Codequalität.

Sie sind nützlich, um als Administrator festzustellen, ob die Versionen eines bestimmten Softwarepakets, das Sie verwenden, für bestimmte bekannte Exploits gepatcht wurden und welches Potenzial besteht Auswirkungen von Exploits, die entdeckt wurden. Auf diese Weise können sie als eines der vielen Tools, mit denen Sie sicherstellen können, dass Ihr Unternehmen das Software-Sicherheitsrisiko ordnungsgemäß verwaltet, direkt in einen Schwachstellenmanagementprozess einfließen.

Der Hauptanwendungsfall für CVE besteht darin, eindeutige Kennungen für Software-Schwachstellen zu haben. Es ist kein gutes Tool, um die Gesamtsicherheit eines Produkts zu messen, und hilft Ihnen nicht bei der eingehenden Analyse eines Fehlers.

Sie sollten sich CVE als Wörterbuch vorstellen Anstelle einer Datenbank, die Schwachstellen Standardnamen zuweist, damit Sie systemübergreifend eindeutig auf sie verweisen können. Machen Sie nicht den Fehler anzunehmen, dass ein CVE-Eintrag eine vollständige Erklärung einer Sicherheitsanfälligkeit oder eine genaue Abschätzung der Auswirkungen enthält.

Die Seite Über CVE macht dies ziemlich deutlich Der Schwerpunkt liegt auf Standardisierung 1:

CVE ist:

• Ein Name für eine Sicherheitsanfälligkeit oder Gefährdung
• Eine standardisierte Beschreibung für jede Sicherheitsanfälligkeit oder Gefährdung
• Ein Wörterbuch anstelle einer Datenbank
• Wie unterschiedliche Datenbanken und Tools dieselbe Sprache "sprechen" können
• Der Weg zu Interoperabilität und besserer Sicherheitsabdeckung
• Eine Grundlage für die Bewertung zwischen Tools und Datenbanken

[...]

Also CVE ist nicht als umfassende Datenbank aller bekannten Schwachstellen in einem Produkt gedacht, da die Einträge weder von Dritten überprüft noch unbedingt vollständig sind. Dies ist vor allem als Übersicht nützlich. Um eine eindeutige Kennung zu erhalten, können Sie den Fehler in einem Patch oder einer Beschreibung beheben.

CVEs sind in mehrfacher Hinsicht nützlich.

Erstens und vielleicht am wichtigsten bieten sie einen gemeinsamen Begriff für eine bestimmte Sicherheitsanfälligkeit. Auf diese Weise können Sie auf einfache Weise sicherstellen, dass Sie von der gleichen Android-Sicherheitsanfälligkeit sprechen, wenn jemand sagt, dass Sie diese Android-Sicherheitsanfälligkeit gesehen haben. Dies vereinfacht auch die Suche nach weiteren Informationen zu diesem Problem erheblich.

Wenn Sie sich auf der Seite von NIST zur Sicherheitsanfälligkeit durchklicken, werden CVSS -Informationen angezeigt Wenn Sie mit dem Lesen der Notation vertraut sind, können Sie sich schnell einen Überblick darüber verschaffen, wie wichtig es für Sie ist, die Sicherheitsanfälligkeit in Ihrer Umgebung zu beheben.

CVEs sind für mich ein bisschen wie Wörterbuchbegriffe. Es soll in der Lage sein, über eine gemeinsame Aufzählung leicht zu kommunizieren, was etwas ist.

Weitere Informationen dazu, warum sie so geschrieben sind, finden Sie unter https://cve.mitre.org/about/. faqs.html # b4

Ein guter CVE bezieht sich auf OpenSSL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE -2016-6304

Die Beschreibung ist kurz, aber die Seite verweist auf relevante Referenzen, die den CVE weiter erweitern.

In dem CVE, den Sie als verwenden Beispiel: Es gibt einen Link zum Android Security Bulletin, der mehr Informationen und Sicherheitsfokus enthält (obwohl nicht viel erwähnt wird). Wenn ein Exploit verfügbar war, wird er wahrscheinlich nicht freigegeben.

Wie bereits gesagt, sind sie nützlich ... es kommt nur darauf an, was Sie tun möchten. Wenn Sie eine Sicherheitsüberprüfung durchführen, wie ich mich meiner Antwort nähere, ist es wichtig, einen Ausgangspunkt zu haben. Wenn Sie etwas wie Nessus oder OpenVAS ausführen, werden Sie feststellen, dass ein bestimmtes CVE mit einem Host korreliert. Von dort aus müssen Sie mithilfe von Exploit-db.com untersuchen, ob Exploits dafür verfügbar sind. Exploits werden nicht immer im CVE aufgeführt, daher ist eine sorgfältige Prüfung erforderlich.

CVEs sind für alle Akteure in der Softwarekette (Entwickler, Systemadministratoren, Kunden ...) nützlich, um zu entscheiden, ob Maßnahmen gegen vorhandene Software ergriffen werden sollen oder nicht. Proof of Concepts werden absichtlich redigiert, da das Patchen der tatsächlichen Installationen , wie ich zeigen werde, sehr lange dauert.

In einer theoretischen Welt werden Patches sofort bereitgestellt alle Geräte. Dies garantiert, dass alle Geräte gepatcht und geschützt sind. Dies ist nicht möglich.

Wählen Sie Android ...

• T0: Eine Sicherheitsanfälligkeit im Linux-Kernel, die sich auf den Android-Kernel auswirkt, wurde gefunden und gepatcht
• T1: Google patcht AOSP und veröffentlicht den Patch.
• T2: Mobilfunkhersteller (z. B. LG, Motorola, Samsung) erhalten den Patch und wenden ihn auf ihren benutzerdefinierten Build an.
• T3: Der Patch wird OTA an Verbraucher geliefert
• T4: Ein Unternehmen mit Tausenden von Android-Geschäftsgeräten desselben Herstellers stellt das Update für die Arbeitsgeräte bereit.

Wählen Sie Apache ...

Dies ähnelt einem Fall, der mir während meiner Arbeit passiert ist.

• T0: Eine Sicherheitslücke in Apache wurde gefunden und gepatcht. Apache wird freigegeben.
• T1 : Ein großes Unternehmen, das Apache für viele Anwendungen verwendet, die intern auf verschiedenen Servern installiert sind, plant das Upgrade
• T2 auf T100: Alle Apache-Instanzen werden auf den Unternehmenssystemen aktualisiert, wobei Lieferanten und Manager sich treffen und planen müssen ein Testplan

Kurz gesagt,

CVEs sind nützlich, um de Termine "wie alt" und "wie riskant" eine Software ist. Durch die Prüfung des Schweregrads und der betroffenen Komponenten können die IT-Mitarbeiter entscheiden, ob sie beispielsweise vorerst kein Upgrade durchführen, sofort ein Upgrade durchführen und zusätzliche temporäre Sicherheitsmaßnahmen anwenden möchten (z. B. Firewall, Proxy).

In der Unternehmenswelt Das Software-Upgrade weist eine intrinsische Langsamkeit auf. Ich sehe Banken, auf denen Java < = 1.5 ausgeführt wird (wieder nicht später als 1.5 ), weil spätere Versionen nicht zertifiziert wurden und Java 1.7 bereits nicht mehr verfügbar ist. Wir wissen, dass Unternehmen immer noch XP ausführen, weil sie nicht wissen, ob ihre gesamte vorhandene Softwarebasis unter Windows 7 ausgeführt wird, und es nicht einmal wagen, 10 zu versuchen.

Meiner Erfahrung nach kann ein schwerer CVE der Grund sein um ein Software-Upgrade in einem strukturierten Unternehmensszenario zu priorisieren.