Die meisten Plattformbewertungen belohnen Funktionslisten und Demos auf Anbieterdaten und scheitern dann im Betrieb an Varianten, Re-Importen und Audit-Trails. Bewerten Sie Kandidaten stattdessen anhand der Fragen, die Ihr heutiger Stack nicht beantworten kann, nachgewiesen auf Ihren eigenen Dateien, gewichtet nach Ihrer Rolle als OEM oder Tier-1 und abgesichert durch Deployment- und Identitätsanforderungen.
Die Bewertung einer Automotive-Cybersecurity-Plattform ist für OEM- und Tier-1-Teams zu einer wiederkehrenden Aufgabe geworden, und viele führen sie aus einem verständlichen Grund schlecht durch: Die Ausschreibung ist eine Funktionsliste, die Demo läuft auf Beispieldaten des Anbieters, und das Bewertungsblatt belohnt die längste Spalte mit Häkchen. Monate später stellt das Team fest, dass die TARA nicht sagen kann, für welche Varianten ein Risiko gilt, oder dass der Audit-Trail bei „Datensatz geändert“ endet.
Diese Checkliste richtet sich an diejenigen, die die Entscheidung treffen: CSMS-Verantwortliche, PSIRT- und VSOC-Leitungen, Engineering-Manager sowie die Mitarbeiter aus IT-Sicherheit und Einkauf, die Deployment- und Identitätsanforderungen prüfen. Jeder der sieben Bereiche hat denselben Aufbau: Fragen, Demo-Nachweise, Warnsignale und die Gewichtung für einen OEM und einen Tier-1. Sie nennt keine Anbieter und erstellt keine Rangliste.
Beginnen Sie mit den Fragen, die Ihr heutiger Stack nicht beantworten kann
Listen Sie fünf bis zehn Fragen auf, die die Organisation nur langsam oder gar nicht beantwortet: Welche Programme und Varianten enthalten eine bestimmte Komponentenversion; welche Maßnahmen behandeln ein Risiko und welche Tests haben sie auf der ausgelieferten Baseline verifiziert; in welchen Märkten fahren Fahrzeuge mit einer Teilenummer, die eine aktive CVE erreicht. Diese Fragen werden zum Demo-Skript, und eine Plattform, die sie aus verknüpften Datensätzen auf Ihren eigenen Dateien beantwortet, leistet etwas, das eine Tabellenkalkulation nicht kann.
Lassen Sie generische Werkzeuge an ihrem Platz: Ticketsystem, GRC-Plattform und SIEM behalten ihre Rollen, und die Lücke, die sie hinterlassen, beschreibt warum generische GRC- und ITSM-Plattformen den Automotive-Cybersecurity-Kontext verlieren. Bei der Bewertung geht es um das Produktmodell als verknüpfte, versionierte Datensätze.
Die Gewichtung unterscheidet sich nach Rolle. Ein OEM kauft vor allem für die Programmebene: viele Projekte und Lieferanten, Varianten, Flottenexposition und Incident Command. Ein Tier-1 kauft für TARA-Tiefe und für Nachweise, die ein OEM übernehmen kann, ohne sie neu einzutippen oder Lizenzen zum Lesen zu kaufen.
Bewerten Sie die Plattform anhand der Fragen, die Sie heute nicht beantworten können, nicht anhand der Funktionen, die Sie bereits haben.
Architekturmodellierung: das System wie entwickelt, nicht wie gezeichnet
Fragen: Kann die Plattform die Architektur aus dem führenden Engineering-System importieren, als UML/XMI und AUTOSAR ARXML, statt ein Neuzeichnen zu verlangen? Führt sie Komponententypen, Verbindungseigenschaften wie Protokoll und Verschlüsselung sowie Vertrauensgrenzen mit? Kann jede Komponente einer Fahrzeugarchitektur mit einem eigenen Sicherheitsprojekt verknüpft werden, sodass die Komponentenanalyse in das Programm hochgerollt wird? Kann eine ECU Softwareeinheiten enthalten, jede mit eigener Architektur und SBOM?
Einzufordernder Nachweis: Importieren Sie ein echtes Modell. Ein solider Import zeigt vor dem Speichern eine Konformitätsübersicht, listet Qualitätswarnungen wie Vererbungszyklen oder Ports, deren Schnittstelle nicht gefunden wird, und erfasst nicht gezeichnete Elemente in einer Downgrade-Liste, damit nichts stillschweigend verloren geht. Für Produktionsprojekte fordern Sie einen gestuften Import mit Freigabe durch eine zweite Person, jeder Schritt im Audit-Trail.
Warnsignale: keine Warnungen bei einem unsauberen Modell; Komponenten, die Zeichnungen ohne Eigenschaften sind; ein Programm, das ein Ordner mit Projekten ist statt der in Programme und Fahrzeugarchitektur beschriebenen Fahrzeugarchitektur.
Gewichtung: OEM hoch, weil Programmebene und Varianten davon abhängen; Tier-1 mittel, steigend, je mehr Kunden Nachweise auf Architekturebene pro Lieferumfang verlangen.
TARA: generierte Risiken, geregelte Bewertung und nachvollziehbare Behandlung
Fragen: Werden Risiken aus einem Bedrohungsszenario generiert, das mit einem Angriffspfad verknüpft ist, eines pro Asset und Cybersecurity-Eigenschaft, oder von Hand eingetippt? Stammt die Auswirkung aus den verknüpften Schadensszenarien über die Bewertungen Safety, Finanzen, Betrieb und Datenschutz, die Wahrscheinlichkeit aus der Angriffsdurchführbarkeit und ein Cybersecurity Assurance Level aus Auswirkung und Angriffsvektor? Definiert eine Policy (Richtlinie) die Risikomethode, die akzeptierten Stufen und die zulässigen Behandlungsstrategien und verweigert, was sie nicht zulässt? Erfasst die Behandlung Strategie (reduzieren, beibehalten, teilen oder vermeiden), Begründung, Verantwortlichen und Restrisiko, und verknüpft sie reduzierte Risiken mit Zielen, Anforderungen und Maßnahmen sowie beibehaltene Risiken mit Claims (Nachweisbehauptungen) und Belegen? Die Methode behandelt der Leitfaden zur TARA nach ISO/SAE 21434.
Einzufordernder Nachweis: Importieren Sie eine Ihrer eigenen TARAs, aus einer Tabellenkalkulation oder aus OpenXSAM, und verfolgen Sie ein Risiko vom Asset bis zum Testfall. Löschen Sie das Asset; das Risiko sollte mit einem Hinweis auf die entfernte Referenz markiert werden, nicht verschwinden. Versuchen Sie, ein hohes Risiko unter einer Policy beizubehalten, die nur mittlere und niedrigere akzeptiert. Wo KI Behandlungen empfiehlt, fragen Sie, wie ein Vorschlag angenommen oder abgelehnt wird und ob KI-angereicherte Datensätze eine Markierung tragen, die ein Prüfer bestätigen muss.
Warnsignale: editierbare Risikowerte; ein Compliance-Panel, das eine ausgefüllte Vorlage ist; kein Restrisiko; eine TARA, die sich nicht pro Baseline versionieren lässt, das Problem, das Versionskontrolle für die TARA behandelt.
Gewichtung: Tier-1 hoch, weil TARA-Tiefe der Lieferumfang ist; OEM hoch, mit Schwerpunkt auf dem Roll-up über, sagen wir, 14 Komponentenprojekte.
SBOM und CVE-Auswirkungsanalyse: von der Komponente zur Teilenummer
Fragen: Welche Formate (mindestens CycloneDX und SPDX) und welche Re-Import-Optionen (zusammenführen, ersetzen, nur aktualisieren), damit die Neulieferung eines Lieferanten als Differenz dargestellt statt überschrieben wird? Welche Schwachstellenquellen werden abgeglichen, einschließlich regionaler Feeds wie CNVD, wo GB 44495 gilt, und steuert eine Policy, welche davon vertrauenswürdig sind? Gibt es einen Status-Workflow mit „akzeptiert mit Begründung“ und „unterdrückt als Fehlalarm“, sodass eine „nicht betroffen“-Aussage ein Datensatz ist und keine E-Mail? Vor allem: Werden Architekturmodule den SBOM-Komponenten zugeordnet, automatisch über Package-URL oder eindeutigen Namen und bei Mehrdeutigkeit zur Prüfung zurückgehalten, und lässt sich eine Schwachstelle von der Softwarekomponente über Softwareeinheit, Systemkomponente, Teilenummer und Fahrzeug bis zum Markt verfolgen?
Einzufordernder Nachweis: Bringen Sie Ihre eigene SBOM für eine Softwareeinheit mit, deren Architektur Sie ebenfalls exportieren können. Lesen Sie nach dem Abgleich die drei Zähler: zugeordnet, nicht zugeordnete Komponenten, nicht zugeordnete Module. Wählen Sie eine Komponente mit bekannter Schwachstelle, fragen Sie nach ihrem Wirkungsbereich durch die Architektur und dann nach den Märkten, in deren Fahrzeugen eine Teilenummer verbaut ist, die sie erreicht. Ist die Kette unvollständig, sollte die Plattform das sagen, wie Ausbreitungsradius einer Automotive-CVE über Fahrzeugvarianten erläutert.
Warnsignale: Schwachstellenzähler ohne Status-Workflow; null Mehrdeutigkeiten bei einer echten SBOM; ein „Lieferantenmanagement“, das eine Kontaktliste ist. Zu den Formaten siehe CycloneDX vs. SPDX im Automotive-Bereich.
Gewichtung: OEM hoch für die Kette bis zu Teilenummer und Flotte; Tier-1 hoch für die Hygiene pro Lieferumfang und belastbare „nicht betroffen“-Aussagen.
Vorfallbearbeitung: vom Flottensignal zum eingetretenen Risiko
Ein Vorfall muss mit den betroffenen Komponenten, den Risiken, die den Angriff modelliert haben, der verwundbaren Software und den Maßnahmen, die ihn erkennen sollten, verknüpft sein und in die TARA zurückfließen. Fragen: Aus welchen Quellen wird ein Vorfall eröffnet (manuelle Meldung, automatisiertes Monitoring, Threat Intelligence, Schwachstellenscan, externe Partei)? Wird das Risiko als eingetreten markiert, wenn ein bestätigter Vorfall zeigt, dass ein modellierter Angriff stattfindet? Wird eine TARA-Lücke eröffnet, die das Engineering schließen muss, wenn der Angriff nie modelliert wurde? Sind Reaktionszeiten pro Schweregrad in der Policy festgelegt und werden sie durchgesetzt?
Einzufordernder Nachweis: Eröffnen Sie einen Vorfall aus einer Threat-Intelligence-Meldung, verknüpfen Sie ihn mit einer Komponente und einem Risiko, fügen Sie ein Update und einen Anhang hinzu und prüfen Sie dann den Status des Risikos. Fragen Sie, wie der Programmverantwortliche ihn sieht: offene Vorfälle nach Markt, neben Schwachstellen und Risiken in einer Ansicht, mit einer am Vorfall verankerten Traceability Map. Fragen Sie nach Webhook-Benachrichtigungen und nach Kennzahlen jenseits der mittleren Lösungszeit (Incident-Response-Kennzahlen jenseits der MTTR).
Warnsignale: Vorfälle, die sich nicht mit Risiken oder Komponenten verknüpfen lassen; kein Rückweg in die TARA; SLA-Felder ohne Durchsetzung. Die Abschlussnachweise, die ein Assessor erwartet, stehen in der Checkliste für Abschlussnachweise bei Vorfällen.
Gewichtung: OEM sehr hoch, da Post-Production-Monitoring und flottenweite Reaktion die Pflicht des OEM nach UN R155 sind und der EU CRA Meldepflichten hinzufügt; Tier-1 mittel, mit Schwerpunkt auf der Eskalation zum und vom OEM.
Nachweise und Rückverfolgbarkeit: Baselines, Freigaben und der Audit-Trail
Alles oben Genannte gilt nur, wenn die Plattform die Datensätze so reproduzieren kann, wie sie zum Zeitpunkt einer Entscheidung standen. Fragen: Gibt es Projekt-Baselines, bei denen eine freigegebene Baseline schreibgeschützt ist und in einen neuen Entwurf abgezweigt werden kann? Schützt ein Design-Freeze die TARA, während die Assurance-Kette weiterläuft? Sind Varianten so modelliert, dass gemeinsam genutzte Entitäten nicht aus einer Variante heraus geändert werden können? Lässt sich eine auf einen Befund verankerte Traceability Map auf Programmebene als Link teilen, der die exakte Ansicht wiederherstellt? Werden Policies automatisch versioniert, wobei eine abschwächende Änderung auf einen zweiten Freigeber wartet? Kann ein Claim hochgeladene Nachweise mit einem Status wie „Nachweis ausstehend“ oder „validiert“ tragen?
Einzufordernder Nachweis: Geben Sie eine Baseline frei, versuchen Sie, ein Risiko darin zu bearbeiten, zweigen Sie dann einen Entwurf ab und nehmen Sie die Änderung dort vor. Fordern Sie den Audit-Trail eines gestuften Imports und einer Policy-Änderung an. Fragen Sie nach jedem Datensatz, der ein Risiko berührt, und dann nach demselben für eine Schwachstelle auf Programmebene. Die Kette beschreibt Rückverfolgbarkeit in der Automotive Cybersecurity: ein Praxisleitfaden, die Sicht des Assessors die Vorbereitung auf das CSMS-Audit.
Warnsignale: „Versionierung“, die den Export eines PDF meint; ein Audit-Log ohne Feld, Akteur und Begründung; Policies, die Dokumente sind statt durchgesetzter Konfiguration.
Gewichtung: hoch für beide. Ein OEM braucht sie für die Typgenehmigung nach UN R155 und R156; ein Tier-1, weil jede Übergabe eine Baseline ist und Kunden gegen ISO/SAE 21434 und zunehmend den CRA auditieren.
Integrationen: gestufte Importe, offene Formate und Status, der zurückfließt
Bewerten Sie Integrationen nach Kategorie und Richtung, nicht nach der Anzahl der Logos. Entlang der Pipeline: Kommunikationsmatrix-Eingaben (ARXML, DBC, VSS); Systemmodellierung (UML/XMI, SysML, AUTOSAR); Asset-Identifikation aus Diagnosekatalogen (ODX, CDD); TARA-Import (Tabellenkalkulationen, OpenXSAM); Anforderungsaustausch (ReqIF); Softwarearchitektur und SBOM (CycloneDX, SPDX); Befunde aus Code- und Binäranalyse (SARIF); Schwachstellendatenbanken; Prüfstandstests, die als Verifikationsnachweis zurückkommen; Datenaustausch (STIX, PDF, CSV, Excel); VSOC und Threat Intelligence (Event-Streaming, STIX-Ingest); sowie Identität (SAML 2.0, LDAP). SIEM und VSOC mit den Engineering-Werkzeugen verbinden behandelt den Betrieb.
Fragen: Wird jeder Import gestuft und geprüft, bevor er im Graphen landet? Wenn eine Behandlung eine Aufgabe im Ticketsystem anlegt, fließt der Status zurück? Bleiben Identifikatoren über den Hin- und Rückweg erhalten: CWE in SARIF, Package-URL in SBOMs, Anforderungs-IDs in ReqIF? Ist die API in Ihrer Lizenzstufe enthalten? Einzufordernder Nachweis: ein Round-Trip auf Ihren Dateien, Architektur hinein, Anforderungen als ReqIF heraus, SBOM hinein, ein Befund über SARIF hinein, eine Aufgabe heraus und ihr Status zurück. Warnsignale: einseitige Exporte, Konnektorlisten ohne Formatversionen, Importe ohne Vorschau.
Gewichtung: OEM hoch für VSOC-, Threat-Intelligence- und Ticketing-Round-Trips; Tier-1 hoch für den Austausch mit Anforderungswerkzeugen und OEM-lesbare Exporte.
Deployment- und Sicherheitsanforderungen für OEMs und Tier-1s
Über das Deployment wird oft erst nach der technischen Bewertung entschieden, was die Reihenfolge umkehrt: Eine Plattform, die nicht dort laufen kann, wo Ihre Daten liegen dürfen, ist kein Kandidat. Ein gehostetes Abonnement passt zu einer Abteilung, deren Datenklassifizierung es zulässt; eine Private Cloud nutzt die eigene Tenancy der Organisation; On-Premise- und Air-Gap-Deployments sind die Norm für klassifizierte Fahrzeugdaten und Märkte mit Residenzvorgaben. Bei einer Air-Gap-Instanz lautet die Frage vor allen anderen, wie Schwachstellen-Feeds ankommen: Die Antwort muss eine Offline-Feed-Synchronisation mit dokumentiertem Rhythmus sein.
| Anforderung | Warum sie zählt | Zu stellende Frage | Einzufordernder Nachweis |
|---|---|---|---|
| SSO / SAML | Ein- und Austritte werden einmal vom Identity Provider behandelt | Welche Protokolle (SAML 2.0, LDAP), in welcher Lizenzstufe? | Anmeldung über Ihren Identity Provider; ein entfernter Nutzer verliert den Zugriff |
| RBAC | Lieferanten, Prüfer und Freigeber sehen Unterschiedliches | Berechtigungen pro Modul und Aktion (lesen, schreiben, behandeln, freigeben, exportieren)? | Ein Lieferantenkonto, das nur freigegebene Nachweise sieht |
| MFA | Freigaben brauchen mehr als ein Passwort | Für alle Nutzer durchsetzbar, stärkerer Faktor für Produktionsänderungen? | Ein Produktions-Import-Commit, der einen frischen Passkey verlangt |
| Audit-Trail | Assessoren fragen, wer was wann und warum geändert hat | Akteur, Feld, Zeitstempel und Begründung bei jeder Änderung, einschließlich Policies und Importen? | Exportierter Trail eines gestuften Imports und einer Policy-Änderung |
| Datenresidenz | Fahrzeug- und Lieferantendaten dürfen eine Jurisdiktion nicht verlassen | Wo werden Daten pro Modell gespeichert; In-Region-Hosting für Märkte wie China? | Datenflussbeschreibung pro Modell; Regionsoptionen im Vertrag |
| Air-Gap-Feed-Sync | Der Abgleich ist nur so aktuell wie die Feeds | Wie werden NVD, OSV und regionale Feeds offline geliefert, wie oft, mit welcher Integritätsprüfung? | Offline-Feed-Import auf einer getrennten Instanz, Feed-Datum sichtbar |
| API-Zugang | Automatisierung braucht eine stabile Schnittstelle | Dokumentiert, versioniert, in der Lizenzstufe enthalten, RBAC-konform? | Lesen Ihres eigenen Projekts über die API mit einem eingeschränkten Token |
Ein OEM sollte SSO, RBAC, Audit-Trail und Datenresidenz als Bestanden/Nicht bestanden behandeln. Ein Tier-1 sollte eine Anforderung ergänzen, die die Tabelle auslässt: das Teilen von Nachweisen mit einem Kunden, der keine Lizenz in der Instanz des Lieferanten besitzt.
Die druckbare Checkliste, um eine Automotive-Cybersecurity-Plattform zu bewerten
Die Tabelle fasst die sieben Bereiche zu bewertbaren Zeilen zusammen. Gewichtungen sind hoch (H), mittel (M) oder Bestanden/Nicht bestanden (P), zuerst für einen OEM, dann für einen Tier-1.
| Bereich | Frage | Einzufordernder Nachweis | Gewichtung (OEM / Tier-1) |
|---|---|---|---|
| Architektur | Import mit Konformitätsübersicht, Warnungen, Downgrade-Liste und gestufter Freigabe; Komponenten mit eigenen Projekten verknüpft? | Import Ihres Modells; Audit-Trail von Analyse, Freigabe, Commit; Navigation vom Programm zum Projekt | H / M |
| TARA | Risiken aus Bedrohungsszenario und Angriffspfad generiert; Auswirkung, Wahrscheinlichkeit und CAL abgeleitet? | Ein Risiko vom Asset bis zur Maßnahme verfolgt; Asset gelöscht, Markierung angezeigt | H / H |
| TARA | Policy legt akzeptierte Stufen und Strategien fest und verweigert Verstöße; Behandlung erfasst Restrisiko und die Kette? | Hohes Risiko unter strenger Policy beibehalten; Behandlungsassistent; Assurance-Graph | H / H |
| SBOM | CycloneDX- und SPDX-Import; zusammenführen, ersetzen, nur aktualisieren; Status-Workflow? | Re-Import einer geänderten Lieferanten-SBOM, Differenz angezeigt | M / H |
| SBOM | Module den Komponenten zugeordnet, Mehrdeutiges zur Prüfung zurückgehalten; CVE bis Teilenummer und Markt verfolgt? | Zähler zugeordnet und nicht zugeordnet; eine CVE bis zu den Märkten verfolgt oder ein ehrliches „Kette unvollständig“ | H / H |
| Vorfälle | Verknüpft mit Komponenten, Risiken und Software; bestätigter Angriff markiert Risiko als eingetreten; nicht modellierter Angriff eröffnet TARA-Lücke; SLAs durchgesetzt? | Vorfall aus einer Threat-Intelligence-Meldung bis zum Risikostatus; Webhook an einen Test-Endpunkt | H / M |
| Nachweise | Freigegebene Baselines schreibgeschützt und abzweigbar; Design-Freeze; Variantenschutz; Map per Link teilbar? | Baseline freigeben, Bearbeitung versuchen, Entwurf abzweigen; geteilten Map-Link erneut öffnen | H / H |
| Governance | Policies automatisch versioniert; abschwächende Änderung braucht zweiten Freigeber; ReqIF-Export? | Policy-Änderung mit Banner „Freigabe ausstehend“; die ReqIF-Datei | H / H |
| Integrationen | Round-Trip: ReqIF heraus, SARIF hinein, Ticket heraus, Status zurück, Identifikatoren erhalten? | Der Round-Trip auf Ihren Dateien | H / H |
| Deployment | Identität, RBAC, MFA, Audit, Residenz, Air-Gap-Feeds, API gemäß obiger Tabelle? | Jeder Nachweis aus der Deployment-Tabelle | P / P |
Drei Regeln halten die Bewertung ehrlich. Senden Sie Ihre Dateien eine Woche vorher und bestehen Sie darauf, dass die Demo darauf läuft; eine Demo auf Anbieterdaten erhält in keiner Zeile mehr als einen Punkt. Bewerten Sie jede Zeile von null bis drei: nicht gezeigt, auf Anbieterdaten gezeigt, auf Ihren Daten gezeigt, auf Ihren Daten mit Audit-Trail gezeigt. Schließen Sie mit einem zeitlich begrenzten Pilot auf einem Programm und einer Baseline ab. Der Cybersecurity-Fragebogen für Lieferanten wendet dieselbe Disziplin auf die andere Seite der Übergabe an.
Wie ThreatZ diese Checkliste beantwortet
ThreatZ ist um den verknüpften Datensatz herum gebaut, nach dem diese Checkliste immer wieder fragt. Das Architekturmodell importiert UML/XMI und AUTOSAR und verknüpft jede Fahrzeugkomponente mit einem eigenen Sicherheitsprojekt innerhalb eines Programms. Risiken werden aus Bedrohungsszenarien und Angriffspfaden generiert, aus Schadensszenarien und Angriffsdurchführbarkeit bewertet, erhalten einen CAL aus Auswirkung und Angriffsvektor und unterliegen einer Policy, die verweigert, was sie nicht erlaubt. Die Behandlung verknüpft jedes Risiko mit Zielen, Anforderungen und Maßnahmen oder mit einem Claim samt Nachweis, wobei ein ISO/SAE 21434-Compliance-Panel Lücken anzeigt. Software Composition ordnet Architekturmodule den SBOM-Komponenten zu und verfolgt eine Schwachstelle über Softwareeinheit, Systemkomponente und Teilenummer bis zu VINs und Märkten auf der Traceability Map und der Fleet and Risk Map. Vorfälle markieren ein modelliertes Risiko bei Bestätigung als eingetreten und eröffnen eine TARA-Lücke, wenn der Angriff nie modelliert wurde. Das unterstützt die Nachweisführung für Arbeiten nach ISO/SAE 21434, UN R155 und R156, EU CRA und GB 44495; es ersetzt nicht die Bewertung selbst.
Die Stufen Team und Professional laufen als gehostetes Abonnement über den AWS Marketplace, mit MFA und RBAC ab Professional. Enterprise ergänzt die Programmebene, Fleet Map und Incident Command, den Lieferanten-Arbeitsbereich, SSO/SAML und API-Zugang sowie die Deployment-Optionen aus der Tabelle: Private Cloud oder On-Premise – Air-Gap-Betrieb unterstützt, mit Offline-Synchronisation der Schwachstellen-Feeds und In-Region-Hosting für Arbeiten nach GB 44495. Lizenziert wird pro benanntem Nutzer und Stufe, jährlich abgerechnet; Gäste der Lieferanten-Freigabe, die nur geteilte Nachweise einsehen, sind kostenfrei. Jede Bewertung kann mit einer vierwöchigen kostenlosen Testphase auf Beispiel-Fahrzeugdaten beginnen.
Häufig gestellte Fragen
Wie lange sollte die Bewertung einer Automotive-Cybersecurity-Plattform dauern?
Planen Sie in Etappen statt nach Kalender: ein bis zwei Wochen, um die unbeantworteten Fragen abzustimmen und Dateien zu sammeln, eine Skript-Demo pro Kandidat auf diesen Dateien und ein zeitlich begrenzter Pilot auf einem Programm und einer Baseline für die Plattform auf der Shortlist. Eine vierwöchige Testphase passt zum Pilot; Bewertungen, die länger laufen, fehlt meist ein Skript, nicht Zeit.
Sollten ein OEM und seine Tier-1-Lieferanten dieselbe Plattform nutzen?
Nicht zwingend; die Checkliste erlaubt beiden eine unabhängige Bewertung. Entscheidend an der Schnittstelle ist, dass Nachweise sie in offenen Formaten überqueren, ReqIF für Anforderungen, CycloneDX oder SPDX für SBOMs, OpenXSAM für TARA-Inhalte, und dass ein Lieferant Datensätze mit einem Kunden teilen kann, ohne dass der Kunde Lizenzen in der Instanz des Lieferanten kauft.
Ist ein gehostetes Deployment für Fahrzeug-Cybersecurity-Daten akzeptabel?
Das hängt von Datenklassifizierung und Jurisdiktion ab, weshalb die Deployment-Tabelle ein Gate ist und keine bewertete Zeile. Viele Abteilungen betreiben ein gehostetes Abonnement mit SSO, MFA und RBAC. Programme mit klassifizierten Fahrzeugdaten oder strengen Residenzvorgaben verlangen in der Regel Private Cloud, On-Premise oder Air-Gap-Betrieb mit Offline-Feed-Synchronisation.
Wie sollten KI-Funktionen in einer TARA-Plattform bewertet werden?
Behandeln Sie KI als prüfergestützte Entwurfshilfe und testen Sie die Kontrollen darum herum: Kann eine Empfehlung explizit angenommen oder abgelehnt werden, tragen die entstehenden Datensätze eine sichtbare Markierung, bis eine Person sie bestätigt, und bleiben Risikowerte aus Bedrohungsmodell und Policy abgeleitet? Ein Vorschlag, der stillschweigend in der Assurance-Kette landet, ist ein Governance-Problem.
Welche einzelne Demo-Anfrage ist am aufschlussreichsten?
Löschen Sie ein Asset im Bedrohungsmodell und beobachten Sie, was mit seinem Risiko geschieht; importieren Sie dann eine geänderte Lieferanten-SBOM erneut und beobachten Sie, was mit der vorherigen geschieht. Beide Tests zeigen, ob die Plattform Beziehungen als verwaltete Daten führt. Eine markierte entfernte Referenz und ein Re-Import mit Differenz bestehen; ein verschwundenes Risiko und ein stilles Überschreiben fallen durch.
- Skript vor Einkauf: Schreiben Sie die Fragen auf, die Ihr Stack nicht beantworten kann, und führen Sie jede Demo auf Ihren eigenen Dateien dagegen.
- Nach Rolle gewichten: OEMs gewichten Programmebene, Flottenexposition und Incident Command; Tier-1s gewichten TARA-Tiefe, SBOMs pro Lieferumfang und eine kostengünstige Übergabe.
- Importe müssen gestuft sein: Konformitätsübersichten, Warnungen, Downgrade-Listen und Freigabe durch eine zweite Person trennen einen verwalteten Import von einem Einfügen.
- Risiken werden generiert, nicht getippt: aus Bedrohungsszenario und Angriffspfad, bewertet aus Schadensszenarien und Durchführbarkeit, geregelt durch eine durchgesetzte Policy.
- CVE bis zur Teilenummer folgen: Der Wert der SBOM ist die Kette von Komponente über Softwareeinheit, Systemkomponente, Teilenummer und Fahrzeug bis zum Markt.
- Vorfälle speisen die TARA: Ein bestätigter Angriff markiert sein Risiko als eingetreten; ein nicht modellierter Angriff eröffnet eine TARA-Lücke.
- Deployment ist ein Gate: SSO, RBAC, MFA, Audit-Trail, Datenresidenz, Air-Gap-Feed-Sync und API-Zugang sind Bestanden/Nicht bestanden, entschieden vor der Funktionsbewertung.
Weiterführende Beiträge auf VxLabs Security
- ThreatZ mit Ihrem aktuellen Setup vergleichen
- ThreatZ-Plattform
- ThreatZ für OEM-CSMS-Teams
- ThreatZ für Tier-1-Lieferanten
- Reifegradmodell für Automotive Cybersecurity
- Ein einheitliches CSMS-Betriebsmodell aufbauen
Maßgebliche Referenzen
- ISO/SAE 21434 Straßenfahrzeuge — Cybersecurity Engineering — ISO und SAE International, ISO/SAE 21434
- UN-Regelung Nr. 155 Cybersicherheit und Cybersicherheits-Managementsystem — UNECE, R155
- UN-Regelung Nr. 156 Software-Updates und Software-Update-Managementsystem — UNECE, R156
- Cyber Resilience Act — Europäisches Parlament und Rat, Verordnung (EU) 2024/2847
- GB 44495-2024 Technische Anforderungen an die Fahrzeug-Cybersicherheit — SAMR/SAC, GB 44495-2024
- ISO/PAS 5112 Straßenfahrzeuge — Leitlinien für die Auditierung des Cybersecurity Engineering — ISO, ISO/PAS 5112