Bild 01: Fabrikautomatisierung und industrielle Anwendungen müssen gegen aktuelle und zukünftige Cyber-Security-Bedrohungen gewappnet sein. (Quelle: Helmholz)
Die OT war ursprünglich eine eher isolierte Umgebung, in der PLC, Netzwerke und Steuerungskomponenten für eine spezifische Aufgabe zusammengeschaltet waren. Der Begriff Sicherheit bezog sich dabei vor allem auf den sicheren Betrieb, weniger auf Cyberbedrohungen. Doch seit der Entdeckung des Wurms Stuxnet im Jahr 2010 hat sich dies grundlegend geändert. Der Angriff auf SPS-Steuerungen zeigte eindrücklich, dass auch OT-Umgebungen Ziel von Cyberangriffen sein können. Traditionell arbeiteten diese Bereiche nicht mit externen Netzwerken zusammen. Heute jedoch sind OT-Netzwerke oft via Ethernet oder Wi-Fi an IT-Systeme oder mit der Cloud verbunden.
Mit der Konvergenz von IT und OT müssen Fabrikautomatisierung und industrielle Anwendungen gegen aktuelle und zukünftige Cyber-Security-Bedrohungen gewappnet sein (Bild 1). Zwar treten IT-Vorfälle häufiger auf, doch OT-Vorfälle sind meist wesentlich destruktiver und können Leib und Leben sowie ganze Unternehmen gefährden. Die technische Kluft zwischen IT- und OT-Systemen erschwert es, etablierte IT Sicherheitsmechanismen einfach zu übernehmen.
Staatliche und normative Vorgaben
Inzwischen haben nationale, europäische und internationale Institutionen die Relevanz von OT-Security erkannt. Ein zentrales Ergebnis auf EU-Ebene ist das Cyberresilienzgesetz (Cyber Resilience Act, CRA) [3]. Dieser bezieht sich auf alle Produkte mit digitalen Elementen, die in der Europäischen Union vertrieben werden – also auch auf OT-Komponenten. Der CRA wird nach einer Übergangszeit bis November 2027 ohne nationale Gesetzgebung europaweit gültig. Während der CRA den Fokus auf Produkte legt, adressiert die NIS-2-Richtlinie [4] vor allem Prozesse und IT in Unternehmen, insbesondere in kritischen Infrastrukturen (Kritis) und Kritis-nahen Betrieben. Zudem finden sich Cybersecurity-Anforderungen in weiteren Normen und Regularien wie der Maschinenverordnung (EU) 2023/1230 [5], der (EU) Radio Equipment Directive [6] (RED, Artikel 3.3), der UNR 155/156 [7] (automotive communication) oder der Normenreihe IEC 61508 [8] (Functional Safety).
Lösungsansatz für sichere OT-Umgebungen
Die Normenreihe IEC 62443 ist speziell auf industrielle Kommunikationssysteme (Industrial Automation and Control Systems, IACS) ausgerichtet und bietet einen Rahmen, um Cybersecurity umfassend zu betrachten und praktisch umzusetzen (Bild 2). Sie besteht aus vier Teilen: Während der erste Teil Begriffsbestimmungen klärt, befassen sich die weiteren Teile mit der gesamten Wertschöpfungskette einer Anlage: vom Komponentenlieferanten über den Maschinenbauer bis zum Anlagenbetreiber. Jeder Akteur muss seinen Beitrag zur Sicherheit leisten:
- Komponentenlieferant: Sichere Entwicklung sowie Bereitstellung von Sicherheitsupdates über den Lebenszyklus;
- Maschinenbauer: Sicherheit in Konzeption, Ausstattung mit sicheren Komponenten und sichere Konfiguration;
- Anlagenbetreiber: Sicherer Betrieb, Einspielen von Updates sowie Schulung von Personal.
Alle Beteiligten müssen zudem umfassende Dokumentationen, Hardening Guides und Schulungen bereitstellen sowie potenzielle Sicherheitsrisiken über den gesamten Produktlebenszyklus beobachten und veröffentlichen.
Konzepte der IEC 62443
Die Normenreihe IEC 62443 bietet praxisorientierte Konzepte, um technische und organisatorische Anforderungen abzudecken (Bild 3):
- Defense in Depth (Verteidigung in die Tiefe): Mehrschichtige Sicherheitskonzepte, ähnlich einer Burg mit Wassergraben, Mauern, Türmen und Wachen. So werden Anlagen und Maschinen in verschiedene Schichten unterteilt, von physischem Zugangsschutz bis hin zu sicherem System- und Netzwerkdesign.
- · Security by Design: Sicherheitsanforderungen müssen von Anfang an in die Produkt- und Maschinenentwicklung einfließen, gleichrangig zu funktionalen Anforderungen.
- Security by Default: Produkte sollen in ihrer Grundkonfiguration bereits so sicher wie möglich ausgeliefert werden. Potenziell riskante Funktionen werden erst bei Bedarf aktiviert.
- Secure Development Process and DevSecOps: Ein sicherer Entwicklungsprozess muss Sicherheit durchgängig berücksichtigen. Ähnlich fordern NIS-2 und
(EU) 2016/679 [9] (DSGVO) sichere Entwicklungs- und Betriebsumgebungen.
Da sich Bedrohungslagen ständig ändern, muss das Management von Komponenten laufend aktualisiert werden. Neue Firmware, Anweisungen oder Konfigurationen sind bei Bedarf aktiv zu kommunizieren. Das PSIRT (Product Security Incident Response Team) übernimmt dabei eine zentrale Rolle.