Safety (Security) Risiko im Automobilbereich

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.

Tabelle 1: Relevante Normen und Richtlinien für den Bereich „Safety“

Tabelle 2: Relevante Normen und Richtlinien für den Bereich „Security“

Tabelle 3: Weitere relevante Normen und Richtlinien

​​​​​

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: Tabelle 4: Typen von Risikoquellen und Referenzen

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.

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

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

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

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

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(VDA) 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.

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.

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.

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: Tabelle 4: Typen von Risikoquellen und Referenzen

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.

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

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

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

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

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(VDA) 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.

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.

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.

CKGE_TMP_i Tabellen neu einfügen (als Bild) CKGE_TMP_i

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

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

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

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

Tabelle 8: Impact-Kategorisierung nach ISO/SAE 21434

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.

Tabelle 9: Methode zur Attack Feasibility-Klassifikation nach ISO/SAE 21434

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

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

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

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

Ergänzen: Metriken bei Hardware (ISO 26262): FMEDA, FTA, PMHF, …

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

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.

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

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

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

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)

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

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.

gerne noch weitere ergänzen

Tabelle 14: Lösungsansätze

1. Harman Hunjan (Renesas): ISO/SAE 21434 Automotive Cybersecurity Engineering, 4.7.2018
2. 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
3. Stefan Kriso, Markus Ihle: Automotive Security im Kontext der Funktionalen Sicherheit (ISO 26262), 31. VDI/VW Gemeinschaftstagung Automotive Security, Wolfsburg, 21.-22.10.2015
4. 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
5. Stefan Kriso: Die Grenzen der ISO 26262 – Professioneller Umgang mit Lücken in der Sicherheitsnorm, Embedded Software Engineering Kongress, Sindelfingen, 01.-05.12.2014

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

Ergänzen: Metriken bei Hardware (ISO 26262): FMEDA, FTA, PMHF, …

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

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.

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

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

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

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)

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

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.

gerne noch weitere ergänzen

Tabelle 14: Lösungsansätze

1. Harman Hunjan (Renesas): ISO/SAE 21434 Automotive Cybersecurity Engineering, 4.7.2018
2. 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
3. Stefan Kriso, Markus Ihle: Automotive Security im Kontext der Funktionalen Sicherheit (ISO 26262), 31. VDI/VW Gemeinschaftstagung Automotive Security, Wolfsburg, 21.-22.10.2015
4. 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
5. Stefan Kriso: Die Grenzen der ISO 26262 – Professioneller Umgang mit Lücken in der Sicherheitsnorm, Embedded Software Engineering Kongress, Sindelfingen, 01.-05.12.2014