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

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]).

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.

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.

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