NIS-2-Schwachstellenmanagement nach Artikel 21(2)(e)
Schwachstellenmanagement hat unter NIS 2 zwei Seiten. Schwachstellen in den eigenen Systemen. Und Schwachstellen, die andere bei Ihnen melden. Artikel 21(2)(e) verankert die Pflicht, CIR (EU) 2024/2690 §6.10 konkretisiert sie, und §30(2)(5) BSIG setzt sie in deutsches Recht um.
Die Kurzfassung
Schwachstellenmanagement ist Punkt (e) der Artikel-21(2)-Liste. Der CIR überschreibt den passenden Abschnitt mit 'Behandlung und Offenlegung von Schwachstellen'. Genau das ist der Punkt. NIS 2 adressiert zwei Dinge gleichzeitig: Schwachstellen in den Systemen, die Sie betreiben, und Schwachstellen, die Außenstehende in Ihren Produkten finden und melden wollen.
CIR §6.10 nennt fünf Handlungen. Informationen zu Schwachstellen aus CSIRTs, Behörden, Herstellern und Dienstleistern aufnehmen. Schwachstellenscans in einer dokumentierten Frequenz fahren. Als kritisch eingestufte Schwachstellen unverzüglich beheben. Schwachstellenbehandlung mit Change-, Patch-, Risiko- und Incident-Management verzahnen. Und eine koordinierte Schwachstellenoffenlegung (CVD) einrichten, abgestimmt mit der nationalen CVD-Politik.
Deutschland setzt die Pflicht über §30(2)(5) BSIG um. Der nationale CVD-Rahmen läuft über das CERT-Bund-Programm beim BSI. NIS 2 selbst etabliert in Artikel 12 zusätzlich eine europäische Schwachstellendatenbank, die von ENISA betrieben wird und der Einrichtungen freiwillig Schwachstellen melden können.
Artikel 21(2)(e) NIS-2-Richtlinie (2022/2555)
Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen.
Punkt (e) der zehn Mindestmaßnahmen. Bemerkenswert ist die Verpackung: Schwachstellenbehandlung und Offenlegung sitzen innerhalb einer breiteren Pflicht zu Erwerb, Entwicklung und Wartung. Der CIR teilt das in getrennte Abschnitte auf (§6.9 Beschaffung, §6.10 Schwachstellen). Die Offenlegungshälfte wird in der Praxis am häufigsten unterschätzt.
CIR (EU) 2024/2690, Anhang §6.10
Die betreffenden Einrichtungen erlangen Informationen über technische Schwachstellen in ihren Netz- und Informationssystemen, bewerten ihre Exposition gegenüber solchen Schwachstellen und ergreifen geeignete Maßnahmen zum Umgang mit diesen Schwachstellen.
Unmittelbar geltendes EU-Recht für die im CIR-Anhang genannten Sektoren (DNS, TLDs, Cloud, Rechenzentren, MSPs, Vertrauensdienste und weitere). §6.10.2 listet fünf konkrete Handlungen. §6.10.3 verlangt, dass eine bewusste Entscheidung gegen Maßnahmen dokumentiert wird. §6.10.4 verlangt eine periodische Überprüfung der Kanäle, über die Schwachstelleninformationen bezogen werden.
§30(2)(5) BSIG (Deutschland)
Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen.
Deutschland übernimmt den EU-Wortlaut nahezu identisch. Der nationale CVD-Rahmen läuft über das CERT-Bund-Programm beim BSI, das hinter der Formulierung 'abgestimmt mit den anwendbaren nationalen CVD-Politiken' aus CIR §6.10.2(e) steht.
Informationen reinholen
Schwachstelleninformationen aus CSIRTs, Behörden, Herstellern und Dienstleistern verfolgen. Schwachstellenscans in einer der Umgebung angemessenen Frequenz fahren. Die Scanner (Tenable, Qualys, Nessus, OpenVAS) sind die technische Seite. Die Feeds (CERT-Bund-Newsletter, Hersteller-Advisories, NVD) sind die Awareness-Seite. Beides ist nötig.
Kritisches beheben, Rest dokumentieren
Kritische Schwachstellen werden unverzüglich behoben. Schwachstellenbehandlung muss mit Change-, Patch-, Risiko- und Incident-Management verzahnt sein. Wo Sie sich gegen Maßnahmen entscheiden, verlangt §6.10.3 entweder einen dokumentierten Minderungsplan oder eine schriftliche Begründung, warum nichts zu tun ist. Kein stilles Backlog.
Koordinierte Offenlegung einrichten
Verfahren zum Empfang von Schwachstellenmeldungen Außenstehender und zur koordinierten Offenlegung, abgestimmt mit der anwendbaren nationalen CVD-Politik. Mindestmechanik: ein veröffentlichter Kontaktkanal (security@-Postfach oder eine security.txt), eine Bestätigungsfrist, ein Behebungsfenster und eine koordinierte Veröffentlichung. CERT-Bund vermittelt bei Bedarf.
Periodisch, nicht reaktiv
§6.10.2(b) sagt: Scans laufen 'periodisch, in angemessenem Umfang'. §6.10.4 sagt: Kanäle zur Schwachstellenüberwachung werden periodisch überprüft. Beides heißt: schriftlich festgelegte Frequenz. Dokumentieren Sie, wie oft Sie scannen, dokumentieren Sie, wie oft Sie Ihre Feed-Liste prüfen, und halten Sie sich daran. Ein Scan einmal im Jahr, weil jemand daran dachte, ist nicht periodisch.
Koordinierte Offenlegung ist Pflicht, nicht optional
§6.10.2(e) verlangt, dass das Verfahren existiert. Nicht 'falls Meldungen eingehen'. Das Verfahren existiert, damit ein Forschender beim Fund einen Kanal hat und Ihr Team einen Prozess. Minimum: ein security@ihredomain-Postfach, das jemand liest, eine Bestätigungsfrist (üblich: 7 Tage), eine Offenlegungsfrist (üblich: 90 Tage). Schriftlich festhalten, veröffentlichen, eine security.txt darauf zeigen lassen.
BSI / CERT-Bund CVD-Programm
Das BSI betreibt CERT-Bund, das nationale CSIRT, und führt ein Programm zur koordinierten Offenlegung von Schwachstellen. Forschende können über CERT-Bund melden, das BSI koordiniert mit betroffenen Herstellern. §30(2)(5) BSIG verweist darauf. Wer erstmals einen CVD-Prozess aufsetzt, fährt mit den Fristen und Kontaktwegen des CERT-Bund-Modells als Default sicher.
Europäische Schwachstellendatenbank (Artikel 12 NIS 2)
Artikel 12 NIS 2 etabliert eine europäische Schwachstellendatenbank, die von ENISA betrieben wird. Einrichtungen können Schwachstellen freiwillig dort melden. Das ist kein verpflichtender Meldekanal nach Artikel 23. Es ist eine EU-weite Referenzressource, die Schwachstelleninformationen über Mitgliedstaaten hinweg bündelt.
Nationale CSIRTs als CVD-Koordinatoren
Jeder Mitgliedstaat hat sein nationales CSIRT als CVD-Koordinator (NCSC-NL in den Niederlanden, CERT.at in Österreich, CCB in Belgien). Die Pflicht ist EU-weit dieselbe. Unterschiede gibt es bei der zuständigen Stelle und den genauen Koordinationsabläufen.
Wir patchen am Patch Tuesday, das reicht.
Reicht nicht. §6.10.2(c) verlangt unverzügliche Behebung kritischer Schwachstellen. Patch Tuesday ist ein Release-Rhythmus eines Herstellers. Ein Zero-Day, der am Donnerstag mit aktiver Ausnutzung veröffentlicht wird, wartet nicht bis nächste Woche. Sie brauchen eine Patch-Frequenz für Routinefälle und einen Out-of-Band-Prozess für kritische Fälle.
Wir haben keinen CVD-Prozess, weil uns nie jemand etwas meldet.
§6.10.2(e) sagt nicht 'richten Sie einen Prozess ein, wenn Meldungen kommen'. Das Verfahren muss existieren. Sinn ist: Wenn jemand etwas findet, hat er einen klaren Kanal und Ihr Team weiß, was zu tun ist. Ein security@-Postfach und eine einseitige Richtlinie erfüllen die Pflicht. Wer beides nicht hat, hat einen Befund.
Schwachstellenscans sind Sache des Security-Teams.
Sind sie, bis Sie §6.10.2(d) lesen: Schwachstellenbehandlung muss mit Change-, Patch-, Risiko- und Incident-Management konsistent sein. Und §6.10.4: Überprüfung der Kanäle auf Organisationsebene. Damit ist Schwachstellenmanagement ein bereichsübergreifender Prozess, der IT-Betrieb, Entwicklung, Risiko und Leitungsorgan einschließt, keine isolierte Security-Aufgabe.
Die technische Seite ist meist passabel. Die meisten Mittelstands-IT-Teams betreiben bereits einen Scanner (Tenable, Qualys, Nessus, OpenVAS) und haben irgendeine Patch-Frequenz, sei es 'Patch Tuesday für Clients, quartalsweise für Server'. Die CIR-Pflichten aus §6.10.2(a)+(b)+(c) sind dann vor allem: aufschreiben, was ohnehin läuft, und die Frist für kritische Fälle straffen.
Die CVD-Seite ist die meist unterdokumentierte Hälfte. Realistisches Minimum: ein security@ihredomain-Postfach, das auf zwei Personen geroutet ist, eine einseitige Disclosure-Richtlinie (Bestätigung innerhalb 7 Tagen, Offenlegung innerhalb 90 Tagen, Nennung des Forschenden auf Wunsch) und eine security.txt unter /.well-known/security.txt, die auf das Postfach zeigt. Ein halber Arbeitstag. Der Punkt, den Audits tatsächlich anstreichen.
Das PRO-Modul hält Ihr Schwachstelleninventar, den Scanplan, Behebungsaufgaben und Akzeptanzentscheidungen an einem Ort. Jeder Scanbefund wird in eine Aufgabe mit Owner, Fälligkeit und Freigabe geroutet. Die §6.10.3-Pflicht, das Unterlassen von Maßnahmen zu begründen, läuft über denselben Freigabepfad: schriftliche Begründung, namentlich Freigebender, Audit-Trail. Keine Parallel-Tabelle.
Außerdem liegt eine CVD-Richtlinienvorlage bei (security@-Postfacheinrichtung, security.txt-Inhalt, Bestätigungs- und Offenlegungsfristen abgestimmt mit CERT-Bund). Domain und Kontakte einsetzen, und die §6.10.2(e)-Pflicht ist abgedeckt. Externe Meldungen landen im selben Aufgaben-Pipeline wie Scanbefunde, sodass die Reaktionszeit identisch nachvollzogen wird.
- Richtlinie (EU) 2022/2555 (NIS 2), Artikel 12 und Artikel 21(2)(e): eur-lex.europa.eu/eli/dir/2022/2555/oj
- Durchführungsverordnung (EU) 2024/2690 (CIR), Anhang §6.10: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI-Gesetz (BSIG), §30(2)(5) in der Fassung des NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes
- BSI / CERT-Bund Programm zur koordinierten Offenlegung von Schwachstellen: bsi.bund.de
- ENISA Europäische Schwachstellendatenbank (Artikel 12 NIS 2)