Autor: Daniel Goßen

Allgemein, ISMS, Passwörter, Phishing, Weiterbildung

Klassische Phishing-Simulationen sind tot, lang lebe der Phishing Drill 

Was sind Phishing-Simulationen und welchen Zweck haben sie bisher verfolgt? 

Phishing-Simulationen werden bisher als eine etablierte Methode eingesetzt, um Mitarbeitende gegenüber der Gefahr, welche von potentiell schädlichen E-Mails ausgeht, zu sensibilisieren und zu schulen.   

Bei klassischen Phishing-Angriffen per E-Mail wird ein Szenario ausgearbeitet, welches einer authentischen E-Mail sehr nahekommt. Allerdings verweist der Link in der E-Mail nicht auf die zu erwartende Website, sondern auf eine präparierte nachgebaute Seite eines Angreifers. Dies verfolgt häufig den Zweck, Nutzerdaten abzufangen und für weitergehende Angriffe zu nutzen. 

Die sogenannte Phishing-Simulation verfolgt denselben Zweck. Hierbei folgt allerdings kein Angriff auf das Unternehmen, sondern ein Bericht, welcher die Ergebnisse der Simulation aufarbeitet. Mit diesem Bericht soll ein Unternehmen zum einen ein Gefühl dafür bekommen, wie die Mitarbeitenden auf Phishing-E-Mails reagieren, zum anderen einen Überblick erhalten, wie gefährdet Sie durch Phishing sind. Dazu sei kurz erwähnt: Am Ende kann eine einzelne Reaktion auf eine Phishing-E-Mail, z. B. die Eingabe valider Zugangsdaten, ausreichen, um einen Angriff auf das Unternehmen erfolgreich zu machen. Es sollten immer weitere Maßnahmen getroffen werden, um das Unternehmen abzusichern. Beispielsweise sei hier zu nennen: Der Aufbau einer Zero-Trust-Architektur, Nutzung von Passkeys, Einsatz von Multifaktor-Authentifizierung etc. 

Warum sind klassische Phishing-Simulationen doch nicht so vielversprechend wie bisher erwartet? 

Eine kürzlich veröffentlichte Studie, über die Heise bereits berichtet hat, legt nun den Schluss nahe, dass Phishing-Simulationen, wie sie bisher durchgeführt wurden, doch nicht so vielversprechend sind, wie häufig behauptet. Die Ergebnisse der Studie legen nahe, dass Phishing-Simulationen nur zu einem sehr geringen Grad als alleinstehende Awareness-Maßnahme weiterhelfen. 

Aber was bedeutet das nun genau? Sollte gänzlich auf Phishing-Simulationen verzichtet werden, oder muss die Erwartungshaltung an Phishing angepasst werden? 

Die Autoren haben in einer Phishing-Simulation mit ca. 19.500 Mitarbeitenden monatlich Phishing-E-Mails an alle Mitarbeitenden versendet und dabei die Effektivität verschiedener Schulungsmaterialien, welche direkt nach einem Klick auf den präparierten Link angezeigt wurden, untersucht. Dabei zeigen sie auf, dass der Schulungserfolg durch Phishing-Simulationen, wider der bisherigen Erwartung, nicht oder nur minimal gegeben ist. Im Vergleich der verschiedenen Kampagnen über einen Zeitraum von acht Monaten konnte keine signifikante Änderung des Klickverhaltens der Mitarbeitenden dokumentiert werden. Ein Vergleich des Durchführungsdatums einer jährlichen webbasierten Sicherheitsschulung mit dem Klickverhalten einzelner Mitarbeitenden zeigte, dass solche Trainings nahezu keinen Einfluss auf die Awareness der Mitarbeitenden hatten. Interaktives Trainingsmaterial, welches nach einem Klick angezeigt wurde, konnte zur Steigerung der Awareness beitragen, jedoch wurde dieses Trainingsmaterial in den allermeisten Fällen nicht betrachtet. 

