Absicherung von Häfen nach IEC 62443

Startseite

Blogs

Absicherung von Häfen nach IEC 62443

Team Shieldworkz

4. September 2026

Ein Leitfaden für OT-Cybersecurity, Resilienz und Compliance in Seehafenterminals

Moderne Hafenbetriebe hängen von automatisierter, vernetzter Operational Technology (OT) und Industrial Control Systems (ICS) ab. Die Konvergenz von Terminal-Operating-Systemen (TOS), automatisierten Containerumschlagsgeräten, maritimen Schnittstellen und industriellen Netzwerken hat die Angriffsfläche der globalen Hafeninfrastruktur drastisch vergrößert.

Ein Cyber-Vorfall in diesen Umgebungen kann physische Lieferketten unterbrechen, katastrophale wirtschaftliche Verluste verursachen, die Sicherheit von Menschenleben gefährden und Umweltschäden herbeiführen.

Dieser Artikel bietet Hafenbehörden, Terminalbetreibern und Schiffsingenieuren einen praxisorientierten, evidenzbasierten Leitfaden für den Entwurf, die Implementierung und die Aufrechterhaltung eines OT-Cybersecurity-Programms, das die Normenreihe IEC 62443 als primären Rahmen nutzt.

Ziele des Leitfadens

Ziel	Beschreibung
Systematische Identifikation	Kategorisierung und Erfassung kritischer maritimer OT-Assets, Abhängigkeiten und Netzwerkgrenzen.
Risikobasierte Architektur	Aufteilung des Hafenbetriebs in verteidigungsfähige Zonen und Conduits, die an Target Security Levels (SL 1–SL 4) gekoppelt sind.
Maßnahmen-Alignment	Zuordnung von Sicherheitsmaßnahmen zu den sieben grundlegenden Anforderungen (FR 1–FR 7) der IEC 62443-3-3.
Verifizierbare Nachweise	Etablierung von kontinuierlichem Monitoring, automatisierter Beweiserhebung und Reifegradmetriken zur Erfüllung regulatorischer Anforderungen wie IMO MSC-FAL.1/Circ.3, EU-NIS-2 und USCG 33 CFR / NVIC 01-20.

Wichtigste Erkenntnisse

Erkenntnis	Beschreibung
Risiko der IT/OT-Konvergenz	Eine unkontrollierte Integration zwischen Unternehmens-IT-Netzwerken, cloudbasierten Analyseplattformen und OT-Assets auf Feldebene schafft Angriffsvektoren, die traditionelle Perimeterschutzmaßnahmen umgehen können.
Mangelnde Asset-Sichtbarkeit	Über 60 % der Sicherheitslücken in der Hafen-OT resultieren aus nicht erfassten Altsystemen (Legacy Assets), unbefugten Fernzugriffspunkten von Drittanbietern und dynamischen Funknetzwerken auf mobilen Umschlagsgeräten.
Weitverbreitete Shared Accounts	Engineering Workstations (EWS) und Human-Machine Interfaces (HMIs) werden häufig mit gemeinsam genutzten administrativen Zugangsdaten betrieben, was die Anforderungen an Revisionssicherheit und Zugriffskontrolle verletzt.
Mängel bei der Isolation von Sicherheitssystemen	Sicherheitsgerichtete Systeme (SIS) und Notabschaltsysteme (ESD) in Flüssig-/Schüttgutterminals sind oft ohne physische oder kryptografische Netzwerktrennung (Air-Gap) mit Prozessnetzwerken verbunden, wodurch physische Abläufe für Manipulationen aus der Ferne anfällig werden.
Lieferketten-Schwachstellen bei Drittanbietern	Wartungsverbindungen von Drittanbietern, einschließlich Mobilfunk-Dongles und unverschlüsselter VPNs, stellen die am häufigsten genutzten Einfallstore für Erstzugriffe in maritimen ICS-Umgebungen dar.

Maritime Container-, Schüttgut- und Flüssiggutterminals sind komplexe industrielle Ökosysteme, die rund um die Uhr in Betrieb sind.

Im Gegensatz zu klassischen IT-Umgebungen in Unternehmen, in denen Vertraulichkeit und Datenintegrität häufig im Vordergrund stehen, priorisieren OT-Ökosysteme in Häfen:

Sicherheit (Safety)
Betriebliche Verfügbarkeit
Physische Integrität
Kontinuität des Ladungsumschlags

Eine unmitigierte OT-Störung an einem Tier-1-Containerterminal kann den Schiffsanlauf stoppen, intermodale Schienen- und Lkw-Netze blockieren und erhebliche Liegegeld- sowie Betriebskosten verursachen.

Die Absicherung dieser Umgebungen erfordert einen ingenieurtechnischen Ansatz, der für deterministische Systeme ausgelegt ist. Der IEC 62443-Standard adressiert diese Anforderungen, indem er Cybersecurity als betriebliche Ingenieurdisziplin behandelt.

Bedrohungslage der Hafen-OT

Moderne Hafeninfrastrukturen sind Bedrohungsakteuren ausgesetzt, die von opportunistischen Ransomware-Gruppen bis hin zu hochentwickelten, staatlich geförderten Advanced Persistent Threats (APTs) und Hacktivisten reichen.

Bedrohungsarchitektur und Angriffspfad-Matrix

Bedrohungskategorie	Angriffsvektor	Primäres Ziel-Asset	Betriebliche Auswirkungen	Sicherheitsrelevante Folgen (Safety)	Herausforderung bei der Erkennung	IEC 62443 Mitigation
Ransomware / Erpressung	Phishing → IT/OT-DMZ → TOS-Datenbank	Terminal-Operating-System (TOS), Gate-Datenbank	Vollständiger Terminal-Lockout; manueller Yard-Betrieb	Stillstand im Yard; Blockade von Rettungswegen	Verschlüsseltes C2 über HTTPS; Missbrauch legitimer Tools	3-3: FR 5 (Restricted Data Flow), FR 7 (Resource Availability)
Ausnutzung von OT-Protokollen	Kompromittierte EWS → Nicht authentifiziertes Modbus/S7	SPS von Containerbrücken (STS-Kranen)	Kranblockade, herabstürzende Lasten, Antriebsstörungen	Struktureller Einsturz, Personenschäden	Nativer Protokollverkehr erscheint Standard-IT-IDS-Systemen als valide	3-3: FR 1 (IAC), FR 3 (System Integrity); 4-2: CR 1.1
Missbrauch von Drittanbieter-Fernzugriffen	Dual-Homed-Herstellermodem → OT-Netzwerk	Antriebe von automatischen Stapelkranen (ASC)	Unbefugte SPS-Reprogrammierung; Verlust der Automatisierung	Unkontrollierte Kranbewegungen im aktiven Yard	Datenverkehr stammt aus vertrauenswürdigem Herstellerkanal	2-4: SP.03 (Remote Access); 3-3: FR 1, FR 2 (Use Control)
GNSS-Spoofing / -Störung	Funkstörung / RF-Spoofing	Yard-Positionierungssysteme, fahrerlose Transportsysteme (AGVs)	Fehlplatzierung von Containern; Navigationsausfall der AGVs	Kollisionen von Geräten in automatisierten Zonen	Anomalie auf Sensorebene ohne Netzwerkspur	3-2: Risk Assessment; 3-3: FR 6 (Timely Response); manueller Rückfallmodus
Living-off-the-Land (LotL)	Gestohlene Zugangsdaten → Remote Desktop / PowerShell	HMI / SCADA-Server	Unbemerktes Ändern von Sicherheitsverriegelungen oder Sollwerten	Umweltleckage; Tanküberlauf im Flüssiggutterminal	Nutzung nativer administrativer Binärdateien wie PsExec und WMIC	3-3: FR 2 (Use Control), FR 6 (Audit Trail, Anomaly Detection)

