| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| content:luftfahrt [2024/12/04 01:42] – approve | content:luftfahrt [2026/07/16 00:32] (aktuell) – [4. Wie werden Risikoanalysen durchgeführt?] approve |
|---|
| <h1>Safety und Security in der Luftsicherheit</h1> | ====== Safety und Security in der Flugsicherheit / Flugzeugsicherheit====== |
| |
| <div class="level1"> </div> | ===== Kernnormen/-richtlinien für den Beitrag ===== |
| |
| <h2>Relevante Normen und Richtlinien (unvollständig)</h2> | ^Bezeichnung^Vollständiger Titel^Einordnung für den Wiki-Beitrag| |
| | |EUROCAE ED-79B / SAE ARP4754B|Guidelines for Development of Civil Aircraft and Systems|Zentrale Safety-/Development-Assurance-Richtlinie für die Entwicklung ziviler Luftfahrzeuge und Systeme. Sie beschreibt insbesondere den Entwicklungsprozess, Requirements Engineering, Validation und Verification, Configuration Management, Process Assurance sowie die Schnittstellen zur Safety Assessment.| |
| | |EUROCAE ED-135 / SAE ARP4761A|Guidelines for Conducting the Safety Assessment Process on Civil Aircraft, Systems, and Equipment|Zentrale Richtlinie für den Safety-Assessment-Prozess. Sie behandelt insbesondere AFHA, PASA, SFHA, PSSA, SSA und ASA sowie Methoden wie FTA, FMEA/FMES, Markov Analysis, Zonal Safety Analysis (ZSA), Particular Risk Analysis (PRA), Common Mode Analysis (CMA) und Model-Based Safety Assessment (MBSA).| |
| | |EUROCAE ED-201A / RTCA DO-391|Aeronautical Information System Security Framework Guidance|Übergreifendes Framework für Aeronautical Information System Security. Behandelt Stakeholder, Lebenszyklus, Risk Management, Assurance, Supply Chain, Information Sharing sowie ISMS-bezogene Aspekte.| |
| | |EUROCAE ED-202B / RTCA DO-326B|Airworthiness Security Process Specification|Zentrale Prozessspezifikation für Airworthiness Security. Beschreibt den Umgang mit Intentional Unauthorized Electronic Interaction (IUEI) im Entwicklungs- und Zertifizierungskontext.| |
| | |EUROCAE ED-203A / RTCA DO-356A|Airworthiness Security Methods and Considerations|Methodische Ergänzung zu ED-202B. Behandelt insbesondere Security Scope, Threat Conditions, Threat Scenarios, Security Measures, Level of Threat, Security Assurance und Security Architecture.| |
| | |EUROCAE ED-204A / RTCA DO-355A|Information Security Guidance for Continuing Airworthiness|Richtlinie für Information Security in Betrieb, Wartung und Continuing Airworthiness. Behandelt u. a. Airborne Software, Aircraft Components, Network Access Points, Ground Support Equipment, Operator-Prozesse, Rollen und Training.| |
| | |EUROCAE ED-206 / RTCA DO-392|Guidance on Security Event Management|Richtlinie für Security Event Management. Behandelt Organisation, Detektion, Analyse, Response, Recovery und Reporting von Security Events mit tatsächlichen oder potenziellen Aviation-Safety-Konsequenzen.| |
| |
| <div class="level2">\\ | ===== Ergänzende Referenzen ===== |
| <p>Nachfolgend werden für die Luftfahrtindustrie (Infrastruktur Flughafen exkludiert) wichtige und relevante Normen und Richtlinien für die Bereiche Safety und Security aufgeführt. Die Auflistungen erheben hierbei keinen Anspruch auf Vollständigkeit.</p> | |
| |
| <p><b>Tabelle 1: Relevante Normen und Richtlinien für Safety und Security</b></p> | ^Bezeichnung^Vollständiger Titel^Einordnung für den Wiki-Beitrag| |
| | |EUROCAE ED-205A / RTCA DO-393|Process Standard for Security Certification and Declaration of ATM/ANS Ground Systems|Ergänzende Richtlinie für ATM/ANS Ground Systems. Für den Beitrag insbesondere relevant als Schnittstelle zu Boden-, Kommunikations- und Navigationsdiensten.| |
| | |RTCA DO-178C / EUROCAE ED-12C|Software Considerations in Airborne Systems and Equipment Certification|Relevante ergänzende Richtlinie für sicherheitsrelevante Softwareentwicklung. Wird in ED-79B als Referenz für Softwareentwicklung genannt.| |
| | |RTCA DO-254 / EUROCAE ED-80|Design Assurance Guidance for Airborne Electronic Hardware|Relevante ergänzende Richtlinie für airborne electronic hardware. Wird in ED-79B als zentrale Hardware-Assurance-Quelle genannt.| |
| | |EUROCAE ED-124 / RTCA DO-297|Integrated Modular Avionics Development Guidance and Certification Considerations|Ergänzende Richtlinie für Integrated Modular Avionics (IMA). Relevant für komplexe, integrierte Avionikarchitekturen sowie deren Entwicklungs- und Zertifizierungskontext.| |
| | |EASA CS-25|Certification Specifications and Acceptable Means of Compliance for Large Aeroplanes|Zertifizierungsvorgaben für große Flugzeuge. Besonders CS 25.1309 ist für Safety Objectives, Failure Conditions sowie „safe flight and landing“ zentral. In CS 25.1319 wird Security gleichrangig mit Safety behandelt.| |
| | |EASA AMC 20-42|Airworthiness Information Security Risk Assessment|Relevanter EASA-Kontext für Airworthiness Security. ED-202B nennt AMC 20-42 im Zusammenhang mit Security Considerations unter CS-E 50, CS-P 230 und CS 25.1319.| |
| | |EASA Part 21 / GM21|Certification of Aircraft and Related Products, Parts and Appliances, and of Design and Production Organisations|Relevanter regulatorischer Rahmen für Design Approval, Type Certification, Changes und Continued Airworthiness. ED-79B verweist im Kontext der in-service safety assessment auf EASA Part 21 bzw. GM21.| |
| | |EU 2017/373|Requirements for Providers of Air Traffic Management/Air Navigation Services and Other Air Traffic Management Network Functions and Their Oversight|Relevanter regulatorischer Rahmen für ATM/ANS, insbesondere im Zusammenhang mit ED-205A für Ground Systems sowie Security Declaration und Certification.| |
| | |EASA Part-IS|Information Security Requirements for Aviation Organisations|Neuerer europäischer regulatorischer Rahmen für Information Security Management in Luftfahrtorganisationen. ED-205A und ED-206 stehen in engem Zusammenhang mit der Entwicklung bzw. Umsetzung entsprechender Anforderungen.| |
| | |CVSS|Common Vulnerability Scoring System|Ergänzende Security-Metrik für Vulnerability Management. ED-206 enthält aviation-spezifische Guidance zur Anwendung von CVSS-Metriken.| |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=184ba2c0b89601db982d78b809595c0f.png" title="184ba2c0b89601db982d78b809595c0f.png"><img alt="" class="media" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?media=184ba2c0b89601db982d78b809595c0f.png" /></a></p>\\ | ===== 1 Risiko: Definition und Herausforderungen ===== |
| </div> | |
| |
| <h2>1 Risiko: Definition und Herausforderungen</h2> | ==== 1. Wie werden Risiko, Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren? ==== |
| |
| <div class="level2">\\ | In der Disziplin Flugsicherheit / Flugzeugsicherheit ist Risiko eng an den Begriff der Lufttüchtigkeit und an die Sicherstellung von safe flight and landing gebunden. Auf der Safety-Seite wird Risiko primär über Failure Conditions beschrieben, also über Zustände, bei denen Fehlfunktionen von Luftfahrzeugfunktionen, Systemen oder Komponenten zu Auswirkungen auf Luftfahrzeug, Besatzung oder Passagiere führen können. Diese Failure Conditions werden nach ihrer Schwere klassifiziert und daraus werden Safety Objectives, Anforderungen an Systemarchitektur, Unabhängigkeit sowie Development Assurance abgeleitet. |
| <p>Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren? Welche Probleme und Dilemmata sind in Ihrer Disziplin charakteristisch? Wie werden unscharfe oder unsichere Risikobeiträge behandelt?</p>\\ | |
| </div> | |
| |
| <h2>2 Durchführung von Risikoanalysen</h2> | Die klassische Safety-Methodik der Luftfahrt ist stark prozessual und normativ strukturiert. ED-79B / SAE ARP4754B beschreibt den Entwicklungsprozess ziviler Luftfahrzeuge und Systeme einschließlich Requirements, Validation, Verification, Configuration Management und Process Assurance. ED-135 / SAE ARP4761A beschreibt den Safety Assessment Process mit AFHA, PASA, SFHA, PSSA, SSA und ASA sowie Methoden wie FTA, FMEA/FMES, Markov-Analyse, ZSA, PRA, CMA und MBSA. |
| |
| <div class="level2">\\ | Typische Safety-Verfahren sind: |
| <p>Wie werden Risikoanalysen in Ihrer Disziplin durchgeführt? (qualitativ, quantitativ, semi-quantitativ, nach Norm oder Richtlinie) Welche Metriken kommen hierbei zum Einsatz? Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Ihrer Disziplin in Erscheinung und wie werden diese behandelt? <span style="font-size:11pt">Die Risikoanalyse wird in der Luftfahrtentwicklung strukturiert vorgenommen. Es gibt zunächst den Security-Kontext, wo der Rahmen für die Risikoanalyse eines jeden Projekts gesetzt wird: Taxonomie, akzeptable Risiken, Security-Umgebung (wem vertraue ich?), Annahmen und Impact-Klassen. Dann werden Informationen aus der Design-Phase benötigt: Architekturelle und insbesondere funktionale Beschreibungen, was das Flugzeug und die inhärenten Sub-Systeme tun sollen und welche Schnittstellen es allgemein gibt. Abschließend werden Dokumente aus Entwicklungsaktivitäten herangezogen, bestehend aus technischen Spezifikationen (Schnittstellendefinition, funktionale Tests, Pentestberichte, weil Flugzeuge nach V-Modell entwickelt werden, etc.). Jedes einzelne Requirement muss grundsätzlich testbar sein. Das ist Voraussetzung für den Beginn der eigentlichen Arbeit. In der Flugzeugentwicklung wird gem. Requirement-based Engineering gearbeitet. Funktionen und Teilfunktionen eines Systems werden auf Unterfunktionen heruntergebrochen und in funktionale Anforderungen übersetzt. Das ist insofern wichtig, weil Security-Angriffe sich zu 100% auf Equipment (Hardware) beziehen. Deswegen macht es wenig Sinne, Konstrukte zu bauen, Daten in Transit zu manipulieren. Im Fokus liegen Angriffe auf Software, die auf einer aktiven Hardware läuft.</span></p> | |
| |
| <p><b><span style="color:#333333"><span style="font-size:10.5pt">Abbildung 1: Dekomposition eines Flugzeugs in Funktionen und funktionale Anforderungen</span></span> </b></p> | ^Verfahren^Bedeutung| |
| | |AFHA|Aircraft Functional Hazard Assessment| |
| | |PASA|Preliminary Aircraft Safety Assessment| |
| | |SFHA|System Functional Hazard Assessment| |
| | |PSSA|Preliminary System Safety Assessment| |
| | |SSA|System Safety Assessment| |
| | |ASA|Aircraft Safety Assessment| |
| | |FTA, FMEA/FMES, CMA, PRA, ZSA, Markov, MBSA|Ergänzende qualitative, semiquantitative und quantitative Analyseverfahren| |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=29b5ab52a25fb7d542578e839112ba1d.png" title="29b5ab52a25fb7d542578e839112ba1d.png"><img alt="" class="media" height="441" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=903&h=441&tok=be90c3&media=29b5ab52a25fb7d542578e839112ba1d.png" width="903" /></a> <span style="font-size:11pt">In Analogie zur Failure Condition (Safety) wird in der Security eine Threat Condition definiert.</span> Eine Threat Condition ist eine Konsequenz an einem funktionalen Asset. Die Konsequenz ist der Verlust der Security-Eigenschaften (CIA) und kann schon aus der Failure Hazards Analysis abgeleitet werden. Die Konsequenzen werden detailliert herausgearbeitet und in Stufen klassifiziert. Dieser Arbeitsschritt nimmt etwa 50% der Arbeitszeit für die Durchführung einer Risikoanalyse für das Gesamtsystem ein.</p> | 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. |
| |
| <p><b><span style="color:#333333"><span style="font-size:10.5pt">Abbildung 2: Beispiele für Impact-Klassifikationen aus der Safety (nach EASA CS25 Kap. 13.09) und der Security (nach Betriebsstörungen gem. ED-203A)</span></span> </b></p> | 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. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=ed3bc123ab9cd36d73f35f57545d8b40.png" title="ed3bc123ab9cd36d73f35f57545d8b40.png"><img alt="" class="media" height="438" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=935&h=438&tok=8bad4d&media=ed3bc123ab9cd36d73f35f57545d8b40.png" width="935" /></a> <span style="font-size:11pt">Wenn bekannt ist, was zu erhaltende Funktionen (= Assets) sind, dann wird geschaut, wo gibt es Einstiegspunkte zum System bzw. zum Flugzeug. Es geht um Dateneinsprungpunkte. Durch die Architekturbeschreibung werden dann Angriffspfade gesucht, je nach Detailgrad kurz oder auf Systemlevel aufdetailliert. Nach allen möglichen Pfaden von externen Schnittstellen zu allen relevanten Assets werden die Szenarien beschrieben, bestehend aus dem Angriffsvektor, der ausbeutbaren Schwachstellen und dem Ziel (im Zweifelsfall immer Hardware). Ein Threat Vector kann sich aus einer Sequenz mehrerer Threat Vectors zusammensetzen, stets nach demselben Prinzip: Es gibt es Asset und i.d.R. mehrere Wege, die ein Angreifer dorthin nehmen kann. Damit wird die Infrastruktur beschrieben, auf die geschaut wird.</span> <span style="font-size:11pt">Der nächste Schritt ist, zu analysieren, welche Maßnahmen einen Angriff verhindern oder dem entgegenstehen. Es ist einerlei, wie viele Angriffe es gibt, es darf nur keiner erfolgreich sein. Alles, was dem Angriff entgegensteht, ist eine Maßnahme. Diese wird einer Stärke zugeordnet, die nicht absolut ist, sondern sich im Austausch mit den Entwicklerkollegen gibt. Maßnahmen können technischer Art sein, auch Safety-Funktionen, ebenso Vorschriften, Vorgehensweisen für die Crew, usw. Diese werden dann auf einer Likelihood-Skala 1 bis 30 einsortiert. Es wird die Likelihood reduziert von 30 nach 1 (Hinweis: In der ED-203A läuft das andersherum, es beginnt bei 0 und endet bei 30 und die Bezeichnungen sind anders, meinen aber dasselbe, wie hier dargelegt). Was keinen Effekt hat, also nicht wirksam ist, ist keine Maßnahme.</span></p> | Der Safety-Prozess ist einer der wichtigsten Bestandteile des Entwicklungsprozesses (siehe Abbildung) |
| |
| <p><b><span style="color:#333333"><span style="font-size:10.5pt">Tabelle 2: Gegenüberstellung von ED-203A und dem Bewertungsschema bei Airbus</span></span> </b></p> | Auf der Security-Seite wird die Disziplin nicht allgemein als IT-Sicherheit verstanden, sondern spezifisch als Aeronautical Information System Security bzw. Airworthiness Security. Ausgangspunkt ist die zunehmende Möglichkeit einer Intentional Unauthorized Electronic Interaction (IUEI) mit Luftfahrzeug- und luftfahrtbezogenen Informationssystemen. ED-201A / DO-391 beschreibt hierfür einen übergreifenden Rahmen für Aeronautical Information System Security, der Luftfahrzeuge, Betrieb, Wartung, MRO, Flughäfen, ATM/ANS, UAS/UTM und Lieferketten einschließt. Security dient in diesem Kontext ausdrücklich dazu, die Sicherheit des Flugs und die Funktionsfähigkeit der zivilen Luftfahrtinfrastruktur zu gewährleisten. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=ddd1c6b93eb6f3135bd6b5b88589c2d1.png" title="ddd1c6b93eb6f3135bd6b5b88589c2d1.png"><img alt="" class="media" height="255" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=966&h=255&tok=ed0452&media=ddd1c6b93eb6f3135bd6b5b88589c2d1.png" width="966" /></a> <span style="font-size:11pt">Zunächst gibt es Reduktionsfaktoren, bestehend aus Preperation Means, d.h. vorbereitende, präventive Maßnahmen, dann Execution Means und die Window of Opportunity. Die wesentliche Eigenschaft von Preperation Means ist, dass das Sachen sind, die ein Angreifer nur einmal für den Angriff vorbereiten muss, um es für Angriffsversuche wiederzuverwenden. Begonnen wird mit der Tabelle 3. Es wird geschaut, was es braucht, um eine definierte (programmierte) Maßnahme doch noch zu umgehen. Wissen, das benötigt wird, wird gegen die erforderliche Ausrüstung gemappt. Jede Kombination aus Wissen und Equipment entspricht einem „Vorbereitungs-„Score-Wert bis maximal 6. Das ist eine Stärke, die für den Angriff steht.</span></p> | Für den engeren Bereich der Flugzeugsicherheit beschreibt ED-202B / DO-326B den Airworthiness Security Process. Dieser adressiert Bedrohungen durch IUEI, sofern diese Auswirkungen auf die Safety des Luftfahrzeugs haben können. ED-202B ist insbesondere für Design Approval Holder, Luftfahrzeughersteller und System-/Equipment-Zulieferer im Rahmen von Type Certificates, Amended Type Certificates und Supplemental Type Certificates relevant. |
| |
| <p><b><span style="color:#333333"><span style="font-size:10.5pt">Tabelle 3: Definition von Equipment-Kategorien (Preperation Means)</span></span> </b></p> | Die Security-Risikoanalyse arbeitet mit einer eigenen, aber eng an Safety anschlussfähigen Begrifflichkeit. Zentrale Begriffe sind: |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=6e8b19fb2025680e1528ca5f447348a0.png" title="6e8b19fb2025680e1528ca5f447348a0.png"><img alt="" class="media" height="320" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=973&h=320&tok=f00cad&media=6e8b19fb2025680e1528ca5f447348a0.png" width="973" /></a> <span style="font-size:11pt">In einem nächsten Schritt wird die Window of Opportunity betrachtet: Wann kann der Angriff ausgeführt werden? Flugzeugspezifisch wird die Window of Opportunity von 0 bis 8 gescort. Ein Punkt Abzug in der Effektivität gibt es, wenn der Angriff nur im Flug machbar ist, usw.</span></p> | ^Begriff^Funktion im Security-Kontext| |
| | |Asset|Schutzwürdige Funktion, Information, System oder Schnittstelle| |
| | |Security Property|z. B. Integrität, Verfügbarkeit, Vertraulichkeit oder Authentizität| |
| | |Threat Condition|Sicherheitsrelevante Folge des Verlusts einer Security Property| |
| | |Threat Scenario|Konkretes Angriffsszenario mit Threat Vector, Vulnerability, Target und Threat Condition| |
| | |Threat Path|Angriffspfad von einem Einstiegspunkt bis zum Zielsystem| |
| | |Security Measure|Technische, organisatorische oder prozedurale Maßnahme zur Verringerung der Angriffserfolgswahrscheinlichkeit| |
| | |Level of Threat / Likelihood|Semiquantitative Bewertung der verbleibenden Erfolgswahrscheinlichkeit eines Angriffs| |
| | |Security Effectiveness / Security Assurance|Bewertung und Nachweis der Angemessenheit und Belastbarkeit von Security-Maßnahmen| |
| |
| <p><b><span style="font-size:11pt">Tabelle 4: Window of Opportunity Scoring</span> </b></p> | Die Besonderheit der Flugsicherheit liegt darin, dass Safety- und Security-Bewertungen ungewöhnlich eng aufeinander bezogen sind. Security wird nicht isoliert bewertet, sondern an den möglichen Safety Impact einer Threat Condition gekoppelt. ED-202B formuliert ausdrücklich, dass der Security-Prozess mit dem Safety-Prozess interagieren muss und dass Security Assessment Activities die Outputs des Safety Assessment Process berücksichtigen sollen. Alternativ kann ein dokumentierter blended process verwendet werden, der Safety und Security integriert und geeignete Nachweise für beide Anforderungstypen liefert. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=dd55455dbea8c3f6b8e38e32e8b76b2e.png" title="dd55455dbea8c3f6b8e38e32e8b76b2e.png"><img alt="" class="media" height="319" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=993&h=319&tok=e83851&media=dd55455dbea8c3f6b8e38e32e8b76b2e.png" width="993" /></a> <span style="font-size:11pt">Bei den Execution Means handelt es sich um Maßnahmen, die überwunden werden müssen in der Ausführung des Angriffs. Der eigentliche Angriff wird ausgeführt und es wird geschaut, was für Voraussetzungen der Angreifer mitbringen muss (Wissen, spezielle Expertise, spezielles Equipment, etc.). Die Vorgehensweise ist gleich wie in Tabelle 3, jedoch anstelle Knowledge wird die Expertise gegen das erforderliche Equipment gemappt. Hier wird zwischen dem Laien, dem Experten und dem multiplen Experten (in verschiedenen Bereichen) unterschieden. Im letzteren Fall reicht es nicht, ein Cybersecurity-Experte zu sein. Es braucht z.B. auch Erfahrung in der Flugsteuerung. Das muss zusammenkommen. Maximal können 12 Punkte zu dem Security-Measure geordnet werden.</span></p> | Damit entsteht in der Luftfahrt kein vollständig gemeinsames quantitatives Risikomodell, aber eine sehr weit entwickelte semiquantitative Abstimmung. Safety liefert die Wirkungs- und Kritikalitätsachse über Failure Conditions und Severity-Klassen. Security bewertet Angriffsszenarien, Angriffspfade, Maßnahmenwirksamkeit und Assurance. Die Angemessenheit von Security-Maßnahmen wird daran gespiegelt, welchen sicherheitsrelevanten Impact ein erfolgreicher Angriff haben kann. |
| |
| <p><b><span style="font-size:11pt">Tabelle 5:</span> <span style="color:#333333"><span style="font-size:10.5pt">Definition von Equipment-Kategorien (Execution Means)</span></span> </b></p> | Für die FA512-Systematik lässt sich die Flugsicherheit daher wie folgt einordnen: |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=6b11e1e16d6498ebd8676570bab2ce85.png" title="6b11e1e16d6498ebd8676570bab2ce85.png"><img alt="" class="media" height="339" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1014&h=339&tok=c312b3&media=6b11e1e16d6498ebd8676570bab2ce85.png" width="1014" /></a> <span style="font-size:11pt">Es wird anschließend ein Combined Assessment durchgeführt, um sicherzustellen, dass die Measures nicht gleichartig oder voneinander abhängig sind. Das soll gewährleisten, die Wirksamkeiten nicht doppelt zu zählen. Insgesamt liegen dann technische Maßnahmen (programmiert, Hardware, das, was die Technik tut) und operationale Maßnahmen (Handbücher, vom Menschen umgesetzt) vor. Operational Measures sind maximal 6 Punkte stark, da angenommen wird, dass der Mensch weniger zuverlässig ist als technische Maßnahmen und er Maßnahmen auch mal nicht befolgen könnte.</span></p> | ^Domäne^Risikologik| |
| | |Safety|Risiko aus Failure Conditions, die aus Fehlern, Ausfällen oder Entwicklungsfehlern entstehen und nach ihrer Wirkung auf Luftfahrzeug, Crew und Insassen klassifiziert werden.| |
| | |Security|Risiko aus vorsätzlicher unautorisierter elektronischer Interaktion, die Security Properties beeinträchtigt und dadurch Threat Conditions mit potenziellen Safety-Auswirkungen erzeugt.| |
| | |Kopplung|Zuordnung von Security Threat Conditions zu safety-relevanten Auswirkungen sowie semiquantitative Bewertung von Threat Level, Security Measures und Security Assurance.| |
| |
| <p><b><span style="font-size:11pt">Tabelle 6:</span> <span style="color:#333333"><span style="font-size:10.5pt">Gegenüberstellung von Measure Type und Reduktion per Maßnahme</span></span> </b></p> | Kernaussage: Die Flugsicherheit ist eine Disziplin mit sehr weit entwickelten, normativ verankerten Safety-Prozessen und einer vergleichsweise weit formalisierten Security-Risikoanalyse. Ihre Besonderheit liegt darin, dass Security-Maßnahmen systematisch an den Safety-Auswirkungen möglicher Angriffsszenarien gespiegelt werden. Damit ist die Flugsicherheit ein besonders gutes Beispiel für eine semiquantitative Kopplung von Safety- und Security-Bewertungen, ohne dass daraus eine vollständig gemeinsame probabilistische Risikometrik entsteht. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=b7d02b648eae7ba17e009cc144dc24b3.png" title="b7d02b648eae7ba17e009cc144dc24b3.png"><img alt="" class="media" height="124" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1049&h=124&tok=9340c6&media=b7d02b648eae7ba17e009cc144dc24b3.png" width="1049" /></a> <span style="font-size:11pt">Als nächstes wird das Attacker Profile erarbeitet: Warum würde das jemand machen? Letztendlich wird auf die Motivation geschaut. Was will der Angreifer erreichen (finanzielle Schäden / Gewinne, Reputationsgewinn für sich, usw.)? Auch Umweltaktivisten dürfen nicht ignoriert werden, weil sie dazu beitragen können, dass Flieger am Boden bleiben und nicht abheben können.</span></p> | ==== 2. Welche Probleme und Dilemmata sind in der Disziplin charakteristisch? ==== |
| |
| <p><b><span style="font-size:11pt">Abbildung 3: Attacker Profiles</span> </b></p> | Charakteristisch für die Disziplin Flugsicherheit / Flugzeugsicherheit ist zunächst die extreme Systemkomplexität moderner Luftfahrzeuge. Die technische Entwicklung führte von relativ einfachen und robusten Systemen über zunehmend komplexe Bord- und Avioniksysteme hin zu stark integrierten, vernetzten Architekturen mit zahlreichen internen und externen Schnittstellen. Seit den 1990er-Jahren nehmen die Schnittstellen zwischen Luftfahrzeugsystemen zu; seit etwa 2000 kommen verstärkt Schnittstellen zu externen Systemen wie ATM, ATC oder Satellitennavigation hinzu. Damit werden Luftfahrzeugsysteme stärker voneinander abhängig; cascading failures und common mode failures gewinnen an Bedeutung. Der klassische „single fault“- oder „fail safe“-Ansatz allein reicht daher nicht mehr aus, um Safety auf Luftfahrzeugebene angemessen zu bewerten. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=b255235b8af8ca0c735605cad51bf1e3.png" title="b255235b8af8ca0c735605cad51bf1e3.png"><img alt="" class="media" height="449" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1074&h=449&tok=52d42b&media=b255235b8af8ca0c735605cad51bf1e3.png" width="1074" /></a> <span style="font-size:11pt">Es werden ferner Abzüge in der Risikoreduktion einmal durch die Seltenheit von Angriffen und die Anonymität gemacht. Der Drive-by-Angreifer hat keine weitere Motivierung. Er muss i.d.R. nicht bei operationellen Ausfällen oder dergleichen berücksichtigt werden. Der Terrorist wird sich nicht die Mühe machen, Reputationsschaden hervorzuheben, weil er schlichtweg zum Ziel haben wird, möglichst großen Schaden anzurichten.</span></p> | Ein erstes zentrales Problem liegt somit in der Beherrschung von Interdependenzen. Safety-relevante Funktionen werden nicht mehr ausschließlich durch klar abgegrenzte Einzelsysteme erfüllt, sondern entstehen durch das Zusammenwirken mehrerer Systeme, Subsysteme, Software-/Hardware-Items, Datenquellen und externer Dienste. Kritisch sind insbesondere Mehrfachabhängigkeiten, gemeinsame Ressourcen, gemeinsame Fehlerursachen sowie Abhängigkeiten von Daten- und Kommunikationspfaden. |
| |
| <p><b><span style="font-size:11pt">Abbildung 4: Scoring von Angreiferprofilen in Bezug auf Seltenheit und Anonymität</span> </b></p> | Ein zweites charakteristisches Problem entsteht durch die zunehmende Angreifbarkeit safety-relevanter Funktionen über elektronische Schnittstellen. Die EUROCAE-Dokumente behandeln diese Problematik über den Begriff der Intentional Unauthorized Electronic Interaction (IUEI). ED-202B beschreibt den Airworthiness Security Process als Prozess zur Behandlung zusätzlicher Risiken für das Luftfahrzeug, wenn dieses IUEI-Bedrohungen ausgesetzt ist. Die Security Risk Assessment Activities interagieren dabei mit dem Safety Assessment Process und dem Entwicklungsprozess nach ED-79B und ED-135. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=a446c56d47921743a42f52bda0ccd193.png" title="a446c56d47921743a42f52bda0ccd193.png"><img alt="" class="media" height="446" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1075&h=446&tok=41e13f&media=a446c56d47921743a42f52bda0ccd193.png" width="1075" /></a> <span style="font-size:11pt">Schlussendlich werden die Measures in einer pseudo-mathematischen Tabelle zusammen aufgetragen. Angefangen wird mit 30 Punkten im Sinn. Es wird spaltenweise die Tabelle durchgegangen. Ein Cross-Check wird durchgeführt. Die Preperations Means in Summe sollen nicht mehr als 6 Punkte ausmachen, die Window of Opportunity nicht mehr als 8 Punkte und die Execution Means nicht mehr als 18 Punkte zusammen. Dahinter steht, dass sich nicht darauf verlassen werden soll, dass eine einzelne Art und Qualität von Maßnahmen das Maß aller Dinge ist. Es braucht immer eine Kombination. Die Maßnahmen in der Ausführung dürfen dreimal so groß sein wie bei den Preperation Means, weil bei den Preperation Means nur eine einmalige Vorbereitung angenommen wird.</span></p> | Das grundlegende Dilemma besteht darin, dass Security-Maßnahmen erforderlich werden, um Safety-relevante Funktionen gegen Angriffe zu schützen, diese Maßnahmen aber selbst nicht die Safety des Luftfahrzeugs beeinträchtigen dürfen. Besonders deutlich wird dies im Unterschied zwischen fail secure und fail safe. Fail secure bedeutet, dass ein System auch im Fehlerfall sicher im Sinne der Security bleibt, beispielsweise indem Verbindungen geschlossen oder Zugriffe blockiert werden. Diese Forderung kann jedoch mit fail-safe-Anforderungen kollidieren, insbesondere in Notfalloperationen oder im Flug. ED-203A formuliert deshalb, dass fail secure die Airworthiness nicht beeinträchtigen darf und dass fail safe Vorrang vor fail secure hat. |
| |
| <p><b><span style="font-size:11pt">Abbildung 5: Zusammenführung der Maßnahmen in einer Tabelle</span> </b></p> | Daraus ergibt sich ein für die Luftfahrt besonders typischer Zielkonflikt: Security muss Angriffe begrenzen, darf aber safety-kritische Funktionen nicht blockieren. Security-Reaktionen wie Isolieren, Blockieren, Authentifizieren, Abschalten oder Alarmieren dürfen nicht dazu führen, dass Flugsteuerung, Navigation, Kommunikation oder andere sicherheitskritische Funktionen unzulässig beeinträchtigt werden. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=395845176722b7f8dbcdfb3a49f572c2.png" title="395845176722b7f8dbcdfb3a49f572c2.png"><img alt="" class="media" height="465" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1071&h=465&tok=163447&media=395845176722b7f8dbcdfb3a49f572c2.png" width="1071" /></a> <span style="font-size:11pt">Für die Bewertung pro Szenario ist bei Airbus ein eigenes Tool entwickelt worden. Zur Ermittlung des Risikos wird die Kombination aus Impact und Likelihood (in Abgrenzung zur Probability, um nicht zur Verwechslung zu kommen mit der Safety) herangezogen. Der Trick ist hier, die Impact-Spalten auf die Seite zu legen, und jedes Feld der Likelihood kann in sechs Unterfelder aufgeteilt werden. Das ergibt insgesamt eine 30-Punkte-Skala. Das kann verwendet werden, um die Ergebnisse der Berechnungen aus Abbildung 5 in diese Skala einzutragen für die entsprechende Impact-Stärke.</span></p> | Ein drittes Problem betrifft die Bewertung von Angriffsszenarien und Maßnahmenwirksamkeit. Die Luftfahrt verwendet hierfür semiquantitative Verfahren, doch die dahinterliegenden Bedrohungswahrscheinlichkeiten bleiben epistemisch. Angreiferverhalten ist willensgesteuert, adaptiv und abhängig von Motivation, Fähigkeit, Gelegenheit und verfügbaren Mitteln. Die Wirksamkeit von IT-Security-Maßnahmen kann daher nicht im Sinne klassischer Safety-Ausfallwahrscheinlichkeiten quantifiziert werden. |
| |
| <p><b><span style="font-size:11pt">Abbildung 6: Risikomatrix</span> </b></p> | Zusammenfassend sind für die Disziplin Flugsicherheit hervorzuheben: |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=e52b1aca2e3bb2bb45d82078773e4e5e.png" title="e52b1aca2e3bb2bb45d82078773e4e5e.png"><img alt="" class="media" height="541" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1085&h=541&tok=5b87ad&media=e52b1aca2e3bb2bb45d82078773e4e5e.png" width="1085" /></a> <span style="font-size:11pt">Das Verfahren kann angewandt werden für den Ist-Zustand der Flugzeug- und System- und Equipmententwicklung. Das funktioniert auf allen Detailebenen. Hier kann zwischen akzeptierten und nichtakzeptierten Risiken differenziert werden. Zusätzliche Maßnahmen können dazu beitragen, die Risikopunkte zu reduzieren. Der Charme davon, mehr als ein Kästchen für Likelihood-Werte zu haben, ist ein sichtbarer Spielraum. Wenn Risiken auf der Schwelle sind, z.B. zwischen grün und orange, dann sind die Maßnahmen noch nicht gut genug, um Akzeptanz zu erreichen.</span></p> | ^Problem / Dilemma^Beschreibung| |
| | |Komplexität und Interdependenz|Moderne Luftfahrzeuge sind hochgradig integrierte cyber-physische Systeme mit vielfältigen technischen und organisatorischen Abhängigkeiten.| |
| | |Angriffswirkungen auf Safety|Intentional Unauthorized Electronic Interaction (IUEI) kann safety-relevante Funktionen beeinträchtigen und dadurch unmittelbare oder mittelbare Auswirkungen auf die Lufttüchtigkeit verursachen.| |
| | |fail safe vs. fail secure|Security-Reaktionen und Schutzmaßnahmen dürfen die Airworthiness sowie sicherheitskritische Funktionen nicht unzulässig beeinträchtigen; erforderlich ist daher eine abgestimmte Betrachtung von Safety- und Security-Zielen.| |
| | |epistemische Unsicherheit|Bedrohungen, Angreiferverhalten und die tatsächliche Wirksamkeit von Security-Maßnahmen sind nur eingeschränkt probabilistisch belastbar, weshalb häufig semiquantitative Bewertungsansätze verwendet werden.| |
| |
| <p><b><span style="font-size:11pt">Abbildung 7: Beispielhafte Risikobestimmung</span> </b></p> | Kernaussage: Die charakteristischen Probleme der Flugsicherheit ergeben sich aus der Kombination hochgradig integrierter, safety-kritischer Systemarchitekturen und zunehmender elektronischer Angreifbarkeit. Die zentrale Herausforderung besteht darin, Security-Maßnahmen so auszulegen, dass sie Angriffe auf safety-relevante Funktionen verhindern oder erschweren, ohne Lufttüchtigkeit, Crew-Handlungsfähigkeit oder safety-kritische Kommunikation selbst zu beeinträchtigen. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=5fd2ec5ff7aa43a4d3d9a245cf97a3f4.png" title="5fd2ec5ff7aa43a4d3d9a245cf97a3f4.png"><img alt="" class="media" height="514" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1087&h=514&tok=8cdc00&media=5fd2ec5ff7aa43a4d3d9a245cf97a3f4.png" width="1087" /></a> <span style="font-size:11pt">Am Ende wird das Angreiferprofil über die Risikobewertung für den Ende-zu-Ende-Angriffspfad gestreut. Der große Vorteil ist, dass einzelne Maßnahmen bewertet und wiederbewertet werden. Nach der Implementierung und dem Testing der Maßnahmen seitens der Hersteller kann ein Re-Assessment erfolgen. Der Angriff als solcher bleibt stets erhalten, daher können die Maßnahmen auch nach dem Pentesting nochmal bewertet werden. Weitere Measures können dazu definiert werden, bis der grüne Bereich erreicht wird. Die Risikobewertung lässt sich ferner zwischen den einzelnen Detailgraden verknüpfen und synchronisieren. Der Impact einer Teilfunktion ist nicht zwingend der größte Impact auf der übergeordneten Ebene. Wenn die Teilfunktion eine Primary Subfunction ist für die Gesamtfunktion, dann wird der Impact der Gesamtfunktion gem. der Einordnung der Subfunction verändert. Die Likelihood-Bewertung funktioniert rückwärts: Wenn der gute Hersteller z.B. einer neuen Fräsmaschine ein 3G-Modem für Fernwartung mitliefert, dann kann das neue Einstiegspunkte durch diese Schnittstelle ermöglicht werden. Die Likelihood kann nicht durrchgereicht werden, sondern muss auf jeder Ebene einzeln bewertet werden. Worst Cases von „unten“ im Detailgrad müssen sich nach „oben“ auf Systemebene fortsetzen und dort übernommen werden. Wichtig ist, alles Prozessschritte detailliert und klar verständlich auszuführen, um den Review-Prozess der Product Security Community im Sinne einer Schwarmintelligenz unter den Entwicklern und Managern zu fördern.</span></p> | ==== 3. Wie werden unscharfe oder unsichere Risikobeiträge behandelt? ==== |
| |
| <p><b><span style="font-size:11pt">Abbildung 8: Prinzip der Konsistenz von Likelihood und Risiko zwischen Levels</span> </b></p> | In der Disziplin Flugsicherheit / Flugzeugsicherheit werden Unsicherheiten unterschiedlich behandelt, je nachdem, ob sie der klassischen Safety-Bewertung oder der Security-Bewertung zuzuordnen sind. Charakteristisch ist nicht eine vollständige Auflösung der Unsicherheit, sondern eine Kombination aus konservativer Klassifikation, systematischer Prozessführung, semiquantitativer Bewertung, Expertenurteil und Nachweisführung über Assurance. |
| |
| <p><a class="media" href="/!vdi-fa512/lib/exe/detail.php?id=luftfahrt&media=9a18ca337ab5ecd6e5f485e25b1c116c.png" title="9a18ca337ab5ecd6e5f485e25b1c116c.png"><img alt="" class="media" height="271" loading="lazy" src="/!vdi-fa512/lib/exe/fetch.php?w=1084&h=271&tok=06efbe&media=9a18ca337ab5ecd6e5f485e25b1c116c.png" width="1084" /></a> <span style="font-size:11pt">Anstelle der ASIL A – D aus dem Automotive-Bereich werden Development Assurance Level (DAL) gem. DO 178 / ED 12 (Software Design) und DO 254 / ED 80 (Hardware-Design) definiert:</span></p> | Auf der Safety-Seite ist der Umgang mit Unsicherheit stark methodisiert. Failure Conditions werden nach ihren möglichen Auswirkungen auf Luftfahrzeug, Besatzung und Insassen klassifiziert. Für schwerwiegende Failure Conditions werden qualitative und quantitative Safety Objectives abgeleitet, etwa über Kategorien wie Catastrophic, Hazardous, Major, Minor oder No Safety Effect. Diese Logik kann anhand der CS/FAR-25.1309-Systematik aufgezeigt werden: Je schwerwiegender die Auswirkung einer Failure Condition ist, desto unwahrscheinlicher muss ihr Auftreten sein. |
| |
| <p><b><span style="font-size:11pt">DAL A: quality process at the highest level</span> </b></p> | Diese Safety-seitige Unsicherheitsbehandlung beruht auf mehreren Mechanismen: |
| |
| <p><b><span style="font-size:11pt">DAL B: quality process that can be acceptable for item with “Hazardous” repercussions as single malfunction</span> </b></p> | ^Mechanismus^Funktion| |
| | |Konservative Klassifikation|Frühe Einordnung von Failure Conditions, häufig auf Aircraft-Level.| |
| | |Dokumentierte Annahmen|Erfassung und Nachvollziehbarkeit relevanter Annahmen, z. B. zu Crew-Awareness, Flugphase und Betriebsbedingungen.| |
| | |Rückkopplung Aircraft-Level ↔ System-Level|Präzisierung der Bewertung durch SFHA, PSSA und SSA sowie die schrittweise Verfeinerung von Anforderungen und Analysen.| |
| | |Quantitative Nachweise|Einsatz quantitativer Methoden, wenn Fehlerraten, Zuverlässigkeitsdaten und Architekturmodelle verfügbar sind.| |
| | |Common-Cause-/Common-Mode-Betrachtung|Behandlung gemeinsamer Ursachen und Abhängigkeiten, die mehrere Funktionen oder Systeme gleichzeitig beeinflussen können.| |
| | |Engineering Judgement und In-Service Experience|Absicherung und Bewertung von Risiken in Bereichen, in denen Daten oder statistische Nachweise begrenzt verfügbar sind.| |
| |
| <p><b><span style="font-size:11pt">DAL C: quality process acceptable for item with “Major” repercussions as single malfunction</span> </b></p> | ED-135 stellt hierfür eine umfangreiche Methodenlandschaft bereit: Fault Tree Analysis, FMEA/FMES, Common Mode Analysis, Zonal Safety Analysis, Particular Risk Analysis, Markov-Analyse und Model-Based Safety Analysis. Diese Verfahren dienen nicht nur der Berechnung von Wahrscheinlichkeiten, sondern auch der systematischen Identifikation von Abhängigkeiten, gemeinsamen Ursachen, latenten Fehlern, räumlichen Kopplungen und besonderen externen Einwirkungen. |
| |
| <p><b><span style="font-size:11pt">DAL D: quality process acceptable for “Minor” repercussions as single malfunction</span> </b></p> | Auf der Security-Seite ist die Unsicherheitslage grundsätzlich anders. Security-Risiken beruhen auf absichtlichem, adaptivem und strategischem Handeln. Die Wahrscheinlichkeit, dass ein Angriff versucht wird, und die Wahrscheinlichkeit, dass ein Angreifer konkrete Security-Maßnahmen überwindet, lassen sich nicht in gleicher Weise objektiv prognostizieren wie technische Ausfallraten. ED-201A weist ausdrücklich darauf hin, dass Angriffe und deren Erfolg beim Überwinden von Security-Maßnahmen nicht objektiv vorhergesagt werden können; stattdessen werden Klassifikationen und Level-of-Threat-Bewertungen verwendet. |
| |
| <p><b><span style="font-size:11pt">DAL E: No required constraint on quality process. Can be used for item with “no safety effects” or off-the-shelf equipment with a not known DAL (COTS)</span> </b> <span style="font-size:11pt">Zusammenfassend wird in der Luftfahrt ein Scoring-basierter Ansatz verwendet, um Safety und Security zu verknüpfen. Um eine Analyse zu machen und eine Bewertung anstellen zu können, müssen zunächst der Kontext definiert, die betrachteten Funktionen herausgearbeitet und die Anforderungsspezifikationen gesichtet werden. Für die Durchführung einer Risikobewertung wird von Airbus in Anlehnung an ED-203A folgender Vorgang vorgeschlagen:</span></p> | Die Security-seitige Behandlung unsicherer Risikobeiträge erfolgt daher vorrangig über Szenarien und semiquantitative Bewertungslogiken. ED-203A strukturiert die Security-Risikoanalyse über Security Scope, Asset Identification, Security Perimeter, Threat Condition Identification, Threat Scenario Identification, Security Measure Characterization, Level of Threat Evaluation und Risk Evaluation. |
| |
| <ul>\\ | Ein weiterer zentraler Mechanismus ist Assurance. Da Security-Wirksamkeit nicht im gleichen Sinne quantitativ nachgewiesen werden kann wie die Verfügbarkeit einer Safety-Funktion, spielen Security Assurance, Security Verification, Refutation, Architekturprinzipien und Prozessqualität eine wichtige Rolle. |
| <li class="level1 node"><b><span style="font-size:11.0pt">Impact-Analyse</span> </b> | |
| |
| <ul>\\ | Damit ergibt sich folgende Zweiteilung: |
| <li class="level3"><b><span style="font-size:11.0pt">Asset-Identifikation und Priorisierung (mit Scores)</span> </b></li>\\ | |
| <li class="level3"><b><span style="font-size:11.0pt">Bestimmung der Threat Conditions; Threat Condition = Asset-Score x Consequence (Impact on Safety Function)</span> </b></li>\\ | |
| <li class="level3"><b><span style="font-size:11.0pt">Impact Evaluation mit Scores</span> </b></li>\\ | |
| </ul>\\ | |
| </li>\\ | |
| <li class="level1 node"><b><span style="font-size:11.0pt">Threat Modeling</span> </b>\\ | |
| <ul>\\ | |
| <li class="level3"><b><span style="font-size:11.0pt">Threat Path Identification</span> </b></li>\\ | |
| <li class="level3"><b><span style="font-size:11.0pt">Refinement</span> </b></li>\\ | |
| </ul>\\ | |
| </li>\\ | |
| <li class="level1"><b><span style="font-size:11.0pt">Threat Scenario Generation (Threat Scenario (TS) = f(Threat Vector, Vulnerability, Target, (Threat Condition)))</span> </b></li>\\ | |
| <li class="level1"><b><span style="font-size:11.0pt">Likelihood & Security Measure Assessment</span> </b></li>\\ | |
| </ul> | |
| |
| <p><span style="font-size:11pt">Wenn eine ganzheitliche Risikoanalyse durchgeführt werden soll, dann muss in irgendeiner Weise auch die Häufigkeit von Angriffen mit in Erwägung gezogen werden. Das tut die Luftsicherheit aber im Grunde gar nicht, d.h. die Häufigkeit, mit der ein bestimmtes Szenario eintritt, wird nicht wirklich berücksichtigt, auch wenn Angreifer-Profile anhand der Kriterien „Rarität“ und „Gefühl der Straffreiheit“ bewertet werden. Es wird stattdessen gesagt, dass alle Eventualitäten mit angemessenen Maßnahmen belegt sein müssen. Ein Flugzeug steht immer im besonderen Aufmerksamkeitsfokus, daher will sich keiner darauf verlassen, dass ein Angriff selten ist. Das Risiko wird auf einer Skala von „1“ (niedrig) bis „30“ (hoch) bewertet. Risiken in der Luftsicherheit werden auf Flugzeugebene (High Level, wenig Wissen über Angriffsszenarien), Systemebene, Geräteebene und Komponentenebene betrachtet. Auf der tiefsten Ebene (Low Level, viel Wissen über Angriffsszenarien) wird Software konfiguriert und implementiert. Wenn nun „bei mehr Detail“ festgestellt wird, dass die Konfiguration schlechter (risikobehafteter) ist, dann muss das in die höheren Level übertragen bzw. dort korrigiert werden. Wenn das „Low Level“ dagegen besser ist, dann wird die obere Analyse nicht verändert, weil nur eine einzige Implementierung betrachtet und bewertet wird. Daraus folgt, dass in der Luftsicherheit auch Sicherheitspuffer berücksichtigt werden. Es wird angenommen, dass in naher Zukunft auch das Szenario x eintreten könnte. Deswegen muss die Top-Level-Funktion „Flugzeug fliegt“ auch über 30 Jahre sichergestellt werden.</span></p>\\ | ^Domäne^Umgang mit Unsicherheit| |
| </div> | |Safety|Klassifikation, konservative Annahmen, Fehlerraten, Architekturmodelle, quantitative Nachweise, Common-Cause-Analysen und Engineering Judgement zur Bewertung und Beherrschung von Unsicherheiten.| |
| | |Security|Bewertung durch Threat Conditions, Threat Scenarios, Level of Threat, semiquantitative Scorings, Security Measures, Security Assurance, Refutation sowie Vulnerability Management.| |
| |
| <h2>3 Domänenübergreifende Zusammenführung</h2> | Für die gemeinsame Betrachtung bedeutet dies: Die Luftfahrt erreicht eine vergleichsweise enge Kopplung, indem Security-Bewertungen an Safety Impact bzw. Threat Condition Severity gespiegelt werden. Sie vermeidet jedoch eine vollständige metrische Verschmelzung. Die Unsicherheit der Security-Seite wird nicht aufgelöst, sondern durch strukturierte Szenarien, konservative Bewertung, semiquantitative Skalen, Begründungspflichten und Assurance beherrschbar gemacht. |
| |
| <div class="level2">\\ | Kernaussage: Die Flugsicherheit behandelt unsichere Risikobeiträge durch formale Prozessführung und abgestufte Bewertungsverfahren. Safety-seitig werden Unsicherheiten über Failure-Condition-Klassifikation, quantitative Zielwerte, Architektur- und Fehleranalysen sowie Nachweisführung reduziert. Security-seitig bleiben Bedrohungswahrscheinlichkeiten und Maßnahmenwirksamkeiten epistemisch unsicher; sie werden über Threat Scenarios, semiquantitative Threat-Level-Bewertungen, Security Measures und Assurance eingehegt. |
| <p>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?</p>\\ | |
| </div> | |
| |
| <h2>Quellen</h2> | ===== 2 Durchführung von Risikoanalysen ===== |
| |
| <div class="level2">\\ | ==== 4. Wie werden Risikoanalysen durchgeführt? ==== |
| <p>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.</p> | |
| |
| <p><b>Airbus “A Statistical Analysis of Commercial Aviation Accidents 1958-2021”</b></p> | Risikoanalysen in der Disziplin Flugsicherheit / Flugzeugsicherheit werden stark norm- und prozessgeführt durchgeführt. Charakteristisch ist eine Kombination aus qualitativen, semiquantitativen und quantitativen Verfahren, die entlang des Entwicklungs- und Lebenszyklus eines Luftfahrzeugs miteinander verzahnt sind. Safety- und Security-Analyseprozesse unterscheiden sich methodisch, sind aber über Safety-relevante Auswirkungen, Anforderungen und Nachweisartefakte eng aufeinander bezogen. |
| |
| <p><b>EASA CS25 “Certification Specifications and Acceptable Means of Compliance For Large Aeroplanes”</b></p> | Auf der Safety-Seite folgt die Risikoanalyse einer hierarchischen Prozesslogik. Ausgangspunkt ist die Betrachtung von Luftfahrzeugfunktionen und deren möglichen Fehlfunktionen. In frühen Entwicklungsphasen werden auf Aircraft-Level Failure Conditions identifiziert, deren Auswirkungen bewertet und nach Schweregrad klassifiziert. Daraus werden Safety Objectives und Anforderungen an Systeme, Funktionen, Architektur, Unabhängigkeit und Development Assurance abgeleitet. |
| |
| <p><b>SAE ARP4754A “Guidelines for Development of Civil Aircraft and Systems”</b></p> | Typisch ist folgende Prozesskette: |
| |
| <p><b>SAE ARP4761 “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment”</b></p> | ^Prozessschritt^Zweck| |
| | |AFHA|Identifikation und Klassifikation von Failure Conditions auf Luftfahrzeugebene.| |
| | |PASA|Bewertung der vorläufigen Aircraft-Architektur hinsichtlich der Erfüllung von Safety Objectives.| |
| | |SFHA|Identifikation und Bewertung systembezogener Failure Conditions.| |
| | |PSSA|Prüfung, ob die geplante Systemarchitektur die definierten Safety Objectives erfüllen kann.| |
| | |SSA|Nachweis, dass das realisierte System die geforderten Safety Objectives erfüllt.| |
| | |ASA|Abschließende Bewertung der Safety auf Luftfahrzeugebene.| |
| |
| <p><b>RTCA DO-178 “Software Considerations in Airborne Systems and Equipment Certification”</b></p> | ED-135 beschreibt diesen Safety Assessment Process und die zugehörigen Analyseverfahren. |
| | |
| | Diese Safety-Analysen sind nicht rein quantitativ. In frühen Phasen dominieren qualitative und semiquantitative Bewertungen: Failure Conditions werden identifiziert, beschrieben und klassifiziert. Quantitative Bewertungen treten insbesondere dort hinzu, wo Architekturmodelle, Fehlerraten, Risk Times, latente Fehler, Wartungsintervalle und Redundanzen betrachtet 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. |
| | |
| | Weiterführende Darstellung: Der Prozess der Security-Risikobewertung ist in EUROCAE ED-203A, Figure 3-2, Security Risk Assessment Process, dargestellt. |
| | |
| | Die konkrete Security-Methodik wird in ED-203A ausgeführt. Sie umfasst im Kern: |
| | |
| | ^Schritt^Inhalt| |
| | |Security Scope|Festlegung des betrachteten Sicherheitsbereichs und der Systemgrenzen.| |
| | |Asset Identification|Identifikation schutzwürdiger Funktionen, Systeme, Daten und Schnittstellen.| |
| | |Security Perimeter / Environment|Abgrenzung des Sicherheitsbereichs sowie Definition relevanter Umgebungsbedingungen und Annahmen.| |
| | |Threat Condition Identification|Identifikation safety-relevanter Folgen des Verlusts einer Security Property.| |
| | |Threat Scenario Identification|Beschreibung konkreter Angriffsszenarien, Angriffspfade (Threat Paths) und relevanter Bedrohungsbedingungen.| |
| | |Security Measure Characterization|Bewertung technischer, organisatorischer und prozeduraler Schutzmaßnahmen zur Reduzierung von Sicherheitsrisiken.| |
| | |Level of Threat Evaluation|Semiquantitative Bewertung der verbleibenden Angriffsmöglichkeit bzw. Erfolgswahrscheinlichkeit eines Angriffs.| |
| | |Risk Evaluation|Bewertung der Akzeptabilität des Risikos sowie Ableitung weiterer Security-Anforderungen und Maßnahmen.| |
| | |
| | Damit ergibt sich für die Security-Seite ein überwiegend semiquantitatives und szenariobasiertes Vorgehen. Anders als in der Safety werden keine belastbaren statistischen Angriffswahrscheinlichkeiten berechnet. Stattdessen wird beurteilt, wie schwierig ein erfolgreicher Angriff unter gegebenen Bedingungen ist, welche Voraussetzungen er erfordert und welche Schutzmaßnahmen seine Durchführung erschweren. |
| | |
| | Im Betrieb und über den Lebenszyklus wird die Risikoanalyse durch Continuing-Airworthiness- und Event-Management-Prozesse ergänzt. ED-204A behandelt Information Security Guidance for Continuing Airworthiness, also Betrieb, Wartung, Ground Support Equipment, Ground Support Information Systems, Airborne Software, digitale Zertifikate, Operator-Rollen, Schulung und organisatorische Security-Programme. ED-206 ergänzt dies um Security Event Management mit Organisation, Detektion, Analyse, Reaktion, Wiederherstellung und Meldung von Security Events mit tatsächlichen oder potenziellen Aviation-Safety-Konsequenzen. |
| | |
| | Kernaussage: Risikoanalysen in der Flugsicherheit sind normativ stark geregelt und methodisch ausdifferenziert. Die Safety-Seite kombiniert qualitative Failure-Condition-Klassifikation mit quantitativen Nachweisen zu Ausfallwahrscheinlichkeiten, Architektur und Unabhängigkeit. Die Security-Seite arbeitet szenariobasiert und semiquantitativ mit Assets, Threat Conditions, Threat Scenarios, Security Measures, Level of Threat und Assurance. Beide Seiten werden im Airworthiness-Kontext so gekoppelt, dass Security-Maßnahmen an den möglichen Safety-Auswirkungen eines Angriffs gespiegelt werden. |
| | |
| | ==== 5. Welche Metriken kommen zum Einsatz? ==== |
| | |
| | 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. |
| | |
| | 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. |
| | |
| | Auf der Security-Seite kommen andere, aber anschlussfähige Metriken zum Einsatz. Zunächst wird der mögliche sicherheitsrelevante Effekt einer Threat Condition bewertet. ED-201A beschreibt hierfür eine Zuordnung von Severity-of-Threat-Condition-Klassen zu Safety-Auswirkungen. |
| | |
| | Eine zweite zentrale Security-Metrik ist der Level of Threat. ED-201A stellt eine Risk Acceptance Comparison Matrix dar, in der Severity of the Threat Condition mit dem Level of Threat kombiniert wird. Die daraus resultierenden Bewertungen lauten etwa Acceptable, Conditionally Acceptable oder Not Acceptable. Damit wird Security-Risiko nicht als einfache Angriffswahrscheinlichkeit verstanden, sondern als semiquantitative Bewertung der Angemessenheit von Schutzmaßnahmen bezogen auf den potenziellen Safety Impact. |
| | |
| | Ergänzend kommt im Bereich Security Event Management und Vulnerability Management auch CVSS zum Einsatz. ED-206 enthält eine luftfahrtspezifische Anleitung zur Verwendung des Common Vulnerability Scoring System. CVSS dient dabei vor allem der Bewertung und Priorisierung von Schwachstellen, nicht der eigentlichen Airworthiness-Safety-Severity-Logik. |
| | |
| | ^Bereich^Metrik / Bewertungsgröße^Funktion| |
| | |Safety|Failure-Condition-Severity: CAT, HAZ, MAJ, MIN, NSE|Bewertung der Auswirkungen von Failure Conditions auf Luftfahrzeug, Crew und Insassen.| |
| | |Safety|Qualitative Wahrscheinlichkeitsklassen|Einordnung zulässiger Auftretenshäufigkeiten von Fehlerzuständen.| |
| | |Safety|Quantitative Zielwerte pro Flugstunde|Nachweis der Erfüllung definierter Safety Objectives durch probabilistische Bewertungen.| |
| | |Safety|FDAL / IDAL|Bestimmung des erforderlichen Strengegrads für Entwicklungs- und Assurance-Prozesse.| |
| | |Safety|Failure Rate, Risk Time, MFT, Wartungsintervalle|Quantitative Detailbewertung von Fehlerwahrscheinlichkeiten, Expositionen und betrieblichen Einflussfaktoren.| |
| | |Security|Severity of Threat Condition|Bewertung des Safety-Impacts einer Security-Bedrohung.| |
| | |Security|Level of Threat / Likelihood|Semiquantitative Bewertung der verbleibenden Angriffsmöglichkeit eines Threat Scenarios nach Umsetzung von Schutzmaßnahmen.| |
| | |Security|Security Measure Effectiveness|Bewertung der Wirksamkeit einzelner technischer, organisatorischer und prozeduraler Security-Maßnahmen.| |
| | |Security|Risk Acceptability|Einstufung des Risikos als Acceptable, Conditionally Acceptable oder Not Acceptable.| |
| | |Security|Security Assurance Level / Assurance|Bewertung der Angemessenheit sowie des Nachweisniveaus von Security-Maßnahmen.| |
| | |Vulnerability Management|CVSS (Common Vulnerability Scoring System)|Bewertung und Priorisierung von Schwachstellen im Rahmen des Vulnerability Managements.| |
| | |
| | Die Besonderheit der Luftfahrt liegt nicht darin, dass Safety- und Security-Metriken vollständig vereinheitlicht wären. Eine solche vollständige Vereinheitlichung ist wegen epistemischer Bedrohungswahrscheinlichkeiten und nicht probabilistisch quantifizierbarer IT-Security-Wirksamkeit nicht möglich. Die Besonderheit liegt vielmehr darin, dass Security-Metriken systematisch an Safety-Wirkungen gekoppelt werden. |
| | |
| | Kernaussage: Die Flugsicherheit nutzt eine besonders weit entwickelte semiquantitative Kopplung von Safety- und Security-Metriken. Safety arbeitet mit Failure-Condition-Severity, qualitativen und quantitativen Wahrscheinlichkeitszielen sowie FDAL/IDAL. Security arbeitet mit Severity of Threat Condition, Level of Threat, Security-Measure-Effectiveness, Risk Acceptability, Assurance Levels und ergänzend CVSS. Die Metriken sind nicht identisch, werden aber über den Safety Impact von Threat Conditions systematisch aufeinander bezogen. |
| | |
| | ===== 3 Domänenübergreifende Zusammenführung ===== |
| | |
| | ==== 6. Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Erscheinung, und wie werden sie behandelt? ==== |
| | |
| | In der Disziplin Flugsicherheit / Flugzeugsicherheit treten Wechselwirkungen zwischen Safety und Security vor allem dort auf, wo elektronische Angriffe die Lufttüchtigkeit oder safety-relevante Funktionen des Luftfahrzeugs beeinflussen können. Die zentrale Kopplung entsteht nicht durch eine vollständige Verschmelzung beider Risikomodelle, sondern dadurch, dass Security-Bedrohungen auf Safety-Auswirkungen bezogen werden und die Security-Risikoanalyse die Ergebnisse der Safety-Analyse berücksichtigen muss. |
| | |
| | Die wichtigste Form der Wechselwirkung ist eine Angriffswirkung von Security auf Safety: Ein Security-Ereignis kann Verfügbarkeit, Integrität oder korrekte Funktion eines safety-relevanten Systems beeinträchtigen und dadurch eine Safety-relevante Threat Condition erzeugen. ED-206 beschreibt Security Events als bösartige Interaktionen, Malware oder Schwachstellen in Systemen, Komponenten oder Prozeduren, die Safety-Konsequenzen für Luftfahrzeug, Passagiere oder Crew verursachen können. |
| | |
| | In Entwicklung und Zertifizierung wird diese Wechselwirkung über einen gekoppelten Prozess behandelt. ED-202B beschreibt, dass Compliance entweder über differenzierte, aber interagierende Safety- und Security-Prozesse erreicht werden kann oder über einen dokumentierten blended process. Entscheidend ist, dass die Security-Prozesse die Outputs des Safety Assessment Process berücksichtigen und die Konsistenz beider Prozesse gewahrt bleibt. |
| | |
| | Die Wechselwirkung wird also in der Luftfahrt vor allem durch Anforderungs- und Nachweisbeziehungen behandelt: |
| | |
| | ^Safety-/Security-Kopplung^Behandlung| |
| | |Safety Assessment identifiziert Failure Conditions und Kritikalitäten|Das Security Assessment berücksichtigt diese Ergebnisse und bewertet potenzielle Security-Auswirkungen auf safety-relevante Funktionen.| |
| | |Security Assessment identifiziert Threat Conditions und Threat Scenarios|Ableitung von Security Requirements sowie geeigneten technischen, organisatorischen und prozeduralen Security Measures.| |
| | |Security Measures schützen safety-relevante Funktionen|Nachweis der Wirksamkeit von Security-Maßnahmen durch Security Effectiveness und Security Assurance.| |
| | |Security-Maßnahmen können Safety beeinträchtigen|Abwägung zwischen fail safe und fail secure; bei Konflikten hat der Erhalt der Airworthiness und Safety-Funktion Vorrang.| |
| | |Security Events können Safety-Folgen haben|Verbindung von Security Event Management und Safety Reporting zur Erkennung, Bewertung und Behandlung potenzieller Auswirkungen.| |
| | |
| | Besonders relevant sind Designwechselwirkungen zwischen Security-Maßnahmen und Safety-Funktionen. ED-203A behandelt dies anhand des Unterschieds zwischen fail secure und fail safe. Fail secure darf die Airworthiness nicht beeinträchtigen; fail safe hat Vorrang vor fail secure. |
| | |
| | Damit ist für die FA512-Systematik wichtig: |
| | |
| | ^Wechselwirkungstyp^Bedeutung in der Luftfahrt| |
| | |Angriffswirkung|Intentional Unauthorized Electronic Interaction (IUEI), Malware, manipulierte Daten oder kompromittierte Schnittstellen können safety-relevante Funktionen beeinträchtigen und dadurch Auswirkungen auf die Lufttüchtigkeit verursachen.| |
| | |Designwechselwirkung|Security-Maßnahmen wie Blockieren, Isolieren, Authentifizieren oder Abschalten können potenziell Safety-Funktionen beeinflussen und müssen daher hinsichtlich ihrer Auswirkungen auf die Airworthiness bewertet werden.| |
| | |
| | In der operationellen Phase treten Wechselwirkungen zusätzlich über Security Event Management und Safety Reporting auf. ED-206 beschreibt die Schnittstelle zwischen Information Security Event Management und bestehenden Safety Event Management- bzw. Occurrence-Reporting-Prozessen. Security Events können Safety-Auswirkungen haben, bevor sie im klassischen Safety Management sichtbar werden; umgekehrt kann ein Safety Incident eine Security-Ursache haben. |
| | |
| | Kernaussage: In der Flugsicherheit treten Safety-/Security-Wechselwirkungen vor allem als Angriffswirkungen auf safety-relevante Luftfahrzeugfunktionen und als Designwechselwirkungen zwischen Security-Maßnahmen und Safety-Anforderungen auf. Behandelt werden sie durch eine enge Prozesskopplung: Der Security-Prozess berücksichtigt die Ergebnisse der Safety-Analyse, Security Requirements werden aus safety-relevanten Threat Conditions abgeleitet, und Security-Maßnahmen dürfen die Airworthiness nicht beeinträchtigen. Besonders prägend ist der Grundsatz: fail safe hat Vorrang vor fail secure. |
| | |
| | ==== 7. Werden in angrenzenden Disziplinen ähnliche oder andere Probleme bearbeitet? ==== |
| | |
| | In angrenzenden Disziplinen werden sehr ähnliche Grundprobleme bearbeitet, allerdings mit unterschiedlichen Schutzobjekten, regulatorischen Rahmenbedingungen, Metriken und Verantwortungsgrenzen. Die Disziplin Flugsicherheit / Flugzeugsicherheit ist besonders eng verbunden mit Flughafensicherheit, und Automotive. |
| | |
| | ED-201A zeigt, dass Aeronautical Information System Security nicht nur Luftfahrzeuge betrifft, sondern ein vernetztes Ökosystem aus Aircraft Design and Production, Aircraft Operations, MRO, Airports, Air Traffic Management, UAS/UTM, Lieferketten und informationsverarbeitenden Organisationen umfasst. |
| | |
| | === Flughafensicherheit === |
| | |
| | Die Flughafensicherheit bearbeitet ähnliche Safety-/Security-Konflikte, aber mit anderem Schwerpunkt. Während die Flugzeugsicherheit auf Lufttüchtigkeit, Aircraft Systems und safe flight and landing zielt, stehen bei Flughäfen Passagierströme, Sicherheitsbereiche, Zugangskontrollen, Gepäckprozesse, Notausgänge, Räumung, Betriebskontinuität und physische Sicherheitszonen im Vordergrund. |
| | |
| | Ähnlich ist die Grundstruktur der Zielkonflikte: Safety-Anforderungen wie Flucht- und Räumungsmöglichkeiten müssen mit Security-Anforderungen wie Zutrittskontrolle und Integrität des Sicherheitsbereichs zusammengebracht werden. Anders als beim Luftfahrzeug sind viele Konflikte jedoch stärker räumlich, organisatorisch und personengebunden. |
| | |
| | === Automotive und andere cyber-physische Systeme === |
| | |
| | In Automotive werden ähnliche Fragen bearbeitet: funktionale Sicherheit nach ISO 26262, Cybersecurity nach ISO/SAE 21434, Kopplung von Safety-Kritikalität und Security-Schutzbedarf. Die Parallele liegt in Angriffen auf elektronische Steuergeräte und Kommunikationspfade mit möglichen Safety-Folgen. Der Unterschied liegt in Reife, Zertifizierungslogik und regulatorischem Zuschnitt. |
| | |
| | Kernaussage: In angrenzenden Disziplinen werden ähnliche Safety-/Security-Probleme bearbeitet, insbesondere in Flughafensicherheit, und Automotive. Gemeinsam sind zunehmende Vernetzung, mögliche Angriffswirkungen auf safety-relevante Funktionen und Zielkonflikte zwischen Schutzmaßnahmen. Die Flugsicherheit unterscheidet sich durch ihre besonders ausgeprägte lufttüchtigkeitsbezogene Prozess- und Nachweislogik. |
| | |
| | ==== 8. Was sind methodische Unterschiede und Gemeinsamkeiten in verschiedenen Domänen? ==== |
| | |
| | Die Disziplin Flugsicherheit / Flugzeugsicherheit zeigt besonders deutlich, dass Safety und Security methodisch eng gekoppelt werden können, ohne ihre unterschiedlichen Bewertungslogiken aufzugeben. Gemeinsam ist beiden Domänen, dass sie in der Luftfahrt stark prozess-, anforderungs- und nachweisorientiert organisiert sind. Unterschiede bestehen jedoch in der Art der betrachteten Ursachen, in der Bewertbarkeit von Wahrscheinlichkeiten, in den verwendeten Metriken und in der Form der Nachweisführung. |
| | |
| | Gemeinsamkeiten zwischen Safety und Security in der Luftfahrt |
| | |
| | ^Gemeinsamkeit^Beschreibung| |
| | |Prozessstruktur|Beide Domänen arbeiten mit geregelten Prozessketten, Planungsartefakten, Anforderungen und Nachweisen zur strukturierten Bewertung und Umsetzung von Maßnahmen.| |
| | |Kritikalitätsorientierung|Beide betrachten die möglichen Auswirkungen auf Luftfahrzeug, Crew, Passagiere sowie das Ziel eines safe flight and landing.| |
| | |Assurance-Logik|Beide erzeugen Vertrauen in die Angemessenheit, Wirksamkeit und korrekte Umsetzung definierter Anforderungen durch geeignete Nachweise und Bewertungsverfahren.| |
| | |Lebenszyklusorientierung|Beide beschränken sich nicht auf die Entwicklungsphase, sondern begleiten das Luftfahrzeug über Betrieb, Wartung und Continuing Airworthiness hinweg.| |
| | |
| | Safety Requirements und Security Requirements werden aus vorgelagerten Analysen abgeleitet und müssen im Entwicklungsprozess nachvollziehbar umgesetzt und geprüft werden. ED-202B betont, dass der Security-Prozess mit dem Safety-Prozess interagieren und dessen Outputs berücksichtigen soll. |
| | |
| | === 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. |
| | |
| | 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 dritter Unterschied betrifft die Metriken. Safety verwendet Failure-Condition-Severity, qualitative Wahrscheinlichkeitsklassen, quantitative Zielwerte, FDAL/IDAL und Failure Rates. Security verwendet Severity of Threat Condition, Threat Scenarios, Level of Threat, Security Measure Effectiveness, Risk Acceptability, Security Assurance Level und ergänzend CVSS. |
| | |
| | === Methodische Kopplung === |
| | |
| | Die Luftfahrt löst diese Unterschiede nicht durch eine vollständige Vereinheitlichung der Metriken auf. Stattdessen koppelt sie die Domänen über eine gemeinsame sicherheitsbezogene Wirkungsachse: Security wird dann airworthiness-relevant, wenn ein Angriff eine Safety-relevante Wirkung auf das Luftfahrzeug haben kann. |
| | |
| | Kernaussage: Safety und Security sind in der Flugsicherheit methodisch nicht identisch, aber stark gekoppelt. Gemeinsam sind Prozessführung, Anforderungsableitung, Nachweisorientierung und Kritikalitätsbezug. Unterschiede bestehen in Ursache, Unsicherheit, Quantifizierbarkeit und Metrik. Die Luftfahrt löst diesen Unterschied nicht durch eine künstliche gemeinsame Wahrscheinlichkeitsmetrik, sondern durch eine semiquantitative Kopplung: Security Threat Conditions werden an Safety-Auswirkungen gespiegelt, während Security Measures, Level of Threat und Assurance die Angemessenheit des Schutzes bewerten. |
| | |
| | === 9. Wie könnte ein gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security-Modellen aussehen? === |
| | |
| | In der Disziplin Flugsicherheit / Flugzeugsicherheit liegt ein gemeinsamer Nenner für Safety- und Security-Risiken nicht in einer vollständig gemeinsamen Wahrscheinlichkeitsmetrik. Eine solche metrische Verschmelzung ist methodisch nicht erreichbar, weil Safety und Security unterschiedliche Unsicherheitsarten behandeln. Safety kann in wesentlichen Teilen mit Ausfallwahrscheinlichkeiten, Failure Rates, quantitativen Safety Objectives und Development-Assurance-Logiken arbeiten. Security muss dagegen mit absichtlichem, adaptivem Angreiferverhalten, veränderlichen Bedrohungslagen und nicht objektiv quantifizierbarer Maßnahmenwirksamkeit umgehen. |
| | |
| | Der gemeinsame Nenner liegt daher nicht in der Formel Risiko = Wahrscheinlichkeit × Auswirkung im strengen probabilistischen Sinn, sondern in einer gemeinsamen Wirkungs- und Kritikalitätsachse: Sowohl Safety als auch Security beziehen ihre Bewertung letztlich darauf, welche Folgen ein Ereignis oder Angriff für Luftfahrzeug, Crew, Passagiere und sicheren Flug haben kann. |
| | |
| | Auf der Safety-Seite geschieht dies über Failure Conditions und deren Severity-Klassen. Auf der Security-Seite geschieht dies über Threat Conditions, deren Severity an mögliche Safety-Auswirkungen gekoppelt wird. ED-201A stellt hierfür Klassifikationen bereit, mit denen die Severity of Threat Conditions mit Safety-Auswirkungen vergleichbar kommuniziert werden kann. |
| | |
| | Damit ergibt sich als gemeinsamer Nenner nicht eine identische Metrik, sondern eine kompatible semiquantitative Bewertungsarchitektur: |
| | |
| | ^Ebene^Gemeinsamer Nenner| |
| | |Wirkungsbezug|Betrachtung des Safety Impact bzw. Airworthiness Impact als gemeinsame Zielgröße.| |
| | |Kritikalität|Bewertung der Auswirkungen anhand der Severity von Failure Conditions bzw. Threat Conditions.| |
| | |Schutzangemessenheit|Bewertung der Angemessenheit von Security Measures und Level of Threat im Bezug auf den resultierenden Safety Impact.| |
| | |Nachweis|Erzeugung von Assurance als Vertrauensnachweis für die Angemessenheit und Wirksamkeit der Maßnahmen, anstatt einer vollständigen Quantifizierung aller Unsicherheiten.| |
| | |
| | Ein möglicher gemeinsamer Nenner ist daher die safety-relevante Threat Condition. Sie übersetzt eine Security-Beeinträchtigung in eine sicherheitsbezogene Wirkung. Ein Angriff ist im Airworthiness-Security-Kontext nicht deshalb relevant, weil er allgemein ein IT-System betrifft, sondern weil er über den Verlust einer Security Property eine Threat Condition erzeugt, die safety-relevante Konsequenzen haben kann. |
| | |
| | Auf dieser Grundlage kann eine semiquantitative Bewertung erfolgen. In der Safety werden Failure Conditions nach Schwere und zulässiger Auftretenswahrscheinlichkeit klassifiziert. Im Security-Kontext werden Impact bzw. Severity der Threat Condition mit einer Einschätzung des Level of Threat bzw. der verbleibenden Angriffsmöglichkeit kombiniert. |
| | |
| | Für das FA512-Wiki lässt sich daraus ableiten: Der gemeinsame Nenner liegt in der Luftfahrt nicht in einer vollständig gemeinsamen Risikoformel, sondern in einer übersetzbaren Struktur aus Ursache / Angriffspfad – Beeinträchtigung – sicherheitsrelevanter Wirkung – angemessenem Schutzniveau. |
| | |
| | Kernaussage: Ein gemeinsamer Nenner für Safety- und Security-Risiken in der Flugsicherheit ist nicht eine vollständig gemeinsame quantitative Wahrscheinlichkeit, sondern der Safety Impact einer unerwünschten Wirkung. Safety bewertet Failure Conditions, Security bewertet Threat Conditions; beide lassen sich über die sicherheitsrelevante Wirkung auf Luftfahrzeug, Crew, Passagiere und safe flight and landing miteinander verbinden. Die Quantifizierung bleibt daher semiquantitativ und assurance-orientiert: Sie dient der Begründung angemessener Schutzmaßnahmen, nicht der exakten Berechnung eines gemeinsamen Gesamtrisikos. |
| | |
| | ==== 10. Welches neue Wissen ist erforderlich für eine Synthese der Domänen? ==== |
| | |
| | Für die Disziplin Flugsicherheit / Flugzeugsicherheit ist bereits eine vergleichsweise weit entwickelte methodische Kopplung von Safety und Security vorhanden. Die zentralen EUROCAE-Dokumente beschreiben Safety Assessment, Airworthiness Security, Security Risk Assessment, Continuing Airworthiness und Security Event Management als aufeinander bezogene Prozesse. Dennoch bleibt eine vollständige Synthese beider Domänen methodisch anspruchsvoll. Erforderlich ist vor allem neues Wissen darüber, wie unterschiedliche Unsicherheitsarten, Metriken, Nachweislogiken und Lebenszyklusprozesse konsistent miteinander verbunden werden können, ohne Scheingenauigkeit zu erzeugen. |
| | |
| | Ein erster Wissensbedarf betrifft die Bewertung epistemischer Unsicherheit in Security-Risiken. Während Safety-Analysen teilweise auf Fehlerraten, quantitativen Safety Objectives, Architekturmodellen und probabilistischen Methoden beruhen, bleiben Security-Bedrohungen wesentlich von Angreifermotivation, Fähigkeiten, Gelegenheit und adaptivem Verhalten abhängig. Für die Synthese werden Methoden benötigt, die epistemische Security-Unsicherheiten transparent beschreiben, begründen und kommunizieren, ohne sie in scheinbar exakte Wahrscheinlichkeiten zu überführen. |
| | |
| | Ein zweiter Wissensbedarf betrifft die Bewertung der Wirksamkeit von Security-Maßnahmen. In der Safety kann die Verfügbarkeit technischer Schutzfunktionen teilweise quantitativ nachgewiesen werden. Die Wirksamkeit von IT-Security-Maßnahmen ist dagegen nicht in gleicher Weise berechenbar, weil Angreifer auf Schutzmaßnahmen reagieren, neue Pfade suchen oder Schwachstellen ausnutzen können. Für eine weitergehende Synthese wäre zu klären, wie Scoring-Ansätze validiert, kalibriert, auditiert und zwischen Organisationen vergleichbar gemacht werden können. |
| | |
| | Ein dritter Wissensbedarf betrifft Designwechselwirkungen zwischen Safety- und Security-Maßnahmen. Die Luftfahrt behandelt diese Frage unter anderem über den Grundsatz, dass fail safe Vorrang vor fail secure haben muss, wenn Airworthiness betroffen ist. Für die Synthese braucht es zusätzliche methodische Ansätze, um solche Konflikte früh im Entwurf zu erkennen, zu dokumentieren und nachvollziehbar aufzulösen. |
| | |
| | Ein vierter Wissensbedarf betrifft die Integration von Entwicklung, Betrieb und Ereignismanagement. Security-Risiken sind dynamisch: Neue Schwachstellen, neue Angriffsmethoden und neue Betriebsumgebungen können nach der Zertifizierung auftreten. ED-204A erweitert die Betrachtung auf Continuing Airworthiness, Betrieb, Wartung, Ground Support, Rollen, Training und Operator-Prozesse. ED-206 behandelt Security Event Management einschließlich Detektion, Analyse, Response, Recovery und Reporting. |
| | |
| | Ein fünfter Wissensbedarf liegt in der koordinierten Risikokommunikation über Organisationsgrenzen hinweg. Luftfahrzeuge, Betreiber, MRO, Ground Support, ATM/ANS, Zulieferer und externe Dienste bilden ein vernetztes Ökosystem. ED-201A betont die gemeinsame Verantwortung vieler Akteure im zivilen Luftfahrtsystem und stellt Vergleichsformate für Security Risk Assessment Outputs bereit. |
| | |
| | Ein sechster Wissensbedarf betrifft die Abgrenzung und Übertragbarkeit zwischen Disziplinen. Die Flugsicherheit kann als sehr weit entwickeltes Beispiel für semiquantitative Safety-/Security-Kopplung dienen. Dennoch ist unklar, welche Teile dieser Methodik auf z. B. Automotive, Railway, Industrieanlagen, KRITIS oder physische Sicherheit übertragbar sind. |
| | |
| | Kernaussage: Für eine weitergehende Synthese von Safety und Security in der Flugsicherheit ist vor allem Wissen darüber erforderlich, wie epistemische Security-Unsicherheiten, semiquantitative Security-Scorings, Safety-Severity, Security Assurance und Lebenszyklusdaten konsistent verbunden werden können. Die zentrale offene Aufgabe besteht nicht in einer vollständigen gemeinsamen Quantifizierung, sondern in einer belastbaren Übersetzung zwischen Safety-Wirkung und Security-Schutzlogik — einschließlich klarer Kriterien für Angemessenheit, Nachweisführung, Verantwortlichkeit und Rückkopplung aus dem Betrieb. |
| | |
| | ===== 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. |
| | |
| | **Airbus “A Statistical Analysis of Commercial Aviation Accidents 1958-2021”** |
| | |
| | **EASA CS25 “Certification Specifications and Acceptable Means of Compliance For Large Aeroplanes”** |
| | |
| | **SAE ARP4754A “Guidelines for Development of Civil Aircraft and Systems”** |
| | |
| | **SAE ARP4761 “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment”** |
| | |
| | **RTCA DO-178 “Software Considerations in Airborne Systems and Equipment Certification”** |
| | |
| | **RTCA DO-254 “Design Assurance Guidance for Airborne Electronic Hardware”** |
| | |
| | **Duane Kritzinger „Aircraft System Safety: Assessments for Initial Airworthiness Certification”** |
| |
| <p><b>RTCA DO-254 “Design Assurance Guidance for Airborne Electronic Hardware”</b></p> | |
| |
| <p><b>Duane Kritzinger „Aircraft System Safety: Assessments for Initial Airworthiness Certification”</b></p>\\ | |
| </div> | |