• Aucun résultat trouvé

La construction de cette base de connaissances est réalisée en se basant sur les spécifications d’une base existante. Le choix de M4D4 [MMDD09] comme fondation paraît justifié pour plusieurs raisons. Tout d’abord sur le fond, une grande partie des éléments de modélisation recherchés sont présents (cartographie, vulnérabilités, attaques) et en particulier le modèle de visibilité des IDS. Ensuite, sur la forme, la base est conçue pour être facilement implémentée dans un langage logique (Prolog), ce qui donne certains avantages de développement et de souplesse, au prix de limitations en performances. Cependant, la base M4D4 a été initialement conçue comme une architecture permettant de fédérer des informations contextuelles pertinentes pour remettre les notifications de sécurités dans leur contexte et permettre de réaliser des requêtes pour tester la corrélation entre événements et alertes reçues. Dans notre approche, les informations pertinentes concernent la description d’un système d’information ainsi que la modélisation du comportement des outils de

1. Comme les évolutions proposées ne sont pas entièrement compatibles avec la description originale de M4D4, on parle d’une évolution ou d’une adaptation plutôt que d’une extension.

détection. La partie de M4D4 dédiée à la fédération des événements générés par le système est par exemple en dehors de notre périmètre.

La base de connaissances à construire doit contenir toutes les informations contextuelles indis- pensables à la création des règles de corrélation. Ces informations sont organisées de la manière suivante :

— une première partie modélise la topologie du système ;

— une seconde partie est dédiée à la cartographie (les services et logiciels installés) ;

— une partie dédiée aux actions, aux attaques et aux vulnérabilités qui décrit une hiérar- chie de classes d’attaques élémentaires et d’actions standards pouvant être réalisées par un attaquant sur le système ;

— une partie dédiée aux observateurs et à la supervision inclut les positionnements et configu- rations des observateurs.

La section qui suit propose un passage en revue des différentes parties de la base de connaissances en rappelant les concepts issus de M4D4 et introduisant les évolutions apportées.

3.1.1 Rappels sur M4D4

A Topologie et cartographie

Cette partie de M4D4 met à disposition des prédicats permettant de décrire l’infrastructure fonctionnelle d’un système d’information. Le tableau 3.1 liste les prédicats liés à la topologie du système et les prédicats permettant de spécifier la cartographie, c’est-à-dire les processus et services instanciés au niveau de chaque machine, sont regroupés dans le tableau 3.2. La topologie décrite dans M4D4 repose sur la définition de réseaux et de nœuds connectés à un réseau.

Prédicats signification

network(N) N est un réseau

netaddress(N, A) A est l’adresse du réseau N

node(H) H un est nœud

nodeaddress(H, Ah) Ah est une adresse de H

gateway(H) H est un routeur

nodenet(H, N) Le nœud H appartient au réseau N

nodegw(H, Hg) Le routeur Hg est directement accessible par H

routes(Hg1, Hg2, N) Hg1 route les paquets vers le réseau N par Hg2

path(Hgs, Hgd, L, N) L est la liste de routeurs composant la route vers le réseau N depuis Hgs vers Hgd

route(Hs, Hd, L) L est une route entre la source Hs et la destination Hd

nat(G, A1, P1, A2, P2) L’adresse A1 et le port P1 sont translatés respectivement A2 et P2 par le routeur G

nodename(H, Name) Name est le nom d’hôte de H

resolve(A, Name) Le FQDN de l’adresse A est Name

Table3.1 – M4D4 : topologie.

Des précisions sont apportées concernant la lecture du tableau 3.1. Le prédicat nodenet(H, N) peut correspondre à un fait ou bien est déduit (via une règle) par vérification de l’appartenance d’une adresse du nœud H au sous-réseau N. Lorsque le noeud H est en dehors du système adminis- tré, le prédicat nodegw(H, Hg) est vrai si Hg est un routeur de bordure permettant l’interconnexion avec un réseau externe. Le prédicat nodegw(H, Hg) associe à un noeud externe au système admi- nistré un routeur en bordure du système. Le prédicat path est défini par des règles qui mettent en jeu un prédicat auxiliaire travel chargé de construire la liste des routeurs traversés de manière

3.1. CHOIX D’UNE BASE DE RÉFÉRENCE 45

récursive :

path(Hgs, Hgd, L, N ) ← travel(Hgs, Hgd, [Hgs], L, N ) travel(Hgs, Hgd, R, [Hgd|R], N ) ← routes(Hgs, Hgd, N )

travel(Hgs, Hgd, R, L, N ) ← routes(Hgs, Hgi, N ) ∧ Hgi 6= Hgd

Hgi /∈ R ∧ travel(Hgi, Hgd, [Hgi|R], L, N )

Le prédicat route(Hs, Hd, L) permet de déterminer la liste L des routeurs constituant une route entre Hs et Hd. Cette route est déterminée en identifiant les routeurs respectifs Hgs et Hgd des nœuds Hs et Hd en faisant appel au prédicat path :

