IEC-62443-Prinzipien im RAMS-Lebenszyklus: Security entlang der Bahn-Safety-Logik

Problem in der Praxis

In Bahnprojekten existieren zwei reife, aber getrennte Welten. Die Safety-Organisation arbeitet seit Jahrzehnten diszipliniert nach RAMS, mit klaren Lebenszyklusphasen, Nachweisführung und Zulassungslogik. Die Security-Organisation kommt oft aus dem IT- oder ISMS-Umfeld und denkt in anderen Begriffen und Taktungen.

Werden beide Welten nicht zusammengeführt, entstehen typische Bruchstellen: Security-Anforderungen treffen spät auf ein eingefrorenes Safety-Design; Zonen- und Conduit-Schnitte passen nicht zur funktionalen Architektur; Patch-Management kollidiert mit der Zulassung sicherheitsrelevanter Systeme, weil jede Änderung den Safety-Nachweis berühren kann. Am Ende fragt eine NIS2-Aufsicht nach Nachweisen, die nie systematisch erzeugt wurden. Das Ergebnis ist teuer: nachträgliche Aufsätze, Reibung und unklare Risikoverantwortung.

CISO-Einordnung

Die Kombination IEC 62443 / CLC/TS 50701 / EN 50126 beantwortet nicht "Welche Norm gilt?", sondern "Wie steuern wir Security so, dass sie zum Engineering der Bahn passt?". Dazu gehören drei Einordnungen.

Erstens, die methodische Basis ist IEC 62443: das betrachtete System abgrenzen (System-under-Consideration), in Zonen und Conduits aufteilen, Security Levels zuordnen und Anforderungen aus einer Risikobewertung ableiten. CLC/TS 50701 ist die bahnspezifische Konkretisierung dieser Logik.

Zweitens, der Trägerrahmen ist der RAMS-Lebenszyklus nach EN 50126, ein Prozess-, kein Produktstandard. Cybersecurity gehört ausdrücklich nicht zu RAMS. CLC/TS 50701 nutzt die Lebenszyklusphasen (Konzept, Spezifikation, Design, Implementierung, Betrieb/Wartung, Stilllegung) als Aufhänger und ergänzt die Security-Dimension.

Drittens, die Rechtspflicht kommt von außen. CLC/TS 50701 ist eine Technische Spezifikation der CENELEC, kein Gesetz; die Pflicht zum Cyberrisikomanagement folgt aus NIS2 für den Sektor Verkehr/Schienenverkehr und dem nationalen Recht. Die Norm liefert das anerkannte "Wie", nicht das verbindliche "Ob".

Umsetzungsperspektive

Die Leitidee lautet: ein Lebenszyklus, zwei Dimensionen. Security-Aktivitäten werden an dieselben Phasen gehängt, in denen ohnehin RAMS-Entscheidungen fallen. In Konzept und Spezifikation entsteht ein erster Zonen-/Conduit-Entwurf, der zur funktionalen und zur Safety-Architektur passt; die Risikobewertung sollte anschlussfähig zur etablierten Bahn-Risiko-Logik sein, für die sich CLC/TS 50701 auch auf die CSM-RA-Methodik der Verordnung (EU) 402/2013 bezieht. In Design und Implementierung werden Security Levels zugeordnet und Anforderungen gemeinsam mit Safety abgeleitet, damit Schutzmaßnahmen die RAMS-Eigenschaften nicht untergraben. In Betrieb und Wartung greifen die Daueraufgaben: Vulnerability- und Patch-Management, sichere Beschaffung, Assurance und Nachweisführung.

Die deutsche Vornorm DIN VDE V 0831-104 zeigt, dass dieser IEC-62443-basierte Ansatz im Bahnumfeld nicht neu ist; sie ist jedoch enger auf Signal- und Sicherungstechnik fokussiert, während CLC/TS 50701 den breiteren Rahmen über Communications, Signalling & Processing, Rolling Stock und Fixed Installations spannt.

Typische Fehler

1. Security wird als nachgelagertes Projekt statt als Dimension des RAMS-Lebenszyklus organisiert.
2. EN 50126 wird fälschlich als Cyber-Norm verstanden; tatsächlich liefert sie RAMS und Lebenszyklus, aber keine Security.
3. Zonen- und Conduit-Schnitte werden rein IT-getrieben gezogen und passen nicht zur Safety- und Funktionsarchitektur.
4. Patch- und Änderungsprozesse für Security ignorieren die Zulassungslogik sicherheitsrelevanter Systeme.
5. Die Norm wird mit der Rechtspflicht verwechselt; verbindliche Vorgaben inklusive Meldefristen stammen aus NIS2 und nationalem Recht, nicht aus CLC/TS 50701.

