ASPICE for Cybersecurity: Das Wichtigste in 5 Minuten

Cybersecurity im Auto? Klingt erstmal nach Hackern, die Bremsen übernehmen oder Radios, die plötzlich dubiose Popups anzeigen.

Doch in der Realität ist das Thema viel nüchterner – und gleichzeitig noch viel wichtiger: Prozesse sicher gestalten. Genau hier kommt ASPICE for Cybersecurity ins Spiel.

Viele reden darüber, wenige setzen es konsequent um. In diesem Artikel gehen wir ins Detail: Wir schauen uns die Kernprozesse an, wie sie sich in der Praxis anfühlen, wo die größten Stolperfallen liegen und wie du ASPICE & ISO/SAE 21434 smart kombinierst.

ASPICE kurz erklärt – der Blick aufs „Warum“

Zunächst kurz zur Auffrischung: ASPICE ist quasi ein Framework, das überprüft, wie reif eure Softwareprozesse sind – vom Niveau 0 (incomplete) bis Level 5 (innovating). Entwickelt vom VDA, orientiert an ISO/IEC-330xx-Standards. Unternehmen wie OEMs und Zulieferer nutzen ASPICE, um Qualität, Sicherheit und Prozesseffizienz zu messen und zu verbessern.

Das heißt ASPICE bewertet Prozesse, nicht das Endprodukt.

Beispiel: Wenn dein Team eine Software entwickelt, fragt ASPICE nicht: „Funktioniert die Software?“

Es fragt: „War euer Vorgehen so strukturiert, dass sie wahrscheinlich auch beim nächsten Mal funktioniert?“

Cybersecurity erweitert diesen Gedanken: „Habt ihr Prozesse, die sicherstellen, dass euer Produkt auch gegen Angriffe robust ist?“

ASPICE 4.0 im Überblick - was neu ist

ASPICE 4.0 ist seit November 2023 veröffentlicht und bringt handfeste Änderungen mit:

Kürzere VDA-Mandate im Assessment, z. B. Reduktion auf Grund- und Domänenteile – weniger Papier, mehr Fokus.
Strategiedokumente wandern von Level 1 zu Level 2 – Level 1 ist leichter erreichbar.
Weniger, aber stärker kombinierte Base Practices – etwa Rückverfolgbarkeit & Konsistenz in einem.
Assessoren müssen sich neu qualifizieren – mehr Expertise gefragt.

Die Cybersecurity-Prozessgruppen in der Praxis

Seit 2022 gibt’s die Cybersecurity-Erweiterung (Cybersecurity PAM). Der VDA hat sie in Form eines ergänzenden Process Reference & Assessment Models veröffentlicht.

Die Erweiterung von ASPICE für Cybersecurity (Cybersecurity PAM) ergänzt genau die Lücken, die ISO/SAE 21434 im Audit-Kontext offenlässt. Sie liefert prozessuale Nachweise, die im Assessment bewertet werden können.

Lass uns die Prozesse greifbar machen:

ACQ.2 – Supplier Request & Selection

Theorie: Auswahl und Bewertung von Lieferanten auf Basis ihrer Cybersecurity-Fähigkeiten.

Praxisbeispiel:
Stell dir vor, dein Unternehmen will eine neue ECU einkaufen.

Du fragst nicht nur: „Kann die ECU technisch alles?“
Sondern auch: „Hat der Lieferant nachweisbare Cybersecurity-Prozesse?“
Hast du Nachweise, wie z. B. eine vorherige ASPICE-Cybersecurity-Bewertung oder eine CSMS-Zertifizierung nach ISO/SAE 21434:2021?

Tipp: Entwickle einen „Cybersecurity Supplier Checklist“ oder vereinbare ein Cybersecurity Interface Agreement. Darauf gehören:

Gibt es einen TARA-Prozess beim Zulieferer?
Wie dokumentiert er Schwachstellenmanagement?
Hat er ein Patch-Management nach SOP?
Welche Arbeitsprodukte werden vom Zulieferer wann geliefert?

MAN.7 – Cybersecurity Risk Management

Theorie: Risiken identifizieren, analysieren, behandeln.

Praxisbeispiel:
Du arbeitest an einem Gateway-Steuergerät. Angriffsfläche: OTA-Updates.

Risikoanalyse (TARA): OTA könnte gefälschte Firmware einschleusen.
Behandlung: Implementiere Secure Boot + digitale Signaturen.
Dokumentation: Risiko wurde erkannt, mitigiert, erneut bewertet.

Tipp für Projekte:

Identifiziere die Assets sinnvoll.
Nutze Attack Path Analysis (wie im Gelbband beschrieben).
Gewährleiste die Nachvollziehbarkeit zum Beispiel bei der Herleitung von Angriffswahrscheinlichkeiten vor und nach der Risikobehandlung
Stell dir immer die Frage: „Wenn ich Hacker wäre – wo würde ich ansetzen?“
Dokumentiere jede Annahme. Denn im Assessment wird genau da gebohrt: „Warum habt ihr entschieden, dieses Risiko zu akzeptieren?“
Stelle sicher, dass die Risiken im Cybersecurity Konzept addressiert sind und der Cybersecurity Prozess aufgeplant ist.