Betriebliches Risiko und Auswirkungs-Hierarchie

Rahmenwerk zur Klassifizierung von Hafensystemen nach Schadensausmaß

Klasse	Klassifizierung	Repräsentative Systeme	Potenzielle Auswirkungen
Klasse 1	Kritische Sicherheit und physische Integrität — Katastrophal	Sicherheitsgerichtete Systeme (SIS), Notabschaltsysteme (ESD), Schleppernavigation/dynamische Positionierung, Brand- und Gasüberwachung	Potenzieller Verlust von Menschenleben, schwere strukturelle Schäden, maritime Umweltkatastrophe
Klasse 2	Primärer Betrieb — Schwerwiegend	SPS von STS-Kranen, ASC-Steuerungssysteme, TOS-Core-Datenbank, SCADA für Flüssigguttransfer	Vollständiger Stillstand von Terminal-Liegeplätzen oder Yard-Abläufen; schwerer wirtschaftlicher Schaden
Klasse 3	Sekundärer Betrieb — Moderat	Gate OCR, Kennzeichenerkennung (ANPR), Waagen-SPS, Reefer-Überwachung	Teilweise Verlangsamung des Durchsatzes; manuelle Übergangslösungen bei reduzierter Effizienz verfügbar
Klasse 4	Unterstützende Systeme — Geringfügig	Gebäudeleittechnik (GLT), Videoüberwachung (CCTV), Umweltsensoren	Betriebliche Unannehmlichkeiten; lokale Beeinträchtigung der physischen Sicherheit; keine direkte Auswirkung auf den Ladungsumschlag

Klarstellung von Umfang und Fähigkeiten

Grenzen der Zertifizierung

Das Erreichen einer IEC 62443-Zertifizierung für eine einzelne Komponente – beispielsweise eine IEC 62443-4-2-konforme SPS – macht nicht das gesamte Terminal sicher.

Die Komponente muss in eine sichere Architektur gemäß IEC 62443-3-2 integriert werden, gestützt auf effektive Betriebskonzepte nach IEC 62443-2-1 sowie sichere Integrationsprozesse nach IEC 62443-2-4 und IEC 62443-3-3.

Systemgrenzen

Die IEC 62443 gilt spezifisch für Industrial Automation and Control Systems (IACS).

Enterprise-IT-Plattformen wie ERP- und HR-Systeme des Unternehmens fallen nicht in ihren primären Geltungsbereich, es sei denn, sie sind über Mechanismen wie DMZs direkt mit der OT gekoppelt.

Rollen und Verantwortlichkeiten der Stakeholder

Eine erfolgreiche Sicherheitsarchitektur im Hafen erfordert klar definierte Schnittstellen zwischen allen Beteiligten.

Stakeholder	Primärer Fokus (IEC 62443)	Hauptverantwortlichkeiten im Hafenumfeld
Betreiber (Asset Owner) — Hafenbehörde / Terminalbetreiber	2-1, 3-2	Gesamtrisikoakzeptanz, CSMS-Governance, Zonen-/Conduit-Definition und Festlegung der angestrebten Sicherheitsstufen (SL-T).
Systemintegrator — Kranbauer / Automatisierungspartner	2-4, 3-3	Entwurf, Installation und Inbetriebnahme von OT-Systemen entsprechend dem spezifizierten SL-T; Erstellung von Hard-/Software-Inventaren und Baseline-Konfigurationen.
Produkthersteller / OEM — SPS-, Antriebs- und SCADA-Hersteller	4-1, 4-2	Bereitstellung von Hard- und Softwarekomponenten, die unter sicheren Lebenszyklen entwickelt wurden und die spezifizierten Sicherheitsstufen (SL-C) erfüllen.
Dienstleister — Wartungsunternehmen / Managed Security	2-4	Einhaltung sicherer Fernzugriffsrichtlinien, Patch-Management-SLAs und Verfahren zur Zuverlässigkeitsüberprüfung.
Prüfer / Auditor	2-1, 3-2, 3-3	Unabhängige Validierung der Konformität gegenüber den spezifizierten Kontrollen und Überprüfung der Nachweisdokumente.

Modell der Hafen-OT-Asset- und Netzwerkarchitektur

Eine moderne Hafeninfrastruktur erfordert die Abbildung physischer Assets über die hierarchischen Ebenen des Purdue-Modells bzw. der IEC 62443.

Umfassende Asset-Taxonomie

Asset-Kategorie	Repräsentative Assets
Automatisierung und Gerätesteuerung	Kran-SPS wie Siemens S7-1500 und ABB AC800M, Antriebe/Wechselrichter, dezentrale Peripheriegeräte (Remote I/O), Steuerungen für automatische Stapelung
Betrieb und Logistik	TOS-Applikationsserver wie Navis N4 und CyberLogitec, Gate-ANPR/OCR-Prozessoren, Waagen-Steuerungen, RFID-Lesegeräte
Schnittstelle Schiff/Land	Schutzrelais für Landstromversorgung (Cold Ironing), Liegeplatz-Überwachungssysteme, dynamische Festmachersteuerungen
Schüttgut- und Flüssiggutinfrastruktur	Prozessleitsysteme (DCS), übergeordnetes SCADA, Tankmesssysteme, Pipeline-Ventilantriebe, Sicherheitsgerichtete Systeme (SIS) wie Triconex und Yokogawa ProSafe
Infrastruktur und Hilfsbetriebe	Umspannwerk-Automatisierung und IEC 61850-Schutzgeräte, USV-Steuerungen, Gebäudeleittechnik (GLT), Videoserver (CCTV), Zutrittskontrollzentralen

Anwendung von Zonen und Conduits

Die IEC 62443-3-2 schreibt die logische und physische Segmentierung von IACS in Zonen (Gruppierungen von Assets mit gemeinsamen Sicherheitsanforderungen) vor, die über Conduits (kontrollierte Kommunikationspfade zwischen den Zonen) verbunden sind.

Repräsentative Zonen- und Conduit-Architektur

Architekturschicht	Verbindung / Grenze	Ziel
Unternehmensnetzwerk (Enterprise Zone)	↓	DMZ-Conduit
DMZ-Conduit	↓	Terminalbetrieb-Zone
Terminalbetrieb-Zone	↓	Betriebliche Conduits
Kran-Conduit	→	STS-Kransteuerung-Zone
Gate-Conduit	→	Gate-Automatisierungszone
Energie-Conduit	→	Umspannwerk-Zone

