CRA umsetzen: Was bedeutet Anforderung 2 aus Teil I für die Praxis?

Unsere bisherigen Beiträge zum CRA bieten eine solide Grundlage, um die Anforderungen des CRA zu verstehen und erste Schritte zur Umsetzung zu planen. In diesem Artikel gehen wir erneut einen Schritt tiefer und schauen auf die nächsten Anforderungen.

Nachdem uns im vorangegangenen Artikel die Anforderung 1 mit voller Wucht deutlich machte, dass wir Cyber Security in allen Phasen und Prozessen des Produktlebenszyklus berücksichtigen müssen, schauen wir nun auf konkrete Cyber-Security-Anforderungen an unser Produkt.

Anforderung 2 aus Teil I beginnt mit den Worten:

Auf der Grundlage der Bewertung der Cybersicherheitsrisiken gemäß Artikel 13 Absatz 2 müssen Produkte mit digitalen Elementen, soweit zutreffend,

Daran schließen sich 13 einzelne Anforderungen, nummeriert von a bis m, an.

• a) Keine bekannten ausnutzbaren Schwachstellen
• b) Sichere Standardkonfiguration und Rücksetzbarkeit
• c) Sicherheitsaktualisierungen
• d) Schutz vor unbefugtem Zugriff
• e) Schutz der Vertraulichkeit
• f) Schutz der Integrität
• g) Datenminimierung
• h) Sicherstellung der Verfügbarkeit wesentlicher Funktionen
• i) Minimierung negativer Auswirkungen auf andere Geräte oder Netze
• j) Reduzierung der Angriffsfläche
• k) Schadensbegrenzung bei Sicherheitsvorfällen
• l) Sicherheitsrelevantes Monitoring und Opt-out
• m) Sichere Löschung und Datenübertragung

Bevor wir uns den Unterpunkten widmen, werfen wir einen Blick auf die Einleitung und den referenzierten Artikel 13 Absatz 2.

Artikel 13 (2) Für die Zwecke der Erfüllung von Absatz 1 führen die Hersteller eine Bewertung der Cybersicherheitsrisiken durch, die ein Produkt mit digitalen Elementen birgt, und berücksichtigen das Ergebnis dieser Bewertung in der Planungs-, Konzeptions-, Entwicklungs-, Herstellungs-, Liefer- und Wartungsphase des Produkts mit digitalen Elementen, um die Cybersicherheitsrisiken zu minimieren, Sicherheitsvorfälle zu verhindern und die Auswirkungen solcher Sicherheitsvorfälle, auch in Bezug auf die Gesundheit und Sicherheit der Nutzer, so gering wie möglich zu halten.

Hier wird nochmals klar, dass die Anforderungen sich auf den gesamten Lebenszyklus beziehen und dass der Hersteller eine Bewertung der Risiken über den gesamten Lebenszyklus leben und pflegen muss. Daher ist und bleibt eine der wichtigsten und ersten Aufgaben zur Adressierung der CRA-Anforderung die Durchführung einer Risikobewertung. Ein Hersteller sollte die Risikobewertung systematisch angehen. Methoden wie STRIDE und PASTA können hier helfen. Für Teams, die sich zum ersten Mal mit Threat-Modellierung beschäftigen, lohnt sich die Einbindung externer Spezialisten. Diese bringen Erfahrung und einen unabhängigen Blick mit, was für Audits und Compliance-Nachweise sehr hilfreich sein kann. Aber Achtung: Auch der externe Spezialist entbindet nicht von der Haftung.

Um den Kreis zu schließen, muss als Nächstes auf die Unterpunkte a bis m geschaut werden. Diese Punkte besagen, was durch die Risikoanalyse sichergestellt bzw. unterbunden werden muss.

a) Keine bekannten ausnutzbaren Schwachstellen

Die Behandlung von Schwachstellen wird in Teil 2 des Anhang 1 genauer detailliert, welchen wir uns in einem weiteren Artikel gesondert anschauen. Dies vorausgeschickt, ist die Kernaussage der Anforderung 2.a, dass zum Zeitpunkt der Bereitstellung auf dem Markt, also in jedem Fall mit dem Übergang des Produkts zum Kunden, keine bekannten Schwachstellen enthalten sind, die ausnutzbar sind. Es entsteht eine Nachweispflicht für den Hersteller. Gleichzeitig öffnet die Anforderung einen interessanten Diskussionsraum: Darf ich mein Produkt am Markt bereitstellen, obwohl es bekannte Sicherheitslücken enthält, diese aber bei mir nicht ausgenutzt werden können? Ein klassisches Beispiel ist die Angreifbarkeit des Betriebssystems via USB-Schnittstellen. Wenn Ihr System solch eine Lücke aufweist, Ihre Hardware aber keine USB-Schnittstellen bereitstellt, wären Sie tendenziell auf der sicheren Seite.

💡 Unsere Empfehlung ist dennoch: Vermeiden Sie solche Spitzfindigkeiten und gewährleisten Sie einen sicheren und möglichst automatisierten Umgang mit Schwachstellen.

b) Sichere Standardkonfiguration und Rücksetzbarkeit

Anforderung 2.b erzwingt “Security by Default”. Die Absicherung des Systems ist kein Opt-In. Es ist bereits ab Auslieferungszustand sicher. Während des Betriebs kann durch Konfiguration das Sicherheitsniveau reduziert werden, z.B. durch Öffnen von Schnittstellen um bestimmte Funktionen wie z.B. Remote Access oder Datenaustausch mit Drittsystemen nutzen zu können. In diesem Fall muss ein Rücksetzen des Systems möglich sein, sodass wieder ein sicherer Betrieb gewährleistet ist. Hierbei ist nicht definiert oder vorgeschrieben, welche Daten das Rücksetzen überleben müssen. Hier entscheiden wohl Markt und Komfortbedürfnis, ob nach dem Rücksetzen eine erneute Parametrierung notwendig sein wird oder ob der Hersteller Aufwände investiert, um Nutzerdaten beim Rücksetzen zu erhalten. Darüber hinaus lässt die Anforderung 2.b es sogar zu, dass gewerbliche Nutzer eines maßgeschneiderten Produkts die Option haben, vertraglich eine Nicht-Einhaltung dieser Anforderung zu vereinbaren. Der Umgang mit der Definition von “maßgeschneidert” ist dabei noch offen. Führen Optionen beim Produkt schon zur Maßschneiderei?

💡 Unsere Empfehlung: Hoffen Sie nicht auf eine Auslegung zu Ihren Gunsten. Befähigen Sie Ihr System, in jedem Fall “secure by default” ausgeliefert zu werden.

c) Sicherheitsaktualisierungen

Mit Anforderung 2.c wird die Fähigkeit erzwungen, auf auftretende Schwachstellen reagieren und Sicherheitsupdates ausliefern und installieren zu können. Die Updates müssen ggf. automatisch, aber in jedem Fall innerhalb eines angemessenen Zeitrahmens installiert werden. Der Nutzer muss darüber informiert werden und muss die Möglichkeit haben, Aktualisierungen zu verschieben. Hier steckt jede Menge Arbeit für das Entwicklungsteam drin. Lösungen wie mender.io oder Hawkbit können helfen. Neben der Technik muss aber auch der Prozess zum Ausrollen von Updates beherrscht werden. Canary- und Ring-Deployments gehören daher ebenso zu den Aufgabengebieten wie Feature Flags zum (De-)Aktivieren von Funktionen oder ein klarer und benutzerfreundlicher Opt-Out-Mechanismus. Und auch bei Offline-Updates via USB ist meist Handlungsbedarf angesagt. Authentizität und Integrität von Installationspaketen müssen auch hier sichergestellt sein.

💡 Unsere Empfehlung: Schauen Sie sehr genau auf die Prozesse, mit denen Sie heute Aktualisierungen zu Ihren Kunden bringen. Und prüfen Sie Ihren Technologie-Stack, ob jeder technisch aktualisierbare Teil auch wirklich sicher und einfach aktualisierbar ist.

d) Schutz vor unbefugtem Zugriff