SEC.1 – Cybersecurity Requirements Elicitation

Theorie: Ableiten von Security-Zielen aus Risikoanalysen.

Praxisbeispiel:
Du hast das Risiko „Remote Exploit über Infotainment“ identifiziert.

Ziel: „Unautorisierter Zugriff auf Fahrfunktionen verhindern.“
Abgeleitete Anforderungen:
Alle externen Verbindungen müssen authentifiziert sein.
Daten zwischen Infotainment und Gateway sind zu verschlüsseln.

Tipp: Nutze Bidirektionale Traceability (wie im Gelbband gefordert). Das bedeutet: Jede Anforderung ist mit dem zugehörigen Risiko und dem späteren Testfall verknüpft.

SEC.2 – Cybersecurity Implementation

Theorie: Umsetzung der Anforderungen in Architektur & Design.

Praxisbeispiel:

Anforderung: „Kommunikation verschlüsseln.“
Umsetzung:
- TLS 1.3 auf der Infotainment-Schnittstelle.
- HSM (Hardware Security Module) für Schlüsselverwaltung.

Tipp aus der Praxis: Mach dir klar: Cybersecurity Controls sind nicht gratis.
Oft beeinflussen sie die Architektur massiv (CPU-Last, Speicher, Timing). Plane sie frühzeitig ein – sonst drohen teure Redesigns.

SEC.3 – Risk Treatment Verification

Theorie: Überprüfung, ob Implementierung den Anforderungen entspricht.

Praxisbeispiel:

Verifiziere, ob TLS 1.3 korrekt konfiguriert ist.
Teste, ob Angriffe wie Downgrade-Attacks abgeblockt werden.

Tipp: Automatisiere, wo es geht!

Static Code Analysis (z. B. MISRA-C mit Security-Checks)
Security-Testautomatisierung in CI/CD
Regressionstests für Patches

Hinweis: Die Sicherstellung der Effektivität von Maßnahmen hängt von der Qualität der Pflichtenhefte ab. Je besser und detaillierter die Anforderungen geschrieben sind, desto sicherer kann man sein, dass die Maßnahmen greifen.

SEC.4 – Risk Treatment Validation

Theorie: Validierung, dass das System wirklich sicher ist – also der „Reality Check“.

Praxisbeispiel:

Penetrationstest gegen die reale ECU.
Fuzzing gegen CAN-Schnittstelle.

Tipp: Denk hier an den „Red Team“-Ansatz.
Der Unterschied zur Verification: Es geht nicht nur um „richtige Implementierung“, sondern darum, ob die richtigen Maßnahmen gewählt wurden.

ASPICE Cybersecurity vs. ISO/SAE 21434 – wer macht was?

ISO/SAE 21434 → gibt den Rahmen: Welche Aktivitäten braucht es?
ASPICE Cybersecurity → prüft die Prozesse: Wie reif sind diese Aktivitäten in deinem Unternehmen implementiert?

Praktisch heißt das: 21434 fordert, dass du ein TARA machst. ASPICE bewertet, ob dein TARA-Prozess wiederholbar, nachvollziehbar und robust ist.

Wie ein Assessment in der Realität aussieht

Ein ASPICE-Cybersecurity-Assessment ist keine Prüfung deines Produkts – sondern deiner Prozesse. Typischer Ablauf:

Scope festlegen: Welche Prozesse (SEC.1–4, MAN.7, ACQ.2) sind relevant?
Interviews: Assessoren sprechen mit Entwicklern, Architekten, Testern.
Work-Products prüfen: Anforderungen, Architektur-Dokumente, Risikoanalysen, Testberichte.
Bewertung: Jeder Prozess bekommt ein Reifegradlevel (von „not achieved“ bis „fully achieved“).
Ergebnis: Du erhältst ein Profil – und siehst, wo Lücken sind.

Tipp: Bereite deine Teams vor. Assessoren fragen oft sehr konkret:

„Zeigen Sie mir die Traceability von diesem Risiko bis zum Testfall.“
„Wie stellen Sie sicher, dass auch externe Zulieferer Ihre Security-Anforderungen erfüllen?“

Häufige Stolperfallen (und wie du sie vermeidest)

Doppelte Doku: ISO/SAE 21434 & ASPICE parallel abbilden → Chaos.
Lösung: Gemeinsame Templates.
Traceability nur auf dem Papier: Requirements-Tools (DOORS, Polarion) pflegen → aber im Projekt leben die Excel-Listen.
Lösung: Toolchains vereinheitlichen, Nachweise integrieren.
Validation unterschätzt: Verification (Tests) ≠ Validation (Reality Check).
Lösung: Externe Pen-Tests bereits bei der Akquise einplanen, bevor SOP ansteht.
Supplier Management: Oft der schwächste Punkt.
Lösung: Lieferanten frühzeitig einbinden, mit ASPICE-Checklisten prüfen.

Fazit – was du jetzt tun kannst

ASPICE for Cybersecurity ist mehr als ein neues Buzzword – es ist der praktische Hebel, um Cybersecurity-Prozesse im Automotive-Bereich greifbar und messbar zu machen.

Wenn du: