Was der Cyber Resilience Act von Herstellern fordert [German]

Dokumentation, Dokumentation, Dokumentation (das ist besser, als es klingt)

Was ist der Cyber Resilience Act?

Der Cyber Resilience Act (CRA) wird die weltweit erste Regulierung, die Security-Anforderungen für Produkte als Markteintrittshürde definiert, oder weniger formalistisch: Ohne Security dürfen “Produkte mit digitalen Elementen” in der EU ab voraussichtlich 2027 nicht mehr angeboten werden.

Dabei erfindet die EU das Rad nicht neu, sondern fügt Security als ein neues Puzzlestück in das bestehenden Konzept des CE-Kennzeichens ein, das sicherheitsrelevante Produkte wie Sonnenbrillen, Kinderspielzeug oder Druckbehälter auch heute schon tragen müssen. “Sicherheit” war dabei bislang als “Safety” zu lesen, Security ist nun neu. (Die Grundmechanismen des CE-Kennzeichens und wie sich der CRA dort einsortiert können Sie hier nachlesen, und hier die Bedeutung von harmonisierten europäischen Normen für das CE-Kennzeichen.)

Was ist der Stand der Dinge in der Gesetzgebung?

Der Cyber Resilience Act (CRA) der EU ist am 12. März vom EU-Parlament verabschiedet worden (517 Ja-Stimmen, 12 Nein-Stimmen, 78 Enthaltungen). Das kam einigermaßen überraschend, immerhin hieß es Anfang des Jahres noch, dass es möglicherweise bis zu den Parlamentswahlen im Juni nichts mehr werde. Nun fehlt nur noch die Zustimmung des europäischen Rats, dann kann der CRA in Kraft treten.

Parlament und Rat hatten sich bereits Ende 2023 in den Trilog-Verhandlungen zwischen Kommission (die im September 2022 den Entwurf des CRA vorgelegt hatte), Parlament und Rat inhaltlich geeinigt, daher ist ein Zustimmung des Rats zur nun im Parlament verabschiedeten Fassung wahrscheinlich.

Die am 12.03.2024 vom Parlament verabschiedete Fassung des CRA ist öffentlich verfügbar; es ist das erste öffentliche Update seit der Entwurfsfassung vom 15.09.2022 und mit großer Wahrscheinlichkeit auch die finale Version, vorbehaltlich der “legal-linguistic finalisation” — die ändert aber nichs mehr am Inhalt.

Wenn der CRA in Kraft tritt, gilt er sofort auch in allen EU-Mitgliedsstaaten, denn im Gegensatz zu etwa NIS-2 ist der CRA keine Direktive, die von den Mitgliedsstaaten erst in nationales Recht übersetzt werden muss, sondern eine Verordnung. Das heißt: Nach einer Übergangsfrist von 36 Monaten gelten die Anforderungen des CRA für die Hersteller der betroffenen Produkte — bei dem wahrscheinlichen Inkrafttreten in diesem Jahr bedeutet das, die Hersteller müssen die Anforderungen ab 2027 erfüllen.

So, und nun wird’s spannend: Wer sind denn die betroffenen Produkte und die Anforderungen?

Betroffene Produkte

Die grundsätzlich betroffenen Produkte sind: “products with digital elements (=software and hardware products and its remote data processing solutions) made available on the market, the intended purpose or reasonable foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network”.

Oder, verkürzt: Alle Hard- und Software, die während ihres Gebrauchs eine Daten- oder Netzwerkverbindung haben könnte. Noch kürzer: Alles, was digital kommuniziert. Das ist viel.

Besondere Anforderungen, allen voran die zwingende Notwendigkeit, die Erfüllung der Cybersecurity-Anforderungen durch eine externe Stelle (z.B. TÜVs) prüfen zu lassen, gelten nur für “important products with digital elements ” und “critical products with digital elements”. Diese finden sich in Annex III und IV des CRA und decken drei Produkttypen ab:

1. IT-Basisinfrastruktur: Browser, Betriebssysteme, Router, Modems, Switche, Netzwerk- und Boot-Manager, Netzwerk-Schnittstellen und Virtualisierungsinfrastruktur.
2. Produkte mit Security-Funktion: Authentifizierungssysteme, Passwortmanager, Virenschutz, VPN, SIEM, PKI, Microcontroller und andere eingebettete Systeme mit Security-Funktionen, Firewalls, IDS und IPS, Smart-Home-Geräte mit Security-Funktionen (zum Beispiel Türschließanlagen), Smart Meter Gateways und Hardware-Securitymodule wie Smartcards und Security Boxes
3. Produkte, die persönliche Informationen (von Kindern) oder Gesundheitsdaten aufzeichnen können: Spielzeuge und Babyphones mit Internetverbindung, Wearables mit Gesundheitsfunktionen und persönliche Assistenten.

