Cet article explore l’impact de réglementations telles que l’ARC et NIS2 sur la gestion des risques liés au développement. Nous examinons pourquoi le Threat Modeling est la solution standard de l’industrie et nous démontrons son application pratique pour les développeurs, les responsables AppSec et les directeurs techniques.
Vous connaissez déjà les principes de base ? Cet article s’appuie sur notre article précédent, » Threat Modeling : Une porte vers une culture de développement sécurisée« qui couvre les fondements culturels et une approche progressive pour commencer.
1. Les exigences de NIS 2 et CRA en matière de gestion des risques
Ni l’ARC ni le NIS2 n’utilisent explicitement l’expression « Threat Modeling ». Ce qu’ils exigent, cependant, correspond presque parfaitement à ce que produit un bon Threat Model.
Le Cyber Resilience Act (CRA)
L’ARC est entrée en vigueur en décembre 2024 et s’appliquera à tout produit contenant des éléments numériques mis sur le marché de l’UE d’ici décembre 2027. Son obligation principale est la sécurité dès la conception : la sécurité doit être intégrée dès le départ, et non pas boulonnée après le déploiement.
Concrètement, l’ARC exige des fabricants qu’ils1
- Évaluer les risques de cybersécurité dans le cadre du processus de développement des produits
- Documenter les décisions en matière de sécurité et leur justification
- Veiller à ce que les vulnérabilités soient identifiées et traitées tout au long du cycle de vie.
- Appliquer le principe de la sécurité par défaut/conception
Chacune de ces exigences correspond directement au résultat d’un processus de Threat Modeling bien mené : un registre des risques, des décisions d’architecture documentées, des vecteurs d’attaque identifiés et des mesures d’atténuation architecturales.
NIS2
NIS2 s’applique aux entités essentielles et importantes des secteurs critiques et étend les obligations de sécurité plus profondément dans les chaînes d’approvisionnement que son prédécesseur. Parmi les exigences en matière de gestion des risques, citons
- La sécurité doit être prise en compte dans le développement des systèmes et des services
- Les risques liés aux fournisseurs et aux composants tiers doivent être évalués
- Les incidents doivent pouvoir être évités dans la mesure du possible grâce à une gestion proactive des risques.
Là encore, le Threat Modeling est l’une des rares techniques structurées permettant de produire les preuves que ces obligations requièrent, notamment en ce qui concerne les risques liés à la chaîne d’approvisionnement et la prise de décisions architecturales proactives.
2. Des bonnes pratiques aux preuves de conformité
C’est là que de nombreuses équipes échouent : elles font du Threat Modeling un exercice, mais elles ne la traitent pas comme un artefact de conformité. La différence est importante. Un Threat Model produit à partir d’une conversation sur un tableau blanc a de la valeur pour l’équipe. Un modèle de menace documenté, versionné, lié aux décisions architecturales et revu lorsque le système change devient une preuve.
Ce que cela signifie en pratique :
- Traçabilité : Chaque menace identifiée doit être liée à une décision d’atténuation ou à un risque accepté. La phrase « Nous avons identifié ce vecteur d’attaque, voici ce que nous avons fait » est la phrase que votre documentation de conformité doit pouvoir produire.
- Répétabilité : Un modèle unique pour une seule fonctionnalité ne répond pas aux obligations permanentes de l’ARC. Les équipes ont besoin d’un processus léger et reproductible qui peut être appliqué à chaque phase de la conception.
- Versioning : Lorsque le système change, le modèle de menace doit évoluer avec lui. Il faut donc traiter les résultats de la MT comme des documents évolutifs et non comme des instantanés.
- Couverture : Le champ d’application du CRA comprend les composants et les dépendances de tiers. le Threat Modeling doit aller au-delà de votre propre code et englober les bibliothèques, les API et les services sur lesquels votre produit s’appuie.
L’écart entre « nous faisons du Threat Modeling » et « nous pouvons démontrer que nous faisons du Threat Modeling » est précisément là où CRA et NIS2 exposeront les équipes non préparées. Vous devez montrer que vous avez réfléchi aux risques avant d’embarquer.
A quoi cela ressemble pour chaque rôle
Si il est intéressant que toutes sortes de profils soient impliquées dans l’activité, leur apport est différent pour chaque rôle.
Pour les développeurs et les ingénieurs
La bonne nouvelle : vous n’avez pas besoin de devenir un expert en sécurité2. Le Threat Modeling au niveau du développeur consiste à prendre l’habitude de se demander « ce qui pourrait mal tourner » avant d’écrire le code, et non après.
Dans la pratique, cela peut signifier
- Organiser une conversation structurée de 30 à 60 minutes au début d’une nouvelle fonctionnalité ou d’un changement important.
- Utiliser un cadre simple comme STRIDE ou celui des 4 questions pour guider et alimenter la discussion
- Saisir les menaces et les mesures d’atténuation convenues dans un modèle léger, lié au ticket ou à l’article concerné
- Signaler explicitement les risques non résolus plutôt que de les laisser implicites
Le résultat n’a pas besoin d’être un document formel. Il doit être trouvable, attribuable et honnête sur ce qui a été pris en compte et ce qui a été décidé.
Pour les responsables AppSec/Sécurité
Votre rôle passe de l’exécution du Threat Modeling à sa mise en œuvre à grande échelle. Dans le cadre des obligations du CRA, la question à laquelle vous devez répondre est la suivante : chaque équipe peut-elle, pour chaque fonctionnalité importante, produire un Threat Model qu’un régulateur pourrait examiner ?
Cela nécessite un processus standardisé dont l’exécution ne requiert pas d’expertise spécifique en matière de sécurité (modèles, listes de contrôle, guides de facilitation légers, matériel de formation), mais aussi de s’assurer que ce processus s’intègre bien dans les rituels de développement existants tels que les revues de conception, la planification des sprints, les comités d’examen de l’architecture, …
Pour vous, le Threat Modeling est un moyen de regrouper les menaces au sein des équipes afin d’identifier les risques systémiques et les schémas récurrents. le Threat Modeling offre également aux responsables AppSec quelque chose qui leur fait souvent défaut : un moyen structuré d’établir des priorités. Chaque menace n’appelle pas la même réponse. Une liste de problèmes de sécurité documentée et classée par ordre de risque est bien plus défendable et actionnable qu’une liste indifférenciée de constatations.
Pour les directeurs techniques et les RSSI
L’ARC crée une responsabilité personnelle pour les hauts dirigeants, ce qui n’était pas le cas des cadres précédents. La sécurité dès la conception est désormais une exigence de conformité des produits, avec des implications potentielles en termes d’accès au marché. Vous devez vous assurer que vous êtes sur la bonne voie en interrogeant vos équipes :
- Disposons-nous d’un processus documenté pour évaluer les risques de sécurité au moment de la conception ?
- Pouvons-nous prouver que nous avons identifié et traité les menaces pour notre dernière version majeure ?
- Notre évaluation des fournisseurs et des dépendances inclut-elle des critères de risque pour la sécurité ?
- Notre processus de Threat Modeling est-il intégré dans notre SDLC ou existe-t-il en tant qu’activité parallèle qui est négligée sous la pression du temps ?
Investir dans une capacité de Threat Modeling devient aujourd’hui un facteur de différenciation sur le marché, car les clients et les partenaires s’intéressent désormais à la position de leurs fournisseurs de logiciels en matière de sécurité. Pensez aux conséquences pratiques de l’impossibilité de démontrer la conformité lorsque l’équipe d’approvisionnement d’un client potentiel le demande.
Construire le pont de conformité : un chemin pratique
Si votre équipe est en train de démarrer, « Le Threat Modeling : Une porte vers une culture de développement sécurisée » présente le changement culturel et l’approche progressive. Cet article reprend là où il s’arrête.
Si votre équipe pratique déjà le Threat Modeling sous une forme ou une autre, même de manière informelle, le chemin vers une pratique conforme est plus court que vous ne le pensez. Il s’agit principalement de systématiser ce que vous faites déjà.
La pratique de la conformité est plus courte que vous ne le pensez. Il s’agit surtout de systématiser ce que vous faites déjà.
Le bilan
Le Threat Modeling a toujours été l’un des investissements les plus rentables qu’une équipe de développement puisse faire, c’est une pierre angulaire de l’état d’esprit « shift-left ». L’ARC et le NIS2 l’ont désormais rendue non optionnelle pour une grande partie du marché.
Les équipes qui traverseront cette transition le plus facilement sont celles qui ont intégré le Threat Modeling comme un élément à part entière de la manière dont elles conçoivent et construisent les logiciels. Il ne s’agit pas d’un exercice de conformité réalisé sous pression, mais d’une habitude qui a pour effet secondaire de produire de meilleurs logiciels.
Bonne nouvelle : vous n’avez pas besoin de prendre cette habitude tout seul. Des cadres existent et certains outils sont légers. L’expertise est également disponible.
Ce qu’il faut, c’est prendre la décision de commencer.