Threat modeling — STRIDE¶

Identifier les menaces techniques composant par composant avant qu'elles ne se materialisent.

Pourquoi le threat modeling¶

Le threat modeling est une approche structurée pour identifier les menaces de sécurité d'un système avant que le code ne soit écrit. Plutôt que d'attendre les tests de penetration en fin de projet, on anticipe les vecteurs d'attaque des la conception.

STRIDE est un framework de categorisation des menaces développé par Microsoft. Les 6 catégories couvrent l'ensemble des vecteurs d'attaque possibles sur un système. Pour les définitions détaillées de chaque catégorie et leur application au code, voir Securiser son code — fondamentaux.

Processus en 4 étapes¶

Étape 1 — Dessiner le diagramme de flux (DFD)¶

Le DFD (Data Flow Diagram) est la base de l'analyse. On identifie les composants, les flux de données entre eux, les frontieres de confiance et les stockages de données.

Les éléments du DFD :

La précision du DFD détermine la qualité de l'analyse. Un DFD trop abstrait manque les menaces. Un DFD trop détaillé rend l'analyse ingerable. On vise le niveau ou chaque flux de données significatif est visible.

Étape 2 — Identifier les menaces par composant¶

Pour chaque composant et chaque flux du DFD, on appliqué STRIDE systematiquement. La question n'est pas "est-ce que cette menace est probable ?" mais "est-ce que cette menace est possible ?". La priorisation vient ensuite.

Chaque "x" est une menace a documenter avec une description concrète.

Étape 3 — Prioriser avec une risk matrix¶

Toutes les menaces n'ont pas le même impact ni la même probabilite. Une risk matrix simple croise probabilite et impact sur une échelle 1-3 :

Les menaces de score >= 5 sont traitees en priorité. Les autres sont documentees et revisitees lors du prochain cycle.

La méthode DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) offre une granularité supplémentaire si la risk matrix simple ne suffit pas.

Étape 4 — Définir les mitigations¶

Pour chaque menace prioritaire, on définit la mesure d'attenuation concrète et l'équipe responsable.

Exemple complet : API e-commerce¶

graph LR
    U[Utilisateur] --text--> GW[API Gateway]
    GW --text--> OS[Order Service]
    OS --text--> DB[(Base de donnees)]
    OS --text--> PP[Payment Provider]
    OS --text--> NS[Notification Service]

Analyse STRIDE¶

Threat modeling automatise¶

Le threat modeling manuel est indispensable pour les analyses profondes. Mais pour les systèmes complexes avec de nombreux composants, des outils automatises aident à couvrir la surface et a maintenir l'analyse dans le temps.

Outils principaux¶

OWASP Threat Dragon¶

Threat Dragon est l'outil de référence open source. Il permet de dessiner des DFD, d'appliquer STRIDE automatiquement à chaque composant, et de générer un rapport de menaces.

Workflow typique :

1. Dessiner le DFD dans l'interface (composants, flux, frontieres)
2. Pour chaque composant, l'outil suggère les menaces STRIDE applicables
3. Valider ou rejeter chaque menace suggérée
4. Documenter les mitigations pour les menaces retenues
5. Générer le rapport final

L'avantage principal : le modèle est versionne avec le code. À chaque modification architecturale, on met à jour le DFD et l'outil signale les nouvelles menaces potentielles.

Threagile¶

Threagile adopte une approche "as code" — le modèle du système est défini en YAML et l'outil généré automatiquement les risques identifiés :

# threagile.yaml (extrait)
technical_assets:
  api-gateway:
    description: API Gateway public
    type: process
    technologies:
      - web-service-rest
    internet: true
    confidentiality: confidential
    integrity: critical
    availability: critical

  order-service:
    description: Service de commandes
    type: process
    technologies:
      - web-service-rest
    internet: false

communication_links:
  api-gateway-to-order:
    source: api-gateway
    target: order-service
    protocol: https
    authentication: token

L'approche "as code" permet d'intégrer le threat model dans le pipeline CI. À chaque changement d'architecture, le modèle est mis à jour et les risques sont recalcules automatiquement.

Intégrer le threat modeling dans le cycle¶

Le threat modeling n'est pas un exercice ponctuel. Il doit être rejoue à chaque modification architecturale significative.

Déclencheurs de revue¶

Bonnes pratiques¶

• Intégrer le threat modeling au processus de design review — avant le code, pas après
• Versionner le DFD avec le code source du projet
• Maintenir un registre des menaces et de leur statut (ouverte, mitigee, acceptee)
• Impliquer les développeurs, pas seulement les specialistes sécurité
• Commencer simple : un DFD papier et une matrice STRIDE sur un tableau blanc suffisent pour démarrer

STRIDE per élément vs STRIDE per interaction¶

Deux variantes de STRIDE existent selon la granularité souhaitee :

STRIDE per élément — on applique les 6 catégories à chaque composant du DFD. C'est l'approche classique, plus rapide mais moins précisé.

STRIDE per interaction — on appliqué STRIDE à chaque flux de données entre composants. Plus détaillé, cette variante identifie des menaces spécifiques aux communications (homme du milieu, rejeu, etc.).

Pour un premier threat model, STRIDE per élément suffit. Pour les systèmes critiques ou les flux sensibles (paiement, authentification), STRIDE per interaction apporte une couverture plus fine.

Arbres d'attaque¶

Les arbres d'attaque sont un complement a STRIDE pour les menaces complexes. La ou STRIDE identifie les catégories de menaces, l'arbre d'attaque decompose un objectif d'attaque en sous-objectifs et en chemins alternatifs.

La racine de l'arbre est l'objectif de l'attaquant. Les branches représentent les différentes manières d'atteindre cet objectif. Les nœuds intermédiaires sont des sous-objectifs. Les feuilles sont des actions concrètes.

graph TD
    ROOT["Exfiltrer les donnees\nde paiement"]
    ROOT --> A["Compromettre\nla base de donnees"]
    ROOT --> B["Intercepter\nles flux de paiement"]
    ROOT --> C["Compromettre\nun backup"]
    A --> A1["Injection SQL\nvia l'API"]
    A --> A2["Credentials DB\nen clair dans la config"]
    A --> A3["Acces direct\nport DB expose"]
    B --> B1["Man-in-the-middle\nsans mTLS"]
    B --> B2["Compromission\ndu payment gateway"]
    C --> C1["Backup non chiffre\nsur S3 public"]
    C --> C2["Acces au NAS\nvia credentials par defaut"]

Chaque feuille est évaluée en termes de faisabilite et de coût pour l'attaquant. Les chemins les plus accessibles (faible coût, forte probabilite) sont les priorités de traitement.

Les arbres d'attaque sont particulièrement utiles pour :

• Les menaces complexes qui impliquent plusieurs étapes
• La communication avec les decideurs non techniques (la représentation visuelle est intuitive)
• L'identification de points de convergence ou une seule mesure bloque plusieurs chemins

Registre des menaces¶

Le registre des menaces est le livrable opérationnel du threat modeling. Il centralise toutes les menaces identifiées, leur évaluation, leur statut de traitement et les responsables.

Le registre est un document vivant. Il est révisé à chaque modification architecturale et chaque incident de sécurité. Les menaces traitees restent documentees pour la traçabilite. Les nouvelles menaces sont ajoutees au fur et à mesure que le système évolue.

Chapitre suivant : Zero trust — ne jamais faire confiance par défaut, même à l'intérieur du réseau.