Détection d’anomalies – IDS

L’IDS doit, à partir du modèle établi lors de la phase d’apprentissage,

per-mettre de détecter les anomalies dans des communications : il s’agit de la phase de

détection. Lorsque le modèle de référence est mis en place, l’IDS traite de la même

manière les spectrogrammes reçus par la sonde de manière continue en extrayant

les attributs représentatifs précédemment définis. L’erreur est ensuite directement

calculée, toujours en continu, à partir des sorties obtenues. L’IDS implémente donc

simplement le modèle appris, place en entrée les attributs extraits puis récupère les

sorties et les compare pour en extraire une erreur. Par la suite, c’est sur la base de

cette erreur qu’une alarme est déclenchée ou non. Ce mécanisme de déclenchement

d’alarme en fonction d’une erreur est appelée la génération d’alarmes.

En considérant que les phases précédentes ont été réalisées, c’est-à-dire que la

phase d’apprentissage a été réalisée et que le ou les modèles de référence appris

soient implémentés par l’IDS, ce dernier est alors en mesure de mettre en place la

génération d’alarmes permettant de réaliser une détection d’anomalies. Dans la

gé-nération d’alarmes mise en place par notre solution, le processus permettant à l’IDS

de notifier la présence d’une anomalie au sein d’une fenêtre de R spectrogrammes

se déroule en 4 étapes : 1) le vecteur d’attributs correspondant aux données de R

spectrogrammes est extrait ; 2) ce vecteur est fourni en entrée du modèle de

réfé-rence, qui va essayer de le reconstruire à partir de ses connaissances, c’est l’étape

de prédiction ; 3) une erreur est calculée pour chaque couple d’entrée-sortie selon

l’équation présentée en 4.2, formant ainsi un vecteur d’erreur Erreur; 4) à partir

des données d’apprentissage, la densité de probabilité de l’erreur pour chaque

attri-but a été estimée tel que présenté dans [Luvison 2009] en approchant la distriattri-bution

de chaque erreur par une gaussienne. Le vecteur d’erreur établi dans l’étape

pré-cédente est donc comparé avec cette densité de probabilité. Si une erreur dépasse

un seuilS, appelé seuil de détection, tel qu’un grand pourcentage des erreurs

obte-nues soient inférieures à celle-ci, alors ce vecteur d’erreur est considéré comme peu

probable, une alarme est donc levée par l’IDS.

Erreur(i) =sortie

−entree

, i∈ {1, R×8} (4.2)

Le paramétrage de ce seuil de détection est nécessaire pour éviter de détecter un

trop grand nombre de faux positifs, c’est-à-dire de lever une alerte alors qu’aucune

attaque n’a été effectuée. La détermination de cette valeur seuil dans

l’implémen-tation dépend du niveau de sécurité à mettre en place dans l’environnement, si

celui-ci est très élevé, alors le seuil de détection doit être bas, quitte à avoir des

alertes ne correspondant à aucune attaque. Cependant, nous considérons que dans

le cadre d’un domicile connecté, un détecteur qui lève trop souvent des alertes risque

d’exaspérer les utilisateurs. Dans notre implémentation, cette valeur seuil est donc

déterminée à partir d’une partie des données d’apprentissage, appelé plus tard jeu

de validation : lorsque le modèle est établi, des données sans attaques sont injectées

dans l’IDS et les vecteurs d’erreurs sont calculés pour chaque vecteur d’attribut. La

densité de probabilité de ces vecteurs d’erreurs est ensuite estimée, et le seuil de

détection est défini comme étant la valeur telle que 97% des erreurs calculées soient

inférieures à ce seuil. Ce 97% est également égal au calcul duT N R (Taux de Vrais

Négatifs ou True Negative Rate en anglais), qui correspond à calculer le taux de

données classées comme étant sans attaque. Cela signifie donc que seulement 3%

des erreurs calculées à partir de données sans attaque lève une fausse alerte.

Concernant l’architecture nécessaire pour mettre en place ce détecteur, celui-ci

n’effectue que deux actions qui ne sont que peu coûteuses. Comme montré

précédem-ment, le pré-traitement des spectrogrammes ne requiert pas une puissance de calcul

élevée et peut être effectué sur un composant à bas coût. Quant à l’implémentation

du modèle de référence, celui-ci n’impose pas non plus d’architecture particulière,

puisqu’il ne s’agit que d’effectuer une série d’opérations sur un peu moins d’une

centaine de nombres flottants et de comparer une différence avec une densité de

probabilité pour déterminer l’erreur. L’IDS peut donc tout à fait s’intégrer à un

composant tel qu’un point d’accès du domicile.

4.4 Conclusion

Dans ce chapitre nous avons vu et discuté la possibilité de déploiement de

l’ap-proche générique présentée notamment dans un type d’environnement particulier :

les domiciles connectés. Nous avons tout d’abord défini les problématiques et les

hy-pothèses considérées liés à la connectivité et aux comportements des utilisateurs et

des objets dans ce type d’environnement. Ensuite, nous avons présenté les éléments

d’implémentation nécessaires, du point de vue de la phase d’apprentissage et de la

phase de détection, pour une installation respectueuse des contraintes précédentes.

L’implémentation réalisée pour ce contexte est fonctionnelle, et le prochain chapitre

détaille les expérimentations que nous avons menées pour évaluer notre solution.

Chapitre 5

Expérimentations & Résultats

Sommaire

5.1 Introduction . . . . 81 5.2 Environnement expérimental . . . . 82

5.2.1 Mise en place d’un environnement de test réaliste . . . 82 5.2.2 Composition de l’environnement et comportements . . . 83

5.3 Protocole expérimental . . . . 85

5.3.1 Installation de la solution . . . 85 5.3.2 Collecte des données . . . 86 5.3.3 Apprentissage du modèle . . . 88 5.4 Évaluation . . . . 91 5.4.1 Protocole d’évaluation . . . 91 5.4.2 Génération d’attaques . . . 92 5.4.3 Injection d’attaques . . . 94 5.4.4 Métriques d’évaluation . . . 95 5.4.5 Résultats et discussions . . . 97 5.4.6 Quantification du risque associée à la détection d’anomalies . 100

5.5 Conclusion . . . 102 5.6 Synthèse de la partie III . . . 102

5.1 Introduction

Ce chapitre présente les expérimentations réalisées dans le cadre du

déploie-ment de notre solution dans le contexte d’un domicile connecté. Dans une première

partie, nous détaillons la mise en place de la solution dans un environnement réel

représentatif, un appartement équipé d’un ensemble d’objets connectés. Ensuite, la

composition de l’environnement est présentée, notamment les caractéristiques de

celui-ci vis-à-vis des objets installés et de leurs comportements, ainsi que celui des

utilisateurs de cette expérimentation. Le protocole expérimental réalisé pour

véri-fier et évaluer la solution est par la suite décrit, présentant notamment les jeux de

données à récolter pour établir le modèle de référence puis la méthode d’injection

ainsi que les attaques à mettre en oeuvre pour évaluer les capacités de détection de

notre approche dans cet environnement. Finalement, les résultats sont présentés et

discutés dans une dernière section avant de conclure.