OT-Security für Produktionsunternehmen: IT und OT sicher verbinden

OT-Security für Produktionsunternehmen: IT und OT sicher verbinden
Photo by Simon Kadula / Unsplash

Die fortschreitende digitale Transformation im Produktionsumfeld, insbesondere durch Industrie 4.0-Initiativen, führt zu einer zunehmenden Konvergenz von klassischer Informationstechnologie (IT) und Betriebstechnologie (Operational Technology, OT). Diese Entwicklung eröffnet zwar erhebliche Effizienzpotenziale, schafft jedoch gleichzeitig neue Angriffsvektoren für Cyber-Bedrohungen. Die sichere Integration beider Welten erfordert ein fundiertes Verständnis der spezifischen Anforderungen sowie die Implementierung etablierter Sicherheitsstandards wie dem BSI IT-Grundschutz und der IEC 62443.

Fundamentale Unterschiede: IT-Security vs. OT-Security

Die Absicherung von OT-Umgebungen unterscheidet sich grundlegend von klassischen IT-Sicherheitskonzepten. Während in der IT-Welt die Schutzziele typischerweise in der Reihenfolge Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade) priorisiert werden, kehrt sich diese Hierarchie in OT-Umgebungen wie Produktionsanlagen, SCADA-Systemen und Prozessleittechnik um.

Priorisierung der Schutzziele in der OT-Security

In industriellen Steuerungssystemen (Industrial Control Systems, ICS) und SPS-Umgebungen steht die Verfügbarkeit an oberster Stelle. Produktionsausfälle können binnen Minuten zu erheblichen finanziellen Verlusten führen und im kritischen Infrastrukturbereich sogar Menschenleben gefährden.

Die Integrität der Steuerungsdaten und -befehle folgt als zweites Schutzziel, da manipulierte Prozessparameter zu fehlerhaften Produkten oder gefährlichen Betriebszuständen führen können.

Die Vertraulichkeit ist zwar relevant, steht jedoch nachrangig zu den beiden erstgenannten Schutzzielen.

Technologische Besonderheiten der OT-Security

OT-Systeme weisen spezifische Charakteristika auf, die besondere Sicherheitsmaßnahmen erfordern. Nach den BSI IT-Grundschutz-Bausteinen der Reihe IND (Industrielle IT) sind folgende Aspekte zu berücksichtigen:

  • Langlebigkeit der Systeme: Während IT-Systeme typischerweise Lebenszyklen von 3-5 Jahren aufweisen, bleiben OT-Komponenten oft 15-25 Jahre im Einsatz. Dies erschwert die Implementierung moderner Sicherheitsmaßnahmen erheblich.
  • Echtzeit-Anforderungen: Viele ICS sind auf einen vollständig unterbrechungsfreien Informationsfluss angewiesen. Bereits Verzögerungen im Millisekundenbereich können kritisch sein, was den Einsatz klassischer IT-Sicherheitslösungen wie Deep Packet Inspection limitiert.
  • Proprietäre Protokolle: OT-Netzwerke nutzen häufig industriespezifische Kommunikationsprotokolle (PROFINET, EtherCAT, Modbus TCP), die nicht unter primären Sicherheitsgesichtspunkten entwickelt wurden und oft keine Authentisierung oder Verschlüsselung bieten.
  • Heterogene Systemlandschaften: Produktionsumgebungen bestehen typischerweise aus Komponenten verschiedener Hersteller unterschiedlicher Generationen, was ein einheitliches Sicherheitskonzept erschwert.

Netzwerksegmentierung nach IEC 62443: Zonen und Conduits

Die internationale Normenreihe IEC 62443 etabliert einen risikobasierten Ansatz zur Absicherung industrieller Automatisierungs- und Kontrollsysteme (IACS). Ein zentrales Konzept bildet dabei das Modell der Zonen (Zones) und gesicherten Kommunikationspfade (Conduits).

Zonenkonzept

