content:luftfahrt [VDI Knowledgebase]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== Safety und Security in der Luftsicherheit ======

===== Relevante Normen und Richtlinien (unvollständig) =====

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

{{:184ba2c0b89601db982d78b809595c0f.png}}

===== 1 Risiko: Definition und Herausforderungen =====

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?

===== 2 Durchführung von Risikoanalysen =====

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?
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 10.5pt/inherit;;#333333;;inherit>Abbildung 1: Dekomposition eines Flugzeugs in Funktionen und funktionale Anforderungen</font>  **

{{:29b5ab52a25fb7d542578e839112ba1d.png?903x441}}
 <font 11pt/inherit;;inherit;;inherit>In Analogie zur Failure Condition (Safety) wird in der Security eine Threat Condition definiert.</font> 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.

** <font 10.5pt/inherit;;#333333;;inherit>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)</font>  **

{{:ed3bc123ab9cd36d73f35f57545d8b40.png?935x438}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 10.5pt/inherit;;#333333;;inherit>Tabelle 2: Gegenüberstellung von ED-203A und dem Bewertungsschema bei Airbus</font>  **

{{:ddd1c6b93eb6f3135bd6b5b88589c2d1.png?966x255}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 10.5pt/inherit;;#333333;;inherit>Tabelle 3: Definition von Equipment-Kategorien (Preperation Means)</font>  **

{{:6e8b19fb2025680e1528ca5f447348a0.png?973x320}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Tabelle 4: Window of Opportunity Scoring</font> **

{{:dd55455dbea8c3f6b8e38e32e8b76b2e.png?993x319}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Tabelle 5:</font>
 <font 10.5pt/inherit;;#333333;;inherit>Definition von Equipment-Kategorien (Execution Means)</font>  **

{{:6b11e1e16d6498ebd8676570bab2ce85.png?1014x339}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Tabelle 6:</font>
 <font 10.5pt/inherit;;#333333;;inherit>Gegenüberstellung von Measure Type und Reduktion per Maßnahme</font>  **

{{:b7d02b648eae7ba17e009cc144dc24b3.png?1049x124}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Abbildung 3: Attacker Profiles</font> **

{{:b255235b8af8ca0c735605cad51bf1e3.png?1074x449}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Abbildung 4: Scoring von Angreiferprofilen in Bezug auf Seltenheit und Anonymität</font> **

{{:a446c56d47921743a42f52bda0ccd193.png?1075x446}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Abbildung 5: Zusammenführung der Maßnahmen in einer Tabelle</font> **

{{:395845176722b7f8dbcdfb3a49f572c2.png?1071x465}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Abbildung 6: Risikomatrix</font> **

{{:e52b1aca2e3bb2bb45d82078773e4e5e.png?1085x541}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Abbildung 7: Beispielhafte Risikobestimmung</font> **

{{:5fd2ec5ff7aa43a4d3d9a245cf97a3f4.png?1087x514}}
 <font 11pt/inherit;;inherit;;inherit>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.</font>

** <font 11pt/inherit;;inherit;;inherit>Abbildung 8: Prinzip der Konsistenz von Likelihood und Risiko zwischen Levels</font> **

{{:9a18ca337ab5ecd6e5f485e25b1c116c.png?1084x271}}
 <font 11pt/inherit;;inherit;;inherit>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:</font>

** <font 11pt/inherit;;inherit;;inherit>DAL A: quality process at the highest level</font> **

** <font 11pt/inherit;;inherit;;inherit>DAL B: quality process that can be acceptable for item with “Hazardous” repercussions as single malfunction</font> **

** <font 11pt/inherit;;inherit;;inherit>DAL C: quality process acceptable for item with “Major” repercussions as single malfunction</font> **

** <font 11pt/inherit;;inherit;;inherit>DAL D: quality process acceptable for “Minor” repercussions as single malfunction</font> **

** <font 11pt/inherit;;inherit;;inherit>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)</font> **
 <font 11pt/inherit;;inherit;;inherit>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:</font>

  * ** <font 11.0pt/inherit;;inherit;;inherit>Impact-Analyse</font> **
      * ** <font 11.0pt/inherit;;inherit;;inherit>Asset-Identifikation und Priorisierung (mit Scores)</font> **
      * ** <font 11.0pt/inherit;;inherit;;inherit>Bestimmung der Threat Conditions; Threat Condition = Asset-Score x Consequence (Impact on Safety Function)</font> **
      * ** <font 11.0pt/inherit;;inherit;;inherit>Impact Evaluation mit Scores</font> **
  * ** <font 11.0pt/inherit;;inherit;;inherit>Threat Modeling</font> **
      * ** <font 11.0pt/inherit;;inherit;;inherit>Threat Path Identification</font> **
      * ** <font 11.0pt/inherit;;inherit;;inherit>Refinement</font> **
  * ** <font 11.0pt/inherit;;inherit;;inherit>Threat Scenario Generation (Threat Scenario (TS) = f(Threat Vector, Vulnerability, Target, (Threat Condition)))</font> **
  * ** <font 11.0pt/inherit;;inherit;;inherit>Likelihood & Security Measure Assessment</font> **
 <font 11pt/inherit;;inherit;;inherit>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.</font>

===== 3 Domänenübergreifende Zusammenführung =====

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?

===== 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”**