Évaluation de la détection d’anomalies

7.4.3 Évaluation du diagnostic fréquentiel . . . 127 7.4.4 Évaluation du diagnostic spatial . . . 127

7.5 Injection d’attaques réalistes . . . 127

7.5.1 Attaques injectées . . . 128 7.5.2 Anomalies non prévues . . . 129

7.6 Résultats de l’évaluation . . . 129

7.6.1 Résultats de la détection d’anomalies . . . 129 7.6.2 Résultats du diagnostic temporel . . . 130 7.6.3 Résultats du diagnostic fréquentiel . . . 132 7.6.4 Résultats du diagnostic spatial . . . 133

7.7 Discussions . . . 134

7.7.1 Limites globales de l’approche . . . 135 7.7.2 Comparaison expérimentale des environnements étudiés . . . 136 7.7.3 Vie privée . . . 138 7.7.4 Amélioration du diagnostic spatial . . . 139

7.8 Conclusion . . . 140 7.9 Synthèse de la partie IV . . . 140

7.1 Introduction

Ce chapitre décrit les expérimentations réalisées pour évaluer le déploiement et

l’implémentation de notre solution dans un contexte professionnel. Tout d’abord,

nous présentons l’environnement expérimental mis en place pour évaluer notre

ap-proche. Ensuite, nous détaillons les différents paramétrages des modèles utilisés

pour réaliser les diagnostics. Le protocole expérimental et les moyens mis en oeuvre

pour évaluer ces mécanismes sont détaillés dans la section suivante, en insistant sur

l’injection d’attaques représentatives. Finalement, nous listons les résultats

d’éva-luations associées à chacun des éléments de diagnostic mis en oeuvre, en précisant

leurs limites et leur efficacité, avant de discuter ces résultats dans une dernière

section.

7.2 Environnement expérimental

Pour évaluer notre solution, nous mettons en place un environnement

expéri-mental professionnel réaliste, c’est-à-dire composé d’un grand nombre d’objets

hé-térogènes et de nombreux utilisateurs aux comportements distincts. Ensuite, nous

injectons des attaques dans l’environnement pour vérifier les capacités de détection

et de diagnostic de notre approche déployée.

7.2.1 Composition de l’environnement et déploiement de

l’ap-proche

L’environnement expérimental utilisé pour valider l’approche proposée est

illus-tré par la figure 7.1. Il correspond à une salle de travail qui accueille les étudiants

de Master durant leur période de stage. C’est une salle relativement occupée et

visitée toute l’année, notamment car elle est utilisée pour les pauses cafés. Celle-ci

a été équipée d’un grand nombre d’objets connectés représentatifs et pouvant être

achetés dans le commerce. La table 7.1 décrit l’ensemble des objets installés, ainsi

que leur rôle et la technologie qu’ils utilisent. Les comportements des utilisateurs

ne sont pas simulés, ils peuvent ainsi interagir avec les objets connectés ou venir

avec leurs propres objets, pour recréer les comportements BYOD. Cependant, pour

assurer des activités radios régulières, nous automatisons certaines actions sur tous

les objets positionnés (par exemple, la sonnette sonne aléatoirement deux fois par

jour). Pour réaliser ces tâches automatisées, nous instrumentons deux HackRF qui

rejouent des commandes auprès des différents objets.

Trois sondes sont déployées (numérotées 1, 2 et 3), chacune basée sur deux

composants, comme présenté dans la section 3.3 : un HackRF One comme

périphé-rique SDR et un Raspberry Pi 3B pour traiter lessweeps. Chaque Raspberry Pi est

connecté en Ethernet au serveur implémentant l’IDS. Pour des facilités de

dévelop-pement, nous avons décidé de stocker l’ensemble des spectrogrammes au sein de ce

serveur.

Nous monitorons trois bandes de fréquences distinctes : 400-500 MHz et

800-900 MHz, qui sont généralement employées au sein des objets domotiques et des

smart-phones, ainsi que 2.4-2.5 GHz, utilisées par un grand nombre de technologies

sans-fil (WiFi, Zigbee, etc.) [Al-Fuqaha 2015]. Chaque sonde est équipée d’une

