UNECE R155 – Wie sicher ist euer Auto gegen Cyberangriffe und Hacks?

Es hilft ja nichts, wir müssen zuerst technisch werden und uns an spezifische Definitionen halten. Die UNECE R155 liest sich vollständig bezeichnet folgendermaßen: „Proposal für a new UN Regulation on uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system”. Dies bedeutet, dass künftig neue und spezifische Vorgaben für die Sicherheit von aktuellen (und ab 2024 auch älteren) Fahrzeugtypen gegen Cyber-Angriffe gelten. Macht Sinn – das Fahrzeug als „Rolling Device“, als, so gesehen, durchaus wuchtiges Internet of Things Modul, steckt inzwischen voller Software, hat ein Betriebssystem, erfährt over-the-air-updates. Es besteht also potentieller Raum für Angriffe, der von den Fahrzeugherstellern abgesichert werden muss – nun auch verpflichtend, in Form der UNECE R155. Die Haftung endet nun also nicht mehr am Rand des Fahrzeugs, und auch nicht mehr für nur einen kurzen Zeitraum.

Stattdessen fordert die neue Regelung, dass Fahrzeughersteller ein Cyber Security Management System, kurz meist nur „CSMS“ bezeichnet, bereitstellen sowie nachweisen müssen, dass dieses auch tatsächlich funktioniert. Dies ist sogar zulassungsrelevant – ohne den Nachweis ist keine Typgenehmigung für den entsprechenden Fahrzeugtypen möglich.

Das betreffende CSMS muss dabei unter anderem schon auf Konzeptebene Prozesse zur Risiko-Erkennung enthalten, diese bewerten und gegebenenfalls beseitigen oder zumindest mindern können. Wir sprechen im Folgenden noch darüber, wie sich dies beispielsweise unterschiedlich auf Endkunden-Fahrzeuge auswirkt, verglichen mit einer ganzen Fahrzeugflotte. So müssen Angriffe, die bekannt geworden sind, weitergegeben werden, Updates müssen geschrieben werden – hier flankiert die UNECE R156 die Neuregelung; dazu mehr im folgenden Absatz.

Zu guter Letzt muss ein unabhängiges Prüfinstitut, denkbar wäre eine Institution wie der TÜV, ein Assessment durchführen, um einen Nachweis zu erbringen, dass das CSMS den Vorgaben der R155 entspricht. Nur mittels dieses Nachweises ist eine Typzulassung für das geprüfte Fahrzeug möglich. Es versteht sich praktisch von selbst, dass dies gewaltige Herausforderungen für eine Branche birgt, die in diesen Punkten selbst noch in den Kinderschuhen steckt. Expertise muss auf Prüfseite wie auf Herstellerebene bestehen, Infrastrukturen müssen gebildet werden, und was die Zeit bringen wird, ist kaum abzusehen. Denn die R155 sieht vor, dass die Absicherung gegen Cyber-Angriffe für die gesamte Lebensdauer des Fahrzeugs gilt. Zwar werden klassische PKWs im Durchschnitt lediglich 10 Jahre betrieben. Einzelne Exemplare überdauern aber viel länger, teils Jahrzehnte lang, und selbst mit einer Oldtimer-Zulassung wäre der Hersteller noch immer verantwortlich für die Cybersicherheit des Fahrzeugs, bis auch das letzte Fahrzeug dieses Typs nicht mehr aktiv im Straßenverkehr betrieben wird. Das ist, wir sagen es ganz profan: Eine verflixt lange Zeit. Wir gehen am Ende des Artikels auf die offensichtlichen Probleme ein, die diese Regelung mit sich bringt – zunächst sehen wir uns noch die begleitenden Regularien R156 und ISO/SAE 21434 an.

UNECE R156 – Spaß mit Steuergeräten im Zusammenhang mit R155

