Cartographie

La cartographie représente les configurations logicielles propres à chaque nœud du système. La connaissance de ces paramètres joue un rôle important pour déterminer si un nœud peut être la cible de certaines catégories d’attaques. Cette section présente la modélisation des logiciels, processus et services qui sont liés à un nœud sont présentés. La question du regroupement des machines disposant de configurations équivalentes est également traitée. Cette partie se termine en abordant la question de la modélisation des machines virtuelles et des comptes utilisateurs.

A Logiciels, processus

Les prédicats restent inchangés par rapport à M4D4. Un logiciel est exprimé par software(N,V,T,A), où N représente le nom du logiciel, V son numéro version, T son type et A l’architecture d’exé- cution. Un processus process(S,U) est constitué d’un logiciel (S ) exécuté par un utilisateur U. L’exécution d’un processus est modélisé avec exec(H, P) pour traduire le fait que la machine H exécute le processus P.

B Service

La principale différence avec M4D4 est l’ajout de la prise en compte de l’interface réseau sur laquelle le service écoute. Le prédicat listens(N,service(Process, Port, Iface)) signifie que le service dépendant du processus Process est en écoute sur le port Port sur l’interface réseau Iface de la machine N. Cette information permet de modéliser un service en écoute uniquement sur une interface donnée.

Modification Type de modification Justification

listens ajout d’un argument prise en compte de l’interface d’écoute Table_{3.10 – Évolution de la spécification des services.} Le tableau 3.10 résume les évolutions apportées.

C Classes d’équivalence

Dans des systèmes, il peut être commun de trouver une ensemble de machines au sein d’un même sous-réseau qui disposent de configurations équivalentes, d’une accessibilité équivalente et qui diffèrent uniquement par leurs identifiants (adresse IP et mac). Cette méthode de regroupement des machines en classes d’équivalence est similaire à celle mise en œuvre pour la simplification des graphes d’attaques ([ZOH11]). Deux nœuds sont équivalents s’ils disposent de la même configura- tion et de la même accessibilité.

equivalent_node(N, N′_{) ← (3.2.6a)} ∧ same_conf iguration(N, N′_{) (3.2.6b)} ∧ same_reachability(N, N′_{) (3.2.6c)} same_conf iguration(N, N′_{) ← (3.2.6d)} ∧ same_processes(N, N′_{) (3.2.6e)} ∧ same_services(N, N′_{). (3.2.6f)}

same_processes(N, N′_{) ←{S | ∀S.exec(N, S)} = {S | exec(N, S)} (3.2.6g)}

same_services(N, N′_{) ←{S | ∀S.listens(N, S)} = {S | listens(N, S)} (3.2.6h)}

same_reachability(N, N′_{) ←reach_f rom(N, X), reach_f rom(N}′_{, X) (3.2.6i)}

reach_to(N, Y ), reach_to(N′_{, Y ) (3.2.6j)} reach_f rom(N, X) ← X = {(S, P, R) | (3.2.6k) connectivity(S, N, P, _) (3.2.6l) ∧ route(S, N, R)}. (3.2.6m) reach_to(N, X) ← X = {(S, P, R) | (3.2.6n) connectivity(N, S, P, _) (3.2.6o) ∧ route(N, S, R)}. (3.2.6p) (3.2.6q) Le listing 3.2.6 exprime la définition de l’équivalence de deux nœuds N et N′_{. Ces nœuds doivent}

disposer de la même configuration (3.2.6b) et de la même accessibilité (3.2.6c). L’équivalence des configurations s’exprime comme l’égalité entre l’ensemble des processus et des services présents sur chaque nœud (3.2.6d).

Les prédicats reachF rom(N, X) (3.2.6k) et reachT o(N, X) (3.2.6n) donnent respectivement l’ensemble des connexions possibles vers et depuis le nœud N, où X représente l’ensemble des triplets (S, P, R) où S est un nœud, P un port et R la route entre les nœuds N et S.

