Ot Penetration Testing Wasser Sicherheit: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

OT-Penetration-Testing in Wasserwerken, Pumpstationen, Aufbereitungsanlagen und Verteilnetzen folgt nicht den Regeln klassischer IT-Tests. In Office-Netzen ist ein Scan mit hoher Parallelität oft nur eine Frage von Performance und Logging. In einer Wasseranlage kann dieselbe Vorgehensweise Kommunikationsmodule überlasten, SPS-Zyklen beeinflussen, serielle Gateways destabilisieren oder HMI-Verbindungen abbrechen lassen. Genau deshalb beginnt ein sauberer Test nicht mit Tools, sondern mit Prozessverständnis.

Die Wasserversorgung ist ein physischer Prozess. Rohwasserentnahme, Aufbereitung, Dosierung, Filtration, Druckhaltung, Speicherbewirtschaftung und Verteilung hängen an Steuerungslogik, Sensorwerten und Kommunikationspfaden. Ein Fehler im Test kann nicht nur ein Gerät neu starten, sondern eine Kaskade auslösen: Messwertverlust, falsche Regelung, Alarmflut, manuelle Umschaltung, Betriebsunterbrechung. Wer OT testet, muss daher immer die Frage beantworten: Welche technische Aktion kann welchen betrieblichen Effekt erzeugen?

Ein professioneller Ansatz trennt strikt zwischen Sichtbarkeit, Validierung und Ausnutzung. Sichtbarkeit bedeutet: Asset-Lage, Kommunikationsbeziehungen, Protokolle, Firmwarestände, Fernwartungswege und Trust-Beziehungen verstehen. Validierung bedeutet: Schwachstellen kontrolliert nachweisen, ohne den Prozess zu gefährden. Ausnutzung bedeutet in OT fast nie „maximaler Exploit“, sondern ein minimalinvasiver Beleg, der Risiko und Auswirkung nachvollziehbar macht. Genau an dieser Stelle unterscheidet sich ein belastbarer OT-Test von rein toolgetriebenem Vorgehen.

In Wasserumgebungen kommen häufig ältere SPS-Generationen, proprietäre Engineering-Stationen, Windows-Systeme mit langen Patchzyklen, Funk- oder Richtfunkstrecken, Mobilfunkrouter, unmanaged Switches und historisch gewachsene Fernwirkinfrastrukturen zusammen. Dazu kommen Protokolle wie Modbus/TCP, OPC, OPC UA, IEC-104 in Randbereichen, serielle Tunnel oder herstellerspezifische Engineering-Protokolle. Wer die Grundlagen vertiefen will, findet ergänzende Einordnung unter Ot Security, während der Unterschied zwischen klassischer IT und Anlagenumgebungen besonders deutlich bei Unterschied It Und Ot Security Wasser Sicherheit wird.

Ein weiterer Punkt ist die Zieldefinition. In Wasseranlagen geht es selten darum, „Domain Admin“ zu erreichen. Relevanter ist, ob ein Angreifer von einer Fernwartungsverbindung in die Prozesszone gelangt, ob Sollwerte manipulierbar sind, ob Alarme unterdrückt werden können, ob Historian-Daten verfälscht werden oder ob eine SPS ohne Authentisierung angesprochen werden kann. Ein Test muss daher entlang realistischer Angriffswege aufgebaut werden: externer Zugang, Dienstleisterzugang, IT-zu-OT-Übergang, Engineering-Zugang, Feldkommunikation, Leitwarte, Fernwirkstation.

Saubere OT-Penetration-Tests in der Wasserversorgung sind damit immer eine Kombination aus Technik, Betriebsabstimmung und Risikodisziplin. Ohne Freigabefenster, Rückfallplan, Kommunikationsmatrix und klare No-Go-Zonen wird aus einem Sicherheitstest schnell selbst ein Betriebsrisiko. Genau deshalb ist die Vorbereitungsphase oft aufwendiger als die eigentliche technische Durchführung.

Vor jedem Test steht die Modellierung der Anlage. Dazu gehört nicht nur ein Netzplan, sondern ein Betriebsmodell. Welche Stationen fördern, welche dosieren, welche speichern, welche melden nur? Welche SPS steuert direkt Aktoren, welche dient nur als Datensammler? Welche HMI ist lokal, welche zentral? Welche Verbindungen sind permanent, welche werden nur bei Wartung aktiviert? Ohne diese Antworten bleibt jeder Test blind.

