AcadeNice/Rendu_Securite_IoT-Jeep_Cherokee

2026-06-08 10:31:03 +02:00

53 KiB

Raw Permalink Blame History

Brief Projet — Site d'analyse de risques IoT (Jeep Cherokee 2015)

Document de référence complet à fournir à Claude Code pour reconstruire le site à partir de l'artefact iot_risk_briefing.jsx.

1. Contexte projet

Objectif

Site web pédagogique présentant une étude de cas complète du Jeep Cherokee Hack de 2015 dans le cadre d'un cours d'analyse de risques IoT. Le site doit présenter 5 méthodologies d'analyse appliquées au même cas :

Dossier d'incident — Récit technique de l'attaque
Analyse de risques — Matrice criticité P × I (5 risques contextualisés)
AMDEC / FMEA — Analyse des modes de défaillance (G × O × D = IPR)
CVE / CVSS — Référencement standardisé de la vulnérabilité
RTO / RPO / PCA-PRA — Plan de continuité d'activité

Public cible

Étudiants en cybersécurité / IoT
Professeurs (pour évaluation pédagogique)
Professionnels intéressés par les méthodologies de risque

Ton et style

Esthétique « briefing tactique / dossier de sécurité »
Theme dark exclusif (bg zinc-950, accents amber + emerald + criticité colorée)
Tone factuel, précis, technique mais accessible
Bilingue ready (priorité FR, structure permettant ajout EN ultérieur)

2. Stack technique recommandée

Choix préféré

- Framework : Next.js 15 (App Router) avec TypeScript strict
- Runtime : Bun (cohérent avec la stack du dev)
- Styling : Tailwind CSS v3+ (classes utility uniquement, pas de @apply)
- Icônes : lucide-react
- Polices : geist / inter (variable fonts via next/font)
- Déploiement : Vercel (zero-config) ou self-hosted

Alternative légère

- Framework : Vite + React 18 + TypeScript
- Tooling : Bun
- Styling : Tailwind CSS
- Routing : react-router-dom v6

Contraintes

Pas de localStorage / sessionStorage côté UI (état React in-memory)
Tout rendu côté client OK (pas besoin de SSR sauf pour SEO)
Pas de backend nécessaire — toutes les données sont statiques
Bundle final < 200KB gzipped souhaitable

3. Architecture du site

Routes

/                       → Redirige vers /dossier
/dossier               → Page 1 : Dossier d'incident
/risques               → Page 2 : Analyse de risques (matrice P×I)
/amdec                 → Page 3 : AMDEC / FMEA
/cve                   → Page 4 : CVE-2015-5611 / CVSS
/continuite            → Page 5 : RTO / RPO / PCA-PRA

Layout commun

┌─────────────────────────────────────────────────┐
│ HEADER global                                   │
│   Logo bouclier + "IoT RISK ANALYSIS"           │
│   Titre H1 + sous-titre                         │
├─────────────────────────────────────────────────┤
│ HERO du cas (toujours visible)                  │
│   Codename CHRYSLER-2015-001                    │
│   Titre + année + sous-titre                    │
│   Score criticité 12/CRITIQUE en encart à droite│
│   4 stats : 1.4M véhicules, 2 chercheurs,       │
│             Sprint réseau, ∞ distance           │
├─────────────────────────────────────────────────┤
│ NAVIGATION SECONDAIRE (onglets soulignés)       │
│   01 Dossier · 02 Risques · 03 AMDEC ·          │
│   04 CVE/CVSS · 05 Continuité                   │
├─────────────────────────────────────────────────┤
│ CONTENU DE LA PAGE                              │
│   (fade-in 250ms au changement de route)        │
├─────────────────────────────────────────────────┤
│ FOOTER                                          │
│   Version + standards référencés                │
└─────────────────────────────────────────────────┘

4. Design system

Palette

const colors = {
  // Backgrounds
  bg: "#09090b",          // zinc-950
  surface: "#18181b",     // zinc-900
  surfaceAlt: "#27272a",  // zinc-800

  // Texte
  textPrimary: "#fafafa",   // zinc-50 / zinc-100
  textSecondary: "#a1a1aa", // zinc-400
  textMuted: "#71717a",     // zinc-500
  textFaint: "#52525b",     // zinc-600

  // Accents
  amber: "#facc15",       // amber-400 (accent principal / méthodologie)
  emerald: "#22c55e",     // emerald-500 (mitigation / solutions)

  // Criticité (P×I et CVSS)
  low: "#22c55e",         // vert
  medium: "#eab308",      // jaune
  high: "#f97316",        // orange
  critical: "#ef4444",    // rouge
  none: "#71717a",        // gris (CVSS NONE)

  // Cas-specifique
  jeepAccent: "#ff3b30",  // rouge Jeep
};

Typographie

Sans (body) : Inter ou Geist Sans
Mono (technique) : JetBrains Mono ou Geist Mono ou Space Mono
Pas de serif

Hiérarchie :

text-3xl md:text-4xl font-bold pour H1 (page principale)
text-2xl font-bold pour H2 (sections principales)
text-lg font-semibold pour H3 (sous-sections)
text-sm font-semibold pour cartes
text-[10px] tracking-[0.25em] font-mono pour les codes/labels
text-xs pour le corps de texte secondaire
text-[11px] pour les méta-infos

Patterns visuels

Bordures fines : border border-zinc-800 partout
Pas d'ombres ni de gradients agressifs (sauf hero avec subtle blur ambient)
Espacement : gap-3 pour grilles, mb-6 à mb-8 entre sections
Coins droits : pas de rounded-* (excepté éventuellement les badges en rounded-full mini)
Animations : transitions de 200-250ms, fade-in subtle au changement de route

Composants récurrents

Section header : icône carrée + code mono + titre
Stat card : icône en haut, valeur grande, label en petites caps
Carte expandable (RiskCard, AMDECRow) : en-tête cliquable + contenu replié/déplié
Badge : border + bg-color/10 + text-color + text-[9px] font-mono tracking-wider
Bandeau info : border-l-2 + couleur d'accent + texte
Timeline step : numéro en bordure ronde + ligne verticale + texte

5. Structures de données (TypeScript)

// === MATRICE P × I ===
type ProbabilityScore = 1 | 2 | 3 | 4;
type ImpactScore = 1 | 2 | 3 | 4;
type CriticalityLevel = "FAIBLE" | "MODÉRÉ" | "ÉLEVÉ" | "CRITIQUE";

// === ÉCHELLES ===
interface ScaleLevel {
  score: number;
  label: string;
  description: string;
}

// === CAS D'ÉTUDE ===
interface CaseStudy {
  id: "jeep";
  codename: string;            // "CHRYSLER-2015-001"
  title: string;               // "Jeep Cherokee Hack"
  year: string;                // "2015"
  subtitle: string;
  accent: string;              // hex color
  stats: Stat[];               // 4 stats clés
  
  // P × I global
  probability: ProbabilityScore;
  impact: ImpactScore;
  probReason: string;
  impactReason: string;

  // Page 1 — Dossier
  timeline: TimelineStep[];      // 5 étapes
  why: RootCause[];              // 4 causes
  problems: string[];            // ~5 problèmes
  solutions: NamedItem[];        // ~5 solutions

