Product Security über den Produktlebenszyklus

Unternehmens-IT-Security schützt die eigene Infrastruktur und wird typischerweise über ein ISMS nach ISO/IEC 27001 gesteuert. Product Security schützt dagegen das Produkt im Feld – in der Umgebung des Kunden, oft mit physischem Zugriff durch Angreifer und über Laufzeiten, die übliche IT-Supportzyklen deutlich überschreiten. Eine Schwachstelle betrifft dabei nicht ein einzelnes System, sondern die gesamte installierte Basis und kann Safety-Folgen, Rückrufe oder den Verlust der Typgenehmigung nach sich ziehen. Organisatorisch verschiebt sich die Verantwortung damit vom IT-Betrieb in die Produktentwicklung – mit eigenen Managementsystemen (CSMS), Entwicklungsprozessen (Secure Development Lifecycle) und Reaktionsstrukturen (PSIRT).

ISO/SAE 21434:2021 definiert das Cybersecurity-Engineering für Straßenfahrzeuge über den gesamten Lebenszyklus – von der Konzeptphase bis zur Außerbetriebnahme. Kernstück ist die Threat Analysis and Risk Assessment (TARA) nach Kapitel 15: von der Asset-Identifikation über Bedrohungsszenarien, Schadens- und Angriffspfadanalyse bis zur Risikobehandlungsentscheidung. Verbindlich wird das Thema durch die UNECE-Regelungen: UN R155 verlangt ein zertifiziertes Cybersecurity-Management-System (CSMS) als Voraussetzung der Typgenehmigung, UN R156 ein Software-Update-Management-System (SUMS). In der EU gelten beide über die General Safety Regulation (EU) 2019/2144 – seit Juli 2022 für neue Fahrzeugtypen, seit Juli 2024 für alle Neufahrzeuge; ISO/SAE 21434 gilt als anerkannter Stand der Technik zur Umsetzung der CSMS-Anforderungen.

Für Komponenten industrieller Automatisierungssysteme trennt die IEC-62443-Reihe Prozess- und Produktanforderungen. IEC 62443-4-1:2018 beschreibt einen sicheren Produktentwicklungslebenszyklus in acht Practices – von Security-Management und Anforderungsspezifikation über Secure Design und Implementierung bis zu Verifikation, Defect- und Patch-Management sowie Security-Guidelines für Anwender –, der ausdrücklich bis zum Produkt-End-of-Life reicht und über vier Reifegrade bewertet wird. IEC 62443-4-2:2019 spezifiziert die technischen Anforderungen an die Komponenten selbst: Component Requirements für vier Komponententypen (Embedded Devices, Host Devices, Netzwerkkomponenten, Software-Applikationen), abgeleitet aus sieben Foundational Requirements und gestaffelt in die Security Level SL 1 bis SL 4. Für Hersteller werden beide Teile zunehmend zum Beschaffungskriterium, weil Betreiber Nachweise und Security Level konkret nachfragen.

Die Delegierte Verordnung (EU) 2022/30 aktiviert die Cybersicherheitsanforderungen des Art. 3 Abs. 3 Buchst. d–f der Funkanlagenrichtlinie (RED); seit dem 1. August 2025 sind sie verbindliche Voraussetzung für das Inverkehrbringen internetfähiger Funkanlagen. Als harmonisierte Normen dienen EN 18031-1, -2 und -3 (Ausgabe 2024) für Netzschutz, Schutz personenbezogener Daten und Betrugsschutz; die EU-Kommission hat sie im Januar 2025 im Amtsblatt gelistet – allerdings mit Einschränkungen. Erlaubt ein Produkt etwa den Verzicht auf ein Passwort (Abschnitte 6.2.5.1/6.2.5.2) oder fehlt bei EN 18031-2 eine zugesicherte Kindersicherung (Abschnitte 6.1.3–6.1.6), greift die Konformitätsvermutung nicht, und eine Benannte Stelle muss einbezogen werden. Hersteller sollten diese Einschränkungen daher früh im Konformitätsbewertungsverfahren prüfen.

Ein Product Security Incident Response Team (PSIRT) behandelt Schwachstellen in den eigenen Produkten – im Unterschied zum CSIRT, das Vorfälle in der eigenen Infrastruktur bearbeitet. Das PSIRT Services Framework v1.1 von FIRST (2020) strukturiert die Aufgaben in sechs Service-Bereiche – Stakeholder Ecosystem Management, Vulnerability Discovery, Triage, Remediation, Disclosure sowie Training und Education – und beschreibt verteilte, zentralisierte und hybride Organisationsmodelle. Spätestens mit dem Cyber Resilience Act (Verordnung (EU) 2024/2847) wird diese Fähigkeit zur Pflicht: Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen nach Art. 14 gestaffelt binnen 24 Stunden, 72 Stunden und 14 Tagen an den als Koordinator benannten CSIRT und die ENISA melden; für schwerwiegende Vorfälle gilt dieselbe Staffelung mit einem Monat für den Abschlussbericht. Ohne eingespielte PSIRT-Prozesse sind diese Fristen kaum einzuhalten.

Produktsicherheit endet nicht mit der Markteinführung: Schwachstellenmanagement, Sicherheitsupdates und Monitoring müssen über die gesamte Nutzungsdauer geplant und finanziert werden. Der Cyber Resilience Act verlangt einen Unterstützungszeitraum, der die erwartete Produktnutzungsdauer widerspiegelt und in der Regel mindestens fünf Jahre beträgt (Art. 13 Abs. 8); Sicherheitsupdates sind kostenlos bereitzustellen, und der Support-Zeitraum ist vor dem Kauf transparent zu machen. Branchennormen denken das End-of-Life ebenfalls mit: IEC 62443-4-1 nimmt es ausdrücklich in den Entwicklungslebenszyklus auf, UN R156 verlangt gemanagte Software-Updates über die Fahrzeuglebensdauer. Ein geordnetes End-of-Life umfasst die frühzeitige Ankündigung des Support-Endes, letzte Security-Advisories und Migrationspfade für Bestandskunden.