Deshalb sollten Phishing-Simulationen nur als ein Bestandteil eines Gesamtkonzepts für Awareness betrachtet werden. Um die Sicherheit unmittelbar zu erhöhen, sollte auf technische Maßnahmen gesetzt werden. Beispielsweise kann man mit der Verwendung von FIDO2 bzw. dem Einsatz von Passkeys die Möglichkeit eines Phishing-Angriffs zum Abgreifen von Zugangsdaten eliminieren. Jedoch sollte der Faktor Mensch dadurch nicht außer Acht gelassen werden, da mittels Phishing nicht nur Passwörter abgegriffen werden können. Durch Social Engineering könnten Mitarbeitende in schadhaften Mails oder in Telefonanrufen beispielsweise dazu bewegt werden, Überweisungen zu tätigen oder schadhaften Code auszuführen. Der Modus, wie geschult wird, muss sich also ändern.  

Es sollte allen Personen im Unternehmen klar sein, worauf es bei E-Mails zu achten gilt und vor allem, welche Möglichkeiten es im Unternehmen gibt, um Phishing E-Mails zu melden oder prüfen zu lassen. Hierzu sollte eine niederschwellige Lösung wie z. B. ein extra Button im E-Mail-Client verfügbar sein. Eine kurze Zeit bis zur ersten Meldung und eine hohe Melderate sind ausschlaggebend, damit ein Unternehmen schnell auf Phishing-Angriffe reagieren und Schäden abwenden kann. 

Wofür können Phishing-Simulationen trotzdem noch verwendet werden? 

Bisher wurden Phishing-Simulationen als Schulungsmaßnahme betrachtet, welche eingesetzt wird, um den Mitarbeitenden eine reale Erfahrung in einer geschützten Umgebung zu bieten. Dabei haben die Mitarbeitenden die Möglichkeit, Fehler zu machen, ohne Konsequenzen zu fürchten. Es wurde bisher davon ausgegangen, dass die direkte Präsentation von Schulungsmaterial nach dem Fehlverhalten einen erhöhten Schulungseffekt im Vergleich zu normalen Schulungen hat. Der Weiterbildungsaspekt tritt bei solchen Simulationen als alleinstehende Maßnahme allerdings nicht wie gewünscht ein. 

Nichtsdestotrotz kann ein Unternehmen durch Phishing-Simulationen weiterhin interessante Einsichten erhalten, gerade um einen ersten Überblick über die Resilienz zu bekommen. Die Szenarien sollten jedoch individuell auf den Kunden und die gewünschten Zielgruppen abgestimmt sein. Wenn in den Phishing-Simulationen im Gegensatz zur Studie auch die Login-Eingabe-Rate und die Melderate erhoben werden, kann ein sinnvoller Überblick über die potenziellen Auswirkungen eines Phishing-Angriffs aufgezeigt werden. Eine möglichst hohe Melderate ist für die IT-Abteilung wichtig. Nur so kann beispielsweise entschieden werden, ob eine kurzfristige Kommunikation an alle Beschäftigten notwendig ist. Hierbei sind insbesondere eine kurze Zeit bis zur ersten Meldung und wohldefinierte nachgelagerte Prozesse notwendig, um schnell agieren zu können und Schaden durch übermittelte Zugangsdaten einzugrenzen. 

Auch hierbei sei gesagt, natürlich handelt es sich bei den Ergebnissen einer Phishing-Simulation lediglich um eine grobe Momentaufnahme. Verminderte Klickrate durch Abwesenheiten, eine interne Kommunikation über Phishing-Aktivitäten oder das Klicken und Eingeben von Daten aus Neugierde können die Ergebnisse verfälschen. Dennoch kann die Simulation mit begleitender Kommunikation das Thema Phishing bei den Mitarbeitenden in Erinnerung rufen. 

Gibt es Alternativen zu klassischen Phishing-Simulationen? 

Wenn Phishing-Simulationen nun nicht die Erwartungen erfüllen können, die man sich wünscht: Gibt es Alternativen, die einen anderen Ansatz verfolgen? 

