Koordinierte Schwachstellenoffenlegung: Ein neuer Rahmen für Forscher

Wer sollte das lesen: Sicherheitsforscher, Koordinatoren für Schwachstellenoffenlegung, Produktsicherheitsteams, Cybersicherheitspolitik-Entscheider.

Für Sicherheitsforscher stellt das Aufkommen der NIS2-Richtlinie sowohl eine Chance als auch eine Verpflichtung dar. Die Richtlinie etabliert in Artikel 12 ausdrücklich einen Rahmen für die koordinierte Schwachstellenoffenlegung (CVD) und schafft institutionelle Strukturen und Prozesse, durch die Forscher Schwachstellen verantwortungsvoll melden können. Das ist bedeutsam: Die Richtlinie erkennt an, dass verantwortungsvolle Offenlegung Koordination erfordert, dass Forscher eine kritische Rolle bei der Verbesserung der Sicherheit spielen und dass vertrauenswürdige Prozesse notwendig sind, damit die Offenlegung effektiv funktioniert. Wenn Sie Forscher, Schwachstellenkoordinator oder im Produktsicherheitsbereich tätig sind, ist das Verständnis von Artikel 12 und des dadurch geschaffenen europäischen Schwachstellenoffenlegungs-Ökosystems unerlässlich.

Die koordinierte Schwachstellenoffenlegung ist nicht neu; Sicherheitsforscher legen seit Jahrzehnten verantwortungsvoll Schwachstellen offen. Neu ist die Schaffung eines formellen, EU-weiten Rahmens mit dediziertem institutionellem Rückhalt. Die Richtlinie etabliert in jedem Mitgliedstaat als Koordinatoren benannte CSIRTs, schafft eine europäische Schwachstellendatenbank und legt Verfahren für den Umgang mit Schwachstellen fest, die Grenzen überschreiten oder mehrere Anbieter betreffen. Diese Infrastruktur schafft einen vertrauenswürdigen Weg für verantwortungsvolle Offenlegung und schützt Forscher vor rechtlicher Haftung, wenn sie Schwachstellen in gutem Glauben offenlegen.

Die Rolle des Koordinator-CSIRT

Gemäß Artikel 12(1) muss jeder Mitgliedstaat eines seiner Computer Security Incident Response Teams (CSIRTs) als Koordinator für die Schwachstellenoffenlegung benennen. Dieses Koordinator-CSIRT hat mehrere spezifische Funktionen, die für das NIS2-Schwachstellenökosystem grundlegend sind.

Erstens agiert das Koordinator-CSIRT als vertrauenswürdiger Vermittler. Wenn Sie eine Schwachstelle entdecken und verantwortungsvoll offenlegen möchten, können Sie sie an das Koordinator-CSIRT Ihres Mitgliedstaats melden. Das CSIRT identifiziert dann den betroffenen Anbieter oder Hersteller und vermittelt die Kommunikation zwischen Ihnen und ihm. Diese Vermittlerrolle ist wichtig, weil sie Ihre Anonymität schützt, falls Sie diese wünschen, und weil sie eine neutrale dritte Partei schafft, die helfen kann, die unvermeidlichen Reibungen zu bewältigen, die manchmal zwischen Forschern und Anbietern während der Offenlegung auftreten.

Zweitens unterstützt Sie das Koordinator-CSIRT als Forscher. Wenn Sie Anleitung benötigen, wie Sie Ihre Offenlegung strukturieren, wie Sie Ihre Befunde testen, ohne Schaden zu verursachen, oder wie Sie die Kommunikation mit einem schwierigen Anbieter gestalten, kann der CSIRT-Koordinator helfen. Das ist nicht nur ein nettes Extra; es ist ein formeller Dienst, der allen Forschern, die Schwachstellen in Europa melden, zur Verfügung steht.

Drittens verhandelt das Koordinator-CSIRT Offenlegungsfristen und verwaltet Schwachstellen, die mehrere Einrichtungen betreffen. Wenn Ihre Schwachstelle drei verschiedene Anbieterprodukte betrifft, wird das Koordinator-CSIRT daran arbeiten, die Offenlegung über diese Anbieter zu synchronisieren und sicherzustellen, dass Patches koordiniert sind und die Offenlegung etwa zur gleichen Zeit erfolgt. Dies verhindert die Situation, in der ein früher Offenleger benachteiligt wird, weil er patcht, bevor andere dieselbe Schwachstelle behoben haben.

