Avant d'implémenter : modélisez les menaces en quatre phases

Publier un système sans avoir modélisé ses menaces laisse la sécurité à la chance de la première revue de code qu'il reçoit au hasard, et quand cette revue arrive il y a déjà des clients qui utilisent le système. « Introduction to threat modeling » sur Microsoft Learn présente la modélisation de menaces comme une technique qui se fait au début du cycle de vie : identifier des menaces et décider comment réduire le risque avant que la première ligne n'arrive en production. La technique tient en quatre phases, et ce post les parcourt en ordre : concevoir le système sur papier, reposer le cadre sur cette conception, corriger ce qui apparaît, et vérifier que tout est respecté avant d'implémenter.

Quand elle s'utilise

Elle s'utilise dès qu'on conçoit un nouveau système ou qu'on met à jour un existant. Trois exemples à échelle réelle illustrent quand elle s'applique : un microservice Azure qui rapporte l'usage des ressources à des fins budgétaires, une API publique pour les clients, et une nouvelle fonctionnalité dans une application existante. Les trois cas partagent une propriété : au moment de la conception, il est encore bon marché de changer d'avis.

Pas besoin d'être spécialiste. N'importe qui avec une connaissance pratique du système et une compréhension basique de la sécurité peut le faire, avec n'importe quelle approche de livraison (Agile ou Waterfall) et à la cadence que l'équipe peut tenir : chaque heure, chaque mois ou chaque année. La cadence compte moins que la constance.

Les quatre phases

La technique se divise en quatre phases, et chacune répond à une question que les autres ne peuvent pas répondre.

flowchart LR
    D["Conception"] --> B["Repos (break)"]
    B --> C["Correction"]
    C --> V["Vérification"]
    V -.->|"la cadence revient"| D

En clair : d'abord vous dessinez ce qu'il y a, ensuite vous regardez ce dessin avec des lunettes de sécurité, ensuite vous décidez quoi faire de ce que vous avez vu, et à la fin vous vérifiez que ce qui a été fait suffit. L'ordre ne peut pas s'inverser : il n'y a pas de façon de trouver des menaces d'un système que personne n'a décrit.

L'omission de chaque phase a son prix concret. Sans conception, des considérations de sécurité sont négligées ; sans la phase de repos, les menaces ne se trouvent pas ; sans correction, les risques ne se réduisent pas ; et sans vérification, on ne prouve pas que le travail de sécurité s'est terminé. La dernière est la plus sautée, et c'est elle qui transforme une liste de bonnes intentions en un travail vérifiable.

Phase de conception : tout demander avant de dessiner

