Mit dem Cyber Resilience Act und der zunehmenden regulatorischen Bedeutung der IEC 62443 reicht es nicht mehr aus, Sicherheitsmaßnahmen intuitiv zu definieren. Jede industrielle Anlage benötigt eine nachvollziehbare, dokumentierte und methodisch saubere Risikoanalyse. Die maßgebliche Grundlage dafür ist die IEC 62443-3-2.
Alexander Tsolkas – Tsolkas Executive Consulting GmbH – Berater u.a. für IEC 62443 ICS, Warehousing, Logistics, Automotive, Rail, Energy und mehr
Dieser Artikel zeigt, wie eine Risikoanalyse nach 3-2 in der Praxis durchgeführt wird und wie daraus konkrete technische Maßnahmen, Security Levels und Architekturentscheidungen abgeleitet werden.
1 Ziel der Risikoanalyse
Die Risikoanalyse verfolgt drei zentrale Ziele:
Identifikation schützenswerter Assets
Bewertung realistischer Bedrohungsszenarien
Ableitung angemessener Schutzmaßnahmen
Sie dient nicht der theoretischen Dokumentation, sondern ist das Fundament für:
Zonenkonzepte
Segmentierungsentscheidungen
Remote Access Architektur
Vulnerability Priorisierung
Security Level Definition
Ohne strukturierte Risikoanalyse bleibt jede Sicherheitsarchitektur zufällig.
2 Schritt 1 Asset Identifikation
Der erste und wichtigste Schritt ist vollständige Transparenz.
Ein Asset in industriellen Systemen ist nicht nur ein Server oder eine Steuerung. Es umfasst:
PLC
HMI
IPC
Switches
Firewalls
Industrial WLAN Komponenten
Gateways
Engineering Stationen
Remote Access Systeme
Sicherheitssteuerungen
Edge Geräte
Sicherheitsrelevante Software
Zusätzlich müssen logische Assets erfasst werden:
Netzwerkzonen
Kommunikationspfade
Remote Verbindungen
Externe Dienstleisterzugänge
Jedes Asset erhält mindestens folgende Attribute:
Technische Funktion
Standort
Zone
Firmware oder Software Version
Verantwortlicher Eigentümer
Kritikalität
Ohne vollständige Assetbasis ist keine belastbare Risikoanalyse möglich.
3 Schritt 2 Bedrohungsmodellierung
Im zweiten Schritt werden realistische Bedrohungen identifiziert.
Hierbei wird unterschieden zwischen:
Unbeabsichtigten Fehlhandlungen
Technischen Fehlfunktionen
Externe Angriffe
Interne Manipulation
Lieferkettenrisiken
Wichtig ist, keine abstrakten Extremfälle zu modellieren, sondern reale Szenarien wie:
Missbrauch eines Remote Zugangs
Manipulation von Parametern
Unbefugter Zugriff auf Engineering Station
Malware Einschleusung über Wartungslaptop
Ausnutzung ungepatchter Komponenten
Die Bedrohungsanalyse muss sich an der tatsächlichen Exposition orientieren.
4 Schritt 3 Bewertung von Auswirkungen
Nun werden Auswirkungen bewertet. In industriellen Systemen sind die klassischen IT Kriterien nicht ausreichend.
Bewertet werden müssen insbesondere:
Auswirkung auf Safety
Produktionsausfall
Qualitätsbeeinträchtigung
Umweltrisiko
Haftungsrisiko
Reputationsschaden
Ein Angriff mit geringer Datenrelevanz kann in einer Produktionsumgebung erhebliche wirtschaftliche Auswirkungen haben.
Verfügbarkeit und Integrität stehen meist vor Vertraulichkeit.
5 Schritt 4 Eintrittswahrscheinlichkeit bewerten
Die Eintrittswahrscheinlichkeit hängt unter anderem ab von:
Netzwerkexposition
Existenz von Remote Access
Zonensegmentierung
Patchstand
Angriffsattraktivität
Komplexität des Angriffs
Ein isoliertes Safety Netz mit physischer Trennung besitzt eine andere Eintrittswahrscheinlichkeit als eine Steuerung mit Internetanbindung.
Hier ist technische Ehrlichkeit gefragt.
6 Schritt 5 Risikoermittlung und Priorisierung
Risiko ergibt sich aus Auswirkung multipliziert mit Eintrittswahrscheinlichkeit. In der Praxis empfiehlt sich eine strukturierte Matrix mit klar definierten Bewertungsstufen. Ergebnis ist eine priorisierte Liste von Risiken.
Diese Liste bildet die Grundlage für:
Architekturentscheidungen
Security Level Festlegung
Budgetpriorisierung
Maßnahmenplanung
7 Ableitung von Security Levels
Die Risikoanalyse führt zur Definition eines Ziel Security Levels pro Zone. Hier kommt die IEC 62443-3-3 ins Spiel. Zonen mit höherem Risiko erhalten höhere Security Level Anforderungen.
Beispiel:
Eine Safety Zone mit kritischer Abschaltfunktion kann SL3 erfordern.
Eine isolierte Monitoring Zone kann SL2 ausreichend sein.
Security Levels sind Ergebnis der Analyse, nicht politischer Wunschwerte.
8 Ableitung konkreter Maßnahmen
Aus den priorisierten Risiken werden technische Maßnahmen abgeleitet, zum Beispiel:
Netzwerksegmentierung
Stärkere Authentisierung
Einführung von MFA
TLS Verschlüsselung
Einführung eines Industrial Security Lab
Einführung strukturierter Patchprozesse
Erweiterung von Logging und Monitoring
Jede Maßnahme muss einem identifizierten Risiko zugeordnet werden. Maßnahmen ohne Risikobezug sind nicht auditierbar.
9 Dokumentation und Auditfähigkeit
Die Risikoanalyse muss dokumentiert werden.
Sie sollte enthalten:
Assetliste
Zonenkonzept
Bedrohungsszenarien
Risikobewertung
Security Level Zuordnung
Maßnahmenkatalog
Rest Risiko Bewertung
Diese Dokumentation ist nicht nur für interne Steuerung relevant, sondern wird künftig bei Audits und regulatorischen Bewertungen eine zentrale Rolle spielen.
10 Typische Fehler in der Praxis
Unvollständige Asset Erfassung
Copy Paste Bedrohungslisten
Keine Berücksichtigung von Safety
Überbewertung rein theoretischer Szenarien
Keine Verknüpfung zur Architektur
Keine Aktualisierung bei Änderungen
Eine Risikoanalyse ist kein einmaliges Dokument. Sie muss regelmäßig aktualisiert werden, insbesondere bei:
Architekturänderungen
Einführung neuer Protokolle
Remote Access Erweiterungen
Cloud Anbindungen
Fazit
Die Risikoanalyse nach IEC 62443 3 2 ist kein bürokratischer Akt. Sie ist das technische Fundament jeder belastbaren Sicherheitsarchitektur. Wer hier sauber arbeitet, schafft:
Transparenz
Priorisierung
Planbarkeit
Auditfähigkeit
Im nächsten Artikel betrachten wir die Referenzarchitektur für Industrial Control Systems und analysieren, wie Zonenkonzepte, Segmentierung und Conduits konkret umgesetzt werden.
Weitere Artikel
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 3 – Wann wird eine industrielle Anlage regulatorisch zu einem Produkt und was bedeutet das für Betreiber
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 2 – IEC 62443 richtig verstanden und wie 3-3, 4-1, und 4-2 zusammen eine belastbare Sicherheitsarchitektur bilden
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 1 – Cyber Resilience Act und was industrielle Betreiber jetzt konkret umsetzen müssen
Artikelserie Digitale ID – Artikel 8 – Der unsichtbare Abzug