Engineering-Kontrollsysteme, die Systeme für die Überwachung der Kontrolle und Datenerfassung (SCADA), verteilte Steuerungssysteme (DCS) und speicherprogrammierbare Steuerungen (PLC) umfassen, bilden das operative Rückgrat kritischer Infrastrukturen. Diese Systeme verwalten alles, von Stromnetzen und Wasseraufbereitungsanlagen bis hin zu Ölraffinerien und automatisierten Fertigungsanlagen. Da die Betriebstechnologie (OT) zunehmend mit der Informationstechnologie (IT) und dem Internet verbunden ist, dehnt sich die Angriffsfläche aus, was robuste Sicherheitstests zu einer wesentlichen betrieblichen Anforderung macht. Ein erfolgreicher Cyberangriff auf diese Systeme kann zu katastrophalen physischen Folgen führen, einschließlich Schäden an Geräten, Umweltschäden und Bedrohungen für die menschliche Sicherheit. Dieser Leitfaden bietet einen detaillierten Fahrplan für die Durchführung effektiver und sicherer Sicherheitstests an technischen Steuerungssystemen, um sicherzustellen, dass Schwachstellen identifiziert und gemindert werden, bevor sie ausgenutzt werden können.

Überbrückung der Lücke zwischen IT- und OT-Sicherheitstests

Sicherheitstests in einer technischen Umgebung unterscheiden sich grundlegend von den Standard-IT-Bewertungen von Unternehmen. Die Hauptziele der CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) werden in OT umgekehrt. Während Vertraulichkeit in der IT oberste Priorität hat, sind Sicherheit und Verfügbarkeit die obersten Prioritäten in technischen Steuerungssystemen. Die Störung eines Prozesses zum Testen einer Sicherheitslücke kann eine Produktionslinie stundenlang stoppen oder das Stromnetz destabilisieren. Folglich muss jede Testmethode an die einzigartigen Einschränkungen industrieller Umgebungen angepasst werden.

Verständnis der Operational Technology Landschaft

Vor der Durchführung von Tests müssen die Teams die spezifischen Komponenten verstehen, die ein technisches Kontrollsystem bilden, wie z.B.:

  • Mensch-Maschine-Schnittstellen (HMIs): Software, die es den Bedienern ermöglicht, den physischen Prozess zu überwachen und mit ihm zu interagieren.
  • Steuerungslogik (PLCs und RTUs): Eingebettete Geräte, die die Steuerlogik für physische Geräte ausführen.
  • Engineering Workstations (EWS): PCs, die von Ingenieuren zum Programmieren, Konfigurieren und Warten von Steuergeräten verwendet werden.
  • Industrielle Protokolle: Kommunikationsstandards wie Modbus, DNP3, PROFINET und OPC-UA, von denen viele keine native Authentifizierung oder Verschlüsselung haben.
  • Historiker und Datenserver: Zentrale Repositorien für Prozessdaten, die häufig auf Standard-Windows- oder Linux-Servern ausgeführt werden.

Das Testen dieser Komponenten erfordert ein spezielles Skillset, das tiefes Protokollwissen mit einem akuten Bewusstsein für Betriebsrisiken verbindet. Die Zusammenarbeit mit Anlageningenieuren und Kontrollsystemintegratoren ist nicht optional - es ist eine Voraussetzung für sichere und produktive Tests.

Pre-Engagement: Festlegung des Umfangs und der Regeln des Engagements

Die kritischste Phase eines OT-Sicherheitstests erfolgt vor dem Versand eines einzelnen Pakets. Eine umfassende Vorab-Engagement-Phase verhindert Unfallschäden und stellt sicher, dass die Tests den Anforderungen an die Geschäftskontinuität entsprechen. Diese Phase muss in einem rechtsverbindlichen Dokument resultieren, das den genauen Umfang, die Methodik und die Sicherheitsbeschränkungen beschreibt.

Umfang der Bewertung

Clearly define which systems are in scope. Is the test limited to the IT/OT boundary (e.g., data historians, jump boxes) or does it extend to the Level 1 control devices (PLCs, RTUs) and Level 0 physical processes (sensors, actuators)? Testing active production lines introduces significant risk. In many cases, organizations begin with a passive assessment of the live network before moving to active scanning against a mirrored network segment or a lab environment.

Sicherheitsprotokolle und "Tötungsschalter"

Ein robustes RoE-Dokument muss ein "Stop Light"-System oder einen definierten Kill Switch-Prozess enthalten. Dieser Mechanismus ermöglicht es dem Werkspersonal, die Tests sofort einzustellen, wenn es unsicheres Verhalten im physikalischen Prozess beobachtet. Spezifische Aktionen sind oft vertraglich verboten, ohne ausdrückliche schriftliche Ausnahme, einschließlich des Schreibens in Ausgangsspulen, des Sendens von Fernstart-/Stop-Befehlen oder des Änderns der Firmware. Das Testteam muss auch Sicherheitsinstrumentierte Systeme (SIS) überprüfen - diese sind tabu, es sei denn, die Anlage wird heruntergefahren und umgangen, da jede Störung kritische Sicherheitsfunktionen deaktivieren könnte.

Threat Modeling für Engineering Systeme

Vor der Ausführung von Angriffen, entwickeln Sie ein Bedrohungsmodell basierend auf bekannten ICS Gegner Verhalten. Frameworks wie die MITRE ATT & CK für ICS Matrix bieten eine strukturierte Taxonomie von Taktiken spezifisch für industrielle Umgebungen, einschließlich "Loss of Control", "Loss of View" und "Manipulation of View". Diese Modellierung hilft, Testbemühungen gegen die realistischsten und wirkungsvollsten Angriffsvektoren zu priorisieren, wie eine erweiterte persistente Bedrohung (APT), die Zugriff über ein kompromittiert Fernwartungskonto.

Phase 1: Passive Aufklärung und Informationssammlung

Passive Aufklärung ist die Grundlage aller sicheren OT-Sicherheitstests. Ziel ist es, die Netzwerkarchitektur abzubilden, Geräte zu identifizieren und Verkehrsströme zu verstehen, ohne ein einzelnes Paket an potenziell fragile industrielle Steuerungen zu senden. Diese Phase beruht vollständig auf dem Abhören des Netzwerkverkehrs und der Überprüfung der verfügbaren Dokumentation.

Netzverkehrsanalyse

Mit Tools wie Wireshark oder TCPdump auf einem gespiegelten SPAN-Port oder einem Netzwerk-Anzapfer können Tester Live-Datenverkehr erfassen. Analysten suchen nach Broadcast-Paketen, Protokoll-Handshakes und Routine-Abfragedaten. Durch die Untersuchung der Quell- und Ziel-MAC-Adressen und IPs erstellen Tester eine Topologiekarte des OT-Netzwerks. Diese passive Analyse zeigt:

  • Aktive IP-Adressen und Subnetze.
  • Industrielle Protokolle im Einsatz (z. B. Modbus/TCP-Port 502, DNP3-Port 20000, Profinet-Port 34964).
  • Firmware-Versionen und Gerätetypen aus dem Banner-Grabing.
  • Kommunikationsmuster zwischen HMI und SPS.

Dokument- und Konfigurationsprüfung

Die Überprüfung von Netzwerkdiagrammen, früheren Auditberichten, Firewall-Regelsätzen und Konfigurationsdateien für HMI-Software (z. B. Wonderware, Rockwell FactoryTalk) kann Standard- oder Hardcode-Anmeldeinformationen und schwache Sicherheitsarchitekturen aufdecken. Sicherheitstests umfassen die Überprüfung, ob Konfigurationsdateien verschlüsselt sind und Zugriffskontrollen streng durchgesetzt werden.

Phase 2: Vulnerability Assessment und Scannen

Nach passivem Mapping besteht der nächste Schritt darin, aktiv mit dem Netzwerk zu interagieren, um bekannte Schwachstellen zu identifizieren. Allerdings ist Vorsicht von größter Bedeutung. Viele herkömmliche IT-Schwachstellenscanner senden fehlerhafte Pakete oder Authentifizierungsversuche, die dazu führen können, dass alte SPS und RTUs abstürzen oder neu starten. Daher muss das Scannen mit speziellen Tools und sicheren Scanprofilen auf die OT-Umgebung zugeschnitten werden.

Verwendung von OT-spezifischen Scan-Tools

Standard-Tools wie Nmap können mit Vorsicht verwendet werden, indem die (paranoide) Zeitvorlage verwendet wird, um überwältigende Geräte zu vermeiden. Allerdings werden dedizierte OT-Bewertungstools stark bevorzugt. Plattformen wie Tenable.ot, Claroty, Nozomi Guardian oder Dragos haben vorgefertigte Signaturen, die getestet werden, um das Risiko von Aufprall zu minimieren. Diese Tools können Schwachstellen identifizieren, die für industrielle Steuerungen spezifisch sind, wie EIP (EtherNet/IP) Stapelüberläufe oder unsachgemäße Handhabung von DNP3-Anwendungsschichtanforderungen.