Anforderung 2.d will sicherstellen, dass ein Schutz vor unbefugtem Zugriff durch geeignete Kontrollmechanismen gegeben ist. Die Anforderung geht weiter und formuliert, dass dies zumindest Authentifizierungs-, Identitäts- oder Zugangsverwaltungssysteme umfasst und ein möglicherweise unbefugter Zugriff gemeldet wird. Auch in dieser Anforderung steckt durchaus Aufwand für das Entwicklungsteam. Gibt es heute eine Zugriffskontrolle? Läuft das System stets mit erhöhten Rechten? Wird das System mit Default-Passwörtern ausgeliefert? Im besten Fall müssen Inbetriebnahmeprozeduren angepasst werden. Im schlechtesten steht ein großflächiger Umbau bis hin zur Neuentwicklung vor der Tür.

💡 Unsere Empfehlung: Hinterfragen Sie bestehende Zugriffsrechte kritisch, ersetzen Sie Standardpasswörter konsequent und planen Sie eine robuste Zugriffsverwaltung frühzeitig in Ihre Systemarchitektur ein.

e) Schutz der Vertraulichkeit

Daten müssen verschlüsselt werden, sowohl auf dem Dateisystem, bei der Übertragung als auch während der Verarbeitung. Dies bezieht sich nicht nur auf personenbezogene Daten, sondern auch auf sonstige Daten. State-of-the-Art-Verschlüsselung wie AES-256 und sichere Kommunikation, z. B. mit TLS 1.3, werden zur Pflicht. Hierzu gehört auch eine saubere Schlüsselverwaltung und die Fähigkeit, Schlüssel austauschen oder widerrufen zu können.

💡 Unsere Empfehlung: Prüfen Sie, wie Sie heute Daten speichern und übertragen. Greifen Sie auf etablierte Bibliotheken zurück (ACHTUNG: Sie bleiben in der Pflicht und Haftung, gerade bei Open Source). Trennen Sie sich von Eigenimplementierungen. Bedenken Sie, dass Kryptografie als Dual-Use-Gut gilt und häufig zumindest eine Prüfung der Exportkontrolle beinhalten sollte. Und prüfen Sie Ihre Logs. Nicht, dass da heute schon GDPR-Verstöße schlummern.

f) Schutz der Integrität

Neben Vertraulichkeit aus 2.e verlangt der CRA in Anforderung 2.f, dass Daten, Befehle, Programme und Konfigurationen nicht unbemerkt manipuliert werden können. Integritätsprüfung mittels Hashes und Signaturen wird zur Pflicht. Das beginnt bereits beim Booten der Systeme, geht weiter über oft vernachlässigte Konfigurationsdateien und endet nicht zuletzt beim Datenaustausch von Datensätzen oder Prozessdaten oder bei Plugins, die Ihre modulare Systemarchitektur z. B. nach Kauf von Optionen nachlädt. Auch in dieser Anforderung steckt hohes Potenzial für die Überlastung Ihrer Entwicklungsabteilung. Auch hier kann die Konsequenz sein, dass das bestehende System diesen Anforderungen nicht gerecht wird.

💡 Unsere Empfehlung: Prüfen Sie Ihr System auf alle Daten, vom Start bis zum Shutdown. Übernehmen Sie alle Funde in Ihre Risikoanalyse und führen Sie die notwendige Bewertung durch. Mechanismen wie Secure Boot (TPM) oder Werkzeuge wie AIDE können hier hilfreich sein.

g) Datenminimierung

Anforderung 2.g verpflichtet dazu, die Verarbeitung personenbezogener oder sonstiger Daten auf ein notwendiges und sachlich gerechtfertigtes Maß zu beschränken. Was nicht für die Funktion oder den Zweck des Produkts erforderlich ist, darf nicht erhoben oder gespeichert werden. Dieses Prinzip gilt unabhängig davon, ob es sich um Kundendaten, Betriebsdaten oder interne Diagnosedaten handelt. „Alles sammeln, man weiß ja nie“ gilt dann als unzulässig.

