0%
ZURÜCK ZUR ÜBERSICHT

OT-Pentest: Warum SCADA, SPS und Industrieanlagen eine andere Sicherheitslogik brauchen

OT-Pentest: Warum SCADA, SPS und Industrieanlagen eine andere Sicherheitslogik brauchen

Die SPS lief seit 22 Jahren. Niemand hatte sie je auf Schwachstellen geprüft. Bis ein Angreifer es tat.

Ein mittelgroßer Wasserversorger in Süddeutschland. Drei Pumpstationen, zwei Kläranlagen, eine zentrale Leitwarte. Das SCADA-System war 2003 installiert worden – damals noch vollständig air-gapped, ohne Verbindung nach außen. Im Laufe der Jahre hatte die IT-Abteilung Fernwartungszugänge eingerichtet, einen VPN-Tunnel zur Leitzentrale gelegt, ein HMI-Webinterface für mobile Überwachung aktiviert. Jede Entscheidung für sich war nachvollziehbar. In der Summe hatten sie eine SPS, die seit 22 Jahren nie gepatcht worden war, über das Internet erreichbar gemacht.

Im Rahmen eines beauftragten OT-Pentests fanden wir innerhalb von vier Stunden passiver Netzwerk-Analyse: unverschlüsselte Modbus-Kommunikation auf Port 502, offen erreichbar über einen falsch konfigurierten Firewall-Regelsatz. Kein Passwort. Kein Authentifizierungstoken. Vollständige Lese- und Schreibrechte auf die Ventilsteuerung.

Wir hätten Chlor-Dosierung ändern können. Wir hätten Pumpen abschalten können. Wir hätten Druckwerte manipulieren können, bis Rohre bersten. Wir haben keines davon getan – aber ein Angreifer mit schlechteren Absichten hätte es getan. Und niemand hätte es gemerkt, bis die ersten Haushalte kein Wasser mehr hätten.

OT-Sicherheit ist kein IT-Thema mit anderem Namen. Es ist ein eigenständiges Fachgebiet – mit anderen Protokollen, anderen Prioritäten und einem anderen Schadenspotenzial. Wenn OT-Systeme versagen, versagen physische Prozesse. Maschinen stoppen. Leitungen bersten. Menschen werden gefährdet.

22 J.
Betrieb ohne Sicherheitsprüfung der SPS
4 Std.
Bis zur vollständigen Anlagensteuerung im Pentest
0
Authentifizierungsschritte auf der Modbus-Schnittstelle
∅ $1M+
Stündliche Kosten eines OT-Ausfalls in der Produktion

Warum OT eine andere Sicherheitslogik braucht als IT

In der IT gilt: Confidentiality, Integrity, Availability – in dieser Reihenfolge. Vertraulichkeit zuerst. In der OT ist diese Hierarchie umgekehrt. Verfügbarkeit kommt zuerst – weil eine Pumpe, die nicht läuft, oder ein Ventil, das falsch steht, unmittelbar physischen Schaden anrichten kann. Ein OT-Pentest, der diese Logik ignoriert, ist gefährlich.

Das bedeutet konkret: Ein klassischer IT-Pentest mit aggressivem Netzwerk-Scan kann eine SPS abstürzen lassen. Nicht weil der Scanner bösartig ist – sondern weil viele SPS-Systeme schlicht nicht dafür gebaut wurden, mit der Geschwindigkeit und dem Volumen eines IT-Netzwerkscans umzugehen. Industriesteuerungen aus den 1990er und 2000er Jahren können bei zu vielen gleichzeitigen Verbindungsversuchen in einen undefinierten Zustand geraten – mit direkten Auswirkungen auf die gesteuerten physischen Prozesse.

Klassischer IT-Pentest
IT Security
CIA-Triade · Confidentiality first
Priorität: Vertraulichkeit → Integrität → Verfügbarkeit
Downtime akzeptabel für Sicherheitsgewinn
Patch-Zyklen: Wochen bis Monate
Aggressive Scans und Exploits Standard
Systeme können neugestartet werden
Schaden: Datenverlust, Compliance-Verstoß
OT / ICS Pentest
OT Security
AIC-Triade · Availability first
Priorität: Verfügbarkeit → Integrität → Vertraulichkeit
Downtime kann Menschenleben gefährden
Patch-Zyklen: Jahre bis Jahrzehnte (oder nie)
Passiver Ansatz first – jeder aktive Schritt abgestimmt
Neustart kann Produktionsstopp oder Sicherheitsrisiko bedeuten
Schaden: Produktionsausfall, Umweltkatastrophe, Personenschaden

