Cyber-Risikobewertung von Produkten: Warum sind die meisten Sicherheitsanalysen scheinbar korrekt, in der Praxis jedoch unbrauchbar?

In der überwiegenden Mehrheit der Technologieunternehmen existiert der Prozess, der als Cyber-Risikobewertung bekannt ist, bereits. Meist hat er die Form einer umfangreichen Tabelle, einer komplexen Matrix oder einer Kalkulation, in der die Werte „low“, „medium“ und „high“ dominieren. Dieses Dokument enthält eine lange Liste generischer Bedrohungen, kurze Beschreibungen potenzieller Schwachstellen sowie ein Set standardisierter Kontrollmaßnahmen. Formal betrachtet stimmt alles: Das Dokument ist vollständig, vom Vorstand unterzeichnet und sicher archiviert.

Das Problem ist nur: In der ingenieurpraktischen Realität verändert dieses Dokument rein gar nichts.

Es beeinflusst weder die Architektur des entwickelten Geräts. Noch bestimmt es Entscheidungen darüber, wie Updates bereitgestellt werden. Es verändert weder das After-Sales-Supportmodell noch überprüft es die Beziehungen zu Komponentenlieferanten. Es ist ein Dokument, das aus Compliance-Sicht korrekt ist, für die tatsächliche Cybersicherheit von Produkten jedoch vollkommen irrelevant. Das liegt nicht an fehlender Kompetenz in Engineering- oder Security-Teams. Es ist ein Problem eines grundlegend falschen Ausgangspunkts.

Die meisten klassischen Risikoanalysen beginnen mit der Frage: „Welche Bedrohungen können auftreten?“. Der neue, regulatorische Ansatz der Europäischen Union – deutlich erkennbar in Rechtsakten wie dem Cyber Resilience Act (CRA), den medizinischen Richtlinien (MDR) oder der neuen Maschinenverordnung 2023/1230 – erzwingt eine völlig andere Perspektive. Sie beginnt mit der Frage:

Unter welchen Nutzungsbedingungen kann ein Produkt zum Träger eines Risikos für den Nutzer, das System oder den Markt werden – und ist der Hersteller in der Lage, dieses Risiko über den gesamten Lebenszyklus zu beherrschen?

Das ist ein grundlegender Paradigmenwechsel. Eine Cyber-Risikobewertung im Produktkontext ist nicht einfach eine weitere Bedrohungsanalyse der IT-Infrastruktur. Sie ist auch weder ein Penetrationstest noch die mechanische Umsetzung der Leitlinien der Norm ISO 27001. Es handelt sich um eine tiefgehende Analyse der Fähigkeit sowohl des Produkts selbst als auch seines Herstellers, Sicherheit über die Zeit hinweg in einer realen Betriebsumgebung aufrechtzuerhalten.

Technische Schwachstelle vs. Produktrisiko – die Unterscheidung in der Cybersicherheit

Damit eine Risikobewertung nicht nur eine bürokratische Tabelle bleibt, sondern zu einem ingenieurmäßigen Entscheidungswerkzeug wird, müssen wir zwei Begriffe sauber voneinander trennen, die am Markt häufig durcheinandergeraten. Merken wir uns: Eine Schwachstelle ist nicht gleich Produktrisiko.

• Technische Schwachstelle ist ein konkreter, identifizierbarer Fehler in Software, Hardwarekonfiguration oder im Design selbst. Das kann eine fehlerhafte Datenvalidierung, eine veraltete Programmbibliothek oder eine Lücke im Authentifizierungsmechanismus sein. Solche Fehler werden in Datenbanken wie dem CVE-System (Common Vulnerabilities and Exposures) erfasst. Das bleibt jedoch eine Bewertung auf rein technischer Ebene.
• Produktrisiko entsteht erst dann, wenn die genannte Schwachstelle (oder sogar ihr vorübergehendes Nichtvorhandensein) in die harten Realitäten der Nutzung eingebettet wird.

Dieser Kontext umfasst eine Reihe von Variablen: die Arbeitsumgebung (offenes oder isoliertes Netzwerk), die Art der Integration mit anderen Systemen, das Verhalten der Nutzer, die Verfügbarkeit von Sicherheitsupdates (sog. Patch-Management) sowie die organisatorische Fähigkeit des Herstellers, auf Vorfälle zu reagieren.

