Während eines kürzlich durchgeführten Bewertungsprojekts für einen führenden Metrobetreiber in Indien konnte ich viele Aspekte der Eisenbahn- und Metro-Cybersicherheit aus nächster Nähe beobachten. Wie bei jeder anderen kritischen Infrastruktur müssen Eisenbahnen auf einem sehr einzigartigen Sicherheitsniveau betrieben werden, das betriebliche Schwachstellen, Bedrohungslandschaft, OEM-bezogene Herausforderungen und Compliance-Vorgaben berücksichtigt.

Im Jahr 2026 geht es nicht nur um den Verlust von Daten (was es tatsächlich nie war). Stattdessen geht es darum, die kinetische Sicherheit zu gewährleisten, was bedeutet, dass ein Bit-Flip in einem SCADA-System nicht zu einem SPAD (Signal Passed at Danger) führt. Im heutigen Blog-Beitrag formulieren wir einen strategischen Rahmen zur Sicherung von Railway OT, der weit über die Compliance hinaus zu echter Resilienz führt.

Bevor wir weitermachen, vergessen Sie nicht, unseren vorherigen Beitrag über die Überprüfung von Modbus- und IEC-basierten PLCs durch EU-Versorgungsunternehmen hier zu lesen.

Die Realität der Railway-OT: Über die ersten Schichten hinausblicken

Traditionelle IT betrachtet die Sicherheit durch die Brille der CIA (Confidentiality, Integrity, Availability). In der Railway OT verwenden wir RAMS (Reliability, Availability, Maintainability, Safety). Wenn eine Sicherheitskontrolle (wie z. B. eine Firewall) eine Latenzspitze von 200 ms in einem ETCS (European Train Control System) Paket verursacht, kann dies eine Notbremsung auslösen, die im Wesentlichen einen "fail-safe" Modus darstellt. Dies könnte zu einigen betrieblichen Herausforderungen führen, die eigenständig behandelt werden müssen.   

Übersehene Aspekte und einzigartige Herausforderungen in der Eisenbahn-Cybersicherheit

• Geografische Ausdehnung: Im Gegensatz zu einer Fabrik sind Bahnvermögenswerte über Tausende von Meilen verteilt. Ein "Signaling House" in einem abgelegenen Gebiet ist ein physischer und digitaler Eintrittspunkt.

• Schattens-OT: Wartungsteams installieren oft unautorisierte 4G/5G-Modems für Ferndiagnosen, um nicht zu den Außeneinsätzen reisen zu müssen. Diese umgehen jede Perimeterverteidigung.

• Protokollanfälligkeit: Legacy-Serien-zu-IP-Konverter und ältere Protokolle (wie Profibus oder unverschlüsseltes VHF) stürzen häufig ab, wenn sie einem Standard-IT-Schwachstellenscan ausgesetzt sind.

• Herausforderungen in der Lieferkette: Da Lieferketten weltweit vernetzt sind, könnten einige Zweige der Lieferketten in fragwürdige geografische Regionen führen oder durch solche verlaufen oder die Ketten könnten selbst anfällig für „Lieferkettenvergiftungen“ sein

• OT-Sicherheit ist ein unbeachtetes Detail

• Verschiedener Stand der Konnektivität

Warum institutionelle Leitplanken scheitern

Traditionelle IT-gesteuerte Sicherheitsprogramme scheitern im Schienenverkehr aus drei spezifischen Gründen:

• Philosophiebias: IT-Teams priorisieren das Patchen von "hohen" CVEs. OT-Experten wissen, dass das Patchen eines 30-jährigen Stellwerks ein hohes Risiko darstellt; wir bevorzugen das Virtuelle Patchen am Netzwerkrand. Außerdem sind IT-Sicherheitsteams nicht fließend in OT-Sicherheit.

• Gefahren des aktiven Scannens: Standard-Sicherheitstools verwenden "Aktive Sondierung". Auf einem Schienennetzwerk kann dies einen PLC (Programmable Logic Controller) überfluten und einen "Freeze-in-State"-Fehler verursachen.

• Governance-Silos: Der CISO spricht oft eine andere Sprache als der RAMS-Ingenieur. Ohne eine "Safety-Security-Synchronisation" werden Sicherheitsmaßnahmen oft von Sicherheitsgremien abgelehnt.

Die auf TS 50701 basierende Risiko- und Sicherheitsbewertung

Lassen Sie uns nun CLC/TS 50701 betrachten, den Goldstandard für Eisenbahn-Cybersicherheit. Anders als generische Frameworks integriert es sich direkt mit dem EN 50126 Lebenszyklus.

Phase 1: System unter Betrachtung (SuC)

