Wasser- und Abwasserversorgungsunternehmen betreiben kritische Infrastrukturen (KRITIS), bei denen Cyberangriffe direkte Auswirkungen auf die öffentliche Gesundheit, die Umweltsicherheit und die Kontinuität der Gemeinschaft haben können. Traditionelle IT-Sicherheitsmodelle für Unternehmen, die der Vertraulichkeit Priorität einräumen und stark auf eine zentralisierte, weiche Perimetersicherheit setzen, versagen in Operational Technology (OT)-Umgebungen. Wassersysteme zeichnen sich durch hochgradig verteilte, geografisch entlegene Anlagen (Pumpstationen, Hebewerke, Dosierstationen) aus, die über eingeschränkte Telemetrieverbindungen, veraltete unauthentifizierte serielle/IP-Protokolle und enge physisch-cyberphysische Regelkreise verbunden sind.

Die Standardenreihe ISA/IEC 62443 bietet einen risikobasierten Rahmen auf Ingenieursniveau, der speziell für industrielle Automatisierungs- und Steuerungssysteme (IACS) entwickelt wurde. Dieser Artikel bietet ein umfassendes Konzept für CISOs von Wasserversorgern, OT-Architekten und SCADA-Ingenieure zur Modellierung, zum Entwurf, zur Implementierung und zum Betrieb einer partitionierten Defense-in-Depth-Architektur gemäß IEC 62443. Durch die Einrichtung eines präzisen System Under Consideration (SuC), die Aufteilung der Umgebung in logische Zonen und Conduits, die Durchsetzung von Security Levels (SL) auf der Grundlage detaillierter Risikoanalysen und die Ausrichtung der Kontrollen an den sieben Foundational Requirements (FRs) können Wasserversorger Angriffsflächen minimieren und laterale Bewegungen in ihren Systemen verhindern.

Warum Wasserversorger ein anderes Verteidigungsmodell benötigen

OT-Umgebungen in der Wasserwirtschaft weisen spezifische physische, betriebliche und architektonische Merkmale auf, die sie von der Unternehmens-IT und anderen Industriesektoren unterscheiden.

Prozesscharakteristika und physische Auswirkungen

Wasserversorger umfassen zwei Hauptbetriebsbereiche:

Wasseraufbereitung und -verteilung: Umfasst Rohwasserentnahmen, Koagulation/Flockung, Sedimentation, Filtration (Membran/Sand), Desinfektion (Chlorgas, Natriumhypochlorit, UV, Ozon), Reinwasserbehälter, Hauptpumpwerke, Hochbehälter und Verteilungsnetze.

Abwassererfassung und -behandlung: Umfasst Abwasserhebewerke, Zulaufrechen, Sandfang, Vorklärung, biologische Stufe (Belebtschlammverfahren, Tropfkörper), Nachklärung, anaerobe Schlammfaulung und Vorflutereinleitung.

Ein Ausfall oder eine böswillige Manipulation innerhalb dieser Prozesse verursacht physische Schäden und nicht nur Datenverlust:

Manipulation der Chemikalien-Dosierung: Die Veränderung von Sollwerten in automatisierten Chemikalien-Dosiersystemen (wie Natriumhydroxid zur pH-Wert-Einstellung, Chlor/Natriumhypochlorit zur Desinfektion, Fluorkieselsäure) kann zur Verteilung toxischer Chemikalien in städtische Trinkwassernetze oder zu einem biologischen Absterben in der Abwasserreinigung führen.

Manipulation von Pumpen und Ventilen: Das schnelle Takten von Frequenzumrichtern (VFD) oder das abrupte Schließen von Absperrventilen in der Ferne führt zu zerstörerischen Druckstößen (hydraulischen Stoßwellen), die Transportleitungen reißen lassen, Pumpendichtungen zerstören oder Kavitation in Pumpen verursachen können.

Verlust von Sichtbarkeit und Kontrolle: Das Ausblenden von Prozessdaten an der zentralen Mensch-Maschine-Schnittstelle (HMI) bei gleichzeitiger unbemerkter Änderung der Programmable Logic Controller (PLC)-Logik kann dazu führen, dass Reinwasserbehälter trockenlaufen oder Speicherbehälter überlaufen, was die umliegende kommunale Infrastruktur überschwemmt.