Ein Produkt kann am Tag der Markteinführung keine bekannten Schwachstellen aufweisen und dennoch ein kritisches Risiko erzeugen, wenn sein Hersteller keine Prozesse für langfristigen Support hat. Das Verständnis dieses Unterschieds strukturiert die gesamte ingenieurmäßige Arbeit. Genau darauf basiert der risikobasierte Ansatz (risk-based approach). Sicherheitsmaßnahmen müssen proportional zu vorhersehbaren Missbrauchsszenarien sein – nicht zu einer abstrakten Liste aus dem Internet.

Das Sicherheitsparadox: Wann Schutz das Risiko in IT und OT erhöht

Beim Entwurf von Cybersicherheit wird oft angenommen, dass das Hinzufügen eines neuen „Vorhängeschlosses“ das Risiko immer senkt. Die Praxis zeigt, dass es mitunter genau umgekehrt ist. Eine Maßnahme, die ohne Verständnis des Kontexts umgesetzt wird, schafft neue Angriffsvektoren.

1. Starke Authentifizierung in der industriellen Umgebung (OT)

Stellen wir uns die Einführung einer Multi-Faktor-Authentifizierung (MFA) an einer Industriemaschine vor. Aus IT-Sicht ist das ein vorbildlicher Schritt, doch Cybersicherheit in der Industrieautomation ist eine völlig andere Realität. In der Fabrikumgebung läuft das Gerät 24/7, und Serviceeingriffe erfolgen unter Zeitdruck. Wenn das Netzwerk ausfällt, kann der Techniker den Token nicht online autorisieren. Die Produktion steht. Das Ergebnis? Der frustrierte Kunde deaktiviert diesen Mechanismus dauerhaft und umgeht die Schutzmaßnahme vollständig. Eine Maßnahme, die schützen sollte, hat ein massives operatives Risiko erzeugt.

2. Automatische Updates in Medizinprodukten (IoMT)

Schnelles Schließen von Schwachstellen minimiert die Angriffsfläche – in der IT ist das Standard. In der Medizintechnik kann ein erzwungenes Update während einer laufenden Prozedur jedoch das Systemverhalten verändern oder die Kommunikation mit dem Krankenhausnetzwerk stören. In diesem Fall erzeugt technischer Schutz ein kritisches klinisches und regulatorisches Risiko (Verstoß gegen die MDR-Zertifizierung).

3. Schließen von Schnittstellen in Consumer-Geräten (IoT)

Der Hersteller entfernt lokale Diagnoseports physisch aus einem Smart-Home-Gerät, um Hackern den Zugriff zu erschweren. In der Praxis beginnen autorisierte Servicepartner, Störungen über instabile Schnittstellen ohne Verschlüsselung zu diagnostizieren, und fortgeschrittene Nutzer installieren massenhaft modifizierte Software (custom firmware). Das Ergebnis ist ein vollständiger Verlust der Kontrolle des Herstellers über das eigene Ökosystem.

Eine echte Cyber-Risikoanalyse fragt: „Wie verändern sich Stabilität, Nutzbarkeit und Sicherheit des gesamten Ökosystems, wenn wir genau diesen Mechanismus hinzufügen?“.

Die 5 häufigsten Fehler in der Risikoanalyse technologischer Produkte

Bei der Bewertung von Prozessen in Unternehmen, die Elektronik und Software auf den Markt bringen, erkennen Cybersecurity-Experten wiederkehrende Muster.