Diese unterschiedliche Sicherheitslogik bedeutet: ein OT-Pentest erfordert OT-Expertise. Nicht nur Kenntnisse von SCADA-Systemen als Zusatz-Modul – sondern tiefgreifendes Verständnis industrieller Prozesse, Protokolle und der Konsequenzen jedes einzelnen Teststschritts auf die laufende Anlage.

Wo OT-Systeme angreifbar sind: Die vollständige Angriffsfläche

OT-Angriffsflächen haben eine Eigenschaft, die sie von IT-Umgebungen fundamental unterscheidet: sie sind über Jahrzehnte gewachsen, ohne dass Sicherheit je eine primäre Designentscheidung war. Modbus wurde 1979 entwickelt. DNP3 1990. Profibus 1987. Keines dieser Protokolle hat Authentifizierung. Keines hat Verschlüsselung. Sie wurden für zuverlässige Kommunikation in kontrollierten, abgeschlossenen Umgebungen entwickelt – nicht für eine Welt, in der OT-Netze über VPN und Cloud-Dienste mit dem Internet verbunden sind.

Die unsichere Protokoll-Landschaft

Protokoll Einsatz Sicherheitslücken by Design Angriffspotenzial
Modbus TCP/RTU SPS-Kommunikation, Sensoren, Aktuatoren Keine Authentifizierung, kein Encryption, kein Sequenzschutz KRITISCH
DNP3 Energie, Wasserversorgung, SCADA Authentifizierung optional und selten aktiviert; Replay-Angriffe möglich HOCH
Profinet / Profibus Fertigungsanlagen, Automotive Keine native Verschlüsselung; MAC-Spoofing möglich HOCH
OPC Classic (DCOM) HMI-Server-Kommunikation DCOM-Schwachstellen, Windows-Abhängigkeit, veraltete Auth-Mechanismen HOCH
OPC UA Moderne IIoT-Kommunikation Oft Encryption deaktiviert; Zertifikatsverwaltung häufig fehlerhaft MITTEL
IEC 60870-5-104 Energieversorgung, Smart Grid Kein Authentifizierungsmechanismus im Basisstandard HOCH
BACnet Gebäudeautomation, HVAC Offene Broadcast-Discovery; keine Authentifizierung im Standard MITTEL

Die IT/OT-Konvergenz: Die gefährlichste Entwicklung der letzten zehn Jahre

Früher war OT air-gapped. Eine physische Trennung vom IT-Netz schützte die Anlage – nicht weil die Systeme sicher waren, sondern weil niemand von außen herankam. Diese Zeit ist vorbei.

Remote-Monitoring, Predictive Maintenance, Cloud-Anbindung von Historian-Datenbanken, VPN-Zugänge für Servicetechniker – jede dieser Maßnahmen macht die Anlage effizienter. Und jede schafft eine neue Brücke zwischen dem IT-Netz und der Produktionsumgebung. Ein Angreifer, der das IT-Netz kompromittiert hat, braucht diese Brücke nur zu überqueren.

Die häufigste Frage nach einem OT-Incident: „Wie ist der Angreifer ins OT-Netz gekommen?" Die häufigste Antwort: über das IT-Netz. Lateral Movement vom Office-Laptop zur SPS – weil die Segmentierung zwischen IT und OT auf dem Papier existierte, aber in der Firewall-Konfiguration nicht.

Reale Angriffe, reale Konsequenzen

OT-Angriffe sind keine Theorie. Colonial Pipeline 2021: Ransomware im IT-Netz, vorsorglich OT abgeschaltet – fünf Tage Pipelinestillstand, Kraftstoffknappheit an der US-Ostküste, 4,4 Millionen Dollar Lösegeld. Norsk Hydro 2019: Ransomware in der Aluminiumproduktion, 800 Millionen Kronen Schaden, manuelle Steuerung der Anlagen über Wochen. Triton/TRISIS 2017: Malware, die gezielt Safety Instrumented Systems (SIS) angriff – die letzte Schutzebene vor physischen Katastrophen in petrochemischen Anlagen.

Das Ziel von Triton war nicht Datendiebstahl. Das Ziel war, Sicherheitssysteme zu deaktivieren – und damit physische Explosionen oder Freisetzungen gefährlicher Stoffe zu ermöglichen. Das ist die Dimension, um die es bei OT-Security geht.

OT-Pentest ohne Produktionsstopp: Die Methodik

