Automotive SPICE®

Hintergrund

Fahrzeuge entwickeln sich zunehmend zu Computern auf Rädern. Beginnend beim Infotainmentsystem, über „Steer-/ Brake-by-wire“ bis hin zum hochautomatisierten Fahren übernehmen Fahrzeugcomputer mitunter sicherheitskritische Aufgaben.

Gleichzeitig wächst die digitale Vernetzung von Fahrzeugen mit ihrer Umwelt (Car-to-X). Das X kann sowohl für die Kommunikation mit anderen Verkehrsteilnehmer:innen stehen, z. B. beim „Platooning“ – ein sich in der Entwicklung befindendes System, welches das Kolonne-Fahren mit sehr geringem Abstand ermöglicht –, oder für die Kommunikation mit stationärer Infrastruktur, z.B. Funk- und Sendemasten für die Internetanbindung bei „over-the-air“ Updates.

Die Realisierung dieser Funktionen erfordert teilweise weitreichende Zugriffsrechte auf die Fahrzeugfunktionen. Jede Schnittstelle ist dabei auch ein potenzielles Angriffsziel und stellt ein Risiko für die Fahrzeuginsassinnen und Fahrzeuginsassen und andere Verkehrsteilnehmer:innen dar: Denkbare Schäden eines erfolgreichen Angriffs reichen vom Mitlesen persönlicher Daten, über die Veränderung (sicherheitsrelevanter) Einstellungen und Funktionen, bis hin zur Übernahme des Fahrzeugs.

Die Herausforderung für Hersteller vernetzter Produkte (insbesondere Fahrzeuge) besteht somit darin, die digitale Angriffssicherheit - allgemein als Cybersecurity (CS) bezeichnet - über die gesamte Wertschöpfungskette zu gewährleisten. Es ist die Aufgabe des Fahrzeugherstellers, neben dem Projektrisikomanagement ein Risikomanagement für digitale Angriffe auf das Fahrzeug sowie dessen Infrastruktur über die gesamte Lebensdauer - von der Entwicklung über die Inverkehrbringung bis hin zur Außerbetriebnahme - durchzuführen.

Beziehung zwischen ASPICE^® und ASPICE^® CS

ASPICE^® (Automotive Software Process Improvement and Capability Determination) ist eine strukturierte Sammlung von Best Practices für die Entwicklung in der Automobilindustrie. Dieser Standard erlaubt eine Bewertung der Leistungsfähigkeit der Entwicklungsprozesse im Rahmen von Assessments. Ergänzend hierzu hat die „Automotive Special Interest Group“ in Zusammenarbeit mit der „Quality Management Center des Verbands der Automobilindustrie (VDA QMC)“ im Juli 2021 das „Automotive SPICE^® for Cybersecurity – Process Reference and Assessment Model” (ASPICE^® CS) herausgegeben. Es nimmt die Inhalte aus ISO/SAE 21434:2021 (Road Vehicles – cyber security engineering) für automobile Entwicklungsprojekte auf und leitet daraus analog zu ASPICE® ein Prozessreifegradmodell bezüglich CS für Fahrzeughersteller ab. Wie auch ASPICE^®, behandelt ASPICE^® CS aus der ISO 21434 nur die Produktentwicklung – ausgeschlossen ist sowohl die Übergabe in die Produktion als auch die fortwährende Betreuung über den gesamten Produktlebenszyklus.

ASPICE^® CS ist als eigenständiges Reifegradmodell zu betrachten, entsprechend wird der Reifegrad einer Organisation in einem eigenständigen Assessment bewertet.

Im Vergleich zu ASPICE^® enthält ASPICE^® CS eine komplett neue „primäre“ Prozessgruppe „Cybersecurity Engineering Process Group (SEC). Darüber hinaus wird die „Aquisition Process Group“ um den neuen Prozesskern „ACQ.2 Supplier Request and Selection“ für die Auswahl von Zulieferern basierend auf deren CS Qualifikation ergänzt (siehe Abb. 1). Weiterhin kommt in der Management Process Group (MAN) der Prozesskern „MAN.7 Cybersecurity Risk Management“ hinzu.

Im Cybersecurity Risk Management (MAN.7) erfolgt die Ermittlung und Bewertung aller bekannten CS Risikoszenarien für die betrachtete Entwicklung über die gesamte Wirkkette, d. h. Fahrzeug, Infrastruktur und Backend (Server/Cloud). MAN.7 überwacht und steuert alle CS bezogenen Risiken über den gesamten Zeitraum der Entwicklung, analog zum Projektrisikomanagement (MAN.5) für Projektrisiken.

