Wie läuft ein Penetrationstest in einer OT-Umgebung ab?

Unter Operational Technology (OT) werden die Hard- und Softwaresysteme verstanden, die physische Prozesse in der realen Welt steuern. Dies umfasst Automatisierungssysteme in der produzierenden Industrie genauso wie die Gebäudeleittechnik in Häusern aller Art oder die Steuerungssysteme von medizinischen Geräten im Krankenhaus – um nur einige Beispiele zu nennen. Mit zunehmender Digitalisierung der Prozesse hat auch bei den entsprechenden Steuerungssystemen die Vernetzung zugenommen. Neben vielen Vorteilen dieser Technik, wie etwa dem effizienten Austausch von Daten zwischen Produktion und Enterprise Resource Planning (ERP)-Systemen oder der einfacheren Konfiguration und Programmierung der Geräte auch aus der Ferne, ergibt sich hieraus eine große Angriffsfläche. Insbesondere birgt die Verbindung der klassischen IT-Netzwerke mit den Produktionsnetzwerken und der Einsatz gewöhnlicher aus der IT bekannter Technologien (sogenannte "IT/OT-Konvergenz") Risiken. Im Gegensatz zur IT besteht auch eine reale Gefahr für die physische Sicherheit/Unversehrtheit, sowohl von Menschen als auch von Komponenten.

Angriffe auf OT-Netzwerke können verschiedene Motivationen haben. Neben der Erpressung von Lösegeld durch den schnell sehr hohen finanziellen Schaden bei einem Ausfall und Stillstand der Anlagen sowie der Industriespionage finden auch immer häufiger Angriffe statt, die einen möglicherweise staatlichen Hintergrund haben. Dies betrifft insbesondere die Kritische Infrastruktur.

Vor diesem Hintergrund ist es für Unternehmen sehr wichtig, ihre OT-Netzwerke so weit wie möglich abzusichern. Die SySS GmbH kann bei diesem Prozess auf verschiedene Weisen unterstützen. Der klassische Penetrationstest, die Kernkompetenz der SySS, muss auf die spezifischen Herausforderungen von OT-Umgebungen angepasst werden. Hierzu zählen unter anderem die Minimierung des Risikos eines Ausfalls oder gar Schadens durch den Test sowie den im Vergleich zu IT-Systemen deutlich anderen Lebenszyklus und die vorhandenen – oder eben nicht vorhandenen – Sicherheitsfunktionen der eingesetzten Geräte.

In diesem Artikel geht es darum, wie ein Penetrationstest in einer OT-Umgebung üblicherweise abläuft und was Kunden von einem solchen Projekt in ihrer Organisation erwarten können.

Phase 1: Gemeinsame Abstimmung der Fragestellungen und Ziele für den Test

Zu Beginn wird gemeinsam abgestimmt, was das Ziel des Projekts ist. Hierzu erfragen wir, wie der Prozess beim Kunden grob aufgebaut ist, welche Systeme eingesetzt werden und wie das Zusammenspiel der unterschiedlichen vorhandenen Komponenten funktioniert. Wir klären, ob eine technische Überprüfung direkt im Netzwerk infrage kommt oder ob eine ausschließlich theoretische Analyse und Einordnung der Architektur sowie des Standpunkts des Kunden in Bezug zur Cybersicherheit besser geeignet ist. Anschließend erhält der Kunde ein maßgeschneidertes Angebot für ein passendes Projekt.

Für eine technische Überprüfung empfehlen wir Fragestellungen und Testszenarien, die wir gemeinsam mit dem Kunden auswählen und für die wir die nötigen Rahmenbedingungen abstecken. Hierbei legen wir einen Fokus auf die IP-Netzwerk-bezogenen Komponenten.

Die funktionelle Sicherheit sowie Verfügbarkeit des Prozesses hat oberste Priorität. Daher besprechen wir auch, ob der Penetrationstest während eines Wartungsfensters oder im laufenden Betrieb stattfinden kann. Auch die nötige persönliche Schutzausrüstung wird bestimmt. In der Regel führen zwei Consultants aus unserem Schwerpunktteam OT das Projekt vor Ort durch.

Phase 2: Betrachtung der Netzwerkarchitektur und eingesetzter Technologien

