Safety (Security) Risiko im Eisenbahnbereich
Relevante Normen und Richtlinien (unvollständig)
Tabelle 1: Relevante Normen und Richtlinien für den Bereich „Safety“
Kennung | Jahr | Titel | Anmerkung |
---|---|---|---|
DIN EN 50126 | 2018 | Bahnanwendungen – Spezifikation und Nachweis von Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit und Sicherheit (RAMS) | - |
EN 50128 | 2012 | Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme - Software für Eisenbahnsteuerungs- und Überwachungssysteme | - |
EN 50657 | 2017 | Anwendungen für Schienenfahrzeuge - Software auf Schienenfahrzeugen | - |
Tabelle 2: Relevante Normen und Richtlinien für den Bereich „Security“
1 Risiko: Definition und Herausforderungen
Risiko wird in der Regel in Form von Sicherheitsanforderungsstufen (Safety Integrity Level – SIL) beschrieben. Je nach System werden unterschiedliche Metriken genutzt: die Wahrscheinlichkeit eines Fehlers bei Bedarf (probability of failure on demand – PFD) oder die Wahrscheinlichkeit eines Fehlers pro Betriebsstunde (Probability of Failure per Hour – PFH) bzw. deren Kehrfunktion, die mittlere Zeit zwischen zwei Fehlern (Mean Time Between Failures – MTBF). Systeme, die konstant laufen, nutzen dabei die letztere Metrik, während Systeme, die diskrete Funktionen umsetzen, auf die erstere Metrik setzen.
Für sicherheitsrelevante Systeme sind in der Regel die SIL Level 3 für den Rangierbetrieb $ \text{PFD} = 10^{-3} - 10^{-4} \quad / \quad \text{MTBF} = 1.000 - 10.000 \text{a} $
und SIL Level 4 für das reguläre Schienennetz
$ \text{PFD} = 10^{-4} - 10^{-5} \quad / \quad \text{MTBF} = 10.000 - 100.000 \text{a} $ .
Beim Entwicklungsprozess wird grundsätzlich auf ein V-Modell gesetzt. Für die unterschiedlichen Verfahren in der Softwareentwicklung gibt die EN 50128 unterschiedliche Vorgaben und/oder Empfehlungen (ein Abweichen von diesen muss begründet werden). Zu diesen gehören:
- Top-Down-Entwurfsverfahren
- Modularität
- Verifikation jeder Phase des Entwicklungslebenszyklus
- Verifizierte SW-Komponenten und SW-Komponenten-Bibliotheken
- Klare Dokumentation und Rückverfolgbarkeit
- Auditierbare Dokumente
- Validierung
- Begutachtung
- Konfigurationsmanagement und Änderungsmanagement
- Geeignete Betrachtung von Fragen der Organisation und der Kompetenz des Personals
Security ist im Bahnkontext vergleichsweise neu bzw. wurde bisher mit dem Ansatz von dedizierten Punkt-zu-Punkt-Verbindungen totgeschlagen. Dies ändert sich zunehmend mit der Einführung von (geteilten) IT-Netzwerken. Nach EN TS 50701 wird dabei ein kontinuierliches Cybersecuritymanagement angestrebt, das sich aus Risikoanalyse, der Begegnung des Risikos mit einem Cybersecurymanagementsystem und dessen Überwachung und kontunierunliche Verbesserung. Generell wird nach dem NIST-Modell gearbeitet.
Ein Kerndilemma ist die unterschiedliche Lebensdauer der Komponenten. Security-Komponenten sind kurzlebiger (Updates nach der Entdeckung von Sicherheitslücken müssen oft tagsüber erfolgen) und müssen regelmäßiger aktualisiert werden. Bisher wurden Systeme als ganzes zugelassen. Dies ist mit regelmäßigen Security-Updates nicht mehr möglich. Die Lösung dieses Problems steckt noch in Ihren Kinderschuhen. Verlässliche Anforderungen an solch einen Prozess, die bei Erfüllung eine Zulassung durch das Eisenbahn-Bundesamt garantieren, fehlen.
Unsicherheiten werden in der Regel versucht, zu quantifizieren. Kann ein Eintreten mit SIL4 ausgeschlossen werden, werden bestimmte Szenarien nicht weiter betrachtet.
2 Durchführung von Risikoanalysen
Risikoanalysen werden in der Regel quantitativ, mithilfe von Fehlerbäumen durchgeführt. Dabei wird die Unabhängigkeit der Ereignisse angenommen.So ergibt sich beispielsweise, dass um SIL 4 sicherzustellen, wenn eine bestimmte Komponente nur nach SIL 3 gesichert ist, dass diese um den Faktor 10 zusätzlich gesichert werden muss. Menschliches Handeln wird dabei oft mit SIL 0 angenommen.
Es werden die Metriken wie oben eingeführt genutzt. Wechselwirkungen zwischen Safety und Security werden in der Regel nicht betrachtet. Sind zum Funktionieren einer Komponente zusätzliche Securitykomponenten notwendig, wird deren Ausfallrisiko aber beispielsweise eingerechnet.
3 Domänenübergreifende Zusammenführung
Wird in Folge der Fachausschussdiskussionen beantwortet.
Werden in den angrenzenden Disziplinen ähnliche oder andere Probleme bearbeitet? Was sind methodische Unterschiede und Gemeinsamkeiten in verschiedenen Domänen? Wie könnte ein gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security Modellen aussehen? Welches neue Wissen ist erforderlich für eine Synthese der Domänen?
Quellen
Hier bitte relevante Quellen angeben, auf die bei der Beantwortung der Leitfragen referenziert wird. Gut geeignet sind sicher auch Quellen, die schon eine breitere Übersicht über die Thematik und Beispiele liefern