Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
content:automotive [2026/09/09 19:04] – termin_neucontent:automotive [2026/09/10 09:11] (aktuell) – [Exemplarisches Beispiel: Widerspruch zwischen Safety und Security bei Software-Updates] vdiadmin
Zeile 1: Zeile 1:
-====== Automobilbereich - Safety & Security ======+====== 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. 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.
Zeile 178: Zeile 178:
  
 | |
 +
 +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** **Tabelle 8: Impact-Kategorisierung nach ISO/SAE 21434**
  
-^Severity class  ^Safety  ^Financial  ^Operational  ^Privacy  | +^Impact-Kategorie  ^Safety Impact  ^Financial Impact  ^Operational Impact  ^Privacy Impact  | 
-|**Negligible** |**S0** \\ +|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.| 
-   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|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.| 
-|**Moderate** |**S1** \\ +|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.| 
-   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: \\ +|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.|
-   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.|+
  
-**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. 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 223: 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. 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:** \\ +|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.| 
-   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.| +|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).| 
-|**Medium** |**Adjacent:** \\ +|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.| 
-   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.| +|Very Low|Physical: Bedrohungsakteure benötigen physischen Zugriff auf die betreffende Komponente beziehungsweise das System, um den Angriffsweg zu realisieren.|
-|**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.| +
-|**Very Low** |**Physical:** \\ +
-   Bedrohungsakteure benötigen physischen Zugriff, 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. 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 338: Zeile 328:
 **Tabelle 14: Lösungsansätze** **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 Standards und Technologien für vernetzte Fahrzeuge konzentriert.| |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) unterstützt das Ziel, ein hohes und gemeinsames Niveau der Cybersicherheit innerhalb der Europäischen Union zu erreichen.| |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.|
Zeile 345: Zeile 335:
 |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.| |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 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.| |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 \\ +|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.| 
-   (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)|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.| 
-|EVITA \\ +|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.|
-   (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.|+
 |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.| |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)|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.| |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.|
-|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.| 
-| | | | 
  
-===== 5. Wechselwirkungen zwischen Safety und Security im Automotive-Kontext =====+===== 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. 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.
Zeile 470: Zeile 456:
 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. 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? =====+ 
 +===== 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. 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.
  • Zuletzt geändert: 2026/09/09 19:04
  • von termin_neu