Insight

So werden die Weichen auf Konformität mit dem Cyberresilienzgesetz der EU (CRA) gestellt

Das Cyberresilienzgesetz (Cyber Resilience Act, CRA) stellt einen bedeutenden Wendepunkt dar, weil es Hersteller für die digitale Sicherheit ihrer Produkte im europäischen Markt offiziell in die Verantwortung nimmt. In einigen Fällen trifft dies auch für Importeure und Händler zu. Die Verordnung gilt für alle Produkte mit digitalen Elementen, die mit einem anderen Gerät oder Netzwerk verbunden werden können und für den Verkauf in Europa bestimmt sind. Wesentliche Cybersicherheitsstandards wurden bereits definiert und werden gerade in branchenspezifische Standards überführt. Helbling hat jahrelange Erfahrung in der Entwicklung von Produkten, die Regulatorien erfüllen müssen, und unterstützt Unternehmen auch bei der Umsetzung der neuen CRA-Verordnung. Dabei können Unternehmen von Helblings Expertise profitieren, wobei bewährte Methodik mit neuester Technologie kombiniert wird.

Die Cyberangriffe auf digitale Produkte führen zunehmend zu erheblichen finanziellen Verlusten [1]. Gleichzeitig haben die Auswirkungen der Angriffe auf Produkte zugenommen, da sich durch die Vernetzung die Angriffsfläche für Cyberkriminelle vergrössert. Insbesondere Schwachstellen in den Lieferketten sind zu einem hohen Risiko geworden, weil sie bösartige Aktivitäten wie DDoS-Angriffe und die anonyme Verbreitung von Schadsoftware in teils gross angelegten Cyberangriffen begünstigen. Ein jüngeres Beispiel ist ein Botnetz, das von Cyberakteuren auf kompromittierter Hardware aufgebaut wurde und das von der National Security Agency (NSA) und dem Federal Bureau of Investigation (FBI) mit der Volksrepublik China in Verbindung gebracht wird [2].

Um dieser Entwicklung bestmöglich entgegenzuwirken, initiierte die Europäische Kommission 2022 das Cyberresilienzgesetz (CRA, [3]). Es legt wesentliche Cybersicherheitsstandards für Hersteller fest – unabhängig davon, ob es sich um ein Unternehmen aus der EU oder um ein externes handelt. Angesprochen sind alle, die ein Produkt auf den EU-Markt bringen wollen [4] –unter der Voraussetzung, dass dessen „vorgesehener Zweck oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder einem Netzwerk umfasst“ (CRA, Art. 2.1 [3]).

Abbildung 1: Zeitplan zum Cyberresilienzgesetz. Abbildung: Helbling 

Das Cyberresilienzgesetz ist verbindlich und dessen Erfüllung wird zur Voraussetzung für die CE-Kennzeichnung und den Vertrieb von Produkten mit digitalen Elementen auf dem europäischen Markt. Bis Ende 2027 bleibt noch Zeit, um alle Anforderungen umzusetzen. Allerdings ist es empfehlenswert, dass Unternehmen bereits jetzt die notwendigen Massnahmen ergreifen. Einzelheiten zum Cyberresilienzgesetz und seinem Zeitplan finden sich am Ende des Textes.

Helbling ist für Unternehmen bei der Umsetzung des Cyberresilienzgesetzes ein kompetenter Partner mit vielen Jahren Erfahrung in der Entwicklung von Produkten mit digitalen Elementen. Darunter sind insbesondere auch zahlreiche Projekte in regulierten Branchen wie der Medizintechnik. Helbling-Fachleute haben erfolgreich risikobasierte Entscheidungen und Cybersecurity-Analysen in den Design- und Entwicklungsprozess integriert und unterstützen Kunden auch dabei, erforderliche Standards zu erfüllen. Gleichzeitig hilft Helbling bei der Integration robuster Sicherheitspraktiken in den Betrieb. Mit Blick auf das CRA haben die Fachleute von Helbling ihre bewährte Methodik ausgeweitet und integrieren stets neueste Technologien, um die Umsetzung der Vorschriften so effizient und effektiv wie möglich zu gestalten.