Logische Architektur

Zone	Primärfunktion
Unternehmensnetzwerk (Enterprise Zone)	Unternehmens-IT und Geschäftsanwendungen
Industrial DMZ	Kontrollierter Informations- und Dienstaustausch zwischen IT und OT
Terminalbetrieb-Zone	TOS und logistische Betriebssysteme
STS-Kransteuerung-Zone	STS-Kran-SPSen, HMIs, Antriebe und zugehörige Wireless-Infrastruktur
Gate-Automatisierungszone	Gate-Automatisierung und Lkw-Abwicklungssysteme
Umspannwerk-Zone	Stationsautomatisierung und Energiemanagementsysteme

Spezifikation einer typischen Hafenzonen- und Conduit-Struktur

Zonen-ID	Zonenname	Enthaltene Assets	Target Security Level (SL-T)	Grenz-/Perimeterschutzmaßnahmen	Zugehörige Conduits
Z-DMZ	Industrial DMZ	TOS-Staging-Datenbank, Historian, Patch-Server, Jump-Hosts	SL 3	Dual-Homed-Firewalls, expliziter Proxy, Protokollterminierung, MFA	C-IT-DMZ, C-DMZ-OPS
Z-OPS	Terminalbetrieb	TOS-Server, Gate-Steuerungen, Reefer-Server	SL 2	Stateful-Inspection-Firewalls, AD-Isolation, IDS	C-DMZ-OPS, C-OPS-CRN
Z-CRN	STS- und ASC-Kransteuerung	Kran-SPSen, HMIs, Antriebe, Wireless Access Points	SL 3	Industrie-Firewalls mit DPI für Modbus/Profinet; WPA3-Enterprise	C-OPS-CRN, C-VND-CRN
Z-LIQ	Flüssiggut/Tanklager-SCADA	Tankmesssysteme, SCADA-Master, Ventil-SPSen	SL 3	Strikte Netzwerktrennung; physisch isolierte Engineering-Konsolen	C-OPS-LIQ, C-LIQ-SIS
Z-SIS	Sicherheitsgerichtete Zone (Safety)	Sicherheits-SPSen, ESD-Relais, Gasdetektion	SL 4	Physische Isolation / unidirektionale Gateways; keine direkten externen Routen	C-LIQ-SIS — nur lesend
Z-VND	Fernwartung durch Drittanbieter	Jump-Hosts von Drittanbietern, Wartungs-Laptops	SL 3	Zeitlich begrenztes Privileged Access Management (PAM), Sitzungsaufzeichnung, erzwungene Outbound-only-Verbindungen	C-VND-CRN

Methodik zur Cyber-Risikoanalyse nach IEC 62443-3-2

Risikoanalysen müssen betriebliche Bedrohungen im Hinblick auf Schadensszenarien bewerten, um das erforderliche Target Security Level für jede Zone zu bestimmen.

Risikoformel

Risiko = Eintrittswahrscheinlichkeit × Schadensausmaß

Wobei gilt:

Faktor	Skala	Beschreibung
Schadensausmaß (C)	1–5	1 = Geringfügig; 5 = Katastrophal / Verlust von Menschenleben / mehrwöchiger Stillstand
Eintrittswahrscheinlichkeit (L)	1–5	1 = Selten; 5 = Häufig / automatisierter Angriff

Matrix für Eintrittswahrscheinlichkeit und Risikobewertung

Wahrscheinlichkeit / Schadensausmaß	1 — Niedrig	2 — Mittel	3 — Hoch	4 — Schwerwiegend	5 — Kritisch
5 — Hoch	M	H	H	VH	VH
4 — Mittel	L	M	H	H	VH
3 — Niedrig	L	L	M	H	H
2 — Selten	L	L	L	M	H
1 — Unwahrscheinlich	L	L	L	L	M

Zuordnung von Risikostufen zu Target Security Levels

Risikostufe	Target Security Level
Sehr Hoch (VH)	SL-T 3 oder SL-T 4
Hoch (H)	SL-T 2 or SL-T 3
Mittel (M)	SL-T 1 or SL-T 2
Niedrig (L)	SL-T 1 oder grundlegende Cyber-Hygiene

Sicherheitsstufen verstehen — SL 1 bis SL 4

Sicherheitsstufen (Security Levels) definieren die Widerstandsfähigkeit einer Zone oder eines Systems gegenüber spezifischen Angriffsfähigkeiten. Sie dürfen nicht mit der bloßen Kritikalität von Assets verwechselt werden.

Definition der Security Levels

Security Level	Definition	Repräsentative Angriffsfähigkeit
SL 1	Schutz gegen unbeabsichtigte oder zufällige Verletzung der Sicherheit	Ungezielte Fehler, einfache Malware
SL 2	Schutz gegen vorsätzliche Verletzung mit einfachen Mitteln	Geringe Ressourcen, Standardwerkzeuge, grundlegende Fachkenntnisse
SL 3	Schutz gegen vorsätzliche Verletzung mit anspruchsvollen Mitteln	Moderate Ressourcen, IACS-spezifisches Fachwissen, gezielte Vorgehensweise
SL 4	Schutz gegen vorsätzliche Verletzung mit anspruchsvollen Mitteln und umfassenden Ressourcen	Hochentwickelte, finanzstarke und hochmotivierte Angreifer

Die drei Dimensionen der Sicherheitsstufen

Begriff	Bedeutung
SL-T — Target	Angestrebtes Sicherheitsniveau, das in der Risikoanalyse definiert wurde
SL-C — Capability	Native Sicherheitsfähigkeit eines Assets/einer Komponente gemäß IEC 62443-4-2
SL-A — Achieved	Tatsächlich gemessenes Sicherheitsniveau nach der Implementierung

Grundlegende Anforderungen (Foundational Requirements) der IEC 62443 — FR 1 bis FR 7

Die IEC 62443-3-3 strukturiert technische Sicherheitsanforderungen in sieben grundlegende Anforderungen.

FR	Anforderung	Abkürzung
FR 1	Identifizierung und Authentifizierung (Identification and Authentication Control)	IAC
FR 2	Zutritts- und Zugriffskontrolle (Use Control)	UC
FR 3	Systemintegrität (System Integrity)	SI
FR 4	Vertraulichkeit von Daten (Data Confidentiality)	DC
FR 5	Eingeschränkter Datenfluss (Restricted Data Flow)	RDF
FR 6	Frühzeitige Reaktion auf Ereignisse (Timely Response to Events)	TRE
FR 7	Verfügbarkeit von Ressourcen (Resource Availability)	RA

Praktische Zuordnungsmatrix für Hafensysteme

FR 1 — Identifizierung und Authentifizierung (IAC)

