Automotive - Safety & Security

Die Produktsichehrheit bei Straßenfahrzeugen ist ein sehr vielschichtiger Begriff, da er eine Vielzahl verschiedener Sicherheitsaspekte umfasst, die jeweils für sich aber auch zusammen betrachtet werden müssen. So stellt der Bereich Funktionale Sicherheit nur einen Teil der Gesamtsicherheit dar, genau so wie dies für die Cybersicherheit gilt. Weitere Aspekte (einige davon im nachfolgendem Bild dargestellt), die nicht weniger wichtig sein können, betreffen die Datensicherheit, die Sicherheit der beabsichtigten Funktion, Sicherheit und künstliche Intelligenz, mechanische Sicherheit, Störfestigkeit, elektrische Sicherheit, Hochvolt-Sicherheit usw.

Der vorliegende Automotive-Beitrag fokussiert industriebezogen auf funktionale Sicherheit und Automotive Cybersecurity. Menschliche Zuverlässigkeit kann hier als querschnittlicher Einflussfaktor berücksichtigt werden, insbesondere dort, wo menschliches Handeln die Beherrschbarkeit (Controllability) sicherheitskritischer Situationen beeinflusst. In diesem begrenzten Sinne kann Human Reliability eine verbindende Perspektive zwischen Menschen, technischer Funktion und Sicherheitsbetrachtung liefern. Die VDI 4006 Blatt 2 - 2003-02 liefert Methoden zur quantitativen Bewertung menschlicher Handlungen und kann damit insbesondere die Functional-Safety-Betrachtung ergänzen, wenn menschliche Reaktionen die Beherrschbarkeit (Controllability) eines gefährlichen Ereignisses beeinflussen; ein unmittelbarer methodischer Bezug zur Automotive Cybersecurity besteht dagegen nicht.

Bild 1: Struktur der Wechselbeziehungen zwischen verschiedenen Sicherheitsaspekten bei Straßenfahrzeugen

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

Bild 2: Iterativer Prozess zur Risikobeurteilung und Risikoreduzierung gem. ISO/IEC Guide 51

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 (engl.: 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/SAE 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]).

Bild 3: 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 EU-Regelung Nr. 155 ist Teil der UNECE WP.29, welche aus den Regelungen Nr. 155 (Cybersecurity-betreffend), Nr. 156 (Software-Updates-betreffend) und Nr. 157 (Automated Lane Keeping-betreffend) besteht.ö

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 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. 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 beinhalten 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/SAE 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, der Angriffsvektor- 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, Angriffsvektor 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 der Risikomatrix (aus Impactbewertung und Angriffsvektor). Die Abhängigkeit vom Angriffsvektor anstatt von der Angriffsmachbarkeit hat den Vorteil, dass für den Cybersecurity Assurance Level eine Stetigkeit beschreiben werden kann. Das Risiko beschrieben mit der Angriffsmachbarkeit 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 führen. Erst durch Spezifikation, Umsetzung und Test eines Fixes der Schwachstelle wird das Risiko reduziert. Aufgrund des erforderlichen Engineering Supports Post von SOP (Start of Production) bis über EOP (End of Production) hinaus, ist es empfehlenswert, dass die Vertragspartner ein Service-Level-Agreement 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.

Im Bereich der Funktionalen Sicherheit im Automotive-Bereich werden „Gefährdungsanalysen und Risikobewertungen“ (G&R) gemäß ISO 26262 durchgeführt. 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 Controllability nach ISO 26262-3:2018

Im informativen Teil der ISO 26262 sind teils 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 Standard ISO/PAS 8800 wird die Sicherheit von AI addressiert. 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 dieser Standard erst kürzlich veröffentlicht wurde (Dezember 2024), 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 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 HARA oder 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 (engl.: threat analysis and risk assessment, TARA). Die Schritte zur Durchführung einer 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)
• 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.

Die ISO/SAE 21434 betrachtet die Auswirkungen eines Cybersecurity-Schadensszenarios in den vier Kategorien Safety, Financial, Operational und Privacy. Die jeweilige Auswirkung wird den Stufen Negligible, Moderate, Major oder Severe zugeordnet. Tabelle 8 fasst die entsprechenden Impact-Kategorien zusammen.

Tabelle 8: Impact-Kategorisierung nach ISO/SAE 21434