Zugegeben, der Zusammenhang ist offensichtlich: Zur Absicherung von Cyber-Angriffen, vor allem nach Bekanntwerden bestimmter Angriffsmuster, wird es nötig sein, Steuergeräte (und weitere elektrische/elektronische Elemente an Bord) mit Updates zu versehen. Dies kann in bestimmten Intervallen in der Werkstatt geschehen, muss aber in kritischen Fällen auch schnell over-the-air erfolgen können. Die Handlungsfähigkeit gegenüber Cyber-Angriffen ist ein wesentlicher Punkt der schon besprochenen R155. Ausgesprochen nennt sich die zusätzliche Regelung mit der Bezeichnung R156: „Proposal für a New UN Regulation on Uniform Provisions Concerning the Approval of Vehicles with Regards to Software Update and Software Update Management System” und ist eine weitere Regelung der UNECE (Wirtschaftskommission für Europa), die den künftigen Umgang mit Updates der Steuergeräte-Software bestimmt.

Wie bei der R155 ist auch hier wieder ein Management-System erforderlich, und zwar ein „Software Update Management System“, kurz „SUMS“. Auch in diesem Fall muss die Funktionalität von einem von der Zulassungsbehörde akzeptierten Prüfungsinstitut nachgewiesen werden, damit eine typspezifische Zulassung erteilt wird. Hierzu soll, ähnlich wie zur R155, begleitend eine neue ISO helfen: ISO 24089 (mit Stand am 26.07.2022 ist diese noch im Entwurfsmodus) wird Maßnahmen beschreiben, die der Industrie helfen, die Vorgaben der R156 umzusetzen. Zweck der Regelung ist, dass Software-Updates von Funktionen, die zulassungsrelevant sind (wie z.B. Abgas, Bremsen, Motorsteuerung) auch nach dem Update unverändert gesetzeskonform sind, sowie dass die Updates „safe and secure“ sind. Das bedeutet weitestgehend, dass die Updates vor Fehlfunktionen und Bugs geschützt sein sollten (wie zum Beispiel das Auslösen des Airbags aufgrund heftiger Beschleunigung) und manipulationssicher sind. Selbst, wenn ein Update fehlschlägt, muss die Grundfunktion weiterhin sicher und problemlos abrufbar sein.

ISO21434 – Wie Hersteller und Zulieferer neue Haftungs-Wege finden und Verantwortung teilen

Wer UNECE R155 und R156 sagt, muss auch ISO 21434 sagen. Der Name „ISO“ nimmt es dabei vorweg: Hier handelt es sich nicht um ein Gesetz, sondern einen Standard für „Road Vehicles – Cybersecurity Engineering“ in Kraftfahrzeugen. Diese neue Norm soll für Komponenten in Serienfahrzeugen sowie für Ersatzteile und Zubehör gelten und umfasst Entwicklung, Produktion, Betrieb, Wartung und Recycling über den gesamten Lifecycle des Fahrzeugs hinweg. An diesem Standard beteiligt sind die Internationale Organisation für Normung (ISO) sowie die SAE International, wobei „SAE“ für „Society of Automotive Engineers“ steht. Die ISO 21434 ist also vor allem eine Norm für die Zuliefererindustrie. So wird sichergestellt, dass alle zugelieferten Komponenten ihren Teil dazu beitragen, dass der beauftragende OEM die Einhaltung der R155 und R156 sicherstellen und somit eine Zulassung für den betreffenden Fahrzeugtypen erhalten kann.

Was bedeuteten die neuen Gesetze (R155, R156) und Normen (ISO 24089, ISO 21434) für die Automobilbranche?

