Cybersicherheit für Hersteller maritimer Software und Ausrüstung

Ein Zulieferer der Schifffahrt unterliegt drei Regelwerken, die sich überschneiden, aber nicht decken: EU-Produktrecht, Klassifikationsregeln für Neubauten und die IMO-Leitlinien für Schiffsbetreiber. Klären Sie für jedes Produkt, was gilt, bevor Sie die Nachweise planen.

Der CRA nimmt Ausrüstung nach der Schiffsausrüstungsrichtlinie aus

Artikel 2 Absatz 4 des Cyber Resilience Act, Verordnung (EU) 2024/2847, lautet: „Diese Verordnung gilt nicht für Ausrüstung, die in den Anwendungsbereich der Richtlinie 2014/90/EU fällt.“ Diese Richtlinie über Schiffsausrüstung (Marine Equipment Directive, MED) erfasst Ausrüstung, die an Bord eines EU-Schiffs angebracht ist oder werden soll und für die die IMO-Übereinkommen die Zulassung durch die Verwaltung des Flaggenstaats verlangen: die Ausrüstung mit wheel mark (Steuerrad-Kennzeichen). Beispiele sind Navigationsausrüstung wie Radar, ECDIS, AIS und Schiffsdatenschreiber, Funkausrüstung, Brandschutz- und Rettungsmittel. Prüfen Sie für Ihren eigenen Artikel die aktuelle MED-Durchführungsliste.

Was im Anwendungsbereich des CRA bleibt

Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden und keine MED-Ausrüstung sind: Bord- und Landsoftware, die als Produkt verkauft wird, installiert oder heruntergeladen; Systeme für Schiffsbetrieb, Unterbringung, Catering und Hotelmanagement; Service-Systeme für Besatzung und Passagiere; Software für Flotten- und Reisemanagement; IoT-Sensoren und Gateways an Bord; Überwachungs- und Automatisierungsausrüstung, die keine Zulassung des Flaggenstaats braucht. Software as a Service für sich allein fällt nicht unter den CRA, es sei denn, sie ist die Datenfernverarbeitung eines Produkts, wobei NIS2 für ihren Anbieter dennoch gelten kann.

Manche Fälle brauchen eher eine rechtliche Einschätzung als eine Regel: Ausrüstung eines Typs mit wheel mark, die für Schiffe verkauft wird, die keine EU-Flagge führen, und Produkte, die MED-Ausrüstung mit Softwaremodulen außerhalb der MED kombinieren.

IACS UR E26 und E27

Die Unified Requirements des Internationalen Verbands der Klassifikationsgesellschaften gelten über die Klassifikation, nicht über EU-Recht. Rev.1 beider Anforderungen gilt für Schiffe, deren Bauvertrag am oder nach dem 1. Juli 2024 geschlossen wurde. Verbindlich sind sie für Fahrgastschiffe und Hochgeschwindigkeitsfahrzeuge in der Auslandfahrt, Frachtschiffe ab 500 GT in der Auslandfahrt, bewegliche Offshore-Bohreinheiten und bestimmte Offshore-Einheiten mit eigenem Antrieb; für andere Schiffe dienen sie als Leitlinie. Ein Produkt, das wegen der MED nicht unter den CRA fällt, kann trotzdem in den Anwendungsbereich von E26 und E27 fallen, und umgekehrt.

IMO

Die Entschließung MSC.428(98) verlangt von Schiffsbetreibern, Cyberrisiken in ihren Sicherheitsmanagementsystemen zu berücksichtigen, spätestens bei der ersten jährlichen Prüfung des Document of Compliance des Unternehmens nach dem 1. Januar 2021. Die IMO-Leitlinien zum maritimen Cyberrisikomanagement sind unverbindliche, allgemeine Leitlinien für Betreiber. Ihre jüngste Überarbeitung vom Mai 2026 besagt, dass das Cyberrisikomanagement Drittanbieter, Embedded-Systeme sowie Software- und Hardware-Lieferketten berücksichtigen sollte, und fordert Betreiber auf, Richtlinien zur Sicherheit der Software- und Hardware-Lieferkette für kritische Systeme festzulegen. Deshalb geben Betreiber die Frage an ihre Zulieferer weiter.