  // Page 2 — Risques
  risks: Risk[];                 // 5 risques

  // Page 3 — AMDEC
  amdec: AMDECRow[];             // 5 modes

  // Page 4 — CVE
  cves: CVE[];                   // 1 CVE

  // Page 5 — Continuité (NOUVEAU)
  continuity: ContinuityAnalysis;
}

interface Stat {
  label: string;
  value: string;
  icon: string;  // nom lucide-react
}

interface TimelineStep {
  phase: string;   // "01" .. "05"
  title: string;
  text: string;
}

interface RootCause {
  title: string;
  text: string;
}

interface NamedItem {
  title: string;
  text: string;
}

interface Risk {
  id: string;            // "R1" .. "R5"
  title: string;
  description: string;
  probability: ProbabilityScore;
  impact: ImpactScore;
  probHypothesis: string;
  impactHypothesis: string;
  solution: string;
}

interface AMDECRow {
  id: string;            // "AMD-01" .. "AMD-05"
  component: string;
  function: string;
  failureMode: string;
  cause: string;
  effect: string;
  severity: number;      // G : 1-10
  occurrence: number;    // O : 1-10
  detection: number;     // D : 1-10
  action: string;
  // IPR calculé : severity × occurrence × detection
}

interface CVE {
  id: string;             // "CVE-2015-5611"
  title: string;
  publishedDate: string;
  advisories: { id: string; source: string }[];
  affected: string;
  description: string;
  attackChain: string[];
  cvssV2: CVSSScore;
  cvssV3: CVSSScore;
  remediation: string[];
  references: { label: string; url: string }[];
}

interface CVSSScore {
  score: number;
  severity: "NONE" | "LOW" | "MEDIUM" | "HIGH" | "CRITICAL";
  vector: string;
  note?: string;
  metrics: CVSSMetric[];
}

interface CVSSMetric {
  key: string;        // "AV", "AC", etc.
  label: string;      // "Attack Vector"
  value: string;      // "A"
  valueLabel: string; // "Adjacent"
  detail: string;     // justification spécifique au cas
}

interface ContinuityAnalysis {
  criticalComponent: {
    name: string;
    rationale: string;
    alternatives: string[];  // autres composants envisagés
  };
  rto: {
    value: string;           // "< 72h" / "6 mois"
    realityHistorical: string;
    target: string;
    justification: string;
  };
  rpo: {
    value: string;
    realityHistorical: string;
    target: string;
    justification: string;
  };
  continuityMeasures: ContinuityMeasure[];
  retrospective: {
    pcaPraExisted: boolean;
    description: string;
    consequences: string[];
    postIncidentLessons: string[];
  };
}

interface ContinuityMeasure {
  type: "TECHNIQUE" | "ORGANISATIONNELLE";
  title: string;
  description: string;
}

6. Page 1 — Dossier d'incident

Données du Hero

{
  codename: "CHRYSLER-2015-001",
  title: "Jeep Cherokee Hack",
  year: "2015",
  subtitle: "Prise de contrôle à distance via réseau cellulaire",
  accent: "#ff3b30",
  probability: 3,
  impact: 4,
  // score = 12, niveau CRITIQUE (rouge)
  stats: [
    { label: "Véhicules rappelés", value: "1.4M", icon: "Car" },
    { label: "Chercheurs", value: "2", icon: "Users" },
    { label: "Réseau exploité", value: "Sprint", icon: "Radio" },
    { label: "Distance d'attaque", value: "∞ km", icon: "Target" },
  ],
}

Section : Comment l'attaque s'est déroulée (Timeline)

Phase 01 — Reconnaissance

Miller & Valasek identifient le système Uconnect (Harman-Kardon) comme cible. Tout véhicule Sprint connecté est scannable depuis n'importe quel téléphone du même opérateur — la flotte forme un sous-réseau adressable.

Phase 02 — Pivot Wi-Fi → Cellulaire

Première intrusion via le hotspot Wi-Fi du véhicule, puis exploitation d'un port D-Bus ouvert (port 6667) accessible directement depuis le réseau cellulaire Sprint — aucun firewall en sortie.

Phase 03 — Compromission de la head unit

Code arbitraire exécuté sur le système Linux du Uconnect via des services D-Bus non authentifiés. À ce stade : contrôle de la radio, GPS, climatisation.

Phase 04 — Pivot vers le CAN bus

Reflashing du microcontrôleur Renesas V850 via une liaison SPI depuis le processeur OMAP. Un firmware modifié permet d'envoyer des trames CAN arbitraires.

Phase 05 — Contrôle physique

Direction, freins, accélérateur, transmission, frein de parking : tout est pilotable à distance. Démonstration publique sur autoroute avec un journaliste de Wired comme cobaye.

Section : Pourquoi c'est arrivé (Causes racines)

01. Architecture plate sans segmentation

Aucune séparation logique entre le réseau infotainment (non critique) et le CAN bus (sécurité fonctionnelle). Le V850 acceptait du firmware non signé via SPI.

02. Modèle de menace obsolète

Les constructeurs raisonnaient en termes d'accès physique au véhicule. Le scénario « attaquant distant via opérateur télécom » n'était pas dans le threat model.

03. Services exposés sans authentification

D-Bus écoutait sur 0.0.0.0 sur un port joignable depuis Internet via Sprint. Aucune ACL, aucun TLS, aucun secret partagé.

04. Pas d'isolation opérateur

Sprint n'isolait pas les véhicules entre eux sur son réseau privé : un appareil quelconque pouvait scanner tous les Uconnect du pays.

Section : Problèmes identifiés

Surface d'attaque massive (1.4M véhicules joignables depuis n'importe quel téléphone Sprint)
Danger physique direct : freins, direction et accélérateur contrôlables à 110 km/h
Détection impossible côté conducteur — aucune télémétrie de sécurité
Patch impossible OTA en 2015 : rappel physique nécessaire pour 1.4M véhicules
Le V850 acceptait n'importe quel firmware via SPI — pas de signature cryptographique

Section : Solutions et bonnes pratiques

Segmentation réseau interne (gateway CAN)

Insertion d'une passerelle filtrante entre l'infotainment et le CAN bus, avec liste blanche stricte des trames autorisées.

Firmware signé partout

Secure boot et signature cryptographique obligatoire sur tous les ECU, y compris les microcontrôleurs périphériques (V850 et équivalents).

OTA sécurisées (Uptane)

Adoption d'Uptane comme standard de mise à jour OTA résistant aux compromissions de serveur, déployé depuis chez les principaux constructeurs.

Isolation au niveau opérateur

Sprint a fermé l'accès au port 6667 côté APN et isolé les véhicules sur des sous-réseaux dédiés sans communication transverse.

ISO/SAE 21434 & UNECE R155

Standards apparus après l'incident : threat modeling cybersécurité obligatoire pour l'homologation des véhicules à partir de 2022.

7. Page 2 — Analyse de risques (Matrice P × I)

Méthodologie (briefing en haut de page)

Activité 1 — Matrice de criticité

À partir du cas fil rouge assigné, réaliser les étapes suivantes :

