Die Steuerung Saia PCD3.M6893 bietet neben höchster Cybersecurity auch die Möglichkeit zur objektorientierten Hochsprachenprogrammierung. (Quelle: Saia Burgess Controls)
Herr Greune, in der Industrie wächst der Bedarf an vernetzten Systemen. Gleichzeitig steigen die Anforderungen an Cybersecurity. Wie gelingt es Saia Burgess Controls, beides in Einklang zu bringen, ohne die Flexibilität der Anlagen zu verlieren?
O. Greune: Das lässt sich nicht in einem Wort beantworten: Cybersecurity beginnt nicht erst bei der Steuerung, sondern beim Grundkonzept. Entscheidend ist, dass Betreiber und Planer Security von Anfang an gemeinsam denken: Dabei definiert der Betreiber, welche Sicherheitsstufen erreicht werden sollen und wo die Schwerpunkte liegen. Darauf aufbauend erarbeiten Planer und Betreiber ein Sicherheitskonzept, das idealerweise dem Zonenprinzip mit klaren Funktionen je Zone folgt.
In der Umsetzung arbeiten dann Systemintegrator und Hersteller zusammen – und hier kommen wir ins Spiel. Ziel ist es, essenzielle Zonen sauber zu kapseln, also außen eine klar kontrollierte Schnittstelle, darunter ein lokales Netz für die Zonenautomation.
Technisch heißt das auch, dass eine Steuerung in der Regel mindestens zwei physikalisch getrennte Netzwerke unterstützen sollte: eines für Management/übergeordnete Systeme und eines für die lokale Automation. So können Sensoren, Feldgeräte und lokale Visualisierung in der Zone im Zweifel weiterlaufen, ohne dass die Anlagenfunktion durch Ereignisse aus der übergeordneten Vernetzung beeinträchtigt wird.
Es wird also deutlich, dass Cybersecurity nichts ist, was man wie ein Produkt kaufen kann. Cybersecurity muss vielmehr im Verbund von Betreibern, Planern, Systemintegratoren und Herstellern gelebt und immer wieder nachjustiert werden. Gemeinsam muss über den gesamten Lebenszyklus hinweg immer wieder geprüft werden: Sind die ursprünglichen Konzepte noch zielführend oder müssen sie angepasst werden usw.?
Ihre Steuerungen gelten als besonders sicher und erfüllen die Anforderungen nach IEC 62443. Wie wird Sicherheit in Ihrem Unternehmen schon in der Entwicklung und im Systemdesign mitgedacht, damit sie eben später keinen Zusatzaufwand verursacht?
O. Greune: Wir haben bereits 2017 damit begonnen, Security konsequent in Entwicklung und Systemdesign zu verankern. Ziel war von Anfang an, eine Steuerung zu entwickeln, die intrinsisch sicher ist – also kein System, das später mit Zusatzmaßnahmen gehärtet werden muss.
Heute sind wir ein Stück weit stolz darauf, dass wir mit unseren Steuerungen eine IEC-62443-Zertifizierung auf Maturity Level 3 erreicht haben. Wer die Norm kennt, weiß: Die Levels beschreiben, gegen welche Angreifertypen ein System ausgelegt ist. Und der Schritt von Maturity Level 2 – heute vielfach marktüblich – zu Maturity Level 3 ist in der Praxis ein deutlicher Sprung. Das gilt vor allem in der Tiefe der Anforderungen.
Technisch bedeutet Level 3: Sicherheit lässt sich nicht mehr „hier und dort“ per Software ergänzen. Das gesamte Gerät muss von Grund auf entsprechend konzipiert sein, inklusive Hardware-Security-Bausteinen wie kryptografischen Chips, klaren Speicher- und Rechtekonzepten sowie physikalisch getrennten Speicherbereichen. Auch intern müssen Zugriffe sauber geregelt sein; es darf keine unnötigen Rechte oder „Abkürzungen“ geben.
Ein zentraler Baustein ist zudem eine Chain of Trust im Firmware- und Update-Prozess. So muss die Steuerung verifizieren können, dass Firmware – und je nach Architektur auch Applikationsbestandteile – aus einer vertrauenswürdigen Quelle stammen. Insgesamt reicht das sehr tief in Architektur, Tool-Chain und Prozess hinein.
Warum sind regelmäßige Software-Updates und eine klare Dokumentation der eingesetzten Komponenten – Stichwort Software Bill of Materials – heute so wichtig und wie unterstützen Sie Ihre Kunden, diese Prozesse einfach umzusetzen?
O. Greune: Weil Security kein Zustand ist, sondern ein permanenter Wettlauf. Ich vergleiche das gern mit „Tom & Jerry“: Es gibt immer Akteure, die Schwachstellen suchen, ob aus krimineller Absicht (Störung oder Stillstand einer Anlage) oder schlicht aus Ehrgeiz. Entsprechend werden Lücken in Betriebssystemen, Browser-Komponenten, Protokollen oder Bibliotheken irgendwann öffentlich. Als Hersteller müssen wir reagieren und diese Schwachstellen schließen. Genau deshalb sind regelmäßige Updates so wichtig.
In der Industrie ist das vor allem in kritischen Anlagen nicht mit der IT-Welt vergleichbar. Sie können nicht einfach „mal schnell“ ein Update einspielen und sind zwei Minuten später wieder online. Updates müssen geplant, getestet und in Wartungsfenster integriert werden. Genau hier wird Transparenz zum entscheidenden Hebel: Der Betreiber braucht klar nachvollziehbare Informationen darüber, was geändert wurde, welches Risiko adressiert wird und wie dringend ein Update ist. Deshalb legen wir großen Wert auf saubere Release Notes und eine verständliche, belastbare Kommunikation: Welche Schwachstelle ist bekannt? In welcher Version ist sie geschlossen? Welche Auswirkungen sind zu erwarten? Erst dann kann der Kunde entscheiden, ob ein Update für seine Umgebung relevant ist und ob es sofort notwendig ist oder im nächsten geplanten Wartungsfenster erfolgen kann.
Damit sind wir beim zweiten Punkt, der Dokumentation der eingesetzten Komponenten, also Software Bill of Materials. Wenn der Betreiber weiß, welche Softwarebausteine in welcher Version in einem System vorliegen, kann er Risiken überhaupt erst sauber bewerten und priorisieren.
Und weil kritische Anlagen nicht beliebig lange einem hohen Risiko ausgesetzt werden können, gehören zu einem pragmatischen Update-Konzept auch betriebliche Maßnahmen. Dazu kann es gehören, temporär Netzwerkverbindungen zu reduzieren, Segmente abzutrennen oder die Kommunikation zu übergeordneten Systemen einzuschränken, bis das geplante Update eingespielt werden kann.
Unterm Strich heißt das: Updates sind Pflicht, aber planbar. Voraussetzung dafür sind Transparenz, belastbare Release Notes und eine saubere Komponentendokumentation. Dann können Betreiber Wartung und Risikomanagement in Einklang bringen, ohne den Betrieb unnötig zu stören.