Tatsächlich gibt es eine ähnliche Schulungsmaßnahme mit einem anderen Ansatz. Im Security Blog von Google wurden sogenannte Phishing Drills vorgeschlagen. Bei einem Phishing Drill ist der Aufbau der Maßnahme im ersten Schritt ähnlich. Der oder die Mitarbeitende erhalten eine E-Mail. Diese E-Mail enthält allerdings eine klare Aussage: „Ich bin eine Phishing-E-Mail!“ und „an den folgenden Kriterien kann dies festgestellt werden“. Des Weiteren wird den Mitarbeitenden der interne Meldeweg erklärt und sie werden animiert, den Meldeweg für diese E-Mail einmal praktisch zu üben, um den Ablauf im Umgang mit erkannten Phishing E-Mails zu verinnerlichen. Bei klassischen Phishing-Kampagnen interagieren üblicherweise ausschließlich die Mitarbeitenden mit dem Schulungsmaterial, welche auf die simulierte Phishing-E-Mail hereingefallen sind. Diese Thematik wird auch in der genannten Studie adressiert. Ein Phishing-Drill wirkt dem entgegen, indem alle Mitarbeitenden in die Maßnahme einbezogen werden. Er kann wie eine Brandschutzübung verstanden werden, in der die Mitarbeitenden die relevanten Meldewege und Prozesse in Erinnerung rufen und aktiv durchlaufen. 

Insgesamt können klassische Phishing-Simulationen alleinstehend keine umfassende Wirkung entfalten. Auf die jeweilige Umgebung abgestimmte Kampagnen sollten vielmehr als Teil eines übergeordneten Ansatzes mit weiteren Maßnahmen, wie dem Schaffen einer guten Meldekultur ohne ein Gefühl der Angst, ausgereiften und zielgruppenorientierten Schulungsformaten, Phishing-Drills und einer bewussten internen Kommunikation, angesehen werden. 

Referenzen:

Allgemein, Risikomanagement, Schwachstelle, Supply Chain

Drohende Abschaltung der CVE-Datenbank und mögliche Alternativen

Kurz vor Ostern schreckte eine Nachricht des CVE-Teams die Sicherheitswelt auf. Die Finanzierung des CVE-Programms stand auf der Kippe und im Extremfall wäre einen Tag später bereits Schluss gewesen. Der Aufschrei war zu Recht groß und so konnte der Betreiber MITRE eine Vertragsverlängerung bis Anfang nächsten Jahres erreichen. Aber was kommt dann?  

In diesem Blogpost wollen wir mit etwas Abstand zu den Ereignissen zusammenfassen, welche Alternativen in der Diskussion um eine mögliche CVE-Abschaltung oft genannt wurden und ob sie tatsächlich in die Fußstapfen von CVE treten könnten.  

Anwendungsfälle

Zuerst wollen wir uns kurz anschauen, wo wir und viele unserer Kunden Berührungspunkte mit CVE haben. Es gibt darüber hinaus weitere Anwendungsfälle, aber für diese häufigen Nutzungen wollen wir uns im Folgenden die Alternativen anschauen. 

Risikomanagement im ISMS 

Beim Thema Informationssicherheit denken viele Laien als Erstes an die Sicherheitsupdates, die ihre Geräte regelmäßig von ihnen fordern. Im professionellen ISMS kommt noch dazu, dass einige Updates nur mit einer Betriebsunterbrechung eingespielt werden können oder unerwünschte Nebenwirkungen haben. Es muss also eine bewusste Entscheidung zwischen dem neu hinzugekommenen Sicherheitsrisiko und den betrieblichen Einschränkungen getroffen werden. Wenn eine Sicherheitslücke bereits bekannt ist, aber noch kein Patch verfügbar ist, wird die Entscheidung zwischen Abschalten und Risikoakzeptanz noch herausfordernder. 

Die reinen CVE-Nummern können in dem Anwendungsfall bei der weitergehenden Recherche helfen oder teilweise den Abgleich von verschiedenen Prüfformen ermöglichen (z.B. ob die im Pentest erkannten Lücken, bereits aus einem anderen Audit adressiert werden). 

