Case Study: Product Security und Cyber Resilience Act

Ein global tätiger Elektronikhersteller muss seinen gesamten Entwicklungsprozess auf den Cyber Resilience Act ausrichten. Keine kritischen Produkte, aber komplexe Strukturen, historisch gewachsene Prozesse und Kompetenzlücken in mehreren Abteilungen. Was folgt, ist kein Compliance-Projekt. Es ist ein Neustart der Produktsicherheit.

Ausgangssituation: Viel Unsicherheit, wenig Zeit

Durch das Inkrafttreten des Cyber Resilience Acts (CRA) muss ein global tätiger Hersteller smarter Haushaltsgeräte mit Sitz in Deutschland die Cybersicherheit seiner Produkte mit digitalen Elementen/Komponenten auch für die gesamte Produktlebensdauer sicherstellen. Es herrschte zunächst große Unsicherheit, welche Bedeutung genau der CRA für ein digitales Produkt hat und wie sich das mit bestehenden Produkt- & Softwareentwicklungsprozessen vereinbaren lässt. Unklar war ebenfalls, welche Produkte (nicht) vom CRA betroffen und welche Anforderungen des CRA bereits (teilweise) umgesetzt sind.

Der Hersteller beauftragte unser fachübergreifendes Expertenteam, eine holistische Strategie zur Erreichung der CRA-Compliance zu entwickeln, um fortan ein hohes Niveau an Cybersicherheit entlang des gesamten Lebenszyklus der digitalen Produkte zu erreichen.

Herausforderungen

Historisch gewachsene Prozesse

Die bisherigen Prozesse des Herstellers zur Produkt- und Softwareentwicklung haben sich teilweise über einen langen Zeitraum hinweg sowie uneinheitlich entwickelt. Außerdem wurden Aspekte der Cybersecurity bisher nicht sonderlich stark oder nur vereinzelt bedacht.

Komplexe Unternehmensstruktur

Die Komplexität der Unternehmensstruktur unseres global tätigen Kunden stellt eine weitere Herausforderung dar. So besteht das Unternehmen aus zahlreichen autarken Abteilungen mit teils geringen Kommunikationsschnittstellen zueinander. Cybersecurity wurde bisher nur in wenigen Abteilungen, und dort jeweils sehr unterschiedlich, berücksichtigt.

Ressourcen und Kompetenzen

Die für die Umsetzung des Cyber Resilience Act (CRA) erforderlichen personellen und finanziellen Ressourcen sowie das notwendige Fachwissen waren sehr unterschiedlich in den Abteilungen vorhanden und fehlten an einigen Stellen ganz. Infolgedessen herrschte große Unsicherheit über die erforderlichen Maßnahmen, um den Anforderungen des CRA zu entsprechen.

Integration mit anderen Regularien und unternehmensinternen Vorgaben

Da auch andere nationale, europäische und internationale Regularien auf das Unternehmen einwirken, sind Überschneidungen und Dopplungen zwischen diesen nicht bekannt und einbezogen. Außerdem decken unternehmensinterne Vorgaben diese Regularien teilweise bereits ab oder behindern deren Erfüllung. Eine Harmonisierung dieser Regularien und Vorgaben fand noch nicht statt.

Um diesen Herausforderungen zu begegnen und Lösungen zu entwickeln, wurden unser CRA Cybersecurity Expertenteam beauftragt.

Vorgehen: Strukturiert, Schritt für Schritt

Betroffene Produkte und Regularien identifizieren

Der erste Schritt für eine erfolgreiche Einführung des CRA bestand darin, die betroffenen Produkte zu identifizieren. Dafür musste das gesamte Portfolio sowie die komplexe Struktur des Unternehmens analysiert und die Produkte die unter den CRA fallen identifiziert werden. Bei der Überprüfung erfolgte außerdem eine Analyse, ob der Kunde oder das Produkt gegebenenfalls auch unter andere relevante Regularien (NIS-2 oder RED – Radio Equipment Directive) fällt.

Diese Einordnung diente als Basis für die weiteren Schritte.

Verantwortlichkeiten und Budget klären

Nach der Identifikation der betroffenene Produkte wurde gemeinsam eine klare Zuweisung von Verantwortlichkeiten erarbeitet. Dabei wurden Rollen für die Umsetzung des CRA innerhalb des Unternehmens definiert und auf der Managementebene Sichtbarkeit für das Thema erzielt. Gleichzeitig wurde das benötigte Budget für die Umsetzung der Anforderungen des CRA abgeschätzt und so berechnet, dass genug Ressourcen und Kompetenzen für die Umsetzung zur Verfügung stehen. Bei der Budgetplanung wurden sowohl die einmaligen als auch die laufenden Kosten berücksichtigt. Ein klar definiertes Budget ermöglichte eine realistische und effiziente Umsetzung der Sicherheitsmaßnahmen.

