Automotive SPICE® im Kontext von Cybersecurity (ASPICE® CS) – Das neue Reifegradmodell im Überblick

Cybersecurity, ASPICE, Functional Safety, etc. – im Bereich Automotive schlagen viele Begrifflichkeiten und Themen auf. Dieser Artikel gibt Ihnen einen kompakten Einblick in das neue Reifegradmodell für Cybersecurity von Automotive SPICE® (ASPICE® CS), wie es in Beziehung zu dem allgemeinen Reifegradmodell von ASPICE® steht und welche Konsequenzen sich daraus für Organisationen im Automotive-Bereich ergeben. Darüber hinaus beleuchten wir, wieso Cybersecurity in der Automobilbranche mehr und mehr an Bedeutung gewinnt. Im Anschluss geben wir Impulse für Organisationen, die ASPICE® CS umsetzen wollen.

– Tiba Magazin 2022 –

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 (Abb. 1). Weiterhin kommt in der Management Process Group (MAN) der Prozesskern „MAN.7 Cybersecurity Risk Management“ hinzu.

Abb. 1: ASPICE® Prozessgruppen, petrol eingezeichnet die neuen Prozessgruppen aus ASPICE® CS. [Quelle ASPICE® CS]

Umgang mit (technischen) Risiken – das Projektmanagementviereck

In der Praxis ist es grundsätzlich schwierig, die Aktivitäten des Risikomanagement streng chronologisch in Bezug zum Durchlauf des V-Modells (siehe Abb. 1) durchzuführen. Diese Schwierigkeit ist unabhängig davon, ob es sich um ein Projektrisiko, ein Risiko der Funktionalen Sicherheit, oder ein Cybersecurity-Risiko handelt.

Denn Risiken stehen allgemein in natürlicher Konkurrenz zum Projektinhalt. Wenn Inhaltsanforderungen mit einem nicht tolerierbaren Risiko für die zu schützenden Aspekte (Personen, Umwelt, Daten, etc.) einhergehen, dürfen diese Inhalte nicht, oder nicht in der gewünschten Form, umgesetzt werden. Damit ergeben sich aus den adressierten Risiken erhöhte Steuerungsaufwände im Projekt, welche sich auf das gesamte Projektmanagementdreieck auswirken (Qualität, Zeit und Kosten).

Hieraus resultiert zwangsläufig ein iteratives Vorgehen: Nach der Planung des Inhalts bezüglich Anforderungen und Architektur über die verschiedenen Ebenen (System-Ebene, SW-Ebene, HW-Ebene, etc.) sind die Risiken zu bewerten. Sind diese nach ihrer Bewertung nicht tolerierbar, müssen Risikomaßnahmen abgeleitet und die Planung entsprechend angepasst werden, sowie die Vereinbarkeit mit dem Projektterminplan und dem Projektbudget abgeglichen werden. Erst, wenn Inhalt, Kosten, Zeit und Risiko zueinander widerspruchsfrei sind, kann mit der Umsetzung begonnen werden. Dieser Abgleich muss im Laufe des Projekts bei jeder Planänderung erneut stattfinden.

Integration von ASPICE® in das Entwicklungs-V

ASPICE® CS trägt diesem iterativen Vorgehen im Sinne einer risikogetriebenen Entwicklung Rechnung. Die relative Zuordnung der ASPICE® CS Prozesse mit denen von ASPICE® sind in der Abbildung 2 dargestellt:

Abb. 2: Einordnung der Prozessgruppen aus ASPICE® CS in die das Entwicklungs-V aus ASPICE®. © Scharnhorst, Nils.

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.

Holen Sie sich jetzt die gesamte Tiba Magazin Ausgabe 2022

Spotlight Megatrends: Die Themen New Work, Gender Shift, Urbanisierung und Sicherheit im Fokus

Zum Download

Quellen

  • ASPICE: Automotive SPICE® Process Assessment / Reference Model, VDA QMC Working Group 13 / Automotive SIG, Version 3.1 (01.11.2017)
  • ASPICE CS: Automotive SPICE® for Cybersecurity Process Reference and Assessment Model, VDA QMF Project Group 13, Version 1.0 (17.07.2021)
  • ISO 21434: ISO/SAE 21434:2021 Road Vehicles – Cybersecurity engineering, ISO/TC 22/SC 32 Electrical and electronic components and general systems aspects, Edition

Autor:in

Portrait Autor

Dr. Nils Scharnhorst

Dr. Nils Scharnhorst ist studierter Physiker und hat sich nach einer Zeit als Post-Doc entschlossen seine analytische Denkweise zunächst als Koordinator für Methoden und Prozesse bei einem Ingenieursdienstleister und seit 2021 als Berater bei der Tiba einzusetzen. Sein Know-how hilft ihm in entwicklungsnahen Projekten, die Kundenherausforderungen zu durchdringen. Zusätzlich hat er sich eine Expertise in ASPICE® und agiler Entwicklung aufgebaut.

Portrait Autor

Paul F. Ullrich

Paul F. Ullrich leitet das CoC Prozessmanagement und ist Berater bei der Tiba. Das Zusammenwirken von Menschen und Systemen – besonders bei der Erstellung von Produkten – mitzugestalten ist Teil seiner Leidenschaft. Es fasziniert ihn, neue Herausforderungen zu identifizieren und in einem starken Team Lösungen zu realisieren.

Portrait Autor

Matthias Größler

Matthias Größler ist Geschäftsführer der FSQ Experts GmbH. Der studierte Wirtschaftsingenieur ist spezialisiert auf technische Produktsicherheit und die Sicherheit hochautomatisierter Systeme.

Portrait Autor

Julian Pelz

Julian Pelz ist langjähriger Berater für Produktsicherheit im Automotive- Umfeld bei der FSQ Experts GmbH und begleitet Unternehmen bei der Entwicklung und Implementierung von Projektmanagement- und Softwareentwicklungsprozessen. Er ist zertifizierter Provisional Assessor für Automotive SPICE und legt den Fokus bei der Prozessentwicklung vorwiegend auf die Einhaltung der Richtlinien und Anforderungen von ASPICE und der funktionalen Sicherheitsnorm ISO 26262.