Die häufigste Sorge, wenn wir OT-Pentests ansprechen: „Kann das unsere laufende Produktion gefährden?" Die Antwort ist nein – wenn der Test von Leuten durchgeführt wird, die wissen, was sie tun. Unsere Methodik trennt konsequent zwischen passiven und aktiven Phasen, und jeder aktive Schritt wird vorher mit dem Betriebsteam abgestimmt.

Phase 01
Passive Reconnaissance
Netzwerk-Sniffing, Traffic-Analyse, Asset-Discovery ohne aktive Pakete. Kein Risiko für laufende Systeme.
Phase 02
Asset-Inventar
SPS-Typen, Firmware-Versionen, Protokolle, Netzwerktopologie dokumentieren – Basis für alle weiteren Schritte.
Phase 03
Risikoabstimmung
Gemeinsam mit Betrieb: welche aktiven Tests in welchem Zeitfenster? Wartungsfenster, Testumgebung oder Semi-aktiv?
Phase 04
Kontrollierte Aktivtests
Protokoll-Analyse, Auth-Tests, Segmentierungsprüfung – abgestimmt, dokumentiert, rückrufbar.
Phase 05
Reporting & Remediation
Kritische Findings sofort eskaliert. Abschlussbericht mit Risikobewertung und priorisierter Remediation-Roadmap.

Was wir konkret prüfen

SPS / PLC
Speicherprogrammierbare Steuerungen
Siemens S7 (S7comm, S7comm-Plus), Rockwell/Allen-Bradley, Schneider Electric, ABB, Beckhoff. Authentifizierung, Firmware-Stand, offene Programmierports, unerlaubte Schreibzugriffe.
SCADA / HMI
Leitsysteme & Bedienoberflächen
Webinterfaces, OPC-Server, Historian-Datenbanken, Fernzugänge. Bekannte CVEs, Default-Credentials, Injection-Schwachstellen in HMI-Weboberflächen.
Netzwerk
IT/OT-Segmentierung
Firewall-Regelsätze, DMZ-Konfiguration, erlaubte Cross-Zone-Verbindungen, unerlaubte Brücken zwischen IT- und OT-Netz, VLAN-Hopping-Möglichkeiten.
Protokolle
Industriekommunikation
Modbus, DNP3, Profinet, IEC 60870, OPC UA – Sniffing, Replay-Angriffe, Man-in-the-Middle, Command Injection unter kontrollierten Bedingungen.
Remote Access
Fernwartungszugänge
VPN-Konfiguration, Jump-Server, Wartungszugänge von Drittanbietern, MFA-Enforcement, Session-Monitoring. Häufigster Einstiegspunkt für externe Angreifer.
Wireless
Funkbasierte OT-Kommunikation
WLAN in Produktionsumgebungen, Bluetooth-Sensoren, LoRaWAN, WirelessHART, Rogue Access Points. Oft vergessen, weil „ja nur intern".

Der Goldstandard ist die Kombination: OT-Pentest + Physical Pentest + IT-Pentest als Full-Chain-Szenario. Ein Angreifer, der physisch in eine Anlage eindringt, ein Rogue Device platziert, sich lateral durch das IT-Netz bewegt und schließlich in die SPS pivotiert – das ist das realistische Bedrohungsbild für KRITIS-Betreiber. Und genau das testen wir.

Was NIS2, KRITIS und IEC 62443 von euch fordern

OT-Sicherheit ist längst kein freiwilliges Thema mehr. Mit NIS2 (Dezember 2025) und dem KRITIS-Dachgesetz (Januar 2026) sind OT-Sicherheitsmaßnahmen für Betreiber kritischer Infrastrukturen rechtsverbindlich und mit persönlicher Haftung der Geschäftsleitung verbunden.

  • NIS2 (§ 21): Schreibt „Sicherheit der Lieferkette", „Netzwerksicherheit" und „Sicherheit in der Produktion" explizit vor – inklusive OT-Umgebungen. Erstmeldung eines Vorfalls: 24 Stunden. Sanktion: bis zu 10 Mio. Euro oder 2% des Jahresumsatzes. Persönliche Haftung der Geschäftsleitung.
  • KRITIS-Dachgesetz: Erweitert den Betreiberkreis und schreibt Resilienzpläne vor, die physische und digitale Sicherheit der OT-Infrastruktur einschließen. Nachweispflicht gegenüber dem BSI – ein OT-Pentest-Bericht ist ein anerkannter Nachweis.
  • IEC 62443: Der internationale Standard für OT/ICS-Sicherheit. Definiert Security Levels (SL 1–4) für Zonen und Conduits im OT-Netz. Unsere Berichte sind auf IEC-62443-Compliance ausgerichtet.
  • BSI IT-Grundschutz (ICS-Profil): Konkrete Maßnahmen für industrielle Steuerungsanlagen in Deutschland. Basis für viele KRITIS-Nachweise gegenüber dem BSI.
  • CER-Richtlinie: Erweitert NIS2 um physische Resilienz – OT-Schutz entlang der gesamten Lieferkette, inkl. Zulieferer und Wartungsdienstleister. Relevant für alle, die Teil einer kritischen Lieferkette sind.

