OT Penetration Testing · Moritz Samrock

OT Penetration Testing ist die autorisierte Sicherheitsprüfung von Operational-Technology-Umgebungen — SCADA-Systeme, Prozessleitsysteme (DCS), speicherprogrammierbare Steuerungen (SPS), Bedien- und Beobachtungssysteme (HMI) sowie die industriellen Protokolle, die sie verbinden. Ziel ist es, ausnutzbare Schwachstellen in Systemen zu identifizieren, die physische Prozesse steuern, bevor ein Angreifer sie für Betriebsstörungen, Sicherheitsvorfälle oder Umweltschäden nutzen kann.

Im Gegensatz zu klassischen IT-Pentests gelten bei OT-Assessments strenge Sicherheitsauflagen: Ein fehlgeleitetes Paket auf einem Modbus-Segment kann eine Produktionslinie stoppen oder eine Sicherheitsabschaltung auslösen. Das erfordert Spezialwissen über industrielle Protokolle, Prozesssicherheit und den betrieblichen Kontext jedes getesteten Geräts.

Wer beauftragt diesen Test?

OT-Penetrationstests werden typischerweise von Werksleitern, OT-Sicherheitsbeauftragten oder CISOs in Organisationen mit industrieller Infrastruktur beauftragt. In der Praxis kommt der Anstoß oft aus der Compliance- oder Risikomanagement-Abteilung — getrieben durch regulatorische Anforderungen wie das IT-Sicherheitsgesetz, die EU-NIS2-Richtlinie oder branchenspezifische Normen wie die IEC 62443. In KRITIS-Sektoren — Energie, Wasser, Produktion, Transport — verantworten Betriebsleitung und OT-Security-Team das Engagement gemeinsam.

Ziel des Tests

Primäre Ziele sind die Bewertung der Widerstandsfähigkeit industrieller Steuerungssysteme gegen gezielte Cyberangriffe, die Überprüfung der Netzwerksegmentierung zwischen IT- und OT-Zonen sowie die Identifikation von Angriffspfaden, über die ein Angreifer vom Unternehmensnetz in die Produktionsnetze vordringen könnte. Sekundäre Ziele umfassen häufig die Validierung von Erkennungsfähigkeiten in OT-spezifischen Monitoring-Tools und die Prüfung, ob Safety Instrumented Systems (SIS) über netzwerkbasierte Angriffe kompromittiert werden können.

Was wird getestet?

Die Prüfung umfasst den gesamten OT-Stack: SCADA-Server und Historian-Datenbanken, DCS-Controller, SPS und Remote Terminal Units (RTUs), HMIs und Engineering-Workstations sowie die verbindenden Industrieprotokolle — Modbus TCP/RTU, OPC UA und OPC DA, PROFINET, DNP3, BACnet, EtherNet/IP und IEC 60870-5-104. Netzwerkinfrastruktur innerhalb der OT-Zone (Managed Switches, industrielle Firewalls, Data Diodes), Remote-Access-Gateways und die IT/OT-Demilitarisierte Zone gehören ebenfalls zum Scope. Falls vorhanden, werden auch drahtlose Feldnetzwerke (WirelessHART, ISA100.11a) und Seriell-zu-Ethernet-Konverter geprüft.

Übliche Schwachstellen und Findings

Standard- oder Werkskennwörter auf SPS, RTUs und HMIs, die nach der Inbetriebnahme nie geändert wurden
Flache Netzwerke ohne Segmentierung zwischen IT und OT oder zwischen Safety- und Steuerungszonen
Industrieprotokolle ohne Authentifizierung oder Verschlüsselung (Modbus, OPC DA, BACnet)
Veraltete Firmware auf Controllern, die wegen Produktionsverfügbarkeit nicht gepatcht werden können
Legacy-Windows-Systeme (XP, Server 2003) für HMI- oder Historian-Software in OT-Zonen ohne kompensierende Kontrollen
Exponierte Engineering-Workstations mit direktem SPS-Programmierzugriff aus dem Unternehmensnetz
Unsicherer Remote-Zugang — VPN- oder RDP-Tunnel in OT-Segmente mit schwacher Authentifizierung und ohne MFA
Fehlende oder falsch konfigurierte OT-spezifische Angriffserkennung
Unüberwachte USB-Ports an HMIs und Engineering-Stationen

Ablauf eines OT-Penetrationstests

Interesse/Erstanfrage — Die Organisation meldet sich, oft ausgelöst durch ein regulatorisches Audit, einen Vorfall bei einem Branchenkollegen oder eine anstehende IEC-62443-Zertifizierung. Das Pentest-Team erfasst grundlegende Informationen zur industriellen Umgebung, Branche und regulatorischen Rahmenbedingungen.

Erstgespräch zum Verständnis der Kundenziele — Ein detailliertes Gespräch mit Werksleitung, OT-Security und IT-Sicherheit, um industrielle Prozesse, Kritikalitätsstufen, akzeptables Risiko während der Tests und Safety-Constraints zu verstehen. Dieser Schritt ist entscheidend: Der Tester muss wissen, welche Aktionen physische Sicherheit beeinträchtigen könnten.