route(Hs, Hd, L) ←nodegw(Hs, Hgs) ∧ nodegw(Hd, Hgd) nodenet(Hd, N ) ∧ path(Hgs, Hgd, L, N )

Prédicats signification

software(N, V, T, A) Logiciel de nom N, version V, de type T et d’architecture A

hosts(H, S) Le nœud H héberge le produit S

process(S, U) Le processus S est exécuté avec l’identité U

exec(H, P) Le nœud H exécute le processus P

service(P, Q) Le processus P écoute sur le port Q

listens(H, Ser) Le nœud H exécute le service Ser

Table 3.2 – M4D4 : cartographie.

B Vulnérabilités et attaques

Les prédicats introduits dans M4D4 pour décrire les vulnérabilités et les classes d’attaques sont présentés dans le tableau 3.3. Une vulnérabilité est définie comme une faiblesse au niveau de l’architecture, l’administration ou l’implémentation d’un système ou d’un logiciel. Les vulnérabilités modélisées dans M4D4 reposent sur une configuration vulnérable constituée d’un ensemble de logiciels.

Prédicats signification

vulnerability(V) V est une vulnérabilité

affects(V, C) La vulnérabilité V affecte la configuration C

takespartin(S, C) Le logiciel S est un élément de la configuration vulnérable C

refersto(V, O, Vn) La vulnérabilité V est nommée Vn par l’organisation O

equiv(O, V, O’, V’) V et V’ sont des noms d’une même vulnérabilité (respectivement de l’organisme O et O’)

severity(V, S) La sévérité de la vulnérabilité V est S

requires(V, W) W est un prérequis pour exploiter la vulnérabilité V

losstype(V, C) Les conséquences de l’exploitation de la vulnérabilité V sont C

published(V, D) D est la date de publication de la vulnérabilité V

attackclass(C) C est une classe d’attaque

inherits(C1, C2) C1 est une classe fille de C2

attacksubclass(C1, C2) C1 est une sous-classe de C2

exploits(C, V) La classe d’attaque C exploite la vulnérabilité V

En plus des éléments apportés dans le tableau 3.3, il faut noter que le prédicat not_vulnerable(H, V) exprime le fait que le nœud H n’est pas affecté par la vulnérabilité V :

not_vulnerable(H, V ) ←vulnerability(V ) ∧ node(H) ∧ ∀C.af f ects(V, C) ∧ (∃Sv.takespartin(Sv, C)

∧ (∀Sn.hosts(H, Sn) ∧ Sv 6≈ Sn))

Le nœud H n’est pas vulnérable si l’intégralité des configurations vulnérables mettent en jeu au moins un produit qui diffère de tous les produits hébergés par H.

Le prédicat attacksubclass(C1, C2) est défini par la règle : attacksubclass(C1, C2) ← inherits(C1, C2)

attacksubclass(C1, C2) ← inherits(Ci, C2) ∧ attacksubclass(C1, Ci)

C Analyseurs

Les prédicats qui permettent une description des outils de sécurité qui génèrent des messages (IDS) et de leurs capacités de détection sont regroupés dans le tableau 3.4

Prédicats signification

analyser(A) A est un analyseur

ids(A) A est un IDS

hids(A) A est un IDS hôte

monitors(A, H) L’HIDS A surveille le nœud H

monitors(A, H, S) L’IDS applicatif A surveille l’application S du nœud H

nids(A) A est une IDS réseau

ips(A) A est un IPS (Intrusion Prevention System)

monitors(A, Hg) L’IPS A est positionné sur le routeur Hg

monitors(A, G1, G2) Le NIDS A surveille le lien G1, G2.

can_detect(A, Hs, Hd) L’IDS A peut être capable d’analyser un paquet allant du nœud Hs au nœud Hd

kbids(A) A est un IDS fonctionnant par signatures

abids(A) A est un IDS comportemental

signature(S) S est une signature d’IDS

active(A, S) La signature S est active pour l’IDS A

detects(C, S) La signature S est prévue pour détecter la classe d’attaque C

func_vis(A, C) L’IDS par signatures A peut détecter des attaques qui sont des sous-classes de C

detects(A, C) L’IDS comportemental A peut détecter l’attaque C ainsi que ses sous-classes

scanner(A) A est un scanner de vulnérabilité

monitors(A, V, H) A recherche la vulnérabilité V sur le nœud H

deny(Hg, As, Ps, Ad, Pd) Hg bloque les connexions entrantes venant de l’adresse As et du port Ps vers le port Pd de l’adresse Ad

Table3.4 – M4D4 : analyseurs.

Le prédicat can_detect(A, Hs, Hd) distingue les cas dans lesquels A est un IPS placé en coupure au niveau d’un routeur G ou un NIDS :

can_detect(A, Hs, Hd) ← ips(A) ∧ route(Hs, Hd, L) ∧ monitors(A, G) ∧ G ∈ L