Threat Modeling – Exercice 1 : Concevoir un DFD pour une fonctionnalité de recharge de crédit

Introduction

Dans une démarche de Security by Design, la première étape avant d’identifier les menaces est de comprendre le système étudié.

Le Data Flow Diagram (DFD) est un outil essentiel du Threat Modeling. Il permet de représenter :

• les acteurs du système ;
• les composants techniques ;
• les échanges de données ;
• les zones où le niveau de confiance change (Trust Boundaries).

Dans cet exercice, nous allons modéliser une fonctionnalité de recharge de crédit en ligne via Mobile Money proposée par une administration publique nigérienne.

L’objectif est d’identifier l’architecture du système avant de poursuivre avec l’analyse des menaces.

Une administration permet aux citoyens de recharger un crédit de service en ligne.

Le citoyen utilise un navigateur web pour effectuer une demande de recharge. Le paiement est réalisé via un service Mobile Money externe grâce à un agrégateur de paiement.

Le système comprend les composants suivants :

• Citoyen : utilisateur qui effectue la recharge ;
• Navigateur web : interface utilisée par le citoyen ;
• Portail web : application développée par l’administration ;
• Service de paiement interne : composant chargé de gérer les demandes de paiement ;
• Agrégateur de paiement externe : service tiers permettant l’accès aux opérateurs Mobile Money ;
• Base des transactions : stockage des informations liées aux opérations de recharge.

Une Trust Boundary représente une zone où le niveau de confiance change.

Dans ce système, nous identifions plusieurs frontières :

1. Frontière citoyen / application

Le citoyen est un acteur externe. Les données envoyées depuis son navigateur doivent être considérées comme non fiables.

Risques possibles :

• modification des données envoyées ;
• usurpation d’identité ;
• manipulation des requêtes.

2. Frontière administration / service externe

L’agrégateur de paiement appartient à un tiers.

Cette frontière nécessite une attention particulière car :

• l’administration ne contrôle pas totalement ce service ;
• les échanges doivent être sécurisés ;
• les réponses reçues doivent être validées.

3. Frontière application / base de données

La base des transactions contient des informations importantes.

Il faut garantir :

• la confidentialité ;
• l’intégrité des transactions ;
• la traçabilité des opérations.

flowchart LR

    Citizen[Citoyen]
    Browser[Navigateur Web]

    Portal[Portail Web Administration]

    PaymentService[Service de paiement interne]

    Aggregator[Agrégateur de paiement externe]

    MobileMoney[Opérateur Mobile Money]

    Database[(Base des transactions)]


    subgraph TB1["Trust Boundary - Utilisateur externe"]
        Citizen
        Browser
    end

    subgraph TB2["Trust Boundary - Système Administration"]
        Portal
        PaymentService
        Database
    end

    subgraph TB3["Trust Boundary - Service externe"]
        Aggregator
        MobileMoney
    end


    Citizen --> Browser
    Browser -->|Demande de recharge| Portal

    Portal -->|Création paiement| PaymentService

    PaymentService -->|Requête paiement| Aggregator

    Aggregator -->|Transaction Mobile Money| MobileMoney

    MobileMoney -->|Statut paiement| Aggregator

    Aggregator -->|Confirmation paiement| PaymentService

    PaymentService -->|Enregistrement transaction| Database

    Database -->|Historique transaction| PaymentService

Grâce à ce DFD, nous pouvons déjà identifier plusieurs zones sensibles :

• identité du citoyen ;
• informations de paiement ;
• références des transactions ;
• statut des opérations.

• sécurisation des échanges entre le portail et l’agrégateur ;
• validation des réponses de paiement ;
• protection de la base des transactions ;
• authentification des utilisateurs.

La création d’un DFD est une étape fondamentale du Threat Modeling.

Avant de chercher les vulnérabilités, il faut comprendre :

• comment les données circulent ;
• où elles sont stockées ;
• quelles sont les frontières de confiance ;
• quels composants nécessitent le plus de protection.

Dans les prochains exercices, cette modélisation servira de base pour identifier les menaces avec la méthode STRIDE et définir les mesures de mitigation adaptées.

#Cybersecurity #ThreatModeling #DevSecOps #SecurityByDesign #STRIDE