Réalisation d’un système de détection des attaques contre les web services SOAP moyennant les méthodes de fusion de classifieurs

Table of Contents

Rèsumè

Abstract

Rèsumè en Arabe

Liste des Figures

Liste des Tableaux

Introduction

1 Méthodes de combinaison de classifieurs
1.1 Introduction à l’apprentissage automatique
1.1.1 Définition de la classification supervisée
1.1.2 Définition d’un classifieur
1.1.3 Type de sorties d’un classifieur
1.1.4 Processus de classification supervisée
1.1.5 Quelques algorithmes de classification supervisée
1.1.6 Synthèse
1.2 Les méthodes de combinaison de classifieurs
1.2.1 Définition de la combinaison de classifieurs
1.2.2 Architectures de combinaison de classifieurs :
1.2.3 Méthodes de combinaison Parallèles
1.2.4 Fusion de classifieurs différents
1.2.4.1 Fusion non paramétrique
1.2.4.2 Synthèse
1.2.5 Méthodes de sélection de classifieurs
1.2.5.1 Principe
1.2.5.2 Motivations de la sélection
1.2.5.3 Méthodes de sélection
1.2.6 Étude comparative entre les méthodes de combinaison ...
1.2.6.1 Comparaison entre les méthodes de Fusion
1.2.6.2 Comparaison entre les méthodes de sélection
1.2.6.3 Comparaison entre les méthodes de fusion et de sélection
1.3 Synthèse Générale
1.4 Conclusion

2 Les web services
2.1 Introduction
2.2 Généralités sur les Services Web
2.2.1 Définition des services web
2.2.2 Web services basés sur SOAP
2.2.2.1 Définition SOAP
2.2.2.2 Structure d’un message SOAP
2.3 Failles de sécurité dans les WS
2.3.1 Attaques relatives à SOAP
2.3.1.1 Attaques relatives au header SOAP
2.3.1.2 SOAP message flooding
2.3.2 Coercive Parsing
2.3.3 Attaque relatif au contenu XML
2.3.3.1 Injection SQL
2.3.3.2 Injection XML
2.4 Solutions de Sécurisation Existantes
2.4.1 Utilisation des parseurs SAX
2.4.2 Normes de sécurité XML
2.4.3 WS-Security
2.4.4 Firewall XML
2.4.5 IDS pour les web services
2.5 Travaux Similaires
2.5.1 Les solutions proposées
2.5.1.1 Système multi agents pour la détection des mes­sages SOAP malicieux
2.5.1.2 Extraction de règles d’association à partir de l’analyse des attaques relatif à XML
2.5.1.3 Sécurisation des transactions via la détection des anomalies dans les documents XML
2.5.1.4 Système multi-agents pour la détection des attaques Dos orientées WS
2.5.1.5 Approche Pot de miel pour détecter les attaques contre SOAP
2.5.1.6 Détection des attaques injection profil visant les systèmes de recommandation
2.5.2 Synthèse
2.5.3 Observations relevées sur les solutions proposées
2.6 Conclusion

3 Conception
3.1 Introduction
3.2 Solution Proposée
3.3 Étude des besoins
3.3.1 Identification des acteurs du système
3.3.2 Capture des besoins fonctionnels et non fonctionnels du sys­tème
3.3.2.1 Besoins fonctionnels
3.3.2.2 Besoins non fonctionnels (techniques)
3.4 Architecture Globale du système
3.5 Description détaillée des modules
3.5.1 Module de Prétraitement
3.5.1.1 Espace Caractéristique relatif à la classification prélim­inaire
3.5.1.2 Espace Caractéristique relatif à la classification XDos
3.5.1.3 Espace Caractéristique relatif à la classification des Injections
3.5.1.4 simulation d’un cas pratique de prétraitement ...
3.5.2 Module de Classification
3.5.2.1 Choix de l’architecture de combinaison
3.5.2.2 Choix du type de Fusion
3.5.2.3 Choix de la méthode de sélection des classifieurs . .
3.5.2.4 Choix des classifieurs à combiner
3.5.2.5 Choix de l’architecture globale du système
3.5.2.6 Classification Préliminaire
3.5.2.7 Classification XDos
3.5.2.8 Classification Injection
3.5.3 Application des AGs
3.5.4 Module de Mapping
3.6 Conclusion

4 Réalisation et Tests
4.1 Introduction
4.2 Environnement du développement
4.2.1 Langage de programmation
4.2.2 Les bibliothèques utilisées
4.3 Résultats Expérimentaux et Interprétations
4.3.1 Environnement Expérimental
4.3.1.1 Web Services invoqués pour les tests
4.3.1.2 Génération des messages SOAP
4.3.2 Mesures d’évaluation utilisées
4.3.2.1 Mesures d’évaluation utilisées dans la phase prélim­inaire
4.3.2.2 Mesures d’évaluation utilisées dans la classification XDos/Injection
4.3.3 Résultats de la classification préliminaire
4.3.3.1 Construction des datasets
4.3.3.2 Choix du modèle de régression
4.3.3.3 Recherche des meilleurs paramètres du modèle choisis
4.3.3.4 Fixation des seuils
4.3.3.5 Synthèse
4.3.4 Résultats de la classification des attaques XDos
4.3.4.1 Construction des datasets
4.3.4.2 Apport de la fusion de classifieurs
4.3.4.3 Apport de la méthode de sélection de classifieurs .
4.3.4.4 Synthèse
4.3.5 Résultats de la classification des attaques Injections
4.3.5.1 Construction des datasets
4.3.5.2 Apport de la fusion de classifieurs
4.3.5.3 Apport de la méthode de réduction dimensionnelle
4.3.5.4 Apport de la méthode de sélection de classifieurs sans réduction dimensionnelle
4.3.5.5 Apport de la méthode de sélection de classifieurs avec réduction dimensionnelle
4.3.6 Synthèse
4.4 Synthèse générale

Synthèse Générale et Perspectives

Annexes

1 Introduction à la classification supervisée

1.1 Processus de classification supervisée

1.1.1 Prétraitement

1.1.2 Le Choix des variables prédictives

1.1.3 La Vectorisation

1.1.4 La réduction dimensionnelle

1.1.5 Construction du modèle

1.1.6 validation du modèle

1.1.7 Utilisation du modèle

2 Évaluation des performances d’un classifieur

3 Méthodes ensemblistes

3.1 Fusion non paramétrique

3.2 Fusion paramétrique

4 Méthodes de Réduction Dimensionnelle

4.0. 1 Méthodes Filter:

4.0. 2 Méthodes Wrapper:

5 Conception Logicielle

5.1 Identification des principaux scénarios (CU)

5.1.1 Cas d’utilisation Détection d’une attaque XDOS .

5.1.2 Cas d’utilisation Détection d’une attaque Injection

5.1.3 Cas d’utilisation Classification manuelle des mes­sages SOAP Indéfini

5.2 Modèle d’analyse

5.2.1 Identification des classes

5.2.2 Diagramme de classe d’analyse

5.3 Modèle de conception

5.3.1 Diagrammes de classes de conception

5.3.2 Diagrammes de séquences

Références Bibliographiques

Liste des Figures

1.1.1 Notion de classifieurs

1.1.2 Processus de classification supervisée

1.2.1 Architecture Parallèle[Heutte 05]

1.2.2 Taxonomie proposée dans [Zouari 05]

1.2.3 Matrice de décision de l’individu x

1.2.4 Fusion non paramétrique

1.2.5 Sélection de classifieurs

1.2.6 Regrouper et extraire

1.2.7 Rechercher et Sélectionner en utilisant les AGs

1.2.8 Sélection locale

1.2.9 Sélection par pondération

2.2.1 Structure d’un message SOAP [Chollet 09]

2.3.1 Récapitulatif des attaques contre les web services SOAP

3.2.1 Principe de fonctionnement du système

3.4.1 Architecture modulaire du système

3.5.1 Module de vectorisation détaillé

3.5.2 Partie DTD

3.5.3 Enveloppe du message SOAP

3.5.4 Ajustement de l’opérateur de fusion

3.5.5 Choix des classifieurs

3.5.6 Architecture globale parallèle

3.5.7 Architecture globale Série

3.5.8 Architecture globale Hybride

3.5.9 Processus de Classification Préliminaire

3.5.10 Traitement attaque XDos

3.5.11 Processus de Classification XDos

3.5.12 Traitement attaque injection

3.5.13 Processus de Classification Injection

3.5.14 Articles relatif à l’application des AGs dans la classification

3.5.15 Structure du Chromosome

4.3.1 Architecture Globale du Système

4.3.2 Comparaison entre les algorithmes de régression

4.3.3 Comparaison entre les modèles de régression après variation de leurs paramètres

4.3.4 Évaluation des modèles de régression après affinage des paramètres

4.3.5 Configuration retenue pour le modèle de régression

4.3.6 Fixation seuils approximatives des méthodes GetUserInfo et Sub­scribe (respectivement)

4.3.7 Synthèse étude XDos

4.3.8 impact AG et réduction dimensionnelle sur le temps de prédiction

4.3.9 impact AG et réduction dimensionnelle sur taux de fausses alertes

4.3.10 impact AG et réduction dimensionnelle sur l’accuracy

.1 Matrice de confusion

.1 Fusion paramétrique

.1 Package Classification

.2 Package Configuration

.3 Package Vectorisation

.4 Diagramme de classe de conception

.5 Diagramme de séquence du CU traitement XDos

.6 Diagramme de séquence du CU traitement Injection

.7 Diagramme de séquence du CU Cas Indéfini

Liste des Tableaux

1.2 Classification supervisée

1.3 Principaux Algorithmes de classification supervisée

1.4 Comparaison entre les algorithmes de classification

1.5 Méthodes de combinaison de classifieurs

1.6 Comparaison entre les opérateurs de fusion non paramétriques . .

1.7 Tableau comparatif des méthodes de combinaison de classifieurs (Sélection)

1.8 Tableau comparatif des méthodes de combinaison de classifieurs (Fusion/Sélection)

2.1 Attributs Entete SOAP [Keita 10]

2.2 Contre mesures [Ghourabi 10]

2.3 Récapitulatif des principaux cas d’études

2.4 Récapitulatif des principaux cas d’études

2.5 Tableau comparatif des solutions présentées

2.6 Evaluation des travaux présentés

3.1 Modules du système

3.2 Attributs préliminaire du message SOAP

3.3 Espace caractéristique XDos

3.4 Exemples de Caractéres d’injections

3.5 Vecteur caractéristique préliminaire

3.6 Vecteur caractéristique XDOS

3.7 Vecteur caractéristique Injection

3.8 Tableau Comparatif des architectures globales du système

3.9 Paramètres de l’AG

4.1 Mesures d’évaluation

4.2 Mesures d’évaluation utilisées

4.3 Plan de tests de construction du modèle préliminaire

4.4 Constitution du dataset relative à la Phase de tests 1

4.5 Observations et Interprétation des résultats du Test n°1

4.6 Observations et Interprétation des résultats du Test n°2

4.7 Observation et interprétation pour la fixation des seuils

4.8 Fixation des seuils

4.9 Plan de Test Classification XDos

4.10 Constitution du dataset relatif à GetUserInfo

4.11 Constitution du dataset relatif à Subscribe

4.12 Espace caractéristique XDos

4.13 Paramètres mono-classifieur

4.14 Ensembles de tests XDos Partie 1

4.15 Ensembles de tests XDos Partie 2

4.16 Ensembles de tests XDos Partie3

4.17 Résultats relatifs à la méthode GetUserInfo (moins de 5 classifieurs)

4.18 Résultats relatifs à la méthode GetUserInfo (plus de 5 classifieurs)

4.19 Résultats relatifs à la méthode Subscribe (plus de 5 classifieurs) .

4.20 Résultats d’optimisation XDos relatifs à la méthode GetUserInfo (de 3 à 5 classifieurs )

4.21 Résultats optimisation XDos relatifs à la méthode GetUserInfo (plus de 5 classifieurs )

4.22 Résultats optimisation XDos relatifs à la méthode Subscribe (plus de 5 classifieurs)

4.23 Plan de Test Classification Injections

4.24 Constitution du dataset relative à GetUserInfo

4.25 Constitution du dataset relative à Subscribe

4.26 Vectorisation TFIDF

4.27 Ensembles de tests Injections Partie 1

4.28 Ensembles de tests Injections Partie 3

4.29 Résultats relatifs à la méthode GetUserInfo Partie 1

4.30 Résultats relatifs à la méthode GetUserInfo Partie 2

4.31 Résultats réduction dimensionnelle à la méthode GetUserInfo (plus de 5 classifieurs)

4.32 Résultats d’optimisation relatifs à la méthode GetUserInfo (plus de 5 classifieurs)

4.33 Résultats d’optimisation et réduction relatifs à la méthode Ge­tUserInfo

1 Méthodes de combinaison de classifieurs de type classe

2 Entités du système

3 Contrôleurs du système

4 Interfaces du système

Liste des abréviations

illustration not visible in this excerpt

Glossaire

Ensemble learning: désigne les méthodes de combinaison de classifieurs.

La réutilisation des services: signifie la possibilité de réutiliser des services par plusieurs consommateurs.

La composition des services: elle est liée à la réutilisation. La composition est possible grâce à la modularité des services et permet d’assurer une fonction­nalité plus importante, en s’appuyant sur la composition de services.

L’autonomie des services: elle assure la réutilisation et la composition des services. L’autonomie peut être définie par la capacité des services à manipuler ses ressources, contrôler son état et exécuter ses fonctionnalités, sans appui extérieur.

L’interopérabilité des services: c’est à dire leur interconnexion sans pro­grammation spécifique.

W3C: est un acronyme signifiant « World Wide Web Consortium ». Il s’agit d’une organisation mondiale régissant les grands standards techniques du web. Son rôle est majeur afin de définir les mêmes règles pour les développeurs web du monde entier.

Couplage faible :Le couplage mesure la dépendance entre des classes ou des modules.Le faible couplage favorise la faible dépendance entre les classes, la ré­duction de l’impact des changements dans une classe, la réutilisation des classes ou modules.

Couplage fort : c’est la forte dépendance entre les classe et les modules (ex: utilisation des variables globales).

Introduction

Cadre Général et Objectifs

Avec l’interconnexion des systèmes d’informations ou plus précisément l’expansion des services en lignes via le cloud, le besoin d’exposer ces services vers l’extérieur est devenu croissant. Les Services Web sont une solution maintenant éprouvée qui répond à ce besoin.

Ces dernières années les services web ont connu une popularité continue. Ils sont utilisés surtout en raison de leur simplicité et leur interopérabilité. Leur mise en œuvre repose sur une architecture décentralisée. Cette architecture orientée services (Service Oriented Architecture - SOA) est un style architectural fondé sur la description des services et de leurs interactions. Les services sont publiés dans des annuaires par des fournisseurs qui les développent et les hébergent. Ils sont accessibles via un réseau pour les clients qui les découvrent, les invoquent et les utilisent.

Les services Web reposent sur plusieurs standards comme SOAP, REST, XML et HTTP pour échanger les informations entre applications dans des environnements hétérogènes à travers le réseau Internet. Mais comme toute nouvelle technologie, les services Web apportent de nouveaux problèmes de sécurité.

Plusieurs approches préventives sont apparues pour sécuriser les web-services (ex: WS-Security, Chiffrement, Signature...etc), ainsi plusieurs mécanismes de détection ont été proposées tel que des pare-feu XML, cependant ils présentent comme inconvénient, leur faible capacité à reconnaître les nouvelles attaques, et ne se focalisent généralement que sur l’intégrité du message, la confidential­ité, l’authentification de l’utilisateur et l’autorisation ce qui ne les prémunie pas d’autres types d’attaques, pour cela il est nécessaire de s’investir dans de nouvelles solutions afin de promouvoir la protection des WS.

Ce mémoire présente une approche de sécurisation des services web orientés SOAP qui repose sur la classification supervisée. Cette dernière est parmi les méthodes de prédiction les plus utilisées de nos jours dans divers domaines. Dans notre cas, il est question de concevoir un système de détection des attaques contre SOAP en s’appuyant sur les méthodes d’ensemble learning plus précisément la

fusion non paramétrique des classifieurs pour la détection des attaques toute en exploitant l’apport de l’optimisation de l’espace de décision de classifieurs.

Par le biais de cette introduction nous souhaitons répondre à la problématique suivante : quelles sont les configurations d’ensemble learning les plus appropriées au problème de détection des attaques contre les web services SOAP? Comment nous pouvons optimiser l’espace de décision de classifieurs et identifier les sous­ensembles de classifieurs offrants les meilleures performances?

La finalité de cette étude se résume dans ce qui suit :

- Élaborer une étude comparative des méthodes de la fusion non paramétriques de classifieurs.
- Établir une étude de l’existant des travaux qui s’inscrivent dans le cadre de la détection des attaques contre les web services SOAP en faisant appel aux méthodes de machine learning.
- Concevoir et réaliser un système de détection performant et robuste en ex­ploitant les atouts de la fusion non paramétrique des classifieurs dans le contexte de la sécurité des web services .
- Optimisation de l’espace de décision des classifieurs en d’autres termes sélec­tionner le sous ensemble de classifieurs qui présente les meilleures perfor­mances.

Organisation du rapport

Le présent rapport est organisé en 4 chapitres; Le premier chapitre initie les con­cepts fondamentaux de la classification supervisée, à savoir les principales étapes constituant le processus de classification, ainsi que les différentes méthodes de com­binaisons, les taxonomies qui en découlent tout en élaborant une étude comparative entre ces méthodes ensemblistes. Le deuxième chapitre introduit les services web SOAP et leurs vulnérabilités ainsi que les contres-mesures existantes, nous termi­nons par la présentation des principaux travaux de la sécurité des services web basés sur la classification supervisée. Quant au troisième chapitre, il détaille la conception de la solution proposée et es principaux modules la constituant. Enfin le quatrième chapitre recense les différentes technologies, bibliothèques utilisées et présente en détails l’étude expérimentale menée afin de concrétiser notre concep­tion.

Chapitre 1 Méthodes de combinaison de classifieurs

Avant d’entamer le vif du sujet (application de la combinaison de classifieurs dans le contexte de la sécurité des web services SOAP), nous allons définir dans quel domaine s’inscrit la classification supervisée, nous détaillerons par la suite les prin­cipales étapes de ce processus pour pouvoir mieux aborder par la suite la notion de combinaison de classifieurs. Notons que nous nous intéressons aux différentes con­figurations de combinaison en faisant abstraction de l’algorithme de classification implémenté par le classifieur.

1.1 Introduction à l’apprentissage automatique

Le machine learning (apprentissage automatique) fait référence au développement, à l’analyse et à l’implémentation de méthodes statistiques qui permettent à une machine d’apprendre à remplir une tâche à partir d’exemples, ce qui était impos­sible à accomplir par des moyens algorithmiques plus classiques.

Le machine learning englobe les approches suivantes selon [Mitchell 97]:

1. Apprentissage supervisé : est une technique d’apprentissage automa­tique où l’on cherche à produire automatiquement des prédictions à partir d’une base de données d’apprentissage contenant des exemples (individus), les classes à prédire sont prédéterminées et les classes des exemples de la base d’apprentissage sont connues, le système apprend à classer un nouvel exemple selon un modèle de classement ; La classification supervisée se fait en deux phases, dans la première phase (hors ligne, ou phase d’apprentissage), il s’agit de déterminer un modèle de prédiction à partir d’un ensemble de données étiquetées (base d’apprentissage), le défi est d’éviter le “surapprentissage”,

qui consiste à produire un modèle qui prédit sans erreurs les classes des exem­ples de la base d’apprentissage mais il est incapable de prédire correctement la classe d’un nouvel exemple . Quant à la seconde phase (en ligne, ou phase de test) elle consiste à prédire l’étiquette (la classe) d’un nouvel exemple, en se basant sur le modèle préalablement appris.

2. Apprentissage pour la régression: la Régression est une forme d’analyse prédictive qui cherche à établir la relation entre une variable dépendante (cible) et un ensemble de variables indépendantes dites prédictives. il existe différentes techniques de régression qui se distinguent principalement par le:

a) Nombre de variables indépendantes;
b) Type de la variable cible (continu, discrète);
c) Forme de la fonction de régression (linéaire ou non linéaire).

Exemples d’algorithmes de régression: régression linéaire, support vector regression (SVR), ElasticNet, ...etc.