Völlig neu für die gesamte Industrie ist, dass sich Hersteller nun über das gesamte Autoleben hinweg um die Cyber Security des Fahrzeugs kümmern müssen. Wir reden also nicht von der Wartung einer x-beliebigen Krypto-Library, sondern vom gesamtem Lifecycle des Produkts Automobil – und das betriffft nicht nur die verbauten Materialien, sondern geht hinein bis in die Cloud. Dies zieht ein komplettes Security-Monitoring (und den Aufbau der zugrundeliegenden Infrastruktur) nach sich. Fahrzeugdaten müssen in regelmäßigen Abständen (die erst noch definiert werden müssen) ausgelesen werden, beispielsweise indem der Fehlerspeicher bei Wartung in der Werkstatt ausgelesen wird. Doch auch das ständige Prüfen der Online-Verbindung wird nun erforderlich, möglicherweise täglich, inklusive einer Analyse auf Auffälligkeiten hin. Dass sich dabei viele Daten in dedizierten Steuergeräten befinden, die zunächst zusammengeführt und in ein einheitliches Datenbild gebracht werden müssen, ist nur eine der vielen spannenden Herausforderungen auf dem Weg zur Einhaltung der UNECE-Regelungen. Sicherlich – die Daten gibt es alle schon im Fahrzeug. Bislang wurden diese indes oftmals nicht gespeichert oder einfach als irrelevante Zahlen verworfen. Nun können aber völlig neue Auffälligkeiten entstehen – ein Steuergerät sendet plötzlich ständig kleine Fehler zum anderen, Nachrichten werden gesendet: Fehlfunktion, oder Phishing-Attacke? Eine zusammenhängende Bewertung dieser bisher weitestgehend isolierten Daten wird somit unbedingt erforderlich.

Der Jeep Cherokee Hack und dessen Folgen für die Automotive Cybersecurity

Dass der Schritt hin zu mehr Cybersecurity, zu mehr Funktionaler Sicherheit hin ein sinnvoller ist, steht außer Frage. Man denke an die Black Hat USA 2015, bei der Charlie Miller und Chris Valasek erklärten, wie sie praktisch vom Sofa aus das WLAN des Jeep Cherokee hacken konnten, da das zugehörige Passwort auf der Zeit der ersten Anmeldung basierten und somit herausgefunden werden konnte. In diesem Hack konnten die Forscher den Musikplayer kontrollieren, Sender verändern, Lautstärken ändern. Klingt harmlos, kann bei Tempo 150 auf der Autobahn aber erschrecken und für Gefahrenmomente und Ablenkung sorgen. Doch auch Lenkrad, Motor, Getriebe, Bremssystem, Scheibenwischer, Klimaanlage und Türschlösser wurden von Miller und Valasek mit einem vergleichsweise einfachen Hack kontrolliert, und zusätzlich konnten die GPS-Daten praktisch jedes Jeep Cherokee bestimmt werden. Die Möglichkeiten zum Missbrauch waren erheblich. Dieser Moment schreckte eine ganze Industrie samt Politik auf, da man sich bis dahin kaum bewusst war, in welchem Umfang – und mit welch teils simplen Mitteln – brutale Hacks vorgenommen werden konnten.

Schließlich geht es nicht nur um die Steuerung der Fahrzeuge; auch die Masse an persönlichen Daten, von Personendaten bis Kreditkartendaten der Endnutzer, ist von hohem Interesse für Cyberkriminelle. Sicher – für den Hack brauchten die Forscher Jahre, und wichtige Feldversuche sind nicht geglückt, wie die Verwaltung der mit dem CAN-Bus verknüpften Komponenten. Aber es war ein deutliches Zeichen, dass die neuen Möglichkeiten im Fahrzeugbau auch völlig neue Möglichkeiten von Nutzen und Missbrauch der Cybersecurity mit sich brachten – und dass Handlungsbedarf besteht, damit die Industrie nicht den Anschluss an den technischen Standard und somit an das Vertrauen der Nutzer verliert.

Alarmzustand dank UNECE R155: Und wer macht das in 20 Jahren?