In der Praxis ist die Dokumentation oft unvollständig. Netzpläne zeigen VLANs, aber keine realen Routing-Ausnahmen. Firewall-Regeln existieren, aber temporäre Wartungsfreigaben wurden nie zurückgebaut. Engineering-Laptops sind nicht inventarisiert. Externe Integratoren nutzen VPN-Zugänge, die auf dem Papier deaktiviert sind, technisch aber noch funktionieren. Deshalb muss ein OT-Test immer mit einer Verifikation der Realität beginnen. Das kann passive Traffic-Analyse, Konfigurationssichtung, Interviews mit Betrieb und Instandhaltung sowie punktuelle Live-Validierung umfassen.

Besonders wichtig ist die Zonierung. Typische Wasserumgebungen enthalten Office-IT, DMZ, Leitwarte, Historian, Engineering, Fernwirknetz, lokale Anlagenzellen und Feldgeräte. Die eigentliche Frage lautet nicht nur, ob diese Zonen existieren, sondern ob sie wirksam getrennt sind. Ein Layer-3-Übergang mit Any-Any-Regeln ist keine Segmentierung. Ein VPN direkt auf eine SPS ist keine Fernwartungsarchitektur. Ein Jump Host ohne Protokollierung ist kein Kontrollpunkt. Für vertiefende Strategien zur Trennung von Bereichen sind Ot Netzwerk Segmentierung Wasser Sicherheit und Industrielle Firewalls Wasser Sicherheit praxisnah anschlussfähig.

Ebenso relevant sind Prozessabhängigkeiten. Ein Test gegen eine scheinbar unkritische Pumpstation kann indirekt die Druckhaltung in einem Versorgungsgebiet beeinflussen. Ein Neustart eines Kommunikationsprozessors kann dazu führen, dass die Leitwarte veraltete Werte anzeigt. Ein HMI-Ausfall während einer Dosierphase kann Personal in den Handbetrieb zwingen. Deshalb wird vor Testbeginn festgelegt, welche Systeme nur passiv betrachtet, welche kontrolliert aktiv geprüft und welche ausschließlich in Labor- oder Wartungsfenstern getestet werden.

• Kritische Assets zuerst nach Prozesswirkung klassifizieren, nicht nach IP-Adresse oder Betriebssystem.
• Kommunikationspfade zwischen Leitwarte, Engineering, Fernwartung und Feldgeräten vollständig nachvollziehen.
• No-Go-Bereiche definieren: Safety-nahe Komponenten, Live-Regelkreise, instabile Altgeräte, serielle Gateways ohne Redundanz.

Ein häufiger Fehler ist die Annahme, dass nur die zentrale Leitwarte relevant sei. Tatsächlich entstehen viele Risiken an den Rändern: schlecht geschützte Außenstationen, Mobilfunkrouter mit Standardkonfiguration, lokale Panels ohne Authentisierung, Engineering-Zugänge über Dienstleister oder Notebook-Bridges zwischen IT und OT. Gerade in verteilten Wasserinfrastrukturen ist die Fläche der Angriffsoberfläche oft größer als in kompakten Produktionsanlagen.

Wer diese Vorarbeit sauber erledigt, reduziert nicht nur das Betriebsrisiko des Tests, sondern erhöht auch die Aussagekraft der Ergebnisse. Ein Befund ist nur dann wertvoll, wenn klar ist, in welchem Prozesskontext er steht und welche Kette von Voraussetzungen für eine reale Ausnutzung nötig wäre.

Die meisten realistischen Angriffspfade in Wasserumgebungen beginnen nicht direkt an der SPS, sondern an Übergängen. Fernwartung ist dabei regelmäßig der wichtigste Einstiegspunkt. VPN-Gateways, Mobilfunkrouter, Fernwartungsportale, TeamViewer-ähnliche Lösungen, herstellerspezifische Remote-Services und schlecht kontrollierte Jump Hosts bilden die Brücke zwischen externen Netzen und der Prozesswelt. Wenn Mehrfaktor-Authentisierung fehlt, Konten geteilt werden oder Sitzungen nicht protokolliert sind, entsteht ein direkter operativer Angriffsweg.

Die Leitwarte ist die zweite große Angriffsfläche. SCADA-Server, Historian, Alarmserver, Datenbankdienste und HMI-Clients sind oft Windows-basiert und damit für klassische Schwachstellen, Fehlkonfigurationen und Identitätsangriffe anfällig. Entscheidend ist aber nicht nur die einzelne Schwachstelle, sondern die Frage, ob von dort aus Steuerbefehle, Rezepturen, Sollwerte oder Alarmparameter verändert werden können. Ergänzende technische Hintergründe finden sich unter Scada Security Wasser Sicherheit und Ot Security Scada Sicherheit.