Das Cyberresilienzgesetz verbessert die digitale Resilienz des gesamten Ökosystems

Gemäss Cyberresilienzgesetz, Art. 3 [3] ist der Begriff „Cybersicherheit“ wie in Art. 2, Punkt (1), der Verordnung (EU) 2019/811 definiert als: „die Tätigkeiten, die notwendig sind, um Netz- und Informationssysteme, die Nutzer solcher Systeme und andere von Cyberbedrohungen betroffene Personen zu schützen“ [5]. Das Gesetz setzt folglich auf einen defensiven Cybersicherheitsansatz: Durch die Verbesserung der Sicherheit sollte ein Produkt immer betriebsfähig bleiben und nicht kompromittiert werden. Angreifer zielen jedoch selten auf das Gerät selbst ab; stattdessen nutzen sie es als Zugangspunkt zum tatsächlichen Ziel, welches der Nutzer sein könnte oder der Bediener an einem Produktionsstandort. Deshalb wird das Cyberresilienzgesetz, wie der Name schon andeutet, letztlich die digitale Resilienz des gesamten Ökosystems stärken.

Das Cyberresilienzgesetz sieht eine strenge Durchsetzung vor – mittels Strafen, wenn die im Annex I definierten grundlegenden Cybersicherheitsanforderungen und Pflichten gemäss Artikel 13 und 14 (CRA, Art. 64) [3] nicht eingehalten werden. Die Strafen können in Form von Bussgeldern von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes gesprochen werden, je nachdem, welcher Betrag höher ist. Die Höhe der Strafe hängt hauptsächlich von zwei Faktoren ab: der Organisation, die sich die Nichtkonformität zu Schulden kommen liess (vor allem ihrer Grösse), und der Art der Nichteinhaltung (Art, Schwere und Dauer sowie deren Folgen).

Wie anfangen?

Ein guter Ausgangspunkt – sobald die Anforderungen an die Cybersicherheit klar sind – ist die Einführung der leicht anzuwendenden Methodik der Bedrohungsanalyse, Threat Modeling genannt, und die frühzeitige Übernahme von Verantwortung durch die Beteiligten. Es ist besonders wichtig, Entwickler einzubeziehen, egal ob für Hardware oder Software. Denn ein wichtiger Erfolgsfaktor liegt darin, dass Sicherheit als gemeinsame Verantwortung wahrgenommen wird. Nur so gelingt es, das System und seine inhärenten Cybersicherheitsrisiken gesamtheitlich zu betrachten. Das ist letztlich die Voraussetzung für eine ausgewogene Sicherheitsarchitektur. Dabei ist auch die Priorisierung der identifizierten Cyberrisiken entscheidend, um nicht von der schieren Anzahl der Angriffspunkte überwältigt zu werden. Oftmals reduziert die Mitigation bestimmter Risiken auch andere, weshalb diese Bewertung iterativ durchgeführt werden muss.

 

Etablierung der drei wichtigsten Grundpfeiler

Der defensive Ansatz des Cyberresilienzgesetzes lässt sich zusammenfassen durch die folgenden drei Grundpfeiler, die berücksichtigt werden müssen (siehe Annex I und Annex II [6]):

  1. Sicheres Produkt: Sicherstellen, dass ein Produkt nur dann auf den Markt gebracht wird, wenn es von vornherein und standardmässig sicher ist.
  2. Sicherer Betrieb: Hersteller verpflichten, die Sicherheit ernst zu nehmen und diese während des gesamten Produktlebenszyklus durch Bereitstellung von Sicherheitsupdates zur Behebung neu auftretender Schwachstellen zu gewährleisten.
  3. Transparenz und Offenlegung: Nutzer befähigen, Cybersicherheit beim Kauf und bei der sicheren Nutzung von Produkten zu berücksichtigen.