Risiken und Trade-offs

Der zentrale Trade-off liegt zwischen Safety und Security. Eine Maßnahme, die einen Angriff erschwert, kann die Verfügbarkeit oder Wartbarkeit eines sicherungstechnischen Systems beeinträchtigen; umgekehrt darf Safety nicht als Argument dienen, notwendige Security dauerhaft zu verschieben. Beide Disziplinen müssen denselben Risikobegriff sprechen lernen, ohne ihre Nachweislogik aufzugeben.

Hinzu kommen zwei weitere Spannungen. Die Tiefe der Zonen-/Conduit-Architektur ist zu grob ohne Schutzwirkung, zu fein im langlebigen Bahnbetrieb kaum pflegbar; Bahnsysteme leben Jahrzehnte, während Bedrohungen sich schnell ändern. Und die Behördenzuordnung muss sauber abgebildet sein: Cyber/NIS2-Aufsicht liegt in Deutschland beim BSI, die eisenbahnrechtliche Safety-Aufsicht beim Eisenbahn-Bundesamt.

Entscheidungspunkte

• Wie definieren wir das betrachtete System (System-under-Consideration) und wer verantwortet den Zonen-/Conduit-Schnitt gemeinsam mit Safety?
• An welchen RAMS-Lebenszyklusphasen verankern wir verbindlich welche Security-Aktivitäten und -Nachweise?
• Wie integrieren wir Vulnerability- und Patch-Management in die Zulassungs- und Änderungslogik sicherheitsrelevanter Systeme?
• Welche Risikomethodik nutzen wir, und wie sichern wir die Anschlussfähigkeit zur Bahn-Risiko-Logik (CSM-RA)?
• Wie trennen und verbinden wir die Pflichten gegenüber BSI (NIS2/Cyber) und Eisenbahn-Bundesamt (Safety)?

Praktische Empfehlungen

1. Behandeln Sie Security als zweite Dimension desselben RAMS-Lebenszyklus, nicht als separates Nebenprojekt.
2. Schneiden Sie Zonen und Conduits gemeinsam mit Safety und Engineering, ausgerichtet an der funktionalen Architektur.
3. Verankern Sie Security-Nachweise dort, wo ohnehin RAMS-Nachweise entstehen, damit Assurance ein Nebenprodukt des Lebenszyklus wird.
4. Etablieren Sie gemeinsame Änderungs- und Freigabeprozesse für Patch-/Schwachstellenmanagement, die die Zulassung nicht blockieren.
5. Leiten Sie die Rechtspflicht aus NIS2 und nationalem Recht ab und nutzen Sie CLC/TS 50701 als anerkannte Umsetzungsmethodik.
6. Beobachten Sie die internationale Normung (geplanter Standard IEC 63452) als Roadmap-Thema, ohne darauf bereits verbindliche Aussagen zu stützen.

Relevante Normreferenzen

• CLC/TS 50701: Railway applications: Cybersecurity. Technische Spezifikation der CENELEC (TC 9X); 1. Ausgabe 2021, aktuelle 2. Ausgabe CLC/TS 50701:2023. Überträgt IEC-62443-Prinzipien auf die Bahn und bettet Cybersecurity in den RAMS-Lebenszyklus ein.
• EN 50126-1:2017 / EN 50126-2:2017: RAMS-Lebenszyklus. Prozessrahmen, ausdrücklich kein Cybersecurity-Standard.
• IEC 62443-Reihe: methodische Basis (Security Levels, Zonen/Conduits, IACS-Security), auf die CLC/TS 50701 aufsetzt.
• DIN VDE V 0831-104: deutsche Vornorm, IT-Sicherheitsleitfaden auf Grundlage IEC 62443, Fokus Signal-/Sicherungstechnik.
• IEC 63452 (geplant): kommender internationaler Bahn-Cybersecurity-Standard, derzeit im Entwurf und noch nicht final; Zeitplan und Inhalt vor verbindlicher Nutzung prüfen.
• Richtlinie (EU) 2022/2555 (NIS2): Rechtspflicht für den Sektor Verkehr/Schienenverkehr; nationale Umsetzung über das BSIG i. d. F. NIS2UmsuCG.
• Verordnung (EU) 402/2013 (CSM-RA): Risikomethodik als Referenz für die Security-Risikobewertung.
• ISO/IEC 27001: ergänzendes ISMS auf Management-Ebene; komplementär zur anlagen-/lebenszyklusbezogenen CLC/TS 50701, kein gegenseitiger Ersatz.