Auf SPS-Ebene sind die Risiken anders gelagert. Viele Steuerungen vertrauen implizit dem Netz. Wenn ein Host das richtige Protokoll spricht und erreichbar ist, akzeptiert die SPS Lese- oder Schreiboperationen, Stop/Run-Befehle, Uploads oder Diagnosen. Die konkrete Ausnutzbarkeit hängt vom Hersteller, der CPU-Serie, Schutzstufen, Passwortkonzepten und der Engineering-Architektur ab. In Wasseranlagen sind besonders problematisch: ungeschützte Programm-Uploads, fehlende Schreibsperren, gemeinsam genutzte Engineering-Stationen und nicht dokumentierte Service-Schnittstellen. Tiefergehende Betrachtungen dazu liefern Plc Security Wasser und Plc Hacking Wasser.

Feldkommunikation ist oft der am meisten unterschätzte Bereich. Modbus/TCP ist in Wasseranlagen weiterhin weit verbreitet, weil es einfach, interoperabel und historisch gewachsen ist. Genau diese Einfachheit ist das Problem: keine eingebaute Authentisierung, keine Integritätssicherung, keine Vertraulichkeit. Wer im richtigen Netzsegment sitzt, kann Register lesen und unter Umständen schreiben. Das bedeutet nicht automatisch, dass jede Anlage sofort manipulierbar ist, aber es bedeutet, dass Netzpositionierung und Segmentierung zur primären Schutzmaßnahme werden. Für Protokollrisiken und Schutzansätze sind Modbus Sicherheit Wasser und Modbus Sicherheit Best Practices relevant.

Hinzu kommen Nebensysteme: Zeitsynchronisation, Backup-Server, Patch-Server, Antivirus-Management, Domänencontroller in OT-nahen Bereichen, Drucker, Kameras, Zutrittskontrollsysteme oder IoT-Komponenten. In vielen Vorfällen war nicht das Kernsystem der erste Einstieg, sondern ein Randgerät mit schwacher Konfiguration. Von dort aus erfolgte laterale Bewegung in Richtung Leitwarte oder Engineering.

Ein belastbarer Test betrachtet deshalb immer die gesamte Kette: externer Zugang, Authentisierung, Segmentierung, Identitäten, Protokolle, Steuerbarkeit und Nachweis der Prozesswirkung. Nur so lässt sich unterscheiden, ob ein Befund ein theoretisches Problem oder ein realer Betriebshebel ist.

Die wichtigste Fähigkeit im OT-Pentest ist nicht Exploit-Entwicklung, sondern Zurückhaltung. In Live-Wasseranlagen gilt: Jeder aktive Test muss begründet, freigegeben, beobachtet und rücknehmbar sein. Das betrifft Portscans, Authentisierungstests, Protokoll-Requests, Dateioperationen, Service-Abfragen und jede Form von Schreibzugriff. Ein aggressiver Standardscan mit Service-Erkennung kann auf älteren Geräten bereits zu viel sein.

Deshalb wird die Methodik in Stufen aufgebaut. Zuerst passive Sichtung: Konfigurationsdateien, Firewall-Regeln, VPN-Profile, Asset-Listen, Projektstände, Backup-Dateien, Historian-Exports, Routingtabellen. Danach vorsichtige aktive Validierung mit begrenzter Paketfrequenz, klar definierten Zielsystemen und Monitoring durch den Betrieb. Erst wenn die Auswirkungen verstanden sind, folgen eng begrenzte Nachweise einzelner Schwachstellen. In vielen Fällen reicht ein Read-only-Nachweis, ein kontrollierter Login-Test oder die Verifikation einer unsicheren Konfiguration, ohne dass ein vollständiger Exploit nötig wäre.

Ein gutes Beispiel ist Modbus. Wenn nachgewiesen werden soll, dass Schreibzugriffe möglich sind, muss nicht sofort ein prozessrelevantes Register verändert werden. Sicherer ist ein abgestimmtes Testobjekt: ein ungenutztes Register, ein Labor-Tag, ein Wartungsfenster oder eine isolierte Test-SPS. Ähnlich bei Engineering-Zugängen: Der Nachweis, dass Projektdateien ohne Schutz auslesbar sind, ist oft ausreichend, ohne eine CPU in STOP zu versetzen oder Logik zu verändern.

Für die Durchführung haben sich einige Grundregeln bewährt. Sie klingen banal, verhindern aber die meisten selbstverursachten Störungen.

• Keine ungeprüften Standard-Scans gegen SPS, RTUs, Gateways oder serielle Konverter.
• Keine Schreiboperationen auf Live-Prozessdaten ohne explizites Testfenster und Rückfallplan.
• Keine Passwortsprays oder Brute-Force-Tests gegen produktive Fernwartungs- und HMI-Systeme.