Identifizierung schwacher Authentifizierung und Autorisierung

Ein erheblicher Teil der OT-Schwachstellen dreht sich um schwache Authentifizierung.

  • Standard-Anmeldeinformationen: SPS und HMIs werden oft mit bekannten Passwörtern ausgeliefert (z. B. , ).
  • Weak SNMP Community Strings: Devices using and strings allow read and write access to configuration data.
  • Unverschlüsselte Protokolle: Bestätigung, dass sensible Daten, wie z. B. technische Anmeldeinformationen, das Netzwerk im Klartext über Protokolle wie Telnet oder ältere Versionen von OPC durchqueren.

Phase 3: Aktive Penetrationsprüfung von Steuerungssystemen

Aktive Penetrationstests bestätigen, ob identifizierte Schwachstellen genutzt werden können, um ein bestimmtes Betriebsziel zu erreichen. Diese Phase erfordert einen "Fly-by-Wire"-Ansatz, bei dem jeder Schritt sowohl vom roten Team als auch vom Werksbetriebsteam sorgfältig geplant und überwacht wird. Ziel ist es, die Auswirkungen eines Kompromisses zu demonstrieren, ohne eine tatsächliche Prozessstörung zu verursachen.

Industrielle Protokolle angreifen

Penetrationstester manipulieren industrielle Protokolle, um einen Angreifer zu simulieren, der Zugang zum OT-Netzwerk erhalten hat. Zum Beispiel kann ein Tester mit Tools wie ModbusPal oder Scapy bösartige Modbus-Pakete herstellen. Ein Angriff auf eine Wasseraufbereitungsanlage könnte zum Beispiel das Senden eines Schreibbefehls (Funktionscode 16) an ein SPS-Halteregister beinhalten, das eine Chemikaliendosierpumpe steuert. Durch Modifizieren von Daten schneller als der Bediener sie korrigieren kann, simuliert der Tester einen "Man-in-the-Middle" (MitM) Angriff, der zu einer Überchlorierung einer Wasserversorgung führen könnte.

Nutzung von HMI und Engineering Workstations

HMIs und EWSs sind typischerweise Windows-basierte Maschinen, wodurch sie anfällig für Standard-IT-Angriffsvektoren sind. Testteams versuchen, diese Stationen mit Phishing-Simulationen zu kompromittieren oder ungepatchte Schwachstellen auszunutzen (z. B. EternalBlue, Log4j). Sobald ein Stand auf dem HMI hergestellt wurde, erbt der Angreifer die Vertrauensbeziehung dieses Computers zu den SPSs. Von dieser Position aus können Tester:

  • Bereitstellen von Ransomware, die HMI-Konfigurationsdateien verschlüsselt.
  • Ändern Sie HMI-Grafiken, um unsichere Prozesswerte zu verbergen (Manipulation of View).
  • Steal-Leiter-Logik-Quellcode, um den physischen Prozess für einen zukünftigen Angriff zu verstehen.

Privilegescalation und Lateralbewegung

Sobald der erste Zugriff erlangt ist, versucht der Tester, sich seitlich vom IT-Netzwerk zum OT-Netzwerk zu bewegen, indem er die Industrial Demilitarized Zone (IDMZ) durchquert, wobei häufig nach gemeinsamen Anmeldeinformationen gesucht, Domain Trusts angegriffen oder schlecht konfigurierte Sprungserver ausgenutzt werden. Ziel ist es, einen Weg von einem internetorientierten Webserver zu einer Sicherheits-SPS auf dem Werksboden zu demonstrieren. Der Erfolg in dieser Phase unterstreicht die Notwendigkeit einer strengen Netzwerksegmentierung und das Prinzip der geringsten Privilegien.

Testen von Incident Response und Recovery-Verfahren

Bei Sicherheitstests geht es nicht nur darum, technische Fehler zu finden, sondern auch darum, die vorhandenen Personen und Prozesse zu bewerten, um einen Angriff zu erkennen und darauf zu reagieren. Eine Organisation verfügt möglicherweise über robuste technische Kontrollen, aber wenn ihre Betreiber und Cybersicherheitsanalysten einen Verstoß nicht richtig identifizieren können oder die richtigen Reaktionsverfahren nicht anwenden, ist die Sicherheitsinvestition verschwendet.

Tabletop-Übungen und Purple Teaming

