Télécharger le fichier original (Mémoire de fin d’études)

Construire un bon détecteur

De nombreux paramètres sont à prendre en compte lors du choix d’un détecteur d’ano-malies. Si la qualité de la détection est bien sûr à prendre en compte, l’utilisation d’un détecteur nécessite aussi la mobilisation de ressources, qu’elles soient liées au travail d’un administrateur ou aux infrastructures nécessaires à l’exécution du détecteur. Chaque solu-tion nécessite alors une véritable analyse coût-bénéfice.
Exhausitivité et robustesse. L’utilité d’un détecteur est tout d’abord conditionnée par sa capacité à détecter les anomalies, de manière efficace et inconditionnelle. La qualité de la détection est donc l’un des paramètres à prendre en compte lors du choix d’une solution. La sensibilité (ou taux de vrais positifs) d’un détecteur correspond à sa capacité à lever une alerte lorsqu’une anomalie est présente dans le trafic. Un détecteur idéal est alors très sensible, détectant toutes les anomalies présentes dans le trafic.
Aussi, un détecteur utilisable doit pouvoir opérer en temps réel sur le trafic tout en détectant les anomalies au plus tôt, avant qu’elle ne cause des dommages irrémédiables au système visé.
Il doit enfin être robuste, pouvant opérer en toutes situations. Un pic d’utilisation ne doit notamment pas perturber le bon fonctionnement du détecteur. En cas d’attaque, le détecteur doit rester opérationnel autant que possible, au moins le temps qu’une contre-mesure puisse être mise en place.
Réduction du travail de l’administrateur. Le travail de l’administrateur est l’un des coûts importants à considérer pour l’adoption d’un détecteur. Son temps est précieux, un bon détecteur doit donc tout faire pour limiter l’intervention de l’administrateur. Plusieurs points sont alors à prendre en compte.
Si un détecteur détectant toutes les anomalies serait évidemment intéressant, le fait est que, dans un cas réaliste, un détecteur très sensible peut avoir tendance à générer des alertes alors qu’aucune anomalie n’est présente dans le trafic. On parle alors d’un faux positif. La sensibilité d’un détecteur, évoquée plus tôt, est par conséquent toujours à considérer conjointement avec le taux de faux positifs, soit la proportion d’alarmes levées ne correspondant pas à une vraie anomalie. La capacité d’un détecteur à générer peu de faux positifs est alors primordiale, l’analyse de chacune de ces fausses alertes gaspillant le temps de l’administrateur. Lorsque le détecteur génère un trop grand nombre de ces faux positifs, l’administrateur peut, dans le pire des cas, perdre confiance et finir par ignorer les alertes générées.
Ceci dit, au-delà de la qualité de la détection en elle-même, ce sont les résultats produits par le détecteur qui permettent une gestion efficace des anomalies. Lorsqu’il lève une alerte, un bon détecteur doit alors fournir à l’administrateur assez d’informations pour une prise de décision avisée, notamment lorsque le détecteur ne peut produire une information assurément fiable. Le détecteur doit notamment produire une caractérisation de l’anomalie, c’est-à-dire une liste d’attributs permettant de tracer une frontière entre le trafic normal et celui de l’anomalie. Aussi, lorsque plusieurs évènements sont détectés, mais correspondant à une même anomalie, le détecteur doit être capable de corréler ces évènements et doit fournir l’ensemble de ces informations de manière compacte. Les outils d’analyse fournis avec un détecteur, graphiques ou non, font donc partie intégrante d’une solution.
Si un détecteur fournissant des informations pertinentes est un avantage, un détecteur capable d’opérer de manière autonome la plupart du temps est bien plus appréciable encore. Cette autonomie repose sur plusieurs critères.
Tous d’abord, à condition qu’il dispose de suffisamment d’informations, un détecteur doit pourvoir appliquer automatiquement des contre-mesures si l’anomalie détectée est assurément un danger au bon fonctionnement du système. L’échelle de temps nécessaire à l’intervention d’un administrateur étant généralement bien plus grande que celle nécessaire à un traitement automatique, c’est un avantage certain.
L’autonomie d’un détecteur est aussi conditionnée par le travail nécessaire à l’installa-tion et la mise à jour du détecteur. Le détecteur doit pouvoir opérer sur des trafics fon-damentalement différents et s’adapter de manière fluide à la fois aux évolutions du trafic normal mais aussi à l’apparition de nouvelles attaques et anomalies. Un détecteur auto-nome propose généralement une approche proactive, il ne nécessite l’intervention