Element	Beschreibung
Ziel	Sicherstellen, dass alle menschlichen Benutzer, Geräte und Prozesse eindeutig identifiziert und authentifiziert werden, bevor sie auf OT-Assets zugreifen.
Beispiel Hafen-OT	Authentifizierung eines Automatisierungsingenieurs, der sich von einer Engineering Workstation aus mit der SPS einer Containerbrücke verbindet.
Typische Maßnahmen	Zentralisierte Verzeichnisdienste, MFA auf Jump-Hosts, PKI/X.509-Gerätezertifikate für industrielle Wireless-Endpunkte
Prüfungsnachweise	AD/LDAP-Benutzerlisten, RADIUS/TACACS+-Logs, MFA-Registrierungsberichte, CA-Protokolle
Bewertungsfrage	Sind gemeinsam genutzte Operator-Accounts auf allen HMIs und EWS-Konsolen ohne sekundäre Zuordnung strikt untersagt?

FR 2 — Zugriffskontrolle (UC)

Element	Beschreibung
Ziel	Durchsetzung autorisierter Berechtigungsstufen zur Verhinderung unbefugter Aktionen oder Parameteränderungen.
Beispiel Hafen-OT	Beschränkung der Änderung von Krangeschwindigkeitsparametern am lokalen HMI ausschließlich auf leitende Wartungsingenieure.
Typische Maßnahmen	Rollenbasierte Zugriffskontrolle (RBAC), PAM mit Sitzungsaufzeichnung, Durchsetzung des Least-Privilege-Prinzips auf Workstations
Prüfungsnachweise	PAM-Sitzungsprotokolle, RBAC-Berechtigungsmatrizen, GPO-Exportdateien
Bewertungsfrage	Werden administrative Privilegien nach Abschluss von Wartungsarbeiten automatisch wieder entzogen?

FR 3 — Systemintegrität (SI)

Element	Beschreibung
Ziel	Schutz operativer Systeme vor unbefugten Modifikationen, Code-Manipulationen und Schadsoftware.
Beispiel Hafen-OT	Verhinderung, dass eine nicht freigegebene Änderung des SPS-Programms (Ladder-Logic) auf eine ASC-SPS geladen wird.
Typische Maßnahmen	Application Allowlisting, Erkennung von SPS-Codeänderungen, kryptografische Firmware-Validierung, EWS-Festplattenverschlüsselung
Prüfungsnachweise	Allowlisting-Logs, SPS-Prüfsummen-/Baseline-Berichte, Nachweise zur Firmware-Integrität
Bewertungsfrage	Gibt es einen automatisierten Mechanismus, der Bediener alarmiert, wenn die Prüfsumme des SPS-Programms von der autorisierten Baseline abweicht?

FR 4 — Vertraulichkeit von Daten (DC)

Element	Beschreibung
Ziel	Schutz sensibler Betriebsdaten während der Übertragung und Speicherung vor unbefugter Offenlegung.
Beispiel Hafen-OT	Verschlüsselung von TOS-Datenbankabfragen, die Manifestdaten, Gefahrgutinformationen und Containerstaupläne enthalten.
Typische Maßnahmen	TLS 1.3 für interne Webanwendungen, AES-256 für ruhende Daten, WPA3-Enterprise / 802.1X
Prüfungsnachweise	TLS-Konfigurationsberichte, Cipher-Suite-Konfiguration der Wireless-Controller, Status der Festplattenverschlüsselung
Bewertungsfrage	Wird der drahtlose Datenverkehr, der industrielle Steuerungssignale (z. B. AGV/ASC-Steuerung) überträgt, durch Verschlüsselung auf Enterprise-Niveau geschützt?

FR 5 — Eingeschränkter Datenfluss (RDF)

Element	Beschreibung
Ziel	Segmentierung von Kommunikationsnetzen zur Isolierung kritischer Assets und Beschränkung des Datenflusses auf autorisierte Kanäle.
Beispiel Hafen-OT	Unterbindung der direkten Kommunikation zwischen dem IT-Unternehmensnetzwerk und dem SPS-Netzwerk der Containerbrücken.
Typische Maßnahmen	Stateful Firewalls, industrielles IPS, IDMZ-Reverse-Proxies, unidirektionale Sicherheitsgateways/Datendioden
Prüfungsnachweise	Firewall-Regelwerke, VLAN-Routing-Tabellen, Validierung der DMZ-Architektur, Logs unidirektionaler Gateways
Bewertungsfrage	Sind alle zonenübergreifenden Conduits durch restriktive Firewall-Regelsätze (Default Deny) beschränkt?

FR 6 — Frühzeitige Reaktion auf Ereignisse (TRE)

Element	Beschreibung
Ziel	Erkennung, Protokollierung, Analyse und Reaktion auf Sicherheitsvorfälle und betriebliche Anomalien in Echtzeit.
Beispiel Hafen-OT	Alarmierung des Hafen-SOCs, wenn eine unerwartete IP-Adresse versucht, einen Modbus-Schreibbefehl an eine SPS der Flüssiggutsteuerung zu senden.
Typische Maßnahmen	Passives OT NDR, zentralisiertes Log-Management/SIEM, automatisierte Incident-Response-Playbooks
Prüfungsnachweise	SIEM-Ingestion-Logs, Topologie der NDR-Sensoren, Incident-Tickets, Ausführungsprotokolle der SOC-Playbooks
Bewertungsfrage	Werden OT-spezifische Protokollanomalien innerhalb von 60 Sekunden an das Security-Operations-Team weitergeleitet?

FR 7 — Verfügbarkeit von Ressourcen (RA)

Element	Beschreibung
Ziel	Sicherstellen, dass operative Systeme gegenüber DoS-Zuständen resilient bleiben und die kontinuierliche Betriebsfähigkeit aufrechterhalten wird.
Beispiel Hafen-OT	Sicherstellung der Verfügbarkeit der Kransteuerung bei hohem Netzwerk-Broadcast-Aufkommen oder DDoS-Versuchen.
Typische Maßnahmen	Traffic Shaping/Rate Limiting, redundante industrielle Ringtopologien, PRP/HSR, offline gelagerte, unveränderliche Backups (Immutable Backups), manuelle Notfallkonzepte
Prüfungsnachweise	QoS-Konfigurationen, Berichte über Disaster-Recovery-Tests, Verifikationsprotokolle der Offline-Backups
Bewertungsfrage	Können Terminalbetreiber bei einem Ausfall der Netzwerkverbindung in einen sicheren, manuellen Containerumschlagsmodus wechseln?

Technische Sicherheitsarchitektur

Die Implementierung technischer Maßnahmen nach IEC 62443 erfordert ein Defense-in-Depth-Modell, das Identitäten, Netzwerke, Endpunkte und Engineering-Assets umfasst.

Defense-in-Depth-Modell

Schicht	Repräsentative Maßnahmen
Identität und Zugriff	Zentrales Verzeichnis, PAM, MFA, RBAC
Netzwerksicherheit	Mikrosegmentierung, IDMZ, DPI-Firewalls, unidirektionale Gateways
Endgerätesicherheit	Application Allowlisting, Härtung von Systemen, EDR
OT-Monitoring	Passives NDR, DPI-Protokollanalyse, SIEM/SOC-Integration
Resilienz	Unveränderliche Offline-Backups, PRP/HSR-Redundanz, sichere manuelle Betriebskonzepte