Wir bewerten nicht "die Eisenbahn." Wir definieren spezifische SuCs mit einzigartigen Eigenschaften:

• Bordnetz: TCMS (Train Control & Management System), PIS (Passenger Information System).

• Strecke: Stellwerke, Balisen, RBC (Radio Block Center).

• Zentrale: Verkehrsmanagementsysteme (TMS), SCADA.

Phase 2: Zonen und Leitungen

Wir gliedern die Umgebung in handhabbare "Sicherheitszonen" basierend auf der Kritikalität.

• Zone 1 (Sicherheitskritisch): Signaltechnik & Stellwerk (SL-4).

• Zone 2 (Betrieblich): CCTV, Lautsprechersysteme (SL-2).

• Zone 3 (Öffentlich): Passagier-WLAN (SL-1).

Schwachstellen- und Risikoanalyse

Wir verwenden STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Privilegieneskalation), um jede Leitung zu bewerten.

Der Implementierungsfahrplan (24-Monats-Strategie)

Lieferketten-Sicherheit: Die "Stückliste"-Politik

Sie sind nur so sicher wie Ihr schwächster Anbieter. Unsere Lieferkettenrichtlinie fordert nun:

• SBOM (Software-Stückliste): Anbieter müssen eine maschinenlesbare Liste aller Bibliotheken in ihrem Code bereitstellen.

• HBOM (Hardware-Stückliste): Identifizierung des Ursprungs der physischen Chips und Komponenten, um "Hintertüren"-Risiken zu mindern.

• VEX (Vulnerability Exploitability eXchange): Anstatt nur CVEs aufzulisten, müssen Anbieter VEX-Dateien bereitstellen, die angeben, ob eine Schwachstelle im Eisenbahnumfeld tatsächlich ausnutzbar ist.

Die Wirtschaft rechtfertigen: Reduzierung des Cyber- und kinetischen Risikos pro Passagier

Im Schienenverkehr rechtfertigen wir Investitionen durch eine Kennzahl für Todesfälle und gewichtete Verletzungen (FWI).

Traditionell:

$$Risiko = Häufigkeit \times Konsequenz$$

Im cyber-physischen Zeitalter berechnen wir die Cyber-FWI-Reduktion:

• Das Modell: Wir ordnen einem "Worst-Case"-Cyber-Szenario (z. B. Fernsteuerung einer Weiche) seine potenzielle FWI-Auswirkung zu.

• Die Rechtfertigung: Wenn eine Investition von $2M$ in Zero Trust Architectur die Wahrscheinlichkeit eines $50-Todesopfer$-Ereignisses um $30\%$ reduziert, wird die Amortisation gegen den VPF (Value of Preventing a Fatality) berechnet, der derzeit in den meisten entwickelten Bahn-Märkten ~$3.2M pro Person beträgt.

• Das Ergebnis: Sicherheit ist nicht mehr ein "Kostenfaktor"; es ist eine Sicherheitsversicherung, die die soziale Betriebslizenz der Marke schützt.

Keinerlei Technologie kann das "Bauchgefühl des Disponenten" ersetzen. Wir müssen Betreiber darin schulen, die relevanten cyberinduzierten Anomalien zu erkennen. Wenn ein Signal "seltsam" reagiert, das System jedoch grünes Licht zeigt, muss der Mensch die Autorität haben, eine manuelle Übersteuerung ohne Angst vor schlechten Leistungsbewertungen zu initiieren.

Dieser Entwurf ist dazu gedacht, als Cybersecurity-Anhang oder Schedule in einem Liefervertrag für Schienenfahrzeuge aufgenommen zu werden. Er bewegt sich weg von vager "Best-Effort"-Sprache und fordert spezifische technische Ergebnisse, die mit CLC/TS 50701 und IEC 62443 übereinstimmen.

Anforderungen an die Cybersicherheit im Eisenbahn-OT

1. Allgemeine Compliance und Governance

1.1. Einhaltung der Standards: Der Lieferant muss die Schienenfahrzeuge in voller Übereinstimmung mit CLC/TS 50701 (Schienenfahrzeuge – Cybersicherheit) und den IEC 62443-4-1/4-2 Standards für sichere Produktentwicklung konzipieren, entwickeln und liefern.

1.2. Sicherheitsziel (SL) Ziel: Der Lieferant muss nachweisen, dass das "System unter Betrachtung" (SuC) ein Mindestniveau von Sicherheitslevel 2 (SL-2) für nicht-kritische Systeme und SL-4 für sicherheitskritische Systeme (z. B. TCMS, Bremsen, Signalisierung) erreicht, wie durch die Risikoanalyse des Auftraggebers definiert.

2. Obligatorische Sicherheitsprodukte