Abbildung 2: Die drei Grundpfeiler des Cyberresilienzgesetz (Abbildung: Helbling)

Grundpfeiler 1: Sicheres Produkt

Wie wird „Security by design“ erreicht?

Die Anwendung von „Security by design“ bedeutet: Der Fokus liegt darauf, die Schwachstellen zu minimieren und die Angriffsfläche des gesamten Systems zu reduzieren. Dabei ist es wichtig, einen ganzheitlichen Ansatz zu verfolgen, um potenzielle Risiken zu identifizieren, die bei einer Konzentration auf einen isolierten Teil des Systems möglicherweise übersehen werden. Wie erwähnt, ist das Produkt selbst selten das Ziel, daher sollte eine Analyse der Cybersicherheitsbedrohungen das gesamte System umfassen, um die möglichen Auswirkungen von Angriffen besser einordnen zu können. Ein solche Analyse umfasst auch die Art und Weise, wie Benutzer mit dem System interagieren; auch unbeabsichtigter Missbrauch kann zu Schwachstellen führen.

Die frühzeitige Berücksichtigung der Cybersicherheit bei der Spezifikation und dem Design eines Produkts ist entscheidend. Nur das ermöglicht die Entwicklung einer robusten Sicherheitsarchitektur, die Cyberangriffen standhält und dabei weniger Aufwand und Kosten verursacht als nachträgliche Änderungen zur Verbesserung der Sicherheit in bestehendem Design.

Ein weiterer wichtiger Aspekt beim Aufbau einer robusten Sicherheitsarchitektur liegt darin, die Sicherheit durchgängig, also Ende-zu-Ende zu betrachten. Sobald Daten über unsichere Transportkanäle durch Verschlüsselung geschützt sind, verschiebt sich der Fokus darauf, wie der Schlüssel gesichert wird. Angesichts der Verschiebung von netzwerk- hin zu identitätsbasierten Angriffen rückt die Authentifizierung von Benutzern und Geräten in den Fokus. Doch worauf kann man wirklich vertrauen? Wird beispielsweise die Secure-Boot-Funktion genutzt, um das Laden von Schadsoftware bei Starten (Boot) des Produkts zu verhindern?

Wie wird „Security by default“ erreicht?

„Security by default“ bedeutet, dass Produkte so entwickelt werden, dass die sicherste Konfiguration und die sichersten Einstellungen standardmässig und unmittelbar nach dem Auspacken aktiviert sind. Anstelle sich darauf zu verlassen, dass Nutzer Sicherheitsmassnahmen nach der Bereitstellung implementieren, werden Sicherheitsfunktionen automatisch integriert und aktiviert, ohne zusätzliche Schritte.

Bei einem Produkt beginnt „Security by default“ normalerweise damit, die Anzahl potenzieller Einstiegspunkte zu reduzieren, indem unnötige Dienste und Funktionen deaktiviert werden. Dazu zählt zum Beispiel eine Diagnosefunktion mit detaillierter Protokollierung. Wann immer ein Gerät Zugang zu sensiblen Daten bietet, müssen starke Authentifizierung und das Prinzip von Least Privilege angewendet werden. Daten müssen gespeichert und während der Übertragung kryptographisch geschützt sein.

Nutzen Hersteller von Produkten Protokolle wie OPC UA, welche mit einer Sicherheitsarchitektur konzipiert wurden, müssen sie sicherstellen, dass die vorgesehenen Sicherheitsmassnahmen wie ACLs nicht optional sind, auch dann nicht, wenn dies die Betriebsabläufe komplexer macht.

 

Grundpfeiler 2: Sicherer Betrieb

Während des gesamten Lebenszyklus müssen sichere Software-Updates durchgeführt werden können – signiert und verschlüsselt sowie idealerweise automatisch getestet. Dies ist nicht nur aus Gründen der Cybersicherheit wichtig, sondern auch, um das Ausrollen von Verbesserungen und neuen Funktionen schnell und gleichzeitig in hoher Qualität zu ermöglichen.