Eine Zone definiert eine logische Gruppierung von Systemen mit ähnlichen Sicherheitsanforderungen. Im Gegensatz zur physischen Trennung ermöglicht dieses Konzept eine flexible Segmentierung basierend auf:

  • Gemeinsamen Schutzzielen und Security Levels (SL-T)
  • Ähnlichen Bedrohungsszenarien
  • Vergleichbaren Anforderungen an Verfügbarkeit und Latenz
  • Identischen Verantwortlichkeiten und Zuständigkeiten

Die Zonenbildung erfolgt unabhängig von physischen Standorten und kann Systeme über Standortgrenzen hinweg umfassen. Dies ermöglicht moderne Architekturen wie Cloud-basierte Historian-Systeme oder verteilte Produktionsstandorte.

Conduits: Gesicherte Kommunikationspfade

Conduits repräsentieren die kontrollierten Kommunikationsverbindungen zwischen Zonen. Für jeden Conduit sind gemäß IEC 62443 folgende Sicherheitsmaßnahmen zu definieren:

  • Authentisierung und Autorisierung der Kommunikationspartner
  • Verschlüsselung sensitiver Daten
  • Integritätssicherung übertragener Informationen
  • Monitoring und Logging aller Zugriffe
  • Filterung unerwünschten Datenverkehrs

Der BSI IT-Grundschutz-Baustein IND.3.2 "Fernwartung im industriellen Umfeld" konkretisiert diese Anforderungen für OT-spezifische Anwendungsfälle und fordert ein zentrales Fernwartungskonzept für die gesamte OT einer Institution.

Purdue-Modell in der praktischen Umsetzung

Das Purdue Enterprise Reference Architecture Model (Purdue-Modell) strukturiert Industrie- und Automationsnetze hierarchisch in sechs Ebenen (Level 0-5) und dient als Grundlage für die Sicherheitszonierung.

Die Ebenen des Purdue-Modells

Level 0 - Physischer Prozess: Sensoren, Aktoren und die physische Produktionsebene bilden die unterste Schicht. Hier erfolgen Messwerterfassung und direkte Prozesssteuerung ohne Netzwerkanbindung oder mit minimaler Konnektivität.

Level 1 - Intelligente Feldgeräte: Speicherprogrammierbare Steuerungen (SPS), Remote Terminal Units (RTU) und intelligente Feldgeräte übernehmen die lokale Steuerung und Regelung. Diese Ebene weist die höchsten Verfügbarkeitsanforderungen auf.

Level 2 - Prozessleitsysteme: SCADA-Systeme (Supervisory Control and Data Acquisition), Historian-Datenbanken und Bedienoberflächen (HMI) ermöglichen die Überwachung und Steuerung der Produktionsprozesse.

Level 3 - Betriebsführung: Manufacturing Execution Systems (MES), Produktionsplanung und Qualitätssicherungssysteme koordinieren die Fertigung und optimieren Produktionsprozesse.

Level 3.5 - Demilitarisierte Zone (DMZ): Eine kritische Übergangszone zwischen OT- und IT-Netzwerk, in der gemeinsam genutzte Ressourcen wie Datenaustausch-Server, Patch-Management-Systeme oder Fernwartungszugänge platziert werden.

Level 4 - Unternehmenslogistik: Enterprise Resource Planning (ERP)-Systeme, Warenwirtschaft und Logistiksysteme bilden die Geschäftsprozessebene.

Level 5 - Unternehmensnetzwerk: Das klassische Office-IT-Netzwerk mit Arbeitsplatzrechnern, E-Mail-Systemen und Internet-Zugang.

Praktische Implementierung mit IEC 62443

Während das Purdue-Modell eine funktionale Trennung definiert, konkretisiert IEC 62443 die technischen Sicherheitsmaßnahmen für jede Ebene. Die Kombination beider Ansätze ermöglicht eine strukturierte Sicherheitsarchitektur:

  1. Strikte Segmentierung zwischen Levels: Firewalls oder Industrial Security Appliances trennen die Ebenen physisch oder logisch (VLANs).
  2. Minimierung horizontaler Kommunikation: Innerhalb einer Ebene sollte die Kommunikation zwischen verschiedenen Produktionslinien oder Anlagen unterbunden werden (Mikrosegmentierung).
  3. Kontrollierte vertikale Kommunikation: Datenflüsse zwischen den Ebenen erfolgen ausschließlich über definierte Conduits mit entsprechenden Sicherheitskontrollen.
  4. Jump-Server-Konzepte: Für administrative Zugriffe von höheren auf niedrigere Ebenen werden gehärtete Sprungserver (Jump Hosts) eingesetzt.

