Die EU-Gesetzgeber sind dabei, eine politische Einigung über den Cyber Resilience Act zu erzielen, wobei die größte noch zu lösende Hürde die Befugnis der nationalen Behörden betrifft, den Zugang zu gemeldeten Schwachstellen einzuschränken.
Der Cyber Resilience Act ist ein Gesetzesvorschlag zur Einführung von Sicherheitsanforderungen für die Hersteller vernetzter Geräte. Das Dossier befindet sich in der Endphase des Gesetzgebungsverfahrens, in dem EU-Kommission, Parlament und Rat in sogenannten Trilogen die endgültigen Entscheidungen erarbeiten.
Die wichtigsten EU-Institutionen werden voraussichtlich am Donnerstag (30. November) bei einem politischen Trilog eine Einigung formalisieren, aber die meisten Aspekte des Dossiers wurden bereits auf technischer Ebene geklärt, heißt es in einem internen Dokument vom 24. November, das Euractiv eingesehen hat.
Gleichzeitig bleibt der heikle Aspekt der Meldung von Sicherheitslücken und Vorfällen die wichtigste offene politische Frage.
Meldung von Sicherheitslücken
Das neue Cybersicherheitsgesetz führt erstmals die Verpflichtung ein, nicht nur schwerwiegende Vorfälle zu melden, sondern auch aktiv ausgenutzte Schwachstellen, also Einfallstore, die derzeit von böswilligen Akteuren genutzt werden und noch nicht gepatcht wurden.
Während die Meldefristen denen der überarbeiteten Netzwerk- und Informationssystemrichtlinie (NIS2) angeglichen wurden, wurde für aktiv ausgenutzte Schwachstellen die Bereitstellung des Abschlussberichts voraussichtlich 14 Tage betragen.
Der ursprüngliche, vom Parlament unterstützte Vorschlag sah vor, diese Schwachstellen der ENISA, der EU-Agentur für Cybersicherheit, zu melden. Die Mitgliedstaaten wollen diese Aufgabe in die Hände ihrer nationalen Computer Security Incident Response Teams (CSIRTs) übertragen.
Als Referenz-CSIRT gilt das Land, in dem der Hersteller seine Hauptniederlassung hat, d. h. dort, wo er Entscheidungen im Zusammenhang mit der Cybersicherheit trifft oder die meisten Mitarbeiter beschäftigt. Unternehmen ohne EU-Niederlassung müssen sich auf das Land beziehen, in dem sie die meisten Nutzer haben.
Mitte November berichtete Euractiv, wie die Kommission als Kompromiss vorschlug, dass die Hersteller die Meldung über eine einzige Meldeplattform einreichen würden, um gleichzeitig das zuständige nationale CSIRT und die ENISA zu alarmieren.
Während sich über diesen Ansatz ein Konsens entwickelt, besteht der Rat auf der Möglichkeit für die CSIRTs, den Zugriff der ENISA auf die Meldungen aus Gründen der Cybersicherheit vorübergehend einzuschränken. Da die Abgeordneten diese Maßnahme entschieden ablehnen, wird dies der Streitpunkt im kommenden Trilog sein.
Gleichzeitig versteht Euractiv, dass die Mitgliedstaaten mit dem Kompromiss der Präsidentschaft nicht ganz zufrieden sind, da er über ihr Mandat hinausgeht. Weitere Kontroversen könnten dadurch entstehen, dass das EU-Parlament eine Formulierung mit der Forderung nach einer Aufstockung der Ressourcen der ENISA einbringen will.
Spezielle Produktkategorien
Nach dem Cybersicherheitsgesetz hätten Hersteller die Möglichkeit, die Einhaltung der Sicherheitsanforderungen selbst zu beurteilen. Für bestimmte „wichtige“ Produktkategorien müssten die Produkte jedoch von zertifizierten Konformitätsbewertungsstellen überprüft werden.
Wichtige Produkte sind im Anhang der Verordnung aufgeführt. Dem Rat ist es jedoch gelungen, eine Methode zur Klassifizierung von Produkten in diese speziellen Kategorien und einige Filter einzuführen, nämlich dass das Produkt eine kritische Funktion für die Cybersicherheit anderer Produkte haben muss oder eine Funktion aufweist, die ein erhebliches Risiko für negative Auswirkungen auf eine große Anzahl von Produkten mit sich bringt Produkte oder Benutzer.
Die Liste wichtiger Produkte, ein weiterer Knackpunkt in den Verhandlungen, ist mittlerweile konsolidiert.
Die erste Klasse wichtiger Produkte umfasst Identitätsmanagementsysteme, Browser, Passwortmanager, Malware-Erkennungssoftware, virtuelle private Netzwerke (VPNs), Netzwerkmanagementsysteme, Sicherheitsinformations- und Ereignismanagementsysteme, Bootmanager, Software zur Ausstellung digitaler Zertifikate, Netzwerkschnittstellen und Betriebssysteme Systeme, Router, Mikroprozessoren, Mikrocontroller mit sicherheitsrelevanten Funktionalitäten und anwendungsspezifische Schaltkreise.
Auf Drängen der Abgeordneten wurden auch Verbraucherprodukte wie Smart Homes, mit dem Internet verbundene Spielzeuge und persönliche Wearables in Klasse I aufgenommen. In Klasse II umfasst die endgültige Liste Hypervisoren und Container-Laufzeitsysteme, Firewalls, manipulationssichere Mikroprozessoren und Controller.
Schließlich führte der Rat auch eine zusätzliche Liste kritischer Produkte ein, für die möglicherweise ein Cybersicherheitszertifikat beantragt werden muss, darunter Hardwaregeräte, intelligente Zähler und Smartcards.
Pflichten für Hersteller
Hersteller müssen eine Risikobewertung durchführen, die Aufschluss darüber gibt, welche Sicherheitsanforderungen für ihr Produkt gelten. Die Risikobewertung ist während der Supportlaufzeit des Produkts gegebenenfalls zu aktualisieren.
Der Supportzeitraum ist der Zeitrahmen, über den die Hersteller den Umgang mit den Schwachstellen der Produkte sicherstellen sollen. Er sollte mindestens fünf Jahre betragen, wenn das Produkt eine kürzere erwartete Lebensdauer hat.
Darüber hinaus schreibt der vereinbarte Text vor, dass alle während des Supportzeitraums bereitgestellten Sicherheitsupdates mindestens zehn Jahre nach ihrer Veröffentlichung oder für den Rest des Supportzeitraums verfügbar bleiben sollten, je nachdem, welcher Zeitraum länger ist.
Der Text sieht nun vor, dass Hersteller ihre Produkte „standardmäßig mit einer sicheren Konfiguration versehen und den Benutzern Sicherheitsupdates kostenlos zur Verfügung stellen“ sollen.
Befreiung von der nationalen Sicherheit
Der Wortlaut der vom Rat geforderten Ausnahmeregelung zur nationalen Sicherheit muss noch bestätigt werden. Hier stellt sich die Frage, ob nur Produkte ausgeschlossen werden sollen, die ausschließlich für Zwecke der nationalen Sicherheit oder Verteidigung entwickelt wurden, oder auch solche, die für diese Zwecke modifiziert wurden.
Quelloffene Software
Auf technischer Ebene ist man sich weitgehend einig, wie Open-Source-Software einzubinden ist. Wie Euractiv zuvor berichtete, haben EU-Politiker die Zahl der Open-Source-Software-Verwalter eingeführt, die der Dokumentation und dem Umgang mit Schwachstellen unterliegen.
Verwendung der Einnahmen aus Strafen
Ein kleinerer Punkt, der im Trilog geklärt werden muss, ist der Vorschlag der Abgeordneten, die EU-Länder dazu zu verpflichten, die Einnahmen aus Strafen im Rahmen dieser Verordnung in Aktivitäten zum Aufbau von Cybersicherheitskapazitäten zu reinvestieren.
[Edited by Nathalie Weatherald]
