IEC 62443 — OT/IT-Segmentierung in der Praxis

Kunde im Energiesektor, Auditor vor der Tür: „Wie weit sind Sie mit IEC 62443?" Der Kunde antwortet: „Wir haben eine Firewall zwischen Office und Produktion." Das ist nicht IEC 62443. Das ist eine Voraussetzung, die der erste Penetrationstest bricht. Dieser Artikel handelt davon, was es wirklich bedeutet, IEC 62443-3-3 auf ein Niveau zu bringen, das ein Audit besteht und einem realen Angriff standhält.

Warum jetzt — NIS2-Deadline

Die NIS2-Richtlinie (EU 2022/2555) ist für Betreiber wesentlicher Dienste in der EU seit **17. Oktober 2024** verbindlich (in DE umgesetzt über NIS2UmsuCG, in AT über NISG-Novelle). Für **NIS2-Betreiber (Energie, Wasserversorgung, Transport, Gesundheitswesen, Produktion kritisch für die Lieferkette, digitale Infrastruktur)** bedeutet das die Pflicht zu:

• Risk-Management-Framework nach anerkanntem Standard — IEC 62443 ist die De-facto-Referenz für OT.
• Incident Reporting innerhalb von **24 Stunden** nach Detektion eines signifikanten Vorfalls an das BSI (DE) bzw. die nationale Behörde.
• Strafe bis **10 Mio. EUR oder 2 % des Umsatzes**, je nachdem, was höher ist.

DACH-Realität: Das BSI-Audit des ersten NIS2-Jahres (Herbst 2025) zeigte, dass ~70 % der Betreiber wesentlicher Dienste nicht einmal ein Z/C-Modell (Zonen und Conduits) implementiert haben, geschweige denn eine Netzwerksegmentierung, die SL-1 (Security Level 1) entsprechen würde.

Z/C-Modell — Grundlage, die als Erstes gezeichnet wird

IEC 62443-3-2 führt das Konzept der **Zonen (Zones)** und **Conduits** ein. Zone = Gruppe von Assets mit derselben Sicherheitsanforderung. Conduit = kontrollierter Kommunikationskanal zwischen Zonen.

Typisches Z/C-Modell für eine Produktionshalle mit ERP-Anbindung

Z0 — Internet / Untrusted (Wild West). Z1 — Enterprise IT (Büros, ERP, E-Mail). Trust Level Standard. Z2 — DMZ (Webserver, VPN-Endpoint, Jump Servers). Trust Level Stricter. Z3 — Operations Management / Historian / MES (Purdue Level 3). Trust Level OT-Standard. Z4 — SCADA + HMI (Purdue Level 2). Trust Level OT-Strict. Z5 — PLC + Control Devices (Purdue Level 1). Trust Level OT-Critical. Z6 — Field Instrumentation (Purdue Level 0). Trust Level OT-Critical.

Conduits: C0↔1 — Firewall + IDS. ALL deny by default, Ausnahmen für HTTP/HTTPS outbound vom VPN-Endpoint. C1↔3 — OT-IT DMZ mit Reverse Proxy. Historian-Daten read-only Richtung hoch (Z3 → Z1). Keine Befehle Richtung runter. C3↔4 — Diode oder Unidirectional Gateway für SCADA → MES Daten. Keine Steuerbefehle Richtung hoch. C4↔5 — Protocol-Aware Firewall (Tofino Xenon, Hirschmann Eagle One mit DPI für Modbus/TCP, EtherNet/IP, S7Comm).

Wo in der Praxis die OT-IT-Firewall steht

Typischer Streit bei der Implementierung: **wo physisch die OT-IT-Firewall steht**. Drei Varianten:

1. **Zwischen Purdue L2 (SCADA) und L3 (Historian / MES)** — häufigste Lösung. Hier wird eine Hardware-Firewall mit OT-spezifischen Signaturen eingesetzt: Fortinet FortiGate 1000F/2000F mit OT Threat Intelligence, Cisco Industrial Security Appliance ISA-3000, Hirschmann EAGLE40-7G, oder Tofino Xenon (Belden), wenn „fail-secure" gefordert ist. 2. **Zwischen L3 und L4 (Enterprise IT)** — manche Security-Teams bevorzugen diese Schicht, da L3 bereits OT-Zone ist. Funktioniert, aber L3-Systeme (Historian) atmen dann nach IT-Politiken und drücken den Angriff auf Basisdaten. 3. **Beides (Defense in Depth)** — beste Wahl für SL-2+. Zwei Firewall-Schichten, verschiedene Vendor (Fortinet + Palo Alto ist häufiger Mix), kein Single Point of Failure.

