Bahn-Cybersecurity: Mapping und Roadmap für Betreiber und Hersteller

Problem in der Praxis

In vielen Bahnorganisationen laufen Cyber-Initiativen parallel und unverbunden. Die Rechtsabteilung arbeitet an NIS2, die OT-Teams an Zonen und Security Levels, die Fahrzeug- und Signaltechnik an Zulassungs- und Sicherheitsnachweisen. Jede Gruppe nutzt eigene Begriffe und Reifegrade. Die Folge sind vermeidbare Reibungsverluste: Anforderungen werden doppelt erhoben, Risiken unterschiedlich bewertet, Nachweise passen nicht zueinander. Spätestens bei Beschaffung, Audit oder Vorfall fehlt die gemeinsame Landkarte, die zeigt, welche Pflicht aus dem Recht stammt, welche Methodik sie trägt und welche Bahnnorm den Lebenszyklus bedient.

Ein zweites Missverständnis verschärft die Lage: CLC/TS 50701 ist eine technische Spezifikation, kein Gesetz. Sie schafft keine eigenständige Rechtspflicht und enthält keine gesetzlichen Melde- oder Umsetzungsfristen. Wer sie wie ein Gesetz behandelt, sucht Fristen an der falschen Stelle; wer sie ignoriert, verliert die anerkannte Methodik für den Bahnbetrieb.

CISO-Einordnung

Die drei Ebenen lassen sich sauber trennen und dann bewusst verbinden:

• NIS2 (Recht, das Warum): Die Richtlinie (EU) 2022/2555 begründet die Pflicht für Betreiber im Sektor Verkehr beziehungsweise Schienenverkehr als wesentliche oder wichtige Einrichtung und verlangt Risikomanagement, Governance und Meldepflichten. Verbindliche Fristen stammen aus NIS2 und der nationalen Umsetzung, nicht aus einer Bahnnorm.
• IEC 62443 (Methodik, das Wie auf OT-Ebene): Sie liefert die OT-Sicherheitslogik mit Security Levels, Zonen und Conduits sowie risikobasierter Anforderungsableitung und ist die Basis, auf der die Bahnspezifik aufsetzt.
• CLC/TS 50701 (Bahnkonkretisierung): Die Spezifikation wendet die IEC-62443-Prinzipien auf den Bahnkontext an, bettet Cybersecurity in den RAMS-Lebenszyklus nach EN 50126 ein und deckt die Domänen Communications, Signalling und Processing, Rolling Stock sowie Fixed Installations ab.

Wichtig ist die Abgrenzung von Safety und Security. EN 50126 beschreibt RAMS (Reliability, Availability, Maintainability, Safety); es ist ein Prozessrahmen und selbst kein Cyber-Standard. CLC/TS 50701 nutzt diesen Lebenszyklus als Aufhänger und ergänzt die Security-Dimension, ohne die Safety-Eigenschaften zu beeinträchtigen; die verwandten Normen EN 50128 und EN 50129 bleiben Safety-Normen. Behördlich gilt in Deutschland: Für NIS2 und Cyber ist das BSI zuständig, auch im Schienenverkehr; das Eisenbahn-Bundesamt ist die Eisenbahn-Aufsicht im Safety-Sinn, nicht die NIS2-Cyber-Behörde.

Umsetzungsperspektive

Eine tragfähige Roadmap folgt der Logik vom Recht über die Methodik zur Bahnpraxis und macht das Mapping zum verbindenden Element.

1. Geltung und Scope klären. Feststellen, ob und als welche Kategorie die Organisation unter NIS2 beziehungsweise das nationale Recht fällt und welche Systeme zum Geltungsbereich gehören. Hersteller und Integratoren klären ihre Rolle als Produktlieferant gegenüber den Betreiberpflichten.
2. Gemeinsame Risikobasis schaffen. Das System under Consideration definieren, in Zonen und Conduits aufteilen, Security Levels zuordnen. Diese IEC-62443-Logik wird in CLC/TS 50701 für den Bahnkontext konkretisiert und mit der Risikomethodik in Anlehnung an CSM-RA (VO (EU) 402/2013) verzahnt.
3. Cyber in den Lebenszyklus einhängen. Security-Aktivitäten den Lebenszyklusphasen zuordnen, von Konzept bis Stilllegung. So entstehen Nachweise im Prozess statt erst vor dem Audit.
4. NIS2-Pflichten auf die Methodik mappen. Governance, Meldewege und Risikomanagement aus NIS2 mit den technischen Maßnahmen der Bahnmethodik verbinden, sodass jede Pflicht eine technische Entsprechung und einen Nachweis hat.
5. Ein ISMS als Klammer nutzen. Ein ISMS nach ISO/IEC 27001 oder IT-Grundschutz liefert die organisatorische Steuerung. Es ist komplementär zu CLC/TS 50701 und ersetzt die bahn- und OT-spezifischen Anforderungen nicht.
6. Roadmap fortschreiben. Die internationale Überführung in IEC 63452 ist im Entwurfsstand; ein definitiver Termin ist geplant, aber noch nicht final. Sie gehört als beobachtetes Roadmap-Item in die Planung, nicht als geltender Standard in die Anforderungen.