Eine Vulnerability bezeichnet im Sinne der ISO/SAE 21434 eine Schwachstelle, die innerhalb eines Angriffspfads ausgenutzt werden kann. Für die Risikobewertung wird betrachtet, mit welchem Aufwand ein Angreifer einen solchen Angriffspfad realisieren kann. Die Attack Feasibility (Angriffsmachbarkeit) beschreibt damit, wie schwierig oder einfach die erfolgreiche Umsetzung eines Angriffs ist. Dabei werden unter anderem benötigte Zeit, Fachkenntnisse, Wissen über das betrachtete System, Zugangsmöglichkeiten und erforderliche Ausrüstung berücksichtigt.

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.

Da der Angriffsvektoransatz für die Bestimmung des Cybersecurity Assurance Level verwendet wird, wird dieser hier weiter erläutert. Der Angriffsvektor reflektiert den Kontext der Angriffspfad ausgenutzt werden kann. Die Angrifssmachbarkeit steigt mit der Remote- Verfügbarkeit des Angriffspfad. Eine über das Internet angreifbare Schwachstelle wird von mehreren Angreifer ausgenutzt als eine Schwachstelle, die physischen Zugriff auf die Komponente erfordert.

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

Für die Entwicklung relevant ist der Cybersecurity Assurance Level. Dieser wird im Annex E der ISO/SAE 21434 definiert:

Die Tabelle 11 beschrieb die Risikomatrix in Abhängigkeit des Angriffspotential. Für das Cybersecurity Assurance Level wird jedoch der Angriffsvektor definiert. Dabei ergibt sich folgende Matrix (laut Annex Table E1 in der ISO/SAE 21434):

Die UN-Regelung Nr. 155 liefert im Annex 5 eine umfangreiche Liste von Bedrohungen und entsprechenden Gegenmaßnahmen. Für Fahrzeugprojekte, welcher der UN-Regelung Nr. 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, DIN EN 61508-2, DIN EN 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), um die Sicherheitskonzepte anzupassen und neue Sicherheitsmechanismen zu definieren oder die Wirksamkeit der bestehenden Sicherheitskonzepte/-mechanismen nachzuweisen.

Im Rahmen der Cybersecurity kommen qualitative Analysen zur Bestimmung der Produktrisiken hinsichtlich Safety, Financial, Operational und Privacy sowie des Cybersecurity Assurance Level (CAL) zum Einsatz (siehe ISO/SAE 21434; siehe Ausführungen oben). Quantitative Methoden werden bei den Cybersecurity-Betrachtungen für den Wirksamkeitsnachweis der implementierten Securtiy-Mechanismen nicht verwendet.

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. Die notwendige Risikoreduzierung addressiert einerseits die Vermeidung systematischer Fehler, andererseits die Beherrschung auftretender zufälliger Hardware-Fehler.

Zur Bewertung, ob das gewählte Hardware-Architekturdesign geeignet ist, zufällig auftretende Hardware-Fehler angemessen entdecken und beherrschen zu können, werden entsprechend definierte Hardware-Metriken herangezogen (siehe ISO 26262-5:2028, Kap. 8 und 9). Die Berechnung dieser Metriken basiert auf Handbuchdaten, dementsprechend konservativ sind die entsprechenden zu erreichenden Zielwerte (die kontextabhängig angepasst werden können) festgelegt. Diese Zielwerte entfalten keine absolute Signifikanz, das heißt sie haben nicht den Anspruch, real im Feld auftretende Ausfallraten abzubilden. Zur Ermittlung der entsprechenden Zielwerte kommen induktive Methoden (z.B. FMEDA) und/oder deduktive Methoden (FTA) zum Einsatz.

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, sharing, reduction) durchgeführt werden. Die Option „Reduction“ verfolgt das Ziel, das Risiko 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/SAE 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/SAE 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.

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.

Bild 4: Schnittmenge von Safety und Cybersecurity

Funktionale Sicherheit (Safety) und Automotive Cybersecurity (Security) sind eigenständige, zugleich eng miteinander verknüpfte Domänen. Sicherheitskritische Fahrzeugfunktionen werden insbesondere dann auch für die Cybersecurity relevant, wenn Cyberangriffe ihr sicheres Verhalten beeinflussen oder beeinträchtigen können. Die TARA berücksichtigt den Impact für Safety, aber auch für den betrieblichen Einfluss, finanziellen Schaden und Datenschutzverletzung.