Artikel 12(1) erlaubt Forschern ausdrücklich, Schwachstellen anonym an das Koordinator-CSIRT zu melden, falls sie dies wünschen. Das CSIRT muss eine sorgfältige Nachverfolgung Ihres Berichts sicherstellen und Ihre Anonymität während des gesamten Prozesses wahren, falls Sie dies verlangen. Dies ist ein bedeutender Schutz, insbesondere für Forscher in kleineren Mitgliedstaaten oder weniger entwickelten Cybersicherheitsökosystemen, in denen die Anonymität von Forschern sonst schwer zu garantieren wäre.

Wenn eine Schwachstelle erhebliche Auswirkungen auf Einrichtungen in mehreren Mitgliedstaaten haben könnte, müssen die Koordinator-CSIRTs jedes betroffenen Mitgliedstaats zusammenarbeiten. Wenn Sie eine Schwachstelle in einem DNS-Root-Nameserver oder in der Infrastruktur eines großen Cloud-Anbieters entdecken, könnte das Ausmaß der potenziellen Auswirkung leicht Grenzen überschreiten. Das CSIRT-Netzwerk wird den Offenlegungsprozess koordinieren, um eine kohärente Reaktion in ganz Europa sicherzustellen.

Die europäische Schwachstellendatenbank

Artikel 12(2) verlangt von der ENISA (Agentur der Europäischen Union für Cybersicherheit), eine europäische Schwachstellendatenbank zu entwickeln und zu unterhalten. Diese Datenbank unterscheidet sich von bestehenden Schwachstellen-Repositorien wie der National Vulnerability Database (NVD) oder dem CVE-System von Mitre. Sie ist europaspezifisch und spielt eine besondere Rolle im NIS2-Rahmen.

Die europäische Schwachstellendatenbank enthält Informationen über öffentlich offengelegte Schwachstellen in IKT-Produkten und IKT-Diensten. Bemerkenswert ist, dass sie freiwillig ist; Anbieter und Forscher können wählen, Schwachstellen zu registrieren, und die Teilnahme ist nicht vorgeschrieben. Allerdings ist die Datenbank darauf ausgelegt, als zentraler Bezugspunkt für Schwachstelleninformationen zu dienen, die für europäische Einrichtungen und Regulierungsbehörden besonders relevant sind.

Die Datenbank umfasst vier Schlüsselkategorien von Informationen. Erstens enthält sie Beschreibungen der Schwachstelle selbst: was sie ist, welche Systeme sie betrifft und unter welchen Bedingungen sie ausgenutzt werden kann. Zweitens spezifiziert sie die betroffenen IKT-Produkte und -Dienste sowie die Schwere der Schwachstelle. Drittens liefert sie Informationen über Patches: ob Patches verfügbar sind, wann sie veröffentlicht wurden und wo sie bezogen werden können. Viertens, falls Patches nicht verfügbar sind, liefert die Datenbank Anleitung der zuständigen Behörden oder CSIRTs, wie Nutzer die Schwachstelle abmildern können.

Für Forscher bietet diese Datenbank mehrere Vorteile. Die Veröffentlichung Ihrer Schwachstelleninformationen in der europäischen Schwachstellendatenbank verleiht ihnen offizielle Anerkennung im Rahmen der Cybersicherheits-Governance der EU. Betroffene Organisationen in der gesamten EU können die Schwachstelle entdecken, auf technische Details zugreifen und Patch-Informationen aus einer vertrauenswürdigen, offiziellen Quelle finden. Das reduziert die Wahrscheinlichkeit, dass Schwachstelleninformationen über verschiedene Plattformen fragmentiert oder in der Übersetzung zwischen verschiedenen nationalen Regulierungssystemen verloren gehen.

Die Datenbank unterstützt auch das, was die Richtlinie „alle Beteiligten” nennt. Das umfasst Anbieter und Hersteller (die die Datenbank auf Schwachstellen überwachen können, die ihre Produkte betreffen), Sicherheitsteams in Unternehmen (die die Datenbank zur Verfolgung von Schwachstellen verwenden können, die ihre Infrastruktur betreffen) und politische Entscheidungsträger (die die Datenbank verwenden können, um aufkommende Schwachstellen-Trends zu verstehen und Ressourcen entsprechend zuzuweisen).