Eine Enumeration vorhandener Systeme im OT-Bereich mithilfe von Werkzeugen wie Port- und Schwachstellenscannern ohne Vorwissen kommt für uns in der Regel nicht infrage. Zwar würde einem echten Angreifer nur diese Vorgehensweise bleiben, sie hätte jedoch ein zu hohes und vor allem vermeidbares Risiko, Geräte unbeabsichtigt zum Absturz zu bringen. Bis vor vergleichsweise kurzer Zeit legten die Hersteller von OT-Geräten eher wenig Wert auf die Resilienz ihrer Geräte in Bezug auf unerwartete Kommunikation. OT-Netzwerke wurden wie klassische Feldbusse als prinzipiell vor Eindringlingen geschützte Bereiche angesehen. Mit der Vernetzung von OT- und IT-Netzwerken ist dies heute nicht mehr der Fall. Da allerdings potenziell sehr alte Geräte im Netzwerk vorhanden sein können, stellt eine Suche ohne Vorwissen eine Gefahr dar.

Daher führen wir den Penetrationstest mit einem Whitebox-Ansatz durch. Wir besprechen am Anfang des Projekts die Netzwerkarchitektur sowie die eingesetzten Technologien. Dies findet typischerweise als Workshop vor Ort statt und umfasst auch eine Begehung der Produktionsbereiche bzw. der OT-Anlagen. Typischerweise werden hier bereits Verbesserungsmaßnahmen identifiziert und passende Empfehlungen formuliert. Auch die Pentestszenarien werden hier gemeinsam besprochen und final festgelegt.

Phase 3: Durchführung der festgelegten Pentestszenarien

Nun geht es los mit der technischen Überprüfung der OT-Umgebung auf Schwachstellen. Wir schließen also ein SySS-Notebook an das Kundennetzwerk an bzw. erhalten Zugriff auf einen typischen Client, den Mitarbeitende des Unternehmens verwenden würden. Wir bearbeiten die in den folgenden Abschnitten beschriebenen Fragestellungen.

Fragestellung 1: Sind unsichere Protokolle erreichbar?

Hier geht es darum, welche Protokolle für die Kommunikation zwischen Steuerungen, Bediengeräten (Human Machine Interface, HMI), Data Historians und Managementservern im Einsatz sind. Sehr gut eignet sich für die Analyse ein Spiegelport an einem bzw. mehreren relevanten Switches, da dieser einen Mitschnitt des realen Netzwerkverkehrs ohne Risiko eines Ausfalls der beteiligten Systeme erlaubt. Mithilfe des Mitschnitts können wir dann sehen, welche Geräte über welche Protokolle miteinander sprechen.

Viele der klassischerweise genutzten Protokolle im OT-Bereich sind unverschlüsselt und besitzen keinen Authentifizierungsmechanismus. Es ist also schlicht gesagt auf Protokollebene gar nicht möglich, die Kommunikation abzusichern – ein Passwort lässt sich hier beispielsweise nicht setzen. Der Fokus der Protokolle liegt vielmehr auf der verlässlichen Echtzeitkommunikation und Übertragung von aktuellen Prozessdaten. Von den meisten Protokollen gibt es inzwischen modernere Varianten, die Verschlüsselung und Authentifizierung auf verschiedenen Wegen hinzufügen – oftmals durch die Verwendung des Transport Layer Security (TLS)-Protokolls. Da dies aber die Verwaltung von individuellem Schlüsselmaterial auf den OT-Geräten und die Verwendung entsprechend aktueller Firmware-Stände erfordert, ist die Verbreitung der sicheren Protokollvarianten noch gering. Und auch für die verschlüsselten Protokolle existieren teilweise Angriffsmöglichkeiten.

Aufgrund dieser Gegebenheiten muss eine OT-Umgebung sorgsam isoliert werden. Wir prüfen daher, welche Dienste und Geräte wir von welchen Standorten bzw. Ausgangssystemen erreichen können, und bewerten das hieraus entstehende Risiko.

Fragestellung 2: Welche Softwareversionsstände sind im Einsatz?

Als nächstes versuchen wir, von möglichst vielen Geräten Informationen über die eingesetzte Firmware zu erhalten. Praktischerweise sind die meisten OT-Geräte in diesem Punkt vergleichsweise gesprächig und erlauben das Auslesen der Version über Discovery-Protokolle. Sofern dies nicht möglich ist oder die entsprechenden Dienste nicht erreichbar sind, klären wir die Versionsstände im Gespräch. Neben Low-Level-Geräten wie den Steuerungen betrifft dieser Prüfschritt auch die begleitenden Systeme, die oftmals mit Microsoft Windows betrieben werden.