Meist nutzt man jedoch auf CVE-basierte Datenbanken wie die National Vulnerability Database (NVD) der US-Regierung oder Ableitungen davon, die bereits eine allgemeine Risikobewertung mitbringen. Damit können bereits erkannte Risiken schneller und ressourcensparsam vorbewertet werden. Das konkrete Risiko für die jeweilige Betriebssituation muss man dennoch individuell bewerten (z.B. ob die betroffene Funktion überhaupt genutzt wird). 

Außerdem nutzen viele Informationsdienste und Vulnerability-Management-Tools CVE-basierte Datenbanken, um auf neu bekanntgewordene Schwachstellen hinzuweisen. Im besten Fall wählt man als Betreiber alle genutzten Softwareprodukte aus und wird dann aktiv auf neue Schwachstellen hingewiesen. 

Schwachstellenscan für Container 

Für Betreiber von containerisierten Services ist das Scannen von Containern bzw. Container-Scanning ist ein weiterer Anwendungsfall für die Nutzung von CVEs.  

Dabei werden Container-Images auf Sicherheitslücken überprüft. Zuerst wird analysiert, welche OS-Pakete, Dependencies und weitere Software in dem zu scannenden Image benutzt werden, z.B. openssl. Anschließend werden die Findings (Name der Komponente sowie Versionsnummer/-stand) mit den gängigen CVE-basierten Datenbanken wie NVD abgeglichen. Sollten bekannte Schwachstellen identifiziert werden, wird dies an das Scanning-Tool zurückgemeldet und das Tool erstellt auf Basis dieser Informationen einen Bericht. 

Der Bericht enthält dann. welche CVE gefunden wurde, wie schwerwiegend diese ist bzw. wie hoch ihr CVSS-Score ist, wo im Image die Schwachstelle gefunden wurde, und es werden in den meisten Fällen auch direkt Mitigationsmaßnahmen empfohlen. Diese Maßnahmen beziehen sich entweder auf ein Update/Upgrade der verwendeten Version auf die nächste sichere Version oder auf geeignete Konfigurationen, um die Sicherheitslücke zu schließen. 

Gängige Tools, die man für Scanning verwenden kann, sind u.a. die OpenSource Tools Trivy sowie Clair. Kommerzielle Tools, die z.B. auch einen erweiterten Support zur Verfügung stellen können oder weitere Funktionen haben, sind Snyk sowie JFrog.

Verwendet man Container-Scanning in seiner Infrastruktur, hat man den großen Vorteil, dass Schwachstellen noch vor dem Deployment entdeckt werden können. Auch ist das Container-Scanning in CI/CD-Pipelines automatisierbar und bietet so eine weitere Dosis Sicherheit. 

Software Supply Chain 

Nicht nur Betreiber, sondern auch Softwareanbieter benötigen ein Risikomanagement. Sicherheitsrelevante Fehler in genutzten Komponenten, Bibliotheken und Hilfstools können sich auch auf die ausgelieferte Software übertragen. Angriffe, die gezielt auf diese Vererbung der Sicherheitslücken abzielen, werden Software-Supply-Chain-Angriff genannt. 

Die reinen CVE-Nummern helfen den Softwareanbietern bei der Kommunikation. In ihren Release-Notes können sie ihren Kunden eindeutig aufzeigen, welche Schwachstellen (eigene und von Drittkomponenten geerbte) beseitigt wurden. Die Kunden können die Information dann mit ihrem eigenen Risikomanagement aus Betriebssicht abgleichen. Die CVE-Nummer kann aber auch gut genutzt werden, um aufzuzeigen, dass die eigene Software von einer konkreten Lücke nicht betroffen ist. So forderten beispielsweise bei der Log4Shell-Schwachstelle in der Log4j-Bibliothek viele große IT-Organisationen von ihren Zulieferern Negativbescheide, dass ihre Produkte von dieser Lücke nicht betroffen waren. 

