Überblick
Die Compliance-Säule bietet eine strukturierte regulatorische Compliance-Bewertung, Evidenzmanagement und Audit-Berichterstattung für die ThreatZ-Plattform. Sie ermöglicht es Automotive-Cybersecurity-Teams, ihre Sicherheitslage gegen ISO/SAE 21434:2021 und UNECE R155/R156 zu bewerten, die Fertigstellung von Arbeitsprodukten nachzuverfolgen, Compliance-Verstöße in Echtzeit zu erkennen und audit-fertige Berichte mit Lückenanalyse und Empfehlungen zu generieren.
Unterstützte Standards
| Standard | Geltungsbereich | Abdeckung |
|---|---|---|
| ISO/SAE 21434:2021 | Cybersecurity-Engineering für Straßenfahrzeuge | 15 Klauseln, vollständige Anforderungszuordnung |
| UNECE R155 | Cybersecurity und CSMS | Fahrzeugkategorie-spezifisch, Anhang-5-Bedrohungen |
| UNECE R156 | Software-Update-Management | Referenziertes Framework |
| ISO 26262 | Funktionale Sicherheit | Framework-Standardreferenz |
| SAE J3061 | Cybersecurity-Leitfaden | Framework-Standardreferenz |
| China GB Standard | Fahrzeug-Cybersecurity (Klauseln 7–8) | Professional+ Tier |
Compliance-Struktur
Das Compliance-Framework ist hierarchisch organisiert:
Standard
→ Klausel (z.B. Klausel 9: Konzeptphase)
→ Abschnitt (z.B. 9.3: TARA)
→ Datensatz (z.B. RQ-09-04: Schadensszenarien identifizieren)
• Antwort (erfüllt / nicht erfüllt)
• Notizen (Evidenzbeschreibung)
• Arbeitsprodukte (WP-Links)Anforderungs-ID-Formate:
RQ-XX-YY— Anforderung (verbindlich)RC-XX-YY— Empfehlung (beratend)PM-XX-YY— Praxis (Anleitung)
ISO 21434 Klauselabdeckung
| Klausel | Titel | Schwerpunkt |
|---|---|---|
| 5 | Organisatorisches Cybersecurity-Management | Richtlinien, Kompetenz, Werkzeuge, Audits |
| 6 | Projektabhängiges Cybersecurity-Management | Cybersecurity-Plan, -Fall, -Bewertung |
| 7 | Verteilte Cybersecurity-Aktivitäten | Schnittstellenvereinbarungen mit Lieferanten |
| 8 | Kontinuierliche Cybersecurity-Aktivitäten | Überwachung, Schwachstellenmanagement |
| 9 | Konzeptphase | Item-Definition, TARA, Ziele, Behauptungen |
| 10 | Produktentwicklung | Spezifikationen, Design, Integration, Verifikation |
| 11 | Cybersecurity-Validierung | Validierungsbericht |
| 12 | Produktion | Produktionskontrollplan |
| 13 | Betrieb & Wartung | Incident-Response-Plan |
| 14 | Ende der Cybersecurity-Unterstützung | Stilllegungsverfahren |
| 15 | TARA-Methoden | Bedrohungsanalyse, Risikobewertungsmethodik |
Nachverfolgung von Arbeitsprodukten
44 Arbeitsprodukte über alle Klauseln hinweg zugeordnet:
| ID-Bereich | Kategorie | Beispiele |
|---|---|---|
| WP-05-01 bis WP-05-05 | Organisationsmanagement | Cybersecurity-Richtlinie, Kompetenzmanagement, Auditberichte |
| WP-06-01 bis WP-06-04 | Projektmanagement | Cybersecurity-Plan, Cybersecurity-Fall, Bewertungsbericht |
| WP-07-01 | Verteilte Aktivitäten | Cybersecurity-Schnittstellenvereinbarung |
| WP-08-01 bis WP-08-06 | Kontinuierliche Aktivitäten | Quellen, Auslöser, Ereignisse, Schwachstellen, Analyse, Evidenz |
| WP-09-01 bis WP-09-07 | Konzeptphase | Item-Definition, TARA, Ziele, Behauptungen, Verifikationsberichte |
| WP-10-01 bis WP-10-07 | Produktentwicklung | Spezifikationen, Anforderungen, Dokumentation, Verifikation |
| WP-11-01 | Validierung | Validierungsbericht |
| WP-12-01 | Produktion | Produktionskontrollplan |
| WP-13-01 | Operations | Incident-Response-Plan |
| WP-14-01 | Ende der Unterstützung | Stilllegungsverfahren |
| WP-15-01 bis WP-15-08 | TARA | Schadensszenarien, Assets, Bedrohungen, Auswirkungen, Angriffspfade, Machbarkeit, Risikobewertungen, Behandlung |
Compliance-Bewertung
Bewertungen werden bottom-up berechnet:
- Datensatzebene: Binär (erfüllt / nicht erfüllt)
- Abschnittsebene: Durchschnitt der Datensatzantworten innerhalb des Abschnitts
- Klauselebene: Durchschnitt der Abschnittsprozentsätze innerhalb der Klausel
- Gesamtebene: Durchschnitt über alle Klauseln
Statusinterpretation
| Bewertung | Status | Bedeutung |
|---|---|---|
| 90–100% | Bereit | Vollständige Compliance, audit-bereit |
| 70–89% | Fast bereit | Geringe Lücken verbleibend |
| 50–69% | In Arbeit | Erheblicher Aufwand erforderlich |
| < 50% | Frühes Stadium | Große Lücken über alle Klauseln |
Compliance-Status
COMPLIANT(80%+)PARTIAL(50–79%)NON_COMPLIANT(< 50%)NOT_ASSESSED
Verstoßerkennung
Die Plattform bewertet kontinuierlich Compliance-Anforderungen, wenn sich Projektentitäten ändern. Verstöße werden erkannt für:
- Bedrohungsmodellierungs-Anforderungen (RQ-15-01 bis RQ-15-15): Fehlende Assets, Schadensszenarien, Bedrohungsszenarien, Angriffspfade
- Risikobewertungs-Anforderungen (RQ-09-04 bis RQ-09-10): Unvollständige Risikoberechnungen, fehlende Machbarkeitsbewertungen
- Risikobehandlungs-Anforderungen (RQ-09-08 bis RQ-09-10): Fehlende Ziele, Behauptungen oder Kontrollimplementierungen
Jeder Verstoß umfasst die fehlgeschlagene Anforderungs-ID, den Entitätstyp und die ID, die den Verstoß verursacht (Asset, Schadensszenario, Bedrohung, Angriffspfad, Risiko, Ziel, Behauptung), eine beschreibende Nachricht und einen Behebungsvorschlag. Verstöße werden nach Compliance-Modell (Bedrohungsmodellierung, Risikobewertung, Risikobehandlung) für eine gezielte Überprüfung gruppiert.
Berichtserstellung
ISO 21434-Bericht
- Gesamter Compliance-Status (Compliant / Partial / Non-Compliant)
- Gesamtabdeckungsprozentsatz
- Klausel-für-Klausel-Abdeckungsübersicht
- Testzusammenfassung (Gesamtläufe, Penetrationstests, Fuzz-Tests, Konformitätstests)
- Befundezusammenfassung nach Schweregrad (Kritisch, Hoch, Mittel, Niedrig)
- Lückenanalyse mit Schweregrad und Empfehlungen
- Evidenzpaket (Artefaktanzahl, Größe, Typen)
UNECE R155-Bericht
- Alle Felder des ISO 21434-Berichts, plus:
- Fahrzeugtypinformationen (Kategorie, Hersteller, Modell)
- Kategorieabdeckung nach Bedrohungskategorie
- Bedrohungsabdeckung (adressiert / teilweise adressiert / nicht adressiert)
Lückentypen
| Typ | Beschreibung |
|---|---|
| Fehlender Test | Kein Testfall deckt diese Anforderung ab |
| Unzureichende Abdeckung | Testabdeckung unterhalb des Schwellenwerts |
| Fehlende Evidenz | Keine Evidenzartefakte verlinkt |
| Fehlende Mitigation | Keine Kontrollen oder Ziele adressieren dieses Risiko |
| Fehlgeschlagener Test | Testausführung für diese Anforderung fehlgeschlagen |
Evidenzmanagement
Evidenz wird über mehrere Mechanismen gesammelt und verknüpft:
- Behauptungs-Evidenzmedien: Dateien, die direkt an Behauptungen angehängt werden
- Testartefakte: Penetrationstestberichte, Fuzz-Berichte, Scan-Berichte, PCAP-Dateien, Konformitätsberichte, Abdeckungsberichte
- Compliance-Datensatznotizen: Freitext-Evidenzbeschreibungen pro Anforderung
- Arbeitsprodukt-Lieferobjekte: Dokumente und Berichte, die mit Arbeitsprodukt-IDs verknüpft sind
Integration mit anderen Säulen
| Richtung | Säule | Datenfluss |
|---|---|---|
| Eingehend | TARA | Assets, Bedrohungen, Risiken, Ziele, Behauptungen, Kontrollen liefern Evidenz für Klauseln 9 und 15 |
| Eingehend | Testing | Testergebnisse und Abdeckung aktualisieren Compliance-Bewertungen automatisch |
| Eingehend | SBOM | Schwachstellenstatus und Komponenteninventar fließen in die Compliance-Lage ein |
| Eingehend | Design | Architekturdokumentation dient als Evidenz für systemweite Arbeitsprodukte |
| Eingehend | Operations | Incident-Response-Protokolle liefern Evidenz für Klausel-13-Arbeitsprodukte |
| Ausgehend | Alle Säulen | Compliance-Verstöße zeigen Lücken auf, die technische Maßnahmen erfordern |
Compliance-Modelle
Drei Compliance-Modelle ordnen Anforderungen spezifischen Engineering-Bereichen zu:
| Modell | Anforderungen | Zweck |
|---|---|---|
| Bedrohungsmodellierung | RQ-15-01 bis RQ-15-15 | Validiert die Vollständigkeit der Bedrohungsanalyse |
| Risikobewertung | RQ-09-04 bis RQ-09-10 | Validiert Risikobewertung und Machbarkeit |
| Risikobehandlung | RQ-09-08 bis RQ-09-10 | Validiert die Vollständigkeit der Mitigation |
Diese Modelle ermöglichen eine gezielte Verstoßprüfung — wenn ein Asset geändert wird, werden nur Bedrohungsmodellierungs-Anforderungen neu bewertet; wenn sich ein Risikowert ändert, werden nur Risikobewertungs-Anforderungen geprüft.