Eine Aktualisierung auf die neuste Version von Firmware bzw. des Betriebssystems oder das Einspielen verfügbarer Updates ist im OT-Bereich erheblich schwieriger als im IT-Bereich. Oftmals können nur Updates installiert werden, die vom Hersteller der eingesetzten Anlagen freigegeben werden – andernfalls besteht das Risiko, dass die Hard- oder Software nicht mehr funktioniert und der Hersteller auch keinen Support bietet. Diese Freigaben kommen regelmäßig mit einiger Verzögerung.

Die SySS bewertet die Vor- und Nachteile von Updates im Hinblick auf die jeweilige Situation in der Kundenumgebung. Hier kommt zum Beispiel auch der Patch-Entscheidungsbaum der CISA zum Einsatz. Konkret muss das Risiko durch möglicherweise öffentlich bekannte Schwachstellen gegen das eines Ausfalls eben durch den Patch abgewogen werden. Gegebenenfalls ist virtuelles Patchen die beste Option. Hierunter versteht man die Implementierung von Schutzmaßnahmen, die eine Ausnutzung der Schwachstelle verhindern – wie beispielsweise Firewallregeln, das Deaktivieren von Diensten oder der Einsatz von Intrusion Prevention-Systemen.

Fragestellung 3: Wie sind die Übergänge zwischen IT- und OT-Netzen abgesichert?

Um Prozessdaten effizient zwischen Produktion und Planung (beispielsweise einem ERP-System im IT-Netzwerk) auszutauschen, kann eine vollständige Isolierung des OT-Netzwerks üblicherweise nicht erreicht werden. Neben dem Datenaustausch ist oft auch ein Zugriff auf Engineering- oder Operator-Systeme gewünscht. Die hierfür geschaffenen Übergänge zwischen IT- und OT-Netzen sind aber für Angreifer sehr interessant, da sie ggf. eine Ausbreitung von einem kompromittierten Client im Bürobereich hin zu den ungeschützten Protokollen im OT-Bereich erlauben. So kann aus einer initialen Infektion (beispielsweise durch eine Schadsoftware, die aus dem Internet heruntergeladen wurde) ein kritischer Produktionsausfall werden. Auch die andere Richtung wird beleuchtet: Geht von einem infizierten Servicelaptop eines Technikers im OT-Netzwerk eine Gefahr für die Systeme im IT-Netzwerk aus?

Idealerweise startet die Analyse von einem Referenzclient, auf dem die SySS ein niedrig privilegiertes Standardkonto hat. Von diesem Ausgangspunkt versuchen wir dann, unsere Rechte auf weitere Systeme auszuweiten und einen Weg hin zum OT-Netzwerk zu finden – meist über mehrere Sprünge. Hierfür ist auch die Prüfung eines gegebenenfalls eingesetzten Active Directory-Verzeichnisdiensts essenziell, vor allem wenn Systeme im OT-Bereich ebenfalls Teil der Domäne sind.

Fragestellung 4: Welche Risiken sind durch den Einsatz von Fernwartungszugängen vorhanden?

Ein häufiges Einfallstor neben der Kompromittierung eines Office-Clients sind vorhandene Fernwartungszugänge. Es ist üblich, dass die Anlagenhersteller auf einen solchen Zugang zur Wartung der Systeme bestehen – und oft kommt für die Hersteller bzw. Integratoren nur ein bestimmter, von ihnen präferierter Weg infrage. Dieser ist dann oft eher mit einem Fokus auf effiziente Verwendbarkeit für das Unternehmen als auf besonders hohe Sicherheit konzipiert.

Wir prüfen daher, welche Möglichkeiten sich einem Angreifer ergeben, der den Fernwartungszugang hacken konnte – sei es durch die Kompromittierung von Zugangsdaten, einen Supply-Chain-Angriff auf einen Dienstleister des Kunden oder eine Schwachstelle in der verwendeten Fernzugriffstechnologie. Insbesondere beliebte Remote Access Gateways, die eine VPN-Verbindung direkt in das OT-Netzwerk anbieten, waren hier in der Vergangenheit bereits von verschiedenen Schwachstellen (Security Advisories SYSS-2024-059 bis -065 und SYSS-2024-016/-017/-018/-032/-033/-043) betroffen, die unter anderem von SySS Expert IT Security Consultant Moritz Abrell aufgedeckt wurden.

Fragestellung 5: Wie kann ein Angreifer direkten Zugriff zu den OT-Netzwerken erlangen?

