Modélisation de menaces en une heure

La modélisation de menaces meurt presque toujours de la même façon. Une équipe y consacre deux jours, produit un diagramme complet du système et un tableau de quatre-vingts menaces classées par criticité. Six mois plus tard, l'architecture a changé et personne n'a rouvert le document.

Ce qui a tué l'exercice, c'est son périmètre. Un modèle du système entier est faux le lendemain et ne produit aucune décision. Je fais l'inverse : je modélise un changement plutôt qu'un système, en une heure au lieu de deux jours, avec une sortie qui se mesure en tickets. Une séance qui ne modifie pas le backlog n'a pas eu lieu.

Le déclencheur : une frontière de confiance qui bouge

Une frontière de confiance est l'endroit où une donnée passe d'une entité à une autre qui n'a pas les mêmes droits ou les mêmes intérêts : du navigateur au serveur, d'un tenant à un autre, de votre application à un prestataire, d'un utilisateur anonyme à un utilisateur authentifié. Les failles vivent sur ces frontières, parce qu'une hypothèse faite d'un côté y cesse d'être vraie de l'autre.

La séance se déclenche quand un changement en crée une, en déplace une ou en fait traverser une à un nouveau type de donnée :

• un nouveau point d'entrée (route publique, webhook entrant, import de fichier) ;
• une nouvelle intégration (prestataire, API tierce, agent qui appelle des outils) ;
• un nouveau type de donnée sensible, ou une donnée existante envoyée vers une nouvelle destination ;
• un changement du modèle d'autorisation (nouveau rôle, partage, délégation) ;
• un nouveau composant qui exécute ou interprète du contenu venu d'ailleurs.

Le critère se pose pendant le cadrage. Une modélisation faite sur du code terminé ne peut plus recommander que des rustines, et chacune sera négociée contre la date de livraison.