Der BSI IT-Grundschutz-Baustein IND.1 "Prozessleit- und Automatisierungstechnik" fordert die Erstellung eines aktuellen Netzplans, der Zonen, Zonenübergänge (Conduits) sowie eingesetzte Protokolle und Zuständigkeiten dokumentiert.

Produktionsverfügbarkeit vs. Sicherheit: Der Balanceakt

Die Absicherung von OT-Umgebungen erfordert einen ausgewogenen Ansatz zwischen Sicherheitsanforderungen und Produktionsverfügbarkeit. Dieser Zielkonflikt manifestiert sich in verschiedenen Bereichen:

Patch-Management-Dilemma

Während IT-Systeme typischerweise automatisierte Patch-Prozesse nutzen, erfordert OT ein differenziertes Vorgehen. Die unkontrollierte Installation von Sicherheitsupdates kann zu Produktionsausfällen führen, da:

  • Patches die Funktionalität spezialisierter OT-Software beeinträchtigen können
  • Neustarts von Steuerungssystemen ungeplante Produktionsunterbrechungen verursachen
  • Kompatibilitätsprobleme zwischen verschiedenen Systemkomponenten auftreten

Risikobasierter Ansatz für OT-Security

Die Implementierung eines Informationssicherheits-Managementsystems nach ISO/IEC 27001 bietet einen strukturierten Rahmen für risikobasierte Entscheidungen in der OT-Security. Dabei sind folgende Faktoren zu bewerten:

  • Kritikalität des Systems: Welche Auswirkungen hätte ein Ausfall?
  • Kompensationsmaßnahmen: Können andere Sicherheitskontrollen das Risiko mindern?
  • Wartungsfenster: Existieren geplante Stillstandszeiten für Updates?
  • Segmentierung: Ist das System ausreichend vom Rest der Infrastruktur isoliert?

Ein externer Informationssicherheitsbeauftragter (ISB) kann bei der Entwicklung und Umsetzung solcher risikobasierter Strategien unterstützen und die kontinuierliche Überwachung der Sicherheitsmaßnahmen gewährleisten.

Defense-in-Depth-Strategie

Statt sich ausschließlich auf Patch-Management zu verlassen, empfiehlt die IEC 62443 eine mehrschichtige Verteidigungsstrategie:

  1. Netzwerksegmentierung: Begrenzung der Angriffsfläche durch Zonierung
  2. Zugriffskontrolle: Strikte Authentisierung und Autorisierung
  3. Monitoring: Kontinuierliche Überwachung auf Anomalien
  4. Physische Sicherheit: Zutrittskontrolle zu kritischen Systemen
  5. Security Awareness: Schulung des Personals

Patch-Management in OT-Umgebungen: Besondere Herausforderungen

Die Aktualisierung von OT-Systemen erfordert einen strukturierten Prozess, der die spezifischen Rahmenbedingungen industrieller Umgebungen berücksichtigt.

Herausforderungen und Restriktionen

Legacy-Systeme: Viele OT-Komponenten basieren auf veralteten Betriebssystemen (Windows XP, Windows 2000, proprietäre RTOS), für die keine aktuellen Sicherheitsupdates mehr verfügbar sind. Der BSI IT-Grundschutz-Baustein IND.1 fordert die Dokumentation solcher Restriktionen und die Definition kompensierender Maßnahmen.

Herstellerabhängigkeiten: Im Gegensatz zur IT, wo Patches direkt von Microsoft oder anderen Softwareherstellern bezogen werden, müssen OT-Updates häufig vom Anlagenhersteller validiert und freigegeben werden. Dies kann Monate dauern und erfordert oft kostenpflichtige Wartungsverträge.

