Modéliser les cyberattaques pour mieux se défendre : mode d'emploi

Comprendre les cybermenaces pour mieux les anticiper. Tel est le challenge que tente de relever les RSSI qui est cependant loin d'être une mince affaire tant on sait que la posture du cyberdéfenseur est beaucoup plus compliquée et complexe à tenir que celle du cyberattaquant. Pourtant, modéliser les menaces apparait comme un processus structuré permettant aux responsables IT et sécurité d'identifier leur potentiel en termes de surface d'attaque et de vulnérabilités, mesurer leur dangerosité et prioriser les techniques de contournement et ressources de protection à activer. La clé d'une modélisation des cybermenaces passe par son aspect systématique et structuré. Les personnes qui en sont chargées doivent suivre plusieurs étapes pour comprendre totalement l'environnement qu'ils essaient de sécuriser, identifier les vulnérabilités et les attaques potentielles.

Ceci étant dit, la modélisation des cybermenaces reste quelque part un art plus qu'une science, et il n'existe pas un seul processus canonique pour l'établir. Cette pratique s'inspire de diverses actions antérieures, notamment le concept des « arbres d'attaque » développés dans les années 1990. En 1999, les employés de Microsoft, Loren Kohnfelder et Praerit Garg, ont ainsi fait circuler dans l'entreprise un document intitulé « Les menaces pour nos produits » et résumé par « Stride », considéré par beaucoup comme la première description définitive de la modélisation des menaces. Il faut cependant garder en tête qu'il existe par ailleurs de nombreuses variétés de méthodologies et environnements de modélisation des menaces., leurs approches sont plus ou moins spécifiques et certaines sont centrées sur la sécurité applicative. Pour aider à y voir plus clair, voyons ce que ces méthodologies ont en commun, et les particularités techniques de certaines d'entre elles.

Processus et étapes de la modélisation des menaces

Chaque méthodologie de modélisation des menaces consiste à suivre une série d'étapes. Pour commencer on s'intéressera d'abord au point commun entre toutes ces méthodes, mis en avant par l'ingénieur logiciel Goran Aviani, qui est de répondre à ces quatre questions suivantes : sur quoi travaillons-nous ? Qu'est-ce qui ne va pas ? Que fait on par rapport à ça ? Avons-nous fait ce qu'il fallait ? Le processus de modélisation des menaces devrait impliquer de s'investir quatre étapes, chacune permettant de répondre aux différentes questions. A savoir : décomposition de l'application ou de l'infrastructure, déterminer les menaces, déterminer les contremesures et contournements, classer les menaces. Pour comprendre exactement ce qu'implique chacune de ces étapes, il est nécessaire considérer les techniques spécifiques qui sous-tendent la modélisation des menaces.

Sans doute que le terme le moins familier dans ces étapes est celui de la décomposition. Qu'es-ce que signifie de décomposer une application ou une infrastructure ? L'ingénieur logiciel Andrea Della Corte a expliqué que globalement, décomposer une application consiste à « comprendre l'application et sa façon d'interagir avec des entités externes ». Cela implique la création de cas d'usage pour comprendre comment l'application est utilisée, l'identification des points d'entrée pour voir où un attaquant potentiel pourrait interagir avec l'application, des actifs (c'est-à-dire les éléments / zones qui pourraient intéresser l'attaquant), ainsi que des niveaux de confiance, soit les droits d'accès que l'application accordera à des entités externes. Une des techniques pour décomposer une application est d'élaborer un diagramme de flux de données. Elles ont été développées dans les années 70 comme un moyen de représenter la façon dont les données peuvent évoluer dans une application ou un système, et où les données sont altérées ou stockées par des composants variés. Ce concept de « limite de confiance », illustre un aspect du flux de données devant être validées avant de pouvoir être utilisées par l'entité qui les reçoit. Souligné au début des années 2000, cette idée est essentielle pour utiliser un diagramme de flux de données pour la modélisation des menaces.

Des exemples de diagrammes de flux de données

Un premier exemple de diagramme illustre le flux de données au travers d'une application bancaire en ligne. Les lignes en pointillés représentent les limites de confiance où les données pourraient être potentiellement modifiées et les mesures de sécurité qui doivent être prises.