L'objectif de la phase de conception est de rassembler autant de données que possible sur ce que vous construisez : développer une image claire du fonctionnement du système, énumérer tous les services qu'il consomme, énumérer toutes les hypothèses sur l'environnement et les configurations de sécurité par défaut, et créer un diagramme de flux de données (DFD) au bon niveau de profondeur. Le DFD est la représentation graphique du système, et il se compose de cinq éléments avec leur propre forme : processus (tâche qui reçoit, modifie ou redirige l'entrée vers la sortie), magasin de données (stockage permanent et temporaire, caches web et bases de données Azure), entité externe (hors contrôle direct : utilisateurs et API tiers), flux de données (mouvement entre processus, magasins et entités externes) et limite de confiance (changements de zone de confiance, comme des utilisateurs Internet accédant à un réseau d'entreprise protégé). Le détail de chacun a son propre post dans cette série. Si la phase de conception se coupe trop tôt, ces considérations de sécurité restent hors du document et ensuite personne ne les récupère.

Les questions du système se formulent par domaines, et la liste est longue exprès : description (ce qu'il fait, quels processus métier il contrôle), environnement (cloud ou local, système d'exploitation, conteneurs), scénarios (comment il sera utilisé et comment non), permissions, fournisseur cloud et ses configurations par défaut, système d'exploitation et ses configurations, services de premier et de tiers, comptes (types, locaux ou de cloud, quel accès et pourquoi), identité et contrôle d'accès (Microsoft Entra ID, listes de contrôle d'accès (ACL), authentification multifacteur (MFA)), tokens et sessions, omission (portes dérobées), journalisation, supervision et sauvegarde, réseau, données (type, classification, validation, chiffrement dans tous les états) et administration des secrets (clés, certificats, identifiants).

La source est honnête sur la limite de cette liste : elle est extensive mais pas exhaustive. Il vaut parler avec les collègues et l'équipe de sécurité, même organiser une session de tableau blanc. Un chiffre qui montre pourquoi l'effort en vaut la peine : les équipes d'ingénierie de Microsoft envoient des DFD comme partie des exigences de conformité de sécurité, parce qu'un bon dessin fait avancer les conversations de sécurité mieux que n'importe quel paragraphe.

Phase de repos : regarder le dessin avec des lunettes de sécurité

La phase de repos (aussi appelée « break ») utilise le DFD pour trouver des menaces possibles avec un cadre. Le cadre que Microsoft utilise est STRIDE, l'acronyme des six catégories principales de menaces : usurpation d'identité, altération, déni, divulgation d'information, déni de service et élévation de privilèges. Le détail de chaque catégorie a son propre post dans cette série ; ce qui compte ici est autre chose : avant d'appliquer le cadre on choisit une approche d'attention. Protéger le système (trouver des problèmes comme une connexion non chiffrée), comprendre l'attaquant (moyens, motifs, points d'entrée) ou protéger les actifs critiques identifiés par le contrôle des données classifiées. Les ingénieurs produit de Microsoft se concentrent principalement à protéger le système ; les équipes de test de pénétration travaillent sur les deux premiers en même temps.

Phase de correction : décider avec des variables, pas des sensations

Chaque menace qui apparaît au repos a besoin d'une destination, et la destination se décide avec trois variables. Impact : la catégorie STRIDE qui lui revient. Gravité : la barre d'erreurs interne de Microsoft ou un cadre de priorisation, évalué avec les pires cas possibles ; la barre utilise les classements critique, important, modéré, bas ou d'information. Risque : le calcul entre l'efficacité du contrôle de sécurité et le coût de l'implémenter.

L'issue priorisée devient une tâche dans un service de gestion d'incidents comme Azure DevOps Services, ce qui renforce la propriété du problème, suit l'historique et permet des modèles standardisés. Ensuite chaque menace se assigne à un ou plusieurs contrôles de sécurité selon un mapeo que la source fixe : l'usurpation va avec l'authentification (messages signés avec signatures numériques), l'altération avec l'intégrité (validation d'entrée), le déni avec le non-repudiation (journaux de sécurité avec actions et horodatages), la divulgation avec la confidentialité (ACL), le déni de service avec la disponibilité (ressources élastiques) et l'élévation de privilèges avec l'autorisation (exécuter le service avec le minimum d'accès possible). Et le mapeo n'est pas un à un en pratique : un seul contrôle peut réduire plusieurs menaces, et SSL/TLS est l'exemple que donne la source, avec des canaux sécurisés qui couvrent modification et divulgation à la fois. L'issue se ferme avec une des quatre résolutions :

Réduire : corrections ou changement de conception.
Transférer : l'issue est assignée à un autre système ou équipe.
Éviter : l'élément qui contient l'issue est éliminé.
Accepter : le risque est accepté sans solution. Accepter n'est pas un laissez-passer : ça requiert l'approbation d'un responsable autorisé à prendre des décisions sur les risques, et la hauteur de la signature dépend de la gravité. Une menace critique demande une direction sénior ; un sujet de défense en profondeur peut suffire avec un ingénieur sénior.

flowchart LR
    A[Menace détectée] --> P["Priorisation<br/>impact · gravité · risque"]
    P --> C[Contrôle ou contrôles]
    C --> R["Résolution<br/>réduire · transférer · éviter · accepter"]

Chaque menace parcourt ces quatre cases : elle se détecte contre le DFD, se priorise avec les trois variables, se couvre d'un ou plusieurs contrôles et se ferme avec une des quatre résolutions ; si la résolution est accepter, la clôture est signée par un responsable autorisé.

Phase de vérifier : celle qui prouve que le travail a existé

La phase de vérification se fait avant d'implémenter et assure que les exigences sont satisfaites, que les hypothèses sont valides et que les contrôles sont implémentés. Concrètement : confirmer la conformité des exigences nouvelles et antérieures (plans de sécurité réseau, solution de secrets, journalisation et supervision, contrôles d'identité et d'accès), configurer le fournisseur cloud, le système d'exploitation et les composants pour satisfaire ces exigences, avec des exemples comme le chiffrement de données transparent d'Azure SQL Database, le contrôle d'accès basé sur les rôles (RBAC) et le Pare-feu Windows sur tous ses profils ; résoudre tous les incidents enregistrés en vérifiant les corrections ; et faire des vérifications manuelles et automatisées avant l'implémentation.

La cadence de cette vérification est par déploiement ou à intervalles de 6 à 12 mois, et chez Microsoft les systèmes sont soumis à un processus de vérification pré-implémentation qui peut inclure des analyses automatisées, des revues de code et des tests de pénétration. La source marque quand il vaut d'accélérer : si le système est utilisé externement, contrôle des données confidentielles, doit respecter des réglementations ou l'organisation requiert des processus de sécurité supplémentaires pour la confidentialité, le risque opérationnel ou le développement, la cadence devrait être plus courte.

De la lecture à l'exécution

Ce parcours a été de lecture : je n'ai modélisé aucun vrai système en suivant ces quatre phases sur un abonnement à soi. Ce que la source rend clair, c'est le cadre complet, depuis la première question de conception jusqu'à la signature qui approuve un risque accepté ; ce qui manque, c'est de l'appliquer à quelque chose de soi, parce que c'est là qu'apparaissent les vrais doutes : quelles hypothèses d'environnement sont des mensonges dans votre infrastructure, combien de temps prend vraiment une session de tableau blanc, et si votre équipe tient la cadence après l'enthousiasme initial. L'ordre pour reprendre est déjà donné par les quatre phases : dessinez le DFD de quelque chose que vous connaissez, regardez-le avec STRIDE, priorisez ce qui sort et vérifiez avant de toucher à la production.

---

*Source : le module « Introduction to threat modeling » de Microsoft Learn.*