Bild 5: Safety als Teil der Cybersecurity-Impact-Bewertung

Der Abgleich der Impactbewertungen kann im Rahmen eines TARA/HARA-Cross-Checks erfolgen. Der Safety Manager wird damit zum 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/SAE 21434 die Severity-Einstufung aus der ISO 26262 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 (ISO 26262):

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. Sowohl der ASIL als auch der CAL werden genutzt, um in der Entwicklung die anzuwendenden Methoden für Analyse, Design und Verifikation festzulegen. Auch werden über ASIL und CAL die Unabhängigkeit der Assessments definiert.

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.

Safety- und Security-Entwicklungen im Automobilbereich verfolgen trotz unterschiedlichem Fokus (s. Einleitung) teils ähnliche Ansätze und die relevanten Standards erwarten teils ähnliche Aktivitäten entlang des Produktlebenszyklus. Dies lässt recht deutlich im nachfolgenden Bild gem. [7] erkennen, wo die jeweiligen Kernaspekte mittels des bekannten V-Modells dargestellt sind. Die vorherrschenden Symbiosen gilt es von den involvierten Unternehmen bestmöglich zu nutzen, so dass die beiden Bereiche nicht vollständig losgelöst voneinander agieren.

Bild 6: Aktivitäten von Safety & Security im Lebenszyklus

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.

Tabelle 14: Lösungsansätze

Safety und Security sind eigenständige, zugleich eng miteinander verknüpfte Domänen. Abhängig vom jeweiligen Anwendungsfall können ihre Anforderungen miteinander vereinbar sein, sich gegenseitig beeinflussen oder zu Zielkonflikten führen. Tabelle 15 zeigt typische Wechselwirkungen zwischen Safety und Security sowie mögliche Lösungsansätze anhand ausgewählter Automotive-Beispiele.

Tabelle 15: Wechselwirkungen zwischen Safety und Security im Automotive-Kontext

Software-Updates, einschließlich Over-the-Air-Updates (OTA), sind ein typischer Anwendungsfall für direkte Wechselwirkungen zwischen Safety- und Security-Anforderungen. Der Zielkonflikt entsteht daraus, dass Security nicht vertrauenswürdige oder manipulierte Software verhindern muss, während Safety die sichere Verfügbarkeit der Fahrzeugfunktionen gewährleisten muss.

• Software-Updates müssen authentifiziert und gegen Manipulation geschützt sein.
• Steuergeräte dürfen ausschließlich autorisierte und signierte Software akzeptieren.
• Kommunikationsschnittstellen müssen angemessen abgesichert werden, beispielsweise durch TLS und Zertifikate.
• Manipulationen an Software, Daten oder Update-Paketen müssen erkannt und verhindert werden.

Ziel ist es, nicht autorisierte Software sowie Manipulationen am Fahrzeug zu verhindern.

• Steuergeräte müssen ihre sicherheitsrelevanten Funktionen innerhalb der vorgesehenen Betriebszustände zuverlässig bereitstellen.
• Updates dürfen sicherheitskritische Funktionen nicht unkontrolliert beeinträchtigen, insbesondere während des Fahrbetriebs.
• Fehler während eines Updates müssen in einen definierten sicheren Zustand überführt werden.
• Safety-relevante Softwarefehler müssen innerhalb eines angemessenen Zeitraums behoben werden können.

Ziel ist es, die sichere Fahrzeugfunktion während und nach dem Update-Prozess zu gewährleisten.

• Strenge Security-Mechanismen können ein Update blockieren, beispielsweise bei einem abgelaufenen oder nicht vertrauenswürdigen Zertifikat.
• Ein sicherheitskritischer Fehler kann ein zeitnahes Update erforderlich machen.
• Kryptographische Prüfungen können das Zeitverhalten und die Verfügbarkeit eines Systems beeinflussen.
• Ein unterbrochenes oder fehlerhaftes Update kann sicherheitskritische Funktionen beeinträchtigen.
• Safety- und Security-Anforderungen können unterschiedliche Anforderungen an Verfügbarkeit, Integrität und Systemzustände stellen.

Die Beherrschung dieser Wechselwirkungen erfolgt durch eine abgestimmte System- und Prozessgestaltung, bei der die Anforderungen beider Disziplinen gemeinsam bewertet werden.