Governance der Schwachstellenoffenlegung

Der Rahmen, den Artikel 12 etabliert, spiegelt mehrere wichtige Prinzipien wider, die die Schwachstellenoffenlegung unter NIS2 regeln.

Das erste ist das Prinzip des legitimen Schutzes. Forscher, die Schwachstellen in gutem Glauben gemäß dem Rahmen aus Artikel 12 offenlegen, haben rechtlichen Schutz. Das ist kritisch. Ohne rechtlichen Schutz würden Forscher zögern, verantwortungsvoll offenzulegen, und Schwachstellen würden stattdessen auf dunklen Märkten verkauft oder für kriminelle Zwecke verwendet. Die Richtlinie macht klar, dass die koordinierte Schwachstellenoffenlegung ein öffentliches Gut ist und dass Forscher, die daran teilnehmen, die Unterstützung der Richtlinie haben.

Das zweite ist das Prinzip der angemessenen Fristen. Die Richtlinie schreibt kein spezifisches Offenlegungsfenster vor (etwa „Anbieter müssen innerhalb von 30 Tagen patchen”), weil solche Fenster nicht universell angemessen sind. Einige Schwachstellen sind trivial zu patchen; andere erfordern erheblichen Entwicklungsaufwand. Einige Anbieter haben schnelle Veröffentlichungszyklen; andere veröffentlichen Patches vierteljährlich. Der Rahmen verlangt, dass Fristen „verhandelt” werden, was bedeutet, dass Koordinatoren die Diskussion zwischen Forschern und Anbietern erleichtern sollten, um eine angemessene Frist zu vereinbaren, die der spezifischen Komplexität der Schwachstelle und dem Entwicklungszyklus des Anbieters Rechnung trägt.

Das dritte ist das Prinzip der gestaffelten Reaktion. Wenn ein Anbieter nicht reagiert oder trotz einer Fristvereinbarung nicht patcht, sollte der Prozess eskalieren. Ein Forscher kann an das Koordinator-CSIRT eskalieren, das versuchen kann, einen alternativen Kontakt innerhalb der Anbieterorganisation zu finden, oder an die nationale zuständige Behörde des Anbieters eskalieren. Dieser gestaffelte Ansatz verleiht Forschern Hebelwirkung und erhält gleichzeitig einen geordneten Prozess.

Das vierte ist das Prinzip des Rechts der betroffenen Einrichtungen auf Information. Artikel 12(1) verlangt, dass Koordinatoren eine sorgfältige Nachverfolgung sicherstellen, was beinhaltet, dafür zu sorgen, dass Anbieter über Schwachstellen Bescheid wissen, die ihre Produkte betreffen. Wenn ein Anbieter einen Schwachstellenbericht nicht anerkennt, sollte der CSIRT-Koordinator die Angelegenheit weiterverfolgen, bis der Anbieter reagiert oder es klar wird, dass der Anbieter nicht reagiert.

Verantwortlichkeiten und bewährte Praktiken der Forscher

Artikel 12 schafft Chancen für Forscher, impliziert aber auch Verantwortlichkeiten. Die koordinierte Schwachstellenoffenlegung im Rahmen bringt Erwartungen mit sich, wie Sie Ihre Forschung durchführen und Ihre Befunde kommunizieren.

Wenn Sie eine potenzielle Schwachstelle entdecken, sollten Sie angemessenes Vertrauen haben, dass sie real ist, bevor Sie sie offenlegen. Das bedeutet, ausreichende Tests durchzuführen, um zu bestätigen, dass die Schwachstelle existiert, und die Bedingungen zu verstehen, unter denen sie ausgenutzt werden kann. Verantwortungsvolle Offenlegung bedeutet nicht, jede theoretische Möglichkeit offenzulegen; es bedeutet, Schwachstellen offenzulegen, die Sie validiert haben.