1. Übertragen des Corporate-IT-Modells auf die Produktwelt. Ein Produkt ist kein Rechenzentrum. Es läuft in einer unbekannten Umgebung, oft offline, und wird von Laien konfiguriert. IT-Tools auf die Produktanalyse anzuwenden, endet damit, dass zentrale Themen ignoriert werden: der Lebenszyklus des Geräts und das Fehlen erzwungener Updates.
2. Analyse abstrakter Bedrohungen statt realer Szenarien. Schlagworte wie „unautorisierter Zugriff“ in eine Tabelle zu schreiben, ist analytisch wertlos. Die Analyse muss auf Konkretem beruhen: Wer? Über welche Schnittstelle? Zu welchem Zweck? Mit welcher Wirkung?
3. Ignorieren des Produktlebenszyklus (End-of-Life). Die Risikoanalyse bezieht sich meist auf den Zeitpunkt der Markteinführung. Dabei steigt das Risiko mit der Zeit – Open-Source-Bibliotheken altern, und Komponentenlieferanten stellen den Support ein. Ohne ein Wartungsmodell ist die Analyse falsch.
4. Abkopplung vom Entwicklungsteam (R&D). Die Risikobewertung als Checkliste vor dem Audit zu behandeln, ist der direkte Weg in die Katastrophe. Ergebnisse müssen als harte Architekturanforderungen an die Ingenieure zurückfließen (Secure by Design).
5. Technikfetisch auf Kosten von Prozessen. Unternehmen investieren ein Vermögen in fortgeschrittene Kryptografie, wissen aber nicht, wer im Unternehmen dafür verantwortlich ist, nach der Meldung einer Schwachstelle durch einen Forscher einen Sicherheitsfix (Patch) zu veröffentlichen (Vulnerability Disclosure Program).

Wie führt man eine Analyse gemäß Cyber Resilience Act durch? 7 Schritte aus Ingenieurssicht

Die Cyber-Risikobewertung muss aufhören, eine bürokratische Last zu sein. Nachfolgend ein marktübliches, EU-konformes Betriebsmodell (u. a. im Einklang mit den CRA-Anforderungen).

1. Definiere die Grenzen des Produkts. Ein Produkt ist nicht nur Hardware. Dazu gehören auch die Mobile-App, die Cloud, OTA-Server und API-Schnittstellen.
2. Beschreibe die harte Realität der Einsatzumgebung. Beschreibe nicht die Laborumgebung. Beantworte Fragen zur tatsächlichen Internetanbindung, zu den Kompetenzen der Nutzer und zu den Möglichkeiten des physischen Zugriffs auf das Gerät.
3. Identifiziere Missbrauchsszenarien (Threat Modeling). Verwirf generische Listen. Nutze bewährte ingenieurmäßige Methoden und Werkzeuge zur Risikoschätzung, um dich auf präzise Angriffsvektoren zu konzentrieren, die zu deiner Branche passen.
4. Quantifiziere nichtfinanzielle Konsequenzen. Bewerte das Risiko von Produktionsstillstand, Gesundheitsgefährdung oder der Verletzung regulatorischer Pflichten.
5. Stelle die Frage nach der Kontrolle. Kannst du als Hersteller das identifizierte Missbrauchsszenario verhindern, erkennen und schnell darauf reagieren?
6. Entwirf verhältnismäßige Schutzmechanismen. Entscheidungen zu Verschlüsselung oder Netzsegmentierung müssen sich direkt aus den Antworten der vorherigen Schritte ergeben.
7. Entwirf den Instandhaltungsprozess (Lifecycle). Dokumentiere die Policy zur Bereitstellung von Sicherheits-Patches, die Supportdauer sowie die Kommunikationskanäle zum Kunden.

Zusammenfassung: Was sollte nach einer fundierten Risikobewertung übrig bleiben?

Das Ergebnis einer korrekten Risikobewertung der Cybersecurity eines Produkts sollte niemals ein textlastiges Gedicht für den Auditor sein. Aus dieser Arbeit müssen greifbare Artefakte entstehen: eine klare Karte der Systemgrenzen, belastbare Architekturentscheidungen in R&D, ein freigegebenes Budget für die Update-Policy sowie eine konsistente Audit-Trail, die die Konformität mit EU-Richtlinien belegt.

Eine technologisch reife Organisation fragt nicht mehr: „Sind wir zu 100% sicher?“. Stattdessen fragt sie: „Wo genau sind wir exponiert, und können wir das über die Zeit beherrschen?“.

Ist dein Produkt bereit für neue Regulierung?

Sicherheit ist ein Prozess – kein einmaliges Zertifikat. Wenn du nicht möchtest, dass die Risikobeurteilung in deinem Unternehmen nur „Papierkram“ ist, lohnt es sich, proaktiv zu handeln. Sieh dir an, wie du ein Produkt in den Jahren 2026-2027 realistisch auf den Cyber Resilience Act (CRA) in den Jahren 2026-2027 vorbereitest – noch bevor offizielle harmonisierte Normen veröffentlicht werden.