Safety & Security im Eisenbahnwesen
Die Normungslandschaft im Eisenbahnbereich hat sich in den letzten Jahren fundamental gewandelt. Von einer primär sicherheitsorientierten Ausrichtung entwickelt sich ein integrierter Ansatz, der Safety und Security als gleichwertige und sich ergänzende Domänen behandelt. Gegenwärtig läuft noch für viele Normen eine Übergangsphase, wodurch teilweise vorübergehend Inkonsistenzen entstehen.
| Kennung | Jahr | Titel | Anmerkung |
| EN 50716 | 2023 | Bahnanwendungen — Anforderungen an die Softwareentwicklung | (ersetzt EN 50128 und EN 50657) [1] |
| IEC 62443-Serie | - | Industrielle Kommunikationsnetze — IT-Sicherheit für Netze und Systeme | (adaptiert für Bahnanwendungen) [2] |
| CLC/TS 50701 | 2021/2023 | Bahnanwendungen — Cybersicherheit | (erste bahnspezifische Cybersecurity-Norm) [3] |
| EN 50129 | 2019 | Bahnanwendungen-Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme – Sicherheitsbezogene elektronische Systeme für Signaltechnik | - |
Diese Standards repräsentieren einen Paradigmenwechsel von isolierten Sicherheitsbetrachtungen zu einem ganzheitlichen RAMS+Security-Ansatz. Die Integration erfolgt über den gesamten Systemlebenszyklus, von der Konzeption bis zur Außerbetriebnahme. Besonders bemerkenswert ist die Synchronisation mit dem RAMS-Lebenszyklus (vgl. Anhang A) gemäß EN 50126 [4], wodurch Cybersecurity nicht als nachträgliche Ergänzung, sondern als integraler Bestandteil der Systementwicklung etabliert wird.
Die Standardisierung wird hauptsächlich durch CENELEC TC 9X vorangetrieben, mit über 96 Experten aus 20+ Ländern [5]. Für Deutschland wird aus den DKE/AK 351.0.6A/B [6] und DKE/AK 351.3.7A/B [7] zugearbeitet. Die Zusammenarbeit zwischen ERA (European Union Agency for Railways) für Safety und ENISA (European Union Agency for Cybersecurity) für Security prägt die regulatorische Landschaft [8]. International erfolgt die Harmonisierung über das IEC TC 9, wodurch europäische Standards global Anwendung finden.
1. Risiko: Definition und Herausforderungen
Während Safety in der Domaine Eisenbahn stark verankert ist und eine lange Historie hat, ist Security ein vergleichsweise neues Konzept, was sich in bestehende Prozesse und Anforderungen integrieren muss. Ein zentrales Problem sind die langen Lebenszyklen der Produkte, die mit schnellen Update Prozessen, wie von Security Normen gefordert, unvereinbar sind.
Sowohl Safety (Funktionale Sicherheit) als auch (Cyber)Security (Sicherheit vor digitalen Angriffen) werden über die Abschätzung eines Risikos quantifiziert. Während das Safety Risiko aus auf Erfahrungswerten und historischen Daten beruhenden Eintrittswahrscheinlichkeit und Schadensausmaß bestimmt werden kann, benutzt die Security komplexere Modelle, die teilweise Intention und Können eines Angreifers mit einbeziehen.
1.1 Definitionen und theoretische Konzepte
1.1.1 Risikodefinitionen
Die Risikomodellierung unterscheidet sich grundlegend zwischen Safety und Security:
Safety (Funktionale Sicherheit):
Definition nach EN 50716: Risiko ist die Kombination aus erwarteter Häufigkeit eines Schadens und erwartetem Schweregrad dieses Schadens
Modell: Risiko = Eintrittswahrscheinlichkeit × Schadensausmaß
Ziel: Freiheit von inakzeptablem Risiko für menschliche Gesundheit und Umwelt
Security (IT-Sicherheit/Cybersecurity):
Definition nach CLC/TS 50701: Erwarteter Verlust als Wahrscheinlichkeit, dass eine bestimmte Bedrohung eine bestimmte Schwachstelle mit einer bestimmten Folge ausnutzt
Modell: Risiko = Bedrohung × Schwachstelle × Auswirkung
Besonderheit: Keine probabilistische Bewertung möglich, da Angreifer mit Absicht handeln
1.1.2 Etablierte Modelle und Verfahren
Safety-Verfahren:
Fault Tree Analysis (FTA): Top-Down-Analyse zur Identifikation von Fehlerursachen
FMEA/FMECA: Fehlermöglichkeits- und Einflussanalyse zur systematischen Bewertung potentieller Fehler
Bow-Tie-Modell: Kombiniert Fehlerursachen (Fault Tree) und Auswirkungen (Event Tree)
HAZOP: Hazard and Operability Study für systematische Gefahrenanalyse
Security-Verfahren:
Bedrohungsmodellierung: Systematische Identifikation von Angriffsvektoren und Bedrohungsszenarien
Attack Trees: Hierarchische Darstellung möglicher Angriffspfade
Schwachstellenanalyse: Identifikation technischer, organisatorischer und prozessualer Schwachstellen
Penetrationstests: Praktische Überprüfung der Wirksamkeit von Schutzmaßnahmen
1.2 Charakteristische Probleme und Dilemmata
Zwischen safety und security existieren bedeutende Überschneidungen [12, 18] in ihren Zielen und Methodiken, andererseits gibt es auch grundsätzliche Zielkonflikte.
Gemeinsamkeiten:
Beide schützen Menschen, Vermögenswerte und Betrieb vor Schäden [18]
Gemeinsame systematische Fehlerursachen (insbesondere Software-Vulnerabilitäten) [1]
Evidenzbasierte Case-Dokumentation [3, 5]
Verwendung von Integritätsstufen zur Risikoeinstufung (SIL vs. SL) [2, 10]
Ähnliche System-Lebenszyklusmanagement-Ansätze [4]
Im Eisenbahnwesen treten spezifische Zielkonflikte zwischen Safety und Security auf:
Verfügbarkeit vs. Sicherheit:
Safety-Perspektive: Ausfall in einen sicheren Zustand (z.B. Notbremsung) ist akzeptabel
Security-Perspektive: Verfügbarkeit muss gewährleistet bleiben, da DoS-Angriffe zu Betriebsstörungen führen
Dilemma: Sicherheitsrelevante Systeme müssen sowohl in sicheren Zustand gehen als auch verfügbar bleiben
Offenheit vs. Zugriffsbeschränkung:
Safety: Fordert transparente, bedienbare Systeme für Wartung und Notfälle
Security: Erfordert Zugangsbeschränkungen, Authentifizierung und Verschlüsselung
Lösung: Defense-in-Depth mit gestaffelten Schutzmaßnahmen bei gleichzeitiger Bedienbarkeit
Fehlertoleranz vs. Fehlerausnutzung:
Safety: Redundanzen und Fail-Safe-Mechanismen gegen zufällige Fehler
Security: Angreifer nutzen systematisch Schwachstellen aus, auch in Redundanzsystemen
Prinzip: Diversität in Redundanzen zur Vermeidung gemeinsamer Schwachstellen
Legacy-Systeme:
Bestandssysteme ohne integrierte Cybersecurity-Maßnahmen
Lange Lebenszyklen (20-40 Jahre) vs. schnelle Bedrohungsentwicklung
Nachrüstung durch Zonierung und Boundary Protection
1.3 Umgang mit unscharfen oder unsicheren Risikobeiträgen
Die epistemische Unsicherheit wird in beiden Domänen unterschiedlich adressiert:
Konservative Ansätze bei Safety:
Worst-Case-Annahmen bei fehlenden Daten
Sicherheitsfaktoren in Berechnungen
Verwendung historischer Unfalldaten als Referenz
Qualitative Bewertung bei Security:
Da quantitative Risikobewertung nicht möglich ist, werden semi-quantitative Verfahren eingesetzt
Likelihood-Faktoren: Angreifer-Kompetenz, Motivation, Schwachstellen-Ausnutzbarkeit, Exposition
Verwendung von Ordinalskalen (niedrig, mittel, hoch, sehr hoch)
Expertenabschätzungen:
Bei unbekannten Schwachstellen in neuen Systemen: Annahmen basierend auf vergleichbaren Systemen
Regelmäßige Aktualisierung der Risikobeurteilung bei neuen Erkenntnissen
Dokumentation aller Annahmen im Bedrohungsprotokoll
Sensitivitätsanalysen:
Variation von Parametern zur Abschätzung der Auswirkungen
Identifikation kritischer Schwellenwerte
Priorisierung von Maßnahmen nach Robustheit
2. Durchführung von Risikoanalysen
Für die Risikoanalyse im Bereich Safety werden quantitative Verfahren auf Grundlage von Expertenschätzungen eingesetzt. Am häufigsten werden Fehlerbäume (Fault Trees) eingesetzt.
Für die Risikoanalyse im Bereich Security werden diverse Varianten der in der IEC 62443 beschriebenen Methodik eingesetzt.
2.1 Methodologie der Risikoanalyse
Die Eisenbahnbranche verwendet normative Ansätze gemäß EN 50126, EN 50716 und IEC 62443:
Qualitative Risikoanalyse:
Verwendung von Kategorien (z.B. gering, mittel, hoch)
Geeignet für initiale Bewertungen und strategische Entscheidungen
Basiert auf Expertenurteilen und historischen Erfahrungen
Semi-quantitative Risikoanalyse:
Standard in Cybersecurity gemäß CLC/TS 50701
Numerische Bewertung auf Ordinalskalen (z.B. 1-5)
Risikomatrizen zur Kombination von Likelihood und Auswirkung
Ermöglicht Priorisierung und Vergleichbarkeit
Quantitative Risikoanalyse:
Nur für Safety-Aspekte mit ausreichenden statistischen Daten
Berechnung von Fehlerraten und Ausfallwahrscheinlichkeiten
Nicht anwendbar für Security (Prinzip 6 aus CLC/TS 50701)
Normative Grundlagen:
EN 50126: RAMS-Lebenszyklus für Bahnanwendungen
EN 50129: Safety Case-Konzept, Brücke zwischen Safety und Security
IEC 62443: Cybersecurity für industrielle Automatisierungssysteme
ISO 27005: Informationssicherheits-Risikomanagement
2.2 Verwendete Metriken
Die Metriken unterscheiden sich fundamental zwischen Safety und Security:
Safety Integrity Level (SIL):
Definition: Diskrete Stufen (SIL 0-4) zur Festlegung der Sicherheitsintegrität
Höherer SIL: Strengere Anforderungen an Entwicklung und Verifikation
SIL 4: Höchste Integritätsstufe für kritische Funktionen, basiert auf Fehlerwahrscheinlichkeit und Ausfallrate
Security Level (SL):
Definition nach IEC 62443: SL 0-4, basierend auf Angreifertyp
SL-T (Target): Zu erreichender Security-Level
SL-C (Capability): Erreichbarer Security-Level einer Komponente
SL-A (Achieved): Tatsächlich erreichter Security-Level
SL-Vektor:
Sieben grundlegende Anforderungsklassen (FR 1-7): IAC, UC, SI, DC, RDF, TRE, RA
Beispiel-Vektor: (3, 3, 3, 1, 2, 3, 2) für verschiedene Schutzziele
Priorität im Bahnwesen: Verfügbarkeit und Integrität vor Vertraulichkeit
Weitere Metriken:
CVSS: Common Vulnerability Scoring System für Schwachstellenbewertung
Risikoschweregrade: Gering, mittel, erheblich, hoch, sehr hoch
Auswirkungskategorien: Funktionale Sicherheit, Betrieb, Finanzen, Reputation, Regulatorik
2.3 Wechselwirkungen zwischen Safety und Security
Die Integration von Safety und Security erfordert explizite Berücksichtigung ihrer Wechselwirkungen:
Defense-in-Depth als gemeinsames Prinzip:
Safety-Analogie: Erster Fehler darf keine Gefahr verursachen, zweiter Fehler wird erkannt
Security-Analogie: Keine einzelne Maßnahme als ausreichend, immer zweite Verteidigungslinie
Schichten: Physisch → Perimeter → Netzwerk → Host → Anwendung → Daten
Behandlung in der Risikoanalyse:
Security als Umweltbedingung für Safety betrachten
Cybersecurity-Angriffe können Safety-Funktionen kompromittieren
Integrierte Bedrohungsszenarien: z.B. Manipulation von Signalstellwerken
Methodische Integration:
Zonierungskonzept: Gemeinsame Architektur für Safety- und Security-Anforderungen
Boundary Protection: Schutz von Zonengrenzen durch Gateways und Firewalls
SecRACs: Security-related Application Conditions analog zu Safety-RACs
Keine direkte Kopplung SIL-SL:
Prinzip 7 (CLC/TS 50701): Maßnahmen für Safety und Security sollen nicht gekoppelt werden, SIL basiert auf Fehlerwahrscheinlichkeit, SL auf Angreifertyp
Mindestanforderung: Jedes Safety-System sollte mindestens SL 1 erfüllen (Schutz vor unbeabsichtigten Fehlern)
Priorisierung von Maßnahmen:
Bei Konflikten: Verfügbarkeit wesentlicher Funktionen hat Vorrang
Im Fehlerfall geschlossen: Nicht wesentliche Funktionen werden gestoppt
Aufrechterhaltung des Safety-Levels auch bei Security-Incidents
3. Domänenübergreifende Zusammenführung
Die Domaine Eisenbahn benötigt eine zuverlässige Energieversorgung und teilt sich somit Herausforderungen mit dem Energiesektor. Als Transportmittel gibt es Überschneidungen zu den anderen Transportsektoren, wobei der sichere Zustand (safety) im Stillstand zumeist gegeben ist. Analog zum Gesundheitswesen ist das System immer im direkten Kundenkontakt und somit nicht durch reinen Perimeterschutz absicherbar.
3.1 Vergleich mit angrenzenden Disziplinen
Das Eisenbahnwesen teilt Herausforderungen mit anderen kritischen Infrastrukturen:
Gemeinsame Herausforderungen:
Legacy-Systeme: Auch in Energie, Luftfahrt, Automotive
Lange Lebenszyklen: 20-40 Jahre typisch für kritische Infrastruktur
Verfügbarkeitsanforderungen: Kontinuierlicher Betrieb erforderlich
Regulatorische Komplexität: Nationale und internationale Vorgaben
Unterschiede zu anderen Domänen:
IT/Software: Kürzere Lebenszyklen, schnellere Updates möglich
Automotive: Individuelle Systeme vs. vernetzte Infrastruktur
Luftfahrt: Höhere Redundanz, aber ähnliche Safety-Security-Integration
Energie: Ähnliche IEC 62443-Anwendung, aber andere Betriebsmodelle
3.2 Methodische Unterschiede und Gemeinsamkeiten
Innerhalb des Eisenbahnwesens existieren domänenspezifische Unterschiede:
Safety-Methoden:
Etabliert seit Jahrzehnten (post-Eschede 1998, Ladbroke Grove 1999)
Probabilistische Modelle mit historischen Daten
Quantitative Ziele (z.B. THR - Tolerable Hazard Rate)
Systematisches Prozessframework (EN 50126-1)
Security-Methoden:
Relativ neu im Bahnwesen (CLC/TS 50701:2023)
Qualitative/semi-quantitative Bewertung
Bedrohungsorientierter Ansatz
Kontinuierliche Anpassung an neue Bedrohungen
Gemeinsame Elemente:
Risikomatrix-Ansätze
Integritätslevel-Konzepte (SIL/SL)
Defense-in-Depth Strategie
Lifecycle-Management
Nachweis-basierte Argumentation (Safety Case/Security Case)
Übertragbare Ansätze:
Bow-Tie-Modell: Kann für Security-Angriffspfade adaptiert werden
FMEA: Erweitert zu FMECA (Criticality Analysis) für Security
Zonierung: Purdue-Modell aus Prozessleittechnik adaptiert
3.3 Gemeinsamer Nenner für Quantifizierung
Die Entwicklung eines gemeinsamen Nenners ist herausfordernd aber essenziell:
Harmonisierte Risikokategorien:
Einheitliche Schweregrad-Skalen für Auswirkungen
Kategorien: Funktionale Sicherheit, Betrieb, Finanzen, Reputation, Regulatorik
Ermöglicht Vergleichbarkeit auch bei unterschiedlichen Ursachen
Kompatible Assessment-Skalen:
Likelihood: 1-5 Skala für beide Domänen
Schweregrad: A-E oder 1-5 für Auswirkungen
Risikoschweregrad: Gering-Mittel-Hoch-Sehr Hoch
Gemeinsame Indikatoren:
Verfügbarkeit: Downtime, MTBF, MTTR
Integrität: Fehlererkennungsrate, False Positive Rate
Auswirkung: Anzahl betroffener Personen, finanzielle Schäden
Integriertes Risiko-Dashboard:
Visualisierung von Safety- und Security-Risiken in gemeinsamer Matrix
Identifikation von Wechselwirkungen und Synergien
Priorisierung von Maßnahmen nach Gesamtrisiko
Grenzen der Quantifizierung:
Security-Risiken bleiben qualitativ/semi-quantitativ
Keine direkte Umrechnung zwischen SIL und SL
Fokus auf konsistente Bewertungsmethodik statt einheitlicher Metrik
=3.4 Erforderliches neues Wissen für Synthese=
Die systematische Integration von Safety und Security erfordert Entwicklung neuer Kompetenzen und Wissensbereiche:
Interdisziplinäre Kompetenzen:
Safety Engineers: Benötigen Grundverständnis von Cybersecurity-Bedrohungen
Security Engineers: Benötigen Verständnis für Safety-kritische Systeme
Kompetenzlücke: Derzeit eine der größten Herausforderungen der Branche
Unsicherheitsbewertung:
Methoden zur Quantifizierung epistemischer Unsicherheit
Umgang mit unvollständiger Information
Sensitivitätsanalysen für robuste Entscheidungen
Bayesianische Ansätze zur Aktualisierung von Annahmen
Ethische Abwägung:
Priorisierung bei Zielkonflikten (z.B. Privacy vs. Monitoring)
Verhältnismäßigkeit von Maßnahmen
Transparenz und Accountability
Berücksichtigung sozialer Auswirkungen
Integrierte Entscheidungsmodelle:
Multi-Kriterien-Entscheidungsanalyse (MCDA)
Game-theoretische Ansätze für Angreifer-Verteidiger-Szenarien
Kosten-Nutzen-Analysen für kombinierte Maßnahmen
Adaptive Systeme:
Selbstadaptierende Sicherheitsarchitekturen
Machine Learning für Anomalieerkennung
Kontinuierliches Monitoring und Feedback
Cyber-Physical Systems Security
Organisatorisches Wissen:
Governance-Strukturen für integriertes Risikomanagement
Change Management für Kulturwandel
Incident Response Koordination
Supply Chain Risk Management
Forschungsbedarf:
Formale Verifikation kombinierter Safety-Security-Properties
Quantifizierung von Defense-in-Depth Effektivität
Metriken für Security-Resilienz
Langzeitauswirkungen von Legacy-System-Integration
4. Fazit und Ausblick
Die Integration von Safety und Security im Eisenbahnwesen ist eine komplexe, aber notwendige Entwicklung. Die aktuellen Standards EN 50716, IEC 62443 und CLC/TS 50701 bieten einen soliden Rahmen, jedoch bestehen noch erhebliche Herausforderungen:
Zentrale Erkenntnisse:
Defense-in-Depth ist das verbindende Prinzip zwischen Safety und Security
Keine direkte Kopplung zwischen SIL und SL, aber gemeinsame Architekturansätze
Quantitative Methoden für Safety, qualitative/semi-quantitative für Security
EN 50129 spielt eine Schlüsselrolle als Brücke zwischen beiden Domänen
Kritische Erfolgsfaktoren:
Aufbau interdisziplinärer Kompetenzen
Systematische Adressierung von Legacy-Systemen
Kontinuierliche Aktualisierung von Bedrohungsmodellen
Entwicklung harmonisierter Bewertungsansätze
Die Zukunft liegt in der Entwicklung adaptiver, resilienter Systeme, die Safety und Security nicht als separate Disziplinen, sondern als integrierte Aspekte eines ganzheitlichen Risikomanagements verstehen.
Referenzen