Problématique

ministrateur que lorsque un évènement suspect a été effectivement détecté. Aussi, lorsque l’administrateur a pris une décision vis-à-vis d’une anomalie, un détecteur autonome sera capable de prendre en compte cette décision, et appliquera, si une anomalie similaire se présente, la même décision automatiquement. Ceci étant dit, une approche totalement autonome n’est par réaliste. L’intervention de l’administrateur sera toujours nécessaire, puisque la définition même d’une anomalie dé-pend de la politique de sécurité à appliquer, et qu’elle est forcément en constante évolution.
Coût matériel. Le travail de l’administrateur n’est pas le seul coût à prendre en compte lors de l’utilisation d’un détecteur. Chaque solution nécessite l’utilisation de plus ou moins de ressources de calcul. Suivant l’architecture sur laquelle repose le détecteur, ces ressources peuvent être limitées, notamment lorsque la détection n’opère pas sur un matériel dédié. L’utilisation d’un détecteur nécessitant des ressources de calcul modérées, et si possible, constantes, peut donc être nécessaire.

Difficultés

Si la construction d’un détecteur d’anomalies nécessite de prendre en compte de nom-breux paramètres, certaines difficultés ne sont pas inhérentes à la construction de tels détecteurs mais plutôt aux conditions dans lesquelles ils doivent opérer.
Évolution et disparités du trafic
Tous d’abord, force est de constater l’augmentation constante du trafic depuis plusieurs années. Le rapport d’Akamai du troisième trimestre 2017 [3] sur l’état d’Internet fait état, de 2010 à 2016, d’un quadruplement (de 20151 pétaoctets par mois à 88719) du trafic Internet et d’une augmentation de 70% du nombre d’utilisateurs (de 2, 0 à 3, 4 milliards). Cette évolution, expliquée et par le développement économique de plusieurs pays, et par le développement récent de l’Internet des objets, a conduit à la multiplication des équipements connectés à Internet, et par conséquent du trafic produit. Cette évolution a aussi un impact sur la nature du trafic. Le streaming vidéo, toujours plus populaire, représente désormais une grande partie du trafic traversant les réseaux (50% en France d’après le même rapport). Les applications supportées par le réseau sont toujours plus diverses.
Aussi, Internet est un réseau disparate. Chaque réseau connecté à Internet peut suppor-ter des applications très diverses, résultant en des propriétés statistiques significativement différentes d’un point à l’autre du réseau. Les seuils de détection doivent être adaptés en conséquence, suivant le trafic, mais aussi suivant la politique de sécurité à appliquer.
Cette disparité spatiale s’ajoute à une disparité temporelle, liée par exemple aux cycles d’utilisation journaliers de la plupart des services.
La disparité et l’évolution du trafic ont deux conséquences directes : un détecteur par-fait construit à un moment donné peut devenir inefficace en peu de temps, et un détecteur efficace en un endroit du réseau peut être complètement inefficace ailleurs. Construire des détecteurs capables de s’adapter au trafic de manière autonome devient plus qu’un avan-tage, une nécessité. Aussi, les débits actuels requièrent l’utilisation de solutions pouvant, ou passer facilement à l’échelle, ou pouvant opérer à des débits très importants (à l’aide de matériel dédié par exemple).
Le cas particulier des attaques par déni de service distribuées S’ajoutent aux difficultés liées à l’évolution du trafic légitime, celles dues à la multi-plication des anomalies, à la fois en nombre et en type. Les attaques sont des anomalies particulières puisqu’elles sont la conséquence du désir de nuire d’un attaquant. L’intérêt de l’attaquant est par conséquent que son attaque reste difficile à détecter et à contrer. Plusieurs techniques d’évasion lui sont alors disponibles afin de faire passer le trafic nuisible pour du trafic légitime. Aussi, l’attaquant peut potentiellement exploiter des faiblesses de conception inhérentes à certains détecteurs pour les rendre inopérants. Certaines attaques peuvent alors profiter de la complexité algorithmique de certains détecteurs pour épuiser leurs ressources, ce qui peut permettre de cacher une attaque sous une surcharge à priori inoffensive.
Un type d’attaque régulièrement utilisé dans ce but est l’attaque par déni de service distribuée. Ce type d’attaque vise à épuiser les ressources de la victime grâce à un très grand nombre de fausses requêtes. Comme illustré par la figure 1.2, ces attaques sont géné-ralement lancées à l’aide de botnets, un ensemble de machines contrôlées par un attaquant et réparties sur le réseau. De telles attaques ont des conséquences graves, pouvant entraîner la paralysie des systèmes visés. En effet, d’après un rapport de Neustar [4] interrogeant un panel de 1010 entreprises, plus de 60% des entreprises interrogées estiment le coût de l’indisponibilité de leurs services à plus de $100.000 par heure. Le détail de ces réponses est détaillé sur la figure 1.3. D’après ce même rapport, plus de 50% de ces attaques nécessitent plus de 3 h pour être atténuées. Comme illustré par le graphique 1.4, les débits considérés sont conséquents.
Si le risque dû à une seule de ces attaques peut alors se chiffrer en millions de dollars, il doit encore être multiplié par leur fréquence. Toujours d’après la même étude, 84% des entreprises interrogées ont subi une attaque DDoS en 2017, contre 73% en 2016. La figure 1.5 illustre les résultats obtenus lors de la consultation sur la fréquence des attaques.