Die “important products” und “critical products” sind im Vergleich zum Entwurf 2022 signifikant eingedampft worden. Damals gab es noch eine lange Liste, darunter industrielle Leitsysteme, Roboter, IIoT und Microcontroller.

Anforderungen

Essential requirements and harmonised standards

Die inhaltlichen Anforderungen, die der CRA an Produkte stellt, sind in Annex I aufgeführt. Sie lassen sich recht schlank zusammenfassen in Anforderungen während des Designs und Anforderungen während des Betriebs:

Der Annex I ist sehr kurz und die Anforderungen sind sehr generisch. Das ist Absicht, denn die konkrete Ausgestaltung der Anforderungen soll in sogenannten “harmonisierten Standards” erfolgen. Diese werden gerade in den europäischen Standardisierungsorganisationen CEN/CENELEC ausgearbeitet. Es sollen, soweit möglich, existierende Standards verwendet werden. Aber einen Horizontalstandard, der für alle Produkte des sehr breiten Anwendungsbereichs der CRA gleichermaßen passend wäre, gibt es bislang nicht.

Die Erfüllung dieser “essential requirements” muss dokumentiert werden. Die sichtbaren Ergebnisse, die Hersteller für die Erfüllung des CRA erzeugen müssen, sind drei Arten von Dokumentation:

EU declaration of conformity

Die zentrale Dokumentation, die für Produkte vorliegen muss, ist das CE-Kennzeichen. Das darf man anbringen, wenn man eine “EU declaration of conformity” erstellt hat. Diese Konformitätserklärung ist im Prinzip erst einmal nur ein formales Schriftstück, das erklärt, das Produkt sei konform zu den oben beschriebenen “essential requirements”.

Eine Konformitätserklärung kann man nach verschiedenen Verfahren erwerben. Je nach Verfahren ist eine Prüfung durch Dritte notwendig oder nicht.

Der einfachste Weg ist Modul A / “internal control”. In diesem Fall erklärt der Hersteller die Konformität mit den “essential requirements” selbst.

Für die Prüfung durch Dritte gibt es drei Möglichkeiten:

• Modul H: Prüfung auf Basis eines Qualitätsmanagementsystems
• Modul B+C: “EU-type examination” — dabei prüft eine von der EU benannte Prüfstelle (z.B. ein TÜV, DEKRA etc.)
• Erwerb eines Zertifikats gemäß EU Cybersecurity Certification Scheme.

Die “important entities” und “critical entities” müssen eine Prüfung durch Dritte durchlaufen, um eine Konformitätserklärung und somit das CE-Kennzeichen zu bekommen. Für alle anderen reicht auch die Selbsterklärung.

Die Konformitätserklärung für das Produkt muss mit dem Produkt ausgeliefert werden bzw. öffentlich einsehbar sein.

Technical documentation

Die technische Dokumentation muss alle Informationen beinhalten, die für die Konformität mit den “essential requirements” notwendig sind, oder in CRA-O-Ton: “all data and details of the means used to ensure conformity with essential requirements”.

Konkret bedeutet das vor allem

• eine Risikoanalyse, die insbesondere die Anwendbarkeit der “essential requirements” für das Produkt analysiert (diese prominente Positionierung der Risikoanalyse und die explizite Verknüpfung der Risikoanalyse mit den “essential requirements” ist übrigens neu im Vergleich zur Fassung von 2022),
• Design-Informationen, die der Dokumentation der “essential requirements Part I” dienen; insbesondere Systemarchitekturzeichnungen und Interaktionen von Systemkomponenten,
• Dokumentation des Schwachstellen-Management-Prozesses gemäß “essential requirements Part II”; inklusive SBOM,
• Testberichte aus dem Konformitätsbewertungsverfahren sowie eine Liste der angewandten harmonisierten Standards.

Es gibt übrigens einen Standard zur Erstellung von technischen Dokumentationen: EN IEC/IEEE 82079–1:2020.

Die technische Dokumentation muss für jedes Produkt erstellt werden, das unter den CRA fällt — egal ob “important”, “critical” oder nicht.

