Threat modeling en pratique

Prérequis : cours précédent.

Pourquoi

Le cours 1.1 donne le vocabulaire ; ici la méthode pas à pas, sur TON app, en une heure. Un threat model écrit vaut tous les scanners du monde pour les failles de conception (qu'aucun outil ne trouve).

Concepts

• STRIDE (Microsoft) : par composant, chercher Spoofing (usurpation), Tampering (modification), Repudiation (déni — « c'est pas moi »), Info disclosure (fuite), DoS, Elevation (montée de privilèges). Une grille, pas de l'inspiration.
• Diagramme de flux : dessiner users → front → API → base → tiers, avec les frontières de confiance (internet / DMZ / interne). Les attaques vivent aux frontières.
• Cotation : impact × probabilité (ou DREAD simplifié). Tout ne se traite pas : on traite le rouge, on assume le vert par écrit.

Exemple : login en STRIDE express

Spoofing : brute-force → rate-limit + alertes (cf. 1.1)
Tampering : reset token devinable → token aléatoire 256 bits + expiry 15 min
Repudiation : qui s'est connecté quand ? → logs auth horodatés
Info disclosure : énumération (403 vs 404 !) → messages génériques
Elevation : rôle modifiable par l'user ? → jamais depuis le client

Cas réel

Reset password par token incrémental (/reset?token=1042) : énuméré en 10 minutes, 300 comptes pris. STRIDE de 20 minutes l'aurait vu (« Tampering : token devinable ? »). Coût du fix après : 3 jours + communication + rotation forcée.

Pièges

• Modéliser une fois puis oublier : chaque feature (upload ! SSO ! export !) rouvre la question. Rituel par feature sensible.
• Tout classer rouge : sans priorités, rien n'est fait. Assumer du vert par écrit, c'est aussi de la sécu.
• Oublier les logs comme asset ET comme risque (données dedans !) : les deux côtés du triangle.

À retenir

STRIDE par composant, frontières sur le schéma, rouge traité, vert assumé par écrit.