Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- content:automotive [2025/10/16 16:52] – [Relevante Normen und Richtlinien (unvollständig)] droste
+++ content:automotive [2026/09/10 09:11] (aktuell) – [Exemplarisches Beispiel: Widerspruch zwischen Safety und Security bei Software-Updates] vdiadmin
@@ Zeile 1: / Zeile 1: @@
-====== Safety (Security) Risiko im Automobilbereich ======
+====== 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 Sichereit 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.
+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 [[https://www.dinmedia.de/de/technische-regel/vdi-4006-blatt-2/60089611|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.
 {{https://safetyandsecurity.vdi.de/_media/content:automotive2.svg?nolink&600x244}}
 **Bild 1: Struktur der Wechselbeziehungen zwischen verschiedenen Sicherheitsaspekten bei Straßenfahrzeugen **
 ===== Relevante Normen und Richtlinien (unvollständig) =====
@@ Zeile 34: / Zeile 34: @@
 ^Kennung^Jahr^Titel^Anmerkung|
-|[[https://www.dinmedia.de/en/standard/iso-sae-21434/345375662|ISO/SAE 21434]]|2021|Road vehicles – Cybersecurity engineering|Spezifizierung von Engineering-Anforderungen an das Cybersicherheits-Risikomanagement bzgl. Konzept, Produktentwicklung, Produktion, Betrieb, Wartung und Außerbetriebnahme von E/E-Systemen in Straßenfahrzeugen|
+|[[https://www.dinmedia.de/en/standard/iso-sae-21434/345375662|ISO/SAE 21434]]|2021|Road vehicles – Cybersecurity engineering|Spezifizierung von Engineering-Anforderungen an das Cybersecurity-Risikomanagement hinsichtlich Konzept, Produktentwicklung, Produktion, Betrieb, Wartung und Außerbetriebnahme von E/E-Systemen in Straßenfahrzeugen. Ein E/E-System (Elektrik/Elektronik) im Fahrzeug umfasst alle elektrischen und elektronischen Komponenten sowie deren Zusammenspiel. Dazu zählen insbesondere Steuergeräte, Sensoren, Aktuatoren, Verkabelung, Kommunikationsnetzwerke und die zugehörige Software.|
-|[[https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security|UN-Regelung Nr. 155]]|2021|Genehmigung von Fahrzeugen hinsichtlich der Cybersicherheit und des Cybersicherheitsmanagementsystems|Regulierung fordert den Betrieb eines zertifizierten Cybersicherheitsmanagementsystems als Bedingung für die zukünftige Typengenehmigung über den kompletten Fahrzeug-Lebenszyklus (inkl. Sicherstellung der Einhaltung von Cybersicherheitsanforderungen entlang der gesamten Lieferkette)|
+|[[https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security|UN-Regelung Nr. 155]]|2021|Genehmigung von Fahrzeugen hinsichtlich der Cybersicherheit und des Cybersicherheitsmanagementsystems|Regulierung fordert den Betrieb eines zertifizierten Cybersicherheitsmanagementsystems als Bedingung für die Typgenehmigung über den gesamten Fahrzeuglebenszyklus, einschließlich der Sicherstellung von Cybersecurity-Anforderungen entlang der Lieferkette.|
-|[[https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update|UN-Regelung Nr. 156]]|2021|Genehmigung von Kraftfahrzeugen hinsichtlich der Softwareaktualisierung und des Softwareaktualisierungsmanagementsystems|Regulierung fordert den Betrieb eines zertifizierten Softwareupdatemanagementsystems als Bedingung für die zukünftige Typengenehmigung über den kompletten Fahrzeug-Lebenszyklus (inkl. Compliance der Zulieferer)|
+|[[https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update|UN-Regelung Nr. 156]]|2021|Genehmigung von Kraftfahrzeugen hinsichtlich der Softwareaktualisierung und des Softwareaktualisierungsmanagementsystems|Regulierung fordert den Betrieb eines zertifizierten Softwareupdatemanagementsystems als Bedingung für die Typgenehmigung über den gesamten Fahrzeuglebenszyklus, einschließlich der Einbindung relevanter Zulieferer.|
-|[[https://www.dinmedia.de/de/norm/sae-j-3061/349587715|SAE J3061]]|2021|Cybersecurity Guidebook for Cyber-Physical Vehicle Systems|Praxisleitfaden für die Cyber-Sicherheit von Fahrzeugen über den gesamten Lebenszyklus|
+|[[https://www.dinmedia.de/de/norm/sae-j-3061/349587715|SAE J3061]]|2021|Cybersecurity Guidebook for Cyber-Physical Vehicle Systems|Praxisleitfaden für die Cybersecurity von Fahrzeugen über den gesamten Lebenszyklus.|
-|[[https://webshop.vda.de/QMC/de/automotive-spice-for-cybersecurity-2nd-edit-2025|VDA QMC]]|2025 V2.0|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://webshop.vda.de/QMC/de/automotive-spice-for-cybersecurity-2nd-edit-2025|VDA QMC]]|2025 V2.0|Automotive SPICE for Cybersecurity|Erweiterung von Automotive SPICE um zusätzliche Cybersecurity-Prozesse mit dem Ziel, Cybersecurity-relevante Aktivitäten in das bestehende Prozessmodell zu integrieren.|
-|[[https://www.dinmedia.de/de/technische-regel/iso-pas-5112/353687920|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|
+|[[https://www.dinmedia.de/de/technische-regel/iso-pas-5112/353687920|ISO/PAS 5112]]|2022|Road vehicles – Guidelines for auditing cybersecurity engineering|Leitfaden zur Auditierung von Automotive Cybersecurity Engineering sowie zu den Anforderungen und Kompetenzen der beteiligten Auditoren.|
-|[[https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final|NIST SP 800-57 Part 1]]|2020 Rev. 5|Recommendation for Key Management: Part 1 – General|Allgemeine Richtlinien für die Verwaltung kryptografischer Schlüsselmaterialien|
+|[[https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final|NIST SP 800-57 Part 1]]|2020 Rev. 5|Recommendation for Key Management: Part 1 – General|Allgemeine Richtlinien für die Verwaltung kryptografischer Schlüsselmaterialien.|
-|[[https://csrc.nist.gov/pubs/sp/800/57/pt2/r1/final|NIST SP 800-57 Part 2]]|2019 Rev. 1|Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations|Richtlinien für Organisationen zur Verwaltung kryptografischer Schlüssel|
+|[[https://csrc.nist.gov/pubs/sp/800/57/pt2/r1/final|NIST SP 800-57 Part 2]]|2019 Rev. 1|Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations|Richtlinien und Best Practices für Organisationen zur Verwaltung kryptografischer Schlüssel.|
-|[[https://csrc.nist.gov/pubs/sp/800/57/pt3/r1/final|NIST SP 800-57 Part 3]]|2015 Rev. 1|Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance|Richtlinien für die Nutzung kryptografischer Funktionen in aktuellen Systemen|
+|[[https://csrc.nist.gov/pubs/sp/800/57/pt3/r1/final|NIST SP 800-57 Part 3]]|2015 Rev. 1|Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance|Richtlinien für die anwendungsspezifische Nutzung kryptografischer Verfahren und das zugehörige Schlüsselmanagement.|
-|[[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html|BSI-TR-02102-1]]|2025|Kryptographische Verfahren: Empfehlungen und Schlüssellängen|Technische Richtlinie vom BSI mit einer Bewertung der Sicherheit von ausgewählten kryptographischen Verfahren.|
+|[[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html|BSI-TR-02102-1]]|2025|Kryptographische Verfahren: Empfehlungen und Schlüssellängen|Technische Richtlinie des BSI mit Empfehlungen und Bewertungen zur Sicherheit ausgewählter kryptografischer Verfahren und Schlüssellängen.|
-|[[https://www.dinmedia.de/de/norm/iso-iec-29100/378089168|ISO/IEC 29100]]|2024|Information technology – Security techniques – Privacy framework|Dokument legt gemeinsame Terminologie für den Datenschutz fest und definiert Akteure und ihre Rollen bei der Verarbeitung von personenbezogenen Daten.|
+|[[https://www.dinmedia.de/de/norm/iso-iec-29100/378089168|ISO/IEC 29100]]|2024|Information technology – Security techniques – Privacy framework|Dokument legt eine gemeinsame Terminologie für den Datenschutz fest und definiert Akteure, Rollen und grundlegende Prinzipien bei der Verarbeitung personenbezogener Daten.|
 **Tabelle 3: Weitere relevante Normen und Richtlinien**
@@ Zeile 54: / Zeile 54: @@
 |[[https://www.dinmedia.de/de/technische-regel/iso-sae-pas-22736/345375919|ISO/SAE PAS 22736]]  |2021  |Taxonomy and definitions for terms related to driving automation systems for on-road motor vehicles|Das Dokument enthält eine Taxonomie mit detaillierten Definitionen für sechs Stufen der Fahrautomatisierung, die von keiner Fahrautomatisierung (Stufe 0) bis zur vollständigen Fahrautomatisierung (Stufe 5) reichen, im Zusammenhang mit Fahrzeugen und deren Betrieb auf der Straße:|
 |[[https://www.dinmedia.de/de/norm/din-en-61000-6-7/241796186|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. 2021 erschien eine Berichtigung  |
+|[[https://www.dinmedia.de/de/technische-regel/vdi-4006-blatt-2/60089611|VDI 4006 Blatt 2 - 2003-02]]  |2003  |Menschliche Zuverlässigkeit – Methoden zur quantitativen Bewertung menschlicher Zuverlässigkeit  |Beschreibt Methoden zur **quantitativen Bewertung menschlichen Handelns in technischen Systemen**. Behandelt die grundsätzliche Vorgehensweise der **Human Reliability Analysis (HRA)** und unterstützt die systematische Bewertung menschlicher Handlungen und möglicher Fehlhandlungen. Im Automotive-Kontext kann die Richtlinie insbesondere die **Functional-Safety-Betrachtung** ergänzen, wenn menschliche Reaktionen die Beherrschbarkeit (//Controllability//) gefährlicher Situationen beeinflussen. Ein unmittelbarer methodischer Bezug zur Automotive Cybersecurity besteht nicht. **Hinweis:** Die Ausgabe 2003-02 ist zurückgezogen und wurde durch **VDI 4006 Blatt 2:2017-11** ersetzt.  |
+|[[https://genorma.com/en/standards/pren-18282|prEN 18282]]  |2026  |Artificial Intelligence – Cybersecurity specifications for AI Systems  |Europäischer Normenentwurf zur Cybersecurity von Hochrisiko-KI-Systemen über den gesamten Lebenszyklus. Behandelt organisatorische und technische Maßnahmen zur Prävention, Erkennung, Reaktion und Beherrschung KI-spezifischer Angriffe und Schwachstellen. Dazu zählen insbesondere **Data Poisoning**, **Model Poisoning**, **adversariale Eingaben / Model Evasion**, Vertraulichkeitsangriffe und modellbezogene Schwachstellen. Der Standard definiert zudem objektive Kriterien zur Bewertung, ob technische oder organisatorische Maßnahmen ein definiertes Schutzziel angemessen erfüllen.  |
 ===== VDI Richtlinien =====
-^ Kennung ^ Jahr ^ Titel ^ Anmerkung ^
+^Kennung^Jahr^Titel^Anmerkung|
-| VDI-EE 4020 | 2024 | Grundlagen der Funktionalen Sicherheit gemäß IEC 61508 und spezifische Sektor-Normen | — |
+|[[https://www.dinmedia.de/de/technische-regel/vdi-ee-4020/378351818|VDI-EE 4020]]|2024|Grundlagen der Funktionalen Sicherheit gemäß IEC 61508 und spezifische Sektor-Normen|—|
-| VDI 2700 |  | Ladungssicherung auf Straßenfahrzeugen | Richtlinienreihe |
+|[[https://www.dinmedia.de/de/technische-regel/vdi-2700/76329774|VDI 2700]]|2004|Ladungssicherung auf Straßenfahrzeugen|Richtlinienreihe|
-| VDI/VDE 2862 Blatt 1 | 2025 | Mindestanforderungen beim Einsatz von Schraubsystemen und -werkzeugen – Anwendungen in der Fahrzeug- und Anbauteileindustrie | Entwurf 06/2025 |
+|[[https://www.dinmedia.de/de/technische-regel/vdi-vde-2862-blatt-1/146660826|VDI/VDE 2862 Blatt 1]]|2025|Mindestanforderungen beim Einsatz von Schraubsystemen und -werkzeugen – Anwendungen in der Fahrzeug- und Anbauteileindustrie|Neuer Entwurf 06/2025|
-| VDI 5950 |  | Umgang mit Hochleistungsbatterien (Lithium-Ionen) in der Elektromobilität | Richtlinienreihe |
+|[[https://www.vdi.de/mitgliedschaft/vdi-richtlinien/details/vdi-5950-blatt-1-umgang-mit-hochleistungsbatterien-begriffe-und-grundlagen|VDI 5950]]|-|Umgang mit Hochleistungsbatterien|Noch nicht veröffentlicht|
 ===== 1 Risiko: Definition und Herausforderungen =====
@@ Zeile 115: / Zeile 117: @@
 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 [[https://www.sae.org/standards/content/j3061_202112| 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.
+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 [[https://www.sae.org/standards/content/j3061_202112|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 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.</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>
@@ Zeile 177: / Zeile 179: @@
 |
-**Tabelle 8: Impact-Kategorisierung nach ISO/SAE 21434**
+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.
-^ Severity class  ^ Safety  ^ Financial  ^ Operational  ^ Privacy  ^
+**Tabelle 8: Impact-Kategorisierung nach ISO/SAE 21434**
-| **Negligible** | **S0** \\ Keine Verletzungen | Der finanzielle Schaden führt zu keinen Auswirkungen, vernachlässigbaren Konsequenzen oder ist für den Straßenbenutzer irrelevant. | Der operationale Schaden führt zu keiner oder einer nicht wahrnehmbaren Beeinträchtigung einer Fahrzeugfunktion. | Der Datenschutzschaden führt zu keinen Auswirkungen, vernachlässigbaren Konsequenzen oder ist für den Straßenbenutzer irrelevant. Die Informationen über den Straßenbenutzer sind nicht sensibel und schwer mit einer persönlich identifizierbaren Information (PII) verknüpfbar. |
-| **Moderate** | **S1** \\ Leichte bis moderate Verletzungen | Der finanzielle Schaden führt zu unangenehmen Konsequenzen, die der betroffene Straßenbenutzer mit begrenzten Ressourcen überwinden kann. | Der operationale Schaden führt zu einer teilweisen Degradierung einer Fahrzeugfunktion. \\ **Beispiel:** Nutzerzufriedenheit wird negativ beeinflusst. | Der Datenschutzschaden führt zu unangenehmen Konsequenzen für den Straßenbenutzer. Die Informationen über den Straßenbenutzer sind: \\ a) sensibel, aber schwer mit einer PII verknüpfbar; oder \\ b) nicht sensibel, aber leicht mit einer PII verknüpfbar. |
-| **Major** | **S2** \\ Schwere und lebensbedrohliche Verletzungen (Überleben wahrscheinlich) | Der finanzielle Schaden führt zu erheblichen Konsequenzen, die der betroffene Straßenbenutzer überwinden kann. | Der operationale Schaden führt zum Verlust oder zur Beeinträchtigung einer wichtigen Fahrzeugfunktion. \\ **Beispiel:** Erhebliche Belästigung des Fahrers. | Der Datenschutzschaden führt zu schwerwiegenden Auswirkungen auf den Straßenbenutzer. Die Informationen über den Straßenbenutzer sind: \\ a) hochsensibel, aber schwer mit einer PII verknüpfbar; oder \\ b) sensibel und leicht mit einer PII verknüpfbar. |
-| **Severe** | **S3** \\ Lebensbedrohliche Verletzungen (Überleben ungewiss), tödliche Verletzungen | Der finanzielle Schaden führt zu katastrophalen Konsequenzen, die der betroffene Straßenbenutzer möglicherweise nicht überwinden kann. | Der operationale Schaden führt zum Verlust oder zur Beeinträchtigung einer zentralen Fahrzeugfunktion. \\ **Beispiel:** Fahrzeug funktioniert nicht oder zeigt unerwartetes Verhalten bei Kernfunktionen wie dem Aktivieren des Limp-Home-Modus oder dem autonomen Fahren an einen unbeabsichtigten Ort. | Der Datenschutzschaden führt zu erheblichen oder sogar irreversiblen Auswirkungen auf den Straßenbenutzer. Die Informationen über den Straßenbenutzer sind hochsensibel und leicht mit einer PII verknüpfbar. |
+^Impact-Kategorie  ^Safety Impact  ^Financial Impact  ^Operational Impact  ^Privacy Impact  |
+|Negligible|S0 – Keine Verletzungen|Keine oder lediglich vernachlässigbare finanzielle Auswirkungen für den betroffenen Straßenbenutzer.|Keine oder nicht wahrnehmbare Beeinträchtigung einer Fahrzeugfunktion.|Keine oder lediglich vernachlässigbare Auswirkungen auf die Privatsphäre. Die betroffenen Informationen sind nicht sensibel und nur schwer mit personenbezogenen Informationen (PII) verknüpfbar.|
+|Moderate|S1 – Leichte bis moderate Verletzungen|Unangenehme finanzielle Auswirkungen, die der betroffene Straßenbenutzer mit begrenztem Aufwand bewältigen kann.|Teilweise Beeinträchtigung oder Degradierung einer Fahrzeugfunktion. Beispiel: Die Nutzerzufriedenheit wird merklich beeinträchtigt.|Unangenehme Auswirkungen auf die Privatsphäre. Die Informationen sind entweder sensibel und nur schwer mit PII verknüpfbar oder nicht sensibel und leicht mit PII verknüpfbar.|
+|Major|S2 – Schwere und lebensbedrohliche Verletzungen (Überleben wahrscheinlich)|Erhebliche finanzielle Auswirkungen, die der betroffene Straßenbenutzer noch bewältigen kann.|Verlust oder erhebliche Beeinträchtigung einer wichtigen Fahrzeugfunktion. Beispiel: Erhebliche Beeinträchtigung oder Belastung des Fahrers.|Schwerwiegende Auswirkungen auf die Privatsphäre. Die Informationen sind entweder hochsensibel und nur schwer mit PII verknüpfbar oder sensibel und leicht mit PII verknüpfbar.|
+|Severe|S3 – Lebensbedrohliche Verletzungen (Überleben ungewiss) oder tödliche Verletzungen|Katastrophale finanzielle Auswirkungen, die der betroffene Straßenbenutzer möglicherweise nicht mehr bewältigen kann.|Verlust oder erhebliche Beeinträchtigung einer zentralen Fahrzeugfunktion. Beispiel: Eine Kernfunktion des Fahrzeugs ist nicht verfügbar oder zeigt unerwartetes Verhalten.|Erhebliche oder irreversible Auswirkungen auf die Privatsphäre. Die betroffenen Informationen sind hochsensibel und leicht mit PII verknüpfbar.|
-**Vulnerability **ist gemäß ISO/SAE 21434 definiert als //„Schwachstelle, die als Teil eines Angriffspfades ausgenutzt werden kann“.//  Die Bewertung der Vulnerability erfolgt anhand der **Attack Feasibility (Angriffsmachbarkeit)**, die als Maß für die //Exploitability//  einer Schwachstelle dient. Die Attack Feasibility beschreibt, wie schwer oder einfach es für einen Angreifer ist, eine bestimmte Schwachstelle auszunutzen, um ein Bedrohungsszenario zu realisieren.
+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.
@@ Zeile 214: / Zeile 217: @@
 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.
-^ Attack feasibility rating ^ Kriterium ^
+^Attack feasibility rating  ^Kriterium  |
-| **High** | **Network:** \\ Der potenzielle Angriffsweg ist an den Netzwerk-Stack gebunden, ohne jegliche Einschränkungen. \\ **Beispiel 1:** Mobilfunkverbindung, die die ECU direkt mit dem Internet verbindet und zugänglich macht. |
+|High|Network: Der potenzielle Angriffsweg ist an den Netzwerk-Stack gebunden, ohne Einschränkungen hinsichtlich der Netzwerkverbindung. Beispiel 1: Mobilfunkverbindung, über die eine ECU direkt mit dem Internet verbunden und erreichbar ist.|
-| **Medium** | **Adjacent:** \\ Der potenzielle Angriffsweg ist an den Netzwerk-Stack gebunden; jedoch ist die Verbindung physisch oder logisch eingeschränkt. \\ **Beispiel 2:** Bluetooth-Schnittstelle, Virtual Private Network (VPN) Verbindung. |
+|Medium|Adjacent: Der potenzielle Angriffsweg ist an den Netzwerk-Stack gebunden, die Verbindung ist jedoch physisch oder logisch eingeschränkt. Beispiel 2: Bluetooth-Schnittstelle oder Verbindung über ein Virtual Private Network (VPN).|
-| **Low** | **Local:** \\ Der potenzielle Angriffsweg ist nicht an den Netzwerk-Stack gebunden, und Bedrohungsakteure benötigen direkten Zugriff auf das System, um den Angriffsweg zu realisieren. \\ **Beispiel 3:** USB-Massenspeichergerät, Speicherkarte. |
+|Low|Local: Der potenzielle Angriffsweg ist nicht an den Netzwerk-Stack gebunden. Bedrohungsakteure benötigen einen lokalen beziehungsweise direkten Zugriff auf das System, um den Angriffsweg zu realisieren. Beispiel 3: USB-Massenspeichergerät oder Speicherkarte.|
-| **Very Low** | **Physical:** \\ Bedrohungsakteure benötigen physischen Zugriff, um den Angriffsweg zu realisieren. |
+|Very Low|Physical: Bedrohungsakteure benötigen physischen Zugriff auf die betreffende Komponente beziehungsweise das System, um den Angriffsweg zu realisieren.|
 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.
@@ Zeile 287: / Zeile 290: @@
 **Bild 4: 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 Datenschutzverletzung.
+**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.
-{{https://safetyandsecurity.vdi.de/_media/content:automotive6.svg?direct&250x226}}
+^  Cybersecurity-Critical Systems  ^^^|
+|  Safety Impact  |  Financial Impact  |  Operational Impact  |  Privacy Impact  |
-**Bild 5: Safety als Untermenge der Cybersecurity**
+**Bild 5:
+ <font 11.0pt/inherit;;inherit;;inherit>Safety als Teil der Cybersecurity-Impact-Bewertung</font> **
 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):
@@ Zeile 323: / Zeile 328: @@
 **Tabelle 14: Lösungsansätze**
-^ Thema / Konzept / Projekt ^ Jahr / Zeitraum ^ Anmerkungen ^
+^Thema / Konzept / Projekt  ^Jahr / Zeitraum  ^Anmerkungen  |
-| Connected Vehicle Systems Alliance (COVESA) | 2009 (Gründung) | 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. |
+|Connected Vehicle Systems Alliance (COVESA)|2009 (Gründung)|COVESA ist eine offene, kollaborative Allianz, die sich auf die Entwicklung offener Standards und Technologien für vernetzte Fahrzeuge konzentriert.|
-| European Union Agency for Cybersecurity (ENISA) | 2004 (Gründung) | 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. |
+|European Union Agency for Cybersecurity (ENISA)|2004 (Gründung)|Die Agentur der Europäischen Union für Cybersicherheit (ENISA) unterstützt das Ziel, ein hohes und gemeinsames Niveau der Cybersicherheit innerhalb der Europäischen Union zu erreichen.|
-| SoQrates | 2003 (Gründung) | SoQrates ist eine Initiative, die zum Ziel hat, ASPICE in die deutsche (Automobil)Industrie hineinzutragen. |
+|SoQrates|2003 (Gründung)|SoQrates ist eine Initiative mit dem Ziel, Automotive SPICE und zugehörige Ansätze zur Prozessverbesserung in der deutschen Automobilindustrie zu fördern.|
-| ENX Association | 2000 (Gründung) | 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. |
+|ENX Association|2000 (Gründung)|Die ENX Association ist ein Zusammenschluss europäischer Automobilhersteller, Zulieferer und Verbände. Ziel ist unter anderem die Förderung eines sicheren unternehmensübergreifenden Informationsaustauschs in der Automobilindustrie.|
-| E-Gas-Überwachungskonzept | 2013 | 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. |
+|E-Gas-Überwachungskonzept|2013|Standardisiertes Drei-Ebenen-Sicherheitskonzept eines Arbeitskreises mehrerer deutscher OEMs in Zusammenarbeit mit Steuergeräteherstellern. Das Konzept dient der Überwachung der Funktion, der Funktionsüberwachung sowie des Steuergeräts selbst.|
-| AUTOSAR | 2003 (Gründung) | 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. |
+|AUTOSAR|2003 (Gründung)|Weltweite Entwicklungspartnerschaft von Automobilherstellern, Zulieferern sowie Unternehmen aus der Elektronik-, Software- und Halbleiterindustrie. Ziel ist die Entwicklung und Etablierung standardisierter Softwarearchitekturen und Schnittstellen für automobile E/E-Systeme.|
-| HIS \\ (Herstellerinitiative Software) | 2001 - 2007 | 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. |
+|HIS (Herstellerinitiative Software)|2001 – 2007|Der Zusammenschluss deutscher OEMs verfolgte das Ziel, harmonisierte Produkt- und Prozessschnittstellen zu definieren und dadurch den Aufwand von Zulieferern bei der Anpassung an unterschiedliche OEM-Anforderungen zu reduzieren.|
-| EVITA \\ (E-Safety Vehicle Intrusion Protected Applications) | 2008 - 2011 (Projektdauer) | 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. |
+|EVITA (E-Safety Vehicle Intrusion Protected Applications)|2008 – 2011 (Projektdauer)|Projekt zur Entwicklung und Verifikation einer sicheren Architektur für automobile Bordnetze. Sicherheitsrelevante Komponenten sollten vor Manipulation und sensible Daten vor Kompromittierung geschützt werden.|
-| SHE, SHE \\ (Secure Hardware Extension) | 2008 | 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 jedem beliebigen Mikrocontroller implementieren. |
+|SHE (Secure Hardware Extension)|2008|Spezifikation einer Hardware-Erweiterung zur geschützten Ausführung kryptografischer Operationen und zur sicheren Speicherung kryptografischer Schlüssel. SHE wurde im Umfeld der Herstellerinitiative Software (HIS) definiert und kann als geschützter Bereich eines Mikrocontrollers umgesetzt werden.|
-| Car Connectivity Consortium (CCC) | 2011 (Gründung) | 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. |
+|Car Connectivity Consortium (CCC)|2011 (Gründung)|Branchenübergreifendes Konsortium zur Entwicklung und Standardisierung von Technologien und Schnittstellen für die Kommunikation zwischen mobilen Endgeräten und Fahrzeugen.|
-| Object Management Group (OMG) | 1989 (Gründung) | 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. |
+|Object Management Group (OMG)|1989 (Gründung)|Internationales Konsortium zur Entwicklung und Standardisierung von Methoden, Sprachen und Austauschformaten für die System- und Softwareentwicklung. Zu den bekannten Spezifikationen gehören unter anderem die Unified Modeling Language (UML), die Systems Modeling Language (SysML) sowie das Austauschformat ReqIF für Anforderungen.|
+===== 5 Wechselwirkungen zwischen Safety und Security im Automotive-Kontext =====
+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**
+^Kategorie^Beziehungsart der Anforderungen^Design-Wechselwirkung^Richtung der Beeinflussung^Beispielhafte Anwendung (Automotive)^Lösungsbeispiel|
+|1|kohärent oder konsistent|nein|keine|Diagnosezugang über ein gesichertes Gateway: Eine Firewall erlaubt ausschließlich authentifizierte Werkstattzugriffe. Dadurch wird die Security erhöht, ohne die Safety-Funktion zu beeinträchtigen.|Parallele Auslegung von Safety und Security, beispielsweise durch Security-by-Design ohne Einfluss auf die Safety-Funktion.|
+|2|widersprüchlich|ja|Security → Safety (unidirektional)|Secure Boot oder eine Signaturprüfung verlängert die Startzeit eines Steuergeräts. Dadurch kann eine sicherheitskritische Funktion, beispielsweise eine Bremsassistenz, verzögert verfügbar sein.|Priorisierung zeitkritischer Safety-Funktionen, beispielsweise durch optimierte Startpfade oder eine szenarienabhängige Aktivierung bestimmter Security-Prüfungen.|
+|3|widersprüchlich|ja|Safety → Security (unidirektional)|Eine Notentriegelung der Türen kann im Crash-Fall den Fahrzeugzugang unabhängig von einer regulären Authentifizierung ermöglichen. Die Security-Funktion der Zutrittskontrolle wird dabei in einem definierten Safety-Szenario gezielt übersteuert.|Zeitlich und funktional begrenzte Freigaben, Logging sowie eine Aktivierung ausschließlich bei eindeutig erkannten Notfallszenarien, beispielsweise einem validierten Crash-Signal.|
+|3|widersprüchlich|ja|Safety → Privacy|Anforderungen an die Innenraumüberwachung können eine Erkennung von Ablenkung, Müdigkeit oder eingeschränkter Fahrtüchtigkeit des Fahrers vorsehen. Daraus können Eingriffe von ADAS-Funktionen wie FCW, AEB, LKA, LDW oder Emergency Stop resultieren. Die dafür erforderliche Innenraumüberwachung kann gleichzeitig Auswirkungen auf Datenschutz und Privatsphäre haben.|Datenminimierung, begrenzte Speicherdauer, lokale Verarbeitung sowie Abstraktion der erfassten Informationen auf die für die jeweilige Fahrzeugfunktion erforderlichen Zustandsinformationen.|
+|4|widersprüchlich|ja|Safety ↔ Security (bidirektional)|Keyless-Systeme verbinden Komfort und Diebstahlschutz mit Safety-Anforderungen an einen möglichen Fahrzeugzugang im Notfall, beispielsweise bei leerer Fahrzeugbatterie oder nach einem Unfall.|Richtungs- und szenarioabhängige Entkopplung, beispielsweise durch einen mechanischen Notschlüssel oder einen definierten Notfallzugang.|
+|4|widersprüchlich|ja|Safety ↔ Security (bidirektional)|Bei einem OTA-Softwareupdate kann eine fehlgeschlagene Signatur- oder Zertifikatsprüfung die Installation aus Security-Gründen verhindern. Gleichzeitig darf der Update-Prozess sicherheitskritische Funktionen während des Fahrzeugbetriebs nicht beeinträchtigen.|Szenarioentkopplung, beispielsweise Updates nur im Parkzustand, A/B-Update-Strategien, sichere Fallback-Mechanismen und eine definierte Priorisierung sicherheitskritischer Updates.|
+==== Exemplarisches Beispiel: Widerspruch zwischen Safety und Security bei Software-Updates ====
+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.
+=== Security-Anforderungen ===
+  * 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.
+=== Safety-Anforderungen ===
+  * 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.
+=== Typische Zielkonflikte ===
+  * 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.
+=== 1. Szenarioentkopplung ===
+Eine zentrale Maßnahme ist die Trennung unterschiedlicher Betriebs- und Update-Szenarien.
+=== Fahrbetrieb – Safety dominiert ===
+  * 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.
+=== Stillstand oder Parkzustand – Update-Prozess ===
+  * 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.
+=== 2. Technische Maßnahmen ===
+=== A/B-Update-Strategie ===
+  * 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.
+=== Graceful Degradation ===
+  * 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.
+=== Fallback-Mechanismen ===
+  * 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.
+=== Priorisierung sicherheitskritischer Updates ===
+  * 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.
+=== 3. Architektonische Maßnahmen ===
+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.
+===== 6 Welche Rolle spielt Künstliche Intelligenz im Zusammenspiel von Automotive Safety und Security? =====
+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.
+==== Neue Herausforderungen durch KI ====
+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.
+==== Wechselwirkung zwischen Safety und Security ====
+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.
+==== Relevante Standards ====
+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.
 ===== Weitere Quellen =====