Diagramme de flux de données pour une application bancaire en ligne (crédit : Wei Zhang & Marco Morana / OWASP)

Ce document Microsoft remontant aux premiers instants du propre mouvement de modélisation des menaces effectué par la firme de Redmond explique plus en détail comment créer son propre diagramme de flux de données pour un système ou application. Parce que les diagrammes de flux de données ont été développés par des ingénieurs système plutôt que par des professionnels de la sécurité, ils incluent de nombreuses informations qui ne sont pas nécessaires à la modélisation des menaces. Une alternative à un diagramme de flux de données est un diagramme de flux de processus. Celles-ci sont similaires dans leur approche globale, mais plus rationalisées et axées sur la façon dont les utilisateurs et l'exécution de code se déroule dans un système, reflétant plus fidèlement la façon dont les attaquants pensent. ThreatModeler constitue à ce titre un bon début pour construire un diagramme par flux de processus.

Construire un arbre d'attaque est une technique de modélisation des menaces qui devient importante lorsque l'on atteint un stade où les menaces potentielles contre une application ou une infrastructure sont déterminées. Les arbres d'attaque ont été lancés par le légendaire Bruce Schneier de l'infosec à la fin des années 90. En quoi consistent-ils ? Une série de nœuds parents et enfants représentant différents événements, les nœuds enfants étant des conditions qui doivent être remplies pour que les nœuds parents soient vrais. Le nœud racine - parent le plus haut dans le diagramme - est l'objectif global de l'attaque. Avec ce type d'arbre d'attaque, les modélisateurs de menaces peuvent voir quel ensemble de circonstances doit être réuni pour qu'une menace soit couronnée de succès, comme c'est le cas dans le deuxième exemple ci-dessous.

Un arbre d'attaque simple illustrant les différentes manières dont un virus peut réussir à infecter un fichier. (crédit : Bluefoxicy / Creative Commons Licence)

Hackinthebox a une bonne présentation de construction d'arbres d'attaque du point de vue d'un attaquant, ce qui peut aider les entreprises dans leur quête de compréhension des menaces auxquelles elles sont confrontées. Les techniques pour déterminer les contre-mesures et classer les menaces varient plus largement en fonction du cadre ou de la méthodologie choisi, ce qui est précisément abordé plus en détail dans la section suivante.

7 environnements populaires de modélisation des menaces

La variété des approches structurées pour modéliser les menaces est habituellement constituée d'environnements et méthodologies (deux termes pouvant être facilement interchangeables dans ce contexte). Il en existe un grand nombre, dont les 7 plus populaires sont les suivants : Stride, Dread, Pasta, Vast, Trike, Octave et Nist.

1/ Stride. Comme évoqué plus haut, Stride est un peu la figure paternelle de la modélisation des menaces, développée pour la première fois chez Microsoft à la fin des années 90. Elle représente les six catégories de menaces, chacune violant une propriété spécifique des variations de la triade CIA : en termes d'usurpation d'identité ou usurpation de l'identité d'une autre personne ou d'un autre ordinateur violant l'authenticité, l'altération des données qui viole l'intégrité, la répudiation ou impossibilité de lier une action à effectuer violant la non-répudiabilité, la divulgation d'informations qui viole la confidentialité, le déni de service qui viole la disponibilité et l'elévation de privilège qui viole l'autorisation.