Umweltverschmutzung: Die Deaktivierung von Zulaufhebewerken oder Belüftungsgebläsen in Kläranlagen führt zu ungeklärten Abwassereinleitungen direkt in lokale Gewässer, was massive Umweltschäden und regulatorische Strafen nach sich zieht.

IEC 62443 als Fundament

Die Norm ISA/IEC 62443 bietet einen strukturierten Lifecycle-Ansatz zur Absicherung industrieller Automatisierungs- und Steuerungssysteme (IACS). Um die Verteidigung effektiv zu modellieren, muss ein Wasserversorger verstehen, wie die einzelnen Teile der Norm ineinandergreifen.

Struktur der Kernnormen

IEC 62443-1-1 (Begriffe und Modelle): Definiert die Kernterminologie, einschließlich System Under Consideration (SuC), Zonen, Conduits und Security Levels.

IEC 62443-2-1 (Anforderungen an ein Sicherheits-Managementsystem für IACS-Betreiber): Beschreibt die Anforderungen an die Einrichtung eines OT-Cybersecurity-Managementsystems (CSMS), das Richtlinien, Risikomanagement, Personal und Betriebssicherheit umfasst.

IEC 62443-2-4 (Anforderungen an das IT-Sicherheitsprogramm von IACS-Dienstleistern): Spezifiziert die Anforderungen an Systemintegratoren und Wartungsdienstleister, die Integrations- und Supportleistungen für Wasserversorger erbringen.

IEC 62443-3-2 (Sicherheitsstufen und Zonen-/Conduit-Entwurf): Schreibt die Methodik für die Aufteilung eines IACS in Zonen und Conduits, die Durchführung von Risikoanalysen und die Zuweisung von Target Security Levels ($\text{SL-T}$) vor.

IEC 62443-3-3 (Systemanforderungen an die IT-Sicherheit und Sicherheitsstufen): Spezifiziert die technischen System-Sicherheitsanforderungen (SRs) in Verbindung mit den sieben Foundational Requirements (FRs) zur Erreichung definierter Sicherheitsstufen.

IEC 62443-4-1 (Anforderungen an den Lebenszyklus für eine sichere Produktentwicklung): Definiert die Herstellerkompetenzen für sichere Produktlebenszyklus-Prozesse von Hardware, Software und PLC-Firmware.

IEC 62443-4-2 (Technische Sicherheitsanforderungen an IACS-Komponenten): Detailliert die Sicherheitsanforderungen auf Komponentenebene (SL-C), die für PLCs, RTUs, HMIs, Netzwerkschalter und Firewalls erforderlich sind.

Die Verantwortungmatrix des Ökosystems

Cybersecurity in einem Wasserversorgungsunternehmen kann nicht vollständig an Technologiehersteller oder Systemintegratoren delegiert werden. Die IEC 62443 teilt die Verantwortung auf drei primäre Stakeholder auf:

Erstellung des System Under Consideration (SuC)

Vor der Einrichtung von Sicherheitszonen muss ein Wasserversorger sein System Under Consideration (SuC) gemäß IEC 62443-3-2 definieren. Das SuC legt die genaue Grenze der zu bewertenden und zu sichernden IACS-Umgebung fest.

Praktische Methodik zur SuC-Definition

Warum automatisierte Asset-Erkennung allein nicht ausreicht

Passive Tools zur Netzwerküberwachung und aktive Scanner identifizieren IP-Adressen, MAC-Adressen, Firmware-Versionen und offene Ports. Sie sind jedoch nicht in der Lage, den Prozesskontext, Sicherheitsverriegelungen und die betriebliche Kritikalität aufzuzeigen.

Beispielsweise kann ein aktiver Scanner zwei identische Modbus-fähige PLCs identifizieren. Erst die kontextbezogene Prozessabbildung zeigt, dass PLC-A die Rückspülgebläse steuert (geringe kritische Auswirkung), während PLC-B die Natriumhypochlorit-Dosierung direkt vor dem Reinwasserbehälter regelt (katastrophale kritische Auswirkung). Die SuC-Definition muss technische Asset-Inventare mit R&I-Fließschemata (Rohrleitungs- und Instrumentenfließschemata) und Beschreibungen der Betriebssteuerung verknüpfen.