Die Geschichte der Cyberindustrie im Rahmen der Automobilbranche ist durchaus eine besondere. Um zu verstehen, wieso nun helle Aufregung in der Branche herrscht und praktisch jeder Hersteller plötzlich von intensiver Intrusion Detection spricht, muss man die Situation vor 2015 und dem Jeep-Hack kennen. Das heutige Auto als Endprodukt ist im Grunde ein rollendes Internet of Things Device, tonnenschwer, von Menschen umgeben. Kaum vorstellbar, welche tragische Folgen der Hack der Motorsteuerung und eine damit einhergehende, vom Fahrer nicht aufhaltbare Beschleunigung auslösen könnte. Sicherheits-Konzepte, die außerhalb der Branche durchaus bekannt und etabliert sind, erobern daher nun auch die Automobil-Industrie, wie die schon genannte Intrusion Detection, TARA (Threat and Risk Assessment) oder CVE (Common Value Evaluator). Diese Konzepte stellen einen gewaltigen Schritt für die Industrie dar. Hersteller wussten mitunter nicht mal im Detail, welche Software an welcher Stelle im Fahrzeug verbaut wurde – was auch nicht nötig war, dafür gab es ja schließlich Zulieferer. Der beinahe schon „heilige Gral“ in Sachen Identifikation war die Hardware-Teilenummer, und auch Zulieferer verfolgten diese kaum nach. Es war sicherlich noch bekannt, welcher weitere Zulieferer aus der Kette die entsprechende Software für ein bestimmtes Steuergerät lieferte. Aber welche Version genau, wusste kaum jemand, was ein entsprechendes Monitoring nahezu unmöglich machte.

Dass Software nun überhaupt erstmal als eigenes Asset anerkannt und verwaltet wird, ist ein enorm wichtiger Schritt für die Industrie. Für deren Verwaltung gehören nun das komplette Tooling erstellt, Spezialwissen erarbeitet, technische Möglichkeiten ausgelotet. Gerade im Bereich der Embedded Software kommen klassische IT-Systeme nicht weiter, so dass neue Optionen geschaffen werden müssen, damit auch statisch generierte, voll optimierte Codes in kleinen Standardsteuergeräten berücksichtigt werden für Monitoring, Updates, Wartung. Hierfür ist die Software zu kennen, die idealerweise nun beispielsweise wöchentlich mit einem Blick in eine entsprechende Datenbank geprüft werden kann.

Um ein praktisches Beispiel zu nennen, sagen wir einfach, Tier 1 Zulieferer XX entwickelt ein Steuergerät, mit dem auch einiges an Software geliefert wird. XY muss sich vollständig darüber im Klaren sein, welche Software genau das ist, und muss in der Lage sein, verschiedene Quellen wie CVE Datenbanken, Cybersecurity-Listen etc. anzuzapfen, um nach „Known Issues“ zu suchen: Gibt es hier neue Ergebnisse, ganz ohne Auslesen von Daten, sondern einfach durch die Bekanntmachung auftretender Probleme anhand ausgelieferter Fahrzeuge? Taucht hier etwas Neues auf, muss dies gemeldet, analysiert und gegebenenfalls behoben werden, optimalerweise direkt und over the air – und das über den gesamten Lebenszyklus des Fahrzeugs. Dies ist definitiv eine der größten Herausforderungen: Wie stellt man ein solches Monitoring inklusive Reaktionsfähigkeit über 30 Jahre sicher? Sind die benötigten Schnittstellen in 20 Jahren überhaupt noch verfügbar? Gibt es die Betriebssysteme noch, gibt es noch die Spezialisten in der Branche, die das nötige Fachwissen aufweisen? Es gibt hier keine Erfahrungen, da die Regelung viel zu neu ist, als dass auch nur ein einziger Fahrzeugtyp das Ende seines Lebenszyklus erreicht haben könnte. Wer haftet also nach 25 Jahren für einen Softwarefehler? Was macht die Branche, wenn essenzielle Hardware-Innovationen den Markt erobern wie beispielsweise Quantencomputer? Dann sind die vorhandenen Steuergeräte, die jetzigen Rechner und die Algorithmen aktueller Cybersecurity kaum noch die damaligen Produktionskosten wert. Um hier weiter für die Sicherheit garantieren zu können, kommt man um einen physischen Austausch von Steuergeräten im Fahrzeug nicht herum. Aber wie lässt sich dies für einen 20 Jahre alten Fahrzeugtypen umsetzen?

Lösungsansätze, oder: Wieso die Branche an ihren Herausforderungen wachsen kann

