Une équipe s'apprête à construire une nouvelle fonctionnalité de paiement. Quand et comment la modélisation des menaces doit-elle avoir lieu ?
Réponse courte
La modélisation des menaces est la moins coûteuse et la plus efficace à la conception, avant que le code ne fige les décisions : parcourez les flux de données, énumérez les menaces avec un cadre comme STRIDE, intégrez les mesures, puis révisez à mesure que la conception évolue. La faire seulement après un incident ou au pentest annuel révèle les problèmes une fois qu'ils sont coûteux à corriger et déjà exposés. Et se fier à des « développeurs prudents » est un espoir, non un contrôle reproductible et auditable.
Une fonctionnalité de paiement manipule de l'argent et des données sensibles — exactement le type de système où la réflexion sécurité dès la conception rapporte le plus. La question teste si le candidat comprend quand le travail de sécurité est bon marché et efficace, par opposition à coûteux et réactif.
Pourquoi la modélisation des menaces à la conception l'emporte
La modélisation des menaces est une façon structurée de se demander, avant de construire : qu'est-ce qui peut mal tourner, et qu'allons-nous y faire ? À la conception, l'architecture est encore fluide — vous pouvez déplacer une frontière de confiance, ajouter un contrôle ou abandonner une dépendance risquée pour le coût d'une modification de diagramme, pas d'un refactoring de code déjà livré.
Un déroulé pratique :
- Diagrammez les flux de données de la fonctionnalité de paiement et marquez les frontières de confiance (navigateur → API → processeur de paiement → base de données).
- Énumérez les menaces avec un cadre comme STRIDE — Usurpation, Altération, Répudiation, Divulgation d'information, Déni de service, Élévation de privilège — à chaque frontière.
- Définissez les mesures (authentification/autorisation, validation des entrées, clés d'idempotence, tokenisation, journalisation) et suivez-les comme des exigences.
- Révisez à chaque changement de conception — c'est une activité vivante, pas un acte unique.
Pourquoi les mauvaises réponses sont fausses
« Après le lancement, seulement en cas d'incident » est le pire timing possible : vous payez en violations, préjudice client et reprise en urgence. « Uniquement lors du pentest annuel » trouve les problèmes tard, de façon étroite, et après leur mise en production — un pentest valide une conception, il ne remplace pas une conception sécurisée. « Inutile si les développeurs sont prudents » confond la diligence individuelle avec un processus ; la prudence n'est ni reproductible, ni auditable, ni résistante au renouvellement des équipes, et n'offre aucune couverture systématique des catégories de menaces.
Ce que sonde l'examinateur
Il veut un instinct shift-left : un raisonnement sécurité intégré à la conception, une méthodologie nommée, des frontières de confiance et des mesures concrètes, et la maturité de traiter le modèle de menaces comme un artefact vivant qui évolue avec le système — pas une case à cocher à la fin.
Questions de suivi probables
- Déroulez STRIDE appliqué à un flux de paiement — donnez une menace par catégorie.
- Quels artefacts (diagramme de flux de données, frontières de confiance) faut-il avant de pouvoir modéliser les menaces ?
- Comment garder un modèle de menaces vivant plutôt qu'un document unique qui se périme ?