Testanforderungen: Jedes Update muss in einer Testumgebung validiert werden, die die Produktionsumgebung möglichst exakt abbildet. Dies ist aufgrund der Heterogenität und Komplexität von OT-Umgebungen oft schwierig und kostenintensiv.

Zeitfenster: Produktionsanlagen laufen häufig im 24/7-Betrieb. Wartungsfenster für Updates sind rar und müssen langfristig geplant werden.

Strukturierter Patch-Management-Prozess

Ein professionelles OT-Patch-Management umfasst folgende Phasen:

1. Inventarisierung: Vollständige Erfassung aller OT-Komponenten mit Software- und Firmwareversionen. Der BSI IT-Grundschutz fordert die Führung eines Bestandsverzeichnisses mit allen relevanten Produkt- und Protokollversionen.

2. Bewertung: Analyse neuer Schwachstellen hinsichtlich ihrer Relevanz für die eigene Umgebung. Nicht jede CVE (Common Vulnerabilities and Exposures) ist tatsächlich ausnutzbar oder kritisch für die spezifische Konfiguration.

3. Priorisierung: Risikobewertung basierend auf:

  • CVSS-Score (Common Vulnerability Scoring System)
  • Kritikalität des betroffenen Systems
  • Verfügbarkeit von Exploits
  • Exposition gegenüber potenziellen Angreifern

4. Test: Validierung in einer separaten Testumgebung vor Produktionseinführung.

5. Implementierung: Koordinierte Ausrollung während geplanter Wartungsfenster.

6. Verifikation: Überprüfung der erfolgreichen Installation und Funktionalität.

7. Dokumentation: Lückenlose Dokumentation aller durchgeführten Maßnahmen.

Kompensatorische Maßnahmen

Wenn Patches nicht zeitnah eingespielt werden können, sind alternative Schutzmaßnahmen zu implementieren:

  • Virtuelle Patches: Industrial Firewalls oder Intrusion Prevention Systems können Angriffsvektoren auf Netzwerkebene blockieren, ohne die Systeme selbst zu modifizieren.
  • Verstärkte Segmentierung: Zusätzliche Netzwerktrennung ungepatchter Systeme.
  • Erweiterte Überwachung: Intensiviertes Monitoring auf verdächtige Aktivitäten.
  • Härtung: Deaktivierung nicht benötigter Dienste und Schnittstellen.

Typische Schwachstellen in SPS und SCADA-Systemen

Die Analyse dokumentierter Sicherheitslücken in OT-Umgebungen zeigt wiederkehrende Muster und Schwachstellen-Kategorien.

Authentisierung und Zugriffskontrolle

Fehlende oder schwache Authentisierung: Viele ältere SPS und SCADA-Systeme verfügen über keine oder nur rudimentäre Authentisierungsmechanismen. Default-Passwörter (oft "admin/admin" oder "1234") bleiben häufig unverändert im Einsatz.

Unzureichende Autorisierung: Granulare Berechtigungskonzepte fehlen oft. Nutzer verfügen über weitreichende Rechte, die über das erforderliche Maß hinausgehen (Verstoß gegen das Least-Privilege-Prinzip).

Hartcodierte Credentials: In Firmware oder Konfigurationsdateien fest einprogrammierte Zugangsdaten, die nicht ohne Weiteres geändert werden können, stellen ein erhebliches Risiko dar.

Netzwerk- und Kommunikationssicherheit

Unverschlüsselte Kommunikation: Viele industrielle Protokolle (Modbus, S7, PROFINET) übertragen Daten und Steuerungsbefehle im Klartext. Dies ermöglicht Man-in-the-Middle-Angriffe und das Mitlesen sensitiver Informationen.

Fehlende Integritätssicherung: Ohne kryptographische Signaturen können Angreifer Steuerungsbefehle manipulieren oder gefälschte Sensordaten einspielen.

Offene Netzwerkdienste: Unnötige aktive Dienste wie Telnet, FTP oder HTTP-Server vergrößern die Angriffsfläche erheblich.

Software- und Firmware-Schwachstellen