Eine zentrale Maßnahme ist die Trennung unterschiedlicher Betriebs- und Update-Szenarien.

• Keine Installation von Software-Updates während sicherheitskritischer Fahrsituationen.
• Safety-relevante Funktionen bleiben verfügbar.
• Security-Mechanismen müssen die erforderlichen Echtzeit- und Verfügbarkeitsanforderungen berücksichtigen.

• Vollständige Authentifizierung und Integritätsprüfung des Update-Pakets.
• Installation nur innerhalb eines definierten und geeigneten Fahrzeugzustands.
• Aktivierung der neuen Software erst nach erfolgreicher Prüfung.

Typische Kriterien für einen geeigneten Fahrzeugzustand können sein:

• Fahrzeug steht, beispielsweise v = 0 km/h.
• Antrieb befindet sich in einem für das Update vorgesehenen Zustand.
• Fahrzeug ist gegen unbeabsichtigte Bewegung gesichert.
• Keine für den Update-Prozess ausgeschlossenen sicherheitskritischen Funktionen sind aktiv.
• Ausreichende Energieversorgung ist gewährleistet.
• Erforderliche Kommunikationsverbindungen sind stabil.

Der Zielkonflikt wird dadurch zeitlich und funktional entkoppelt.

• Zwei getrennte Softwarestände beziehungsweise Speicherbereiche stehen zur Verfügung.
• Die neue Softwareversion wird zunächst in einen inaktiven Bereich geladen.
• Integrität und Authentizität werden vor der Aktivierung geprüft.
• Die Aktivierung erfolgt erst nach erfolgreicher Validierung.
• Bei einem Fehler kann auf einen zuvor freigegebenen Softwarestand zurückgewechselt werden.

• Ein Fehler führt nicht zwangsläufig zum vollständigen Verlust der Fahrzeugfunktion.
• Eine zuvor definierte eingeschränkte Funktion kann weiterhin verfügbar bleiben.
• Die eingeschränkte Betriebsart muss im Rahmen der Safety- und Security-Bewertung berücksichtigt werden.

• Der Update-Prozess wird überwacht.
• Fehler oder unvollständige Installationen werden erkannt.
• Das System kann auf einen zuvor freigegebenen Softwarestand zurückkehren.
• Das Fahrzeug beziehungsweise das betroffene System verbleibt in einem definierten Zustand.

• Safety-relevante Updates können entsprechend ihrer Kritikalität priorisiert werden.
• Für außergewöhnliche Situationen können definierte alternative Vertrauensmechanismen vorgesehen werden.
• Auch priorisierte Updates müssen weiterhin die festgelegten Security-Anforderungen erfüllen.

Eine geeignete E/E- und Softwarearchitektur kann Wechselwirkungen zwischen Safety und Security reduzieren.

• Trennung von Safety- und Security-Funktionen.
• Kapselung sicherheitskritischer Funktionen.
• Definierte und kontrollierte Schnittstellen zwischen Safety- und Security-Komponenten.
• Nutzung dedizierter Security-Komponenten, beispielsweise eines Hardware Security Module (HSM).
• Sicherstellung deterministischer Eigenschaften für zeitkritische Safety-Funktionen.
• Definierte Fallback- und Recovery-Mechanismen.

Zielkonflikte zwischen Safety und Security können bei vernetzten und softwaredefinierten Fahrzeugfunktionen folglich systembedingt entstehen. Entscheidend ist ihre systematische Beherrschung durch klar definierte Betriebs- und Update-Szenarien, robuste und fehlertolerante Update-Mechanismen, abgestimmte Safety- und Security-Architekturen sowie definierte Prioritäten und Entscheidungsregeln. Dadurch können Cyberangriffe und nicht autorisierte Änderungen verhindert und gleichzeitig die sichere Fahrzeugfunktion über den gesamten Update-Prozess hinweg gewährleistet werden.

Künstliche Intelligenz (KI) entwickelt sich im Automotive-Bereich zu einem wichtigen Querschnittsthema von Safety und Security. Dies betrifft insbesondere Funktionen, bei denen KI für Wahrnehmung, Entscheidungsfindung oder Fahrzeugregelung eingesetzt wird.

