./tell

Der Cyber Resiliance Act, eine Übersicht

Seit einiger Zeit beschäftigen wir uns bei ./kernel concepts nun mit dem Cyber Resiliance Act (kurz CRA), welcher im März 2024 vom Europäischen Parlament verabschiedet wurde. In diesem Blog haben wir die wichtigsten Informationen rund um den CRA für Euch zusammen getragen und aufbereitet.

Was ist der CRA?

Der Cyber Resiliance Act zielt darauf ab, Kunden und Nutzer von Produkten mit einer digitalen Komponente zuverlässiger zu schützen [1]
Es handelt sich um neues Gesetz, welches vorschreibt, dass alle in der EU in Umlauf gebrachten Produkte gewisse Richtlinien, abhängig von ihrer Risikoklasse erfüllen. Hierzu muss jedes Produkt, welches unter die Regularien fällt, ein entsprechendes Kennzeichen tragen, um vertrieben werden zu dürfen. Gemäß der Definition der EU fallen so gut wie alle Endgeräte und Software-Komponenten unter die neuen Vorgaben.

Bei den Produkten für Endverbaucher betrifft dies z.B. Unterhaltungselektronik, Smart-Home-Komponenten aber auch Smartphone-Apps und PC Software. Im B2B-Bereich fallen viele Komponenten für Industrie-, Umwelt- und Energietechnologie unter die Verordnung. z.B. Sensoren, Steuerungssystene, Systeme zur Datenaufbereitung und Analysem, HMI Systeme usw. Selbstverständlich zählt auch die Medizintechnik dazu.

Was bedeutet der CRA für Kunden?

Für die Käufer der Geräte ändert sich erstmal nicht viel. Sie können sich über die neuen Sicherheitsstandards ihrer Käufe freuen und bekommen die Möglichkeit sich jederzeit über bestehende Sicherheitslücken, ihrer genutzten Produkte informieren. Es ist allerdings möglich, dass der gestiegene Aufwand in der Entwicklung sich auf die Preise von Produkten auswirkt.

Was bedeutet der CRA für Unternehmen?

Hier wird die Liste der Auswirkungen schon umfangreicher. Jeder Hersteller, der Produkte in der EU vertreibt, muss mit Inkrafttreten des CRA gewährleisten, dass seine Hard- und Software die nötigen Sicherheitsstandards erfüllt. Hierzu muss er entsprechende Zertifikate erwerben. Für alle Produkte der Standardkategorie muss der Hersteller eine Konformitätserklärung abgeben und die vorgenommen Maßnahmen dokumentieren, um das benötigte CE-Kennzeichen zu erhalten. [2]

Bei allen zu zertifizierenden Produkten, welche nicht in die Standardkategorie fallen, ist eine Prüfung durch eine entsprechende Behörde nötig, um das entsprechende Kennzeichen anbringen zu können.
Es wird geschätzt, dass ca. 90 % aller Produkte in die Standardkategorie fallen. Hier sind Produkte und Software einzuordnen, die keine cybersicherheitsrelevanten Aufgaben erfüllen (z.B. Social-Media-Apps, Videospiele oder vernetzte Haushaltsgeräte).
Der Großteil der restlichen Produkte werden in zwei Klassen unterteilt. In Klasse I befinden sich Produkte, welche als cybersicherheitsrelevant eingestuft werden (z.B. Anti-Viren-Programme und Netzwerkkomponenten). Klasse II wird für Produkte verwendet, die auch als Sicherheitsrelevant gelten und deren Manipulation weitreichendere Folgen hätte, als bei Produkten aus Klasse I. Hier sind als Beispiele industrielle Firewalls und SCADA-Systeme zu nennen.
Darüber hinaus gibt es noch eine vierte Kategorie, welche in einem weiteren Anhang des CRA definiert wird. In dieser Kategorie finden sich allerdings nur wenige Produkte und eine Einstufung in diese Kategorie erfolgt auch nur, wenn eine Sicherheitsrelevanz für kritische Infrastruktur vorliegt. [2,3] Ein Beispiel dafür sind Smart-Meetering-Gateways zur Übertragung von Energieverbrauchsdaten.