Für einen sicheren Betrieb ist ein effizientes Management von Schwachstellen unerlässlich. Dementsprechend rückt die „Software Bill of Materials“ (SBOM) in den Mittelpunkt (Annex I, Teil II, Punkt (1) [6]). Diese ermöglicht eine schnelle Bewertung der Gefährdung eines Produkts durch neue Schwachstellen. Durch das Cyberresilienzgesetz ist es ohnehin obligatorisch, eine SBOM zu erstellen. Als Hilfestellung hat das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) die SBOM-Anforderungen durch die Veröffentlichung der technischen Richtlinie TR-03183 [8] präzisiert. Damit die SBOM auch den erwarteten Nutzen bringt, sollte bei ihrer Erstellung unbedingt einem Standard gefolgt werden.

Die Idee, Sicherheit als gemeinsame Verantwortung zu betrachten, ist auch im Betrieb grundlegend. Der Begriff DevSecOps spiegelt dies in der Methodik wider, Entwicklungs-, Betriebs- und Sicherheitspraktiken zusammenzubringen. Sie hat zum Ziel, die Verantwortung für die Sicherheit in der gesamten Software-Lieferkette zu integrieren. Dazu gehört auch, die Prozesse zur Erstellung und Pflege einer SBOM zugunsten der Konsistenz und Nachvollziehbarkeit zu standardisieren. Die frühzeitige Erstellung der SBOM während der Entwicklungsphase hilft bei der Verfolgung aller Softwarekomponenten Ende-zu-Ende und sorgt für Transparenz, so dass Unternehmen einen Einblick in ihre Lieferkette erhalten.

Im Betrieb kann das Monitoring durch neue Ansätze weiter automatisiert werden, etwa durch KI-Agenten-basierte Systeme, die das Schwachstellen-Monitoring für ein SBOM übernehmen und bei besonders kritischen Risiken sogar automatisiert Patches zur Verfügung stellen können.

Mit höherem Automatisierungsgrad und Reife der DevSecOps-Prozesse können Organisationen Probleme schneller beheben und dadurch die Bedrohungsanfälligkeit deutlich reduzieren.

 

Grundpfeiler 3: Transparenz und Offenlegung

Das Bewusstsein, auch Awareness genannt, ist Ausgangspunkt für alle Sicherheitsüberlegungen. Das heisst, eine Nutzerin muss über Schwachstellen im Produkt Bescheid wissen. Sie muss folglich wissen, wo Informationen über Schwachstellen angefordert werden können und was die koordinierte Richtlinie zur Offenlegung von Schwachstellen beinhaltet (Annex II, Punkt (2) und Annex I, Teil II, Punkt (5) [6]). Nach der Behebung von Schwachstellen durch Sicherheitsupdates sind die Hersteller verpflichtet, diese Informationen öffentlich bekannt zu geben sowie den Nutzern klare Anweisung zur Behebung des unsicheren Zustands zu geben (Annex I, Teil II, Punkt (4) [6]). Dies sorgt für Transparenz und vermittelt den Nutzern das nötige Wissen, um ihre Systeme zu schützen und die erforderlichen Massnahmen zu ergreifen. Das soll Sicherheit und Resilienz in einer sich rasch entwickelnden digitalen Landschaft gewährleisten.

Während des gesamten Produktlebenszyklus müssen den Endnutzern Anleitungen zur Verfügung gestellt werden – in Bezug auf Sicherheit bei der Installation, Bedienung und Nutzung. Um die Sicherheit eines Produkts einschätzbar zu machen, müssen ausserdem einschlägige technische Unterlagen zur Verfügung gestellt und über zehn Jahre nach dem Inverkehrbringen des Produkts aufbewahrt werden (CRA, Art. 13, Punkt 13 [3]). Damit wird das Konzept des „Bewusstseins“ auf den Endnutzer ausgedehnt und Ende-zu-Ende umgesetzt.