3. Apprentissage non supervisé: former des groupes (clusters) homogènes à l’intérieur d’une population non étiquetée.

4. Apprentissage semi-supervisé: attribuer une classe aux exemples à partir de données étiquetées et non étiquetées.

1.1.1 Définition de la classification supervisée

Nous considérons une population divisée en q groupes d’individus différents Gi...G3. Ces groupes sont caractérisés par p caractères X1...XP, sans que l’on ait connais­sance des valeurs de X1r..,XP les distinguant. Soit Y le groupe auquel appartient un individu. Nous disposons de n individus avec les valeurs de Y, X1...XP connues . Les données sont donc de la forme [Chesneau 16]:

illustration not visible in this excerpt

Table 1.2 : Classification supervisée

Objectif :

Nous nous intéressons à un individu w* de la population avec ses valeurs x = (xi,...,xp), sans connaissance de son groupe d’appartenance.

Partant des données, l’objectif est de déterminer à quel groupe l’individu a le plus de chance d’appartenir[Chesneau 16]. En terme mathématique, ce groupe inconnu est:

G = Argmax3e{Gl...Gq} p(Y = g / {(Xi...Xp)} = x)

La plupart des algorithmes d’apprentissage supervisés tentent de trouver un modèle (une fonction mathématique) qui explique le lien entre des données d’entrée et les classes de sortie.

1.1.2 Définition d’un classifieur

Un classifieur désigne tout outil de reconnaissance, qui reçoit une forme x (indi­vidu) en entrée, et donne des informations à propos de la classe de cette forme, tout classifieur implémente un algorithme de classification précis [Heutte 05].

illustration not visible in this excerpt

Figure 1.1.1 : Notion de classifieurs

1.1.3 Type de sorties d’un classifieur

Les sorties d’un classifieur (la décision) peuvent être de trois types :

- Type Classe : le classifieur fournit en sortie la classe attribuée à l’individu « x » présenté en entrée.
- Type Rang : le classifieur présente en sortie une liste ordonnée de classes de la plus probable à celle qui l’est le moins.
- Type Mesure : le classifieur attribue à chaque classe une mesure, cette mesure peut être une probabilité, une distance, une mesure de confiance . . . etc.

1.1.4 Processus de classification supervisée

En général, un système de classification n’est opérationnel qu’après une succession d’étapes d’apprentissage et de test, afin d’aboutir par la suite à une stratégie de classification efficace.

Une fois donc le classifieur construit (choix de l’algorithme de classification et construction du modèle), il est essentiel de le valider en essayant d’estimer les erreurs de classification qu’il peut engendrer, cela est effectué lors de la phase de validation du modèle (cette phase réajuste les paramètres du modèle).

Il faut disposer d’une base d’individus qui n’appartiennent pas à la base d’apprentissage, c’est ce que l’on appelle la base de test, elle contient des individus étiquetés per­mettant de comparer les prédictions avec la valeur réelle de la classe.

Le schéma suivant résume le processus de classification supervisée:

illustration not visible in this excerpt

Figure 1.1.2 : Processus de classification supervisée

N.B: Chaque étape du processus est détaillée en annexe.

1.1.5 Quelques algorithmes de classification supervisée

Tableau récapitulatif des principaux algorithmes de classification

Dans le tableau ci-dessous, nous résumons les principales caractéristiques des al­gorithmes de classification: KNN, Naive Bayes, Arbre de décision (AD), SVM et Réseau de neurones (ANN).

illustration not visible in this excerpt

Table 1.3 : Principaux Algorithmes de classification supervisée

Suite à notre recherche élaborée dans le but de cerner les avantages et les incon­vénients de chaque algorithme recensé plus haut, nous résumons les résultats tirés dans le tableau suivant [Raffaëlli 15],[Mitchell 97], [Chesneau 16],[Mohamadally 06]:

illustration not visible in this excerpt

Table 1.4 : Comparaison entre les algorithmes de classification

1.1.6 Synthèse

Dans cette section nous avons introduit les notions de bases dans la classification supervisée, ainsi que les principales étapes dans tout processus de classification.

Néanmoins l’implémentation d’un seul algorithme, n’est pas toujours suffisantes, en termes de précision, les chercheurs s’orientent de plus en plus vers les méthodes d’ensemble learning, c’est ce qui sera détaillé dans le prochaine section.

1.2 Les méthodes de combinaison de classifieurs

Les chercheurs ont constaté qu’il n’existe pas un classifieur parfait pour traiter n’importe quelle distribution des données d’apprentissage, notons que dans les cas où le nombre de classes est important il est souvent difficile de faire appel à un seul classifieur suffisamment fiable en termes de résultats de classification, de plus le réglage d’un classifieur (perfectionnement du modèle) constitue un problème complexe(on procède souvent par essai/erreur).

C’est pourquoi les concepteurs des systèmes de classification, se sont tournés vers la combinaison de classifieurs, qui offre une meilleure distribution des carac­téristiques, permet d’exploiter la complémentarité entre les classifieurs (chacun sa région d’expertise) ainsi que la prise en considération des performances de chacun d’eux.

1.2.1 Définition de la combinaison de classifieurs

la combinaison de classifieurs est une approche en apprentissage automatique, qui a pour but de définir un modèle de prédiction performant et général en prenant en considération l’avis de plusieurs experts (classifieurs), plusieurs architectures ont été proposées dans ce sens: parallèle, série et hybride [S Asmita 14].

Le majeure défi dans la combinaison de plusieurs classifieurs, apparait au niveau de l’agencement de ces derniers, sachant qu’on dispose de L classifieur, on cherche à fiabiliser la prise de décision, cela dépend de la façon dont on veut les faire interagir [Heutte 05] :

- Indépendamment les uns des autres (vote) ;
- Elimination d’hypothèses (décisions dépendantes) ;
- Coopération de classifieurs (chacun résout un problème).

Notons que pour qu’un ensemble de classifieur présente de meilleures résultats, il est nécessaire que:

- Chaque classifieur présente un taux de reconnaissance au moins au-dessus de 50%.^[1]

1.2.2 Architectures de combinaison de classifieurs :

Il existe plusieurs architectures de combinaison de classifieurs[Heutte 05]:

- Combinaison Série: elle consiste en l’organisation des classifieurs en niveaux successifs de décision permettant de réduire progressivement le nombre de classes possibles. À chaque niveau un seul classifieur prend en compte la réponse fournie par le classifieur placé en amont. Néanmoins, cette archite- cure est sensible à l’ordre dans lequel sont placés les classifieurs et suppose donc une connaissance apriori du comportement de chacun.
- Combinaison Parallèle: Les classifieurs opèrent indépendamment les uns des autres puis leurs sorties sont combinées, à la recherche d’un consensus entre les classifieurs pour aboutir à une décision unique.
- Combinaison Hybride: elle consiste à jumeler les deux précédentes ap­proches, dans le but de réduire l’ensemble des classes possibles, tout en recherchant un consensus entre les classifieurs. Cependant cette approche n’est pas très répandu dans la littérature ceci étant dû au fait qu’elle est ex­trêmement dépendantes des données à traiter et très complexe à optimiser.

Notons que pour la suite de l’étude nous nous intéresserons à la combinaison parallèle, Cette architecture est facile à mettre en œuvre car elle ne nécessite pas un reparamétrage des autres classifieurs en cas de modification d’un d’entre eux comme dans le cas de l’approche série. On lui reproche cependant son coût en temps de calcul étant donné l’activation de tous les classifieurs en parallèle.

Elle est considérée plus intéressante que l’approche séquentielle dans la mesure où cette dernière nécessite la connaissance du comportement de chaque classifieur, quant à l’approche hybride, elle demeure une méthode assez complexe à optimiser [Bernard 11].

illustration not visible in this excerpt

Figure 1.2.1 : Architecture Parallèle[Heutte 05]

1.2.3 Méthodes de combinaison Parallèles

Dans les divers travaux de [Kuncheva 01] dédiés au méthodes de combinaison parallèles, on trouve la distinction entre deux approches de combinaisons :

- Fusion : combiner toutes les sorties des classifieurs via un opérateur de fusion.
- Sélection : choisir de manière dynamique “m” classifieurs parmi “n” à com­biner via un opérateur de fusion tels que m < n.

On retrouve dans les travaux de [Duin 00], une distinction entre :

- Fusion de classifieurs faibles : combinaison de classifieurs implémentant les mêmes algorithmes (algorithme de classification faible c-à-d il se comporte presque comme un classifieur aléatoire), la diversification des classifieurs porte alors sur l’ensemble d’apprentissage, l’ensemble des caractéristiques ou alors sur les paramètres des algorithmes, l’objectif est de créer un algorithme fort (bon compromis biais/variance) à partir de classifieurs faibles.

- Sélection de classifieurs : approche plus récente, plusieurs travaux ont mon­tré que dans certains cas la sélection de certains classifieurs présente de meilleures performances que de fusionner tous les classifieurs.

On retrouve dans l’article [S Asmita 14], une distinction entre :

- Fusion de classifieurs faibles : combinaison de classifieurs implémentant les mêmes algorithmes.^[2]

La figure ci-dessus englobe les principales méthodes de combinaisons parallèles selon la Taxonomie présentées dans [Zouari 05], que la plupart des travaux récents reprennent:

illustration not visible in this excerpt

Figure 1.2.2 : Taxonomie proposée dans [Zouari 05]

Dans ce qui suit nous nous focaliserons sur une des méthodes de Fusion des plus répandus (les autres approches sont décrites en détails en annexe).

1.2.4 Fusion de classifieurs différents

Cette approche peut se résumer comme suit : étant donnée un ensemble de L clas- sifieurs (souvent implémentant des algorithmes différents), participant de manière indépendante à la résolution du même problème de classification, l’objectif est d’élaborer une réponse finale à partir des résultats de ces classifieurs.

Notons que les méthodes de combinaisons par fusion se distinguent principale­ment par les facteurs suivants :

- Type de sorties des classifieurs ;
- Prise en considération de paramètres supplémentaires (nécessite une phase d’apprentissage supplémentaire) ;
- Stratégie de combinaison (définition de l’opérateur de combinaison).

Les méthodes de fusion manipulent souvent une matrice de décision relative à l’individu x à classifier, cette matrice est de dimension (N, L), tels que L désigne le nombre de classifieurs et N le nombre de classes, chaque ligne de la matrice correspond à une classe, chaque colonne de la matrice correspond à la réponse d’un classifieur concernant une classe:

illustration not visible in this excerpt

1.2.4.1 Fusion non paramétrique

Cette approche regroupe des méthodes considérées comme étant simple à im­plémenter car elles ne nécessitent pas l’estimation de paramètres supplémentaires par une phase d’apprentissage autre que celle pendant laquelle les classifieurs sont entraînés individuellement, néanmoins cela peut porter préjudice à l’efficacité de ses méthodes dans certains cas où il serait plus judicieux de considérer l’apport individuel de chaque classifieur.

Dans ce qui suit nous présenterons donc les méthodes de fusion existantes en variant le type de sortie (type classe, rang et mesure) et en variant l’opérateur de fusion.

Nous supposons que chaque classifieur Q fournit les sorties , tels que j allant de 1 à N, N étant le nombre de classes.

Dans le tableau ci-dessus, nous exposons le principe des méthodes de fusion non paramétriques qui différent selon le type de sortie et l’opérateur de fusion utilisé, enfin nous relevons quelques observations relatives à ces méthodes, pour plus de détails se référer à l’annexe (sous-séction A.3.1).

illustration not visible in this excerpt

Table 1.5 : Méthodes de combinaison de classifieurs

Notons qu’il existe d’autres approches de fusion (détaillées en annexe) tels que la fusion paramétrique et la fusion faible. Dans la fusion paramétrique, les classifieurs sont considérés différemment, et cela en leurs attribuant généralement des poids dans le but de mettre en avant les sorties des classifieurs jugés les plus performants (cela nécessite une phase supplémentaire d’apprentissage). Quant à la fusion faible, elle consiste à prendre en considération plusieurs classifieurs faibles implémentant le même algorithme dans le but de combiner l’information que chacun porte afin d’obtenir un super-classifieur plus performant (classifieur fort) en variant soit la base d’apprentissage de chaque classifieur, l’espace caractéristique ou alors les paramètres intrinsèques.

1.2.4.2 Synthèse

Les méthodes de combinaison se distinguent principalement par le niveau d’information en sortie, notons que les méthodes de type classe ont été les plus préconisées par la communauté de recherche cela étant dû principalement à leur simplicité de mise en œuvre et d’analyse expérimentale et théorique, mais concrètement il n’y a pas de méthode meilleure qu’une autre, cela demeure étroitement lié au domaine d’application. Toujours est-il que les méthodes non paramétrées sont largement préconisées par les chercheurs grâce à leur simplicité, toute en offrant le plus souvent des résultats tout aussi performants que les autres approches, ainsi l’utilisation de méthodes plus élaborées que la fusion non paramétrique (tels que la fusion paramétriques) ne garantissent pas toujours de meilleures résultats sys­tématiquement.

1.2.5 Méthodes de sélection de classifieurs

1.2.5.1 Principe

Les méthodes de sélection de classifieurs consistent à extraire un sous ensemble de classifieurs à combiner à partir d’un ensemble initial, tels que l’ensemble choisi présente les meilleures performances en termes de classification [S Asmita 14].

1.2.5.2 Motivations de la sélection

- La sélection est vue comme une approche permettant l’optimisation de l’espace de décisions des classifieurs ;
- Étant donnée qu’on dispose d’un grand nombre de classifieurs, l’enjeu est de trouver le nombre de classifieurs à combiner et lesquels choisir pour améliorer la reconnaissance ;^[3]

Les méthodes de sélection prennent aussi en considération le cas où l’on dispose de classifieurs ayant des régions d’expertises différentes, il serait alors intéressent de mettre en place des mécanismes permettant pour une situation donnée (un individu x donnée) de sélectionner le sous ensemble de classifieurs le plus adéquat (sélection adaptative).

illustration not visible in this excerpt

Figure 1.2.5 : Sélection de classifieurs

1.2.5.3 Méthodes de sélection A. Sélection statique

Dans ce cas la sélection est dite statique car le choix du sous ensemble ne dépend pas explicitement de l’entrée x à classifier.

A.1. Regrouper et extraire

Le principe consiste à regrouper les classifieurs en sous-ensembles en ayant recours à un algorithme de clustering de tels sorte que les classifieurs qui ne sont pas complémentaires dans leurs prédictions soient dans le même groupe (ils sont donc très corrélés), par la suite il suffit d’extraire un classifieur représentatif de chaque sous-ensemble.

Une des méthodes proposées pour mesurer la corrélation entre deux classfieurs,consiste en l’utilisation d’une mesure de diversité qui se base sur la probabilité que deux clas­sifieurs proposent simultanément des réponses incorrectes sur une base de validation (base différente de la base de tests et apprentissage).L’idée consiste donc à combiner des classifieurs les plus complémentaires possibles[Zouari 04].

illustration not visible in this excerpt

Figure 1.2.6 : Regrouper et extraire

A.2. Rechercher et Sélectionner

illustration not visible in this excerpt

Figure 1.2.7 : Rechercher et Sélectionner en utilisant les AGs

Utiliser des heuristiques (Algorithmes génétiques, Recherche séquentielle), pour sélec­tionner le meilleure sous ensemble de classifieurs[S Asmita 14].

B. Sélection Dynamique

Sélectionner un sous ensemble de classifieurs en fonction de l’individu en entrée .

B.1. Sélection locale

Consiste à diviser l’espace des caractéristiques en régions, puis estimer la performance locale de chaque classifieur dans chaque région et enfin choisir le meilleure classifieur le plus adéquat à chaque région, à l’arrivée d’un nouvel individu on calcule la région qui lui est la plus proche (utiliser une distance) puis on lui prédit sa classe par le classifieur (ou sous-ensemble de classifieurs) affecté à cette région[Zouari 04].

illustration not visible in this excerpt

Figure 1.2.8 : Sélection locale

B.2. Sélection par pondération (stacking)

Le principe général consiste à faire appel à un sélecteur (un autre classifieur) qui attribue des poids aux classifieurs en fonction de l’individu x présent en entrée[S Asmita 14].

illustration not visible in this excerpt

Figure 1.2.9 : Sélection par pondération

1.2.6 Étude comparative entre les méthodes de combinaison

1.2.6.1 Comparaison entre les méthodes de Fusion

Ce tableau dresse une comparaison entre les méthodes de fusion non paramétriques en fonction de leurs caractéristiques.

illustration not visible in this excerpt

illustration not visible in this excerpt

Table 1.6 : Comparaison entre les opérateurs de fusion non paramétriques

1.2.6.2 Comparaison entre les méthodes de sélection

Dans ce tableau, il est question de comparer les deux principales approches de sélection statique et dynamique en terme de conception :

illustration not visible in this excerpt

Table 1.7 : Tableau comparatif des méthodes de combinaison de classifieurs (Sélection)

1.2.6.3 Comparaison entre les méthodes de fusion et de sélection

Ce tableau dresse une comparaison entre les méthodes de fusion et les méthodes de sélection, en termes de complexité d’implémentation, spécificités de l’espace caractéristiques ainsi que d’autres paramètres qui influent la classification.

illustration not visible in this excerpt

Table 1.8 : Tableau comparatif des méthodes de combinaison de classifieurs (Fusion/Sélection)

1.3 Synthèse Générale

A partir de cet état de l’art, nous avons identifié une approche générale à aborder et à adapter selon le domaine d’application pour la conception d’un système multi- classifieurs :

