automotive [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.
~~NOCACHE~~
[[http://localhost/inhaltsverzeichnis/| Knowlegebase Inhaltsverzeichnis]]
----
====== Safety (Security) Risiko im Automobilbereich ======

===== Relevante Normen und Richtlinien (unvollständig) =====
 <font inherit/inherit;;#000000;;inherit>Nachfolgend werden für die Automobilindustrie wichtige und relevante Normen und Richtlinien für die Bereiche Safety und Security aufgeführt. Die Auflistungen erheben hierbei keinen Anspruch auf Vollständigkeit.</font>

**Tabelle 1: Relevante Normen und Richtlinien für den Bereich "Safety"**

^ <font inherit/inherit;;#000000;;inherit>Kennung</font>  ^ <font inherit/inherit;;#000000;;inherit>Jahr</font>  ^ <font inherit/inherit;;#000000;;inherit>Titel</font>  ^ <font inherit/inherit;;#000000;;inherit>Anmerkung</font>  |
|[[https://www.vde-verlag.de/iec-normen/217177/iec-61508-1-2010.html|IEC]] 61508  | <font inherit/inherit;;#000000;;inherit>2010</font>  | <font inherit/inherit;;#000000;;inherit>Functional safety of electrical/electronic/programmable electronic safety-related systems</font>  | <font inherit/inherit;;#000000;;inherit>7 Teile der Normenreihe gelten als branchenunabhängige Sicherheitsgrundnorm</font>  |
|[[https://www.iso.org/standard/43464.html|ISO]] 26262  | <font inherit/inherit;;#000000;;inherit>2018</font>  | <font inherit/inherit;;#000000;;inherit>Road vehicles – Functional safety</font>  | <font inherit/inherit;;#000000;;inherit>12 Teile der Normenreihe als sektorspezifisches Derivat für Straßenfahrzeuge</font>  |
|[[https://www.sae.org/standards/content/j2980_201505/|SAE]] J2980  | <font inherit/inherit;;#000000;;inherit>2018</font>  | <font inherit/inherit;;#000000;;inherit>Considerations for ISO 26262 ASIL Hazard Classification</font>  | <font inherit/inherit;;#000000;;inherit>Präsentation einer Methode sowie Beispielergebnisse für die ASIL-Ermittlung</font>  |
|[[https://webshop.vda.de/VDA/de/vda-702-062015|VDA]] 702  | <font inherit/inherit;;#000000;;inherit>2015</font>  | <font inherit/inherit;;#000000;;inherit>Situationskatalog E-Parameter nach ISO 26262-3</font>  | <font inherit/inherit;;#000000;;inherit>Abbildung von Basissituationen und deren E-Parameter für die weitere Verwendung in der Gefährdungs- und Risikoanalyse</font>  |
|ISO/TR 8939  |2023 (geplant)  |Application of predictive maintenance to hardware with ISO 26262-5  |Standard befindet sich derzeit in der Entwicklung durch ISO/TC 22/SC 32/WG8. Das informative Dokument soll Erklärungen zum Sachverhalt "vorausschauende Instandhaltung" bieten, welche insbesodere bei Halbleitern immer wichtiger wird.|
|ISO/PAS 8926  |2023 (geplant)  |Qualification of pre-existing software products for safety-related applications  |Standard befindet sich derzeit in der Entwicklung durch ISO/TC 22/SC 32/WG8.|
|ISO/TR 9968  |2023 (geplant)  |Application to generic rechargeable energy storage systems for new energy vehicles  |Standard befindet sich derzeit in der Entwicklung durch ISO/TC 22/SC 32/WG8. Das informative Dokument soll einen Ansatz definieren für die systematische Ableitung von Sicherheitsanforderungen an E/E-Systeme unter Berücksichtigung anderer Technologien (z.B. mechnaische und chemische Sicherheit).|
|ISO TS 5083  |2023 (geplant)  |Road vehicles - Safety for automated driving systems - Design, verification and validation  |Standard befindet sich derzeit in der Entwicklung durch ISO/TC 22/SC 32/WG13. Er soll anwendungsspezifisch für die Sicherheit in automatisierten Fahrsystem der SAE-Level 3 und 4 anwendbar sein und den gesamten Sicherheitslebenszyklus abdecken.|
|[[https://www.vde-verlag.de/iec-normen/220702/iso-iec-guide-51-2014.html|ISO]]/IEC Guide 51  | <font inherit/inherit;;#000000;;inherit>2014</font>  | <font inherit/inherit;;#000000;;inherit>Safety aspects - Guidelines for their inclusion in standards</font>  | <font inherit/inherit;;#000000;;inherit>Leifaden mit Anforderungen und Empfehlungen für die Ersteller von Normen zur Einbeziehung von Sicherheitsaspekten</font>  |
|[[https://unece.org/transport/documents/2021/03/standards/un-regulation-no-157-automated-lane-keeping-systems-alks|UNECE]] R157  | <font inherit/inherit;;#000000;;inherit>2021</font>  | <font inherit/inherit;;#000000;;inherit>Automated Lane Keeping Systems</font>  | <font inherit/inherit;;#000000;;inherit>Erste verbindliche internationale Regelung für die so genannte „Level 3-Fahrzeugautomatisierung" mit Bezug zur Funktionalen Sicherheit</font>  |
|[[https://www.iso.org/standard/70939.html|ISO]] 21448  | <font inherit/inherit;;#000000;;inherit>2022</font>  | <font inherit/inherit;;#000000;;inherit>Road vehicles – Safety of the intended functionality</font>  | <font inherit/inherit;;#000000;;inherit>Behandelt Gefahren durch Unzulänglichkeiten bei der Spezifikation der beabsichtigten Funktionalität auf Fahrzeugebene</font>  |
|[[https://www.iso.org/standard/83303.html|ISO]]/PAS 8800  | <font inherit/inherit;;#000000;;inherit>2023 \\
(geplant)</font>  | <font inherit/inherit;;#000000;;inherit>Road vehicles – Safety and artificial intelligence</font>  | <font inherit/inherit;;#000000;;inherit>Standard befindet sich derzeit in der Erarbeitung durch ISO/TC 22/SC 32/WG8</font>  |
|ISO 12100  |2010  | <font inherit/inherit;;#000000;;inherit>Safety of machinery - General principles for design - Risk assessment and risk reduction</font>  | <font 14px/Arial,Helvetica,sans-serif;;#000000;;inherit>Standard kann als Quelle herangezogen werden zur systematischen Identifkation von Risikoquellen, auch wenn er nicht explizit für den Bereich der Straßenfahrzeuge erstellt wurde</font>    |
| <font inherit/inherit;;#000000;;inherit>Regulation (EC) 661</font>  |2009  | <font inherit/inherit;;#000000;;inherit>General Safety Regulation (GSR)</font>  | <font inherit/inherit;;#000000;;inherit>Europäische Verordnung mit Anforderungen für die Typgenehmigung bzgl. der Sicherheit von Kraftfahrzeugen, Anhängern, Komponenten und separaten technischen Einheiten</font>  |
 <font inherit/inherit;;#000000;;inherit>**Tabelle 2: Relevante Normen und Richtlinien für den Bereich "Security"**</font>

^ <font inherit/inherit;;#000000;;inherit>Kennung</font> ^ <font inherit/inherit;;#000000;;inherit>Jahr</font> ^ <font inherit/inherit;;#000000;;inherit>Titel</font> ^ <font inherit/inherit;;#000000;;inherit>Anmerkung</font> |
|[[https://www.iso.org/standard/70918.html|ISO]]/ SAE 21434  | <font inherit/inherit;;#000000;;inherit>2021</font> | <font inherit/inherit;;#000000;;inherit>Road vehicles – Cybersecurity engineering</font> | <font inherit/inherit;;#000000;;inherit>Spezifizierung von Engineering-Anforderungen an das Cybersicherheits-Risikomanagement bzgl. Konzept, Produktentwicklung, Produktion, Betrieb, Wartung und Außerbetriebnahme von E/E-Systemen in Straßenfahrzeugen</font> |
|[[https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security|UN Regulation 155]]  | <font inherit/inherit;;#000000;;inherit>2021</font> | <font inherit/inherit;;#000000;;inherit>Cyber security and cyber security management system</font> | <font inherit/inherit;;#000000;;inherit>Regulierung fordert den Betrieb eines zertifizierten Cybersecurity-Managementsystems als Bedingung für die zukünftige Typengenehmigung über den kompletten Fahrzeug-Lebenszyklus (inkl. Sicherstellung der Einhaltung von Cybersecurity-Anforderungen entlang der gesamten Lieferkette)</font> |
|[[https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update|UNECE]] R156  | <font inherit/inherit;;#000000;;inherit>2021</font> | <font inherit/inherit;;#000000;;inherit>Software update and software update management system</font> | <font inherit/inherit;;#000000;;inherit>Regulierung fordert den Betrieb eines zertifizierten Softwareupdate-Managementsystems als Bedingung für die zukünftige Typengenehmigung über den kompletten Fahrzeug-Lebenszyklus (inkl. Compliance der Zulieferer)</font> |
|[[https://www.sae.org/standards/content/j3061_202112|SAE]] J3061  | <font inherit/inherit;;#000000;;inherit>2016</font> | <font inherit/inherit;;#000000;;inherit>Cybersecurity Guidebook for Cyber-Physical Vehicle Systems</font> | <font inherit/inherit;;#000000;;inherit>Praxisleitfaden für die Cyber-Sicherheit von Fahrzeugen über den gesamten Lebenszyklus</font> |
|[[https://webshop.vda.de/QMC/de/acsms-eng_2020|V]]DA  | <font inherit/inherit;;#000000;;inherit>2020</font> | <font inherit/inherit;;#000000;;inherit>Automotive Cybersecurity-Managementsystem-Audit</font> | <font inherit/inherit;;#000000;;inherit>Definition des Fragenkatalogs und des Bewertungsschemas, das bei der Auditierung (OEM und Vertragspartner) eines Cybersecurity-Managementsystems zur Anwendung kommen kann</font> |
|[[https://webshop.vda.de/QMC/de/automotive-spice-for-cybersecurity_1st-edit-2021|VDA]]  |2021  |Automotive SPICE for Cybersecurity  |Erweiterung des bekannten Automotive SPICE Standards um zusätzliche Prozesse mit dem Ziel die Cybersecurity-relevanten Prozesse in das bewährte Grundgerüst zu integrieren  |
|[[https://www.iso.org/standard/80840.html|ISO PAS 5112]]  |2022  |Road vehicles - Guidelines for auditing cybersecurity engineering  |Leitfaden zur Auditierung von Cybersecurity-Management-Systemen (CSMS) und den Kompetenzen des CSMS-Auditors  |
 <font inherit/inherit;;#000000;;inherit>**Tabelle 3: Weitere relevante Normen und Richtlinien**</font>

^ <font inherit/inherit;;#000000;;inherit>Kennung</font> ^ <font inherit/inherit;;#000000;;inherit>Jahr</font> ^ <font inherit/inherit;;#000000;;inherit>Titel</font> ^ <font inherit/inherit;;#000000;;inherit>Anmerkung</font> |
|[[https://www.beuth.de/de/technische-regel/iatf-16949/263942493|IATF]] 16949| <font inherit/inherit;;#000000;;inherit>2016</font> | <font inherit/inherit;;#000000;;inherit>Anforderungen an Qualitätsmanagementsysteme für die Serien- und Ersatzteilproduktion in der Automobilindustrie</font> | <font inherit/inherit;;#000000;;inherit>Festlegung von grundlegenden Anforderungen an Qualitätsmanagementsysteme im Rahmen der Serien- und Ersatzteilproduktion in der Automobilindustrie</font> |
|[[https://www.beuth.de/de/technische-regel/iatf-16949/263942493|VDA Automotive]] SPICE| <font inherit/inherit;;#000000;;inherit>2017 V3.1</font> | <font inherit/inherit;;#000000;;inherit>Automotive SPICE Process Reference Model / Process Assessment Model</font> | <font inherit/inherit;;#000000;;inherit>Verbindliches Verfahren zur objektiven Prozessbewertung und der daraus resultierenden anschließenden Prozessverbesserung auf Projekt- sowie Organisationsebene</font> |
|DIN EN 61000-1-2|2017|Elektromagnetische Verträglichkeit (EMV): Allgemeines - Verfahren zum Erreichen der funktionalen Sicherheit von elektrischen und elektronischen Systemen einschließlich Geräten und Einrichtungen im Hinblick auf elektromagnetische Phänomene|Zu betrachtende Gesichtspunkte, wenn E/E/PES elektromagnetischen Störgrößen ausgesetzt sind, die deren Betrieb beeinflussen können|
|IEC 61000-6-7|2015|Elektromagnetische Verträglichkeit (EMV) – Teil 6-7: Fachgrundnormen - Störfestigkeitsanforderungen an Geräte und Einrichtungen, die zur Durchführung von Funktionen in sicherheitsbezogenen Systemen (funktionale Sicherheit) an industriellen Standorten vorgesehen sind|Bestimmt für Lieferanten, die Angaben zur Störfestigkeit von Geräten machen müssen, die zur Verwendung in sicherheitsbezogenen Systemen bestimmt sind|




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

Gemäß der internationalen Rechtsprechung dürfen nur Produkte in Verkehr gebracht werden, von denen keine Gefahr für Leib und Leben ausgeht (siehe zum Beispiel in Deutschland §3(2) des Produktsicherheitsgesetzes), die also "sicher" im Sinne von "safe" sind. Die Safety kann hierbei von verschiedenen Risikoquellen negativ beeinflusst werden, deren Ansätze zur Vermeidung oder Beherrschung in verschiedenen Normen / Standards addressiert werden:
 <font inherit/inherit;;#000000;;inherit>**Tabelle 4: Typen von Risikoquellen und Referenzen**</font>

^Risikoquelle^Standard^Titel|
|Fehlfunktionen von E/E-Systemen aufgrund systematischer Fehler oder zufälliger Hardware-Fehler|ISO 26262|Funktionale Sicherheit|
|Nichtadäquates Sollverhalten, unzureichende Performanz oder physikalische Unzulänglichkeiten der Sensorik|ISO 21448|Sicherheit der intendierten Sollfunktion ("SOTIF")|
|Ausfall der Sollfunktion von E/E-Systemen|ISO 26262 (Band 10, Kap. 12)|Sicherheitsrelevante Verfügbarkeit ("SaRA")|
|Bewusste Manipulation des Systems|ISO 21434|Cybersecurity|
|Alterung / Verschleiß|diverse|Maßnahmen gemäß Stand der Technik, z.B. FMEA, DRBFM, Dauererprobung, HALT/HASS usw.|

Eine Vorgehensweise zur systematischen Identifikation der Risikoquellen findet sich in der ISO 12100.

Charakteristisch ist, dass die unterschiedlichen Methoden und Ansätze nicht untereinander abgeglichen sind bzw. auch gar nicht ableichbar sind. Am weitesten ausgearbeitet ist der Bereich der Funktionalen Sicherheit, hierfür gibt es einen mittlerweile etablierten Standard (ISO 26262). Wie die Frage des Safety-Risikos aber domänenübergreifend beantwortet werden kann, fehlt aber heute noch. Heutige Ansätze gehen von einer eher qualitativen Betrachtung auf Basis des jeweiligen „Stands der Technik“ aus.

==== Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren? ====

Als grundlegender Standard zur Beschreibung der Vorgehensweise bei der sicherheitsgerichteten Entwicklung kann die ISO/IEC Guide 51:2014 ("Safety aspects — Guidelines for their inclusion in standards") herangezogen werden, welcher die grundsätzliche Vorgehensweise zur risikobasierten Entwicklung beschreibt und woran sich ISO-/IEC-Normen im Bereich der Safety orientieren:

**Abbildung 1: Vorgehensweise nach ISO/IEC Guide 51:2014**

{{:bbf8df5b2262ee2ebf7b77331f4f96f6.png}}

Diese Vorgehensweise wird in der ISO 26262 für die funktionale Sicherheit von Straßenfahrzeugen folgendermaßen abgebildet: Das Risiko wird als Kombination der Eintrittswahrscheinlichkeit eines Schadens und des entsprechenden Schadensausmaßes definiert. ISO 26262-3 gibt in einem informativen Anhang zur Gefährdungsanalyse und Risikobeurteilung (hazard analysis and risk assessment, HARA) an, dass ein Risiko als Funktion wie folgt beschrieben werden kann: R=F(f,C,S)

Dabei gelten die folgenden Begrifflichkeiten (im Originalwortlaut):

  * f: frequency of occurrence of a hazardous event
  * C: the ability to avoid specific harm or damage through timely reactions of the persons involved (= controllability)
  * S: potential severity of the resulting harm or damage

Die Eintrittshäufigkeit wiederum wird von diversen Faktoren wie folgt beeinflusst: f=E×λ

Dabei gelten die folgenden Begrifflichkeiten (im weitest gehenden Originalwortlaut und –kontext):

  * E: A factor to consider how frequently and for how long individuals find themselves in a situation where the aforementioned hazardous event can occur. In ISO 26262 this is simplified to be a measure of the probability of the operational situation taking place in which the hazardous event can occur (=exposure).
  * λ: Another factor is the failure rate of the item that could lead to the hazardous event. The failure rate is characterised by hazardous hardware random failures and systematic faults that remained in the E/E system. The failure rate of the item is not considered a priori (in the risk assessment) because an unreasonable residual risk is avoided through the implementation of the resulting safety requirements.

Die drei Risikoparameter E, C und S werden im Rahmen der HARA eingestuft und miteinander kombiniert, um den ASIL (Automotive Safety Integrity Level) zu ermitteln, der als Maß zur erforderlichen Risikoreduzierung angesehen werden kann.

Die ISO 21434 zum Thema Cyber-Security (s. auch Ausführungen zu Punkt 3 in Kapitel 2) soll das Risiko als eine Art Ansatz „Feasibility vs. Impact“ betrachten, wobei insgesamt fünf Risikoparameter verwendet werden sollen. Die Risikokalkulation basiert derzeit auf der so genannten „Heat Map“ (s. nachfolgendes Bild aus [1]).

**Abbildung 2: Heatmap zur Risikokalkulation**

{{:bild_1.png?400}}

Das zunehmende Wachstum von Firmware-, Software- und Cloudkomponenten macht moderne Fahrzeuge zu Datenhubs. Gleichzeitig sind die Daten von fahrzeugimmanenten Systemen attraktive Ziele für Cyberattacken. Erfolgreiche Angriffe können, bedingt durch die Interoperabilität von Systemkomponenten innerhalb des Fahrzeugs, unerwünschte Schadensereignisse hervorrufen, die die Safety bzw. die physische Security betreffen. Um den Herausforderungen durch Cyberbedrohungen zu begegnen, wurde im Januar 2021 die UNECE R 155-Regulation (kurz: R 155) für Cybersecurity-Managementsysteme von der United Nations Economic Commission for Europe (UNECE) eingeführt. Die Verordnung Nr. 155 (R 155) ist Teil der UNECE WP.29, welche aus den Verordnungen Nr. 155 (Cybersecurity-betreffend), Nr. 156 (Software-Updates-betreffend) und Nr. 157 (Automated Lane Keeping-betreffend) besteht. Auf der Homepage der[[http://unece.org/sites/default/files/2021-03/R155e.pdf|UNECE.org]]-
 <font 11pt/inherit;;inherit;;inherit>Webseite können die Spezifikationen dieser Regulation mit dem Titel „Proposal for a new UN Regulation on uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system” nachgelesen werden.</font>

Webseite erworben werden. Grundlage der Norm ist die SAE J3061 "Cybersecurity Guidebook for Cyber-Physical Vehicle Systems", welche einen Praxisleitfaden für die Cyber-Sicherheit von Produkten im Fahrzeug über den gesamten Lebenszyklus beinhaltet. Sie kann unter[[https://www.sae.org/standards/content/j3061_202112|der SAE.org]]-Webseite erworben werden. In der SAE J3061 werden die Threat and Operability Analysis, Attack Tree Analysis und das HEAVENS Security Model zur Analyse und Bewertung von Cybersecurity-Risiken vorgeschlagen. Im Gegensatz zur ISO/SAE 21434 wird die SAE J3061 jedoch nicht mehr weiterentwickelt.
 <font 11pt/inherit;;inherit;;inherit>Die ISO/SAE 21434 fasst den Umfang etwas weiter und beschreibt allgemein Anforderungen an die Informationssicherheit (als „Dach“, beschrieben in ISO 27001), die Prozessgüte (als „Träger“, beschrieben in Automotive SPICE Supply Chain & Cybersecurity) und die Produktsicherheit (als „Fundament“, dem Nukleus der SAE J3061 und beschrieben in dem TARA der ISO/SAE 21434). Es gibt eine Vielzahl von Parallelen zur ISO 26262, so sind z.B. beim Cybersecurity Process Overview (SAE J3061, Teil 8) die Phasen des Entwicklungszyklus an die Teile 3-8 der ISO 26262 angelehnt. Sie beinhlaten die Konzeptphase, die Systementwicklung (Hardware bzw. Software), die Produktion und unterstützende (Support-)Prozesse. Sie gilt für Bauteile (elektronische Teile und Software) von in Serie hergestellten Fahrzeugen sowie für Ersatzteile und Zubehör. Sie deckt die Phasen der Entwicklung, der Produktion, des Betriebs, der Wartung und des Recyclings im Lebenszyklus eines Fahrzeugs ab, d.h. OEM müssen die Anforderungen aus der Norm über die gesamte Lieferantenwirkkette nachweisen. Zentrale Punkte der ISO/SAE 21434 ist der Aufbau sowie Betrieb eines Cybersecurity Managementsystems und die Bedrohungsanalyse und Risikobewertung, Threat Analysis and Risk Assessment (TARA) genannt.</font>
 <font 11pt/inherit;;inherit;;inherit>Die ISO/SAE 21434 beschreibt lediglich ein Rahmenwerk. Die konkrete Implementierung liegt beim Anwender. Weil die OEMs zur Homologation gemäß UN R155 für ihre Produkte (Fahrzeuge) das CSMS über die gesamte Lieferantenwirkkette nachzuweisen haben, werden diese von den automobilen Zulieferern Konformität mit den Anforderungen an ein CSMS respektive an die Erstellung einer TARA fordern. Weiterhin werden die Nachweise zur cybersecurity Testumsetzung und die Testergebnisse im Rahmen des CSMS über die Lieferantenwirkkette nachzuweisen sein. Grundsätzlich ist die Homologation OEM-Verantwortung. Es gibt Ausnahmen z. B. Systeme der passiven Sicherheit, wo auch Tier-1 selber Systeme homologieren. Mit der ISO/PAS 5112 wurde ein Standard herausgegeben, in der die Auditierung eines CSMS und die Komponenten des CSMS Auditors definiert sind.</font>

Wie aber OEM den Nachweis der ISO 21434-Konformität von Tier-1 fordern, ist jeweilige OEM-Sache. Die Notwendigkeit zur Durchführung einer TARA seitens der Zulieferer ist sicher. Um die Fahrzeughersteller bei der Vorbereitung auf das Assessment zu unterstützen, hat der Verband der Automobilindustrie([[https://webshop.vda.de/QMC/de/acsms-de_2020|VDA]])
 <font 11pt/inherit;;inherit;;inherit>das Dokument "Automotive Cyber Security Management System Audit" veröffentlicht. Es „definiert den Fragenkatalog und das Bewertungsschema, das bei der Auditierung des CSMS sowohl der OEMs als auch der Vertragspartner zur Anwendung kommen kann“, so die Abstract-Beschreibung der Veröffentlichung.</font>

==== Welche Probleme und Dilemmata sind in Ihrer Disziplin charakteristisch? ====

Die Einstufung der Risikoparameter ist nicht immer trivial und einfach. Da die HARA die Basis für alle weiteren Aktivitäten des automotiven Sicherheitslebenszyklus darstellt, ist hier natürlich besondere Sorgfalt geboten. Insbesondere bei der Einstufung der Exposition kommt es durchaus im Rahmen des Analyseteams zu unterschiedlichen Ansichten, die es dann zusammenzutragen gilt. Fast noch entscheidender ist jedoch, die genaue Definition des Betrachtungsgegenstands, welche als Eingang zur HARA vorliegen muss. Wenn nicht klar ist, was genau untersucht werden soll, wie die entsprechenden Funktionalitäten aussehen und welche Grenzen die Funktion bzw. das System hat, wird eine entsprechende Analyse der Gefährdungen und Risiken nicht zwingend von Erfolg gekrönt sein.

Mit der ISO/SAE 21434 wird die Methodik der Bedrohungsanalyse und des Risikoassessments beschrieben, jedoch stehen die Klassifizierungsvorschläge für die Impact- Kategorien, der Angriffsmachbarkeits- Kategorien und die Risikomatrix als Beispiele im Anhang, was den verbindlichen Charakter und somit einen Standard entgegenspricht. Es ist daher wichtig, dass sich die Vertragspartner beim Austausch von Risiken immer über die angewendeten Definitionen, Methoden und Metriken (zur Impactbewertung, Angriffsmachbarkeitbewertung oder Ableitung einer Risikomatrix) informieren.

Ähnlich dem ASIL, definiert in der ISO 26262, führt die ISO/SAE 21434 einen Cybersecurity assurance level (CAL) ein. Annex E der ISO/SAE 21434 beschreibt den CAL als Ergebnisse aus der Risikomatrix (aus Impactbewertung und Angriffsmachbarkeitseinstufung). Damit ist ein deutlicher Unterschied zum ASIL herauszustellen: Der CAL kann während des Produktlebenszyklus' dynamisch sein. Ein in der Entwicklungsphase mitigiertes Risiko, dessen implementierte Cybersecurity Maßnahme durch Tests als effektiv bewiesen wurde, kann in der Post- Entwicklungsphase durch eine entdeckte Schwachstelle wieder zu einer Erhöhung des Risikos und damit des CALs führen. Erst durch Spezifikation, Umsetzung und Tests eines Fixes der Schwachstelle wird das Risiko und damit der CAL reduziert. Aufgrund des erforderlichen Engineering Supports Post- SOP (Start- of- Production) bis über EOP (End- of- Production) hinaus, ist sehr empfehlenswert, dass die Vertragspartner ein Service- Level Agreements für den Supportzeitraum, den Kommunikationsplan für die Cybersecurity Incidences, den zeitlichen Umfang und der Abrechnung der Engineersleistungen vereinbaren. Insbesondere kryptographische Algorithmen und Schlüssellängen sind nur zeitlich begrenzt. Der NIST SP 800-57 gibt eine Hilfestellung zur Anwendung der richtigen kryptographischen Verfahren und Schlüssellängen über den Produktlebenszykluszeitraum.

==== Wie werden unscharfe oder unsichere Risikobeiträge behandelt? ====

Die unter Punkt 1 beschriebenen Risikoparameter sind bereits als unscharf anzusehen. Deren Klassifizierung erfolgt mit Hilfe verschiedener Abstufungen (S0 bis S3, E0 bis E4, C0 bis C3). Die Durchführung der HARA erfolgt im Team mit dem erforderlichen Expertenwissen.

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

Gemäß der internationalen Rechtsprechung dürfen nur Produkte in Verkehr gebracht werden, von denen keine Gefahr für Leib und Leben ausgeht (siehe zum Beispiel in Deutschland §3(2) des Produktsicherheitsgesetzes), die also "sicher" im Sinne von "safe" sind. Die Safety kann hierbei von verschiedenen Risikoquellen negativ beeinflusst werden, deren Ansätze zur Vermeidung oder Beherrschung in verschiedenen Normen / Standards addressiert werden:
 <font inherit/inherit;;#000000;;inherit>**Tabelle 4: Typen von Risikoquellen und Referenzen**</font>

^Risikoquelle^Standard^Titel|
|Fehlfunktionen von E/E-Systemen aufgrund systematischer Fehler oder zufälliger Hardware-Fehler|ISO 26262|Funktionale Sicherheit|
|Nichtadäquates Sollverhalten, unzureichende Performanz oder physikalische Unzulänglichkeiten der Sensorik|ISO 21448|Sicherheit der intendierten Sollfunktion ("SOTIF")|
|Ausfall der Sollfunktion von E/E-Systemen|ISO 26262 (Band 10, Kap. 12)|Sicherheitsrelevante Verfügbarkeit ("SaRA")|
|Bewusste Manipulation des Systems|ISO 21434|Cybersecurity|
|Alterung / Verschleiß|diverse|Maßnahmen gemäß Stand der Technik, z.B. FMEA, DRBFM, Dauererprobung, HALT/HASS usw.|

Eine Vorgehensweise zur systematischen Identifikation der Risikoquellen findet sich in der ISO 12100.

Charakteristisch ist, dass die unterschiedlichen Methoden und Ansätze nicht untereinander abgeglichen sind bzw. auch gar nicht ableichbar sind. Am weitesten ausgearbeitet ist der Bereich der Funktionalen Sicherheit, hierfür gibt es einen mittlerweile etablierten Standard (ISO 26262). Wie die Frage des Safety-Risikos aber domänenübergreifend beantwortet werden kann, fehlt aber heute noch. Heutige Ansätze gehen von einer eher qualitativen Betrachtung auf Basis des jeweiligen „Stands der Technik“ aus.

==== Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren? ====

Als grundlegender Standard zur Beschreibung der Vorgehensweise bei der sicherheitsgerichteten Entwicklung kann die ISO/IEC Guide 51:2014 ("Safety aspects — Guidelines for their inclusion in standards") herangezogen werden, welcher die grundsätzliche Vorgehensweise zur risikobasierten Entwicklung beschreibt und woran sich ISO-/IEC-Normen im Bereich der Safety orientieren:

**Abbildung 1: Vorgehensweise nach ISO/IEC Guide 51:2014**

{{:bbf8df5b2262ee2ebf7b77331f4f96f6.png}}

Diese Vorgehensweise wird in der ISO 26262 für die funktionale Sicherheit von Straßenfahrzeugen folgendermaßen abgebildet: Das Risiko wird als Kombination der Eintrittswahrscheinlichkeit eines Schadens und des entsprechenden Schadensausmaßes definiert. ISO 26262-3 gibt in einem informativen Anhang zur Gefährdungsanalyse und Risikobeurteilung (hazard analysis and risk assessment, HARA) an, dass ein Risiko als Funktion wie folgt beschrieben werden kann: R=F(f,C,S)

Dabei gelten die folgenden Begrifflichkeiten (im Originalwortlaut):

  * f: frequency of occurrence of a hazardous event
  * C: the ability to avoid specific harm or damage through timely reactions of the persons involved (= controllability)
  * S: potential severity of the resulting harm or damage

Die Eintrittshäufigkeit wiederum wird von diversen Faktoren wie folgt beeinflusst: f=E×λ

Dabei gelten die folgenden Begrifflichkeiten (im weitest gehenden Originalwortlaut und –kontext):

  * E: A factor to consider how frequently and for how long individuals find themselves in a situation where the aforementioned hazardous event can occur. In ISO 26262 this is simplified to be a measure of the probability of the operational situation taking place in which the hazardous event can occur (=exposure).
  * λ: Another factor is the failure rate of the item that could lead to the hazardous event. The failure rate is characterised by hazardous hardware random failures and systematic faults that remained in the E/E system. The failure rate of the item is not considered a priori (in the risk assessment) because an unreasonable residual risk is avoided through the implementation of the resulting safety requirements.

Die drei Risikoparameter E, C und S werden im Rahmen der HARA eingestuft und miteinander kombiniert, um den ASIL (Automotive Safety Integrity Level) zu ermitteln, der als Maß zur erforderlichen Risikoreduzierung angesehen werden kann.

Die ISO 21434 zum Thema Cyber-Security (s. auch Ausführungen zu Punkt 3 in Kapitel 2) soll das Risiko als eine Art Ansatz „Feasibility vs. Impact“ betrachten, wobei insgesamt fünf Risikoparameter verwendet werden sollen. Die Risikokalkulation basiert derzeit auf der so genannten „Heat Map“ (s. nachfolgendes Bild aus [1]).

**Abbildung 2: Heatmap zur Risikokalkulation**

{{:bild_1.png?400}}

Das zunehmende Wachstum von Firmware-, Software- und Cloudkomponenten macht moderne Fahrzeuge zu Datenhubs. Gleichzeitig sind die Daten von fahrzeugimmanenten Systemen attraktive Ziele für Cyberattacken. Erfolgreiche Angriffe können, bedingt durch die Interoperabilität von Systemkomponenten innerhalb des Fahrzeugs, unerwünschte Schadensereignisse hervorrufen, die die Safety bzw. die physische Security betreffen. Um den Herausforderungen durch Cyberbedrohungen zu begegnen, wurde im Januar 2021 die UNECE R 155-Regulation (kurz: R 155) für Cybersecurity-Managementsysteme von der United Nations Economic Commission for Europe (UNECE) eingeführt. Die Verordnung Nr. 155 (R 155) ist Teil der UNECE WP.29, welche aus den Verordnungen Nr. 155 (Cybersecurity-betreffend), Nr. 156 (Software-Updates-betreffend) und Nr. 157 (Automated Lane Keeping-betreffend) besteht. Auf der Homepage der[[http://unece.org/sites/default/files/2021-03/R155e.pdf|UNECE.org]]-
 <font 11pt/inherit;;inherit;;inherit>Webseite können die Spezifikationen dieser Regulation mit dem Titel „Proposal for a new UN Regulation on uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system” nachgelesen werden.</font>

Webseite erworben werden. Grundlage der Norm ist die SAE J3061 "Cybersecurity Guidebook for Cyber-Physical Vehicle Systems", welche einen Praxisleitfaden für die Cyber-Sicherheit von Produkten im Fahrzeug über den gesamten Lebenszyklus beinhaltet. Sie kann unter[[https://www.sae.org/standards/content/j3061_202112|der SAE.org]]-Webseite erworben werden. In der SAE J3061 werden die Threat and Operability Analysis, Attack Tree Analysis und das HEAVENS Security Model zur Analyse und Bewertung von Cybersecurity-Risiken vorgeschlagen. Im Gegensatz zur ISO/SAE 21434 wird die SAE J3061 jedoch nicht mehr weiterentwickelt.
 <font 11pt/inherit;;inherit;;inherit>Die ISO/SAE 21434 fasst den Umfang etwas weiter und beschreibt allgemein Anforderungen an die Informationssicherheit (als „Dach“, beschrieben in ISO 27001), die Prozessgüte (als „Träger“, beschrieben in Automotive SPICE Supply Chain & Cybersecurity) und die Produktsicherheit (als „Fundament“, dem Nukleus der SAE J3061 und beschrieben in dem TARA der ISO/SAE 21434). Es gibt eine Vielzahl von Parallelen zur ISO 26262, so sind z.B. beim Cybersecurity Process Overview (SAE J3061, Teil 8) die Phasen des Entwicklungszyklus an die Teile 3-8 der ISO 26262 angelehnt. Sie beinhlaten die Konzeptphase, die Systementwicklung (Hardware bzw. Software), die Produktion und unterstützende (Support-)Prozesse. Sie gilt für Bauteile (elektronische Teile und Software) von in Serie hergestellten Fahrzeugen sowie für Ersatzteile und Zubehör. Sie deckt die Phasen der Entwicklung, der Produktion, des Betriebs, der Wartung und des Recyclings im Lebenszyklus eines Fahrzeugs ab, d.h. OEM müssen die Anforderungen aus der Norm über die gesamte Lieferantenwirkkette nachweisen. Zentrale Punkte der ISO/SAE 21434 ist der Aufbau sowie Betrieb eines Cybersecurity Managementsystems und die Bedrohungsanalyse und Risikobewertung, Threat Analysis and Risk Assessment (TARA) genannt.</font>
 <font 11pt/inherit;;inherit;;inherit>Die ISO/SAE 21434 beschreibt lediglich ein Rahmenwerk. Die konkrete Implementierung liegt beim Anwender. Weil die OEMs zur Homologation gemäß UN R155 für ihre Produkte (Fahrzeuge) das CSMS über die gesamte Lieferantenwirkkette nachzuweisen haben, werden diese von den automobilen Zulieferern Konformität mit den Anforderungen an ein CSMS respektive an die Erstellung einer TARA fordern. Weiterhin werden die Nachweise zur cybersecurity Testumsetzung und die Testergebnisse im Rahmen des CSMS über die Lieferantenwirkkette nachzuweisen sein. Grundsätzlich ist die Homologation OEM-Verantwortung. Es gibt Ausnahmen z. B. Systeme der passiven Sicherheit, wo auch Tier-1 selber Systeme homologieren. Mit der ISO/PAS 5112 wurde ein Standard herausgegeben, in der die Auditierung eines CSMS und die Komponenten des CSMS Auditors definiert sind.</font>

Wie aber OEM den Nachweis der ISO 21434-Konformität von Tier-1 fordern, ist jeweilige OEM-Sache. Die Notwendigkeit zur Durchführung einer TARA seitens der Zulieferer ist sicher. Um die Fahrzeughersteller bei der Vorbereitung auf das Assessment zu unterstützen, hat der Verband der Automobilindustrie([[https://webshop.vda.de/QMC/de/acsms-de_2020|VDA]])
 <font 11pt/inherit;;inherit;;inherit>das Dokument "Automotive Cyber Security Management System Audit" veröffentlicht. Es „definiert den Fragenkatalog und das Bewertungsschema, das bei der Auditierung des CSMS sowohl der OEMs als auch der Vertragspartner zur Anwendung kommen kann“, so die Abstract-Beschreibung der Veröffentlichung.</font>

==== Welche Probleme und Dilemmata sind in Ihrer Disziplin charakteristisch? ====

Die Einstufung der Risikoparameter ist nicht immer trivial und einfach. Da die HARA die Basis für alle weiteren Aktivitäten des automotiven Sicherheitslebenszyklus darstellt, ist hier natürlich besondere Sorgfalt geboten. Insbesondere bei der Einstufung der Exposition kommt es durchaus im Rahmen des Analyseteams zu unterschiedlichen Ansichten, die es dann zusammenzutragen gilt. Fast noch entscheidender ist jedoch, die genaue Definition des Betrachtungsgegenstands, welche als Eingang zur HARA vorliegen muss. Wenn nicht klar ist, was genau untersucht werden soll, wie die entsprechenden Funktionalitäten aussehen und welche Grenzen die Funktion bzw. das System hat, wird eine entsprechende Analyse der Gefährdungen und Risiken nicht zwingend von Erfolg gekrönt sein.

Mit der ISO/SAE 21434 wird die Methodik der Bedrohungsanalyse und des Risikoassessments beschrieben, jedoch stehen die Klassifizierungsvorschläge für die Impact- Kategorien, der Angriffsmachbarkeits- Kategorien und die Risikomatrix als Beispiele im Anhang, was den verbindlichen Charakter und somit einen Standard entgegenspricht. Es ist daher wichtig, dass sich die Vertragspartner beim Austausch von Risiken immer über die angewendeten Definitionen, Methoden und Metriken (zur Impactbewertung, Angriffsmachbarkeitbewertung oder Ableitung einer Risikomatrix) informieren.

Ähnlich dem ASIL, definiert in der ISO 26262, führt die ISO/SAE 21434 einen Cybersecurity assurance level (CAL) ein. Annex E der ISO/SAE 21434 beschreibt den CAL als Ergebnisse aus der Risikomatrix (aus Impactbewertung und Angriffsmachbarkeitseinstufung). Damit ist ein deutlicher Unterschied zum ASIL herauszustellen: Der CAL kann während des Produktlebenszyklus' dynamisch sein. Ein in der Entwicklungsphase mitigiertes Risiko, dessen implementierte Cybersecurity Maßnahme durch Tests als effektiv bewiesen wurde, kann in der Post- Entwicklungsphase durch eine entdeckte Schwachstelle wieder zu einer Erhöhung des Risikos und damit des CALs führen. Erst durch Spezifikation, Umsetzung und Tests eines Fixes der Schwachstelle wird das Risiko und damit der CAL reduziert. Aufgrund des erforderlichen Engineering Supports Post- SOP (Start- of- Production) bis über EOP (End- of- Production) hinaus, ist sehr empfehlenswert, dass die Vertragspartner ein Service- Level Agreements für den Supportzeitraum, den Kommunikationsplan für die Cybersecurity Incidences, den zeitlichen Umfang und der Abrechnung der Engineersleistungen vereinbaren. Insbesondere kryptographische Algorithmen und Schlüssellängen sind nur zeitlich begrenzt. Der NIST SP 800-57 gibt eine Hilfestellung zur Anwendung der richtigen kryptographischen Verfahren und Schlüssellängen über den Produktlebenszykluszeitraum.

==== Wie werden unscharfe oder unsichere Risikobeiträge behandelt? ====

Die unter Punkt 1 beschriebenen Risikoparameter sind bereits als unscharf anzusehen. Deren Klassifizierung erfolgt mit Hilfe verschiedener Abstufungen (S0 bis S3, E0 bis E4, C0 bis C3). Die Durchführung der HARA erfolgt im Team mit dem erforderlichen Expertenwissen.

===== 2 Durchführung von Risikoanalysen =====
 <font inherit/inherit;;inherit;;rgb(241, 196, 15)>CKGE_TMP_i Tabellen neu einfügen (als Bild) CKGE_TMP_i</font>

Im Bereich der Funktionalen Sicherheit im Automotive-Bereich führen wir „Gefährdungsanalysen und Risikobewertungen“ (G&R) gemäß ISO 26262 durch. Im normativen Teil der ISO 26262 ist diese Methode eher als qualitativ, allenfalls semi-quantitativ anzusehen, da die Parameter Exposure E, Controllability C und Severity S zwar in Klassen (E0…E4, C0…C3, S0…S3) eingeteilt werden, diesen Klassen aber keine quantitativen Definitionen zu Grunde liegen, wie die nachfolgenden Tabellen zeigen:

**Tabelle 5: Definition der Severity nach ISO 26262-3:2018**

{{:58c727cb621016347600557810989bdf.png}}

**Tabelle 6: Definition der Exposure nach ISO 26262-3:2018**

{{:534b10a5473e2c110f0b889c18b53da0.png}}

Der VDA 702 Situationskatalog gibt eine Hilfestellung bei der Klassifizierung von Fahrsituationen und Ermittlung des E-Parameters.

**Tabelle 7: Definition der Contollability nach ISO 26262-3:2018**

{{:f80393296211a112ad07b9bfac7677ac.png}}

Im informativen Teil der ISO 26262 sind hier quantitative Vorschläge gemacht, dennoch ist die Methodik stark subjektiv.

Ergänzend hierzu wird in der ISO 21448 "Safety of the intended functionality" die Frage addressiert, ob eine Funktionalität bei Vorliegen physikalischer Unzulänglichkeiten der Messdatenerfassung und -auswertung als ausreichend sicher (safe) angesehen werden kann. Hier wird jedoch keine neue Risikobewertungsbewertungmethodik eingeführt, sondern als Ergebnis ergibt sich lediglich "SOTIF-relevant ja/nein" und das verbleibende Restrisiko wird über die Erfüllung von "acceptance criteria" definiert. Da dieser Standard jedoch noch relativ neu ist (Veröffentlichung 2022), liegen noch nicht ausreichend Erfahrungen in seiner Anwendung vor.

Im zukünftigen Standard ISO/PAS 8800 soll die Sicherheit von AI addressiert werden. Die Sicherheitsanforderungen ergeben sich hierbei aus der HARA gemäß ISO 26262 aus dem Systemkontext, es wird keine explizite Risikobewertung (Ausgangsrisiko) des AI-Systems vorgenommen. In einem "Safety Assurance Case" wird bewertet, warum das verbleibende Restrisiko ausreichend gering ist, allerdings geschieht dies sehr qualitativ und nicht quantitativ. Da sich dieser Standard momentan noch in der Erstellung befindet (Veröffentlichung voraussichtlich Ende 2023), wird man Erfahrungen bzgl. seiner Anwendbarkeit erst in den nächsten Jahren sammeln können.

Wechselwirkungen zwischen Safety und Security treten hier nicht Erscheinung. Zum einen adressiert die ISO 26262 lediglich systematische Fehler und zufällige Hardware-Fehler, so dass bewusste Manipulationen als Safety-„Feindbild“ out of scope sind. Zum anderen fehlt uns heute noch ein methodischer Ansatz, um das Safety-Risiko einer bewussten Manipulation bewerten zu können. Die ISO 26262 geht implizit von einer statistischen Unabhängigkeit zwischen Fehlerauftreten und relevanter Fahrsituation aus, was aber bei einer bewussten Manipulation nicht a priori gegeben ist. Daher kann die Methodik der ISO 26262 nicht ohne Weiteres auf die bewusste Manipulation als Safety-Risiko übertragen werden. Ein Ansatz, um Safety- und Security-Risiken miteinander abzugleichen, besteht darin, relevante Security-Angriffsvektoren mit (aus der G&R bekannten) Safety-Goals abzugleichen. Dies geschieht iterativ während der Entwicklung des Produktdesigns.
 <font 14px/inherit;;inherit;;inherit>Im Bereich der Automotive Cybersecurity definiert die ISO/SAE 21434 die Durchführung einer Bedrohungsanalyse und eines Risikoassessments (TARA). Die Schritte zur Durchführung eines TARA sind nachfolgend aufgeführt:</font>
 <font 14px/inherit;;inherit;;inherit>Der normative Teil legt die folgenden Methoden fest:Asset Identifikation (section 8.3), Bedrohungsszenarien identifizieren (section 8.4), Impact- Klassifikation (section 8.5), Angriffspfadanalyse (section 8.6) , Angriffsmachbarkeit- Klassifizierung (section 8.7), Risikobestimmung (section 8.8) und Festlegung der Risikobehandlung (section 8.9).</font>
 <font 14px/inherit;;inherit;;inherit>Für die Impact- Klassifizierung definiert der normative Teil, dass die Schadensfälle hinsichtlich Safety, Financial, Operational und Privacy in den Einstufungen negligible, moderate, major und severe bewertet werden. Der Anhang F liefert Beispiele für die Impact- Klassifizierung der einzelnen Schadenskategorien Safety, Financial, Operational und Privacy. Die Safety Impact- Klassifizierung ist in Anlehnung an die ISO 26262- 3:2018 und die Privacy Impact- Klassifizierung verweist für die Personally Identifiable Information (PII) auf die ISO/ IEC 29100.</font>

|

**Tabelle 8:**** I****mpact-Kategorisierung nach ISO/SAE 21434**

{{:80273e7dbef47145e5c64c166e60c4dd.png?864x737}}
 <font 12.0pt/inherit;;inherit;;inherit>Für die Angriffsmachbarkeit- Klassifizierung stellt der Anhang G Beispiele für die Einstufung der Angriffe hinsichtlich ihrer Elapsed time, specialist expertice, Knowledge of the item or component, window of opportunity und equipment bereit.</font>

**Tabelle 9:**** Methode zur Attack Feasibility-Klassifikation**** nach ISO/SAE 21434**{{:6bfbbd21f9a273a19916e30ed7496f9d.png?731x264}}

Der normative Teil definiert, dass die Attack- Machbarkeit in very low, low, medium und high einzustufen ist. Anhang G gibt ein Beispiel, wie die aus der oberen Tabelle aufsummierten Werte der einzelnen Kategorien zur Bewertung des Angriffs zu den Einstufungen very low, low, medium und high zu gewiesen werden können.

**Tabelle 10:**** Attack Feasability-Stufen**** nach ISO/SAE 21434**

{{:6fd92c968c6f1ff320969ab2c9595d8a.png?431x192}}

Neben dem oben beschriebenen Angriffspotenzialansatz, stellt der Anhang G die Ansätze der Angriffs- Machbarkeiteinstufung mittels CVSS und Angriffsvektor vor.

Mit den ermittelten Impact und Angriffs- Machbarkeiteinstufungen wird das Angriffsrisiko ermittelt. Anhang H gibt ein Vorschlag für die Risikobestimmung. Zur anschließenden Angriffsbehandlung beschreibt der normative Teil folgende Auswahlmöglichkeiten: Risikovermeidung (Entfernung der Risikoquelle), Reduzierung, Risikoteilung (mit Vertragspartner OEM oder Sub- Lieferanten; Versicherung) und das Risiko beibehalten/ akzeptieren.

**Tabelle 11:**** Matrix zur Bestimmung des Risk Values**** nach ISO/SAE 21434**

{{:a34e12e44789caa7d38b1d4f0f0cc1b9.png?520x212}}

Die UN Regulierung R155 liefert im Annex 5 eine umfangreiche Liste von Bedrohungen und entsprechenden Gegenmaßnahmen. Für Fahrzeugprojekte, welcher der UN R 155 zur Typenzulassung anzuwenden haben, empfiehlt sich der Abgleich der betrachteten Angriffspfade mit der Liste aus Annex 5. Mit den Gegenmaßnahmen wird ein Einstieg für das Cybersecurity Concept geliefert.

**Tabelle 12:**** Liste von High Level Vulnerabilities und Threats**** nach ISO/SAE 21434**

{{:2597b08bdf78060564d0a120f2cd3349.png?603x363}}


==== Wie werden Risikoanalysen in Ihrer Disziplin durchgeführt? (qualitativ, quantitativ, semi-quantitativ, nach Norm oder Richtlinie) ====

Im Rahmen der Funktionalen Sicherheit kommen generell qualitative Risikoanalysen zur Bestimmung des erforderlichen ASIL/SIL/PL zum Einsatz (s. ISO 26262-3, IEC 61508-2, ISO 13849-1) (s. hierzu auch Ausführungen oben). Im Anschluss daran werden in den erforderlichen Domänen (System, Hardware, Software) ggf. weitere Analysen erforderlich (z.B. induktiv (wie FMEA) und/oder deduktiv (wie FTA), welche sowohl qualitativ, semi-quantitativ als auch quantitativ eingesetzt werden. Diese Analysen haben allerdings weniger das Risiko im Fokus als eher die Untersuchung von möglichen Fehlern (systematisch und zufällig). Im Rahmen der Cybersecurity kommen qualitative Risikoanalysen zur Bestimmung der Cybersecurity Assurance Level (CAL) zum Einsatz (siehe ISO/SAE 21434; siehe Ausführungen oben).

==== Welche Metriken kommen hierbei zum Einsatz? ====

// <font inherit/inherit;;inherit;;#f1c40f>Ergänzen: Metriken bei Hardware (ISO 26262): FMEDA, FTA, PMHF, …</font> //

Wie oben erwähnt, werden die drei Risikoparameter E, C und S im Rahmen der HARA eingestuft und miteinander kombiniert, um den ASIL (Automotive Safety Integrity Level) zu ermitteln, der als Maß zur erforderlichen Risikoreduzierung angesehen werden kann. In der Cybersecurity werden einerseits Bedrohungsanteile und andererseits Impactanteile miteinander kombiniert, um den CAL zu bestimmen. Eine Möglichkeit, den Bedrohungsanteil – die sog. Attack Feasability – zu bestimmen, ist die Anwendung der Common Vulnerability Scoring System ([[https://www.first.org/cvss/|CVSS]]) Metriken. Mit dem CAL verbunden sind Anforderungen an die Entwicklung. Nach der Risikobewertung können Risk Treatment Decisions (accept, remove, sharing, reduction) durchgeführt werden. Die Option „Reduction“ verfolgt das Ziel, den CAL zu reduzieren.

==== Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Ihrer Disziplin in Erscheinung und wie werden diese behandelt? ====

Die Behandlung von Security-Themen bzw. die entsprechende Kombination mit Safety-Aspekten befindet sich aktuell in Abstimmung in den entsprechenden Expertenkreisen. Der Standard ISO 21434 „Road Vehicles – Cyber Security Engineering“ soll u.a. hierzu Klärung bringen. An der Normenentwicklung beteiligt sind über 80 weltweit vertretene Unternehmen von OEMs, Zulieferern, Forschungseinrichtungen und Aufsichtsbehörden. Darin soll die Security in den gesamten Produktlebenszyklus integriert werden. Der Standard soll dann ein Rahmenwerk bieten, um über einen risikoorientierten Ansatz entsprechende Prozesse in Unternehmen zu etablieren. Eine simple Erweiterung der Safety-Aktivitäten um Security-Aspekte wird als nicht zielführend und sinnvoll angesehen, da beide Komplexe zwar ähnlich, aber doch einzigartig sind. Weiterhin soll die ISO 21434 ein einheitliches Vokabular zu den relevanten Begrifflichkeiten bieten, welches in der gesamten Supply Chain einsatzbar sein soll. Die in dem Standard enthaltenen Abschnitte beschäftigen sich neben dem Management der Cyber-Security und dem Risikomanagement auch mit der Konzept- und der Produktentwicklungsphase sowie den weiteren Phasen Produktion, Betrieb und Wartung. Der Standard orientiert sich folglich ebenfalls an einem Lebenszyklusmodell, der sehr ähnlich zu dem der ISO 26262 scheint.

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

// <font inherit/inherit;;inherit;;#f1c40f>Vorschlag zur Zusammenführung / Handshake Safety-Security (z.B. Abgleich Hazards TARA-HARA); Quellen: J3061, …</font> //

Safety und Cybersecurity Engineering haben gemeinsame Schnittmengen in Arbeitsschritten und Arbeitspaketen. Auf der System-, Software- und Hardwareebene können Safety und Cybersecurity Anforderungen Teil einer gemeinsamen Spezifikation sein. Zudem können existierende Architekturen um Cybersecurity Elemente erweitert werden. Gleiche Herangehensweise gilt für die funktionalen Testspezifikationen, welche um die Cybersecurity Anteile erweitert werden können.

**Abbildung 3: Schnittmenge von Safety und Cybersecurity**

{{:3b7488e37841b8a22a417603c0d891b0.png}}

Andererseits ist die Funktionale Sicherheit nur eine Untermenge der Cybersecurity Betrachtung. Die TARA berücksichtigt den Impact für Safety, aber auch für den betrieblichen Einfluss, finanziellen Schaden und Dataschutzverletzung.

**Abbildung 4: Safety als Untermenge der Cybersecurity**

{{:4422edfcac1cc42649ae062bfb7b667e.png}}

Der Abgleich der Impactbewertungen kann im Rahmen eines TARA- HARA cross check erfolgen. Der Safety Manager wird damit zur Review Stakeholder für die TARA. Die Hazards werden Teil der Schadensszenariendefinition in der TARA. Theoretisch können mit den Schadensszenarien aus der TARA auch neue Hazards abgeleitet werden. Abschnitt 2 führte die Impactklassifizierungen in der TARA ein. Für Safety Impact der TARA schlägt die ISO 21434 die Severity- Einstufung aus der ISO26262 vor. Da diese jedoch keinen bindenden Charakter hat, können auch weitere Definitionen für die Safety- Impactklassifizierung erfolgen, z.b. eine Kombination von Severity (ISO 26262) und Controllability (ISO26262):

**Tabelle 13: Mapping von Severity und Controllability (ISO 26262) **

{{:97fd074ace5131785416e5c6af65d02a.png}}

Abschließend ist Hervorzuheben, dass die TARA in jeder Produktentwicklungsphase aktualisiert werden kann. Neue Schwachstellen sind in der TARA zu bewerten und geeignete Maßnahmen sind für das Restrisiko abzuleiten.

Eine Quantifizierung des Safety-Risikos fehlt komplett: Zum einen gibt es keinen legislativen „Grenzwert“ (bzw. dieser liegt bei „Null“, siehe ProdSG §3(2)), zum anderen gibt es keine Felddaten, auf deren Basis eine Berechnung des Risikos durchgeführt werden könnte. Quantitative Betrachtungen, die man heute anstellt, sind allenfalls ein „Testende- bzw. Freigabekriterium“, aber kein „Akzeptanzkriterium“ im Feld. Diese quantitativen Freigabekriterien sind aber – auf Grund der unterschiedlichen Datenquellen und –güten – stark domänenabhängig. Da diese gemeinsame Basis fehlt, ist ein Zusammenführen der Domänen heute nicht möglich.

Die Funktionale Sicherheit ist ein Themenfeld, welches in vielen Industriezweigen und Domänen von hoher Relevanz ist. In fast allen uns bekannten Domänen werden das Risiko und das damit zusammenhängende Sicherheitsintegritätslevel auf ähnliche Art und Weise bestimmt und bewertet. Manche Domänen schreiben direkt ein Verfahren vor, wie z.B. die Automobilindustrie. Andere Domänen lassen den entsprechenden Verantwortlichen mehr Freiraum in der Wahl der geeigneten Methode, wie z.B. die IEC 61508 (darin werden u.a. HAZOP, Risikomatrix oder Risikograph angeführt). Generell unterscheiden sich die Risikobegriffe bei der Safety und der Security durch den Risikoparameter des Schadens. Bzgl. der Safety geht es dabei primär um die mögliche Gefährdung von Leib und Leben beteiligter Personen (zusätzlich sind auch Umwelt- und Sachschäden in manchen Domänen relevant). Im Bereich Security spielen bei der Schadensdefinition zusätzlich noch finanzielle und imageschädigende Aspekte eine erhebliche Rolle.

Im Automobilbereich wird das Umfeld der Produktentwicklung, d.h. die Erfüllung eines Informationssicherheitsstandards zertifiziert. Der VDA Information Security Assessment Fragenkatalog hat sich als Branchenstandard etabliert und ist die Grundlage für das Branchenmodell TISAX ([[https://enx.com/en-US/TISAX/|Link TISAX]]), über das eine unternehmensübergreifende Anerkennung von Information Security Assessment-Ergebnissen gewährleistet wird. Der VDA hat die ENX Association als neutrale Instanz für die Steuerung und Betreuung des TISAX-Modells hinzugezogen.

===== Lösungsansätze =====

Nachfolgend werden einige Lösungsansätze zu verschiedenen Herausforderungen aufgeführt, die mit dem automotiven Spielfeld der Safety und Security in Verbindung stehen. Diese können z.B. von nationalen und internationalen Konsortien oder Initiativen stammen oder auch aus öffentlichen Projekten. Die Liste erhebt dabei keinen Anspruch auf Vollständigkeit, sondern soll vielmehr als Anhaltspunkt dienen.

// <font inherit/inherit;;inherit;;#f1c40f>gerne noch weitere ergänzen</font> //

**Tabelle 14: Lösungsansätze**

| <font 11pt/Calibri,sans-serif;;black;;inherit>Thema / Konzept / Projekt</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Jahr / Zeitraum</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Anmerkungen</font>    |
| <font 11pt/Calibri,sans-serif;;black;;inherit>Connected Vehicle Systems Alliance (COVESA)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2009 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>COVESA ist eine offene, kollaborative Allianz, die sich auf die Entwicklung offener Normen und Technologien für vernetzte Fahrzeuge konzentriert, welche inzwischen einen immer größeren Anteil der Fahrzeuge auf der Straße ausmachen.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>European Union Agency for Cybersecurity (ENISA)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2004 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Die Agentur der Europäischen Union für Cybersicherheit (ENISA) ist eine Einheit, die ein hohes Niveaus in der Cybersicherheit in der ganzen EU erreichen möchte.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>SoQrates</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2003 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>SoQrates ist eine Initiative, die zum Ziel hat, ASPICE in die deutsche (Automobil)Industrie hineinzutragen.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>ENX Association</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2000 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Die ENX Association ist ein Zusammenschluss europäischer Automobilhersteller, -Zulieferer und Verbände und hat zum Ziel, den Informationsaustausch zu fördern und u.a. Anforderungen an die unternehmensübergreifende IT-Sicherheit zu definieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>E-Gas-Überwachungskonzept</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2013</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Ziel des standardisierten 3-Ebenen-Sicherheitskonzepts eines Arbeitskreises mehrerer deutscher OEMs in Zusammenarbeit mit Steuergeräteherstellern war es, ein Überwachungskonzept zu entwickeln, in dem sowohl Funktion als auch Funktionsüberwachung und das Steuergerät selbst permanent überwacht werden.</font>    |
| <font 11pt/Calibri,sans-serif;;black;;inherit>AUTOSAR</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2003 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Weltweite Entwicklungspartnerschaft verschiedener Automobilhersteller, Zulieferfirmen und Unternehmen aus der Elektronik-, Software- und Halbleiterindustrie mit dem Ziel der Entwicklung und Etablierung einer standardisierten Softwarearchitektur für Steuergeräte. Seit 2003 wurden bisher vier Hauptversionen der Classic Plattform und eine Version von Acceptance Tests veröffentlicht.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>HIS \\
(Herstellerinitiative Software)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2001 - 2007</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Dieser Zusammenschluss fünf deutscher OEMs verfolgte das Ziel, harmonisierte Schnittstellen (Produkt und Prozess) zu definieren, um den Zulieferer-Aufwand bei der Anpassung an unterschiedliche OEM-Anforderungen zu reduzieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>EVITA \\
(E-Safety Vehicle Intrusion Protected Applications)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2008 - 2001 (Projektdauer)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Projektziel war die Entwicklung und Verifikation einer Architektur für automobile Bordnetze, in welcher sicherheitsrelevante Komponenten vor Manipulation und sensible Daten vor Kompromittierung geschützt sind.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>SHE, SHE \\
(Secure Hardware Extension)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2008</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Es handelt sich dabei um eine On-Chip-Erweiterung, mit der die Kontrolle über kryptografische Operationen und Schlüssel von der SW- in die HW-Domäne verlagert wird, um diese Schlüssel vor Software-Angriffen zu schützen. Die SHE-Erweiterung wurde vom HIS-Konsortium definiert und lässt sich als abgeschlossener Bereich auf jdem beliebigen Mikrocontroller implementieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>Car Connectivity Consortium (CCC)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2011 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Die branchenübergreifende Organisation mit mehr als hundert Mitgliedsunternehmen will die Technologien für Verbindungslösungen Smartphone-zu-Fahrzeug vorantreiben. Ziel ist es die Schnittstellen zwischen Smartphones und Fahrzeugen zu standardisieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>Object Management Group (OMG)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>1989 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Das internationale und mitgliederorientierte Konsortium bietet ein neutrales Forum, um Normen und Standards zu entwickeln, welche die Einführung und Innovation von Spitzentechnologien in allen Branchen weltweit fördern. Zu den bekanntesten Entwicklungen der OMG gehört die Unified Modeling Language UML), welche die Modellierung und Dokumentation von objektorientierten Systemen in einer normierten Syntax erlaubt. Auch dessen Erweiterung SysML sowie das Austauschformat für Anforderungen ReqIF wurden von der OMG entwickelt.</font>    |
| ::: | ::: | ::: |

===== Weitere Quellen =====

  - Harman Hunjan (Renesas): ISO/SAE 21434 Automotive Cybersecurity Engineering, 4.7.2018
  - Stefan Kriso, Jürgen Klarmann, Claudia Loderhose, Franziska Wiemer, Carsten Gebauer, Simon Burton, Markus Ihle: Sicher unterwegs in einer manipulierten Umwelt: Eine Frage der Safety oder Security – oder von beidem?, Embedded Software Engineering Kongress, Sindelfingen 03.-07.12.2018
  - Stefan Kriso, Markus Ihle: Automotive Security im Kontext der Funktionalen Sicherheit (ISO 26262), 31. VDI/VW Gemeinschaftstagung Automotive Security, Wolfsburg, 21.-22.10.2015
  - Benjamin Glas, Carsten Gebauer, Jochen Hänger, Andreas Heyl, Jürgen Klarmann, Stefan Kriso, Priyamvadha Vembar, Philipp Wörz: Automotive Safety and Security Integration Challenges, Automotive Safety & Security 2015, Stuttgart, 21.-22.04.2015, Lecture Notes in Informatics (LNI) - Proceedings, Volume P-240 (ISBN 978-3-88579-634-3), S. 13-28
  - Stefan Kriso: Die Grenzen der ISO 26262 – Professioneller Umgang mit Lücken in der Sicherheitsnorm, Embedded Software Engineering Kongress, Sindelfingen, 01.-05.12.2014


==== Wie werden Risikoanalysen in Ihrer Disziplin durchgeführt? (qualitativ, quantitativ, semi-quantitativ, nach Norm oder Richtlinie) ====

Im Rahmen der Funktionalen Sicherheit kommen generell qualitative Risikoanalysen zur Bestimmung des erforderlichen ASIL/SIL/PL zum Einsatz (s. ISO 26262-3, IEC 61508-2, ISO 13849-1) (s. hierzu auch Ausführungen oben). Im Anschluss daran werden in den erforderlichen Domänen (System, Hardware, Software) ggf. weitere Analysen erforderlich (z.B. induktiv (wie FMEA) und/oder deduktiv (wie FTA), welche sowohl qualitativ, semi-quantitativ als auch quantitativ eingesetzt werden. Diese Analysen haben allerdings weniger das Risiko im Fokus als eher die Untersuchung von möglichen Fehlern (systematisch und zufällig). Im Rahmen der Cybersecurity kommen qualitative Risikoanalysen zur Bestimmung der Cybersecurity Assurance Level (CAL) zum Einsatz (siehe ISO/SAE 21434; siehe Ausführungen oben).

==== Welche Metriken kommen hierbei zum Einsatz? ====

// <font inherit/inherit;;inherit;;#f1c40f>Ergänzen: Metriken bei Hardware (ISO 26262): FMEDA, FTA, PMHF, …</font> //

Wie oben erwähnt, werden die drei Risikoparameter E, C und S im Rahmen der HARA eingestuft und miteinander kombiniert, um den ASIL (Automotive Safety Integrity Level) zu ermitteln, der als Maß zur erforderlichen Risikoreduzierung angesehen werden kann. In der Cybersecurity werden einerseits Bedrohungsanteile und andererseits Impactanteile miteinander kombiniert, um den CAL zu bestimmen. Eine Möglichkeit, den Bedrohungsanteil – die sog. Attack Feasability – zu bestimmen, ist die Anwendung der Common Vulnerability Scoring System ([[https://www.first.org/cvss/|CVSS]]) Metriken. Mit dem CAL verbunden sind Anforderungen an die Entwicklung. Nach der Risikobewertung können Risk Treatment Decisions (accept, remove, sharing, reduction) durchgeführt werden. Die Option „Reduction“ verfolgt das Ziel, den CAL zu reduzieren.

==== Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Ihrer Disziplin in Erscheinung und wie werden diese behandelt? ====

Die Behandlung von Security-Themen bzw. die entsprechende Kombination mit Safety-Aspekten befindet sich aktuell in Abstimmung in den entsprechenden Expertenkreisen. Der Standard ISO 21434 „Road Vehicles – Cyber Security Engineering“ soll u.a. hierzu Klärung bringen. An der Normenentwicklung beteiligt sind über 80 weltweit vertretene Unternehmen von OEMs, Zulieferern, Forschungseinrichtungen und Aufsichtsbehörden. Darin soll die Security in den gesamten Produktlebenszyklus integriert werden. Der Standard soll dann ein Rahmenwerk bieten, um über einen risikoorientierten Ansatz entsprechende Prozesse in Unternehmen zu etablieren. Eine simple Erweiterung der Safety-Aktivitäten um Security-Aspekte wird als nicht zielführend und sinnvoll angesehen, da beide Komplexe zwar ähnlich, aber doch einzigartig sind. Weiterhin soll die ISO 21434 ein einheitliches Vokabular zu den relevanten Begrifflichkeiten bieten, welches in der gesamten Supply Chain einsatzbar sein soll. Die in dem Standard enthaltenen Abschnitte beschäftigen sich neben dem Management der Cyber-Security und dem Risikomanagement auch mit der Konzept- und der Produktentwicklungsphase sowie den weiteren Phasen Produktion, Betrieb und Wartung. Der Standard orientiert sich folglich ebenfalls an einem Lebenszyklusmodell, der sehr ähnlich zu dem der ISO 26262 scheint.

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

// <font inherit/inherit;;inherit;;#f1c40f>Vorschlag zur Zusammenführung / Handshake Safety-Security (z.B. Abgleich Hazards TARA-HARA); Quellen: J3061, …</font> //

Safety und Cybersecurity Engineering haben gemeinsame Schnittmengen in Arbeitsschritten und Arbeitspaketen. Auf der System-, Software- und Hardwareebene können Safety und Cybersecurity Anforderungen Teil einer gemeinsamen Spezifikation sein. Zudem können existierende Architekturen um Cybersecurity Elemente erweitert werden. Gleiche Herangehensweise gilt für die funktionalen Testspezifikationen, welche um die Cybersecurity Anteile erweitert werden können.

**Abbildung 3: Schnittmenge von Safety und Cybersecurity**

{{:3b7488e37841b8a22a417603c0d891b0.png}}

Andererseits ist die Funktionale Sicherheit nur eine Untermenge der Cybersecurity Betrachtung. Die TARA berücksichtigt den Impact für Safety, aber auch für den betrieblichen Einfluss, finanziellen Schaden und Dataschutzverletzung.

**Abbildung 4: Safety als Untermenge der Cybersecurity**

{{:4422edfcac1cc42649ae062bfb7b667e.png}}

Der Abgleich der Impactbewertungen kann im Rahmen eines TARA- HARA cross check erfolgen. Der Safety Manager wird damit zur Review Stakeholder für die TARA. Die Hazards werden Teil der Schadensszenariendefinition in der TARA. Theoretisch können mit den Schadensszenarien aus der TARA auch neue Hazards abgeleitet werden. Abschnitt 2 führte die Impactklassifizierungen in der TARA ein. Für Safety Impact der TARA schlägt die ISO 21434 die Severity- Einstufung aus der ISO26262 vor. Da diese jedoch keinen bindenden Charakter hat, können auch weitere Definitionen für die Safety- Impactklassifizierung erfolgen, z.b. eine Kombination von Severity (ISO 26262) und Controllability (ISO26262):

**Tabelle 13: Mapping von Severity und Controllability (ISO 26262) **

{{:97fd074ace5131785416e5c6af65d02a.png}}

Abschließend ist Hervorzuheben, dass die TARA in jeder Produktentwicklungsphase aktualisiert werden kann. Neue Schwachstellen sind in der TARA zu bewerten und geeignete Maßnahmen sind für das Restrisiko abzuleiten.

Eine Quantifizierung des Safety-Risikos fehlt komplett: Zum einen gibt es keinen legislativen „Grenzwert“ (bzw. dieser liegt bei „Null“, siehe ProdSG §3(2)), zum anderen gibt es keine Felddaten, auf deren Basis eine Berechnung des Risikos durchgeführt werden könnte. Quantitative Betrachtungen, die man heute anstellt, sind allenfalls ein „Testende- bzw. Freigabekriterium“, aber kein „Akzeptanzkriterium“ im Feld. Diese quantitativen Freigabekriterien sind aber – auf Grund der unterschiedlichen Datenquellen und –güten – stark domänenabhängig. Da diese gemeinsame Basis fehlt, ist ein Zusammenführen der Domänen heute nicht möglich.

Die Funktionale Sicherheit ist ein Themenfeld, welches in vielen Industriezweigen und Domänen von hoher Relevanz ist. In fast allen uns bekannten Domänen werden das Risiko und das damit zusammenhängende Sicherheitsintegritätslevel auf ähnliche Art und Weise bestimmt und bewertet. Manche Domänen schreiben direkt ein Verfahren vor, wie z.B. die Automobilindustrie. Andere Domänen lassen den entsprechenden Verantwortlichen mehr Freiraum in der Wahl der geeigneten Methode, wie z.B. die IEC 61508 (darin werden u.a. HAZOP, Risikomatrix oder Risikograph angeführt). Generell unterscheiden sich die Risikobegriffe bei der Safety und der Security durch den Risikoparameter des Schadens. Bzgl. der Safety geht es dabei primär um die mögliche Gefährdung von Leib und Leben beteiligter Personen (zusätzlich sind auch Umwelt- und Sachschäden in manchen Domänen relevant). Im Bereich Security spielen bei der Schadensdefinition zusätzlich noch finanzielle und imageschädigende Aspekte eine erhebliche Rolle.

Im Automobilbereich wird das Umfeld der Produktentwicklung, d.h. die Erfüllung eines Informationssicherheitsstandards zertifiziert. Der VDA Information Security Assessment Fragenkatalog hat sich als Branchenstandard etabliert und ist die Grundlage für das Branchenmodell TISAX ([[https://enx.com/en-US/TISAX/|Link TISAX]]), über das eine unternehmensübergreifende Anerkennung von Information Security Assessment-Ergebnissen gewährleistet wird. Der VDA hat die ENX Association als neutrale Instanz für die Steuerung und Betreuung des TISAX-Modells hinzugezogen.

===== Lösungsansätze =====

Nachfolgend werden einige Lösungsansätze zu verschiedenen Herausforderungen aufgeführt, die mit dem automotiven Spielfeld der Safety und Security in Verbindung stehen. Diese können z.B. von nationalen und internationalen Konsortien oder Initiativen stammen oder auch aus öffentlichen Projekten. Die Liste erhebt dabei keinen Anspruch auf Vollständigkeit, sondern soll vielmehr als Anhaltspunkt dienen.

// <font inherit/inherit;;inherit;;#f1c40f>gerne noch weitere ergänzen</font> //

**Tabelle 14: Lösungsansätze**

| <font 11pt/Calibri,sans-serif;;black;;inherit>Thema / Konzept / Projekt</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Jahr / Zeitraum</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Anmerkungen</font>    |
| <font 11pt/Calibri,sans-serif;;black;;inherit>Connected Vehicle Systems Alliance (COVESA)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2009 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>COVESA ist eine offene, kollaborative Allianz, die sich auf die Entwicklung offener Normen und Technologien für vernetzte Fahrzeuge konzentriert, welche inzwischen einen immer größeren Anteil der Fahrzeuge auf der Straße ausmachen.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>European Union Agency for Cybersecurity (ENISA)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2004 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Die Agentur der Europäischen Union für Cybersicherheit (ENISA) ist eine Einheit, die ein hohes Niveaus in der Cybersicherheit in der ganzen EU erreichen möchte.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>SoQrates</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2003 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>SoQrates ist eine Initiative, die zum Ziel hat, ASPICE in die deutsche (Automobil)Industrie hineinzutragen.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>ENX Association</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2000 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Die ENX Association ist ein Zusammenschluss europäischer Automobilhersteller, -Zulieferer und Verbände und hat zum Ziel, den Informationsaustausch zu fördern und u.a. Anforderungen an die unternehmensübergreifende IT-Sicherheit zu definieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>E-Gas-Überwachungskonzept</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2013</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Ziel des standardisierten 3-Ebenen-Sicherheitskonzepts eines Arbeitskreises mehrerer deutscher OEMs in Zusammenarbeit mit Steuergeräteherstellern war es, ein Überwachungskonzept zu entwickeln, in dem sowohl Funktion als auch Funktionsüberwachung und das Steuergerät selbst permanent überwacht werden.</font>    |
| <font 11pt/Calibri,sans-serif;;black;;inherit>AUTOSAR</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2003 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Weltweite Entwicklungspartnerschaft verschiedener Automobilhersteller, Zulieferfirmen und Unternehmen aus der Elektronik-, Software- und Halbleiterindustrie mit dem Ziel der Entwicklung und Etablierung einer standardisierten Softwarearchitektur für Steuergeräte. Seit 2003 wurden bisher vier Hauptversionen der Classic Plattform und eine Version von Acceptance Tests veröffentlicht.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>HIS \\
(Herstellerinitiative Software)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2001 - 2007</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Dieser Zusammenschluss fünf deutscher OEMs verfolgte das Ziel, harmonisierte Schnittstellen (Produkt und Prozess) zu definieren, um den Zulieferer-Aufwand bei der Anpassung an unterschiedliche OEM-Anforderungen zu reduzieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>EVITA \\
(E-Safety Vehicle Intrusion Protected Applications)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2008 - 2001 (Projektdauer)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Projektziel war die Entwicklung und Verifikation einer Architektur für automobile Bordnetze, in welcher sicherheitsrelevante Komponenten vor Manipulation und sensible Daten vor Kompromittierung geschützt sind.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>SHE, SHE+ \\
(Secure Hardware Extension)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2008</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Es handelt sich dabei um eine On-Chip-Erweiterung, mit der die Kontrolle über kryptografische Operationen und Schlüssel von der SW- in die HW-Domäne verlagert wird, um diese Schlüssel vor Software-Angriffen zu schützen. Die SHE-Erweiterung wurde vom HIS-Konsortium definiert und lässt sich als abgeschlossener Bereich auf jdem beliebigen Mikrocontroller implementieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>Car Connectivity Consortium (CCC)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>2011 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Die branchenübergreifende Organisation mit mehr als hundert Mitgliedsunternehmen will die Technologien für Verbindungslösungen Smartphone-zu-Fahrzeug vorantreiben. Ziel ist es die Schnittstellen zwischen Smartphones und Fahrzeugen zu standardisieren.</font>    |
| ::: | ::: | ::: |
| <font 11pt/Calibri,sans-serif;;black;;inherit>Object Management Group (OMG)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>1989 (Gründung)</font>    | <font 11pt/Calibri,sans-serif;;black;;inherit>Das internationale und mitgliederorientierte Konsortium bietet ein neutrales Forum, um Normen und Standards zu entwickeln, welche die Einführung und Innovation von Spitzentechnologien in allen Branchen weltweit fördern. Zu den bekanntesten Entwicklungen der OMG gehört die Unified Modeling Language UML), welche die Modellierung und Dokumentation von objektorientierten Systemen in einer normierten Syntax erlaubt. Auch dessen Erweiterung SysML sowie das Austauschformat für Anforderungen ReqIF wurden von der OMG entwickelt.</font>    |
| ::: | ::: | ::: |

===== Weitere Quellen =====

  - Harman Hunjan (Renesas): ISO/SAE 21434 Automotive Cybersecurity Engineering, 4.7.2018
  - Stefan Kriso, Jürgen Klarmann, Claudia Loderhose, Franziska Wiemer, Carsten Gebauer, Simon Burton, Markus Ihle: Sicher unterwegs in einer manipulierten Umwelt: Eine Frage der Safety oder Security – oder von beidem?, Embedded Software Engineering Kongress, Sindelfingen 03.-07.12.2018
  - Stefan Kriso, Markus Ihle: Automotive Security im Kontext der Funktionalen Sicherheit (ISO 26262), 31. VDI/VW Gemeinschaftstagung Automotive Security, Wolfsburg, 21.-22.10.2015
  - Benjamin Glas, Carsten Gebauer, Jochen Hänger, Andreas Heyl, Jürgen Klarmann, Stefan Kriso, Priyamvadha Vembar, Philipp Wörz: Automotive Safety and Security Integration Challenges, Automotive Safety & Security 2015, Stuttgart, 21.-22.04.2015, Lecture Notes in Informatics (LNI) - Proceedings, Volume P-240 (ISBN 978-3-88579-634-3), S. 13-28
  - Stefan Kriso: Die Grenzen der ISO 26262 – Professioneller Umgang mit Lücken in der Sicherheitsnorm, Embedded Software Engineering Kongress, Sindelfingen, 01.-05.12.2014