Abbildung 3: Wachsendes Bewusstsein von Anfang bis Ende eines Projekts. Abbildung: Helbling 

Zusammenfassung: CRA-Konformität ist als kontinuierlicher iterativer Prozess zu bewältigen

Das Cyberresilienzgesetz ist im Wesentlichen eine Erweiterung der CE-Kennzeichnung. Durch die Ergänzung erhält die Cybersicherheit angesichts der ständig wachsenden Bedrohungen angemessenes Gewicht. Dabei ist es unumgänglich, die Sicherheit in die DNA der Herstellung eines Produkts mit digitalen Elementen zu integrieren – insbesondere, um die Anforderungen an den Umgang mit Sicherheitslücken effizient zu erfüllen.

Die Herausforderungen einer CRA-Konformität für Unternehmen mögen beträchtlich erscheinen, für manche vielleicht sogar wie eine Herkulesaufgabe. Dabei ist es umso wichtiger, nicht in Panik zu verfallen, sondern die Reise zu beginnen: Es handelt sich um einen iterativen Prozess und jetzt ist der ideale Zeitpunkt für eine erste Iteration. Helbling unterstützt seine Kunden im gesamten Lebenszyklus, beginnend bei der Konzeption und Entwicklung bis zum Betrieb der Produkte, und bringt das spezifische Wissen interdisziplinärer Teams und jahrelange Erfahrung ein.

 

Autoren: Frederic de Simoni, Martin Junghans

Hauptbild: iStock

Factbox

6 Antworten für die Praxis

1. Für welche Produkte gilt das Cyberresilienzgesetz?

Das Gesetz gilt für alle in Europa in Verkehr gebrachten Produkte mit digitalen Elementen, die entweder direkt oder indirekt mit einem anderen Gerät oder einem Netzwerk verbunden werden können. Ausgenommen sind Produkte, für welche die Cybersicherheitsanforderungen bereits in bestehenden EU-Vorschriften festgelegt sind, dazu gehören beispielsweise medizinische Geräte, Luftfahrtprodukte und Autos. CRA, Art. 3 [3] stellt klar, dass alle Softwarelösungen ebenfalls in den Anwendungsbereich des Gesetzes fallen, wenn sie mit einem Produkt verbunden sind, etwa eine SaaS-Plattform, die Daten von einem IoT-Gerät empfängt.

2. Wie sieht der Zeitplan für die neuen Vorschriften aus?

Das Cyberresilienzgesetz wurde am 10. Oktober 2024 fertiggestellt und wird zeitnah von den Präsidenten des Rates und des Europäischen Parlaments unterzeichnet. Die neue Verordnung tritt zwanzig Tage nach ihrer Veröffentlichung im EU-Amtsblatt in Kraft (EIF). Die Produkthersteller haben drei Jahre Zeit, um die Anforderungen vollständig zu erfüllen. Im Jahr 2026, nach 21 Monaten, werden Meldungen an die Behörden obligatorisch sein. Nach 36 Monaten muss die vollständige Erfüllung des Cyberresilienzgesetz abgeschlossen sein. (CRA, Art. 71, 2) [3].

3. Was geschieht mit bestehenden Produkten mit digitalen Elementen auf dem EU-Markt?

Produkte, die vor 2027 (EIF + 36 Monate) auf den Markt gebracht werden, müssen nur dann der Richtlinie entsprechen, wenn an dem Produkt wesentliche Änderungen vorgenommen werden. Diese beziehen sich auf Hardware und Software.

4. Wie bleibt man mit den auf dem Markt befindlichen Produkten konform?

