Bei Betreibern komplexer Anlagen sorgen SCADA-Systeme (Supervisory Control and Data Acquisition) für das optimale Zusammenspiel von Anlagen, MSR-Einrichtungen und IT. Doch die meisten dort verwendeten Protokolle wurden nicht für Risiken in vernetzten Umgebungen entwickelt. Das wird zunehmend zum Problem für Betreiber. Doch es gibt Lösungen für eine angemessene Cybersicherheit der Operational Technology (OT).
In aller Kürze
- Das Purdue-Modell gibt die Struktur vor, innerhalb derer die Protokolle eines SCADA-Systems kommunizieren. Ein genaues Verständnis dessen ist der erste Schritt zu mehr OT Security.
- Die meisten dieser Protokolle wurden jedoch nicht für vernetzte Umgebungen entwickelt und bieten deshalb keine oder nicht ausreichende Cybersicherheit.
- Die IEC 62443-3-3 empfiehlt für alle gängigen Protokolle in SCADA-Systemen Maßnahmen zur Verringerung von Risiken.
Welches Angriffsszenario ist für SCADA-Systeme problematisch?
Es ist ein Dienstagmorgen. Irgendwo in einem Chemiewerk läuft die Produktion. Ein Mitarbeiter in der IT-Abteilung öffnet eine E-Mail – nichts Ungewöhnliches. Doch die E-Mail enthält Schadsoftware. Der PC ist infiziert.
Bis hierhin: ein klassischer IT-Vorfall.
Doch drei Stunden später beginnen Ventile in der Produktion, sich unerwartet zu öffnen. Die Ursache: Das SCADA-System war über das gleiche Netzwerksegment erreichbar wie der infizierte Büro-PC. Kein Angreifer musste eine Tür aufbrechen. Er kannte einfach die Protokolle.
Genau das ist die Frage, die dieser Artikel beantwortet: Welche Protokolle nutzen SCADA-Systeme – auf welcher Ebene des Purdue-Modells – und was bedeutet das für die OT Security?
Was ist das Purdue-Modell?
Das Purdue-Modell (auch: Purdue Enterprise Reference Architecture, PERA) ist ein Schichtenmodell, das industrielle Steuerungsumgebungen in sechs Ebenen (Level 0 bis Level 5) gliedert. Es beschreibt, welche Systeme auf welcher Ebene angesiedelt sind – und damit auch, welche Kommunikation zwischen diesen Ebenen stattfindet.
Die Grundidee: Je tiefer die Ebene, desto näher an der physischen Anlage – und desto kritischer jede Kommunikation, die dort ankommt.
Das Purdue-Modell ist in der IEC 62443-3-2 als Referenzarchitektur verankert und bildet die Grundlage für die Zonierung von OT-Umgebungen.
Was sind die sechs Ebenen des Purdue-Models – und was wird dort kommuniziert?
Level 0 – der physische Prozess: Sensoren, Aktoren, Maschinen
Hier passiert das Eigentliche: Motoren drehen sich, Ventile öffnen und schließen, Temperaturen werden gemessen. Sensoren melden Zustände, Aktoren führen Befehle aus.
Die Kommunikation auf dieser Ebene ist hochgradig spezialisiert. Es handelt sich fast ausschließlich um Feldbusprotokolle – oft proprietär, oft ohne eingebaute Sicherheitsfunktionen:
- PROFIBUS – klassischer Feldbus, weit verbreitet in der Prozessindustrie
- PROFINET – der Ethernet-basierte Nachfolger, inzwischen dominant in der Fertigungsautomation
- EtherNet/IP – in der amerikanischen Fertigungsindustrie weit verbreitet
- Modbus RTU – uralt, simpel, noch immer in zahllosen Anlagen aktiv
Was das bedeutet: Diese Protokolle wurden für Zuverlässigkeit und Geschwindigkeit entwickelt – nicht für Sicherheit. Authentifizierung? Fehlt. Verschlüsselung? Nicht vorgesehen. Wer auf dieser Ebene Befehle senden kann, steuert die Anlage direkt.
Level 1 – Basissteuerung: SPS, RTU, DCS-Controller
Auf Level 1 sitzen die Speicherprogrammierbaren Steuerungen (SPS), Remote Terminal Units (RTU) und DCS-Controller. Sie empfangen Messwerte von Level 0 und senden Steuerbefehle zurück. Gleichzeitig kommunizieren sie nach oben mit dem SCADA-System auf Level 2.
Die Protokolle auf dieser Ebene sind der Kern des Problems – und der Grund, warum SCADA-Sicherheit so komplex ist:
- Modbus TCP – die TCP/IP-Variante des klassischen Modbus. Keine Authentifizierung, jeder, der eine TCP-Verbindung aufbauen kann, kann Befehle senden.
- PROFINET – schnell und weit verbreitet, aber ursprünglich ohne Sicherheitsfeatures konzipiert.
- S7-Protokoll (Siemens) – proprietäres Protokoll für Siemens-SPS. Bekannt aus dem Stuxnet-Angriff, bei dem genau dieses Protokoll ausgenutzt wurde.
- DNP3 – vor allem in der Energieversorgung und Wasseraufbereitung eingesetzt. Neuere Versionen unterstützen Authentifizierung (Secure Authentication v5), ältere Installationen laufen oft noch ohne.
- IEC 60870-5-104 – das TCP/IP-Pendant zu IEC 60870-5-101, typisch in der Energieautomation. Ebenfalls ohne eingebaute Verschlüsselung.
- OPC UA – der moderne Standard. Unterstützt Authentifizierung und Verschlüsselung. Wird zunehmend eingesetzt, aber noch nicht flächendeckend.
Was das bedeutet: Ein Angreifer, der Level 1 erreicht, kann in vielen Anlagen direkt mit SPS kommunizieren – ohne Passwort, ohne Zertifikat, ohne Protokoll. Das ist die Realität in Tausenden von Industrieanlagen heute.
Level 2 – Überwachung und Bedienung: Das SCADA-System
Level 2 ist die Heimat des SCADA-Servers, der HMI-Workstations (Human Machine Interface) und des OT-Historians. Hier werden Prozessdaten visualisiert, Alarme verwaltet und Bedienereingriffe durchgeführt.
Der SCADA-Server ist der zentrale Kommunikationsknoten: Er spricht nach unten mit den SPS (Level 1) und nach oben mit dem MES oder der IT (Level 3 und 4).
Protokolle auf Level 2:
- OPC UA – bevorzugter Standard für die Kommunikation zwischen SCADA und SPS. Mit Zertifikaten und TLS-Verschlüsselung kann er sicher betrieben werden.
- OPC DA (klassisch) – der Vorgänger, basiert auf Windows DCOM. Sicherheitstechnisch problematisch, sollte ersetzt werden.
- SCADA-HMI-Protokolle – oft herstellerspezifisch (z. B. Wonderware, Ignition, WinCC). Kommunikation zwischen HMI und SCADA-Server läuft über proprietäre oder HTTPS-basierte Verbindungen.
- SQL / Historian-API – der SCADA-Server schreibt Prozessdaten in den Historian. Je nach Hersteller über SQL-Verbindungen oder proprietäre APIs.
Was das bedeutet: Level 2 ist die kritischste Ebene aus Sicherheitsperspektive. Wer den SCADA-Server kompromittiert, hat Sicht auf die gesamte Anlage und kann – je nach Konfiguration – Steuerbefehle an alle angebundenen SPS senden.
Level 3 – OT-Betriebsführung: MES und Produktionsmanagement
Auf Level 3 arbeiten Manufacturing Execution Systems (MES) und andere produktionsnahe IT-Systeme. Sie kommunizieren mit dem SCADA-Server, um Produktionsaufträge zu übergeben, Qualitätsdaten abzurufen und Berichte zu erstellen.
Protokolle auf Level 3:
- OPC UA – zunehmend der Standard für die Kommunikation zwischen MES und SCADA. Mit TLS und Zertifikaten sicher betreibbar.
- MQTT über TLS – leichtgewichtiges Publish-Subscribe-Protokoll, zunehmend für IoT- und MES-Anbindungen genutzt.
- HTTPS REST-APIs – moderne MES-Systeme kommunizieren über standardisierte Web-APIs.
Was das bedeutet: Level 3 ist die erste Ebene, auf der IT-Sicherheitsstandards wirklich greifen können. Wer hier OPC UA mit Zertifikaten und MQTT mit TLS einsetzt, schafft eine nachvollziehbare, verschlüsselte Kommunikation.
Industrial DMZ – die Pufferzone zwischen IT und OT
Die Industrial Demilitarized Zone (IDMZ) ist keine Ebene im klassischen Sinne, aber der wichtigste Sicherheitsbaustein im Purdue-Modell. Sie trennt die OT-Welt (Level 0–3) von der IT-Welt (Level 4–5).
In der IDMZ befinden sich:
- Jump Host / Remote Access Gateway – der einzige erlaubte Einstiegspunkt für Fernwartung
- Historian-Replikat / Datentransferdienst – repliziert Prozessdaten in die IT-Welt, ohne direkte Verbindung zwischen den Netzen
Protokolle in der IDMZ:
- RDP / SSH über Jump Host – Fernwartungszugriffe laufen ausschließlich über den Jump Host, werden protokolliert und aufgezeichnet
- HTTPS / TLS, SFTP – für den Datentransfer zwischen OT-Historian und IT-Welt
- OPC UA (repliziert) – Historian-Daten werden in der IDMZ repliziert und erst von dort in die IT übergeben
Was das bedeutet: Die IDMZ ist das Nadelöhr. Kein Datenverkehr fließt direkt zwischen IT und OT. Alles wird gebrochen, geprüft und protokolliert. Wer die IDMZ weglässt, verbindet IT und OT direkt – und schafft genau die Situation aus dem Eingangsbeispiel.
Level 4 und 5 – Unternehmens-IT und externe Netze
Level 4 ist die klassische IT: ERP, Active Directory, E-Mail, Office. Level 5 sind externe Netze – Fernwartungspartner, Cloud-Dienste, Internet.
Protokolle auf diesen Ebenen:
- VPN mit MFA / TLS – für den kontrollierten Zugriff externer Partner
- HTTPS / TLS – für Reporting und Datenaustausch
- SFTP – für gesicherten Dateitransfer
Was das bedeutet: Auf diesen Ebenen gelten klassische IT-Sicherheitsstandards. Das Problem entsteht, wenn diese Ebenen ohne ausreichende Trennung mit der OT-Welt verbunden werden.
Wie lassen sich Protokolle anhand der IEC 62443 absichern?
Die meisten Protokolle, die heute in OT-Umgebungen laufen, wurden nicht für Sicherheit entwickelt. Modbus, PROFIBUS, S7, DNP3, IEC 60870-5-104 – sie alle stammen aus einer Zeit, in der Industrieanlagen physisch isoliert waren. Netzwerkverbindungen gab es nicht. Angriffe von außen waren kein wirkliches Risiko.
Das hat sich geändert. Heute sind Industrieanlagen mit IT-Netzwerken verbunden, oft mit dem Internet, manchmal mit der Cloud. Die Protokolle sind geblieben.
Die IEC 62443 – insbesondere IEC 62443-3-3 – antwortet darauf mit klaren Anforderungen:
| Protokoll | Sicherheitsstatus | Empfehlung |
|---|---|---|
| Modbus TCP | Keine Authentifizierung, keine Verschlüsselung | Nur in isolierten Segmenten, Zugang streng kontrollieren |
| PROFINET | Begrenzte Sicherheitsfeatures | Netzwerksegmentierung, Monitoring |
| S7 (Siemens) | Proprietär, ältere Versionen unsicher | Neuere S7-1500 mit Schutzstufen nutzen |
| DNP3 | Ohne Secure Authentication v5 unsicher | Upgrade auf SA v5 oder Protokollfilter |
| IEC 60870-5-104 | Keine eingebaute Verschlüsselung | TLS-Wrapper oder Protokollfilter |
| OPC UA | Sicher wenn korrekt konfiguriert (TLS + Zertifikate) | Bevorzugter Standard für neue Installationen |
| MQTT über TLS | Sicher | Für IoT- und MES-Anbindungen geeignet |
Die IEC 62443 formuliert es klar: Kommunikation zwischen Ebenen des Purdue-Modells darf nur über definierte Conduits (Zonenübergänge oder Kommunikationswege) mit restriktiven Regeln stattfinden. Direkte Verbindungen von der Unternehmens-IT oder dem Internet zur SCADA-Zone oder zu Steuerungen sind zu vermeiden.
Das klingt einfach. In der Praxis scheitern viele Anlagen genau daran – weil historisch gewachsene Netzwerke diese Trennung nie hatten, weil Fernwartungsverbindungen ohne IDMZ eingerichtet wurden, weil Protokolle wie Modbus TCP über Netzwerkgrenzen hinweg erreichbar sind.
Der Angreifer aus dem Eingangsbeispiel brauchte keine Schwachstelle in der SPS. Er brauchte nur ein flaches Netzwerk und die Kenntnis eines Protokolls, das seit 1979 unverändert ist.
Was sollten Betreiber tun, um ihre SCADA-Systeme zu schützen?
Wenn Sie eine Anlage betreiben, in der SCADA-Systeme mit SPS kommunizieren, stellen Sie sich als erstes drei Fragen:
- Welche Protokolle laufen in meiner Anlage? Viele Betreiber wissen das nicht genau. Eine Asset-Inventarisierung nach IEC 62443-2-1 ist der erste Schritt.
- Wer kann diese Protokolle erreichen? Wenn ein Büro-PC im gleichen Netzwerksegment wie ein SCADA-Server sitzt, ist die Antwort: potenziell jeder, der den PC kompromittiert. Netzwerksegmentierung nach IEC 62443-3-2 schafft Abhilfe.
- Werden Kommunikationen protokolliert? Modbus TCP sendet keine Logs. OPC UA kann so konfiguriert werden, dass jeder Zugriff protokolliert wird. IEC 62443-3-3 fordert Audit-Logging für sicherheitsrelevante Kommunikation (SR 2.8).
Wie kann activeMind Betreiber bei der OT Security ihrer SCADA-Netzwerke unterstützen?
Wenn wir Betreiber industrieller Anlagen bei der OT Security unterstützen, identifizieren wir im Rahmen einer GAP-Analyse nach TRBS 1115 Teil 1 alle sicherheitsrelevanten Komponenten im SCADA-Netzwerk – von HMI und Historian bis zu den Kommunikationsverbindungen zwischen Leitebene und Feldgeräten.
Anschließend definieren wir gemeinsam mit dem Betreiber auf Basis der IEC 62443-3-2 ein Zonenmodell mit Conduits, das die SCADA-Systeme logisch segmentiert und kritische Datenflüsse absichert.
Ihre Vorteile:
- Mit unserer spezialisierten Softwarelösung activeMind.cloud dokumentieren Sie Assets, Risiken und Maßnahmen digital und an einem Ort. So entsteht eine lückenlose Nachweisführung, die jeder ZÜS-Prüfung standhält.
- Bei rechtlichen Fragen zur Betreiberverantwortung nach BetrSichV oder zur Haftung bei Sicherheitsvorfällen steht die angeschlossene Kanzlei activeMind.legal ergänzend zur Verfügung.
SCADA-Systeme rechtkonform und sicher zu gestalten, überfordert viele interne Teams. Gerne unterstützen unsere Experten Sie dabei. Vereinbaren Sie jetzt ein kostenfreies Erstgespräch!
Fazit: OT Security beginnt mit dem Verständnis der Protokolle
Wer SCADA-Systeme schützen will, muss verstehen, was sie sprechen. Und wer versteht, was sie sprechen, erkennt sofort: Die meisten dieser Protokolle sind auf Vertrauen ausgelegt – auf das Vertrauen, dass nur autorisierte Geräte im Netzwerk sind.
Dieses Vertrauen herzustellen ist die Aufgabe von Zonenarchitektur, Conduits, Netzwerksegmentierung und Zugangskontrolle – zusammengefasst in der IEC 62443.
Das Purdue-Modell gibt die Struktur vor. Die Protokolle zeigen, wo die Risiken liegen. Und die Norm gibt die Antwort darauf.