Grundlagen der IEC 62443 – ein Überblick für Produkthersteller
Nach dem Trend zur Vernetzung in der Automatisierungstechnik hat sich mittlerweile auch ein Standard für die Umsetzung von Industrial Security durchgesetzt, um diese vernetzten Anlagen heute und zukünftig sicher zu betreiben. Hierbei handelt es sich um den Standard IEC 62443 „IT-Sicherheit für industrielle Automatisierungssysteme“.
Entsprechend der typischen Rollenaufteilung in der Automatisierungstechnik unterscheidet die Norm in Anlagenbetreiber, Installations-/Service-Integratoren sowie Hersteller von Komponenten. Diese Aufteilung in die verschiedenen Rollen und Verantwortlichkeiten schlägt sich in der Struktur dieses mehrteiligen Standards wieder. Während Abschnitt 1 die Grundlagen und Begriffe beschreibt, werden im Abschnitt 2 Anforderungen an Betreiber und Betrieb gestellt. Im Abschnitt 3 werden Anforderungen an die Anlage als Ganzes in den Fokus genommen, der Abschnitt 4 definiert abschließend noch Anforderungen an Hersteller und die Komponenten selbst.
In dieser und der folgenden Ausgabe der GIT SICHERHEIT soll die Normreihe IEC 62443 aus Sicht der Produkthersteller näher beleuchtet werden: Welche Vorgaben macht die Normreihe? Worauf ist aus Herstellersicht besonders zu achten? Welche Parameter müssen erfüllt sein, um ein Produkt secure-by-design zu entwickeln? Der erste Teil befasst sich dabei mit den Grundlagen der IEC 62443. Der zweite Teil in der kommenden Ausgabe beleuchtet hingegen detailliert die sogenannten acht Practices der Normreihe.
Die Risikoanalyse
Um sich die Normreihe IEC 62443 zu erschließen, empfiehlt es sich auf den Blickwinkel einer Rolle zu fokussieren, wir sprechen im Weiteren von einer Vorgehensweise. Dieser Artikel beschäftigt sich primär mit der OT Security bei Produktherstellern und Komponenten. Dementsprechend nehmen wir ab dem folgenden Absatz die Rolle des Herstellers ein. Zuvor setzen wir aber noch kurz den Hut des Anlagenplaners auf und stellen uns die Frage, wie der Bezug zu Sicherheit von Komponenten ist. Die Vorgehensweise zur Anlagenplanung – Abschnitt 3 der IEC 62443 – beginnt mit einer Risikoanalyse der geplanten Anlage, dem System-under-consideration.
Dabei wird die Anlage in unterschiedlich kritische Bereiche eingeteilt. Hierbei spricht man von der Zonierung. Dies führt zum einen zu Änderungen im Kommunikationsdesign und gleichzeitig werden für die Zonen der Anlage Security Level (SL) definiert, d. h. das im Bereich oder Netzsegment zu erreichende Security-Niveau wird festgelegt.
Nachdem diese Schritte erfolgt sind, kann das geforderte Security Level auf die vorgesehenen Komponenten projiziert werden. Wie diese Projektion oder Zuordnung erfolgen kann, ist eine der schwierigen Interpretationsfragen bei der Nutzung der Norm.
Security Level der Komponenten
Hersteller von Komponenten sind Zulieferer von Automatisierungsanlagen. Die Summe der Komponenten sowie deren Zusammenschaltung und Programmierung machen eine Automatisierungsanlage aus. In der Regel werden Komponenten für verschiedene Anwendungsfälle entwickelt, um damit eine relevante Stückzahl erreichen zu können.
Ein Hersteller, der ganz bewusst Security-Eigenschaften realisiert, muss sich auch die Frage stellen, welche der verschiedenen möglichen Eigenschaften die Komponente benötigt. Die IEC 62443 definiert hierzu den Begriff der Component Requirements (CR), diese beschreiben standardisiert Security-Eigenschaften. Weiter definiert der Standard die Menge von CRs als Security Level. Dies sind die gleichen Security Level wie bei der Anlagenplanung. Der Standard definiert hierzu vier Security Level, wobei bisher in der Praxis hauptsächlich die drei Stufen SL-1 bis SL-3 eine Anwendung finden.
Um zu entscheiden, welches Security Level oder Security-Eigenschaften eine Komponente enthalten soll, muss ein Hersteller den Bedarf an Security von seinem Zielmarkt gut kennen, also den Security-Bedarf zukünftiger Anlagen. Dies bedeutet für das Produktmanagement, dass eine entsprechende Analyse durchgeführt werden muss.
Der sichere Entwicklungsprozess – Secure-by-design
Neben der Definition welche Security-Eigenschaften eine Komponente realisieren soll, ist ein Hersteller bei der Nutzung der IEC 62443 verpflichtet einen sicheren Entwicklungsprozess (SDL – Security Development Lifecycle) zu etablieren. Durch die Implementierung eines solchen Entwicklungsprozesses wird Security-by-design in der Entwicklung gefordert.
An diesem Punkt kommt die IEC 62443-4-1 ins Spiel: Die Norm besteht aus 47 Anforderungen, die in 8 thematisch abgegrenzte Bereiche, sogenannte Practices, gegliedert sind. Von Practice 1 („Security Management“) und Practice 8 („Security Guidelines“ oder Handbücher) abgesehen, folgt die Aufteilung einem klassischen Entwicklungsmodell:
- Anforderungen (Practice 2 – „Specification of security requirements“)
- Design (Practice 3 – „Secure by design“)
- Implementierung (Practice 4 – „Secure implementation“)
- Testing (Practice 5 – „Security verification and validation testing“)
- Fehler Management (Practice 6 – „Management of security related issues“)
- Umgang mit Updates (Practice 7 – „Security Update Management“)
Auch, wenn die Norm in ihrer Aufteilung einem Standard-Entwicklungsmodell folgt, so gibt sie kein Entwicklungsmodell direkt vor. Sie lässt sich gleichermaßen in Verbindung mit klassischen Entwicklungsmodellen (z. B. Wasserfall, V-Modell) und mit agilen Entwicklungsmodellen (z. B. SCRUM) einsetzen. Dies gelingt der Norm, indem sie dem Anwender Freiheitsgrade lässt und eine prozedurale Umsetzung fordert.
Umgekehrt bedeutet dies, es werden an keiner Stelle konkrete technische Maßnahmen gefordert. Beispielsweise verpflichtet die Norm den Anwender dazu, eine Bedrohungsmodellierung durchzuführen (gefordert in Practice 2), wie und mit welcher Methodik dies geschieht, wird komplett dem Anwender überlassen.