Angebotserstellung und Freigabe — Ein formelles Angebot spezifiziert den Testansatz, listet explizit verbotene Aktionen auf (z. B. Schreiben auf SPS-Register, Änderung von Safety-Controller-Logik) und definiert die verfügbaren Wartungsfenster für aktive Tests. Das Angebot wird von Werksleitung, OT-Engineering und Rechtsabteilung geprüft.

Scope-Definition — Systeme, Netzwerksegmente, Protokolle und physische Standorte werden dokumentiert. OT-Pentests definieren häufig einen gestuften Scope: passive Aufklärung gegen das gesamte OT-Netz, aktives Scanning beschränkt auf unkritische Segmente, kontrollierte Exploitation nur an designierten Testsystemen oder während geplanter Wartungsfenster.

Letter of Engagement — Unterzeichnete Autorisierung mit rechtlicher Absicherung, Notfallkontakten und einem Safety-Stop-Verfahren. In OT-Umgebungen enthält dieses Dokument typischerweise eine dedizierte Safety-Eskalationskette und ein sofortiges Stopp-Protokoll.

Erstellung weiterer Freigaben — Falls cloudbasierte SCADA- oder Remote-Monitoring-Plattformen im Scope sind, werden providerspezifische Testgenehmigungen eingeholt.

Bereitstellung von Informationen je nach Black-/Gray-/White-Box-Ansatz — Der Auftraggeber stellt je nach Ansatz Netzwerkdiagramme, Asset-Inventare, Protokolldokumentation, Firmware-Versionen und Zugang zu Engineering-Workstations bereit. Gray-Box ist der häufigste Ansatz in OT, da rein blindes Testen ein nicht akzeptables Sicherheitsrisiko birgt.

Kick-Off Call — Finale Abstimmung mit allen Beteiligten: Anlagenbetreiber, Schichtleiter, OT-Engineering, IT-Security und Pentest-Team. Notfallverfahren, Kommunikationskanäle und Testzeitplan werden bestätigt.

Durchführung mit laufender Information der Stakeholder — Die Tests beginnen typischerweise mit passiver Netzwerkanalyse (Traffic-Capture, Protokollidentifikation, Asset Discovery) und gehen dann zu aktivem Probing während vereinbarter Wartungsfenster über. Das Pentest-Team hält kontinuierlichen Kontakt zur Betriebsleitung. Jede Anomalie wird sofort gemeldet. Safety-kritische Systeme werden nur mit expliziter Echtzeit-Freigabe des Betriebspersonals getestet.

Sammlung und Bewertung der Schwachstellen — Findings werden gesammelt, verifiziert und nach für OT geeigneten Frameworks bewertet (z. B. CVSS mit Umgebungsmetriken, die OT-Auswirkungen abbilden, oder IEC 62443 Security Levels).

Erstellung des Abschlussberichts — Der Bericht dokumentiert jedes Finding mit technischem Nachweis, einer Bewertung der operativen und Safety-Auswirkungen sowie umsetzbaren Maßnahmen, die auf OT-Constraints zugeschnitten sind (wo Patching nicht möglich ist, werden kompensierende Kontrollen empfohlen).

Vorstellung in einer Präsentation — Die Ergebnisse werden Stakeholdern präsentiert, darunter Werksleitung, OT-Engineering, IT-Security und Geschäftsführung. Die Präsentation übersetzt technische Findings in operatives Risikovokabular.

Projektabschluss — Lessons Learned, Maßnahmenzeitpläne und Empfehlungen für Folgetests oder Monitoring-Verbesserungen werden vereinbart.

Wer sollte diesen Test wann durchführen lassen?

Betreiber kritischer Infrastrukturen — Energieerzeugung und -verteilung, Wasser- und Abwasserversorgung, Produktion, Chemie, Transport — sind die primäre Zielgruppe. In Deutschland unterliegen KRITIS-Betreiber expliziten Pflichten nach dem IT-Sicherheitsgesetz und der BSI-Kritisverordnung. Die NIS2-Richtlinie weitet vergleichbare Anforderungen EU-weit aus. IEC-62443-Compliance-Programme verlangen regelmäßige Sicherheitsbewertungen industrieller Automatisierungs- und Steuerungssysteme.

OT-Pentests sollten nach wesentlichen OT-Netzwerkänderungen, neuen SCADA- oder DCS-Deployments, der Integration von IT- und OT-Netzen, der Migration von seriellen zu Ethernet-basierten Protokollen und in einem regelmäßigen Zyklus (jährlich oder halbjährlich) durchgeführt werden. Besonders wertvoll ist eine Erstprüfung nach Jahren organischen Wachstums, in denen Sicherheit gegenüber Betriebsverfügbarkeit nachrangig war.