1. Formaliser le problème posé en un problème de classification supervisée (définir le but de l’étude, définir les classes à prédire)
2. Sélectionner les sources de données relatives au domaine d’application.
3. Identifier l’espace caractéristique (choix des attributs, si nécessaire faire appel à une méthode de sélection d’attributs.
4. Extraire les valeurs des attributs pour constituer les vecteurs caractéristiques (normaliser les valeurs en cas de besoin).
5. Construire la base d’apprentissage.
6. Choisir l’architecture de combinaison de classifieurs qui convient le plus au problème de classification posé (Parallèle/ Série/ Hybride).
7. Choisir les types de classifieurs à utiliser et leurs nombre (classifieurs implé­mentant le même algorithme ML/ classifeurs différents).
8. Choisir la configuration d’apprentissage (tous les classifieurs utilisent la même base d’apprentissage/ chaque classifieur utilise une sous-base d’apprentissage/ chaque classifieur est affecté à une région (une partie des attributs) et utilise une sous base d’apprentissage).
9. Choisir la méthode de combinaison (choix du type de Fusion, choix de la méthode de fusion, choix des paramètres de la méthode).
10. Choisir la stratégie de validation de la base d’apprentissage la plus adéquate, cela est souvent réalisé après les tests des méthodes les plus répandues (val­idation croisée, k-fold, ...etc) et comparaison des résultats en termes de pré­cision, rappel ou en termes de taux de faux positifs et faux négatifs, temps d’apprentissage.
11. Après choix de la méthode de combinaison, il est possible éventuellement de l’améliorer en l’adaptant aux spécificités du problème posé (nouvelle formule de vote pondérée, nouvelle version d’adaboost ...etc).
12. Étudier l’éventualité d’aborder une approche de sélection de classifieurs afin d’optimiser l’espace de décision.
13. Choisir la méthode de sélection de classifieurs.
14. Évaluer le système conçu en termes de précision, rappel,.. .etc.

Ce processus est itératif, souvent il est nécessaire de reprendre les premières étapes de l’étude dans le but d’ajuster certains paramètres. Pour ce qui est de la méth­ode de validation de la base d’apprentissage elle est impliquée dans le choix des paramètres intrinsèques aux classifieurs (utilisation de la validation croisée pour le choix du paramètre « k » de knn par exemple), choix des méthodes de fusion et de leurs paramètres, validation de la constitution de la base en ajustant le nom­bre d’individus à prendre de chaque classe. Notons que dans toutes les étapes faisant appel à un choix à effectuer, ce choix sera déterminé après comparaison des méthodes existantes et cela souvent en termes de rappel, précision et temps de traitement.

1.4 Conclusion

Dans ce chapitre nous avons abordé les différentes architectures de combinaison de classifieurs, puis nous avons présenté les principales méthodes existantes dans l’approche parallèle qui reste la plus répandue. Nous avons aussi abordé la notion de sélection de classifieurs qui se fait généralement après la fusion dans le but d’affiner au maximum le processus de prise de décision (la prédiction).

On constate qu’il est difficile de généraliser les résultats de combinaison de clas­sifieurs, étant donné qu’ils restent extrêmement liés au domaine d’application (les données réelles).

Le nombre d’études effectuées sur l’analyse des méthodes de combinaison de classifieurs de manière générale en faisant abstraction du domaine d’application reste limité, il est donc difficile de mettre en place une approche générale qui englobera totalement le problème de la combinaison de classifieurs, du moins il est possible de proposer une approche à suivre lorsque qu’on est confronté à un problème de classification donnée.

Afin d’adapter l’approche proposée ci-dessus dans le contexte des web services, nous allons présenter dans le prochain chapitre les principaux travaux de recherches qui s’inscrivent dans le cadre de la sécurité des web services faisant appel au méthodes de machine learning.

Chapitre 2 Les web services

Dans ce chapitre, nous introduisons les fondements technologiques des services web SOAP. Nous décrivons par la suite les vulnérabilités inhérentes à SOAP, les différents types d’attaque visant les failles de sécurité de ce dernier, les solutions de sécurité actuelles et les contre-mesures disponibles pour contrer ces attaques. Nous terminons par une étude de l’existant dont nous citons les principaux travaux qui s’inscrivent dans ce contexte.

2.1 Introduction

L’accès aux systèmes d’information s’appuyant de plus en plus sur les technologies du web, les efforts de standardisation et de flexibilité déployés dans ce contexte ont favorisé l’engouement des organisations pour l’utilisation des web services comme support de développement des applications.

Les services Web proposent une architecture par composants qui permet aux entreprises, de faire communiquer leurs systèmes d’informations avec ceux de leurs clients ou partenaires, moyennant l’usage de fonctionnalités distantes. En effet, les services Web reposent sur les technologies standards de l’infrastructure d’Internet qui sont totalement indépendante du matériel, ou du langage de programmation. Cette technologie s’affranchit donc de toute contrainte de compatibilité logicielle ou matérielle.

2.2 Généralités sur les Services Web

2.2.1 Définition des services web

Un service Web est défini par W3C comme étant « Un système logiciel identifié par une URI, dont les interfaces publiques et les associations sont définies et décrites en XML. Sa définition peut être découverte par d’autres systèmes logiciels. Ces systèmes peuvent alors interagir avec le service Web selon les modalités indiquées dans sa définition, en utilisant des messages XML transmis par des protocoles internet » [W3C 16].

D’autres définitions apparaissent dans la littérature, définissant les web services comme suit:

Les services Web sont « des applications modulaires, qui se suffisent à elles- mêmes, qui peuvent être publiées, distribuées sur Internet »[Rabhi 12].

2.2.2 Web services basés sur SOAP

2.2.2.1 Définition SOAP

Un message SOAP est un moyen d’échange entre le client et le fournisseur du service, c’est un standard introduit en 1998 comme moyen d’échange de messages entre applications hétérogènes et réparties.

Les paquets SOAP sont encapsulés dans un protocole de transport (http, SMTP), et ils sont échangés suivant un protocole de communication tels que RPC (Remote Procedure Call), document, ...etc [W3C 16].

SOAP est basé sur le format XML. Le format XML est utilisé pour définir le contenu du message SOAP ainsi que sa structure.

L’utilisation de XML en tant que formalisme du message SOAP, et de HTTP comme protocole de transport, apporte à SOAP une très grande flexibilité et in­teropérabilité :

- XML est un format universel de description de données (structurées ou non), manipulés par la plupart des langages de programmation existants.^[4]

Enveloppe SOAP

C’est l’élément racine d’un message SOAP. Il doit avoir le nom d’espace : http://www.w3.org/2003/05/soap-envelope

qui indique qu’il s’agit de l’élément SOAP Envelope. SOAP Envelope peut utiliser d’autres noms d’espace si cela est requis.

L’enveloppe SOAP possède deux sous-éléments: SOAP Header et SOAP Body.

Il doit inclure les noms d’espace de WS-Security, XML-Signature, XML-Encryption si le message contient une déclaration de sécurité, de signature et de chiffrement [Keita 10].

Header SOAP

SOAP Header est optionnel, il donne des directives à un intermédiaire (nœud qui relaie le message soap) ou au destinataire, concernant le traitement du message.

Ces directives concernent généralement la sécurité : déclaration d’assertions, déclaration de signature, déclaration de chiffrement, information sur une clé cryp­tographique, ...etc.

SOAP Header contient un ou plusieurs blocs appelés également entrées d’en- têtes. Une entrée d’en-tête se compose d’un ou plusieurs espaces de nom, d’un nom local et de quatre attributs: encodingStyle, role, Relay et mustUnderstand [Keita 10].

illustration not visible in this excerpt

Table 2.1 : Attributs Entete SOAP [Keita 10]

Body SOAP

Body SOAP est l’élément contenant les données à transmettre. Il comporte un ensemble d’entrées contenant des informations que le destinataire doit traiter.

L’élément Body est également utilisé pour transmettre un message d’erreur dans le cas où une erreur survient [Keita 10].

Cette figure récapitule la structure générale d’un message soap :

illustration not visible in this excerpt

Figure 2.2.1 : Structure d’un message SOAP [Chollet 09]

2.3 Failles de sécurité dans les WS

Notons que la diversité des standards sur lesquels sont basés les services Web (XML, HTTP, ...etc.), les rends plus vulnérables aux attaques. C’est pourquoi un grand nombre d’attaques de différents types ayant des finalités différentes ont été mises au point.

Dans cette section, nous allons exposer les principales attaques inhérentes au web services SOAP, qui peuvent être classés comme suit :

- Corruption et épuisement des ressources du serveur Web pour rendre le ser­vice fourni inexploitable (exemple: attaques XDos);
- Vol d’informations confidentielles (exemple: attaques SQL Injections);
- L’exécution d’instructions non autorisées sur le système visant l’altération de données (exemple: OS commanding).

Dans ce qui suit nous allons présenter les principales attaques contres les web services SOAP recensés par OWASP [OWASP 16] :

2.3.1 Attaques relatives à SOAP

2.3.1.1 Attaques relatives au header SOAP

Ces attaques ciblent l’entête SOAP, elles peuvent se manifester sous la forme d’injections au niveau du header SOAPAction ou à travers un nombre énorme de blocs header, les attaquants ciblent les mécanismes de cryptage en générant des chaînes complexes de clés cryptés dans le but d’épuiser les ressources du des­tinataires.

2.3.1.2 SOAP message flooding

Cette attaque consiste à envoyer un nombre considérable de messages soap en un laps de temps considérablement court dans le but de générer une attaque de déni de service.

2.3.2 Coercive Parsing

Lorsqu’un nœud SOAP destinataire (fournisseur de service) reçoit une requête SOAP, il analyse les éléments de la requête pour extraire les traitements à effectuer (parsing) , pour cela il est souvent question d’un parseur (analyseur syntaxique) qui va extraire des paramètres, déterminer la méthode à invoquer, insérer un contenu dans la base de données, ...etc.

Un attaquant peut faire en sorte d’invoquer excessivement cette tache dans le but de générer une attaque DoS (déni de service) en épuisant les ressources du serveur.

2.3.3 Attaque relatif au contenu XML

2.3.3.1 Injection SQL

Cette attaque consiste à injecter des instructions SQL dans la partie données envoyée par le client au service (exemple de formulaire), cela peut donner accès à la base de donnée du service, l’attaquant peut ainsi lors du remplissage des champs d’un formulaire injecter des caractères spéciaux tels que “;”, pour enchaîner plusieurs requêtes SQL,il existe une autre attaque similaire à celle-ci, il s’agit de “injection XPATH”, cette attaque cible les services qui utilisent XPATH (langage non XML) comme langage d’interrogation des bases de données XML, tous comme pour une injection XPATH, l’attaquant injecte dans les input du code malicieux afin d’accéder à des données confidentielles.

2.3.3.2 Injection XML

Les attaques à base d’injection XML, visent à modifier la structure XML d’un message SOAP en insérant des balises XML, ce qui va entraîner des conséquences sur le serveur hébergeant le service, tels que ajouter un > en plus, ce qui peut bloquer le parseur du fournisseur [Jensen 09].

Cette attaque peut se manifester aussi sous la forme de balises CDATA (con­tenu inséré entre deux balises CDATA n’est pas analysé par le parseur), ainsi un attaquant peut exploiter cette faille afin d’insérer du code malveillant.

La figure ci-dessous résume les principales attaques auxquelles font face les web services SOAP:

2.4 Solutions de Sécurisation Existantes

Il existe une multitude de solutions pour sécuriser les web services, ces solutions peuvent apparaitre sous formes de contre mesures, standards et normes à appliquer lors de la conception d’une application web dans un cadre préventif, il peut s’agir aussi de systèmes de détection d’attaques sous forme de module à intégrer dans les firewalls et les IDS. Avant de présenter les principales solutions existantes, notons qu’il existe deux types d’approches afin de protéger un système contre les attaques de manière générale[Thakar 10]:

- L’approche préventive: cette approche consiste à tester les vulnérabilité du système vis à vis de ces attaques avant même sa mise en production en ayant recours à des outils de tests de pénétrations, cela permet par la suite d’ avoir les contre mesures adéquates au vulnérabilités détectées.
- L’approche de détection: cette approche consiste à déployer en premier lieu le système, et veiller à son bon fonctionnement de manière continu en mettant en place un mécanisme de détection des potentielles attaques, cette façon de faire englobe trois principales variantes (très répandu dans les IDS) :
— Anomaly Detection : consiste à analyser le comportement normal (ex­emple messages soap valides), tous ce qui diffère de ce comportement est considéré comme attaque (risque élevé de fausses alertes).
— Misuses Detection : consiste à analyser le comportement malicieux (les attaques), tous ce qui est similaires au signatures d’attaque déjà établie au préalable souvent par un expert informatique sera considéré comme attaque (risque élevée de non détection des nouvelles attaques).
— Hybride : Cette approche est un compromis entre les deux précédentes, et c’est souvent la plus préconisée.

A présent nous allons présenter les principales solutions qui ont été mises au point dans le cadre des attaques contre les web services SOAP.

2.4.1 Utilisation des parseurs SAX

Afin de contrer les attaques XDos qui ciblent souvent les parseurs XML (recursive payload, oversize payload), il est conseillé de ne pas utiliser de parseur DOM qui lit le message SOAP dans sa globalité et construit en mémoire un XML-tree relatif au message SOAP cela va entraîner une consommation excessive des ressources (CPU, mémoire) ce qui va mener à un déni de service du serveur en cas d’attaque XDos. Afin d’éviter cela, il est possible d’avoir recours au parseur SAX (Simple Api for XML), ce parseur est basé sur les évènements en procédant à l’analyse du document XML élément par élément (exemples d’évènements : début document, début élément, ..etc ), ainsi il ne charge pas la totalité du message SOAP en mémoire en revanche l’analyse du message SOAP prendra plus de temps comparé au temps d’analyse d’un parseur DOM[Ghourabi 10].

2.4.2 Normes de sécurité XML

W3C a permit la standardisation de spécifications XML tels que XML signature, XML Encryption, XML key management spécification dans le but d’assurer la confidentialité, l’intégrité et la non répudiation dans les documents XML , ces spécifications permettent de définir des signatures numériques, définir des règles de cryptage et d’utiliser divers méthodes de gestion de clés [OCTO 16].

2.4.3 WS-Security

WS-Security est un standard pour sécuriser des services web SOAP uniquement. Ce dernier assure entre autres l’authentification, le chiffrement, la signature.

Dans un message SOAP, Le body est prévu pour ne contenir que des notions orientées métier (appel des services offerts). quant au header il est destiné au informations techniques relatif au web service. C’est donc ce dernier qui est utilisé pour contenir les informations d’authentification et d’autorisation. Les protocoles de sécurité de Web Service tel que WS Sécurity se basent donc sur le header soap pour ajouter les informations relatives à l’authentification, le cryptage, et les signatures.

Principe général :

Le web service implémentant WS-Security fournira des données de sécurité sous forme de jeton unique à durée de vie limitée à l’utilisateur qui se sera authentifié via une méthode web prévue à cet effet. L’utilisateur devra ensuite fournir dans les header soap son login et son mot de passe, ce jeton de sécurité sera utilisé pour chaque appel de services. Du côté du web service, un intercepteur devra valider ces données avant de permettre ou rejeter l’appel au service [OCTO 16].

2.4.4 Firewall XML

Un pare-feu XML se différencie d’un pare-feu traditionnel qui se révèlent inefficace pour éradiquer les menaces sur les services web. Un pare-feu XML se déploie en aval du pare-feu traditionnel pour parer à ces vulnérabilités. Un pare-feu XML est conçu spécifiquement pour inspecter les flux XML et SOAP (Simple Object Access Protocol) [guide 17].

Les fonctionnalités de sécurité mises en œuvre portent principalement sur :

- la validation des messages;
- la détection des intrusions;
- le routage selon le type de contenu;
- la sécurité au niveau de la couche de message.

2.4.5 IDS pour les web services

Quant tenu du fait que les IDS classiques (système de détection des intrusions) ne permettent pas de détecter les attaques contre les web services étant donnée qu’ils opèrent au niveau du réseau ou au niveau des hôtes, plusieurs travaux de recherches se sont intéressés à la conception d’ IDS pour sécuriser les web services soit en s’inspirant des IDS destinés au applications web (permet de détecter les attaques transmises via http) ou alors en concevant un module permettant l’inspection des messages soap et la détection d’éventuels attaques. [Ghourabi 10].

Quelques contre-mesures

Dans le tableau ci-dessous, nous exposons quelques contres mesures relatifs aux attaques les plus répandus [Ghourabi 10]:

illustration not visible in this excerpt

Table 2.2 : Contre mesures [Ghourabi 10]

Les solutions présentées ci-dessus sont efficaces et nécessaires, néanmoins elles demeurent insuffisantes car elles présentent quelques limites quant à la détection des nouvelles attaques et le support des nouvelles techniques et stratégies des at­taquants. De plus certaines de ces solutions préventives telles que ws-security et les normes de sécurité XML deviennent des cibles d’attaques à leur tour, de plus le cryptage introduit par XML Encryption nécessite plus de temps de traite­ment, cela peut inciter un attaquant à envoyer au service Web plusieurs messages SOAP chiffrés et malicieux, qui ont une grande taille dans le but de générer un Dos. Actuellement les administrateurs de sécurité ont besoin de solutions semi- automatiques qui prennent en charge le filtrage des messages soap et permettent de détecter de nouvelles attaques afin de mettre au point de nouvelles contre mesures de sécurité.

2.5 Travaux Similaires

Afin de prendre connaissance des méthodes de sécurisation existantes dans les web services basé sur soap, nous avons recenser les travaux de recherches (entre 2011 et 2016) qui ont été publiés dans ce contexte, à partir de cette étude bibliographique nous avons pu dégager les conclusions suivantes :

- Les principales attaques ciblées par les travaux de recherches s’articule en premier lieu autour des attaques XDos, suivi des attaques XML et SQL injection, rarement les articles qui traitent plusieurs attaques à la fois .
- Plusieurs solutions ont été proposées, voici les principales catégories recen­sées:
Méthodes préventives :
— Proposition de nouveau mécanismes de sécurisation (extensions XML, renforcement de la structure du message SOAP).
— Développement de nouveau outils de tests de vulnérabilités, honeypots (exemple: [Thomé 15], [Ghourabi 10]).
— Elaboration d’approches basée sur le raisonnement à base de cas (ex­emple: [Pinzón 11]).
— Développement de nouvelles ontologies (exemple: [Vorobiev 06]).
Méthodes de détection:
— Approches basée sur les méthodes de machine learning (exemple: [Ladole 16], [Sheykhkanloo 14]).
— Approches basée sur les systèmes d’inférence en logique floue (exemple:
[Chan 12][Chan 13]).
— Approches basée sur les techniques d’extractions de règles d’association(exemple: [Esfahani 16] ).
— Approches basée sur des études statistiques et probabilistes(exemple: [Rahnavard 10]) .

Après avoir recensé le maximum d’articles ayant été publiés de 2011 à 2016, nous n’avons sélectionné que ceux qui traitent de la détection d’attaques contre SOAP, moyennant les outils du machine leraning; souvent ces travaux combinent ces outils au système d’inférence de logique flous et aux approches d’extraction de règles d’association.

A la suite de cette étude bibliographique nous effectuerons une synthèse com­parative et critique des systèmes conçus, enfin nous fixerons nos objectifs sur la solution que nous souhaiterons apporter.

2.5.1 Les solutions proposées

2.5.1.1 Système multi agents pour la détection des messages SOAP malicieux

Dans l’article [Pinzón 11], les auteurs proposent une approche adaptative capable de détecter les attaques XDos, la solution proposée est basée sur un système multi agents hiérarchique suivant une approche de détection d’anomalies, cette solution réagit au attaques en temps réels. La classification se fait en deux phases pour des raisons de performances (économiser les ressources du système).

A l’interception d’un message SOAP par un des agents de trafic, ce dernier est traité pour en extraire de manière distincte les paramètres du header et le texte brute en XML du body, par la suite les agents de classification du premier niveau prennent le relais pour une classification dites légère ou il est question d’analyser uniquement la taille du message SOAP, la longueur du header SOAPAction, le temps de routage, temps d’inter arrivée des messages provenant du même client et l’id du service sollicité.

le but de cette classification est d’éviter que des attaques Xdos n’altère le sys­tème en lui même, car cette dernière ne nécessite pas d’analyser le message en profondeur. la première classification consiste en la construction d’un arbre de décision, chaque agent exécute le cycle suivant pour chaque nouveau message , il charge en premier le modèle relatif au web service du message, si le modèle n’existe pas , il construit un nouvel AD, cependant en cas d’erreur de prédiction détecté à l’étage suivant ou par l’expert en sécurité, dans ce cas le modèle est reconstruit après ajout de ce message à la base d’apprentissage , en sortie le message est classé soit en : attaque, bon ou indéfini.

A l’étage suivant, le message est examiné plus en détail par un réseau de neu­rones (multi couche perceptron), le nombre d’attributs est par conséquent élargie (nombre éléments dans le body, temps de parsing, profondeur des éléments du body).

Les auteurs justifient la pénalité dans le temps de prédiction, par le gain en con­tre partie dans la précision de prédiction, le prototype a été tester sur des données réelles d’un web service de gestion de centre commerciaux, d’après les résultats d’expérimentation on conclut que ce système présente d’assez bon résultats.

2.5.1.2 Extraction de règles d’association à partir de l’analyse des attaques relatif à XML

Dans l’article [Chan 12], il est question d’un système (ANFIS) de détection des at­taques relatifs à XML basé sur un modèle de règles d’association floues et cela dans le contexte d’un web services de e-commerce (sql injection, buffer overflow, soap oversized payloead, recursive payload, recursive payload, parametre tampering).

En premier lieu les entrées (messages soap) sont validées par le biais d’un en­semble de règles (business policies qui fixe des seuils à ne pas dépasser concernant la taille des champs et la taille globale du message SOAP) dans le but d’éviter de surcharger le système par la suite.

L’utilisateur du service de e-commerce commence par introduire sont nom d’utilisateur et son mot de passe, à ce stade il est possible de détecter des inputs malicieux tels que SQL injection ou buffer overflow, une fois ces inputs validés, il introduit le numero de la carte de crédit, email, adresse, ...etc à ce stade le système se focalise davantage sur les attaques XDos tels que corecive parsing, recursive payload et les XML injection tels que XPath.

Les tests ont été effectuer sur des données simulées via l’outil WSKnignt qui permet de générer des messages soap malveillant, les résultats ont été très con­cluants , précision de prédiction proche de 100%, taux de fausse alarme inférieur à 1%, néanmoins la solution proposée reste extrêmement liée au web service de e-commerce sur lequel s’articule l’étude toute entière.

2.5.1.3 Sécurisation des transactions via la détection des anomalies dans les documents XML

Dans l’article [Menahem 12], il est question d’un framework “XML-AD” (XML anomaly detection) pour détecter et localiser les anomalies dans les transactions XML en utilisant les techniques de machine learning, ce système aborde une ap­proche de détection d’anomalies.

Etant donné qu’il existe une infinité d’exemples de documents invalides, l’auteur préconise une méthode de détection semi supervisée (one-class learning) car il est plus simple d’obtenir des documents XML valides de plus cette approche lui évitera de faire une recherche exhaustive de toutes les attaques pouvons survenir.

La détection se fait via le calcul de similarité entre le corpus de documents XML normaux et le nouveau document qui correspond à la distance entre l’individu du corpus le plus proche du document à classer. Le framework comporte trois principaux modules, un module pour l’extraction des attributs, un module pour la génération des données (vectorisation) et un module pour la construction du modèle.

L’extraction des attributs d’un document XML se fait selon les informations extraites de son fichier XSD qui est en premier lieu analysé par un parseur (création d’un vecteur qui comporte entre autres les éléments du fichier XML et leurs types), les documents xml de la base d’apprentissage sont regroupé dans une matrice.

Afin d’uniformiser ces données pour pouvoir appliquer par la suite un algo­rithme de machine learning (le nombre d’attributs fixe, et les valeurs doivent être des scalaires), un ensemble de fonction d’agrégation (Sum,Max,Min) ont été ap­pliquées , ainsi que la méthode du TF-IDF de chaque mot a été calculé avec prise en compte uniquement des k termes ayant les plus grand TF-IDF, le choix des fonctions d’agrégations s’est fait par rapport au type des éléments (si type=String utilisation de la mesure TF-IDF, si type =Enumerations utilisation de la somme, si type=Number utilisation de Min et Max).

Quant à la construction du modèle elle s’est faite avec l’utilisation d’un nou­vel algorithme ADIFA (Attribute Density Function Approximation) et cela étant donné que la base d’apprentissage obtenue a une dimension élevée, de plus cette dimension ne peut être réduite avec les méthodes de sélection au risque de passer à côté d’une attaque qui peut cibler n’importe quel attribut, nous nous sommes intéressées dans cette article au processus de transformation d’un document XML complexe en un vecteur de scalaires à taille fixe toute en préservons les informations concernant la structure et le contenu du document.

2.5.1.4 Système multi-agents pour la détection des attaques Dos orientées WS

Cet article [Pinzón 12] présente un nouveau mécanisme de détection et de préven­tion des attaques DoS, cette solution s’intitule Multi-agent Adaptive Intrusion De­tection Système (AIDeMaS), elle a été conçue en utilisant la plateforme FUSION@ qui propose une nouvelle méthode de développement de systèmes distribués intelli­gents plus flexible, où les applications et les services peuvent communiquer, même à partir de périphériques mobiles, indépendamment des restrictions de temps et d’emplacement.

AIDeMaS est basé sur un groupe d’agents spécialement conçus pour travailler ensemble d’une manière intelligente et adaptative pour résoudre le problème de la fiabilité des messages SOAP. Le modèle proposé dans cette étude est innovant, puisqu’il propose une nouvelle perspective pour aborder les attaques Dos dans les architectures orientées services. L’approche présentée dans cet article propose pour la première phase un classifieur F1 (Agent) qui incorpore une stratégie de classification basée sur un algorithme Naives Bayes, et un agent classifieur F2 pour la seconde phase qui intègre un réseau de neurones.

La processus affecte les messages SOAP à une des trois classes : attaque, sus- pect,no attaque. Cette classification se fait à base d’algorithmes ML en comparant les valeurs des attributs extraites par rapport aux seuils prédéfinis dans la phase d’apprentissage.

2.5.1.5 Approche Pot de miel pour détecter les attaques contre SOAP

Dans la thèse [Ghourabi 10], l’auteur propose une approche pot de miel qui simule un web service basé sur SOAP à forte interaction dans le sens ou ces services sont réels et non émulés, de plus les services peuvent être déployés sous plusieurs technologies (Axis, .Net) dans le but de leurrer le maximum d’attaquants .

Le but de ce système (WS-Honeypot) est de détecter les attaques contre SOAP, principalement les attaques XDos et XML injection.

La sélection des attributs a été effectué en utilisant l’ACP (analyse en com­posante principales) . Après application de l’ACP les attributs retenus sont les suivants (méthode invoquée, les 7 premiers paramètres de la méthode, taille du message, usage CPU, usage mémoire, les paramètres relatifs à la session).

Le corpus global est composé de trois principaux datasets :

- Le premiers comporte les messages SOAP valides représentés par les attributs exprimant la consommation de ressources, ce dataset est destiné au classifieur SVR (Support Vector Regression ) qui est une implémentation de SVM pour la régression, il détecte les attaques de déni de service en prédisant la taille du message par rapport au temps de traitement , occupation CPU et mémoire cette taille sera par la suite comparée à la taille réelle du message.
- Le deuxième dataset concerne les attributs relatif au contenu des messages SOAP, il est utilisé par le classifieur SVM,dans le but de détecter de nou­velles attaques d’injection à travers le calcul d’une probabilité qui exprime la similarité entre le nouveau message et les précédents. Le choix de SVM à noyau polynomial a été justifié après comparaison de ce dernier avec d’autres algorithmes via l’outil WEKA.
- Le dernier dataset (combiné au deuxième) servent de base d’apprentissage à deux algorithmes de clustering (spectral clustering, sequence clustering) dans le but d’étudier et de caractériser le comportement des attaquants.

Pour ce qui est de la partie expérimentation, WS-Honeypot a été déployé pour simuler un web service de e-commerce (cible souvent prisée par les attaquants). Étant donné que les messages SOAP réelles recueillis par le système n’ont pas été suffisantes pour la construction de la base d’apprentissage, il a fallu simuler des attaques en ayant recours aux outils de tests de pénétrations et les scanners de vulnérabilités. Les résultats ont été très concluants le taux de détection des attaques DOS a atteint les 100%, le taux de détection des nouvelles attaques par SVM a atteint les 94%.

2.5.1.6 Détection des attaques injection profil visant les systèmes de recommandation

L’article [Kumar 15], traite les systèmes de recommandation e-commerce qui sont très vulnérables aux attaques par injection de profil. Les auteurs Comparent six algorithmes ML basés sur un modèle d’apprentissage réel et mesurent sa perfor­mance dans la détection des attaques injection profil.

Le principal objectif de l’attaquant est d’interagir avec le système de recomman­dation avec certain nombre de faux profils d’utilisateurs dans le but de polariser la sortie du système, c’est-à-dire promouvoir ou saboter un article particulier.

Le système conçu User-user est connu sous le nom du filtrage collaboratif KNN; Ce dernier évalue l’intérêt que porte un utilisateur u pour un article i en util­isant les notes pour cet article par d’autres utilisateurs appelés voisins qui ont des notation ou des intérêts similaires.

L’article présente une étude détaillée des similarités existantes entre les attaques de types "injection de profil” dans les systèmes de recommandations (e-commerce). L’approche développée catégorise les attaques par injection de profil en deux prin­cipales catégories:

- Attaque modèles: cette attaque injecte un ensemble de faux profils. Chaque profil se compose de quatre ensemble d’éléments.
- Attaque dimensions: cette attaque est catégorisée en fonction de la taille de l’attaque, l’intention de l’attaque et la connaissance requis par l’attaquant pour monter l’attaque.

La classification se fait à base des fonctions de similarités pour la détection des attaque modèles, et à base des seuils prédéfinis sur la taille du message et le taux de remplissage d’une commande ainsi le comportement d’un client pour les attaques démentions.

Les auteurs comparent la performance des forêts aléatoires, arbre de décision, adaboost, SVM , régression linéaire et réseau de neurones. Pour cette expérience ils entraînent la base sur 60% de données et testent 40% de données afin de vérifier la robustesse de la base d’apprentissage. En fonction des résultats, ils découvrent trois modèles performants qui sont le réseau de neurones, SVM et les forêt aléatoire. Ils combinent par la suite ces trois modèles pour construire un Modèle d’ensemble learning dont la précision est de 90%.

2.5.2 Synthèse

Dans ce tableau nous avons récapituler les caractéristiques des solutions proposées précédemment en termes d’attaques ciblées, attributs recensés, modèle de détec­tion (algorithmes ML utilisés, type de données), technologies (outils) utilisées que ce soit pour la simulation des données ou pour l’implémentation du modèle de détection.

illustration not visible in this excerpt

Table 2.4 : Récapitulatif des principaux cas d’études

Le tableau ci-dessous établie une étude comparative entre les divers solutions proposées en termes de mesures d’évaluation du système conçus (TFP: taux de faux positifs, TFN: taux de faux négatifs, Tmps Rps: temps de réponse), type de données (réelles ou simulées), caractéristiques du système (solution temps réelle, approche distribuée, mesures de sécurisation du système de détection contre les attaques).

illustration not visible in this excerpt

Table 2.5 : Tableau comparatif des solutions présentées

2.5.3 Observations relevées sur les solutions proposées

Le tableau ci-dessous, recense les principales observations que nous avons pu relever concernant les articles de recherches sélectionnés.

illustration not visible in this excerpt

Table 2.6 : Évaluation des travaux présentés

2.6 Conclusion

Dans ce chapitre, nous avons en premier lieu présenté le principe de fonctionnement des web services SOAP, les vulnérabilités et attaques auxquelles ils sont sujets, ainsi que les contres mesures et solutions proposées pour y faire face, néanmoins ces dernières demeurent nécessaires mais non suffisantes étant donné leurs incapacités à détecter de nouvelles attaques et la capacité des attaquants à les contourner. C’est pourquoi, les chercheurs se sont orientés vers des solutions de détection plus élaborées souvent basées sur le machine learning entre autres la classification supervisée.

En deuxième lieu, nous avons recensé les principaux travaux qui s’inscrivent dans ce contexte, nous avons sélectionné ceux qui se rapprochent le plus de nos objectifs, cependant nous avons constaté que ces solutions n’exploitent pas les approches d’ensemble learning pour la détection de plusieurs types d’attaques, souvent il est question d’un seul type d’attaque détecté via un seul classifieur de ML.

C’est pourquoi nous souhaiterions apporter notre contribution à ce volet de la recherche en concevant un système de détection des attaques les plus prédomi­nantes dans le contexte des web services SOAP et cela en exploitant au mieux l’expertise d’un comité de classifieurs.

Chapitre 3 Conception

Dans ce chapitre, nous exposons la conception détaillée de la solution proposée. Le système conçu est un système de détection des attaques contre les web services SOAP en ayant recours aux méthodes de machine learning (classification super­visée basée sur la combinaison de plusieurs classifieurs), qu’il est possible d’intégrer à un firewall contrôlant l’accès aux web services.

Nous commençons par rappeler le contexte dans lequel s’inscrit ce projet, suivi de la description de la solution proposée et de son architecture globale ou il sera question de justifier les choix relatifs à l’architecture de combinaison, optimisation de l’espace de décision des classifieurs, ...etc.

Par la suite, nous présentons notre étude préliminaire (modèle de besoins) du système qui englobe l’identification des acteurs, la capture des besoins fonctionnels et techniques, identification et description des principaux modules du système (dé­coupage modulaire). Enfin, nous détaillerons les fonctionnalités de chaque module.

3.1 Introduction

Suite à l’étude menée dans le chapitre précédent, nous avons recensé les principales attaques auxquelles les web services SOAP sont confrontés ainsi que les limites des solutions existantes à ce jour, la nécessité d’une solution qui comble les vulnéra­bilités que présentent les contre-mesures et les solutions de prévention existantes est indéniable.

C’est pourquoi nous proposons de mettre en place un système capable de filtrer les messages SOAP en amont, en se focalisant sur les deux familles d’attaques XDos et injections qui demeurent les plus tenaces, et qu’il est possible de détecter en analysant la structure et le contenu de la requête SOAP. Le système conçu est basé sur la détection hybride, qui constitue un bon compromis entre « anomaly detection » qui présente souvent un taux de fausses alertes élevé et « misuse detection » qui est basée sur les signatures d’attaques exactes donc difficile à généraliser (détection de nouvelles attaques).

Cette détection se fait via un processus de classification supervisée étant donné que le système se focalise sur des catégories d’attaques connues, néanmoins l’apparition de nouvelles variantes de ces dernières est toujours envisageable, c’est pourquoi nous proposons une solution semi-automatique ou l’administrateur de sécurité pourra identifier la classe d’une requête SOAP non reconnue par le système et ainsi enrichir l’expertise de ce dernier dans la détection des attaques . L’enjeu est de faire en sortes que les situations indéfinies (une requête SOAP non reconnue) soient les plus rares possibles, en constituant des bases d’apprentissage les plus représentatives possibles, en intégrant dans cette dernière les requêtes classées par l’administrateur ainsi le système sera apte à les reconnaître la prochaine fois, en sollicitant l’expertise de plusieurs classifieurs (ensemble learning), ainsi pour toutes les autres situations apprises par le système, leurs traitements sera complètement automatique.

3.2 Solution Proposée

Notre solution consiste donc à concevoir un système de détection des attaques contre les web services SOAP en complément des solutions de sécurité existantes, permettant de :

- Concevoir et réaliser un système de détection performant et robuste en ex­ploitant les atouts de la fusion non paramétrique des classifieurs dans le contexte de la sécurité des web services.
- Optimisation de l’espace de décision des classifieurs en d’autres termes sélec­tionner le sous ensemble de classifieurs qui présente les meilleures perfor­mances.

Par le biais des connaissances acquises dans le cadre de la classification supervisée nous allons appliquer l’approche générale déduite du chapitre 2 au problème con­cret de sécurisation de SOAP sur le plan conceptuel et pratique. Cela impliquera donc que nous allons traiter des messages SOAP (fichiers XML) et les classer en trois catégories: attaque, non attaque et indéfini. En premier lieu, notre chal­lenge consistera à choisir les attributs jugés discriminants dans la caractérisation des attaques. Par la suite il sera impératif de trouver le moyen le plus adéquat pour représenter ces messages SOAP sous forme de vecteurs caractéristiques tout en gardant le maximum d’informations relatives à leur structure et contenu (faire appel aux techniques de la recherche d’informations en termes de vectorisation de textes).

En deuxième lieu, un autre point de réflexion s’impose, ce dernier concerne le choix de la configuration d’ensemble leanring la plus adéquate et son paramétrage. Par la suite, nous nous focaliserons sur l’optimisation de l’espace de décisions (méthodes de sélection abordées dans le chapitre 2).

Enfin, nous validerons notre système à travers une panoplie de tests qui perme­ttrons d’ajuster tous les paramètres du modèle de classification construit afin qu’il s’adapte au mieux aux spécificités du problème posé.

Étant donné l’ampleur de la tâche du système, ce dernier devra être extrêmement réactif et robuste ainsi le temps de réponse sera décisif en plus des critères de taux de bonne prédiction et de fausses alertes.

illustration not visible in this excerpt

Figure 3.2.1 : Principe de fonctionnement du système

Le schéma ci-dessus, expose le fonctionnement global de notre système, à l’interception d’un message SOAP par le firewall XML, ce dernier sera redirigé vers le système en question, il subira le traitement suivant:

1. Vectorisation du message SOAP: cette étape consiste à extraire les attributs du message SOAP, normaliser leurs valeurs et constituer le vecteur carac­téristique.
2. Classification du message SOAP: cette étape consiste à attribuer une classe (attaque, non attaque, indéfini) au vecteur relatif au message SOAP.
3. En fonction de la classe attribué, un des traitements suivants sera enclenché:
a) Dans le cas d’une Attaque reconnu par le système, la requête SOAP sera ignorée.
b) Dans le cas d’une Non attaque , la requête SOAP sera redirigée vers le web service concerné.
c) Dans le cas indéfini (le système n’arrive pas à identifier la nature du message), la requête SOAP sera redirigée vers l’administrateur de sécu­rité.

