Folge 3: Der CRA kennt unterschiedlich kritische Klassen. Wir stellen sie Ihnen vor.
Was ist Kritikalität? Was sind Produktklassen? Wer ist betroffen? Und was hat das zur Folge? Diesen Fragen gehen wir in unserem dritten Beitrag zum Cyber Resilience Act (CRA) nach. Im zweiten Beitrag unserer Serie haben wir erfahren, warum es den CRA überhaupt gibt. Daran schließt sich also jetzt die Frage an, inwieweit denn Produkte einzuschätzen sind. Denn alle Hersteller, ob Konzern, KMU oder Kleinstunternehmen, möchten schließlich wissen, wie und in welcher Tiefe sie betroffen sind. Im Grunde kann man sich das anhand von ein paar trivialen Beispielen deutlich machen.
Die ersten Fragen, die man sich stellen muss, beziehen sich auf die einfachsten Eigenschaften von Produkten:
· Ist mein Produkt mit dem Internet direkt oder indirekt vernetzt? Wenn ja, dann geht es in die nächste Runde.
· Als Zweites sollte man die Frage beantworten, ob man mit der Software Geld verdient und sie nicht quelloffen publiziert wird. Damit ist nämlich alles entschieden. Schreibe ich eine proprietäre Software, um Geld zu verdienen, bin ich betroffen, wenn sie vernetzt ist.
Ein paar Beispiele sollen illustrieren, was gemeint ist: Wenn ich eine Motorsäge mit WIFI-Anschluss baue, bin ich drin. Genauso ist derjenige Hersteller mit von der Partie, der Bausätze zum Nachrüsten einer rein analogen Säge auf den EU-Markt bringen möchte. Es ist vollkommen egal, ob es sich um Apparate handelt, die etwa per Internet den Gashaushalt in einem Aquarium steuern, oder ob es sich nur um eine smarte Waage für den privaten Sportgebrauch handelt. Es sind digitale Elemente vorhanden, daher muss man sich an den CRA halten.
Es ist also sehr wahrscheinlich, dass sich bald eine Flut von Herstellern mit neuen Anforderungen konfrontiert sieht. Doch das sind wir in Europa eigentlich gewöhnt. Das Gesetz wurde gemäß dem Prinzip der Verhältnismäßigkeit geschrieben. Wer also unkritische Produkte baut, muss auch nicht so arg kontrollieren oder – besser – kontrolliert werden.
Dass sich jedoch generell etwas an der Lage der Produktsicherheit ändern muss, sollte der vorherige Beitrag hinreichend belegt haben. Offenbar reicht es nicht, dass dauernd in den Medien die Probleme und Schäden durch Cybercrime geschildert werden.
Infobox: Widersprüche
Die Lage ist eindeutig: Cyberkriminellen wird es immer noch zu leicht gemacht, einzubrechen. Härtung, Resilienz und korrektes Verhalten können Mittel sein, das Problem zu mitigieren. Wir benötigen aber auch eine Stärkung der Sicherheitsforschung. Erst durch gezielte Untersuchung schwacher Maschinen finden wir Lösungswege. Es gibt allerdings hier eine Reihe noch aufzulösender Inkonsistenzen mit bestehenden Gesetzgebungen. Stichwort Hackerparagraf 202c des Strafgesetzbuchs (StGB).1 Ein Strafmaß bis zu zwei Jahre Freiheitsentzug kann verhängt werden, wenn die Beschaffung und Verbreitung von Zugangscodes zu zugangsgeschützten Daten „illegal“ erfolgt. Darunter fallen auch die Herstellung und der Gebrauch von Tools, die diese Vorbereitungen zum Einbruch ermöglichen. Das gilt als Vorbereitung einer Straftat. Derzeit verurteilen Gerichte noch Spezialisten, die ohne Auftrag zum Beispiel Software erforschen, selbst wenn mit diesen Programmen gegen den CRA verstoßen werden würde. Ein Beispiel: Eine Firma lizenziert eine Software, die das lokale Warenhaltungssystem an ein übergeordnetes Verkaufsportal im Internet anbietet. Diese Schnittstelle wurde mit hart kodierten Passwörtern verkauft. Wenn die Software so nach 2027 auf den Markt käme, verstieße sie gegen die Forderung des CRA nach Security by Design/Default. Derjenige aber, der diese Sicherheitslücke aufgefunden hat, wäre immer noch per § 202c straffällig. Hier kollidieren Absichten verschiedener Perspektiven und erzeugen Klärungsbedarf.
Im Folgenden werfen wir zunächst den Blick auf die wichtigsten Pflichten, die aus dem Gesetz abgeleitet werden. Wir stellen kurz die Kritikalitätsklassen vor, die besagen, welches Produkt in welcher Kategorie welche Pflichten zu erfüllen haben. Dann stellen wir noch eine Ausnahme vor, denn auch die gibt es.
Verantwortung beim Hersteller
Zunächst einmal tragen Hersteller die Hauptverantwortung für die Cybersicherheit ihrer Erzeugnisse. Der CRA schreibt, wie auch andere Gesetze, eine Reihe verbindlicher Pflichten vor. Diese gelten bereits vom Moment der Entwicklung eines Produkts an und überspannen die komplette Lebensdauer bis zum „Ende“ eines Produkts (EOL, End of Life Cycle). Hinzu kommt: Nicht jedes Produkt ist gleichermaßen stark vom CRA betroffen, und manche Geräte werden erst in kritischen Umgebungen zu kritischen Geräten. Das heißt, dass die die Produkte hinsichtlich Kritikalität variieren. Mit steigender Kritikalität steigen die Sicherheitsanforderungen, die das Gesetz an die Hersteller stellt.
Was sind die wichtigsten Herstellerpflichten?
· Schon während der Konzeptions- und Entwicklungsphase müssen Hersteller potenzielle Sicherheitsrisiken analysieren und minimieren. Eine Risikobewertung vor Markteinführung ist verbindlich vorzunehmen, um Schwachstellen frühzeitig identifizieren zu können. Produkte sind von vornherein so zu konzipieren, dass sie standardmäßig mit hohen Sicherheitsvorkehrungen ausgestattet sind (Stichwort Security by Default, z. B. Verbot schwacher Standardpasswörter, Verbot hart kodierter Passwörter).
· Hersteller müssen außerdem ein systematisches Schwachstellenmanagement aufsetzen und pflegen. Das bedeutet, dass das Produkt immer und fortwährend auf bekannte Sicherheitslücken kontinuierlich überwacht wird. Wird entdeckt, dass es eine Lücke gibt, muss sie umgehend geschlossen werden. Das bekommen Hersteller von Softwareprodukten, dass sie hierfür eine Software-Stückliste (SBOM) aller verwendeten Komponenten führen, um bei Bekanntwerden neuer Schwachstellen schnell reagieren zu können.
· Außerdem müssen regelmäßige Sicherheitsupdates bereitgestellt werden. Das muss über einen definierten Mindestzeitraum nach Markteinführung passieren. Die EU-Kommission sieht hier in der Regel mindestens fünf Jahre Support für sicherheitsrelevante Updates vor. Diese Dauer muss gegenüber den Endanwendern transparent kommuniziert werden. Sollte die Lebensdauer eines Produkts kürzer sein, verkürzt sich auch diese Verpflichtung.
· Alle Sicherheitsfunktionen, bekannten Schwachstellen sowie vorgenommene Updates eines Produkts müssen umfassend dokumentiert werden. Zudem ist vom Hersteller eine EU-Konformitätserklärung zu erstellen, die bestätigt, dass das Produkt alle CRA-Anforderungen erfüllt. In der Regel übernimmt das der Hersteller selbst. Tool hierzu ist die interne Selbstbewertung. Das gilt jedoch nicht für alle Produkte. Bestimmte kritische Produktkategorien benötigen jedoch eine externe Zertifizierung durch eine benannte Stelle (notified body). Produkte, die die Anforderungen erfüllen, erhalten die CE-Kennzeichnung (Conformité Européenne) als Nachweis der Cybersecurity-Konformität mit den Regularien für den europäischen Markt.
· Sollte der Hersteller eine gravierende Sicherheitslücke entdecken, oder es tritt ein schwerwiegender Cybervorfall im Zusammenhang mit dem Produkt auf, besteht eine Meldepflicht. Innerhalb von 24 Stunden muss der Vorfall an die zuständigen Behörden bzw. eine zentrale EU-Meldeplattform, die von der europäischen Cybersicherheitsbehörde ENISA aufgesetzt wird. Das kann man sich als Warnsystem denken. Es soll einen schnellen Informationsaustausch ermöglichen und koordinierte Gegenmaßnahmen in der EU erleichtern. Hersteller müssen daher interne Prozesse einrichten, um solche Vorfälle unverzüglich zu erkennen und zu melden.
Das meiste ist Standard
Es ist davon auszugehen, dass die meisten Produkte, für die der CRA relevant ist, im Standardbereich angesiedelt sind und damit per Selbstdeklaration gemeldet werden können. Dazu gehören etwa Games oder Bildbearbeitungsprogramme. Allerdings gibt es auch Produkte mit höherer Kritikalität. Sie werden als wichtig oder in oberster Stufe als kritisch bezeichnet. Wichtige Produkte unterteilen sich zudem in Klasse I und Klasse II. Unter die erste Klasse fallen beispielsweise Betriebssysteme, Passwortmanager oder eigenständige bzw. eingebettete Browser. Und in Klasse II. finden sich Firewalls, manipulationssichere Mikrocontroller und -prozessoren oder Software zur Angriffserkennung bzw. -prävention.
Ausnahmen bestätigen die Regel
Stellen Sie sich vor, Sie arbeiten tagsüber in einem Softwareunternehmen. In Ihrer Freizeit sind Sie leidenschaftlicher Programmierer. Sie programmieren einen einfachen Texteditor, den man über das Internet auf den neuesten Stand bringen kann. Da Sie regelmäßig daran arbeiten und Ihnen Sicherheit am Herzen liegt, achten Sie besonders auf Security by Design und Default. Die Software stellen Sie als Quellcode und als Bytecode im Internet in einschlägigen Repositories zur Verfügung. Die Software selbst veröffentlichen Sie unter der GNU General Public Licence. Sie haben eine Reihe befreundeter Coder, die Ihnen dabei helfen, die Software stets sicher und up to date zu halten. Außerdem läuft ein Bug-Bounty-Programm. Sie geben jedem, der einen Bug oder einen Exploit findet, einen Kaffee aus. Das hat Ihr Programm zu einiger Berühmtheit verholfen.
Jetzt fragen Sie sich, ob Sie vom CRA betroffen sind. Sind Sie’s? Nein, sind Sie nicht. Das Szenario, das hier beschrieben wurde, stellt einen einwandfreien Fall von Open-Source-Entwicklung vor. Und solche Software ist vom CRA ausgenommen. Ein Kriterium für die CRA-Betroffenheit ist somit auch die Gewinnerzielungsabsicht. Fehlt diese und kommt die Software der Allgemeinheit zugute, muss man keine Befürchtungen haben, unter den CRA zu fallen.
Es gibt eine Reihe weiterer Produktgruppen bzw. Branchen, die nicht betroffen sind. Das hat seinen Grund meist darin, dass es bereits bestehende oder gerade in Kraft tretende neue Regulierungen gibt. Dazu zählen beispielsweise Produkte aus der Medizin. Und wie immer gibt es ein paar kryptische Abkürzungen dazu. Produkte, die unter die MDR (Medical Device Regulation) fallen, oder die unter die IVDR (In Vitro Diagnostic Regulation) gehören, sind nicht CRA-relevant. MDR und IVDR sind zwei EU-Verordnungen, die neue, strengere Regeln für die Zulassung, Sicherheit und Überwachung von Medizinprodukten (z. B. Implantate, OP-Instrumente) und In-vitro-Diagnostika (z. B. Labortests, Schwangerschaftstests) im europäischen Markt festlegen. Ebenfalls werden Produkte im Bereich Luftfahrt und Marine ausgenommen. Was auch nicht reguliert wird, sind Produkte für nationale Sicherheits- oder Verteidigungszwecke. Hinzu kommen Ersatzteile, die nicht eigenständig funktionieren können. Einfaches Beispiel: eine herkömmliche RJ45-Steckdose. Mit Blick auf die Automobilindustrie werden all jene Fahrzeuge und Komponenten nicht durch den CRA reguliert, die durch Typengenehmigungsverfahren geprüft werden (EU-Verordnung 2019/2144). Für cloudbasierte Dienste (SaaS, Software as a Service) gilt normalerweise auch, dass sie nicht direkt vom CRA betroffen sind, solange sie keine lokal installierbaren digitalen Komponenten enthalten. SaaS ist ein Grenzfall, da sie eher wie eine „Organisation“ funktioniert. Man mietet sich ja als Kunde ein und bekommt eine Infrastruktur mit einer ganzen Reihe von Akteuren und nicht nur das, was im Browser zu sehen ist. Daher fällt SaaS meistens unter die NIS-2-Richtlinie.
Offene Enden
Quelloffene Software fällt nicht unter den CRA. Aber auch hier gibt es wieder Ausnahmen. Es gibt Lizenzen für quelloffene Software, die es erlauben, dass man diese in Produkte einbaut und damit Geld verdient. Ein Beispiel sind NAS-Geräte, die etwa mit TrueNAS, einem quelloffenen System auf der Basis des Linux-Kernels. Das wiederum kann in Hardware zum Einsatz kommen, die hergestellt und mit TrueNAS als Betriebssystem ausgeliefert wird. Damit fällt das Gerät unter den CRA und muss entsprechend secure entwickelt, gemeldet, gepflegt, geupdatet und dokumentiert werden. Also entscheidet der Einzelfall. Den erkennt man aber erst, wenn man sich intensiv mit dem auseinandersetzt, was man tut. Und über diese Prozesse kann man zu größerer Sicherheit und Resilienz gelangen.
Software-Stücklisten (SBOM) werden verbindlich für die Erfüllung der Anforderungen aus dem CRA. Was das ist und wie man damit umgeht erfahren Sie im nächsten, vierten Teil unserer Serie zum Cyber Resilience Act.