Aaron Rose, Office of the CTO bei Check Point Software
Ende Juli wurden mehr als 30 kommunale Wassersysteme im US-Bundesstaat Minnesota innerhalb von wenigen Tagen Opfer eines koordinierten Cyberangriffs. In der Stadt Braham ging eine Wasseraufbereitungsanlage offline, in der Stadt Plymouth wurde die Mobilfunkkommunikation zu zwei Wassertürmen und Abwasser-Hebestationen unterbrochen. In der Stadt Maple Plain wurde sogar der lokale Notstand ausgerufen.
Erste Berichte wiesen auf im Internet exponierte Programmable Logic Controllers (PLCs) als möglichen Zugriffspunkt hin. Ermittler überprüfen Verbindungen zu iranisch-affiliierter Akteuren. Entscheidend ist jedoch, dass das Trinkwasser sicher blieb, keine Hinweise zum Abkochen des Wassers wegen möglicher Verunreinigungen ausgegeben wurden. Gemeinden wie Plymouth konnten die Wasserversorgung aufrechterhalten, indem sie auf manuelle Prozesse direkt an der Ausrüstung umstellten.
Kurz darauf veröffentlichten das Australian Signals Directorate, die CISA, das FBI sowie die nationalen Cyber-Sicherheitszentren Kanadas, Großbritanniens und Neuseelands die gemeinsame Richtlinie „CI Fortify: Advice for Isolating Vital Systems“. Die Botschaft ist eindeutig: Betreiber kritischer Infrastrukturen müssen lebenswichtige OT-Systeme bewusst und geordnet von allen anderen Netzwerken trennen können, um kritische Dienste über die Dauer einer Krise hinweg bereitstellen zu können.
Logische Trennung ist keine belastbare Isolation
Diese Richtlinie widerlegt eine weitverbreitete Annahme. VLANs stellen keinen echten Air Gap dar. Sie werden als „minimally effective“ bewertet und allenfalls als Übergangslösung auf dem Weg zu physischer oder kryptografischer Isolation angesehen. Ein VLAN ist letztlich ein Traffic-Label, das von einem Switch durchgesetzt wird. Wer den Switch kontrolliert, kontrolliert somit auch dieses Label.
Das bedeutet nicht, dass VLANs nutzlos sind. Es bedeutet jedoch, dass ihr Betrieb hohe Disziplin erfordert. VLAN-Konfigurationen sollten nicht automatisch im Netzwerk weitergegeben werden. Trunk-Ports müssen auf ausdrücklich erlaubte VLANs begrenzt sein. Trunk Negotiation sollte deaktiviert werden. Dem Internet ausgesetzte Zonen oder DMZs dürfen keine Infrastruktur mit OT teilen. Dass ein so aufwendig zu pflegender Kontrollmechanismus dennoch nur als minimal wirksam gilt, zeigt die eigentliche Schwäche: Logische Trennung kann helfen, sie ersetzt aber keine belastbare Isolation.
Ähnlich deutlich fällt die Einschätzung zu MPLS aus. Die Richtlinie stellt klar, dass MPLS keine belastbare Segregation garantiert und nicht standardmäßig sicher ist. Wer MPLS zur Trennung von Netzwerken unterschiedlicher Vertrauensstufen nutzt, beispielsweise zwischen IT und OT, benötigt zusätzliche kryptografische Isolation. Auch Carrier-bereitgestellte Dienste sollten aus Sicht der Betreiber als nicht vertrauenswürdig und potenziell feindlich behandelt werden. Grund dafür ist nicht das Misstrauen gegenüber dem Anbieter, sondern die Frage, was Betreiber an der eigenen Demarkationsgrenze tatsächlich überprüfen können.
Isolation schützt nur, wenn sie geplant, getestet und beherrscht wird
Die „CI-Fortify“-Richtlinie macht außerdem deutlich, dass Isolation kein einzelner technischer Schalter ist. Vielmehr verlangt sie einen methodischen Prozess: Zunächst müssen vitale Systeme identifiziert, kritische Kunden und Abhängigkeiten bestimmt sowie Kritikalität und Vertrauensniveau klassifiziert werden. Anschließend ist jede Verbindung zu erfassen und echte Trennung und Isolation Points aufzubauen. Zuletzt muss ein abgestufter Isolationsplan mit klaren Auslösekriterien in den Incident-Response-Plan integriert werden.
In der Praxis werden gerade zwei Punkte leicht unterschätzt: Dependency Mapping und Testing. Dienste wie Active Directory, DNS, Zeitsynchronisierung, Backups oder gemeinsame Hypervisoren können OT unbemerkt mit der Unternehmensinfrastruktur verbinden. Jede dieser Abhängigkeiten kann aus einer scheinbar sauberen Trennung einen Ausfall machen. Ebenso reicht es nicht aus, in einer Übung nur ein einzelnes System zu isolieren. Es entstehen Abhängigkeiten zwischen Systemen. Deshalb muss eine vollständige Isolation regelmäßig getestet werden. Teil dieser Vorbereitung ist auch eine offline verfügbare, gedruckte Kopie des Notfallplans, damit ein Angreifer, der Zugriff auf das Dokumentenmanagement hat, nicht nachlesen kann, welche Schritte als Nächstes geplant sind.
Eine Isolation bringt zudem eigene Risiken mit sich. So können Systeme aus dem Patching-Stand fallen, die externe Sichtbarkeit sinkt genau dann, wenn sie besonders wichtig wäre, und externe Wechselmedien werden plötzlich zum zentralen Transportweg für Daten. Gleichzeitig können die Prüfstationen für diese Medien ohne Updates bleiben. Isolation ist also kein sicherer Raum, sondern ein Betriebsmodus mit eigenen Anforderungen. Wer sie erst im Krisenfall lernt, ist zu spät dran.
Fazit
Sowohl der Angriff auf die Wassersysteme in Minnesota als auch die „CI-Fortify“-Richtlinie zeigen dasselbe Problem aus zwei Perspektiven: Kritische Infrastrukturen benötigen mehr als logische Segmentierung und gute Absichten. Betreiber müssen wissen, welche Systeme wirklich vital sind, welche Abhängigkeiten sie aufweisen, welche Verbindungen bestehen und wie sich die OT im Ernstfall geordnet isolieren lässt, ohne den kritischen Dienst selbst zu gefährden.
