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.

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.

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.

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

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

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

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

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.

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

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

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