Cyber Resilience Act und was industrielle Betreiber jetzt konkret umsetzen müssen
Industrial Control Systems waren jahrzehntelang primär technische Systeme. Stabilität, Verfügbarkeit und Safety standen im Mittelpunkt. Cybersecurity wurde ergänzt – aber selten systemisch integriert. Mit dem Inkrafttreten des Cyber Resilience Act hat sich diese Lage grundlegend verändert. Der CRA macht Cybersicherheit zu einer rechtlich überprüfbaren Produkteigenschaft. Für industrielle Systeme bedeutet es, dass Sicherheit nicht länger eine optionale Qualität ist, sondern eine regulatorische Pflicht – über den gesamten Lebenszyklus hinweg.
Dieser Artikel zeigt konkret, was Betreiber industrieller Anlagen jetzt umsetzen müssen.
1. Der Paradigmenwechsel: Von Projekt-Security zu Produktverantwortung
Bisher wurde Sicherheit häufig projektbezogen behandelt:
-
Perimeter-Firewall implementieren
-
VPN-Zugang absichern
-
Passwortregeln definieren
Mit dem CRA verschiebt sich der Fokus. Entscheidend ist nicht mehr, ob einzelne Maßnahmen existieren, sondern ob ein System:
-
über den gesamten Lebenszyklus sicher betrieben werden kann
-
updatefähig ist
-
dokumentiert ist
-
Schwachstellenprozesse besitzt
-
und Vorfälle meldefähig abwickeln kann
Für Betreiber bedeutet das:
Sie müssen von Lieferanten belastbare Sicherheitsarchitekturen und Nachweise verlangen – und selbst interne Betriebsprozesse auf regulatorische Anforderungen ausrichten.
2. Updatefähigkeit ist keine Option mehr
Der CRA verlangt, dass Produkte während eines definierten Zeitraums sicher aktualisierbar bleiben.
Für industrielle Anlagen heißt das konkret:
-
Steuerungen dürfen nicht als statische Blackbox betrieben werden
-
Firmwarestände müssen dokumentiert sein
-
Abhängigkeiten zwischen Hardware, Firmware und Applikationssoftware müssen bekannt sein
-
Updateprozesse müssen getestet werden
In der Praxis bedeutet das:
-
Keine nicht patchbaren Komponenten ohne Kompensationsmaßnahmen
-
Keine nicht dokumentierten Firmwarestände
-
Keine ungeprüften Updates im Feld
Updatefähigkeit wird zu einer Architekturentscheidung – nicht zu einer Wartungsfrage.
3. Vulnerability Management wird betriebsrelevant
Der CRA verlangt aktive Schwachstellenbehandlung.
Betreiber müssen deshalb:
-
Schwachstellenmeldungen strukturiert aufnehmen
-
Relevanz für ihre Anlagen bewerten
-
Maßnahmen ableiten
-
Priorisieren
-
Dokumentieren
Das bedeutet: Ein reines IT-Vulnerability-Tool reicht nicht aus.
In industriellen Umgebungen müssen zusätzlich berücksichtigt werden:
-
Purdue- Modelle und Zonenarchitektur
-
Exposition gegenüber Remote Access
-
Safety-Auswirkungen
-
Produktionsfenster
-
Echtzeitfähigkeit
Ohne ein strukturiertes Vulnerability-Management-Framework ist regulatorische Konformität nicht erreichbar.
4. Incident Reporting wird verpflichtend
Ein zentraler Bestandteil des CRA ist die Meldepflicht bei sicherheitsrelevanten Vorfällen.
Das bedeutet für Betreiber:
-
Es muss klar definiert sein, was ein meldepflichtiger Vorfall ist
-
Zuständigkeiten müssen festgelegt sein
-
Eskalationswege müssen dokumentiert sein
-
Zeitliche Fristen müssen eingehalten werden
Ein ICS ohne definierte Incident-Response-Struktur ist regulatorisch nicht ausreichend abgesichert.
5. Logging und Nachweisbarkeit werden auditierbar
Ein weiterer zentraler Punkt: Nachweisbarkeit.
Betreiber müssen in der Lage sein zu zeigen:
-
Wer hatte wann Zugriff?
-
Welche Konfiguration wurde geändert?
-
Welche Softwarestände sind aktiv?
-
Welche Schwachstellen wurden bewertet?
Das bedeutet:
-
Zentrales Logging
-
Protokollierung von Remote-Zugängen
-
Change-Control-Dokumentation
-
Asset-Transparenz
Sicherheit ohne Nachweis wird künftig nicht mehr ausreichen.
6. Architektur wird zur Pflichtdisziplin
Viele industrielle Systeme sind historisch gewachsen. Segmentierung wurde nachgerüstet, Remote Access erweitert, WLAN ergänzt.
Der CRA zwingt zu einer strukturierten Betrachtung der Gesamtarchitektur.
Entscheidende Fragen sind:
-
Sind Steuerungsnetze klar segmentiert?
-
Gibt es definierte Sicherheitszonen?
-
Sind Remote-Zugänge über kontrollierte Conduits geführt?
-
Existiert eine DMZ?
-
Ist Protokollverschlüsselung angemessen umgesetzt?
Hier kommt die IEC 62443 ins Spiel. Sie liefert das methodische Gerüst für Zonierung, Zugriffskontrolle, Logging und Systemintegrität. Der CRA schreibt nicht jede technische Maßnahme vor – aber er verlangt, dass die Sicherheitsarchitektur belastbar und dokumentierbar ist.
7. Safety bleibt oberste Nebenbedingung
Ein häufiger Fehler in Security-Programmen ist die Vernachlässigung von Echtzeitanforderungen.
In industriellen Systemen gilt:
-
Determinismus hat Priorität
-
Safety-Zykluszeiten dürfen nicht verletzt werden
-
Verschlüsselung darf keine unzulässige Latenz erzeugen
Deshalb müssen Betreiber jede Security-Maßnahme bewerten im Hinblick auf:
-
CPU-Last
-
Zykluszeiten
-
Jitter
-
Safety-Integrität
Security darf Safety nicht kompromittieren.
Der CRA hebt diese Anforderung nicht auf.
8. Was Betreiber jetzt konkret tun müssen
Zusammengefasst ergeben sich acht unmittelbare Handlungsfelder:
-
Vollständige Asset-Transparenz herstellen
-
Zonenkonzept definieren oder überprüfen
-
Remote-Access-Architektur neu bewerten
-
Vulnerability-Management-Prozess einführen oder professionalisieren
-
Incident-Response-Struktur definieren
-
Logging- und Nachweisstrategie implementieren
-
Lifecycle-Strategie für Komponenten erstellen
-
Lab- oder Testumgebung zur Validierung etablieren
Ohne diese Grundlagen bleibt Compliance theoretisch.
9. Der zentrale Punkt
Der Cyber Resilience Act zwingt industrielle Betreiber zu einer strukturierten Sicherheitsarchitektur – nicht nur zu punktuellen Maßnahmen.
Wer jetzt handelt:
-
reduziert regulatorisches Risiko
-
erhöht technische Resilienz
-
verbessert Auditfähigkeit
-
und stärkt die langfristige Betriebsstabilität
Wer abwartet, wird reagieren müssen – unter Zeitdruck und möglicherweise unter Aufsicht.
Im nächsten Artikel analysieren wir im Detail, wie die IEC 62443 als technischer Referenzrahmen genutzt wird – und wie die Teile 3-3, 4-1 und 4-2 systematisch zusammenspielen, um eine belastbare Sicherheitsarchitektur zu bilden.
