Schutz für Industrieanlagen: IEC 62443: Der Standard für sichere Automatisierung
In der Welt der Automatisierungstechnik verschmelzen mehrere Disziplinen, darunter Maschinenbau und IT-Sicherheit. Die Herausforderung besteht darin, dass Experten mit unterschiedlichen Hintergründen und Fachsprachen zusammenarbeiten müssen. Hier eine solide Brücke zu bauen, ist Ziel der IEC 62443-Norm.
Der Standard bietet eine gemeinsame Basis für sichere Automatisierungssysteme. Er schafft einheitliche Begriffe und Konzepte, die Anwender, Kunden und Produkthersteller zusammenbringen, um gemeinsam Sicherheitsprobleme zu lösen.
Die IEC 62443 ist ein umfassender Sicherheitsstandard, der ursprünglich für die Absicherung von Industrial Automation and Control Systems (IACS) entwickelt wurde. Heutzutage wird er jedoch in einem breiteren Kontext angewendet und bietet eine ganzheitliche Betrachtung der Sicherheit von Automatisierungstechnik, auch bekannt als Operational Technology (OT) Security.
Warum benötigen wir überhaupt einen speziellen Sicherheitsstandard für Automatisierungstechnik? In der herkömmlichen Informationstechnologie (IT) sind die primären Ziele:
- die Vertraulichkeit (kein unbefugter Zugriff auf Informationen),
- die Integrität (keine unbemerkte Veränderung von Informationen) und
- die Verfügbarkeit (keine Beeinträchtigung des Zugriffs auf Informationen).
Im OT-Bereich sind diese Schutzziele ebenfalls relevant, jedoch in umgekehrter Reihenfolge der Relevanz: Die Verfügbarkeit steht an erster Stelle, gefolgt von der Integrität. Denn eine nicht funktionierende oder fehlerhafte Anlage kann erhebliche Verluste verursachen. Die Vertraulichkeit steht an dritter Stelle. Ein Angriff auf eines dieser Schutzziele kann dazu führen, dass essentielle Funktionen der Automatisierungslösung, einschließlich Sicherheits- und Steuerungsfunktionen, nicht mehr gewährleistet sind.
In besonders kritischen Fällen kann dies sogar Menschenleben gefährden. Im Gegensatz zu einem Cyber-Angriff in der reinen IT, bei dem das Hauptziel in der Regel Daten sind, kann ein cyberphysischer Angriff eine Anlage auch physisch zerstören. Eine weitere Herausforderung im industriellen Umfeld ist die deutlich längere Lebensdauer von Anlagen und deren Komponenten im Vergleich zur IT. Es ist keine Seltenheit, dass Komponenten in Anlagen 30 Jahre und älter sind. Zum Vergleich: Firmennotebooks und die darauf installierte Software werden oft schon nach drei Jahren ausrangiert.
Der Standard ISA/IEC 62443 „Security for Industrial Automation and Control Systems“ wird in Zusammenarbeit der Institutionen ISA (International Society for Automation) und IEC (International Electrotechnical Commission) entwickelt und veröffentlicht. Die IEC 62443 besteht aus mehreren Teilen, die in Abschnitte unterteilt sind. Zum Beispiel gibt es den Teil 4-1 (oder 62443-4-1), der zum Abschnitt 4 gehört. Bild 1 verdeutlicht die Zusammenhänge zwischen den verschiedenen Teilen der IEC 62443.
Bild 1: Zusammenhänge der IEC-62443-Teile.
Die Norm IEC 62443 besteht aus verschiedenen Abschnitten, die für unterschiedliche Akteure relevant sind. In Abschnitt 1 werden allgemeine Informationen bereitgestellt. Betreiber von Automatisierungslösungen finden hauptsächlich in Abschnitt 2 relevante Informationen für sich. Abschnitt 3 richtet sich an Integratoren, die Komponenten in bestehende Anlagen einbauen oder neue Anlagen zusammenstellen. Abschnitt 4 ist für Komponentenhersteller von Anlagen von Bedeutung.
Hersteller, Integratoren oder Betreiber können ihre Komponenten oder Anlagen gemäß bestimmten Teilen der Norm zertifizieren lassen. Aktuell wird eine einheitliche Bewertungsmethodik für die Zertifizierung in Abschnitt 6 erarbeitet. Abschnitt 5 ist für die sogenannten Profile reserviert, die bestimmte Normteile für spezifische Anwendungsbereiche anpassen. Im letzten Teil des Artikels werden wir noch einmal genauer auf den Gedanken der Profile eingehen.
Trotz der verschiedenen Teile der Norm gibt es einige zentrale Konzepte, die übergreifend gelten. Eines davon ist das Konzept der Defense-in-Depth, bei dem Sicherheit auf allen Ebenen des Systems durchdacht und umgesetzt wird, ähnlich wie bei einer mittelalterlichen Burg. Dabei ist es wichtig, das betrachtete System (System under Consideration) genau zu analysieren. Es werden Zonen definiert, die als vertrauenswürdig angesehen werden, sowie Übergänge (Conduits) zu anderen Zonen.
Jede Zone wird mit einem Security Level versehen. Die Definition von Security Level wird später erläutert. Darüber hinaus ist Sicherheit nur dann möglich, wenn sie fest in die bestehenden Unternehmensabläufe integriert oder neue Prozesse dafür etabliert werden. Zum Beispiel bedeutet dies bei der Produktentwicklung, dass Sicherheit in allen Phasen – vom Design über die Implementierung und Tests bis hin zur Aktualisierung – berücksichtigt wird. Dieses Konzept wird als Security Development Lifecycle (SDL) bezeichnet und findet sich auch im Titel der Norm IEC 62443-4-1 wieder: „Anforderungen an den Lebenszyklus für eine sichere Produktentwicklung“.
Um die entwickelten Komponenten gemäß den zentralen Konzepten einheitlich und vergleichbar bewerten zu können, sind Evaluationsmethoden wichtig. Aktuell wird der Teil IEC 62443-6-2 entwickelt, der ein Vorgehensmodell und Bewertungskriterien für Komponenten enthalten wird. Das Vorgehensmodell basiert auf den prozeduralen und technischen Anforderungen aus den Teilen IEC 62443-4-1 und IEC 62443-4-2, die im Folgenden genauer erläutert werden.
Ein näherer Blick auf den Hersteller-Abschnitt
Der Teil 4-1 der Norm IEC 62443 enthält mehrere Ansätze (Practices) für Hersteller von Komponenten, um eine Defense-in-Depth-Strategie umzusetzen. Diese Practices umfassen insgesamt 47 Anforderungen, die sich auf verschiedene Entwicklungsstufen/Lebensabschnitte einer Komponente beziehen, wie zum Beispiel Produktanforderungen, Entwurf, Implementierung, Verifikation und Validierung, Problembehandlung und Updates. Dabei wird der SDL-Gedanke betont, also die Berücksichtigung von Cybersicherheit über den gesamten Lebenszyklus hinweg. Es wird erwartet, dass Prozesse vorhanden sind oder angewendet werden, um diese Anforderungen zu erfüllen.
Eine der Anforderungen besteht darin, eine Bedrohungsmodellierung durchzuführen. Dieser Prozess umfasst die Analyse des Systems, die Identifikation von Bedrohungen und die Festlegung von Schutzmaßnahmen. Dieser Zusammenhang wird in Bild 2 gezeigt.
Bild 2: Mögliche Phasen einer Bedrohungsmodellierung.
In der Praxis treten Schwierigkeiten häufig bereits in der ersten Phase auf, da eine umfassende Beschreibung des Systems mit allen Informationsflüssen, Vertrauensgrenzen, Schnittstellen, Protokollen etc. selten im Voraus vollständig dokumentiert ist. Daher sind Abstimmungen mit Entwicklern oder Produktmanagern erforderlich, um diese Informationen zu erhalten.
Für den zweiten Schritt, das Auffinden von Bedrohungen, kann die STRIDE-Methodik verwendet werden. STRIDE steht für:
- Spoofing (Identitätsverschleierung)
- Tampering (Manipulation)
- Repudiation (Verleugnung)
- Information disclosure (Preisgabe von Informationen)
- Denial of service (Verweigerung des Dienstes)
- Elevation of privilege (Rechteausweitung)
Für jede Schnittstelle werden mithilfe der STRIDE-Methodik mögliche Bedrohungen identifiziert. Diese Methode ermöglicht eine systematische Herangehensweise an die Bedrohungsanalyse und hilft dabei, die Sicherheitsrisiken zu erkennen und angemessene Schutzmaßnahmen zu entwickeln.
Im letzten Schritt der Bedrohungsmodellierung werden Maßnahmen ermittelt, die einen Schutz vor den identifizierten Bedrohungen bieten können. Es ist auch möglich, eine Risikobewertung in die Bedrohungsmodellierung einzubeziehen. Sowohl die möglichen Bedrohungen als auch das zu ermittelnde Risiko können stark von der Anwendungsumgebung abhängen. Zum Beispiel ist bei einer kompromittierten Steuerungskomponente in einem Atomkraftwerk ein höheres Risiko anzunehmen als bei derselben Steuerung, die das Licht im Smarthome ein- und ausschaltet.
Die Bedrohungsmodellierung ermöglicht eine umfassende Betrachtung potenzieller Gefahren und unterstützt die Entwicklung geeigneter Sicherheitsmaßnahmen. Indem sowohl die Bedrohungen und das Risiko bewertet werden, können angemessene Schutzvorkehrungen ergriffen werden, um die Sicherheit der Automatisierungstechnik zu gewährleisten.
Die Durchführung einer Bedrohungsmodellierung muss als etablierter Prozess in jedem Produktentwicklungszyklus stattfinden. Es müssen entsprechende Prozesse entwickelt werden, um sicherzustellen, dass die Cybersicherheit kontinuierlich während der Entwicklung berücksichtigt wird. Dieser Prozessansatz ist entscheidend, da nachhaltige Cybersicherheit nur erreicht werden kann, wenn wiederholbare Routinen etabliert werden, anstatt sich auf einmalige Zielerreichung zu verlassen.
Der Teil 62443-4-2 enthält technische Sicherheitsanforderungen für Komponentenhersteller und baut auf dem Teil 62443-4-1 auf. Diese Anforderungen werden hauptsächlich in Component Requirements (CR) und Requirement Enhancements (RE) sowie Common Component Security Constraints (CCSC) beschrieben. CCSC sind allgemeine Anforderungen, die für alle Komponenten gelten. Die CR und RE ergänzen sich gegenseitig, wobei ein bestimmtes CR durch ein oder mehrere RE erweitert wird. Der Bezug zu den Security Levels (SL) zeigt, wie die Anforderungen durch zusätzliche RE erhöht werden (Bild 3). Der Security Level drückt aus, welches Sicherheitsniveau für eine bestimmte Anforderung gefordert wird.
Bild 3: Mapping von CRs und REs zu FR SL Levels 1-4
In der praktischen Anwendung hat sich gezeigt, dass es unterschiedliche Interpretationen der CR und RE gibt. Wenn Produkte häufiger nach den Normanforderungen zertifiziert werden, wird es wichtiger, dass die Anforderungen verifizierbar sind. Es wurde festgestellt, dass dies in der Praxis oft nicht der Fall ist. Das Ziel des neuen Teils IEC 62443-6-2 besteht darin, diese Lücke zu schließen und ein Vorgehensmodell sowie Bewertungskriterien für Komponenten bereitzustellen.
Teletrust Use Cases als wichtige Normergänzung
In der Anwendung des Standards IEC 62443 besteht das Problem, dass Komponenten für einen offenen Markt entwickelt und vertrieben werden, während Anlagenbauer konkrete Lösungen für verschiedene Szenarien benötigen und dafür Komponenten einsetzen. Sowohl aus Sicht des Herstellers als auch des Anlagenbauers sind Sicherheitsaspekte relevant, da der Hersteller Sicherheitsfähigkeiten liefert, die der Anlagenbauer benötigt. Die grobe Struktur der IEC 62443 ermöglicht jedoch keine detaillierte Abbildung dieser Realität. Mit der Norm lassen sich Sicherheitsfähigkeiten nur durch CRs, REs und/oder Security Levels beschreiben.
Der Bundesverband IT-Sicherheit e.V. (TeleTrusT) hat einen Lösungsansatz entwickelt. In der Arbeitsgruppe „Smart Grids/Industrial Security“ wurden sogenannte IEC 62443-4-2 Use Cases erstellt. Diese Use Cases sind einheitlich strukturiert und beginnen mit der Beschreibung eines typischen Einsatzszenarios für einen Komponenten- oder Produkttyp. Die Use Cases ermöglichen die Definition eigener Stufen von CRs und REs, die sich an den Security Levels orientieren sollen. Dabei werden spezifisch relevante Sicherheitsanforderungen
(CRs und REs) ausgewählt.
Darüber hinaus enthalten die Use Cases weitere praxisrelevante Informationen zu den Komponententypen. Bisher hat TeleTrusT drei Use Cases veröffentlicht. Sie sind unter folgendem Link abrufbar: https://www.teletrust.de/publikationen/teletrust-iec-62443-4-2/
Ein Beispiel für einen Use Case ist die Industrial Firewall. Wie in Bild 4 gezeigt, dient eine Industrial Firewall entweder dazu, die Kommunikation zwischen Zellen zu ermöglichen und abzusichern oder die Kommunikation zwischen einer Zelle und einer Workstation zu realisieren. Aus dem Use Case geht implizit hervor, dass keine ITNetz-Firewall beschrieben wird.
Die Use Cases haben das Ziel, die Kommunikation zwischen Maschinenbauern, Anlagenbetreibern, Herstellern von Automatisierungstechnik und Einkäufern zu fördern. Sie dienen als Referenz für die Beschaffung und Bewertung von Komponenten. Die Struktur der Use Cases kann auch genutzt werden, um Komponententypen und den Sicherheitsbedarf abzugrenzen. TeleTrusT hat dafür auch ein leeres Use Case Template veröffentlicht.
Die TeleTrusT IEC 62443-4-2 Use Cases weisen bereits eine starke Überlappung mit dem in Arbeit befindlichen Profilschema der IEC 62443-Serie auf, das voraussichtlich als Teil IEC 62443-1-5 veröffentlicht wird. Das Profilschema enthält Regeln zur Beschreibung von Profilen und wird etwas weniger Flexibilität bieten als die Use Cases.
Dennoch ist geplant, dass die bestehenden Use Cases nach Verfügbarkeit des Profilschemas angepasst und erneut im Einklang mit diesem veröffentlicht werden.
Bild 4: Typisches OT-Netzwerk
Luise Werner ist SDL Expertin und Industrial Security Spezialistin für IEC 62443 bei der secuvera GmbH.
Sebastian Fritsch ist Leiter der Prüfstelle für IT-Sicherheit bei der secuvera GmbH und IEC-Projektleiter für die neue IEC 62443-6-2.