| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| content:automotive [2026/09/09 18:50] – alte Version wiederhergestellt (2025/11/24 17:13) termin_neu | content:automotive [2026/09/10 09:11] (aktuell) – [Exemplarisches Beispiel: Widerspruch zwischen Safety und Security bei Software-Updates] vdiadmin |
|---|
| ====== 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. |
| |
| ^Kennung^Jahr^Titel^Anmerkung| | ^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.| |
| Ein ** | |[[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.| |
| E/E-System (Elektrik/Elektronik) ** | |[[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.| |
| 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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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.| |
| |[[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://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.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.| | |
| |
| **Tabelle 3: Weitere relevante Normen und Richtlinien** | **Tabelle 3: Weitere relevante Normen und Richtlinien** |
| |
| | | | |
| | |
| | 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** \\ 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.| | |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|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.| | |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)|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.| | |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), 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.| | |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. | 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. |
| 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:** \\ 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. | 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. |
| |
| **Bild 5: | **Bild 5: |
| <font 11.0pt/inherit;;inherit;;inherit>Safety als Teil der Cybersecurity-Impact-Bewertung</font> ** | <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): | 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 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 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 \\ | |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|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.| | |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)|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.| | |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.| |
| |SHE, SHE \\ | |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.| |
| (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.| | |
| |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.| | |
| |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.| | |
| |
| ===== 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. |
| 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. |