Modellierung des Wasserversorgers mittels Zonen und Conduits

Die IEC 62443-3-2 erfordert die Aufteilung des SuC in logische Gruppen, die als Zonen bezeichnet werden und ausschließlich über explizit definierte Kommunikationspfade, sogenannte Conduits, miteinander kommunizieren.

Zone: Eine logische oder physische Gruppierung von Cyber-Assets, die gemeinsame Sicherheitsanforderungen, betriebliche Kritikalität und Risikoprofile teilen. Eine Zone hat definierte physische und logische Grenzen.

Conduit: Eine spezialisierte Zone, die zwei oder mehr Zonen verbindet und alle Kommunikationskanäle kapselt, die zwischen ihnen verlaufen. Conduits setzen Sicherheitsrichtlinien, Zugriffskontrollen und Datenflussbeschränkungen durch.

Unten ist eine beispielhafte, für Wasserversorger spezifische Zonen- und Conduit-Architektur dargestellt, die auf zentrale Aufbereitungsanlagen und geografisch verteilte Fernwirk-Assets zugeschnitten ist.

Modellierung der Conduits

Ein Conduit muss als strikte Zugriffsgrenze behandelt werden. Jedes Conduit, das eine Zonengrenze kreuzt, erfordert eine technische Durchsetzung von Richtlinien (in der Regel Stateful Firewalls, industrielle Sicherheitskomponenten oder unidirektionale Datendioden). 

Protokoll-Deep-Dive und Einschränkungen der Mikrosegmentierung

Generische Firewalls, die mit „ALLOW TCP 502“ (Modbus TCP) konfiguriert sind, lassen Steuerungen anfällig für Angriffe. Industrielle Conduits müssen Deep Packet Inspection (DPI) erzwingen, um Protokoll-Payloads bis hin zu Funktionscodes und Speicherregisteradressen zu überprüfen.

Modbus TCP (Port 502): Unauthentifiziert, unverschlüsselt. Conduits müssen den Modbus-Verkehr von SCADA zu PLC auf Lese-Funktionscodes beschränken (z. B. `0x01` Read Coils, `0x03` Read Holding Registers). Schreib-Funktionscodes (`0x05` Write Single Coil, `0x10` Write Multiple Registers) müssen streng auf autorisierte IP-Adressen der Leitwartenebene beschränkt und bei anderweitiger Erzeugung gemeldet werden.

DNP3 (Port 20000) / IEC 60870-5-104 (Port 2404): Weit verbreitet für die Telemetrie entlegener Pumpstationen. Ältere Implementierungen übertragen im Klartext. Conduits, die WAN-Verbindungen im Feld durchqueren, müssen DNP3 Secure Authentication (SA v5) vorschreiben oder den Datenverkehr in IPSec/TLS-Tunneln mit hardwaregestützter Zertifikatsauthentifizierung kapseln.

OPC UA (Port 4840): Bevorzugt für die Kommunikation zwischen Leitwarte, Prozessdatenarchiv (Historian) und verschiedenen Zonen. Conduits müssen OPC-UA-Sicherheitsprofile vorschreiben, die eine Verschlüsselung mit `Basic256Sha256` oder `Aes128_Sha256_RsaOaep` mit gegenseitiger X.509-Zertifikatsvalidierung nutzen. Der Modus `None` muss global untersagt werden.

Risikoanalyse und Sicherheitsstufen (Security Levels)

IEC 62443-3-2 schreibt einen risikobasierten Ansatz zur Zuweisung von Security Levels (SL) für Zonen und Conduits vor. Die Norm definiert drei verschiedene Arten von Sicherheitsstufen:

1. Target Security Level (SL-T): Die angestrebte Sicherheitsstufe, die einer bestimmten Zone oder einem Conduit auf der Grundlage einer Risikoanalyse zugewiesen wird.

2. Achieved Security Level (SL-A): Die tatsächlich erreichte Sicherheitsstufe, die durch die implementierten architektonischen Kontrollen und Gegenmaßnahmen bereitgestellt wird.

3. Capability Security Level (SL-C): Die inhärenten Sicherheitsfunktionen, die standardmäßig in eine IACS-Komponente oder ein System integriert sind (gemäß IEC 62443-3-3 / 4-2).

