Die meiste Diskussion über NIS2 konzentriert sich auf die Vorfallmeldung und die Risikomanagement-Maßnahmen. Die Seite der koordinierten Offenlegung von Schwachstellen bekommt weniger Aufmerksamkeit, obwohl sie prägt, wie von jeder regulierten Organisation erwartet wird, den Moment zu handhaben, in dem ein Forscher mit einem Fehler ankommt. Hier steht, was NIS2 tatsächlich verlangt, in klaren Worten.
NIS2 teilt die CVD auf zwei Ebenen auf
NIS2 teilt die koordinierte Offenlegung von Schwachstellen zwischen einer nationalen Ebene und einer organisatorischen Ebene auf.
Auf der nationalen Ebene muss jeder Mitgliedstaat Richtlinien verabschieden, die die koordinierte Offenlegung von Schwachstellen fördern und erleichtern, und mindestens ein CSIRT als Koordinator benennen. Dieses CSIRT empfängt Schwachstellenmeldungen, verfolgt sie nach, schützt die Anonymität des Meldenden, wo gewünscht, und koordiniert zwischen den Parteien, wenn ein Fehler mehr als einen Hersteller betrifft. Mitgliedstaaten müssen es einer Person auch erlauben, eine Schwachstelle anonym zu melden, und Forschern ein gewisses Maß an rechtlichem Schutz gewähren, wenn sie sich an die Regeln halten.
Auf der organisatorischen Ebene müssen wesentliche und wichtige Einrichtungen die Behandlung und Offenlegung von Schwachstellen als Teil ihrer Risikomanagement-Maßnahmen behandeln. Das ist der Teil, der bei Unternehmen landet statt bei Regierungen. NIS2 legt keine vollständige Vorlage dar, aber die Leitlinien der NIS-Kooperationsgruppe füllen diese Lücke mit einem klaren Satz von Erwartungen.
Was eine CVD-Richtlinie enthalten soll
Die Leitlinien lesen sich fast wie eine Checkliste. Von einer Organisation, die ihre eigene CVD-Richtlinie verabschiedet, wird erwartet, dass sie Folgendes abdeckt.
- Geltungsbereich. Geben Sie klar an, welche Systeme und Dienste im Geltungsbereich liegen, und listen Sie alles auf, was von Dritten bereitgestellt wird und ausgeschlossen ist. Meldende sollten nicht raten müssen.
- Eine Kontaktstelle. Ein dedizierter Kanal für Meldungen, etwa eine Sicherheitsadresse oder ein Online-Formular, mit interner Weiterleitung, sodass Meldungen, die über andere Kanäle eintreffen, das richtige Team erreichen. Eine security.txt-Datei auf der Website hilft Forschern, sie zu finden.
- Verhältnismäßigkeit. Der Meldende sollte den Dienst nicht stören oder weiter gehen als nötig, um den Fehler zu demonstrieren, und sollte Daten, einschließlich personenbezogener Daten, nicht länger als nötig aufbewahren.
- Treu und Glauben. Die Organisation verpflichtet sich, keine rechtlichen Schritte gegen einen Meldenden zu unternehmen, der sich an die Richtlinie hält. Der Meldende verpflichtet sich, ohne Schädigungsabsicht zu handeln.
- Vertraulichkeit. Meldende teilen das, was sie finden, nicht mit Dritten, über das benannte CSIRT oder die zuständige Behörde hinaus, und gehen nicht ohne Einvernehmen an die Öffentlichkeit.
- Umgang mit personenbezogenen Daten. Da ein Meldender auf personenbezogene Daten stoßen kann, sollte die Richtlinie schriftliche Pflichten dazu festlegen, wie diese Daten gehandhabt werden, beschränkt auf das, was zum Nachweis des Fehlers nötig ist, und durch Verschlüsselung geschützt. Für Datenschutzfachleute ist das der Teil, der genaues Lesen lohnt. Eine CVD-Richtlinie kann als eine Form von Vereinbarung fungieren, die den Forscher an die Organisation bindet, was direkte DSGVO-Folgen dafür hat, wer als Verantwortlicher gilt und auf welcher Rechtsgrundlage die Daten verarbeitet werden.
- Belohnung oder Anerkennung. Optional. Das reicht von einer öffentlichen Würdigung oder einer Hall of Fame bis zu einem Bug-Bounty. Anerkennung kostet fast nichts und hebt dennoch die Qualität der Meldungen.
Die operative Seite
Über den Richtlinientext hinaus setzen die Leitlinien Erwartungen dafür, wie der Prozess im Tagesgeschäft läuft.
Die Kommunikation sollte sicher sein, mit Verschlüsselung oder einem geschützten Portal, sodass Details eines ungepatchten Fehlers nicht durchsickern. Jede Stufe sollte eine Frist haben, für die Bestätigung des Eingangs, für Fortschrittsaktualisierungen, für die Entwicklung einer Korrektur und für jede Veröffentlichung, dabei aber flexibel genug für wirklich komplexe Fälle bleiben. Die Offenlegung gegenüber der Öffentlichkeit sollte mit den betroffenen Parteien und dem benannten CSIRT koordiniert werden, sodass Zeit bleibt, den Fehler zu beheben und betroffene Nutzer zu warnen, bevor Details öffentlich werden. Wo ein Produkt von Upstream-Komponenten abhängt, wird vom Hersteller erwartet, diese Abhängigkeiten zu verfolgen und Schwachstelleninformationen sowohl nach oben an Lieferanten als auch nach unten an Kunden weiterzugeben.
Nichts davon ist exotisch. Es ist der Unterschied zwischen einem Prozess, der einer Prüfung standhält, und einer Sicherheitsadresse, die jemand prüft, wenn er daran denkt.
Warum das jetzt wichtig ist
NIS2 setzt die EU-weite Erwartung, dass Organisationen einen ordentlichen Prozess zur koordinierten Offenlegung von Schwachstellen betreiben. Es hob den Mindeststandard. Was es nicht tut, ist, jedem Hersteller eines vernetzten Produkts spezifische, fristgebundene Offenlegungspflichten aufzuerlegen.
Hier kommt der Cyber Resilience Act ins Spiel. Der CRA nimmt dasselbe Denken der koordinierten Offenlegung und macht es für Hersteller verbindlich, die Produkte mit digitalen Elementen auf den EU-Markt bringen, mit konkreten Pflichten und harten Fristen. Die Erwartungen an die Schwachstellenbehandlung, die NIS2 im Grundsatz beschreibt, verwandelt der CRA in eine gesetzliche Anforderung mit angehängtem Datum.
Wenn Sie bis hierher gelesen haben, weil NIS2 für Sie gilt, ist der CRA das nächste Dokument auf Ihrem Schreibtisch. Die gute Nachricht ist, dass eine Organisation, die einen glaubwürdigen CVD-Prozess für NIS2 aufbaut, bereits den größten Teil der Grundlagenarbeit für das geleistet hat, was der CRA verlangen wird.
Quelle: NIS-Kooperationsgruppe, Leitlinien zur Umsetzung nationaler Richtlinien zur koordinierten Offenlegung von Schwachstellen, 2023.