Identität, Zugriff und Remote Engineering

Zero-Trust Remote Engineering

Wartungspartnern von Drittanbietern sollte niemals ein direkter VPN-Zugriff auf Netzwerkebene in die Zonen der Ebenen 1 und 2 gewährt werden.

Empfohlener Zugriffspfad

Partner-Verbindung → Outbound-only TLS-Tunnel → Port-PAM/Jump-Host → MFA → Protokollbruch / Sitzungsisolation → Ziel-Asset

Sitzungskontrollen

Verpflichtende Aufzeichnung der Sitzung
Freigabe-Workflow durch Hafenbetreiber in Echtzeit
Automatische Trennung bei Inaktivität
Maximale Inaktivitätsdauer: 15 Minuten

Industrielle Netzwerksegmentierung und DMZ-Architektur

Dual-Firewall IDMZ

Implementieren Sie physisch getrennte Hardware-Firewalls verschiedener Hersteller für die Grenzen zwischen Unternehmensnetzwerk und DMZ sowie zwischen DMZ und OT, sofern dies durch die Risikoanalyse begründet ist.

Dies minimiert die Abhängigkeit von einer einzelnen Firewall-Technologie oder -Schwachstelle.

Deep Packet Inspection (DPI)

Setzen Sie Industrie-Firewalls ein, die zur Protokollanalyse auf Schicht 7 fähig sind.

Blockieren Sie, sofern technisch unterstützt und betrieblich sicher, potenziell kritische Befehle wie:

STOP
PROGRAM
FIRMWARE_DOWNLOAD

während notwendige Lese- und Telemetriedaten zugelassen werden.

Fernzugriff und Sicherheitsrahmenwerk für Drittanbieter

Sicherheitsrisiken in der Lieferkette durch Drittanbieter stellen ein erhebliches Risiko für den Erstzugriff in Hafenumgebungen dar.

Sicherer Fernzugriffs-Ablauf

Schritt	Kontrollpunkt
1	Partner initiiert Sitzung über Webportal via HTTPS
2	Identity Provider erzwingt MFA
3	Hafen-Ingenieur gewährt ein zeitlich begrenztes Zugriffsfenster
4	PAM stellt eine isolierte Bastion-Sitzung via RDP/SSH-Proxy her
5	Eine DPI-Überprüfung der Sitzung wird erzwungen; Befehle werden auditiert und protokolliert
6	Die Sitzung wird nach Abschluss oder bei Erkennung anomaler Aktivitäten automatisch beendet

Sicherheitsanforderungen für den Partner-Fernzugriff

Anforderung	Maßnahme
Kein direkter Mobilfunkzugriff	Direkte Mobilfunkmodems an Kranen oder SPSen dürfen keinen unkontrollierten Zugriff ermöglichen. Der Fernzugriff muss zwingend über das PAM-Gateway des Unternehmens erfolgen.
Personalisierte Accounts	Generische Konten von Dienstleistern sind zu verbieten. Jeder externe Techniker muss namentlich registrierte Zugangsdaten verwenden, die an seine Identität im Partnerunternehmen gekoppelt sind.
Hardware-Token	Remotesitzungen, bei denen sicherheitsrelevante Parameter geändert werden, müssen hardwarebasierte MFA (z. B. FIDO2/WebAuthn) nutzen, sofern dies unterstützt wird.

Protokollanalyse-Matrix für die SOC-Inbetriebnahme im Hafen

Protokoll	Typische Nutzung im Hafen	SOC-Erkennungs-Use-Case / Anomalie-Trigger
Profinet / S7	Siemens Kran-SPSen, ASCs	Alarmierung bei CPU-Statusänderungen (RUN → STOP) oder Logik-Uploads
Modbus TCP	Flüssigguttransfer, Leistungsmesser	Alarmierung bei den Funktionscodes 05, 06 und 16 (Schreiboperationen)
EtherNet/IP (CIP)	Kranantriebe von Rockwell/ABB	Alarmierung bei „Forward Open“-Anfragen aus nicht erfassten IP-Subnetzen
NMEA 0183 / NMEA 2000	Maritime Schnittstelle zum Schiff	Alarmierung bei Abweichungen der Positionsdelta-Werte, die auf potenzielles GNSS-Spoofing hindeuten
IEC 60870-5-104	Stationsleittechnik im Umspannwerk	Alarmierung bei unbefugten Test- oder Steuerbefehlen an Leistungsschalter

Incident Response und betriebliche Resilienz

Im Falle eines OT-Sicherheitsvorfalls müssen die Eindämmungsprotokolle der physischen Sicherheit (Safety) und der Aufrechterhaltung des Terminalbetriebs höchste Priorität einräumen.

Phasen der OT-Vorfallreaktion

Phase	Maßnahme
Phase 1 — Sicherheitsprüfung (Safety)	Sicherstellen des gefahrenfreien physischen Zustands aller schweren Maschinen.
Phase 2 — Isolation	Isolierung der betroffenen Zone über vordefinierte Mechanismen zur Netzwerktrennung.
Phase 3 — Betriebsumstellung	Wechsel auf manuellen Containerumschlag / Offline-Protokollierung der Betriebsabläufe.
Phase 4 — Forensische Sicherung	Sicherung von Arbeitsspeicher, SPS-Code und relevanten forensischen Daten aus betroffenen EWS- und SPS-Umgebungen, sofern technisch und betrieblich vertretbar.
Phase 5 — Re-Baselining	Wiederherstellung verifizierter SPS-Programme und Konfigurationen aus unveränderlichen Offline-Sicherungen.

Sicherer manueller Rückfallmodus — Ausfall der Automatisierung

Betriebsbereich	Manueller Rückfallmodus
Kransysteme	Aufrechterhaltung lokaler manueller Steuerungsmöglichkeiten in der Kabine unabhängig von Remote-Netzwerksignalen. Durchführung regelmäßiger Schulungen für Kranführer im manuellen Betrieb.
Gate-Betrieb	Etablierung papierbasierter oder offline-fähiger Erfassungsprozesse per Tablet für die Lkw-Abwicklung, um Staus bei TOS-Ausfällen zu verhindern.
Flüssiggutterminals	Sicherstellen, dass mechanische Überdruckventile und manuelle Absperrvorrichtungen ohne elektrische oder Netzwerkabhängigkeiten betrieben werden können.

Lieferkettensicherheit und Software Bill of Materials (SBOM)

Die Beschaffung von Hafengeräten betrifft Wirtschaftsgüter mit jahrzehntelangen Lebenszyklen. Terminalbetreiber sollten daher bereits in der Ausschreibungs- und Beschaffungsphase konkrete Cybersecurity-Anforderungen integrieren.

Sicherheitsanforderungen bei der Beschaffung

Anforderung	Zu liefernder Nachweis des Herstellers
Konformität mit IEC 62443-4-1	Nachweis, dass Software/Firmware im Rahmen eines sicheren Entwicklungsprozesses (Secure Development Lifecycle) entwickelt wurde
Bereitstellung einer SBOM	Maschinenlesbare Software Bill of Materials (SBOM) in Standardformaten wie CycloneDX oder SPDX
Vulnerability SLA	Vertragliche Zusage für verifizierte Patches bei kritischen Schwachstellen innerhalb definierter Fristen über den gesamten Lebenszyklus