Schließlich prüfen wir, wie einfach oder schwierig ein Netzwerkzugriff auf OT-Netzwerke von einem Angreifer durch direkten physischen Zugriff erlangt werden kann. Dies ist insbesondere bei vielen kleinen verteilten Knoten interessant, beispielsweise Messpunkte im Stromnetz oder entlang von Gasleitungen. Die beste Sicherheit für den Hauptstandort des Kunden und den Fernzugriff auf das OT-Netzwerk bringt nichts, wenn ein Angreifer ein Vorhängeschloss an einer unbewachten und einsamen Messstation aufbrechen kann und dort eine gepatchte Ethernetdose mit Netzwerkzugriff auf das Leitnetz vorfindet.

Die Analyse findet üblicherweise im gemeinsamen Gespräch oder durch Begehung eines ausgewählten repräsentativen Außenstandorts statt. Auch ggf. eingesetzte Netzwerkzugangskontrollen testen wir auf Wirksamkeit.

Phase 4: Dokumentation von Workshopergebnissen, Schwachstellen und Maßnahmen sowie Präsentation der Ergebnisse

Die im Penetrationstest gefundenen Schwachstellen und Risiken werden in einem Bericht dokumentiert und über eine verschlüsselte Übertragung zur Verfügung gestellt. Der Bericht enthält zu Beginn unser Executive Summary, das die Ziele und Rahmendaten des Projekts sowie die empfohlenen Maßnahmen für das Management klar und prägnant darlegt. Es folgt eine tabellarische Zusammenfassung der Funde, die nach Kritikalität sortiert und passend farblich markiert ist. Anschließend werden die identifizierten Schwachstellen jeweils mit dem nötigen Hintergrund, der Beschreibung des Funds, einer Proof of Concept-Darstellung, die sich auch zur Reproduktion eignet, und unserer Empfehlung beschrieben. Unsere Empfehlung erfolgt dabei auf dem aktuellen Stand der Technik sowie unter Berücksichtigung der konkreten OT-Landschaft.

Der Bericht wird zweistufig qualitätsgesichert (technisch und sprachlich) und umgehend zugestellt. Anschließend besprechen wir mit dem Kunden die Ergebnisse und klären mögliche Rückfragen.

Phase 5: Weitere Betreuung bei der Umsetzung von Verbesserungsmaßnahmen

Nun beginnt die nächste Phase: die Umsetzung der empfohlenen Verbesserungsmaßnahmen durch den Kunden mit dem Ziel, die Sicherheit der OT-Umgebung zu erhöhen. Während sich einige Empfehlungen üblicherweise vergleichsweise schnell umsetzen lassen ("Quick Wins"), benötigen andere teilweise hohe Aufwände und Umbaumaßnahmen in der Architektur.

Die SySS unterstützt gerne auch in dieser Phase weiter tatkräftig. Zwar empfehlen wir aufgrund unserer Neutralität als Penetrationstestanbieter, die in unserer Berufsethik festgehalten ist, keine konkreten Produkte, wir analysieren allerdings gerne für den Kunden die gewählte Option aus Sicherheitssicht, beispielsweise durch einen Pentest mit den Modulen SOFTWARE, WEBAPP, WEBSERVICE oder unseren Embedded Systems (ES)-Modulen. Zudem beraten wir mit Freude bei der Einführung neuer Produkte und Lösungen und bewerten die damit einhergehenden Auswirkungen auf die Architektur.

Unserer Erfahrung nach macht ein passendes Folgeprojekt nach einiger Zeit in nahezu allen Fällen Sinn. Dies gibt dem Kunden die Gelegenheit, die Maßnahmen aus dem Penetrationstest für sich zu priorisieren und umzusetzen und anschließend einen neuen Blick auf die OT-Umgebung zu werfen. Sicherheit sollte stets als ein iterativer Prozess verstanden werden, denn zum einen wird so nicht der Beginn von Verbesserungsmaßnahmen durch Perfektionismus verzögert und zum anderen entwickeln sich auch die gängigen OT-Systeme und Angriffe weiter.

Wir vereinbaren gerne einen unverbindlichen Termin mit Ihnen, in dem wir Ihnen unsere Vorgehensweise näher erläutern und gemeinsam mit Ihnen herausfinden, ob ein Penetrationstest Ihrer OT-Umgebung für Sie der richtige Schritt ist bzw. wie dieser genau auf Ihre Bedürfnisse abgestimmt werden kann. Wenden Sie sich gerne an anfrage(at)syss.de.