Ähnlich wie die Scanner für Container gibt es auch Scantools, die über die Versionsstände von eingebundenen Dependencies ermitteln, ob eine neue Schwachstelle bekannt wurde. Nutzt man zum Verwalten der Abhängigkeiten einen Registry-basierten Ansatz (z.B. mit NPM), erhält man so leicht die notwendigen Informationen. Für händisch hinzugefügte Abhängigkeiten (z.B. JAR-Archiv, Binärbibliothek, JavaScript) gibt es ebenfalls Scanner, die teilweise Heuristiken einsetzen müssen, um den eindeutigen Namen der Bibliothek und die Versionsnummer zu bestimmen (z.B. RetireJS, Trivy). 

Exploits/Lücken nachvollziehen im Pentest / in der Incident Response 

Im Bereich von Penetrationstests, technischen Audits und Incident Response werden CVEs regelmäßig verwendet. Durch die eindeutige Benennung sprechen sowohl Kunden als auch Sicherheitsberatende über dieselbe Sicherheitslücke. Kunden erlaubt dies beispielsweise einfacher einzuschätzen, in welchen Versionen eine Sicherheitslücke eines eingesetzten Systemes vom Hersteller behoben wurde, da Changelogs der Hersteller und externe Quellen die CVEs zu betroffenen Versionen mappen. 

Ebenso werden anhand der CVE z.B. weiterführende Recherchen, sei es über Suchmaschinen, auf GitHub oder in dedizierten Vulnerability Databases, erleichtert. Es kann z.B. besser eingeschätzt werden, ob bereits öffentlich verfügbare Write-Ups, Exploits oder Proof-of-Concept Code existiert, der durch Angreifende verwendet werden kann. Im Incident Response kann dies als Indiz für die Ausgereiftheit der Angreifenden herangezogen werden. 

Gefundene Schwachstelle melden 

Bei der Meldung von Schwachstellen wird die gefundene Sicherheitslücke im Rahmen von Responsible Disclosure häufig bei einer CVE Numbering Authority (CNA) eingereicht, um für diese Lücke eine CVE zugewiesen zu bekommen. Da während des Prozesses der Meldung viele Parteien beteiligt sein können, z.B. die Entdeckenden der Lücke, die Herstellenden des Systems, die Personen, die das System einsetzen, oder auch Vermittelnde wie ein CERT, soll eine CVE dabei sicherstellen, dass von der gleichen Lücke gesprochen wird. Außerdem können alle Beteiligten den Fortschritt während des Prozesses der Responsible Disclosure effektiver verfolgen. Nach der Behebung einer Sicherheitslücke erlaubt eine veröffentlichte CVE der Öffentlichkeit, z.B. betroffenen Firmen, den Einfluss der Sicherheitslücke auf die eigenen Systeme zu beurteilen und ggf. Maßnahmen zu ergreifen. 

Alternativen 

Für diese Anwendungsfälle wollen wir uns jetzt mögliche Alternativen anschauen. Wir haben dabei die Ansätze ausgewählt, die in den Tagen um die drohende CVE-Abschaltung am breitesten diskutiert wurden. Einige der Ansätze sind aktuell noch nicht praktisch nutzbar oder zielen auch auf ein ganz anderes Anwendungsfeld ab. Wenn sie dennoch in der Diskussion Raum eingenommen haben, haben wir sie hier aufgegriffen. 

Das Original: MITRE CVE 

Betrieben von der Non-Government-Organization (NGO) MITRE Corporation, gilt das Common Vulnerabilities and Exposures (CVE) System als die Referenz in der Welt der IT-Sicherheit für Sicherheitslücken und Schwachstellen. Durch die Vereinheitlichung der Nummerierung von Sicherheitslücken ist jederzeit eindeutig, auf welcher Sicherheitslücke man sich bezieht.  

Dadurch ist das Kürzel “CVE” für einige auch schon zum Synonym für “Sicherheitslücke” geworden und wird meist auch mit den detaillierten Einträgen in CVE-basierten Datenbanken wie der NVD gleichgesetzt. Die CVE-Datenbank selbst enthält allerdings nur sehr wenige Informationen zur Lücke. Grundsätzlich gerade so viele Informationen, um die Lücke wiedererkennen zu können. Das Datenbankformat erlaubt auch Risikoeinschätzungen und andere Informationen, diese sind aber optional.  