In Cybersecurity Requirements Elicitation (SEC.1) werden aus den allgemeinen CS Risikoszenarien jeweils funktionale und nicht-funktionale Cybersecurity-Anforderungen abgeleitet. Diese ergänzen die allgemeinen Anforderungen aus der Systemanforderungserhebung (SYS.1) und fließen analog in die (technische) Anforderungsspezifikation auf System- und Softwareebene (SYS.2 und SWE.1) mit ein.

Die Cybersecurity Implementation (SEC.2) beschreibt die Umsetzung der Cybersecurity Anforderungsspezifikationen auf System- und Softwareebene im jeweiligen Architekturdesign (parallel zu SYS.3 und SWE.2). Den Cybersecurity Anforderungen müssen explizit Elementen der Architektur und spezifischen Lösungen zur Verhinderung, Detektion und Risikominimierung zugewiesen werden. Dies trifft insbesondere für sicherheitsrelevanten Schnittstellen zur (Betriebs-)Umwelt zu. Die CS Lösungen werden parallel zu SWE.3 in den Software-Elementen umgesetzt, entweder durch eine Anpassung von Software-Units oder dem Design zusätzlicher neuer Software-Units in Ergänzung zu den „rein funktionalen“ Software-Elementen.

Nach der Umsetzung gilt es auf der rechten Seite des V-Modells die Erfüllung der zuvor gestellten Anforderungen zu überprüfen. Hierzu fordert ASPICE® CS für jede Ebene (Software, System) jeweils eine Verifikation (Risk Treatment Verification, SEC.3) zur Überprüfung der Anforderungen aus SEC.1 anhand der dort definierten Tests und Testkriterien. Um bisher unberücksichtigte Risiken aufzudecken, sieht ASPICE® zusätzlich Validierungstests vor (Risk Treatment Validation, SEC.4), wie z.B. Penetration-Tests. Diese erlauben es, die Erreichung der Cybersecurity-Ziele unabhängig von den identifizierten Risiken zu überprüfen. Im Rahmen der Validierung können unerkannte CS Risiken aufgedeckt werden. Diese sind im Rahmen von SEC.1 aufzunehmen und zu bewerten. Ergibt die Bewertung, dass die neuen CS Risiken adressiert werden müssen, erfordert dies einen erneuten Durchlauf des Entwicklungs-Vs (ASPICE^® & ASPICE^® CS).

Zulieferer für Cybersecurity-Projekte müssen dahingehend überprüft werden, dass sie ihre Liefergegenstände ihrerseits nach ASPICE^® CS herstellen und grundsätzlich vertrauenswürdig sind. Diese Anforderungen werden in dem neuen Prozesskern ACQ.2 Supplier Request and Selection in der Beschaffungsprozessgruppe explizit dargelegt und ergänzen damit ACQ.3 (Contract Agreement), ACQ.11-13 (Technical, Legal & Administrative, and Project Requirements) und ACQ.15 (Supplier Qualification).

Ausblick

Im Gegensatz zur ISO 21434 behandelt ASPICE^® CS nur die Produktentwicklung, nicht aber die fortwährende Betreuung über den gesamten Produktlebenszyklus bis zum Produktlebensende. Wie z. B. bei Sicherheitsupdates von Mobiltelefonen muss auch der Schutz vernetzter Fahrzeuge permanent überprüft und im Lichte neu erkannter Sicherheitslücken verbessert werden. Dies wird aufgrund der hohen Innovationsrate bei Cyberattacken im Vergleich zur Funktionalen Sicherheit eine zeitlich engmaschigere Kontrolle erfordern.

Die schnelle, effektive und aufwandseffiziente Reaktion auf neue Angriffsszenarien und Schwachstellen während der Produktlebenszeit stellt zusätzliche Anforderungen an das Produkt. Um die aufwendigere Produktentwicklung und -pflege teilweise kompensieren zu können, empfiehlt sich eine modulare und standardisierte Produktarchitektur („secure-by-design“). Die schnelle Begegnung auf zukünftige Sicherheitslücken in Bestandssystemen führt in Kombination mit einer langanhaltenden Abwärtskompatibilität zu einer langen Produktlebensdauer. Sollten ab einem gewissen Zeitpunkt keine Updates mehr bereitgestellt werden (aufgrund technischer oder wirtschaftlicher Aspekte), wird die Benutzung des Fahrzeugs potenziell gefährlich und kann schlimmstenfalls durch den Gesetzgeber verboten werden. Wird es in Zukunft ggf. ein definierte Produktlebenszeit geben und wie ist mit „Altfahrzeugen“ umzugehen? Hier schließen sich viele Fragen an, die jedoch den Umfang dieses Artikels sprengen würden und noch viel Diskussionspotenzial für z.B. das Produktmanagement bieten.

