Koordinierte Offenlegung von Schwachstellen

Die koordinierte Offenlegung von Schwachstellen ist ein festgelegtes Verfahren, in dem Außenstehende eine gefundene Schwachstelle an den Hersteller melden, der Hersteller sie behebt und beide Seiten sich darüber verständigen, wann Einzelheiten öffentlich werden. Der Cyber Resilience Act (CRA) macht daraus eine Pflicht. Anhang I Teil II Nummer 5 verlangt, dass Hersteller „eine Strategie für die koordinierte Offenlegung von Schwachstellen aufstellen und umsetzen“.

Die Anforderung richtet sich nicht an das Produkt, sondern an die Verfahren des Herstellers. Sie wird deshalb im Konformitätsbewertungsverfahren mitgeprüft, denn die EU-Konformitätserklärung darf nach Artikel 13 Absatz 12 erst ausgestellt werden, wenn auch die Verfahren des Herstellers den Anforderungen aus Anhang I Teil II genügen.

Was der CRA verlangt und was er offenlässt

Der Verordnungstext ist knapp. Er nennt drei Bausteine, die zusammengehören:

• die Strategie selbst, aufgestellt und tatsächlich angewendet (Anhang I Teil II Nummer 5)
• eine Kontaktadresse für die Meldung entdeckter Schwachstellen, dazu Maßnahmen, die den Austausch von Informationen über mögliche Schwachstellen im Produkt und in enthaltenen Komponenten Dritter erleichtern (Nummer 6)
• Verfahren, mit denen gemeldete Schwachstellen aus internen wie externen Quellen bearbeitet und behoben werden (Artikel 13 Absatz 8)

Was der CRA nicht vorgibt, ist ebenso bemerkenswert. Es gibt keine Frist bis zur Veröffentlichung, keine vorgeschriebene Form der Strategie und keine Pflicht, Meldungen zu vergüten. Erwägungsgrund 76 beschreibt nur das Ziel: einen strukturierten Prozess, der dem Hersteller Diagnose und Behebung ermöglicht, bevor Einzelheiten an Dritte oder an die Öffentlichkeit gelangen.

Trotzdem ist die Anforderung scharf bewehrt. Eine fehlende Strategie ist ein Verstoß gegen Anhang I, und dafür sieht Artikel 64 Absatz 2 Geldbußen von bis zu 15 000 000 EUR oder, bei Unternehmen, bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres vor, je nachdem, welcher Betrag höher ist.

Wo die Strategie auffindbar sein muss

Nach Anhang II Nummer 2 müssen die Informationen für den Nutzer die zentrale Kontaktstelle nennen, bei der Schwachstellen gemeldet werden können und bei der auch das Konzept für die koordinierte Offenlegung zu finden ist. Artikel 13 Absatz 17 ergänzt zwei Anforderungen an diese Anlaufstelle: Nutzer müssen sie leicht ermitteln können, und sie müssen ihr bevorzugtes Kommunikationsmittel wählen dürfen. Ein einziger automatisierter Kanal genügt deshalb nicht, denn die Mittel dürfen ausdrücklich nicht auf automatisierte Instrumente beschränkt werden. Erwägungsgrund 63 nennt die Chatbox als Beispiel: Wer sie anbietet, soll zusätzlich eine Telefonnummer oder eine andere digitale Kontaktmöglichkeit wie eine E-Mail-Adresse oder ein Kontaktformular bereitstellen.

In die Technische Dokumentation gehört die Strategie ebenfalls. Anhang VII Nummer 2 Buchstabe b nennt sie neben der Software-Stückliste und dem Nachweis, dass eine Kontaktadresse bereitgestellt wurde. Erwägungsgrund 76 legt den Herstellern zusätzlich nahe, ihre Sicherheitskonzepte in maschinenlesbarem Format zu veröffentlichen. Verpflichtend ist das nicht.

Wenn die Meldung über ein CSIRT kommt

Nicht jeder Hinweis erreicht Sie direkt. Artikel 12 Absatz 1 der NIS-2-Richtlinie verpflichtet jeden Mitgliedstaat, eines seiner CSIRTs als Koordinator für die koordinierte Offenlegung zu benennen. Dieses als Koordinator benannte CSIRT wirkt als vertrauenswürdiger Vermittler. Zu seinen Aufgaben gehört, die betroffenen Einrichtungen zu ermitteln und zu kontaktieren, die meldende Person zu unterstützen und Zeitpläne für die Offenlegung auszuhandeln, auch bei Schwachstellen, die mehrere Einrichtungen betreffen.