Besondere Aufmerksamkeit bekam dieses System, nachdem die US-Regierung unter Trump im April 2025 die Finanzierung stoppte. Dieses System wird vom US-Heimschatzuministerium (DHS) sowie der untergeordneten Cybersecurity and Infrastructure Security Agency (CISA) unterstützt. Durch das Ziehen einer Optionsklausel im Vertrag der Förderung durch die US-Regierung, bleibt das MITRE CVE System bis 16.03.2026 am Start. Was danach passiert, kann niemand abschätzen. 

Dadurch, dass dieses System seit 1999 im Einsatz ist, hat es sich zum Standard entwickelt. Es ist daher die derzeit aktuellste, kompatibelste und vollständigste Lösung. 

Neu aufgedeckte Schwachstellen werden von den CVE Numbering Authorities (CNA) eingepflegt, nummeriert und verwaltet. Die Meldung erfolgt u.a. über ein eigenes Portal. Es können jedoch auch vorgefertigte sowie selbst programmierte Clients verwendet werden. Eine CVE kann bereits vor der Veröffentlichung beantragt werden, und für die Zuweisung erfolgt meist nur eine grobe Prüfung. Eine zugewiesene CVE bedeutet also nicht automatisch, dass ein tatsächliches Risiko besteht. Zu vielen CVEs werden keine Lücken veröffentlicht – so wurden z.B. 2023 ca. 40.000 CVEs reserviert, aber nur ca. 29.000 veröffentlicht. 

Die reinen CVE-Nummern bilden nur einen Teil der Anwendungsfälle ab, insbesondere liefern sie nicht unbedingt eine Risikobewertung. Sie bilden aber die Basis für viele darauf aufbauende Datenbanken wie die NVD. 

Wird oft mit CVE verwechselt: NIST National Vulnerability Database (NVD) 

Die National Vulnerability Database (NVD) wird von der US-Behörde NIST betrieben und oft mit CVE verwechselt. Beide sind auch eng miteinander verknüpft – für jede CVE im Zustand “veröffentlicht” wird automatisch ein Eintrag in der NVD erzeugt. Während die CVE-Datenbank nur rudimentäre Informationen zur Lücke enthält, wird der Eintrag in der NVD noch um weitere Informationen wie einen Risikoscore nach dem Industriestandard Common Vulnerability Scoring System (CVSS) oder Links zu weiteren Informationen ergänzt. 

Diese Informationen werden teilweise manuell ergänzt. Im Frühjahr 2024 kam es dabei zu einer Überlastung des zuständigen Teams, und es wurden für mehrere Monate keine Ergänzungen insbesondere auch keine Risikobewertungen eingepflegt. Durch den Einsatz von externen Partnern konnte der Stau aufgelöst und das System resilienter gemacht werden, aber wie bei CVE zeigt der Vorfall, wie stark die NVD vom amerikanischen Bundeshaushalt abhängt. 

Die NVD-Daten stehen auch als strukturierte Daten im Security Content Automation Protocol (SCAP) Format zur Verfügung und können ohne Einschränkungen verwendet werden. Daher setzen viele Tools und auch Schwachstellen-Webseiten die NVD-Daten direkt ein oder nutzen sie als Basisdatensatz, der durch eigene Erkenntnisse ergänzt wird. Da die NVD nicht zwingend genannt werden muss, ist der Zusammenhang nicht immer direkt erkennbar. 

Fast alle unserer Anwendungsfälle kann die NVD bedienen. Lediglich neue Lücken können nicht direkt bei der NVD gemeldet werden – hier muss eine CVE beantragt werden und damit entsteht automatisch auch der NVD-Eintrag. 

CVE Foundation 

Die Meldung, dass die US-Regierung die Förderung von MITRE CVE einstellen will, sorgte berechtigterweise für eine Menge Wirbel in der globalen Cybersecurity Szene. Angetrieben durch dieses Ereignis sowie dem schon länger existierenden Wunsch noch neutraler und nachhaltiger auftreten zu können (und nicht an eine Regierung gebunden zu sein) entschieden sich diverse Vorstandsmitglieder des CVE-Systems ihre eigene (non-profit) Stiftung zu gründen, um die Finanzierung des MITRE Programms zu realisieren. 