Für die Umsetzung der Inhalte aus ASPICE^® CS ist eine Erweiterung bestehender Rollen im Bereich Anforderungsentwicklung und Architektur um Cybersecurity-Fachwissen notwendig, als auch die Schaffung neuer Rollen, insbesondere zur Validierung von Cybersecurity-Maßnahmen („hacker“). Gerade Letztere erfordert eine Besetzung durch Fachspezialist:innen, die in Zukunft immer stärker nachgefragt werden.

Die Validierungstests für Cybersecurity sind im Vergleich zur Verifikation weniger klar definierbar, da bislang unbekannte Schwachstellen identifiziert werden sollen und dementsprechend kreative Testmethoden erforderlich sind. Genauso unklar ist die richtige Balance zwischen standardisiertem Vorgehen (und dadurch kontrollierter Zeit- und Ressourcenaufwand) und freiem Testen (wie lange ist ausprobieren sinnvoll? Wie skaliert die Wahrscheinlichkeit eines erfolgreichen Hacks zum Zeitaufwand? Wann ist eine Validierung zu Ende?). Hierüber trifft ASPICE^® CS keine Aussage und es ist an den Organisationseinheiten, mit Hilfe von zusätzlichen Standards und Regularien wie der ISO/SAE 21434:2021 darauf Antworten zu definieren.

Fazit

Mit ASPICE^® CS ergänzt das Quality Management Center des Verbands der Automobilindustrie (VDA QMC) das Prozessreferenz- und Assessmentmodell ASPICE^® um ein eigenständiges Model für Cybersecurity-Inhalte, welches in eigenständigen Assessments zur Anwendung kommt. Beide Modelle lassen sich jedoch miteinander in Beziehung setzen, wie oben in Abbildung 2 veranschaulicht. ASPICE^® CS betrachtet im Gegensatz zu der darunterliegenden ISO/SAE Norm 21434:2021 nur die Produktentwicklung. Es fehlt jedoch eine Betrachtung, wie mit Cybersecurity über den gesamten Produktlebenszyklus umgegangen werden soll und die Prozesse bewertet werden können.

Vermeidbare Stolpersteine

Gemeinsam mit unseren Kund:innen bewegen wir uns tagtäglich in herausfordernden Projekten, um „alte“ Vorgehen in der Produktentwicklung auf den neusten Stand der Technik zu heben, neue Impulse zu setzen und passgenaue Lösungen zu konzipieren sowie umzusetzen. Dabei zeigen sich oftmals vermeidbare Stolpersteine, von denen wir Ihnen an dieser Stelle abraten wollen:

• Die Berücksichtigung des neuesten Stands der Technik erst dann, wenn dieser durch externe Stakeholder eingefordert wird. Meist reichen die Umsetzungszeiten dann nicht mehr aus und es müssen Task Forces gegründet werden.
• Der Einsatz eines Teams mit nicht ausreichend erfahrenen Teammitgliedern, da die internen Expert:innen für das höher priorisierte Tagesgeschäft eingesetzt werden. In diesem Fall werden richtungsweisende Entscheidungen falsch getroffen, die Vorhaben verzögern sich und die Missstände fallen meist erst bei ¾ Projektlaufzeit auf. Eine Korrektur ist hier kaum noch möglich.
• Der Versuch, die Anforderungen 1:1 aus den beispielhaften Prozessarchitekturen in die eigene Organisation zu übertragen. Wenn keine vorzeitigen Pilotierungen/Simulationen stattfinden, fällt dieser Fehler erst im Rollout auf, die Anwender:innen zeigen Unverständnis und die Akzeptanz scheitert. Das Prozessmodell ist nur wenig nutzbar und es ist nicht selten ein nahezu völliger Neuaufsatz des Projektes erforderlich.

Sie haben Fragen oder wollen sich unverbindlich mit uns zu den Themen austauschen? Kommen Sie gerne auf uns zu, wir unterstützen Sie bei der Identifikation Ihrer Bedarfe, dem Vorgehenskonzept bis hin zur nachhaltigen Implementierung. Dabei bauen wir auf unsere langjährige Erfahrung im Umfeld der Produktentwicklung, dem Gestalten von Prozessen sowie Organisationen gemeinsam mit unserem Partnernetzwerk.