Rapport de stage de DEA RSD

Nicolas Nobelis
DEA RSD / ESSI3 SAR
Septembre 2004
Un modèle de Case-Based Reasoning pour la
détection d'intrusion
Rapport de stage DEA RSD/ESSI3 SAR
Stage effectué sous l'encadrement de Melle Karima Boudaoud
pour le laboratoire I3S
Avril – Septembre 2004
1. Introduction
Les réseaux et systèmes informatiques sont devenus des outils indispensables au fonctionnement des
entreprises. Ils sont aujourd’hui déployés dans tous les secteurs professionnels : la banque, les assurances, la
médecine ou encore le domaine militaire. Initialement isolés les uns des autres, ces réseaux sont à présent
interconnectés et le nombre de points d’accès ne cesse de croître.
Ce développement phénoménal s’accompagne naturellement de l'augmentation du nombre d’utilisateurs.
Ces utilisateurs, connus ou non, ne sont pas forcément pleins de bonnes intentions vis-à vis de ces réseaux.
Ils peuvent exploiter les vulnérabilités des réseaux et systèmes pour essayer d’accéder à des informations
sensibles dans le but de les lire, les modifier ou les détruire, pour porter atteinte au bon fonctionnement du
système ou encore tout simplement par jeu.
Dès lors que ces réseaux sont apparus comme des cibles d’attaques potentielles, leur sécurisation est
devenue un enjeu incontournable. De nombreux outils et moyens sont disponibles, tels que firewalls,
solutions matérielles, logiciels d'audits ou systèmes de détection d'intrusion (IDS). Les IDS sont une des plus
populaires réponses au problème posé par :
●
●
●
l'évolution continue des attaques,
l'apparition de nouvelles attaques,
la nécessité de pouvoir appliquer rapidement de nouvelles politiques de sécurité dans un réseau
afin de détecter et réagir le plus vite possible aux attaques survenant dans ce réseau.
Dans ce contexte, un IDS utilisant des politiques de sécurité et fondé sur un système multi-agents a été
proposé ([21]). Dans ce système, des agents intelligents coopèrent et communiquent pour détecter
efficacement des attaques suivant des schémas d'attaque définis dans leur base de connaissances. Les
caractéristiques clés des agents intelligents (AI) utilisées dans ce système sont la délégation, la coopération
et la communication. Cependant, une propriété importante des AI, qui est leur capacité d'apprentissage, n'a
pas été utilisée. Cette caractéristique nous paraît idéale pour détecter de nouvelles attaques. C'est pour cette
raison que nous nous proposons d'étendre cet IDS multi-agents en lui ajoutant la fonction d'apprentissage de
nouveaux schémas d'attaque.
L'objectif de ce travail est donc de concevoir d'un modèle permettant la détection d'attaques inconnues pour
le système à base d'agents existant.
Nous commencerons par un état de l'art sur la détection d'intrusions. Puis, nous présenterons une technique
particulière permettant l'extraction et la classification de données pertinentes, issues de fichiers d'audit, pour
la détection d'intrusions : le Data Mining. Ensuite, nous étudierons une seconde technique, dite
"Raisonnement à Base de Cas" ("Case Based Reasoning"), technique qui nous semble intéressante dans
l'apprentissage de nouvelles attaques. Enfin, nous décrirons notre modèle fondé sur le CBR pour la détection
d'intrusions inconnues. Finalement, nous terminerons par une conclusion et quelques remarques sur les
travaux futurs.
2/28
2. État de l'art
Une intrusion peut être définie comme tout ensemble d'actions qui essaye de compromettre :
●
●
●
la confidentialité des données,
l'intégrité des données,
la disponibilité d'une ressource ou d'un service.
En dépit des différentes formes d'intrusion, elles peuvent être regroupées dans deux classes :
●
●
les intrusions connues
les intrusions inconnues ou anomalies.
Dans le cadre de ce travail, nous nous intéresserons à la détection de ces deux types d'intrusions.
2.1 La détection d'intrusions
La détection d'intrusions fait référence à la capacité d'un système informatique de déterminer
automatiquement, à partir d'événements relevant de la sécurité, qu'une violation de sécurité se produit ou
s'est produite dans le passé. Pour ce faire, la détection d'intrusions nécessite qu'un grand nombre
d'événements de sécurité soient collectés et enregistrés afin d'être analysés. On parle alors d'audit de
sécurité.
Les systèmes de détection d'intrusion (IDS) actuels reposent sur des techniques diverses et variées. Dans
cette section, nous présentons une classification de haut niveau de ces techniques.
Les systèmes de détection d'intrusions sont divisés en deux catégories, suivant l'approche utilisée, qui peut
être ([21]) :
●
●
●
soit une approche par scénarios.
soit une approche comportementale.
soit hybride (i.e. un mixte des deux approches)
Les approches par scénarios se basent sur le fait que toute attaque connue produit une trace spécifique dans
les enregistrements d'audit. Elles nécessitent une connaissance a priori des attaques à détecter : une alarme
est émise lorsque la trace d'une attaque connue est détectée. Les approches par scénarios utilisent des
techniques différentes, dont les principales sont :
les techniques à base de règle (i.e. les systèmes experts). La base de connaissances des systèmes
experts contient des règles concernant non seulement les scénarios d'attaque que l'on veut
détecter sur le système cible, mais aussi les vulnérabilités connues de ce système. La construction
de cette base repose entièrement sur l'expérience et le savoir faire de l'officier de sécurité.
● les approches fondées sur la signature des attaques essayent de représenter les attaques sous
forme de signatures. Les données courantes sont alors comparées à ces signatures. S'il y a des
similitudes, une alarme est déclenchée.
● et les algorithmes génétiques, utilisés afin d'optimiser la recherche de scénarios d'attaque dans
des fichiers d'audit ([20]). Leur utilisation permet d'éviter une recherche exhaustive en
sélectionnant les meilleurs éléments d'une population (ici les scénarios d'attaque).
●
L'approche comportementale vise à modéliser ou à prédire le comportement normal : cette approche
nécessite une phase d'apprentissage proprement dite durant laquelle les cas de références, représentant le
profil normal, sont construits. Une alarme est émise quand une déviation trop importante de ce profil est
observée.
Pour modéliser le profil normal, les approches comportementales utilisent :
3/28
soit des modèles statistiques qui consistent à utiliser des mesures statistiques pour modéliser un
profil de comportement et détecter ensuite des comportements intrusifs. Chacune des ces mesures
est associée à un seuil ou à un intervalle de valeurs, dans lequel une activité est considérée
comme normale. Tout dépassement de seuil ou situation de valeurs à l'extérieur des bornes de
l'intervalle indique une activité anormale,
● soit des systèmes experts. La différence majeure entre un système expert et un modèle
statistique est que ce dernier utilise des formules statistiques pour identifier des comportements
dans les données d'audit alors que le système expert utilise un ensemble de règles pour
représenter ces comportements.
●
Les approches comportementale prédisant le profil normal peuvent, quant à elles, reposer sur :
des générateurs de forme prédictive. Cette approche prédit les formes les plus probables en se
basant sur les formes observées. Durant la phase d'apprentissage, cette approche détermine des
règles temporelles qui caractérisent le comportement normal des utilisateurs.
● ou des réseaux de neurones. Un réseau de neurones est constitué de plusieurs éléments de
traitement simples appelés unités et qui interagissent en utilisant des connections pondérées. Le
réseau constitue le profil normal d'un utilisateur. Ainsi, après chaque commande utilisée par cet
utilisateur, le réseau essaye de prédire la commande suivante, en tenant compte des n commandes
antérieures. Si la commande réelle dévie de celle prédite, alors une alarme est envoyée.
●
Quelle que soit l'approche choisie (comportementale, par scénarios ou hybride), tous les IDS se trouvent
confrontés au problème de la détection de nouvelles attaques, plus précisément à la détection d'attaques
inconnues. Les systèmes fondés sur une approche par scénarios, ne peuvent, a priori, détecter que des
attaques connues : la détection de nouvelles attaques pour eux consiste en la mise à jour de leur base de
connaissance (à la manière des logiciels antivirus). L'approche comportementale, quant à elle, permet
effectivement de détecter des attaques inconnues, puisque toutes les attaques constituent une déviation vis à
vis de leur comportement normale de référence.
Au delà du problème de la détection de nouvelles attaques, tous les IDS existants (encore une fois, quelle
que soit l'approche sur laquelle ils reposent) sont soumis aux problèmes de l'extraction et surtout de la
classification de données pertinentes d'un large volume de donnée diverses ([13]). Ce volume et cette variété
peuvent se justifier par ([9]) :
l'augmentation du nombre d'attaques ainsi que la taille des journaux d'audits manipulés (qui
contiennent de plus en plus d'événements), augmentations liées à celle des débits des réseaux,
● l'éventail d'IDS (propriétaires ou non) utilisant chacun leurs techniques et données propres par
manque de standard reconnu.
●
Une des techniques les plus populaires à l'heure actuelle est celle du Data Mining, que nous allons
expliciter dans la partie suivante.
2.2 Le Data Mining et la classification de données d'audit
D'après Dary Alexandra Pena Maldonado ([9]), le Data Mining (DM) est une technique permettant de
retrouver des corrélations d'attributs entre éléments d'un même jeu de données, pour caractériser un
comportement spécifique, mais autorisant également la construction de règles à des fins de classification.
Pour Wenke Lee & Al. ([18]), le DM est un processus chargé d'extraire automatiquement un modèle d'un
large ensemble de données. Les auteurs distinguent différent types d'algorithmes de DM :
●
●
Classification : permet de déterminer l'appartenance d'un élément à une catégorie prédéfinie.
Analyse de lien : permet de déterminer les relations entres différentes caractéristiques d'une base
de données, afin de conseiller le meilleur jeu de caractéristiques pour la détection d'intrusions.
4/28
●
Analyse de séquence : autorise la recherche, dans une séquence d'événements, de schémas
caractéristiques, afin de définir le comportement normal.
Le DM peut être utilisé quelque soit le type de stratégie sur lequel repose le système de détection
d'intrusions, comme nous allons le voir dans les paragraphes ci-dessous.
2.2.1 Le Data Mining dans les approches par scénarios
Le protocole utilisé dans cette approche est le suivant :
Il faut tout d'abord prendre un vaste jeu de données dont les entrées sont étiquetées comme étant des
activités normales ou anormales. Le Data Mining intervient à travers l'utilisation d'un logiciel de création de
règles comme RIPPER ([19]) : A partir du jeu de données, des règles précises sont générées permettant de
caractériser une activité, caractérisation normale ou anormale.
Deux exemples populaires d'une telle approche sont :
●
Le projet "Automated Discovery of Concise Predictive Rules for Intrusion détection" de Helmer
& Al ([12] plus agents [10] [11]), qui utilise la technique suivante : RIPPER est lancé sur un jeu
de données d'entraînement étiqueté (i.e. les attaques sont identifiées). Cet algorithme génère
ensuite des règles de classification pour la classe comprenant le moins d'éléments. Illustrons cela
par un exemple. Soit V un vecteur d'événements inconnus à classifier. Si dans le jeu
d'entraînement, il y a moins d'attaques que d'événements normaux, les règles générées
ressemblent à :
Si caractéristique no1 de V > x
alors V est une attaque
Si (caractéristique no2 de V > y et caractéristique no5 de V <> 3)
alors V est une attaque
...
Sinon
V n'est pas une attaque.
Illustration 1: Un exemple de règles générées par RIPPER
Ceci reste une utilisation classique de RIPPER, mais ce projet est néanmoins très intéressant de par
l'utilisation de plusieurs techniques conjointes (tel que RIPPER et les algorithmes génétiques par
exemple).
●
Le projet JAM – Java Agent For Metalearning ([18][17][16]), qui utilise une approche
nécessitant le calcul d'un profil issu de données étiquetées durant une phase d'apprentissage. Un
algorithme d'apprentissage est ensuite utilisé pour classifier des événements inconnus. Ce projet
présente un caractère original car le système JAM est indépendant de l'algorithme
d'apprentissage. Les algorithme RIPPER, Bayes et Wpebls sont inclus nativement dans le
système, mais n'importe quel autre algorithme peut être utilisé via un système de plugin. Pour
plus de détails sur les résultats de ce projet, voir [15].
2.2.2 Le Data Mining dans les approches comportementales
Dans les approches comportementales, le DM est utilisé sur un jeu de données enregistrées durant une
utilisation normale du système lors d'une phase dédiée d'apprentissage (contrairement à l'approche
précédente, les données ne sont pas étiquetées suivant leur nature - normale ou anormale - ) . L'utilisation du
DM permet de construire le profil normal utilisé pour l'observation de déviations par rapport à ce profil, afin
de caractériser les attaques.
5/28
Deux exemples d'une telle approche sont :
●
Le projet ADAM – Audit Data Analysis and Meaning ([8]) qui utilise une combinaison de règles
d'association et de classification pour découvrir des attaques dans des fichiers d'audit du logiciel
TCPdump. ADAM construit tout d'abord un profil normal à partir de ces fichiers d'audit
enregistrés durant une période ne comprenant pas d'attaques. Ensuite, un algorithme est lancé sur
un jeu de données à tester afin de retirer toutes les traces d'un comportement normal, ceci à l'aide
du profil normal construit précédemment. Finalement, un dernier algorithme spécialement
entraîné à la classification des attaques est lancé sur les données restantes, les classifiant en
attaques connues, attaques inconnues et fausses alarmes.
●
Le projet "Intrusion Detection with Unlabeled Data Using Clustering" de Leonid Portnoy ([14])
qui définit un framework permettant de détecter des attaques inconnues nécessitant uniquement
un jeu de données non étiqueté durant la phase d'apprentissage. Les données brutes non
identifiées sont agrégées en clusters, puis le cluster contenant le plus d'éléments est étiqueté
"normal", les autres clusters étant étiquetés "anormaux". Lorsqu'un événement inconnu est
soumis au système, un algorithme détermine à quel cluster appartient l'événement avec des
calculs de distance euclidienne.
2.2.3 La nécessité d'une autre approche
Pour conclure, le Data Mining est une approche très performante dans le domaine de la détection
d'intrusions, et sa popularité caractérise bien l'engouement que les chercheurs ont eu pour lui. Néanmoins,
deux points importants peuvent entraver son utilisation :
Dans une approche par scénarios, l'obligation de posséder un jeu de données comprenant à la fois
des attaques (true positive) et à la fois des événements normaux (true negative).
● Dans une approche comportementale, la nécessité de consacrer une phase d'apprentissage dédiée
à la création d'un profil normal.
●
Ces deux points nous ont poussé a chercher une autre approche que le Data Mining, recherche qui nous a
conduit aux Modèles de Raisonnement à Base de Cas, dit "Case-Based Reasoning Models", que nous
décrivons dans la section suivante.
2.3 Le Case-Based Reasoning
Comme le définissent Aamodt & Plaza ([3]), "Le Case-Based Reasonning (CBR), est une approche capable
d'utiliser la connaissance spécifique de problèmes (cas) s'étant déjà produits dans le passé pour répondre à
de nouveaux problèmes. Un nouveau problème est résolu en cherchant un cas passé similaire, et en
réutilisant sa solution dans le problème présent."
Cette définition montre que le CBR est un algorithme très naturel : en tant qu'être humain, lorsqu'un
problème se pose, l'idée première est de rechercher si ce problème (ou un cas similaire) s'est déjà produit, et,
le cas échéant, reprendre la solution passée pour essayer de l'adapter au problème présent.
6/28
Illustration 2: Les principales étapes d'un
algorithme de CBR
De part la généralité de son algorithme, le Case-Based Reasoning a été utilisé dans des domaines variés, et
nombreux sont les systèmes se fondant sur cette technique : CASEY, PROTOS, PATDEX ([7]), CREEK et
CHROMA ([6]) pour ne citer que les plus connus.
●
PROTOS est un système de CBR développé pour aider au diagnostique des malentendants. Un
problème est présenté à PROTOS comme un vecteur de caractéristiques, et la tâche du système
est de retrouver le cas passé qui correspond le plus au vecteur. La solution d'un problème passé
est proposée comme solution au problème présent, sans adaptation (pas de REVISE). Si la
solution est refusée par l'utilisateur, une étape d'apprentissage commence : PROTOS peut alors
rechercher une autre solution, ou accepter une solution de l'utilisateur. Dans ce cas, l'utilisateur
est obligé de définir les termes entrés dans le système qui sont inconnus de PROTOS, en
décrivant leur relation avec les termes existants. Cette phase permet de construire la
connaissance générale du système. Si le problème a été résolu tout de suite, le système renforce
(par pondération) les caractéristiques ayant permit la résolution. Parallèlement, si le problème
n'est résolu qu'en seconde étape, PROTOS affaiblit les caractéristiques fautives. L'originalité de
PROTOS tient au fait que son apprentissage repose sur l'utilisateur.
●
CASEY est un système de CBR développé pour aider au diagnostique de problèmes cardiaques.
Un problème présenté à ce système est résolu en recherchant un cas, et, contrairement à
PROTOS, en adaptant la solution passée au problème présent. Chaque cas contient une
explication causale qui lie les caractéristiques au diagnostique (i.e. la solution). CASEY apprend
toujours de la résolution d'un problème : le nouveau cas est enregistré s'il possède des
caractéristiques suffisamment différentes du cas de référence recherché. Si le cas de référence est
identique au problème présent, les informations définissant l'importance de ses caractéristiques
sont mises à jour. Le problème majeur de CASEY est son absence d'interaction avec l'utilisateur
(c'est, en quelque sorte, un monde fermé).
●
CHROMA est un système utilisé pour choisir les techniques de chromatographie utilisées dans la
purification de protéines issues de cultures. Ce système se focalise plus précisément sur la
coopération dans un CBR distribué. Chaque agent dispose de connaissances propres sur les cas
passés. Les auteurs identifient deux formes de CBR : le Distributed CBR (DistCBR) et le
Collective CBR (ColCBR). Dans le premier cas, le problème posé à un agent A est transmit par
7/28
celui-ci à un autre agent B. Ainsi, la méthode de CBR utilisée sera celle de B. De manière
générale, un problème soumis au CBR est distribué à tous les agents qui utilisent ensuite leurs
propres méthodes pour sa résolution. Dans le cas du ColCBR, lorsque A transmet le problème, il
transmet également sa méthode à B (ainsi, la méthode de A sera utilisée avec la connaissance de
B). Autrement dit, l'émetteur utilise les mémoires de cas des autres agents : il s'agit, en quelque
sorte, d'une mémoire collective.
Il existe de nombreux documents traitant des optimisations de l'algorithme et plus particulièrement :
●
●
●
de l'organisation des données dans la base de cas ([2] et [3]).
de l'algorithme de similarité utilisé dans le meilleur cas ([5] et [4])
de l'utilisation de connaissances pour effectuer une analyse sémantique lors du RETRIEVE et du
RETAIN (voir l'Illustration 2) au lieu de l'analyse syntaxique traditionnellement utilisée [1].
2.4 Conclusion
Pour conclure, le Case-Based Reasoning est un modèle d'apprentissage qui pourrait se substituer au Data
Mining dans notre domaine de recherche, et, à notre connaissance, cette approche n'a jamais été appliquée
dans la détection d'intrusions. Dans le cadre de ce travail nous nous proposons d'intégrer dans un IDS à base
d'agents intelligents existant (décrit dans la section suivante) un modèle fondé sur le CBR pour la détection
d'attaques inconnues. Ce modèle est décrit dans la section 4.
8/28
3. Système de détections d'intrusion base d'agents
intelligents.
Le système multi-agents existant est complètement décrit dans [21], mais nous allons cependant présenter
les principales caractéristiques ayant un rapport avec notre modèle. En particulier, nous décrirons le modèle
organisationnel du système multi-agents, ainsi que son modèle événementiel.
3.1 Le modèle organisationnel
Les caractéristiques clés de ce système de détection d’intrusions à base d’agents sont : l’autonomie, la
distribution, la coopération, l’adaptabilité et la flexibilité. Dans ce système, les agents intelligents, localisés
dans des entités spécifiques du réseau, sont organisés de manière hiérarchique (voir Illustration 3) dans deux
couches : une couche gestionnaire et une couche locale.
Administrateur
Gestionnaire de politique
de sécurité
Gestionnaire extranet
Gestionnaire intranet
Dépendance hiérarchique
Reports
Surveillant local
Illustration 3: Le modèle organisationnel du système existant
La couche gestionnaire gère la sécurité globale d’un réseau. Dans cette couche, il existe trois niveaux
d’agents : l’agent gestionnaire de politiques de sécurité, l’agent gestionnaire extranet et des agents
gestionnaires intranet.
L'agent gestionnaire de politique de sécurité à pour rôle d'assurer les fonctions suivantes :
● dialogue avec l'administrateur pour la spécification des politiques de sécurité.
● gestion des politiques de sécurité (création, mise à jour, activation, ...).
● instanciation des schémas d'attaque et transmission des buts aux entités du niveau inférieur, i.e
les agents gestionnaires extranet.
Le gestionnaire extranet a une vue globale du réseau d'entreprise, et remplit les fonctions suivantes :
● réception des buts du niveau supérieur.
● détection des attaques globales et coordonnées.
● distribution des attaques aux entités distribuées du niveau inférieur.
Le gestionnaire intranet remplit la même fonction que le gestionnaire extranet, mais du point de vue local
du réseau d'entreprise.
La couche locale gère la sécurité d’un domaine, composé d’un sous-ensemble de machines dans un réseau
local. Cette couche contient un seul niveau d’agents qui sont les agents surveillants locaux et qui ont pour
fonction la détection des schémas d’attaque.
9/28
Dans ce modèle multi-agents hiérarchique, chaque agent gestionnaire a la capacité de contrôler des agents
spécifiques et d’analyser des données, alors que les agents surveillants locaux ont pour mission de surveiller
des activités spécifiques. A chaque niveau, les agents communiquent et s’échangent leurs connaissances et
analyses afin de détecter les activités intrusives de manière coopérative.
3.2 Le modèle événementiel.
Dans cette section, nous décrivons le modèle événementiel du système existant, i.e. la manière dont les
événements sont filtrés suivant les schémas d'attaques reçus par les agents.
Modèle conceptuel
de données
Fenêtre temporelle d ’observation
M1 M2…………………………………………………………………Mn
Messages
Filtrage
Filtres d ’événements
E1 E2…………………………………………………………...…….…Em
Regroupement
Evénements
Schémas d ’attaque
……….
Suite S1
Suite S2
Suite Si
Suite Sp
Suites d ’événements
Illustration 4: Le modèle événementiel du système existant
Le modèle événementiel se décompose en trois étapes simples :
filtrer les événements à l'aide de critères définis par les schémas d'attaques,
regrouper les événements filtrés à partir des schémas d'attaque pour construire des suites d'événements
corrélés, i.e. agréger les événements identiques avec des opérateurs d'occurrence par exemple,
● analyser les suites d'événements corrélés pour identifier des schémas d'attaque.
●
●
3.3 Conclusion sur le système existant.
Le système que nous venons de décrire ne permet de détecter que des attaques connues. L'objectif de ce
travail est donc d'enrichir ce système avec un modèle fondé sur le CBR pour :
● obtenir de nouveaux événements à analyser,
● détecter à partir de ces événements des attaques inconnues,
● mettre à jour automatiquement les politiques de sécurité pour prendre en compte les nouvelles
attaques détectées.
Ce modèle est décrit dans la section suivante.
10/28
4. Le modèle d'apprentissage
L'objectif de ce modèle est d'ajouter un mécanisme d'apprentissage de nouvelles attaques au système
existant (voir partie précédente) en utilisant un moteur de Case-Based Reasoning. Cet ajout comprend
plusieurs points :
1. L'extension du filtrage des événements ( ).
2. La mise en place des éléments du moteur de CBR ( ).
3. La génération automatique des schémas d'attaque correspondant aux caractéristiques des
nouvelles attaques détectées, et la mise à jour des politiques de sécurité pour prendre en compte
les nouvelles attaques ( ).
Voici le positionnement de chacune de ces fonctionnalités dans le modèle d'apprentissage d'un agent :
Moteur de
délibération
Événements filtrés
2
Moteur CBR
En cas de
suspicions
1
Filtrage
Construction du
schéma
correspondant
Filtrage
avancé des
événements
Événements bruts
Administrateur
Mise à jour des
politiques de
sécurité
Illustration 5: Vue interne du modèle d'apprentissage
Note : Les éléments du système existant sont représentés en saumon ( ).
4.1 Extension du filtrage des événements
Comme expliqué précédemment, les agents actuels n'observent que les événements définis par les schémas
d'attaque qui leur ont été transmis. Pour pouvoir détecter des attaques inconnues (non définies par des
schémas d'attaques), nous proposons d'ajouter un autre module de filtrage au niveau des agents surveillants
locaux (voir chapitre 3) du système actuel .
Le filtre ( ) se comporte comme celui présent à l'origine dans les agents : il est programmable avec des
listes d'événements et permet de savoir si un événement observé appartient à ces listes. Ces dernières
ressemblent à celles permettant de définir des schémas d'attaque car elles utilisent le même langage de
spécification à l'exception des opérateurs d'occurrence et des opérateurs temporels [21].
11/28
4.2 Mise en place des éléments du moteur de CBR.
A présent, nous disposons de nouveaux événements à analyser, et nous désirons les soumettre au moteur de
Case-Based Reasoning. Pour cela, il faut identifier tous les éléments intervenant dans l'algorithme ainsi que
toutes les étapes de cet algorithme.
4.2.1 Notre algorithme de Case-Based Reasoning
Suite suspicieuse d'événements
Recherche du meilleur
cas (Retrieve)
Mémoire des cas
Administrateur
Enregistrement du nouveau
cas (Retain)
Illustration 6: Le moteur de délibération du CBR
Voici les étapes effectuées par le moteur de délibération du CBR (en (
soumission d'une suite suspicieuse d'événements :
) sur l'Illustration 5) lors de la
La suite est traitée par un préprocesseur (non présenté sur le schéma) qui va positionner les
opérateurs d'occurrence sur les éléments de la suite (i.e. agréger les événements identiques)
● A l'aide d'une fonction de similarité, le cas le plus similaire est recherché dans une base de cas
(appelée mémoire dans la terminologie du Case-Based Reasoning), contenant des attaques (i.e.
des suites d'événements passés, identifiées comme attaques) : c'est le Retrieve.
● Si le taux de similarité est trop faible entre le meilleur cas et la suite suspicieuse, le
système peut : soit ignorer la suite, soit demander l'avis de l'administrateur (choisir le
meilleur cas tout seul, ignorer la suite ou certifier que la suite est une attaque – et passer
à l'étape suivante – ).
● Si la suite suspicieuse est une attaque, un nouveau cas correspondant à cette attaque est ajouté
dans la mémoire et la suite d'événements est passée au module suivant qui va générer le schéma
d'attaque correspondant.
●
Nous devons à présent définir le coeur du système, i.e. La fonction de similarité qui va nous
renvoyer le meilleur cas.
12/28
4.2.2 La Fonction de similarité
L'objectif de cette fonction est, à partir d'une suite d'événements suspicieuse et d'une base de cas contenant
des attaques (sous forme de suite d'événements), de trouver l'attaque ressemblant le plus à la séquence
observée. Cette recherche va évaluer la ressemblance entre la séquence à tester et chaque séquence de
référence. Toutes ces séquences sont sous la forme d'une suite d'événements, forme comprenant en plus les
opérateurs d'occurrence et de séquence utilisés de la manière suivante :
• l'opérateur d'occurrence permet d'agréger plusieurs éléments identiques consécutifs.
• l'opérateur de séquence permet de définir si l'ordre temporel des événements est
caractéristique de ces derniers.
Pour plus d'informations sur ces opérateurs, ainsi que sur le langage permettant de les décrire, consulter
[21], page 74, section 4.3.1.2.
Illustration 7: Les classes d'événements de sécurité
Avant de commencer à décrire la fonction de similarité, regardons les classes définissant les événements de
sécurité :
Nous nous rendons compte qu'un événement peut être vu à plusieurs niveaux :
• Le niveau 0, le plus élevé, où l'événement est vu comme un GenericSecurityEvent.
13/28
Le niveau 1, où l'événement est considéré, suivant sa nature, comme un AuditEvent ou un
NetworkEvent.
• Le niveau 2, dernier niveau, où l'on s'intéresse aux sous-classes des éléments de niveau 1.
•
De part la nature des objets à comparer, nous allons subdiviser le problème de l'étude de la similarité de
deux suites d'événements en plusieurs étapes :
• Le calcul de la similarité de deux classes de niveau 0, appelé "comparaison de base".
• La prise en compte de la similarité des classes de niveau 1 et 2, qui sera analysée lors de la
"comparaison avancée".
• Puis le calcul final de la similarité des deux suites d'événements, i.e. "la comparaison
finale".
4.2.2.1 Les bases de la fonction de similarité
L'algorithme que nous nous proposons d'utiliser, pour écrire cette fonction, est l'algorithme le plus simple
possible existant dans le Case-Based Reasoning : CBL1 (Case-Based Learning) [4] [5]. Cet algorithme est
très basique et il existe de nombreuses améliorations dont nous ne discuterons pas ici (mais qui constituent
des possibilités d'extension du système).
Voici CBL1, définissant la similarité des cas C1 et C2 :
Similarity CBL1 C 1, C 2, P  =
1
 ∑ Feature _ dissimilarity C 1 ,C 2 
i
i∈P
1
1
avec P un vecteur de caractéristiques et
{
C 1 −C 2 2
Feature _ dissimilarity C 1 ,C 2  =
0
1
i
i
1
i
Si la caractéristique i est numérique
Si la caractéristique i est discrète et C 1 =C 2
Sinon
i
i
2
Ainsi, la similarité de deux cas correspond à l'inverse de la distance euclidienne des caractéristiques
numériques et utilise un simple test de correspondance pour les caractéristiques discrètes. Pour éviter que les
caractéristiques numériques prennent plus d'importance que les autres caractéristiques, nous avons la
possibilité :
● de normaliser linéairement toutes les caractéristiques numériques (via l'utilisation d'un
préprocesseur)
● ou alors, de pondérer chaque caractéristique à l'aide d'un coefficient.
En utilisant la deuxième solution, notre fonction de calcul de la similarité devient :
Similarity C 1, C 2, P  =
1

∑ w i⋅Feature _ dissimilarity C 1 ,C 2 
i
i∈P
avec
∑ wi
i∈P
3
i
= 1, 0w i ≤1
4.2.2.1.a Espace de valeur de la fonction de similarité
Nous nous intéressons maintenant aux valeurs que peut prendre la fonction de similarité, si toutes les
caractéristiques sont discrètes. Pourquoi considérer seulement ce cas ? La majorité des caractéristiques
des nos suites d'événements sont discrètes (à une ou deux exception près), et dans la mesure du possible,
14/28
nous souhaitons éviter les caractéristiques numériques, notamment à cause de leur variation importante en
cas de dissimilarité.
Nous remarquons tout d'abord que si les cas sont similaires en tout point, la fonction de similarité tendra
vers l'infini. Laissons ce cas quelque peu spécial de côté, et intéressons nous aux extremums de la fonction.
Proposition : la valeur de retour de la fonction de similarité est comprise entre :
[
1,
1
 w min
]
où w min = Min wi
4
Démonstration : la similarité entre deux cas augmente lorsque la distance entre ceux-ci diminue. Lorsque les
deux cas sont totalement différents, (2) vaut 1 pour toutes les caractéristiques des cas, (3) devient :
1
∑ w
i∈P
3
= 1
i
d'où la borne inférieure de l'intervalle.
Lorsque deux cas, sont très très similaires ("i.e. le plus similaire possible sans être égaux"), cela revient à
dire que seule la caractéristique ayant le moins d'importance est différente. La caractéristique la plus faible
correspond au coefficient w minimal (noté wmin). (3) devient :
1
car w i = 0  pour tout w i ≠w min 
 w min
CQFD.
Néanmoins, un problème reste posé : cette espace de valeur n'est pas fixe, i.e. la borne supérieure dépend du
coefficient de pondération le plus faible. Pour cela, nous définissons une nouvelle fonction, qui ramène les
valeurs de l'intervalle (4), dans [1, 2]. Pour cela, nous appliquons une simple fonction linéaire :
Nouvel _ Intervalle  N , w min  = N⋅
 w min  1−2 ⋅ w min
1 −  w min
1−  w min
où N est une valeur dans[1,
5
1
]
 w min
Pourquoi avoir choisit [1, 2] ? Ces valeurs sont totalement arbitraires mais il était nécessaire de fixer un
ordre de grandeur comme nous le verrons plus tard. Nous verrons également pourquoi cet intervalle ne
pouvait pas être [0, 1].
4.2.2.1.b Comparaison de base
La comparaison de base se charge de calculer la similarité entre deux événements en considérant ces
événements comme des GenericSecurityEvent. Pour cela, il faut tout d'abord identifier quelle
caractéristiques de cette classe vont servir à la comparaison. Voici les membres de cette classe que nous
avons retenu (voir Illustration 7: Les classes d'événements de sécurité) :
●
●
●
●
●
EventType qui indique s'il s'agit d'un message réseau, d'une commande système, d'une
connection ou d'un fichier.
EventName qui contient le nom de la commande ou du service UDP/TCP utilisé.
EventSource qui précise la source de l'événement sous la forme d'une adresse IP.
EventDestination parallèlement concerne la cible de l'événement.
EventResult, qui permet de savoir le résultat de l'événement (en terme de succès/échec, mais
aussi en terme de légitimité de l'action).
Maintenant que ces caractéristiques ont été isolées, il faut à présent leur accorder un poids : pour cela, nous
15/28
devons garder à l'esprit que ce poids sanctionne la non similarité des caractéristiques. Ainsi, EventType et
EventName sont pour nous des attributs très importants pour définir la dissimilarité de deux cas.
Parallèlement, la différence des adresses sources ou destinations n'as pas réellement de poids dans la
comparaison : ces données ne permettent pas de définir une attaque (puisque l'attaque peut survenir
depuis/vers n'importe quel poste). Si les adresses sont identiques, la comparaison "récompensera" cette
attribut en renvoyant 0 (via la fonction (2)), dans le cas contraire, le score final ne sera pas affecté par cette
différence.
Voici le vecteur de poids w que nous proposons pour les caractéristiques respectives {EventType,
EventName, EventSource, EventDest, EventResult} :
w={
1 1 1 1 1
, , , , }
3 3 12 12 6
6
Tous les paramètres de la comparaison de base sont à présent définis : deux GenericSecurityEvent, C1 et C2
sont comparés grâce à la fonction Similarity (voir (3)), suivant les caractéristiques énoncées plus haut et la
pondération w (6). Le résultat est un nombre décimal à ramener dans l'intervalle [1, 2], via la fonction
Nouvel_Intervalle (voir (5)).
4.2.2.2 Comparaison avancée.
La comparaison avancée rajoute l'information des classes de niveaux 1 et 2 à la comparaison de base. L'idée
principale ici est de descendre dans la hiérarchie des classes et d'ajuster la similarité suivant la nature des
objets comparés.
Voici donc la fonction effectuant la comparaison avancée :
Similarity Avancée C 1, C 2  = Moy Harmonique Similarity 1 C 1, C 2, P  , Similarity 2 C 1, C 2, P ' 
avec Similarity 1 C 1, C 2, P  = Nouvel _ Intervalle Similarity C 1, C 2, P  , w min 
7
8
La moyenne harmonique de deux valeurs étant définit ainsi :
Moy Harmonique  A , B =
1
1 ,1
Moy Arithmétique 

A B
9
L'utilisation de la moyenne harmonique se justifie par le fait que les fonctions de calcul de similarité
renvoient des inverses de distance. Si nous avions utilisé une moyenne arithmétique, quel sens donner à une
moyenne d'inverse de distance ? La moyenne harmonique calcule la moyenne des distances, puis renvoi
l'inverse de cette moyenne : c'est un inverse de moyenne de distance, dont la signification paraît plus
naturelle. Néanmoins, l'utilisation de cette fonction nous empêche d'autoriser les fonctions de calcul de
similarité à renvoyer une valeur nulle, d'où l'intervalle choisit : [1, 2].
Avant de définir Similarity2, remarquons tout d'abord que les classes de niveau 1 (AuditEvent et
NetworkEvent) n'ont toutes deux qu'une seule caractéristique, respectivement UserName et ProtocolType
(voir Illustration 7: Les classes d'événements de sécurité). Nous arrivons donc à cette définition :
Soit
16/28
P i ∈[1, 2] avec P 1 P 2 ~ P 3
Sc  A= A vue comme une sous - classe de niveau 2
Similarity 2 C 1 , C 2  =
i
i
{
1
si C 1 et C 2 ne sont pas de la même classe (de niveau 1 ou 2)
Si C 1 et C 2 sont de niveau 1 :
Max [2, P 1 Similarity 2 Sc C 1  , Sc C 2 ] , si C 1 . cara=C 2 . cara
Max [2, P 2 Similarity 2 Sc C 1  , Sc C 2 ] , si C 1 . cara≠C 2 . cara
10
Si C 1 et C 2 sont de niveau 2 :
Max [2, P 3 Similarity 1 C 1, C 2 ]
Nous remarquons que Similarity2 est une fonction récursive à deux niveaux : au premier (resp. deuxième)
niveau elle compare des classes de niveau 1 (resp. 2). Quel que soit le niveau, si les cas ne sont pas de même
classe, alors ils n'ont certainement pas des caractéristiques similaires, d'où la valeur la plus faible sur
l'intervalle [1, 2].
Lorsque Similarity2 compare des classes de niveau 2, elle effectue juste un simple calcul de similarité, en
ramenant la valeur de retour sur [1, 2] (via (8)), en lui ajoutant une constante P3 et en majorant le résultat par
la valeur maximale de similarité, 2.
Voici les caractéristiques retenues pour les classes de niveau 2, ainsi que leur pondérations (voir (3))
proposées respectives :
[
FileEvent={FileName 0.375 , FileType 0.25 , FileAccessType 0.375}
FileSystem={UsedCPURate 0.5 , MemOccupationRate 0.5}
ConnectionEvent={Endtime 0.5 , Duration 0.5}
ICMPEvent={ICMPType 0.5 , ICMPCode 0.5}
TCPEvent={TCPSquenceNumber 0.5 , AcknowledgeNumber 0.5}
UDPEvent {SourcePort 0.25 , DestinationPort 0.75}
]
11
La comparaison de niveau 1 est un peu spéciale parce que, comme expliqué précédemment, les classes de
niveau 1 n'ont qu'une seule caractéristique. Suivant la similarité de cette caractéristique, une constante d'une
certaine valeur est ajoutée, et un appel récursif est effectué pour calculer la similarité des cas C1 et C2 en les
considérant comme des instances de classe de niveau 2.
Les constantes Pi sont présentes pour rappeler le fait que les objets comparés sont de classes identiques
(donc que leur similarité est un peu plus élevée), même si leurs caractéristiques ne sont pas similaires. Voici
une proposition pour les Pi :
P={0.5, 0 .15, 0 .15}
12
Notons que P1 est plus élevé car il doit refléter que la caractéristique de niveau 2 est similaire pour les deux
cas.
Avant de conclure sur le calcul de la similarité de suite d'événements, intéressons nous au cas où, à
17/28
n'importe quel niveau de la comparaison, deux cas parfaitement identiques sont découverts. Dans cette
situation, la fonction (3) diverge vers l'infini et donc toute la récursivité de la fonction (9) est écrasée par
cette valeur, même si en amont, les cas ne sont pas similaires. Pour cela, nous considérons que si une
similarité parfaite est découverte, nous remplaçons l'infini par la valeur maximal sur l'intervalle [1, 2], i.e. 2
(ce remplacement ne figure pas dans la définition de la fonction, afin d'alléger la notation). Cela revient à
faire une approximation, puisque nous "oublions" qu'une telle similarité a été découverte, mais cette
approximation est négligeable devant les autres paramètres du système (tels que les coefficients de
pondération ou les Pi).
A ce point de l'étude de la fonction de similarité, nous pouvons parfaitement comparer deux événements et
calculer leur similarité sur l'intervalle [1, 2]. Nous nous intéressons maintenant à la comparaison finale.
4.2.2.3 Comparaison finale.
Comme expliqué précédemment, la comparaison finale permet, à partir d'une base de cas contenant des
attaques (sous la forme d'une suite d'événements) de chercher le cas de référence le plus similaire à une suite
d'événements suspicieuse donnée. Cette recherche doit prendre en compte deux opérateurs présents dans les
deux suites :
• l'opérateur d'occurrence qui permet d'agréger plusieurs éléments identiques consécutifs.
• l'opérateur de séquence qui permet de définir si l'ordre temporel des événements est
caractéristique de ces derniers.
4.2.2.3.a Algorithme de base.
Avant d'effectuer la comparaison finale, nous devons tout d'abord définir la comparaison de deux suites
d'événements. Soit C2 le cas de référence. Subdivisons les cas ainsi :
Comparaison suite C 1, C 2  =
{
Comparaison suite _ atemporelle C 1, C 2  Si l'ordre temporel n'est pas présent dans C 2
Comparaison suite _ temporelle C 1, C 2  Si l'ordre temporel est présent dans C 2
13
4.2.2.3.b Cas où l'ordre temporel n'est pas présent
Notons A la suite d'événements suspicieuse, Ai étant les événements de cette suite i∈[1, N A ]
Soit B la base des cas de référence, B j étant un cas j ∈[1, M ] , B j k étant un événement de ce cas k ∈[1, N  B  ]
j
{
Pour chaque  B j k (événement) :
Pour chaque Ai (événement) :
Calculer S i k  = Similarité avancée _ occ  Ai , B j k 
Comparaison suite _ atemporelle  A , B j  =
Pour chaque  B j k (évènement) :
Calculer SMAX k = Distribuer _ les _ similarités S , k 
Calculer S Total = Moy Harmonique  SMAX k 
14
18/28
{
Chercher i max tel que S i k =Max  S i k  , pour k ∈[1, N  B  ]
si i max n'est pas marqué et
avec Distribuer _ les _ similarités  S , k n  =
si  S i k =Max S i k  , pour i∈[1, N A ] , i non marqué
marquer i et renvoyer S i k 
sinon recommencer en cherchant i max−1 , etc...
avec Similarité avancée _ occ C 1, C 2  =
max
max
n
j
n
max
{
Similarité Avancée C 1, C 2 
Max [2, Q 1 Similarité Avancée C 1, C 2 ]
Max [2, Q 2 Similarité Avancée C 1, C 2 ]
Max [2, Q 1 Similarité Avancée C 1, C 2 ]
n
si
si
si
si
C 1. occ=1 et C 2. occ=1
C 1. occ=C 2. occ
C 1. occC 2. occ
C 1. occC 2. occ
Cet algorithme va balayer tous les événements d'un cas de référence Bj et chercher le meilleur accord
possible, entre les événements d'un suite suspicieuse et les siens. Ce meilleur accord s'effectue via la
fonction Distribuer_les_similarités qui permet de chercher l'évènement Ai le plus similaire à un événement
(Bj)k seulement si aucun autre événement de Bj n'est plus similaire à Ai . Voici un exemple d'exécution de cet
algorithme sur le tableau des S(i k) suivant :
[
1.2 1.1 1
soit S = 1
1
1
1.5 1 1.7
]
Soit B (resp. A) les colonnes (resp. lignes) de S. Regardons :
• Distribuer_les_similarités(S, B1) : le maximum de la colonne est en A3, mais (B1, A3) n'est
pas le maximum de la ligne A3. Nous prenons le second maximum, A1 (et nous marquons la
ligne A1). D'où la réponse 1.2.
• Distribuer_les_similarités(S, B2) : le maximum de la colonne est en A1, mais la ligne A1
est marqué. Nous prenons donc le second maximum et nous marquons la ligne A2. D'où la
réponse 1.
• Distribuer_les_similarités(S, B3) : le maximum de la colonne est en A3, qui n'est pas prise,
et (B3, A3) est le maximum de la ligne A3. Nous prenons donc le maximum et nous
marquons la ligne A3. D'où la réponse 1.7.
•
Note : Une situation bloquante peut survenir si une colonne n'a que des minimums :
[
1.2 1 1.1
soit S = 1.1 1 1.2
1.5 1 1
]
Ici, lors du choix de B2, A3 est déjà marqué par B1 et aucune valeur ne peut être prise par A2 . Solution :
effectuer auparavant tous les autres passages, ici celui de B3, et effectuer à nouveau celui de B2, en
l'autorisant à prendre une ligne libre, même si il n'est pas maximum sur cette ligne. Cette situation n'est pas
présente dans l'algorithme pour alléger la notation.
19/28
La fonction Similaritéavancée_occ permet de prendre en compte les occurrences des événements lors du calcul
de la similarité : si les événements n'ont pas d'occurrence multiple, leur similarité n'est pas modifiée. Au
contraire, si leur occurrence est égale, un bonus leur est accordé. Ce bonus est identique si le nombre
d'occurrence de la suite d'événements suspicieuse est supérieure à celui du cas référence. En effet, nous
pouvons considérer que l'attaque est reconnue même si des événements en plus sont observés. En revanche,
si moins d'événements ont été observés que dans le cas de référence, le bonus est moins important. Voici un
ordre de grandeur des bonus accordés :
Q={0.3, 0 .1}
15
Note : Nous pourrions pondérer le bonus Q2 par le nombre d'occurrences manquantes, c'est une possibilité
qui ne figure pas dans notre modèle, afin de l'alléger quelque peu, mais tout à fait envisageable.
Une fois que le meilleur accord possible a été déterminé, via la fonction Distribuer_les_similarités,
l'algorithme effectue une moyenne harmonique (voir (8)) sur toutes les similarités entre événements, pour
déterminer la similarité globale entre deux suites d'événements.
4.2.2.3.c Cas où l'ordre temporel est présent
L'idée de cet algorithme est de prendre un par un les événements du cas de référence et de chercher à quel
moment le cas le plus similaire est survenu dans la suite suspicieuse (en cherchant la similarité maximale).
Une fois que la position est trouvée, nous retenons son index (c'est le couple (imax, k)), et nous créons un
sous-ensemble V, qui comprend les événements de la suite suspicieuse, de l'élément suivant l'index jusqu'à la
fin de la suite. Lorsque nous effectuerons la recherche suivante, avec l'événement suivant du cas de
référence, nous travaillerons seulement sur l'ensemble V.
{
première _ comparaison
Pour chaque  B j k (événement) :
Soit V le sous intervalle de [i max 1, k −1 , N A ]
Si V =∅
S i k =1
Sinon
Comparaison suite _ temporelle  A , B j  =
Pour chaque Ai (événement), i∈V
Calculer S i k  = Similarité avancée _ occ  Ai , B j k 
Chercher i max , k  tel que S i k  = Max S i k  pour i∈V
Si S i k Tmin
i max , k =i max , k −1 et S i k =1
Calculer S Total = Moy Harmonique S i k  , pour k ∈[1, N  B  ]
max
max
max
max
max
j
20/28
16
{
Pour  B j 1,
Pour chaque Ai (événement) :
Calculer S i 1 = Similarité avancée _ occ  Ai , B j 1 
avec première _ comparaison =
Chercher i max , 1 tel que S i 1 = Max S i 1  pour i∈[1, N A ]
Si S i 1T min
i max , 1=1, 1 et S i 1=1
max
max
max
La fonction première_comparaison effectue un passage pour le premier événement du cas de référence :
cette fonction distincte est nécessaire pour initialiser l'espace V au début de l'algorithme.
Le fait de toujours réduire l'ensemble de recherche permet de garantir l'ordre temporel : ainsi, tous les
événements redondants de la suite suspicieuse sont écartés (et donc ne baissent pas la similarité). Si à un
moment donné l'ensemble V est vide, cela signifie qu'il manque des événements à la suite suspicieuse, et
donc nous pénalisons le calcul de la similarité avec 1 (pas de similarité).
Un problème peut survenir si, à n'importe quel moment de l'algorithme, nous ne trouvons pas un événement
du cas de référence dans la séquence suspicieuse : toutes les notes de similarité seraient alors médiocres et
l'espace V pourrait se réduire considérablement en effaçant des événements importants. Pour cela, nous
utilisons une constante (Tmin) garantissant un taux minimal de similarité avant d'entamer la réduction de
l'espace. Si, par exemple, à un moment donné un événement est absent de la suite suspicieuse, le taux
maximal de cet événement sera exécrable, nous le remplacerons par 1 (pas de similarité) puis nous passons à
l'événement suivant sans réduction de l'espace V. Voici un ordre de grandeur de ce seuil :
T min=1.1
16
A présent, nous avons complètement défini la fonction Comparaisonsuite (voir (13)), que ce soit dans le cas
temporel et atemporel. Nous pouvons donc très simplement, définir la comparaison finale, qui, rappelons le,
permet de trouver le cas le plus similaire à une attaque potentielle. Ses paramètres sont une suite suspicieuse
C et une base de cas B :
Comparaison finale C , B =
{
Pour chaque B j , calculer S j = Comparaison suite C , B j 
17
Le meilleur cas est B meilleur , tel que S meilleur = Max S j  , j∈[1, N B ]
4.2.2.4 Cas d'indécisions
Ces cas se produisent lorsque :
● plusieurs cas de la mémoire sont candidats à l'élection pour le cas de référence et que leurs taux
de similarité sont trop proches les uns des autres pour les départager,
● un cas de référence est trouvé, mais son taux de similarité est très légèrement inférieur au taux
minimal requis (Tmin ) : nous souhaitons quand même minimiser le taux d'échecs lors de la
recherche du cas de référence.
Nous proposons donc des critères de comparaison avancés effectués lors de tests de rattrapage pour régler
ces cas. Cependant, nous ne développerons pas plus en avant ces critères, l'objectif de ce rapport étant juste
la démonstration de notre modèle d'apprentissage de base.
4.2.2.4.a Prise en compte de la durée entre deux événements
21/28
La durée entre deux événements dans une suite suspicieuse n'est pas présente dans le système existant. Pour
cela, nous nous proposons de rajouter un champ EventTime dans la suite EventSeriesFeatures (voir [21]) qui
comprendrait deux séries de deux index, ΔT et Δt. Voici la définition de ces index :
Soit une suite E i d'événements . Soit { E 0, ... , E n } ces événements .
Soit {TE 0, ... ,TE n } les temps où ces événements se sont produits.
Nous définissons  T i = TE i −TE 0 le temps entre le premier événement et l'événement E i .
Nous définissons  t i = TE i −TE i−1 le temps entre les événements E i et E i−1 , avec  t 0 = 0 .
t2
Soit 
E 0, 
E 1, E 2 ,... avec TE i = {1, 2, 4 } ,
T 2
Nous avons donc  T i = {0, 1, 3 } et  t i = {0, 1, 2 } .
Ces durées peuvent donc être utilisées dans la comparaison de deux suites d'événements afin d'affiner le
calcul de leur similarité.
4.2.2.4.b Blacklistes et connaissances de l'agent.
Dans le système existant, l'agent dispose de connaissances à caractère permanents tels que ([21]) :
● les informations de configuration du réseau (équipements, utilisateurs, applications);
● la liste des utilisateurs connus/ groupes d’utilisateurs;
● la liste des machines connues;
● a liste des adresses connues (internes/externes, local/intranet/extranet), adresses interdites,
réservées, impossibles;
● la liste des utilisateurs ayant la fonction d'administrateur et liste des administrateurs par
machine;
● la liste des utilisateurs suspects/ attaquants : Ce sont les blacklistes.
● la liste des adresses suspicieuses/ attaquantes : Ce sont les adresses à surveiller ou à interdire
l’accès;
● la liste des utilisateurs autorisés à se connecter de l’extérieur du réseau distribué.
● la liste des utilisateurs absents : ce sont les utilisateurs en congé, en mission ou en arrêt maladie.
Si un cas d'indécision se produisait, il serait possible d'utiliser ces connaissances à caractère permanent afin
de définir une attaque.
4.2.2.4.c Reconstruction temporelle.
Il faut remarquer que les événements issus du filtrage avancé ne sont pas les seuls à être soumis au moteur
de délibération du CBR : comme nous pouvons le voir sur l'Illustration 5, les suites d'événements
suspicieuses non reconnues dans le système de base sont elles aussi soumises au CBR (cercle ( ) numéroté
2). Si un cas d'indécision se produit, nous pourrions utiliser l'algorithme suivant :
● si une suite issue du filtrage avancé est reconnue par le CBR comme un cas de référence avec une
certaine similarité S
● alors, nous pouvons chercher, en reconstruisant la suite temporelle 1 + 2, des événements
supplémentaires dans 1 permettant d'obtenir une similarité plus élevée.
L'inverse est aussi vrai (i.e. reconstruire 1 + 2 pour chercher dans 2 des événements manquants à
l'identification de 1).
22/28
Note : cette reconstruction temporelle n'est obligatoire que si le cas de référence nécessite un ordre
temporel. Si ce n'est pas le cas, cette reconstruction n'est pas effectuée et la recherche est tout de suite
lancée.
4.2.2.5 Performance et améliorations
Intéressons nous à présent à la complexité des trois fonctions, avec n le nombre d'événements dans la suite
suspicieuse, m le nombre moyen d'événements dans un cas de référence et M le nombre de cas de référence :
● Comparaisonsuite_atemporelle : environ o(2.m.n).
● Comparaisonsuite_temporelle : environ o(2.m.n) au pire des cas (i.e. V ne diminue que d'un élément à
la fois).
● Comparaisonfinale : environ o(2.m.n.M) + o(M) (pour le calcul du maximum).
Voici un ordre de grandeur des entités utilisées par la fonction de similarité :
● Nombre d'événements de A (i.e. NA) : 10.
● Nombre moyen d'événements dans une attaque de référence : 10.
● Nombre de cas de référence dans la base : 1000.
Nous nous apercevons que la complexité du système augmente quadratiquement quand la taille des données
augmente linéairement, ce qui n'est pas bon.
Il existe de nombreuses améliorations disponibles pour CBL1, portant sur des éléments divers tels que
l'organisation des structures de données de la base des cas, le pré-traitement des données ou une approche
probabilitiste (voir [4] et [3]). Sans rentrer dans des améliorations complexes, nous proposons de diminuer
le nombre de calculs de similarité inutiles grâce à cet algorithme :
●
Avant qu'une suite suspicieuse soit analysée, nous construisons une table d'index contenant les
EventName (de la classe GenericSecurityEvent) ainsi que leur numéro d'événement :
Par exemple la suite suivante :
Evénement 1 EventName=Telnet
Evénement 2 EventName=SSH
Evénement 3 EventName=Telnet
[
]
entraîne la table d'index :
[
EventName=Telnet [1, 3]
EventName=SSH
[2]
]
Ainsi, au lieu de parcourir tous les événements de la suite A (par exemple dans Comparaisonsuite_temporelle),
pour calculer leur similarité avec un événement Bi, nous ne parcourons que les événements de A qui ont le
même EventName que celui de Bi.
Cela revient à faire une approximation, puisque nous ne testons que les cas susceptibles d'offrir une
similarité élevée, mais cela nous permet de diminuer la complexité du système : en considérant que nous ne
balayons plus que 10% des événements de A, et en utilisant l'ordre de valeur énoncé plus haut, la complexité
des fonctions devient :
Comparaisonsuite_atemporelle : environ o(2.m) + o(n).
Comparaisonsuite_temporelle : environ o(2.m) + o(n).
Comparaisonfinale : environ o(2.m.M) + o(M) + o(n)
Note : les o(n) dans les Comparaisonsuite proviennent de la construction de la table d'index, qui se fait en
temps linéaire.
●
●
●
La complexité de l'algorithme reste quadratique, mais dans la comparaison de deux suites devient linéaire.
Une mise en pratique de ces tables d'index à un niveau plus haut (i.e. pour comparer la suite suspicieuse
avec seulement les cas intéressants) serait intéressante pour obtenir une complexité logarithmique sur tout
l'algorithme. Cette optimisation, ainsi que toutes les autres, ouvre la possibilité à de nombreux travaux
futurs.
23/28
4.2.2.6 Le peuplement initial de la base des cas.
Jusqu'à présent, nous avons supposé que la base des cas était peuplée. Le problème qui se pose à présent est
comment remplir cette base. Nous ne pouvons partir d'une mémoire vierge, car l'administrateur serait alors
activement sollicité pour identifier les suites suspicieuses (et cela reviendrait à effectuer une phase
d'apprentissage ce dont nous désirons nous passer).
Pour répondre à ce problème, nous supposons que la base des cas est importée à partir d'une source
sécurisée et certifiée, un serveur ftp universitaire regroupant toutes les bases de cas de référence. Ces
mémoires de référence peuvent êtres :
● Écrites à la main par des experts.
● L'oeuvre de contribution des utilisateurs du système.
● En provenance d'un autre système/logiciel. Dans ce cas, les mémoires de référence seraient
converties dans le bon format.
A présent, le moteur de CBR ainsi que tous ses éléments sont totalement définis. Nous pouvons passer à la
dernière étape, la mise à jour des politiques.
4.2.3 Génération du schéma d'attaque et mise à jour des politiques.
Nous supposons qu'une attaque (ou une variante) a été détectée : nous allons nous intéresser au module
construction du schéma correspondant + mise à jour des politiques de sécurité (en ( ) sur l'Illustration 5).
Bien que cette partie du système n'ait pas été finalisée, nous proposons le protocole général suivant :
● Le schéma d'attaque correspondant à la suite d'événements est généré : lors de cette génération,
un algorithme doit déterminer quels événements sont caractéristiques de l'attaque, quels attributs
(par exemple la source de l'attaque) peuvent être omis, si le temps entre deux événements est
significatif, si l'ordre temporel est nécessaire, etc... Cet algorithme abouti à un schéma d'attaque
dont certains attributs sont positionnés (i.e. ont une valeur), et d'autres sont laissés génériques.
● Sur la confirmation de l'administrateur, les politiques de sécurité sont modifiées pour prendre
en compte la nouvelle attaque découverte, attaque qui sera ensuite transmise aux agents
ultérieurement. Nous considérons que la génération des schémas d'attaque est un point trop
critique pour être réalisé de manière entièrement automatisée, et que, par conséquent, une
intervention humaine est nécessaire avant la mise à jour de la base des schémas d'attaque. Si
l'administrateur refuse de reconnaître une attaque, la suite d'événements est aussi retirée de la
mémoire des cas.
4.2.4 Conclusion sur le modèle
Dans cette section, nous avons décrit notre modèle fondé sur le CBR pour la détection d'intrusions
inconnues. Ce modèle est constitué de trois sous-modèles : un modèle pour l'extension du filtrage des
événements, un modèle pour le moteur de CBR et enfin un dernier modèle pour la génération automatique
des schémas d'attaque ainsi que la mise à jour des politiques de sécurité. Bien que la fonction de génération
de schéma et de mise à jour des politiques de sécurité ne soit pas complètement spécifiée, le coeur de notre
modèle (filtrage et moteur de CBR) l'est. En effet, nous avons défini la fonction de similarité qui est le
composant essentiel du moteur CBR et qui permet d'identifier des attaques inconnues. Cette fonction qui a
été construite à partir d'un algorithme générique simple (CBL1) et qui a fortement enrichi cet algorithme,
nous permet de calculer la similarité de deux objets complexes.
24/28
5. Conclusion
A travers ce travail, nous pouvons voir que tous les IDS existants sont confrontés aux problèmes de
l'extraction, la catégorisation et la prise de décision à partir d'un large volume de données, afin de détecter
les attaques se produisant dans un système, en particulier les attaques inconnues. Différentes approches ont
été définies pour répondre à certains de ces problèmes, en particulier une approche très populaire, le Data
Mining, qui a largement prouvé son efficacité pour l'extraction et la classification d'événements à partir d'un
large volume de données. Cependant, cette approche, comme nous l'avons expliqué dans la section 2.2.3,
présente certains inconvénients, qui nous ont poussé à nous orienter vers le Cased-Base Reasoning, une
nouvelle approche qui n'a, jusqu'à présent, pas été appliquée dans le domaine de la détection d'intrusions.
En nous basant sur cette approche, nous avons conçu un nouveau modèle pour la détection d'attaques
inconnues. Ce modèle a été intégré à un système de détection d'intrusions à base d'agents, qui ne détectait
que des attaques connues.
La phase de conception étant terminée, nous prévoyons de valider notre modèle par une application
logicielle. D'autre part, en ce qui concerne le moteur CBR (le coeur de notre système), nous avons proposé
plusieurs optimisations qu'une étude empirique permettra de confirmer.
25/28
6. Index des illustrations
Illustration 1: Un exemple de règles générées par RIPPER................................................................. 5
Illustration 2: Les principales étapes d'un algorithme de CBR.............................................................6
Illustration 3: Le modèle organisationnel du système existant.............................................................8
Illustration 4: Le modèle événementiel du système existant................................................................ 9
Illustration 5: Vue interne du modèle d'apprentissage........................................................................10
Illustration 6: Le moteur de délibération du CBR.............................................................................. 11
Illustration 7: Les classes d'événements de sécurité........................................................................... 12
26/28
7. Table des matières
1. Introduction...................................................................................................................................... 2
2. État de l'art........................................................................................................................................ 3
2.1 La détection d'intrusions............................................................................................................ 3
2.2 Le Data Mining et la classification de données d'audit..............................................................4
2.2.1 Le Data Mining dans les approches par scénarios............................................................. 5
2.2.2 Le Data Mining dans les approches comportementales..................................................... 5
2.2.3 La nécessité d'une autre approche...................................................................................... 6
2.3 Le Case-Based Reasoning..........................................................................................................6
2.4 Conclusion................................................................................................................................. 7
3. Système de détections d'intrusion base d'agents intelligents............................................................ 8
3.1 Le modèle organisationnel......................................................................................................... 8
3.2 Le modèle événementiel............................................................................................................ 9
3.3 Conclusion sur le système existant............................................................................................ 9
4. Le modèle d'apprentissage.............................................................................................................. 10
4.1 Extension du filtrage des événements......................................................................................10
4.2 Mise en place des éléments du moteur de CBR.......................................................................11
4.2.1 Notre algorithme de Case-Based Reasoning ................................................................... 11
4.2.2 La Fonction de similarité................................................................................................. 11
4.2.2.1 Les bases de la fonction de similarité.......................................................................13
4.2.2.1.a Espace de valeur de la fonction de similarité....................................................13
4.2.2.1.b Comparaison de base........................................................................................ 14
4.2.2.2 Comparaison avancée...............................................................................................15
4.2.2.3 Comparaison finale...................................................................................................17
4.2.2.3.a Algorithme de base........................................................................................... 17
4.2.2.3.b Cas où l'ordre temporel n'est pas présent.......................................................... 17
4.2.2.3.c Cas où l'ordre temporel est présent................................................................... 19
4.2.2.4 Cas d'indécisions...................................................................................................... 20
4.2.2.4.a Prise en compte de la durée entre deux événements......................................... 20
4.2.2.4.b Blacklistes et connaissances de l'agent............................................................. 21
4.2.2.4.c Reconstruction temporelle................................................................................ 21
4.2.2.5 Performance et améliorations................................................................................... 21
4.2.2.6 Le peuplement initial de la base des cas...................................................................22
4.2.3 Génération du schéma d'attaque et mise à jour des politiques......................................... 22
4.2.4 Conclusion sur le modèle................................................................................................. 23
5. Conclusion...................................................................................................................................... 24
6. Index des illustrations.....................................................................................................................25
8. Bibliographie.................................................................................................................................. 27
27/28
8. Bibliographie
1: Knowledge-Intensive Case-Based Reasoning and Sustained Learning, Agnar Aamodt,
Proceedings of the 9th European Conference on Artificial Intelligence (ECAI-90), 1990.
2: Explanation-Driven Retrieval, Reuse and Learning of Cases, Agnar Aamodt, Proceddings of
EWCBR-93, 1993.
3: Case-Based Reasoning : Foundational Issues, Methodological Variations, and System
Approaches, Agnar Aamodt & Enric Plaza, AI Communications Vol. 7 Nr. 1, 1994.
4: Case-Based Learning Algorithms, David W. Aha, Proceeding of the 1991 DARPA Case-Based
Reasonning Workshop, 1991.
5: Weighting Features, Dietrich Wettschereck & David W. Aha, ICCBR-95, 1995.
6: Cooperation Modes among Case-Based Reasoning Agents, Enric Plaza, Josep Lluis Arcos and
Francisco Martin, Proceeding of the ECAI'96 Workshop on Learning in Distributed AI Systems,
1996.
7: Similarity, Uncertainty and Case-Based Reasoning in PATDEX, Michael M. Richter, Stefan
Wess, Automated reasoning, essays in honour of Woody Bledsoe, Kluwer, pp. 249-265, 1991.
8: ADAM : Detecting Intrusions by Data Mining, Daniel Barbará, Julia Couto, Sushil Jajodia,
Leonard Popyack & NingNing Wu, Proceedings of the 2001 IEEE Workshop on Information
Assurance and Security, 2001.
9: Data Mining : A New Intrusion Detection Approach, Dary Alexandra Pena Maldonado, GIAC
Security Essentials Certification Practical Assignement [SANS Institute], June 2003.
10: Intelligents Agents for Intrusion Detection, Guy G. Helmer, Johnny S. K. Wong, Vasant
Honavar & Les Miller, Proceedings, IEEE Information Technology Conference pp 121-124, 1998.
11: Lightweight Agents for Intrusion Detection, Guy Helmer, Johnny S. K. Wong, Vasant Honavar
& Les Miller, the Journal of Systems and Software, 2000.
12: Automated Discovery of Concise Predictive Rules for Intrusion Detection, Guy Helmer, Johnny
S.K. Wong, Vasant Honavar & Les Miller, the Journal of Systems and Software 60, 2002.
13: Artificial Intelligence and Intrusion Detection : Current and Future Directions, Jeremy Franck,
Division of Computer Science, University of California at Davis, 1994.
14: Intrusion Detection with Unlabeled Data Using Clustering, Leonid Portnoy, ACM Workshop on
Data Mining Applied to Security (DMSA 2001), 2001.
15: Cost-Base Modeling for Fraud and Intrusion Detection : Results from the JAM Project,
Salvatore J. Stolfo, Andreas Prodromidis, Wenke Lee, Wei Fan & Philip K. Chan, Proceedings of
the DARPA Information Survivability Conference and Exposition, IEEE Computer Press pp. 130144, 2000.
16: Java Agents for Meta-Learning over Distributed Databases, Salvatore Stolfo, Andreas L.
Prodromidis, Shelley Tselepis, Wenke Lee, Dave W. Fan & Philip K. Chan, American Association
for Artificial Intelligence, 1997.
17: Data Mining Approaches for Intrusion Detection, Wenke Lee & Salvatore J. Stolfo, Proceedings
of the 7th USENIX Security Symposium, 1998.
18: A Data Mining Framework for Building Intrusion Detection Models, Wenke Lee, Salvatore J.
Stolfo & Kui W. Mok, IEEE Symposium on Security and Privacy, 1999.
19: Fast Effective Rule Induction, William W. Cohen, Machine Learning : Proceedings of the
Twelfth International Conference (ML95), 1995.
20: Feature Selection Using a Genetic Algorithm for Intrusion Detection, Guy Helmer, Johnny
Wong, Vasant Honavar & Les Miller, Proceedings, Genetic and Evolutionary Computation
Conference, Orlando, 1999.
21: Détection d'intrusions : Une nouvelle approche par systèmes multi-agents, Karima Boudaoud,
Ecole Polytechnique Fédérale de Lausanne, 2000.
28/28