Ein Cybersicherheits-Assurance-Case ist die Erzählung, die Ihre TARA, Kontrollen und Tests mit einem verteidigbaren Claim verbindet. CAE (Claims-Arguments-Evidence) und GSN (Goal Structuring Notation) sind die zwei dominanten Notationen.
Automotive-Cybersecurity-Teams erzeugen grosse Mengen an Beweismitteln: TARAs, Architekturmodelle, Cybersecurity-Ziele, Anforderungen, Testberichte, Penetrationstest-Befunde, SBOMs, Schwachstellen-Entscheidungen, Lieferantenerklärungen, Software-Update-Datensaetze und Vorfallberichte. Eine grosse Beweismittelsammlung erklärt aber nicht automatisch, warum ein Fahrzeug, ECU oder eine Software-Plattform angemessen sicher ist.
Diese Erklärung ist der Zweck eines Automotive-Cybersecurity-Assurance-Case.
Ein Assurance-Case verbindet drei Dinge: einen Claim über die Sicherheit eines definierten Systems, ein Argument, das erklärt, warum der Claim plausibel ist, und Evidence, die jeden Schritt des Arguments stützt. Er erfasst auch Annahmen, Betriebsbedingungen, Restrisiken, Konfidenz und die Grenzen dessen, was nachgewiesen wurde.
Das ist mehr als ein polierter Compliance-Report. Ein gut konzipierter Assurance-Case wird zu einer wiederverwendbaren Engineering-Struktur. Tier-2-Lieferanten können Komponenten-Sub-Cases liefern. Tier-1-Lieferanten können sie mit Integrations-Beweismitteln kombinieren. OEMs können fahrzeugweite Argumente zusammenstellen, ohne jede Lieferantenbewertung aus Rohdateien neu aufzubauen. Wenn sich Software, Architektur, Schwachstellen oder Betriebsbedingungen ändern, können die betroffenen Claims identifiziert und neu bewertet werden.
Dieser Leitfaden erklärt, wie man dieses Betriebsmodell aufbaut, ohne einen allgemeinen ISO/SAE-21434-Umsetzungsleitfaden oder eine Audit-Checkliste zu duplizieren. Im Fokus steht die Reasoning-Struktur, die unverbundene Arbeitsprodukte in ein verteidigbares, pflegbares Cybersicherheits-Argument verwandelt.
Was ist ein Automotive-Cybersicherheits-Assurance-Case?
Ein Automotive-Cybersecurity-Assurance-Case ist ein strukturiertes, evidence-gestütztes Argument dafür, dass ein Fahrzeug-Item, eine Komponente, Funktion oder ein System ein akzeptables Cybersicherheitsniveau in einem definierten Kontext erreicht.
Ein einfaches Beispiel könnte mit dem Top-Level-Claim beginnen:
Die Telematik-Plattform ist über ihren gesamten Support-Lebenszyklus angemessen gegen unautorisierte Fernsteuerung geschuetzt.
Dieser Claim ist für sich zu breit, um akzeptiert zu werden. Das Argument muss ihn in kleinere Claims zerlegen, etwa:
- Extern erreichbare Schnittstellen sind identifiziert und geschuetzt.
- Geraete- und Backend-Identitäten sind authentifiziert.
- Privilegierte Kommandos sind autorisiert und eingegrenzt.
- Software-Integritaet ist vom Build bis zur Installation geschuetzt.
- Sicherheitskontrollen wurden in repräsentativen Umgebungen verifiziert.
- Schwachstellen und Feld-Vorfälle werden überwacht und behandelt.
- Restrisiken sind bekannt, freigegeben und durch explizite Annahmen begrenzt.
Jeder Sub-Claim wird dann durch Evidence gestützt. Evidence kann Architektur-Baselines, Schnittstelleninventare, Bedrohungsanalyse, Sicherheitsanforderungen, Implementierungs-Datensaetze, Testergebnisse, signierte Release-Manifeste, Penetrationstest-Berichte, Schwachstellen-Datensaetze und Monitoring-Verfahren umfassen.
Der Case sollte auch seinen Scope ausweisen. "Sicher" ist ohne Grenzen bedeutungslos. Ein verteidigbarer Case identifiziert das exakte Produkt, Hardware- und Software-Versionen, Varianten, Lieferanten, Betriebsbedingungen, Support-Zeitraum, Deployment-Umgebung und Ausschluesse, auf die das Argument anwendbar ist.
Evidence ist nicht dasselbe wie ein Argument
Viele Organisationen nennen einen Ordner mit Arbeitsprodukten einen Cybersecurity-Case. Der Ordner mag vollstaendig sein, doch der Reviewer muss trotzdem schlussfolgern, wie die Teile zusammenpassen.
Stellen Sie sich einen Penetrationstest-Bericht vor, der kein ausnutzbares Problem an einer Diagnose-Schnittstelle zeigt. Dieser Bericht ist Evidence, aber er belegt für sich nicht, dass die Schnittstelle angemessen geschuetzt ist. Das Argument muss zeigen:
- Warum diese Schnittstelle für den Top-Level-Claim relevant ist.
- Welche Bedrohungen und Angriffspfade der Test abdeckte.
- Welche Konfiguration und Version getestet wurden.
- Ob die Testmethode dem erwarteten Angreifer entsprach.
- Welche Kontrollen geuebt wurden.
- Welche Einschraenkungen oder ungetesteten Bedingungen verbleiben.
- Ob das Ergebnis nach spaeteren Änderungen noch gueltig ist.
Ohne dieses Reasoning kann Evidence technisch beeindruckend, für den Claim aber irrelevant sein.
Das umgekehrte Problem tritt ebenfalls auf. Ein Bericht kann starke narrative Aussagen, aber schwache Belege enthalten. "Secure Boot verhindert unautorisierte Software" ist ein Argument-Fragment, keine Evidence. Die stützende Evidence könnte das Boot-Chain-Design, die Trust-Anchor-Provisionierung, Signatur-Validierungs-Testergebnisse, Negativtests, Schlüsselmanagement-Kontrollen und Release-Datensaetze für die tatsaechliche Produkt-Baseline umfassen.
Ein reifer Assurance-Case macht die Unterscheidung explizit: Claims sagen, was geglaubt wird, Arguments erklären warum, und Evidence zeigt, was beobachtet oder implementiert wurde.
Die zentralen Bausteine
Claims
Claims sind klare, prüfbare Aussagen über Sicherheit, Prozess oder Evidence-Qualität. Sie sollten so konkret sein, dass ein Reviewer entscheiden kann, ob sie gestützt werden.
Nützliche Claim-Muster umfassen:
- Ein definiertes Asset ist gegen eine definierte Bedrohungsklasse geschuetzt.
- Ein Risiko wurde unter die Akzeptanzschwelle der Organisation gesenkt.
- Eine Kontrolle ist für jede anwendbare Variante implementiert.
- Eine Anforderung ist durch aktuelle Evidence verifiziert.
- Eine Lieferantenkomponente erfuellt unter dokumentierten Annahmen die genannten Sicherheitseigenschaften.
- Ein Post-Production-Prozess ist in der Lage, relevante Schwachstellen zu erkennen und zu behandeln.
Vermeiden Sie absolute Claims wie "das Fahrzeug kann nicht gehackt werden". Assurance ist kontextbezogen und evidenzbasiert, keine Null-Risiko-Garantie.
Arguments
Arguments verbinden Claims logisch. Gaengige Strategien zerlegen einen Top-Level-Claim:
- Nach Architektur: Fahrzeug, Domain, ECU, Softwareeinheit, Schnittstelle.
- Nach Lebenszyklus: Konzept, Entwicklung, Produktion, Betrieb, Wartung, Stilllegung.
- Nach Bedrohung: Spoofing, Tampering, Privilege-Missbrauch, Denial of Service, Informationsoffenlegung.
- Nach Kontrollziel: verhindern, erkennen, eindaemmen, wiederherstellen.
- Nach Lieferanten-Verantwortung: OEM, Tier-1, Tier-2, Cloud-Provider, Service-Betreiber.
- Nach Betriebszustand oder Variante: Fertigung, Werkstatt, Kundennutzung, degradierter Modus, regionale Konfiguration.
Die gewählte Zerlegung sollte zu der Art passen, wie Risiko und Evidence tatsaechlich gemanagt werden. Ein schoenes Diagramm, das nicht auf die Engineering-Verantwortung abbildet, wird veralten.
Evidence
Evidence sollte identifizierbar, attributierbar, versioniert und mit dem unterstützten Claim verknuepft sein. Typische Evidence umfasst:
- Item-Definitionen und Architektur-Baselines.
- Asset-, Schadens-Szenario-, Bedrohungs-, Angriffspfad- und Risiko-Datensaetze.
- Cybersicherheits-Ziele, -Anforderungen, -Kontrollen und Implementierungs-Claims.
- Design-Reviews und Code-Analyse-Ergebnisse.
- MIL-, SIL-, HIL-, Fahrzeug-, Fuzzing- und Penetrationstest-Beweismittel.
- SBOMs, VEX-Statements, Schwachstellen-Datensaetze und Remediationsentscheidungen.
- Secure-Build-, Signing-, Release- und Software-Update-Datensaetze.
- Lieferantenzertifikate, Evaluierungsberichte und Assumptions of Use.
- Incident-Response-Übungen und Post-Production-Monitoring-Beweismittel.
- Audit-Logs, Freigaben, Abweichungen und Restrisiko-Akzeptanz.
Die Qualität der Evidence zählt mehr als die Anzahl der Dateien. Ein Ergebnis ohne Produktversion, Konfiguration, Datum, Owner, Methode oder erwartetes Resultat ist schwer belastbar.
Kontext und Annahmen
Jeder Claim hängt vom Kontext ab. Beispiele:
- Ein Hardware-Security-Modul ist mit OEM-kontrollierten Schlüsseln provisioniert.
- Debug-Schnittstellen sind in der Produktion deaktiviert.
- Ein Backend-Dienst erzwingt Multi-Faktor-Authentifizierung für privilegierte Nutzer.
- Das Fahrzeug wird innerhalb spezifizierter Umwelt- oder Netzwerkbedingungen betrieben.
- Ein Lieferanten-Patch wird integriert, ohne eine geschuetzte Schnittstelle zu verändern.
Annahmen sollten sichtbar und prüfbar sein. Verborgene Annahmen sind eine Hauptursache für Assurance-Versagen. Wenn eine Annahme nicht mehr gilt, sollten die betroffenen Claims automatisch in die Prüfung gehen.
Justifications und Restrisiken
Der Case sollte erklären, warum eine bestimmte Argument-Strategie, Testtiefe oder Risikoentscheidung akzeptabel ist. Er sollte auch Restrisiken benennen, statt sie in ein separates Register zu verschieben.
Ein Restrisiko-Statement sollte die verbleibende Exposition, den betroffenen Scope, kompensierende Kontrollen, Monitoring, Entscheidungs-Owner, Freigabedatum und die Bedingungen nennen, die eine Neubewertung auslösen.
Mit der Entscheidung beginnen, die der Case stützen soll
Ein Assurance-Case sollte für eine reale Entscheidung gebaut werden, nicht als abstrakte Dokumentationsübung. Typische Entscheidungen sind:
- Freigabe eines ECU für ein OEM-Programmgate.
- Akzeptanz einer Lieferantenkomponente zur Integration.
- Nachweis der Bereitschaft für die Typgenehmigung.
- Freigabe eines Software-Release oder einer OTA-Kampagne.
- Akzeptanz eines Restrisikos.
- Beurteilung, ob eine Schwachstelle eine ausgelieferte Flotte betrifft.
- Nachweis gegenüber einem Assessor, dass die geforderten Cybersicherheitseigenschaften implementiert und verifiziert sind.
Die Entscheidung bestimmt Scope, Adressaten, Detailtiefe und die erforderliche Evidence-Aktualitaet.
Eine Sourcing-Entscheidung kann stark auf Komponenten-Sicherheitseigenschaften, Entwicklungsprozess-Evidenz, Zertifizierung, Assumptions of Use und Lieferanten-Support-Verpflichtungen ruhen. Eine Release-Entscheidung braucht exakte Konfiguration, Testergebnisse, ungeloeste Befunde, freigegebene Abweichungen und den Deployment-Scope. Eine Feld-Schwachstellen-Entscheidung braucht SBOM-Verknuepfung, Ausnutzbarkeits-Kontext, Angriffspfade, Kontrollen, Flotten-Exposition und Behebungs-Evidenz.
Der Versuch, einen statischen Bericht für alle diese Entscheidungen zu nutzen, erzeugt entweder ein unlesbares Dokument oder ein zu generisches Argument.
Eine Claim-Architektur aufbauen, bevor weitere Dokumente gesammelt werden
Der schnellste Weg, einen Assurance-Case zu verbessern, ist oft, vorübergehend mit dem Sammeln aufzuhoeren und die Claim-Struktur zu entwerfen.
Ein praktischer Top-Down-Prozess:
- Item- und Entscheidungsgrenze definieren.
- Einen Top-Level-Claim in einfacher Sprache formulieren.
- Die wesentlichen Argument-Strategien zur Stützung benennen.
- Jede Strategie in prüfbare Sub-Claims zerlegen.
- Die bereits vorhandene Evidence anhängen.
- Nicht gestützte, teilweise gestützte, veraltete oder annahmen-abhängige Claims kennzeichnen.
- Owner und Schliessungs-Aktionen zuweisen.
Das erzeugt ein Evidence-Demand-Modell. Statt Teams zu bitten, alles hochzuladen, kann die Organisation den genauen Beleg anfordern, der für einen ungestützten Claim noetig ist.
Ein Telematik-Assurance-Case könnte sechs Top-Level-Strategien nutzen:
- Architektur und Angriffsflaeche sind verstanden.
- Sicherheitsrisiken sind identifiziert und behandelt.
- Trust-, Zugriffs- und Software-Integritaets-Kontrollen sind implementiert.
- Kontrollen sind gegen repräsentative Angriffspfade verifiziert.
- Lieferanten- und Betriebsabhängigkeiten sind gesteuert.
- Schwachstellen und Vorfälle werden über den Support hinweg gemanagt.
Jede Strategie kann dann nur soweit ausgebaut werden, wie Risiko und Entscheidung es erfordern.
Modulare Assurance-Cases über die Lieferkette
Die Automotive-Lieferkette macht monolithische Assurance-Cases ineffizient. Ein Tier-2-Lieferant kann ein Secure Element, ein Betriebssystem, einen Kommunikationsstack, einen Sensor oder eine Bibliothek liefern, die über viele ECUs und Fahrzeugprogramme genutzt wird. Die gleiche Evaluation für jede Integration zu wiederholen, verschwendet Zeit und erzeugt Inkonsistenz.
Ein modulares Modell behandelt das Argument des Lieferanten als Sub-Case, der in einen größeren Case komponiert werden kann.
Ein Komponenten-Sub-Case sollte enthalten:
- Den Evaluationsgegenstand und die exakte Version.
- Beanspruchte Sicherheitseigenschaften.
- Berücksichtigte Bedrohungen und Angreiferannahmen.
- Sicherheitsfunktionen und -grenzen.
- Evaluierungs- und Test-Beweismittel.
- Bekannte Schwachstellen und Restrisiken.
- Erforderliche Umgebungskontrollen.
- Integrations-Leitfaden und verbotene Nutzungen.
- Gueltigkeitsbedingungen, Support-Zeitraum und Änderungs-Notifikationsregeln.
Der Tier-1 hängt nicht einfach das Zertifikat oder den Bericht an. Er fuegt ein Integrations-Argument hinzu, das zeigt, dass die Komponente innerhalb ihrer evaluierten Bedingungen verwendet, korrekt konfiguriert und mit den erforderlichen umliegenden Kontrollen kombiniert wird.
Der OEM ergänzt dann fahrzeugweite Evidence zu domaenenübergreifenden Angriffspfaden, Variantenverhalten, Lieferanten-Interaktionen, Diagnose, Backend-Diensten, Updates und Post-Production-Betrieb.
Das schuetzt geistiges Eigentum. Lieferanten können ein abgegrenztes Claim- und Evidence-Paket exponieren, ohne jedes Designdetail offenzulegen. Die empfangende Organisation erhaelt dennoch genug Informationen, um Anwendbarkeit und Integrationsrisiko zu bewerten.
Wie Komponentenzertifizierung den Case stützen kann
Komponenten-Evaluierungsschemata wie GlobalPlatform SESIP sind relevant, weil sie definierte Security Targets, Assurance Levels, Profile, Komposition und Wiederverwendung betonen. Eine zertifizierte Komponente kann glaubwuerdige Evidence für einen Teil des Fahrzeug-Arguments liefern.
Zertifizierung ersetzt jedoch keine fahrzeugweite TARA oder Integrations-Assurance.
Ein Zertifikat zeigt vielleicht, dass eine Komponente definierte Sicherheitsfunktionen implementiert und evaluiert hat. Es belegt nicht automatisch:
- Dass der OEM diese Funktionen korrekt konfiguriert hat.
- Dass erforderliche Schlüssel und Identitäten sicher provisioniert wurden.
- Dass die umgebende Software die Funktionen sicher aufruft.
- Dass Assumptions of Use erfuellt sind.
- Dass die Integration keinen neuen Angriffspfad eingeführt hat.
- Dass die evaluierte Version die tatsaechlich ausgelieferte ist.
- Dass operative Monitoring- und Update-Prozesse wirksam bleiben.
Nutzen Sie Komponentenzertifizierung als Evidence-Modul. Mappen Sie jede zertifizierte Eigenschaft auf den fahrzeugweiten Claim, den sie stützt, dokumentieren Sie die Annahmen und fuegen Sie integrationsspezifische Evidence hinzu. So bleibt Wiederverwendung möglich, ohne überzubewerten, was die Zertifizierung belegt.
Mit der Weiterentwicklung der Automotive-Arbeiten an Cybersecurity Assurance Levels und Targeted Attack Feasibility ist zu erwarten, dass die Anpassung des Assurance-Aufwands an das Risiko strukturierter diskutiert wird. Das praktische Prinzip ist bereits nützlich: Wenden Sie staerkere Evidence, Unabhängigkeit, Testtiefe und Konfigurationssteuerung auf Claims an, deren Ausfall größere Auswirkungen erzeugen könnte oder deren Angriffsmachbarkeit höhere Konfidenz erfordert.
Konfidenz: wie stark ist die Evidence?
Ein binaerer Status "gestützt/nicht gestützt" ist oft zu grob. Zwei Claims können beide Evidence haben, doch einer ist durch einen unabhängigen Labortest auf der Produktions-Baseline gestützt, während der andere auf einem alten Design-Review für eine aehnliche Variante beruht.
Ein Assurance-Konfidenz-Modell kann berücksichtigen:
- Relevanz: Adressiert die Evidence den Claim direkt?
- Scope: Deckt sie das tatsaechliche Produkt, die Variante und Konfiguration ab?
- Rigorositaet: War die Methode dem Angreifer und Risiko angemessen?
- Unabhängigkeit: Wurde die Evidence wo noetig unabhängig erzeugt oder geprüft?
- Aktualitaet: Ist sie nach Änderungen und neuen Schwachstellen noch gueltig?
- Integritaet: Sind Evidence und Provenienz vertrauenswuerdig?
- Vollstaendigkeit: Fehlen signifikante Bedingungen oder Angriffspfade?
- Wiederholbarkeit: Kann das Ergebnis reproduziert oder unabhängig geprüft werden?
Konfidenz sollte kein willkuerlicher Score werden, der Engineering-Urteil verdeckt. Verwenden Sie klare Kriterien und verknuepfen Sie jede Bewertung mit der zugrunde liegenden Evidence und ihren Grenzen.
Änderungen als Assurance-Impact-Ereignisse behandeln
Statische Assurance-Cases zerfallen in softwaredefinierten Fahrzeugen schnell. Eine Änderung kann nur einen Argumentzweig entkraeften oder den gesamten Top-Level-Claim untergraben.
Ereignisse, die eine Impact-Analyse auslösen sollten:
- Architektur-, Schnittstellen- oder Vertrauensgrenze-Änderungen.
- Hardware- oder Softwareversionswechsel.
- Neue Lieferanten oder Subliferanten-Komponenten.
- Änderungen der Sicherheitskontroll-Konfiguration.
- Fehlgeschlagene oder abgelaufene Test-Evidence.
- Neue Schwachstellen oder Threat Intelligence.
- Geänderte Assumptions of Use.
- Neue Betriebsumgebungen oder Fahrzeugvarianten.
- Vorfälle, anomales Feldverhalten oder Rückruferkenntnisse.
- End-of-Support oder nicht verfügbare Behebung.
Das Assurance-Modell sollte erkennen, welche Claims von der geänderten Entitaet abhängen. Eine neue Schwachstelle in einer Krypto-Bibliothek sollte zu den betroffenen Komponenten, ECUs, Kontrollen, Tests, ausgelieferten Varianten, Lieferanten-Claims und Top-Level-Argumenten führen. Teams können dann den betroffenen Zweig prüfen, statt den gesamten Case manuell neu zu öffnen.
Das ist der Unterschied zwischen einem lebendigen Assurance-Case und einem Bericht, der zu einem Meilenstein erstellt wird.
Evidence-Akzeptanzkriterien gestalten
Evidence sollte definierte Qualitäts-Gates durchlaufen, bevor sie einen Claim stützen kann. Eine wiederverwendbare Akzeptanz-Checkliste kann verlangen:
- Eindeutige Evidence-Kennung.
- Produkt- und Konfigurations-Scope.
- Quell-Organisation und verantwortlicher Owner.
- Methode, Werkzeug und Umgebung.
- Datum und Gueltigkeitszeitraum.
- Erwartetes und beobachtetes Ergebnis.
- Rohdaten-Artefakt oder geschuetzte Quelle.
- Prüf- und Freigabestatus.
- Verknuepfte Anforderung, Kontrolle, Bedrohung, Risiko oder Claim.
- Einschraenkungen und Abweichungen.
- Integritaets- oder Signaturinformationen, wo passend.
Lieferantenvertraege sollten diese Felder und das Austauschformat spezifizieren. "Stellen Sie einen Penetrationstest-Bericht bereit" reicht nicht. Die Vereinbarung sollte Ziel-Baseline, Abdeckungserwartungen, Schweregradbehandlung, Evidence-Aufbewahrung, Remediations-Workflow und das, was nach einer Änderung aktualisiert werden muss, festlegen.
Häufige Fehlerbilder von Assurance-Cases
Der Document Dump
Hunderte von Dateien werden ohne navigierbares Argument geliefert. Reviewer rekonstruieren das Reasoning selbst, was Kosten und Inkonsistenzen erhoeht.
Zirkulaeres Reasoning
Ein Claim wird durch eine Anforderung gestützt, und die Anforderung gilt als erfuellt, weil sie existiert. Der Case muss Implementierungs- und Verifikations-Evidenz enthalten, nicht nur die Spezifikation.
Zertifizierungs-Überreichweite
Ein Komponentenzertifikat wird als Beleg dafür behandelt, dass der komplette ECU oder das Fahrzeug sicher ist. Integrationsannahmen und Cross-Component-Verhalten werden ignoriert.
Unkontrollierte Wiederverwendung
Evidence aus einem anderen Programm wird kopiert, ohne nachzuweisen, dass Architektur, Konfiguration, Bedrohungskontext und Annahmen äquivalent sind.
Veraltete Evidence
Der Test ist vor zwei Releases bestanden worden, der Claim erscheint aber nach relevanten Änderungen noch immer gruen.
Unsichtbare Annahmen
Das Argument hängt von sicherer Provisionierung, Backend-Kontrollen, Werkstattrichtlinien oder Operator-Verhalten ab, das im Case nicht abgebildet ist.
Evidence ohne Negativtests
Es wird nur erwartetes Verhalten getestet. Dem Case fehlt der Nachweis, dass unautorisierte, fehlgeformte, wiedereingespielte, abgelaufene oder nicht-sequenzgerechte Aktionen sicher abgelehnt werden.
Kein Owner für den Top-Level-Claim
Einzelne Teams besitzen Artefakte, doch niemand ist dafür verantwortlich, zu entscheiden, ob das kombinierte Argument angemessen ist.
Eine praktische 12-Wochen-Umsetzungs-Roadmap
Woche 1-2: Eine Entscheidung und ein Item auswählen
Waehlen Sie ein reales Programmgate, Release oder eine Lieferantenakzeptanz-Entscheidung. Definieren Sie Scope, Adressaten, Baseline und Top-Level-Claim.
Woche 3-4: Claim-Architektur aufbauen
Zerlegen Sie den Top-Level-Claim in Strategien und Sub-Claims. Erfassen Sie Annahmen, Kontexte und Restrisiko-Entscheidungen.
Woche 5-6: Vorhandene Evidence mappen
Verknuepfen Sie aktuelle TARA, Anforderungen, Kontrollen, Tests, SBOM, Lieferanten-, Release- und Betriebsartefakte. Klassifizieren Sie jeden Claim als gestützt, teilweise, ungestützt, veraltet oder nicht anwendbar.
Woche 7-8: Kritische Evidence-Luecken schliessen
Priorisieren Sie ungestützte High-Impact-Claims, ungueltige Annahmen, fehlende Integrations-Evidenz und alte Testergebnisse. Versuchen Sie nicht, zuerst jeden Low-Risk-Zweig zu perfektionieren.
Woche 9-10: Lieferanten-Sub-Case-Muster erstellen
Definieren Sie ein Standardpaket für einen Komponentenlieferanten mit Eigenschaften, Evidence, Assumptions of Use, Versions-Scope und Änderungsverpflichtungen. Prüfen Sie, ob Tier-1 oder OEM es ohne unnoetige IP-Offenlegung komponieren können.
Woche 11-12: Eine unabhängige Prüfung durchführen
Bitten Sie einen Reviewer, der den Case nicht gebaut hat, vom Top-Level-Claim zur Evidence und zurück zu navigieren. Erfassen Sie Fragen, fehlende Verknuepfungen, mehrdeutiges Reasoning und Antwortzeiten. Setzen Sie eine Baseline und definieren Sie Update-Trigger.
Der Pilot ist erfolgreich, wenn ein Entscheidungstraeger versteht, warum der Claim gestützt ist, wo die Konfidenz schwach ist und was die Schlussfolgerung entkraeften wuerde.
Kennzahlen für Assurance-Case-Qualität
Nützliche Kennzahlen umfassen:
- Anteil der Top-Level- und kritischen Sub-Claims mit akzeptierter Evidence.
- Anzahl der Claims, die nur durch indirekte oder veraltete Evidence gestützt werden.
- Anteil der Evidence, die mit einer exakten Konfigurations-Baseline verknuepft ist.
- Anzahl unverifizierter Assumptions of Use.
- Zeit, um einen Claim zu seiner Evidence zu verfolgen.
- Zeit, um von einer Änderung oder CVE betroffene Claims zu identifizieren.
- Anteil der Lieferanten-Sub-Cases, die das Standard-Akzeptanzschema erfuellen.
- Wiederverwendungsquote gueltiger Komponenten-Sub-Cases über Programme.
- Anzahl Restrisiken ohne benannten Entscheidungs-Owner oder Review-Datum.
- Durchschnittsalter der Evidence, die kritische Claims stützt.
- Review-Fragen, die manuelle Suchen ausserhalb des Cases erfordern.
- Anteil fehlgeschlagener Tests oder Vorfälle, die betroffene Claims automatisch wieder öffnen.
Das Ziel ist nicht, die Anzahl der Claims zu maximieren. Es ist, das Reasoning vollstaendig, prüfbar, aktuell und risikoangemessen zu machen.
Wie ThreatZ einen lebendigen Assurance-Case unterstützt
Ein Assurance-Case ist von Natur aus ein Connected-Data-Problem. Claims hängen von Risiken ab; Risiken von Assets, Bedrohungen, Angriffspfaden und Annahmen; Kontrollen implementieren Anforderungen; Tests verifizieren Kontrollen; Lieferanten-Evidence stützt Komponenten-Eigenschaften; Releases definieren Konfiguration; Schwachstellen und Vorfälle können früheren Schlussfolgerungen die Grundlage entziehen.
ThreatZ kann diese Beziehungen in einem Cybersicherheits-Knowledge-Graph abbilden, sodass der Case aus aktuellem Engineering und Betriebs-Evidence generiert wird, statt in ein separates Dokument kopiert zu werden. Teams können ungestützte Claims identifizieren, Lieferanten-Sub-Cases wiederverwenden, Evidence in beide Richtungen verfolgen und sehen, welche Argumentzweige von einer Änderung betroffen sind.
Ein starker Pilot ist ein ECU oder eine Plattform mit einer klaren Sourcing- oder Release-Entscheidung. Bauen Sie den Top-Level-Claim, importieren Sie vorhandene Evidence, decken Sie die ungestützten Zweige auf und weisen Sie nach, dass eine Lieferanten- oder Komponentenänderung zu den exakten zu prüfenden Claims führt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem Cybersecurity-Case und einem Assurance-Case?
Die Begriffe werden oft synonym verwendet. "Assurance-Case" betont eine explizite Claims-Arguments-Evidence-Struktur. Ein Cybersecurity-Case, der nur eine Sammlung von Arbeitsprodukten enthaelt, mag eine Dokumentationskonvention erfuellen, liefert aber schwächeres Reasoning als ein strukturierter Assurance-Case.
Verlangt ISO/SAE 21434 einen Cybersecurity-Case?
ISO/SAE 21434 führt den Cybersecurity-Case als Lebenszyklus-Arbeitsprodukt. Die praktische Qualitätsfrage ist, ob der Case ein strukturiertes Argument mit aktueller Evidence präsentiert oder lediglich Dokumente buendelt.
Kann ein Lieferantenzertifikat OEM-fahrzeugweite Evidence ersetzen?
Nein. Ein Zertifikat kann definierte Komponenten-Claims stützen, doch der Integrator muss korrekte Konfiguration, Assumptions of Use, umgebende Kontrollen, Versionsidentitaet und fahrzeugweites Verhalten nachweisen.
Was ist ein modularer Assurance-Case?
Es ist ein Assurance-Case, der aus wiederverwendbaren Sub-Cases mit expliziten Schnittstellen und Annahmen zusammengesetzt ist. Ein Tier-2-Komponenten-Case kann einen Tier-1-System-Case stützen, der dann einen OEM-Fahrzeug-Case stützt.
Wie oft sollte der Assurance-Case aktualisiert werden?
Aktualisieren Sie ihn, sobald ein Ereignis einen Claim, eine Annahme, Evidence-Gueltigkeit oder ein Restrisiko ändern kann. Relevante Ereignisse sind Architekturänderungen, Releases, Lieferantenwechsel, neue Schwachstellen, fehlgeschlagene Tests, Vorfälle und geänderte Betriebsbedingungen.
Was ist der beste erste Use Case?
Waehlen Sie eine Produktentscheidung mit fragmentierter, aber verfügbarer Evidence, zum Beispiel die Akzeptanz einer sicherheitskritischen Komponente oder die Freigabe eines ECU-Releases. Der Wert wird sichtbar, wenn das Team von einem Top-Level-Claim zu exakter, versionierter Evidence gelangt, ohne das Argument in Meetings zu rekonstruieren.
Autoritative Referenzen
- ISO/SAE 21434:2021 - Road vehicles - Cybersecurity engineering
- ISO/PAS 5112:2022 - Guidelines for auditing automotive cybersecurity engineering
- Automotive ISAC - Constructive Cybersecurity Assurance Cases
- GlobalPlatform SESIP - Methodik und Ressourcen
- GlobalPlatform - Cybersecurity Vehicle Forum 2026