Stattdessen werden Testprofile erstellt: Welche Hosts dürfen mit welcher Rate angesprochen werden? Welche Ports sind tabu? Welche Protokollfunktionen sind erlaubt? Wer beobachtet parallel die Anlage? Wer entscheidet über Abbruch? Diese Disziplin ist der Kern professioneller OT-Methodik. Ergänzend lohnt sich ein Blick auf Ot Penetration Testing Methoden und Ot Penetration Testing Checkliste, weil dort die operative Struktur solcher Tests gut anschlussfähig ist.

Ein weiterer Punkt ist die Beweisführung. In IT-Tests wird oft ein Shell-Zugriff als Goldstandard betrachtet. In OT ist das zu kurz gedacht. Ein valider Nachweis kann auch sein: unautorisierter Zugriff auf Engineering-Projekte, manipulierbare Alarmgrenzen, fehlende Signaturprüfung bei Logik-Uploads, ungeschützte Fernwartung oder die Möglichkeit, Prozessdaten unbemerkt zu verfälschen. Entscheidend ist, dass der Nachweis reproduzierbar, risikoarm und fachlich belastbar ist.

Wer OT testet, muss außerdem mit dem Betrieb sprechen wie mit einem technischen Partner, nicht wie mit einem Hindernis. Leitwarte, Instandhaltung und Verfahrenstechnik kennen die empfindlichen Stellen der Anlage. Diese Informationen ersetzen keine Sicherheitsanalyse, aber sie verhindern unnötige Fehler und helfen, technische Befunde korrekt einzuordnen.

Ein OT-Pentest in der Wasserversorgung sollte entlang realistischer Kill Chains aufgebaut werden. Ein typischer Pfad beginnt mit einem extern erreichbaren Fernwartungszugang. Dort wird geprüft, ob Mehrfaktor-Authentisierung aktiv ist, ob Konten personengebunden sind, ob alte Dienstleisterzugänge fortbestehen, ob Split-Tunneling erlaubt ist und ob die Sitzung auf einen Jump Host oder direkt in die OT führt. Danach folgt die Frage, welche Systeme aus dieser Sitzung erreichbar sind: Leitwarte, Engineering, Dateifreigaben, Historian, SPS-Netze.

Der nächste Pfad betrifft die IT-zu-OT-Übergänge. In vielen Umgebungen existieren Domänenvertrauen, gemeinsame Administrationskonten, Backup-Verbindungen oder Monitoring-Systeme, die beide Welten berühren. Ein Angreifer benötigt nicht zwingend einen Exploit gegen eine SPS, wenn er über eine schlecht segmentierte Management-Verbindung an eine Engineering-Station gelangt. Genau hier zeigt sich, warum Ot Netzwerk Segmentierung Ics Sicherheit und Ot Monitoring Wasser nicht nur Architekturthemen, sondern direkte Pentest-Befunde beeinflussen.

Ein dritter Pfad ist die Manipulation von Sichtbarkeit statt direkter Steuerung. Wenn Historian-Daten, Alarmgrenzen oder HMI-Anzeigen verändert werden können, entsteht eine gefährliche Lage: Der Prozess läuft physisch weiter, aber das Bedienpersonal sieht falsche Zustände. In Wasseranlagen kann das bedeuten, dass Füllstände, Druckwerte oder Dosiermengen falsch interpretiert werden. Solche Angriffe sind oft realistischer als spektakuläre SPS-Übernahmen, weil sie weniger auffallen und mit Standardrechten auf SCADA-nahen Systemen möglich sein können.

Ein vierter Pfad betrifft Engineering-Arbeitsplätze. Dort liegen häufig Projektdateien, Kommunikationsparameter, Bibliotheken, Firmwarepakete und Zugangsdaten. Wenn ein Angreifer diese Station kontrolliert, kann er Logik analysieren, Änderungen vorbereiten oder bei nächster Wartung einschleusen. Selbst wenn die SPS online gut geschützt ist, bleibt die Engineering-Kette ein kritischer Hebel. Deshalb gehört die Prüfung von Projektablagen, Backup-Konzepten, Passwortschutz, Signaturmechanismen und Wechseldatenträgern zwingend in den Testumfang.