Sie sollten der angemessenen Einrichtung gegenüber offenlegen. Für Anbieter und Hersteller, die in Europa tätig sind, sollte Ihr erster Kontakt das Sicherheitsteam des Anbieters sein (falls Sie es identifizieren können) oder Ihr nationaler CSIRT-Koordinator. Den Anbieter direkt in Ihre Offenlegung einzubeziehen, auch vor Einbeziehung des CSIRT, ist oft der effizienteste Weg, vorausgesetzt, Sie haben einen funktionierenden Sicherheitskontakt beim Anbieter. Der CSIRT-Koordinator ist verfügbar, falls direkter Anbieterkontakt scheitert oder falls Sie sich unwohl fühlen, den Anbieter direkt zu kontaktieren.

Sie sollten ausreichende technische Details liefern, damit der Anbieter die Schwachstelle verstehen und beheben kann. Das bedeutet nicht, sofort Exploit-Code zu veröffentlichen, aber es bedeutet, die Schwachstelle klar genug zu erklären, dass ein kompetenter Entwickler sie reproduzieren und die Grundursache identifizieren kann.

Sie sollten geduldig sein. Anbieter, selbst verantwortungsvolle, brauchen Zeit, um Patches zu entwickeln, zu testen und zu veröffentlichen. Wenn Sie eine Frist mit dem Anbieter ausgehandelt haben (vielleicht über den CSIRT-Koordinator), lassen Sie diese Frist verstreichen, bevor Sie weiter eskalieren.

Sie sollten Embargos und vorgängige Vertraulichkeit respektieren. Wenn Sie mit einem Anbieter vereinbart haben, eine Schwachstelle nicht vor einem bestimmten Datum öffentlich offenzulegen, ist die Einhaltung dieser Vereinbarung sowohl ethisch als auch essenziell für die Aufrechterhaltung des Vertrauens in den Offenlegungsprozess.

Das umfassendere Ökosystem

Artikel 12 koordiniert Forscher, Anbieter und CSIRTs, existiert aber in einem umfassenderen Ökosystem aus Normen und Praktiken. ISO 30111 liefert Anleitung zur Schwachstellenbehandlung; ISO 29147 liefert Leitlinien für die Schwachstellenoffenlegung. Diese Normen sind relevant dafür, wie der Rahmen aus Artikel 12 funktioniert, auch wenn NIS2 sie nicht namentlich vorschreibt.

Ebenso übernehmen Organisationen zunehmend Richtlinien für verantwortungsvolle Offenlegung und betreiben Bug-Bounty-Programme. Der Rahmen aus Artikel 12 ergänzt diese privatwirtschaftlichen Initiativen. Ein Forscher, der eine Schwachstelle entdeckt, kann sie entweder über das Bug-Bounty-Programm eines Anbieters (falls eines existiert) oder über den NIS2-Rahmen melden. Im Laufe der Zeit sollten diese Wege zu einem nahtloseren europäischen Schwachstellenoffenlegungs-Ökosystem konvergieren.

Wichtigste Erkenntnisse

• Artikel 12 etabliert einen formellen Rahmen für die koordinierte Schwachstellenoffenlegung, wobei jeder Mitgliedstaat einen CSIRT-Koordinator benennt, um die verantwortungsvolle Offenlegung zu erleichtern und die Anonymität der Forscher zu schützen.

• Ihr nationaler CSIRT-Koordinator kann bei der Schwachstellenoffenlegung helfen, Fristen mit betroffenen Anbietern aushandeln und die Offenlegung über mehrere Mitgliedstaaten koordinieren, falls eine Schwachstelle Einrichtungen in mehr als einem Land betrifft.

• Die europäische Schwachstellendatenbank, die von der ENISA unterhalten wird, dient als zentrales Repositorium für öffentlich offengelegte Schwachstellen, die für europäische Einrichtungen relevant sind. Ihre Befunde dort zu veröffentlichen integriert sie in den offiziellen EU-Cybersicherheitsrahmen.

• Forscher, die Schwachstellen gemäß Artikel 12 offenlegen, haben rechtlichen Schutz. Gutgläubige Koordination mit Anbietern über den Rahmen des CSIRT-Koordinators ist der Prozess, durch den dieser Schutz gesichert wird.

• Die Fristverhandlung ist zentral für den Rahmen. Offenlegungsfristen sollten angemessen sein, der Komplexität der Schwachstelle und dem Entwicklungszyklus des Anbieters Rechnung tragen und dokumentiert werden.