KI-basierte Systeme lassen sich nicht vollständig durch deterministische Anforderungen und klassische Testverfahren absichern. Neben klassischen Fehler- und Angriffsszenarien müssen daher zusätzliche Einflussgrößen berücksichtigt werden. Dazu gehören insbesondere die Qualität und Repräsentativität der verwendeten Trainings- und Eingangsdaten, der Umgang mit unbekannten oder seltenen Betriebssituationen sowie die Robustheit und die bekannten Grenzen des KI-Modells. Darüber hinaus ist zu berücksichtigen, dass sich das Verhalten eines KI-basierten Systems über den Lebenszyklus verändern kann. Eine weitere Herausforderung besteht darin, Entscheidungen, Modelländerungen und deren Auswirkungen auf das Systemverhalten nachvollziehbar zu dokumentieren und zu bewerten.

Der Einsatz von KI schafft zusätzliche Cybersecurity-Angriffsflächen. Angriffe können beispielsweise auf die Manipulation von Trainingsdaten (Data Poisoning), die Veränderung oder Kompromittierung von KI-Modellen (Model Poisoning) oder auf gezielt gestaltete adversariale Eingaben abzielen. Darüber hinaus können Modelle ausgetauscht oder verändert sowie Software- und Modell-Updates kompromittiert werden. Bei Safety-kritischen Funktionen können solche Manipulationen das Fahrzeugverhalten beeinflussen. Ein Cybersecurity-Ereignis kann dadurch unmittelbar zu einem Safety-relevanten Fehlverhalten auf Fahrzeugebene führen.

Safety und Security müssen bei KI-Anwendungen daher gemeinsam betrachtet werden. Entscheidend ist, nachvollziehbar nachzuweisen, unter welchen Bedingungen ein KI-System zuverlässig arbeitet, welche Grenzen bekannt sind und wie mit Abweichungen, neuen Erkenntnissen sowie Änderungen am Modell oder Gesamtsystem umgegangen wird.

Für die Absicherung KI-basierter Fahrzeugsysteme sind verschiedene Safety- und Cybersecurity-Standards relevant. ISO 26262 bildet den zentralen Rahmen für die funktionale Sicherheit elektrischer und elektronischer Fahrzeugsysteme, während ISO 21448 (SOTIF) Risiken adressiert, die aus Unzulänglichkeiten der beabsichtigten Funktion entstehen können. ISO/PAS 8800 ergänzt diese Ansätze speziell für die Safety von Systemen mit künstlicher Intelligenz. Für die Automotive Cybersecurity stellt ISO/SAE 21434 den zentralen Engineering-Rahmen dar.

Mit prEN 18282:2026 „Artificial Intelligence – Cybersecurity specifications for AI Systems“ wird dieser Rahmen um KI-spezifische Cybersecurity-Aspekte ergänzt. Der Normenentwurf adressiert insbesondere Risiken im Zusammenhang mit KI-Modellen, Trainings- und Inferenzdaten sowie deren Interaktion mit der Betriebsumgebung. Dazu zählen unter anderem Data Poisoning, Model Poisoning, adversariale Manipulationen und weitere KI-spezifische Schwachstellen. Der Entwurf wird im CEN-CLC/JTC 21 „Artificial Intelligence“ entwickelt und trägt zur Konkretisierung von Cybersecurity-Anforderungen für KI-Systeme im europäischen regulatorischen Umfeld bei.

KI verstärkt somit die Wechselwirkungen zwischen Safety und Security. Ein Angriff auf Daten, Modelle oder Software kann zu fehlerhaften Entscheidungen eines KI-Systems führen und sich anschließend als Safety-relevantes Fehlverhalten auf Fahrzeugebene manifestieren. Die Absicherung KI-basierter Funktionen erfordert deshalb eine integrierte Betrachtung von Safety, Cybersecurity, Daten, Modell, Betrieb und Änderungen über den gesamten Produktlebenszyklus.

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
6. Arno Meyna, Dirk Althaus, Andreas Braasch, Fabian Plinke, Marco Schlummer: Sicherheit und Zuverlässigkeit technischer Systeme, Hanser Verlag, 2023.
7. Alessandro Farsaci, Luca Toninello: Automotive Functional Safety and Cybersecurity - Building Connect and Engineering, Automotive Functional Safety Forum, Berlin, 30.-31.05.2023.