Meldende können dort anonym bleiben. Für Hersteller heißt das: Ein Hinweis kann über ein CSIRT eintreffen, ohne dass Sie je erfahren, wer ihn gegeben hat. Meldet eine andere Person als der Hersteller eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall, unterrichtet das CSIRT den Hersteller nach Artikel 15 Absatz 4 unverzüglich.

Verhältnis zur Meldepflicht

Ein laufendes Verfahren zur koordinierten Offenlegung setzt die Meldepflichten nicht aus. Wird eine Schwachstelle aktiv ausgenutzt, läuft die 24-Stunden-Frist des Artikels 14 unabhängig davon, ob mit einem Melder Stillschweigen vereinbart wurde.

Rücksicht auf das laufende Verfahren nimmt der CRA an anderer Stelle, und zwar unter engen Bedingungen. Wurde ein als Koordinator benanntes CSIRT im Rahmen eines koordinierten Offenlegungsverfahrens nach Artikel 12 Absatz 1 der NIS-2-Richtlinie auf eine aktiv ausgenutzte Schwachstelle aufmerksam, so kann das CSIRT, bei dem die Meldung zuerst eingegangen ist, deren Weiterverbreitung über die einheitliche Meldeplattform nach Artikel 16 Absatz 6 aus berechtigten Gründen der Cybersicherheit aufschieben, und zwar nicht länger als unbedingt erforderlich und längstens, bis die beteiligten Parteien der Offenlegung zugestimmt haben. Den Hersteller hindert das nicht daran, die Schwachstelle freiwillig zu melden. Diese Rücksicht liegt also bei der Behörde, nicht beim Hersteller.

Daneben steht die freiwillige Meldung nach Artikel 15. Sie ist für jede Schwachstelle und für jede natürliche oder juristische Person offen, und nach Absatz 5 darf sie der meldenden Person keine zusätzlichen Pflichten auferlegen. Artikel 17 Absatz 4 stellt außerdem klar, dass die Meldung als solche keine höhere Haftung begründet.

Schwachstellen in fremden Komponenten

Betrifft eine Meldung eine Komponente, die Sie nicht selbst geschrieben haben, endet die Sache nicht mit dem eigenen Patch. Artikel 13 Absatz 6 verpflichtet Sie, die Schwachstelle an die Person oder Einrichtung zu melden, die diese Komponente herstellt oder wartet. Haben Sie eine Software- oder Hardware-Änderung entwickelt, um sie zu beheben, teilen Sie den betreffenden Code oder die Unterlagen mit, gegebenenfalls in maschinenlesbarem Format.

Das gilt ausdrücklich auch für quelloffene Komponenten. Eine brauchbare Strategie legt deshalb fest, wer diesen Schritt geht und über welchen Kanal.

Nach der Behebung

Anhang I Teil II Nummer 4 verlangt, Informationen über beseitigte Schwachstellen zu teilen und zu veröffentlichen, sobald eine Sicherheitsaktualisierung bereitsteht. Dazu gehören eine Beschreibung, Angaben zur Identifizierung des betroffenen Produkts, Auswirkungen und Schwere sowie verständliche Hinweise, mit denen Nutzer die Schwachstelle beheben können.

Ein Aufschub ist möglich, aber eng begrenzt. Er setzt einen hinreichend begründeten Fall voraus, in dem der Hersteller die Risiken der Veröffentlichung für schwerer wiegend hält als die Vorteile in Bezug auf die Sicherheit, und er reicht nur so lange, bis den Nutzern die Möglichkeit gegeben wurde, den entsprechenden Patch anzuwenden.

Ist die Schwachstelle nach Artikel 14 Absatz 1 oder Artikel 15 Absatz 1 gemeldet worden und öffentlich bekannt, nimmt die ENISA sie im Einvernehmen mit dem Hersteller in die Europäische Schwachstellendatenbank auf, sobald eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist (Artikel 17 Absatz 5).

Andere Pflicht für Verwalter quelloffener Software

Ein Verwalter quelloffener Software braucht keine Strategie nach Anhang I Teil II Nummer 5. Artikel 24 Absatz 1 verlangt von ihm stattdessen eine überprüfbar dokumentierte Cybersicherheitsstrategie, die einen wirksamen Umgang mit Schwachstellen fördert, die freiwillige Meldung nach Artikel 15 unterstützt und den Austausch über aufgedeckte Schwachstellen innerhalb der Open-Source-Gemeinschaft voranbringt. Für Hersteller, die eine solche Komponente integrieren, ändert das nichts: Sie brauchen ihre eigene Strategie.