💡 Unsere Empfehlung: Dokumentieren Sie für jede erhobene Datenart den Verarbeitungszweck und prüfen Sie, ob dieser nachvollziehbar und technisch erforderlich ist. Löschen Sie alle nicht länger notwendigen Daten. Kontinuierlich. Auch nach der Auslieferung.

h) Sicherstellung der Verfügbarkeit wesentlicher Funktionen

Anforderung 2.h stellt klar: Auch bei einem Sicherheitsvorfall muss das Produkt in der Lage sein, seine wesentlichen und grundlegenden Funktionen weiterhin bereitzustellen. Außerdem müssen Maßnahmen vorhanden sein, um Überlastungsangriffe (Denial-of-Service) abzuwehren oder ihre Auswirkungen zu begrenzen. Praktisch bedeutet das für Hersteller, dass kritische Grundfunktionen nicht komplett ausfallen dürfen, auch wenn Teilbereiche eines Systems kompromittiert oder überlastet sind.

💡 Unsere Empfehlung: Analysieren Sie, welche Funktionen für einen sicheren Minimalbetrieb unverzichtbar sind und bauen Sie entsprechende Redundanz- und Abwehrmechanismen ein. Und vergessen Sie nicht, dies auch regelmäßig zu testen.

i) Minimierung negativer Auswirkungen auf andere Geräte oder Netze

Anforderung 2.i legt fest, dass Produkte mit digitalen Elementen so gestaltet sein müssen, dass sie keine unverhältnismäßigen negativen Auswirkungen auf die Verfügbarkeit anderer Geräte oder Netzwerke haben. Im Klartext: Ein einzelnes kompromittiertes oder fehlerhaft konfiguriertes Gerät darf nicht ganze Netze lahmlegen oder andere Dienste ungewollt blockieren. Gerade bei IoT-Produkten ist das Risiko bekannt. Beispiele sind vernetzte Kameras oder Drucker, die durch Botnets missbraucht werden und massenhafte Anfragen ins Internet feuern.

💡 Unsere Empfehlung: Sorgen Sie dafür, dass Ihr Produkt sich im Fehlerfall oder bei Kompromittierung möglichst kontrolliert verhält und keine Ressourcenflut auslöst. Nutzen Sie das Konzept der Circuit Breaker, um den Blast Radius von Fehlern und Kompromittierungen zu verringern. Integrieren Sie Rate Limiting und Verbindungsbegrenzung auch für ausgehende Verbindungen.

j) Reduzierung der Angriffsfläche

Anforderung 2.j verpflichtet Hersteller dazu, Produkte so zu konzipieren, zu entwickeln und herzustellen, dass sie möglichst geringe Angriffsflächen bieten — insbesondere auch bei externen Schnittstellen. Das bedeutet: Jede Funktion, jede Schnittstelle und jeder Dienst muss auf das technisch erforderliche Maß reduziert werden. Nicht benötigte Ports, Debug- oder Wartungsschnittstellen dürfen nicht offen zugänglich sein. Jede offene Schnittstelle stellt potenziell einen Angriffsweg dar.

💡 Unsere Empfehlung: Überprüfen und dokumentieren Sie alle offenen Schnittstellen systematisch und schalten Sie alles ab, was nicht zwingend gebraucht wird bzw. schalten Sie Schnittstellen nur zu dem Zeitpunkt an, zu dem sie aktiv genutzt werden sollen. Was unvermeidbar ist, muss bestmöglich abgesichert sein (siehe 2.d, 2.e und 2.f).

k) Schadensbegrenzung bei Sicherheitsvorfällen

Anforderung 2.k verlangt, dass Produkte so gestaltet sein müssen, dass die Auswirkungen eines Sicherheitsvorfalls begrenzt werden. Es geht also darum, dass ein Angreifer nicht ungehindert das komplette System kompromittieren oder großen Schaden anrichten kann, selbst wenn er eine Schwachstelle findet. Typische Maßnahmen sind: Sandboxing, Trennung von Systembereichen, geringste Rechte für Prozesse und klare Begrenzung, welche Ressourcen eine kompromittierte Komponente erreichen kann. Auch der Einsatz von Memory-Safe Languages wie Rust kann helfen, bestimmte Fehlerquellen (zum Beispiel Speicherfehler) schon im Vorfeld zu verhindern und so die Möglichkeiten für Angreifer stark einzuschränken.

