| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| content:luftfahrt [2026/07/14 16:27] – [4. Wie werden Risikoanalysen durchgeführt?] approve | content:luftfahrt [2026/08/19 16:42] (aktuell) – [8. Was sind methodische Unterschiede und Gemeinsamkeiten in verschiedenen Domänen?] wollweber |
|---|
| ====== Safety und Security in der Luftsicherheit ====== | ====== Safety und Security in der Flugsicherheit / Flugzeugsicherheit====== |
| |
| ===== Kernnormen/-richtlinien für den Beitrag ===== | ===== Kernnormen/-richtlinien für den Beitrag ===== |
| Die Safety-Risikologik folgt einem hierarchischen Entwicklungs- und Nachweisprinzip: Von der Luftfahrzeugebene werden Funktionen, Failure Conditions und Sicherheitsziele auf System-, Subsystem- und Item-Ebene heruntergebrochen. Umgekehrt wird in der Nachweisführung gezeigt, dass die implementierten Systeme die abgeleiteten Anforderungen erfüllen. Diese Kopplung zwischen Entwicklungsprozess, Safety Assessment und Verifikation kann anschaulich dargestellt werden, insbesondere über die Sequenz AFHA → PASA → SFHA → PSSA → SSA → ASA. | Die Safety-Risikologik folgt einem hierarchischen Entwicklungs- und Nachweisprinzip: Von der Luftfahrzeugebene werden Funktionen, Failure Conditions und Sicherheitsziele auf System-, Subsystem- und Item-Ebene heruntergebrochen. Umgekehrt wird in der Nachweisführung gezeigt, dass die implementierten Systeme die abgeleiteten Anforderungen erfüllen. Diese Kopplung zwischen Entwicklungsprozess, Safety Assessment und Verifikation kann anschaulich dargestellt werden, insbesondere über die Sequenz AFHA → PASA → SFHA → PSSA → SSA → ASA. |
| |
| {{:content:v-modell_entwicklung-und-verifikation.svg?800x263}} | Weiterführende Darstellung: Der Zusammenhang zwischen dem Entwicklungsprozess und dem Safety-Assessment-Prozess ist in EUROCAE ED-79B, Figure 4-2, Interaction between Safety Assessment and Development Processes, dargestellt. |
| | |
| Abbildung (ED-79B, Figure 4-2: Interaction between Safety Assessment and development processes.) Annotation (Safety Assessment und Entwicklugsprozess) | |
| |
| Der Safety-Prozess ist einer der wichtigsten Bestandteile des Entwicklungsprozesses (siehe Abbildung) | Der Safety-Prozess ist einer der wichtigsten Bestandteile des Entwicklungsprozesses (siehe Abbildung) |
| Auf der Security-Seite erfolgt die Risikoanalyse ebenfalls prozessgeführt, aber anders als in der klassischen Safety. Der Airworthiness Security Process nach ED-202B ergänzt den Aircraft Development and Certification Process um Security-Aktivitäten. ED-202B unterscheidet insbesondere Security Risk Assessment Activities, Security Development Activities und Compliance-Aktivitäten. Der Security-Prozess soll mit Safety Assessment und Entwicklung interagieren; alternativ kann ein dokumentierter blended process genutzt werden. | Auf der Security-Seite erfolgt die Risikoanalyse ebenfalls prozessgeführt, aber anders als in der klassischen Safety. Der Airworthiness Security Process nach ED-202B ergänzt den Aircraft Development and Certification Process um Security-Aktivitäten. ED-202B unterscheidet insbesondere Security Risk Assessment Activities, Security Development Activities und Compliance-Aktivitäten. Der Security-Prozess soll mit Safety Assessment und Entwicklung interagieren; alternativ kann ein dokumentierter blended process genutzt werden. |
| |
| {{ :content:security-risk-assessment.svg |}} | Weiterführende Darstellung: Der Prozess der Security-Risikobewertung ist in EUROCAE ED-203A, Figure 3-2, Security Risk Assessment Process, dargestellt. |
| Abbildung: ED-203A: Security Risk Assessment Process. Annotation Security Risk Assessment (Quelle) | |
| |
| Die konkrete Security-Methodik wird in ED-203A ausgeführt. Sie umfasst im Kern: | Die konkrete Security-Methodik wird in ED-203A ausgeführt. Sie umfasst im Kern: |
| In der Disziplin Flugsicherheit / Flugzeugsicherheit kommen sowohl auf der Safety- als auch auf der Security-Seite gestufte Bewertungs- und Nachweismetriken zum Einsatz. Charakteristisch ist, dass diese Metriken nicht identisch sind, aber im Bereich der Airworthiness Security vergleichsweise eng aufeinander bezogen werden. | In der Disziplin Flugsicherheit / Flugzeugsicherheit kommen sowohl auf der Safety- als auch auf der Security-Seite gestufte Bewertungs- und Nachweismetriken zum Einsatz. Charakteristisch ist, dass diese Metriken nicht identisch sind, aber im Bereich der Airworthiness Security vergleichsweise eng aufeinander bezogen werden. |
| |
| Auf der Safety-Seite sind die zentralen Metriken die Klassifikation von Failure Conditions nach Schweregrad sowie die daraus abgeleiteten qualitativen und quantitativen Safety Objectives. In der klassischen CS/FAR-25.1309-Logik werden Failure Conditions typischerweise in Kategorien wie Catastrophic, Hazardous, Major, Minor und No Safety Effect eingeordnet. | Auf der Safety-Seite sind die zentralen Metriken die Klassifikation von Failure Conditions nach Schweregrad sowie die daraus abgeleiteten qualitativen und quantitativen Safety Objectives. In der klassischen CS/FAR-25.1309-Logik werden Failure Conditions <del>typischerweise</del> in __die__ Kategorien <del>wie</del> Catastrophic, Hazardous, Major, Minor und No Safety Effect eingeordnet. |
| |
| Eine zweite zentrale Safety-Metrik ist der Development Assurance Level. Dabei wird unterschieden zwischen FDAL für Funktionen und IDAL für Items, also insbesondere Software- und Hardware-Elemente. FDAL/IDAL beschreiben nicht unmittelbar eine Ausfallwahrscheinlichkeit, sondern die notwendige Strenge des Entwicklungs- und Nachweisprozesses, um Entwicklungsfehler zu vermeiden oder hinreichend zu beherrschen. | Eine zweite zentrale Safety-Metrik ist der Development Assurance Level. Dabei wird unterschieden zwischen FDAL für Funktionen und IDAL für Items, also insbesondere Software- und Hardware-Elemente. FDAL/IDAL beschreiben nicht unmittelbar eine Ausfallwahrscheinlichkeit, sondern die notwendige Strenge des Entwicklungs- und Nachweisprozesses, um Entwicklungsfehler zu vermeiden oder hinreichend zu beherrschen. |
| === Unterschiede zwischen Safety und Security === | === Unterschiede zwischen Safety und Security === |
| |
| Der wichtigste methodische Unterschied betrifft die Art der Ursachen. Safety betrachtet primär unbeabsichtigte Fehlfunktionen, technische Ausfälle, Entwicklungsfehler, Bedien- oder Wartungsfehler sowie externe Ereignisse. Security betrachtet absichtliche, adaptive und strategische Handlungen durch Angreifer. Safety-Analysen beruhen häufig auf relativ stabilen Annahmen über technische Ausfälle, Umgebungsbedingungen und Betriebsprofile. Security-Analysen müssen mit neuen Schwachstellen, veränderten Angreifermethoden und dynamischen Angriffspfaden umgehen. Deshalb haben Security Event Management, Vulnerability Management und Continued Security Effectiveness besondere Bedeutung. | Der wichtigste methodische Unterschied betrifft die Art der Ursachen. Safety betrachtet <del>primär</del> unbeabsichtigte Fehlfunktionen, technische Ausfälle, Entwicklungsfehler, Bedien- oder Wartungsfehler sowie externe Ereignisse. Security betrachtet <del>absichtliche, adaptive und strategische</del> __vorsätzliche__ Handlungen durch Angreifer. Safety-Analysen beruhen häufig auf relativ stabilen Annahmen über technische Ausfälle, Umgebungsbedingungen und Betriebsprofile. Security-Analysen müssen mit neuen Schwachstellen, veränderten Angreifermethoden und dynamischen Angriffspfaden umgehen. Deshalb haben Security Event Management, Vulnerability Management und Continued Security Effectiveness besondere Bedeutung. |
| |
| Ein zweiter Unterschied betrifft die Quantifizierbarkeit. In Safety können bestimmte Risiken über Fehlerraten, Ausfallwahrscheinlichkeiten, Risk Times, Redundanzen, latente Fehler und Architekturmodelle quantitativ bewertet werden. In Security ist eine vergleichbare probabilistische Bewertung nicht möglich, weil Angriffserfolg von Motivation, Fähigkeit, Gelegenheit, Wissen, Werkzeugen und adaptivem Verhalten abhängt. | Ein zweiter Unterschied betrifft die Quantifizierbarkeit. In Safety können bestimmte Risiken über Fehlerraten, Ausfallwahrscheinlichkeiten, Risk Times, Redundanzen, latente Fehler und Architekturmodelle quantitativ bewertet werden. In Security ist eine vergleichbare probabilistische Bewertung nicht möglich, weil Angriffserfolg von Motivation, Fähigkeit, Gelegenheit, Wissen, Werkzeugen und adaptivem Verhalten abhängt. |