Um ganzheitliche OT-Security gewährleisten zu können, müssen die drei zentralen Rollen einer Automationslösung (Betreiber, Integrator, Hersteller) mit einbezogen werden. Anhand dieser Rollen werden auch die zentralen Vorgehensweisen zur Nutzung der Norm abgeleitet. Nacheinander stellen wir diese im Folgenden vor.
Vorgehensweise Integrator
Die Vorgehensweise für die Perspektive eines Integrators, der die Aufgabe hat, eine bestehende Anlage weiterzuentwickeln (Brownfield) oder eine neue Anlage zu planen (Greenfield) startet jeweils mit einer Risikoanalyse. Basierend auf den Ergebnissen zur Gesamtanlage wird entsprechend der Bewertung (primär des festgestellten Risikos) zum einen eine Zonierung auf Systemebene durchgeführt und zum anderen Maßnahmen abgeleitet, welche sowohl technischer als auch organisatorischer bzw. personeller Natur sein können. Diesen Zwischenschritt könnte man als Sicherheitskonzept für die Anlage bezeichnen.
Das Herunterbrechen von technischen Systemmaßnahmen auf Komponentenmaßnahmen von existierenden oder noch zu entwickelnden Komponenten ist der dann folgende nächste Schritt. Hierbei kann es sein, dass nicht alle technischen Maßnahmen tatsächlich umgesetzt werden können. Alternativ sollte man in diesen Fällen organisatorische Prozesse als kompensierende Ersatzmaßnahmen definieren.
Diese Vorgehensweise der Norm entspricht einem Top-Down-Ansatz und kann somit, ausgehend von der Gesamtanlage, nach und nach auf die einzelnen Komponenten heruntergebrochen werden. Eine Schwäche der beschriebenen Vorgehensweise der Norm ist, dass Schritte teilweise offengelassen werden und damit für Anwender schwer umsetzbar sind. Es fehlen konkrete Hinweise darauf, wie man beispielsweise auf Grundlage der Risikoanalyse eine Zonierung durchführen kann oder welche SL-Stufen typischen Skalen aus anderen Sicherheitsstandards zuzuordnen sind. Dies macht die Anwendung der Norm für Integratoren schwierig, insbesondere da die Norm so von Anwendern jeweils anders genutzt wird. (Vorgehensweise basierend auf: IEC 62443-3-2 (Entwurf)/-3-3/-4-2)
Vorgehensweise Hersteller
Zulieferer von Automatisierungsanlagen, die Hersteller von Komponenten, folgen in der Regel einer anderen Vorgehensweise. Hier stellt sich nicht die Frage nach spezifischen Sicherheitsleistungen für eine abzusichernde Umgebung oder eine Art von Automationslösung (wie ein Blueprint). In der Regel werden Komponenten für verschiedene Anwendungsfälle entwickelt, um damit auch eine relevante Produktstückzahl erreichen zu können. Dies führt dann aber zu der erweiterten Fragestellung, welche Security-Maßnahmen und -Resistenz, ausgedrückt durch das Security Level (SL), für die Komponente erreicht werden muss. Diese Frage ist nicht einfach zu beantworten, denn unterschiedliche Einsatzbereiche werden zu unterschiedlichen Anforderungen kommen. Man kann jedoch annehmen, dass insbesondere die unteren drei Stufen (SL-1 bis SL-3) häufig angesetzt und somit eine hohe praktische Relevanz erreichen werden. Vermutlich werden Komponenten-Hersteller nicht einzelne Component Requirements (CR) wählen, da diese Strategie eher aus Sicht der Systemplanung (siehe erste Vorgehensweise des Integrators) angewendet wird.
Neben der notwendigen Wahl von Security Requirements mit SL-Stufe sind Komponenten-Hersteller bei Nutzung der Norm verpflichtet einen „sicheren“ Entwicklungsprozess (einen SDL – Security Development Lifecycle) zu etablieren. Durch die Implementierung eines solchen Entwicklungsprozesses werden die wichtigsten Prozess-Anforderungen bereits in der Entwicklung gefordert, ein zentraler Anspruch ist hier die Durchführung von Security Updates der jeweiligen Komponenten. Diese Vorgehensweise ist dadurch geprägt, dass eine fundierte Auswahl einer SL-Stufe zu treffen ist. Hierzu muss der Hersteller das Security-Bedürfnis seines Zielmarktes gut kennen, was für das Produktmanagement bedeutet, dass dieses eine entsprechend gute Analyse durchführt, und dann eine Entscheidung getroffen werden muss. (Vorgehensweise basierend auf: IEC 62443-4-1/-4-2)
Vorgehensweise Betreiber
Die dritte Vorgehensweise betrifft den Betreiber und somit die Aufrechterhaltung und kontinuierliche Bewertung der effektiven Security einer industriellen Anlage im laufenden Betrieb. Nach ersten verworfenen Konzepten in der IEC 62443 ist aktuell geplant, den Begriff des „Security Program“ (SP) in der Norm einzuführen. Hierbei handelt es sich um die Kombination von technischen und organisatorischen Anforderungen, welche über SP Elements (z. B. „SPE 3 – Network and communications security“) und darunter Security Control Classes (SCC, z. B. „SCC NET 1: System segmentation“), definiert werden. Unterhalb von SCCs finden sich Detailanforderungen. In Ergänzung verweisen alle Detailanforderungen auf bestehende Standards (wie u.a. die ISO 27001) bzw. Normteile der IEC 62443, um so inhaltliche Redundanzen zu vermeiden.
Ergänzend zum Konzept des Security Program definiert der letzte Entwurf des Normteils IEC 62443-2-2 die sogenannten Protection Level (PL). Dieses Konstrukt ermöglicht eine Art Messung, welchen kombinierten Bewertungswert eine Automatisierungsumgebung hinsichtlich der erreichten OT-Security inne hat. Es werden zum einen technische Anforderungen (z. B. die Component Requirements (CR) entsprechen Normteil 4-2) aber auch organisatorische Anforderungen (z. B. Kompetenz von Integratoren nach Normteil 2-4) definiert. Bei der Erfassung des Status der Protection Level muss eine Bewertung pro Detailaspekt vorgenommen werden. Daraus wird entsprechend einem beschriebenen Vorgehensmodell ein Gesamtwert oder ein Wert für einen Teilbereich (in der Regel nach einer SCC, siehe vorheriger Absatz) gebildet. Mit diesem Ansatz lässt sich der aktuelle OT-Security-Status einer betriebenen Anlage „messen“. Diese Methode kann sowohl für die Ersterfassung, als kontinuierliche Prüfung oder auch als externe Audittechnik genutzt werden. Die beiden Entwürfe der Normteile 2-1 und 2-2 nutzen ein identisches Vokabular. (Vorgehensweise basierend auf: IEC 62443-2-1/-2-2)
Zusammengefasst steckt hinter den beiden Normteilen zur Betreiberperspektive die Vorgehensweise zur Etablierung, Aufrechterhaltung und kontinuierliche Statuserfassung eines Security Programs. Die Bewertung von organisatorischen Anforderungen erfolgt mit einem Reifegrad, wo hingegen die Bewertung der technischen Anforderungen der Standard generell offen lässt. Und genau hierfür kann das TeleTrusT-Prüfschema genutzt werden, welches im dritten Teil der Serie vorgestellt wird.
Bekannte Schwächen der Norm
Die oben beschriebenen Vorgehensweisen kann man zwar inhaltlich in der Norm finden, sind aber nicht explizit beschrieben. Diese ergeben sich auch erst oft, wenn mehr als ein Normteil in den Fokus genommen wird. Vorgehensweisen oder Konzepte der Norm werden aktuell nicht eindeutig in dieser erklärt. Dies ist ein deutlicher Nachteil. Man kann sich zwar viel Wissen über die Ideen der Norm mit Diskussionen erarbeiten, was aber natürlich nicht skaliert und damit de-facto viele Anwender vom Standard fernhält.
Obwohl viele Normteile in den letzten Monaten fertiggestellt wurden, existieren immer noch einige Teile, dessen finaler Abschluss noch offen steht. Insbesondere die Vorgehensweisen zum Security Program beim Betreiber sind aktuell noch in Arbeit und werden regelmäßig überarbeitet. Damit muss bis heute festgehalten werden, dass eine erste komplette Stabilität der Norm immer noch aussteht.
Empfehlungen
Aber trotz aller Probleme und Hindernisse, ist die Nutzung der Norm als Vorgehensweisen für die jeweiligen Rollen die wesentliche Stärke der Norm. Diese ist ein ganzheitlicher Ansatz und kein Stückwerk. Es wird sowohl das zu entwickelnde oder bereits betriebene System angesprochen als auch die Komponenten, aus denen sich dieses System zusammensetzt.
Es wäre wünschenswert, wenn diese integrierte, ganzheitliche Sicht nicht nur implizit in der Norm enthalten ist, sondern auch zeitnah explizit von Anwendern nachgelesen werden kann und am besten in der Norm selbst erklärt wird.
Hersteller von Komponenten, welche mit der Norm praktisch umgehen müssen, erhalten mit dem TeleTrusT-Prüfschema für IEC 62443-4-2 weitere Hinweise als Ergänzung zur Norm selbst. Das Prüfschema wird in diesem Artikel vorgestellt.
IEC 62443 Guide: Besser diskutieren mit Herstellern
CEO & Founder
Die IEC 62443 nimmt weiter mehr Fahrt auf und wird immer öfters auch von Herstellern, Lieferanten und auch Betreibern referenziert.
In unserem Guide helfen wir Ihnen als Betreiber, wie sie die IEC 62443 zur besseren Diskussion mit Ihren Lieferanten und Komponentenherstellern nutzen können.
