Bedrohungs- und Risikoanalyse nach IEC 62443: Methode, Nachweis, typische Lücken

Fast jedes Unternehmen, das Feldgeräte baut, hat eine Bedrohungs- und Risikoanalyse. Deutlich weniger haben eine, die ein Audit übersteht. Der Unterschied liegt selten in der Methode — sondern darin, ob sich die Analyse zum Zeitpunkt der Prüfung noch herleiten lässt: welche Version gilt, worauf die Risikoentscheidung beruhte, und ob nach der Freigabe noch etwas geändert wurde.

Dieser Artikel ordnet ein, wie eine Analyse nach IEC 62443 methodisch aufgebaut ist, welche zusätzlichen Pflichten der Cyber Resilience Act mitbringt, und an welchen Stellen sie in der Praxis reißt.

Zwei Perspektiven, die oft verwechselt werden

IEC 62443 ist eine Normenreihe, keine einzelne Norm — und die Teile sprechen unterschiedliche Rollen an. Für die Risikoanalyse sind zwei Blickwinkel relevant:

• Anlagenperspektive (62443-3-2): Ein Betreiber oder Integrator betrachtet ein System under Consideration, teilt es in Zonen und Conduits und bewertet die Risiken dieser Struktur.
• Produktperspektive (62443-4-1 / 4-2): Ein Gerätehersteller betrachtet sein Produkt — den Entwicklungsprozess, der Sicherheit systematisch erzeugt (4-1), und die technischen Anforderungen, die das Gerät erfüllen muss (4-2).

Wer Geräte baut, arbeitet primär in der zweiten Welt. Der Prozess der 62443-3-2 ist trotzdem lehrreich, weil er sauber vormacht, wie eine Risikoanalyse strukturiert abläuft — und weil Ihre Kunden nach genau dieser Logik fragen werden.

Der strukturierte Ablauf: sieben Schritte

IEC 62443-3-2 (Edition 1.0, 2020-06) beschreibt die Risikobewertung als Folge von sieben Schritten, den Zone and Conduit Requirements (ZCR):

Das übergreifende Prinzip für die Aufteilung ist dabei ausdrücklich die Risikobewertung selbst (ZCR 3.1) — nicht die Netzwerktopologie und nicht das Organigramm.

Der eigentliche Wert dieses Ablaufs liegt in Schritt 4. Er zwingt zu einer expliziten Aussage darüber, was als tolerierbar gilt. Genau diese Aussage fehlt in den meisten Analysen, die uns begegnen — und ohne sie ist jede Priorisierung danach eine Geschmacksfrage.

Risiko bewerten heißt: zwei Größen getrennt halten

Ein Risiko ist keine Zahl, die vom Himmel fällt, sondern das Zusammenspiel aus Eintrittsmöglichkeit und Auswirkung. Beide werden getrennt erhoben und erst am Ende zusammengeführt — typischerweise über eine Matrix, nicht über eine Formel.

Für die Eintrittsseite existiert eine etablierte, nachvollziehbare Systematik: die Attack-Potential-Bewertung aus der Common-Criteria-Methodik, veröffentlicht als internationale Norm ISO/IEC 18045. Sie zerlegt die Frage „wie realistisch ist dieser Angriff?” in fünf Faktoren — benötigte Zeit, erforderliche Expertise, Kenntnis des Zielobjekts, Gelegenheitsfenster und benötigte Ausrüstung — und macht aus der Einschätzung eine reproduzierbare Rechnung statt eines Bauchgefühls.

Auf der Auswirkungsseite lohnt die Trennung in Kategorien — Safety, finanzieller Schaden, Betriebsunterbrechung, rechtliche Folgen, Datenschutz. Gerade bei Geräten mit sicherheitsgerichteter Funktion ist die Safety-Kategorie der Punkt, an dem Security-Analyse und funktionale Sicherheit sich berühren: Ein Integritätsverlust ist dort kein reines IT-Problem, sondern kann die Schutzfunktion selbst außer Kraft setzen.

Was der Cyber Resilience Act hinzufügt

Der CRA macht aus der guten Praxis eine Pflicht — mit zwei Terminen, die unterschiedliche Dinge bedeuten:

• 11. September 2026: Die Meldepflichten greifen. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind an ENISA und das zuständige nationale CSIRT zu melden — und zwar auch für Produkte, die bereits im Markt sind. Eine Übergangsfrist gibt es hier nicht.
• 11. Dezember 2027: Die übrigen Pflichten gelten vollständig — die grundlegenden Cybersicherheitsanforderungen aus Annex I, Konformitätsbewertung, technische Dokumentation, EU-Konformitätserklärung und CE-Kennzeichnung.

Für die Risikoanalyse ist vor allem der zweite Termin relevant: Die Risikobewertung ist kein freiwilliges Beiwerk, sondern Teil der Nachweiskette, auf der die Konformitätserklärung ruht. Was Sie unterschreiben, müssen Sie herleiten können.

Die vier Lücken, die im Audit auffallen

Aus unseren Assessments wiederholen sich vier Muster:

Die Analyse ist ein Dokument, kein Zustand. Sie wurde einmal erstellt, meist vor einem Release, und danach nicht mehr angefasst. Das Produkt hat sich seither dreimal geändert. Beim Audit gilt formal ein Stand, der die aktuelle Firmware nicht beschreibt.

Die Bewertung ist nicht reproduzierbar. Risiken tragen Werte wie „hoch”, aber niemand kann sagen, wie dieser Wert zustande kam. Zwei Personen im selben Team kämen zu verschiedenen Ergebnissen — das ist kein Bewertungsmaßstab, sondern eine Meinung mit Farbcode.

Die Abdeckung ist behauptet, nicht belegt. Zu jeder Anforderung existiert ein Häkchen, aber keine Aktivität, die es trägt. Die Frage „welche konkrete Maßnahme deckt diese Anforderung ab, und wo ist deren Ergebnis?” bleibt offen.

Prozessreife und Umsetzung klaffen auseinander. Der Entwicklungsprozess nach 62443-4-1 ist vorbildlich dokumentiert — aber im Gerät ist die entsprechende technische Anforderung aus 62443-4-2 nicht verifiziert. Diese Lücke ist die teuerste, weil sie erst auffällt, wenn jemand das Produkt selbst prüft statt der Ablage.

Was daraus folgt

Eine belastbare Bedrohungs- und Risikoanalyse ist weniger eine Frage der Methodenwahl als der Durchhaltefähigkeit. Sie braucht eine explizite Risikoakzeptanzschwelle, eine reproduzierbare Bewertungssystematik, eine nachvollziehbare Verbindung von Anforderung zu Nachweis — und einen Mechanismus, der all das aktuell hält, wenn sich das Produkt ändert.

Die Methode dafür ist seit Jahren verfügbar und gut dokumentiert. Woran es in der Praxis scheitert, ist fast nie das Verfahren, sondern die Frage, wo der Stand lebt und wer ihn pflegt.