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:10] – 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 184: Zeile 184:
  
 ^Impact-Kategorie  ^Safety Impact  ^Financial Impact  ^Operational Impact  ^Privacy Impact  | ^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|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.| 
-|**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|Unangenehme finanzielle Auswirkungen, die der betroffene Straßenbenutzer mit begrenztem Aufwand bewältigen kann.|Teilweise Beeinträchtigung oder Degradierung einer Fahrzeugfunktion. \\ +|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.|
-   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 ein unerwartetes Verhalten.|Erhebliche oder irreversible Auswirkungen auf die Privatsphäre. Die betroffenen Informationen sind hochsensibel und leicht mit PII verknüpfbar.|+
  
 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. 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.
Zeile 224: 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 346: 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.| +
-|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)|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.|
  
-===== 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:10
  • von termin_neu