Definitionen der Sicherheitsstufen (IEC 62443-1-1 / 3-3)

SL 1: Schutz gegen unbeabsichtigte oder zufällige Verletzung der Sicherheit.

SL 2: Schutz gegen vorsätzliche Verletzung mit einfachen Mitteln, geringen Ressourcen, allgemeinen Fähigkeiten und geringer Motivation.

SL 3: Schutz gegen vorsätzliche Verletzung mit anspruchsvollen Mitteln, mäßigen Ressourcen, IACS-spezifischen Kenntnissen und mäßiger Motivation.

SL 4: Schutz gegen vorsätzliche Verletzung mit hochentwickelten Mitteln, beträchtlichen Ressourcen, IACS-spezifischen Kenntnissen und hoher Motivation (z. B. staatliche Akteure).

Beispiel: Risikoanalyse und SL-T-Bestimmung für ein Chemikalien-Dosiersystem

Zuweisung eines SL-T für die Chemikalien-Dosierzone einer Wasseraufbereitungsanlage mit einer Kapazität von 190.000 m³ pro Tag (50 MGD):

Schritt 1: Auswirkungsanalyse

Szenario: Ein Angreifer manipuliert die PLC-Analogausgangsregister, die die Dosierpumpen für Natriumhypochlorit (Desinfektion) und Natriumhydroxid (pH-Wert-Einstellung) steuern.

Auswirkung: Überdosierung führt zu toxischer Verunreinigung im Verteilungssystem; Unterdosierung führt zur Belastung mit pathogenen Erregern (wie Cryptosporidium, Giardia, E. coli).

Schweregrad: Katastrophal (Sicherheit & öffentliche Gesundheit); unmittelbare Gefahr für Menschenleben und langfristiger Verlust des öffentlichen Vertrauens.

Schritt 2: Bewertung der Bedrohungskompetenz

Bedrohungsvektor: Angreifer nutzen eine verwundbare Fernwartungsverbindung eines Herstellers aus, wechseln auf den SCADA-Server und senden unauthentifizierte Befehle über industrielle Protokolle an die Dosier-PLC.

Wahrscheinlichkeit: Hohes Risiko aufgrund von veralteten Fernwartungsverbindungen.

Schritt 3: SL-T-Zuweisung

Da die Auswirkungen direkt die öffentliche Gesundheit katastrophal gefährden und der Bedrohungsvektor mäßiges bis hohes IACS-Spezialwissen erfordert.

Transformation der IEC 62443 in ein echtes Defense-in-Depth-Konzept

IEC 62443-3-3 definiert sieben grundlegende Anforderungen (Foundational Requirements, FRs), die das Rückgrat der technischen IACS-Sicherheit bilden. Unten aufgeführt ist eine umfassende Kontrollmatrix, die diese FRs in konkrete Maßnahmen für einen Wasserversorger übersetzt.

Modellierung der Angriffsfläche

Um das Architekturmodell zu validieren, muss ein Wasserversorger potenzielle Bedrohungsvektoren gegen seine Zonen und Conduits evaluieren. Im Folgenden sind drei klassische Bedrohungsvektoren in der Wasserwirtschaft aufgeführt, und es wird gezeigt, wie eine IEC-62443-Architektur den Angriffspfad unterbricht.

Angriffspfad 1: Überwindung der IT-Grenze hin zum zentralen SCADA-System

· Initialer Zugriff: Eine Spear-Phishing-E-Mail kompromittiert die Workstation eines Verwaltungsmitarbeiters in der Enterprise-IT-Zone.

· Laterale Bewegung (unsegmentiert): Der Angreifer scannt das Unternehmens-Subnetz, identifiziert offene SMB/RDP-Ports direkt auf dem SCADA-Server und wechselt direkt dorthin.

· Eingrenzung nach IEC 62443: Die Enterprise-Zone ist von der zentralen SCADA-Zone durch eine OT-DMZ getrennt. Direktes IP-Routing zwischen IT und SCADA ist blockiert. Der Angreifer erreicht den OT-DMZ-Jump-Host, der eine hardwarebasierte MFA (FR1) erfordert. Der Angreifer kann den zweiten Faktor nicht bereitstellen, wodurch die laterale Bewegung an der DMZ-Grenze gestoppt wird.