an-tenne sensible à l’une de ces bandes : 400-500 MHz pour la sonde 1, 800-900 MHz

7.2. Environnement expérimental 123

Figure 7.1 – Environnement connecté

Table 7.1 – Objets connectés de la salle d’expérimentation

Nom Rôle Technologie Qté

D-Link Camera Vidéo-surveillance WiFi/2.4–2.5 GHz 1

Phones, Laptops Téléphonie et Internet WiFi/2.4–2.5 GHz 5+

Philips Hue Ampoule ZigBee/2.4–2.5 GHz 1

Beewi Smartbulb Ampoule BLE/2.4–2.5 GHz 1

Keyboard & mouse Périphériques sans-fil ESB/2.4–2.5 GHz 2

WiFi Access Points Point d’accès WiFi/2.4–2.5 GHz 2

Smart outlet Nityam Prise électrique 868 MHz 3

Bricelec doorbell Sonnette 433 MHz 1

HackRF One Émetteur automatique 433 MHz 1

HackRF One Émetteur automatique 868 MHz 1

Samsung Smart TV Télévision connectée 470–800 MHz/2.4–2.5 GHz 1

pour la sonde 2 et 2.4-2.5 GHz pour la sonde 3.

Nous établissons la résolution fréquentielle des sweeps (1/bw) à 10 mesures

par MHz, ce qui correspond à 3000 mesures pour l’ensemble des trois bandes de

100 MHz. Chaque sweep prend 37.5 ms pour scanner toutes les bandes, ce qui

cor-respond à une résolution temporelle 1/T de 27sweepspar seconde. Pour rappel, les

notations utilisées ici sont présentées dans la section 3.4. Contrairement à notre

im-plémentation pour les domiciles, chaque mesure est sauvegardée sur un octet, pour

limiter la taille des données enregistrées. Ainsi, 80 ko de données sont mesurées par

chaque sonde chaque seconde. Au total, plus de 2 Go sont collectés chaque jour.

7.2.2 Caractéristiques techniques des composants de l’approche

Dans notre expérimentation, l’IDS s’exécute sur un serveur équipé d’un Intel

Core i7-7700 cadencé à 4.2 GHz, 32 Go de RAM et d’une carte graphique Nvidia

GTX-1080-Ti. Cependant, nous ne pensons pas qu’il soit nécessaire d’avoir un

ser-veur aussi puissant. En effet, un ordinateur 30 fois plus lent serait suffisant pour

traiter les données venant des sondes en temps réel. Dans le cas de notre

expé-rimentation, les données sont traitées hors-ligne mais nous sommes confiants que

notre système pourrait fonctionner en ligne puisqu’il nous faut environ 20.407 s

pour traiter l’ensemble des spectrogrammes enregistrés, correspondant à 700,815 s

de mesure.

7.3 Paramétrage des modèles

7.3.1 Pré-traitement

Dans notre expérimentation, le niveau de bruit est situé à environ -65 dBm et les

sondes ne mesurent aucune puissance dépassant les 0 dBm, nous établissons donc

le seuil maximumB

u

et le seuil minimal B

l

à respectivement 0 dBm et -50 dBm.

7.3.2 Estimation de l’erreur de reconstruction

Nous découpons chaque spectrogramme en morceaux dont les dimensions sont

16×1000 :N = 16 étant la dimension temporelle (600 ms) et 1000 étant la dimension

fréquentielle (une des trois bandes monitorées), c’est-à-dire le nombre de mesures

par sweep. La dimension temporelle de 600 ms est un compromis : si celle-ci est

trop faible, l’auto-encodeur ne sera pas capable d’apprendre de longues activités

radios ; si elle est trop grande, le nombre de paramètres à apprendre pour le modèle

serait trop élevé et l’apprentissage nécessiterait trop de données. Concernant les

hyperparamètres de l’auto-encodeur, nous choisissons les valeurs suivantes :

1. les entrées, composées de 16×1000 attributs ;

2. une couche convolutive à une dimension avec 500 filtres et une fenêtre

tem-porelle de 5, utilisant la fonction d’activation ReLu ;