Die CVE Foundation ist daher keine Alternative zu bestehenden Programmen und will es nach unserem Kenntnisstand auch gar nicht werden. Aktuell befindet sich die Stiftung noch im Aufbau – Informationen dazu wie es weitergeht und was die nächsten Schritte sein werden, sind daher rar. In ihren eigenen FAQs werden lediglich einige Fragen zum Auftrag sowie einige der baldigen Vorstände benannt. 

Unsere Anwendungsfälle wären bei einer CVE-Stiftung genauso abgedeckt wie bisher. Wenn die Stiftung die bestehende Datenbank und Nummerierung übernehmen würde, gäbe es auch keinen Umstellungsaufwand. 

Common Security Advisory Framework (CSAF)

Ein weiterer Name, der in diesen Zusammenhängen immer wieder genannt wurde, ist das Common Security Advisory Framework (CSAF). Dahinter verbirgt sich eine technische Spezifikation für einen verteilten Ansatz. Eine vertrauenswürdige Instanz wie aktuell beispielsweise das Bundesamt für Sicherheit in der Informationstechnik (BSI) pflegt eine Liste von Organisationen, die Sicherheitslücken dokumentieren. Diese wiederum veröffentlichen die Sicherheitslücken in einem strukturierten Format (JSON). 

Laut der eigenen FAQ sieht sich CSAF nicht als CVE-Ersatz. Der Standard bietet ein optionales Feld für die CVE-Nummer an, und in der Technischen Richtlinie TR-03191 des BSI ist die CVE-Nummer sogar verpflichtend. In CSAF geht es eher um die Details zu jeder Lücke, man kann CSAF also eher als eine dezentrale Alternative zur NVD-Datenbank betrachten. 

Die Anwendungsfälle, in denen die Eindeutigkeit der CVE-Nummer im Vordergrund steht – z.B. als Ordnungsmerkmal im Risikomanagement oder als eindeutige Kennung in der Software Supply Chain – können von CSAF nicht abgebildet werden. CSAF-Dokumente haben zwar eindeutige Kennungen, aber zwei Dokumente können sich auf die gleiche Lücke beziehen. 

Als Informationsbasis und insbesondere als Datenbasis für Scan-Tools eignen sich die CSAF-Dokumente dagegen gut. Die CSAF-Seite verzeichnet direkt einige passende Tools. Es gibt jedoch keinen Automatismus wie bei der NVD, der für jede veröffentlichte CVE zumindest einen rudimentären Eintrag erzeugt. 

Global CVE Allocation System (GCVE)

Das Global CVE Allocation System (GCVE) ist ein neuer Ansatz vom Computer Incident Response Center Luxembourg (CIRCL), bei dem statt einer zentralen Instanz wie MITRE die Vergabe von IDs für Sicherheitslücken dezentral stattfinden soll. Zwar gibt es im traditionellen CVE-System auch verschiedene Vergabestellen für CVEs – sogenannte CVE Numbering Authorities (CNAs) – jedoch müssen die Vorgaben von MITRE eingehalten werden, und die Vergabe von eindeutigen IDs wird durch die zentrale Instanz gesteuert. Im GCVE wird die ID dazu im Format „GCVE-<GNA ID>-<YEAR>-<UNIQUE ID>“ vergeben. Jeder teilnehmenden Organisation wird eine sogenannte GNA ID zugeteilt, sodass die Organisationen ihren eigenen ID-Bereich unabhängig vergeben können, ohne Überschneidungen hervorzurufen. Es bleibt abzuwarten, ob die Anzahl der aktuell acht teilnehmenden Organisationen steigt und sich auch bekannte Größen dem im Aufbau befindlichen System anschließen. 

Für die oben definierten Anwendungsfälle ist es aktuell kaum nutzbar. Nur die vom CIRCL betriebene Datenbank Vulnerability Lookup benutzt derzeit das Schema.  