Zum Abschluss der Planung wurde der weitere zeitliche Ablauf definiert, um die wichtigen Fristen der EU einzuhalten und Verzögerungen bei den Releases neuer Produkte zu vermeiden. Da sich das Unternehmen rechtzeitig mit dem CRA auseinandersetzte, entstanden keine größeren Verzögerungen.

Soll/Ist Analyse der Anforderungen des CRA

Nun wurden bei einer Soll-Ist-Analyse die bestehenden Sicherheitsmaßnahmen des Unternehmens und der Produkte mit den Anforderungen des CRA verglichen und Lücken identifiziert. Durch eine Dokumentenprüfung, fachliche Interviews mit Ansprechpartnern sowie Sichtung von Auditberichten kamen wir zu folgenden Ergebnissen:

Die Produkte des Unternehmens verfügten schon über die grundlegenden Sicherheitsmechanismen, jedoch waren die Strukturen und Prozesse im Unternehmen nicht auf die neuen Anforderungen des CRA ausgerichtet. Es existierten zwar Maßnahmen wie Software-Updates und Zugriffskontrollen, doch dem Produktlebenszyklus fehlte ein systematisches Sicherheitskonzept nach dem Prinzip Security by Design. Die Sicherheitsaspekte wurden nicht bereits in der Entwurfsphase beachtet, sondern erst kurz vor oder sogar erst nach dem Release der Produkte. Außerdem fehlte manchen Produkten das Prinzip Security by Default, da sie mit einem Standardpasswort ausgeliefert wurden. Die Software-Updates wurden aufgrund von mangelnden technischen Möglichkeiten nicht über den kompletten Lebenszyklus der Geräte verfügbar gemacht, sondern wurden oft bereits nach 3 Jahren eingestellt. Zudem wurde festgestellt, dass dem Unternehmen die Prozesse und die Infrastruktur für das geforderte Incident Response Management und Security Monitoring fehlten. Die Mitarbeitenden waren nur teilweise im Bereich Cybersicherheit geschult. Die Dokumentationen (allgemeine Produktbeschreibung, Risikobewertungen und angewandte Normen) des Unternehmens waren teilweise vorhanden, es fehlte jedoch die geforderte SBOM (Software Bill of Materials).

Diese Ergebnisse wurden dann in einem Bericht zusammengefasst, um dem Kunden einen transparenten Überblick über seinen aktuellen Stand zu geben. Das Ergebnis zeigte auf, welche Maßnahmen bereits konform waren und welche Maßnahmen im weiteren Verlauf noch eingeführt werden müssten. Auf der Basis des Berichts wurden konkrete Handlungsempfehlungen formuliert.

Risiken innerhalb der betroffenen Produkte analysieren

Nach der Soll-Ist-Analyse wurde eine detaillierte Risikoanalyse durchgeführt. Es wurden potenzielle Sicherheitsrisiken für die Produkte evaluiert. Dabei wurden klassische Schwachstellenanalysen mit Threat-Informed Defense (TID) kombiniert, um eine fundierte Priorisierung der erforderlichen Sicherheitsmaßnahmen vorzunehmen.

Außerdem wurden bei einigen Produkten Penetrationstests durchgeführt mit dem Ziel, die kritischen Schwachstellen der Produkte zu identifizieren. Wir vervollständigten auf diese Weise unser Bild vom Unternehmen. Auf Grundlage der gewonnenen Erkenntnissen nahmen wir eine Priorisierung der erforderlichen Sicherheitsmaßnahmen vor und sie flossen in unsere Handlungsempfehlungen ein.

Umsetzung identifizierter Maßnahmen (prozessual & technisch)

Die erste durchgeführte Maßnahme war die Schulung des relevanten Personals. Neben dem vermittelten Wissen hatte dies den Nebeneffekt, dass wir die Mitarbeitenden besser in die Umsetzung der Maßnahmen einbeziehen konnten.

Eine besondere Herausforderung stellten die historisch gewachsenen Produkt- und Softwareentwicklungsprozesse dar, die über Jahre hinweg ohne einheitliche Sicherheitsstrategie entstanden waren. Diese haben wir angepasst, indem wir strukturierte Security by Design Prinzipien eingeführt und somit einen sicheren Produktentwicklungsprozess und Lebenszyklus eingeführt haben. Die Produktsicherheit wird im Unternehmen nun schon ab der Designphase in allen Phasen des Produktslebenszyklus berücksichtigt. Dabei wurde auch miteinbezogen, dass die Sicherheitsupdates für Produkte nun der Lebensdauer der Produkte entsprechen müssen. Die Technik wird so gewählt, dass sie auch nach 5 Jahren noch Sicherheitsupdates erhalten kann.

Darüber hinaus führte das Unternehmen mit unserer Unterstützung eine neue Continuous Integration und Continuous Delivery (CI/CD) Pipeline mit automatisierten Sicherheitsprüfungen ein. Dazu wurde eine Application Security Platform eingeführt, die den Code der Entwickler automatisch überprüft und schon während der Programmierung Schwachstellen im Code und in Bibliotheken meldet. Außerdem kann dieses Programm die vom CRA geforderte SBOM für die gesamte entwickelte Software des Unternehmens erstellen.