Dans ce qui suit, nous présenterons en détail notre solution suivant le proces­sus unifié qui est un processus de développement logiciel construit sur UML. Ce processus est itératif.

Les activités de développement sont définies par 5 workflows fondamentaux qui décrivent :

- La capture des besoins ;
- L’analyse ;
- La conception ;
- L’implémentation ;
- Le test.

3.3 Étude des besoins

Dans cette section, il est question de déterminer les fonctionnalités, les acteurs, les principaux cas d’utilisation.

3.3.1 Identification des acteurs du système

Le système sera manipulé par deux principaux acteurs, le premier assurera la détection de nouvelles formes d’attaques, il supervisera le trafic web (solution semi-automatique), le second veillera à l’adaptation (ajustement) du modèle de prédiction implémenté dans le système en cas de besoin (flexibilité de la solution):

- L’administrateur de sécurité: Cet acteur veille à la sécurité du système d’information de l’entreprise, en particulier il est responsable du bon fonc­tionnement des services web hébergés.^[5]

3.3.2 Capture des besoins fonctionnels et non fonctionnels du système

3.3.2.1 Besoins fonctionnels

Fonctionnalités relatives à l’interaction administrateur/système :

- Le système doit permettre à l’administrateur de sécurité de spécifier son rôle comme administrateur de sécurité.
- Le système doit permettre à l’administrateur de préciser le service web à superviser.
- Le système doit autoriser l’accès au système.
- Le système doit permettre à l’administrateur de visualiser les résultats de classification des messages SOAP entrants.
- Le système doit permettre à l’administrateur de modifier la classe d’un mes­sage SOAP de type indéfini.
- Le système doit relancer automatiquement la phase d’apprentissage pour les messages SOAP de type indéfini qui ont été reclassés par l’administrateur comme attaque ou non attaque.
- Le système doit permettre à l’administrateur d’enrichir la base d’apprentissage:
— Introduire des messages SOAP étiquetés de son choix.
— Relancer la phase d’apprentissage (Mise à jour du modèle).
— Mesurer les performances du nouveau modèle.
— Sauvegarder le nouveau modèle construit.
— Restaurer le modèle de classification initial en cas de besoin.

Fonctionnalités relatives à l’interaction Data-scientiste/système:

- Le système doit permettre au data-scientiste de spécifier son rôle comme data-scientiste ou administrateur.
- Le système doit permettre au data-scientiste de préciser le service web à superviser.^[6]
— Modifier la méthode de combinaison de classifieurs et d’ajuster ces paramètres.
— Modifier la méthode de validation de la base d’apprentissage.
— Mesurer les performances du modèle de classification.
— Ajuster les paramètres relatifs à la méthode de sélection de classifieurs pour l’optimisation de l’espace de décision.
— Valider les modifications apportées au modèle de prédiction.
— Restaurer le modèle de classification initial en cas de besoin.

Fonctionnalités Automatiques (propre au système):

- Le système doit être en mesure de charger les messages SOAP interceptés par le firewall.
- Le système doit charger le modèle relatif au web service du message SOAP entrant.
- Le système doit permettre la vectorisation des messages SOAP entrants.
- Le système doit permettre la classification des vecteurs caractéristiques (mes­sage SOAP).
- Le système doit afficher les résultats de la classification de chaque vecteur caractéristiques dans le fichier log.
- Le système doit permettre l’optimisation de l’espace de décision (liste des classifieurs à combiner et méthode de combinaison) du modèle de classifica­tion.

3.3.2.2 Besoins non fonctionnels (techniques)

- Le système doit être réactif (temps de réponse réduit, de l’ordre des ms).
- Le système doit être robuste (immuniser contre les attaques XDos).
- Le système doit présenter une précision au moins supérieure à 80%.
- Le système doit être doté d’une interface (IHM) conviviale, simple à utiliser.
- Le système doit être facilement déployable (intégrable aux firewall existants).
- Le système doit être parallélisable.

Notons que les deux modèles d’analyse et de conception se trouvent respectivement détaillés en annexe.

3.4 Architecture Globale du système

Dans cette section, il est question de décrire l’architecture du système d’un point de vue modulaire, nous allons donc en premier lieu recenser les principaux modules constituant le système, la fonction de chaque module et les interactions entre eux.

illustration not visible in this excerpt

Table 3.1 : Modules du système

illustration not visible in this excerpt

Figure 3.4.1 : Architecture modulaire du système

3.5 Description détaillée des modules

Le système est composé de quatre principaux modules :

3.5.1 Module de Prétraitement

Ce module est chargé d’extraire les attributs relatifs aux messages SOAP, et de les représenter sous forme de vecteurs numériques appelés vecteurs caractéristiques.

Afin de caractériser au mieux le contenu et la structure des messages SOAP entrants, nous avons jugé nécessaire de diviser l’espace caractéristique en deux ré­gions selon la catégorie de l’attaque, étant donné que les attaques XDos impactent généralement la taille du message, la consommation des ressources, le temps de traitement et la structure du message, quant aux attaques de type injections, elles impactent le plus souvent le contenu du message.