Doch mit dem Erwerb des Zertifikats ist die Arbeit noch nicht getan. Des Weiteren muss sich jedes Unternehmen über die gesamte Lebenszeit seiner Produkte um Updates für deren Sicherheit kümmern. Außerdem ist jede bekannt werdende Sicherheitslücke innerhalb von 24 Stunden der entsprechenden Behörde zu melden [4], welche die bekannten Risiken dann an die Endkunden weiter gibt.

All diese neuen Vorgaben werden Unternehmen vor eine große Herausforderung stellen, welche die benötige Arbeitszeit an jedem Projekt signifikant erhöhen wird.

Was bedeutet der CRA für uns?

Nicht erst seit verabschiedung des CRA verfolgen wir die Konzepte „Security by design“ und „Security by default“. Wir sind Entwickler mit Verantwortung und selbstverstädnlich richten wir unsere Entwicklung schon in der Planungsphase auf Sicherheit und Fehlerfreiheit aus. Doch in der Vergangenheit hat sich gezeigt, dass dies nicht bei jedem Projekt auch dann noch konsequent weiter verfolgt wurde, wenn unser Teil der Entwicklung abgeschlossen ist.

Somit werden wir in Zukunft noch um so mehr beraten und unsere Kunden bei Ihren Projekten nicht nur in der Entwicklungsphase sondern über die gesamte Lebensdauer des Produktes unterstützen.

Auch uns stellt der CRA vor eine große Herausforderung. Vor allem im Bereich der Dokumentation und Bewertung von OpenSource Komponenten sowie Pflegen von Patches etc. werden wir viel mehr Ressourcen aufbringen müssen, als in der Vergangenheit. Was das in der Praxis für die Projekte bedeutet, werden wir zusammen mit unseren Kunden erarbeiten.

Open-Source unter dem CRA

Der erste Entwurf des Gesetztes war für die Open-Source-Entwicklung höchst kritisch und hätte diese vermutlich nahezu gänzlich zum Erliegen gebracht. Das Problem bestand darin, dass die erste Fassung des CRA immer den Entwickler von Code in die Pflicht genommen hätte, seine Arbeit mit Zertifikaten zu versehen. Da jedoch viele Developer im privaten Rahmen Tools und Code entwickeln, den sie anderen Entwicklern kostenfrei zur weiteren Verwendung bereitstellen, hätten diese in den meisten Fällen nicht die Kapazitäten gehabt, diese Richtlinien zu erfüllen. Folglich hätten sie die Entwicklung einstellen müssen. Das wäre ein harter Schlag für die Entwicklung von Software im Allgemeinen. In kaum einer anderen Branche helfen sich entfernte Kollegen so selbstverständlich mit ihrer Arbeit aus, wie in der Software Entwicklung. Die erste Fassung des CRA hätte dies unmöglich gemacht. [5]

Hierfür wurde aber eine gute Lösung gefunden. Im fertigen Gesetzestext, wird derjenige in die Pflicht genommen, die Richtlinien zu erfüllen, der die geschriebene Software für seine wirtschaftlichen Interessen nutzen möchte. [6]

Was ist der aktuelle Stand der Dinge?

Der CRA wurde im März 2024 vom Europäischen Parlament verabschiedet. Bis die Regeln in Kraft treten, gibt es eine Übergangsphase von 36 Monaten. Wir haben bereits mit einigen Kunden begonnen, uns zusammen zusetzten, um die Implementierung der neuen Regeln in unsere gemeinsamen Projekte zu planen. Und wir empfehlen anderen Unternehmern, sich auch zeitnah mit der Thematik auseinander zu setzten.

Links

[1] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
[2] https://www.security-insider.de/eu-cyber-resilience-act-cra-neue-vorgaben-vernetzte-produkte-a-da11d4f61a65be1d98a29ca7a7794c6f/
[3] https://legal.pwc.de/de/news/fachbeitraege/europaeische-kommission-verabschiedet-entwurf-fuer-cyber-resilience-act
[4] https://www.dihk.de/de/themen-und-positionen/wirtschaft-digital/dihk-durchblick-digital/cyber-resilience-act-cra–90956
[5] https://www.golem.de/news/cyber-resilience-act-grosse-auswirkungen-auf-open-source-befuerchtet-2301-171517.html
[6] https://www.golem.de/news/cyber-resilience-act-open-source-entwickler-bedanken-sich-bei-eu-fuer-einlenken-2402-181869.html