Table des matières

1 Introduction
1.1 Le projet AATAC
1.2 Problématique
1.2.1 Construire un bon détecteur
Exhausitivité et robustesse.
Réduction du travail de l’administrateur.
Coût matériel.
1.2.2 Difficultés
Évolution et disparités du trafic
Le cas particulier des attaques par déni de service distribuées
1.2.3 Résumé
1.3 Contributions
1.3.1 AATAC, un nouvel algorithme de détection d’anomalies
1.3.2 Évaluation des performances d’AATAC en conditions réelles
1.3.3 Impact de différentes techniques d’échantillonnage sur les performances
de l’algorithme
1.4 Résumé
1.5 Plan
2 État de l’art
2.1 Systèmes experts
2.2 Approches supervisées et semi-supervisées
2.2.1 Réseaux de neurones artificiels
2.2.2 SVM
2.2.3 Règles d’association
2.2.4 Méthodes ensemblistes
2.2.5 Autres méthodes de classification
2.2.6 Considérations relatives aux détecteurs supervisés
2.3 Approches non-supervisées
2.3.1 Détection de changement
2.3.2 Approches statistiques
2.3.3 Analyse des plus proches voisins
2.3.4 Techniques de clustering
2.3.5 Techniques supervisées adaptées
2.3.6 Autre techniques
2.3.7 Considérations relatives aux détecteurs non-supervisés
2.4 Détecteurs hybrides
2.5 Résumé
3 AATAC
3.1 Vue d’ensemble
3.2 Traitement continu
3.2.1 Construction des attributs du trafic
3.2.2 Mise à jour incrémentale de la densité des cellules
3.3 Traitement discret
3.3.1 Mise à jour de la structure de données
3.3.2 Création des prototypes d’histogrammes
3.3.3 Construction et stockage de l’instantané du trafic
3.3.4 Détection des instantanés anormaux
3.4 Diagnostic de l’anomalie
3.5 Paramètres de l’algorithme
3.6 Résumé
4 Évaluation
4.1 Évaluation de la qualité de la détection
4.1.1 Jeu de données
4.1.2 Courbes ROC
4.1.3 Limites des courbes ROC
4.1.4 Courbe d’opération et efficacité de la détection
4.1.5 Choix des paramètres
4.1.6 Résultats
4.2 Évaluation de la capacité du détecteur à opérer en temps réel
4.2.1 Traces capturées
4.2.2 Mesure des performances
4.2.3 Résultats
4.3 Comparaison avec FastNetMon et ORUNADA
4.4 Conclusion
5 Impact de l’échantillonnage sur les performances d’AATAC
5.1 Techniques d’échantillonnage
5.2 Protocole d’évaluation
5.2.1 Techniques d’échantillonnage utilisant le nombre de paquets
5.2.2 Techniques d’échantillonnage temporel
5.3 Résultats de l’évaluation sur du trafic échantillonné
5.3.1 Impact sur la qualité de la détection
5.3.2 Impact sur les ressources de calcul
5.3.3 Comparaison avec FastNetMon
5.4 Résumé
6 Conclusion
6.1 Contributions
6.1.1 AATAC
6.1.2 Évaluation d’AATAC sur deux jeux de données
6.1.3 Impact de l’échantillonnage sur la détection
6.2 Perspectives
6.2.1 Une meilleure caractérisation des anomalies
6.2.2 Échantillonnage idéal
6.2.3 Résistance aux slow growth
6.3 Résumé
Acronymes

Télécharger le rapport complet