IEC 62443 Audit- und Nachweisrahmenwerk

Die Einhaltung von Sicherheitsvorgaben muss durch verifizierbare Nachweise belegt werden.

Nachweiskategorie	Primäres Dokument	Erstellungsfrequenz	Validierung durch den Auditor	Häufige Mängel
Architektur	Zonen- und Conduit-Konzept, Netzwerkpläne	Vierteljährlich / nach Änderungen	Abgleich der physischen Verkabelung mit den logischen Diagrammen; Überprüfung von Switch-Trunk-Konfigurationen	Veraltete Pläne; fehlende Erfassung von LTE-Modems oder nicht dokumentierten Switches
Zugriffskontrolle	Benutzermatrix, PAM-Logs, Firewall-Regelwerke	Monatlich	Abgleich aktiver Active-Directory-Benutzer mit HR-Stammdaten	Inaktive Konten von externen Dienstleistern mit weiterhin aktiven administrativen Rechten
Integrität	Prüfsummen von SPS-Programmen, Allowlisting-Logs	Automatisiert täglich/wöchentlich	Vergleich der laufenden SPS-Prüfsummen mit der autorisierten Baseline	Nicht genehmigte Code-Änderungen während dringender Notfallwartungen
Resilienz	Protokolle unveränderlicher Backups, Ergebnisse von DR-Tests	Halbjährlich	Begleitung der praktischen Wiederherstellung eines SCADA-Servers und von SPS-Konfigurationen	Fehlen spezifischer Treiber in den Backups oder Speicherung auf ungesicherten, vernetzten NAS-Systemen

Reifegradmodell für Hafen-OT-Cybersecurity — P-CSMM

Dieses praxisnahe fünfstufige Reifegradmodell ermöglicht es Häfen, ihren aktuellen Status zu bestimmen und Fortschritte im Einklang mit den Prinzipien der IEC 62443 zu messen.

Stufe	Reifegrad	Beschreibung
1	Initial	Nicht erfasste Assets, flache Netzwerke, gemeinsam genutzte Konten (Shared Accounts)
2	Im Aufbau (Developing)	Einfache IT-Firewalls vorhanden; informelle Asset-Listen
3	Definiert (Defined)	Zonen und Conduits gemäß IEC 62443-3-2 etabliert; formelles CSMS aktiv
4	Gesteuert (Managed)	Kontinuierliches OT-NDR-Monitoring; automatisierte Erfassung von Compliance-Nachweisen
5	Optimiert (Optimized)	Dynamische Sicherheitsmaßnahmen; proaktives Bedrohungsmonitoring (Threat Hunting)

Domänen-Reifegradmatrix

Sicherheitsbereich	Stufe 1 — Initial	Stufe 2 — Im Aufbau	Stufe 3 — Definiert	Stufe 4 — Gesteuert	Stufe 5 — Optimiert
Governance	Keine dedizierte OT-Sicherheitsrolle	IT-Team betreut die OT ad hoc mit	CSMS gemäß 2-1 etabliert; OT-CISO ernannt	KPI/KRI-Dashboard wird an den Vorstand berichtet	Kontinuierliche Optimierung und Auditierung des CSMS
Architektur	Flaches Schicht-2-Netzwerk	Einfache VLAN-Trennung	Zonen und Conduits durch Firewalls durchgesetzt	Mikrosegmentierung mit DPI	Unidirektionale Gateways für kritische Zonen
Monitoring	Keine Protokollierung auf OT-Ebene	Zentralisierter Syslog-Server	OT-NDR; Alarme bei Protokollanomalien	SIEM/SOAR-Integration und SOC-Playbooks	Fortgeschrittenes Threat Hunting und automatisierte Vorfallreaktion
Lieferkette	Keine Sicherheitsprüfung von Dienstleistern	Ad-hoc-Sicherheitsvereinbarungen (NDAs)	Einkaufsrichtlinien nach IEC 62443	Verpflichtung zu SBOM-Lieferung und Patch-SLAs	Kontinuierliches Risikomanagement für Drittanbieter

24-Monats-Implementierungs-Roadmap

Überblick über den Ablauf

Zeitraum	Phase	Primäres Ziel
Monate 0–1	Phase 1	Governance, Asset-Erfassung und Abgrenzung des Scopes
Monate 1–3	Phase 2	Schwachstellenminimierung und Etablierung von Baselines
Monate 3–6	Phase 3	Zonenarchitektur und Netzsegmentierung
Monate 6–12	Phase 4	Identitäts- und Zugriffsschutz sowie PAM-Einführung
Monate 12–24	Phase 5	Kontinuierliches Monitoring und vollständige Absicherung

Phase 1 — Governance, Asset-Erfassung und Abgrenzung des Scopes

Monate 0–1

Aktivität	Maßnahme
Governance	Gründung eines OT-Sicherheitsausschusses bestehend aus Vertretern der Hafenbehörde, des Terminalbetriebs und der Technik
Asset-Erfassung	Einsatz passiver Monitoring-Sensoren zum Aufbau eines vollständigen OT-Asset-Inventars
Risikoanalyse	Definition des Risikoappetits und Durchführung einer ersten High-Level-Risikoanalyse nach IEC 62443-3-2
Sofortmaßnahme	Identifizierung und Trennung direkter Internetverbindungen der OT sowie unbefugter Modems

Phase 2 — Schwachstellenminimierung und Etablierung von Baselines

Monate 1–3

Beseitigung gemeinsam genutzter administrativer Zugangsdaten auf HMIs, EWS und Jump-Hosts.
Einführung strikter Prüfprotokolle für USB-Datenträger, die durch Wartungspersonal genutzt werden.
Einrichtung unveränderlicher Offline-Backups für SPS-Steuerungscode, SCADA-Datenbanken und TOS-Konfigurationen.
Implementierung von Application Allowlisting auf geeigneten Windows-basierten Arbeitsstationen der Ebenen 2 und 3.

Phase 3 — Zonenarchitektur und Netzsegmentierung

Monate 3–6

Konzeption der logischen Zonen- und Conduit-Architektur basierend auf der detaillierten IEC 62443-3-2 Risikoanalyse.
Aufbau einer industriellen DMZ (Ebene 3.5), wo betrieblich erforderlich.
Migration gemeinsam genutzter Dienste wie TOS-Schnittstellen, Historians und Patch-Infrastrukturen in kontrollierte Zonen.
Konfiguration von Schicht-7-Industriefirewalls zwischen den operativen Zonen.
Implementierung grundlegender Fernzugriffskontrollen über ein zentrales PAM-System.

Phase 4 — Zugriffskontrolle und PAM

Monate 6–12

Einführung von WPA3-Enterprise / 802.1X-Authentifizierung für mobile Umschlagsgeräte.
Integration von PAM mit MFA für externe Wartungszugriffe.
Einsatz passiver OT-NDR-Sensoren an kritischen Conduits.
Durchführung von Notfallübungen für manuelle Betriebsabläufe bei Automatisierungsausfall.