Ein realistischer Prüfpfad endet nicht bei „Zugriff möglich“, sondern bei „betriebliche Wirkung plausibel“. Beispiel: Ein Test zeigt, dass ein HMI-Benutzer mit erweiterten Rechten Sollwerte für eine Chlor-Dosierung ändern kann. Dann muss bewertet werden, welche Freigaben, Plausibilitätsprüfungen, Grenzwerte und manuellen Kontrollen existieren. Erst daraus ergibt sich das tatsächliche Risiko. Ohne diese Einordnung bleibt der Befund technisch korrekt, aber operativ unvollständig.

In gut geführten Tests werden solche Pfade als Szenarien dokumentiert: Einstieg, Voraussetzungen, technische Schritte, beobachtete Wirkung, vorhandene Barrieren, verbleibendes Risiko. Das ist deutlich wertvoller als eine lose Liste einzelner CVEs, weil es die reale Angreifbarkeit der Anlage abbildet.

Der häufigste Fehler ist die Übertragung klassischer IT-Methoden auf OT, ohne die Prozesswirkung zu berücksichtigen. Dazu gehören Vollscans, aggressive Service-Erkennung, unkoordinierte Credential-Tests und automatisierte Exploit-Checks gegen Systeme, deren Stabilität unbekannt ist. In Wasseranlagen ist das besonders riskant, weil viele Komponenten lange Lebenszyklen haben und nie für solche Lastprofile ausgelegt wurden.

Ein zweiter Fehler ist unklare Scope-Definition. „Test der OT“ ist kein Scope. Es muss exakt festgelegt werden, welche Segmente, Hosts, Protokolle und Aktionen erlaubt sind. Fehlt diese Präzision, entstehen zwei Probleme gleichzeitig: Entweder wird zu wenig geprüft und kritische Übergänge bleiben unentdeckt, oder es wird zu viel geprüft und der Betrieb gefährdet. Gute Scopes definieren auch Ausschlüsse, Eskalationswege und Abbruchkriterien.

Drittens wird die Rolle des Betriebs oft unterschätzt. Wenn Leitwarte und Instandhaltung nicht eingebunden sind, fehlen Informationen über empfindliche Geräte, Wartungszustände, Redundanzen und bekannte Altlasten. Dann werden Tests an ungünstigen Zeitpunkten durchgeführt oder Befunde falsch interpretiert. Ein Kommunikationsabbruch zu einer Außenstation kann harmlos sein oder hochkritisch, je nachdem, ob gerade eine Umschaltung, Spülung oder Dosierphase läuft.

Viertens werden Befunde häufig ohne Prozesskontext priorisiert. Ein ungepatchter Windows-Host in einer isolierten Beobachtungszone ist nicht automatisch kritischer als ein unscheinbarer Engineering-PC mit direktem Zugriff auf mehrere SPS. Ebenso ist eine CVSS-Zahl allein wertlos, wenn nicht klar ist, ob der Angreifer den Pfad überhaupt erreichen kann. In OT zählt die Kombination aus Erreichbarkeit, Steuerbarkeit und Prozesswirkung.

Fünftens fehlt oft die Nachbereitung. Ein Pentest erzeugt nicht nur Findings, sondern auch Wissen über Architektur, Betriebsabläufe und Schwachstellenketten. Wenn dieses Wissen nicht in Segmentierung, Monitoring, Härtung und Incident-Response überführt wird, bleibt der Test ein einmaliges Ereignis ohne nachhaltige Wirkung. Genau deshalb sollten Ergebnisse mit Themen wie Ot Forensik Wasser Sicherheit, Ot Incident Response Wasser Sicherheit und Ot Risikomanagement Wasser Sicherheit verzahnt werden.

• Zu breite Testfreigaben ohne technische Leitplanken führen fast immer zu unnötigem Risiko.
• Einzelne Schwachstellen ohne Angriffsweg zu bewerten erzeugt falsche Prioritäten.
• Fehlende Rückfallpläne machen selbst kleine Testfehler zu operativen Störungen.

Diese Fehler passieren nicht aus Nachlässigkeit allein, sondern oft aus Zeitdruck, unvollständiger Dokumentation und falschen Erwartungen. Manche Auftraggeber wollen „einen echten Angriff“ sehen, ohne die Konsequenzen eines echten Angriffs in einer Live-Anlage zu akzeptieren. Professionelles OT-Pentesting setzt hier klare Grenzen: realistisch ja, fahrlässig nein.

In Wasseranlagen ist Modbus/TCP oft das erste Protokoll, das in Assessments sichtbar wird. Die technische Prüfung beginnt hier nicht mit blindem Registerschreiben, sondern mit Mapping und Kontext. Welche Geräte sprechen als Master, welche als Slave? Welche Register sind read-only, welche steuern reale Aktoren? Gibt es Gateways zu seriellen Segmenten? Werden Werte zyklisch gepollt oder ereignisbasiert verarbeitet? Erst wenn diese Fragen geklärt sind, lässt sich sicher bewerten, ob ein Schreibzugriff überhaupt relevant wäre.