Da die Teilbereiche unabhängig verwaltet werden, wird es Lücken geben, die mehrere GCVE-Nummern von unterschiedlichen GNA erhalten werden. Die GCVE eignet sich dann nicht als eindeutiges Ordnungsmerkmal im Risikomanagement oder in der Software Supply Chain. 

European Vulnerability Database (EUVD) 

Eigentlich noch im Probebetrieb wurde die europäische Antwort auf die NVD im Zuge der drohenden CVE-Abschaltung kurzerhand öffentlich verfügbar gemacht. Die Datenbank ist noch in der Beta-Phase und soll vor allem die Korrelation aus verschiedenen Datenquellen ermöglichen.  

Da so auch Sicherheitslücken aufgenommen werden, die nicht bei der CVE gemeldet wurden, vergibt die European Network and Information Security Agency (ENISA) eigene Nummern, die mit EUVD starten. Aktuell ist das System auf eine Ko-Existenz und eine Abbildung auf CVEs ausgelegt, könnte aber bei einer CVE-Abschaltung auch problemlos weiterbetrieben werden. 

Während einzelne neuere Einträge bereits sehr viele Informationen aufweisen, konnten wir in Stichproben immer wieder Einträge finden, die entweder nur die Basis-Daten aus der CVE-Datenbank enthielten oder die im Vergleich zum korrespondierenden NVD-Eintrag viel weniger Details hatten. 

Die EUVD ist so ausgelegt, dass alle unsere oben beschriebenen Anwendungsfälle langfristig bedient werden können. Aktuell ist die Datenqualität noch nicht vergleichbar mit der NVD, und nur wenige Tools nutzen die EUVD als Datenbasis. Beides kann sich aber mit der Zeit noch ändern.  

Ob die EUVD-Nummern die etablierten CVE-Nummern als eindeutige Kennung ersetzen können, ist noch offen. Da die EUVD Teil der NIS2-Richtlinie der EU ist und von den europäischen Informationssicherheitsbehörden gemeinsam genutzt wird, stehen die Chancen aber zumindest für Europa nicht schlecht. 

Single Reporting Platform (SRP) des europäischen Cyber Resilience Act (CRA) 

Neben der NIS-2-Richtlinie, die vor allem auf den sicheren IT-Betrieb abzielt, macht die EU im Cyber Resilience Act (CRA) Informationssicherheitsvorgaben für Produkte. Darin sind auch Vorgaben wie Schwachstellen veröffentlicht werden sollen und welche Meldewege die Hersteller ermöglichen müssen. 

Eine neue geschaffene Single Reporting Platform (SRP) soll dabei eine zentrale Rolle spielen. Die Erstellung der Plattform wird gerade ausgeschrieben. Daher kann es noch keine konkrete Einschätzung geben, wie sich die SRP auf die Anwendungsfälle auswirkt. Bisher bekannt ist lediglich die Arbeitsteilung zwischen SRP und EUVD: Während die SRP auch unveröffentlichte Schwachstellen für einen beschränkten Empfängerkreis bereitstellen soll, sollen veröffentlichte Schwachstellen aus der SRP direkt in die EUVD aufgenommen werden. 

Was müssen Anwender jetzt tun? 

Bis März 2026 kann erstmal alles wie bisher bleiben. Es ist jedoch ratsam, sich bereits auf mögliche Alternativszenarien nach dem Datum vorzubereiten. 

Für die Nutzung der CVE als eindeutige Kennung (im Risikomanagement, als Hersteller, als Entdecker), kann man bereits jetzt anfangen, zusätzlich eine der alternativen Kennungen wie die EUVD-Nummer zu dokumentieren. Idealerweise spricht man mit Kunden und Lieferanten über die Alternativen und findet vielleicht eine gemeinsame Alternative. 

Bei den Scan-Tools und Informationsdiensten (fürs ISMS, Container, Software) sollte man rechtzeitig prüfen, auf welchen Daten sie basieren. Nutzen sie einfach die NVD oder binden sie bereits heute verschiedene Datenbanken (die nicht nur Kopien der NVD sind) an? Möglicherweise müssen Tools und damit die daran hängenden Prozesse ausgetauscht werden, um mehr Datenquellen nutzen zu können.