Die technische Dokumentation ist nicht öffentlich; sie enthält ja auch potentiell sensible Informationen. Die Marktaufsichtsbehörde — in Deutschland wird das wohl BSI oder BNetzA — kann aber in begründeten Fällen Einsicht in die technische Dokumentation fordern. So ein Fall wäre zum Beispiel denkbar, wenn die Ausnutzung einer Schwachstelle für ein bestimmtes Produkt bekannt wird.

Information & instructions to the user

Die “informations & instructions to the user” könnte man kurz mit “Nutzer-Anleitung” übersetzen. Sie soll den Nutzer befähige, das Produkt auch tatsächlich sicher zu betreiben.

Dafür sollen die intendierte Nutzung und die wichtigsten Funktionen des Produkts beschrieben werden, aber auch die Security-Eigenschaften, die das Produkt mitbringt. Außerdem soll der Nutzer gewarnt werden, welche Arten der Nutzung oder Veränderung des Produkts aus Security-Sicht riskant sind und welche Maßnahmen er ergreifen muss, um das Produkt sicher zu nutzen: Was muss bei Inbetriebnahme konfiguriert werden? Wie können Security-Updates installiert werden?

Wie die technische Dokumentation muss auch die Nutzer-Anleitung für jedes Produkt erstellt werden, das unter den CRA fällt — egal ob “important”, “critical” oder nicht. Im Gegensatz zur technischen Dokumentation muss die Nutzer-Anleitung aber mit dem Produkt ausgeliefert werden. Sie ist also gewissermaßen die “Security-Visitenkarte” des Produkts für seine Kunden. Damit ist diese Nutzeranleitung vielleicht das größte für den Anwender spürbare Novum des CRA, vor allem für B2B-Produkte.

Überblick

Zum Abschluss noch einmal alle Anforderungen und zu erstellenden Dokumente auf einen Blick:

Und jetzt?

Es hat in letzter Zeit viel Wirbel und Spekulationen um die “important” und “critical” products gegeben, denn das Konformitätsbewertungsverfahren unter Einbeziehung Dritter wollten viele Hersteller vermeiden. Mit Erfolg: Diese Liste ist nun viel kürzer und das Gros der Betroffenen wird 2027 wohl nur eine Selbsterklärung abgeben müssen.

Die “essential requirements” müssen aber durch jeden Hersteller von vernetzten Produkten erfüllt werden, egal, ob sie in den Anhängen III und IV auftauchen oder nicht. Und die drei Typen der Dokumentation — Conformity declaration, Technical documentation, information & instructions to the user — müssen ebenfalls von jedem erstellt werden.

Das ist nicht wenig Dokumentationsarbeit, die besonders kleinen Unternehmen Sorgen bereitet. Der CRA verspricht daher, dass es für all diese Dokumentationen vereinfachte Formen und Hilfestellung seitens der EU für kleine und mittelständische Unternehmen geben soll.

Aber tatsächlich erfordert das, was vordergründig wie lästige Dokumentation aussieht, im Kern Denkprozesse, die zu wirklich besserer Security führen und unabhängig von CRA-Regulierung absolut sinnvoll sind:

Gedanken über intendierte Funktionen, Dokumentation dieser Funktionen, vorhersehbarer Missbrauch dieser Funktionen, eine Risikoanalyse? Wenn Sie das gut machen, kommen Sie als Hersteller damit hinter den Ball, um zu entscheiden, welche Security-Maßnahmen eigentlich notwendig sind.

Ein Schwachstellenmanagementprozess, Anweisungen an den Nutzer, was er für die sichere Nutzung berücksichtigen muss? Wenn Sie das gut machen, machen Sie als Hersteller damit Ihre Kunden, die sich zunehmend Sorgen um Security machen (müssen), sehr glücklich.

Tatsächlich muss man, um mit diesen Schritten zu beginnen, auch nicht auf die Veröffentlichunge der harmonisierten Standards warten, die vor 2025 wohl sowieso nicht fertig werden.

Man kann als Hersteller auf den CRA schimpfen— er kommt aber sowieso. Dann kann man ihn eigentlich auch gleich als Chance begreifen, das lästige Security-Thema endlich strukturiert anzugehen, oder? Die gute Nachricht ist, dass die geforderte Dokumentation sowohl die richtigen Anreize und den Freiraum dafür bietet, die Kommunikation der Security seiner Produkte richtig gut zu machen — und sich damit positiv vom Wettbewerb abzuheben.