3. la couche du goulot d’étranglement, une couche dense avec 2000 attributs,

employant la fonction d’activation sigmoïde ;

4. une couche dense de sortie, avec 16×1000 sorties, utilisant la fonction

d’ac-tivation sigmoïde.

Nous utilisons la même architecture pour chaque bande, ainsi les résultats ne

sont pas affectés par le comportement spécifique de chaque bande. Ici, la taille

7.4. Protocole expérimental 125

optimale de la couche d’étranglement dépend du trafic sur la bande considérée. En

effet, les bandes avec peu de communications (par exemple 800-900 MHz) pourraient

employer une couche plus fine pour éviter le surapprentissage ; au contraire, les

bandes très utilisées (comme 2.4-2.5 GHz) pourraient nécessiter une couche plus

large pour apprendre correctement les comportements radios. Nous avons établi un

compromis en définissant 2000 attributs. Ce modèle est implémenté et appris grâce

à Keras [Chollet 2015] reposant sur Tensorflow.

Une recherche plus exhaustive des hyperparamètres améliorerait sans aucun

doute nos résultats, mais ces travaux ne rentrent pas dans le cadre de notre

pro-position qui se focalise sur la preuve de concept liée à une approche de diagnostic

indépendante de la spécification des protocoles.

Pour la phase d’apprentissage, nous établissons à 80% la superposition des

fe-nêtres glissantes consécutives pour maximiser la quantité de données disponibles.

Dans le cadre du jeu de test, celle-ci est de 20%.

7.3.3 Diagnostic temporel

Nous utilisons deux seuils d’erreurs τ : un pour les jours de la semaine entre

8 heures et 19 heures 30, et un pour le reste (week-end et nuits). Le jeu de test

comporte un jour férié. Cependant, cette information n’est pas fournie à l’IDS.

Nous estimons le seuil d’erreur τ à l’aide du 99

th

percentile du score des séries

temporelles du jeu d’apprentissage pour chaque bande et chaque sonde, et nous

estimonsT (le seuil d’erreur cumulatif) au 99.995

th

percentile des erreurs cumulées

à l’aide de la fonction d’erreur appliquée au jeu d’apprentissage, et ce pour chaque

sonde et chaque bande.

7.3.4 Diagnostic spatial

La calibration est effectuée en envoyant trois signaux à différentes puissances

(5 dBm, 20 dBm et 40 dBm) sur la fréquence centrale de chacune des bandes

(450 MHz, 850 MHz et 2.45 GHz) à 40 positions distinctes. Ces signaux sont ensuite

monitorés par les sondes positionnées dans l’environnement. Nous implémentons

l’algorithme des k plus proches voisins pour estimer la position d’une anomalie à

partir de ces données de calibration. Nous fixons k = 6 et utilisons une distance

euclidienne classique entre les SNR. La largeur de la bande autour de la fréquence

centrale est fixée àδ

_f

= 0.2 MHz.

7.4 Protocole expérimental

Pour le jeu d’apprentissage, nous réalisons la collecte entre le 19 mars et le 27

mars 2019 (8 jours). Nous collectons deux jeux de tests. Le premier jeu, mesuré entre

le 28 mars et le 3 avril, ne contient qu’une seule position d’injection d’attaque, la

position F (visible sur la figure 7.2). Le second jeu, mesuré le 7, 8, 13 et 14 mai 2019,

contient quant à lui des attaques effectuées à plusieurs positions. Nous réalisons 4

Figure7.2 – Position des attaques dans l’environnement

évaluations distinctes sur ces jeux de données, pour vérifier la pertinence de la

détection, puis des différentes phases de diagnostic réalisées.

7.4.1 Évaluation de la détection d’anomalies

Pour évaluer les capacités de détection de notre solution, nous mesurons la

pro-portion d’attaques ayant une intersection avec les intervalles de détection estimés

par les sondes sur la même bande. Autrement dit, une attaque est considérée

dé-tectée si une alarme est levée durant son exécution.

Dans le document Détection d'intrusion dans des environnements connectés sans-fil par l'analyse des activités radio (Page 134-139)