Während einer Übung mit einem „lila Team führt das rote Team einen bestimmten Angriff aus (z. B. Manipulation eines Temperatursensors), während das blaue Team seine SIEM- (Security Information and Event Management) und OT-Überwachungstools (z. B. Nozomi, Dragos) überwacht.

  • Erkennungszeit: Wie lange dauert es, bis das Security Operations Center (SOC) realisiert, dass eine Prozessvariable manipuliert wurde?
  • Analyst Response: Kontaktiert das SOC den Anlageningenieur oder versuchen sie, die SPS zu isolieren, ohne die Sicherheitsauswirkungen zu verstehen?
  • Kommunikationskanäle: Werden die richtigen Eskalationspfade befolgt? Wird der Incident Response Plan nur für IT-Szenarien geschrieben oder beinhaltet er OT-spezifische Eindämmungsstrategien wie manuelles Failover?

Sanierungs- und Härtestrategien für Engineering-Systeme

Die Identifizierung von Schwachstellen ist nur die halbe Miete. Die letzte Phase beinhaltet die Erstellung einer priorisierten Sanierungs-Roadmap, die die betrieblichen Einschränkungen respektiert. In OT ist Patching oft der letzte Ausweg aufgrund von Kompatibilitätsproblemen mit dem Anbieter und dem Risiko, die Kontrolllogik zu durchbrechen. Daher werden Ausgleichskontrollen stark genutzt.

Netzwerksegmentierung (Purdue-Modell)

Die Einhaltung des ANSI/ISA-62443-Standards (früher ISA-99) und der Purdue Enterprise Reference Architecture ist der Goldstandard für OT-Sicherheit.

  • Der Datenverkehr aus dem IT-Netzwerk (Level 4/5) kann eine SPS (Level 1) nicht direkt erreichen.
  • Eine Stateful Firewall oder Einweg-Datendiode erzwingt die IDMZ-Grenze.
  • Industrielle Protokolle werden von der Firewall inspiziert oder zugelassen (Deep Packet Inspection).

Wenn ein Tester eine SPS von einem Laptop aus an eine Ethernet-Buchse eines Unternehmens anschließen kann, ist die Segmentierung fehlgeschlagen.

Sicherer Remotezugriff und Vendor Management

Fernzugriffspunkte sind der Eintrittsvektor Nummer eins für OT-Angriffe. Testteams sollten gründlich beurteilen, wie Drittanbieter sich mit dem System verbinden. Die Verwendung von VPNs mit Multi-Faktor-Authentifizierung (MFA), Sprungboxen und Sitzungsaufzeichnungstools sollte streng durchgesetzt werden. Testen sollte sicherstellen, dass keine Rogue-Modems oder Mobilfunkrouter direkt mit Kontrollnetzwerken verbunden sind - ein häufiger Befund bei Vor-Ort-Bewertungen. Organisationen sollten sich auf Richtlinien von Gremien wie dem National Institute of Standards and Technology (NIST SP 800-82) beziehen, um umfassende Anleitungen zur Sicherung des ICS-Fernzugriffs zu erhalten.

Anwendung und Device Whitelisting

Engineering-Workstations führen oft Legacy-Betriebssysteme aus, die nicht gepatcht werden können. Eine kritische Ausgleichskontrolle ist das Whitelisting von Anwendungen. Tester sollten versuchen, nicht autorisierte Binärdateien oder Skripte auf diesen Computern auszuführen. Wenn die Whitelisting-Lösung (z. B. Microsoft AppLocker, Cisco AMP für ICS) die Ausführung nicht autorisierter Tools verhindert, bietet sie eine starke Verteidigung gegen Malware und Ransomware. Ebenso sollten Tester überprüfen, ob USB-Ports deaktiviert oder gesteuert sind, um die Einführung von bösartiger Firmware oder USB-basierten Angriffen wie BadUSB zu verhindern.

Fazit: Iteratives Testen für eine dynamische Bedrohungslandschaft

Security testing on engineering control systems is not a one-time project but an iterative lifecycle that must adapt to evolving threats and changes in the production environment. By combining passive reconnaissance, careful vulnerability scanning, scenario-based penetration testing, and rigorous incident response evaluation, organizations can significantly reduce their risk of a catastrophic cyber event. The ultimate objective is to build resilience—ensuring that even if a breach occurs, the safety and reliability of the critical processes remain intact. As attackers continue to target the intersection of IT and OT, a disciplined and safety-first approach to testing is no longer a technical preference; it is a core operational necessity.