Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- content:automotive [2026/09/09 19:13] – termin_neu
+++ content: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.
@@ Zeile 217: / 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:** \\
+|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.
@@ Zeile 345: / Zeile 341: @@
 |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.
@@ Zeile 460: / 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.
-===== 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.