2/ Dread. Conçu comme un complément au modèle Stride qui permet aux modélisateurs de classer les menaces une fois qu'elles ont été identifiées, Dread pose six questions sur chaque menace potentielle en potentiel de dommages (quel est le montant des dommages si la vulnérabilité est exploitée), reproductibilité (est-il facile de reproduire l'attaque), exploitabilité (est-il facile de lancer une attaque), utilisateurs concernés (en pourcentage approximatif combien d'utilisateurs sont concernés) et découvrabilité (est-il facile de trouver la vulnérabilité). Chacune de ces questions est adressée avec une note comprise entre un et trois.

3/ Pasta. Signifiant Process for Attack Simulation and Threat Analysis, Pasta est un processus en sept étapes axé sur l'alignement des exigences de sécurité technique avec des objectifs commerciaux. Chaque étape est assez complexe, composée de plusieurs sous-étapes, mais la séquence globale est la suivante : définir des objectifs, définir la portée technique, la décomposition d'application, l'analyse des menaces, l'analyse des vulnérabilités et des faiblesses, la modélisation d'attaque et l'analyse des risques et des impacts.

4/ Vast pour Visual, Agile Threat Modeling. Ce modèle est à la base de ThreatModeler, une plateforme automatisée de modélisation des menaces qui fait la distinction entre les modèles de menaces applicatives et opérationnelles. Vast est spécialement conçu pour s'intégrer dans des workflows construits autour de la philosophie Devops.

5/ Trike est un cadre et un outil open source d'accompagnement pour la modélisation des menaces et l'évaluation des risques, qui opère d'un point de vue défensif plutôt que d'essayer d'imiter le processus de pensée d'un attaquant. Avec Trike, il est possible de modéliser le système que l'ont tente de défendre, en évaluant chaque composant à travers le point de vue de Crud qui a les capacités de créer, lire, mettre à jour ou supprimer cette entité. Les menaces sont identifiées en itérant à travers un diagramme de flux de données, chaque menace entrant dans seulement deux catégories : déni de service ou élévation de privilèges.

6/ Octave qui signifie Operationally Critical Threat, Asset, and Vulnerability Evaluation, est une méthodologie de modélisation des menaces développée à Carnegie Mellon University qui se concentre sur les risques organisationnels plutôt que technologiques. Il se compose de trois phases : création des profils de menace basés sur les actifs, identification de vulnérabilité de l'infrastructure et développement d'une stratégie et des plans de sécurité.

7/Nist. Le National Institute of Standards and Technology des États-Unis a sa propre méthodologie de modélisation des menaces centrée sur les données, qui comprend quatre étapes : identifier et caractériser le système et les données d'intérêt, identifier et sélectionner les vecteurs d'attaque à inclure dans le modèle, caractériser les contrôles de sécurité pour atténuer les vecteurs d'attaque et analyser le modèle de menace. Le projet du Nist comprend également un exemple détaillé de la manière dont cette méthodologie serait appliquée dans la pratique. Si l'on recherche un exemple de modélisation des menaces, c'est un excellent document à lire pour voir comment fonctionne le processus.

Meilleures pratiques de modélisation des menaces

Peu importe la méthodologie choisie, le plus important est de suivre quelques pratiques. Le plus important - bien que souvent difficile à suivre dans la réalité - est peut-être de faire de la modélisation des menaces une priorité lors du développement du système. Si cela est possible de le faire au début d'un projet, cela peut permettre d'épargner des désillusions plus tard, en intégrant la sécurité à une application ou un système. Une autre meilleure pratique consiste à ne pas afficher les applications et les systèmes isolément les uns des autres.

« Si les différents modèles de menaces sont connectés les uns aux autres de la même manière que les applications et les composants interagissent dans le cadre du système informatique, le résultat est une surface d'attaque complète que le RSSI peut utiliser pour comprendre l'ensemble du portefeuille de menaces à l'échelle de l'entreprise », explique Michael Santarcangelo, le fondateur de Secuirty Catalyst. Autant qu'à faire, il faut également éviter les erreurs courantes de modélisation des menaces. En synthèse, ne pas trop se concentrer sur les menaces qui font la une des journaux, ne pas oublier que les utilisateurs peuvent être parmi les plus grandes menaces par inadvertance, et surtout qu'un modèle de menace doit être un document évolutif se devant d'être constamment mis à jour.

Outils de modélisation des menaces

A noter que quelques-unes des méthodologies énumérées ci-dessus - Vast et Trike - sont en fait construites autour d'outils logiciels spécifiques. Les outils prennent également en charge d'autres méthodologies. Par exemple, Microsoft dispose d'un outil gratuit de modélisation des menaces et la Fondation OWASP propose des versions de bureau et d'applications Web de ses propres outils. Mais en vérité, la plupart des méthodologies décrites ici sont conceptuelles et ne sont liées à aucune implémentation logicielle. Les arbres d'attaque ou les diagrammes de flux de données peuvent être dessinés avec un stylo et du papier. Comme l'explique cette présentation de Luca Bongiorni, certains des outils les plus populaires pour la modélisation des menaces sont sur Microsoft Visio et Excel. Les obstacles à la mise en route de la modélisation des menaces pour votre infrastructure sont faibles et les récompenses sont élevées.