Geplante Norm für den Umgang mit Schwachstellen

Der neue Cyber Resilience Act (CRA) 2024/2847 soll ab Dezember 2027 digitale Produkte (wie z.B. auch Maschinen, IoT-Geräte, aber auch reine Software) sicherer machen. 

Eine Schlüsselanforderung des CRA wird die Vermeidung von Schwachstellen sowie weiterer Sicherheitsvorfälle sein, die Hersteller mithilfe von Softwareaktualisierungen beheben müssen. Dafür sehen die technischen Unterlagen des Rechtsakts eine “eine Beschreibung der Konzeption, Entwicklung und Herstellung des Produkts mit digitalen Elementen und der Verfahren zur Behandlung von Schwachstellen” vor.

Zur technischen Umsetzung dieser Anforderungen soll in Zukunft die Norm prEN 40000-1-3 dienen, die den Titel “Cybersecurity requirements for products with digital elements - Part 1-3: Vulnerability Handling ” tragen soll. Seit Anfang 2026 gibt es nun auch einen Normentwurf, welcher erste Details zur Umsetzung erläutert. Dieser Fachbeitrag stellt die wichtigsten Inhalte der Norm vor.

Auch wenn viele Hersteller vielleicht schon mit der Normenreihe IEC 62443 vertraut sind, bietet die neue Norm EN 40000-1-3 (derzeit prEN) ein entscheidendes Werkzeug für die Praxis. Die EN 40000-1-3 übersetzt die abstrakten gesetzlichen Vorgaben in konkrete Anforderungen. Dazu wird der Hersteller angeleitet, strukturierte Prozesse und interne und externe Richtlinien im Umgang mit Schwachstellen zu erstellen. Diese sollen die in den nachfolgenden Kapiteln erläuterten Inhalte berücksichtigen:

Koordinierte Offenlegung von Sicherheitslücken 

Die Norm konkretisiert, dass ein passiver Empfang von Fehlermeldungen nicht ausreicht. Hersteller müssen eine aktive Schnittstelle zur Außenwelt schaffen, um den Prozess zu unterstützen. Dazu müssen Hersteller eine externe Richtlinie zur koordinierten Offenlegung von Sicherheitslücken festlegen und diese öffentlich, z. B. auf der Website, zugänglich machen. Diese beinhaltet: 

• Einen „Safe Harbor“ (Rechtliche Sicherheit): Eine wichtigste vertrauensbildende Maßnahme. Der Hersteller sichert zu keinen rechtlichen Schritten gegen Melder einzuleiten, solange dieser: 
  • die Schwachstelle nicht ausnutzen
  • die Lücke zuerst dem Hersteller melden, statt sie sofort öffentlich zu machen
  • keine Erpressungsversuche unternimmt
• Empfangsmanagement: Der Zugang von Meldungen darf nicht an technischen Hürden scheitern. Ein professionelles Empfangsmanagement nutzt daher verschiedene vertrauliche Kanäle und Medien. Dies stellt sicher: 
  • dass kritische Informationen den Hersteller auf mindestens einem Weg, unabhängig von den Möglichkeiten des Senders erreichen
  • vertraulich bleiben 
• Einen Phasenplan (Response-Prozess): Was nach der Meldung passiert, um die Meldefristen des CRA zu wahren.
  • Eingangsbestätigung: Rückmeldung an den Melder innerhalb eines festen Zeitfensters (meist 48–72 Stunden).
  • Validierung & Analyse: Fachliche Prüfung durch den Hersteller, ob die Lücke real und kritisch ist.
  • Behebung: Zeitrahmen für die Entwicklung und den Test eines Patches oder Workarounds. 
• Koordinations-Regeln (Disclosure): Hier wird vereinbart, wie die Information an die Öffentlichkeit gelangt: 
  • Stillhaltefrist: Der Melder verpflichtet sich, Details erst zu veröffentlichen, wenn der Hersteller eine Lösung (Patch) bereitgestellt hat.
  • Gemeinsame Veröffentlichung: Festlegung, wie und wann ein Security Advisory für die betroffenen Kunden herausgegeben wird. 