La condition sur les configurations équivalentes implique également l’équivalence de la visi- bilité topologique des observateurs applicatifs ou locaux installés sur les machines d’une même classe d’équivalence. Les observateurs réseaux disposent également d’une visibilité topologique sur l’ensemble des nœuds d’une même classe d’équivalence du fait de la propriété d’accessibilité qui contraint une égalité des routes empruntées.

Cette définition est valable si les observateurs disposent d’une visibilité opérationnelle équiva- lente sur chaque machine. Cela exclut par exemple la présence de règles spécifiques à seulement une sous-partie des machines d’une classe d’équivalence. Cette limite au modèle de classes d’équivalence ne sont pas traitées, en estimant que ces cas ne sont pas courants et sont en contradiction avec une surveillance homogène d’un parc de machines équivalentes.

Détermination des classes d’équivalence Le listing 3.2.6 présente les propriétés dont doivent disposer deux machines pour caractériser leur appartenance à une même classe d’équiva- lence. Il reste à déterminer la manière dont ces classes sont déterminées en pratique.

Une classe d’équivalence C est définie par le faitequivalence_class(C) et l’appartenance d’un nœud N à une telle classe C est caractérisée par le faitbelongs_to_class(N,C). Le listing 3.2.7 illustre le fonctionnement du test d’appartenance d’un nœud à une classe d’équivalence : N appar- tient à la classe d’équivalence N s’il existe un nœud X équivalent à N et qui appartient à la classe d’équivalence C.

belongs_to_class(N, C) ←equivalence_class(C) (3.2.7a) ∧ belongs_to_class(X, C) ∧ X 6= N (3.2.7b) ∧ equivalent_node(N, X) (3.2.7c)

3.2. ENRICHISSEMENT DES ÉLÉMENTS DE LA BASE DE CONNAISSANCES 55

Il suffit alors de définir une classe d’équivalence et un nœud de référence pour en déduire l’ensemble des nœuds équivalents.

Modification Type de modification Justification

equivalence_class ajout définition d’une classe d’équivalence

belongs_to_class ajout appartenance d’une machine à une classe d’équivalence equivalent_node ajout définition de deux machines équivalentes

Table3.11 – Spécification des classes d’équivalence.

Le tableau 3.11 rassemble les nouveaux prédicats utilisés pour la modélisation des classes d’équi- valence.

D Machines virtuelles

Dans un cas simple, une machine virtuelle est modélisée comme un nœud physique. Cependant, cette approche ne permet pas de modéliser des attaques spécifiques aux machines virtuelles. En effet, un attaquant pourrait prendre le contrôle de la machine hôte pour accéder aux machines virtuelles qui y sont hébergées. Inversement, l’attaquant peut s’évader de l’environnement virtuel pour passer sur la machine physique ou sur d’autres applications hébergées sur le même nœud. Afin de modéliser cette dépendance, nous proposons d’utiliser les prédicats hosts(Node1,VirtualNode) pour indiquer que la machine représentée par Node1 héberge une machine virtuelle représentée par VirtualNode.

E Utilisateurs

Dans M4D4, les utilisateurs existent uniquement lorsqu’ils sont associés à un processus. Il est intéressant d’étendre la modélisation pour permettre de spécifier des interactions liées à un utilisateur (par exemple une réception d’un courrier électronique de hameçonnage suivie d’une infection via une pièce jointe ou un lien piégé par exemple). Pour cela, le faitis_user(U) exprime qu’U est un utilisateur et le faithas_account(U,M) permet de spécifier que l’utilisateur U dispose d’un compte sur la machine M.

Modification Type de modification Justification

is_user(U) ajout modélisations des comptes utilisateurs has_account(U,M) ajout modélisations des comptes utilisateurs hosts modification de la sémantique modélisation des machines virtuelles

Table3.12 – Utilisateurs et machines virtuelles. Le tableau 3.12 liste les prédicats introduits.

Cette sous-partie a présenté les éléments permettant de modéliser les détails liés à un nœud et à son environnement. La topologie et la cartographie se contentent de décrire les éléments fonctionnels du système. La partie suivante propose une modélisation des actions possibles pour un attaquant sur un tel système.