Revue de l'article "Network security assessment using a semantic reasoning and graph based approach"

# Revue de l'article "Network security assessment using a semantic reasoning and graph based approach" ## Préconisations de V.L. sur le rendu Avant de commencer la revue, rappel de ce que la prof a dit dans la séance de regroupement portant sur la revue d'article, notamment en termes de préconisation et de critères de notation : Objectif = vulgariser et expliquer l'article - problématique de l'article (le point "dur") - les solutions vues en cours pour attaquer ce problème - la méthodologie à adopter et pourquoi - quels résultats de l'auteur sur la problématique avec sa méthodologie Synthèse sur 2 à 5 pages avec : contexte, problème métier traité et verrou, méthode et outil pour résoudre le problème I.e. : poser la problématique telle qu'on l'a comprise dans l'article, expliquer les méthodes et outils qui ont permis à l'auteur d'analyser la situation/la pbtique dans laquelle il se trouve, expliquer la nature des outils (machine learning, ontologie, reconstitution de graphe d'attaque, modélisation de la menace) qu'on a compris comme étant la solution de l'auteur, prise de recul : en quoi la situation nous paraît pertinente (éventuellement lire d'autres articles) Vidéo à réaliser par les membres du groupe de 15-20 minutes, sur la base d'une présentation Critères de notation : - identification correcte de la problématique et bonne restitution/vulgarisation - identification correcte de la méthodo utilisée par les auteurs pour rép à la pbtique - identification correcte des tendances de l'état de l'art dans le domaine (dans la review) et compréhension du positionnement de l'auteur - compréhension de la méthodologie utilisée - compréhension de la solution proposée (décrire le mécanisme mis en oeuvre par l'auteur) - compréhension de la manière dont les auteurs se sont challengés et prise de recul ## Problématique Un administrateur de sécurité pour un réseau d’entreprise doit lutter contre des scénarios d’attaque multi-étapes et multi-hôtes.Alors que la combinaison de machines et de services déployés sur les réseaux d’entreprise devient de plus en plus complexe, l’évaluation de la sécurité globale d’un réseau d’entreprise devient une tâche ardue pour les administrateurs humains. L'absence d'un vocabulaire commun pour les différents acteurs (e.g. experts sécurités et administrateurs réseaux) dans le contexte de la sécurité de l'information, ce qui nuit au partage de la connaissance/information et à l'appropriation des outils (notamment les graphes d'attaques) par les acteurs qui devront mettre en place les contre-mesures et solutions de mitigation (principalement les administrateurs réseaux et systèmes). Les auteurs proposent le développement d'une ontologie spécifique pour permettre de partager un langage commun pour les différents acteurs dans le domaine de la sécurité, et permettre le partage des informations. L'enjeu plus général est de pouvoir, à partir des informations sur un réseau (machines, composants) utiliser l'ontologie proposée dans l'article pour inférer des schémas d'attaque possibles et les représenter via des graphes d'attaques, notamment compatibles pour la production de métriques pour l'évaluation des risques. In fine, on veut ainsi obtenir un outil permettant également de faciliter l'analyse de risque et la prise de décision sur les contre-mesures à implémenter. ## Méthodologie utilisée pour répondre à la problématique La méthodologie du système présenté dans l'article repose sur plusieurs étapes successives : 1. La construction de la base de connaissance des attaques, pour définir une ontologie de base qui repose sur l'expertise de spécialistes du domaine de la sécurité de l'information (et éventuellement des ressources extérieures). Cette base de connaissances doit permettre le partage de la connaissance entre les différents acteurs grâce à un vocabulaire commun et l'analyse des attaques potentielles sur un réseau d’entreprise. 2. L'acquisition de l'information sur le réseau : topologie du réseau, configuration des hôtes, vulnérabilités découvertes. Au sein d'une entreprise, il s'agirait plutôt d'une tâche dévolue aux administrateurs (sécurité, réseaux, systèmes). 3. La construction de l'instance spécifique d'ontologie de sécurité, qui à partir des deux items précédents nécessite de construire les objets liés à chaque concept et représenter les relations via des propriétés d'objet 4. La génération du graphe d'attaque, qui consiste à découvrir les schémas d'attaques à plusieurs étapes et multi-hôtes par itérations successives sur l'instance d'ontologie de sécurité définie à l'étape précédente 5. L'analyse de risque et le choix des contre-mesures à adopter, à l'aide de métriques qui pourront facilement être dérivées à partir du graphe d'attaque transformé Le principal apport de l'article concerne les points 1) , 3) et 4). ### Construction de la base de connaissance des attaques Il s'agit de la base conceptuelle d'une ontologie de sécurité : classes (et sous-classes), propriétés, objets. On définit également des règles d'inférence qui vont permettre de déduire des schémas d'attaque plausibles. L'ontologie présentée dans l'article décline 4 grands concepts : - Device (Appareil) qui représente les appareils du réseau, avec pour sous-classes les types d'appareil. Exemples de sous-classes donnés : serveur, station de travail, machine de l'attaquant... - Component (Composant) qui représente ce qu'on peut retrouver au sein des appareils : software, hardware... - Attack (Attaque) qui représente les types d'attaques connues : phishing, vol d'informations... - Vulnerability (Vulnérabilité) qui représente les défauts ou les faiblesses de sécurité des composants : pas de sous-classes données en exemple (mais on peut imaginer des sous-classes qui seraient tirées de l'OWASP Top 10, ou les vulnérabilités applicatives classiques, buffer overflow, format string...) Chaque concept est défini formellement en relation avec les autres : par exemple Device a des composants, des accès aux composants, des possibilités de lancement d'attaque, des attaques sur d'autres appareils (pour ces deux derniers points, penser à la machine de l'attaquant ou à une machine déjà compromise par l'attaquant...) Pour représenter les relations, l'article met à profit le Web Ontology Language (OWL) et ses propriétés entre objets : par exemple, la propriété `exploit(Attack,Vulnerability)` qui permet de relier une attaque à l'exploitation d'une vulnérabilité. Grâce aux règles du Semantic Web Rule Language (SWRL), les auteurs modélisent les schémas d'attaque avec la possibilité de les inférer à partir de l'ontologie de sécurité de base. Pour cela, il est nécessaire : - de construire les objets liés aux concepts d'attaque et de vulnérabilité - de construire un vocabulaire avec les propriétés d'objet pour représenter les besoins et les conséquences d'une attaque - définir les règles SWRL pour inférer les attaques potentielles et les gains qui s'ensuivent pour l'attaquant (Cette construction peut se baser sur les CVE, des bases de données d'exploit comme ExploitDB...) ### Acquisition de l'information sur le réseau Cette partie n'est pas développée dans l'article, qui évoque juste la nécessité pour cette étape de collecter l'information, par un administrateur de sécurité, via les méthodologies habituelles : penetration testing, outil comme OpenVAS... ### Instanciation de l'ontologie de sécurité Il s'agit d'adapter la base conceptuelle dans le cadre spécifique d'un réseau grâce à la phase d'acquisition des informations sur le réseau (topologie, hôtes...) précédente Pour ce faire, il faut : - créer les objets pour les concepts d'appareil, de composant et de vulnérabilité - mettre en place les relations entre les objets via des propriétés d'objets - réactualiser l'ontologie avec de nouveaux schémas d'attaques lors de la découverte de nouvelles vulnérabilités L'outil `Protégé` est privilégié par les auteurs pour l'instanciation de l'ontologie ### Génération de graphes d'attaques Le graphe d'attaque est généré en simulant les schémas d'attaques possibles sur le réseau, intimement liés aux ressources compromises. Les ressources compromises peuvent être représenter par un ensemble de propriétés d'objets (`AttributeSet`), et une attaque `Attack` représente le gain d'un adversaire en passant d'un ensemble initial à un ensemble ultérieur. L'union des ensembles permet de définir une `Combination`, et c'est à travers un ensemble `AttributeSet`, un ensemble d'`Attack` et un ensemble de `Combination` qu'on définit un graphe d'attaque `Attack Graph`. En pratique, la construction du graphe passe par la définition d'un algorithme basé sur le moteur d'inférence JESS. L'algorithme nécessite en entrée une instance d'ontologie de sécurité pour le réseau et une machine de départ contrôlée par l'attaquant. L'algorithme va ensuite itérer pour pour essayer à chaque étape de déduire les nouvelles compromissions possibles pour passer à un nouvel état, jusqu'à ce qu'on ne puisse plus découvrir de nouvelles machines. ### Du graphe d'attaque au management de risque La dernière étape consiste l'intégration avec les outils existants pour le management de risque : en l'occurence les auteurs proposent la transformation du graphe d'attaque précédent obtenu vers un graphe d'attaque de type MulVAL (Multi-host, Multi-stage Vulnerability Analysis Language), en proposant une méthode systématique permettant la conversion. Les graphes d'attaque MulVAL ont pour intérêt d'être compatibles avec de nombreux modèles d'évaluation du risque et sont traités dans plusieurs articles de littérature scientifique sur la sécurité informatique (sans pour autant apparaître comme un véritable "standard"). ## Etude de cas Les auteurs proposent ensuite pour illustrer leur méthode une étude de cas sur un réseau de test simple avec 7 hôtes et 2 sous-réseaux (DMZ et réseau interne, de confiance), séparés d'Internet par un pare-feu. A partir de ce réseau, les auteurs instancient leur ontologie de sécurité à partir des propriétés d'accès initiales à ce réseau test et utilisent un jeu de vulnérabilités qui se base notamment sur les CVE. Les auteurs en déduisent un graphe d'attaque grâce à leur algorithme, qu'ils transforment ensuite en graphe d'attaque MulVAL. ## Evaluation des performances Les auteurs s'attachent à évaluer la complexité de l'algorithme de génération des graphes d'attaques, en identifiant qu'elle est principalement dépendante de la complexité de la méthode de raisonnement (`Jess.reason()`), qui selon eux ne peut pas être précisément déterminée selon la littérature. Ils proposent donc une approche expérimentale basée sur des réseaux de test avec différentes topologies, et comportant de 100 à 1000 hôtes, avec chaque hôte présentant 4 vulnérabilités. Ils identifient en pire scénario le cas où le réseau est entièrement connecté (chaque machine peut accéder à toute autre machine du réseau), auquel cas le temps de calcul CPU tendrait vers $N^2$ ($N$, le nombre d'hôtes) ## Pertinence de l'approche proposée Les auteurs s'attachent à proposer une solution pour améliorer l'évaluation des risques de sécurité sur les réseaux en se basant sur des outils déjà utilisés : graphes d'attaques, métriques et méthodes de management de risque. Leur apport réside dans leur proposition d'ontologie de sécurité (inspirée d'un autre article qui introduit les concepts `Threat` et `Vulnerability`, mais se concentre sur des `Asset` et les `Countermeasure`) et leur algorithme de génération de graphe d'attaque qui peut ensuite facilement être utilisé dans le cadre des démarches de management de risque classique. La principale limite de l'article se situe dans sa relation avec les référentiels de sécurité existants et l'absence d'une extension pour la mitigation et les contre-mesures suite à l'évaluation : du dire des auteurs eux-mêmes, ils envisagent la construction d'un modèle de mitigation à partir d'une ontologie, qui se baserait sur des référentiels comme le NIST. Globalement, il est difficile à partir du seul cas d'utilisation, peut-être trop simple, de se rendre compte de l'opportunité de l'utilisation de cette approche dans des contextes plus complexes, avec une granularité plus fine des attaques, des vulnérabilités, ou des composants. Sur un réseau "réel", il semble y avoir un réel risque "d'explosion" de la complexité, qui pourrait nuire déjà au calcul pratique du modèle (dont la tentative d'estimation semble elle aussi limitée), mais aussi et surtout en termes de lisibilité vis-à-vis des instances d'ontologie et des graphes d'attaques produits. Or, un des principaux enjeux des démarches de management de risque réside bien dans la capacité à prioriser face à une multitude de risques en présence, et si la promesse de l'article est de faciliter ce travail grâce à l'articulation avec des modèles existants (par le passage à un graphe MulVAL) pour en dériver des métriques traditionnelles, cette articulation n'est pas démontrée et les graphes MulVAL ne semblent par ailleurs pas consituer un standard au sein de la communauté.