2.1. Software-Stückliste (SBOM): Für jede Softwarekomponente (einschließlich Firmware, OS und Drittanbieterbibliotheken) muss der Lieferant eine SBOM in einem maschinenlesbaren Format (z. B. CycloneDX oder SPDX) bereitstellen. Diese muss mit jeder Softwareveröffentlichung aktualisiert werden.

2.2. Hardware-Stückliste (HBOM): Der Lieferant muss das Ursprungsland und den Hersteller für alle kritischen Kommunikations- und Verarbeitungshardware (CPUs, Netzwerkschalter, 5G-Gateways) offenlegen.

2.3. Offenlegung von Schwachstellen (VEX): Der Lieferant muss Vulnerability Exploitability eXchange (VEX) Dateien zusammen mit der SBOM bereitstellen und angeben, ob spezifische CVEs (Common Vulnerabilities and Exposures) im spezifischen betriebsbedingten Kontext der Eisenbahn ausnutzbar sind.

3. Sichere Gestaltung und Schnittstellenkontrolle

3.1. Netzwerksegmentierung: Der Lieferant muss physische oder logische (VLAN/VPN) Trennung zwischen:

• Sicherheitskritischen Netzwerken (Zugsteuerung)

• Betriebsnetzen (CCTV, PIS)

• Öffentlichen Netzwerken (Passagier-WLAN)

3.2. Unidirektionaler Datenverkehr: Der Datenfluss von sicherheitskritischen Zonen zu betrieblichen/öffentlichen Zonen muss durch ein hardware-gestütztes Unidirektionales Gateway (Daten-Diode) oder eine zustandsbehaftete Firewall mit streng definierten "Erlaubnislisten" vermittelt werden.

3.3. Härtung: Alle industriellen Leitsysteme (ICS) und HMIs müssen "gehärtet" werden, einschließlich der Entfernung unnötiger Dienste, dem Schließen ungenutzter Ports (USB/Ethernet) und dem Deaktivieren von Standardzugangsdaten.

4. Lebenszyklus- und Schwachstellenmanagement

4.1. Patch-Garantie: Der Lieferant muss die Verfügbarkeit von Sicherheitspatches für die gesamte "Design Lifetime" des Schienenfahrzeugs (z. B. 30 Jahre) garantieren.

4.2. Incident-Response: Im Falle einer "kritischen" Schwachstelle (CVSS-Wert 9.0+) muss der Lieferant innerhalb von 72 Stunden einen Minderungsplan und innerhalb von 30 Tagen einen validierten Patch bereitstellen.

4.3. Unterstützung für virtuelles Patchen: Wenn ein physisches Patch aufgrund von RAMS (Sicherheits-)Re-Zertifizierungsanforderungen nicht möglich ist, muss der Lieferant Signaturen für Netzwerkintrusion-Preventionssysteme (IPS) bereitstellen, um "virtuelles Patchen" zu gewährleisten.

5. Zugangs- und Prüfungsrechte

5.1. Remote-Zugriff: Jeder Fernwartungszugriff (z. B. für "predictive Maintenance") muss beantragt, protokolliert und zeitlich begrenzt sein. Multi-Faktor-Authentifizierung (MFA) ist für alle Anbieter von Fernwartungssitzungen obligatorisch.

5.2. Prüfungsrecht: Der Käufer (oder ein benannter Dritter) behält sich das Recht vor, jährliche Penetrationstests und Quellcode-Audits an repräsentativen Zugsets in der Anlage des Lieferanten oder vor Ort durchzuführen.

Wichtige Überlegungen

• Das "30-Jahre-Problem" angehen: Die meisten IT-Verträge enden nach 5 Jahren. Der obige Ansatz bindet den Anbieter an die tatsächliche Lebensdauer des Bahnguts.

• Es vermeidet "CVE-Lärm": Durch die Anforderung von VEX verhindern Sie, dass der Anbieter Schwachstellen ignoriert, und verhindern gleichzeitig, dass er Zeit mit Fehlern verschwendet, die die spezifische Eisenbahnkonfiguration nicht betreffen.

• Es schützt die echte "Air-Gap": Insbesondere das Mandat von Daten-Dioden verhindert das "Flachnetz"-Problem, bei dem ein kompromittierter WLAN-Router Zugang zu den Bremsen verschafft.

Sprechen Sie mit unserem TS 50701-Experten und besprechen Sie Ihre Herausforderungen im Bereich Eisenbahnsicherheit hier.

Downloaden Sie den ICS-Sicherheitsleitfaden für Risikobewertungen im Bereich Transport und Logistik

Erhalten Sie Ihre IEC 62443 und NIS2 Compliance-Checkliste hier.

Downloaden: Incident-Response-Plan-Vorlage für Kritische Infrastruktur-Cybersicherheit