Afin de protéger notre système contre les attaques XDos qui ciblent les ressources du parseur, nous avons opté pour un troisième espace caractéristique relatif à classification préliminaire des messages entrants qui ne nécessite pas l’extraction exhaustive de tous les attributs, il regroupe des mesures relatives à la consom­mation des ressources (CPU,Mémoire,Temps d’analyse), dans ce qui suit nous les dénoterons par Attributs préliminaires .

3.5.1.1 Espace Caractéristique relatif à la classification préliminaire

L’espace caractéristique relatif à la classification préliminaire comporte les at­tributs suivants:

illustration not visible in this excerpt

Table 3.2 : Attributs préliminaire du message SOAP

3.5.1.2 Espace Caractéristique relatif à la classification XDos

Concernant les attaques XDos, la plupart des articles se basent sur les connais­sances d’experts en sécurité, en se référant aux articles [Pinzón 11], [Ghourabi 10], nous avons construit un ensemble qui compte un certain nombre d’attributs choisis avec précision. cet espace prend en considération les catégories d’attaques XDos suivantes: oversize payload, recursive payload, attaque XXE et Bomb XML.

L’espace caractéristique relatif à la classification XDos comporte les attributs suivants:

Attributs relatifs à la classification XDos

- Nombre de références vers des entités.
- Taille du message SOAP.
- Nombre d’éléments dans le message SOAP.
- Nombre d’attributs dans le message SOAP.
- Plus grande profondeur d’imbrication.
- Plus grande taille d’un élément.
- Taille de la DTD.

illustration not visible in this excerpt

Table 3.3 : Espace caractéristique XDos

3.5.1.3 Espace Caractéristique relatif à la classification des Injections

En ce qui concerne les attaques d’injections, il en existe une multitude de variétés, la plupart impactent le contenu du message SOAP, c’est pourquoi nous allons faire appel aux techniques d’analyse de textes afin de caractériser au mieux les contenus malicieux.

Afin de construire les vecteurs caractéristiques numériques, nous ferons appel à la vectorisation N-gram, qui constitue un procédé largement répandu pour la construction de l’espace caractéristique dans le cadre de la classification textuelle.

On définira un n-gram de caractères par une suite de n tokens tirés d’une séquence de texte:bi-grams pour n=2, tri-grams pour n=3, ...etc. Les tokens peuvent être des syllabes, lettres ou des mots [Choi 11], dans notre cas d’étude nous considérons les n-grams comme une suite de caractères, étant donné que notre base d’apprentissage compte plusieurs catégories d’attaques qui peuvent se présenter sous différents formes pas forcement sous forme de mots :

illustration not visible in this excerpt

Table 3.4 : Exemples de Caractéres d’injections

Cependant, dans le cas ou les n-grams sont une suite de n caractères (bytes), l’espace S de toutes les possibilités (n ^ 1) s’élève à 28n (en considérant qu’un caractère est représenté sur 1 byte):

illustration not visible in this excerpt

Étant donné que les performances d’un modèle de prédiction dépendent étroite­ment de la constitution et la dimension de l’espace caractéristique, il est impératif dans ce cas de faire appel à une méthode de réduction dimensionnelle après ajuste­ment du paramètre “n” afin d’éviter le fléau de la dimension.

Processus d’extraction des attributs pour les attaques d’injections :

- Choisir la valeur de n qui offre le meilleur compromis entre précision dans les prédictions et la complexité de calcul (plus n est petit , plus le nom­bre d’attributs est plus grand d’un autre coté souvent plus n est petit plus l’efficacité de détection est plus grande).
- Générer la grammaire relative à la base d’apprentissage (recenser tous les n- gram extraits de tous les messages SOAP présents dans la base d’apprentissage).

du i-éme n-gram dans le message SOAP .

Normalisation TF-IDF :

Afin de caractériser avec plus de précision le contenu du message SOAP, il est impératif de normaliser les occurrences avec le calcul du TF-IDF relatif à chaque n-gram dans le message en question.

- Mesure TF utilisée: La fréquence « brute » d’un terme (raw frequency) est le nombre d’occurrences de ce terme dans le document considéré [Boughanem 11].

Plusieurs variantes ont été proposées. Nous avons opté pour la normalisation logarithmique qui permet d’amortir les écarts.

TFM= 1+ log(occurrencei>d)

- Mesure IDF utilisée : La fréquence inverse de document (inverse document frequency) est une mesure de l’importance du terme dans l’ensemble du corpus (base d’apprentissage). Elle vise à donner un poids plus important aux termes les moins fréquents, considérés comme plus discriminants [TF- IDF 17]. Elle consiste à calculer le logarithme de l’inverse de la proportion de documents du corpus qui contiennent le terme :

illustration not visible in this excerpt

|D| : nombre total de documents dans le corpus ;

|di; tiG dj|: nombre de documents où le terme t* apparait.

Réduction Dimensionnelle :

Rappelons qu’une phase de réduction dimensionnelle s’impose étant donné la di­mension relativement élevée du vecteur caractéristique.

Objectifs de la réduction dimensionnelle :

Notons qu’il existe une panoplie d’approches de réduction dimensionnelle, certaines méthodes demeurent plus répandues que d’autres dans le domaine de la sécurité (IDS, sécurité des application web, ...etc) tels que PCA.

La réduction dimensionnelle est effectuée suivant deux principales approches [Singh 15]:

- La sélection d’attributs: sélection d’un sous-ensemble d’attributs à partir de l’ensemble initial, les autres attributs sont ignorés; cette approche compte plusieurs méthodes à savoir:
— Les méthodes Filter: la sélection des attributs se fait selon des scores de divers tests statistiques qui repose sur la corrélation entre les attributs et les classes à prédire, sans faire intervenir de modèles de classification.

* Exemple: Mesure KHI2, Information Gain (pour plus de détails se référer à l’annexe).

— Les méthodes Wrapper: la sélection d’attributs se fait via la consti­tution de sous ensembles d’attributs, pour chaque sous ensemble, une phase d’apprentissage est lancée sur un modèle de classification, suivi d’une phase de mesure de performances afin d’évaluer l’efficacité du sous ensemble en question, le processus est itératif jusqu’a obtention du meilleure sous ensemble.

* Exemple: Forward Selection, Backward Eliminatiton, Recursive Feature Elimination (pour plus de détails se référer à l’annexe).^[9]

Notre objectif est de déterminer l’approche de réduction dimensionnelle la plus adéquate et adaptée à notre cas d’étude, pour cela nous allons tester deux méth­odes représentatives des deux approches tels que PCA et LSA pour l’extraction d’attributs, Khi2 et Information Gain pour la sélection d’attributs en variant le nombre d’attributs pour chaque méthode, tout en mesurant la précision atteinte par le modèle de classification entraînés sur les vecteurs caractéristiques auquel nous avons appliqué la réduction dimensionnelle en question.

Au terme de cette expérimentation nous choisirons la méthode qui fournira le meilleur compromis entre précision de prédiction du modèle et temps de réduction dimensionnelle afin de respecter les exigences du système en termes d’efficacité et de rapidité de traitement.

3.5.1.4 simulation d’un cas pratique de prétraitement

A l’arrivée d’un nouveau message SOAP, le module de prétraitement extrait les attributs préliminaires relatifs à ce message, par la suite si le système considère le message comme étant une potentielle attaque XDos, il extraira la liste des attributs XDos cités plus haut, sinon il procédera à la vectorisation N-gram du messages SOAP ainsi qu’à la réduction dimensionnelle du vecteur obtenu dans le but de détecter une attaque d’injection.

illustration not visible in this excerpt

Figure 3.5.1 : Module de vectorisation détaillé

illustration not visible in this excerpt

Figure 3.5.2 : Partie DTD

illustration not visible in this excerpt

Figure 3.5.3 : Enveloppe du message SOAP

Résultat de la vectorisation préliminaire:

illustration not visible in this excerpt

Table 3.5 : Vecteur caractéristique préliminaire

Résultat de la vectorisation XDOS:

illustration not visible in this excerpt

Table 3.6 : Vecteur caractéristique XDOS

Résultat de la vectorisation Injection:

illustration not visible in this excerpt

Table 3.7 : Vecteur caractéristique Injection

3.5.2 Module de Classification

Dans cette partie, il est question de discuter le choix de la configuration d’ensemble learning pour laquelle nous avons opté, cela inclut : l’architecture de combinaison, le type de fusion et la méthode de sélection, avant d’entamer la description détaillée de ce module.

3.5.2.1 Choix de l’architecture de combinaison

illustration not visible in this excerpt

3.5.2.2 Choix du type de Fusion

Rappelons qu’il existe deux types de fusion:

- La fusion faible (EOC) qui consiste à obtenir un classifieur fort à partir d’un ensemble de classifieurs faibles moyennant un algorithme d’ensemble learning.
- La fusion d’algorithmes différents qui consiste à trouver via un opérateur de fusion un consensus entre les résultats des différents classifieurs.

Notons que parmi les principales caractéristiques de la base d’apprentissage dans le cas de la fusion faible est le nombre considérable d’attributs et le grand volume de la base, ce qui ne correspond pas exactement à notre situation, étant donné que nous ne disposons pas de datasets extrêmement volumineux. C’est pourquoi notre choix s’est orienté vers la fusion d’algorithmes différents que nous jugeons la plus appropriée.

Nous préconisons la méthode de fusion de classifieurs implémentant différents algorithmes de classification, pour apporter de la diversité au système étant donné qu’il doit reconnaître plusieurs catégories et variantes d’attaques (oversize pay­load, SQL inejctions, récursive payload, ...etc), plus particulièrement nous nous orientons dans un premier temps vers les méthodes de fusion non paramétrique étant donnée leur simplicité de mise en œuvre, ils ne nécessitent pas de phase d’apprentissage supplémentaires, de plus ils présentent souvent d’aussi bons résul­tats que la fusion paramétrique.

Quant à l’opérateur de fusion, il sera préférable de ne pas le fixer au préalable, nous allons donc procéder à un processus itératif de testes moyennant une base de validation dans le but de déterminer l’opérateur le plus performant dans notre cas.

illustration not visible in this excerpt

Figure 3.5.4 : Ajustement de l’opérateur de fusion

3.5.2.3 Choix de la méthode de sélection des classifieurs

En ce qui concerne l’optimisation de l’espace de décision, nous avons recensé deux principales approches:

la sélection statique et la sélection dynamique qui se distingue de la première par son adaptation à l’individu à classifier, néanmoins elle demeure au stade de la recherche et reste très théorique, contrairement aux méthodes de sélection statique qui répondent amplement au besoin de sélectionner un sous ensemble de classifieurs offrant le meilleur compromis Rappel/précision tout en optimisant le temps de traitement.

Dans l’approche statique, il existe divers méthodes de sélection de classifieurs, tels que les méthodes heuristiques qui peuvent s’adapter à divers domaines, notons que les algorithmes génétiques sont très répandus dans la combinaison de classi­fieurs. C’est pourquoi nous nous orientons vers une optimisation de l’espace de décision des classifieurs basée sur les AGs.

Rappelons donc que nous avons choisi l’approche de combinaison parallèle, en ayant recours à la fusion d’algorithmes différents, et nous avons opté pour les AGs comme méthode de sélection des classifieurs.

3.5.2.4 Choix des classifieurs à combiner

Pour ce qui est du choix des classifieurs, nous allons implémenter les plus répandus (dans le domaine des IDS, sécurité des applications web), à savoir:

illustration not visible in this excerpt

Figure 3.5.5 : Choix des classifieurs

3.5.2.5 Choix de l’architecture globale du système

Nous avons envisager Plusieurs architectures globales:

Architecture Parallèle

illustration not visible in this excerpt

Figure 3.5.6 : Architecture globale parallèle

Dans ce cas de figure, le système analyse le message SOAP pour détecter une éventuelle attaque XDos ou une éventuelle attaque d’injection, le traitement se fait d’une manière tout a fait indépendante et parallèle.

illustration not visible in this excerpt

Figure 3.5.7 : Architecture globale Série

Dans ce cas de figure, le système analyse le message SOAP pour détecter une éventuelle attaque XDos. Si la classification XDos retourne la classe attaque , il rejette le message, dans le cas contraire il analyse le message pour détecter une éventuelle attaque d’injection.

illustration not visible in this excerpt

Figure 3.5.8 : Architecture globale Hybride

Dans ce cas de figure, le système analyse le message SOAP en premier lieu afin de détecter si ce message est potentiellement dangereux pour le système, dans ce cas le message ne sera pas analysé, sinon si le système détecte que ce message présente une potentielle attaque XDos, il l’acheminera vers la classification XDos plus approfondie, dans le cas ou il détecte que ce n’est pas une potentielle attaque XDos le message sera acheminé vers la classification spécialisée dans les attaques d’injections.

Si la classification XDos retourne la classe “non attaque” ou indéfini , afin de ne prendre aucun risque, le système ré-achemine le message vers la classification spécifique aux injections.

Comparaison entre les architectures proposées

illustration not visible in this excerpt

Table 3.8 : Tableau Comparatif des architectures globales du système

Notons que l’architecture hybride offre un bon compromis en termes de temps de traitement et d’occupation CPU, de plus elle offre un dispositif de sécurisation du système, c’est pourquoi nous avons opté pour cette dernière architecture.

3.5.2.6 Classification Préliminaire

La classification préliminaire est une mesure de sécurisation du système contre les attaques XDos qui peuvent altérer le fonctionnement du parseur du système.

Le but de cette classification qui ne consomme pas beaucoup de ressources, est de distinguer les messages SOAP considérés comme XDos dangereux (présentent un danger pour le système de détection) qui ne seront pas analysés (accès refusé au système), des messages Potentiel XDos (nécessitant l’extraction de plus d’attributs pour pouvoir les classer), des messages dont nous sommes sûr qui ne présentent aucun danger en termes de déni de service.

Principe de fonctionnement

Pour cela, nous allons faire appel à une méthode de régression qui permettra de prédire la taille d’un message SOAP à partir des mesures reflétant la consomma­tion de ressources engendrée par l’analyse du message SOAP en question (taux d’occupation CPU, mémoire et le temps de traitement) par un parseur XML de type SAX. Le modèle de régression sera entraîné sur une base d’apprentissage con­stituée de messages SOAP valides, représentés selon l’espace caractéristique des attributs préliminaires.

Le but de cette classification est de vérifier si certaines caractéristiques du traite­ment du message SOAP (tels que le temps de réponse, l’occupation mémoire et l’occupation du processeur) sont conformes à la taille du message SOAP.

En d’autres termes, ce classifieur analyse l’utilisation des ressources pour chaque message SOAP intercepté et prédit sa taille, en comparant la taille prédite avec la taille réelle, il est possible de déterminer si le message SOAP représente un réel danger pour le système de détection. Dans le cas où la différence entre les deux tailles dépasse un certain seuil max ε1 (différence entre taille prédite et taille réelle à ne pas dépasser) le message sera considéré comme étant dangereux, si cette différence se trouve au-dessous d’un seuil minimal ε2, le message sera consid­éré comme non dangereux, il sera acheminé directement vers la classification des injections, par contre si cette différence se situe entre les deux seuils ει et ε2, le message est considéré comme potentiel XDos.

Le choix de la méthode de régression à préconiser sera fixé après avoir tester plusieurs algorithmes de régression tels que SVR (Support Vector Regression), Régression linéaire, nous opterons pour celui qui présentera les meilleurs résultats en termes de précision, et rapidité de traitement.

Processus :

- Récolter les messages SOAP valides.
- Extraire les attributs suivants de chaque message SOAP: taille du message, temps d’analyse par le parseur, occupation CPU, occupation mémoire.
- Construire les vecteurs caractéristiques à partir des attributs extraits relatifs à chaque message.
- Mettre les vecteurs caractéristiques des messages valides dans une base d’apprentissage (Anomaly Detection).
- Entraîner l’algorithme de régression sur cette base d’apprentissage.
- Construire une base de tests comportant un nombre important de messages SOAP XDos (plusieurs occurrences de chaque catégorie par exemple oversize payload, recursive payload, ...etc).
- Tester l’algorithme de régression sur cette base de tests et fixer le seuil max­imum de l’erreur ει ainsi le seuil minimum de l’erreur ε2.^[10]

illustration not visible in this excerpt

illustration not visible in this excerpt

Figure 3.5.11 : Processus de Classification XDos

3.5.2.8 Classification Injection

Similaire à la classification XDos, nous ferons donc appel à un comité de clas- sifieurs différents (implémentant différents algorithmes) entraînés sur la totalité de la base, que nous combinerons via un opérateur de fusion choisi après avoir tester les opérateurs les plus répandu en se basant sur les résultats de mesures de performances obtenues sur une base de validation.

illustration not visible in this excerpt

Figure 3.5.13 : Processus de Classification Injection

3.5.3 Application des AGs

Plusieurs approches d’algorithmes génétiques ont été adoptées dans le cadre des méthodes d’ensemble learning :

illustration not visible in this excerpt

Figure 3.5.14 : Articles relatif à l’application des AGs dans la classification

Dans le cadre de notre cas d’étude, nous allons opter pour l’optimisation du choix de l’opérateur de fusion ainsi que les classifieurs à combiner étant donné que l’espace caractéristiques a été fixé au préalable de plus l’ensemble des classifieurs est entraînés sur la totalité de la base d’apprentissage.

Dans ce qui suit, nous présentons notre conception des AGs:

Objectifs de l’AGs :

- Choisir le sous ensemble de classifieurs de base le plus performant (choisir qui combiner avec qui et combien combiner).^[11]

Codage du problème :

Structure Du Chromosome :

Elle est représentée sous forme d’un vecteur binaire composé de deux partie; la première partie est relative au type de classifieurs, la deuxième partie est relative à la méthode de combinaison.

Concernant la partie1, la position d’un élément indique le type du classifieur et la valeur de l’élément indique la présence (1) ou l’absence (0) du classifieur dans la combinaison.

Liste des classifieurs de base :

- Les SVMs (variant le noyaux, C).
- Les variantes de l’arbre de décision AD.
- Les KNNs (en variant les distances, le k).
- Les variantes de Naïve Bayes NB.

Concernant la partie2, la position d’un élément indique le type de l’opérateur de fusion et la valeur de l’élément indique la présence (1) ou l’absence (0) de ce dernier.

Liste des opérateurs de fusion:Vote majoritaire, Somme, Produit, Max, Médiane, Min.

illustration not visible in this excerpt

Figure 3.5.15 : Structure du Chromosome

Fitness :

L’algorithme génétique est multi-objectifs :

- Objectif 1: accroître la précision en d’autre termes maximiser le nombre de bonnes prédictions dans la base de validation : A= VP+VN/P+N ;
- Objectif 2: réduire le taux de fausse alerte f2= FP/N;
- Objectif 3: Minimiser le temps de traitement du modèle : f3= T tempsPrédiction

Afin d’agréger tous ces objectifs au sein de la mème formule nous nous sommes in­spirées de la somme pondérée qui demeure la méthode d’agrégation la plus utilisée étant donnée sa simplicité de mise en oeuvre.

Formule complète :

illustration not visible in this excerpt

Table 3.9 : Paramètres de l’AG

illustration not visible in this excerpt

Remarques :

L’opérateur de croisement choisi est le croisement à un point, il permet de permuter entre l’ensemble de classifieur et l’opérateur de fusion de deux individus différents.Quant à l’opérateur de mutation, il peut s’appliquer sur l’ensemble de classifieurs (ajouter ou supprimer un classifieurs) ou sur le type de l’opérateur de fusion.

3.5.4 Module de Mapping

Ce module prend en charge la correspondance entre le web service et son modèle de classification ainsi que sa base d’apprentissage, à l’arrivée d’un message SOAP il charge le modèle correspondant au web service relatif au message intercepté, en cas de mise à jour dans la base ou dans le modèle, ce module les prend en charge.

3.6 Conclusion

Dans ce chapitre, nous avons proposé un système de détection des attaques contre les web services SOAP, basé sur la combinaison des algorithmes de classification supervisée,en effet nous avons présenté l’architecture globale de notre système ainsi que son fonctionnement, nous avons décrit le système d’un point de vue modu­laire en détaillons la conception de chaque module, ensuite nous avons expliqué le processus général de la détection, notons que le logiciel a été conçu selon la méthodologie UP.