Phase 5 — Kontinuierliches Monitoring und vollständige Absicherung

Monate 12–24

Vollständige Integration von OT-NDR-Alarmen in das zentrale SOC/SIEM.
Etablierung automatisierter Prozesse zur Erstellung von Nachweisen für Compliance-Audits.
Verpflichtende Anforderung von SBOMs und entsprechenden IEC 62443-Herstellernachweisen bei neuen Beschaffungen.
Durchführung kontrollierter Sicherheitstests und unabhängiger Bewertungen entsprechend dem Risikoprofil des Terminals.

Betriebliche KPIs und Executive KRI-Dashboard

Kennzahlen stellen sicher, dass das Sicherheitsniveau sowohl für die Technik-Teams als auch für die Geschäftsführung messbar bleibt.

Technische KPIs

KPI	Zielwert
Sichtbarkeit der OT-Assets in %	100 % einer spezifischen Zone und einem Conduit zugeordnet
Integritätsrate der SPS-Backups	100 % erfolgreiche automatisierte Validierung der Backup-Hashes pro Woche
Erkannte unbefugte Änderungen	0 nicht genehmigte SPS-Code- oder Parameteränderungen pro Monat
Mittlere Erkennungszeit (MTTD) für OT-Anomalien	< 5 Minuten

Executive Risk Dashboard

Metrik	Aktueller Status	Zielzustand	Status
OT-Schwachstellen mit hoher Ausnutzbarkeit	4 Systeme	0 Systeme	Handlungsbedarf
Anteil veralteter / nicht mehr unterstützter Systeme	12 %	< 5 %	In Umsetzung
Unkontrollierte Fernzugriffspunkte	0	0	Konform
SLA-Compliance kritischer Dienstleister	94 %	100 %	Aufmerksamkeit erforderlich
Wiederherstellungszeit bei Notfall-Backups	42 Minuten	< 60 Minuten	Konform

Typische Fehler in der Hafen-OT-Cybersecurity

#	Fehlermuster
1	Unreflektiertes Übertragen von IT-Richtlinien auf die OT, wie beispielsweise die Erzwingung von Passwortänderungen alle 30 Tage ohne Berücksichtigung der betrieblichen Auswirkungen
2	Betrieb flacher Netzwerke und das blinde Vertrauen in eine physische Netztrennung („Air Gap“), die tatsächlich nicht existiert
3	Behandlung von Asset-Inventaren als einmalige, statische Tabellenprojekte
4	Einsatz aktiver Schwachstellenscanner gegen veraltete SPS-Systeme ohne vorherige Absicherung durch die Fachabteilung
5	Zulassen unkontrollierter Mobilfunkmodems, die von Herstellern für den Remote-Support installiert werden

Strategische Lösungsansätze

Statt	Implementieren Sie
Aktives Scannen sensitiver OT	Passives Out-of-Band-Netzwerk-Monitoring unter Verwendung von TAPs/Sensoren zur Erkennung von Assets und Schwachstellen, ohne die OT-Verfügbarkeit zu gefährden
Ausschließlich digitaler Schutzmaßnahmen	Physische und mechanische Verriegelungen für sicherheitskritische Systeme, sodass eine kompromittierte SPS keine unkontrollierbaren physischen Schäden verursachen kann
Statischer Inventare	Kontinuierliche, automatisierte Asset-Erfassung, die direkt in die CMDB oder ein gleichwertiges Asset-Management-System des Hafens integriert ist

Praxisnahe Fallstudie — „Port Apex“

Hinweis: Die folgende Fallstudie ist praxisnah gestaltet, jedoch vollständig fiktiv.

Architektur der Umgebung

„Port Apex“ betreibt:

8 Containerbrücken (STS-Krane)
24 automatische Stapelkrane (ASCs)
Eine automatisierte Gate-Anlage zur Abwicklung von rund 5.000 Lkw täglich
Ein integriertes Navis N4 Terminal-Operating-System

Szenario des Vorfalls

Der infizierte Wartungs-Laptop eines Servicetechnikers wurde über einen lokalen Netzwerk-Switch in der Kabine direkt mit einem STS-Kran verbunden.

Schadsoftware versuchte, sich über industrielle Modbus-Broadcasts im Netzwerk auszubreiten. Dies blockierte lokale HMI-Bildschirme, führte zu Fehlermeldungen bei den Kranantrieben und stoppte den Betrieb am Liegeplatz.

Behebung und Umsetzung des Sicherheitsleitfadens

Sicherheitsbereich	Implementierung
Zonierung und Segmentierung — 3-2	Port Apex unterteilte das Terminal in sechs separate Sicherheitszonen. Industrielle DPI-Firewalls wurden an den Kran-Conduits installiert, um den Datenverkehr auf autorisierte TOS-zu-SPS-Kommunikation zu beschränken.
Zugriffskontrolle — 3-3 FR 1/FR 2	Direkte Laptop-Verbindungen wurden unterbunden. Wartungstechniker authentifizieren sich nun über ein gehärtetes PAM-Gateway inklusive Sitzungsaufzeichnung.
Systemintegrität — 3-3 FR 3	Application Allowlisting wurde auf allen HMIs eingeführt und ein automatisiertes System zur Überwachung der SPS-Programm-Integrität implementiert.
Erreichtes Ergebnis	Port Apex wies das Sicherheitsniveau 3 (SL-A 3) für kritische Kran- und Gate-Zonen nach, bestand ein unabhängiges Audit nach IEC 62443 und verhinderte die Seitwärtsbewegung (Lateral Movement) bei nachfolgenden Angriffssimulationen erfolgreich.

Umfassende IEC 62443 Audit-Checkliste für Häfen

Diese Checkliste unterstützt formelle Sicherheitsaudits und interne Lückenanalysen in OT-Umgebungen von Häfen.