💡 Unsere Empfehlung: Überprüfen Sie, ob Ihre Architektur Defense-in-Depth wirklich umsetzt oder ob ein erfolgreicher Angriff gleich den ganzen Domino-Effekt auslöst. Nutzen Sie Prozess- und Speicherisolation, Containerisierung, Virtualisierung und prüfen Sie für neue Komponenten den Einsatz einer Memory-Safe Language anstelle von C oder C++. Wenn C und C++ bleiben müssen, setzen Sie auf Safe-Coding-Standards von MISRA C, SEI CERT oder Microsoft (.NET, C++).

l) Sicherheitsrelevantes Monitoring und Opt-out

Anforderung 2.l schreibt vor, dass sicherheitsbezogene Informationen durch Aufzeichnung oder Überwachung interner Vorgänge bereitgestellt werden müssen. Das umfasst zum Beispiel den Zugriff auf Daten, Dienste oder Funktionen sowie Änderungen daran. Ziel ist es, Sicherheitsereignisse nachvollziehbar zu machen und gegebenenfalls schnell reagieren zu können. Gleichzeitig müssen Nutzer die Möglichkeit haben, diese Überwachung abzulehnen (Opt-out), soweit es nicht die Sicherheit des gesamten Systems gefährdet. Praktisch heißt das: Logging und Monitoring ja, aber transparent und mit Kontrollmöglichkeit für den Nutzer.

💡 Unsere Empfehlung: Entwickeln Sie ein klares Konzept, welche Vorgänge überwacht werden, wo die Daten gespeichert werden und wie Sie Nutzer über ihre Optionen informieren. Sorgen Sie für klare Optionen beim Opt-out und dokumentieren Sie, welche Funktionen bei deaktiviertem Monitoring eingeschränkt sein können. Berücksichtigen Sie in diesem Kontext zudem 2.e, 2.f und 2.g.

m) Sichere Löschung und Datenübertragung

Anforderung 2.m verpflichtet Hersteller dazu, den Nutzern eine einfache und dauerhafte Löschung aller Daten und Einstellungen zu ermöglichen. Zusätzlich muss sichergestellt sein, dass eine Übertragung dieser Daten auf andere Produkte oder Systeme sicher erfolgt, um Datenverlust oder unbefugten Zugriff zu verhindern. Das bedeutet für Hersteller: Ein Werksreset darf nicht nur oberflächlich sein, sondern muss sicherstellen, dass keine sensiblen Informationen auf dem Gerät verbleiben. Bei der Datenübertragung müssen Authentizität, Integrität und Vertraulichkeit gewährleistet sein.

💡 Unsere Empfehlung: Dokumentieren Sie klar, welche Daten beim Zurücksetzen entfernt werden und testen Sie regelmäßig, ob der Löschvorgang vollständig funktioniert. Nutzen Sie Verfahren wie Secure Erase.

Fazit

Wer jetzt denkt, das klingt nach Aufwand, der hat recht. Wer viele technische Schulden im Produkt mit sich trägt, steht ggf. vor der Entscheidung einer Neuentwicklung. Aber lieber Aufwand vor dem Launch als Albtraum bei Rückruf und Millionenstrafe. Hersteller sollten spätestens jetzt mit der strukturierten Risikoanalyse und -bewertung starten. Hierbei können GRC (Governance, Risk, Compliance)-Plattformen wie AuditBoard, hyperproof oder Microsoft Purview Compliance Manager hilfreich sein und sowohl bei Risikobewertung als auch Assessment und Audit unterstützen.

👉 Wenn Sie jetzt wissen möchten, wo Ihr Unternehmen steht und welche Produkte besonders betroffen sind: Buchen Sie unseren CRA-Workshop. Praxisnah, kompakt und mit klarem Fahrplan für die nächsten Schritte. Starten Sie vorbereitet in die neue regulatorische Realität!