Quant aux choix techniques, outils de développement, construction de la base d’apprentissage, sources des données, il seront détaillés dans le chapitre suivant.

illustration not visible in this excerpt

Chapitre 4 Réalisation et Tests

4.1 Introduction

Après avoir conçu notre système de sécurité et détailler les différents modules qui le compose, nous entamons à présent la réalisation et le déploiement de notre solution (codage et testes) comme le préconise la démarche UP.

Nous exposons en premier lieu les différents choix techniques auxquels nous avons été confrontés (système d’exploitation, environnement de développement et langage de programmation) dans l’implémentation ainsi que les outils open source sollicités dans la réalisation de notre solution. Enfin nous détaillerons la phase de tests menée dans le but de concrétiser notre conception et cerner les modèles de combinaison les plus adéquats.

4.2 Environnement du développement

Nous déployons le système conçu pour un système d’exploitation Linux avec la dis­tribution UBUNTU (16.04 LTS /16.10 AMD) en utilisant le langage de program­mation portable Python. Nous avons aussi utilisé des outils et des bibliothèques open source qui seront détaillés dans ce qui suit.

4.2.1 Langage de programmation

Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans l’imposer) une approche modulaire et orientée objet. Il est aussi classé parmi les langages leaders dans le domaine de machine learning [Python17]. Les principales caractéristiques de Python sont :

- La syntaxe de Python est très simple et, combinée à des types de données évolués (listes, dictionnaires...), conduit à des programmes à la fois très com­pacts et très lisibles.
- Python gère ses ressources (mémoire, descripteurs de fichiers...) sans inter­vention du programmeur, par un mécanisme de comptage de références.
- Python est (optionnellement) multi-threadé.
- Python est dynamique (l’interpréteur peut évaluer des chaînes de caractères représentant des expressions ou des instructions Python), orthogonal (un petit nombre de concepts suffit à engendrer des constructions très riches), réflectif (il supporte la méta-programmation, par exemple la capacité pour un objet de se rajouter ou de s’enlever des attributs ou des méthodes, ou même de changer de classe en cours d’exécution) et introspectif (un grand nombre d’outils de développement, comme le debugger ou le profiler, sont implantés en Python lui-même).

4.2.2 Les bibliothèques utilisées

Scikit learn :

Scikit-Learn est une bibliothèque de machine learning open source (écrite en Python) qui implémente un grand nombre d’algorithmes de machine learning à l’instar de la classification, la régression et le clustering [SKlearn17].

La bibliothèque QXmlStreamReader:

La bibliothèque QXmlStreamReader est un module du package PyQt de Python qui fournit un analyseur syntaxique (parseur) rapide de type StAX (pour Stream­ing API for XML en anglais). Comme les perseurs SAX, StAX sont orientés évènements et ne chargent en mémoire que la portion du flux XML dont ils ont besoin. Ainsi, un parseur StAX traite les documents XML comme un flux de To­kens. La seule différence entre SAX et StAX réside dans la façon dont ces Tokens sont rapportés. Nous utilisons un tel parseur pour éviter une attaque XDoS sur le parseur lors de l’analyse du message SOAP.

XML.SAX:

SAX est un analyseur XML qui traite les messages SOAP élément par élément, ligne par ligne. Il permet d’extraire des informations à partir d’un document XML dans une forme évènementielle. Le parseur xml.sax fournit un certain nombre de modules qui implémentent l’interface Simple API pour XML (SAX) pour Python,

cependant il n’est pas sécurisé contre les données mal construites. Nous devons analyser les données non approuvées ou non authentifiées en consultant les vul­nérabilités [XMLSAX17].

DEAP:

DEAP est une bibliothèque qui cherche à rendre les algorithmes et les structures de donnée explicites et transparentes. Elle fonctionne en parfaite harmonie avec les mécanismes de parallélisation tels que le multiprocessus [Deap17]. DEAP com­prend les fonctionnalités suivantes :

- Algorithme génétique utilisant toute représentation imaginable Liste, Array, Set, Dictionary, Tree, Numpy Array, etc.
- Programmation génétique utilisant des arbres préfixés Optimisation multi- objectifs (NSGA-II, SPEA-II)
- Co-évolution (coopérative et compétitive) de multiples populations
- Parallélisation des évaluations (et plus)
- Module de benchmarks contenant les fonctions de test les plus communes
- Les algorithmes alternatifs: optimisation des essaims de particules, évolution différentielle, estimation de l’algorithme de distribution.. .etc.

QT :

Qt est une bibliothèque logicielle offrant essentiellement des composants d’interface graphique (communément appelés widgets), mais également d’autres composants non-graphiques permettant entre autre l’accès aux données, les connexions réseaux, la gestion des files d’exécution, etc. Elle a été développée en C++ par la société Trolltech et est disponible pour de multiples environnements Unix utilisant X11 (dont Linux), Windows et Mac OS. Qt est un toolkit qui présente de nombreux avantages. Il est intéressant de les souligner puisque ces avantages se retrouvent dans PyQt.

PyQt est un module qui permet de lier le langage Python avec la bibliothèque Qt. Il permet ainsi de créer des interfaces graphiques en python. Une extension de QtDesigner (utilitaire graphique de création d’interfaces Qt) permet de gérer le code python d’interfaces graphiques. PyQt dispose de tous les avantages lié à Qt.

A travers cette partie, nous avons présenté la réalisation de l’application en justifiant nos choix technologiques, en décrivant brièvement les bibliothèques et les outils invoquées. A présent nous entamons la phase de tests.

4.3 Résultats Expérimentaux et Interprétations

Dans cette partie il sera question d’exposer en détail l’ensemble de tests que nous avons effectués ainsi que leurs interprétations afin de concrétiser les modèles de prédiction décrits au niveau du rapport de conception et d’évaluer le système de détection d’attaques conçu en termes de précision, de taux de fausses alertes enregistrés et enfin en termes de réactivité (temps de traitement des messages).

Dans le graphe ci-dessous, nous rappelons l’architecture globale de notre sys­tème:

illustration not visible in this excerpt

Figure 4.3.1 : Architecture Globale du Système

Afin de mener à bien cette étude expérimentale, nous suivrons le plan de test global ci-dessous:

1. Phase de tests relative à la construction du modèle de régression de la phase préliminaire responsable de la sécurisation du système contre les attaques de déni de services ainsi que l’aiguillage des messages interceptés vers le module de détection le plus adéquat (XDos/Injection).
2. Phase de tests relative à la construction du modèle de classification respon­sable de la détection des attaques XDos.
3. Phase de tests relative à la construction du modèle de classification respon­sable de la détection des attaques d’injections.

Dans ce qui suit, nous commencerons par présenter l’environnement d’expérimentation dans lequel se sont déroulés la totalité des tests ainsi qu’une brève description des caractéristiques des web services sur lesquels ces derniers ont porté suivi des résul­tats et interprétations de chaque phase de test, nous terminerons par une synthèse générale englobant les principales conclusions tirées à partir de cette étude.

4.3.1 Environnement Expérimental

4.3.1.1 Web Services invoqués pour les tests

L’étude expérimentale que nous allons mener, portera sur deux web services dif­férents, plus précisément sur deux méthodes distinctes:

- Méthode GetUserInfo du web service vulnweb qui est un web service vul­nérable aux attaques relatives à SOAP, développé par Acunetix de cette manière intentionnellement afin d’initier les développeurs aux aspects de la sécurité informatique [Acunetix 17].
- Méthode Subscribe simulant un formulaire d’inscription à une plateforme de e-commerce.

4.3.1.2 Génération des messages SOAP

Afin de simuler les données des datasets, nous avons eu recours aux outils de scan de vulnérabilités dans le cadre des web services SOAP tels que:

- SOAPUI (spécialement pour les attaques XML Bomb) [SOAPUI 17].
- WSFuzzer [WSFUZZER 17].
- BurpSuite [bURPSUITE 17].

Pour ce qui est des données valides, nous les avons récoltés à partir des fichiers Username et Password de BurpSuite qui représentent des données réelles, de même pour Subscribe nous avons fait appel aux banques de données gratuites afin de récupérer les valeurs des champs d’inscription [briandunning 17].

4.3.2 Mesures d’évaluation utilisées

Afin d’évaluer et de comparer les différents modèles de prédiction, nous nous baserons principalement sur les métriques suivantes:

4.3.2.1 Mesures d’évaluation utilisées dans la phase préliminaire

Afin de comparer entre les différents modèles de régressions, nous avons eu recours à deux principales métriques:

illustration not visible in this excerpt

Table 4.1 : Mesures d’évaluation

Tout au long de cette phase de test, nous désignerons la première métrique par MAE (mean absolute error) et la seconde par MEAE (median absolute error).

4.3.2.2 Mesures d’évaluation utilisées dans la classification XDos/Injection

Afin de comparer entre les différents modèles de classification, nous avons pris en considération les métriques suivantes (les plus répandus en IDS). tels que:

- TP: désigne une réelle attaque classée comme attaque par le système.
- TN: désigne un message valide classé comme bon message par le système.
- FP: désigne un message valide classé comme attaque par le système.
- FN: désigne une réelle attaque classée comme bon message par le système.

illustration not visible in this excerpt

Table 4.2 : Mesures d’évaluation utilisées

4.3.3 Résultats de la classification préliminaire

L’objectif de la phase préliminaire consiste en premier lieu à sécuriser notre système de détection en contrôlant la consommation des ressources en termes de temps de traitement, occupation CPU et mémoire, en deuxième lieu il permettra d’optimiser l’acheminement des messages SOAP vers le modèle de classification le plus adéquat (Classification XDos/Injection). Pour cela, nous ferons appel à une méthode de régression qui permettra de subdiviser l’ensemble des messages SOAP interceptés en trois régions: non dangereux (déni de service), potentiel XDos, dangereux XDos.

Afin de mener à bien l’étude de la phase préliminaire, nous avons suivi les étapes suivantes:

illustration not visible in this excerpt

Table 4.3 : Plan de tests de construction du modèle préliminaire

4.3.3.1 Construction des datasets

Afin de choisir le modèle de régression le plus approprié, nous avons construit un échantillon comportant 470 messages SOAP valides pour chaque web service utilisé (méthode GetUserInfo et Subscribe), que nous avons par la suite vectorisés selon l’espace caractéristique relatif à la phase préliminaire :

- Temps de traitement du message SOAP par le parseur.
- Occupation CPU nécessaire à l’analyse du message SOAP.
- Occupation Mémoire nécessaire à l’analyse du message SOAP.

Une fois les vecteurs caractéristiques obtenus, nous avons jugés nécessaire de procéder à une normalisation de leurs valeurs pour réduire l’impact des valeurs aberrantes et augmenter l’efficacité de prédiction de chaque modèle de régression. Pour cela nous avons fait appel à une normalisation standard qui consiste à sous­traire de chaque valeur la moyenne et diviser le résultat par la variance.

Nous avons par la suite subdiviser le dataset obtenu en données d’apprentissage (60%) et données de tests(40%) comme suit:

illustration not visible in this excerpt

Table 4.4 : Constitution du dataset relative à la Phase de tests 1

NB: notons que l’étude expérimentale a été menée sur une machine disposant de 8Go de RAM et d’un processeur Intel i7-4510U et 1 To SATA (disque dur).

4.3.3.2 Choix du modèle de régression

Nous avons sélectionné un certain nombre d’algorithmes de régression, cette en­semble inclut la régression linéaire multiple qui constitue l’approche de régression la plus répandue étant donné sa simplicité de mise en œuvre, ainsi qu’un cer­tain nombre de variantes de SVR qui parviennent à approximer des fonctions de prédictions des plus complexes, de plus elles présentent des temps de prédiction rel­ativement réduits ce qui favorise la réduction du temps de traitement du message SOAP dans la phase préliminaire.

Le test que nous avons effectué consiste à afficher la distribution des données de tests (représenter la taille de chaque message en fonction de l’individu) con­jointement aux prédictions des différents algorithmes de régression sur cette même base de tests, cela nous permettra de distinguer facilement les situations de sur­apprentissage ou de sous-apprentissage.

Résultats obtenus pour la méthode Subscribe

illustration not visible in this excerpt

Figure 4.3.2 : Comparaison entre les algorithmes de régression

Observations et Interprétation des résultats

illustration not visible in this excerpt

Table 4.5 : Observations et Interprétation des résultats du Test n°1

Étant donné la distribution non linéaire des données, les deux modèles SVR linéaire et Régression linéaire ne présentent pas des résultats concluants, nous pouvons donc réduire l’intervalle de recherche du meilleure modèle en les éliminant, pour la suite de l’étude nous nous focaliseront donc sur les modèles non linéaires tels que SVR Polynomial et SVR RBF.

4.3.3.3 Recherche des meilleurs paramètres du modèle choisis

