Folge 5: Schwachstellen und Sicherheitsvorfälle, die in die Truhe des Vergessens gesperrt werden, nutzen niemandem. Besser wird man nur, wenn man sie kommuniziert und es damit möglich macht, Feeback aus der Community zu bekommen, andere zu warnen und mitzuteilen: Wir haben’s erkannt, wir schließen das Leck. Das ist natürlich immer wechselseitig zu verstehen. Denn wenn eine Schwachstelle entdeckt wird und in die Community eingespeist wird, profitieren alle davon: auch die Nutzer:innen, denn die werden ein Update bekommen, das den Fehler behebt. Klingt einfach, ist in der Praxis jedoch kein Pappenstiel. Das hat der europäische Gesetzgeber erkannt und Vorgaben für Hersteller von Produkten mit digitalen Elementen gemacht. Ein zentrales Element aus dem Pflichtenkatalog des Cyber Resilience Act (CRA) ist somit das dort geforderte Meldewesen. Hersteller von digitalen Elementen, die unter den CRA fallen, müssen demgemäß Schwachstellen und Sicherheitsvorfälle bekannt machen. Diese Meldepflichten werden im Folgenden erläutert.
Meldebereit?
Was muss gemeldet werden? Wo meldet man? Und an wen meldet man? Der CRA schreibt ein umfassendes Schwachstellenmanagement vor, über das wir einen eigenen Beitrag veröffentlichen werden. Aus dem Nachstehenden lässt sich die Notwendigkeit ableiten, aus diesen Pflichten Prozesse abzuleiten. Das ist eine Ressourcenfrage, und nicht jedes kleine oder mittlere Unternehmen wird sich’s leisten können ein Product Security Incident Response Team (PSIRT), also eine zentrale Anlaufstelle für interne und externe Sicherheitsmeldungen, aufzusetzen. Dennoch verpflichtet das Gesetz zu verantwortlichem Handeln. Daher macht es Sinn, eine Coordinated-Vulnerability-Disclosure-Richtlinie zu verfassen.[1] Das ist ein Dokument, in dem der Prozess des Veröffentlichens von Schwachstellen verbindlich dokumentiert und beschrieben wird. In Richtung Kund:innen sollte ebenfalls ein Kanal existieren, um Patches und notwendige Informationen passgenau ausliefern zu können.
Ein Blick ins Gesetz: Artikel 14, Abs. 1, reguliert die Meldepflicht für das Produkt, wenn eine „aktiv ausgenutzte Schwachstelle“ bekannt geworden ist. Wenn ein Hersteller die Information erhält, dass sein CRA-Produkt eine aktiv ausgenutzte Schwachstelle aufweist, muss er dies innerhalb von 24 Stunden „unter Angabe der Mitgliedstaaten, in deren Hoheitsgebiet das Produkt mit digitalen Elementen des Herstellers seiner Kenntnis nach bereitgestellt wurde“, gleichzeitig bei zwei Stellen melden: Das ist zum einen die europäische Cybersicherheitsbehörde ENISA, die am 11. September dieses Jahr ihr Meldeportal launchen wird, zum anderen das zuständige CSIRT (Computer Security Incident Response Team). In Deutschland ist dies das CERT-Bund im Bundesamt für Sicherheit in der Informationstechnik (BSI).[2]
Zweite Stufe
Diese Meldefrist erweitert sich in Stufe zwei auf 72 Stunden. Dann nämlich ist eine zweite Meldung fällig. Es müssen dann, sofern das nicht schon im ersten Gang nach 24 Stunden erledigt wurde, allgemeine Informationen über Produkt und Ausnutzung sowie die Gegenmaßnahmen und die Sensibilität übermittelt werden: detailreicher und umfänglicher als zur ersten Meldung. Steht eine „Korrektur- oder Risikominderungsmaßnahme“ zur Verfügung, muss spätestens 14 Tage danach ein Schlussbericht übermittelt werden. Dieser enthält die Beschreibung der Schwachstelle und den Schweregrad sowie Auswirkungen, Informationen über diejenigen, die die Schwachstelle ausgenutzt haben, sofern verfügbar. Ferner dokumentiert der Hersteller die Gegenmaßnahmen (Patches, Updates oder Workarounds).
Gleiche Fristen gelten gemäß Art. 14, Abs. 3 für schwerwiegende Sicherheitsvorfälle. Diese Pflichten gelten in gleichem Umfang und mit den gleichen Fristen und Anforderungen für Hersteller, die außerhalb der Europäischen Union ihren Firmensitz haben. Wenn diese keine europäische Hauptniederlassung betreiben, ist der „Bevollmächtigte“ oder „Einführer“ für die Koordination zuständig. Etwas vage heißt es unter Absatz 7, Unterabsatz 3, Buchstabe c, dass bei Fehlen dieser Koordinatoren die Meldung in den Mitgliedsstaaten geschehen muss: nach Händlern („der die meisten Produkte […] dieses Herstellers auf dem Markt bereitstellt“) und Abs. 7, 3d, „der Mitgliedstaat, in dem sich die meisten Nutzer […] befinden“. Das scheint ein Widerspruch zu der Logik der Zuständigkeit zu sein, denn eigentlich kann ein Produkt nur dann in den EU-Binnenmarkt, wenn es einen Importeur gibt. So schreibt es der große Rahmen vor: das New Legislative Framework der EU.
Nutzer:innen im Blick
Das zwingt Leser:innen des Gesetzes zu einem Perspektivwechsel. Ein plausibler Ansatz zum Verständnis könnte sein, dass hier der Blickwinkel sich vom Hersteller zur Meldestelle, dem CSIRT, verschiebt. Es geht also nicht um die rechtliche Verantwortung, sondern um das Land, in dem gemeldet werden soll. Das überliest man leicht, obschon der Zuständigkeitsmechanismus im Kontext der Meldeplattform wörtlich angesprochen wird. Diese Unterpunkte legen also nur fest, an welchen nationalen Koordinator die Meldung gehen soll. Damit versucht der Gesetzgeber, alle Unklarheiten auszuräumen. Man kann sich übrigens vorstellen, dass ein außereuropäischer Hersteller keinen eindeutig zu bestimmenden Einführer hat. Auf der Basis dieses Verständnisses lassen sich dann trotzdem Daten zuordnen. Da es zum jetzigen Zeitpunkt noch keine „Fälle“ im juristischen Sinn gibt, sind diese Texte Vorstellungen, die auf Plausibilitätsannahmen gründen. Außerdem gilt das Gesetz nicht nur für KMU, Händler, Importeure und andere betroffene Marktbegleiter. Auch die Kolleg:innen im CSIRT müssen wissen, was sie fordern. Vorstellbar wäre ja, dass bei einer Stichprobe im Markt eine Software aufgefunden wird, die in der EU erworben werden kann, aber nicht den Kriterien des CRA entspricht. Dann heißt es, detektivisch zu schauen und Verantwortlichkeiten zu bestimmen. Buchstabe d aus Artikel 14, Abs. 7, Unterabsatz 3 wäre gemäß dieser Auslegung ein Hilfskonstrukt, um das Gesetz praktisch umsetzbar zu machen: Irgendeine Meldestelle wird dann für die mangelhafte Software zuständig. Und nicht etwa keine. Vielleicht tut sich hier kund, dass keine weltfremden Juristen, die mit Cybersicherheit nichts zu tun haben, diese Texte geschrieben haben. Meistens liegt es am Vorstellungsfeld der Lesenden, was man versteht. Und da unterscheiden wir uns gravierend.
Art. 14, Abs. 8, legt fest, dass auch Nutzer:innen zu informieren sind. Laut Heckmann/Paschke ist jedoch noch nicht eindeutig geklärt, „in welchen Fällen der Hersteller lediglich die betroffenen Nutzer und in welchen Fällen sämtliche Nutzer des Produktes mit digitalen Elementen zu informieren sind“.[3] Trotz dieser Unsicherheit ist es für die allgemeine Cybersicherheit ein Fortschritt, das Nutzer:innen auch in dieser Hinsicht nicht in Unwissenheit gelassen werden. Im Übrigen muss hierzulande das BSI als Betreiber des CSIRT einspringen, wenn Produktverantwortliche es versäumen, Nutzer:innen in Kenntnis zu setzen. Hier gelten aber Kriterien der Verhältnismäßigkeit und Erfordernis. Und natürlich muss das BSI dann auch wieder den Hersteller informieren. Übrigens regelt dann noch ein weiterer Artikel (15), dass die ENISA und die CSIRTs freiwillige Meldungen aller Schwachstellen und Sicherheitsvorfälle entgegennehmen müssen. Das könnte ein Ansatz zu mehr Sicherheit im Allgemeinen bedeuten. Hat man als Unternehmen einen Meldeprozess etabliert, kann man jede gefundene Schwachstelle mit einem Vulnarability Score bewerten und, wenn es geboten erscheint, einreichen.
Was tun? Jetzt kann man sich natürlich fragen, wie man das bewältigen soll. Der erste Schritt wird sein, dass man herausfindet, ob es bereits vergleichbare Prozesse, Meldewege und -mittel im Unternehmen, etwa für Datenschutzrechtsprobleme, gibt. Dann ließe sich über den Vergleich der Anforderungen herausfinden, ob man den Prozess adaptieren kann. Natürlich fallen Antworten auf die damit einhergehenden Fragen nach Unternehmensgröße und Produktkategorie unterschiedlich aus. Die eigentliche Arbeit beginnt dann in der Regel wie jede Tätigkeit in der Informationssicherheit mit der Bestimmung des Teams der Verantwortlichen für den Meldeprozess. Das Team erarbeitet daraufhin die Richtlinie für die koordinierte Schwachstellenveröffentlichung anhand der Struktur und Größe der Organisation. Dazu gibt es Hilfen: Die ISO/IEC 29147:2018 normiert Vulnerability Disclosure, Control 8.8 in der ISO27002:2022 organisiert und lokalisiert es im Informationsicherheitsmanagementsystem. Die ISO/IEC 30111:2019 empfiehlt die entsprechenden Prozesse fürs Vulnerability Handling. Die Requirements selbst stehen im CRA und wurden oben im Groben beschrieben. Zudem wird Kanal Richtung Kund:innen bzw. Nutzer:innen des Produkts mit digitalen Elementen geöffnet. Wenn in diesem Sinn das Verfahren zur Erfüllung der Meldepflichten steht, ist eine der großen Anforderungen des CRA gestemmt.
[1] Man kann sich beispielsweise an der des BSI orientieren: https://www.bsi.bund.de/DE/IT-Sicherheitsvorfall/IT-Schwachstellen/it-schwachstellen.html.
[2] Heckmann/Paschke/Bearbeiter CRA, Art. 14, S. 213.
[3] Heckmann/Paschke/Bearbeiter CRA, Art. 14, 45, S. 225.