Typische Fehler

1. CLC/TS 50701 wird wie ein Gesetz behandelt und nach gesetzlichen Fristen durchsucht, die dort nicht stehen.
2. NIS2 wird rein juristisch bearbeitet, ohne die technischen Maßnahmen der OT-Methodik anzubinden.
3. Safety und Security werden vermischt; EN 50126 wird fälschlich als Cyber-Rahmen verstanden.
4. Der Entwurf IEC 63452 wird als geltender Standard zitiert, obwohl er noch nicht final ist.
5. Ein ISO/IEC 27001-ISMS wird als vollständiger Ersatz für die bahnspezifischen Anforderungen ausgegeben.
6. Behördenzuständigkeiten werden verwechselt, etwa das EBA als vermeintliche NIS2-Cyber-Behörde.

Risiken und Trade-offs

Ein zu rechtszentriertes Programm erfüllt formale NIS2-Pflichten, bleibt aber technisch flach und schützt die Anlagen nicht wirksam. Ein zu technikzentriertes Programm baut saubere Zonen und Security Levels, verfehlt aber möglicherweise Meldepflichten und Governance-Erwartungen.

Ein zweiter Trade-off betrifft das Timing der Normbasis: Wer heute streng auf den IEC-63452-Entwurf optimiert, riskiert Nacharbeit bis zur finalen Fassung; wer ausschließlich auf CLC/TS 50701 setzt, ist methodisch solide, sollte den internationalen Übergang aber im Blick behalten. Schließlich verleiten lizenzpflichtige Norminhalte zur Scheingenauigkeit. Für die Steuerung reichen Struktur und Konzept; verbindliche Details bleiben der Originalnorm vorbehalten.

Entscheidungspunkte

• Fällt die Organisation als wesentliche oder wichtige Einrichtung unter NIS2, und welcher Geltungsbereich ist betreibbar?
• Welche Rolle nimmt die Organisation ein (Betreiber, Infrastruktur, Integrator, Produktlieferant), und welche Pflichten folgen daraus?
• Wie wird das Mapping zwischen NIS2-Pflicht, IEC-62443-Methodik und CLC/TS-50701-Lebenszyklus organisatorisch verankert?
• Welche Risikomethodik wird führend, und wie wird sie mit CSM-RA und dem RAMS-Lebenszyklus verzahnt?
• Wie wird der Übergang zum künftigen internationalen Standard beobachtet und eingeplant?

Praktische Empfehlungen

1. Erstellen Sie eine einseitige Mapping-Landkarte: je Zeile NIS2-Pflicht, methodische Entsprechung (IEC 62443), bahnspezifische Umsetzung (CLC/TS 50701) und Nachweis.
2. Trennen Sie Safety und Security organisatorisch, verzahnen Sie beide aber an den Schnittstellen des Lebenszyklus.
3. Verankern Sie verbindliche Fristen dort, wo sie herkommen: in NIS2 und der nationalen Umsetzung, nicht in der Bahnnorm.
4. Nutzen Sie ein ISMS als organisatorische Klammer und behandeln Sie OT- und Bahnanforderungen als komplementäre Schicht.
5. Führen Sie IEC 63452 als beobachtetes Roadmap-Item mit, ohne es als geltenden Standard zu zitieren.
6. Halten Sie interne Unterlagen auf Struktur- und Konzeptebene und verweisen Sie für Details auf die Originalnormen.

Relevante Normreferenzen

• CLC/TS 50701 (Railway applications, Cybersecurity): bahnspezifische technische Spezifikation der CENELEC; reference-only, kostenpflichtig.
• IEC 62443-Reihe: methodische OT-Basis (Security Levels, Zonen und Conduits); reference-only, kostenpflichtig.
• EN 50126 (RAMS): Safety- und Lebenszyklus-Rahmen, kein Cyber-Standard; reference-only, kostenpflichtig.
• DIN VDE V 0831-104 (IT-Sicherheit Signal-/Sicherungstechnik auf IEC-62443-Basis): nationale deutsche Vornorm, enger gefasst als CLC/TS 50701; reference-only, kostenpflichtig.
• Richtlinie (EU) 2022/2555 (NIS2): rechtliche Pflicht für den Sektor Verkehr; DE-Umsetzung über das BSIG. Frei zugänglich und zitierbar.
• VO (EU) 402/2013 (CSM-RA): freie Risiko-Referenz, in Anlehnung verwendbar.
• ISO/IEC 27001: Referenz für ein organisatorisches ISMS, komplementär; reference-only.
• prEN IEC 63452 (geplant): künftiger internationaler Standard, derzeit Entwurf, noch nicht final; reference-only, Status zu prüfen.