Angriffspfad 2: Kompromittierter Laptop eines Dienstleisters modifiziert PLC-Logik

· Initialer Zugriff: Der Techniker eines externen Chemikalienlieferanten schließt einen mit Schadsoftware infizierten Wartungslaptop direkt an einen Ethernet-Port im Gebäude einer Wasseraufbereitungsanlage an.

· Laterale Bewegung: Die Schadsoftware scannt das lokale Subnetz nach ungeschützten PLCs ab und sendet unauthentifizierte Schreibbefehle, um die PLC-Ablaufsteuerung (AWL/KOP) zu ändern.

· Eingrenzung nach IEC 62443: Physische Switch-Ports erfordern eine 802.1X-Netzwerkzugriffskontrolle, die an vom Betreiber verwaltete Zertifikate gekoppelt ist (FR1). Nicht erkannte Geräte werden einem Quarantäne-VLAN ohne Routing zugewiesen. Zudem müssen die Dosier-PLCs manuell über einen physischen Schlüsselschalter in den Modus `REMOTE PROGRAMMING` versetzt werden, bevor Logik-Downloads akzeptiert werden (FR3), was automatisierte Logik-Überschreibungen neutralisiert.

Angriffspfad 3: Laterale Bewegung über Mobilfunkanbindung einer Außenstation

· Initialer Zugriff: Ein Angreifer öffnet physisch den unüberwachten Schaltschrank eines abgelegenen Abwasserhebewerks, verbindet sich mit der seriellen/Ethernet-Schnittstelle der RTU oder kompromittiert den Mobilfunkrouter.

· Laterale Bewegung: Der Angreifer versucht, sich rückwärts über die Mobilfunk-WAN-Verbindung des Feldes in den zentralen SCADA-Kern vorzuarbeiten.

· Eingrenzung nach IEC 62443: Die Zone des abgelegenen Pumpwerks ist über ein dediziertes Telemetrie-Conduit mit der Zentrale verbunden. Der zentrale VPN-Konzentrator erzwingt strenge Firewall-Regeln, die nur DNP3-Protokollverkehr (TCP 20000) an den dedizierten Telemetrie-Front-End-Prozessor (FEP) zulassen. Direkter IP-Zugriff auf zentrale Engineering-Workstations, HMIs oder das Unternehmensnetzwerk wird am Gateway explizit verworfen (FR5).

Entwurf der Referenzarchitektur

Unten ist eine praktische Referenzarchitektur dargestellt, die ein IEC-62443-Verteidigungsmodell für ein mittleres bis großes Wasserversorgungsunternehmen abbildet.

Architektonische „Never-Connect“-Regeln

Um die strukturelle Integrität zu wahren, schreibt die Referenzarchitektur explizite Verbindungsverbote vor:

· Verbinden Sie PLCs/RTUs der Ebene 1/0 NIEMALS direkt mit den IT-Netzwerken des Unternehmens oder dem Internet.

· Erlauben Sie NIEMALS Dual-Homed-Systeme, die eine direkte Brücke zwischen der Enterprise-IT-Zone und der Ebene-3-SCADA-Zone bilden, ohne eine OT-DMZ dazwischenzuschalten.

· Routen Sie unverschlüsselte Industrieprotokolle im Klartext (Modbus TCP, DNP3-Klartext) NIEMALS über öffentliche Mobilfunk- oder unverschlüsselte Funknetze.

· Nutzen Sie NIEMALS gemeinsame Identitätsspeicher (z. B. Active Directory) für die Unternehmens-IT und OT-Umgebungen. Die OT muss eine dedizierte, nicht vertrauenswürdige Active-Directory-Gesamtstruktur (Identity Forest) unterhalten.

Mehrstufige Defense-in-Depth (Tiefenverteidigung)

Eine wirksame Tiefenverteidigung erfordert die Überlagerung von acht verschiedenen funktionalen Sicherheitsebenen über alle definierten Zonen und Conduits hinweg.

· Ebene 1 — Physische Sicherheit: Hochsicherheitszäune, physische Einbruchmeldesensoren an den Luken abgelegener Hebewerke, plombierte Schlösser an PLC-Schaltschränken und Videoüberwachung an kritischen Entnahmebauwerken.

