Elektroniknet Logo

ISO/SAE 21434

Cybersecurity im Fahrzeug


Fortsetzung des Artikels von Teil 2

"...gemeinsames Vokabular für die Security..."

Dennoch betont auch Roermond, dass die Norm dazu beiträgt, ein gemeinsames Verständnis und einen gemeinsamen Ansatz in der gesamten Lieferkette zu schaffen, da sie ein gemeinsames Vokabular für die Security im Automobilbereich bereitstellt und klare organisatorische und prozedurale Anforderungen für den gesamten Lebenszyklus eines Fahrzeugs festlegt, vom Konzept und der Entwicklung über die Produktion, den Betrieb und die Wartung bis hin zur Stilllegung. Insbesondere werde ein Security-by-Design-Ansatz gefordert, der bereits in den frühesten (Konzept-)Phasen der Produktentwicklung beginnt, »was für das Erreichen solider Security-Konzepte und -lösungen unerlässlich ist«, so Roermond.

Die neue UN-Vorschrift R155 verlangt von den OEMs ein zertifiziertes Cybersicherheits-Managementsystem (CSMS), um die Cybersicherheit von Fahrzeugen zu verwalten, und die Zulieferer müssen die OEMs dabei unterstützen, nachzuweisen, dass zuliefererbezogene Risiken im Rahmen des CSMS identifiziert und gehandhabt werden. Die Einhaltung von R155 wird ab Juli 2022 in Europa, Japan und Korea schrittweise zur Erlangung der Fahrzeugtypgenehmigung erforderlich sein. Roermond weiter: »Der ISO/SAE-Standard wird die Organisationen entlang der Lieferkette bei der Umsetzung der UN-R155-Anforderungen sehr unterstützen. Daher wird die Einhaltung von ISO/SAE 21434 für Zulieferer, einschließlich Halbleiterherstellern wie NXP, erforderlich sein.«

Was das in der Praxis für einen Halbleiterlieferanten bedeutet und wie viel Anpassung in der Arbeitsweise nötig ist, hängt aus der Sicht von Roermond von der Ausgangssituation ab. Für NXP fallen die Änderungen laut seiner Aussage relativ gering aus. Schon vor der Einführung von ISO/SAE 21434 habe das Unternehmen ein Prozess-Framework für die Produktentwicklung etabliert, das sowohl Security-by-Design- als auch Safety-by-Design-Ansätze umfasst, letztere in Übereinstimmung mit ISO 26262.

Roermond weiter: »Zwischen funktionaler Sicherheit, also ISO 26262, und Security, sprich: ISO/SAE 21434, sollte ein regelmäßiger Austausch stattfinden, mit gegenseitigen Überprüfungen, um sicherzustellen, dass sowohl die Security- als auch die Safety-Ziele erreicht werden, und um zu gewährleisten, dass das Security-Konzept und die damit erforderlichen Gegenmaßnahmen die funktionale Sicherheit nicht negativ beeinflussen oder umgekehrt.«

McKinsey
Studie »Cybersecurity in automotive« (Cybersecurity-in-automotive-Mastering-the-challenge.pdf, Seite 7)
© McKinsey

Beide Disziplinen erfordern eine Risikobewertung während der Konzept- und Entwurfsphase. Risiken, die im Zusammenhang mit der funktionalen Sicherheit auftauchen, bleiben jedoch während der gesamten Produktlebensdauer weitgehend statische Parameter, sodass die Risikobewertung nach ihrer Fertigstellung normalerweise nicht aktualisiert werden muss. »Im Security-Bereich ist das Risiko ein Parameter, der sich im Laufe der Zeit verändert, manchmal in unvorhergesehenen Größenordnungen«, so Roermond. Denn Security ist ein „Moving Target“, es werden einerseits immer wieder neue Schwachstellen entdeckt und andererseits werden auch die Tools zum Auffinden und Ausnutzen von Schwachstellen mit der Zeit immer ausgefeilter und erschwinglicher. Roermond: »Die Geschichte hat gezeigt, dass selbst die intelligentesten Gegenmaßnahmen zu einem späteren Zeitpunkt mit neuen und innovativen Tricks und besseren Werkzeugen umgangen wurden.«

Deshalb müsse die während der Produktentwicklung durchgeführte Security-Risikobewertung auf den neuesten Erkenntnissen und dem aktuellen Stand der Technik beruhen. Und die Risikobewertung muss möglicherweise in späteren Phasen des Produktlebenszyklus aktualisiert werden, da sich die Bedrohungslandschaft ändern kann. Aus diesem Grund fordert ISO/SAE 21434 kontinuierliche Aktivitäten zur Überwachung der Cybersecurity sowie zur Analyse und zum Management von Schwachstellen. Roermond: »Bei NXP beobachten wir ständig die Bedrohungslandschaft und sind bestrebt, unsere Security-Expertise auszubauen, um Veränderungen auf der Angriffsseite besser beherrschbar zu machen. Wir haben einen ausgereiften Prozess zur Reaktion auf Sicherheitsvorfälle und ein Team, das sich um Sicherheitsvorfälle kümmert, wenn sie auftreten.« In diesem Zusammenhang betont er: »Es hat sich ganz klar gezeigt, dass Systeme, die mehrere Abwehrschichten und Security-by-Design-Konzepte verwenden, am längsten überleben. Wir glauben, dass die Einbeziehung dieser Konzepte in einen Produktentwicklungsprozess das beste Rezept ist, um sich auf das Unbekannte vorzubereiten.«
Bei der Safety gibt es verschiedene Klassen (ASIL A bis D), und auch bei der Security gibt es mit Cybersecurity Assurance Level (CAL) ein Klassifizierungsschema, das verwendet werden kann. Ob sich dieses spezielle Schema durchsetzen wird, bleibt aber aus der Sicht von Roermond abzuwarten.


  1. Cybersecurity im Fahrzeug
  2. Infineon Technologies
  3. "...gemeinsames Vokabular für die Security..."
  4. STMicroelectronics

Verwandte Artikel

NVIDIA Corporate, STMicroelectronics GmbH, INFINEON Technologies AG Neubiberg