Die Umsetzung der IEC 62443 ist kein leichtes Unterfangen. Herausforderungen liegen in der Nutzung einer gemeinsamen Sprache („Security Level“), der Auswahl des Standardteils (-3-3? -4-2? -4-1? ...) und der Interpretation (Wie viel ist unser physisches Schloss wert?).

Einige Branchen haben daher begonnen, sich Interpretationshilfen zu entwickeln, so z. B. der deutsche Maschinen- und Anlagenbau – oder auch der europäische Railway-Sektor mit der CENELEC TS 50701 („Railway applications –Cybersecurity“).

David Fuhr berichtet von Irrwegen, Fallstricken und Erfolgen in einem über ein Jahr lang dauernden Prozess mit dem Ziel, auf Basis dieses Bahn-Standards Teile der IEC 62443 „organisch“ in die Entwicklungsprozesse eines Integrators im Railway-Sektor einzubauen, sodass die richtigen Menschen zu den richtigen Zeitpunkten auf die richtige Art und Weise daran vorbeikommen.

Risiken der Lieferkette (Supply-Chain) sind ein Riesenproblem für Hersteller von Automatisierungstechnik. Wissen Sie, welche Software, Protokollstacks und Bibliotheken in Ihren OT-Systemen enthalten sind? Und – noch unangenehmer – welche Schwachstellen dort vielleicht schlummern?

Florian Lukavsky nähert sich dem Thema aus zwei Richtungen: Zuerst beleuchtet er, welche Anforderungen „die IEC 62443 für Hersteller“ (IEC 62443-4-1) an die Supply-Chain-Security stellt und wie Hersteller diese Anforderungen erfüllen können. Dann wird es praktisch: Wie erstellt man eigentlich eine Software Bill of Materials (SBOM)? Welche verschiedenen SBOM-Strategien gibt es? Und, noch wichtiger: Wie nutzt man eine SBOM gewinnbringend?

Bedrohungsszenarien für OT-Systeme entstammen oft vorgefertigten Katalogen und haben wenig mit den individuell zu schützenden Assets zu tun. Eine formale Vorgehensweise zur Auswahl und Begründung von Bedrohungsszenarien fehlt.

Eine Möglichkeit das Problem zu lösen ist STPA, STPA ist die Abkürzung für System-theoretic Process Analysis und wurde am MIT entwickelt. Es ist eine neue auf der Systemtheorie basierende Analysemethode für sicherheitskritische Systeme.

Florian Wagner, Stefan Suchi und Borislav Nikolov erklären, wie STPA für OT-Security angewandt werden kann: Schadensszenarien werden als ein Kontrollproblem gesehen, wenn Security-Randbedingungen nicht eingehalten werden. Eine unsichere Kontroll-Aktion („Ein Ventil wird nicht geöffnet, wenn der Druck im Kessel zu hoch ist“) gilt es zu verhindern, um Schadensszenarien zu vermeiden. Anschließend wird der Frage nachgegangen, wie diese unsicheren Kontroll-Aktionen durch Manipulation des Systems hervorgerufen werden könnten. Daraus werden die schützenswerten Assets identifiziert. Im Ergebnis erhält man eine schlüssige und rückverfolgbare Argumentation zwischen Schadenszenarien und Assets.

Für das Pentesting von Webanwendungen gibt es allseits anerkannte Standards wie die OWASP Top 10 oder den Web Application Testing Guide. Ähnliches gilt auch für mobile Applikationen, Desktop Apps und Programmierschnittstellen (APIs). Aber für OT finden sich wenig generische Methoden, nach denen man einen systematischen Pentest durchführen könnte.

Moritz Gruber präsentiert eine beispielhafte Lab-Umgebung für die Untersuchung von vernetzter Gebäudetechnik und zeigt, wie man diese testen kann und was typische Schwachstellen sind. Auf Basis dieser Beispiele leitet er Methoden ab, die für OT-Pentests über Gebäudeleittechnik hinaus verwendet werden können.