· Ebene 2 — Netzwerksicherheit: Mikrosegmentierung von Zonen, DPI-Firewalls zur Durchsetzung von Conduits nach dem Least-Privilege-Prinzip, Deaktivierung nicht genutzter Switch-Ports und VLAN-Isolierung.

· Ebene 3 — Systemsicherheit: Härtung des Betriebssystems (Deaktivierung nicht benötigter Dienste/Protokolle), vom OT-Hersteller validiertes Patch-Management und Application Whitelisting (Default-Deny-Ausführung) auf HMIs und Engineering-Workstations (EWS).

· Ebene 4 — Identitäts- und Zugriffskontrolle: Zentralisiertes OT Active Directory, hardwarebasierte MFA für den Fernzugriff, rollenbasierte Zugriffskontrolle (RBAC) und Privileged Access Management (PAM) mit Sitzungsaufzeichnung.

· Ebene 5 — Anwendungs- / Steuerungsebene: Härtung der SCADA-Software, HMI-Grenzwerte zur Durchsetzung gültiger numerischer Sollwertbereiche (z. B. Abweisung einer Chemikaliendosierung oberhalb definierter Schwellenwerte) und physische Schlüsselschalter an PLCs.

· Ebene 6 — Erkennung: Passive OT-Netzwerküberwachungssensoren auf TAP/SPAN-Ports, kontinuierliche Erstellung von Verhaltens-Baselines und zentralisierte Protokollaggregation in einem OT-fähigen SIEM.

· Ebene 7 — Reaktion: Erprobte Incident-Response-Playbooks für die OT, automatisierte Firewall-Eingrenzungsregeln, definierte betriebliche Eskalationspfade und manuelle Notbetriebsverfahren (Failover).

· Ebene 8 — Wiederherstellung: Offline gehaltene, unveränderliche, physisch getrennte Backups von SCADA-Datenbanken, HMI-Projekten und PLC-Original-Logikdateien (Golden Master); validierte Bare-Metal-Wiederherstellungspläne.

Fernzugriff und Risikomanagement für Drittanbieter

Der Fernzugriff von Herstellern und Dienstleistern stellt einen der primären Angriffsvektoren für kritische Infrastrukturen dar. Die IEC 62443 verlangt, den Fernzugriff nicht bloß als Netzwerkverbindungsproblem zu betrachten, sondern als eine dedizierte, streng kontrollierte Zonen- und Conduit-Architektur.

Betriebliche Regeln für den sicheren Zugriff von Drittanbietern

1. Keine permanenten Verbindungen: VPN-Verbindungen von Herstellern müssen standardmäßig deaktiviert sein („Always-Off“) und dürfen nur bei Bedarf für definierte Wartungsfenster freigeschaltet werden.

2. Explizite Genehmigung durch den Anlagenbediener: Selbst mit gültigen Zugangsdaten kann sich eine Sitzung erst dann verbinden, wenn ein Anlagenbediener die aktive Anfrage manuell in der SCADA-Oberfläche freigibt.

3. Zeitlich begrenzter, temporärer Zugriff: Zugriffsberechtigungen laufen nach einem festgelegten Zeitfenster (z. B. 2 Stunden) automatisch ab. Verlängerungen erfordern eine erneute Autorisierung.

4. Vollständige Sitzungsaufzeichnung: Alle RDP- und SSH-Sitzungen von Drittanbietern müssen in Videoauflösung aufgezeichnet und für Audit- und Forensik-Zwecke archiviert werden.

OT-Überwachung und -Erkennung

Herkömmliche IT-Intrusion-Detection-Systeme (IDS) basieren auf Signaturdateien und erwarten häufige Verbindungszustandsänderungen. Passive OT-Netzwerküberwachungstools arbeiten zerstörungsfrei über Netzwerk-TAPs oder Switch-SPAN-Ports, um Verhaltens-Baselines industrieller Protokolle zu erstellen.

Incident Response: IT-Eingrenzung vs. OT-Eingrenzung

Eingrenzungsstrategien in IT-Umgebungen basieren häufig auf der schnellen Isolierung von Systemen, dem Herunterfahren von Subnetzen oder dem Beenden von Prozessen. In der Wasserwirtschaft kann die Anwendung von IT-Eingrenzungslogik zu katastrophalen betrieblichen Ausfällen führen.