• Anerkennung (Credit): Festlegung, ob und wie der Melder namentlich erwähnt wird (z. B. in einer „Hall of Fame“). Dies ist für viele Melder oft die primäre Motivation und fördert die Zusammenarbeit.

Integriertes Bestandsmanagement: SBOM trifft HBOM 

Die Norm konkretisiert, dass das Schwachstellenmanagement nicht bei der Software-Applikation aufhören darf. Identifizierung bedeutet gemäß der Norm, zu wissen, was wo verbaut ist, um bei der Entdeckung einer aktiv ausgenutzten Schwachstelle kurzfristig reaktionsfähig zu sein.

Hersteller müssen die gesamte „Bill of Materials“ im Blick haben, was eine Hardware Bill of Materials (HBOM) einschließt.  

• Separate Stücklisten: Neben der Software-Stückliste (SBOM) sind auch die beteiligten Hardware-Komponenten als Stückliste (HBOM) zu erfassen und somit eindeutig zu identifizieren.  
• Durchgängige Lieferkettensicherheit: Die Identifizierung muss die Tiefe der Lieferkette abbilden. Es reicht nicht, das Produkt zu kennen – man muss wissen, welche Software-Version auf welcher Hardware-Revision läuft.
• Aktualität: Die Stücklisten sind dabei keine statischen Dokumente, sondern ein dynamischer Datensatz, der über den gesamten Support-Zeitraum der Maschine aktuell gehalten werden muss.

Kontinuierliche Überprüfung und Identifizierung 

Die Norm beschreibt systematische Prüfprozesse über den gesamten Support-Zeitraum. 

• Automatisierung: Einsatz von Analyse-Tools, die die SBOM kontinuierlich auf neue bekannte Schwachstellen prüfen.
• Intervalle: Festlegung von regelmäßigen Review-Zyklen, auch wenn keine Änderungen an der Maschine vorgenommen wurden (da täglich neue Schwachstellen in bestehendem Code entdeckt werden).
• Nachweisbarkeit: Dokumentation der Prüfergebnisse als Teil der technischen Unterlagen für die Marktüberwachungsbehörden.

Patch-Management 

Wenn eine Lücke gefunden wurde, definiert die Norm einen „Weg zum Patch“: 

• Einstufung der Schwachstelle: Auf Basis einer Risikobewertung ist die Priorität der Behebung festzulegen. Kritische Schwachstellen müssen vor weniger riskanten Fehlern gepatcht werden.
• Interimslösungen: Wenn ein finaler Patch Zeit benötigt, fordert die Norm die sofortige Bereitstellung von Workarounds (z. B. Konfigurationsanpassungen), um das Zeitfenster für Angreifer zu minimieren.
• Sichere Verteilung: Die Norm konkretisiert Anforderungen an die Integrität des Updates, damit das Update selbst nicht zum Einfallstor wird.
• Informationspflicht: Erstellung von „Advisories“ – klare Anweisungen an den Maschinenbetreiber, welche Maßnahmen (Workarounds oder Updates) er treffen muss. 

Krisenreaktion und Melde-Workflows 

Dies ist der administrativ kritischste Punkt der Norm, da er die Brücke zur gesetzlichen Meldepflicht schlägt. 

• Ereignis-Kategorisierung: Die Norm hilft zu entscheiden: Ist dies ein „Sicherheitsvorfall“, der binnen 24 Stunden gemeldet werden muss?
• Schnittstellen-Definition: Festlegung interner Rollen (z.B. Product Security Officer), die autorisiert sind, Meldungen an nationale Behörden (in Deutschland das BSI) oder die ENISA abzusetzen.
• Dokumentationspflicht: Auch wenn eine Lücke nicht gemeldet wird, muss laut Norm intern begründet und dokumentiert werden, warum die Meldeschwelle nicht erreicht wurde. 

Synergien mit der Maschinenverordnung  

Meist müssen für Maschinen mehrere Regelwerke gleichzeitig erfüllt werden. Hierbei kann die Konformität mit dem CRA, durch Anwendung von Normen wie die der EN 40000-Reihe, auch die Einhaltung der Cybersicherheits-Aspekte der neuen 2023/1230 EU-Maschinenverordnung erleichtern. Die EN 40000-1-3 fungiert hier als "horizontale" Klammer, die Prozesse vereinheitlicht.