Soutenance mémoire
Cybersécurité
L’étude proposée dans cette section se focalise rapidement sur la modélisation et l’analyse du point de vue d’un attaquant. En effet, la cybersécurité est un domaine de recherche couvrant de nombreux aspects. Il semble important voire incontournable de se reposer sur un ensemble de vocables sémantiquement bien définis et partagés. Dans ce cadre, une initiative de l’Union Européenne propose d’aligner les terminologies, définitions et domaines de la cybersécurité dans une taxonomie cohérente [125]. Elle comprend 15 domaines, 15 secteurs d’applications et 23 axes technologiques, chacun de ces éléments étant composé d’une dizaine de sous-domaines. Dans ce manuscrit, nous nous focalisons sur le domaine de la modélisation et de l’analyse de la menace de système d’information dans une optique de sécurité. Dans une première section nous définissons donc les principaux termes de notre domaine d’étude. Dans une seconde section nous présentons les standards et les méthodologies permettant de modéliser les menaces d’un système. La troisième partie se focalise sur les approches permettant l’analyse des menaces d’un système. Pour finir nous présentons notre axes de recherche en terme de cybersécurité.
Présentation générale L’analyse et la modélisation de la menace interviennent tout le long du cycle de vie d’un système notamment pour la gestion des risques, l’élaboration d’exigences de sécurité, la conception sécurisée, la hiérarchisation de problèmes de sécurité, les tests de sécurité, la mise en production d’applications et la mise à jour d’applications. L’analyse de la menace est articulée selon plusieurs axes et à différents niveaux : antiterrorisme [8], processus [160], etc. Pour bien caractériser notre domaine d’étude nous définissons l’analyse de la menace, dans ce manuscrit, comme un processus dans lequel la connaissance des vulnérabilités et des informations internes et externes pertinentes pour une organisation particulière sont comparées aux cyberattaques du monde réel. [160] L’analyse de la menace a pour but d’évaluer des menaces et de renforcer la sécurité d’un système, elle peut se décomposer en quatre étapes distinctes :
— Acquisition de connaissances : cette étape de capture d’informations permet de définir ce qui fait ou non partie du système analysé.
— Mise en relation d’informations : les informations concernant un système sont associées et comparées à des bases de données afin d’identifier les vulnérabilités de ce système.
— Analyse de donnée : les informations collectées sont testées en vue de déterminer le niveau d’exposition du système.
— Mise en œuvre de solution : cette étape vise à proposer des mesures de sécurité visant à atténuer ou anticiper l’émergence de cyberattaque sur le système.
L’acquisition de connaissances est une étape de haut niveau de technicité pour laquelle il existe de nombreux outils dédiés (Nessus, SAINT, NeXpose, Qualys Scanner, Nikto, OpenVAS, Retina, NMap, etc.). Par ailleurs la mise en œuvre de solutions dépend principalement du système attaqué et de la politique de sécurité appliquée. La corrélation ou la mise en relation des informations est une étape critique et importante, de même que l’analyse de ces informations restructurées. C’est pourquoi, nous nous focaliserons dans ce manuscrit sur les étapes de mise en relation et d’analyse. La modélisation de la menace intervient lors de ces deux étapes, UcedaVelez and Morana [160] définissent la modélisation de la menace comme « un processus stratégique visant à examiner les scénarios d’attaque et les vulnérabilités possibles dans un environnement d’application proposé ou existant dans le but d’identifier clairement les niveaux de risque et d’impact » . Ce processus peut être abordé selon divers méthodologies, STRIDE, DREAD, PASTA [160]. La méthodologie STRIDE proposée par Microsoft est la plus répandue [164], elle permet de simplifier la compréhension des menaces de sécurité d’un système. STRIDE n’est pas une méthodologie applicative car elle ne définit pas le processus dans lequel le modèle de menace doit être implanté, suivi et livré. Elle permet cependant d’organiser les menaces de sécurité contre un système en les classant dans les six domaines suivants : usurpation d’identité, falsification, répudiation, divulgation d’informations, déni de service et élévation de privilège. La cybersécurité et en particulier l’analyse et la modélisation de la menace, se focalise sur un ensemble de propriétés de sécurité définies dans la norme ISO-27000 [9]. Cette norme liste les 6 propriétés de sécurité suivantes :
— Confidentialité : propriété selon laquelle l’information n’est pas diffusée ni divulguée à des personnes, des entités ou des processus non autorisés.
— Intégrité : propriété d’exactitude et de complétude.
— Disponibilité : propriété d’être accessible et utilisable à la demande par une entité autorisée.
— Authenticité : propriété selon laquelle une entité est ce qu’elle revendique être.
— Non-répudiation : capacité à prouver l’occurrence d’un événement ou d’une action donnée et des entités qui en sont à l’origine.
— Fiabilité : propriété relative à un comportement et à des résultats prévus et cohérents. Kordy et al. [97] recensent 31 approches de modélisation de la menace utilisant pour la plupart le standard STRIDE et la terminologie ISO-27000 comme référence. Parmi les approches étudiées, plus de la moitié se focalisent sur le point de vue de l’attaquant, ce choix permet de centrer la modélisation sur la perception que l’attaquant a du système. Nous retenons de cette présentation générale qu’il existe un foisonnement important des approches, des outils et des langages de modélisation et d’analyse de la menace. Ce foisonnement est pris en compte dans les travaux présentés dans ce manuscrit.
Modélisation d’un attaquant et des vulnérabilités d’un système La modélisation et l’analyse de la menace appliquées au point de vue d’un attaquant se répartissent comme suit : la description de l’attaquant et de ses interactions possibles avec le système, et la modélisation du comportement de l’attaquant lors d’une attaque. La première partie est abordée dans la section 2.1.2 et la seconde dans la section 2.1.3. Le standard ISO-27000 [9] définit une vulnérabilité comme une « faille dans un actif ou dans une mesure de sécurité qui peut être exploitée par une ou plusieurs menaces ». Les actions possibles pour un attaquant sont alors, en plus de celles permises par le système, l’exploitation de vulnérabilités. Dans [159] les auteurs déplorent un manque de standard pour la catégorisation de vulnérabilité et donnent un ensemble de lignes directrices permettant la création de taxonomie plus efficaces. Les auteurs préconisent de baser les taxonomies sur des standards tel que CVSS [3] et soulignent l’importance de la prise en charge de nouvelles vulnérabilités. Pour ce faire, ils privilégient les approches directement connectées au dictionnaire CVE [1], ce dernier regroupe un grand nombre de vulnérabilités et est mis à jour régulièrement. En 2018, une enquête est réalisée couvrant la littérature associée aux modèles de sécurités [164]. L’enquête montre que les standards de sécurités les plus utilisés sont STRIDE, CVSS et CVE. De plus, elle souligne que parmi l’ensemble des propriétés de sécurité, seules la confidentialité, l’intégrité et la disponibilité sont couramment utilisées. Les observations réalisées lors de cette enquête concordent alors avec les préconisations proposées dans [159], pour être efficace une taxonomie doit se baser sur des outils et des propriétés standardisées. Dans cette section, nous présenterons tout d’abord les standards utilisés pour la création de taxonomie de sécurité, puis nous nous focaliserons sur les taxonomies de vulnérabilité et les taxonomies d’attaquant.
Les standards : NVD, CWE, CVE et CVSS
NVD (National Vulnerability Database) [6] est une base de données de vulnérabilité gérée par l’institut états-unien des normes et de la technologie. Elle répertorie plus de 145 000 vulnérabilités nommées d’après la nomenclature CVE. La base de données spécifie les informations sous les titres : identifiant, date de sortie d’origine, date de dernière révision, source, description, score CVSS détaillé, références, type et logiciel vulnérable. NVD associe également une faiblesse aux vulnérabilités répertoriées en référençant le schéma de classification CWE. CVSS (Common Vulnerability Scoring System) [3] est un système de métriques permettant de calculer un score entre 0 et 10 évaluant la dangerosité d’une vulnérabilité, 10 signifiant que la vulnérabilité est critique et 0 signifiant qu’elle est anodine. CVSS permet également de créer un vecteur présentant les caractéristiques de la vulnérabilité évaluée. Les mesures CVSS sont divisées en trois groupes : celles de base mesurent les caractéristiques intrinsèques et fondamentales d’une vulnérabilité, elles ne changent ni dans le temps et ni selon l’environnement. Les métriques temporelles mesurent les attributs qui changent dans le temps mais qui restent indépendantes de l’environnement. Les mesures environnementales mesurent les caractéristiques pertinentes et uniques à un environnement particulier. CWE (Common Weakness Enumeration) [4] est une liste hiérarchique des faiblesses de sécurité des logiciels et du matériel. La structuration hiérarchique permet la définition de plusieurs niveaux d’abstraction, nommés du plus général au plus spécifique : pilier, classe, base et variante. CWE propose également de regrouper les faiblesses selon différentes vues. Par exemple la vue CWE-1003, utilisée par NVD, liste les faiblesses les plus courantes (124 éléments). CVE (Common Vulnerabilities and Exposures) [1] est un dictionnaire énumérant les vulnérabilités de cybersécurité connues du public. Chaque CVE contient un numéro d’identification, une description et au moins une référence publique. L’identification s’effectue suivant le schéma CVE-AAAA-XXXX, avec AAAA l’année où la vulnérabilité a été rendue publique et XXXX est un nombre aléatoire. Le standard CVE propose également de regrouper les vulnérabilités selon différents types dérivés de CWE, [2] classe l’ensemble des entrées CVE de 1999 à 2019 selon 13 types de vulnérabilité :
— Dénis de service (DoS).
— Exécution de code (Code Execution).
— Débordement de tampon (Overflow).
— Corruption de mémoire (Memory Corruption).
— Injection SQL (Sql Injection).
— Script intersite (XSS).
— Traversement de répertoires (Directory Traversal).
— Fractionnement de réponses HTTP (Http Response Splitting).
— Contournement (Bypass something).
— Obtention d’informations (Gain Information).
— Obtention de privilège (Gain Privileges).
— Contrefaçon de demande intersite (CSRF).
— Inclusion de fichier (File Inclusion) .
Cette section présente une partie des nombreux standards utilisés en cybersécurité. Nous verrons dans la suite de ce manuscrit qu’il est nécessaire de manipuler plusieurs de ces standards afin de construire le point de vue d’un attaquant.
Les taxonomies de vulnérabilité
La cybersécurité couvre de nombreux domaines et les acteurs de ces domaines utilisent la notion de vulnérabilité à différents niveaux d’abstraction. Ce constat explique en partie pourquoi, à l’heure actuelle, il n’existe pas de taxonomie de vulnérabilité adoptée comme standard, au contraire, il en existe plusieurs centaines construites spécifiquement pour couvrir un domaine particulier [163]. Il est possible de regrouper l’ensemble des taxonomies existantes en deux grandes catégories, celle s’appuyant sur des standards et les autres. Dans cette seconde catégorie, on retrouve les propositions les plus spécifiques telles que [72] qui présentent une taxonomie en quatre dimensions se focalisant sur le type de cible. Les auteurs décrivent une cible en différenciant les aspects matériels (disque, périphérique, etc.) et logiciels (système d’exploitation, application, services), chaque aspect étant décrit sur six niveaux d’abstraction. De même, Yongzheng and Xiaochun [168] proposent une taxonomie focalisée sur l’élévation de privilège, une vulnérabilité devenant alors uniquement un moyen d’obtenir de nouveaux droits et accès. Ce type d’approche permet de définir une taxonomie à la fois fournie et simple d’utilisation, cependant elle reste très restrictive et spécialisée à un seul type d’analyse. Les taxonomies basées sur les standards proposent des approches plus généralistes. Par exemple, Singh et al. présentent dans [149] et [148] un cadre estimant un niveau de risque à partir d’une fréquence d’exploitation. Les auteurs calculent cette fréquence à partir des données de base et temporelles de CVSS et de la maturité d’une vulnérabilité, déterminées à partir des informations fournies par NVD. Dans cet exemple, les auteurs regroupent des informations provenant de deux standards distincts afin de calculer une nouvelle métrique, ici une fréquence. On retrouve cette approche dans [60], les auteurs font également la distinction entre système d’exploitation et application/service. Leur taxonomie comprend en plus les champs : causes de la vulnérabilité, techniques d’attaques exploitées et niveaux de menace. Ces trois champs sont dérivés des informations textuelles contenues dans les descriptions CVE de la vulnérabilité et de sa note CVSS. Par ailleurs, certaines recherches proposent d’améliorer un standard existant, par exemple Chen et al. [37] proposent un cadre de catégorisation qui transforme le dictionnaire CVE en un classificateur qui catégorise les CVE et qui évalue les tendances générales d’évolution des vulnérabilités. Pour construire leur classificateur, les auteurs ont étudié plus de 20 000 descriptions de vulnérabilités via des algorithmes de machine learning, et ont identifié 11 causes, 11 impacts, 15 types de services vulnérables et 5 niveaux de sévérités. Ce type d’approche propose de déduire de nouvelles informations à partir de l’interconnexion de données provenant de différents standards. Finalement, les taxonomies de vulnérabilité proposent, soit des métriques spécialisées à un domaine et définies manuellement, soit de nouvelles métriques construites grâce à l’association de données provenant de différents standards. Dans l’objectif d’obtenir une taxonomie la plus générique possible, nous pouvons identifier que, au minimum, il faudrait prendre en compte le type, les causes et les impacts des vulnérabilités.
Les taxonomies d’attaquants
Dans la littérature un attaquants est catégorisé, selon ses capacités [80], ses objectifs [160] ou encore un ensemble de caractéristiques. Il existe un grand nombre de solutions permettant de décrire un attaquant, tels que :
— Un niveau global : l’utilisation d’un niveau global permet de définir des attaquants plus ou moins compétents. Cette approche est utilisée, par exemple, dans le standard CVSS [3] avec la création, pour chaque vulnérabilité, d’une complexité d’attaque. Cette complexité représente le niveau de compétences nécessaires à un attaquant afin d’exploiter la vulnérabilité. Elle est évaluée selon trois niveaux : haut, moyen et bas. Par ailleurs, Paulauskas and Garsva [134] définissent un critère de temps moyen de compromission, calculé à partir des informations de NVD sur un ensemble de vulnérabilités et des caractéristiques d’un attaquant hypothétique. Les auteurs proposent de déterminer ce critère en se basant sur une distribution normale du niveau de compétence dans un groupe d’attaquant.
— La création de types d’attaquants : un attaquant est alors représenté par un ou plusieurs types. L’approche STIX [7] définit cinq types d’attaquants : innovateur, expert, praticien, novice et aspirant. Chaque type d’attaquants décrit un ensemble de capacités et d’aptitudes.
— La création de profils d’attaquants : un profil d’attaquants décrit l’ensemble des techniques et des outils utilisés par l’attaquant. Le concept de profil d’attaquants a été initialement proposé dans le projet « Know Your Enemies » [150]. Lenin et al. [110] construisent des profils d’attaquants en fonction d’un budget, de compétences et de temps alloué à l’attaque.
— La création d’un persona d’attaquants : un persona d’attaquants définit un ensemble d’objectifs, de motivations, d’attitudes et de compétences. Faily and Fléchais [54] utilisent ce concept afin identifier des menaces sur un système.
— La définition d’attributs d’attaquants : un attaquant est alors défini via un ensemble d’attributs qui peuvent être de différents types : booléen, numérique, etc. Heckman [75] proposent cinq variables (niveaux de compétence, ressources, intentions, motivations et probabilités) variant de 1 à 10, utilisées pour définir 9 types d’attaquants. Fraunholz et al. [59] proposent quatre attributs permettant de décrire un attaquant. Ces attributs sont : ressources, compétences, intentions et motivations. Les auteurs comparent également 15 approches de description d’attaquants et définissent une correspondance entre la notion de types et celle d’attributs, montrant alors qu’il est possible de passer d’une approche à l’autre. Finalement, une taxonomie d’attaquants prend en compte trois types de critères : ce qu’un attaquant sait faire (capacités, compétences, aptitudes, etc.), ce qu’il veut faire (objectifs, intentions, motivations, etc.) et ce qu’il peut faire (ressources, budget, temps, accès, droits, etc.). Tout comme les taxonomies de vulnérabilité, les informations sont en majorité dérivées des standards, seules les plus spécifiques à un domaine sont définies manuellement. Les travaux [73, 84, 91] comparent tous un grand nombre de taxonomies de vulnérabilité et d’attaquants. Chacun de ces travaux propose une liste de critères permettant de correctement définir une taxonomie. Les critères communs aux différentes études sont : simplicité, réutilisabilité, conformité avec les standards et flexibilité. Il est à noter que la création d’une taxonomie est un problème difficile de caractérisation et d’identification de concepts. De nos jours, il n’existe pas de définition globalement acceptée et la convergence des différentes définitions sera longue voire impossible car trop de préoccupations sont à prendre en compte. A notre sens, les définitions utilisées doivent être à la fois génériques et reposées sur une approche souple et ouverte afin d’intégrer les spécialisations nécessaires. Dans ce but nous présentons dans le chapitre 3 une approche permettant de décrire un attaquant et les vulnérabilités d’un système de manière flexible, simple, réutilisable et basée sur l’interconnexion de différents standards.
Analyses du comportement d’un attaquant L’objectif des analyses de menaces, centrées sur le point de vue d’un attaquant, est d’anticiper le comportement de l’attaquant lors d’une attaque. De nombreux modèles graphiques de sécurité permettent de représenter ce comportement, Lallie et al. [107] en présentent 16, regroupés en deux grands groupes : les arbres d’attaque et les graphes d’attaque. Un arbre d’attaque [120] est un diagramme conceptuel des menaces d’un système et des attaques possibles pour atteindre ces menaces. Il est utilisé pour identifier différents chemins conduisant à un objectif prédéfini et pour construire une arborescence qui décrit comment une vulnérabilité aide un attaquant à atteindre son objectif. Un graphe d’attaque [135] représente une vue détaillée de la sécurité d’un système, il permet de déterminer si un attaquant peut atteindre des états finaux à partir d’un état initial. Il est composé de nœuds et de relations, les nœuds représentent des états et les relations font référence à des transitions entre différents états. Les travaux [97, 81, 107] énumèrent et caractérisent l’ensemble des modèles graphiques de sécurité. Ils soulignent particulièrement la diversité des analyses permises par les arbres d’attaque. LeMay et al. [109] proposent de générer et d’analyser des arbres d’attaque via l’approche ADVISE permettant d’imiter la façon dont un attaquant sélectionne sa prochaine étape d’attaque. Les auteurs proposent un modèle exécutable représentant le comportement de l’attaquant, ce modèle est construit à partir d’un profil d’adversaire et d’un graphe d’exécution des attaques. Un graphe d’exécution des attaques est créé par un expert en sécurité, il est composé de :
— Un ensemble d’étapes d’attaque : chaque étape représente un objectif ou une progression vers un objectif modifiant les accès ou les connaissances qu’a un profil adversaire. Une étape d’attaque comporte une pré-condition, une durée, un coût, une probabilité de succès, une probabilité de détection et une post-condition.
— Un ensemble d’accès : il permet de modéliser les accès de l’attaquant sur l’ensemble des constituants du système.
— Un ensemble d’élément connus : il modélise ce que l’attaquant connaît du système à un instant donné.
— Un ensemble de compétences pertinentes pour attaquer le système.
— Un ensemble d’objectifs pertinents pour un attaquant.
Un profil d’adversaire est composé de :
— Une situation initiale, représentant les droits et accès de l’attaquant avant l’attaque.
— Une fonction décrivant les compétences de l’attaquant. A chaque compétence pertinente pour attaquer le système est associé un booléen signifiant si l’attaquant maîtrise ou non la compétence.
— Une fonction de valeur d’objectif permettant d’associer à chaque objectif une valeur que lui attribue l’attaquant.
— Un ensemble d’attributs modélisant les préférences de l’attaquant en terme de coût, gain et chance d’être détecté. Ces attributs permettent de spécifier l’attaquant, par exemple un attaquant voulant être discret privilégiera une faible chance d’être détecté au détriment des gains et coûts éventuels.
— Une variable d’ »horizon », elle représente la profondeur de l’arbre de prédiction utilisé pour sélectionner l’étape d’attaque.
L’approche ADVISE [109] permet de simuler pas à pas le comportement d’un attaquant en fonction de son profil et du graphe d’exécution des attaques associés au système. Jajodia et al. [87] proposent une approche d’analyse de vulnérabilité sur un réseau nommé TVA (Topological Vulnerability Analysis). Leurs propositions reposent sur l’utilisation de Nessus, un outil de découverte de réseau et de détection de vulnérabilité. Les auteurs décrivent une vulnérabilité comme un tuple contenant une pré-condition et une post-condition représentant respectivement les conditions nécessaires à l’exécution d’une vulnérabilité et les effets de cette dernière sur le système. L’outil proposé s’articule autour de 3 composants :
— Une base de connaissance de vulnérabilité : définie manuellement, elle contient l’ensemble des vulnérabilités prisent en compte et décrites via des pré-conditions et de post-conditions.
— Une description réseau du système étudié : les auteurs utilisent directement les informations issues de Nessus afin de modéliser un réseau.
— Une spécification du scénario d’attaque : le scénario d’attaque définit la cible de l’attaque ainsi que la configuration du système et une situation initiale.
L’utilisation de ses trois composants permet aux auteurs de générer des chemins d’attaque. Certaines approches proposent d’aller plus en profondeur dans l’analyse en proposant des solutions de vérification de modèle (model checking). Les auteurs de [144] s’appuient sur les techniques d’analyse formelle pour générer et analyser automatiquement un arbre d’attaque. Cependant des travaux [11, 132, 62] mettent en avant les limites de l’utilisation de la vérification de modèle, en particulier lors du passage à l’échelle pour des systèmes complexes. Diverses techniques sont alors proposées, utilisant des optimisations graphiques [132] ou encore de l’intelligence artificielle [62]. En plus des analyses effectuées durant la construction d’un arbre d’attaque, il est possible d’effectuer des analyses sur un arbre préexistant. Cela nécessite d’enrichir l’arbre d’attaque avec de nouvelles métriques de sécurité. Ces dernières peuvent représenter un coût, un profit, une chance de détection, une chance de réussite, une complexité, etc. La souplesse apportée par les arbres d’attaque permet de réutiliser un même arbre afin de mener différentes analyses. Par exemple, dans [111] les auteurs évaluent le temps moyen de compromission d’un système à partir d’un arbre d’attaque, ce temps est réutilisé dans [134] afin de calculer la dangerosité d’un type d’attaquant pour un système. Finalement, la généricité apportée par les arbres d’attaque permet une grande diversité des analyses et une réutilisabilité des résultats. L’approche proposée dans [109] dissocie le système de l’attaquant. Cette séparation permet de réutiliser la modélisation d’un attaquant sur différents systèmes et d’étudier la sécurité d’un même système par rapport à diverses stratégies d’attaque. Cependant l’approche ADVISE [109] se concentre sur des systèmes statiques et ne modélise pas le cycle de vie de ce dernier, de plus la création du graphe d’exécution nécessite l’intervention d’un expert à la fois du système modélisé et de l’approche ADVISE. Dans le chapitre 4 nous présentons une approche gardant la flexibilité et la richesse des approches existantes et qui prend en compte le cycle de vie du système et l’existence de nombreuses solutions d’analyse basés sur l’étude d’arbre d’attaque.
Axes de recherche : Modélisation et analyse du point de vue de l’attaquant Parmi l’ensemble des domaines de la cybersécurité, nous avons couvert, dans cette section, les premières phases de l’analyse de la menace. En conséquence, notre état de l’art s’est focalisé sur la modélisation et l’analyse du point de vue d’un attaquant. Cet état de l’art fait ressortir notamment, à notre sens, les problématiques suivantes :
— Deux grandes étapes de modélisation sont principalement utilisées, 1 la mise en commun d’informations provenant de standards et 2 la modélisation manuelle d’informations spécifiques au contexte. Bien qu’un grand nombre de solutions reposent sur l’utilisation de standards ou proposent une modélisation spécifique à un domaine, peu d’entre elles permettent d’effectuer les deux à la fois pour obtenir une modélisation holistique du point de vue d’un attaquant.
— Cette modélisation holistique nécessite une mise en relation d’informations et par conséquent une interopérabilité de différents formalismes issus des différents outils [10]. L’interopérabilité des modèles reste un sujet à part entière et c’est pourquoi nous discutons de cette problématique dans la section suivante de l’état de l’art (§2.2). De plus, nous présentons en section 2.4 la modélisation par rôle comme une solution d’interopérabilité non intrusive et adaptative.
— L’analyse du point de vue de l’attaquant nécessite des approches de simulation ou/et de vérification de modèle. Elle requiert, en plus des modèles du système, des vulnérabilités et de l’attaquant, la prise en compte du comportement du système et des objectifs de l’attaquant. Cette étape permet de générer 3 un ensemble d’informations hétérogènes tel que des arbres ou des graphes d’attaques. Ces informations peuvent être utilisées afin d’effectuer des analyses de sécurité approfondies utilisant des métriques spécifiques telles qu’une analyse de coût. Cependant, nous pouvons noter que dans la littérature la génération d’arbre d’attaque s’effectue généralement sans prendre en compte ni le comportement, ni l’évolution du système.
— La prise en compte des modifications apportées au système requiert une approche de construction de point de vue flexible et offrant des relations bidirectionnelles entre les points de vue et les modèles originels. Ce problème est abordé dans la section 2.3 avec la modélisation de point de vue et il est détaillé dans la section 2.4 via la modélisation par rôle, étudiée pour ses qualités d’abstraction et de flexibilité. Ce manuscrit porte sur la modélisation de point de vue dans un contexte en évolution permanente, à savoir la modélisation et l’analyse de menaces. Pour se faire, nous présentons dans la suite de ce chapitre les problématiques de modélisation se rapportant à notre contexte.
Les rôles pour la dynamicité
Différentes études [153, 14, 69, 112] ont souligné les lacunes des langages de modélisation conceptuels classiques, tels que le modèle Entité-Relation, lorsqu’ils sont utilisés pour modéliser des systèmes dynamiques. Le concept de rôle est depuis ses débuts [113] lié avec la notion de dynamicité, un élément peut, au cours de son existence, s’associer et se dissocier d’un rôle dynamiquement. Par exemple, dans [66], les auteurs utilisent les rôles pour modéliser des aspects et soulignent que le concept de rôle fournit de nouvelles propriétés aux aspects, en particulier en termes de dynamicité. La notion de dynamicité des rôles se retrouve dans l’ensemble de la recherche les classifiant [95, 98, 12, 94, 154, 33, 67, 103]. Tamai et al. [158] utilisent les rôles pour capturer la dépendance d’un objet à un environnement qui évolue. Un objet peut se déplacer dans son environnement, l’environnement lui-même peut être amené à changer au cours du temps et un objet peut appartenir à plusieurs environnements à la fois. Pour résoudre cette dépendance, les auteurs de[158] présentent Epsilon, une approche permettant de décrire finement la séparation des préoccupations qui supporte l’adaptation et la réutilisation de code. D’autres recherches traitent du changement dynamique d’objets en utilisant le concept de rôles, par exemple pour capturer le cycle de vie d’un objet dans une base de données [65] ou encore pour la construction de cadre permettant la documentation et la compréhension de code source [139]. Cette notion de dynamicité d’un rôle se retrouve dans [71], les auteurs comparent ici le concept de rôle et celui d’aspect. Une de leurs conclusions est que les rôles sont à privilégier pour représenter des vues dynamiques. Nous avons trouvé dans la littérature seulement deux exemples d’utilisation des rôles de manière purement statique [38, 18]. Dans [38] les auteurs cherchent à exhiber les qualités des rôles en dehors de l’aspect dynamique en particulier pour matérialiser des dépenses. A notre connaissance, JavaStage [18] est la seule implantation utilisant uniquement l’aspect statique des rôles, l’objectif des auteurs de [38] et de [18] est de prouver que le concept de rôle a un intérêt autre que la prise en compte de la dynamicité d’un système. Finalement la notion de dynamicité est centrale au concept de rôle, elle permet d’adapter un modèle de rôles aux évolutions du système et de son environnement. Un player peut alors, au cours de son cycle de vie, jouer différents rôles et s’en dissocier en fonction de l’évolution du système. L’aspect dynamique des rôles sera abordé dans les chapitres 4 et 5 afin d’adapter la perception d’un attaquant et de simuler son comportement lors d’une attaque.
Un système fil rouge : Alice et Bob
Dans cette section, nous présentons un système , nommé « système fil rouge », servant d’exemple dans les sections 3.3 et 3.4. Il est constitué d’un réseau de trois machines, d’un attaquant et d’internet. Les machines sont des ordinateurs utilisant un système d’exploitation et des applications dont la description est la suivante :
— Systèmes d’exploitation :
— Ubuntu Xenial Xerus : Ubuntu est un système d’exploitation libre pour ordinateur et serveur utilisant un noyau Linux. Xenial Xerus de Ubuntu est le nom donné à la version Ubuntu 16.04 LTS sortie le 21 avril 2016. Dans cette exemple, Ubuntu 16.04 LTS utilise la version 4.4.8 du noyau Linux, sortie le 20 avril 2016.
— Windows 10 Redstone 1 : Windows 10 est un système d’exploitation développé par Microsoft. La version Redstone 1 est le nom donné à la version Windows 101607 sortie le 02 août 2016.
— Applications :
— WordPress Coleman Hawkins V7 : WordPress est un système de gestion de contenu gratuit, libre et open-source permettant de créer et gérer différents types de sites Web. La version Coleman Hawkins V7 de WordPress est le nom donné à la version numérotée WordPress 4.5.7 sortie le 6 Mars 2017.
— Symposium 14.10.3 : Symposium est une extension de WordPress permettant la création d’un réseau social. La version 14.10.3 de Symposium a été publiée le 17 octobre 2014.
— Contact Form 7 to Database 2.10.32 : Contact Form 7 to Database est une extension de WordPress permettant la sauvegarde de contact dans une base de données. La version 2.10.32 de Contact Form 7 to Database a été publiée le 23 février 2017. Les systèmes d’exploitation et les applications présentés ici contiennent des vulnérabilités qui seront modélisées dans la section 3.3.2. Les trois machines constituant le système sont :
— Alice : Alice est un serveur web sur lequel figurent des informations sensibles. Alice utilise le système d’exploitation Windows 10 Redstone 1 et une version de WordPress Coleman Hawkins V7 utilisant l’extension Contact Form 7 to Database 2.10.32. Alice est connectée avec Bob.
— Bob : Bob est un serveur web contenant le système d’exploitation Ubuntu Xenial Xerus. Bob utilise les mêmes applications qu’Alice, plus l’extension Symposium 14.10.3. Bob est connecté avec Alice et Carol.
— Carol : Carol est un serveur web et possède le même système d’exploitation et les mêmes applications que Bob. Dans notre exemple, cette machine sera considérée comme éteinte tout au long de l’attaque. Carol est connectée avec Bob.Dans cet exemple l’attaquant sera appelé Mallory. Mallory veut accéder aux informations sensibles que détient Alice. Pour ce faire, il déroule un scénario d’attaque en quatre étapes numérotées de e0 à e3. Ces étapes sont :
e0| Situation initiale : Mallory sait qu’Alice est dans le système fil rouge mais n’a aucune autre information sur cette dernière.
e1| Connexion au système : Mallory communique, via internet, avec le système et découvre les machines d’Alice et de Bob. Cette étape peut être découpée en sous-étapes :
e1.1| Découverte du système : Mallory établit une connexion avec les machines d’Alice et de Bob.
e1.2| Exploration du système : Mallory tente d’obtenir des informations sur Alice et Bob. Il découvre alors une partie des applications présentes sur ces machines.
e2| Prise de contrôle : Mallory tente de prendre le contrôle d’Alice et de Bob. Il réussit à prendre le contrôle de Bob. Cette étape peut être découpée en sous-étapes :
e2.1| Entrée dans le système : Mallory obtient, via l’exploitation d’une vulnérabilité, un accès limité à Bob. Cela lui permet d’en apprendre plus sur la configuration de ce dernier.
e2.2| Élévation de privilège : Mallory, tirant partie de ses nouvelles connaissances et accès, exploite une vulnérabilité lui permettant de prendre le contrôle de Bob.
e3| Récupération d’informations : Mallory, via Bob et grâce à l’exploitation d’une vulnérabilité, subtilise les informations détenues par Alice. Cette étape peut être découpée en sous-étapes :
e3.1| Pivotage et découverte du réseau : Mallory utilise la machine Bob afin de scanner le réseau du système fil rouge. Il découvre alors que Bob est connecté à Alice. Lors de cette étape, l’attaquant ne découvre pas la connection entre Bob et Carol car Carol n’est pas allumée.
e3.2| Exploration du réseau : Mallory, via la machine Bob, apprend quel est le système d’exploitation utilisé par Alice.
e3.3| Collecte de données : Mallory utilise une vulnérabilité afin de récupérer les informations détenues par Alice.
Le système fil rouge consiste donc en un réseau de trois machines sur lesquelles s’exécutent divers systèmes d’exploitation et applications vulnérables. Ce réseau est attaqué par un attaquant ayant pour objectif de récupérer des informations sur la machine nommé Alice.
|
Table des matières
1 Introduction
1.1 Introduction générale
1.1.1 Cybersécurité
1.1.2 Modélisation
1.2 Problématiques et contributions du manuscrit
1.3 Structure du manuscrit
2 État de l’art
2.1 Cybersécurité
2.1.1 Présentation générale
2.1.2 Modélisation d’un attaquant et des vulnérabilités d’un système
2.1.3 Analyses du comportement d’un attaquant
2.1.4 Axes de recherche : Modélisation et analyse du point de vue de l’attaquant
2.2 Interopérabilité de modèles
2.2.1 Définition de l’interopérabilité de modèles
2.2.2 Fédération de modèles
2.2.3 Transformation bidirectionnelle et synchronisation de modèles
2.2.4 Le futur de l’interopérabilité
2.3 Modélisation de point de vue
2.3.1 Définition des notions de vue et de point de vue
2.3.2 Formalisation des notions de vue, type de vue et point de vue
2.3.3 Utilisation de la modélisation de vues et de points de vue
2.3.4 Discussions sur la modélisation de vues et de points de vue
2.4 Modélisation par les rôles
2.4.1 Formalisation du concept de rôle
2.4.2 Utilisation de la modélisation par les rôles
2.4.3 Limitations de la modélisation par les rôles
2.5 Conclusion de l’état de l’art
3 Conceptualisation de l’analyse de la menace et modélisation d’un point de vue d’un attaquant
3.1 Description de l’approche
3.1.1 Description des concepts
3.1.2 Caractérisation de l’approche
3.2 Un système fil rouge : Alice et Bob
3.3 Définition du concept d’attaquant et construction de points de vue de références
3.3.1 Notion d’attaquant et identification de ses préoccupations
3.3.2 Définition des concepts de référence
3.4 Spécification des points de vue pour un attaquant
3.4.1 Construction de points de vue spécifiques
3.4.2 Construction de la vue d’un attaquant
3.4.3 Mise en évidence des caractéristiques propres à la description de points de vue d’attaquants
3.5 Bilan de l’approche
4 Role4All : Une modélisation de points de vue par les rôles
4.1 Role4All une proposition de modélisation de points de vue par les rôles
4.1.1 Présentation de Role4All
4.1.2 Formalisation de Role4All
4.1.3 Implémentation de Role4All
4.2 Modélisation du point de vue avec Role4All
4.2.1 Utilisation de Role4All pour modéliser un point de vue
4.2.2 Application à la génération de PVR
4.2.3 Génération de PVS
4.3 Analyse du point de vue d’un attaquant via Role4All
4.3.1 Interpréteur fondé sur les rôles
4.3.2 Exemple d’interprétation avec le système fil rouge
4.4 Conclusion
5 Cas d’étude et validation de l’approche
5.1 Présentation du système et des outils utilisés
5.1.1 Description du système
5.1.2 Modélisation du système
5.2 Modélisation de la vue de l’attaquant sur le système
5.2.1 Adaptation des métamodèles sources pour les PVR
5.2.2 Description de l’attaquant et création de son PVS
5.3 Interprétation du point de vue de l’attaquant
5.3.1 Description des comportements et adaptation du PVS pour le point de vue d’interprétation
5.3.2 Interprétation du comportement de l’attaquant
5.3.3 Génération de données pour des outils d’analyse formelle
5.3.4 Validation de l’attaque sur le système réel
5.4 Conclusion
6 Conclusion générale et perspectives
6.1 Objectifs et problématiques du manuscrit
6.2 Contributions du manuscrit
6.3 Perspectives
Liste des publications
Glossaire
Bibliographie
A Impacts des types de vulnérabilité CVE
B Métamodèle complet de Role4All
C Calcul de nombre de combinaisons entre roleInstance et playerInstance
C.1 Explication du cas 1
C.2 Explication du cas 2
D Conséquences du support des caractéristiques de vue et de point de vue d’attaquants par Role4All
E Scénario d’attaque du système fil rouge
F Schéma JSON utilisé pour représenter les vulnérabilités dans NVD
Télécharger le rapport complet