Domäne	Prüffrage	IEC 62443 Standardbezug	Erforderliche Nachweise	Status (Erfüllt/Nicht erfüllt/Nicht anwendbar)	Risikostufe	Empfohlene Maßnahme
Governance	Ist ein formelles Cybersecurity-Managementsystem (CSMS) dokumentiert und von der Geschäftsführung freigegeben?	2-1 Abschnitt 4.2	CSMS-Richtlinie, Protokoll der Freigabe durch die Geschäftsführung	—	Hoch	Erstellung und Inkraftsetzung eines auf das Unternehmensrisiko ausgerichteten CSMS-Rahmenwerks
Asset-Erfassung	Existiert ein automatisiertes, kontinuierlich aktualisiertes Asset-Inventar aller verbundenen OT-Systeme?	2-1 Abschnitt 4.3.3	CMDB-Export, Baseline aus passiven NDR-Systemen	—	Kritisch	Einsatz passiver OT-Netzwerk-Monitoring-Sensoren
Architektur	Sind die OT-Netzwerke in Zonen und Conduits segmentiert und durch entsprechende Firewalls geschützt?	3-2 Abschnitt 5.3	Netzwerkpläne, Firewall-Regelwerke	—	Kritisch	Implementierung einer Netzsegmentierung zur Trennung der verschiedenen OT-Ebenen
Fernzugriff	Erfolgt jeglicher Fernzugriff von Drittanbietern über einen zentralen PAM-Jump-Host mit zwingender MFA?	2-4 SP.03 / 3-3 FR 1.1	PAM-Konfiguration, MFA-Protokolle	—	Kritisch	Abschaltung direkter VPN-Verbindungen/Modems; Durchsetzung eines kontrollierten Remote-Zugangs
Zugriffskontrolle	Sind für administrative Aktionen auf EWS und HMIs personalisierte Konten zwingend vorgeschrieben?	3-3 FR 1.2 / FR 2.1	AD/GPO-Konfigurationen, PAM-Logs	—	Hoch	Beseitigung gemeinsam genutzter Zugangsdaten; Einführung rollenbasierter Zugriffskontrollen (RBAC)
Systemintegrität	Werden SPS-Prüfsummen kontinuierlich auf nicht autorisierte Abweichungen überwacht?	3-3 FR 3.1	Vergleichsprotokolle zur Baseline	—	Hoch	Implementierung einer Konfigurationsüberwachung für Steuerungsgeräte
Datenfluss	Wird der Datenverkehr industrieller Protokolle an den Zonenübergängen (Conduits) tiefergehend analysiert (DPI)?	3-3 FR 5.1	Exportierte DPI-Richtlinien, Protokolle der Regelüberprüfung	—	Hoch	Aktivierung einer dedizierten Protokollüberprüfung
Resilienz	Werden unveränderliche, getestete Offline-Backups für SCADA-Datenbanken und SPS-Programme vorgehalten?	2-1 Abschnitt 4.4.3 / 3-3 FR 7.3	Prüfsummen der Backups, Abnahmeberichte der DR-Tests	—	Kritisch	Einrichtung von Routinen für Offline-Backups und regelmäßige Wiederherstellungstests
Lieferkette	Erzwingen Beschaffungsverträge die Bereitstellung von SBOMs und konkrete Zusagen zum Patch-Management?	2-4 / 4-1	Vertragsklauseln, Service Level Agreements (SLAs) der Hersteller	—	Mittel	Anpassung der Einkaufs- und Ausschreibungsbedingungen

Abschließende Bewertung des Sicherheitsniveaus

Um die Gesamtsicherheit eines Hafens oder maritimen Terminals zu bestimmen, wenden Sie das gewichtete Bewertungsmodell an, das auf den Ergebnissen der Audit-Checkliste basiert.

Sicherheitsbewertung (Readiness Score)

Sicherheitsbewertung (%) = (Anzahl erfüllter Maßnahmen ÷ Anzahl anwendbarer Maßnahmen) × 100

Interpretation der Sicherheitsbewertung

Ergebnisbereich	Reifegradstufe	Compliance-Status	Betriebliche Sicherheit
85–100 %	Stufe 4 / 5	Vollständig konform	Hohe Resilienz / auditfähig
70–84 %	Stufe 3	Weitgehend erfüllt	Moderat Risiken / vereinzelte Lücken
50–69 %	Stufe 2	Nicht konform	Hohes betriebliches Risiko
0–49 %	Stufe 1	Kritische Mängel	Akute Gefahr von Betriebsstillständen/Schäden

Grenzwerte für Maßnahmen

Bedingung	Erforderliche Maßnahme
Eine als kritisch eingestufte Maßnahme ist nicht erfüllt	Herabstufung des Gesamtergebnisses auf „Nicht konform“ und sofortige Einleitung eines Notfallplans zur Behebung
Ergebnis < 70 %	Sofortige Berichterstattung an den Vorstand und beschleunigte Umsetzung der prioritären Roadmap-Aktivitäten

Die Absicherung moderner Häfen und maritimer Terminals gegen Cyber-Bedrohungen erfordert den Übergang von klassischen IT-Sicherheitskonzepten hin zu einem ingenieurtechnisch fundierten Rahmenwerk für Operational Technology (OT).

Die Normenreihe IEC 62443 bietet eine systematische Struktur für die Etablierung robuster Zonen, die Kontrolle von Kommunikationspfaden (Conduits), die Durchsetzung von Zugriffskontrollen, die Überwachung industrieller Netzwerke und die Aufrechterhaltung der Resilienz des Betriebs.

Durch die Implementierung des in diesem Dokument beschriebenen Leitfadens – Erfassung kritischer Assets, Festlegung angestrebter Sicherheitsstufen, Aufbau von Defense-in-Depth-Maßnahmen und Erbringung verifizierbarer Nachweise – können Hafenbehörden und Terminalbetreiber ihre Resilienz stärken, die physische Sicherheit gewährleisten und den reibungslosen Ablauf maritimer Lieferketten nachhaltig absichern.

Das Ziel darf nicht das Erreichen von Compliance durch isolierte Sicherheitslösungen sein. Ein resilienter Hafen erfordert eine ganzheitliche Sicherheitsarchitektur, die folgende Bereiche verzahnt:

Mitarbeiter + Prozesse + Physische Sicherheit + Informationssicherheit + Cybersecurity + Lieferkette + Governance + Auditierung

Buchen Sie hier ein kostenloses Informationsgespräch zur IEC 62443 für Ihren Hafen.

Referenzen

International Electrotechnical Commission (IEC), IEC 62443 Series — Industrial Communication Networks — Network and System Security.
IEC 62443-2-1:2024 — Security Program Requirements for IACS Asset Owners.
IEC 62443-2-4:2023 — Security Program Requirements for IACS Service Providers.
IEC 62443-3-2:2020 — Security Risk Assessment for System Design.
IEC 62443-3-3:2013 — System Security Requirements and Security Levels.
IEC 62443-4-1:2018 — Secure Product Development Lifecycle Requirements.
IEC 62443-4-2:2019 — Technical Security Requirements for IACS Components.
International Maritime Organization (IMO), Resolution MSC.428(98) — Maritime Cyber Risk Management in Safety Management Systems.
IMO, MSC-FAL.1/Circ.3/Rev.3 — Guidelines on Maritime Cyber Risk Management.
International Association of Ports and Harbors (IAPH), IAPH Cybersecurity Guidelines for Ports and Port Facilities.
European Union Agency for Cybersecurity (ENISA), Port Cybersecurity — Good Practices for Cybersecurity in Maritime Ports.
Cybersecurity and Infrastructure Security Agency (CISA), Cross-Sector Cybersecurity Performance Goals (CPGs) und Richtlinien für das maritime Transportsystem.
U.S. Coast Guard (USCG), Navigation and Vessel Inspection Circular (NVIC) 01-20 — Guidelines for Addressing Cyber Risks at Maritime Transportation Security Act (MTSA) Regulated Facilities.
Europäische Union, Richtlinie (EU) 2022/2555 — NIS-2-Richtlinie.
Shieldworkz-Leitfäden zur Behebung von Sicherheitsrisiken
Regulatorische Handbücher von Shieldworkz