Buffer Overflows: Speicherüberläufe ermöglichen die Ausführung von Schadcode und zählen zu den häufigsten kritischen Schwachstellen in OT-Software.

Injection-Schwachstellen: SQL-Injection, Command-Injection oder LDAP-Injection-Angriffe können bei unzureichender Eingabevalidierung zur Kompromittierung von Systemen führen.

Veraltete Bibliotheken: Die Nutzung nicht mehr unterstützter Software-Komponenten mit bekannten Sicherheitslücken ist weit verbreitet.

Spezifische Beispiele dokumentierter Schwachstellen

Die CVE-Datenbank (Common Vulnerabilities and Exposures) dokumentiert zahlreiche kritische Schwachstellen in weit verbreiteten OT-Systemen:

  • CODESYS: In diesem verbreiteten SPS-Programmierframework wurden mehrere kritische Schwachstellen identifiziert, die Remote Code Execution und die vollständige Übernahme von Steuerungen ermöglichten.
  • Siemens SIMATIC: Verschiedene CVEs dokumentieren Schwachstellen in Siemens-Produkten, von Authentication-Bypass bis zu Denial-of-Service-Anfälligkeiten.
  • Schneider Electric: Auch hier finden sich zahlreiche dokumentierte Schwachstellen in verschiedenen Produktlinien.

Mitigationsstrategien

Zur Minimierung dieser Risiken sind folgende Maßnahmen zu implementieren:

  1. Netzwerksegmentierung: Strikte Trennung von Office-IT und OT gemäß Purdue-Modell
  2. Härtung der Systeme: Deaktivierung nicht benötigter Dienste und Funktionen
  3. Verschlüsselung: Wo möglich, Implementierung von VPN-Tunneln oder verschlüsselten Protokollvarianten
  4. Monitoring und Anomalieerkennung: Einsatz spezialisierter OT-Security-Monitoring-Lösungen
  5. Regelmäßige Sicherheitsbewertungen: Durchführung von OT-spezifischen Penetrationstests und Schwachstellenscans
  6. Security-by-Design: Bei Neuanschaffungen Berücksichtigung von Sicherheitsanforderungen gemäß IEC 62443-4-2

Integration von IT und OT: Governance und Organisation

Die erfolgreiche Absicherung der IT-OT-Konvergenz erfordert neben technischen Maßnahmen auch organisatorische und prozessuale Anpassungen.

Verantwortlichkeiten und Rollen

Der BSI IT-Grundschutz definiert für den OT-Bereich spezifische Rollen:

  • ICS-Informationssicherheitsbeauftragter (ICS-ISB): Verantwortlich für die Informationssicherheit im OT-Bereich, mit spezifischem OT-Know-how
  • OT-Betrieb: Verantwortlich für den sicheren und verfügbaren Betrieb der Produktionssysteme
  • IT-Sicherheitsbeauftragter: Bei strategischen Entscheidungen einzubinden, koordiniert übergreifende Sicherheitsmaßnahmen

Diese Rollen sollten eng zusammenarbeiten, wobei klare Verantwortlichkeiten und Eskalationswege definiert sein müssen. Ein externer ISB oder CISO kann diese Koordination übernehmen und die notwendige Brücke zwischen IT- und OT-Expertise bilden.

Compliance und regulatorische Anforderungen

Produktionsunternehmen müssen zunehmend regulatorische Anforderungen erfüllen:

  • NIS2-Richtlinie: Erweiterte Anforderungen an die Cybersicherheit für Betreiber kritischer und wichtiger Einrichtungen
  • IT-Sicherheitsgesetz 2.0: Verschärfte Anforderungen für KRITIS-Betreiber in Deutschland
  • ISO/IEC 27001: Internationaler Standard für Informationssicherheits-Managementsysteme
  • BSI IT-Grundschutz: Deutscher Standard mit praxisorientierten OT-spezifischen Bausteinen

Die Implementierung eines ISMS nach ISO 27001 bietet einen strukturierten Rahmen, um diese Anforderungen systematisch zu erfüllen. Die Integration von OT-spezifischen Bausteinen des BSI IT-Grundschutzes gewährleistet dabei die Berücksichtigung industrieller Besonderheiten.

