Angesichts von EU-Cybersecurity-Regeln
Software von Embedded-Geräten gezielt aktualisieren
Um den Cyber Resilience Act der EU langfristig einzuhalten, benötigen Embedded-Geräte regelmäßige Updates ihrer Cybersecurity-relevanten Software. Die Update-Fähigkeit muss mehrere Aspekte berücksichtigen, so dass sich eine Update-Infrastruktur auf Basis eines bewährten DevOps-Frameworks anbietet.
Die Einhaltung des Cyber Resilience Act (CRA) der Europäischen Union stellt sich als eine der größten technischen und organisatorischen Herausforderungen heraus, vor der Hersteller stehen, die ihre Embedded-Geräte in Europa vermarkten. Das Gesetz trat am 10. Dezember 2024 in Kraft, und viele seiner wesentlichen Verpflichtungen gelten für OEM drei Jahre später, ab dem 11. Dezember 2027. Entscheidendes Element der Bemühungen der OEM zur Einhaltung des CRA ist die Fähigkeit, die Software eines Geräts zu aktualisieren, um es vor neuen Cyberbedrohungen zu schützen und vor allem, um auf die offiziellen Mitteilungen zu bekannten Schwachstellen und Anfälligkeiten (Common Vulnerabilities and Exposures, CVE) zu reagieren. Während die Hardwarekomponenten eines sicherheitskonformen Systems – Geräte wie das Hardware Security Module (HSM) oder das Trusted Platform Module (TPM) – von den OEM heutzutage gut verstanden werden, ist die Wahrung der Sicherheit von Embedded-Software und der Übertragung von Softwareupdates in die Geräte im Feld für viele noch neu.
Es ist verständlich, dass das Thema Softwareupdates Unruhe hervorruft, denn es geht dabei um komplexe und schwierig durchzuführende Funktionen. Dabei ist genau das ein Gebiet, auf dem Foundries.io den Herstellern von Embedded-Geräten seit vielen Jahren Technologie und Unterstützung anbietet. Aus Sicht von Foundries.io gibt es für die OEM keinen Grund, wegen der Anforderungen des CRA zu Softwareupdates beunruhigt zu sein. Der Rollout des Gesetzes hat jedoch gezeigt, dass zwar ein großer Teil des Prozesses vereinfacht und automatisiert werden kann, die Branche aber noch die Lücke bei der Bereitstellung einiger wichtiger Werkzeuge und Dienstprogramme schließen muss, um die Einhaltung des CRA erheblich zu vereinfachen.
Jobangebote+ passend zum Thema
Wie müssen Softwareupdates nach dem CRA gestaltet werden?
Zweck des CRA ist es, »Verbraucher und Unternehmen, die Software- oder Hardwareprodukte mit einer digitalen Komponente kaufen, zu schützen«. Der CRA geht die unzureichende Cybersicherheit in vielen Produkten und das Fehlen rechtzeitiger Sicherheitsupdates für Produkte und Software an (Bild 1). Die EU-Verordnung sieht hierfür neue Verpflichtungen für Hersteller und Verkäufer von Produkten vor. Vor allem »fordert sie von den Herstellern eine Pflege während des Lebenszyklus ihrer Produkte«. Die Zeiten, als Hersteller ein elektronisches Produkt aus dem Werk verschicken und dann vergessen konnten, dass es jemals existiert hat, sind vorbei. Die Verpflichtung zur Wahrung des Schutzes gegen die Bedrohungen durch Cyberattacken gilt nun lange über den Versand des Geräts an die Endanwender hinaus. Das Gesetz kodifiziert diese Verpflichtung zur weiteren Wahrung der Sicherheit auf verschiedenen Wegen. Die wichtigsten dabei sind:
- Reaktion auf in anwendbaren CVE-Einträgen identifizierten Schwachstellen nach dem Versand;
- Führen eines obligatorischen Inventars der Softwarekomponenten (SBOM) für jede Produktionseinheit, um eine wirksame CVE-Nachverfolgung zu ermöglichen;
- Unverzügliches Beheben von Schwachstellen;
- Regelmäßige Tests und Überprüfung der Produktsicherheit;
- Einrichten einer Methode zum Offenlegen von Schwachstellen;
- Sicheres Verteilen von Korrekturen/Updates, zeitnah und kostenlos, an die Endanwender.
Damit ist der OEM verpflichtet, zu allen Softwarekomponenten jeder Produktionseinheit, die das Werk verlässt, eine Aufzeichnung oder eine SBOM zu erstellen; diese SBOM zu pflegen und zu aktualisieren, um Änderungen an der Codebasis durch Aktualisierungen und Patches zu berücksichtigen; zu wissen, wann ein Teil der Codebasis des Geräts einer bekannten Schwachstelle ausgesetzt ist; sowie diese Schwachstelle schnell zu beheben und die Korrektur kostenlos an die Anwender zu verteilen (Bild 2).
Der Wert einer Infrastruktur für lebenslange Updates
Die Codebasis heutiger Embedded-Geräte, besonders derer mit einem Linux-Betriebssystem, ist umfangreich und komplex. Sie besteht häufig aus Hunderten oder Tausenden einzelner Komponenten aus kommerziellen und Open-Source-Quellen sowie proprietärer Software. Dabei ist es kaum jemals möglich, ein Inventar dieser Komponenten von Hand zu führen. Benötigt wird ein System zum automatischen Erstellen der SBOM während der Entwicklung, in der Produktion und nach dem Versand jeder Produktvariante.
Diese Komplexität betrifft auch Sicherheitsfunktionen wie Secure Boot, Authentifizierung und kryptographischen Schutz von Daten und Softwareupdates. Geheime individuelle Schlüssel für jede Produktionseinheit müssen sicher gespeichert und verwaltet werden. Das Management der Public-Key-Infrastruktur (PKI) ist ein wesentliches Element, um vonseiten des OEM den CRA einzuhalten.
Darüber hinaus benötigen die OEM ein System zum Flottenmanagement der Geräte im Feld. Es liefert eine Grundlage für die Übertragung und das Ausspielen der korrekten Updatepakete für jede einzelne Einheit. Ein effektives Flottenmanagementsystem liefert ein sicherheitsorientiertes Inventar aller an die Kunden versandten Einheiten (mit Ausnahme derer, die bekannterweise außer Betrieb genommen wurden), jeweils mit einer eigenen sicheren ID. Das kann dabei helfen, die Flotte davor zu schützen, dass ein Cyberangreifer ein manipuliertes Gerät in die Flotte einbringt und versucht, sich Zugang zu kritischen geheimen Informationen oder Codes zu verschaffen.
Diese Funktionen verlangen ein systematisches Vorgehen beim Protokollieren, Speichern und Verwalten der Daten, Ende-zu-Ende und für jedes einzelne Gerät, von der Entwicklung über die Produktion bis zur Wartung nach dem Versand. Weil alle diese Funktionen die Einhaltung des CRA unterstützen, hat die Einführung der EU-Verordnung einen zusätzlichen Anstoß gegeben, ein formelles DevOps-Framework einzuführen. Ein Beispiel für ein solches System ist die Plattform »FoundriesFactory« von Foundries.io (Bild 3).
Eine solche Plattform sollte einen integrierten Satz von Dienstprogrammen und Werkzeugen für die folgenden Funktionen bereitstellen:
- PKI-Management;
- SBOM-Erstellung und Wartung;
- Flottenmanagement;
- CI/CD zur Unterstützung der schnellen Entwicklung und Verbreitung von Korrekturen und Patches;
- Entwicklung, Lieferung und Ausspielen von Updates mit Unterstützung durch starke Sicherheitsfunktionen.
Mit der Einführung eines solchen Frameworks zu Beginn der Entwicklung eines neuen Produkts und dessen Einsatz als Grundlage für das Lebenszyklus-Management können die OEM das Gerätemanagement und die Sicherheitsprozesse verschlanken und vereinfachen. Diese Prozesse wären sonst äußerst komplex, zeitraubend und anfällig für menschliche Fehler.
Die fehlenden Teile des Compliance-Puzzles
Alle außer den kleinsten OEM werden ein bewährtes DevOps-Framework benötigen, um ihre Einhaltung des CRA zu bewerkstelligen. Das allein reicht aber nicht aus. Es sind noch andere Werkzeuge und Systeme erforderlich, wobei es für einige der wichtigsten Elemente zur Compliance leider noch keine effektiven Open-Source-Werkzeuge gibt. Zwei Lücken fallen besonders auf:
- Verfolgen der CVE-Exponierung;
- Dokumentieren und Auditieren der Compliance-Maßnahmen.
Heutige CVE-Checker sind eher rudimentär und liefern zu viele positive Ergebnisse. Das ist deshalb so, weil sie einfach den Namen und die Beschreibung eines Softwarepakets in einer CVE-Veröffentlichung mit dem Namen und der Beschreibung der Software im SBOM eines Geräts vergleichen. Das ist aber nicht dasselbe wie das Identifizieren einer spezifischen Schwachstelle. Eine CVE-Veröffentlichung gilt normalerweise für einen bestimmten Teil oder Teile der Codebasis eines Softwareprodukts, während der Rest der Codebasis nicht gefährdet ist.
Wenn also ein Embedded-Gerät nur einen Teil des Produkts nutzt, um eine bestimmte Funktion zu implementieren, und keine anfälligen Teile der Codebasis enthält, besteht keine Notwendigkeit, eine Korrektur zu erstellen und zu verbreiten. Ein rudimentärer CVE-Checker kennzeichnet das Gerät trotzdem als anfällig, wenn es irgendeinen Teil des in einer CVE-Mitteilung genannten Softwarepakets nutzt.
Das unterstreicht die Notwendigkeit verbesserter Werkzeuge, die den Sourcecode eines Geräts scannen und Übereinstimmungen mit anfälligem Code, der in einer CVE-Mitteilung erwähnt wurde, finden können. Es gibt Gründe zum Optimismus, dass fortschrittliche KI-Modelle künftig die Grundlage für ein solches Werkzeug bilden könnten.
Die zweite Lücke im Compliance-Werkzeugsatz ist ein System, das Berichte und Audits unterstützt. Der CRA sieht bei Verstößen hohe Geldstrafen je nach Größe des Produktherstellers vor. Das sollte die OEM ausreichend motivieren, nachzuweisen, wie sie die Bestimmungen des Gesetzes für jede einzelne Produktionseinheit im Feld eingehalten haben.
So wie das SBOM-Dienstprogramm in Software wie der Plattform FoundriesFactory das Erzeugen einer Liste von Softwarekomponenten für jedes einzelne Gerät automatisiert, muss ein effektives Compliance-Berichtswerkzeug für jedes einzelne Gerät ein Protokoll der gemeldeten Schwachstellen und der vorgenommenen Korrekturen führen. Idealerweise wird die Open-Source-Community Werkzeuge liefern, die beide Lücken schließen und sich weit genug verbreiten, um zum Standard zu werden. Dort wo Open-Source-Standardlösungen existieren, gewinnt die Branche dadurch, dass nicht zahlreiche Unternehmen das Rad neu erfinden müssen und gemeinsam lernen und Erfahrungen austauschen können.
Die positive Dynamik einer Open-Source-Standardisierung ist der Grund dafür, dass die Plattform FoundriesFactory beispielsweise The Update Framework (TUF) als ihr Werkzeug zur sicheren Auslieferung und zum Ausspielen von Softwareupdates gewählt hat. Viele andere Elemente der Plattform FoundriesFactory haben aus demselben Grund eine Open-Source-Basis.
Softwareupdates – ein Prozess und kein Paket
Unter dem Druck der Einhaltung des CRA beginnen die OEM nun, die Schwierigkeiten beim Update der Software anzugehen. Sie begreifen, dass Softwareupdates ein wesentliches Element ihrer Anstrengungen zur Compliance sind, dass es aber bei Softwareupdates nicht nur um das reine Update-Paket geht. Vielmehr geht es um ein ganzes System aus Überwachung der Geräte, Sicherheit, Flottenmanagement und Software-Auslieferfunktionen als Grundlage für die Fähigkeit, schnell auf neue Schwachstellen oder Exponierungen zu reagieren.
Viele OEM nutzen die Vorteile einer Update-Infrastruktur auf einem bewährten DevOps-Framework als solide und automatisierte Grundlage zum sicheren Identifizieren und Warten von Produktionseinheiten im Feld, um das richtige Update-Paket für das richtige Gerät zum richtigen Zeitpunkt auszuliefern.
Foundries.io auf der embedded world 2026: Halle 4A, Stand 133
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