Beispiel für ein Response-Playbook: Kompromittierte Engineering Workstation (EWS)

1. Sicherheitsüberprüfung: Anlagenbediener überprüfen unverzüglich die physischen Prozessparameter (Füllstände der Reinwasserbehälter, Netzdruck, Dosierraten) anhand lokaler Schalttafelanzeigen und unabhängiger, fest verdrahteter Messgeräte.

2. Logischen Conduit isolieren: Blockieren des Conduits C-2 (EWS zu Ebene-1-PLCs) an der DPI-Firewall. Die EWS darf nicht sofort ausgeschaltet werden, um Beweise im flüchtigen Arbeitsspeicher (RAM) zu sichern.

3. Schlüsselschalter der Steuerungen umlegen: Manuelles Umschalten aller Feld-PLCs auf den Modus `RUN` (Deaktivierung der Fernprogrammierung) an allen Aufbereitungsstationen.

4. Festverdrahtete Rückfallebene aktivieren: Wenn eine HMI-Manipulation erkannt wird, werden die Prozessstationen über physische Hand-Aus-Auto-Schalter (HOA) am Steuerschrank in den lokalen Handbetrieb versetzt.

5. Forensische Untersuchung & Wiederherstellung: Erstellung eines forensischen Abbilds der EWS. Neuinstallation der Workstation von vertrauenswürdigen Offline-Medien, Installation verifizierter Software und Durchführung eines kryptografisch signierten Vergleichs der PLC-Logik mit den Golden-Master-Backups.

Kennzahlen-Framework: KPIs und KRIs

Ein Cybersecurity-Managementsystem für Wasserversorger muss die Leistung anhand expliziter Zielvorgaben messen.

Implementierungs-Roadmap (0–24 Monate) und Governance RACI-Matrix

Die Implementierung einer IEC-62443-Architektur in einem Wasserversorgungsunternehmen erfordert ein phasenweises Vorgehen, bei dem die Risikominderung vor der Anschaffung neuer Technologien Vorrang hat.

10 typische Fehler von Wasserversorgern bei der Implementierung der IEC 62443

· Behandlung der IEC 62443 als einmalige Compliance-Checkliste: Betrachtung der Norm als statisches Audit anstatt als kontinuierlicher Engineering- und Betriebslebenszyklus-Prozess.

· Strukturierung von Zonen rein nach der Netzwerktopologie: Einteilung von Zonen ausschließlich auf Basis bestehender IP-Subnetze statt einer Gruppierung von Assets nach betrieblicher Prozesskritizität und Sicherheitsauswirkungen.

· Willkürliche Zuweisung von Target Security Levels ($\text{SL-T}$): Festlegung eines pauschalen $\text{SL-T} = 3$ für das gesamte Versorgungsunternehmen, ohne die detaillierten Risikoanalysen durchzuführen, die nach IEC 62443-3-2 erforderlich sind, was zu einem untragbaren betrieblichen Mehraufwand führt.

· Vertrauen auf IT-Firewalls ohne industrielle Deep Packet Inspection (DPI): Durchleitung von rohem Modbus-TCP- oder DNP3-Verkehr durch Firewalls, ohne die Protokoll-Funktionscodes und Payload-Grenzen zu überprüfen.

· Vernachlässigung verteilter Außenstationen: Absicherung der zentralen Wasseraufbereitungsanlage, während unüberwachte Hebewerk-RTUs über unverschlüsselte Mobilfunkverbindungen angebunden bleiben.

· Gemeinsame Active-Directory-Domänen für IT und OT: Verwendung von Unternehmens-Zugangsdaten für die Anmeldung am OT-SCADA-System, wodurch kompromittierte Unternehmens-Arbeitsplätze (z. B. durch Phishing) sofort Administratorrechte in der OT erhalten.

· Übermäßiges Vertrauen in passive Überwachung als kompensierende Maßnahme: Einsatz passiver Netzwerkanomalieerkennung in flachen, unsegmentierten Netzwerken mit offenen physischen USB- und Switch-Ports.

· Gewährung dauerhafter VPN-Zugänge für Hersteller: Bereitstellung permanenter, unüberwachter Zugriffskanäle für externe OEMs, anstatt zeitlich begrenzte, vom Bediener genehmigte Jump-Host-Architekturen zu implementieren.