Natürlich: Bis hierher klingt der Rauch rund um das Feuer der UNECE R155 ein wenig nach dem Wehklagen einer Industrie, die sich in der Vergangenheit nicht immer und nicht in allen Belangen mit der nötigen Voraussicht bewegt hat, keine Frage. Der Titel des Artikels kommt nicht von ungefähr – es ist eine Geschichte der teilweisen Vernachlässigung von zukunftsträchtigen und dauerhaft sicheren Konzepten. In diesem Wort liegt aber auch einer der Schlüssel: Konzepte. Während klassische Algorithmen in der Security im Fahrzeug bislang sagten „Ja“ oder „Nein“, „Richtig“ oder „Falsch“, kann nun eine Anomalie auftreten, die ungefähr sagt: „Du, da ist irgendwas irgendwie komisch“. Das ist interpretierbar und wenig konkret. Gut aufgestellte Zulieferer indes bereiten sich auf diese Szenarien vor, vor allem in den Bereichen Data Science und Cloud IT aufgestellte Unternehmen wie beispielsweise die Cognizant Mobility. Hier ist man seit jeher auf Skalierbarkeit und Erweiterbarkeit getrimmt, und die aus dem umfangreichen Anforderungsmanagement in zahlreichen Projekten für namhafte OEMs bekannten Konzepte, die die Zukunft berücksichtigen, lassen sich um die Vorgaben für UNECE R155 / R156 bzw. ISO 21434 erweitern. Natürlich nicht mit einem Fingerschnippen, aber sind wir doch mal ehrlich: Auch die Reise macht Spaß. Wir sind Menschen, Entdecker, Forscher – die Terra Incognita ist gar nicht so unbekannt, und sie ist verlockend. Neue Konzepte müssen nicht entwickelt werden, nein: Wir dürfen diese entwickeln, für Sicherheit sorgen, und ein rundum großartiges Produkt auf die Straße bringen, und gemeinsam an den Herausforderungen wachsen. Die Aggregation von Fehlerbildern über ein Flottenbild ist ein solcher Ansatz, bei dem das Monitoring nicht auf Fahrzeugebene stattfindet, sondern auf Flottenebene. Das kann natürlich im Einzelfall nicht immer verhindern, dass ein Einzelfahrzeug angegriffen wird, die Ausbreitung von allem, dass ein größeres Bild ergibt, kann aber schon jetzt effizient gestoppt werden. Eine extrem wichtige Basis für die kommenden UNECE R155 Regularien.

Auch das „End of Life” des Fahrzeugtyps muss völlig neu bewertet werden. Früher war das einfach: Wurde das letzte Fahrzeug seines Typs auf dem Schrottplatz abgegeben, war es das. Rein in die Presse, Würfelchen pressen, fertig. Heute gibt es im Auto allerdings zahlreiche Datenanbindungen. Fast jedes Auto kann auf OEM Systeme zugreifen, Daten werden geschickt und empfangen, und ein Hack der Systeme, der zugrundeliegenden Cloud, wäre denkbar. Das definitive Ende des Fahrzeugs wird also auch ein kryptographisches Ende sein, entsprechende Systeme müssen unzugänglich gemacht werden. Auch dies muss dank UNECE R155 also künftig berücksichtigt werden – wo sind meine Schnittstellen, wo meine Anschlussstellen, und wie sichere ich diese und wie deaktiviere ich diese am Ende des Lebenszyklus des Fahrzeugs

Diese Vorteile hat die Auto-Industrie gegenüber der UNECE R155/R156

Völlig neu in den Regularien ist, dass Cybersecurity und Updates nun zulassungsrelevant sind. Dafür muss der Nachweis erbracht werden, dass der Hersteller sich vollumfänglich vorbereitet hat und bereit ist, sich auch weiterhin zu kümmern. Interessanterweise ist nur eines davon auch wirklich möglich, nämlich der Nachweis der Vorbereitung. Ob es einem OEM gelingt, sich wirklich komplett zu kümmern, muss sich zeigen, denn hierfür fehlen aktuell noch jegliche Erfahrungswerte, da einfach noch nicht genug Zeit vergangen ist, als dass ein Fahrzeugtyp, der unter die UNECE Regeln fällt, das Ende seines Lebenszyklus erreicht hat. Reden wir in 30 Jahren nochmal drüber.

