Il existe plusieurs méthodes de threat modeling. Le modèle le plus adapté aux besoins de votre organisation dépendra des types de menaces que vous essayez de modéliser et de l’objectif poursuivi. Toutes les méthodes ne sont pas complètes. Certaines sont abstraites, d’autres se concentrent sur les personnes, sur les risques ou les problèmes de confidentialité.
Cependant, elles peuvent être combinées pour créer une vision plus solide et plus complète des menaces potentielles auxquelles sont confrontés vos actifs informatiques. Dans cet article nous donnerons un aperçu sur 5 d’entres elles.
- Qu’est-ce que le threat modeling ?
- Pourquoi le threat modeling est-il important ?
- Quand faut-il commencer le threat modeling ?
- Quelles sont les ressources nécessaires ?
- Méthodes de threat modeling existantes
- Quelle méthode de threat modeling choisir pour votre organisation ?
- Outils de threat modeling
- Base de connaissances des menaces et des scénarios d’attaques
- Approche générale de threat modeling utilisée
- Comment le threat modeling peut-il impacter votre démarche GRC ?
Qu’est-ce que le threat modeling ?
Le threat modeling (parfois francisé en modélisation des menaces) est une activité initialement technique, limitée aux développements d’envergure, dans un contexte agile.
Depuis une dizaine d’années cette activité s’est développée au point de désormais faire partie des contrôles attendus pour respecter le standard de cybersécurité ISO 27002 en version 2022.
Cette activité, relativement simple, permet de placer la sécurité au début des projets, là où les changements sont les moins coûteux en ressources. C’est la première brique afin de poser le concept de security by design.
Pourquoi le threat modeling est-il important ?
L’objectif est de découvrir par une analyse simple les points structurels, en risque vis-à-vis de la sécurité de l’information, tant à la fois d’une architecture que d’un système comme une application développée.
Dans le cadre d’un nouveau déploiement, cette étude préalable permet de garantir qu’il n’y ait pas de points bloquants dans la mise en place de mesures de sécurité, comme la dépendance à des systèmes non sécurisés, à une authentification ou encore à des protocoles faibles.
Traditionnellement le threat modeling est surtout orienté développement applicatif. Néanmoins, il est également possible d’étendre l’étude vers des problématiques de disponibilité, comme par exemple avec des déploiements à l’échelle (e.g. redondance), des authentifications ou des mises-à-jour voire des problématiques de transferts transfrontaliers de données. Une approche pour des systèmes entiers peut être calquée sur celle des architectures applicatives sans aucune difficulté.
Quand faut-il commencer le threat modeling ?
La validation du design ou de l’architecture nécessite, là encore selon les bonnes pratiques, de définir en amont des critères de sécurité nécessaires.
Cette étude permet de valider non seulement que les critères génériques soient respectés, mais également les choix techniques déterminés dans cette phase de design/d’architecture.
Cette activité de sécurité peut donc être réalisée tout au long du projet. Néanmoins, elle doit être entreprise dans le meilleur des cas avant la validation du design ou de l’architecture considérée. De la sorte, les modifications à entreprendre si nécessaire sont les moins couteuses. Il est possible également de faire des modélisations intermédiaires ou partielles afin d’identifier les problèmes de sécurité au plus tôt et là encore de diminuer les coûts de conception.
Quelles sont les ressources nécessaires ?
Les ressources humaines nécessaires sont peu nombreuses mais peuvent être difficiles à trouver selon le contexte de l’entreprise.
Il est nécessaire d’avoir tout d’abord au moins une personne connaissant la structure à analyser (logiciel, infrastructure) et le déploiement sous-jacent.
Selon la méthode et l’outil choisi, il est nécessaire/indispensable d’avoir une personne connaissant les attaques de cybersécurité et apte à les transcrire, dans un contexte défensif, en mesures de protection.
Il est nécessaire d’avoir le responsable de l’élément analysé (application, infrastructure) et normalement le responsable de l’évolution de cet élément (e.g. SCRUM master) pour intégrer les remarques aux évolutions en cours.
Il est souhaitable que le responsable des risques assiste aux réunions pour identifier les risques techniques et ainsi de permettre de mieux estimer ceux-ci.
Pour des analyses plus larges, il est nécessaire d’avoir un responsable légal apte à maitriser les exigences légales dans les pays concernés.
Dans le cadre de certifications ISO 27001, il est nécessaire que le responsable du SMSI soit informé et encadre l’activité (e.g. planification, comptes-rendus, collecte des livrables, suivi des changements) afin de s’assurer que la démarche respecte les attentes du standard.
Quelques méthodes de threat modeling existantes
Différentes méthodes sont envisageables pour définir les risques, toutes avec avantages et inconvénients. En fonction des objectifs, de la maturité de l’entreprise dans l’exercice et des pratiques déjà en cours telle ou telle méthode doit être privilégiée.
Pour résumer les méthodes les plus pertinentes, une courte description suit.
Méthode de threat modeling n°1 : STRIDE
La méthodologie de référence par le passé était la méthode STRIDE :
- Spoofing,
- Tampering,
- Repudiation,
- Information disclosure,
- Denial of service,
- Elevation of privilege
Pour chacun des composants, il est nécessaire d’identifier les possibilités dans chacune des catégories qui forme l’acronyme. Afin d’avoir une exhaustivité des scénarios d’attaques, il est souhaitable de se confronter à une base de connaissances (Cf. chapitre ci-dessous).
Ces points représentent les techniques d’attaques utilisées pour atteindre la sécurité de l’information.
Cette méthode est largement connue et encore appliquée car facile à assimiler. Elle n’est cependant plus maintenue par Microsoft qui lui préfère DREAD.
Méthode de threat modeling n°2 : DREAD
Comme précédemment, les concepts étant élargis pour définir ce nouvel acronyme :
- Damage potential,
- Reproductibility,
- Exploitability,
- Affected users,
- Discoverability.
Bien que plus facile à comprendre pour tous, le scoring de chacune de ces catégories est d’avantage soumis à interprétation. Il faut aussi prendre en compte le dernier D qui promeut la sécurité par obscurité. Or cette pratique est au contraire très fortement déconseillée, induisant un faux sentiment de sécurité.
Cette méthode n’est pas aisée à promouvoir, à cause des biais suivants :
- D : Représente un impact. Pas de biais ici.
- R : Souvent cette valeur reste identique dans cette phase initiale. Elle ne permet pas de qualifier les différentes menaces
- E : Facilité d’exploitation. Pas de biais ici.
- A : Il est difficile de définir l’importance de chaque population d’utilisateurs les unes par rapport aux autres. La sécurité, de plus, doit être considérée dans son ensemble, car une vulnérabilité n’impacte qu’épisodiquement une population en particulier (à l’exception peut-être des administrateurs systèmes)
- D : Promeut la sécurité par l’obscurité, qui est un « faux ami ».
L’analyse porte donc principalement sur l’impact et l’exploitabilité, valeurs usuellement utilisées pour les risques : la méthode aide peu à identifier les menaces et vulnérabilités.
Méthode de threat modeling n°3 : Quantitative threat modeling
L’approche consiste à identifier la sévérité des vulnérabilités à partir des scores CVSS. Les menaces sont identifiées au moyen d’arbres d’attaques dont la racine est chacune des catégories de la méthode STRIDE (citée plus haut).
Les arbres d’attaques peuvent néanmoins être longs à établir et les scores CVSS ne prennent pas en compte le contexte de l’entreprise (et les éventuelles mesures en place qui en limiterait l’impact).
Cette méthode très technique est à considérer pour de petits développements/architecture très critiques, où les vulnérabilités auraient de forts impacts quel que soit le contexte.
Méthode de threat modeling n°4 : LINDDUN
Il est encore une fois fait usage d’un acronyme pour :
- Linkability,
- Identifiability,
- Nonrepudiation,
- Detectability,
- Disclosure of information,
- Unawareness,
- Noncompliance
Cette approche peut être intéressante pour identifier les écarts avec EU 2016/679 GDPR et le respect des concepts clés de « privacy by design » et « privacy by default » définis dans ce règlement.
L’évaluation de l’impact d’une vulnérabilité avec ces critères reste difficile. Cette méthode est davantage destinée à une analyse de compatibilité vis-à-vis de règlements sur la vie privée que sur une recherche de vulnérabilités techniques.
Méthode de threat modeling n°5 : PASTA
Cette méthode associe les objectifs business et les risques techniques au moyen d’un processus relativement logique.
Cette méthode est cependant peu répandue et longue à mettre en place. Le résultat est néanmoins complet et s’intègre aux autres activités métiers (e.g. opérations IT, évaluation des risques).
Source : Shevchenko, N. , 2018: Threat Modeling: 12 Available Methods. Carnegie Mellon University’s Software Engineering Institute Blog
Quelle méthode de threat modeling choisir pour votre organisation ?
La méthode utilisée dépend à la fois des objectifs de découverte et de l’intégration de l’activité au sein du projet (comme l’intégration à l’analyse de risques avec la méthode PASTA ou les besoins de conformité avec LINDDUN).
Bien que datée, la méthode STRIDE est facilement compréhensible et permet d’obtenir des résultats pertinents. Dans le cas où l’activité de threat modeling est nouvelle, elle permet au travers de ses résultats concrets d’assurer la pérennité de la démarche dans les processus projets, à l’avenir selon d’autres méthodes éventuellement.
Dans les contextes où l’activité est d’ores et déjà usuelle, une approche plus intégrée comme PASTA peut être recommandée en synergie avec le service de gestion des risques par exemple.
Outils de threat modeling
Bien que ces analyses n’imposent aucun outil, et qu’une simple feuille de papier pourrait suffire, des outils permettent de cadrer certaines des méthodes proposées ci-avant. Ils permettent le plus souvent d’obtenir un visuel clair et une liste des vulnérabilités et des menaces associées qui soit lisible par le plus grand nombre.
Outils automatisés
Il existe de nombreux outils. On peut identifier deux outils qui pourraient permettre de travailler avec des outils open-source ou gratuit :
- IsiusRisk platform
- MTMT (“Microsoft Threat Modeling Tool”). Il est possible de rajouter des menaces à celles existantes selon des bases de connaissances.
Outils manuels
Les approches manuelles nécessitent en revanche de se conformer à une base de connaissances et/ou des personnes qui maitrisent et donc justifie une prestation parfois externe afin d’avoir les profils souhaités.
Les outils open-source sont :
- OWASP Threat dragon
- Schématisation manuelle (en workshop) / approche whiteboard, au besoin avec des outils comme Microsoft VISIO
Base de connaissances des menaces et des scénarios d’attaques
Les attaques possibles sur chacun des systèmes peuvent être identifiées au moyen de la base de connaissance MITRE ATT&CK (https://attack.mitre.org/matrices/enterprise/).
Il existe également les taxonomies CAPEC (https://capec.mitre.org/data/index.html) et CWE (https://cwe.mitre.org/data/index.html) qui sont plus techniques et orientées par produit. Cela peut être utile pour un threat modeling détaillé sur un ou plusieurs systèmes clés qui n’évoluent pas souvent. Pour la plupart des systèmes cela peut être un peu trop laborieux et peu pérenne.
Il est néanmoins nécessaire d’effectuer un choix dans le niveau de détail souhaité afin de limiter l’étude dans le temps. Cet arbitrage dépend évidemment des ressources disponibles et de la criticité de l’élément analysé (selon qu’il s’agisse de l’infrastructure globale de l’entreprise ou d’un outil pour un service, outil non accessible depuis Internet).
Inputs envisageables
En entrée, les documents suivants peuvent être utiles à l’analyse :
- Diagrammes UML
- Diagrammes de déploiement
- Workshops avec les équipes techniques (surtout pour une action a posteriori)
- Data flow diagrams (DFD)
- Arbres d’attaques
- Lessons learned précédentes
Livrables envisageables
L’activité permet d’obtenir (selon la méthode employée et les objectifs de l’activité) :
- Liste des menaces
- Diagrammes de déploiement (utilisables pour des certifications)
- Data flow diagrams additionnels
- Diagrammes d’analyse des menaces
- Tableau de menaces (à intégrer à des SCRUMs et autres mesures projets)
- Compléments détaillés à l’analyse de risques
- Étude de conformité à GDPR
Approche générale de threat modeling utilisée
Les menaces sont identifiées selon la méthodologie utilisée selon les différents paradigmes (vulnérabilité/concepts d’attaques/privacy). Seule la méthode PASTA est plus complète, peut-être trop d’ailleurs dans de nombreux contextes.
Selon la méthode utilisée, l’impact est principalement sur la détection des menaces.
Exemples de diagrammes de flux de données
A partir de ces diagrammes, on identifie non seulement les frontières (ou « boundaries ») mais également les flux (potentiellement techniques i.e. avec les protocoles, le chiffrement etc. comme sur le troisième diagramme).
Ces diagrammes permettent aux développeurs et aux business analystes techniques d’avoir souvent une vision plus synthétique de leur produit. Cette visibilité est un des premiers atouts de la méthode.
Source : OWASP Application Threat Modeling
Source : OWASP Application Threat Modeling
Exemple de diagramme de déploiement technique
Pour commencer un diagramme mixte :
Source : Threat Modeling – Secodis GmbH
Source : OWASP Application Threat Modeling
Les flux peuvent être définis techniquement i.e. avec les protocoles, le chiffrement etc. comme sur le diagramme précédent.
Il y est également possible d’y faire figurer les frontières des pays (pour identifier les contraintes légales) et les contraintes réglementaires (e.g. PCI-DSS ou la FINMA sur le dernier schéma, s’il s’agissait de la Suisse).
Comment le threat modeling peut-il impacter votre démarche GRC ?
Cette activité peut être intégrée à une démarche GRC au niveau de l’accompagnement de la mise en place de mesures de sécurité, spécialement pour les équipes DevSecOps, mais également pour renforcer l’analyse de risques concernant les applicatifs et les infrastructures sur lesquelles ils sont déployés.
Cela peut également être pertinent dans le cas d’amélioration de la sécurité organisationnelle, en définissant par exemple des schémas de flux de données personnelles. Les processus sont rarement actualisés et peuvent au moyen de cette démarche être améliorés.
Il y a possibilité d’utiliser, en particulier PASTA, pour identifier les risques techniques, mais cette approche nécessite une certaine maturité des structures et une volonté d’implication importante.
Ces diagrammes, lisibles par tous, peuvent être utilisés pour avoir une approche commune entre les équipes.
Enfin cette activité est une réponse pour sécuriser l’architecture des systèmes attendue dans le standard ISO 27002 en version 2022.
