Die Bedeutung von OT-Security im Automationskontext nimmt zu, sowohl aufgrund von ernstzunehmenden Security Vorfällen (z. B. Ransomware) als auch durch zunehmende Regulierung (z. B. EU Cybersecurity Act (CSA)). Man kann dem Thema zwar vielleicht noch aktuell aus dem Weg gehen, aber jedes Projekt, sei es vor oder nach der Inbetriebnahme, wird davon zeitnah eingeholt. Daher werden bereits in der Projektanbahnung immer häufiger folgende Fragen gestellt:
- Was ist eine belastbare und nachhaltige Vorgehensweise für OT-Security?
- Wie kann man nachweisen, dass die Verantwortlichen ihrer Pflicht nachgekommen sind?
- Wie sollte man mit den sich ständig ändernden Parametern und Angriffsvektoren umgehen?
- Gibt es Maßnahmen, die unabhängig vom Szenario immer umgesetzt werden müssen?
- Zudem stellt sich die Frage, wie eine Priorisierung von Maßnahmen überhaupt erfolgen kann.
Ganzheitlicher Ansatz
Security, egal ob im Kontext IT oder OT, kann entweder mit punktuellen Einzelmaßnahmen oder aber ganzheitlich angegangen werden. Ein ganzheitlicher Ansatz ist die bevorzugte Variante, da dieser auf einer spezifischen Risikoanalyse beruht, systematisch vorgeht und zusammenhängende Prozesse und Rollen miteinbezieht. Es stellt sich nur die Frage, was ein solcher „ganzheitlicher Ansatz“ wäre und wie erprobt solche Modelle sind?
Das bekannteste Modell zur ganzheitlichen OT-Security findet sich in der Norm IEC 62443. Die Norm stellt Automatisierungssysteme in den Fokus, wörtlich wird das IACS (Industrial Automation Control System) betrachtet. Damit geht die Norm sehr generell vor und erlaubt eine Anwendung für verschiedene Varianten in der Automatisierung, von der Fertigung über Gebäudeautomatisierung bis hin zu verteilten Versorgungssystemen. Eine Anlage (oder mit den Worten der Norm, ein „System“) kann dabei unterschiedlich groß und komplex sein. Die Norm stellt im Wesentlichen Vorgehensweisen bereit, welche die verschiedenen Rollen in der Automatisierung berücksichtigen und Methoden für die Umsetzung bereitstellen. Aktuell ist jedoch der konzeptionelle und didaktische Einstieg in die Norm für Anwender noch ein Problem. Daher sollen Artikel wie dieser beim Einstieg helfen. Weitere Informationen zum Aufbau und Struktur der finden Sie im Grundlagenartikel der IEC 62443.
Zentrale Konzepte
Anders als beispielsweise die ISO 27001 erfolgt in der IEC 62443 eine Differenzierung nach den typischen Rollen in der Automatisierung: der Hersteller, der Integrator und der Betreiber. Beispielsweise wird die Planung einer Anlage häufig durch einen Integrator durchgeführt. Dieser wird bei Anwendung der Norm dann seine bereits funktional konzeptionierte Anlage einer Risikoanalyse unterziehen. Diesem ersten methodischen Schritt folgen dann weitere, welche aus Sicht des Integrators dann in Auswahl und Security-Bewertung möglicher Komponenten für die Anlage münden. Diese sich aus der Norm implizit (aber häufig nicht explizit) ergebenden Schritte bezeichnen wir jeweils als Vorgehensweise. Diese werden im zweiten Teil der Serie noch detailliert für alle Rollen aufgeführt.
Die Methoden können hierbei sowohl auf Bestandsanlagen (Brownfield) als auch auf komplett neu designte Anlagen (Greenfield) angewendet werden.
Die weiteren Konzepte sind direkt in der Norm definiert und ziehen sich durch die verschiedenen Abschnitte der Norm. Zum einen wird das Defense in Depth Prinzip eingeführt, bei dem unterschiedliche Security-Schutzmaßnahmen mehrschichtig um die Anlage oder bestimmte Systembereiche aufgebaut werden. Im Ergebnis erreicht man mehrere nacheinander greifende Schutzmaßnahmen.
Beim Zones-and-Conduits Konzept, welches ebenfalls in der Norm direkt eingeführt wird, geht es um die Idee, dass Bereiche der Anlage aus Sicht der Kommunikation voneinander getrennt und nur noch explizite Datenflüsse ermöglicht werden.
Weiter werden in der Norm in allen Bereichen nicht nur die Technik sondern auch organisatorische Prozesse adressiert. Zum einen werden Anforderungen an die technischen Fähigkeiten (Capabilities) beschrieben (häufig in Zusammenhang mit Security Levels (SL)), zum anderen Prozesse und Praktiken vorgegeben.
Des weiteren wird ein starker Fokus auf den Entwicklungsprozess gelegt. Explizit bezieht die Norm dies auf Komponenten, eine Anwendung auf den Entwicklungsprozess der gesamten Anlage ist aber ebenso möglich und sinnvoll. Hier soll sichergestellt werden, dass Security-Maßnahmen bereits in der Entwicklung mitberücksichtigt werden.
Als letztes soll hier das polarisierende Konzept der Security Level genannt werden. Inhaltlich sind Security Level definiert als a) Mengen von Security Anforderungen und b) der Definition eines Angreifertyps. Zwar helfen die Security-Level dabei das Schutzniveau der Anlage zu kategorisieren und zu vereinfachen, häufig wird dabei jedoch auch eine differenzierte Betrachtungen bei der Auswahl effektiver Schutzmaßnahmen erschwert. Aus diversen Diskussionen ist zudem bekannt, dass SL-Stufen gerne im Marketing von Produkten genutzt werden, was mindestens zu hinterfragen ist.
Anwendung der Norm
Bis zu dieser Stelle wurde erläutert, dass die IEC 62443 eine sinnvolle Norm zur Umsetzung einer ganzheitlichen OT-Security ist. Zudem wurden die zentralen Konzepte und Ansätze vorgestellt. Um die Norm aber effektiv einsetzen zu können, ist es wichtig zu verstehen welche Vorgehensweisen für die verschiedenen Rollen (Hersteller, Integrator und Betreiber) bereitgestellt werden. Hierzu verweisen wir auf diesen Artikel.
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.