Incident Response für OT-Umgebungen

Sicherheitsvorfälle in OT-Umgebungen erfordern spezielle Reaktionsprozesse, die sich von klassischen IT-Incidents unterscheiden:

  • Priorisierung der Produktionsverfügbarkeit: Bei der Incident Response steht die Aufrechterhaltung oder schnelle Wiederherstellung der Produktion im Vordergrund
  • Koordination mit Safety-Funktionen: Sicherheitsmaßnahmen dürfen die funktionale Sicherheit (Safety) nicht beeinträchtigen
  • Dokumentationspflichten: Besondere Anforderungen an die Dokumentation für regulatorische Meldepflichten
  • Externe Expertise: Häufig ist spezialisiertes OT-Security-Know-how erforderlich, das intern nicht verfügbar ist

Der BSI IT-Grundschutz-Baustein DER (Detektion und Reaktion) konkretisiert Anforderungen an die Incident Response in OT-Umgebungen.

Handlungsempfehlungen / Roadmap

Die sichere Integration von IT und OT in Produktionsunternehmen stellt eine komplexe Herausforderung dar, die technische, organisatorische und prozessuale Maßnahmen erfordert. Folgende Schritte sollten prioritär umgesetzt werden:

  1. Bestandsaufnahme: Vollständige Erfassung und Dokumentation der OT-Infrastruktur, einschließlich aller Netzwerkverbindungen, Protokolle und Abhängigkeiten
  2. Risikoanalyse: Systematische Bewertung der Bedrohungen und Schwachstellen unter Berücksichtigung der spezifischen Produktionsanforderungen
  3. Netzwerksegmentierung: Implementierung einer strukturierten Zonierung nach Purdue-Modell und IEC 62443 mit kontrollierten Conduits
  4. Patch- und Schwachstellenmanagement: Etablierung strukturierter Prozesse unter Berücksichtigung der OT-spezifischen Restriktionen
  5. Monitoring und Detektion: Implementierung OT-fähiger Security-Monitoring-Lösungen
  6. Organisatorische Verankerung: Klare Zuweisung von Verantwortlichkeiten und Etablierung von Incident-Response-Prozessen
  7. Kontinuierliche Verbesserung: Regelmäßige Überprüfung und Anpassung der Sicherheitsmaßnahmen

Die Komplexität dieser Aufgaben sowie der Mangel an qualifizierten OT-Security-Fachkräften sprechen für die Einbindung externer Expertise. Ein spezialisierte Informationssicherheitsbeauftragter oder CISO mit OT-Erfahrung kann die notwendige Kompetenz bereitstellen und gleichzeitig die Anforderungen verschiedener Regelwerke (NIS2, DSGVO, ISO 27001, BSI IT-Grundschutz) koordiniert adressieren.

Die Investition in umfassende OT-Security-Maßnahmen ist nicht nur aus Compliance-Perspektive geboten, sondern schützt auch die Produktionsverfügbarkeit und damit die Wettbewerbsfähigkeit des Unternehmens. Angesichts der zunehmenden Bedrohungslage und der fortschreitenden Vernetzung ist die sichere IT-OT-Integration kein optionales Projekt mehr, sondern eine geschäftskritische Notwendigkeit.


Häufig gestellte Fragen (FAQ) zu OT-Security

Was ist der Hauptunterschied zwischen IT-Security und OT-Security?

Der fundamentale Unterschied liegt in der Priorisierung der Schutzziele. Während IT-Security typischerweise Vertraulichkeit, Integrität und Verfügbarkeit (CIA) in dieser Reihenfolge priorisiert, steht in der OT-Security die Verfügbarkeit an oberster Stelle, gefolgt von Integrität und Vertraulichkeit. Produktionsausfälle können binnen Minuten zu erheblichen finanziellen Verlusten führen, weshalb Sicherheitsmaßnahmen den laufenden Betrieb nicht beeinträchtigen dürfen. Zudem weisen OT-Systeme deutlich längere Lebenszyklen (15-25 Jahre vs. 3-5 Jahre), Echtzeit-Anforderungen und proprietäre Protokolle auf, die klassische IT-Sicherheitslösungen oft nicht unterstützen.

