content:luftfahrt [VDI Knowledgebase]

<h1>Safety und Security in der Luftsicherheit</h1>

<h2>Relevante Normen und Richtlinien (unvollständig)</h2>

<div class=„level2“>
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.

Tabelle 1: Relevante Normen und Richtlinien für Safety und Security

<h2>1 Risiko: Definition und Herausforderungen</h2>

<div class=„level2“>
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?
</div>

<h2>2 Durchführung von Risikoanalysen</h2>

<div class=„level2“>
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? 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.

Abbildung 1: Dekomposition eines Flugzeugs in Funktionen und funktionale Anforderungen

<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> In Analogie zur Failure Condition (Safety) wird in der Security eine Threat Condition definiert. 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.

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)

<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> 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. 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.

Tabelle 2: Gegenüberstellung von ED-203A und dem Bewertungsschema bei Airbus

<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> 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 &bdquo;Vorbereitungs-&bdquo;Score-Wert bis maximal 6. Das ist eine Stärke, die für den Angriff steht.

Tabelle 3: Definition von Equipment-Kategorien (Preperation Means)

<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> 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.

Tabelle 4: Window of Opportunity Scoring

<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> 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.

Tabelle 5: Definition von Equipment-Kategorien (Execution Means)

<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> 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.

Tabelle 6: Gegenüberstellung von Measure Type und Reduktion per Maßnahme

<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> 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.

Abbildung 3: Attacker Profiles

<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> 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.

Abbildung 4: Scoring von Angreiferprofilen in Bezug auf Seltenheit und Anonymität

<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> 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.

Abbildung 5: Zusammenführung der Maßnahmen in einer Tabelle

<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> 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.

Abbildung 6: Risikomatrix

<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> 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.

Abbildung 7: Beispielhafte Risikobestimmung

<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> 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 &bdquo;unten“ im Detailgrad müssen sich nach &bdquo;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.

Abbildung 8: Prinzip der Konsistenz von Likelihood und Risiko zwischen Levels

<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> 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:

DAL A: quality process at the highest level

DAL B: quality process that can be acceptable for item with “Hazardous” repercussions as single malfunction

DAL C: quality process acceptable for item with “Major” repercussions as single malfunction

DAL D: quality process acceptable for “Minor” repercussions as single malfunction

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) 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:

<ul>
<li class=„level1 node“>Impact-Analyse

<ul>

   <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“>Threat Modeling 
<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“>Threat Scenario Generation (Threat Scenario (TS) = f(Threat Vector, Vulnerability, Target, (Threat Condition))) </li>
<li class=„level1“>Likelihood & Security Measure Assessment </li>
</ul>

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 &bdquo;Rarität“ und &bdquo;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 &bdquo;1“ (niedrig) bis &bdquo;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 &bdquo;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 &bdquo;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 &bdquo;Flugzeug fliegt“ auch über 30 Jahre sichergestellt werden.
</div>

<h2>3 Domänenübergreifende Zusammenführung</h2>

<div class=„level2“>
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?
</div>

<h2>Quellen</h2>

<div class=„level2“>
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 &bdquo;Aircraft System Safety: Assessments for Initial Airworthiness Certification”
</div>