Dennoch gibt es erste Autohersteller, die den Nachweis für einzelne Typen bereits erbracht haben. Hier besteht auch noch ein gewisser Graubereich in den UN-Vorgaben, da es noch Übergangsfristen gibt, die sich teils nur auf komplett neue Fahrzeugtypen beschränken oder auf Abwandlungen von bestehenden Typen. Was aber wirklich auf die OEMs zukommt, weiß noch niemand so richtig.

Vor allem die Reaktionsfähigkeit – ein wichtiger Teil der UNECE R155 / R156 – muss gewährleistet sein und birgt aus den beschriebenen Punkten die größten Herausforderungen, schon, da sich Hardware und Software über die Jahre hin rasant und essenziell verändern.

Die Industrie ist aber dennoch nicht hilflos. Erfahrungen aus dem Safety-Bereich können in den Security-Bereich übertragen werden, vor allem aus dem Bereich der Funktionalen Sicherheit. Natürlich gibt es Unterschiede, aber das Basis-Konzept, beispielsweise ein Thread and Risk Assessment (TARA) zu erstellen, ist in der Basis nicht komplett neu. Unternehmen, die schon vorher stark aufgestellt waren im Bereich Safety, sind auch für die Lebenszyklus-Haftung der Security geeignet und können hier sicherlich schneller adaptieren als andere Zulieferer oder gar große Original Equipment Manufacturer.

Mach doch mal vor: UNECE R155/R156 und ISO 21434 und ihre Herausforderungen

Dass trotz des Lichts am Ende des Haftungstunnels noch Schwellen auf den Gleisen liegen, die zum Stolpern animieren mögen, ist offensichtlich. Schon die Frage der Marge ist eine interessante: Dem Endpreis eines Fahrzeugs liegt eine Kalkulation zugrunde, die mit den neuen Vorgaben hinfällig ist. Wer trägt die Mehrkosten, die durch den Aufbau einer ganzen Infrastruktur inklusive Tooling, Fachkräften und jahrzehntelang funktionalen Systemen entstehen? Die durch Wartung, Analyse und Reaktion weiter nach oben getrieben werden? Den Endnutzer zu einer freiwilligen Cyber-Pauschale zu verdammen, kann kaum die Lösung sein. Werden Kunden überhaupt bereit sein, in einigen Jahren Abo-Pakete im Auto zu buchen, die mehr oder weniger Funktionalität versprechen? Oder werden Autofahrer nur in den bisher bekannten Ausstattungspaketen denken? Die Umsetzung von UNECE R155 und R156 muss also im Grunde kostenlos durchführbar sein, oder doch mit den vorhandenen Bordmitteln – völlig realitätsfern, versteht sich. Es ist also neben der reinen Umsetzung eine dringliche Aufgabe der Industrie, hier faire Lösungen zu finden, ein Modell mit Prädikat „one fits all“ – denn ohne Zulieferer, die die Anforderungen erfüllen können und dafür Teil der Preisgestaltungsstruktur sind (mehr denn je), sind auch die OEMs nicht in der Lage, Zulassungen für ihre Produkte zu erzielen.

Weitere Hürden auf dem Weg sind auch noch viele der offenen Punkte, die die UNECE Regeln aufweisen. Schon die Frage, wann ein OEM denn wirklich nachweisen kann, dass er für R155 vorbereitet ist, ist einigermaßen komplex. Auf wie viele Angriffe welcher Natur muss man vorbereitet sind, um wirklich „bereit“ zu sein? Immerhin beschränkt sich die Sicherheitshaftung ja nicht nur auf das Auto, sondern dank R156 auch auf die Backend-Systeme. Deren heutiger Stand in 15 Jahren sicherlich völlig veraltet sein wird – und Experten für die Bedienung veralteter Systeme werden auch nicht leichter zu finden als das schon heute der Fall ist, Fachkräfte werden schließlich jetzt schon heiß umworben. Was tun mit veralteter Hardware, weil Quantencomputer völlig andere Optionen bieten, sowohl im Angebot für OEM und Endkunden als auch für Angreifer? Für einen Quantencomputer wären aktuelle Sicherheitsalgorithmen kaum mehr als ein Witz. Komplett neue Strukturen in der Sicherheit sind also vonnöten. Das wären sie allerdings so oder so, ist also sicher eines der kleineren Probleme – vorhanden ist es aber nichtsdestotrotz – und bringt direkt noch mehr Sorgen im Gepäck mit. Um sich neuen kryptographischen Herausforderungen stellen zu können, werden Hardware-Teile getauscht werden müssen, vor allem jene mit zeitkritischen Aufgaben, wie Steuergeräte für Bremsen, Lenkung oder Motorsteuerung.

