Damit Schwachstellen und Sicherheitslücken geschlossen werden können, ist es zuallererst wichtig, diese eindeutig benennen zu können. Cybersecurity-Expert*innen nutzen dafür die CVE-Datenbank, welche von US-amerikanischen Behörden betrieben wird.
Am Beispiel der von MITRE betriebenen CVE-Datenbank (Common Vulnerabilities and Exposures, https://cve.mitre.org/), deren staatliche Finanzierung durch die USA kurzfristig gefährdet war, wird deutlich, warum echte europäische Lösungen für digitale Souveränität unerlässlich sind. Es stellt sich die Frage, ob wir die Informationssicherheit unserer kritischen Infrastrukturen vom Goodwill der USA oder anderer autokratischer Staaten abhängig machen wollen. Unabhängigkeit von staatlicher Einflussnahme ist essenziell, denn nur dann werden auch solche Schwachstellen enummeriert werden, die von staatlichen Behörden für offensive Cyberoperationen ausgenutzt werden. Als Negativbeispiele für unvollständige oder zensierte nationale Schwachstellendatenbanken gelten die chinesische CNNVD und die russische BDU.
Kurzfristig ist die Finanzierung der CVE-Datenbank für die nächsten elf Monate gesichert. Dabei wurde jedoch offensichtlich, wie viele Tools, Unternehmen und Behörden alternativlos von dieser einen staatlich kontrollierten Datenbank abhängig sind. Jetzt bietet sich die Chance für eine souveräne europäische Lösung: Die ENISA veröffentlichte innerhalb weniger Stunden eine Beta-Version ihrer European Union Vulnerability Database (EUVD). Derzeit verweist diese allerdings noch häufig auf CISA und NIST.
Trotz berechtigter Kritik ermöglicht das CVE-System eine einheitliche Identifikation und Katalogisierung von Schwachstellen. Noch ist unklar, wie eine unabhängige und standardisierte Vergabe von Identifikationsnummern in Zukunft koordiniert werden kann, sollte es mehrere parallele Systeme zur Schwachstellenkatalogisierung geben. Ideal wäre eine unabhängige Struktur mit gesicherter Finanzierung.
Grundsätzlich lassen sich mehrere Modelle unterscheiden:
- Unkoordinierte Schwachstellen-Identifikation
Keine Standardisierung von IDs, keine zentrale Datenbank. Wie bei der Benennung von Malware oder APT-Gruppen würden dann zahlreiche unterschiedliche IDs für dieselbe Schwachstelle existieren. - Zentrale Schwachstellen-Identifikation
Eine global gültige, zentrale Registry zur Verwaltung von Ids und der Vergabe von Rechten, wer IDs beantragen darf. Voraussetzung: Unabhängigkeit von staatlichen Stellen und langfristige Finanzierung. - Community-basierte Schwachstellen-Identifikation
Ein öffentliches Repository, in dem jede*r Informationen und IDs beitragen kann – ähnlich wie bei Wikipedia. Frühere Versuche sind jedoch alle gescheitert, wie z. B. DWF (Distributed Weakness Filing), GSD (Global Security Database), OSVDB (Open Source Vulnerability Database). - Dezentrale Schwachstellen-Identifikation
Ein globaler Standard definiert Format und Algorithmus zur eigenständigen ID-Erstellung. Das Erfassen und Veröffentlichen bleibt dezentral den Beitragenden überlassen.
Aufgrund schlechter Erfahrungen bei der Malware-Identifikation ist vom unkoordinierten Modell dringend abzuraten. Eine eindeutige Identifikation von Sicherheitsproblemen – ob Malware, Schwachstelle oder Exploit – erleichtert den Informationsaustausch erheblich und ist gerade für die schnelle Kommunikation bei Vorfällen im KRITIS Bereich wertvoll.
Das zentrale Modell entspricht im Wesentlichen dem CVE-System, sollte aber durch eine transparente Finanzierung und Unabhängigkeit von staatlichem oder kommerziellem Einfluss weiterentwickelt werden. Die von ENISA betriebene EUVD könnte in diese Richtung gehen – auch hier bleibt die Frage der staatlichen Unabhängigkeit offen, scheint aber noch gestaltbar.
Ein Community-Modell bietet viele Vorteile und funktioniert bei anderen Wissensplattformen gut. Allerdings erfordert die Pflege tagesaktueller Schwachstelleninformationen erheblichen Aufwand, der kaum auf ehrenamtlicher oder spendenfinanzierter Basis tragbar ist. Zudem beruhen viele Geschäftsmodelle im Bereich Cybersicherheit auf der kommerziellen Nutzung dieser öffentlich verfügbarer Daten. Diese Tatsache hemmt freiwilliges Engagement, wie die gescheiterten Versuche zeigen.
Ein globaler Standard zur einheitlichen aber dezentralen Vergabe von Schwachstellen-IDs – idealerweise auch für Malware und APTs – erscheint als beste Lösung. Universally Unique Identifiers (UUIDs) nach RFC 9562, die auch zeitstempelbasierte IDs ermöglichen, bieten einen geeigneten Ansatz. Durch die Beschränkung auf die reine ID-Koordination ließe sich der Verwaltungsaufwand minimieren. Viele Zusatzinformationen in CVE- und NVD-Datenbanken sind ohnehin oft unzureichend verifiziert und in der Praxis wenig hilfreich. Der Fokus sollte auf Werkzeugen liegen, die Schwachstellen eindeutig identifizieren und praxisnahe Anleitungen zu Patches und Updates liefern, statt komplizierte Scores und Dashboards bereitzustellen.
Ohne eine gute, unabhängige Lösung zur Schwachstellen-Katalogisierung drohen kritischen Infrastrukturen:
- Verzögerte Einschätzung und Behebung von Softwarefehlern
- Ausfall von Sicherheitswerkzeugen wie Scannern, Verteidigungssystemen und Dashboards
- Fehlende gemeinsame Sprache für den weltweiten Austausch von Bedrohungsinformationen
Vorerst bleibt das MITRE-CVE-Programm bestehen – doch niemand weiß, wie lange noch. Jetzt ist der richtige Zeitpunkt für eine globale Lösung, die nicht von Nationalstaaten abhängig ist.
Die AG KRITIS fordert daher die deutsche Bundesregierung auf, sich auf der europäischen Ebene für den Aufbau einer wirklich unabhängigen Schwachstellendatenbank unter Führung der ENISA einzusetzen. Wer 100 Milliarden Euro für „KI-Gigafactorys“ ausgeben will, der kann nicht behaupten, die etwa 20-30 Mio € im Jahr, die für den Betrieb der CVE-Datenbank benötigt werden, nicht zu haben.
Egal wie sich die europäische Digitalwirtschaft entwickelt und welche mehr- oder weniger innovativen Vorhaben von SpitzenpolitikerInnen im nächsten Hype-Zyklus präsentiert werden – Auf dem Boden der Tatsachen braucht es auch weiterhin ein Fundament aus größtmöglicher IT-Sicherheit.
Wir Europäer haben nun die Chance, die Kritikpunkte die es am CVE-System gibt, durch Schaffung eines besseren Systems auszuräumen und genau dies fordern wir.
Referenzen:
Zu CNNVD und BDU: https://www.darkreading.com/cyberattacks-data-breaches/russian-national-vulnerability-database-operation-raises-suspicions
CVE Kritik: https://lwn.net/Articles/679315/
DWF: https://seclists.org/oss-sec/2016/q1/560
GSD: https://cloudsecurityalliance.org/blog/2022/02/22/why-we-created-the-global-security-database
GSD: https://github.com/CloudSecurityAlliance/gsd-database
OSVDB: https://en.wikipedia.org/w/index.php?title=Open_Source_Vulnerability_Database&oldid=1247288031
OSVDB: https://web.archive.org/web/20191124210140/https://www.networkworld.com/article/3053613/open-source-vulnerabilities-database-shuts-down.html
OSVDB Lizenzfrage: https://www.theregister.com/2014/05/08/whats_copyright_mcafee_mcslurps_vuln_database/
Virus Namensschema: https://bontchev.nlcv.bas.bg/papers/naming.html
Malware Bennungsprobleme: https://www.gdatasoftware.com/blog/2019/08/35146-taming-the-mess-of-av-detection-names
RFC 9562: Universally Unique IDentifiers (UUIDs) https://www.rfc-editor.org/rfc/rfc9562
Picture by Antony-22 – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=60094941
Vielen Dank an unsere Mitglieder Lioba und random für das Anfertigen dieses Artikels
