Cyber Resilience Act –
Technische Umsetzung von Sicherheitsanforderungen
Mit dem Cyber Resilience Act, kurz CRA, definiert die Europäische Union verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Die Verordnung betrifft damit nicht nur klassische IT-Produkte, sondern auch eingebettete Systeme, Firmware, Softwarekomponenten und industrielle Kommunikationslösungen. Ziel des CRA ist es, ein einheitliches Mindestmaß an Cybersicherheit für vernetzte Produkte im europäischen Markt zu schaffen und Sicherheitsanforderungen über den gesamten Produktlebenszyklus hinweg zu verankern.
Für MicroControl ist der CRA insbesondere im Umfeld industrieller Kommunikationssysteme relevant. Unsere Produkte und Softwarekomponenten, darunter CANopen-, CANopen-FD-, J1939- sowie Bootloader-Lösungen, werden in eingebetteten Systemen und industriellen Anwendungen eingesetzt. Genau in diesem Umfeld entstehen neue Anforderungen an Risikobewertung, Schwachstellenmanagement, sichere Updates, technische Dokumentation und nachvollziehbare Kommunikation von Sicherheitsinformationen.
Eine besondere Rolle spielt dabei der Bootloader. Er ist eine sicherheitsrelevante Basiskomponente für Firmware-Updates, Integritätsprüfungen und den kontrollierten Start eines eingebetteten Systems. Im Rahmen der CRA-Umsetzung arbeitet MicroControl daher auch an Konzepten für Secure Boot. Ziel ist es, sicherzustellen, dass ausschließlich autorisierte und unveränderte Firmware auf einem System ausgeführt wird. Technische Ansätze hierfür sind unter anderem kryptografische Signaturen, Integritätsprüfungen der Firmware und eine definierte Vertrauenskette vom Bootloader bis zur Applikation.
Orientierung an CRA, BSI-Empfehlungen und etablierten Standards
MicroControl setzt die Anforderungen nicht isoliert um, sondern orientiert sich eng an den Vorgaben des CRA sowie an den Empfehlungen des Bundesamts für Sicherheit in der Informationstechnik, kurz BSI. Das BSI beschreibt den CRA als europäische Verordnung, die ein Mindestmaß an Cybersicherheit für vernetzte Produkte festlegt, die auf dem EU-Markt bereitgestellt werden.
Ein wichtiger technischer Baustein ist die strukturierte Bereitstellung von Sicherheitsinformationen. Das BSI empfiehlt hierzu unter anderem das Common Security Advisory Framework, kurz CSAF. CSAF ist ein standardisiertes, maschinenlesbares Format zur Bereitstellung von Sicherheitshinweisen. Damit können Hersteller Informationen zu Schwachstellen, betroffenen Produkten, Versionen, Schweregraden, Abhilfemaßnahmen und Referenzen konsistent veröffentlichen. Für Anwender und Betreiber erleichtert dies die automatisierte Auswertung und die schnelle Bewertung, ob konkrete Produkte oder Versionen betroffen sind.
MicroControl berücksichtigt diese Anforderungen bereits in der eigenen Sicherheitsdokumentation. Auf unserer Seite zur Sicherheitsrichtlinie beschreiben wir, wie Sicherheitsschwachstellen gemeldet werden können, welche Informationen für eine Bewertung hilfreich sind und wie wir mit Meldungen im Rahmen einer koordinierten Offenlegung umgehen.
Schwachstellenmanagement und Coordinated Vulnerability Disclosure
Ein zentraler Bestandteil der CRA-Umsetzung ist ein belastbarer Prozess für das Schwachstellenmanagement. Dazu gehört die Fähigkeit, gemeldete Schwachstellen strukturiert aufzunehmen, technisch zu validieren, hinsichtlich ihrer Auswirkungen zu bewerten und geeignete Maßnahmen abzuleiten.
MicroControl setzt hierfür auf einen Prozess zur Coordinated Vulnerability Disclosure, also zur koordinierten Offenlegung von Schwachstellen. Nach Eingang einer Meldung werden die bereitgestellten Informationen geprüft, das Problem analysiert und mögliche Auswirkungen auf Produkte, Softwarestände oder Konfigurationen bewertet. Darauf aufbauend werden Maßnahmen zur Behebung oder Minderung definiert.
Für eine technische Bewertung sind insbesondere folgende Informationen relevant:
- betroffene Produkte und Produktversionen,
- betroffene Firmware-, Software- oder Hardwarestände,
- Beschreibung der Schwachstelle,
- Schritte zur Reproduktion,
- mögliche Auswirkungen auf Verfügbarkeit, Integrität oder Vertraulichkeit,
- vorhandene Proof-of-Concepts, Logdateien oder Protokollmitschnitte,
- Hinweise auf bereits bekannte CVE-Einträge oder vergleichbare Schwachstellen.
Sicherheitshinweise können anschließend Informationen zu betroffenen Versionen, Schweregradbewertungen, Updates, Workarounds, CVE-Referenzen und einer Revisionshistorie enthalten. Wo sinnvoll, kann die Bereitstellung solcher Informationen auch in standardisierten Formaten wie CSAF erfolgen.
Bedeutung für CAN-Netzwerke
Relevant ist der CRA auch für Produkte und Softwarekomponenten im CAN-Umfeld. Daraus ergibt sich die Notwendigkeit einer system- und anwendungsspezifischen Risikobewertung. Die CAN in Automation e.V., kurz CiA, weist einer Stellungnahme darauf hin, dass SL2 mit minimalen Aufwand in CAN-Netzwerken erreicht werden kann.
Für CAN-basierte Systeme ist die Bewertung immer vom konkreten Einsatzszenario abhängig. Sicherheitsmaßnahmen müssen daher abhängig von Systemarchitektur, Zugriffsmöglichkeiten, Schnittstellen, Betriebsumgebung und gefordertem Security Level ergänzt werden. In industriellen Anwendungen spielen dabei unter anderem folgende Aspekte eine Rolle:
- physischer Zugriff auf das CAN-Netzwerk,
- Netzwerksegmentierung und Gateway-Konzepte,
- Absicherung externer Schnittstellen,
- Trennung von Service-, Diagnose- und Produktionszugängen,
- Zugriffsschutz auf Konfigurations- und Updatefunktionen,
- Integritätsprüfung von Firmware und Konfigurationsdaten,
- Überwachung der Kommunikation,
- Authentifizierung und Autorisierung sicherheitsrelevanter Funktionen.
Für MicroControl ist dieser Kontext besonders wichtig, da unsere Protokollstacks typischerweise in kundenspezifische Geräte, Steuerungen oder Maschinen integriert werden. Die CRA-Konformität muss deshalb nicht nur auf Ebene einzelner Softwarekomponenten betrachtet werden, sondern immer auch im Zusammenspiel mit Zielhardware, Firmware, Bootloader, Updateprozess, Netzwerktopologie und Anwendung.
CSAF und SBOM: Komponenten über PURL und SKU eindeutig zuordnen
Bei der Verarbeitung von Sicherheitsmeldungen stellt sich häufig die Frage, wie eine in einer Schwachstellenmeldung genannte Komponente zuverlässig in einer bestehenden SBOM wiedergefunden werden kann. Gerade wenn Unternehmen Sicherheitsinformationen automatisiert auswerten möchten, ist eine eindeutige Identifizierung der betroffenen Produkte oder Komponenten entscheidend. Ohne standardisierte Identifikatoren bleibt das Matching zwischen Sicherheitsmeldung und SBOM fehleranfällig und oft nur manuell möglich.
Sicherheitsinformationen werden zunehmend im CSAF-Format bereitgestellt. CSAF steht für Common Security Advisory Framework und ist ein standardisiertes Format zur strukturierten Veröffentlichung von Security Advisories. Das CSAF-Format enthält unter anderem den Bereich product_tree. Dort können betroffene Produkte und Komponenten beschrieben werden.
Ein wichtiger Bestandteil ist dabei das Feld product_identification_helper. Dieses Feld ist nicht verpflichtend, bietet aber eine sehr hilfreiche Möglichkeit, zusätzliche Identifikatoren für ein Produkt oder eine Komponente anzugeben. Das Feld product_identification_helper erleichtert das automatische Matching zwischen:
- einer Komponente in einer Sicherheitsmeldung,
- und einer Komponente in einer SBOM.
Damit kann ein Tool automatisiert prüfen, ob eine bestimmte Schwachstelle für ein Produkt oder eine Softwarekomponente relevant ist. Besonders hilfreich ist dabei die Verwendung von standardisierten Identifikatoren wie der Package URL, kurz PURL.
Package URL als Identifikator
Die Package URL ist ein gängiger Standard zur Identifizierung von Softwarepaketen über unterschiedliche Ökosysteme hinweg. Eine PURL beschreibt ein Paket in einer strukturierten Form. Dadurch kann sie von Maschinen gelesen und für automatisierte Vergleiche genutzt werden.
Für die MicroControl Protokollstacks folgt die PURL dem folgendem Schema:
pkg:generic/microcontrol/<stack-prefix>-protocol-stack@<version-string>Schema einer PURL für Protokollstacks
– pkg: Kennzeichnung als Package URL
– generic: Pakettyp, wenn kein spezifisches Ökosystem wie npm, Maven oder PyPI verwendet wird
– microcontrol: Namespace oder Hersteller-/Organisationsbezug
– <stack-prefix>-protocol-stack: Name des Protokollstacks
– <version-string>: konkrete Version der Komponente
Ergänzende Identifikation über SKU
Neben der PURL kann zusätzlich eine SKU angegeben werden. In diesem Fall wird die SAP-Artikelnummer als SKU verwendet. Dadurch entsteht eine zweite Identifikationsmöglichkeit, die besonders hilfreich ist, wenn interne ERP-, Einkaufs- oder Produktdaten mit Sicherheitsinformationen abgeglichen werden sollen.
Für einen J1939 Protocol Stack in Version 4.12.00 mit der SAP-Artikelnummer 50.04.002 sieht der Eintrag im CSAF-Dokument wie folgt aus:
"product_identification_helper": {
"purl": "pkg:generic/microcontrol/j1939-protocol-stack@4.12.00",
"skus": [
"50.04.002"
]
}Beispiel Eintrag im CSAF-Dokument für J1939 Protokollstacks
Fazit
Der Cyber Resilience Act verändert die Anforderungen an Hersteller von Produkten mit digitalen Elementen grundlegend. Für MicroControl ist diese Entwicklung eng mit industrieller Kommunikation, eingebetteter Software, Bootloader-Technologien und CAN-basierten Systemen verbunden.
Wir setzen die Vorgaben des CRA, die Empfehlungen des BSI und die Hinweise aus dem CAN/CANopen-Umfeld konsequent um. Im Mittelpunkt stehen dabei strukturierte Sicherheitsprozesse, koordinierte Schwachstellenbehandlung, standardisierte Sicherheitshinweise, technische Dokumentation sowie sichere Update- und Bootkonzepte. Mit unseren Protokollstacks und Bootloader-Lösungen bewegen wir uns in einem technischen Umfeld, in dem Cyberresilienz zunehmend zum festen Bestandteil der Produktentwicklung wird. Die Umsetzung von Secure-Boot-Ansätzen, klaren Schwachstellenprozessen und nachvollziehbarer Dokumentation ist für uns daher ein wichtiger Schritt, um Kunden bei der Entwicklung sicherer und zukunftsfähiger industrieller Produkte zu unterstützen. Weitere Informationen zum Meldeweg und zum Umgang mit Sicherheitsschwachstellen finden Sie auf unserer Seite zur Sicherheitsrichtlinie.
