Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- content:railway [2026/06/10 12:27] – sprenger
+++ content:railway [2026/06/11 10:56] (aktuell) – sprenger
@@ Zeile 55: / Zeile 55: @@
 Zwischen safety und security existieren bedeutende Überschneidungen [12, 18] in ihren Zielen und Methodiken, andererseits gibt es auch grundsätzliche Zielkonflikte.
-Gemeinsamkeiten:
+**Gemeinsamkeiten**:
   * Beide schützen Menschen, Vermögenswerte und Betrieb vor Schäden [18]
@@ Zeile 65: / Zeile 65: @@
 Im Eisenbahnwesen treten spezifische Zielkonflikte zwischen Safety und Security auf:
-Verfügbarkeit vs. Sicherheit:
+**Verfügbarkeit vs. Sicherheit**:
   * **Safety-Perspektive**: Ausfall in einen sicheren Zustand (z.B. Notbremsung) ist akzeptabel
@@ Zeile 71: / Zeile 71: @@
   * **Dilemma**: Sicherheitsrelevante Systeme müssen sowohl in sicheren Zustand gehen als auch verfügbar bleiben
-Offenheit vs. Zugriffsbeschränkung:
+**Offenheit vs. Zugriffsbeschränkung**:
   * **Safety**: Fordert transparente, bedienbare Systeme für Wartung und Notfälle
@@ Zeile 77: / Zeile 77: @@
   * **Lösung**: Defense-in-Depth mit gestaffelten Schutzmaßnahmen bei gleichzeitiger Bedienbarkeit
-Fehlertoleranz vs. Fehlerausnutzung:
+**Fehlertoleranz vs. Fehlerausnutzung**:
   * **Safety**: Redundanzen und Fail-Safe-Mechanismen gegen zufällige Fehler
@@ Zeile 83: / Zeile 83: @@
   * **Prinzip**: Diversität in Redundanzen zur Vermeidung gemeinsamer Schwachstellen
-Legacy-Systeme:
+**Legacy-Systeme**:
   * Bestandssysteme ohne integrierte Cybersecurity-Maßnahmen
@@ Zeile 93: / Zeile 93: @@
 Die epistemische Unsicherheit wird in beiden Domänen unterschiedlich adressiert:
 **Konservative Ansätze bei Safety**:
   * Worst-Case-Annahmen bei fehlenden Daten
   * Sicherheitsfaktoren in Berechnungen
@@ Zeile 99: / Zeile 100: @@
 **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
@@ Zeile 122: / Zeile 126: @@
 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)
@@ Zeile 133: / Zeile 139: @@
   * 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
@@ Zeile 148: / Zeile 156: @@
 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
@@ Zeile 159: / Zeile 169: @@
   * **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
@@ Zeile 173: / Zeile 185: @@
 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**:
+  * **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
+  * **Zonierungskonzept**: Gemeinsame Architektur für Safety- und Security-Anforderungen
-**SecRACs**: Security-related Application Conditions analog zu Safety-RACs
+  * **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.
-**Keine direkte Kopplung SIL-SL**:
+**Referenzen**
-  * 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