En observons les résultats du test n°1, nous distinguons deux régions dans la distribution des données (la majorité des données se concentre autour de la taille moyenne (500 octet) et le reste de données se répartie de manière homogène au- dessus de de la tailles moyenne. Notre objectif est de construire un modèle qui cerne en premier lieu le comportement prédominant des données (la majorité des données qui se concentre autour de la taille moyenne 500o) cela est possible en ajustant les paramètres intrinsèques des deux modèles (RBF et Polynomiale). Quant aux données qui se répartissent de manière homogène au-dessus de la taille moyenne 500o, ils seront pris en considération après fixation des seuils d’erreurs min et max dans le test n°3.

Résultats obtenus pour la méthode Subscribe

illustration not visible in this excerpt

Figure 4.3.3 : Comparaison entre les modèles de régression après variation de leurs paramètres

Observations et Interprétation des résultats

illustration not visible in this excerpt

Table 4.6 : Observations et Interprétation des résultats du Test n°2

Afin d’évaluer la qualité de prédiction des modèles précédents avec plus de précision nous avons eu recours aux métriques citées plus haut :

illustration not visible in this excerpt

Nous observons que le noyau polynomial inscrit le plus faible taux d’erreurs dans ces prédictions quel que soit la métrique d’évaluation utilisée.

Après avoir affiner Les paramètres intrinsèques au modèle de régression « SVR Polynomial » sa qualité de prédiction c’est nettement amélioré comparé aux autres modèles avec un taux d’erreur inférieur à 0.02ko. Cependant, il est impératif de prendre en considération cette erreur qui représente la distance moyenne entre les deux nuages des données (cités plus haut), c’est pourquoi nous rappelons la prise en considération du deuxième nuage de points dans la prochaine phase de fixation des seuils.

4.3.3.4 Fixation des seuils

Après l’étude menée précédemment nous avons fixé la configuration du modèle de régression comme suit :

illustration not visible in this excerpt

Figure 4.3.5 : Configuration retenue pour le modèle de régression

A présent que la configuration du modèle de régression a été établie, nous en­tamons la phase de fixation des seuils, rappelons que pour cela nous aurons re­cours à une base de tests constituées de bon et de mauvaise messages (attaques XDos). Afin que les résultats soient représentatives et facilement interprétables, nous n’avons représentés qu’un échantillons des données (environs 70 messages) sur les graphes ci-dessous où il est question de représenter les erreurs de prédictions du modèle de régression en fonction des individus de la base de tests.

Résultats obtenus pour GetUserInfo et Subscribe

illustration not visible in this excerpt

Figure 4.3.6 : Fixation seuils approximatives des méthodes GetUserInfo et Sub­scribe (respectivement)

illustration not visible in this excerpt

Table 4.7 : Observation et interprétation pour la fixation des seuils

4.3.3.5 Synthèse

Cette étude porte principalement sur deux méthodes de deux web services dif­férents, elle nous a permis en premier lieu de sélectionner le modèle de régression le plus adéquat, il s’agit dans ce cas du modèle “SVR Polynomial”.

Une fois le modèle de régression choisis, nous avons parvenu à améliorer les performances de ce dernier en ajustant ces paramètres (C=100, epsilon=0.001, gamma=0.1, degré=2) et cela en se basant sur les mesures mean absolute error et median absolute error que nous avons jugé les plus significatives.

Afin de fixer les seuils de la phase préliminaire, nous avons appliqué le mod­èle retenu sur une base de tests (comportant autant de messages valides que d’attaques XDos toutes catégories confondus), cette expérimentation nous a per­mis de fixer approximativement les seuils min et max de l’erreur pour chaque web service comme suit:

illustration not visible in this excerpt

Table 4.8 : Fixation des seuils

Afin de généraliser d’avantage les décisions résultantes de la classification prélim­inaire, nous avons quantifié les seuils comme suit :

- Pour ce qui est du seuil min, si l’erreur commise par modèle de régression dépasse l’erreur moyenne (des messages valides) de 50 % alors le message est considéré comme potentiel XDos.
- Pour ce qui est du seuil max, si l’erreur commise dépasse 3 fois le seuil min le message est considéré comme dangereux (accès refusé au web service).

4.3.4 Résultats de la classification des attaques XDos

Après mise en place du modèle de régression (étude menée précédemment) qui permet entres autres de distinguer les messages SOAP potentiels XDos des autres messages, une analyse plus approfondie de ces potentiels XDos s’impose afin de les classer avec plus de précision (Attaque/Non Attaque) en se basant cette fois-ci sur la structure du message SOAP intercepté, pour cela nous avons eu recours aux méthodes de combinaison de classifieurs afin d’octroyer un certain niveau de confiance aux prédictions du système.

Cette étude a pour principal but d’évaluer l’apport de la combinaison de classi­fieurs dans la classification des attaques XDos, il est nécessaire de cerner le com­portement des opérateurs de fusion en fonctions du nombre, le type de classifieurs utilisés et la constitution du dataset d’apprentissage, pour cela nous allons suivre le plan de test suivant:

illustration not visible in this excerpt

Table 4.9 : Plan de Test Classification XDos

4.3.4.1 Construction des datasets

- Constitution du dataset relatif à la méthode GetUserInfo:

illustration not visible in this excerpt

Table 4.10 : Constitution du dataset relatif à GetUserInfo

- Constitution du dataset relatif à la méthode Subscribe:

illustration not visible in this excerpt

Table 4.11 : Constitution du dataset relatif à Subscribe • Rappel de l’espace caractéristique de la classification XDos:

Attributs relatifs à la classification XDos

- Nombre de références vers des entités.
- Taille du message SOAP.
- Nombre d’éléments dans le message SOAP.
- Nombre d’attributs dans le message SOAP.
- Plus grande profondeur d’imbrication.
- Plus grande taille d’un élément.
- Taille de la DTD.

illustration not visible in this excerpt

Table 4.12 : Espace caractéristique XDos

4.3.4.2 Apport de la fusion de classifieurs

Avant d’entamer l’interprétation des résultats obtenus, nous avons jugé nécessaire d’évaluer le comportement de chaque classifieur à part, dans le but de mieux expliquer les prédictions obtenues pour chaque modèle de combinaison par-là suite.

Le tableau ci-dessous englobe les principaux paramètres pris en considération pour chaque algorithme de classification:

illustration not visible in this excerpt

Table 4.13 : Paramètres mono-classifieur

De cette étude mono-classifieur, nous avons dégagés les observations suivantes (valables pour les deux web services) : classifieurs, de plus KNN affiche un temps de prédiction relativement élevé (spécialement pour la mesure de distance de type minkowski).^[12]

- Pour ce qui est des classifieurs basés sur SVMs, nous constatons que le classi- fieur à noyau RBF se démarquent des autres noyaux (linéaire,sigmoid, poly­nomial) en présentant d’aussi bons résultats que KNN et AD, cependant il affiche un taux de fausses alertes de 1.3 %, de plus son temps de prédiction est légèrement plus élevé (de l’ordre de 0.03s) que AD.

- Quant aux classifieurs implémentant Naive Bayes, ils présentent des résul­tats plus ou moins bon mais ils demeurent inférieures à celles affichées par KNN,AD et SVM(rbf), on distingue une amélioration dans les prédictions de NB (multinomial) par rapport à NB (Gaussian) en termes de précision.

À partir de ces observations, nous avons constitué des sous-ensembles de classifieurs en se basant sur les performances des classifieurs à combiner ainsi que sur leur nombre, c’est ainsi que nous avons fixé les ensembles suivants pour les tests :

illustration not visible in this excerpt

Table 4.14 : Ensembles de tests XDos Partie 1

illustration not visible in this excerpt

Table 4.15 : Ensembles de tests XDos Partie 2

illustration not visible in this excerpt

Table 4.16 : Ensembles de tests XDos Partie3

Résultats relatifs à la méthode GetUserInfo

illustration not visible in this excerpt

Table 4.17 : Résultats relatifs à la méthode GetUserInfo (moins de 5 classifieurs)

illustration not visible in this excerpt

Table 4.18 Résultats relatifs à la méthode GetUserInfo (plus de 5 classifieurs)

Résultats relatifs à la méthode Subscribe

illustration not visible in this excerpt

Table 4.19 : Résultats relatifs à la méthode Subscribe (plus de 5 classifieurs)

Observations et interprétations

Après analyse des résultats de prédictions relatives aux deux datasets construits pour chaque web service, nous avons observé des similitudes dans le comportement des opérateurs de fusion, que nous avons synthétisées ci-dessous :

- La présence d’un classifieur prédominant (performant) dans un ensemble de classifieurs à taille réduite (par exemple constitué de 3 classifieurs dont la plupart ont des performances moins bonnes tels que dans la Config_XDos1) favorise une meilleure précision dans les prédictions des opérateurs fixes tels que min, max et produit qui sont dans ce cas plus performants que le vote majoritaire qui est plus sensible à la qualité des classifieurs en termes de prédiction et leur nombre.
- Dans certaines situations, malgré la présence de classifieurs forts dans l’ensemble (tels que la Config_XDos4), leurs performances n’impactent pas les décisions de l’opérateur de fusion en présence de classifieurs légèrement moins bons mais qui arrivent tout de même à faire chuter considérablement les perfor­mances (perte de 40% d’accuracy), c’est pourquoi il est impératif que les classifieurs à combiner présente une certaine diversité dans leurs prédictions (ne se trompent pas de la même manière) pour que la combinaison apporte de meilleures performances.
- Plus le nombre de classifieurs est grand, plus nous observons une stabilité dans les prédictions de la médiane qui constitue un bon compromis par rap­port au min et max et est considérée comme étant plus robuste (ceci est observable à partir des configurations comportant plus de 10 classifieurs).
- Plus le nombre de classifieurs est grand, plus les situations de conflits sont plus probables, dans certains cas de figures la moyenne est plus précise que le vote majoritaire (tels que dans la Config_XDos10 où l’on observe une amélioration de 30% d’accuracy).
- Les résultats de tests obtenus attestent du fait que combiner tous les clas- sifieurs dont nous disposons ne présentent pas toujours les meilleures per­formances en termes de prédictions (Config_XDos3 présente de meilleures performances que la Config_XDos5 par exemple), de plus il est difficile de rechercher le modèle optimal en termes de temps et de qualité de prédiction manuellement lorsque le nombre de classifieurs dépasse une dizaine.

Notons que dans certaines situations où les bonnes prédictions des classifieurs forts étaient noyées par les mesures de confiances erronées d’autres classifieurs moins bons, une fusion paramétrique aurait été plus fructueuse, cependant la détermi­nation des poids des classifieurs n’est pas une tâche si évidente, dans le cas où l’on utilise une base de validation, les poids seraient fixes est dépendants de cette base, cela nécessitera donc de les mettre à jour de manière récurrentes. Il existe une autre alternative qui consiste à inhiber les classifieurs les moins performants de manière dynamique selon la situation, nous faisons allusion aux méthodes de sélec­tion de classifieurs plus particulièrement des AGs qu’il sera question d’étudier dans la prochaine partie des tests, nous appliquerons donc ces méta-heuristiques sur les ensembles des tests précédents pour faire sortir à chaque fois le sous-ensemble de classifieurs le plus performant de manière dynamique.

4.3.4.3 Apport de la méthode de sélection de classifieurs

Le tableau ci-dessous, comporte le paramétrage des AGs utilisé lors des tests, notons que pour les ensembles à taille réduite, nous avons opté pour une taille de population de 50 individus avec une dizaine de générations, cependant pour les ensembles comportant plus d’une dizaine de classifieurs, nous avons jugé nécessaire d’augmenter de manière significative la taille de la population ainsi que le nombre de générations étant donné que l’espace de décision est devenu plus grand.

Pour ce qui est de la probabilité de croisement, nous l’avons fixé à une valeur de 0.5 car plus ce taux est élevé, plus la population subit des changements importants, cette valeur constitue donc un bon compromis dans notre cas.

Quant à la probabilité de mutation, notons qu’elle participe au maintien de la diversité dans les solutions et permet d’éviter les optimums locaux, elle permet donc une bonne exploration du domaine de recherche, souvent il est conseillé de la choisir entre 0.01 et 0.1, cependant dans notre cas nous l’avons fixé à 0.3 car à partir de cette valeur, l’AG présente des solutions de meilleure qualité.

Paramétrage des AGs

Pour les classifieurs [3, 8]:

- Paramétrage des AGs (taille de la population initiale=50, nombre de généra- tion=10, probabilité de croisement=0.6, probabilité de mutation=0.3)

- Paramétrage fitness (poids accuracy=1, poids taux de fausses alertes=0.5, poids temps de prédiction=0.1)

Classifieurs [9, 20]:

- Paramétrage des AGs (taille de la population initiale=100, nombre de généra- tion=50, probabilité de croisement=0.6, probabilité de mutation=0.3)

- Paramétrage fitness (poids accuracy=1, poids taux de fausses alertes=0.2, poids temps de prédiction=0.1)

N.B: notons que l’utilisation des AGs pour un ensemble à taille réduite de clas­sifieurs ne s’impose pas, nous l’avons effectué uniquement dans le but de confirmer nos observations et interprétations élaborées précedement.

Résultats relatifs à la méthode Get User Info

illustration not visible in this excerpt

Table 4.20 : Résultats d’optimisation XDos relatifs à la méthode GetUserInfo (de 3 à 5 classifieurs )

illustration not visible in this excerpt

Table 4.21 : Résultats optimisation XDos relatifs à la méthode GetUserInfo (plus de 5 classifieurs )

Résultats relatifs à la méthode Subscribe

illustration not visible in this excerpt

Table 4.22 : Résultats optimisation XDos relatifs à la méthode Subscribe (plus de 5 classifieurs)

Observations et interprétations

Rappelons que les tests ci-dessus ont pour objectif principal l’évaluation de l’apport des algorithmes génétiques dans la fusion de classifieurs, plus précisément ex­ploiter cette méthode de sélection pour pallier les insuffisances de la fusion non paramétrique qui peuvent mener dans certaines situations à une chute consid­érable dans la qualité de prédiction bien que l’ensemble de départ soit constitué de classifieurs forts.

A partir de ces tests, nous avons tiré les constatations suivantes :

- L’application des AGs sur les ensembles de 3 à 5 classifieurs, rejoint les observations que nous avons dégagé lors des tests précédents et démontre que dans ce cas de figure les opérateurs fixes plus particulièrement min et max présentent de bons résultats, néanmoins afin de réduire le temps de prédiction tout en préservant le meilleur taux de précision possible, l’AG privilégie les modèles à deux classifieurs (soit deux classifieurs forts et rapide tels que les ADs ou alors un AD fort et un NB Gaussian moins bon mais rapide, par exemples: dans Config_XDos1,Config_XDos3 et Config_XDos4).^[13]
- Nous observons que dans certains cas de figure où l’ensemble de départ com­porte des classifieurs d’assez mauvaises performances (par exemple: Con- fig_XDos2) une dégradation de la qualité de prédiction quelques soit l’opérateur choisis. Après l’utilisation des AG, ces performances se sont nettement améliorées, cependant dans certain tests l’opérateur choisis était le vote ma­joritaire alors que l’ensemble était constitué que de deux classifieurs ce qui rend le résultat de la prédiction totalement arbitraire, ceci est à la charge du data-scientist responsable de détecter ces cas de figures et d’y remédier, néanmoins lorsque l’ensemble de départ est de grande taille l’AG arrive à in­scrire de meilleures performances moyennant le même nombre de classifieurs (2 classifieurs) avec un opérateur plus robuste tels que la somme.

4.3.4.4 Synthèse

Cette étude a eu pour objectif principal l’évaluation de l’apport de la combinaison de plusieurs classifieurs dans la détection des attaques XDos toutes catégories confondus (oversize payload, recursive payload, xml bomb, ...etc), pour cela nous avons généré deux datasets différents chacun relatif à une méthode de deux web services différents afin de diversifier nos études de cas.

De manière générale, nous avons constaté que souvent dans le cas d’ensembles de classifieurs comportant un nombre réduit de classifieurs (de 3 à 5 classifieurs) les opérateurs fixes sont plus performants que le vote, cependant en augmentant graduellement le nombre de classifieurs, nous avons observé une meilleure préci­sion et stabilité dans les prédictions de la médiane et la moyenne (cela implique la somme, étant donné que la moyenne en ai déduite), de même pour le vote majori­taire il présente de bonnes performances lorsque le nombre de classifieurs augmente cependant il est plus sujet au situations de conflits.

Notons que les performances des opérateurs de manière générale demeurent étroitement liées au nombre et aux performances des classifieurs à combiner ainsi qu’à la relation entre les classifieurs (il est impératif qu’il y ait une diversité dans les prédictions des classifieurs pour que l’apport de la combinaison de classifieurs soit palpable).

Enfin en appliquant les AGs sur les ensembles de tests précédents, dans la glob­alité des cas, l’AG parvient à faire émerger un sous ensemble de classifieurs présen­tant de meilleures performances que l’ensemble de départ. La figures ci-dessous, résument les observations auxquelles nous avons abouti :

illustration not visible in this excerpt

Figure 4.3.7 : Synthèse étude XDos

Nous constatons que dans la majorité des situations l’AG a optimisé le temps de prédiction après un choix minutieux des classifieurs et de l’opérateur de fusion, étant donné qu’en termes de précision de classification et de rappel les ensembles de départ présentaient de très bon résultats (dans ce cas de figure).

4.3.5 Résultats de la classification des attaques Injections

A présent nous entamons la phase de tests portant sur la classification des at­taques d’injections, afin de construire le modèle de prédiction le plus adéquat, nous procèderons comme suit :

illustration not visible in this excerpt

Table 4.23 : Plan de Test Classification Injections

4.3.5.1 Construction des datasets

Nous avons veillé à ce que la base d’apprentissage soit la plus représentative et riche possible en termes d’attaques d’injections (présence de la majorité des catégories d’attaques injections : (OS Commanding, LDAP Fuzzer, SQL Injections, Path traversal, Injection XML, Malformed XML, XPATH injection, .. .etc).

- Constitution du dataset relatif à la méthode GetUserInfo:

illustration not visible in this excerpt

Table 4.24 : Constitution du dataset relative à GetUserInfo • Constitution du dataset relatif à la méthode Subscribe:

illustration not visible in this excerpt

Table 4.25 : Constitution du dataset relative à Subscribe

- Paramétrage de la vectorisation TF-IDF utilisé :

Table 4.26 : Vectorisation TFIDF

Notons que nous avons fixé le nombre de ngram à (2,2), étant donné que ce sont les bi-grams qui sont le plus souvent utilisés dans la vectorisation des attaques d’injections.

4.3.5.2 Apport de la fusion de classifieurs

Avant d’entamer l’interprétation des résultats obtenus, nous avons jugé nécessaire d’évaluer le comportement de chaque classifieur, dans le but de mieux expliquer les prédictions obtenues pour chaque modèle de combinaison par-là suite. De cette étude mono-classifieur, nous observons qu’aucun type de classifieurs ne se démarquent des autres par des prédictions à 100 % exactes, les performances des KNN sont de moyenne qualité avec un temps de prédiction extrêmement élevé, les classifieurs ADs quant à eux présentent d’assez bons résultats, néanmoins leurs taux de fausses alertes est plus élevée comparé aux autres classifieurs, SVM à base de noyau linéaire présente un bon compromis rappel/précision comparé aux autres noyaux. Notons que NB Gaussian inscrit un meilleur taux de précision comparé à NB Multinomial, cependant la multinomial inscrit moins de fausses alertes.

À partir de ces observations, nous avons constitué des sous-ensembles de classi- fieurs en se basant sur les performances des classifieurs à combiner ainsi que sur leur nombre, c’est ainsi que nous avons fixé les ensembles suivants pour les tests :

illustration not visible in this excerpt

Table 4.27 : Ensembles de tests Injections Partie 1

illustration not visible in this excerpt

Table 4.28 : Ensembles de tests Injections Partie 3

Résultats relatifs à la méthode GetUserInfo

Les tableaux ci-dessous englobent les résultats de prédictions relatifs à la méthode GetUserInfo, étant donné que nous avons obtenus des résultats similaires pour les deux méthodes, nous n’avons pas jugé nécessaire de représenter les résultats de Subscribe.

illustration not visible in this excerpt

Table 4.29 : Résultats relatifs à la méthode GetUserlnfo Partie 1

illustration not visible in this excerpt

Table 4.30 : Résultats relatifs à la méthode GetUserlnfo Partie 2

Observations et interprétations

Après analyse des résultats de prédictions relatifs aux deux datasets construits pour chaque web service, nous avons relevé les observations suivantes :

- Notons que le vote majoritaire présente un meilleur taux de fausses alertes dans la majorité des cas comparé aux opérateurs fixes, cependant ses ré­sultats en termes de précision ont été liés à la présence ou l’absence des classifieurs forts dans l’ensemble de départ.
- Dans le cas de figure où le nombre de classifieurs dépassent une dizaine de classifieurs, les opérateurs médiane, somme et mean sont plus efficaces et plus stables dans leurs prédictions comparées aux autres opérateurs de fusion (exemples: Config_Injection6, Config_Injection7 et Config_Injection8).
- Nous constatons que les opérateurs min, max et produit affichent des ré­sultats de moins bonne qualité plus particulièrement lorsque le nombre de classifieurs augmente (exemples: Config_Injection8).
- Suite à l’analyse menée précédemment, nous avons observé que 80% des modèles choisis ont affiché une précision maximale avoisinant les 92%, avec un taux de fausses alertes autour de 5% de ce fait l’apport de la combinaison de classifieur est plus flagrante dans ce cas d’étude comparé à l’étude menée dans le cadre des attaques XDos.

Cependant, il ne faut pas négliger le fait que l’espace caractéristique dans le cadre des injections peut facilement atteindre les 1000 attributs, c’est pourquoi il serait judicieux d’effectuer une réduction dimensionnelle sur l’espace caractéristique re­latif aux injections tout en observant l’effet qu’aura cette réduction sur les com­portements des modèles de prédictions précédents.

4.3.5.3 Apport de la méthode de réduction dimensionnelle

Afin de choisir la méthode de réduction dimensionnelle la plus appropriées, nous avons fait appel à deux méthodes appartenant à deux catégories différentes d’approches de réduction: la sélection d’attributs (nous avons sélectionné les mesures de cor­rélation KHI2 et MI), l’extraction d’attributs (nous avons sélectionné LSA, ACP).

Afin de mener à bien ces tests, nous avons sélectionné des modèles à partir de l’étude précédentes (un échantillon de modèles qui présentaient les meilleures performances) sur lesquels nous avons effectué un réapprentissage sur les don­nées réduites (sur lesquels nous avons appliqué la réduction dimensionnelle), nous avons observé que pour un nombre d’attributs de 500, la majorité des méthodes atteignent leurs meilleures performances après application des modèles sur les don­nées de tests, c’est pourquoi pour cette étude nous avons fixé le nombre d’attributs à 500.

Le Tableau ci-dessous, regroupe les performances des modèles retenus après réduction dimensionnelle:

illustration not visible in this excerpt

Table 4.31 : Résultats réduction dimensionnelle à la méthode de 5 classifieurs)

Observations et interprétations

Nous observons que la méthode de sélection KHI2 se démarque des autres ap­proches de réduction dimensionnelle tout en variant le modèle de combinaison, KHI2 améliore donc la précision et elle réduit le taux de fausses alertes tout en affichant un temps de traitement légèrement plus court comparé aux autres ap­proches de réduction. Ces observations nous ont conduit à préconiser la mesure KHI2 comme méthode de réduction pour les attaques de type injection.

4.3.5.4 Apport de la méthode de sélection de classifieurs sans réduction dimensionnelle

Le tableau ci-dessous, comporte le paramétrage des AGs utilisé lors des tests, notons que pour tous les ensembles de classifieurs, nous avons opté pour une taille de population de 50 individus avec une dizaine de générations, étant donné que la réduction dimensionnelle n’a pas encore eu lieu cela impactera énormément le temps de traitement des algorithmes génétiques, c’est pourquoi nous n’avons pas fixé la taille de la population au-delà de 50 individus ainsi que le nombre de génération au-delà de 10 générations, néanmoins cela a été suffisant aux AGs pour présenter des modèles de prédiction de meilleure qualité que les ensembles de départ.

Pour ce qui est de la probabilité de croisement et de mutation, nous avons gardés les mêmes valeurs utilisées dans le cadre de l’étude XDos.

Cependant pour ce qui est de la fonction fitness, nous avons cette fois-ci privilégié le taux de fausses alertes ainsi que le temps de prédiction en diminuant le poids de l’accuracy étant donné que la majorité des modèles inscrivent un taux considérable de fausses alertes comparé au résultats obtenu dans l’étude XDos.

Paramétrage des AGs

Paramétrage des AGs(taille de la population initiale=50, nombre de génération=10, probabilité de croisement=0.6, probabilité de mutation=0.3)

Paramétrage fitness(poids accuracy=0.8, poids taux de fausses alertes=0.5, poids temps de prédiction=0.1)

Le Tableau ci-dessous, regroupe les performances des modèles après application des AGs sans réduction dimensionnelle:

illustration not visible in this excerpt

Table 4.32 : Résultats d’optimisation relatifs à la méthode GetUserInfo (plus de 5 classifieurs)

Observations et interprétations notons que les algorithmes génétiques ont parvenu dans la majorité des cas à extraire un sous ensemble de classifieurs (allant de 5 à 7 classifieurs cela dépend de l’ensemble de départ) combinés le plus souvent via un opérateur stable tels que le mean, médiane ou la somme, et cela a permis le plus souvent de réduire considérablement le taux de fausses alertes inscrit chez la majorité des classifieurs, d’augmenter la précision de certains classifieurs et de réduire le temps de prédiction du modèle initial.

4.3.5.5 Apport de la méthode de sélection de classifieurs avec réduction dimensionnelle

À présent, il est question de reprendre les modèles sur lesquels nous avons appliqué précédemment les AGs mais cette fois-ci en prenant en considération la réduction dimensionnelle via la mesure KHI2 en fixant le nombre d’attributs à 500.

Le Tableau ci-dessous, regroupe les performances des modèles après application des AGs avec réduction dimensionnelle:

illustration not visible in this excerpt

Table 4.33 : Résultats d’optimisation et réduction relatifs à la méthode GetUserInfo

Observations et interprétations

Notons que les performances des modèles retournés par les AGs avec réduction dimensionnelle sont pratiquement équivalents à ceux retournés (par les AGs) sans réduction dimensionnelle en termes de précision/rappel, fausses alertes à quelques différences prêtes, cependant nous distinguons une nette amélioration en termes de temps de prédiction.

4.3.6 Synthèse

Cette étude porte tout comme la précédente sur l’apport de la combinaison de classifieurs dans la détection des attaques d’injections, notons que dans ce cas de figure contrairement au attaques XDos, nous sommes confrontés à un espace car­actéristique considérable (plus de 1000 attributs), ce qui va forcément impacter les performances des classifieurs, c’est pourquoi nous avons jugé nécessaire d’évaluer l’apport d’une approche de réduction dimensionnelle en plus de l’utilisation des AGs.

Les graphiques ci-dessus permettent de synthétiser les résultats obtenus précédem­ment:

illustration not visible in this excerpt

Figure 4.3.8 : impact AG et réduction dimensionnelle sur le temps de prédiction

illustration not visible in this excerpt

Figure 4.3.9 : impact AG et réduction dimensionnelle sur taux de fausses alertes

illustration not visible in this excerpt

Figure 4.3.10 : impact AG et réduction dimensionnelle sur l’accuracy

De cette étude, nous retenons donc les principales conclusions suivantes:

- La combinaison de classifieurs a globalement permis de combler les insuffisances des mono-classfieurs en termes de taux de fausses alertes et d’accuracy.
- La réduction dimensionnelle élaborée a permis globalement d’améliorer les performances des modèles de classification en termes de précision, fausses alertes et temps de prédiction.
- L’apport de la réduction dimensionnelle au niveau des AGs c’est principalement focalisé sur le temps de prédiction.

4.4 Synthèse générale

Cette partie de test regroupe les principales expérimentations que nous avons menées afin de répondre aux mieux à la problématique posée qui s’articule autour de l’évaluation de l’apport de la combinaison de classifieurs plus particulièrement les méthodes de fusion de classifieurs non paramétriques dans la détection des attaques contre SOAP.

Étant donné que les attaques XDos peuvent avoir comme cible le système de dé­tection, nous avons élaboré en premier lieu un modèle de régression qui se base sur les mesures de consommation de ressources afin de détecter rapidement les message XDos flagrants, de plus ce mécanisme permet d’aiguiller les messages interceptés de manière efficace en optimisant leurs temps de traitement (un message est soit redirigé vers le module de détection XDos ou celui d’injections). Afin de construire ce modèle de régression nous avons effectué une panoplie de tests qui ont conduit vers l’algorithme de régression SVR (basé sur un noyau polynomial) étant donnée sa capacité de discernement des fonctions de prédiction les plus complexes et son temps de prédiction relativement réduit.

Pour ce qui est de l’apport de la combinaison de classifieurs, les résultats ont été globalement concluants, la fusion mène de manière générale vers une améliorations nettes des mesures de performances (accuracy, fausse alertes, précision, rappel).

Cependant dans certaines situations elle peut engendrer une chute des perfor­mances, de plus nous avons constaté qu’il est extrêmement difficile de généraliser à partir d’un simple cas d’étude l’ensemble ou l’opérateur de fusion le plus perfor­mant, étant donné que le comportement de ces méthodes de combinaison demeure étroitement liées à la constitution du dataset et son espace caractéristique, la re­lation entre les classifieurs à combiner et le nombre de classifieurs.

C’est pourquoi nous avons fait appel aux AGs en tant que méthode de sélec­tion de classifieurs afin de faire émerger de manière dynamique le sous ensemble de classifieurs le plus optimal en termes de précision, fausses alertes et temps de prédiction à partir d’un ensemble de départ, nous avons observé une nette amélio­ration dans les performances des modèles après application des AGs que ce soit dans le cadre des attaques XDos ou des injections.

Synthèse Générale et Perspectives

Les travaux menés dans ce mémoire s’inscrivent dans le cadre de la sécurisation des web services SOAP à travers la conception d’un système de détection des attaques inhérentes à XML, en ayant recours à la classification supervisée plus particulièrement aux approches d’ensemble learning (méthodes de combinaison de classifieurs).

L’objectif principal de notre travail consiste à évaluer l’apport de la combinaison de classifieurs (plus précisément la fusion de classifieurs non paramétrique) dans l’efficacité de détection des attaques contre SOAP moyennant une approche adap­tative pour la sélection du sous ensemble de classifieurs ainsi que de l’opérateur de fusion le plus adéquat. Cependant il est impératif de veiller à la robustesse et la réactivité du système conçu en optimisant son temps de traitement et en veillant à ce que le attaques n’altèrent pas son fonctionnement.

Pour cela nous avons effectué en premier lieu une étude bibliographique por­tant sur les principales approches de combinaison de classifieurs, à partir de cette étude, nous sommes parvenu à recenser les principales caractéristiques de chacune de ces méthodes ainsi que leurs cadre d’application. En deuxième lieu nous avons jugé nécessaire d’élaborer une étude comparative entre les différents travaux ex­istants, qui s’inscrivent dans le cadre de la sécurisation de SOAP moyennant les approches de machine learning, cela nous a permis entres autres de tirer les car­actéristiques de chaque type d’attaque ce qui a largement facilité la construction des espaces caractéristiques des attaques par la suite, de déterminer les mesures de performances.

Par la suite nous avons entamé la conception du système de détection, en com­mençant par recenser les principaux modules le constituant suivi du choix de l’architecture globale du système, nous avons opté pour une architecture hybride (parallèle/série) qui dispose d’un mécanisme de sécurisation du système basé sur un modèle de régression permettant d’acheminer les messages vers le module de classification le plus adéquat (Injection/Xdos).

Pour ce qui est de la classification Xdos/Injection nous avons opté pour la fu­sion non paramétrique faisant intervenir divers experts implémentant différents algorithmes de classification étant donné la diversité des attaques SOAP, de plus afin d’assurer la réactivité du système (temps de réponse le plus réduit possible) nous avons sélectionné un ensemble d’opérateurs de fusion faciles à implémenter mais qui offrent tout de même des performances équivalentes au approches les plus sophistiqués. Étant donné que les performances du modèle de combinaison de classifieurs demeurent étroitement liées à la constitution de l’ensemble de clas- sifieurs et l’opérateur de fusion, nous avons fait appel à une approche de sélection de classifieurs plus précisément aux algorithmes génétiques multi-objectifs afin de faire émerger de manière dynamique le modèle de classification le plus performant en se basant sur la précision, le taux de fausses alertes et le temps de réponse.

Enfin, nous avons élaboré une panoplie de tests, portant en premier lieu sur le choix du modèle de régression le plus approprié tout en fixant les seuils min et max de filtrage des messages soap. Par la suite nous avons effectuer une étude expérimentale visant à évaluer l’apport de la combinaison de classifieurs et cerner le comportement des opérateurs de fusion que ce soit dans la classification des attaques Xdos ou d’injections une fois les résultats obtenus interprétés, nous nous sommes focalisé sur l’évaluation de l’apport des AGs dans l’optimisation des mod­èles.

Notons que les différentes contributions présentés dans ce mémoire peuvent être résumés comme suit :

- Mise en place d’un système de détection de plusieurs variétés d’ attaques contre SOAP (xml bomb, recursive payload, oversieze payload, sql injection, xxe, xml injection, os commanding, ...etc).
- Mise en place d’un système de détection immunisé contre les attaques Xdos aberrantes et optimisation du temps de traitement des message à travers leurs aiguillage vers le bon module de détection (XDos/Injection) en se basant sur les mesures de consommation de ressources.
- Renforcer le niveau de confiance dans la prise de décision du système à travers la combinaison d’avis de plusieurs experts (exploiter l’apport des méthodes d’ensemble learning).
- Optimiser l’espace de décision du système de classification en termes de choix des classifieurs à combiner et l’opérateur de fusion ce qui nous a permis d’aboutir à des modèles de classification ayant un taux de précision frôlant les 100 % avec un temps de prédiction relativement réduit.
- Mise en place d’une solution de détection fortement paramétrable (choix des classifieurs et de leurs paramètres, choix de l’opérateur de fusion, paramétrage des AGs, ...etc).

Ce travail donne lieu à plusieurs perspectives qu’il est possible d’explorer par la suite tels que l’implémentation du système dans un contexte réel, l’évaluation de l’apport d’autres approches de combinaison et confirmation des résultats obtenus en élaborant une autre approche de sélection tels que le recuit simulé.

Annexes

Annexe

1 Introduction à la classification supervisée

1.1 Processus de classification supervisée

1.1.1 Prétraitement

Le prétraitement des données inclut le nettoyage, la normalisation, la transforma­tion, l’extraction et la sélection des caractéristiques. Le produit du prétraitement des données est l’ensemble d’apprentissage global [Raffaëlli 15].

Il inclut donc :

1.1.2 Le Choix des variables prédictives

Cette phase englobe le choix des attributs qui constitue une tâche importante dans le prétraitement, sachant que la présence d’attributs sans influence, ou redondants impacte directement la qualité de classification, ainsi que le cout d’apprentissage (trop grand), c’est pourquoi souvent il serait utile d’entreprendre une phase de sélection des attributs.

1.1.3 La Vectorisation

La vectorisation est une transformation qui consiste à tirer à partir d’une donnée brute (texte, image, ...etc.) le vecteur caractéristique correspondant, selon les attributs sélectionnés dans la phase précédente.

1.1.4 La réduction dimensionnelle

II est souvent nécessaire de réduire le nombre de variables prédictives, étant donné que :^[14]

- La taille N d’un échantillon croît à cause du nombre élevé de variables pré­dictives ce qui entraine le fléau de la dimension ;
- Le modèle prédictif avec peu de variables prédictives est plus facile à inter­préter et visualiser.

Fléau de la dimension

C’est un phénomène observé lorsque la dimension de l’espace des variables (c’est- à-dire le nombre de variables) grandit si vite que les données qu’il inclut deviennent éparses et éloignées, ce phénomène revient à générer un modèle de prédiction en se basant sur un nombre réduit d’expériences dans un espace de possibilités de dimension élevée.

1.1.5 Construction du modèle

Cette étape désigne la phase d’apprentissage, qui peut être vue comme une phase de conception aboutissant à la mise en œuvre d’une stratégie de classification (un modèle). Le procédé de construction du modèle dépend de l’algorithme de classification utilisée.

1.1.6 validation du modèle

Un modèle performant ne doit pas se contenter de reproduire les valeurs cibles de la base d’apprentissage, mais être capable de bien prédire de nouvelles variables cibles. IL s’agit d’éviter les situations de Surapprentissage [Raffaëlli 15].

La parade à ce problème est souvent de répartir l’ensemble d’apprentissage en parties, une partie pour construire le modèle, une autre pour les tests, il existe plusieurs méthodes de validation de l’ensemble d’apprentissage dont on cite: Hold-out: Cette méthode consiste à de diviser l’échantillon de taille n en deux sous échantillons le premier d’apprentissage et le second de test.

k-fold Cross-validation: Cette méthode consiste à diviser l’échantillon origi­nal en k échantillons, puis on sélectionne un des k échantillons comme ensemble de validation et les (k-1) autres échantillons constitueront l’ensemble d’apprentissage.

Leave one out: Cette méthode est un cas particulier de la deuxième méthode où k=n, c’est-à-dire que l’on apprend sur (n-1) observations puis on valide le modèle sur la énième observation et l’on répète cette opération n fois.

Notons que la méthode hold-out reste la plus répandue [Zouari 04].

1.1.7 Utilisation du modèle

Une fois le modèle validé, le classifieur est opérationnel et capable de généraliser ses prédictions, il est donc prêt pour une utilisation réelle.

2 Évaluation des performances d’un classifieur

La performance d’un classifieurs est mise en œuvre lors de la conception du sys­tème, elle permet de mesurer l’adéquation entre le système et l’application visée.

L’évaluation d’un système peut être théorique ou empirique; l’évaluation théorique permet de caractériser la performance en se basant sur des hypothèses prédéfinies tels que le taux de bruit, la corrélation des données...etc (approche souvent très dif­ficile à réaliser), quant à l’approche empirique, elle consiste à tester la performance en utilisant des données réelles ou artificielles générées par le système [Zouari 04].

Une qualité importante d’un classifieurs est d’être capable de généraliser son comportement en d’autres termes c’est pouvoir fonctionner correctement sur des données qu’il n’a pas apprises. Il est évident que les données utilisées dans la phase d’apprentissage ne sont pas les mêmes données pour lesquelles les tests sont effectués.

En un premier lieu, il est possible d’évaluer les performances d’un classifieur en utilisant la matrice de confusion (propre au classifieurs binaires) où chaque colonne de la matrice représente le nombre d’élements d’une classe estimée, tandis que chaque ligne représente le nombre d’éléments d’une classe réelle. Les données utilisées pour chacun de ces groupes doivent être différentes.

La terminologie utilisée dans cette matrice est définit comme suit :

Supposons que nous disposons d’une classe C, et x élément de la base d’apprentissage. Après classification des éléments x. Calculons :

- VP : le nombre d’éléments x prédit dans la classe C, et apprenant réellement à C.
- FP : le nombre d’éléments x prédit dans la classe C, et n’appartenant pas réellement à C.
- VN: le nombre d’éléments x non prédit dans la classe C, et n’appartenant pas réellement à C.
- FN: le nombre d’éléments x non prédit dans la classe C, et appartenant réelle­ment à C.
- P : nombre d’éléments supposés positifs (appartient à C), VP+FN.
- N : nombre d’éléments supposés négatifs (n’appartient pas à C), VN+FP.

Un des intérêts de la matrice de confusion est qu’elle montre rapidement si le système parvient à classifier correctement.

Matrice de confusion

illustration not visible in this excerpt

Figure .1 : Matrice de confusion

3 Méthodes ensemblistes

3.1 Fusion non paramétrique

Abbildung in dieser Leseprobe nicht enthalten^{[15] [16]}

3.2 Fusion paramétrique

Cette approche englobe des méthodes visant à ne pas considérer les classifieurs de la même manière, et cela en leurs attribuant généralement des poids dans le but de mettre en avant les sorties des classifieurs jugés les plus performants, cette connaissance supplémentaire nécessite souvent une estimation de paramètres effec­tuée lors d’une phase d’apprentissage supplémentaire, il est vivement conseillé de l’effectuer sur une autre base d’apprentissage autre que celle utilisée pour entraîner les classifieurs.

illustration not visible in this excerpt

Figure .1 : Fusion paramétrique

Dans le tableau ci-dessus, nous exposons le principe des méthodes de fusion non paramétriques qui différent selon le type de sortie et l’opérateur de fusion utilisé, enfin nous relevons quelques observations relatives à ces méthodes, pour plus de détails se référer à l’annexe.

illustration not visible in this excerpt

Table 1 : Méthodes de combinaison de classifieurs de type classe

4 Méthodes de Réduction Dimensionnelle

4.0.1 Méthodes Filter:

Mesure Khi2:

La mesure Khi2 est une mesure qui permet d’analyser la dépendance entre l’attribut et la classe. Dans le cas ou l’attribut est indépendant de la classe, son score est égal à 0 dans le cas contraire il est proche de 1, notons qu’un attribut ayant un score Khi2 élevé est considéré comme étant porteur de plus d’information.

Information Gain:

Cette méthode consiste a attribuer un score a chaque attribut, qui permettra de les classer par ordre décroissant, il suffit de déterminer par la suite un seuil au dessus duquel l’attribut est gardé.

4.0.2 Méthodes Wrapper:

Forward Selection:

méthode itérative, qui consiste à ajouter les attributs un à un au modèle, à chaque itération, il est question d’ajouter les attributs qui augmente la précision du mod­èle, jusqu’à ce que cette précision stagne.

Backward Eliminatiton:

Contrairement à la méthode précédente, il est question dans ce cas de considérer en premier lieu la totalité des attributs, puis de manière itérative, éliminer les attributs les moins significatifs un à un (leurs suppression augmente la précision du modèle), ce procédé est répété jusqu’à ce que la précision stagne.

Recursive Feature Elimination:

Cette méthode fait appel à un algorithme d’optimisation glouton, qui cherche le meilleure sous ensemble d’attributs permettant au modèle d’atteindre une meilleure précision.

5 Conception Logicielle

5.1 Identification des principaux scénarios (CU)

5.1.1 Cas d’utilisation Détection d’une attaque XDOS

illustration not visible in this excerpt

5.1.2 Cas d’utilisation Détection d’une attaque Injection

Cas d’utilisation n°2

Objectif : Détecter une attaque Injection

Acteurs: Système

Pré-condition: Arrivée d’un message SOAP, Arrivée d’un message SOAP classé Non attaque XDOS ou Indéfini

Enchaînement Principal:

- Le système déclenche le module de vectorisation N-gram sur le message SOAP reçu
- Le système déclencha la classification spécialisée injection sur le résultat de la vectorisation N-gram
- Si le vecteur caractéristique est classé comme Indéfini
- le système sauvegarde le message SOAP dans sa base
- Sinon (si la classe est de type Non Attaque ou Attaque )
- le système redirigera le message SOAP au firewall Post-condition: Si attaque le système signalera attaque injection au firewall
- Sinon le message SOAP sera redirigé vers le web service concerné .

5.1.3 Cas d’utilisation Classification manuelle des messages SOAP Indéfini

Cas d’utilisation n°3

Objectif: Classer un message SOAP indéfini Acteurs: Administrateur

Pré-condition: l’administrateur est déjà connecté Enchainement Principal:

- L’administrateur affiche le contenu du LOG
- L’administrateur sélectionne un message SOAP de type Indéfini
-Si l’administrateur classe le message SOAP sélectionné dans la classe Attaque XDOS ou Attaque Injection
- le système relance la phase d’apprentissage, en incluant le nouveau messageclassé dans la base
- sinon (si le vecteur caractéristique est classé comme Indéfini)
- le message SOAP sera ignoré

Post-condition:

5.2 Modèle d’analyse

Le modèle d’analyse permet de clarifier les besoins d’une manière plus détaillée, le but de cette phase est d’identifier les principales classes d’analyse et leurs interac­tions.

5.2.1 Identification des classes Identification des entités du système

illustration not visible in this excerpt

Table 2 : Entités du système

Identification des contrôleurs du système

illustration not visible in this excerpt

Table 3 : Contrôleurs du système

Identification des interactions

illustration not visible in this excerpt

Table 4 : Interfaces du système

illustration not visible in this excerpt

illustration not visible in this excerpt

Figure .3 : Package Vectorisation

Notre modèle de classe d’analyse a était résumé en quatre paquets:

- Classification : ce module se charge d’ effectuer le processus complet de la classification, commençant par la vectorisation des message SOAP et terminant par leurs étiquetage(attribuer une classe).

- Configuration : ce module assure le paramétrage du modèle de classification et la mise à jour de la base d’apprentissage

- SupervesionTraficWeb: ce module d’administration assure la supervision du trafic web ainsi il offre une vue claire sur l’analyse du trafic web.

5.3 Modèle de conception

Dans cette section, nous nous intéressons à la manière d’implémenter les fonc­tionnalités du système, nous exposons en premier lieu le diagramme de classe de conception qui est une version plus élaborée du diagramme de classes d’analyse présenté plus haut, ainsi qu’un ensemble de diagrammes comportementaux afin de détailler le fonctionnement des cas d’utilisation les plus importants.

illustration not visible in this excerpt

Figure .4 : Diagramme de classe de conception

5.3.2 Diagrammes de séquences

Le schéma ci-dessous, représente le traitement effectué dans le cas où le message SOAP considéré comme Attaque XDos :

illustration not visible in this excerpt

Figure .5 : Diagramme de séquence du CU traitement XDos

Le schéma ci-dessous, représente le traitement effectué dans le cas où le message SOAP est considéré comme Attaque Injection :

illustration not visible in this excerpt

Figure .7 : Diagramme de séquence du CU Cas Indéfini

Références Bibliographiques

illustration not visible in this excerpt

Références Webographiques

- [Acunetix 17] https://www.acunetix.com/, consulté le [20/04/2017]
- [briandunning 17] https://www.briandunning.com/sample-data/, consulté le [03/04/2017]
- [BURPSUITE 17] https://portswigger.net/burp/, consulté le [05/02/2017]
- [Deap 17] https://deap.readthedocs.io/en/master/, consulté le [26/05/2017]
- [QT 17] https://wiki.python.org/moin/PyQt, consulté le [26/05/2017]
- [guide 17] http://www.guideinformatique.com/dossiers-actualites-informatiques- securite-informatique14/securite-des-services-web-saml-pare-feu-xml-417.html, consulté le [10/01/2017]
- [infoq 17] https://www.infoq.com/fr/articles/rest-soap-when-to-use-each, con­sulté le [20/01/2017]
- [owasp 16] https://www.owasp.org, consulté le [20/12/2016]
- [octo 16] http://blog.octo.com/initiation-a-la-securite-des-web-services/, con­sulté le [25/12/2016]
- [Python 17] https://techterms.com/definition/python, consulté le [26/05/2017]
- [SKlearn 17] http://scikit-learn.org/stable/, consulté le [26/05/2017]
- [SOAPUI 17] https://www.soapui.org/, consulté le [03/02/2017]
- [uddi 16] http://www.uddi.org/pubs/uddi_v3.html, consulté le [10/12/2016]
- [w3c 16] https://www.w3c.org/TR/tr_SOAP, consulté le [15/12/2016]
- [web 17] https://www.1min30.com/dictionnaire-du-web/norme-w3c-definition, consulté le [15/01/2017]
- [wiki 16] https://fr.wikibooks.org/wiki/Patrons_de_conception/Faible_couplage, consulté le [05/01/2016]
- [WSFUZZER 17] https://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project, consulté le [10/02/2017]
- [XMLSAX17] https://docs.python.org/2/library/xml.sax.html, consulté le [26/05/2017]