Auch ist noch gar nicht klar, ob die Prüfungen, inwiefern ein Fahrzeugtyp R155 und R156 entspricht, dann nur typspezifisch möglich sind, oder ob zyklische Prüfungen des gesamten Unternehmens denkbar wären. Und dann gibt es noch ein gemeines Schlupfloch, das vor allem in Sachen Vertrauen Maßstäbe setzen kann: Hersteller könnten sich entscheiden, einfach auf die Updatefähigkeit einzelner Komponenten zu verzichten. Ein Spiel mit dem Feuer, immerhin will, kann, muss ein OEM konkurrenzfähig sein. Aber eine Komponente, die nicht geupdatet werden kann, benötigt keinen Nachweis über die Vorbereitung des SUMS (wir erinnern uns) für diese Komponente. In einem solche Fall müsste die ganze Komponente ausgetauscht werden, wenn ein Sicherheitsrisiko besteht – das kann dann allerdings auf den Zulieferer abgewälzt werden. Ob diese ein so deutliches Risiko in Sachen Gewährleistung überhaupt eingehen, ist mehr als nur fraglich.

UNECE R155 – Krise ist Gelegenheit!

Bringen wir eine lange Beweisführung zum Schlussplädoyer. Die History of Data Violence ist eindeutig beendet, und eine Ära ersten Pioniergeists geht zu Ende. Die Terra Incognita liegt brach vor uns, und am Ende wartet eine Nachweispflicht mit lebenslanger Haftung. Wie wir den Weg dahin beschreiten, sei es als Zulieferer, als OEM, als Programmierer, als Autofan, liegt an uns. Während die Schockwellen sich seit Jahren langsam ausbreiten und auch die letzten Partizipanten der Branche erreicht haben, tüfteln kluge Köpfe an Lösungen. Nie hat es mehr Spaß gemacht, ganz am Anfang zu stehen. Wir haben Basiswissen, wir entwickeln Tool-Landschaften, Methoden, Systeme – und das macht Spaß. Nicht länger beschränkt sich Forschung auf Optimierung und Weiterentwicklung: Etwas gänzlich Neues kann, darf, muss geschaffen werden, und sind wir doch ehrlich: Wir wollen unbedingt sichere Produkte entwickeln, die Spaß machen. Autos müssen sicher sein, von Anfang bis Ende, und Zulieferer wie OEM freuen sich, tolle, saubere, sichere Fahrzeuge in die Hände ihrer Kunden zu übergeben. Dazu ist freilich ein Umdenken in vielen Nischen der Industrie nötig. Es müssen Vorgehensweisen geschaffen werden, Anforderungsmanagement wird eine Blüte erleben ohne Gleichen, und endlich sitzen in Sachen Know-How wieder alle in einem Boot. Will sagen, Auto.

Die Cognizant Mobility als ausgewiesener Experte in den Bereichen Safety, Funktionale Sicherheit, Angriffspfadanalysen, Anforderungsmanagement und weiteren Kernkompetenzen, ist auf jeden Fall bereit und freut sich, diese Herausforderungen anzugehen. Kontaktiert uns gerne über das Kontaktformular, oder ruft einfach an, schreibt eine Mail, folgt uns auf LinkedIn – und dann unterhalten wir uns mal und sehen, was wir für euch tun können.

Es gibt viel zu tun. Packen wir’s an.