Zeitgleich wurde ein Incident Response Team im Unternehmen eingerichtet und die Infrastruktur für Incident Response Management und Security Monitoring geschaffen. Das Unternehmen ist jetzt in der Lage, innerhalb von maximal 24 Stunden Schwachstellen und Sicherheitsvorfälle zu melden. Es kann schnell auf interne, sowie externe Meldungen reagiert werden und den Nutzern Sicherheitsupdates für ihre Produkte zur Verfügung gestellt werden.

Aufgrund der neuen Prozesse und des neuen Sicherheitsdenkens erfüllen die Produkte jetzt die Prinzipien Security by Design & Default.

Durchführung der Konformitätsbewertung

Das Unternehmen hatte keine kritischen Produkte, somit konnte die Konformitätsbewertung vom Unternehmen selbst durchgeführt werden, es brauchte keine Evaluation durch einen Dritten. Bei der Selbstevaluation unterstützten wir das Unternehmen und konnten die CE Kennzeichnung für die neuen Produkte erlangen, sodass diese ohne Verzögerung nach Dezember 2027 auf den EU-Markt kommen können.

Mehrwert

Dank des tiefgehenden Fachwissens unseres CRA Cybersecurity Expertenteams sowie unserer langjährigen Erfahrung im Bereich der Product Security und der sicheren Softwareentwicklung waren wir in der Lage, die spezifischen Herausforderungen unseres Kunden sowie der einzelnen Organisationseinheiten genau zu erfassen und passgenaue Lösungen zu erarbeiten.

Neben unserer transparenten und ganzheitlichen Herangehensweise trugen auch eine enge kundenorientierte Kommunikation und Flexibilität maßgeblich zum Erfolg bei. Durch eine gründliche Bewertung des bestehenden Reifegrads in den Abteilungen sowie eine umfassende Aufklärung über gesetzliche Vorgaben verschafften wir dem Kunden einen klaren Überblick und förderten sein Sicherheitsbewusstsein.

Bei carmasec legen wir großen Wert auf eine enge Zusammenarbeit mit unseren Kunden. Durch ausführliche zielgerichtete Interviews und die Einbindung aller relevanten Stakeholder konnten wir in diesem Projekt ein tiefgehendes Verständnis für die spezifischen Herausforderungen erzeugen. So war es uns möglich, maßgeschneiderte Empfehlungen zu erarbeiten, um die Erfüllung des CRA und weiterer kundenspezifischen Anforderungen sicherzustellen. Dabei setzten wir auf einen integrativen Ansatz mit unseren Open Source Security Experten, der sowohl in der Strategieentwicklung als auch bei der Definition konkreter Maßnahmen berücksichtigt wurde. Neben der Analyse und Bewertung unterstützten wir auch die praktische Umsetzung, indem wir den Kunden befähigten, nachhaltige und praxisnahe Product Security-Strukturen aufzubauen. Gemeinsam definierten wir Rollen und Verantwortlichkeiten und entwickelten eine Roadmap für die Implementierung von Sicherheitsmaßnahmen, wie die Integration von Security-Schritten in den Entwicklungsprozess, die Definition von Secure Coding Standards und die Einführung eines Prozesses für Vulnerability- und Incident-Management. Zusätzlich standen wir als Experten bei der Erstellung erforderlicher Dokumentationen und Prozesse beratend zur Seite.

Binnen eines Jahres haben wir die Rahmenbedingungen für CRA festgelegt und sowohl einen sicheren Entwicklungsprozess als auch ein umfassendes Vulnerability Management mitsamt der CRA-Meldepflichten implementiert.

Dies ersparte dem Kunden die Herausforderung, schwer verfügbare Expert:innen zu rekrutieren, und ermöglichte ihm stattdessen, internes Wissen gezielt aufzubauen. Dadurch konnte er Product Security effektiv implementieren und die Weichen für sichere Produkte von morgen stellen.

Fazit

Compliance mit dem Cyber Resilience Act ist kein einmaliges Projekt. Sie ist eine Strukturfrage. Unternehmen, die Sicherheit spät im Entwicklungsprozess einbauen, zahlen zweimal: einmal für die Nachrüstung, einmal für den Zeitverlust.

Dieses Projekt zeigt, was möglich ist, wenn früh angefangen wird. Security by Design als Prinzip. Eine SBOM als Grundlage. Incident Response als Infrastruktur. Und ein Team, das die Anforderungen nicht von außen aufgedrückt bekommt, sondern versteht, warum sie sinnvoll sind.

Das Ergebnis ist kein abgehaktes Compliance-Dokument. Es ist ein Produktentwicklungsprozess, der ab sofort sicher startet.

FAQ zur CRA-Umsetzung in der Praxis

Dein Team steht vor ähnlichen Fragen?

Unser Team unterstützt dich von der ersten Bestandsaufnahme bis zur CE-Kennzeichnung. Kompetent, direkt und ohne Umwege.

Erstgespräch vereinbaren