Es sagt sich so leicht: Die Remote-Kommunikation zwischen Feldgeräten und Leitsystem sollte verschlüsselt sein. Und wie verschlüsselt man? Klar, mit TLS (Transport Layer Security), dem wohl am häufigsten genutzten Protokoll für Verschlüsselung und gegenseitige Authentifizierung, das jeder aus dem Browser kennt, wenn er „https“ eintippt.

Sushil Siddesh berichtet anhand der Implementierung für den Endress+Hauser-Durchflussmesser Promag 800, dass der Teufel der TLS-Umsetzung im Detail steckt. Nicht zuletzt, weil für die Authentifizierung mit Zertifikaten eine PKI (Public Key Infrastructure) aufgebaut und betrieben werden muss, was in einer industriellen Automatisierungsumgebung eine besondere Herausforderung darstellt.

Digitale Maschinenidentitäten legen das Fundament für viele Security-Lösungen wie Authentisierung und Verschlüsselung. Kein Wunder, dass sie überall gefordert oder sogar vorausgesetzt werden: In der IEC 62443, dem IT-Grundschutz oder ICS-Security-Kompendium des Bundesamts für Sicherheit in der Informationstechnik (BSI) oder der OPC-Spezifikation, um nur einige Beispiele zu nennen.

Obwohl das Thema so grundlegend ist, ist seine Implementierung vor allem in der OT weder einfach noch selbstverständlich. Es gibt viele Stolpersteine: Wie können Zertifikate über den Lebenszyklus verwaltet werden? Wie schafft man einen Zugang zum Thema Identitäten, ohne PKI-Spezialist zu sein? Wie sieht es mit Legacy-Hardware aus? Wie fügen sich digitale Identitäten in die Verwaltungsschale ein?

Florian Handke zeigt praktische Herausforderungen und mögliche Lösungen rund um das Thema digitale Identitäten in der OT.

Functional Mockup Units (FMUs) sind dynamische Systemmodelle, die mit dem offenen Standard FMI (Functional Mockup Interface) erstellt wurden. Damit können sie leichter zwischen verschiedenen Organisationen ausgetauscht und wiederverwendet werden. FMUs werden derzeit in der Industrie z. B. für die Verhaltenssimulation von Produktionskomponenten verwendet. Ihr Gebrauch könnte aber auch auf Energieverbrauch, Lebenszyklusbewertung oder 3D-Informationen ausgedehnt werden.

So viele Möglichkeiten der einfache Austausch der dynamischen Modelle bietet: Ihre Integrität ist bislang nicht geschützt. In FMUs ist lauffähiger Programmcode enthalten, der „blind“ ausgeführt wird. Wenn dort Schadcode enthalten ist oder der Inhalt auf dem Übertragungsweg manipuliert wurde, kann dies heute nicht überprüft werden. Außerdem integrieren FMU-Ersteller (z. B. Komponentenhersteller) sensible Informationen über das interne Verhalten ihrer Komponenten im ausführbaren Teil der FMU.

Für diese Security-Probleme stellen Miriam Schleipen und Christian Wolf Lösungsstrategien vor, damit die neue Technologie ohne Security-Bauschmerzen genutzt werden kann.

Neue Technologien für die Digitalisierung sorgen bei Automatisierern für Begeisterung – zurecht: Durch Ethernet APL wird ein Feldgerät via Ethernet erreichbar, ohne Medienbruch zu Feldbussen, Strom- oder Spannungssignal. IIOT-Geräte erleichtern Maintenance oder Optimierung, indem sie Anlagendaten direkt an ihren Hersteller übermitteln.

Aus Security-Sicht ermöglichen diese Technologien vor allem reibungslosere und weitreichendere Kommunikation, und das leider auch für potenzielle Angreifer. Andreas Schüller diskutiert in seinem Vortrag Security-Herausforderungen und Lösungsideen für solche digitalisierten Technologien. Dabei hat er besonders Störfallbetriebe im Blick, die im Rahmen der KAS-51 Security-Maßnahmen umsetzen müssen – Digitalisierung hin oder her.