Warum ist Patch-Management in OT-Umgebungen so komplex?

Patch-Management in OT-Umgebungen unterscheidet sich grundlegend von der IT aus mehreren Gründen: Legacy-Systeme basieren oft auf veralteten Betriebssystemen ohne aktuelle Sicherheitsupdates. Herstellerabhängigkeiten erfordern, dass Updates vom Anlagenhersteller validiert werden, was Monate dauern kann. Verfügbarkeitsanforderungen lassen keine ungeplanten Neustarts zu – Produktionsanlagen laufen häufig im 24/7-Betrieb. Jedes Update muss in einer Testumgebung validiert werden, die die Produktionsumgebung exakt abbildet. Der BSI IT-Grundschutz-Baustein IND.1 fordert daher strukturierte Patch-Management-Prozesse mit Risikobewertung, Test-Phasen und definierten Wartungsfenstern.

Was ist das Purdue-Modell und warum ist es für OT-Security relevant?

Das Purdue Enterprise Reference Architecture Model strukturiert Industrie- und Automationsnetze hierarchisch in sechs Ebenen (Level 0-5): von der physischen Produktionsebene (Sensoren, Aktoren) über SPS und SCADA-Systeme bis zum Unternehmensnetzwerk. Diese Strukturierung ist für OT-Security essentiell, weil sie die Grundlage für Netzwerksegmentierung bildet. Jede Ebene hat spezifische Sicherheitsanforderungen: Je niedriger der Level, desto höher die Verfügbarkeitsanforderungen. Zwischen Level 3 und 4 befindet sich typischerweise eine DMZ (Demilitarisierte Zone), die OT- und IT-Netzwerk trennt. In Kombination mit IEC 62443 ermöglicht das Purdue-Modell eine strukturierte Implementierung von Zonen und Conduits für Defense-in-Depth-Strategien.

Welche typischen Schwachstellen existieren in SCADA-Systemen und SPS?

SCADA-Systeme und SPS weisen charakteristische Schwachstellen auf: Authentisierungsprobleme wie fehlende oder schwache Authentisierung, Default-Passwörter und hartcodierte Credentials sind weit verbreitet. Unverschlüsselte Kommunikation über industrielle Protokolle (Modbus, S7, PROFINET) ermöglicht Man-in-the-Middle-Angriffe. Software-Schwachstellen wie Buffer Overflows, Injection-Schwachstellen und veraltete Bibliotheken bieten Angriffsvektoren. Die CVE-Datenbank dokumentiert zahlreiche kritische Schwachstellen in Frameworks wie CODESYS oder Produkten von Siemens und Schneider Electric. Mitigationsstrategien umfassen strikte Netzwerksegmentierung, Härtung der Systeme, Verschlüsselung wo möglich und spezialisiertes OT-Security-Monitoring.

Was bedeuten Zonen und Conduits in der IEC 62443?

Zonen (Zones) sind nach IEC 62443 logische Gruppierungen von Systemen mit ähnlichen Sicherheitsanforderungen, unabhängig von ihrer physischen Lokalisation. Eine Zone kann beispielsweise alle SCADA-Server umfassen, auch wenn diese an verschiedenen Standorten stehen. Conduits repräsentieren die kontrollierten Kommunikationspfade zwischen Zonen. Für jeden Conduit müssen spezifische Sicherheitsmaßnahmen definiert werden: Authentisierung, Verschlüsselung, Integritätssicherung, Monitoring und Filterung. Dieses Konzept ersetzt starre physische Trennungen durch flexible, risikobasierte Segmentierung und ermöglicht moderne Architekturen wie Cloud-Integration oder standortübergreifende Produktionsnetze. Der BSI IT-Grundschutz-Baustein IND.3.2 konkretisiert diese Anforderungen für deutsche Unternehmen.


Sie benötigen Unterstützung bei Ihrem Vorhaben? Buchen Sie direkt einen Termin für einen unverbindlichen Austausch!