Kein System ist vollständig abschottbar. Recovery ist entscheidend.
Kritische Funktionen geordnet wiederherstellen oder sicher weiterfhren.
Schutzmaßnahmen sind sichtbarer und leichter kommunizierbar.
Inventar, Priorisierung, getestete Verfahren und definierte Rollen.
Maritime Recovery geht weit über das Wiederherstellen eines Backups hinaus. Moderne Schiffe betreiben zahlreiche vernetzte Systeme: ECDIS (Electronic Chart Display), AIS (Automatic Identification System), GMDSS (Global Maritime Distress and Safety System), Maschinensteuerung, Ballastwassermanagement, Ladungskontrolle und Kommunikationssysteme. Ein Cyberangriff kann mehrere dieser Systeme gleichzeitig beeinträchtigen.
Die IACS Unified Requirements UR E26 und E27 — seit Juli 2024 für Neubauten verbindlich — definieren erstmals Mindestanforderungen für Cyber-Resilienz. UR E26 richtet sich an das Schiff als System und verlangt unter anderem eine Inventarisierung aller Computer-Based Systems (CBS), Netzwerksegmentierung und die Fähigkeit zum kontrollierten Herunterfahren und Wiederstarten. UR E27 richtet sich an Systemlieferanten und fordert Sicherheits-by-Design.
Für Recovery bedeutet dies konkret: jedes kritische System muss eine dokumentierte Wiederanlaufprozedur haben, die von der Crew ohne externe Unterstützung durchgeführt werden kann — zumindest im Grundbetrieb. Dies setzt voraus, dass Backup-Medien an Bord verfügbar sind, Konfigurationsdaten gesichert wurden und die Crew die Reihenfolge der Systemstarts kennt.
Ein häufig übersehener Punkt ist die Abhängigkeit zwischen OT (Operational Technology) und IT (Information Technology). Wenn das IT-Netzwerk kompromittiert ist, darf das OT-Netzwerk — das die Maschinen- und Sicherheitssysteme steuert — nicht mitgerissen werden. Netzwerksegmentierung ist hier keine optionale Massnahme, sondern eine fundamentale Architekturentscheidung, die bereits beim Schiffsdesign getroffen werden muss.
Für bestehende Schiffe, die nicht unter UR E26/E27 fallen, ist die Ausgangslage oft schlechter. Viele ältere Systeme wurden ohne Cybersicherheit im Sinn entworfen — Default-Passwörter, fehlende Netzwerksegmentierung und keine dokumentierten Recovery-Prozeduren sind häufig.
Der pragmatische Ansatz beginnt mit einem System-Inventar: welche CBS sind an Bord, welche sind vernetzt, welche sind sicherheitsrelevant? Daraus ergibt sich eine Priorisierung: Navigationssysteme und Maschinensteuerung haben höchste Priorität, gefolgt von Kommunikation und Ladungskontrolle. Für jede Prioritätsstufe wird eine Recovery-Prozedur definiert — vom einfachen Neustart bis zum vollständigen System-Rebuild.
Entscheidend ist das Testen. Eine Recovery-Prozedur, die nie geprobt wurde, ist im Ernstfall wertlos. Tabletop-Übungen — bei denen die Crew ein Cyberszenario durchspielt, ohne tatsächlich Systeme herunterzufahren — sind ein praktikabler erster Schritt. Vollständige Drills, bei denen Systeme tatsächlich heruntergefahren und wieder gestartet werden, sollten mindestens jährlich stattfinden.
Der NotPetya-Angriff auf Maersk im Juni 2017 bleibt die wirkungsvollste Fallstudie für maritime Cyber-Recovery. Innerhalb weniger Stunden fielen 49.000 Laptops, 3.500 Server und die gesamte Netzwerkinfrastruktur aus. Die Gesamtkosten beliefen sich auf geschätzte 300 Millionen USD.
Die entscheidende Erkenntnis war nicht die Schwäche der Protection, sondern die anfängliche Abwesenheit von Recovery-Fähigkeit. Maersk hatte kein isoliertes Backup des Active Directory — die zentrale Authentifizierungsinfrastruktur. Ein einzelner Domain Controller in Ghana, der zum Zeitpunkt des Angriffs offline war, rettete die Wiederherstellung. Ohne diesen Zufall hätte der Rebuild Wochen länger gedauert.
Für Schiffsbetreiber ist die Lehre klar: wenn die grösste Containerreederei der Welt Wochen braucht, um ihre IT-Infrastruktur wiederherzustellen, kann ein kleinerer Betreiber ohne Recovery-Plan nicht davon ausgehen, innerhalb von Tagen wieder betriebsfähig zu sein.
Betreiber können ihren Recovery-Reifegrad anhand von fünf Stufen bewerten. Stufe 1: kein dokumentiertes Inventar kritischer Systeme. Stufe 2: Inventar vorhanden, aber keine Recovery-Prozeduren. Stufe 3: Prozeduren dokumentiert, aber nie getestet. Stufe 4: regelmässig getestete Prozeduren mit definierten Rollen. Stufe 5: integrierte Recovery-Fähigkeit mit automatisierter Überwachung und regelmässigen Drills.
Die meisten Betreiber befinden sich auf Stufe 2 oder 3. Der Sprung von 3 auf 4 — also das tatsächliche Testen der dokumentierten Prozeduren — bringt den grössten Sicherheitsgewinn bei vergleichsweise geringem Aufwand.
Unverbindliches Erstgespräch – wir analysieren Ihre Situation und finden den besten Weg.
Beratung anfragen