Ein typischer Befund ist, dass Modbus-Kommunikation unverschlüsselt und ohne Authentisierung über flache Segmente läuft. Das allein ist noch keine Überraschung, aber die Kombination mit schwacher Segmentierung macht daraus ein reales Risiko. Wenn ein kompromittierter Wartungsrechner oder HMI-Client dasselbe Segment erreicht, kann aus einem IT-nahen Vorfall schnell ein Prozessrisiko werden. Technische Details und Schutzmaßnahmen dazu sind unter Modbus Sicherheit Konfiguration und Modbus Sicherheit Schutz anschlussfähig.

Bei OPC und OPC UA ist die Lage differenzierter. Klassisches OPC auf DCOM-Basis bringt oft komplexe Berechtigungs- und Kommunikationsprobleme mit sich. OPC UA bietet deutlich bessere Sicherheitsmechanismen, wird aber in der Praxis nicht immer sauber konfiguriert. Zertifikate werden pauschal vertraut, Security Policies zu schwach gewählt, anonyme Sessions zugelassen oder Trust Stores nicht gepflegt. In einem Pentest wird daher nicht nur geprüft, ob OPC UA vorhanden ist, sondern ob die Sicherheitsfunktionen tatsächlich wirksam sind. Dazu passen Opc Ua Security Ics Sicherheit und Opc Ua Security Best Practices.

Windows-basierte Leitwarten erfordern eine doppelte Sicht. Einerseits gelten klassische Themen wie lokale Administratorrechte, veraltete Dienste, SMB-Freigaben, fehlende Application Control, schwache Service-Accounts und unsichere RDP-Konfigurationen. Andererseits muss immer geprüft werden, welche dieser Schwächen tatsächlich in Richtung Prozesssteuerung wirken. Ein lokaler Privilege-Escalation-Befund ist nur dann hochkritisch, wenn der Host zugleich Steuerrechte, Projektdateien oder Kommunikationspfade zu SPS und RTUs besitzt.

Engineering-Stationen sind oft der technisch wertvollste Prüfpunkt. Dort liegen Offline-Projekte, Symboltabellen, Kommunikationsparameter, Bibliotheken, Firmwarestände und teilweise Klartext-Zugangsdaten. Häufig sind diese Systeme von Patch- und Härtungsmaßnahmen ausgenommen, weil Kompatibilitätsängste dominieren. In der Praxis bedeutet das: alte Betriebssysteme, deaktivierte Schutzmechanismen, USB-Nutzung, lokale Adminrechte und direkte Erreichbarkeit mehrerer Steuerungen. Ein Pentest muss hier nicht nur Schwachstellen sammeln, sondern die Integrität der gesamten Engineering-Kette bewerten.

Ein sauberer technischer Bericht beschreibt deshalb nicht nur „was verwundbar ist“, sondern „welche Änderung an welcher Stelle mit welchem Aufwand welche Prozesswirkung entfalten könnte“. Genau diese Verbindung aus Protokollanalyse, Host-Härtung und Prozessbezug macht OT-Pentesting im Wasserbereich fachlich belastbar.

Beispiel für eine risikoarme Prüfsequenz bei einer Engineering-Station:
1. Offline-Sichtung vorhandener Projektdateien und Kommunikationsprofile
2. Prüfung lokaler Rechte, gespeicherter Zugangsdaten und Dienstekonfiguration
3. Verifikation erreichbarer OT-Ziele ohne aggressive Service-Erkennung
4. Nachweis, ob Upload/Download-Funktionen grundsätzlich möglich wären
5. Dokumentation der Prozesswirkung ohne Live-Logikänderung

Ein OT-Befund ist erst dann brauchbar, wenn er technisch präzise und betrieblich verständlich ist. Reine Schwachstellenlisten mit CVE-Nummern reichen nicht aus. In Wasseranlagen muss ein Bericht erklären, wie ein Befund erreichbar ist, welche Voraussetzungen gelten, welche Systeme betroffen sind, welche Prozessfunktion berührt wird und wie der Nachweis erbracht wurde. Ohne diese Struktur bleibt unklar, ob es sich um ein theoretisches Problem oder um eine realistische Gefährdung der Versorgung handelt.

Gute Befunde enthalten daher mindestens fünf Ebenen: technische Beschreibung, Angriffsweg, Prozessbezug, Risikoabschätzung und konkrete Gegenmaßnahmen. Beispiel: „Unsegmentierter Zugriff von Fernwartungs-Jump-Host auf SPS-Netz via Modbus/TCP; Read/Write-Kommunikation ohne zusätzliche Authentisierung; potenziell manipulierbare Sollwerte in Pumpensteuerung; Nachweis über kontrollierte Registerabfrage im Wartungsfenster; empfohlene Maßnahmen: Firewall-Regeln, Jump-Host-Härtung, Schreibpfadbegrenzung, Monitoring auf Funktionscodes.“ Diese Form ist deutlich wertvoller als „Modbus unsicher“.

Priorisierung in OT darf nicht allein auf Schweregraden aus der IT beruhen. Ein mittel eingestufter Host-Befund kann in OT kritisch sein, wenn er den einzigen Engineering-Zugang betrifft. Umgekehrt kann eine hohe CVSS-Bewertung operativ weniger relevant sein, wenn das System isoliert ist und keine Steuerfunktion besitzt. Sinnvoll ist eine Matrix aus Erreichbarkeit, Ausnutzbarkeit, Steuerwirkung, Erkennbarkeit und Wiederherstellbarkeit. Gerade der letzte Punkt wird oft vergessen: Wie schnell kann der Betrieb nach einer Manipulation sicher in einen definierten Zustand zurückkehren?

Ein weiterer Qualitätsfaktor ist die Trennung zwischen Sofortmaßnahmen und Strukturmaßnahmen. Sofortmaßnahmen sind etwa das Deaktivieren alter Fernwartungskonten, das Schließen unnötiger Firewall-Regeln oder das Entfernen gespeicherter Klartext-Zugangsdaten. Strukturmaßnahmen betreffen Segmentierung, Rollenmodelle, Engineering-Prozesse, Monitoring und Notfallabläufe. Beide Ebenen müssen im Bericht klar getrennt werden, damit Betrieb und Management handlungsfähig bleiben.

Für Wasserbetreiber mit regulatorischem Druck ist außerdem die Anschlussfähigkeit an Governance und Nachweisführung wichtig. Themen wie Nis2 Ot Wasser Sicherheit, Kritis Sicherheit Wasser und Ics Security Checkliste werden dann relevant, wenn technische Befunde in Maßnahmenprogramme, Audits und Nachweisdokumentation überführt werden müssen.

Ein guter Bericht vermeidet Alarmismus. Nicht jeder Befund ist ein Katastrophenszenario. Aber jeder Befund muss so beschrieben sein, dass technische Teams ihn reproduzieren, priorisieren und beheben können. Genau diese Präzision trennt belastbare OT-Reports von oberflächlichen Sicherheitsbewertungen.

Ein OT-Penetration-Test ist kein Endpunkt, sondern ein Auslöser für Abwehrverbesserung. Gerade in Wasseranlagen zeigt sich nach einem Test oft, dass nicht nur Schwachstellen existieren, sondern auch Sichtbarkeitslücken. Viele Betreiber können im Nachhinein nicht sicher sagen, ob eine unzulässige Modbus-Funktion, ein Engineering-Upload oder eine ungewöhnliche Fernwartungssitzung erkannt worden wäre. Genau hier beginnt der Übergang von Assessment zu Verteidigung.

Monitoring in OT muss protokoll- und prozessnah sein. Es reicht nicht, nur Windows-Events oder Firewall-Logs zu sammeln. Relevante Fragen sind: Welche neuen Kommunikationsbeziehungen entstehen? Welche SPS wird außerhalb üblicher Wartungsfenster angesprochen? Welche Modbus-Funktionscodes treten plötzlich auf? Welche HMI-Benutzer ändern Sollwerte? Welche Fernwartungssitzung läuft ungewöhnlich lange? Für diese Perspektive sind Ot Monitoring Wasser, Ot Monitoring Ics und Ot Anomalie Erkennung Wasser Sicherheit besonders relevant.

Forensik in OT ist ebenfalls speziell. Nach einem Vorfall können Logquellen begrenzt, Zeitstempel unsauber und Geräte nicht ohne Weiteres offline analysierbar sein. Deshalb sollte bereits vor einem Incident festgelegt sein, welche Daten gesichert werden, wie Konfigurationsstände versioniert werden, wie Projektdateien archiviert sind und welche Netzwerkdaten an zentralen Punkten mitgeschnitten werden können. Ohne diese Vorbereitung bleibt die Aufklärung nach einer Manipulation oft lückenhaft. Vertiefend dazu passen Ot Forensik Ics und Ot Forensik Tools.

Incident Response in Wasseranlagen braucht technische und betriebliche Parallelität. Ein kompromittierter Fernwartungszugang wird nicht nur gesperrt, sondern es muss gleichzeitig geprüft werden, ob Änderungen an SPS-Logik, HMI-Konfiguration, Alarmgrenzen oder Historian-Daten erfolgt sind. Ebenso muss entschieden werden, ob der Prozess im Automatikbetrieb bleiben kann, in Handbetrieb überführt werden muss oder ob einzelne Stationen isoliert werden. Diese Entscheidungen lassen sich nicht improvisieren; sie müssen vorab geübt und dokumentiert sein.

• Nach jedem Pentest Erkennungsregeln aus real beobachteten Kommunikationsmustern ableiten.
• Engineering-Projekte, Konfigurationsstände und Firmwareversionen revisionssicher sichern.
• Für Fernwartung, HMI-Manipulation und SPS-Zugriffe eigene Incident-Playbooks definieren.

Der größte Mehrwert eines guten OT-Pentests liegt oft genau hier: Er zeigt nicht nur, was angreifbar ist, sondern auch, was im Ernstfall unsichtbar bliebe. Wer diese Lücken schließt, erhöht die Resilienz der Wasserversorgung deutlich stärker als durch punktuelle Härtung einzelner Hosts.

Wiederholbare Qualität im OT-Penetration-Testing entsteht durch standardisierte Workflows. Das beginnt mit einer Vorphase, in der Scope, Prozesskritikalität, Ansprechpartner, Testfenster, Kommunikationswege und Abbruchkriterien festgelegt werden. Danach folgt die technische Baseline: Asset-Abgleich, Architekturvalidierung, Identifikation kritischer Übergänge, Sichtung vorhandener Sicherheitsmaßnahmen und Definition risikoarmer Prüfpfade.

In der Durchführungsphase wird jeder Schritt protokolliert: Zeitpunkt, Zielsystem, Aktion, erwartete Wirkung, beobachtete Wirkung, Freigabestatus. Diese Disziplin ist nicht bürokratisch, sondern operativ notwendig. Wenn während eines Tests eine Anomalie auftritt, muss sofort nachvollziehbar sein, welche Aktion sie ausgelöst haben könnte. Gerade in verteilten Wasserinfrastrukturen mit Außenstationen, Pumpwerken und Mischarchitekturen aus Funk, Mobilfunk und Festnetz ist diese Nachvollziehbarkeit unverzichtbar.

Ein sauberer Workflow trennt außerdem Discovery, Validierung und Demonstration. Discovery identifiziert Systeme und Kommunikationsbeziehungen. Validierung prüft, ob ein Risiko real besteht. Demonstration zeigt – nur wenn nötig und freigegeben – die betriebliche Relevanz. Viele schlechte Tests vermischen diese Phasen und eskalieren zu früh. Gute Tests bleiben so lange wie möglich in der risikoarmen Zone.

Ebenso wichtig ist die Rückkopplung in Architektur und Betrieb. Wenn ein Test zeigt, dass eine Außenstation über einen Mobilfunkrouter direkt auf die Leitwarte zugreifen kann, reicht es nicht, nur das Gerät zu härten. Dann müssen Fernwartungsprozess, Segmentierung, Regelwerk, Monitoring und Lieferantensteuerung angepasst werden. Genau deshalb sollten Ergebnisse immer mit Ot Security Wasser Angriffe, Ot Sicherheit Wasser Sicherheit und Kritis Sicherheit Guide zusammengedacht werden.

Ein praxistauglicher Workflow endet mit Re-Test und Lessons Learned. Wurden nur Symptome beseitigt oder die Ursache? Wurde eine Firewall-Regel ergänzt, aber der unsichere Fernwartungsprozess blieb unverändert? Wurde ein Passwort geändert, aber das geteilte Dienstleisterkonto nicht abgeschafft? Erst der Re-Test zeigt, ob Maßnahmen tragfähig sind.

Beispielhafter OT-Testworkflow Wasser:
Phase 1: Scope, Prozesskritikalität, Freigaben, Notfallkontakte
Phase 2: Dokumentensichtung und Architekturvalidierung
Phase 3: Passive Analyse und risikoarme Erreichbarkeitsprüfung
Phase 4: Kontrollierte Validierung priorisierter Schwachstellen
Phase 5: Prozessbezogene Risikobewertung und Bericht
Phase 6: Maßnahmenplanung, Detection-Ableitung, Re-Test

So entsteht aus einem einmaligen Test ein belastbarer Sicherheitsprozess. Genau das ist in Wasseranlagen entscheidend: nicht maximale technische Show, sondern reproduzierbare Sicherheit mit minimalem Betriebsrisiko.