Regel: **Conduit zwischen Zonen mit unterschiedlichem Trust Level MUSS einen expliziten Kontrollpunkt haben.** Switch mit VLANs ist kein Conduit. Switch ist Topologie. Conduit braucht L3-L7-Inspektion.

SL-1 vs. SL-2 vs. SL-3 — wo die Grenze liegt

IEC 62443-3-3 definiert 7 Foundational Requirements (FR), jedes mit 4 Stufen (SL-0 bis SL-4). Praxis-Grenze:

SL-1 — protection against casual or coincidental violation

Minimum, das heute jedes Industriesystem haben muss. Konkret:

• Identifikation und Authentifizierung von Benutzern für HMI/Engineering Workstation (Passwort, keine Shared Accounts).
• Access-Control-Schicht (RBAC auf HMI-Ebene — Bediener, Wartung, Ingenieur, Admin).
• Logging von Änderungen (wer hat sich eingeloggt, was geändert, wann).
• USB-Verbot an Engineering-Workstations (BIOS-Level Disable + GPO).
• Antivirus / EDR auf allen Windows-OS-Stationen in OT-Zonen.

Kosten für SL-1 bei mittlerer Produktion (50–100 OT-Stationen): **30–60 k EUR** Infrastruktur + **150–300 Stunden** Engineering.

SL-2 — protection against intentional violation using simple means with low resources

Hier ändert sich der Preis radikal. Konkret SL-2 über SL-1:

• **MFA (Multi-Factor Authentication)** für Privileged Access. Häufigste YubiKey 5 NFC (~55 EUR/Stück × 30 Personen = 1 650 EUR) oder Duo Security (8 EUR/User/Monat).
• **Anti-Malware mit OT-Signaturen** — Nozomi Networks Guardian, Claroty xDome, Dragos Platform, Forescout SilentDefense. Preise: **25–80 k EUR Lizenz/Jahr** je nach Anzahl überwachter Nodes.
• **Netzwerksegmentierung auf VLAN+ACL+Firewall-Ebene**, nicht nur VLAN. Microsegmentation in OT ist relevant, aber rechentechnisch teuer — typischerweise Cisco TrustSec oder Forescout eyeSegment.
• **Verschlüsselung des Management-Traffics** (HTTPS statt HTTP für HMI Web Access, SSH statt Telnet, kein SNMPv2c — nur SNMPv3 mit authPriv).
• **Logging mit SIEM-Integration** — alle Firewall-Logs, IDS-Alerts, Authentifizierungsereignisse gehen ins SIEM. Splunk Enterprise (2–4 EUR/GB/Tag), QRadar, Elastic Security oder Open-Source Wazuh + ELK bei knappem Budget.
• **Backup-/Restore-Prozeduren mit Offline-Kopien.** Immutable Copy, Air Gap, monatliche Recovery-Tests.

Kosten für SL-2: **120–280 k EUR** Infrastruktur + **500–1 000 Stunden** Engineering, plus **15–25 % jährlich** für Maintenance + Threat-Intelligence-Subscription.

SL-3 — protection against intentional violation using sophisticated means with moderate resources

Hier kommt hinzu:

• **NIDS mit Deep Packet Inspection** für OT-Protokolle (Modbus TCP, EtherNet/IP, S7Comm, OPC UA, DNP3) — Nozomi oder Claroty im Advanced-Modus.
• **Active Hardening** — Port Disable an ungenutzten Interfaces, certificate-based Device Authentication, Application Whitelisting (Microsoft AppLocker, Carbon Black Protection).
• **Air-Gapped Engineering Networks** — Engineering-Laptop wird nie gleichzeitig mit OT und IT verbunden.
• **Quartalsweise Red-Team-Exercises.**
• **Detailliert validierter Change-Management-Prozess** — keine Änderung der PLC-Firmware ohne 3-stufige Approval (Engineering, Operations, Security).