Sobald ein Produkt mit digitalen Elementen die Anforderungen des Cyberresilienzgesetz erfüllt, gibt es zwei potenzielle Gründe, warum es später nicht mehr konform sein kann:

  • Es werden wesentliche Änderungen am Produkt vorgenommen, zum Beispiel durch eine neue Softwareversion mit neuen Funktionen.
  • Es wurde eine neue Schwachstelle gefunden, die mit einem Sicherheitsupdate behoben werden muss, aber mit Verzögerung behandelt wird.

5. Was sind wesentliche Änderungen an Software?

Eine Software-Änderung an einem Produkt mit digitalen Elementen wird als wesentlich angesehen, wenn die Software-Aktualisierung den beabsichtigten Zweck des Produkts ändert und diese Änderungen vom Hersteller bei der ursprünglichen Risikobewertung nicht vorhergesehen war. Als wesentlich gilt es auch, wenn sich die Art der Bedrohung geändert oder sich das Cybersicherheitsrisiko aufgrund der Software-Aktualisierung erhöht hat (PE-100-2023-INIT (2024) Punkt (39) [7]). Im Gegensatz dazu sollten geringfügige Aktualisierungen der Funktionalität, wie visuelle Verbesserungen, das Hinzufügen neuer Sprachen zur Benutzeroberfläche oder eines neuen Satzes von Piktogrammen, im Allgemeinen nicht als wesentliche Änderungen betrachtet werden.

Ein Beispiel für eine wesentliche Änderung ist das Hinzufügen neuer Eingabeelemente zu einer Anwendung, wobei der Hersteller eine angemessene Eingabevalidierung sicherstellen muss. Das Hinzufügen neuer Funktionen führt in der Regel zu einer grösseren Angriffsfläche und erhöht damit das Cybersicherheitsrisiko. Daher müssen die neuen Risiken vom Hersteller neu bewertet werden.

6. Was ist mit Sicherheitsupdates?

Sicherheitsupdates, mit denen das Cybersicherheitsrisiko eines Produkts mit digitalen Elementen verringert werden soll, werden nicht als wesentliche Änderungen betrachtet. Diese ändern nicht den beabsichtigten Zweck eines Produkts. Zur Anwendung kommt das in der Regel bei Situationen, in denen Sicherheitsaktualisierungen nur geringfügige Anpassungen des Quellcodes nach sich ziehen.

Dies könnte der Fall sein, wenn eine Sicherheitsaktualisierung eine bekannte Schwachstelle behebt, auch durch Änderung der Funktionen oder der Leistung eines Produkts zu dem alleinigen Zweck, das Ausmass des Cybersicherheitsrisikos zu verringern. Eine Neubewertung der Sicherheitsrisiken ist daher nicht erforderlich.

Referenzen:

1. Laut IBM betragen die durchschnittlichen globalen Kosten einer Datenschutzverletzung im Jahr 2024 4,88 Millionen USD – ein Anstieg von 10% im Vergleich zum Vorjahr und der höchste Wert aller Zeiten, siehe https://www.ibm.com/reports/data-breach 

2. People’s Republic of China-Linked Actors Compromise Routers and IoT Devices for Botnet Operations,https://media.defense.gov/2024/Sep/18/2003547016/-1/-1/0/CSA-PRC-LINKED-ACTORS-BOTNET.PDF

3. CRA, https://www.cyberresilienceact.eu/the-cyber-resilience-act/

4. The legal term “placing on the market” is defined in the Blue Guide, 29 June 2022, clause 2.3, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.C_.2022.247.01.0001.01.ENG

5. Regulation (EU) 2019/81, https://eur-lex.europa.eu/eli/reg/2019/881/oj

6. CRA Annex, https://www.cyberresilienceact.eu/the-cyber-resilience-act-annex/

7. REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act), 10 October 2024, https://data.consilium.europa.eu/doc/document/PE-100-2023-INIT/en/pdf  

8. Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM), https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2.pdf?__blob=publicationFile&v=5

Kontakt

Frederic de Simoni

Schachenallee 29
5000 Aarau

Weitere Insights

Treten Sie mit uns in Kontakt

Jetzt kontaktieren