· Vernachlässigung der physischen Sicherheit an Außenstationen: Implementierung anspruchsvoller Software-Sicherheitskontrollen, während die Steuerschränke im Feld unverschlossen und mit Standard-Generalschlüsseln zugänglich bleiben.

· Anwendung von IT-Incident-Response-Verfahren auf Prozessumgebungen: Ausschalten von HMIs oder Trennen ganzer Netzwerkverbindungen während eines Vorfalls, ohne die physische Sicherheit, hydraulische Auswirkungen oder die Verfügbarkeit lokaler manueller Steuerungen zu prüfen.

Praktische Checkliste für die Implementierung und den finalen Sicherheitslebenszyklus

Ein resilientes Cybersecurity-Programm für Wasserversorger basiert auf einem kontinuierlichen Regelkreis:

Verifizierungs-Checkliste  

[ ] SCHRITT 1: DEFINITION DER SYSTEMGRENZEN

    [ ] System Under Consideration (SuC) explizit dokumentiert.

    [ ] Alle IT/OT-Schnittstellen, Gateways für den Fernzugriff und Feldverbindungen erfasst.

[ ] SCHRITT 2: SEGMENTIERUNG & CONDUITS

    [ ] OT-DMZ implementiert; keinerlei direktes IP-Routing zwischen der Corporate IT und der Ebene-3-OT.

    [ ] Kritische Prozessbereiche (Chemikalien-Dosierung, Entnahme) in eigenständige Zonen isoliert.

    [ ] Firewalls zur Durchsetzung von Conduits nutzen Deep Packet Inspection (DPI) für OT-Protokolle.

[ ] SCHRITT 3: IDENTITÄTS- UND ZUGRIFFSKONTROLLE

    [ ] Dedizierte, isolierte Active-Directory-Domäne für die OT eingerichtet.

    [ ] Multi-Faktor-Authentifizierung (MFA) für alle Fernzugriffskanäle erzwungen.

    [ ] Zugriff von Drittanbietern über einen Privileged Access Management (PAM) Jump-Host geroutet.

[ ] SCHRITT 4: SYSTEM- UND ANWENDUNGSHÄRTUNG

    [ ] Application Whitelisting auf allen HMIs und Engineering Workstations aktiviert.

    [ ] Physische Schlüsselschalter an PLCs im Normalbetrieb auf RUN-Modus eingestellt.

    [ ] Nicht genutzte physische Switch-Ports deaktiviert; 802.1X im Betrieb erzwungen.

[ ] SCHRITT 5: ERKENNUNG & WIEDERHERSTELLUNG

    [ ] Passive OT-Sicherheitsüberwachungssensoren an den zentralen TAP/SPAN-Ports installiert.

    [ ] Backups von SCADA, HMI und PLC-Logik in offline gehaltenen, physisch getrennten, unveränderlichen Speichern gesichert.

    [ ] OT-spezifische Incident-Response-Playbooks jährlich in Tabletop-Übungen erprobt.

Referenzen und Quellenverzeichnis

1. ISA/IEC 62443-1-1:2018 — *Security for industrial automation and control systems — Part 1-1: Terminology, concepts and models.*

2. ISA/IEC 62443-2-1:2009 — *Security for industrial automation and control systems — Part 2-1: Establishing an industrial automation and control system security program.*

3. ISA/IEC 62443-3-2:2020 — *Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design.*

4. ISA/IEC 62443-3-3:2013 — *Security for industrial automation and control systems — Part 3-3: System security requirements and security levels.*

5. ISA/IEC 62443-4-2:2019 — *Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components.*

6. CISA Water and Wastewater Sector Cybersecurity Services — *Cybersecurity and Infrastructure Security Agency (CISA), Water Sector Guidance.*

7. NIST Special Publication 800-82 Revision 3 — *Guide to Operational Technology (OT) Security*, National Institute of Standards and Technology.

8. AWWA G430-13 — *Security Practices for Operation and Management*, American Water Works Association.

9. AWWA J100-10 — *Risk and Resilience Management of Water and Wastewater Systems*, American Water Works Association.

10. Shieldworkz – IEC 62443-basierte Leitfäden zur Behebung von Schwachstellen