Kosten für SL-3 sind diametral anders — **500 k–1,5 M EUR** Infrastruktur + **2 000+ Stunden** Engineering + dediziertes OT-Security-Team (3–5 VZÄ). Das ist das Niveau, das heute hauptsächlich Energieversorgung (Kernkraftwerke, Übertragungsnetze), kritisches Wasser und einige große Chemiewerke erreichen.

NERC CIP — Vergleich für Energiekunden

Für Betreiber im Energiesektor (besonders Übertragungsnetze, Gasnetze) ist auch der US-amerikanische NERC CIP (Critical Infrastructure Protection) relevant. Unterschied zu IEC 62443:

• **NERC CIP-007** (System Security Management): vergleichbar mit IEC 62443-3-3 FR3 + FR4.
• **NERC CIP-005** (Electronic Security Perimeter): definiert „Electronic Security Perimeter" (ESP), der strenger ist als IEC 62443 Zone — erfordert **expliziten Inventar jedes Access Points durch den ESP** und jährliches Review.
• **NERC CIP-010** (Configuration Change Management and Vulnerability Assessments): erfordert Baseline Configuration jedes Control Device, monatliches Vulnerability Assessment. IEC 62443 deckt das in FR2 ab.
• **NERC CIP-008** (Incident Reporting): 1-Stunden-Reporting-Fenster für NERC vs. 24-Stunden für NIS2.

Kunden mit sowohl NERC CIP als auch NIS2 Exposure (typischerweise große paneuropäische Utilities) mappen beide Normen meist auf **ein internes Framework**, das die höhere der beiden Anforderungen erfüllt.

Deep Packet Inspection Modbus TCP — was es wirklich tut

Modbus TCP ist ein SCADA-Protokoll von 1979 (Modbus RTU) mit TCP-Wrapper von 1999. **Keine Authentifizierung, keine Verschlüsselung.** Jedes Gerät im Netzwerk, das Port 502 sieht, kann Write Single Coil (Function Code 5) senden und einen Output flippen.

Eine Deep-Packet-Inspection-Firewall (DPI), z. B. Tofino Xenon oder Fortinet OT-Aware, macht:

• **Read-Only- vs. Read-Write-Unterscheidung**: erlaubt Function Codes 1–4 (Read Coils, Read Registers), verbietet Function Codes 5–6, 15–16 (Write Single/Multiple Coil/Register) aus unautorisierten Quellen.
• **Function Code Filtering**: einige Function Codes (8 — Diagnostic, 17 — Report Slave ID) werden komplett außerhalb des Wartungsfensters gesperrt.
• **Address Whitelisting**: SCADA → PLC-Adressen 1–247 sind erlaubt, außerhalb des Bereichs = Drop + Alert.
• **Rate Limiting**: > 10 Write-Operationen pro Sekunde von einer IP = Anomalie, Alert.

Reale Erkennung eines Angriffs in Modbus TCP über DPI: durchschnittlich **80–95 %** der Basisangriffe (Replay, Command Injection, Address Scanning). Sophisticated Attacks (Stuxnet-like) brauchen **Integrität der PLC-Konfiguration** (HMI sieht denselben Wert, den die PLC sendet), was Aufgabe für NIDS (Nozomi oder Claroty) ist, nicht für die Firewall allein.

„Patches" in OT-Umgebung — erwarten Sie keinen monatlichen Patch Tuesday

In der IT ist die Norm der monatliche Patch Cycle. In OT ist die Norm **2–4 Patch Windows jährlich**, typischerweise:

• **Frühlings-Wartung** (März-April): geplante Outage 5–10 Tage, vollständiges Patching von OS, PLC-Firmware-Update, SCADA-Server-Upgrade.
• **Herbst-Wartung** (September-Oktober): gleicher Scope.
• **Außergewöhnliches Fenster bei kritischem CVE** (CVSS 9+) auf produktiv verfügbaren Services, das 24–72-stündige Response erfordert.

Patch Management in OT erfordert:

• **Test Bed / Digital Twin** — Patches werden zuerst auf duplizierter Hardware oder Simulator (Mimic Simulation Software, Codesys SoftPLC) getestet, nie in Live-Produktion.
• **Compensating Controls** zwischen Patching — falls Patch nicht möglich (Vendor End-of-Life, validiertes System), Kompensation durch Firewall-Regeln, zusätzliche IDS-Überwachung oder Network Isolation.
• **Approved Baseline** — Patch wird nur dann ausgerollt, wenn er Approved im Change-Management-Board ist.

Praktische Schritte für die ersten 90 Tage für einen NIS2-pflichtigen Betreiber

Wenn Sie in einer Position sind, in der das Audit in 6–12 Monaten kommen kann und IEC 62443 nur ein Begriff auf einer PowerPoint-Folie ist:

1. **Inventory Assets** (Monat 1). Passiver Scan des OT-Netzes — Nozomi Guardian Trial, Claroty xDome PoC oder Open-Source GRASSMARLIN/Wireshark + Custom Scripts. Ziel: Liste jeder PLC, jedes HMI, Switch, Drives, Roboters — IP, MAC, Firmware-Version, Vendor. 2. **Draft Z/C Model** (Monat 1–2). Workshop mit OT-Ingenieuren + IT Security + Management. Output: ein Diagramm auf A1, das an die Serverraumwand geklebt wird. 3. **Risk Assessment nach IEC 62443-3-2** (Monat 2). Tabelle: Zone × Threat × Likelihood × Consequence × SL Target. 4. **Prioritäre Conduits zur Implementierung** (Monat 3). Typischerweise erhält C3↔4 (SCADA-MES) und C1↔3 (IT-OT DMZ) den höchsten Score. Am wenigsten häufig C5↔6 (PLC-Field). 5. **Vendor Selection + PoC** (Monat 3). Drei Vendoren, je zwei Wochen in Laborumgebung, Auswahl based on Protocol Coverage + Alerting Accuracy + Price.

Nach 90 Tagen haben Sie ein audit-defensives Dokumentationspaket + eine Roadmap zur Implementierung, die weitere 12–18 Monate für SL-2 / 24–36 Monate für SL-3 dauert.

Häufigste Fehler in DACH-Implementierungen

• **„Wir haben eine Firewall."** Fragen Sie: ist OT-aware Signatur darin? Modbus/S7Comm-Inspektion? Logs gehen ins SIEM? Wenn nicht, haben Sie einen L3-Paketfilter, keine Security Boundary.
• **„Mit VLANs haben wir alles getrennt."** VLAN ohne ACL oder ohne L3-Firewall dazwischen ist nur Broadcast Separation. Ein Angreifer im selben Switch mit VLAN Hopping (DTP/802.1Q Double Tagging) springt darüber in 30 Sekunden.
• **„PLCs sind nicht im Internet."** Nach 6 Monaten finden wir bei jedem Audit mindestens eine PLC, die über ein nicht dokumentiertes 4G-Modem (direkt am Panel für schnelle „Updates von zu Hause") über Shodan erreichbar war.
• **„Der Vendor macht Updates remote über TeamViewer."** TeamViewer / AnyDesk / VNC in OT-Zonen ohne Jump Host und MFA ist Einstiegspunkt für Supply Chain Attack. Ersetzen durch Bastion Host mit Recording (Wallix, BeyondTrust oder Open-Source Apache Guacamole + Audit Log).
• **„Wir haben nichts zu schützen, wir sind eine kleine Firma."** NIS2 gilt auch für **Medium Entities** in der Lieferkette wesentlicher Dienste. Wenn Sie Lieferant für ein großes Utility sind, bringt deren Audit das Audit auch zu Ihnen.

---

*Wir schreiben dies als technischer Partner, der in den letzten 8 Jahren OT-Segmentierung in Energie, Wasserversorgung und Produktion implementiert hat. Wenn Sie ein NIS2-Audit oder eine IEC-62443-Implementierung erwartet, durchläuft die erste Beratung (90 Minuten) Ihr Z/C-Modell, aktuelle Conduits und Roadmap und gibt Ihnen eine realistische Schätzung von CAPEX und Engineering-Stunden für SL-1 oder SL-2 nach Ihrem Risikoprofil.*