Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| content:railway [2026/06/10 10:16] – sprenger | content:railway [2026/06/11 10:56] (aktuell) – sprenger | ||
|---|---|---|---|
| Zeile 25: | Zeile 25: | ||
| Safety (Funktionale Sicherheit): | 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ß | + | * **Modell**: Risiko = Eintrittswahrscheinlichkeit × Schadensausmaß |
| - | * **Ziel**: Freiheit von inakzeptablem Risiko für menschliche Gesundheit und Umwelt | + | * **Ziel**: Freiheit von inakzeptablem Risiko für menschliche Gesundheit und Umwelt |
| Security (IT-Sicherheit/ | Security (IT-Sicherheit/ | ||
| - | * **Definition nach CLC/TS 50701**: Erwarteter Verlust als Wahrscheinlichkeit, | + | |
| - | * **Modell**: Risiko = Bedrohung × Schwachstelle × Auswirkung | + | * **Modell**: Risiko = Bedrohung × Schwachstelle × Auswirkung |
| - | * **Besonderheit**: | + | * **Besonderheit**: |
| ===1.1.2 Etablierte Modelle und Verfahren=== | ===1.1.2 Etablierte Modelle und Verfahren=== | ||
| Zeile 39: | Zeile 39: | ||
| Safety-Verfahren: | Safety-Verfahren: | ||
| - | * **Fault Tree Analysis (FTA)**: Top-Down-Analyse zur Identifikation von Fehlerursachen | + | |
| - | * **FMEA/ | + | * **FMEA/ |
| - | * **Bow-Tie-Modell**: | + | * **Bow-Tie-Modell**: |
| - | * **HAZOP**: Hazard and Operability Study für systematische Gefahrenanalyse | + | * **HAZOP**: Hazard and Operability Study für systematische Gefahrenanalyse |
| Security-Verfahren: | Security-Verfahren: | ||
| - | * **Bedrohungsmodellierung**: | + | |
| - | * **Attack Trees**: Hierarchische Darstellung möglicher Angriffspfade | + | * **Attack Trees**: Hierarchische Darstellung möglicher Angriffspfade |
| - | * **Schwachstellenanalyse**: | + | * **Schwachstellenanalyse**: |
| - | * **Penetrationstests**: | + | * **Penetrationstests**: |
| ====1.2 Charakteristische Probleme und Dilemmata==== | ====1.2 Charakteristische Probleme und Dilemmata==== | ||
| 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. | 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] | * 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: | Im Eisenbahnwesen treten spezifische Zielkonflikte zwischen Safety und Security auf: | ||
| - | Verfügbarkeit vs. Sicherheit: | + | **Verfügbarkeit vs. Sicherheit**: |
| * **Safety-Perspektive**: | * **Safety-Perspektive**: | ||
| Zeile 71: | Zeile 71: | ||
| * **Dilemma**: | * **Dilemma**: | ||
| - | Offenheit vs. Zugriffsbeschränkung: | + | **Offenheit vs. Zugriffsbeschränkung**: |
| * **Safety**: Fordert transparente, | * **Safety**: Fordert transparente, | ||
| Zeile 77: | Zeile 77: | ||
| * **Lösung**: | * **Lösung**: | ||
| - | Fehlertoleranz vs. Fehlerausnutzung: | + | **Fehlertoleranz vs. Fehlerausnutzung**: |
| * **Safety**: Redundanzen und Fail-Safe-Mechanismen gegen zufällige Fehler | * **Safety**: Redundanzen und Fail-Safe-Mechanismen gegen zufällige Fehler | ||
| Zeile 83: | Zeile 83: | ||
| * **Prinzip**: | * **Prinzip**: | ||
| - | Legacy-Systeme: | + | **Legacy-Systeme**: |
| * Bestandssysteme ohne integrierte Cybersecurity-Maßnahmen | * Bestandssysteme ohne integrierte Cybersecurity-Maßnahmen | ||
| Zeile 93: | Zeile 93: | ||
| Die epistemische Unsicherheit wird in beiden Domänen unterschiedlich adressiert: | Die epistemische Unsicherheit wird in beiden Domänen unterschiedlich adressiert: | ||
| - | **Konservative Ansätze bei Safety**: | + | **Konservative Ansätze bei Safety**: |
| + | |||
| * Worst-Case-Annahmen bei fehlenden Daten | * Worst-Case-Annahmen bei fehlenden Daten | ||
| * Sicherheitsfaktoren in Berechnungen | * Sicherheitsfaktoren in Berechnungen | ||
| Zeile 99: | Zeile 100: | ||
| **Qualitative Bewertung bei Security**: | **Qualitative Bewertung bei Security**: | ||
| + | |||
| * Da quantitative Risikobewertung nicht möglich ist, werden semi-quantitative Verfahren eingesetzt | * Da quantitative Risikobewertung nicht möglich ist, werden semi-quantitative Verfahren eingesetzt | ||
| * Likelihood-Faktoren: | * Likelihood-Faktoren: | ||
| * Verwendung von Ordinalskalen (niedrig, mittel, hoch, sehr hoch) | * Verwendung von Ordinalskalen (niedrig, mittel, hoch, sehr hoch) | ||
| - | **Expertenabschätzungen**: | + | **Expertenabschätzungen**: |
| * Bei unbekannten Schwachstellen in neuen Systemen: Annahmen basierend auf vergleichbaren Systemen | * Bei unbekannten Schwachstellen in neuen Systemen: Annahmen basierend auf vergleichbaren Systemen | ||
| * Regelmäßige Aktualisierung der Risikobeurteilung bei neuen Erkenntnissen | * Regelmäßige Aktualisierung der Risikobeurteilung bei neuen Erkenntnissen | ||
| * Dokumentation aller Annahmen im Bedrohungsprotokoll | * Dokumentation aller Annahmen im Bedrohungsprotokoll | ||
| - | **Sensitivitätsanalysen**: | + | **Sensitivitätsanalysen**: |
| * Variation von Parametern zur Abschätzung der Auswirkungen | * Variation von Parametern zur Abschätzung der Auswirkungen | ||
| * Identifikation kritischer Schwellenwerte | * Identifikation kritischer Schwellenwerte | ||
| Zeile 118: | Zeile 122: | ||
| Für die Risikoanalyse im Bereich Security werden diverse Varianten der in der IEC 62443 beschriebenen Methodik 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, | ||
| + | * **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**: | ||
| + | * **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)**: | ||
| + | * **SL-A (Achieved)**: | ||
| + | |||
| + | **SL-Vektor**: | ||
| + | |||
| + | * Sieben grundlegende Anforderungsklassen (FR 1-7): IAC, UC, SI, DC, RDF, TRE, RA | ||
| + | * Beispiel-Vektor: | ||
| + | * Priorität im Bahnwesen: Verfügbarkeit und Integrität vor Vertraulichkeit | ||
| + | |||
| + | **Weitere Metriken**: | ||
| + | |||
| + | * **CVSS**: Common Vulnerability Scoring System für Schwachstellenbewertung | ||
| + | * **Risikoschweregrade**: | ||
| + | * **Auswirkungskategorien**: | ||
| + | |||
| + | ==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**: | ||
| + | * **Security-Analogie**: | ||
| + | * **Schichten**: | ||
| + | |||
| + | **Behandlung in der Risikoanalyse**: | ||
| + | |||
| + | * Security als Umweltbedingung für Safety betrachten | ||
| + | * Cybersecurity-Angriffe können Safety-Funktionen kompromittieren | ||
| + | * Integrierte Bedrohungsszenarien: | ||
| + | |||
| + | **Methodische Integration**: | ||
| + | |||
| + | * **Zonierungskonzept**: | ||
| + | * **Boundary Protection**: | ||
| + | * **SecRACs**: | ||
| + | |||
| + | **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, | ||
| + | * **Mindestanforderung**: | ||
| + | |||
| + | **Priorisierung von Maßnahmen**: | ||
| + | |||
| + | * Bei Konflikten: Verfügbarkeit wesentlicher Funktionen hat Vorrang | ||
| + | * Im Fehlerfall geschlossen: | ||
| + | * 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, | ||
| + | |||
| + | ====3.1 Vergleich mit angrenzenden Disziplinen==== | ||
| + | |||
| + | Das Eisenbahnwesen teilt Herausforderungen mit anderen kritischen Infrastrukturen: | ||
| + | |||
| + | **Gemeinsame Herausforderungen**: | ||
| + | |||
| + | * **Legacy-Systeme**: | ||
| + | * **Lange Lebenszyklen**: | ||
| + | * **Verfügbarkeitsanforderungen**: | ||
| + | * **Regulatorische Komplexität**: | ||
| + | |||
| + | **Unterschiede zu anderen Domänen**: | ||
| + | |||
| + | * **IT/ | ||
| + | * **Automotive**: | ||
| + | * **Luftfahrt**: | ||
| + | * **Energie**: | ||
| + | |||
| + | ===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: | ||
| + | * Qualitative/ | ||
| + | * Bedrohungsorientierter Ansatz | ||
| + | * Kontinuierliche Anpassung an neue Bedrohungen | ||
| + | |||
| + | **Gemeinsame Elemente**: | ||
| + | |||
| + | * Risikomatrix-Ansätze | ||
| + | * Integritätslevel-Konzepte (SIL/ | ||
| + | * Defense-in-Depth Strategie | ||
| + | * Lifecycle-Management | ||
| + | * Nachweis-basierte Argumentation (Safety Case/ | ||
| + | |||
| + | **Übertragbare Ansätze**: | ||
| + | |||
| + | * **Bow-Tie-Modell**: | ||
| + | * **FMEA**: Erweitert zu FMECA (Criticality Analysis) für Security | ||
| + | * **Zonierung**: | ||
| + | |||
| + | ==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**: | ||
| + | * **Schweregrad**: | ||
| + | * **Risikoschweregrad**: | ||
| + | |||
| + | **Gemeinsame Indikatoren**: | ||
| + | |||
| + | * **Verfügbarkeit**: | ||
| + | * **Integrität**: | ||
| + | * **Auswirkung**: | ||
| + | |||
| + | **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/ | ||
| + | * 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**: | ||
| + | * **Security Engineers**: | ||
| + | * **Kompetenzlücke**: | ||
| + | |||
| + | **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/ | ||
| + | * 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, | ||
| + | |||
| + | **Referenzen** | ||
| + | |||