Identifier 5 risques — Risques précis et contextualisés, pas des catégories génériques
Attribuer P et I — Probabilité (1 à 4) et Impact (1 à 4), calculer la criticité
Positionner dans la matrice — Identifier le risque le plus et le moins critique
Documenter les hypothèses — Pour chaque score de probabilité attribué

À éviter : "Risque réseau" (trop générique, non actionnable) Attendu : "Interception du trafic MQTT entre capteurs et broker en raison de l'absence de chiffrement TLS" (précis, contextualisé)

Échelles

Probabilité (1-4)

Score	Niveau	Fréquence
1	Très improbable	Une fois en 10 ans ou plus
2	Improbable	Une fois tous les 2 à 3 ans
3	Probable	Une fois par an
4	Très probable	Plusieurs fois par an

Impact (1-4)

Score	Niveau	Conséquences
1	Négligeable	Aucune interruption, aucune donnée compromise
2	Mineur	Gêne passagère, dégradation partielle du service
3	Majeur	Interruption de service, perte de données partielle
4	Critique	Danger physique, perte massive, sanction juridique, atteinte irréversible

Niveaux de criticité (Probabilité × Impact)

1-3 : FAIBLE (#22c55e)
4-6 : MODÉRÉ (#eab308)
8-9 : ÉLEVÉ (#f97316)
12-16 : CRITIQUE (#ef4444)

Les 5 risques contextualisés

R1 — Énumération à distance de la flotte Uconnect sur le réseau Sprint

Description : Scan d'IP automatisé depuis n'importe quel terminal Sprint pour cartographier les 1.4M véhicules joignables. Peut être incorporé dans un worm.
P = 4 (Très probable) | I = 1 (Négligeable) | Criticité = 4
Hypothèse P : Aucun isolement L2/L3 entre clients Sprint. Le port D-Bus 6667 répond ou ferme selon la présence du Uconnect, c'est un signal trivialement détectable. Outillage de scan standard (nmap) suffit.
Hypothèse I : Aucune compromission, aucune action sur le véhicule — seulement de la reconnaissance. Mais c'est le prérequis indispensable de toutes les attaques de masse, donc à ne pas sous-estimer dans l'analyse globale.
Mitigation : Isolation L2/L3 sur l'APN opérateur (Sprint a depuis cloisonné ses véhicules sur un sous-réseau dédié sans communication transverse). Côté véhicule : fermeture du port D-Bus en sortie, ACL stricte limitant les connexions entrantes aux serveurs constructeur authentifiés via TLS mutuel.

R2 — Exécution de code à distance sur la head unit Linux via D-Bus port 6667

Description : Service D-Bus exposé sur 0.0.0.0 sans authentification depuis le réseau cellulaire. Permet d'obtenir un shell sur le système Linux du Uconnect.
P = 3 (Probable) | I = 2 (Mineur) | Criticité = 6
Hypothèse P : Exploit fonctionnel documenté par Miller & Valasek. Reproductible pour qui dispose du PoC. Nécessite expertise mais pas génie — donc plus d'un acteur à l'horizon de la divulgation.
Hypothèse I : À ce stade, seul l'infotainment est compromis : radio, GPS, climatisation, écran. Gêne notable pour le conducteur mais pas de danger physique direct. Dégradation partielle du service.
Mitigation : Service D-Bus en écoute locale uniquement (127.0.0.1), authentification mutuelle TLS sur tous les services exposés, désactivation des services non essentiels (principle of least privilege), firewall iptables/netfilter restrictif sur la head unit avec règles par défaut DROP.

R3 — Reflashing du microcontrôleur Renesas V850 avec firmware non signé via SPI

Description : Depuis l'OMAP compromis, écriture d'un firmware modifié sur le V850 qui interface avec le CAN bus. Aucune vérification de signature côté V850.
P = 2 (Improbable) | I = 3 (Majeur) | Criticité = 6
Hypothèse P : Suppose la compromission préalable de la head unit (R2) ET la maîtrise du reverse engineering du V850. Compétences embarqué pointues — barrière à l'entrée réelle.
Hypothèse I : Permet d'envoyer des trames CAN arbitraires : un attaquant peut désormais agir sur n'importe quel sous-système. Interruption de service possible, perte de fiabilité — majeur.
Mitigation : Secure boot avec vérification de signature cryptographique du firmware (RSA-2048 ou ECDSA P-256), HSM (Hardware Security Module) intégré au V850 pour stocker les clés publiques en lecture seule, rollback protection anti-downgrade pour empêcher la réinstallation d'une version antérieure vulnérable.

R4 — Contrôle distant des freins, direction et accélérateur en conduite à haute vitesse

Description : Envoi de trames CAN ciblant les ECU de sécurité fonctionnelle pendant que le véhicule roule. Démontré sur autoroute à 110 km/h.
P = 2 (Improbable) | I = 4 (Critique) | Criticité = 8
Hypothèse P : Nécessite toute la chaîne d'attaque (R1 → R2 → R3) ET la connaissance des trames CAN spécifiques au modèle ET un timing offensif. Pas trivial mais pas impossible pour un acteur étatique.
Hypothèse I : Perte de contrôle direction/freins à vitesse autoroutière = accident potentiellement mortel. Sanction juridique massive pour le constructeur (FCA), atteinte irréversible en cas de décès — critique.
Mitigation : Défense en profondeur : (1) Gateway CAN filtrante entre l'infotainment et le CAN bus critique, avec liste blanche stricte des trames autorisées. (2) SecOC (AUTOSAR Secure Onboard Communication) pour authentifier chaque trame CAN via MAC. (3) IDS embarqué détectant les patterns de trames anormaux avec coupure automatique. (4) Conformité ISO/SAE 21434 et UNECE R155 (obligatoires depuis 2022 pour l'homologation des véhicules).

PLUS CRITIQUE — Score 8

R5 — Désactivation persistante du frein de parking pour immobilisation/sabotage

Description : Modification ciblée d'une fonction unique (parking brake) maintenue après reboot via firmware V850 modifié. Le véhicule devient inutilisable.
P = 2 (Improbable) | I = 2 (Mineur) | Criticité = 4
Hypothèse P : Mêmes prérequis que R4 (chaîne complète), mais cible un sous-système plus simple. Pas observé en pratique car la motivation criminelle est faible — l'ampleur du crime n'est pas proportionnelle au gain.
Hypothèse I : Véhicule immobilisé, intervention dealer obligatoire — gêne réelle mais pas de danger vital. Préjudice économique modéré pour le propriétaire. Mineur.
Mitigation : Watchdog matériel sur les ECU critiques qui rétablit l'état nominal en cas d'incohérence détectée. Vérification d'intégrité du firmware au démarrage de chaque ECU via Trusted Platform Module (TPM). Journalisation tamper-evident des modifications de firmware avec audit obligatoire lors de chaque entretien dealer.

MOINS CRITIQUE (ex-aequo avec R1) — Score 4

Synthèse pédagogique

Les scores cumulés ne sont pas tous concentrés en haut de la matrice — l'inventaire couvre intentionnellement plusieurs niveaux pour illustrer la dispersion d'un même incident en sous-risques de criticités diverses. Le pire risque unitaire (R4) atteint 8 (ÉLEVÉ), tandis que le score global de l'incident dans son ensemble est 12 (CRITIQUE).

8. Page 3 — AMDEC / FMEA

Méthodologie (briefing)

Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité (équivalent français de la FMEA — Failure Mode and Effects Analysis). Méthode systématique de priorisation des défaillances.

Pour chaque composant, on identifie : fonction, mode de défaillance, cause, effet. Puis on score sur 3 axes :

Axe	Sens	Échelle
G — Gravité	Sévérité de l'effet sur le système ou l'utilisateur final	1 (imperceptible) → 10 (critique, danger vital)
O — Occurrence	Fréquence d'apparition de la défaillance en conditions réelles	1 (très rare) → 10 (quasi-certaine)
D — Détection	Difficulté à détecter la défaillance avant impact	1 (détection immédiate) → 10 (indétectable)

Formule : IPR = G × O × D (Indice de Priorité du Risque, max 1000)

Niveaux d'IPR

Score	Niveau	Couleur
< 100	FAIBLE	#22c55e
100-199	MODÉRÉ	#eab308
200-399	ÉLEVÉ	#f97316
≥ 400	CRITIQUE	#ef4444

Échelles détaillées

Gravité

1-2 : Mineure — Effet imperceptible ou très limité, pas de préjudice fonctionnel
3-4 : Faible — Dégradation perceptible mais sans conséquence sécuritaire
5-6 : Modérée — Interruption de service, mécontentement utilisateur
7-8 : Importante — Compromission système, données exposées
9-10 : Critique — Danger physique, atteinte irréversible, mise en jeu de vies

Occurrence

1-2 : Très rare — Probabilité de défaillance quasi nulle (< 1 sur 100 000)
3-4 : Rare — Défaillance peu probable (1 sur 10 000)
5-6 : Occasionnelle — Défaillance possible (1 sur 1 000)
7-8 : Fréquente — Défaillance probable (1 sur 100)
9-10 : Quasi-certaine — Défaillance certaine en conditions d'exploitation

Détection

1-2 : Très probable — Détectée immédiatement par les moyens existants
3-4 : Probable — Détectée avant impact significatif
5-6 : Possible — Détection possible mais incertaine
7-8 : Peu probable — Détection difficile, souvent a posteriori
9-10 : Très improbable — Quasiment indétectable avec les moyens en place

Tableau AMDEC complet (5 modes, triés par IPR descendant)

AMD-05 (IPR = 320) — Protocole CAN bus

Composant : Protocole CAN bus (ISO 11898)
Fonction : Communication temps réel entre ECU pour les fonctions véhicule
Mode de défaillance : Aucune authentification des trames CAN — n'importe quel ECU sur le bus peut émettre n'importe quelle commande
Cause : Protocole CAN conçu en 1986 pour un environnement physiquement fermé, pas pour résister à un ECU compromis
Effet : Direction, freins, accélérateur, transmission pilotables depuis n'importe quel ECU compromis, y compris l'infotainment
G = 10 | O = 4 | D = 8 | IPR = 320 (ÉLEVÉ)
Action corrective : Déploiement de SecOC (AUTOSAR Secure Onboard Communication) — MAC sur chaque trame CAN avec compteur anti-rejeu. Migration progressive vers CAN-FD authentifié. IDS comportemental sur le bus.

PRIORITÉ MAXIMALE — IPR = 320

AMD-03 (IPR = 288) — Microcontrôleur Renesas V850

Composant : Microcontrôleur Renesas V850 (passerelle CAN)
Fonction : Faire le pont entre la head unit (OMAP) et le CAN bus du véhicule (ECU de sécurité)
Mode de défaillance : Accepte du firmware non signé via la liaison SPI depuis l'OMAP — pas de vérification cryptographique
Cause : Pas de secure boot implémenté, pas de stockage de clés (HSM/TPM), conception centrée fonctionnalité sans modèle de menace cyber
Effet : Pivot depuis l'infotainment compromis vers le CAN bus critique : injection de trames CAN arbitraires possible
G = 9 | O = 4 | D = 8 | IPR = 288 (ÉLEVÉ)
Action corrective : Secure boot avec signature cryptographique (RSA-2048 / ECDSA P-256). HSM intégré stockant les clés publiques en lecture seule. Rollback protection anti-downgrade. Attestation au boot vers une autorité constructeur.

AMD-01 (IPR = 240) — APN Sprint

Composant : Réseau cellulaire Sprint / APN constructeur
Fonction : Fournir la connectivité du Uconnect aux serveurs FCA
Mode de défaillance : Absence d'isolation L2/L3 entre clients Sprint — les véhicules sont mutuellement adressables
Cause : Configuration laxiste de l'APN, pas de cloisonnement par VLAN, port D-Bus 6667 ouvert en entrée depuis tout le réseau cellulaire
Effet : Énumération automatisée de la flotte (1.4M véhicules) depuis n'importe quel terminal Sprint, scan IP trivialisé
G = 6 | O = 10 | D = 4 | IPR = 240 (ÉLEVÉ)
Action corrective : Cloisonnement des véhicules sur un sous-réseau dédié sans communication transverse (mesure réellement appliquée par Sprint post-incident). Filtrage du port 6667 côté opérateur.

AMD-04 (IPR = 210) — Architecture réseau interne

Composant : Architecture réseau interne du véhicule
Fonction : Interconnecter les ECU (infotainment, motorisation, freinage, direction, transmission)
Mode de défaillance : Architecture plate, pas de segmentation entre le domaine infotainment et le domaine sécurité fonctionnelle
Cause : Décisions de conception antérieures à la connectivité cellulaire généralisée, threat model centré sur l'accès physique uniquement
Effet : Une fois le V850 compromis (AMD-03), toutes les trames CAN sont à portée — contrôle potentiel des actuateurs critiques
G = 10 | O = 3 | D = 7 | IPR = 210 (ÉLEVÉ)
Action corrective : Insertion d'une gateway CAN filtrante entre les domaines avec liste blanche stricte des trames autorisées. Architecture en zones et conduits (IEC 62443 / ISO 21434). IDS embarqué sur le bus CAN.

AMD-02 (IPR = 112) — Service D-Bus

Composant : Service D-Bus de la head unit Uconnect
Fonction : Communication inter-processus locale entre services de l'infotainment
Mode de défaillance : Service D-Bus en écoute sur 0.0.0.0:6667 sans authentification, exposé à Internet via le modem cellulaire
Cause : Configuration par défaut conservée en production, pas de durcissement systémique, principe de moindre exposition non appliqué
Effet : Exécution de code à distance sur le système Linux du Uconnect, compromission de l'infotainment (radio, GPS, climatisation)
G = 8 | O = 7 | D = 2 | IPR = 112 (MODÉRÉ)
Action corrective : Bind D-Bus sur 127.0.0.1 uniquement. Authentification mutuelle TLS sur tous services exposés. Firewall iptables avec politique DROP par défaut. Audit systémique des ports ouverts avant homologation.

9. Page 4 — CVE / CVSS

Briefing pédagogique

CVE (Common Vulnerabilities and Exposures) attribue un identifiant unique à chaque vulnérabilité publiée, géré par MITRE. CVSS (Common Vulnerability Scoring System) la score sur une échelle de 0 à 10 selon des métriques standardisées. La version officielle au moment de la divulgation Jeep (2015) était CVSS v2 ; CVSS v3.1 est la version en vigueur depuis 2019.

Identification de la vulnérabilité

CVE-2015-5611 — Missing Authorization in FCA Uconnect RA3/RA4 (Harman-Kardon Infotainment)

Publié : 17 septembre 2015
Advisories :
- ICSA-15-260-01 — CISA / ICS-CERT
- VU#819439 — CERT/CC (Carnegie Mellon)
Produits affectés : Uconnect 8.4AN / RA3 / RA4 dans Chrysler 200, 300, Charger, Challenger, Durango, Ram 1500/2500/3500, Jeep Cherokee/Grand Cherokee, Dodge Viper (modèles 2013-2015) — environ 1.4M véhicules rappelés.

Description

Vulnérabilité d'autorisation manquante dans le système Uconnect manufacturé par Harman-Kardon. Le service D-Bus écoutant sur le port 6667 (réseau cellulaire Sprint) accepte des connexions non authentifiées et permet l'exécution de commandes arbitraires sur la head unit. Le défaut permet à un attaquant distant de prendre le contrôle de l'infotainment, puis (via un firmware modifié injecté sur le microcontrôleur Renesas V850) d'envoyer des trames CAN au véhicule.

Chaîne d'attaque

Reconnaissance : Scan IP sur le réseau cellulaire Sprint pour identifier les véhicules Uconnect (port 6667 ouvert)
Exploitation : Connexion D-Bus non authentifiée + exécution de commandes sur la head unit Linux
Élévation : Reflashing du microcontrôleur V850 avec un firmware modifié via SPI
Impact : Injection de trames CAN arbitraires — contrôle des freins, direction, accélérateur, transmission

CVSS v2.0 — OFFICIEL NVD

Score : 8.3 (HIGH)
Vecteur : AV:A/AC:L/Au:N/C:C/I:C/A:C

Clé	Métrique	Valeur	Label	Justification
AV	Access Vector	`A`	Adjacent Network	Le réseau cellulaire Sprint est traité comme adjacent (pas un Internet ouvert) — l'attaquant doit posséder un terminal Sprint pour atteindre les véhicules.
AC	Access Complexity	`L`	Low	Aucune condition particulière requise au-delà de la présence sur Sprint. Scan trivialement automatisable.
Au	Authentication	`N`	None	Aucune authentification requise pour interagir avec le service D-Bus exposé.
C	Confidentiality Impact	`C`	Complete	Lecture totale du système Linux du Uconnect (logs, GPS historique, contenu USB, configuration).
I	Integrity Impact	`C`	Complete	Modification arbitraire du système + chaîne d'attaque permettant de modifier le firmware du V850 et d'injecter dans le CAN bus.
A	Availability Impact	`C`	Complete	Perte totale de disponibilité possible : extinction du moteur, désactivation transmission, blocage du véhicule.

CVSS v3.1 — RÉINTERPRÉTATION PÉDAGOGIQUE

Score : 9.6 (CRITICAL)
Vecteur : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Note : Réinterprétation pédagogique en CVSS v3.1 — le CVE original n'a été scoré qu'en CVSS v2 par NVD à l'époque (v3 publié fin 2015).

Clé	Métrique	Valeur	Label	Justification
AV	Attack Vector	`A`	Adjacent	Conservé en Adjacent : le réseau Sprint constitue un domaine logique partagé (pas Internet ouvert au sens strict).
AC	Attack Complexity	`L`	Low	Pas de condition spéciale, attaque répétable.
PR	Privileges Required	`N`	None	Aucun privilège requis sur le système cible.
UI	User Interaction	`N`	None	Aucune action utilisateur nécessaire — le conducteur n'a rien à cliquer ou installer.
S	Scope	`C`	Changed	La compromission de l'infotainment franchit une frontière de sécurité majeure (vers le CAN bus / les actuateurs physiques). Scope Changed est ici essentiel.
C	Confidentiality	`H`	High	Exposition totale des données système et utilisateur.
I	Integrity	`H`	High	Modification arbitraire du firmware + injection CAN, compromettant l'intégrité fonctionnelle du véhicule.
A	Availability	`H`	High	Mise hors service du véhicule possible (coupure moteur, transmission).

Différence v2 vs v3 — Pourquoi le score grimpe

La métrique Scope introduite en v3 est déterminante ici. En v2, l'impact se mesure uniquement sur le composant vulnérable (la head unit Uconnect). En v3, l'attaque traverse une frontière de sécurité majeure (infotainment → CAN bus → actuateurs physiques), ce qui place le scope à Changed (C) et fait grimper le score de 8.3 (High) à 9.6 (Critical). C'est l'un des changements pédagogiques majeurs apportés par CVSS v3 : la propagation d'impact compte autant que l'impact local.

Échelles CVSS

CVSS v3.1 — Niveaux de sévérité

0.0 : NONE
0.1–3.9 : LOW (vert)
4.0–6.9 : MEDIUM (jaune)
7.0–8.9 : HIGH (orange)
9.0–10.0 : CRITICAL (rouge)

Remediation

Patch firmware Uconnect distribué par FCA le 16 juillet 2015 (mise à jour USB + OTA progressive).
Rappel formel de 1.4M véhicules le 23 juillet 2015 — premier rappel automobile motivé par une vulnérabilité cyber.
Sprint a fermé le port 6667 côté infrastructure et cloisonné les véhicules sur un sous-réseau dédié.
À long terme : adoption de SecOC (AUTOSAR), conformité ISO/SAE 21434 et UNECE R155 (obligatoires en homologation depuis juillet 2022).

Références officielles (liens cliquables)

NVD — CVE-2015-5611 : https://nvd.nist.gov/vuln/detail/CVE-2015-5611
CISA ICSA-15-260-01 : https://www.cisa.gov/news-events/ics-advisories/icsa-15-260-01
CERT VU#819439 : https://www.kb.cert.org/vuls/id/819439
Miller & Valasek — Remote Exploitation of an Unaltered Passenger Vehicle (91p.) : http://illmatics.com/Remote%20Car%20Hacking.pdf

10. Page 5 — RTO / RPO / PCA-PRA (NOUVELLE)

Briefing pédagogique

Activité 3 — Plan de Continuité d'Activité (PCA) et Plan de Reprise d'Activité (PRA)

À partir du cas fil rouge assigné, réaliser les étapes suivantes :

Composant critique — Identifier le composant le plus critique du système
Définir le RTO — RTO réaliste et justifié dans le contexte de l'incident réel
Définir le RPO — RPO réaliste et justifié selon les données en jeu
Mesure de continuité — Proposer une mesure concrète, technique ou organisationnelle
Analyse rétrospective — Un PCA/PRA existait-il lors de l'incident réel ? Avec quelles conséquences ?

Définitions clés

PCA (Plan de Continuité d'Activité) : Ensemble de procédures permettant à l'organisation de maintenir ses activités essentielles pendant un sinistre.
PRA (Plan de Reprise d'Activité) : Ensemble de procédures pour remettre en service les systèmes après sinistre, dans des délais et avec des pertes de données acceptables.
RTO (Recovery Time Objective) : Durée maximale acceptable d'interruption de service après sinistre.
RPO (Recovery Point Objective) : Quantité maximale acceptable de données perdues, mesurée en temps avant le sinistre (≃ fréquence de sauvegarde minimale).

1. Composant critique

Composant identifié : L'infrastructure de mise à jour à distance (OTA) du constructeur FCA

Justification : Au moment de l'incident (2015), FCA ne disposait d'aucune capacité d'OTA déployée sur la flotte Jeep Cherokee. Cette absence est ce qui a rendu l'incident catastrophique d'un point de vue continuité d'activité — pas la vulnérabilité elle-même (qui aurait pu être patchée), mais l'impossibilité de déployer le patch rapidement.

Le composant critique n'est donc pas un composant du véhicule mais un composant de l'écosystème constructeur : sans OTA, chaque véhicule devient un point d'intervention manuel, multipliant le délai de remediation par un facteur 100 à 1000.

Composants alternatifs envisagés (et pourquoi ils sont moins critiques au sens BCP) :

Le CAN bus + ECU de sécurité : composant le plus dangereux en cas de compromission, mais c'est un sujet de sécurité fonctionnelle, pas de continuité d'activité au sens classique.
Le service Uconnect / Sprint : critique pour le service connecté, mais le véhicule reste utilisable sans (autoradio, GPS embarqué etc.).
La head unit Linux du Uconnect : composant vulnérable mais non critique — son indisponibilité ne met pas le véhicule à l'arrêt.

Conclusion : Du point de vue PCA/PRA, le composant critique est l'infrastructure OTA, parce qu'elle conditionne la capacité du constructeur à reprendre le contrôle sur sa flotte en cas d'incident.

2. Définition du RTO

RTO cible : < 72 heures pour atteindre 95% de la flotte patchée

Réalité historique (2015) :

16 juillet 2015 : patch disponible chez FCA
23 juillet 2015 : annonce du rappel formel pour 1.4M véhicules
Septembre 2015 : poursuite du rappel via clés USB postales
~6 mois pour atteindre un taux de couverture significatif (estimé 70-80%)

Justification du RTO cible :

Une fenêtre de divulgation publique d'une vulnérabilité critique automotive ne doit pas dépasser quelques jours avant patch — sinon des attaquants peuvent industrialiser l'exploit (worm sur Sprint était plausible selon Miller).
72h correspond au délai standard adopté post-incident par les principaux constructeurs (Tesla, Ford, GM) pour les patches de sécurité critiques.
Le NHTSA et l'UNECE R155 imposent depuis 2022 une capacité de réaction sous quelques jours pour les défauts cyber.

RTO par périmètre :

Périmètre	Réalité 2015	Cible moderne
Véhicule individuel (intervention dealer)	~2h	< 1h
Flotte complète (1.4M véhicules)	~6 mois	< 72h via OTA
Service Uconnect côté serveur FCA	N/A (pas affecté)	< 4h

3. Définition du RPO

RPO cible : < 5 minutes pour les logs de sécurité, 0 pour la configuration ECU, 24h pour les données utilisateur

Réalité historique (2015) :

Aucun système de télémétrie de sécurité côté véhicule → RPO = total (perte de tout l'historique des événements)
Aucune sauvegarde de la configuration des ECU côté constructeur
Logs CAN non remontés vers FCA → toute trace forensique perdue dès le redémarrage

Justification du RPO cible (par type de donnée) :

Type de donnée	RPO cible	Justification
Logs CAN et événements de sécurité	< 5 minutes	Remontée continue vers un V-SOC pour détection d'attaques en cours. 5 min = compromis entre bande passante et réactivité.
Configuration ECU et firmware	0 (instantané)	Une image signée et versionnée existe toujours côté constructeur — restauration possible sans perte.
Données utilisateur infotainment (contacts, navigation)	< 24h	Synchronisation cloud quotidienne suffisante, ce sont des données de confort sans criticité.
État véhicule (GPS, télémétrie d'usage)	< 1h	Pour traçabilité forensique et investigation post-incident.

Hypothèses du RPO :

La cible suppose une connectivité quasi permanente du véhicule (true pour les modèles connectés post-2018).
En cas de perte de connectivité prolongée, le véhicule stocke localement et synchronise au retour en ligne — buffer de quelques heures dimensionné côté ECU.

4. Mesure de continuité concrète

Mesure proposée : Déploiement d'une infrastructure OTA Uptane couplée à un V-SOC centralisé

Type : TECHNIQUE + ORGANISATIONNELLE (hybride)

Composants techniques :

Uptane (Update Framework for Automotive) : standard OTA résistant aux compromissions de serveur, déjà adopté par Toyota, Ford et la majorité des grands constructeurs depuis 2018. Garantit qu'un patch déployé n'a pas été altéré, même si l'infrastructure constructeur est compromise.
V-SOC (Vehicle Security Operations Center) : équipe et plateforme dédiée à la surveillance cybersécurité de la flotte. Reçoit les logs de sécurité de tous les véhicules connectés en temps quasi réel, détecte les anomalies et déclenche les playbooks d'incident.
Gateway CAN filtrante : sépare physiquement le domaine infotainment du domaine sécurité fonctionnelle. Même en cas de compromission de l'un, l'autre reste préservé — permet au véhicule de continuer à rouler en mode sécurité dégradée.

Composants organisationnels : 4. Procédure d'incident cyber automotive : équipe d'astreinte 24/7 capable de pousser un patch en moins de 72h sur la flotte complète, en lien avec NHTSA / autorités équivalentes. 5. Partage d'information : adhésion à l'Auto-ISAC (Automotive Information Sharing and Analysis Center), créé en 2015 suite à l'incident Jeep — coopération entre constructeurs sur les menaces et IoC.

Mesure prioritaire si on devait n'en garder qu'une : l'OTA Uptane. Sans elle, aucune des autres mesures ne peut atteindre son RTO.

5. Analyse rétrospective

Un PCA/PRA cybersécurité existait-il chez FCA en 2015 ? → Non.

Description de la situation : FCA disposait de plans de continuité classiques (cyber-attaques sur les SI internes, sinistres physiques sur les usines), mais pas de PCA/PRA spécifiquement dédié à la cybersécurité automotive embarquée. La menace de compromission à distance d'un véhicule en circulation n'était pas dans le modèle de menace utilisé pour la conception.

Conséquences concrètes de cette absence :

Conséquence	Détail
Rappel physique de 1.4M véhicules	Premier rappel automobile motivé par une vulnérabilité cyber. Pas d'OTA = pas d'autre option.
Distribution de patches via USB postaux	Clés USB physiques envoyées par courrier aux propriétaires entre juillet et septembre 2015. Couverture incertaine (les utilisateurs doivent brancher la clé).
Fermeture d'urgence côté Sprint	Sprint a dû fermer le port 6667 côté infrastructure en urgence, sans plan préétabli avec FCA. Mesure réactive, pas planifiée.
Enquête NHTSA	Le régulateur (National Highway Traffic Safety Administration) a ouvert une enquête sur l'efficacité du rappel, prolongeant l'exposition médiatique de FCA.
Coût direct estimé	~100M$ entre opérations de rappel, communication, conseil juridique. Hors coût indirect (perte de confiance).
Impact boursier	Action FCA a chuté de ~2% sur la semaine suivant la divulgation.
Durée totale de remediation	~6 mois pour atteindre une couverture significative — fenêtre pendant laquelle des copycats auraient pu exploiter la vulnérabilité (heureusement non observés).

Leçons retenues et changements post-incident (au niveau industrie) :

Création de l'Auto-ISAC (Automotive Information Sharing and Analysis Center) — août 2015, suite directe de l'incident. Plateforme de partage d'IoC et de bonnes pratiques entre constructeurs.
Adoption massive de l'OTA : la plupart des constructeurs ont accéléré leur roadmap OTA. Tesla en avait depuis 2012 ; Ford, GM, BMW ont suivi 2016-2019.
Émergence des V-SOC : création de cellules dédiées à la sécurité automotive chez les grands constructeurs (Toyota, Ford, GM, FCA-Stellantis).
Standard ISO/SAE 21434 (publié 2021) — impose un threat modeling cybersécurité formel sur tout le cycle de vie des véhicules.
Règlement UNECE R155 (adopté 2020, obligatoire homologation juillet 2022) — impose un CSMS (Cyber Security Management System) à tout constructeur souhaitant vendre dans l'UE, Japon, Corée du Sud. Sans CSMS = pas d'homologation = pas de vente.
Procédure de rappel cyber accélérée chez NHTSA — protocole spécifique pour les vulnérabilités cyber, distinct des défauts mécaniques classiques.

Conclusion de l'analyse rétrospective : L'incident Jeep Cherokee de 2015 est un cas d'école de PCA/PRA cybersécurité défaillant dans l'automobile. L'industrie a tiré les conséquences sur dix ans, mais en 2015, FCA s'est trouvé sans aucun moyen de réagir vite à une vulnérabilité grave. Le coût d'une politique de continuité (OTA, V-SOC) est très inférieur au coût d'un rappel physique — et c'est l'enseignement principal de l'incident.

11. Composants UI réutilisables à recréer

Liste minimale des composants à créer côté Next.js / React. Voir l'artefact iot_risk_briefing.jsx pour les implémentations de référence.

Layout

<AppShell> : header global + hero du cas + navigation secondaire + footer
<CaseHero> : carte de présentation du cas avec stats et score de criticité
<NavTabs> : barre d'onglets soulignés avec compteur (ex : "5 risques")
<Section> : conteneur de section avec en-tête (icône + code mono + titre)

Cartes

<StatCard> : carte de stat avec icône + valeur grande + label
<RiskCard> : carte expandable pour un risque (avec hypothèses + mitigation)
<AMDECRow> : ligne expandable pour un mode de défaillance AMDEC
<CVSSMetric> : carte d'une métrique CVSS avec clé, valeur, libellé, justification
<CVSSPanel> : panneau complet d'un scoring CVSS (v2 ou v3)
<TimelineStep> : étape de chronologie avec numéro et trait vertical

Spécialisés

<CriticalityMatrix> : matrice 4×4 cliquable avec positionnement des risques en chips
<CVSSScoreCircle> : score CVSS en cercle coloré selon la sévérité
<ScoreBar> : barre de score 0-10 avec valeur numérique à droite
<Badge> : badge inline (ÉTAPE 04, MITIGATION, OFFICIEL, etc.)

Composants page 5 (nouveaux)

<RTODisplay> : affichage du RTO avec valeur cible et comparaison historique
<RPODisplay> : idem pour le RPO
<ContinuityMeasureCard> : carte d'une mesure de continuité avec badge type (technique/organisationnelle)
<RetrospectiveTimeline> : timeline post-incident des leçons retenues

12. Fonctions utilitaires

// Niveau de criticité P × I
function getCriticality(prob: number, impact: number) {
  const score = prob * impact;
  if (score <= 3) return { score, level: "FAIBLE", color: "#22c55e" };
  if (score <= 6) return { score, level: "MODÉRÉ", color: "#eab308" };
  if (score <= 9) return { score, level: "ÉLEVÉ", color: "#f97316" };
  return { score, level: "CRITIQUE", color: "#ef4444" };
}

// Niveau d'IPR AMDEC
function getIPRLevel(ipr: number) {
  if (ipr < 100) return { label: "FAIBLE", color: "#22c55e" };
  if (ipr < 200) return { label: "MODÉRÉ", color: "#eab308" };
  if (ipr < 400) return { label: "ÉLEVÉ", color: "#f97316" };
  return { label: "CRITIQUE", color: "#ef4444" };
}

// Niveau CVSS
function getCVSSLevel(score: number) {
  if (score === 0) return { label: "NONE", color: "#71717a" };
  if (score < 4.0) return { label: "LOW", color: "#22c55e" };
  if (score < 7.0) return { label: "MEDIUM", color: "#eab308" };
  if (score < 9.0) return { label: "HIGH", color: "#f97316" };
  return { label: "CRITICAL", color: "#ef4444" };
}

13. Notes pour Claude Code

Bonnes pratiques attendues

TypeScript strict : pas de any, types explicites partout
Composants Server / Client clairs : marquer "use client" uniquement quand c'est nécessaire (interactivité, useState)
Lazy import : pour les vues lourdes (CVSS, AMDEC), import dynamique avec next/dynamic si performance critique
Accessibilité : <button> pour tout interactif, aria-expanded sur les expandables, contraste vérifié
SEO de base : <meta> titles et descriptions par page, sitemap auto
Pas de framework de tests obligatoire pour ce projet, mais si ajout : Vitest + Testing Library

Architecture fichiers suggérée

src/
├── app/
│   ├── layout.tsx              ← AppShell global
│   ├── page.tsx                ← redirige vers /dossier
│   ├── dossier/page.tsx
│   ├── risques/page.tsx
│   ├── amdec/page.tsx
│   ├── cve/page.tsx
│   └── continuite/page.tsx
├── components/
│   ├── layout/
│   │   ├── AppShell.tsx
│   │   ├── CaseHero.tsx
│   │   ├── NavTabs.tsx
│   │   └── Section.tsx
│   ├── cards/
│   │   ├── StatCard.tsx
│   │   ├── RiskCard.tsx
│   │   └── AMDECRow.tsx
│   ├── matrix/
│   │   └── CriticalityMatrix.tsx
│   ├── cvss/
│   │   ├── CVSSPanel.tsx
│   │   ├── CVSSMetric.tsx
│   │   └── CVSSScoreCircle.tsx
│   └── ui/
│       ├── Badge.tsx
│       └── ScoreBar.tsx
├── data/
│   └── jeep.ts                 ← tout le contenu du cas (data + types)
├── lib/
│   ├── criticality.ts          ← getCriticality, getIPRLevel, getCVSSLevel
│   └── constants.ts            ← palette, scales, etc.
└── types/
    └── index.ts                ← interfaces TS

Bibliothèques recommandées

{
  "dependencies": {
    "next": "^15.0.0",
    "react": "^18.3.0",
    "react-dom": "^18.3.0",
    "lucide-react": "^0.400.0",
    "tailwindcss": "^3.4.0"
  },
  "devDependencies": {
    "typescript": "^5.4.0",
    "@types/node": "^20.0.0",
    "@types/react": "^18.3.0",
    "eslint-config-next": "^15.0.0"
  }
}

Choses à NE PAS faire

❌ Utiliser localStorage / sessionStorage
❌ Ajouter des librairies UI lourdes (Material-UI, Chakra) — Tailwind suffit
❌ Animer agressivement (pas de Framer Motion sauf vraie nécessité)
❌ Inventer des données qui ne sont pas dans ce brief
❌ Modifier les scores P/I/G/O/D/CVSS — ils sont validés pédagogiquement
❌ Traduire ou paraphraser les hypothèses et mitigations — texte source verbatim
❌ Ajouter des cas autres que Jeep Cherokee (BadBox, etc. ne sont plus dans le périmètre)

Ce qu'il faut faire en priorité

✅ Reproduire fidèlement l'esthétique « briefing tactique » dark
✅ Garder les sous-onglets comme moyen principal de navigation
✅ Les hypothèses et mitigations sont visibles par défaut (déplié), pas cachées
✅ Conserver les badges méthodologiques (ÉTAPE 04, MITIGATION, OFFICIEL, etc.)
✅ Liens externes des références CVE en target="_blank" rel="noreferrer noopener"
✅ Pour la matrice de criticité : interactivité au clic + chips de risques positionnés
✅ Pour les pages AMDEC et RTO/RPO : structure cohérente avec les autres pages

14. Sources et références bibliographiques

Miller, C. & Valasek, C. (2015). Remote Exploitation of an Unaltered Passenger Vehicle. http://illmatics.com/Remote%20Car%20Hacking.pdf
CISA / ICS-CERT (2015). ICSA-15-260-01 — Harman-Kardon Uconnect Vulnerability. https://www.cisa.gov/news-events/ics-advisories/icsa-15-260-01
CERT/CC (2015). VU#819439 — Fiat Chrysler Automobiles UConnect allows a vehicle to be remotely controlled. https://www.kb.cert.org/vuls/id/819439
NVD (2015). CVE-2015-5611. https://nvd.nist.gov/vuln/detail/CVE-2015-5611
ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering
UNECE R155 — Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system
The Update Framework (TUF) / Uptane — https://uptane.github.io/
Auto-ISAC — https://automotiveisac.com/

15. Checklist finale Claude Code

À la livraison du site, vérifier :

Routes /dossier, /risques, /amdec, /cve, /continuite toutes fonctionnelles
Hero Jeep Cherokee visible sur toutes les pages
Score de criticité global 12 / CRITIQUE affiché en rouge dans le hero
Navigation secondaire avec 5 onglets et compteurs corrects
Page Dossier : 5 phases de timeline, 4 causes racines, 5 problèmes, 5 solutions
Page Risques : briefing 4 étapes + 5 risques (R1-R5) avec hypothèses et mitigations visibles par défaut
Page Risques : matrice 4×4 cliquable avec chips R1-R5 positionnés
Page Risques : R4 marqué "PLUS CRITIQUE" (8), R1 ou R5 marqués "MOINS CRITIQUE" (4)
Page AMDEC : 5 modes triés par IPR descendant, AMD-05 en tête (IPR 320)
Page AMDEC : 3 échelles G/O/D détaillées en bas de page
Page CVE : CVE-2015-5611 + 2 advisories visibles
Page CVE : CVSS v2 (8.3 HIGH) et v3.1 (9.6 CRITICAL) côte à côte
Page CVE : encadré comparatif v2 vs v3 expliquant le scope changed
Page CVE : 4 liens cliquables externes (NVD, CISA, CERT, paper M&V)
Page Continuité : 5 sections (composant critique, RTO, RPO, mesure, rétrospective)
Footer présent avec version et liste des standards référencés
Aucune référence résiduelle à BadBox dans le code
TypeScript strict sans erreurs
Lighthouse : Performance > 90, Accessibilité > 95
Pas d'erreur de console au runtime

Fin du brief. Tout ce qui est nécessaire pour reconstruire le site est ci-dessus. En cas de doute sur un contenu, se référer prioritairement à l'artefact iot_risk_briefing.jsx qui contient la version implémentée et validée.

53 KiB Raw Permalink Blame History Unescape Escape

Brief Projet — Site d'analyse de risques IoT (Jeep Cherokee 2015)

1. Contexte projet

Objectif

Public cible

Ton et style

2. Stack technique recommandée

Choix préféré

Alternative légère

Contraintes

3. Architecture du site

Routes

Layout commun

4. Design system

Palette

Typographie

Patterns visuels

Composants récurrents

5. Structures de données (TypeScript)

6. Page 1 — Dossier d'incident

Données du Hero

Section : Comment l'attaque s'est déroulée (Timeline)

Section : Pourquoi c'est arrivé (Causes racines)

Section : Problèmes identifiés

Section : Solutions et bonnes pratiques

7. Page 2 — Analyse de risques (Matrice P × I)

Méthodologie (briefing en haut de page)

Échelles

Les 5 risques contextualisés

R1 — Énumération à distance de la flotte Uconnect sur le réseau Sprint

R2 — Exécution de code à distance sur la head unit Linux via D-Bus port 6667

R3 — Reflashing du microcontrôleur Renesas V850 avec firmware non signé via SPI

R4 — Contrôle distant des freins, direction et accélérateur en conduite à haute vitesse

R5 — Désactivation persistante du frein de parking pour immobilisation/sabotage

Synthèse pédagogique

8. Page 3 — AMDEC / FMEA

Méthodologie (briefing)

Échelles détaillées

Tableau AMDEC complet (5 modes, triés par IPR descendant)

AMD-05 (IPR = 320) — Protocole CAN bus

AMD-03 (IPR = 288) — Microcontrôleur Renesas V850

AMD-01 (IPR = 240) — APN Sprint

AMD-04 (IPR = 210) — Architecture réseau interne

AMD-02 (IPR = 112) — Service D-Bus

9. Page 4 — CVE / CVSS

Briefing pédagogique

Identification de la vulnérabilité

Description

Chaîne d'attaque

CVSS v2.0 — OFFICIEL NVD

CVSS v3.1 — RÉINTERPRÉTATION PÉDAGOGIQUE

Différence v2 vs v3 — Pourquoi le score grimpe

Échelles CVSS

Remediation

Références officielles (liens cliquables)

10. Page 5 — RTO / RPO / PCA-PRA (NOUVELLE)

Briefing pédagogique

Définitions clés

1. Composant critique

2. Définition du RTO

3. Définition du RPO

4. Mesure de continuité concrète

5. Analyse rétrospective

11. Composants UI réutilisables à recréer

Layout

Cartes

Spécialisés

Composants page 5 (nouveaux)

12. Fonctions utilitaires

13. Notes pour Claude Code

Bonnes pratiques attendues

Architecture fichiers suggérée

Bibliothèques recommandées

Choses à NE PAS faire

Ce qu'il faut faire en priorité

14. Sources et références bibliographiques

15. Checklist finale Claude Code

53 KiB

Raw Permalink Blame History