Die Faustregel: Braucht Ihr Produkt ein wheel mark, gilt der CRA dafür nicht; kommt es auf ein Schiff mit Bauvertrag ab Juli 2024, gilt wahrscheinlich E27; verkaufen Sie Software oder vernetzte Produkte in der EU, gehen Sie davon aus, dass der CRA gilt.

E27 ist die Anforderung, die Ausrüstungszulieferer direkt erreicht. Abschnitt 3.1 listet die Dokumente auf, die ein Zulieferer der Klassifikationsgesellschaft für ein computergestütztes System vorlegt, darunter:

• Ein Asset-Inventar (3.1.1): die Hardwarekomponenten mit Name, Version und Patch-Stand ihrer Systemsoftware, etwa Betriebssystem und Firmware, und die Softwarekomponenten, jeweils mit der Hardware, auf der sie installiert sind, ihrem Hersteller, Modell oder Typ, Zweck und ihrer Softwareversion.
• Eine Beschreibung der Sicherheitsfähigkeiten (3.1.3) und ihres Testverfahrens, Leitfäden zur Sicherheitskonfiguration sowie Pläne für Wartung, Reaktion auf Vorfälle, Wiederherstellung und Änderungsmanagement.
• Dokumente zum sicheren Entwicklungslebenszyklus (3.1.6), die auch beschreiben, wie Software-Updates und Patches gehandhabt werden.

Abschnitt 4 legt die erforderlichen Sicherheitsfähigkeiten fest, gestützt auf ausgewählte Systemanforderungen aus IEC 62443-3-3, etwa Authentifizierung und Schutz vor Schadcode. Das sind Fähigkeiten des Produkts.

Abschnitt 5 verlangt einen sicheren Entwicklungslebenszyklus, der Anforderungen, Design, Implementierung, Verifikation, Release, Wartung und Lebensende abdeckt und in einem Dokument festgehalten wird, das die Klassifikationsgesellschaft prüft. Er muss Maßnahmen aus IEC 62443-4-1 enthalten: Schutz der Code-Signing-Schlüssel (SM-8), Dokumentation von Sicherheitsupdates für Nutzer (SUM-2), Dokumentation von Sicherheitsupdates abhängiger Komponenten oder des Betriebssystems (SUM-3), authentische Auslieferung von Updates (SUM-4) sowie Leitfäden zu Defense in Depth und Härtung (SG-1 bis SG-3).

E26 schließt den Kreis auf Schiffsebene: Das Asset-Inventar des Schiffs für Hardware und Software, mit den Feldern aus dem E27-Inventar jedes Zulieferers, wird während der gesamten Lebensdauer des Schiffs aktuell gehalten, und Software- und Hardwareänderungen, die neue Schwachstellen einführen können, werden darin festgehalten.

Was E27 nicht sagt: SBOMs werden nicht erwähnt. Eine SBOM pro Release ist der präziseste Weg, die Softwareversionen für das Inventar und die SUM-3-Informationen zu abhängigen Komponenten zu liefern, aber sie unterstützt diese Anforderungen, statt selbst eine davon zu sein.

Schiffe überdauern Projekte. Ein Schiff bleibt jahrzehntelang im Einsatz, und der Supportaufwand für die Software an Bord überdauert das Projekt, das sie geliefert hat, das Team, das sie gebaut hat, und oft die Produktlinie des Zulieferers selbst.

Viele kleine Zulieferer und Integratoren. Ein einziges Schiff trägt Software von Dutzenden Zulieferern, zusammengeführt von einem Integrator, und jede Übergabe ist eine Gelegenheit, den Überblick zu verlieren, was in jedem Release steckt.

Bordsysteme lassen sich nicht beliebig aktualisieren. Updates warten auf Hafenaufenthalte, Klassenzulassung oder ein Wartungsfenster, daher bleiben alte Versionen lange im Einsatz, nachdem es einen Fix gibt. Sie müssen wissen, auf welchen Schiffen noch welche Version läuft.

Entlegene Standorte, begrenzte Konnektivität. Schiffe auf See und entlegene Anlagen sind schwer erreichbar, daher muss die Aufzeichnung dessen, was installiert wurde, an Land vorliegen, aus dem Build, nicht aus einem Scan des Schiffs.

Tabellen als führendes System. Wir hören von Herstellern maritimer Software, dass SBOMs und zugehörige Aufzeichnungen in vielen Tabellen liegen, von Hand gepflegt. Mit jedem Release veralten sie.