Im ersten Artikel dieser Serie haben wir die regulatorische Lage durch den Cyber Resilience Act betrachtet. Der CRA definiert Pflichten. Er fordert Updatefähigkeit, Vulnerability Management, Incident Reporting und nachweisbare Sicherheit. Doch der CRA beschreibt nicht im Detail, wie industrielle Systeme technisch abgesichert werden müssen. Hier kommt die IEC 62443 ins Spiel.
Alexander Tsolkas – Gründer von Sectank – Berater ICS für Produktsicherheit IEC 62443, MVO, CRA, EN 50741 und 50742 und mehr
Wer die 62443 nur als Sammlung technischer Anforderungen versteht, verkennt ihre eigentliche Stärke. Richtig angewendet ist sie ein vollständiges Architektur und Betriebsmodell für Industrial Control Systems. Dieser Artikel zeigt, wie die drei zentralen Bausteine 3-3, 4-1 und 4-2 zusammenwirken und warum sie nur im Zusammenspiel ihre Wirkung entfalten.
1 Der häufigste Fehler Normteile isoliert betrachten
Viele Unternehmen behandeln die Norm fragmentiert.
4-2 für Komponenten
3-3 für Systeme
4-1 für Entwicklung
Das Ergebnis ist häufig inkonsistent. Komponenten erfüllen Mindestanforderungen, aber das System ist falsch segmentiert.
Architektur ist sauber definiert, aber Updates sind organisatorisch nicht geregelt. Ein Entwicklungsprozess existiert, aber der Betrieb ist nicht strukturiert. Die Norm ist bewusst so aufgebaut, dass sie nur als integriertes Modell funktioniert. Wer sie modular einsetzt, produziert Lücken.
2 IEC 62443 4-1 Security im Entwicklungsprozess verankern
Die IEC 62443-4-1 definiert Anforderungen an den Secure Development Lifecycle. Hier geht es um
Threat Modeling
Sicherheitsanforderungen
Code Reviews
Schwachstellenbehandlung
Patchprozesse
Dokumentation
Warum ist das für Betreiber relevant? Weil Betreiber künftig nachweisen müssen, dass die eingesetzten Produkte systematisch entwickelt wurden, updatefähig sind und über definierte Prozesse zur Schwachstellenbehandlung verfügen. Ein Produkt ohne strukturierten Entwicklungsprozess ist regulatorisch riskant. 4 1 ist damit die Grundlage für CRA Konformität auf Produktebene, für belastbare Updatefähigkeit und für nachvollziehbares Vulnerability Handling.
3 IEC 62443 4 2 Sicherheitsanforderungen an Komponenten
Die IEC 62443-4-2 beschreibt technische Mindestanforderungen für einzelne Komponenten. Sie definiert unter anderem Anforderungen zu
Identifikation und Authentisierung
Zugriffskontrolle
Systemintegrität
Audit Logging
Verfügbarkeitsschutz
Kryptografische Funktionen
Konkrete Beispiele sind:
Keine Default Passwörter
Rollenbasierte Zugriffskontrolle
Schutz vor Manipulation von Firmware
Protokollierung sicherheitsrelevanter Ereignisse
4-2 beantwortet die Frage, was ein einzelnes Gerät technisch leisten muss. Sie beantwortet jedoch nicht, wie diese Geräte im Gesamtsystem miteinander abgesichert werden.
4 IEC 62443 3-3 Sicherheitsanforderungen auf Systemebene
Die IEC 62443-3-3 verschiebt den Fokus vom Gerät zum Gesamtsystem. Hier geht es um
Purdue Modelle und Zonierung
Conduits
Segmentierung
Systemweite Zugriffskontrolle
Logging Strategien
Monitoring
Security Levels
Während 4-2 beschreibt, welche Fähigkeiten eine Komponente besitzen muss, beschreibt 3-3, wie diese Komponenten in einer sicheren Architektur zusammenspielen. 3-3 ist damit das eigentliche Steuerinstrument für Sicherheitsarchitekturen.
5 Security Levels richtig einordnen
Ein zentrales Element von 3-3 sind Security Levels. Sie beschreiben das Widerstandsniveau gegen unterschiedliche Angreifermodelle.
SL1 Schutz gegen zufällige oder unbeabsichtigte Verletzungen
SL2 Schutz gegen einfache vorsätzliche Angriffe
SL3 Schutz gegen gezielte Angriffe mit moderaten Ressourcen
SL4 Schutz gegen hochentwickelte Angreifer
In der Praxis wird häufig SL2 behauptet, aber nur SL1 implementiert. Für viele industrielle Anlagen ist SL3 realistisch der relevante Zielwert. SL3 bedeutet unter anderem
Starke Authentisierung
Minimierung von Angriffsflächen
Integritätsüberwachung
Durchgängiges Logging
Klare Netzwerksegmentierung
SL3 ist kein Label. Es ist eine technische und organisatorische Entscheidung.
6 Zusammenspiel der Normteile ein praktisches Beispiel
Nehmen wir das Thema Remote Access.
4-2 fordert starke Authentisierung auf Komponentenebene.
3-3 fordert, dass Remote Zugänge über definierte Conduits geführt werden.
4-1 fordert einen dokumentierten Prozess für Credential Handling und Schwachstellenbehandlung.
Erst das Zusammenspiel dieser Anforderungen erzeugt eine belastbare Lösung.
Oder Patch Management.
4-1 definiert den Prozess.
4-2 fordert Updatefähigkeit auf Komponentenebene.
3-3 definiert Schutzmechanismen im Systemkontext.
Isoliert betrachtet entstehen Lücken. Integriert entsteht ein Sicherheitsmodell.
7 Typische Umsetzungsfehler
In realen Projekten sind häufig folgende Schwächen zu beobachten
Keine klar definierte Zonierung
Vermischung von IT und OT Sicherheitszonen
Unklare Security Level Zuordnung
Fehlende Dokumentation von Abhängigkeiten
Kein strukturiertes Change Management
Die Norm ist nicht komplex. Sie wird jedoch oft nicht systematisch umgesetzt.
8 Was Betreiber konkret einfordern sollten
Betreiber sollten von Lieferanten mindestens folgende Nachweise verlangen
Nachweis eines 4-1 konformen Entwicklungsprozesses
Dokumentation der 4-2 Compliance auf Komponentenebene
Architekturabbildung nach 3-3 mit klarer Zonendefinition
Definierte Security Level Zuordnung
Dokumentierte Logging und Incident Strategie
Nur wenn diese Ebenen integriert sind, entsteht ein regulatorisch belastbares Gesamtsystem.
Fazit
3-3, 4-1 und 4-2 sind keine isolierten Kapitel. Sie bilden zusammen
Entwicklungsdisziplin
Technische Mindestanforderungen
Architektonische Systemstruktur
Wer diese drei Ebenen integriert, baut keine punktuelle Security, sondern eine belastbare industrielle Sicherheitsarchitektur.
Im nächsten Artikel betrachten wir eine entscheidende Frage. Wann wird eine industrielle Anlage regulatorisch zu einem Produkt und welche Dokumentations, Nachweis und Haftungspflichten ergeben sich daraus konkret?
Wir analysieren die Verbindung zwischen CRA und CE Kennzeichnung, die Rolle der technischen Dokumentation, SBOM Anforderungen und warum viele Betreiber ihre regulatorische Mitverantwortung unterschätzen.
Weitere Artikel
Artikelserie Digital ID – Artikel 19 – Digitale Identität und programmierbares Geld
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 12 – Als Zahlen noch keine Identität brauchten
Artikelserie Digitale ID – Artikel 6 – Das konditionierte Geld