Der häufigste Irrtum: „Wir sind kein KRITIS-Betreiber, also gilt das nicht für uns." NIS2 erweitert den Kreis betroffener Unternehmen massiv – auch mittelständische Zulieferer kritischer Infrastrukturen, Pharmaunternehmen, Lebensmittelproduzenten und Logistikdienstleister können betroffen sein. Im Zweifel: prüfen lassen.

Was OT-Pentest von uns konkret bedeutet

OT-Security ist kein Add-on zu unserem Portfolio – es ist ein eigenständiger Kompetenzbereich. Der Unterschied zu einem IT-Dienstleister, der „auch OT macht": Wir kennen Siemens S7comm genauso gut wie Shodan-Dorks auf SCADA-Systeme. Wir wissen, welche SPS-Typen bei zu vielen Verbindungsversuchen einfrieren – und wir wissen es, bevor wir den Test starten, nicht danach.

Unsere OT-Pentests decken das vollständige Spektrum ab – von der rein passiven Analyse für laufende Produktionsanlagen bis zum Full-Chain-Engagement, das physischen Zugang, IT-Netz und OT-Umgebung kombiniert. Wir liefern audit-fähige Berichte für IEC 62443, KRITIS, NIS2 und BSI IT-Grundschutz – und wir eskalieren kritische Findings sofort, nicht erst im Abschlussbericht.

Das Wichtigste: Produktionssicherheit hat für uns immer Vorrang vor dem Testergebnis. Jeder Schritt wird mit eurem Betriebsteam abgestimmt. Kein Test, der nicht rückrufbar ist. Kein Scan, der die Anlage gefährdet.

Ja – wir machen OT-Pentests. Für Energieversorger, Wasserwerke, Fertigungsanlagen, Pharmaunternehmen, Chemie, Lebensmittelproduktion und Transport. Mit Protokoll-Expertise, Prozessverständnis und dem gleichen Ansatz wie echte Angreifer – aber im kontrollierten, sicheren Rahmen.

Fazit: OT-Sicherheit ist kein IT-Thema. Es ist ein Unternehmensrisiko mit physischen Konsequenzen.

Die SPS läuft. Die Anlage produziert. Das SCADA-System zeigt grün. Das ist kein Sicherheitsbeweis – es ist der Normalzustand, in dem ein Angreifer sich unbemerkt vorbereitet. OT-Angriffe sind leise. Sie hinterlassen keine Logeinträge in einem System, das nie für Security-Logging gebaut wurde. Sie werden erst bemerkt, wenn das Ventil nicht mehr reagiert, die Pumpe nicht anläuft oder die Produktion steht.

Ein OT-Pentest ist kein IT-Pentest in einer Fabrikhalle. Er ist eine eigenständige Disziplin – mit eigener Methodik, eigenen Protokollen, eigenem Risikobewusstsein. Wer OT-Systeme betreibt, ohne sie je auf Schwachstellen geprüft zu haben, betreibt ein Risiko, das er nicht sehen kann. Bis jemand anderes es sieht.

Weiterführend: Was ein Breach in der Produktion wirklich kostet, zeigt der Post zu Kosten eines Breaches. Wie Angreifer physisch in Anlagen gelangen, zeigt die Serie zu Visitor Management und Rogue Devices. Und was NIS2 und KRITIS konkret fordern, erklärt der Post zur physischen Compliance.

Wann wurde eure SPS zuletzt auf Schwachstellen geprüft?

Wir führen OT-Pentests durch, ohne eure Produktion zu gefährden – passiv oder aktiv, in Wartungsfenstern oder Paralleltestumgebungen. Kostenloses Erstgespräch.

OT-Audit anfragen →
Tags // #PhysicalPentest #KRITIS #RedTeam #NIS2 #OTPentest #ICS #SCADA #SPS #Modbus #IndustrieSicherheit

© AccessGranted X GmbH