Vous êtes sur la page 1sur 144

République Tunisienne

Ministère de l’enseignement Supérieur et de la Recherche Scientifique


Université de Carthage

Thèse de doctorat

présentée pour obtenir le grade de docteur de

L’Ecole Supérieure des Communications de Tunis

en

Technologies de l’Information et de la Communication

Par

Randa Jabeur Ben Chikha

Protection contre les appels téléphoniques non


désirés et gestion des risques dans un réseau VoIP

Soutenue le 18/11/2016 devant le jury composé de:


Président
M. Nabil Tabbane Professeur de SUP’COM

Rapporteurs
M. Anas Abou El Kalam Professeur de l’ENSA de Marrakech
M. Rhouma Rhouma Maître de conférences de l’ESEN

Examinateur
Mme. Sihem Guemara Professeur de SUP’COM

Directeur de thèse
M. Adel Bouhoula Professeur de SUP’COM
Co-encadrant .
M. Tarek Abbes Maître-Assistant de l’ENET’COM
Résumé

La Voix sur IP (VoIP) est une technologie innovante. Elle est utilisée pour établir
des appels téléphoniques et d’autres flux multimédia via le protocole IP. Ces dernières
années, la VoIP a suscité beaucoup d’intérêt commercial. En effet, elle offre des services
de télécommunications flexibles tout en réduisant les coûts opérationnels. Cependant et
malgré ces atouts, le réseau VoIP est cible de plusieurs types de menaces qui exploitent
différentes vulnérabilités liées aux protocoles de signalisation et de transport de la voix,
aux équipements intermédiaires (proxy, PBX, Registar) et aux équipements terminaux
(softphone, hardphone). Le SPIT (SPAM over Internet Telephony) est l’une des menaces
majeures dans la VoIP. Ainsi, divers mécanismes de sécurité ont été proposés (système
de détection ou prévention d’intrusion, filtres, pot de miel). Cependant ces mécanismes
restent limités de point de vue sensibilité et spécificité d’une part et leurs impacts sur la
disponibilité et la qualité de service de la VoIP d’autre part. Par ailleurs, la reconnaissance
active des logiciels et des équipements de VoIP est utile pour adapter dynamiquement le
niveau de sécurisation du réseau VoIP en fonction des vulnérabilités existantes et de l’état
actuel du réseau.
L’objectif de cette thèse est de mettre en place un système de gestion de la sécurité
d’un réseau VoIP afin de coordonner les tâches entre les divers équipements de sécurité.
Il permet également d’ajuster dynamiquement le niveau de sécurité assurée, de résumer
l’activité courante de la VoIP et d’organiser les incidents de sécurité selon leurs gravités.
Cette thèse est divisée en deux grandes parties : La première partie traite l’attaque
SPIT (spam over IP Telephony) tout en proposant une méthode de détection basée sur
une approche comportementale. La deuxième partie présente un système de gestion des
risques dans un réseau VoIP. Ce système exploite en particulier la méthode de détection
déjà développée et utilise la métrique RORI (Return On Response Investment) qui assure
la sélection d’une mesure de sécurité optimale réduisant l’impact d’une attaque donnée
sans sacrifier les fonctionnalités du système.

Mots clés : VoIP, SPIT, Approche comportementale de détection, Gestion des risques,
RORI.

i
Protection against unwanted phone
calls and risk management in VoIP
network
Abstract

Voice over IP (VoIP) is an innovative technology. It is used to make telephone calls and
other multimedia streams over the IP protocol. In recent years, VoIP has attracted much
commercial interest. Indeed, it offers flexible telecommunications services while reducing
operational costs. However, despite these advantages, the VoIP network is target to sev-
eral threats that exploit different vulnerabilities related to signaling protocols and voice
transport, to intermediate devices (proxy, PBX, Registar, etc.) and to terminal equip-
ments (softphone, hardphone). SPIT (SPAM over Internet Telephony) is one of the major
threats in VoIP. Thus, various proactive and reactive security mechanisms are needed (in-
trusion detection or prevention system, filters, honey pot). However, these mechanisms
are limited in terms of sensitivity, specificity and impact on the availability and quality of
service of VoIP. Furthermore, active recognition software and VoIP equipments are useful
to dynamically adapt the VoIP network security level based on existing vulnerabilities
and the current state of the network.
The objective of this thesis is to design a VoIP risk management system in order to
coordinate tasks among various security equipments. It also allows to dynamically adjust
the level of security provided to summarize the current activity of VoIP and to organize
security incidents according to their severity.
This thesis is divided into two parts: The first part tackles a severe threat on VoIP
called ”SPIT” (Spam over IP Telephony). We deeply study this threat and we provide a
detection method based on learning machine. The second part presents a risk manage-
ment system in a VoIP network. This system relies particularly on the detection method
already developed and uses RORI (Return On Investment Response) metrics that ensures
the selection of optimal security measure reducing the impact of a given attack without
sacrificing the system functionality.
Keywords: VoIP, SPIT, behavioral based approach, Risk management, RORI.

iii
Remerciements

Je tiens tout d’abord à remercier mon directeur de thèse : Monsieur Adel Bouhoula,
Professeur de l’Ecole Supérieur de Communication (Sup’Com) pour son encouragement
et sa confiance.
Je remercie aussi Monsieur Tarek Abbes, Maître assistant de l’Ecole Nationale d’Elec-
tronique et des Télécommunications de SFAX (ENET’Com) pour m’avoir encadrée, conseillée
ainsi que pour les corrections qu’il a portées à ma thèse.
Je souhaite adresser mes remerciements à Monsieur Nabil Tabbane le président de jury
de ma thèse de doctorat. Je remercie cordialement Monsieur Anas Abou El Kalam et
Monsieur Rhouma Rhouma d’avoir accepté d’être rapporteurs de cette thèse. Je sou-
haite adresser également mes remerciements à Madame Sihem Guemara de m’avoir fait
l’honneur d’examiner mes travaux de thèse.
Un sincère remerciement à mon frère Wassim qui m’a consacré son temps pour finaliser
cette thèse.
Je dédie cette thèse à mon mari Haithem, mes chers enfants Mohamed Khaled et Taha
Yassine, mes parents Ahmed et Monia, mes beaux-parents Mohamed et Fatma, mes frères
Majdi et Wissem et Wassim, mes sœurs Rania et Ines.

iv
Table des matières

Résumé i

Abstract iii

Remerciements iv

Table des matières v

Table des figures xi

Liste des tableaux xiii

Liste des algorithmes xiii

Introduction 1

Partie I: VoIP et Messages Indésirables 5

1 Architecture de la VoIP 6
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Généralités sur la VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Protocoles de la VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Protocole de signalisation SIP . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 Architecture logicielle du protocole SIP . . . . . . . . . . . . . . . . 8
1.4.2 Architecture matérielle du protocole SIP . . . . . . . . . . . . . . . 9
1.4.2.1 Terminal utilisateur . . . . . . . . . . . . . . . . . . . . . 10
1.4.2.2 Serveur d’enregistrement . . . . . . . . . . . . . . . . . . . 10
1.4.2.3 Serveur de localisation . . . . . . . . . . . . . . . . . . . 11
1.4.2.4 Serveur de redirection . . . . . . . . . . . . . . . . . . . . 11
1.4.2.5 Serveur proxy . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2.6 Passerelle (Gateway) . . . . . . . . . . . . . . . . . . . . . 11

v
TABLE DES MATIÈRES

1.4.3 Messages SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11


1.4.3.1 Requêtes SIP . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.3.2 Réponses SIP . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Fonctionnement du protocole SIP . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.1 Enregistrement d’un terminal . . . . . . . . . . . . . . . . . . . . . 14
1.5.2 Initialisation d’une communication directe . . . . . . . . . . . . . . 15
1.5.3 Terminaison d’une communication . . . . . . . . . . . . . . . . . . . 16
1.6 Attaques dans la VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6.1 Attaques sur le protocole SIP . . . . . . . . . . . . . . . . . . . . . 16
1.6.2 Déni de Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6.3 Ecoute clandestine (Eavesdropping) . . . . . . . . . . . . . . . . . . 18
1.6.4 Détournement du trafic (Call hijacking) . . . . . . . . . . . . . . . 18
1.6.5 Reniflage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.6 Fraude de facturation . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.7 SPIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7 Attaques sur le protocole RTP . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7.1 Attaque de charge utile . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7.2 Attaque de falsification . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.8 Attaques sur les autres protocoles . . . . . . . . . . . . . . . . . . . . . . . 20
1.8.1 ARP (Address Resolution Protocol) Poisonning . . . . . . . . . . . 20
1.8.2 Usurpation IP (IP Spoofing) . . . . . . . . . . . . . . . . . . . . . . 20
1.8.3 Inondation du TCP SYN . . . . . . . . . . . . . . . . . . . . . . . . 20
1.8.4 Réponse TCP ou UDP . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.8.5 Insertion du serveur TFTP (Trivial File Transfer Protocol) . . . . . 21
1.9 Mécanismes de sécurité dans la VoIP . . . . . . . . . . . . . . . . . . . . . 21
1.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 Aperçu sur l’Attaque SPIT 25


2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Introduction au SPIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Définition intuitif de SPIT . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2 Différentes formes de SPIT . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.3 Comparaison entre SPIT et SPAM . . . . . . . . . . . . . . . . . . 26
2.3 Analyse de SPIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Collecte de l’information . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Etablissement d’une session SPIT . . . . . . . . . . . . . . . . . . . 28
2.3.3 Envoi des messages médias SPIT . . . . . . . . . . . . . . . . . . . 28
2.3.4 Effacement des traces . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.5 Analyse des incidents des SPITs . . . . . . . . . . . . . . . . . . . . 29

vi
TABLE DES MATIÈRES

2.4 Menaces des SPITs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


2.4.1 Menaces dues aux vulnérabilités de SIP . . . . . . . . . . . . . . . . 30
2.4.1.1 Envoi des demandes ambiguës aux proxys . . . . . . . . . 30
2.4.1.2 Écoute des adresses de multicast . . . . . . . . . . . . . . 30
2.4.1.3 Population d’adresses "actives" . . . . . . . . . . . . . . . 31
2.4.1.4 Contacte d’un serveur de redirection avec des demandes
ambiguës . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.1.5 Comptes SIP jetables . . . . . . . . . . . . . . . . . . . . 31
2.4.1.6 Abus des serveurs sans mémoire (stateless) . . . . . . . . 31
2.4.1.7 Option anonyme de SIP et Back-to-Back User Agents . . 31
2.4.1.8 Envoi des messages aux adresses de multicast . . . . . . . 32
2.4.2 Menaces dues à d’autres risques de sécurité . . . . . . . . . . . . . . 32
2.4.2.1 Surveillance du trafic auprès de serveurs SIP . . . . . . . . 32
2.4.2.2 Balayage des ports connus de SIP . . . . . . . . . . . . . 32
2.4.2.3 Exploitation des procédures de résolutions des domaines
d’adresse particuliers . . . . . . . . . . . . . . . . . . . . . 32
2.5 Techniques de détection des SPIT . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.0.4 Listes de filtrage . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.0.5 Système de réputation . . . . . . . . . . . . . . . . . . . . 34
2.5.0.6 Tests de Turing . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5.0.7 Paiements au risque . . . . . . . . . . . . . . . . . . . . . 35
2.5.0.8 Filtrage du contenu . . . . . . . . . . . . . . . . . . . . . 35
2.5.0.9 Cercles de confiance . . . . . . . . . . . . . . . . . . . . . 36
2.5.0.10 Action légale . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.0.11 Détection d’anomalies basées sur le comportement . . . . 36
2.6 Plateformes anti-SPITs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.1 Prévention des SPIT avec des autorités de vérification anonymes . . 37
2.6.2 Mitigation des SPIT à travers une entité anti-SPIT de la couche
réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.3 Détection de SPIT basée sur des techniques de réputation et de la
facturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.4 DAPES (Domain-based Authentication and Policy-Enforced for SIP) 38
2.6.5 liste grise progressive multi-niveaux PMG (Progressive Multi Grey-
Levelling) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.6 Plateforme biométrique pour la prévention des SPITs . . . . . . . . 39
2.6.7 RFC 4474 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6.8 SIP SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6.9 DSIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.10 Voice spam detector . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.11 VoIP SEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

vii
TABLE DES MATIÈRES

2.6.12 Tests de Turing cachés . . . . . . . . . . . . . . . . . . . . . . . . . 41


2.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 Approche Comportementale pour la Détection de SPIT 43


3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Algorithme de détection de SPIT . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1 Critères d’identification de SPIT . . . . . . . . . . . . . . . . . . . 44
3.2.1.1 Critères du message SIP . . . . . . . . . . . . . . . . . . . 44
3.2.1.2 Critères du UA SIP . . . . . . . . . . . . . . . . . . . . . 45
3.2.2 Description de l’algorithme de détection . . . . . . . . . . . . . . . 45
3.2.3 Résultats et simulations . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3 Approche comportementale . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4 Plateforme de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.1 Collecte des critères d’identification des SPITter sous OPNET . . . 55
3.4.1.1 Architecture proposée . . . . . . . . . . . . . . . . . . . . 55
3.4.1.2 Configuration du réseau déployée . . . . . . . . . . . . . . 56
3.4.2 Classement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5 Métriques d’évaluation des performances d’un classeur des UA . . . . . . . 57
3.6 Résultats de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Partie II : Gestion des Risques dans un Réseau VoIP 68

4 Processus et Modèles de Gestion des Risques 69


4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2 Introduction à la gestion des risques . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1 Définition et éléments de base . . . . . . . . . . . . . . . . . . . . . 70
4.2.1.1 Gestion des risques . . . . . . . . . . . . . . . . . . . . . . 70
4.2.1.2 Actif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.1.3 Menace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.1.4 Vulnérabilité . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.1.5 Attaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.1.6 Risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.2 Principaux méthodes de gestion des risques . . . . . . . . . . . . . . 71
4.2.3 Processus de Gestion des risques . . . . . . . . . . . . . . . . . . . . 73
4.3 Processus de Gestion des risques dans le réseau VoIP . . . . . . . . . . . . 74
4.3.1 Explication des étapes de processus de gestion des risques . . . . . 74
4.3.1.1 Identification des risques . . . . . . . . . . . . . . . . . . . 74
4.3.1.2 Evaluation des risques . . . . . . . . . . . . . . . . . . . . 76

viii
TABLE DES MATIÈRES

4.3.1.3 Traitement des risques . . . . . . . . . . . . . . . . . . . . 77


4.3.2 Différents modèles de gestion des risques dans le réseau VoIP . . . . 80
4.3.2.1 Modèles qualitatifs des risques . . . . . . . . . . . . . . . . 80
4.3.2.2 Modèles quantitatifs des risques . . . . . . . . . . . . . . . 81
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5 Gestion des risques dans un réseau VoIP 84


5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2 Aperçu sur les contremesures . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.1 Classification des contremesures . . . . . . . . . . . . . . . . . . . . 85
5.2.1.1 Contremesures proactives . . . . . . . . . . . . . . . . . . 85
5.2.1.2 Contremesures réactives . . . . . . . . . . . . . . . . . . . 86
5.2.2 Travaux sur la sélection des contremesures . . . . . . . . . . . . . . 87
5.3 RORI (Return On Response Investment) . . . . . . . . . . . . . . . . . . . 88
5.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.3.2 Méthodologie de sélection d’une seule contremesure . . . . . . . . . 89
5.3.3 Méthodologie de sélection de contremesures combinées . . . . . . . 91
5.4 Processus proposé de gestion des Risques . . . . . . . . . . . . . . . . . . 95
5.4.1 Identification des risques . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.2 Evaluation des risques . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.3 Traitement des risques . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.5 Résultats expérimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Conclusion et perspectives 102

Annexes 105

A Méthodologies d’apprentissage 106


A.1 Réseaux Bayésiens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
A.2 Machines à Vecteurs Supports . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.3 Perceptron Multi-Couches . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
A.4 Arbres de Décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.5 Bagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.6 AdaBoost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B Environnement et modèle hiérarchique 112


B.1 OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
B.2 Classement sous Weka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.3 Extrait de trace réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

ix
TABLE DES MATIÈRES

Bibliographie 118

x
Table des figures

1.2.1 Topologie générale de la VoIP. . . . . . . . . . . . . . . . . . . . . . . . . 7


1.4.1 Architecture logicielle de protocole SIP. . . . . . . . . . . . . . . . . . . . 9
1.4.2 Architecture matérielle du protocole SIP. . . . . . . . . . . . . . . . . . . 10
1.4.3 UAC et UAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.4 Format générique d’un message SIP. . . . . . . . . . . . . . . . . . . . . . 12
1.4.5 Format d’une requête SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.6 Format des réponses SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.1 Enregistrement d’un terminal. . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.2 Initiation d’une communication directe. . . . . . . . . . . . . . . . . . . . 15
1.5.3 Terminaison d’une communication. . . . . . . . . . . . . . . . . . . . . . . 16
1.6.1 Attaque DoS via un message SIP CANCEL. . . . . . . . . . . . . . . . . 17

3.2.1 Nombre d’appels initiés par un utilisateur normal et un SPITter . . . . . 48


3.2.2 La détection du SPIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1 Collecte des traces réseau de la signalisation et de l’activité vocale pour
tout UA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.2 Fenêtre glissante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.3 Extraction des critères d’identification des attaquants SPITter. . . . . . . 53
3.3.4 Classification supervisée. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.1 Topologie utilisée dans la simulation. . . . . . . . . . . . . . . . . . . . . 55
3.5.1 Interprétation de la courbe ROC. . . . . . . . . . . . . . . . . . . . . . . 58
3.6.1 Courbes ROC des méthodes BayesNet et NaiveBayes. . . . . . . . . . . . 61
3.6.2 Courbes de détection et de fausses alarmes pour les méthodes BayesNet
et NaiveBayes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.6.3 Courbes ROC des méthodes SMO RBFKernel et SMO PolyKernel. . . . . 62
3.6.4 Courbes de détection et de fausses alarmes pour les méthodes SMO RBF-
Kernel et SMO PolyKernel. . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.6.5 Courbes ROC des méthodes MultiLayerPerceptron à 1 et 2 couches. . . . 63
3.6.6 Courbes de détection et de fausses alarmes pour les méthodes MultiLayer-
Perceptron à 1 et 2 couches. . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.6.7 Courbes ROC des méthodes J48 et NBTree. . . . . . . . . . . . . . . . . . 64
3.6.8 Courbes de détection et de fausses alarmes pour les méthodes J48 et NBTree. 65

xi
TABLE DES FIGURES

3.6.9 Courbes ROC des méthodes AdaBoost M1, Bagging et J48 . . . . . . . . 65


3.6.10 Courbes de détection et de fausses alarmes pour les méthodes Bagging et
AdaBoostM1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4.1 Processus proposé de gestion des risques . . . . . . . . . . . . . . . . . . . 95

A.1 Exemple d’un Réseau Bayésien. . . . . . . . . . . . . . . . . . . . . . . . 106


A.2 Structure d’un RB naïf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.1 Hyperplan linéaire dans R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
A.2 Exemple de prolongement non-linéaire. . . . . . . . . . . . . . . . . . . . 108
A.1 Perceptron à deux couches. . . . . . . . . . . . . . . . . . . . . . . . . . . 109

B.1 Workflow des simulations sous OPNET. . . . . . . . . . . . . . . . . . . . 112


B.2 Modèle hiérarchique d’OPNET. . . . . . . . . . . . . . . . . . . . . . . . 113
B.1 KNOWLEDGE FLOW du traçage des courbes ROC. . . . . . . . . . . . 114
B.2 KNOWLEDGE FLOW de classement des UA. . . . . . . . . . . . . . . . 115
B.1 Extrait du fichier trace réseau de la signalisation et de l’activité vocale. . 116
B.2 Extrait du fichier des critères d’identification des SPITter. . . . . . . . . . 116
B.3 Extrait de la base de données d’apprentissage. . . . . . . . . . . . . . . . 117

xii
Liste des tableaux

1.1 Entrée dans le serveur de localisation permettant de localiser un utilisateur. 15


1.2 Mécanismes de sécurité dans la VoIP . . . . . . . . . . . . . . . . . . . . 24

2.1 Comparaison SPAM et SPIT. . . . . . . . . . . . . . . . . . . . . . . . . . 27


2.2 Incidents des SPIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Techniques et critères d’identification de la solution proposée par rapport
à quelques solutions existantes. . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1 Critères d’identification des attaquants SPITter. . . . . . . . . . . . . . . 50


3.2 Paramètres de traces réseau de la signalisation et de l’activité vocale. . . . 51
3.3 Paramètres de configuration des stations. . . . . . . . . . . . . . . . . . . 56
3.4 Table de contingence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5 Indicateurs définis à partir de la table de contingence. . . . . . . . . . . . 58
3.6 Fixation des seuils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7 Ordre d’apparition de 44 SPITters au cours de 12 fenêtres glissantes . . . 60
3.8 Temps d’entraînement de chaque méthode de classification. . . . . . . . . 66
3.9 AUC de chaque méthode de classification . . . . . . . . . . . . . . . . . . 66

5.1 Sévérité transformée en coûts probabilistes . . . . . . . . . . . . . . . . . 90


5.2 Probabilité d’occurrence transformé en ARO . . . . . . . . . . . . . . . . 90
5.3 Caractéristiques des contremesures supportant le processus proposée de
gestion des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4 Evaluation des contremesures . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.5 Evaluation du RORI pour les contremesures combinées . . . . . . . . . . 100

xiii
Liste des algorithmes

3.1 Détection_de_SPIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Fonctionnement du système de détection des attaquants SPITter. . . . . . 52

xiv
Introduction

Cadre général et objectifs

La Voix sur IP (VoIP) est une technologie en pleine émergence qui transforme la télé-
phonie. Elle consiste à transmettre la voix sur un réseau numérique et sur Internet tout en
assurant plus de dynamicité, de mobilité et d’innovation en matière d’application. En rai-
son de sa grande flexibilité et avantage économique par rapport au Réseau Téléphonique
Commuté Public (RTCP), son déploiement augmente largement par des entreprises et des
individus. Cependant et malgré ces atouts, le réseau VoIP est cible de plusieurs types de
menaces qui exploitent différentes vulnérabilités liées aux protocoles de signalisation et
de transport de la voix, aux équipements intermédiaires (proxy, PBX, Registar, etc.) et
aux équipements terminaux (softphone, hardphone). Ces problèmes d’insécurité, menant
à l’interruption de la téléphonie suite à une attaque ou à une fraude est parfaitement
inadmissible pour les entreprises.
Plusieurs types d’attaques ont été identifiés sur la VoIP tels que les attaques SPIT
(SPAM over Internet Telephony), les attaques Dos (Deni Of Service), le détournement
du trafic, le vol d’identité.
Dans cette thèse, nous nous focalisons sur les attaques SPIT. Grâce à la quasi-gratuité
de la téléphonie sur Internet, SPIT est un bon marché pour les annonceurs. Il est utilisé
pour diriger les clients vers un service ou essayer de leur vendre des produits. Les attaques
SPIT sont semblables aux attaques SPAM menaçant les boîtes de messages électroniques.
Ainsi, les développeurs ont utilisé des techniques typiques d’anti-SPAM pour la détection
des SPAM d’email. Toutefois ces techniques classiques se sont avérées inefficaces voir
même inapplicables à la détection de SPIT. En effet, le traitement des paquets de voix
doit s’effectuer en temps réel, le contenu d’appel n’est disponible qu’après l’établissement
d’appel et les messages de signalisation d’un utilisateur légitime et d’un attaquant SPITter
sont semblables.
Dans ce cadre, plusieurs recherches se sont focalisées pour étudier le phénomène SPIT.
Les techniques listes blanc/noir n’ont pas pu résoudre ces problèmes. En effet, ces tech-
niques se sont avérées inefficaces lorsque le(s) attaquant(s) apparaissent pour la première
fois ou quand l’attaquant inonde la liste noire avec des identités inconnues ou bien, lorsque
les émetteurs de SPIT peuvent découvrir une identité appartenant à la liste blanche et
l’usurper. Shin et. al. [1] ont proposé un algorithme de liste grise progressive multi-niveaux

1
Introduction

(Progressive Multi Gray level PMG) qui se base seulement sur le nombre des appels.
Cependant, plusieurs études se sont focalisées sur la détection de SPIT et ont montré
l’importance d’utiliser plusieurs mesures de détection. Quittek et. al. [2] ont utilisé des
tests de Turing pour distinguer entre les appelants humains et les attaques SPITs générées
automatiquement à partir des réseaux de bots. Cependant, vue la nécessité des ressources
supplémentaires nécessaires côté appelants [3], l’efficacité de ces tests devient limitée.
Les auteurs dans [4] ont proposé une approche de défense socio-technique. Ils ont utilisé
un filtre adaptatif multi-étapes basé sur la présence (lieu, temps, état d’esprit), la confiance
et la réputation. En particulier, ils ont proposé un contrôle de feed_back en boucle fermée
entre les différentes étapes pour décider si un appel entrant est un SPIT. D’autres auteurs
ont présenté un travail similaire nommé « CallRank » [5]. C’est un nouveau mécanisme
construit autour de la durée d’appel utilisée pour distinguer entre un utilisateur légitime
et un SPITter. Au cours de cette méthode, les auteurs ont proposé l’ajout des crédits
de chaque appel au message INVITE et des notes de réputation données par les proxys.
Ainsi, le déploiement à grande échelle de ces deux approches s’avère critique puisqu’il
nécessite l’implantation d’une infrastructure publique de distribution des clefs.
Malgré l’efficacité des travaux déjà cités dans la détection de SPIT, ils restent limités
en termes de sensibilité et de spécificité. En effet, le nombre de faux positifs et de faux
négatifs reste toujours très important.
Ainsi, pour remédier à ce problème, nous envisageons concevoir un système de détection
des SPIT moyennant une approche comportementale. Dans ce cadre, nous utilisons des
méthodes de classification supervisée pour approuver la performance de notre système de
détection de point de vue sensibilité et spécificité.
Cependant, malgré l’importance visée par notre système de point de vue performance,
il peut provoquer un impact négatif sur le service de téléphonie en termes de disponibilité
et de qualité de service. Ce problème est inacceptable pour les clients de la VoIP. En effet,
ces utilisateurs attendent des performances proches des réseaux téléphoniques ordinaires
tels que le taux de rejet d’appels faible, la réponse en temps réel et la bonne qualité de
la communication. Ainsi, la gestion des risques offre de nouvelles perspectives en ce qui
concerne ce dilemme. En effet, il permet de gérer le compromis entre la sécurité, la qualité
de service et l’impact, qui sont tous cruciales pour la VoIP.
Le système de gestion des risques proposé comprend trois étapes de base : la première
étape permet d’identifier les différentes menaces. Elle est basée essentiellement sur l’ap-
proche comportementale de détection de SPIT. La deuxième étape permet d’estimer le
risque en utilisant un modèle quatitatif appelé Rehostat [6]. Enfin, la troisième étape
permet de réduire le risque à un niveau acceptable en appliquant un ensemble de mesures
de sécurité. Pour cela, nous allons utiliser une approche quantitative basée sur la mé-
trique RORI (Return On Response Investment). Cette métrique assure la sélection d’une
mesure de sécurité optimale qui réduit l’impact d’une attaque donnée sans sacrifier les
fonctionnalités du système.

2
Introduction

Contributions

Les contributions de cette thèse peuvent être ainsi récapitulées comme suit :
1. La conception d’un système de détection de SPIT moyennant une approche compor-
tementale : cette approche comprendra un grand nombre de critères d’identification
des SPIT. Nous montrons en premier lieu qu’il existe des critères plus influents
pour la détection. Ainsi nous exploitons la stratégie de la « fenêtre coulissante »
pour suivre et maintenir correctement les profils des appelants. Nous utilisons des
méthodes de classification supervisée pour montrer l’efficacité du système proposé.
Une étude comparative entre les différentes méthodes de classification donnera lieu
à une méthode plus performante que les autres en termes de taux de détection et
de temps de traitement.
2. La conception d’un système de gestion des risques pour les réseaux VoIP en se
basant sur la métrique RORI afin de garantir un compromis entre la sécurité, le
coût et la performance. Cette métrique assurera la sélection d’une solution optimale
en utilisant soit une contremesure individuelle, soit des contremesures combinées.
Ainsi, la valeur supérieure de RORI correspondra à la solution optimale.

Organisation de la thèse

Le manuscrit de la thèse comprend cinq chapitres organisés en deux parties. Ces deux
parties correspondent respectivement à (1) La VoIP et les messages indésirables (2) La
gestion du risque dans un réseau VoIP.
La Partie I comprend trois chapitres organisés comme suit :
Le chapitre 1 présente l’architecture générale d’un réseau VoIP. Tout d’abord, nous
décrivons les différents éléments constituant cette l’architecture. Ensuite, nous définissons
les différents protocoles utilisés par les services de la VoIP tels que : les protocoles d’éta-
blissement de la connexion (SIP, H323,. . . ), les protocoles de transport des médias (RTP,
RTCP) et d’autres protocoles réseaux classiques au niveau de la couche application tels
que DHCP, DNS et HTTP. Nous nous intéressons principalement aux protocoles SIP et
RTP. Enfin, nous présentons les différentes menaces du protocole SIP.
Le chapitre 2 introduit la menace SPIT tout en présentant les différentes techniques de
détection/prévention utilisées pour protéger le réseau VoIP. Tout d’abord, nous définissons
le SPIT. Ensuite, nous présentons une analyse de SPIT. Nous illustrons par la suite les
différentes menaces de SPIT ainsi que les différentes techniques de détection de SPIT.
Enfin, nous présentons les plateformes anti-SPITs.
Le chapitre 3 présente le système de détection de SPIT moyennant une approche com-
portementale. Ce chapitre comprend deux grandes parties. Dans la première partie, nous
définissons l’algorithme de détection de SPIT afin de préciser les paramètres influents.
Dans la deuxième partie, nous présentons l’approche comportementale proposé qui se

3
Introduction

base sur les paramètres influents d’une part et sur les méthodes de classifications super-
visées d’autre part.
La partie II comprend deux chapitres organisés comme suit :
Le chapitre 4 présente un aperçu sur la gestion des risques. Il repose sur deux sections
principales. Dans la première section, nous présentons une étude détaillée sur la gestion
des risques dans le contexte général. Dans ce cadre, nous définissons les éléments de base
da la gestion des risques ainsi que ses principaux standards. Dans la deuxième section,
nous étudions les travaux de recherche qui visent l’évaluation et la réduction des valeurs
du risque. Ensuite, nous montrons les limites de ces travaux pour répondre au compromis
« sécurité-performance-coût », indispensable pour des services VoIP.
Le chapitre 5 décrit le système de gestion des risques proposé. Tout d’abord, nous
donnons un aperçu sur la classification des contremesures et les différents travaux liés.
Ensuite, nous introduisons la métrique RORI ainsi que la méthodologie de sélection des
contremesures individuelles et combinées. Après, nous proposons le processus de gestion
des risques et enfin, nous discutons les différents résultats expérimentaux.
Nous concluons ce mémoire par un rappel sur les objectifs de cette thèse, un bilan des
différents travaux effectués, ainsi que les avantages, les limites et les perspectives visées.

4
Partie I : VoIP et Messages Indésirables
Chapitre 1

Architecture de la VoIP

1.1 Introduction
La VoIP (Voice over Internet Protocol) est une technologie qui a prouvé une grande
efficacité dans les entreprises en termes de simplicité et de réduction de coûts. Plusieurs
protocoles ont été impliqués dans la livraison de la VoIP. Toutefois, les protocoles de
signalisation ont une valeur particulière dans l’architecture de la VoIP puisqu’ils servent
à mettre en place, router, commuter et facturer les appels. Le protocole SIP (Session
Initiation Protocol) est reconnu comme étant le protocole de signalisation le plus utilisé.
Cependant, ce protocole est cible de plusieurs attaques qui menacent la sécurité de la
VoIP.
Ce chapitre est basé sur trois parties. La première partie est consacrée à une étude
générale de la VoIP. La deuxième partie présente une étude détaillée sur le protocole SIP
ainsi que les menaces qui entourent la VoIP. Finalement, la troisième partie est dédiée
aux différents mécanismes de sécurité dans la VoIP.

1.2 Généralités sur la VoIP


Architecture de la VoIP

Le rôle de la VoIP est le transport de la voix via Internet et des réseaux de données
basés sur le protocole IP. C’est une technique dont l’un de ses enjeux est de réussir la
convergence de la voix et des données. Elle est utilisée pour réaliser plusieurs services tels
que :
— Téléphonie sur IP (ToIP) [7] : Elle offre des fonctions téléphoniques sur IP supplé-
mentaires (fax, multi-appel, consultation des messages vocaux dans la messagerie
électronique, ou inversement, écoute des e-mails).
— Téléphonie mobile sur IP[8] : Par défaut, le téléphone mobile utilise le réseau sans
fil Wi-Fi dans le but d’acheminer les communications. Le réseau mobile de l’abonné
(3G, 4G) est toujours accessible mais avec des coûts supplémentaires.

6
Chapitre 1 Architecture de la VoIP

— Télécopie IP[9] : Elle expédie une télécopie en empruntant la route IP.


— Conférence IP[10] : Elle réalise une conférence (audio, vidéo ou texte) sur IP.
La VoIP est une technologie de communication qui n’a pas de standard unique. Ainsi,
chaque concepteur apporte des normes et des fonctionnalités appropriées à ses besoins.
L’essentiel est d’assurer une excellente qualité de service.
La Figure 1.2.1 décrit une topologie générale d’un réseau VoIP. Elle est constituée
essentiellement par des terminaux, un routeur, une passerelle vers les autres réseaux, et
un commutateur IP PBX.

Téléphone SIP

RTPC
Commutateur

RTPC
Internet Fournisseur
VoIP
Passerelle

Routeur

Réseau

Téléphone USB
Téléphone IP

Figure 1.2.1 – Topologie générale de la VoIP.

— Les Terminaux : Ils représentent les téléphones VoIP et les PC ayant des logiciels
de téléphonies.
— Le routeur : Il permet d’aiguiller les données et d’assurer le routage des paquets
entre les réseaux. Certains routeurs permettent de simuler un portier (Gatekeeper)
grâce à l’ajout de cartes spécialisées supportant les protocoles VoIP.
— La passerelle (Gateway) : Il s’agit d’une interface entre le réseau commuté et le
réseau IP.
— Le commutateur IP PBX : Il représente le commutateur du réseau téléphonique
classique. Il permet de faire le lien entre la passerelle ou le routeur et le réseau de
téléphonie commuté (RTC).

7
Chapitre 1 Architecture de la VoIP

La VoIP caractérise l’encapsulation de la voix (signal audio numérique) au sein du pro-


tocole IP. Cette encapsulation permet d’aiguiller la voix sur tout réseau compatible avec
TCP/IP.

1.3 Protocoles de la VoIP


Plusieurs normes et protocoles sont impliqués dans le réseau VoIP. Les couches accès
réseau, Internet et transport permettent d’offrir des services pour soutenir trois types de
protocoles dans la couche application :
— Protocoles de signalisation : divers protocoles de signalisation tels que SIP [11],
H.323 1 et MGCP 2 (Media Gateway Control Protocol) ;
— Protocoles de média : principalement RTP 3 (Real-Time Transport Protocol) et RTCP
(Real-Time Control Protocol) ;
— Protocoles utilitaires : plusieurs protocoles sont impliqués tels que DNS 4 (Domain
Name Service), DHCP 5 (Dynamic Host Configuration Protocol) et TFTP 6 (Trivial
File Transfer Protocol) ;
La signalisation représente l’outil clé pour créer des applications et des services VoIP in-
novants. Plus particulièrement, le protocole SIP est considéré comme le protocole de-facto
de signalisation de nos jours. Néanmoins, il est vulnérable à plusieurs types d’attaques.
Dans cette thèse, nous étudions quelques types d’attaques et nous proposons des solu-
tions de sécurité capables de protéger un réseau de la VoIP, sans toutefois altérer ses
fonctionnalités.

1.4 Protocole de signalisation SIP


Le protocole SIP dispose de deux architectures : logicielle et matérielle. Dans la suite
de cette section, nous exposons ces deux architectures.

1.4.1 Architecture logicielle du protocole SIP


Le protocole SIP permet d’établir des sessions VoIP de types unicast ou multicast à
travers un MCU (Multipoint Control Unit) [12]. L’architecture en couches du protocole
SIP est représentée dans la Figure 1.4.1.

1. H.323, Recommendation H.323, www.itu.int/rec/T-REC-H.323/


2. https ://tools.ietf.org/html/rfc3435
3. RTP, Real Time Protocol, www.ietf.org/rfc/rfc3550.txt
4. DNS, Domain Name System, https ://www.ietf.org/rfc/rfc1035.txt
5. DHCP, Dynamic Host Configuration Protocol, https ://www.ietf.org/rfc/rfc2131.txt
6. TFTP, Trivial File Transfer Protocol, https ://tools.ietf.org/html/rfc1350

8
Chapitre 1 Architecture de la VoIP

Signalisation Qualité de Service Transport media


SDP
H.261,MPEG
SIP RSVP RTCP

RTP

TCP UDP

IP

Figure 1.4.1 – Architecture logicielle de protocole SIP.

Cette architecture fait apparaître de nombreux protocoles :


— le protocole SDP (Session Description Protocol) [13] : il fournit la description d’une
session (les paramètres entrant en jeu dans une communication SIP).
— le protocole RSVP (Resource reSerVation Protocol) [14] : il permet de garantir une
bonne qualité de service et effectue des réservations de ressources.
— le protocole RTP (Real-time Transport Protocol) [15] : il se charge du transport des
flux en temps réel.
— le protocole RTCP (Real-time Transport Control Protocol) [15] : il donne des infor-
mations dynamiques sur l’état du réseau telle que la qualité de service (QoS) dans
la distribution des médias.
Il convient à dire que tous ces protocoles de nature différente de celle du protocole SIP
ne s’interfèrent pas avec la signalisation.

1.4.2 Architecture matérielle du protocole SIP


L’architecture du protocole SIP s’articule principalement autour de six entités sui-
vantes :
— Terminal utilisateur (UA) ;
— Serveur d’enregistrement (Registrar server) ;
— Serveur de localisation (Location server) ;
— Serveur de redirection (Redirect server) ;
— Serveur proxy (Proxy server) ;
— Passerelle (Gateway).
La Figure 1.4.2 représente l’architecture matérielle du protocole SIP. Dans cette architec-
ture, le proxy et les serveurs de redirection permettent de faciliter le routage des messages
de signalisation. Ils jouent souvent le rôle d’intermédiaires entre les utilisateurs, alors
que les serveurs d’enregistrement et de localisation, ont pour fonction d’enregistrer et de
localiser les utilisateurs.

9
Chapitre 1 Architecture de la VoIP

Serveur
Proxy/Redirection/hEnregistrementh
Basehdehdonnées
dehlocalisation
Passerelle

UA

RéseauhSIP
RTCP
UA

TéléphonehRNIS
ouhtéléphonehanalogique

Figure 1.4.2 – Architecture matérielle du protocole SIP.

Dans la suite, nous expliquons toutes les entités de cette architecture matérielle.

1.4.2.1 Terminal utilisateur

Le terminal est l’élément dont l’utilisateur dispose pour effectuer des appels. Il est
désigné par l’acronyme anglais UA (User Agent). Comme représenté dans la Figure 1.4.3,
un UA est composé de deux sous-entités :
— Une entité cliente, notée UAC (User Agent Client), est en charge d’émettre les
requêtes. C’est l’UAC qui initie un appel.
— Une entité serveur, notée UAS (User Agent Server), est en écoute. Elle reçoit et
traite les requêtes. C’est l’UAS qui répond à un appel.
Par conséquent, l’appelant exploite l’UAC de son terminal, alors que l’appelé exploite
l’UAS. L’échange des requêtes et des réponses entre deux UA constitue un dialogue.

Requête

User User
Agent Agent
Client Server

Réponse

Figure 1.4.3 – UAC et UAS.

1.4.2.2 Serveur d’enregistrement

Le serveur d’enregistrement (Registrar Server) offre un moyen pour localiser l’appelé,


tout en gérant sa mobilité. En fait, l’utilisateur indique par un message SIP REGISTER,
émis au serveur d’enregistrement, l’adresse IP où il est joignable. Ce serveur met alors à
jour la base de données de localisation. Un abonné peut s’enregistrer simultanément sur
plusieurs serveurs d’enregistrement. Dans ce cas, il est joignable sur tous les lieux qu’il a

10
Chapitre 1 Architecture de la VoIP

renseignés. Notons que le serveur d’enregistrement est optionnel. En effet, deux utilisateurs
peuvent communiquer entre eux sans passer nécessairement par un serveur d’enregistre-
ment, à condition que l’appelant possède une connaissance préalable de l’adresse IP de
correspondant. Cette contrainte est généralement absente, puisque un appelé peut être
mobile et par conséquent ne peut pas avoir une adresse IP fixe.

1.4.2.3 Serveur de localisation

Le serveur de localisation (Location Server) apporte une fonction complémentaire par


rapport au serveur d’enregistrement en offrant la localisation de l’utilisateur. Ce serveur
contient la base de données de la liste des utilisateurs qu’il gère. Cette base est renseignée
par le serveur d’enregistrement. Pour chaque enregistrement d’un utilisateur auprès du
serveur d’enregistrement, le serveur de localisation sera informé.
Généralement, les serveurs de localisation et d’enregistrement sont implémentés dans la
même entité. Il ne s’agit pas donc de serveur de localisation, mais de service de localisation
d’un serveur d’enregistrement, puisque ces fonctionnalités sont proches et dépendantes.

1.4.2.4 Serveur de redirection

Le serveur de redirection (Redirect Server) joue le rôle d’intermédiaire entre le terminal


client et le serveur de localisation. Il est sollicité par le terminal client afin de contacter le
serveur de localisation pour déterminer la position courante d’un correspondant à joindre.

1.4.2.5 Serveur proxy

Un serveur proxy est le responsable du routage d’une session SIP. Quand il reçoit une
requête SIP, il l’envoie au prochain serveur proxy ou directement à l’UA désigné par la
requête, si celui-ci est connecté au serveur proxy.

1.4.2.6 Passerelle (Gateway)

Pour assurer l’interfonctionnement entre le réseau de téléphonie commuté (RTC) [16]


et le réseau VoIP, il est essentiel d’utiliser une gateway RTC/SIP. En effet, ce Gateway
réalise deux fonctions :
— Traduction de la signalisation SIP en signalisation ISUP (ISDN User Part) [17] et
inversement ;
— Conversion des paquets RTP en signaux audio et inversement.

1.4.3 Messages SIP


Les messages SIP sont définis par l’IETF sous la référence RFC 822 [18]. Ils sont codés
à l’aide de la syntaxe de message HTTP/1.1 [19]. Un message SIP a le format représenté
dans la Figure 1.4.4.

11
Chapitre 1 Architecture de la VoIP

Ligne de requête ou d'état

En-tête

Corps du message

Figure 1.4.4 – Format générique d’un message SIP.

Dans le format générique d’un message SIP, la première partie représente soit une ligne
de requête, dans le cas où il s’agit d’une requête, soit une ligne d’état, dans le cas où il
s’agit d’une réponse. La deuxième partie contient les en-têtes du message. Alors que la
troisième partie représente le corps du message.
Une communication utilisant SIP est caractérisée par une série de messages traduisant
une requête d’un utilisateur à un serveur soit une réponse d’un serveur à un utilisateur.

1.4.3.1 Requêtes SIP

La partie qui définit la requête est subdivisée en trois champs illustrés dans la Figure
1.4.5 :
— méthode : elle précise l’action sollicitée.
— URI (Uniform Resource Identifier) [20] : elle spécifie la destination de la requête.
— version : elle indique le numéro de la version du protocole SIP utilisé.

Requête En-tête Corps

Méthode URI Version

Figure 1.4.5 – Format d’une requête SIP.

Les champs sont séparés par un séparateur, ou SP (SeParator).


SIP utilise six méthodes fondamentales pour exprimer ses requêtes.
1. Initiation d’une session avec le message SIP INVITE : cette requête indique que
l’utilisateur correspondant à l’URL (Uniform Resource Locator) [21] SIP spécifiée
est invité à participer à une session. Cette session est décrite par le corps du message
(par exemple : média supportés par l’appelant). Dans le cas où il s’agit d’une réponse
favorable, l’appelé doit spécifier les médias qu’il supporte.
2. Confirmation des paramètres de session avec le message SIP ACK : cette requête
permet l’appelant de confirmer qu’il a bien reçu une réponse définitive à une requête
INVITE.
12
Chapitre 1 Architecture de la VoIP

3. Obtention des informations avec le message SIP OPTIONS : cette requête est utilisée
pour interroger un serveur SIP, y compris l’UAS sur différentes informations. En
générale, elle contient deux volets : l’état du serveur et ses capacités.
4. Finalisation d’une session avec le message SIP BYE : cette requête permet de fina-
liser une communication. Elle peut être émise soit par l’appelant soit par l’appelé.
5. Annulation d’une demande avec le message SIP CANCEL : cette requête annule
toutes les requêtes dont les réponses ne sont pas encore parvenues au demandeur.
Elle n’interrompe pas une session, mais elle indique que la réponse n’est plus atten-
due et qu’il n’est pas nécessaire de traiter la requête.
6. Enregistrer sa localisation avec le message SIP REGISTER : cette requête permet
au client d’enregistrer son adresse au serveur auquel il est relié. Il existe d’autres
requêtes tels que :
— INFO : cette requête permet d’avoir des informations de contrôle d’une session.
— UPDATE : cette requête est utilisée pour mettre à jour la session sans affecter un
dialogue.
— SUBSCRIBE : cette requête permet de s’abonner à un service.
— NOTIFY : cette requête permet de prévenir un UA d’un évènement.
— MESSAGE : cette requête envoie un message instantané.

1.4.3.2 Réponses SIP

Les réponses SIP suivent le format spécifié dans la Figure 1.4.6.

Etat En-tête Corps

Version Code Raison

Figure 1.4.6 – Format des réponses SIP.

Les réponses aux requêtes SIP commencent par une ligne d’état (Status Line). Elle
contient les trois champs suivants :
— Version : représente la version du protocole SIP utilisée.
— Code d’état (Status Code) : c’est un code numérique de trois chiffres indiquant la
réponse donnée à la requête. Il est codé sur trois bits.
— Raison (Reason Phrase) : c’est un message textuel décrivant le code d’état de la
réponse. Son utilité n’est pas protocolaire mais informative. Il s’agit donc d’un
élément redondant par rapport au code d’état. Il offre ainsi un niveau de clarté
plus accessible. Ce qui améliore la compréhension des messages protocolaires par les
utilisateurs et les programmeurs.
13
Chapitre 1 Architecture de la VoIP

Il existe six classes de réponse dans le protocole SIP. Dans ces classes sont répertoriées
tous les messages de retour possibles. Le premier chiffre de chaque code définit la catégorie
à laquelle appartient le code.
Les six classes sont les suivantes :
— 1 xx = Information : la requête a été reçue et continue à être traitée.
— 2 xx = Succès : l’action a été reçue avec succès, comprise et acceptée.
— 3 xx = Redirection : une autre action doit être menée pour valider la requête.
— 4 xx = Erreur du client : la requête contient une syntaxe fausse ou ne peut pas être
traitée par ce serveur.
— 5 xx = Erreur du serveur : le serveur n’a pas réussi à traiter une requête apparem-
ment correcte.
— 6 xx = Echec général : la requête ne peut être traitée par aucun serveur.

1.5 Fonctionnement du protocole SIP


Nous illustrons la succession chronologique des messages de requêtes et de réponses
dans les scénarios classiques suivants :
1. Enregistrement d’un terminal.
2. Initialisation d’une communication directe.
3. Terminaison d’une communication.

1.5.1 Enregistrement d’un terminal


La première action d’un terminal active dans un réseau VoIP consiste à s’enregistrer
auprès d’un serveur d’enregistrement, de manière à être disponible si un appelant souhaite
le communiquer. Ce scénario est représenté par la Figure 1.5.1.

Serveur Serveur
Terminal Serveur proxy
d'enregistrement de localisation

Base
de localisation
REGIS
T ER
REGIS
TER
Enregistrement
200 OK dans la base
200 OK

Figure 1.5.1 – Enregistrement d’un terminal.

Le serveur de localisation sauvegarde dans sa base de données une entrée associant


l’identifiant d’un utilisateur avec son adresse IP et le port utilisé par l’application SIP.
Cette entrée sera du type indiqué au Tableau 1.1.

14
Chapitre 1 Architecture de la VoIP

Utilisateur Localisation Délai d’expiration


sip :ali@domaine.tn sip :ali@192.68.138.255 :55555 20 minutes

Table 1.1 – Entrée dans le serveur de localisation permettant de localiser un utilisateur.

Il convient à noter que l’enregistrement d’un utilisateur dans la base de données du


serveur a un délai d’expiration. Périodiquement, l’utilisateur doit rafraîchir son entrée
avec la requête REGISTER pour manifester sa présence.

1.5.2 Initialisation d’une communication directe


Une communication peut se manifester directement entre deux UA, sans faire intervenir
d’autres entités. Dans ce cas, l’appelant doit avoir l’adresse IP de la personne qu’il souhaite
contacter. La Figure 1.5.2 représente ce scénario.

Terminal SIP Terminal SIP


Appelant Appelé
(UAC) (UAS)
INVITE

180 Ringing

200 OK

ACK

Flux multimédia (audio, vidéo, texte, ...)

Figure 1.5.2 – Initiation d’une communication directe.

Ce schéma de communication montre la simplicité d’utilisation du protocole SIP. Ici,


quatre étapes sont suffisantes pour établir une communication entre les deux utilisateurs :
1. L’UAC de l’appelant envoie une requête SIP INVITE demandant à l’UAS de son
correspondant d’initier une communication. Ce message comporte les paramètres
désirés pour établir la communication.
2. Dès que l’UAS reçoit le message, l’appelé sera informé (le téléphone sonne). De
même, il indique à l’appelant que l’appelé est en train d’être averti de l’appel (par
une réponse provisoire 180 RINGING).
3. Dès que l’appelé accepte l’appel, l’UAS informe l’appelant que l’appel peut com-
mencer (par une réponse définitive 200 OK). Ce message comporte les paramètres
que l’UAS supporte pour la session.
4. L’UAC retourne à l’UAS un message d’acquittement (requête ACK) lui indiquant
qu’il a pris note que l’appel peut débuter. Ce message comporte les paramètres fixés
pour la session, qui tiennent compte de ces possibilités et de celles de l’UAS.
15
Chapitre 1 Architecture de la VoIP

Les utilisateurs (appelant et appelé) sont ensuite mis en relation et peuvent échanger les
messages.

1.5.3 Terminaison d’une communication


La Figure 1.5.3 représente la terminaison d’une session à la demande de n’importe quel
utilisateur (appelant ou appelé) souhaitant mettre fin à l’appel.

Terminal SIP Terminal SIP

Flux multimédia (audio, vidéo, texte, ...)

BYE

200 OK

Figure 1.5.3 – Terminaison d’une communication.

Ce scénario comporte les deux étapes suivantes :


1. Une requête BYE est envoyée afin d’indiquer au correspondant que la session va
être finalisée.
2. Le correspondant répond à cette requête en validant cette demande par une réponse
200 OK.
La communication entre les utilisateurs est alors rompue.

1.6 Attaques dans la VoIP


La popularité des applications VoIP a attiré l’attention des attaquants. Ces derniers
tentent d’avoir un accès non autorisé aux données et aux informations transmises dans
le but de réaliser des gains financiers ou pour satisfaire leurs propres désirs. Les attaques
VoIP peuvent exploiter la faiblesse de plusieurs protocoles. Ainsi, nous pouvons classer
ces attaques en trois catégories : les attaques sur le protocole SIP, les attaques sur le
protocole RTP et les attaques sur les autres protocoles.

1.6.1 Attaques sur le protocole SIP


Par défaut, les messages SIP sont envoyés en texte clair sur le protocole UDP (User
Datagram Protocol) [22]. La signalisation SIP est par conséquent vulnérable aux injections
de paquets ou à l’écoute malveillante. Les attaques les plus connues sur le protocole SIP
sont : le déni de service, l’écoute clandestine, le détournement du trafic, le reniflage, le
fraude de facturation et les communications non désirées (SPIT).
16
Chapitre 1 Architecture de la VoIP

1.6.2 Déni de Service


Le déni de service ou DoS (Denial of Service) [23] est une attaque entraînant l’indispo-
nibilité d’un service/système pour les utilisateurs légitimes. Cela pourrait inclure l’échec
d’établir ou de recevoir un appel. Ainsi, le déni de service pourrait être une attaque gé-
nérale empêchant l’établissement des appels, ou une attaque plus sélective empêchant
les appels à certaines adresses (numéros de téléphones) [24]. La motivation de cette at-
taque est de perturber les activités et/ou d’empêcher la communication afin de déclencher
un autre événement (par exemple, retarder une intervention d’urgence pour effectuer un
vol). L’attaque DoS pourrait être distribuée en impliquant plusieurs ordinateurs appelés
zombies.
Nous détaillons dans ce qui suit une forme d’attaque DoS qui correspond à l’annulation
de l’appel.

Annulation de l’appel via le message SIP CANCEL

Pour réaliser cette attaque, l’attaquant surveille l’activité du proxy et attend l’arrivée
d’un appel à un utilisateur spécifique. Une fois le terminal de l’utilisateur reçoit le message
SIP INVITE, l’attaquant expédie immédiatement un message SIP CANCEL. Ce message
cause une erreur sur le terminal de l’appelé et finalise l’appel. Ce type d’attaque est utilisé
pour interrompre la communication. Cette attaque est réalisée en utilisant l’usurpation
IP qui sera expliquée en détail dans la sous-section 1.8.2. Le scénario d’attaque est illustré
par la Figure 1.6.1.

7.C
AN
UA5Eve CE
L

ITE
NV
1.I UA5Alice
ing
2.5INVITE ing
4.R
E
NVIT 5.5Ringing
1.I
ing Proxy5SIP Proxy5SIP
R ing Domain5B
6.5 Domain5A

UA5Bob

Figure 1.6.1 – Attaque DoS via un message SIP CANCEL.

L’utilisateur Bob initie l’appel en envoyant une invitation (1) au proxy approprié. Le
proxy du domaine A envoie la requête (2) au proxy lié au terminal d’Alice. Par la suite,
c’est le proxy du domaine B qui achemine le message SIP INVITE (3) pour arriver enfin
17
Chapitre 1 Architecture de la VoIP

à la destination. A la réception de l’invitation, le terminal d’Alice sonne (4). Cette infor-


mation est réacheminée jusqu’au terminal de Bob. L’attaquant qui surveille l’activité du
proxy du domaine B envoie un message SIP CANCEL (7) avant qu’Alice n’ait pu envoyer
la réponse SIP OK qui accepte l’appel. Ce message annulera le message SIP INVITE en
attente. Il s’agit donc DoS puisque l’appel n’a pas eu lieu.

1.6.3 Ecoute clandestine (Eavesdropping)


L’eavesdropping [25] est l’acte d’écouter secrètement une conversation VoIP sans avoir
l’accord des participants. Ceci pourrait être réalisé en capturant les paquets. En effet, un
attaquant peut intercepter et enregistrer le trafic en utilisant des analyseurs de réseau.
Il peut également décoder la conversation vocale en utilisant par exemple le décodeur
VOMIT (Voice Over Misconfigured Internet Telephones) [26]. Ce décodeur permet de
convertir les paquets interceptés en fichier ".wav". Ainsi, l’attaquant peut réécouter ce
fichier avec n’importe quel lecteur de son.

1.6.4 Détournement du trafic (Call hijacking)


Contrairement à l’écoute clandestine, le Call hijacking [27] permet de rediriger l’intégra-
lité de l’appel vers une autre partie. Ainsi, l’attaquant peut participer à la conversation
en faisant semblant d’être l’appelé légitime. Ceci est possible en modifiant la base de
données du serveur d’enregistrement. Dans ce cas, l’adresse IP de l’appelé légitime est
remplacée par celle de l’attaquant. Cela oblige le proxy d’envoyer les appels destinés à
l’appelé d’origine vers l’attaquant.

1.6.5 Reniflage
Un reniflage (sniffing) [28] du trafic SIP permet à l’attaquant de collecter des informa-
tions sur la totalité du réseau VoIP. Ceci peut mener à un vol d’identité ou à la révélation
d’informations confidentielles [29]. En effet, si un attaquant peut écouter le trafic réseau, il
peut donc récupérer une combinaison {nom utilisateur, mot de passe} pour s’authentifier
ultérieurement.

1.6.6 Fraude de facturation


La fraude de facturation est la possibilité d’avoir un accès non autorisé aux services
VoIP pour en tirer un profit personnel ou monétaire. Cette attaque peut être réalisée
en manipulant les messages de signalisation ou la configuration des composants VoIP,
y compris les systèmes de facturation. Un exemple de cette attaque consiste à utiliser
des messages SIP BYE et OK falsifiés. Ces messages semblent terminer l’appel et arrêter
ainsi la facturation alors que dans la réalité l’appel reste en cours [30]. Un autre exemple
répandu est l’usurpation d’identité d’un téléphone afin d’obtenir des appels gratuits de

18
Chapitre 1 Architecture de la VoIP

longue distance. Dans ce cas, l’attaquant usurpe le système en le faisant penser qu’il s’agit
d’un autre téléphone légitime. L’attaquant utilise ensuite son identification "clonée" pour
faire de nombreux appels. Les charges des appels sont ensuite transmises à la victime.

1.6.7 SPIT
SPIT est une attaque semblable au SPAM qui envahit les boîtes de messages électro-
niques. Elle représente un bon marché pour les annonceurs en raison de la quasi-gratuité
de la téléphonie sur Internet. De plus, elle est utilisée pour diriger les clients vers un service
ou essayer de leur vendre des produits. Ce type d’attaque provoque des ennuis majeurs
pour les utilisateurs de la VoIP. Contrairement au SPAM ordinaire, qui peut être ignoré,
le SPIT demande une attention immédiate. En effet, lorsque le téléphone sonne, l’appelé
doit généralement décider d’accepter et d’écouter l’appel. Ainsi, après avoir réalisé que
l’appel contient des informations non désirées et se déconnecte, l’appelé s’avère qu’il a
déjà perdu du temps, de l’argent (facture de téléphone) et de la productivité. Dans ce
contexte, selon [31], les clients de la VoIP des États-Unis perdent chaque année plus de 8,6
milliards de dollars en raison de la fraude provoquée par le SPIT (ce chiffre est toujours en
croissance). De plus, en 2014, la FTC (Federal Trade Commission) a reçu plus de 22 mil-
lions de plaintes contre les appels non sollicités et illégaux. Ainsi, d’après ces statistiques,
le SPIT devient de plus en plus un problème répandu malgré les techniques de défenses
proposées. Par conséquent, une étude détaillée de cette attaque s’avère indispensable afin
de proposer des solutions concrètes et pertinentes. Cette attaque sera étudieé en détail
dans les prochains chapitres.

1.7 Attaques sur le protocole RTP


Après l’établissement d’une session entre deux UAs, le protocole RTP [28] est utilisé
pour transporter les données multimédia (trafic en temps réel) entre les parties communi-
cantes. Dans ce contexte, ce protocole est cible de plusieurs attaques dont nous pouvons
citer : l’attaque de charge utile (Payload attack) et l’attaque de falsification (Tampering
attack).

1.7.1 Attaque de charge utile


Un utilisateur malveillant peut utiliser l’attaque d’homme-du-milieu (Man-In-The-Middle)
[27] pour intercepter et modifier la charge utile d’un message de flux RTP. Comme il est
indiqué dans [32], [33] et [34], le message vocal codé entre deux nœuds (appelants) est
transporté par le protocole RTP. Ce protocole est une extension au protocole UDP (User
Datagram Protocol) tout en ajoutant des informations de séquencement. Cela signifie
qu’un attaquant pouvant inspecter la charge utile du message est capable d’écouter la

19
Chapitre 1 Architecture de la VoIP

conversation entre les deux appelants. En outre, si un attaquant peut modifier le mes-
sage, alors il serait en mesure de modifier le sens de la conversation en injectant son
propre message ou dans un autre cas, d’introduire un bruit afin de dégrader la qualité du
message.

1.7.2 Attaque de falsification


Le paquet RTP comporte deux champs dans son en-tête qui peuvent être manipulés
par un attaquant. Ces champs sont le numéro de séquence et les champs d’horodatage
(timestamp fields). L’attaquant peut modifier avec succès la séquence du paquet et rend
ainsi la conversation dénuée de sens. Aussi, il peut provoquer le téléphone (nœud) recevant
le paquet, à se rendre hors ligne [34].

1.8 Attaques sur les autres protocoles


Ces attaques menacent principalement la sécurité des réseaux de données IP.

1.8.1 ARP (Address Resolution Protocol ) Poisonning


En envoyant des faux paquets ARP [35], l’attaquant peut effectuer une association de
l’adresse MAC (Media Access Control) [36] de l’attaquant et une autre adresse IP dans
le cache ARP du nœud victime. Cette attaque peut permettre à l’attaquant de se faire
passer pour un nœud de contrôle ou un nœud de terminaison dans le système VoIP [37].

1.8.2 Usurpation IP (IP Spoofing)


Cette attaque consiste à utiliser une adresse IP de confiance interne ou externe pour
usurper l’identité d’un ordinateur de confiance. Dans [38], les auteurs affirment que les
attaques d’usurpation IP peuvent être utilisées en tant que pivot pour d’autres attaques
comme le DoS. Dans ce cas, l’attaquant est capable de cacher son identité en utilisant des
adresses sources usurpées (Spoofed).

1.8.3 Inondation du TCP SYN


L’attaquant génère un grand nombre de paquets avec des adresses source aléatoires
et un indicateur TCP SYN [39], demandant ainsi l’allocation d’un tampon au nœud
récepteur. Après l’épuisement de l’espace tampon, les utilisateurs légitimes seront inca-
pables d’établir une connexion avec la machine de la victime. Cependant, les protocoles
de signalisation VoIP (H.323 et SIP) comptent sur le protocole TCP pour effectuer la
communication entre les nœuds.

20
Chapitre 1 Architecture de la VoIP

1.8.4 Réponse TCP ou UDP


A partir des paquets capturés, un hacker peut extraire des informations telles que les
informations d’authentification du périphérique et les conversations vocales. Ensuite, les
données capturées peuvent être replacées sur le réseau pour une nouvelle connexion. Cela
permet à l’attaquant d’enregistrer un périphérique dans le système en utilisant une autre
identification de dispositif. Ainsi, il peut émettre et recevoir des appels ou intercepter des
portions d’un appel vocal ou de données [34].

1.8.5 Insertion du serveur TFTP (Trivial File Transfer Protocol )


Les nœuds terminaux (combinés de téléphone VoIP) sont généralement configurés pour
localiser un serveur TFTP afin d’obtenir des informations de configuration, y compris la
mise à jour du logiciel sur le dispositif. Si un attaquant réussit à établir un faux serveur
TFTP sur le réseau, les nœuds pourront recevoir des canulars de configuration tels que le
numéro de téléphone et l’ID d’un autre combiné et causer ainsi une fraude de facturation
[40].

1.9 Mécanismes de sécurité dans la VoIP


La plupart des mécanismes de sécurité dans la VoIP et plus précisément à l’entour du
protocole SIP s’interessent à l’authentification, le chiffrement et l’intégrité des messages
SIP. Parmi ces mécanismes, nous évoquons HTTP digest authentification [41], l’IPsec [42],
transport layer protocol (TLS) [43] et secure multipart Internet mail exchange (S/MIME)
[44]. SIP utilise le HTTP digest authentification pour vérifier l’identité des utilisateurs.
En se basant sur la configuration du serveur SIP, un serveur peut forcer l’authentification
de l’appelé avant le traitement des demandes SIP. Cependant, cette authentification ne
peut être appliquée que sur certaines demandes, certains utilisateurs ou des demandes en
provenance de certains proxies ou serveurs de redirection.
L’IPsec assure la confidentialité, l’intégrité, l’anti-rejeu et l’authentification des paquets
IP en utilisant une association de sécurité (AS) entre la source et la destination. Afin de
réussir le déploiement de l’IPsec, une gestion évolutive et automatisée des AS et des clés est
souvent nécessaire. TLS est un mécanisme qui est basé sur le Secure Socket Layer (SSL)
[45] et fonctionne sur TCP. Il permet la confidentialité, l’intégrité et l’authentification du
serveur. L’authentification mutuelle peut être assurée par l’échange de certificats durant la
procédure de prise de contact TLS. Bien que les certificats auto-signés ne peuvent pas être
toujours crédible, le maintien d’une infrastructure à clé publique exige beaucoup d’efforts
de gestion. IPsec et TLS fonctionnent selon le concept saut par saut, ou «hop by hop»
[46], pour sécuriser une session de SIP mais leurs calculs cryptographiques ne sont pas
négligeables. TLS ajoute plusieurs allers-retours pour ouvrir une connexion augmentant
la latence du message.

21
Chapitre 1 Architecture de la VoIP

S/MIME assure le chiffrement de bout en bout et l’intégrité des données. C’est un


protocole de sécurité développé pour sécuriser les emails. Certains en-têtes SIP ne peuvent
pas être chiffrés si elles sont demandées par les proxies intermédiaires pour le routage SIP.
Cependant, le chiffrement des corps de message empêche seulement l’écoute clandestine
et les attaques par injection de médias.
Plusieurs autres mécanismes ont été évoqués afin d’assurer la sécurité dans la VoIP
tels que les pare-feux et les systèmes de détection/prévention. Les pare-feux, représentant
une fonction de sécurité standard sur les réseaux de données, inspectent chaque paquet
qui se déplace vers/à partir du réseau. Les services de téléphonie IP basés sur SIP et
H.323 utilisent les paquets UDP et les connexions TCP entrantes. Cependant, la plupart
des pare-feu dans un environnement d’entreprise sont configurés de telle sorte qu’ils ne
permettent pas à ces services d’y passer à travers. En outre, en raison des affectations
dynamiques de ports tout au long de l’appel, les pare-feux ont des problèmes avec le
filtrage du trafic VoIP.
Les systèmes de détection/prévention sont devenus une partie intégrante de la plupart
des architectures de sécurité basées sur les pare-feux. Ils bloquent les paquets malveillants
et protègent le système de réseau contre les intrusions. Cependant, les systèmes de pré-
vension (IPS : Intrusion Prevention System) mal-configurés peuvent détecter par erreur
les paquets normaux comme malveillants provoquant ainsi des faux positifs.
Le tableau 1.2 illustre les différentes méthodes et mécanismes proposés pour contrer les
attaques sur le protocole SIP, le protocole RTP et les autres protocoles.

Protocoles Attaques Mesures de Sécurité


Déni de
— L’utilisation des pare-feux pour filtrer le trafic in-
service
désirable,
SIP
— L’emploi des matériels à usage spécial (tels que les
routeurs et commutateurs) pour empêcher l’atta-
quant d’avoir un accès non autorisé,
— Les systèmes d’authentification efficaces (tels que
IPsec) pour empêcher l’accès non autorisé aux
composants d’infrastructure.

Ecoute
— L’utilisation du chiffrement de flux assuré par IP-
clandestine
sec,
— La sécurisation de l’accès aux ports des switchs,
— L’utilisation du VPN (Virtual Private Network)
pour isoler le trafic VoIP.

Détournement L’utilisation de TLS pour une authentification sécurisée.


du trafic
Reniflage L’utilisation des mécanismes d’authentification combi-
nés avec le chiffrement tel que IPSec.
Fraude de La configuration correcte des pare-feux et la protection
facturation des ports.

22
Chapitre 1 Architecture de la VoIP

SPIT
— Le filtrage du trafic en se basant sur la fréquence
et la durée de l’appel,
— La détection et la mitigation des réseaux de SPIT
utilisant l’analyse de protocole de signalisation,
— Le filtrage de SPIT en se basant sur la réputation,
— L’utilisation du cercle de confiance,
— L’utilisation de défense Socio-techniques,
— Une forte authentification,
— L’utilisation du VPN.

Attaque de
RTP — Le cryptage des paquets transmis par l’utilisa-
charge utile
tion du protocole sécurisé SRTP (Secure Real-time
Transport Protocol) [47], de cette façon, il y aura
une prévention contre l’écoute clandestine sur des
paquets et la modification du contenu du paquet,
— L’utilisation de l’authentification de port et le
VLAN (Virtual Local Area Network).

Attaque de La séparation entre le trafic de la VoIP et le trafic normal


falsification de données sur un réseau. En effet, la mise en œuvre
d’un VLAN pour le trafic VoIP, différent du trafic de
données, va augmenter la difficulté pour un attaquant
d’avoir l’accès ou de modifier le trafic VoIP.
ARP Poison- L’utilisation de la DAI (Dynamic ARP Inspection) [48].
Autres
ning Celle-ci, intercepte tous les paquets ARP sur le commu-
protocoles
tateur et vérifie les liaisons valides IP-vers-MAC avant
la mise à jour de cache ARP locale ou les transmettre à
la destination appropriée.
Usurpation
— Les routeurs doivent être configurés de telle sorte
IP
ne pas autoriser les paquets entrants avec des
adresses sources qui appartiennent à un domaine
local. Les routeurs doivent être également confi-
gurés à rejeter les paquets acheminés hors du do-
maine local et qui ne contiennent pas des adresses
sources se trouvant dans la plage des adresses lo-
cales.
— L’authentification du Port et la séparation du traf-
fic VoIP de non-VoIP à l’aide de VLANs

Inondation La configuration correcte du pare-feu, l’implémentation


du TCP SYN du TCP en utilisant les cookies SYN, ou l’envoi d’un
SYN-ACK avec un numéro de séquence soigneusement
construit avant l’allocation de mémoire tampon.

23
Chapitre 1 Architecture de la VoIP

Réponse TCP Le chiffrement des sessions y compris le numéro de sé-


ou UDP quence unique : le nœud de réception déchiffre le paquet
et vérifie le numéro de séquence pour voir s’il représente
la valeur attendue suivante.
Insertion La connexion authentifiée au serveur de configuration,
du serveur tel que TLS en utilisant Secure Socket Layer (SSL) au
TFTP niveau de TFTP : le nœud terminal doit être préalable-
ment configuré avec les informations de certification du
serveur.

Table 1.2 – Mécanismes de sécurité dans la VoIP

1.10 Conclusion
La VoIP est une révolution dans le monde des télécommunications. Toutefois, la sou-
plesse du système VoIP et la convergence des réseaux voix/données apportent avec eux
des risques de sécurité supplémentaires. Dans ce chapitre, nous avons présenté l’architec-
ture matérielle et logicielle du réseau VoIP. Nous nous sommes focalisés sur le protocole
de signalisation SIP et ses différents composants. Nous avons également illustré les diffé-
rentes attaques dans la VoIP qui touchent principalement le protocole SIP, le protocole de
media RTP et les différentes autres protocoles en liaison avec la VoIP. Aussi, nous avons
présenté les mécanismes de sécurité utilisés pour contrer ces attaques. Ces mécanismes
ont montré une grande efficacité dans certains cas. Cependant, ils restent limités avec le
développement rapide des techniques d’évasion de l’attaquant. Dans ce contexte, le SPIT
représente l’une des attaques qui demande toujours des solutions de sécurité innovantes
et efficaces. En effet, malgré les méthodes et mécanismes de sécurité proposés, le SPIT-
ter trouve toujours des solutions d’évasion provoquant ainsi des incidents graves pour les
individus et pour la société.
Dans le chapitre suivant, nous étudions l’attaque SPIT ainsi que ses principales mé-
thodes de détection. En se basant sur l’avantage et l’inconvénient de chaque méthode,
nous évoquons notre méthode de détection anti-SPIT.

24
Chapitre 2

Aperçu sur l’Attaque SPIT

2.1 Introduction
La technologie VoIP assure des avantages majeurs en termes de réduction des coûts
et de la qualité de services. Cependant, l’utilisation de l’internet comme principale in-
frastructure de la VoIP introduit plusieurs menaces et vulnérabilités. Le SPIT est l’une
de ces menaces. Avec le développement de la VoIP, la menace SPIT est devenue un pro-
blème très sérieux. Le but de ce chapitre est de donner un aperçu détaillé sur la menace
SPIT tout en présentant les différentes techniques de détection/prévention utilisées pour
protéger le réseau VoIP.
Le reste de ce chapitre est organisé comme suit : La Section 2.2 introduit le SPIT.
La Section 2.3 présente une analyse de SPIT. Dans la Section 2.4, nous illustrons les
différentes menaces de SPIT. La Section 2.5 détaille les différentes techniques de détection
de SPIT. La Section 2.6 présente les plateformes anti-SPITs. Nous terminons par une
conclusion du chapitre.

2.2 Introduction au SPIT

2.2.1 Définition intuitif de SPIT


Le terme SPIT est défini d’une façon très similaire dans différentes publications. Ces
définitions peuvent être résumées comme « les appels en masse », « les appels indésirables »
et « les appels non sollicités». Dans [49], le SPIT est défini comme étant des «appels
publicitaires non sollicités». Cette définition représente une forme particulière de SPIT.
Dans [50], cette menace est définie comme étant «la transmission en masse des messages
et des appels non sollicités". Cette définition présente quelques ambiguïtés. En effet, nous
ne pouvons pas affirmer si le terme «messages» est utilisé afin de généraliser le type
des messages envoyés ou si il est utilisé afin d’inclure les SPAMs envoyés via les messages
instantanés. Ainsi, la définition la plus précise se trouve dans [51] où "Call SPAM" (comme

25
Chapitre 2 Aperçu sur l’Attaque SPIT

les auteurs l’appellent) est définie comme étant «un ensemble en masse de tentatives
d’initiation de session non sollicitées qui tente d’établir une communication vocale ou une
communication multimédia, une discussion instantanée, ou tout autre type de session de
communication ».
D’après les différentes définitions déjà citées, nous pouvons remarquer qu’elles sont très
semblables et elles diffèrent juste dans leurs profondeurs.

2.2.2 Différentes formes de SPIT


Le terme spam est principalement utilisé dans le contexte de courrier électronique, mais
peut également se référer à toute communication non sollicitée [52]. Dans le contexte des
réseaux VoIP, SPIT se réfère généralement à des appels massifs non sollicités [53]. En
raison des multiples moyens de communication dont le protocole SIP fournit [52], trois
formes de SPAM ont été identifiées dans ce protocole :
— SPAM over Internet Telephony (SPIT) : Ce type de SPAM est défini comme un
envoi massif de tentatives d’initiation de session (des requêtes INVITE) non sollici-
tées. Généralement, c’est un UAC (User Agent Client) qui lance parallèlement un
grand nombre d’appels. Si l’appel est établi, l’application du spammeur diffuse une
annonce pré-enregistrée, et ensuite elle termine l’appel.
— Instant Message (IM) SPAM : Ce type de SPAM est semblable à celui de l’e-mail.
Il est défini comme un envoi massif de messages instantanés non sollicités. Les IM
SPAM sont envoyés fréquemment sous forme de requêtes SIP. Ils pourraient se pré-
senter encore sous forme des requêtes INVITE avec un corps contenant généralement
un lien vers un site malveillant.
— Presence SPAM : Ce type de SPAM est semblable à l’IM SPAM. Il est défini comme
un envoi massif de requêtes de présence (des requêtes SUBSCRIBE) non sollicitées.
Dans ce cas, le but de l’attaquant est de rejoindre la liste blanche "white list" d’un
utilisateur pour lui envoyer des messages instantanés ou pour communiquer avec
lui autrement. Contrairement à l’IM SPAM, le Presence SPAM ne transmet pas
réellement le contenu des messages.

2.2.3 Comparaison entre SPIT et SPAM


Malgré la ressemblance qui existe entre SPIT VoIP et SPAM email, y compris l’ap-
pellation de SPIT qui commence par le mot "SPAM", il y a de grandes différences. La
ressemblance se manifeste dans le faite que les expéditeurs (ou appelants) utilisent l’Inter-
net afin de placer des appels non sollicités vers des utilisateurs cibles. La différence majeure
se situe essentiellement dans la manière de communication (c.-à-d. VoIP ou email). En
effet, les attaques SPIT s’effectuent en temps réel contrairement au SPAM. En d’autres
termes, si une session VoIP est déjà établie et le téléphone sonne, il est trop tard d’inter-
venir. Dans le cas du SPAM, le destinataire peut décider s’il veut le lire immédiatement

26
Chapitre 2 Aperçu sur l’Attaque SPIT

ou pas. Le Tableau 2.1 présume une comparaison entre le SPAM et le SPIT [54].

SPAM SPIT
Transmission sans contrainte de Communication en temps réel
temps
Possibilité d’enregistrement avant Transmission immédiate
transmission
Remplissage de la boîte email Sonnerie du téléphone (remplissage
de la boite vocale)
Possibilité de vérifier le contenu Vérification du contenu après le
avant la transmission dérangement de l’appelé
Vérification du contenu nécessite un Vérification du contenu nécessite la
traitement de texte (facile) reconnaissance vocale humaine
(difficile)
Peut-être généré par des robots Peut-être généré par des (Bot nets)
(Bot nets) avec un coût très faible avec un coût très faible
Usage pour les objectifs de Usage pour les objectifs de
marketing et de fraude marketing et de fraude

Table 2.1 – Comparaison SPAM et SPIT.

La vague des SPAM domine de plus en plus le trafic régulier des emails en provoquant
des ennuies réguliers aux utilisateurs. Ce phénomène devient incontrôlable. Nous espérons
que les SPIT n’atteignent pas les réseaux VoIP de la même manière que les SPAM. Pour
cela, il faut trouver des solutions effectives pour les bloquer avant qu’il soit trop tard.
Ainsi, l’analyse des incidents de SPIT est indispensable pour en tirer des solutions.

2.3 Analyse de SPIT


Dans la pratique, l’initiateur de SPIT a pour objectif d’établir une session de commu-
nication avec d’autant de victimes que possible afin de transférer un message à un compte
valide. Ainsi, il peut accomplir ce but via quatre étapes. La première étape consiste à col-
lecter systématiquement les adresses de contact des victimes. La deuxième étape permet
l’établissement de sessions de communication avec ces victimes. La troisième étape assure
l’envoi des messages et la quatrième étape est l’effacement des traces de SPIT.

2.3.1 Collecte de l’information


Dans le but d’atteindre autant de victime que possible, l’attaquant doit collecter une
liste valide des URIs de SIP. Le principe de l’analyse de l’attaque est la possession d’au
moins un compte valide et la connaissance du schéma des URIs de SIP de la plateforme
cible (par exemple le fournisseur). Supposons que l’attaquant dispose d’un compte SIP
valide d’un fournisseur SIP "prov.com" et il veut analyser le réseau de ce fournisseur
afin d’obtenir une liste valide des URIs de SIP. Supposons également que le fournisseur

27
Chapitre 2 Aperçu sur l’Attaque SPIT

"prov.com" distribue les URIs qui correspondent au schéma suivant : Le nom de l’utilisa-
teur de l’URI de SIP est un numéro de téléphone qui commence par les chiffres "555" suivi
de 4 chiffres aléatoires. Ainsi, tous les numéros de téléphone de "5550000" à "5559999"
sont des noms d’utilisateurs valides pour ce fournisseur. Maintenant, comme l’attaquant
possède les informations de tous les noms des utilisateurs valides, il doit chercher les nu-
méros qui sont déjà affectés à des clients et les autres qui ne sont pas. De cette façon,
l’attaquant peut parcourir toute la liste des URIs valides et envoyer des messages SIP
adéquats pour chaque URI et recevoir des informations sur l’état de l’URI testée.

2.3.2 Etablissement d’une session SPIT


Maintenant, l’attaquant a collecté un grand nombre d’adresses de contact. Il peut donc
commencer l’établissement de session pour les victimes. Nous pouvons distinguer deux
façons possibles d’établissement de session : l’attaquant peut établir une session par l’envoi
d’un message INVITE via Proxy (SPIT via proxy) ou il peut établir une session avec
l’envoi d’un message INVITE directement au destinataire final sans impliquer le Proxy
(Direct IP Spitting). Dans le cas de SPIT via proxy, l’attaquant a besoin d’une seule liste
des URIs de SIP permanentes et d’au moins un compte utilisateur valide. Dans le cas de
Direct IP Spitting, l’attaquant a besoin seulement de la liste des URI de SIP temporaires.

2.3.3 Envoi des messages médias SPIT


La troisième étape du processus de SPIT est l’envoi des messages médias après l’éta-
blissement de session. Le type de média envoyé dépend du scénario dans lequel l’attaque
SPIT se déroule. Les auteurs dans [49] ont défini trois types de scénarios de SPIT :
— Centres d’appels : dans les centres d’appels, un ordinateur établit un appel à une
entrée du catalogue, puis envoie l’appel à un agent de centre d’appel qui pourra
ensuite discuter avec l’appelé.
— Appels Bots : l’appelant bot commence par rechercher dans la liste des informations
rassemblées, établir une session, puis envoyer un message pré-enregistré.
— Sonnerie SPIT : certains téléphones VoIP sont préconfigurés de manière à ce qu’ils
acceptent une information d’en-tête SIP spéciale appelée «Alerte-info». Cette in-
formation peut contenir une URL pointant vers un fichier audio préalablement
enregistré quelque part sur Internet. Evidemment, cela peut être utilisé pour lire
des messages publicitaires avant l’acceptation de l’appel par l’utilisateur. Ce scé-
nario peut générer une attaque SPIT qui veut juste laisser sonner les téléphones
des victimes pour les déranger. Dans ce cas particulier, aucun média n’est envoyé
et la session sera terminée dès que le téléphone sonne (par exemple quand un "180
Ringing" est reçu). Ceci représente l’aspect le plus ennuyeux de SPIT.

28
Chapitre 2 Aperçu sur l’Attaque SPIT

2.3.4 Effacement des traces


La dernière étape permet d’effacer les traces de SPIT. En effet, après une attaque
réussite, un SPITter peut installer un Rootkit [55] dans le système d’exploitation de la
machine victime afin de masquer son passage. Un Rootkit correspond à un malware qui
permet d’infecter par exemple un PC assurant ainsi le passage d’un pirate sans qu’il soit
détecté par les outils de sécurité. Un Rootkit contient un programme nommé t0rnsb qui
correspond à un nettoyeur de fichiers de journalisation (logs). Le rôle de ce programme
est de supprimer les traces de passage de l’attaquant.

2.3.5 Analyse des incidents des SPITs


Le Tableau 2.2 illustre quelques incidents effectués par des SPITters.

Date Lieu Description


Japan / Messages commerciaux non sollicités (publicité
02/2004
SoftbankBB pour des sites d’adultes) diffusés sur VoIP
Des messages non sollicités demandent des
Japan / informations personnelles via les réseaux VoIP
11/2004
SoftbankBB (utilisés par la suite dans des attaques de
masquerade «Spoofing »)
Appels spontanés ayant une tendance
Netherlands
03/2006 évangéliste religieuse provenant de l’USA
/ SonicWall
(assurés par un fournisseur VoIP)
Appels vidéo de Marketing via Skype (vente
04/2006 USA
des assurances)
Avertissements déclenchés par le FBI
01/2008 -
USA concernant la croissance massive des attaques
02/2012
de Vishing1
La FTC (Federal Trade Commission) a reçu
USA/Federal plus de 22 millions de plaintes contre les
2014 Trade appels non sollicités et illégaux dont 200.000
Commission plaintes chaque mois contre les appels nommés
« RoboCalls » [31].
La FCC (Federal Communication
USA/Federal
Commission) a déclaré que les clients de la
Communica-
01/2015 VoIP continuent à être la cible des appels de
tion
télémarketing non désirés qui violent, dans de
Commission
nombreux cas, la loi.

Table 2.2 – Incidents des SPIT.

Il existe principalement deux catégories de SPIT : La première catégorie concerne les


télévendeurs afin de vendre leurs produits. La deuxième catégorie concerne les pirates in-
formatiques dans le but de déranger les individus ou de les espionner. Ces deux catégories
ont provoqué de graves conséquences sur le développement de la technologie VoIP. Les

29
Chapitre 2 Aperçu sur l’Attaque SPIT

utilisateurs des réseaux VoIP sont de plus en plus déçus 1 . En fait, les attaques succes-
sives de SPIT provoquent des ennuis et l’entrelacement des bons appels dans un nombre
important de SPIT. Ainsi, les SPIT réduisent l’efficacité de communication en amenant
à un remplissage permanent de la boîte vocale.
Pour réduire la gravité des attaques SPIT, il faut étudier et classifier les différentes
menaces des SPITS pour en déduire après les techniques de détection.

2.4 Menaces des SPITs


Cette section présente et discute les menaces de SPIT identifiées concernant le protocole
SIP. Cette présentation est le résultat des travaux présentés dans [50] et [56].

2.4.1 Menaces dues aux vulnérabilités de SIP


L’une des premières mesures prises par les SPITters est de trouver une liste d’adresses
URI de SIP afin de conduire des attaques SPITs.

2.4.1.1 Envoi des demandes ambiguës aux proxys

Lors d’un appel ou d’envoi d’un message, un serveur proxy décide un prochain nœud
destinataire. La décision est prise en considérant une partie spécifique de l’en-tête du
message de requête. Si la localisation de l’appelé présente une ambiguïté qui ne peut
pas être résolue, alors le proxy retourne une réponse SIP avec un code 485. Ce genre de
réponse peut contenir un champ d’en-tête de contact avec une liste de nouveaux URIs
disponibles. Par conséquent, un SPITter récupère ces informations et peut construire un
ensemble d’URIs valides.

2.4.1.2 Écoute des adresses de multicast

Chaque participant à une session de SIP doit se rendre compte de l’endroit courant
des autres UAs. La localisation physique et l’adresse IP d’un utilisateur sont découvertes
pendant la phase d’établissement de la session. En effet, pour que les URIs des utilisa-
teurs soient valides, la base de données du service de localisation enregistre n’importe quel
changement d’adresse d’un utilisateur. Ceci est réalisé en écoutant les adresses spécifiques
de multicast où les UAs envoient des messages REGISTERs qui contiennent leurs adresses

1. Le 4 octobre 2016, le Conseil de la radiodiffusion et des télécommunications canadiennes (CRTC)


a annoncé que six entreprises canadiennes ont reçu des procès-verbaux de violation assortis de sanctions
totalisant 420 000 dollars pour avoir effectué des appels de télémarketing non conformes à des Canadiens,
http ://www.nouvelles.gc.ca/web/article-fr.do ?nid=1132779.
1. Appels d’espionnages qui visent en particulier les données d’accès aux portails de e-banking des
instituts financiers. Il est difficile de suivre les traces des appelants (appels gratuits et masqués via skype,
wengo, . . . ).

30
Chapitre 2 Aperçu sur l’Attaque SPIT

IP courantes. Les UAs écoutant ces adresses sont donc informés des endroits des utilisa-
teurs. Cependant, si un SPITter écoute ce trafic multicast, il peut collecter un ensemble
d‘adresses valides des utilisateurs.

2.4.1.3 Population d’adresses "actives"

Les messages REGISTER, utilisés pour le processus d’enregistrement, associent l’URI


d’un utilisateur avec la machine dans laquelle il est actuellement connecté. En exploitant
ce fait, conjointement avec la vulnérabilité précédente, un SPITter peut découvrir les
adresses « actives » (à savoir les adresses qui sont utilisées par les utilisateurs en ligne).

2.4.1.4 Contacte d’un serveur de redirection avec des demandes ambiguës

Les serveurs de redirection sont principalement utilisés dans le protocole SIP pour
réduire la charge de traitement sur les serveurs proxy. Plus précisément, quand un serveur
de redirection reçoit une demande autre que CANCEL, soit il la refuse, soit il collecte la
liste des emplacements correspondante du service de localisation. Cette liste sera envoyée
après au demandeur. Les SPITters pourraient exploiter cette fonctionnalité en faisant une
attaque par dictionnaire sur un serveur de redirection. Ainsi, ils acquièrent la liste des
emplacements alternatifs afin de générer des appels en masse et des appels non sollicités.

2.4.1.5 Comptes SIP jetables

Un SPITTer pourrait créer plusieurs comptes dans un ou plusieurs domaines. Cette ac-
tion rend difficile l’identification de l’origine de l’appel SPIT réduisant ainsi l’efficacité de
la contremesure de la Liste Noire (Blacklist). Dans le protocole SIP, parmi les utilisations
des messages REGISTER est la création de nouvelles inscriptions (à savoir, les comptes
SIP) ou la modification de ceux qui existent déjà. Un SPITter est libre d’émettre plusieurs
messages REGISTER créant ainsi plusieurs comptes dans un domaine SIP.

2.4.1.6 Abus des serveurs sans mémoire (stateless)

Les serveurs à relais ouverts (Open Relay Servers), qui existent dans le domaine d’email,
sont employés par des Spammeurs pour expédier leurs SPAM email. Les spécifications de
SIP stipulent qu’il peut y avoir des serveurs sans mémoires qui offrent les mêmes services
que les serveurs à relais ouverts dans le sens qu’ils permettent d’expédier n’importe quel
appel à une destination. Les SPITters peuvent exploiter ces serveurs pour cacher leurs
localisations et leurs adresses IP.

2.4.1.7 Option anonyme de SIP et Back-to-Back User Agents

L’option anonyme de SIP permet l’expédition de n’importe quel appel à un destinataire


sans révéler sa propre identité. Les attaquants SPITter utilisent cette option afin d’ou-

31
Chapitre 2 Aperçu sur l’Attaque SPIT

trepasser diverses méthodes de détection comme les listes noires (BlackList) et l’analyse
du contenu d’en-tête. Dans ce scénario un Back-To-Back User Agent (B2BUA) agit en
tant qu’une combinaison de User Agent Server (UAS) et de User Agent Client (UAC). Le
B2BUA rassemble et analyse chaque demande d’un dialogue. Jouant le rôle d’un SPITter,
le B2BUA peut remplacer l’information de contact de chaque message par ses propres
informations avant d’expédier le message. Le destinataire en répondant à sa demande
s’engagerait donc dans un dialogue malveillant.

2.4.1.8 Envoi des messages aux adresses de multicast

Le champ de l’en-tête via est l’un des champs d’en-tête les plus importants de SIP. En
fait, il liste l’ensemble des nœuds parcourus par le message. L’étiquette Maddr est une
propriété de ce champ qui indique une adresse de multicast. Un SPITter qui obtient une
telle adresse peut lancer des appels à un ensemble d’utilisateurs appartenant à l’adresse
de multicast.

2.4.2 Menaces dues à d’autres risques de sécurité


Dans cette partie, nous présentons les menaces SPIT qui pourraient exploiter d’autres
faiblesses de sécurité génériques.

2.4.2.1 Surveillance du trafic auprès de serveurs SIP

Le reniflage de paquets à proximité d’un serveur enregistrement ou d’un serveur proxy


est une menace qui pourrait conduire à la population d’une liste d’utilisateurs. Par
exemple, un SPITter, qui est capable de capturer et d’analyser les paquets IP, pourrait
extraire les attributs To, Via et le contact des champs d’en-tête (tels qu’ils apparaissent
dans les messages SIP). Ainsi, il peut créer une liste de destinataires pour le SPIT.

2.4.2.2 Balayage des ports connus de SIP

Une autre menace est le balayage de port. Etant donnés que tous les UAs SIP utilisent
les ports 5060 et 5061 pour les communications SIP, il est possible pour un SPITter de
lancer une série d’attaques de balayage de ports vers une adresse IP spécifique, et d’enre-
gistrer toutes les adresses qui écoutent les deux ports SIP. Par conséquent, l’établissement
d’une grande liste d’utilisateurs SIP est possible.

2.4.2.3 Exploitation des procédures de résolutions des domaines d’adresse


particuliers

Les adresses des serveurs proxy de SIP pourraient être révélées par des protocoles sup-
plémentaires tels que les requêtes DNS, l’ARP, l’RARP, etc. Ces protocoles peuvent être
vulnérables à plusieurs attaques, telles que l’usurpation d’identité, l’homme au milieu,

32
Chapitre 2 Aperçu sur l’Attaque SPIT

etc. [51][57][23]. Comme plusieurs fonctionnalités du protocole SIP dépendent de ces pro-
tocoles, on peut prétendre que SIP hérite toutes les vulnérabilités signalées.

2.5 Techniques de détection des SPIT


Dans cette partie nous présentons les techniques de base de détection de SPIT tout
en soulignant les inconvénients de chacune. Nous divisions ces méthodes en huit catégo-
ries : l’emploi des listes, le système de réputation, les tests de Turing, le paiement aux
risques, le filtrage du contenu, les cercles de confiances, les actions légales et la détection
comportementale.

2.5.0.4 Listes de filtrage

Description

Il existe trois techniques de liste [51, 49] : la technique de la liste blanche (white List),
la technique de la liste noire (black list) et la technique de la liste grise (grey list). La liste
blanche contient les contacts de chaque utilisateur. Chaque appelant de cette liste sera
accepté et tout autre utilisateur sera bloqué [58]. La liste noire ne contient que les identités
des attaquants SPITter. Tout appelant appartenant à cette liste est automatiquement
bloqué. Si un appel est initié d’un appelant inconnu (c.-à-d. il n’existe pas dans la liste
blanche), il sera automatiquement rejeté et son identité sera placé dans la liste grise.
Dans ce cas, si l’expéditeur tente de rappeler au bout d’un temps moyen, alors il sera
automatiquement bloqué. Dans un autre contexte [59], après consultation de la liste grise,
l’appelé peut décider d’accepter ou de refuser d’une façon permanente les futurs appels
de l’appelant en question.

Faiblesse

Bien que, la technique de la liste noire peut constituer un obstacle raisonnable contre
les attaquants SPITter, elle doit être utilisée d’une façon raisonnable. En effet, l’identité
revendiquée par un SPITter, ainsi que le domaine, pourrait réclamer des données fausses
ou représenter certaines informations relatives à un autre utilisateur (ou domaine). Dans
un mécanisme d’anti–SPIT, la technique utilisant la liste noire ne peut être efficace qu’avec
d’autres méthodes statistiques.
Concernant la technique de la liste blanche, elle s’avère très restrictive et inefficace si elle
est utilisée seule. En effet, supposons que l’un des anciens amis d’une personne souhaite
l’appeler. Dans ce cas, si cet ami ne figure pas dans la liste blanche de la personne en
question, il ne peut jamais le contacter.
L’inconvénient majeur de la technique de la liste grise est le blocage des appels d’urgence
des amis dont les identités n’appartiennent pas à la liste blanche. Par ailleurs, la technique
des listes est vulnérable aux attaques d’usurpation d’adresses.

33
Chapitre 2 Aperçu sur l’Attaque SPIT

2.5.0.5 Système de réputation

Description

Un exemple de système de réputation est décrit dans [49]. Après tout appel reçu, l’appelé
donne à l’appelant une valeur de réputation. Cette valeur doit être affectée à l’identité
de l’appelant pour en servir lors de l’établissement de nouvelles sessions. Ici, pour une
valeur de réputation positive, l’appelant est considéré comme légitime. Dans le cas où la
valeur de réputation est négative, l’appelant est identifié comme étant SPITter. Afin de
fournir une meilleure base de décision, la combinaison d’un système de réputation avec la
technique de la liste grise s’avère intéressante [59].

Faiblesse

Les systèmes ayant une réputation négative peuvent être contournés de la même manière
que les listes noires [59]. Ici, un appelant avec une réputation négative peut facilement
s’évader et renouveler sa valeur de réputation par le biais d’un nouveau compte.

2.5.0.6 Tests de Turing

Description

Le test de Turing a été inventé par Alan Turing en 1950 afin d’évaluer l’intelligence
d’une machine avec certitude. Il prend comme étalon l’être humain. Dans le contexte
des SPIT, les administrateurs de sécurité craignent principalement les robots. L’un des
tests de Turing possible est le CAPTCHA (Completely Automated Public Turing test
to tell Computers and Humans Apart) [60]. Il permet de distinguer entre les appelants
humains et robots. Pour ce faire, il exige à l’appelant de résoudre une énigme, facile
pour l’humain, impossible pour la machine, raison pour laquelle certains tests de Turing
s’appellent «Challenge Message». Si la réponse est satisfaisante, l’appelant est réellement
un humain et son identité sera placée automatiquement dans la liste blanche [61]. Dans
tous les autres cas (mauvaise réponse ou pas de réponse), l’appelant est un SPITter.

Faiblesse

La combinaison des tests de Turing avec la technique de la liste blanche s’avère très
efficaces pour la prévention des SPIT. Néanmoins, un SPITter peut payer des travailleurs
pour passer les tests. De plus, puisque les tests de Turing sont très interactifs, ils ont ten-
dance à exiger un degré élevé d’effort et entraîner ainsi des retards importants à l’appelant
[31].

34
Chapitre 2 Aperçu sur l’Attaque SPIT

2.5.0.7 Paiements au risque

Description

Le mécanisme de paiements au risque est utilisé afin d’exiger un paiement à l’avance


par tout appelant inconnu. Dans le cas de [59], si un utilisateur A veut appeler un autre
B, il doit d’abord envoyer une petite somme d’argent à B. Lorsque B accepte l’appel et
confirme que A n’est pas un SPITter, le montant sera retourné à A. Le paiement est exigé
aux appelants qui ne sont pas dans la liste blanche de l’appelé. Avec cette technique, il
est possible d’augmenter la somme d’argent pour les appelants SPITter qui persistaient.

Faiblesse

Le contournement du mécanisme de paiements au risque dépend principalement de la


façon dont il est mis en œuvre. Prenant par exemple la description du [59], le paiement est
seulement nécessaire pour les appelants qui ne sont pas présents dans la liste blanche de
l’appelé. Dans ce cas, un attaquant pourrait usurper une identité connue par la victime.

2.5.0.8 Filtrage du contenu

Description

Pour établir une communication entre les utilisateurs, le protocole SIP utilise des mes-
sages textuels. Un message SIP comprend généralement deux parties : l’en-tête et le
corps. Pour un appel vocal, un message (par exemple le message SIP INVITE) comporte
un en-tête et une partie SDP (Session Description Protocol). Cependant, dans le cas de
la messagerie instantanée, le message, à savoir le message SIP MESSAGE, comprend un
en-tête et un texte qui se réfère au contenu du message. Pour classer un message SIP
comme SPIT, il faut analyser l’en-tête du message ou/et le corps du message. L’en-tête
du message peut fournir des informations telles que : l’expéditeur est connu comme un
SPITter, l’expéditeur fournit des informations d’en-tête trompeuses ou l’expéditeur envoie
la demande à un grand nombre d’utilisateurs [62].
Le contenu du message peut révéler des informations liées à divers sujets tels que : les
ventes de logiciels, les offres d’assurance, des produits semi-légales de drogues, des sites
pour adulte, etc. Le classement des messages en filtrant leurs en-têtes est certainement
la meilleure façon pour détecter les SPIT. Il faut s’assurer que l’adresse de l’expéditeur
appartient à la liste noire. Le champ objet du message SIP peut être aussi analysé et
utilisé pour bloquer les SPIT.

Faiblesse

Le filtrage de contenu [63] pose un problème puisqu’il nécessite une administration


continue du système de détection. En fait, la mise-à-jour des règles est indispensable pour
détecter de nouveaux types de SPIT. Le risque d’avoir un taux de faux positifs très élevé

35
Chapitre 2 Aperçu sur l’Attaque SPIT

est un autre problème. De plus, les technologies de reconnaissance vocale de nos jours
trouvent des difficultés pour distinguer les SPIT.

2.5.0.9 Cercles de confiance

Description

Dans ce modèle, un cercle de confiance représente un groupe de domaines (par exemple,


un ensemble d’entreprises) qui se réunissent pour échanger les appels SIP sous un engage-
ment [64]. Si l’un d’entre eux est capturé comme SPITter, il doit payer une amende. De
ce fait, chaque entreprise peut sanctionner les employés SPIT à partir de leurs comptes.
Cette méthode est implémentée au niveau de SIP en utilisant le protocole TLS (Transport
Level Security) [65].

Faiblesse

Ce genre de technique ne fonctionne convenablement que pour les petits domaines ou


petits ensembles de fournisseurs. Toutefois, cette technique n’est pas certaine pour des
vastes domaines.

2.5.0.10 Action légale

Description

Sous le prétexte des lois législatives internationales, la méthode d’action légale [66]
fonctionne pour interdire la diffusion des SPIT. Dans ce cas, l’administrateur doit sauve-
garder toutes les informations pour reconstituer la preuve de l’attaque SPIT. Ce domaine
de recherche est connu sous le nom de « forensic ».

Faiblesse

Il y aura toujours des pays hors la loi. De plus, les lois sont disparates et hétérogènes.

2.5.0.11 Détection d’anomalies basées sur le comportement

Description

Afin d’identifier les appels SPIT, la méthode de détection d’anomalies basée sur le com-
portement (Signature based/Anomaly Detection) [67] analyse les comportements suspects
dans le réseau VoIP. Le principe de cette méthode est de corréler les paramètres d’un
appel (identité de l’appelant, durée d’appel,. . . ) avec les modèles statistiques [68][69] [70].
Sur la base de cette corrélation, la méthode prédit si l’appel entrant est un vrai SPIT. Il
existe également de nombreuses possibilités d’améliorer cette méthode en développant de
meilleurs algorithmes de classification [31]. Dans ce contexte, Nassar et al. [71] ont pro-
posé une méthode d’apprentissage supervisé afin de détecter les attaques sur le protocole

36
Chapitre 2 Aperçu sur l’Attaque SPIT

SIP. Wu et al. [72] ont proposé une méthode d’apprentissage semi-supervisé l’apprentis-
sage en utilisant la métrique MPCK-Means (Metric Pairwise Constrained K-Means) pour
détecter les appels SPIT.

Faiblesse

Parce que le comportement d’appel d’un appelant est associé à son numéro de télé-
phone, un spammeur pourrait usurper l’identité de l’appelant vers un numéro avec un
bon comportement d’appel. En outre, un spammeur pourrait cacher ses comportements
d’appels illégitimes en utilisant des identités multiples. Ainsi, en utilisant cette méthode de
détection, il y aura la possibilité de générer des faux positifs. Pour remédier à ce problème,
il est intéressant d’étudier des techniques d’apprentissage avec des critères d’identification
appropriés.
Dans ce contexte, nous adoptons cette méthode pour concevoir notre système de détec-
tion de SPIT. Le système proposé comprend un grand nombre de critères d’identification
des SPIT. De plus, nous utilisons des méthodes d’apprentissage supervisée pour approu-
ver la performance de notre système de point de vue sensibilité et spécificité
Dans cette section, nous avons présenté les différentes techniques de base de détection de
SPIT. Dans la suite, nous allons définir les différentes plateformes adaptant ces techniques.

2.6 Plateformes anti-SPITs


Un grand nombre de plateformes anti-SPITs ont été proposées pour remédier au pro-
blème de SPIT.

2.6.1 Prévention des SPIT avec des autorités de vérification


anonymes
Dans [73], une architecture mettant l’accent sur la prévention de SPIT par l’extension
de la procédure d’établissement d’appel est présentée. L’approche est basée sur la mise en
place d’un mécanisme ’’call-me-back” et sur l’utilisation de deux nouvelles entités dans
l’infrastructure IP, à savoir : le médiateur (the Mediator), et l’autorité de vérification
Anonyme (the Anonymous Verifying Authority). Grâce à l’échange d’informations entre
ces deux entités, l’attaque SPIT est atténuée en bloquant de manière anonyme les appels
non désirés. De cette façon, l’appelant reste inconscient de l’existence de l’appelé pour
vue que l’appel n’a pas pu être établi.

37
Chapitre 2 Aperçu sur l’Attaque SPIT

2.6.2 Mitigation des SPIT à travers une entité anti-SPIT de la


couche réseau
Mathieu et al. [74] présente une approche qui met l’accent sur la détection et la mitiga-
tion des SPITs. Cette approche utilise une entité orienté-reniflage au niveau de la couche
réseau. Cette entité capture les filtres, analyse le trafic réseau et propose des hypothèses
pour savoir si un appel est un SPIT ou non. Ces hypothèses reposent sur une liste de
critères qui contribuent avec un poids différent vers la décision finale. Enfin, en fonction
des résultats de l’analyse de SPIT, les actions de manipulation correspondantes sont ap-
pliquées. Ces actions reposent sur les politiques adoptées par le domaine où l’utilisateur
spécifique appartient, et les préférences de l’utilisateur final.

2.6.3 Détection de SPIT basée sur des techniques de réputation et


de la facturation
Rebai et al. [52] ont proposé un mécanisme de détection de SPIT qui repose sur deux
techniques différentes, à savoir la réputation (tels que les réseaux de confiance) et les
paiements au risque. La technique basée sur la réputation détecte le SPIT en prenant en
compte le montant de la confiance que le destinataire (appelé) perçoit pour l’expéditeur
(appelant).
D’autre part, la technique de la facturation vise à réduire le SPIT en augmentant les
frais d’envoi. Ceci est accompli en obligeant les expéditeurs à payer pour chaque message
envoyé. En plus des paiements au risque, la technique de la facturation intègre d’autres
méthodes anti-SPIT telles que les modules d’authentification et les listes blanches dans
le but d’être appliquée plus efficacement.

2.6.4 DAPES (Domain-based Authentication and Policy-Enforced


for SIP)
La plateforme DAPES [75] tente de déterminer en temps réel si un appel ou un mes-
sage instantané est susceptible d’être un SPIT ou non. DAPES repose sur des mécanismes
d’authentification (Digest et TLS ) en combinaison avec un système de réputation afin de
déterminer si les appels sont des SPITs. Pour que cela soit efficace, plusieurs caractéris-
tiques doivent être prises en charge par l’infrastructure. Ceci rend cette solution difficile
à adopter par les réseaux existants.

2.6.5 liste grise progressive multi-niveaux PMG (Progressive Multi


Grey-Levelling)
La liste grise progressive multi-niveaux est un mécanisme qui repose sur la technique de
la liste grise [76]. Le principe est basé sur un algorithme qui calcule et affecte un niveau de

38
Chapitre 2 Aperçu sur l’Attaque SPIT

gris pour chaque appelant. Le niveau de gris correspond à la probabilité qu’un utilisateur
soit un SPITter. A travers cette valeur, le PMG décide si un appel doit être établi ou non.
La nouveauté de l’algorithme apparaît dans le fait que les niveaux de gris sont calculés
en se basant sur des modèles d’appels passés par un appelant particulier plutôt que sur
la confiance entre les utilisateurs.

2.6.6 Plateforme biométrique pour la prévention des SPITs


Plusieurs mécanismes proposés tentent d’aborder le problème de SPIT à travers la
gestion des identités. Cela provient du fait que dans le contexte d’email, l’une des façons
les plus courantes des spammeurs est le changement fréquent de ses identités.
Dans le cadre de la plateforme biométrique [77], les auteurs proposent l’utilisation de
serveurs mondiaux qui lient les identités des utilisateurs aux données personnelles (à sa-
voir, les données biométriques) tels que la voix d’une personne. Pour que cette plateforme
soit opérationnelle, une infrastructure PKI constitue une condition préalable afin de mon-
dialiser le mécanisme d’authentification.

2.6.7 RFC 4474


Une autre proposition qui s’appuie sur l’approche de gestion des identités est discutée
dans la RFC 4474 [78]. Dans cette plateforme, une tentative est réalisée pour résoudre
le problème d’authentification de l’utilisateur final en combinant l’infrastructure à clé
publique (PKI) avec les autorités de certification (CA). En outre, le RFC introduit deux
nouveaux champs d’en-tête SIP afin d’atteindre ses objectifs initiaux. Bien que cette
approche n’est spécifiquement orientée vers le traitement des SPIT, le mécanisme de
contrôle d’identité est utile pour contrôler le SPIT. Ainsi, même si les auteurs [78] ne
mentionnent pas explicitement que leur proposition pourrait être utilisée dans la gestion
de SPIT, le concept de gestion de l’identité pourrait être intégré dans le cadre de la
lutte contre les SPIT génériques. En effet, l’ajout de deux champs d’en-tête SIP appelés
« Identity » et « Identity info », permet au serveur proxy coté appelant d’appliquer une
forte authentification sur les expéditeurs. Ceci permet donc de compliquer l’infiltration
du SPIT dans le réseau.

2.6.8 SIP SAML


L’approche SAML (Security Assertion Markup Language) est utilisé pour l’expression
des assertions de sécurité, telles que l’authentification, l’appartenance au rôle ou l’autori-
sation.
Dans [79], une autre approche pour l’authentification des utilisateurs est proposée. Cette
approche introduit l’utilisation de SAML pour l’authentification SIP et l’autorisation

39
Chapitre 2 Aperçu sur l’Attaque SPIT

par des caractéristiques affirmées. Les auteurs tentent d’empêcher l’adresse fréquemment
changée par les SPITters grâce à un contrôle d’identité.

2.6.9 DSIP
L’approche DSIP (Differentiated SIP) étend le protocole SIP à vue d’œil vers la classi-
fication des utilisateurs [80]. DSIP marque l’utilisation et l’implémentation des listes de
couleurs à partir du contexte de courrier électronique (à savoir, les listes noires, listes
blanches, listes grises). En outre, DSIP intègre des tests de vérification des droits pour les
utilisateurs sans antécédents historiques afin de décider si la demande est faite par une
machine de SPIT ou un être humain.

2.6.10 Voice spam detector


La plateforme VSD (Voice spam detector) [81] combine une variété de techniques de
détection des SPITs dans le but d’implémenter un modèle multicouche d’anti-SPIT.
Les principaux éléments composant le système VSD sont les suivants :
— Le filtrage (par exemple, si un appelant est dans un état ” occupé ” alors elle pourrait
ne pas accepter un appel entrant ou un message),
— La limitation du débit (le taux des appels entrants initialisés par un appelant spé-
cifique ou un domaine SIP est contrôlé par rapport aux seuils de taux entrants
prédéfinis autorisés),
— Les listes blanches/noires (l’utilisation du filtrage des listes blanches/noires),
— L’apprentissage bayésien (vérifier le comportement potentiel de SPIT associé à l’une
des entités participantes par la recherche d’informations de confiance disponible pour
ces entités),
— Les réseaux sociaux et la réputation (les réseaux sociaux sont utilisés pour repré-
senter les relations de l’utilisateur avec ses voisins de confiance à partir desquelles
l’utilisateur est prêt à recevoir des appels).

2.6.11 VoIP SEAL


VoIP SEAL (VoIP Secure Application Level firewall) est un prototype qui vise à lutter
contre les attaques SPIT d’une façon efficace [66]. La caractéristique principale de VoIP
SEAL est sa structure modulaire qui peut conduire à une gestion efficace des nouvelles
attaques de SPIT tout en mettant à jour les modules existants avec des nouveaux. De
plus, la modularité du système assure la personnalisation flexible et facile des systèmes
et des applications pour répondre aux besoins de divers matériels. Le concept spécifique
dans la référence [66] introduit initialement deux étapes :
— La première étape comprend les modules ” invisible ”,
— La seconde étape comprend les modèles les plus intéressants.

40
Chapitre 2 Aperçu sur l’Attaque SPIT

Les modules de la première étape calculent certains scores pour savoir si l’appel peut passer
aux modules de la deuxième étape ou non. Cette dernière implémente généralement les
tests de Turing.

2.6.12 Tests de Turing cachés


Cette technique est basée sur les modes de communication humaines (par exemple, les
pauses entre les conversations, etc.). Il peut être utilisé après l’établissement de la com-
munication pour distinguer entre les appels humains et les automates [82]. Le Challenge-
response est une méthode de test de Turing.

2.7 Discussion
D’après l’étude des différentes techniques et plateformes anit-SPIT, nous pouvons conclure
que le traitement de SPIT peut être effectué en deux phases différentes : La première
concerne la phase de signalisation dans laquelle nous pouvons extraire des informations
multiples. La deuxième s’effectue après l’établissement de l’appel et comprend le filtrage
de contenu, l’interaction avec l’appelant / l’appelé et la détection d’activité vocale.
Ces plateformes et techniques anti-SPIT doivent répondre à un certain nombre de
conditions pour être efficaces et utiles. Une condition exige que les techniques de protection
doivent identifier le SPIT avant que le téléphone de l’utilisateur sonne. Une autre exigence
se manifeste dans l’impossibilité de contourner une mesure de sécurité par les SPITters. En
effet, chaque technique de protection anti-spam sera inefficace si les spammeurs deviennent
capable de contourner une contremesure. Ainsi, une bonne technique de protection anti-
spam doit donc être à la fois efficace et difficile à contourner. Enfin, le nombre de faux
positifs et de faux négatifs devrait être aussi faible que possible, de préférence, voire nulle.
En conclusion, en se basant sur ces différentes conditions et pour vue que toutes les
techniques de protections citées précédemment présentent des faiblesses à l’égard de ces
dernières, nous proposons d’implémenter une méthode de détection de SPIT moyennant
une approche comportementale. Cette méthode a pour but de respecter strictement les
conditions déjà citées et principalement le nombre de faux positifs et de faux négatifs.
Notre contribution se manifeste principalement dans : le nombre de critères d’identifica-
tion de SPIT utilisés, l’étude des caractéristiques des différents critères et le développement
d’une solution qui garantit la meilleur détection des SPITs de point de vue sensibilité et
spécificité en se basant sur des méthodes d’apprentissage. Notre solution exploite une
combinaison de techniques et de critères d’identification qui sont illustrés dans le tableau
2.3. Ce dernier met en relief l’apport de notre solution par rapport à quelques solutions
existantes.

41
Chapitre 2 Aperçu sur l’Attaque SPIT

Technique P1 P2 P3 P4 P5 P6 P7
Listes de filtrage × × × ×
Système de réputation ×
Test de Turing ×
Détection d’anomalies basées sur le × × × ×
comportement
Fenêtre glissante ×
Classeur Boosting et Bagging ×
Critère d’identification P1 P2 P3 P4 P5 P6 P7
Pourcentage d’Appel Répondus ×
× × ×
Pourcentage d’Appels Refusés
×
Pourcentage d’Appels avec des UAs
Invalides
× × ×
Nombre de Tentatives
× × × × ×
Variance de la Durée d’Appel
×
Variance de la Durée d’Inter-Appel
×
Nombre de Destinataires
×
Variance du Temps de Silence
× ×
Variance de la Durée de Conversation

P1: Nassar et al.[71] P5: Quittek et al.[82]


P2: Wu et al.[72] P6: Kusumoto et al.[83]
P3: Mathieu et al.[84] P7: Solution proposée
P4: Balasubramaniyan et al.[85]

Table 2.3 – Techniques et critères d’identification de la solution proposée par rapport à


quelques solutions existantes.

2.8 Conclusion
Le SPIT s’avère de plus en plus ennuyant pour l’utilisateur de la VoIP. Ainsi, l’analyse
détaillée de cette attaque engendre la proposition des solutions les plus efficaces pour
le contrer. Dans ce chapitre nous avons mené une étude détaillée sur la menace SPIT.
Nous avons spécifié les différentes techniques et plateformes anti-SPIT. Nous avons prouvé
que ces techniques restent limitées en termes de sensibilité et de spécificité. Ainsi, pour
résoudre ce problème, nous proposons de concevoir une approche de détection des SPIT
moyennant une approche comportementale. Cette approche repose principalement sur une
combinaison d’un grand nombre de techniques et de critères d’identification.
Dans le chapitre suivant nous exposons l’approche proposée.

42
Chapitre 3

Approche Comportementale pour la


Détection de SPIT

3.1 Introduction
Le SPIT est devenu un problème très grave parallèlement au progrès de l’utilisation de
la VoIP. Ce type de spam est apprécié par les spammeurs en raison de son efficacité et son
coût faible. De nombreuses solutions anti-SPIT sont appliquées pour résoudre ce problème,
mais elles sont encore limitées dans certains cas tels que le nombre élevé des faux positifs
et des faux négatifs. Afin de résoudre ces limites, nous présentons dans ce chapitre notre
approche qui consiste à concevoir un système anti-SPIT moyennant l’utilisation d’une
approche comportementale. Cette approche est basée sur les différents critères d’identifi-
cation de SPIT et les techniques d’apprentissage utilisées pour différencier entre un UA
légitime et un SPITter.
Le reste de ce chapitre est organisé comme suit : dans la Section 3.2, nous présentons
l’algorithme de la détection de SPIT utilisé pour déterminer les critères les plus influents.
Dans la Section 3.3, nous décrivons l’approche comportementale proposée pour la détec-
tion des attaquants SPITter. Tout d’abord nous présentons la plateforme de simulation.
Ensuite, nous expliquons les métriques d’évaluation des performances d’un classeur des
UA. Après, nous illustrons les différents classeurs utilisés pour détecter les SPITs. Enfin,
la Section 3.7 conclut ce chapitre.

3.2 Algorithme de détection de SPIT


Nous proposons dans cette section un algorithme de détection de SPIT basé sur le
comportement de l’utilisateur. Le principe de cet algorithme est de comparer les critères
d’identification de SPIT tels que (la durée de l’appel, le nombre des appels rejetés. . . )
avec des seuils prédéfinis. Suite à cette comparaison nous pouvons estimer si l’appelant
est un utilisateur légitime ou un SPITter. L’objectif de cet algorithme est de détecter

43
Chapitre 3 Approche Comportementale pour la Détection de SPIT

les utilisateurs SPITters d’une part et les paramètres les plus influents pour la détection
d’autre part.

3.2.1 Critères d’identification de SPIT


Dans cette sous-section, une liste de critères d’identification de SPIT est analysée. Ces
critères peuvent être appliqués en tant que règles de détection de SPIT. Nous proposons
deux catégories génériques de critères d’identification de SPIT :
— Critères du message SIP : Il s’agit de critères qui sont liés aux attributs des messages
SIP.
— Critères de l’UA SIP : Ce sont des tests liés aux attributs d’un UA SIP utiles
pour examiner l’origine de l’appel ou du message ainsi que les relations entre les
correspondants SIP.

3.2.1.1 Critères du message SIP

Ces critères analysent des motifs ou des caractéristiques spécifiques d’appels ou de


messages SIP, afin de déterminer s’ils s’agissent d’une activité SPIT [86].
— Chemin parcouru : Un appel ou un message VOIP peut emprunter un chemin avec
beaucoup d’intermédiaires avant d’atteindre sa destination définitive. Ce chemin est
inscrit dans le champ d’en-têtes via. Ainsi, si dans ce champ un domaine de SPIT
est identifié, l’appel ou le message peut être un SPIT.
— Nombre d’appels ou de messages envoyés durant un délai précis : Nous analysons
le nombre d’appels (ou de messages) établis durant une période du temps fixe par
le même utilisateur. Si ce nombre dépasse un seuil prédéfini alors les appels (ou les
messages) sont considérés comme étant une activité possible de SPIT.
— Durée d’appel statique : Si les appels lancés par un utilisateur simple ont une durée
statique, alors l’utilisateur est un SPITter. Il est possible qu’il utilise un dispositif
automatisé afin de lancer les appels.
— Motifs des adresses destination : Si les adresses des récepteurs suivent un motif
spécifique (par exemple, adresses URI qui suit un ordre alphabétique), alors l’appel
(message) est marqué en tant que SPIT.
— Faible pourcentage d’appels répondus/composés : Nous analysons le nombre des ap-
pels réussis durant une période de temps fixe. Si ce nombre est relativement faible
alors l’appelant est un SPITter.
— Grand nombre des erreurs : Lorsqu’un utilisateur envoie un grand nombre de mes-
sages INVITE et que le serveur SIP retourne plusieurs messages d’erreur (par
exemple, 404 Not Found), alors c’est un signe d’une attaque SPIT.
— Taille des messages de SIP : Dans ce cas, un ensemble de messages SIP envoyés
par un utilisateur est analysé. Si ces messages ont une taille spécifique alors il est
fort possible qu’ils soient envoyés par un logiciel de « bot », ce qu’implique que

44
Chapitre 3 Approche Comportementale pour la Détection de SPIT

l’appelant est un SPITter.

3.2.1.2 Critères du UA SIP

Ces critères examinent les caractéristiques d’une session SIP à savoir les adresses de
l’appelant et de l’appelé (sous forme d’URI ou d’une adresse IP) ainsi que le domaine
d’origine de la session VoIP. Ces critères peuvent être utilisés dans des opérations de
filtrage par une liste blanche (whitelist) ou une liste noire (blacklist).
— URI de l’expéditeur : nous inspectons l’URI de l’expéditeur d’un appel ou d’un
message, afin de déterminer s’il est un SPITter.
— Adresse IP de l’expéditeur : nous analysons l’adresse IP de l’expéditeur afin d’iden-
tifier les attaquants SPITter.
— Domaine de l’expéditeur : ce critère inspecte le domaine de l’expéditeur (via son
URI ou une requête DNS inverse de son adresse IP). Si le domaine est connu comme
une source de SPIT, alors l’expéditeur est un SPITter.
— Relation appelant et appelé : on cherche des relations de confiance entre l’appelant
et l’appelé. La relation de confiance peut être déduite si l’appelant existe dans le
carnet d’adresse de l’appelé, des appels antérieurs ont été établies, ou inversement
l’appelant est marqué comme SPITter par l’appelé.

3.2.2 Description de l’algorithme de détection


Dans cette sous-section nous proposons l’Algorithme 3.1 de détection de SPIT. Cet
algorithme repose sur les critères d’identification ci-dessus. En outre, il utilise les structures
de données suivantes dont les paramètres sont calculés à chaque période de temps T :
— UA(Id_UA, Nb_tentative, Nb_appel_réussit, Nb_appel_échoué, List_UA _Con-
fiance, List_appel, Nb_dest, Score),
— Appel(Id_appelant, Id_appelé, Durée, Temps_Silence, Cause_échec, Nb _occupé).
Parmi les paramètres utilisés, nous décrivons :
— List_UA_Confiance : C’est la liste d’utilisateurs de confiance rempli par chaque
UA. Cette liste est utile afin d’ignorer les comportements douteux et ainsi réduire
le nombre de faux positifs.
— List_appel : C’est la liste des tentatives d’appel effectuées par le UA courant.
— Nb_det : Nombre des appelés connectés avec le UA actuel.
— Nb_occupé : Nombre de réponses « occupé » envoyées par le serveur proxy pour le
UA courant.
— Score : Compteur indiquant si l’utilisateur actuel est un éventuel SPITter.
— Nb_tentative : Nombre de tentatives d’appel initié par le UA courant.
— Cause_échec : Une énumération des causes possibles pour un appel échoué. Il peut
prendre les valeurs : occupé, non trouvé, mauvaise demande, adresse incomplète,
etc.

45
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Algorithm 3.1 Détection_de_SPIT


Données
X: Utilisateur Courant
Début
Pour chaque periode T Faire
Pour chaque appel C dans X.call_list Faire
Let Y= match(C.Iddest )
******test 1******
Si(X.Id∈Y.List_UA_Confiance)Alors
/
Si(C.Nbe >thr1)and(C.Nboccupé /C.Nbe <thr2) Alors
X.Score=X.Score+1;
Fin Si
Fin Si
Fin Faire
******test 2******
Si(X.Nbt >thr3)and(X.Nbdest / X.Nbtot >thr4) Alors
X.Score=X.Score+1;
Fin Si
******test 3******
Si(X.Nbe /X.Nbtot > thr5)Alors
X.Score=X.Score+1;
Fin Si
******test 4******
Si(Variance(X.List_appel.durée)<ε) and (X.Nbr >thr6)Alors
X.Score=X.Score+1;
Fin Si
******test 5******
Si(Variance(X.List_appel.Temps_Silence)<ε) and (X.Nbs >thr7)Alors
X.Score=X.Score+1;
Fin Si
******test 6******
Si (X.Score>thr8) Alors
fill_in_blacklist(X.id_UA);
Fin Faire
Fin Detection_de_SPIT

Nous utilisons les notations suivantes dans l’algorithme de détection : Nb_tentative


=Nbt ; Nb_appel_réussit=Nbr ; Nb_appel_échoué= Nbe ; Nd_dest=Nbdest ; Id _destina-
tion=Iddest ; Nbtot =Nbr +Nbe ; Nb_occupé= Nboccupé
L’algorithme est appliqué à chaque appelant (désigné par X). Dans cet algorithme, nous
comparons les critères d’identification à des seuils prédéfinis. Suite à ces comparaisons,
nous décidons si l’appel est normal ou SPIT.
Durant cet algorithme, nous effectuons six tests: Dans le test 1, pour chaque appel, nous
vérifions si l’appelant appartient à la liste de confiance de l’appelé. Dans le cas contraire,
nous examinons si le nombre d’appels échoué à cet appelé est important (> thr1) et si le
taux d’appels rejetés en raison de l’état occupé est petit (<thr2). Si ces deux conditions
sont remplies, nous incrémentons le score de la pénalité de l’utilisateur. Dans le test 2,

46
Chapitre 3 Approche Comportementale pour la Détection de SPIT

nous nous assurons que le nombre de tentatives d’appel initié par l’appelant est significatif
(> Thr3). En outre, nous avons calculé le taux d’appels. S’il est supérieur à Thr4, nous
incrémentons le score de la pénalité. Dans le test3, nous observons le nombre d’appels
échoué. Si la valeur dépasse Thr5, nous incrémentons le score de la pénalité. Test 4 et
Test 5 évaluent respectivement la variation de la durée des appels et la durée de la période
de silence. Si ces valeurs sont plus petites que ε , nous augmentons le score de la pénalité.
Enfin, nous comparons le score de l’appelant avec Thr8. S’il est supérieur à cette valeur,
alors l’appelant est considéré comme un SPITter et il est inclu ainsi dans la liste noire.

3.2.3 Résultats et simulations


Nous avons employé le simulateur Opnet version 14.5 afin de valider l’algorithme de
détection de SPIT. Nous avons choisi SIP comme protocole de signalisation pour notre
modèle de communication VoIP. En outre, nous avons appliqué l’algorithme de détection
de SPIT. Dans ce cas, nous avons configuré 22 stations comme des appelants normals,
20 stations comme des appelants SPITters, 8 stations comme des appelés et 1 station en
tant que serveur proxy. Nous notons que la phase de détection est réalisée côté appelé.
Les stations qui jouent le rôle de SPITter peuvent révéler un ou plusieurs comporte-
ments étranges simultanément. En fait, un SPITter initie des appels réguliers ou/et
fréquents. La durée de l’appel et la période de silence sont presque constantes pour
certains SPITter (réellement, ça peut être un message d’enregistrement de la voix). En
outre, l’identification des appelés dans une liste peut suivre un schéma logique. Cette liste
s’appelle la liste d’identification des appelés. Nous avons exercé ces comportements sur
20 stations choisies arbitrairement. Chaque station est configuré selon certains critères
(par exemple : durée statique d’appel, grand nombre de tentatives ou /et grand nom-
bre d’appels échoués etc. . . ). Dans ce travail, notre objectif est d’identifier les machines
SPITter en utilisant notre algorithme de détection. Autrement, nous avons déterminé la
rapidité de détection et les critères les plus significatifs afin de découvrir les vrais messages
SPIT. L’étude proposée présente deux phases : l’analyse et la détection. Dans la première
phase, nous avons analysé le comportement de chaque utilisateur et nous avons marqué
les critères significatifs dans les fichiers traces. Ensuite, nous avons utilisé ces fichiers pour
effectuer les calculs décrits dans l’algorithme de détection.
Les seuils sont fixés de manière appropriée lors de l’analyse des appels grâce à des simu-
lations intensives. En effet, au début des expérimentations, nous avons varié les valeurs
des seuils d’une façon arbitraire en observant les résultats de la détection à chaque fois.
En se basant sur le principe de la simulation de Monte Carlo, après 250 itérations et à
partir de certaines valeurs de seuil, nous avons pu avoir un système offrant une meilleure
détection des SPITters. De ce fait, les valeurs de seuil sont: thr1 = 5, thr2 = 0,4, Thr3 =
7, Thr4 = 0,5, Thr5 = 0,5, Thr6= 3, Thr7 = 3 et Thr8 = 1 (pour un seul test activé dans
l’algorithme sinon thr8 = 3). Selon la valeur de seuil Thr8, nous notons que la détection

47
Chapitre 3 Approche Comportementale pour la Détection de SPIT

des appels SPIT peut être réalisée en utilisant un ou plusieurs tests.


La Figure 3.2.1 représente une étude comparative entre un appelant normal et un SPITter
exerçant un nombre de tentatives d’appels.

Objet: SPITter
Objet: Utilisateur légitime
SIP UAC. Tentatives d'appels

Figure 3.2.1 – Nombre d’appels initiés par un utilisateur normal et un SPITter

D’après cette figure, le nombre d’appels initiés du SPITter éventuel est énorme par
rapport à un utilisateur normal. En effet, durant 12 min, un utilisateur normal a lancé
un seul appel, alors qu’un SPITter a lancé 4 appels avec 3 tentatives par appel. Ces
résultats nous permettent de connaître le profil de SPITter et d’appliquer l’algorithme de
détection. Aussi, cette figure montre que le nombre d’appels initiés du SPITter éventuel
est énorme par rapport à un utilisateur normal. En effet, durant 12 min, un utilisateur
normal a lancé un seul appel, alors qu’un SPITter a lancé 4 appels avec 3 tentatives par
appel. Ces résultats nous permettent de connaître le profil de SPITter et d’appliquer
l’algorithme de détection.
La détection de SPITters est réalisée selon quatre méthodes:
— Dans la première méthode, nous avons appliqué seulement le test 4 de l’algorithme
de détection en prenant en considération le critère de la durée d’appel.
— Dans la seconde méthode, nous avons appliqué seulement le test 3, qui prend en
considération le critère d’appel échoué.
— Dans la troisième méthode, nous avons appliqué seulement le test 2, qui prend en
considération le critère du nombre de tentatives.
— Enfin, dans la dernière méthode, nous avons appliqué tous les tests. La Figure 3.2.2
montre qu’après un certain nombre d’appels, tous les SPITters ont été détectés.
Nous notons que le test 4 permet une détection rapide de tous les SPITters. En
48
Chapitre 3 Approche Comportementale pour la Détection de SPIT

100

90

80
% de SPIT détectées

70

60

50

40

30
Listebnoirebavecbtousblesbparamètres
20 Listebnoirebavecblabduréebd'appel
10 Listebnoirebavecbdesbappelsbéchoué
Listebnoirebavecblebnombrebdebtentatives
0
100 200 300 400 500 600 700 800
Nombre d'appels
Nomn

Figure 3.2.2 – La détection du SPIT

effet, dans ce test, après une réalisation de 280 appels, 100% des SPITters sont
détectés. De l’autre côté, le test 2 et le test 3, respectivement, nécessite 550 et 760
tentatives d’appels. Nous pouvons noter que la courbe englobant tous les tests est
très similaire à la courbe du test de la durée d’appel. Nous pouvons conclure alors
que le critère de la durée d’appel est trop significatif pour la détection rapide des
SPITters.
Cet algorithme reste limité si nous considérons le pourcentage de faux positif et faux
négatif. En effet, le traitement individuel de chaque critère d’identification peut provoquer
un problème de faux positif et faux négatif. De même pour l’utilisation de la liste noire.
Aussi, un SPITter peut utiliser le spoofing pour s’échapper de la détection. Ainsi, nous
allons proposer une approche comportementale basée sur les méthodes d’apprentissage
pour remédier à ce problème.

3.3 Approche comportementale


Pour la détection des attaquants SPITter dans un réseau VoIP, notre contribution
consiste à proposer un système Anti-SPIT en utilisant une approche comportementale.
Le système proposé fonctionne selon deux phases : la première concerne la collecte des
critères d’identification (déjà étudiés dans l’algorithme de détection) de tous les UA, la
deuxième permet le classement des UA (Attaquants SPITter ou légitimes).
En se basant sur les critères cités dans la section précédente, nous avons sélectionné
neuf critères pour détecter les attaques de type SPIT.
Le Tableau 3.1 récapitule ces critères.

49
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Critère Abréviation
Pourcentage d’Appels Répondus % ARep
Pourcentage d’Appels Refusés % ARef
Pourcentage d’Appels avec des UAs Invalides (response % AI
NOT FOUND)
% ARep + %ARef + % AI = 100 %
Nombre de Tentatives NT
Variance de la Durée d’Appel VDA
Variance de la Durée d’Inter-Appel VDIA
Nombre de Destinataires ND
Variance du Temps de Silence VTS
Variance de la Durée de Conversation VDC

Table 3.1 – Critères d’identification des attaquants SPITter.

Durant la première phase, la collecte des traces réseau de la signalisation et de l’activité


vocale pour tout UA est illustrée par la Figure 3.3.1.

UA

Initiation d'appel

Collecte d'@ URI

Oui Non
@ Appelé invalide?

@ URI ∈ BlackList? Non


Oui et
@ URI ∈ TrustList_Appelé?

Rejet d'appel Oui Non


Acceptation d'appel?

Fin
Conversation RTP

Terminaison d'appel

Collecte des traces


réseau de la signalisation
et de l'activité vocale

Fin

Figure 3.3.1 – Collecte des traces réseau de la signalisation et de l’activité vocale pour
tout UA.

50
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Au départ, pour chaque initiation d’appel par un UA vers un ou plusieurs appelés, le


système proposé collecte l’adresse URI de l’appelant et le(s) adresse(s) de(s) appelé(s).
Dans le cas où l’adresse de l’appelé est valide, le système proposé vérifie l’adresse de
l’appelant. Si cette dernière est à la fois localisée dans la liste noire (BlackList) du serveur
proxy et non incluse dans la liste de confiance (TrustList) des appelés alors l’appel est
automatiquement rejeté. Dans le cas contraire, le système vérifie la réponse de l’appelé.
Dans le cas où il s’agit d’une acceptation, le système donne lieu à une conversation RTP.
Ainsi, la collecte des traces réseau de la signalisation et de l’activité vocale se déclenche
suite à une conversation finalisée. Le scénario d’appel peut s’achever prématurément avec,
une réponse de refus de l’appelé ou une réponse NOT-FOUND du serveur proxy (adresse
de l’appelé est invalide).
Par la suite, les traces de la signalisation et de l’activité vocale inter-UA doivent être
collectées et traitées pour la détection des attaquants SPITter. Le Tableau 3.2 illustre les
paramètres des traces réseau qu’on doit récupérer.

Paramètre Abréviation
Identifiant d’Appel ID_Appel
Adresse d’appelant @Appelant
Adresse d’appelé @Appelé
Succès d’Appel SA ∈ {0, 1}
Refus d’Appel RA ∈ {0, 1}
Appelé Invalide AI ∈ {0, 1}
Durée d’Appel DA
Initiation d’Appel IA
Fin de Conversation FC
Temps de Silence TS
Durée de Conversation DC

Table 3.2 – Paramètres de traces réseau de la signalisation et de l’activité vocale.

Comme la suite des flux de données de communication est potentiellement infinie, son
stockage dans son intégralité est impossible. De ce fait, nous appliquons le concept de la
fenêtre glissante (Sliding windows). Le rôle de cette fenêtre est de maintenir un flux de
données sous forme d’un ensemble fini de données. Le principe de fonctionnement de cette
fenêtre est illustré par l’exemple de la Figure 3.3.2.

Flux de données

T1
T2
T3
T4
t
}

0 p T 2T 3T

Figure 3.3.2 – Fenêtre glissante.

51
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Chaque période T est subdivisée en un ensemble de p « pas ». Dans l’exemple de la


figure 3.3.2, quatre pas représentent une période. Au départ, la stratégie de la fenêtre
glissante concatène les pas (pas par pas) sur une période T1 . Par la suite, chaque passage
d’une durée Ti à une autre Ti+1 est marqué par l’effacement du premier pas de Ti qui sera
remplacé par un nouveau pas.
Pour le déploiement du système de détection des attaquants SPITter, nous proposons
l’Algorithme 3.2.

Algorithme 3.2 Fonctionnement du système de détection des attaquants SPITter.

Ici, chaque extraction relative à un pas est sauvegardée dans le fichier « trace » cor-
respondant (c.-à-d. le principe de la fenêtre glissante). A la fin de chaque période Ti ,
nous procédons à la concaténation des fichiers traces des pas correspondant pour pouvoir
extraire les critères d’identification de tous les UAs.
Il est important de dédier un processus léger (Thread) à part pour la phase de classe-
52
Chapitre 3 Approche Comportementale pour la Détection de SPIT

ment. Ceci nous permet de poursuivre la collecte des traces de signalisation et de l’activité
vocale durant les opérations d’apprentissage et de classement. Ces données seront utiles
pour les prochaines fenêtres de détection.
La Figure 3.3.3 représente le déroulement de l’extraction des critères d’identification
des attaquants SPITter.

Traces réseau de la signalisation Traces réseau de la signalisation


et de l'activité vocale et de l'activité vocale du
du pas (1) pas (T mod pas)

Concaténation des traces


réseau de la signalisation
et de l'activité vocale

Extraction des critères


d'identification des attaquants
SPITter

Figure 3.3.3 – Extraction des critères d’identification des attaquants SPITter.

Nous analysons ensuite cet ensemble de données par divers classeurs. Nous avons choisi
d’étudier la classification supervisée à travers les méthodes suivantes : NaiveBayes, Bayes-
Net, SMO RBFKernel, SMO PolyKernel, MultiLayerPerceptron 2 couches et 3 couches,
NBTree, J48, Bagging et AdaBoostM1 (Voir annexe). Le choix de ces méthodes est ap-
prouvé par plusieurs travaux sur la détection d’intrusion dans la VoIP et dans le domaine
de la sécurité en générale. Ces travaux ont montré l’efficacité de ces méthodes à résoudre
les problématiques évoqués dans le domaine concerné. Par exemple, dans [87], une ap-
proche d’apprentissage automatique est proposée afin d’identifier les robots Botnet. Ici,
les auteurs ont appliqué les algorithmes traditionnels de classification pour détecter les
comportements suspects de spam Bot. Comme résultat, ils ont montré que le classifieur
bayésien a une meilleure performance globale de détection. Aussi, Nassar et al. [71] ont
proposé une nouvelle approche de surveillance en ligne basée sur la méthode SVM pour
distinguer entre les attaques et les activités normales au niveau de protocole SIP de la
VoIP. Les résultats ont montré une véritable performance en termes de précison et de
temps de détection des attaques DOS et SPIT et plus particulièrement lorsque la détec-
tion est couplée avec des règles de corrélation d’événements efficaces.
D’autres travaux comme [88], ont mené une étude comparative de plusieurs méthodes
d’apprentissage telles que le J48, les forêts aléatoires et les arbres aléatoires pour approuver
leurs efficacité de point de vue spécificité et sensitivité dans le domaine de détection
d’intrusion. Dans ce travail, les auteurs ont montré une grande performance des arbres
aléatoires. Enfin, les auteurs dans [89] ont mené une étude sur les méthodes de détection
d’intrusion moyennant les techniques d’apprentissage. Ils ont examiné 55 études connexes

53
Chapitre 3 Approche Comportementale pour la Détection de SPIT

dans la période entre 2000 et 2007 en mettant l’accent sur le développement d’un grand
nombre de classifieurs. Les auteurs ont montré à la fin les avantages et les limites de
chaque méthode d’apprentissage pour développer un système de détection d’intrusion.
Dans notre travail, les classes sont préalablement connues (données d’apprentissage
étiquetées). La Figure 3.3.4 présente le mécanisme de ce classement. En effet, le classement
des UA comporte deux phases. La première phase concerne l’apprentissage, elle consiste à
construire un classeur à partir d’une base de données d’apprentissage. La deuxième phase
consiste à prédire la classe de chaque UA en se basant sur le classeur déjà construit. Il
s’agit de la phase de classement. Enfin, à la détection d’un nouvel attaquant SPITter, le
système met à jour la liste noire (BlackList). Dans la suite, nous décrivons la plateforme
de simulation.

Début

Critères d'identification
des attaquants SPITters

Apprentissage Classement

Base de données Oui Non


SPITters?
d'apprentissage

Fin
Classification supervisée

Ajout dans la liste noire

Fin

Figure 3.3.4 – Classification supervisée.

3.4 Plateforme de simulation


Afin d’évaluer le système proposé, nous avons choisi l’environnement OPNET Modeler
14.5 pour l’extraction des traces réseaux de la signalisation et de l’activité vocale. Nous
avons également choisi le logiciel de fouille de données Weka pour le classement (voir
description dans l’annexe). Dans ce qui suit, nous allons décrire la phase de la collecte des
critères d’identification sous OPNET et la phase de classification sous Weka.

54
Chapitre 3 Approche Comportementale pour la Détection de SPIT

3.4.1 Collecte des critères d’identification des SPITter sous OPNET


3.4.1.1 Architecture proposée

Au niveau réseau (voir annexe), nous avons déployé la topologie de réseau VoIP repré-
sentée par la figure 3.4.1. Elle est composée des stations (Appelant/Appelé), des commuta-
teurs, des routeurs et un serveur proxy. Ainsi, nous concevons un réseau VoIP composé de
32 appelés et de 96 appelants dont 52, respectivement 44, sont des UA légitimes, respecti-
vement des UA SPITters. La configuration de ces stations est décrite dans le paragraphe
3.4.1.2. Les stations sont réparties géographiquement sur 4 régions. La communication
inter-UA est assurée via un serveur proxy qui se charge du routage de toute session SIP.

IP
Internet

Serveur
proxy

Appelant légitime
Switcheur
Appelant SPITter
Routeur
Appelé

Figure 3.4.1 – Topologie utilisée dans la simulation.

Afin de générer les fichiers de traces réseaux de la signalisation et l’activité vocale,


nous exploitons les processus SIP_UAC et gna_voice_called_mgr de l’environnement
OPNET.

55
Chapitre 3 Approche Comportementale pour la Détection de SPIT

3.4.1.2 Configuration du réseau déployée

Les paramètres de configuration des stations sont décrits dans le Tableau 3.3.

Paramètre Valeur
Adresse de station (Client Address) : AS unique
Destination (Destination Preferences) : DP liste
Adresse de Serveur Proxy (Proxy Server @ proxy
Address) : ASP
Nombre de Répétition d’Appel (Number of N RA ∈ {cst, exp(α)}
Repetition) : NRA
Durée d’Appel (Duration(seconds)) : DA DA ∈ {cst, exp(α)}
Durée d’Inter-Appel (Inter-Repetition DIA ∈ {cst, exp(α)}
(seconds)) : DIA
Durée de Silence (Silence length (seconds)) : DS DS ∈ {cst, exp(α)}
Durée de Conversation (Talk length (seconds)) : DC ∈ {cst, exp(α)}
DC

Table 3.3 – Paramètres de configuration des stations.

Afin de différencier entre les comportements des UA SPITter et des UA légitimes, nous
avons fixé les valeurs de N RA, DA, DIA, DS et DC. Ces valeurs doivent être distribuées
d’une façon exponentielle ou constante. Par la suite, nous avons recueilli les paramètres
des traces de réseau pour tous les appels présentés dans le Tableau 3.2 et donc extraire
les critères d’identification de SPIT mentionnés dans le Tableau 3.1.

3.4.2 Classement
La construction de la base de données d’apprentissage est effectuée en définissant des
seuils de discrimination (Threshold). Les valeurs de ces seuils sont déterminées en ef-
fectuant des simulations intensives ou en utilisant la courbe ROC (Voir la sous section
3.5). Pour distinguer entre les différents UA (légitime ou Spitter), nous avons associé les
seuilsthrj au critères crj (j = 1...9) respectivement. Ces critères (crj , j = 1...9) corres-
pondent à % ARep, VDA, VDIA, VTS, VDC, % ARef, % AI, ND, et NT. Nous supposons
que : 
 0 if cr < thr ,
j j
∀j ∈ {1, ..., 5} , f (crj ) = (3.4.1)
 1 if cr ≥ thr ;
j j

et

 0 if crj > thrj ,
∀j ∈ {6, ..., 9} , g (crj ) =  (3.4.2)
1 if crj ≤ thrj .

56
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Chaque UA est caractérisé par un ensemble de fonctions (S) donnée par l’équation
3.4.3 :

S = (f (cr1 ) , f (cr2 ) , f (cr3 ) , f (cr4 ) , f (cr5 ) ,


g (cr6 ) , g (cr7 ) , g (cr8 ) , g (cr9 )) (3.4.3)

Nous avons distingué deux classes d’UA : la première est une classe légitime (LC) donnée
par l’équation 3.4.4

LC = {S/f (cr1 ) = f (cr2 ) = f (cr3 ) = f (cr4 ) = f (cr5 ) =


g (cr6 ) = g (cr7 ) = g (cr8 ) = g (cr9 ) = 1} . (3.4.4)

et la seconde est une classe SPITter (SC) donnée par l’équation 3.4.5:

SC = LC (3.4.5)

3.5 Métriques d’évaluation des performances d’un


classeur des UA
Les indicateurs d’efficacité utilisés dans l’évaluation des applications de classement sont
nombreux. Néanmoins, la plupart de ces indicateurs sont construits à partir de la table
de contingence présentée dans le Tableau 3.4.

Réalité
légitime SPITter
légitime VN FN
Classificateur
SPITter FP VP

Table 3.4 – Table de contingence.

Ici, les abréviations des cellules sont comme suit :


— VN (Vrais Négatifs) : des UA légitimes classés correctement,
— FN (Faux Négatifs) : des UA SPITter classés comme des légitimes,
— VP (Vrais Positifs) : des UA SPITter classés correctement,
— FP (Faux Positifs) : des UA légitimes classés comme des SPITter.
A partir du Tableau 3.4, nous pouvons extraire plusieurs rapports qui permettent de
définir des critères d’efficacité. Nous avons récapitulé quelques critères dans le Tableau
3.5.

57
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Indicateur Définition
Taux de Faux Positifs (TFP) FP
V N +F P
Taux de Faux Négatifs (TFN ) FN
V P +F N
Sensibilité (Sensibility, Power) (1 − T F N ) = VP
V P +F N
Spécificité (Specificity) (1 − T F P ) = VN
V N +F P
Exactitude (Accuracy) V P +V N
V P +F P +V N +F N
Taux d’erreur global (1 − Exactitude) = V P +FF PP +V
+F N
N +F N

Table 3.5 – Indicateurs définis à partir de la table de contingence.

Les indicateurs dérivés d’une table de contingence ont l’inconvénient d’être spécifiques
à une valeur de seuil. De plus, ils ne peuvent pas donner des informations sur l’efficacité
du classeur à d’autres valeurs de seuils.
Ainsi, un moyen efficace pour l’évaluation des performances de détection, est de tra-
cer la courbe ROC [90]. En fait, cette courbe exprime la Sensibilité en fonction de
(1 − spécif icité) pour différentes valeurs du seuil de discrimination s.
L’interprétation de la courbe ROC est illustrée par la Figure 3.5.1.

prédiction parfaite 1,0 tous classés


point (0,1) Seuil optimal comme
des SPITters
dm

Sp=1 && Sn=1


sa n
in

ha ictio

0,8 point (1,1)


rd
Taux de Vrais Positifs

Sp=0 && Sn=1


au réd
p
r d
Sensibilité

sa

0,6
'a n
ha
qu tio
e ic
u
ur réd
p

0,4
rd
ha n
lle

sa
'a ctio
ei
m

qu di
re pré

0,2
tous classés
pi

comme
des Légitimes 0,0 prédiction nulle
point (0,0)
0,0 0,2 0,4 0,6 0,8 1,0 point (1,0)
Sp=1 && Sn=0 1 - Spécificité Sp=0 && Sn=0

Taux de Faux Positifs

Figure 3.5.1 – Interprétation de la courbe ROC.

Les courbes ROC ont des caractéristiques visuelles interprétées selon les cas suivant :
— la courbe ROC est entièrement comprise dans le carré de sommets opposés (0,0) et
(1,1),
— la courbe ROC d’un classeur idéal (prédiction parfaite) se confond avec le point
(0,1),
— la courbe ROC d’un classeur dont la prédiction est nulle se confond avec le point
(1,0),

58
Chapitre 3 Approche Comportementale pour la Détection de SPIT

— la courbe ROC d’un classeur dont l’efficacité est identique à un choix au hasard
(aléatoire) est définit par le segment reliant les sommets (0,0) et (1,1).
Le calcul de l’aire sous la courbe ROC, notée AUC ( Area Under the Curve) [91] nous
permet de comparer plusieurs classeurs. En effet, si l’AUC d’un classeur est plus grande
que celle d’un autre classeur, nous pouvons alors affirmer que le premier classeur est
globalement plus performant que le second.
La courbe ROC est également utilisée pour fixer la valeur de seuil optimal. En effet,
Wright [92] a justifié l’utilisation de ROC pour trouver le seuil optimal d’un filtre dans
la théorie de détection de signal (SDT). Suite à une discussion sur la courbe ROC, cet
auteur à expliquer la façon dont les critères de décision optimaux sont atteintes. Selon
Saber et al. [40], en se basant sur la courbe ROC, un seuil optimal a été calculé pour
chaque classe. Ceci a permis de maximiser simultanément le nombre de Vrai Positifs VP
et réduire le nombre de Faux Positifs FP. Graphiquement, le seuil optimal représente le
point sur la courbe la plus proche de (0, 1). En effet, si nous notons SN la sensibilité et
SP la spécificité alors la distance entre le point(0, 1) et un point quelconque de la courbe
ROC est donnée par l’équation 3.5.1 [93]

d2 = (1 − Sn )2 + (1 − Sp )2 (3.5.1)

Ainsi, pour obtenir le point optimal (relatif au seuil optimal), il faut calculer la dis-
tance d pour chaque point observé et localiser le point où la distance est minimale (voir
la figure3.5.1). Ici, nous pouvons remarquer que lorsque dmin converge vers 0 (l’UAC
converge vers 1) le classeur est considéré comme idéal.
Dans ce contexte, nous avons appliqué cette méthode pour calculer les valeurs de seuils
relatifs à l’algorithme de la détection des SPITs déjà cité dans la section 3.2. Nous avons
remarqué que cette solution n’est réellement applicable que pour un seul critère de détec-
tion [94].
Dans la suite, nous allons montrer la performance des méthodologies d’apprentissage
afin d’en déduire la plus adaptée pour le système proposé de détection de SPIT.

3.6 Résultats de simulation


Dans le but d’évaluer les différentes techniques de classement, nous avons lancé une
simulation de 52 min. Nous avons fixé T = 30 min (durée de la fenêtre glissante) et
p = 2 min (pas de glissement). Les extraits des fichiers traces sont indiqués dans l’annexe.
Suite à cette configuration, nous avons fixé les différents seuils présentés dans le Tableau
3.6.

59
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Critère Seuil Valeur de Seuil


cr1 thr1 75%
cr2 thr2 500
cr3 thr3 500
cr4 thr4 500
cr5 thr5 500
cr6 thr6 75%
cr7 th7 75%
cr8 th8 8
cr9 th9 10

Table 3.6 – Fixation des seuils

Les valeurs de seuils des critères VDA, VDIA, VTS et VDC sont fixées suite à des
simulations intensives. Pour les autres critères, nous avons choisi les seuils appropriés à la
période de la fenêtre glissante. Par exemple, il est évident que le comportement d’un UA
devient anormal lorsque le nombre de tentatives d’appel NT est supérieur à 10 pendant
un intervalle de temps ne dépassant pas les 30 min.
Notre base de données d’apprentissage contient 512 échantillons (179 UA légitimes et
333 UA SPITters). Toutes les simulations sont générées à partir de cette base de données.
Pour la phase de test, nous avons utilisé 96 UAs dont 44 sont des SPITters comme le
montre sur la Figure 3.4.1. L’ordre de l’apparition de ces 44 SPITters au cours de 12
fenêtres glissantes est illustré dans le Tableau 3.7

Fenêtre Nombre de SPITters % de détection souhaitée


T1 31 70.45
T2 1 72.72
T3 0 72.72
T4 1 75.00
T5 1 77.27
T6 0 77.27
T7 1 79.54
T8 2 84.09
T9 2 88.63
T 10 2 93.18
T 11 1 95.45
T 12 2 100
Total 44

Table 3.7 – Ordre d’apparition de 44 SPITters au cours de 12 fenêtres glissantes

60
Chapitre 3 Approche Comportementale pour la Détection de SPIT

Dans le logiciel de fouille de données Weka, nous utilisons l’option de test "TestSetMa-
ker" car elle permet de classer tous les UA (Voir annexe).
Dans ce qui suit, nous notons que le classeur avec une détection idéale est celui dont la
courbe de détection réelle est la même que la courbe de détection souhaitée.
Dans nos résultats expérimentaux, nous avons tracé les courbes ROC pour évaluer la
performance des techniques d’apprentissage relativement au système proposé.
La Figure 3.6.1 illustre les courbes ROC des méthodes NaiveBayes et BayesNet.
1

0.9

0.8

0.7
Taux de Vrais Positifs

0.6
Sensibilité

0.5

0.4

0.3

0.2

0.1
BayesNet
NaiveBayes
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
1−spécificité
Taux de Faux Positifs

Figure 3.6.1 – Courbes ROC des méthodes BayesNet et NaiveBayes.

En comparant les courbes ROC de ces deux méthodes, nous constatons que les perfor-
mances de détection des attaquants SPITter de la méthode BayesNet est bien meilleure
que celle de NaiveBayes. En effet, la courbe ROC de la méthode BayesNet est au-dessus
de BayesNaive et par conséquent son AUC est le plus grand.
Afin de confirmer les résultats des courbes ROC, nous avons tracé les courbes du pour-
centage de détection et de fausses alarmes par rapport au fenêtrage (principe de la fenêtre
glissante).
La figure 3.6.2 représente l’allure de ces courbes ainsi que les courbes du pourcentage
de détection et de fausses alarmes souhaitées représentant le cas idéal. Nous remarquons
que le comportement de détection de la méthode NaiveBayes est mauvaise puisqu’elle
représente un pourcentage de fausses alarmes trop élevé. En ce qui concerne la méthode
BayesNet, le pourcentage de détection souhaitée n’est pas atteint malgré que le pourcen-
tage de fausses alarmes soit assez proche de cas souhaité.

61
Chapitre 3 Approche Comportementale pour la Détection de SPIT

100

90

% de détection & % de fausses alarmes 80

70

60

Détection souhaitée
50
Fausses alarmes souhaitées
Détection BayesNet
40
Fausses alarmes BayesNet
30
Détection NaiveBayes
Fausses alarmes NaiveBayes
20

10

0
0 2 4 6 8 10 12
Fenêtre

Figure 3.6.2 – Courbes de détection et de fausses alarmes pour les méthodes BayesNet
et NaiveBayes.

L’analyse des courbes ROC des méthodes PolyKernel et SMO RBFKernel illustrée par
la figure 3.6.3 nous permet d’affirmer que la méthode SMO RBFKernel est meilleure que
celle de SMO RBFKernel.
1

0.9

0.8

0.7
Taux de Vrais Positifs

0.6
Sensibilité

0.5

0.4

0.3

0.2

0.1
SMO RBFKernel
SMO PolyKernel
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
1−spécificité
Taux de Faux Positifs

Figure 3.6.3 – Courbes ROC des méthodes SMO RBFKernel et SMO PolyKernel.

La Figure 3.6.4 représente les courbes du pourcentage de détection et de fausses alarmes


par rapport au fenêtrage de ces deux méthodes. Ces courbes confirment que la méthode
SMO RBFKernel est meilleure sauf que la détection est inférieure au cas idéal.

62
Chapitre 3 Approche Comportementale pour la Détection de SPIT

100

90

% de détection & % de fausses alarmes 80

70

60

Détection souhaitée
50
Fausses alarmes souhaitées
Détection SMO RBFKernel
40
Fausses alarmes SMO RBFKernel
Détection SMO PolyKernel
30
Fausses alarmes SMO PolyKernel
20

10

0
0 2 4 6 8 10 12
Fenêtre

Figure 3.6.4 – Courbes de détection et de fausses alarmes pour les méthodes SMO RBF-
Kernel et SMO PolyKernel.

Nous avons également comparé la méthode de perceptron à trois couches (L = 2 avec


7 nœuds au niveau de la première couche cachée (N1 = 7) et 2 nœuds au niveau de la
deuxième (N2 = 2)) avec celle de deux couches perceptron (L = 1 avec 2 nœuds au niveau
de la couche cachée (N = 2)).
Par le biais de la Figure 3.6.5, il est clair que l’AUC de la méthode de perceptron à
trois couches est plus supérieure à celle de perceptron à deux couches.
1

0.9

0.8

0.7
Taux de Vrais Positifs

0.6
Sensibilité

0.5

0.4

0.3

0.2

0.1 MultiLayerPerceptron, L=2, N1=7, N2=2


MultiLayerPerceptron, L=1, N=2
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
1−spécificité
Taux de Faux Positifs

Figure 3.6.5 – Courbes ROC des méthodes MultiLayerPerceptron à 1 et 2 couches.

Par conséquent le premier classeur est le plus performant.


La Figure 3.6.6 représente les courbes du pourcentage de détection et de fausses alarmes
par rapport au fenêtrage.

63
Chapitre 3 Approche Comportementale pour la Détection de SPIT

100

90

% de détection & % de fausses alarmes


80

70

60 Détection souhaitée
Fausses alarmes souhaitées
Détection MultiLayerPerceptron, L=2, N1=7, N2=2
50
Fausses alarmes MultiLayerPerceptron, L=2, N1=7, N2=2
Détection MultiLayerPerceptron, L=1, N=2
40 Fausses alarmes MultiLayerPerceptron, L=1, N=2

30

20

10

0
0 2 4 6 8 10 12
Fenêtre

Figure 3.6.6 – Courbes de détection et de fausses alarmes pour les méthodes MultiLayer-
Perceptron à 1 et 2 couches.

Ces courbes montrent que la méthode de perceptron à trois couches est meilleure.
Cette méthode est marquée par un pourcentage de fausses alarmes nul. Aussi, elle est
plus performante par rapport aux méthodes étudiées jusqu’à maintenant.
La Figure 3.6.7 montre les bonnes performances des méthodes J48 et NBTree. En effet,
ces techniques d’apprentissage possèdent le plus grand AUC par rapport à toutes les
méthodes étudiées.
1

0.9

0.8

0.7
Taux de Vrais Positifs

0.6
Sensibilité

0.5

0.4

0.3

0.2

0.1
J48
NBTree
0
0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1
1−spécificité
Taux de Faux Positifs

Figure 3.6.7 – Courbes ROC des méthodes J48 et NBTree.

La Figure 3.6.8 représente les courbes du pourcentage de détection et de fausses alarmes,


appliquées aux méthodes J48 et NBTree.

64
Chapitre 3 Approche Comportementale pour la Détection de SPIT

100

90

% de détection & % de fausses alarmes 80

70

Détection souhaitée
60 Fausses alarmes souhaitées
Détection J48
50
Fausses alarmes J48
Détection NBTree
40
Fausses alarmes NBTree

30

20

10

0
0 2 4 6 8 10 12
Fenêtre

Figure 3.6.8 – Courbes de détection et de fausses alarmes pour les méthodes J48 et
NBTree.

Ces courbes confirment que ces deux méthodes sont efficaces pour le système proposé.
En effet, elles sont confondues avec les courbes souhaitables.
La comparaison des courbes ROC de AdaBoost M1, Bagging et J48 révéle que la mé-
thode AdaBoost M1 est plus efficace car elle offre une meilleure AUC (AUC = 1) comme
il est indiqué dans la Figure 3.6.9.
1

0.9

0.8

0.7
Taux de Vrais Positifs

0.6
Sensibilité

0.5

0.4

0.3

0.2
AdaBoostM1
0.1 Bagging
J48
0
0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.01
1−spécificité
Taux de Faux Positifs

Figure 3.6.9 – Courbes ROC des méthodes AdaBoost M1, Bagging et J48

La Figure 3.6.10 montre que les méthodes AdaBoostM1 et Bagging peuvent parfaite-
ment distinguer entre les UAs légitimes et les SPITters. En fait, ces deux méthodes ont dé-
tecté avec succès tous les SPITters avec aucune fausse alarme. Ceci paraît évident, en effet
d’après la définition d’AdaBoostM1 et Bagging (voir Annexe), ces méthodes donnent une
grande performance si elles sont combinées avec des méthodes instables (tels que l’arbre
de décision). Ainsi dans notre étude expérimentale, nous avons utilisé les méthodes Ada-
BoostM1 et Bagging en combinaison avec le classeur J48. D’où la grande performance de

65
Chapitre 3 Approche Comportementale pour la Détection de SPIT

détection.
100

90
% de détection & % de fausses alarmes

80

70

60

50

40

30
Détection souhaitée
20 Fausses alarmes souhaitées
Détection AdaBoostM1
Fausses alarmes AdaBoostM1
10 Détection Bagging
Fausses alarmes Bagging
0
0 2 4 6 8 10 12
Fenêtre

Figure 3.6.10 – Courbes de détection et de fausses alarmes pour les méthodes Bagging
et AdaBoostM1

Temps
Classifieur
d’entraînement
(secondes)
NaiveBayes 0, 007
BayesNet 0, 016
J48 0, 021
Bagging 0, 090
AdaBoostM1 0, 130
SMO (RBFKernel) 0, 277
NBTree 0, 858
Multilayer Perceptron L = 2 2, 248

Table 3.8 – Temps d’entraînement de chaque méthode de classification.

Classifieur AUC
AdaBoostM1 1
Bagging 0.9999
J48 0.9992
NBTree 0.9982
BayesNet 0.9920
MultiLayerPerceptron L=2 0.9915
MultiLayerPerceptron L=1 0.9827
SMO RBFKernel 0.9637
NaiveBayes 0.9346
SMO PolyKernel 0.8675

Table 3.9 – AUC de chaque méthode de classification

Par le biais du Tableau 3.8, nous remarquons aussi que le temps d’entrainement (temps
66
Chapitre 3 Approche Comportementale pour la Détection de SPIT

de construction de modèle) de la méthode AdaBoostM1 est raisonnable. Le Tableau 3.9


récapitule l’AUC de chaque méthode de classement.
En conclusion, nous pouvons affirmer que le classeur AdaboostM1 est le plus adapté
pour notre système de détection de SPIT.

3.7 Conclusion
Ce travail vise à développer un mécanisme anti-SPIT en utilisant une approche com-
portementale basée sur les critères d’identifications. Pour cela nous avons développé un
algorithme de détection afin de déterminer les critères d’identification les plus influents
dans la détection (de point de vue détection et temps de réponse). Comme résultat, nous
avons remarqué que la durée d’appel est un critère très significatif pour la détection. En
se basant sur ce résultat, nous avons pu déterminer d’autre critère d’identification tels que
la durée d’inter-appel et la durée de conversation. Ainsi, nous avons utilisé neufs critères
d’identification de SPIT pour l’approche comportementale. De ce fait, nous avons pro-
posé une topologie d’un réseau VoIP dans un environnement OPNET. Par le biais de la
simulation, nous avons prélevé les traces réseaux de la signalisation et de l’activité vocale
afin d’extraire les critères d’identification des attaquants SPITter. Nous avons exploité la
stratégie de la « fenêtre glissante » pour suivre et maintenir correctement les profils des
appelants. Nous avons évalué la classification supervisée à travers dix méthodes (Naive-
Bayes, BayesNet, SMO RBFKernel, SMO PolyKernel, MultiLayerPerceptron 2 couches et
3 couches, NBTree, J48, AdaBoostM1 et Bagging) en utilisant le logiciel de fouille de don-
nées Weka. Notre étude a montré que les classeurs adoptant les méthodes AdaBoostM1
et Bagging sont les plus performants et s’approchent beaucoup du cas de détection idéale.
D’où la performance de notre méthode de détection. Cependant, malgré cette perfor-
mance, cette méthode peut causer un impact négatif sur la disponibilité et la qualité
de service de la VoIP puisqu’elle permet le blocage de UA SPITter. Ainsi, la gestion des
risques offre de nouvelles perspectives pour remédier à ce problème. Ce concept sera étudié
en détail dans le chapitre suivant.

67
Partie II : Gestion des Risques dans un
Réseau VoIP
Chapitre 4

Processus et Modèles de Gestion des


Risques

4.1 Introduction
La gestion des risques se réfère au processus de prise de décisions qui minimisent les
effets des vulnérabilités sur les hôtes du réseau. Cela peut être une tâche difficile dans le
contexte d’identification de nouveaux exploits et de vulnérabilités. Ainsi, afin de mieux
comprendre la fonctionnalité du système de gestion des risques, il est indispensable d’étu-
dier ses différents modèles de base.
Dans ce chapitre, nous présentons un aperçu sur la gestion des risques dans le contexte
général ainsi que dans le contexte de la VoIP.
Le reste de ce chapitre est organisé comme suit : La Section 4.2 introduit la gestion des
risques. Cette Section comprend la définition des éléments de base constituant la gestion
des risques, les différentes méthodes standards et les étapes de processus de gestion. La
Section 4.3 présente l’application du processus de gestion des risques dans un réseau VoIP.
Dans ce cadre, nous détaillons les différentes étapes de gestions ainsi nous illustrons les
travaux liés. Nous terminons par une synthèse du chapitre.

4.2 Introduction à la gestion des risques


Dans cette section nous présentons les différents éléments de base qui constituent la
gestion des risques. Ensuite, nous illustrons les différents modèles standards de gestion
des risques. Ainsi, en se basant sur ces modèles, nous introduisons les différentes étapes
de gestion des risques.

69
Chapitre 4 Processus et Modèles de Gestion des Risques

4.2.1 Définition et éléments de base


4.2.1.1 Gestion des risques

La gestion des risques (Risk Management) est le processus qui permet d’identifier les
risques, d’évaluer les risques et de prendre des mesures de sécurité pour les réduire à
un niveau acceptable [95]. Selon la norme ISO 27000, la gestion du risque se réfère à
un ensemble coordonné d’activités, des méthodes et des techniques que les organisations
utilisent pour gérer le risque et l’incertitude qui influent sur la façon d’atteindre leurs
objectifs.
Pour mieux comprendre le principe de la gestion des risques, il est indispensable de
définir ses éléments de base à savoir : l’actif, la menace, la vulnérabilité, l’attaque et le
risque.

4.2.1.2 Actif

Un actif est défini comme étant tout élément ayant une valeur technique ou un défi pour
le système et ses services [95]. Selon la norme ISO/IEC 27005, nous pouvons distinguer
deux types d’actifs : les actifs primaires (à savoir l’information, les processus et les acti-
vités) et les actifs de support (à savoir les équipements matériels, le personnel, le logiciel,
les réseaux ect.). Dans le contexte de la VoIP, l’actif inclut tout élément en relation avec
le processus d’enregistrement, l’établissement de la session, la localisation des UAs et le
routage d’appel.

4.2.1.3 Menace

Selon la norme ISO/IEC 27005, une menace représente toute source d’attaque qui
exploite une vulnérabilité, intentionnellement ou accidentellement, dans le but d’obtenir
des dommages ou détruire un actif. Nous distinguons trois types de menace : menace
directe, menace indirecte et menace conditionnelle.
— une menaces directe identifie une cible spécifique et peut être livrée d’une manière
simple, claire et explicite,
— une menace indirecte tend à être vague, confus et ambigüe. Ainsi, le plan, la victime
visée, la motivation, et d’autres aspects de la menace sont masqués ou équivoques,
— une menace conditionnelle est le type de menace souvent vue dans des cas d’ex-
torsion. Elle met en garde qu’un acte violent se produira à moins que certaines
exigences ou conditions soient remplies.
Dans le contexte de la VoIP, il existe plusieurs types de menace telles que : l’écoute et
l’analyse du trafic, le vol d’identité, l’envoi d’un nombre élevé de message SIP.

70
Chapitre 4 Processus et Modèles de Gestion des Risques

4.2.1.4 Vulnérabilité

La vulnérabilité représente une faiblesse ou une lacune dans un programme de sécurité


qui peut être exploitée par une menace pour avoir un accès non autorisé à un actif.
Dans le réseau VoIP, nous distinguons plusieurs vulnérabilités à savoir : les paramètres
par défaut, les patches manquants et les mots de passe faibles. Aussi, les conversations
vocales représentent une grande faiblesse de la VoIP puisqu’elle ne sont pas cryptées et
peuvent donc être interceptées et enregistrées.

4.2.1.5 Attaque

L’attaque est un moyen ou un outil par lequel un attaquant utilise une vulnérabilité pour
causer des dommages au système cible. Il peut représenter l’intersection de trois éléments
[96] à savoir : les vulnérabilités de services, l’attaquant accédant à cette vulnérabilité et
l’aptitude de cet attaquant à profiter de la faiblesse.

4.2.1.6 Risque

Le risque représente le potentiel de perte, de dommage ou de destruction d’un actif à


la suite d’une menace qui exploite une vulnérabilité [95], [97]. Selon [98], il existe deux
définitions de base du risque : une définition fondée sur la menace de risques liées ou non
à des vulnérabilités et une définition basée sur des scénarios de risque. Pour la première
définition, le risque est une combinaison d’un actif, une menace pouvant endommager cet
actif et de vulnérabilités exploitées par la menace pour endommager l’actif. La deuxième
définition représente le risque comme étant la combinaison d’un actif, un type de dommage
qui peut survenir à l’actif et les circonstances dans lesquelles ce dommage peut se produire.

4.2.2 Principaux méthodes de gestion des risques


Plusieurs méthodes ont été proposées pour la gestion des risques dont les principales
sont : OCTAVE, EBIOS, MEHARI, ISO27005 et CORAS.
La méthode OCTAVE a été développée au sein de l’Institut de génie logiciel Part of
Carnegie Mellon University (OCTAVE) par le Computer Emergency Response Team
(CERT). Le but de cette méthode est de permettre « l’évaluation stratégique de la sé-
curité de l’information fondée sur les risques et la planification» [99]. Cette approche se
base sur les activités, les menaces et les vulnérabilités. L’approche OCTAVE est desti-
née principalement aux entreprises de 300 employés ou plus et comprend les trois phases
suivantes :
1. Construire des profils de menace basés sur les actifs,
2. Identifier les vulnérabilités de l’infrastructure,
3. Élaborer une stratégie et des plans de sécurité

71
Chapitre 4 Processus et Modèles de Gestion des Risques

La méthode EBIOS a été créée en 1995 par la DCSSI (Direction Centrale de la Sécurité des
Systèmes d’information). L’objectif de la méthode EBIOS est l’évaluation et le traitement
des risques associés à un SI (système d’information). EBIOS est principalement destinée
aux organisations gouvernementales et commerciales travaillant avec le ministère de la
défense qui traitent les informations confidentielles ou les informations de défense classées
secrètes. Elle assure des mesures de sécurité bien informées à entreprendre. La méthode
EBIOS comprend 5 étapes :
1. Etude de contexte ;
2. Etude des besoins de sécurité ;
3. Analyse des menaces
4. Identification des objectifs de sécurité ;
5. Identification des exigences de sécurité
La méthode MEHARI est développée en 1996 par CLUSIF [100]. L’objectif de cette mé-
thode est de fournir un ensemble d’outils spécialement conçus pour la gestion de la sécu-
rité qui comprend un ensemble d’actions de gestion dont chacune a un objectif spécifique.
Exemples de ces actions sont : l’élaboration de plans de sécurité et des plans stratégiques,
la mise en œuvre des politiques ou des règles de sécurité, la garantie de l’intégration de
la sécurité dans la gestion des projets de développement, l’élaboration des séances de for-
mation et de sensibilisation à la sécurité et enfin la gestion de la sécurité opérationnelle
et le contrôle/suivi des actions commises. La méthode comprend 7 étapes :
1. Identification des bases de connaissances des situations de risque,
2. Spécification des règles pour la consolidation de l’analyse des risques entraînant un
cadre parfait des plans d’action,
3. Analyser les enjeux majeurs,
4. Analyser les vulnérabilités,
5. Diminuer et gérer les risques,
6. Surveiller la sécurité des informations,
7. Construire la base de données d’audit.
Le but de la norme ISO 27005 [95] est de fournir des directives pour la gestion des risques
de la sécurité de l’information. Cette norme spécifie d’une manière plus détaillée la gestion
des risques sans fournir des détails ou identifier une méthode pour déterminer le niveau
de risque. Cependant, la norme ISO 27005 définit un processus structuré, systématique et
rigoureuse d’analyse des risques pour la création du plan de traitement des risques [101].
Le processus d’évaluation des risques ISO 27005 est subdivisé comme suit :
1. L’analyse de risque : contenant l’évaluation des risques et l’estimation des risques.
La première phase permet de trouver les sources possibles de perte éventuelle. Dans
la deuxième phase, les connaissances acquises précédemment sont utilisées pour
mesurer qualitativement ou quantitativement le risque.
72
Chapitre 4 Processus et Modèles de Gestion des Risques

2. L’évaluation de risque : chaque niveau de risque est comparé aux critères d’accep-
tation et d’évaluation des risques. Ainsi, une liste hiérarchisée des risques et des
options de traitement recommandées sont créés.
3. L’atténuation de risque : des mesures de réduction, de rétention, d’évitement ou de
transfère de risque sont choisies et utilisées pour produire un plan de traitement des
risque
La méthode CORAS [102] a été développée en utilisant les technologies de la société de
l’information (Information Society Technologies (IST)). L’un des principaux objectifs de
CORAS est de développer une structure qui utilise des méthodes d’analyse des risques, des
méthodes semi-formelles pour la modélisation orientée objet, des outils informatiques pour
une évaluation précise et sans ambiguïté du risque et des systèmes de sécurité critiques
efficaces [103]. La méthodologie est basée sur le langage de modélisation unifié (UML) qui
utilise des diagrammes pour illustrer les relations et les dépendances entre les utilisateurs
et l’environnement dans lequel ils travaillent. Le processus de gestion des risques CORAS
est subdivisé en cinq sous-processus définit comme suit :
1. Identification du contexte : Identifier le contexte de l’analyse qui va suivre,
2. Identification des risques : Identifier les menaces et les vulnérabilités relatives aux
actifs,
3. Analyse des risques : Affectez des valeurs à la conséquence et à la probabilité d’oc-
currence de chaque menace identifiée dans le sous-processus 2,
4. Evaluation des risques : Identifier le niveau de risque associé aux menaces déjà
identifiés et évalués dans les sous-processus précédents,
5. Traitement des risques : Adresser une traitement spécifique aux risques identifiés.

4.2.3 Processus de Gestion des risques


D’après la description détaillée des différentes méthodes de gestion des risques, nous
pouvons conclure que le processus de gestion des risques comprend trois étapes de base :
l’identification des risques, l’évaluation des risques et le traitement des risques.
— L’identification des risques est la phase où les menaces, les vulnérabilités et les
risques associés sont identifiés.
— L’évaluation des risques est la phase qui permet d’affecter des valeurs à la consé-
quence et à la probabilité d’occurrence de chaque menace identifiée et estimer ainsi
la valeur du risque.
— Le traitement des risques est le processus de sélection et d’application de mesures
visant à modifier le risque. Les mesures de traitement des risques peuvent inclure
l’évitement, l’optimisation, le transfert ou le maintien de risque.
Une description détaillée de chaque étape est menée dans la section suivante.

73
Chapitre 4 Processus et Modèles de Gestion des Risques

4.3 Processus de Gestion des risques dans le réseau VoIP

4.3.1 Explication des étapes de processus de gestion des risques


Nous avons considéré, d’après la section précédente, que le processus de gestion des
risques comprend trois étapes de base : l’identification des risques, l’évaluation des risques
et le traitement des risques. Dans la suite nous analysons en détail chacune de ces étapes
dans le contexte de la VoIP.

4.3.1.1 Identification des risques

L’identification des risques est l’étape la plus importante dans le processus de gestion
des risques. Cette étape nécessite une bonne compréhension du contexte dans lequel le
risque existe. L’établissement du contexte s’effectue en tenant compte du :
— Contexte environnemental : l’environnement dans lequel opère le réseau VoIP à
savoir les terminaux, les serveurs, le système d’exploitation, les services et les pro-
tocoles requis
— Contexte opérationnel : les objectifs, les activités et les opérations du VoIP à sa-
voir les données d’enregistrement, les informations d’établissement de session, les
statistiques du trafic des appels et l’historique des serveurs.
Après la collection des différentes informations concernant le réseau VoIP, il est nécessaire
d’identifier les menaces potentielles et les vulnérabilités associées.

Identification des menaces

Différents travaux ont été proposés pour détecter les menaces. Ils incluent les méthodes
de détection d’intrusion et le pot de miel.
Concernant les méthodes de détection d’intrusion, plusieurs travaux ont été présentés.
Dans le contexte de l’attaque SPIT, Quittek et. al. [2] ont utilisé des tests de Turing du côté
de l’appelant toute en comparant leurs résultats à des patrons de communication humaine.
L’efficacité de ces tests est réduite à cause des ressources supplémentaires nécessaires côté
appelants [3]. Shin et. al. [1] ont proposé un algorithme de liste grise progressive multi-
niveaux (nommé PMG) qui se base uniquement sur le nombre des appels. En revanche,
le retour d’expérience pour la détection de SPIT nous montre l’importance d’utiliser
plusieurs mesures de détection. Une autre approche utilisant une défense socio-technique
est présentée dans [4]. Les auteurs proposent un filtre adaptatif multi-étapes basé sur la
présence (lieu, temps, état d’esprit), la confiance et la réputation. Un travail similaire
nommé « CallRank » [5] analyse la durée des appels, les réseaux sociaux et la réputation
globale. Les auteurs ont proposé l’ajout des crédits de chaque appel au message INVITE
ainsi que les notes de réputation données par les proxys. Le déploiement à grande échelle
de ces deux approches est compliqué puisqu’il est nécessaire d’implanter une infrastructure
publique de distribution des clefs.
74
Chapitre 4 Processus et Modèles de Gestion des Risques

Les techniques de détection d’anomalie consistent à identifier les écarts à partir d’un
profil de comportement normal prédéfini en utilisant des mesures statistiques, alors que la
détection basée sur les signatures d’attaque consiste à rechercher des modèles de compor-
tement malveillant en utilisant une base de données de signatures d’attaques prédéfinies.
Dans ce contexte, les signatures d’attaque aussi couramment utilisées dans les systèmes
de détection d’intrusion de réseau tels que Snort [104] ou Bro [105] ont été étendues au
protocole SIP par Nicolini et al. [106].
Nassar et al. [107] ont proposé une autre méthode de détection en utilisant le pot de
miel (honeypot). L’installation d’un honeypot permet d’ouvrir une session, d’étudier les
traces d’attaque et de découvrir les méthodologies des pirates. Cette stratégie de défense
est très réussie mais il peut être dangereux. Ainsi, Nassar et al. utilisent un téléphone pour
jouer le rôle de honeypot. Les auteurs visent en premier lieu à enregistrer les activités des
intrus et comprendre leurs méthodes afin d’améliorer les systèmes de protection.

Identification des vulnérabilités

L’analyse de la menace sur un système informatique doit comprendre une analyse des
vulnérabilités liées à l’environnement du système. Le but de cette étape est de spécifier une
liste des vulnérabilités du système (défauts ou faiblesses) qui pourraient être exploitées
par les menaces potentielles. Dans ce contexte, plusieurs méthodes d’identification et de
quantification des vulnérabilités ont été proposées à savoir : le fingerprinting et le fuzzing.
Le fingerprinting est une méthode utilisée dans l”identification et la quantification des
vulnérabilités. La performance de cette approche apparaît essentiellement en analysant
une grande quantité d’informations telles que les informations archivées des serveurs et
des sessions établies. Ainsi, cette technique assure l’identification des différentes machines
et la détection de sources suspects. La plupart des approches de fingerprinting utilisent
un système de signature correspondant où un ensemble de signatures recherchées dans
le contenu du trafic émis par une entité inconnue. L’entité est identifiée en cherchant sa
correspondance la plus proche avec les signatures stockées. Dans le contexte de la VoIP,
les auteurs dans [108] ont implémenté un pare-feu de SPIT qui utilise le mécanisme de
fingerprinting [109] pour identifier le logiciel à distance des applications VoIP et pour
filtrer les appels provenant des agents suspects. Le pare-feu peut être utilisé dans des
environnements informatiques personnels, des environnements d’entreprise ou des centres
de contact. Il sert comme une étape vers un environnement VoIP plus sûr. D’autres au-
teurs dans [110] ont proposé une nouvelle approche de fingerprinting souples et efficaces
en mesure d’identifier l’entité source de messages dans le réseau VoIP. Le système proposé
génère le fingerprinting en se basant sur une analyse structurale des messages de proto-
coles. Cette solution automatise la génération en utilisant deux grammaires formelles et
des traces de trafic collectées.
Le fuzzing représente une autre méthode pour détecter les vulnérabilités des logiciels
dans un tel réseau [111]. Le fuzzing est effectuée avant le déploiement de logiciels, de

75
Chapitre 4 Processus et Modèles de Gestion des Risques

sorte qu’il n’a aucun effet sur les performances au moment de l’exécution d’une analyse
statique. Le fuzzing est considéré comme un processus dynamique. Ainsi, tout état du
système dynamique peut être utilisé pour identifier les vulnérabilités. L’idée de base de
fuzzing est la suivante : les champs d’un protocole spécifique sont "Fuzzed" (rempli) de
données plus ou moins aléatoire telles que les exceptions de logiciels non traitées qui
peuvent être déclenchées [112]. De cette façon, de nombreuses vulnérabilités peuvent être
détectées automatiquement et ainsi les défauts de logiciels les plus courants (comme pour
l’injection de l’instance SQL dans les applications web) peuvent être vérifiés de manière
simple et efficace. Dans le contexte de la VoIP et plus précisément au niveau du protocole
SIP, les auteurs dans [113] utilisent l’INTERSTATE fuzzer qui explore la machine d’état
du protocole SIP, au cours du processus de test, pour révéler les vulnérabilités associées
aux chemins de flots de contrôle. INTERSTATE génère une séquence d’entrée pour un
téléphone SIP. Cette séquence est construite pour révéler les failles de la sécurité commune.

4.3.1.2 Evaluation des risques

D’après la définition issue de [114], le risque est une fonction de la probabilité d’une
menace donnée exerçant une vulnérabilité potentielle particulière ainsi que l’impact de cet
événement défavorable sur l’organisation. Par conséquent, un calcul de risque se compose
de deux parties : une estimation de la probabilité d’une attaque réussie et une estimation
de l’impact (conséquence). Cette estimation peut être effectuée d’une façon quantitative
ou qualitative. Une estimation qualitative utilise une échelle de qualification des attributs
pour décrire l’ampleur des attaques potentielles (par exemple faible, moyen et élevé) et la
probabilité que ces attaques produisent. L’estimation quantitative utilise une échelle avec
des valeurs numériques pour les conséquences et la probabilité d’occurrence en utilisant
des données provenant de diverses sources.
Pour estimer le risque, plusieurs travaux ont été proposés : Le projet Open Web Ap-
plication Security Project (OWASP) [115] propose une approche pour l’estimation des
risques qui combine la probabilité et la sévérité de chaque menace en utilisant des règles
d’inférence. La probabilité d’une menace est estimée par l’évaluation d’un ensemble de
facteurs qui mesurent l’agent de menace (l’entité qui cause la menace, par exemple l’at-
taquant) et les chances de découvrir et exploiter les vulnérabilités liées à la menace. La
sévérité d’une menace est estimée par l’évaluation d’un ensemble de facteurs qui mesurent
ses activités et ses impacts techniques.
Les auteurs dans [116] ont proposé un modèle qualitatif (par exemple, utilise des valeurs
floues comme faible, élevé) qui mesure le risque de sécurité compte tenu de la sensibilité des
ressources, la probabilité des menaces, et la sévérité de l’exploitation des vulnérabilités.
Dans le contexte de la VoIP, pour évaluer le risque, il faut essentiellement quantifier la
potentialité de l’attaque et ses conséquences.
— La potentialité de l’attaque peut être considérée comme étant la probabilité de l’oc-
currence d’une attaque donnée. Elle représente aussi la probabilité qu’une menace

76
Chapitre 4 Processus et Modèles de Gestion des Risques

puisse exploiter une ou un ensemble de vulnérabilités pour aboutir à une attaque.


Afin de calculer la potentialité de l’attaque les facteurs suivants doivent être pris en
considération : la motivation et la capacité d’une menace, la nature de la vulnéra-
bilité et l’existence et l’efficacité des mesures de sécurité préliminaires.
— La conséquence représente l’impact d’une attaque réussie sur le système de point
de vue coût et performance. Une conséquence peut être une perte d’efficacité, des
conditions d’exploitation défavorables, une perte de la réputation et des dommages.
En général, les conséquences représentent l’impact réel de l’attaque sur les serveurs
et les terminaux, les difficultés subis par les clients VoIP et les coûts de recouvrement
du risque.

4.3.1.3 Traitement des risques

Dans la première phase du traitement des risques, le niveau des risques estimé de-
vrait être comparé à des critères d’évaluation des risques et des critères d’acceptation des
risques. Ces critères qui sont utilisés pour prendre les décisions adéquates, sont fixés lors
de l’établissement du contexte.
Dans la deuxième phase du traitement des risques, quatre techniques de base ont été
proposées pour traiter les risques à savoir : L’évitement, le transfert, l’acceptation et la
réduction [117]. Ces techniques doivent être choisies en fonction de l’issue de l’évaluation
des risques, le coût prévu pour la mise en œuvre de ces techniques et les avantages attendus
[118]. En général, les conséquences défavorables des risques devraient être aussi basses que
possible.

Evitement des risques

L’évitement des risques consiste à éliminer entièrement l’activité productrice de risque


c’est à dire les vulnérabilités exploitées par les menaces. Pour cela, des mécanismes de pré-
vention doivent être établi pour supprimer le risque. Les techniques assurant la confiden-
tialité représentent l’une des solutions envisagées. Dans le contexte de la VoIP, plusieurs
techniques de confidentialité ont été proposées telles que : HTTP Digest Authentication,
IPsec, S/MIME et TLS.
Le HTTP Digest Authentication [119] fournit un mécanisme d’authentification à base
de défi-réponse (Challenge-Response) qui peut être utilisé par un serveur pour contester
une demande de client et par un client pour fournir des informations d’authentification.
Dans le protocole SIP, chaque fois qu’un serveur proxy ou un UA reçoit une demande, il
propose un défi à l’initiateur de la requête afin de fournir une assurance de son identité.
Une fois que l’initiateur a été identifié, le destinataire de la demande devrait déterminer
si cet utilisateur est autorisé à faire la demande en question. Cette technique ne peut
pas assurer suffisamment de sécurité pour les services de protocole SIP. Par exemple, si
l’utilisateur ne vérifie pas l’identité du serveur, un attaquant peut forger l’identité du

77
Chapitre 4 Processus et Modèles de Gestion des Risques

serveur pour obtenir des informations secrètes de l’utilisateur.


L’IPSec [42] offre un ensemble de services pour protéger les paquets IP d’une telle at-
taque. IPSec est souvent utilisé dans les architectures dans lesquelles un ensemble d’hôtes
ou domaines administratifs ont une relation de confiance entre eux. IPsec peut assurer la
confidentialité, l’intégrité, les services d’authentification des données ainsi que la protec-
tion de l’analyse du trafic. Tout déploiement d’IPSec nécessiterait un profil IPSec décrivant
les outils de protocole qui seraient nécessaires pour garantir la sécurité de protocole SIP.
L’inconvénient majeur de l’IPSec est son coût de mise en place élevé.
Le S/MIME [120] assure le chiffrement des messages SIP. Aussi, il peut garantir la confi-
dentialité et l’intégrité de bout en bout pour les corps de message, ainsi que l’authentifi-
cation mutuelle. Cependant, la technique S/MIME dépend d’une autorité de certification
(CA) et d’une infrastructure complète à clé publique (PKI). Ainsi son adoption d’un un
tel système reste limité.
Le TLS (Transport Layer Security) [43] est un protocole utilisé pour fournir la confi-
dentialité et l’intégrité des données entre deux applications communicantes. Ce protocole
est composé de deux couches : le Protocole TLS d’enregistrement qui assure la sécurité
de la connexion et le protocole TLS de négociation qui permet la négociation de l’algo-
rithme de chiffrement et des clés cryptographique entre le serveur et le client. Dans le
protocole SIP, TLS est utilisé pour transporter tous les messages SIP de l’appelant au
domaine de l’appelé. De là, la demande est envoyée en toute sécurité à l’appelant mais
avec des mécanismes de sécurité qui dépendent de la politique du domaine de l’appelé.
Contrairement à l’IPsec, le protocole TLS décline toute relation de confiance entre les
parties communicantes. TLS peut être utilisé soit selon un schéma unidirectionnel ou à
travers une authentification mutuelle. Ainsi, il peut être plus approprié pour l’authenti-
fication inter-domaine. Bien entendu, il y a toujours le risque que le message peut être
intercepté à l’intérieur du réseau du destinataire si le dernier hop ne soit pas crypté. De
plus, TLS présente d’autres limites puisqu’il nécessite, comme le mécanisme S/MIME,
une infrastructure complète à clé publique (PKI).
Comme conclusion, la stratégie d’évitement repose sur des protocoles qui assurent la
confidentialité et la sécurité du protocole SIP. Ces protocoles ont permis l’évitement de
quelques attaques. Cependant, d’autres attaques telles que le déni de services et le SPIT
restent toujours difficile à éviter.

Acceptation des risques

L’acceptation des risques signifie que le service continu à être exploité sans traitement
des risques [121]. Dans le contexte VoIP, les techniques de cercle de confiance et de répu-
tation représentent des stratégies qui acceptent le risque à un certain niveau. Le cercle de
confiance (voir chapitre 2) représente un groupe de domaines (par exemple, un ensemble
d’entreprises) qui se réunissent pour échanger les appels SIP sous un engagement. Si l’un
d’entre eux est capturé par exemple comme SPITter, il doit payer une amende. Dans ce

78
Chapitre 4 Processus et Modèles de Gestion des Risques

cas, le risque est accepté et l’attaque SPIT exerce la même fonctionnalité. De même pour
la technique de réputation, en effet après tout appel reçu, l’appelé donne à l’appelant une
valeur de réputation. Cette valeur doit être affectée à l’identité de l’appelant pour en ser-
vir lors de l’établissement de nouvelles sessions. Pour une valeur de réputation négative,
l’appelant est considéré comme SPITter. Dans ce cas, le risque est accepté à un certain
niveau.
En conclusion la stratégie d’acceptation nous permet de survivre avec l’attaquant en
respectant quelques conditions. Cependant, cette stratégie peut réussir seulement dans
des petits domaines.

Transfert ou partage des risques

Les stratégies de transfert des risques retournent ou partagent la responsabilité de


l’exécution d’une activité risquée à une autre partie [122]. Comme exemple, le transfert
de la responsabilité pour les pertes à une compagnie d’assurance, ou l’externalisation
d’une activité à un entrepreneur avec la stipulation que l’entrepreneur assume le risque.

Réduction des risques

Pour réduire le risque, une liste de contremesures et des contrôles doivent être proposés
pour minimiser l’impact de l’attaque [117]. Ces contremesures doivent être appliquées dès
la détection d’une menace. Dans ce contexte, plusieurs travaux ont été proposés.
Dans [84], les auteurs ont proposé une plateforme nommé SDRS (Spam Detection and
Reaction System) qui combine des systèmes de détection bien connus tels que les listes
noires et listes blanches, avec des méthodes basées sur l’analyse statistique du trafic tels
que le nombre et la durée des appels. Cette plateforme porte sur la menace de SPIT avec
une architecture modulaire et extensible, rassemblant ainsi de nombreuses méthodes de
détection pour l’identification des SPITs. Elle permet d’ajouter en ligne, mette à jour et
configurer des modules pour une réaction rapide et automatique aux changements de la
menace de SPIT.
Dans [60], les auteurs ont proposé d’utiliser le CAPTCHA (Completely Automated
Public Tests to tell Computers and Humans Apart) avec d’autre techniques anti-SPIT
pour réduire le risque. En effet, le CAPTCHA est un test de défi qui permet de distinguer
entre les appelants humains et les robots. Ainsi, c’est une solution idéale pour contrer les
SPITs de type Bots.
L’inconvénient de ces deux travaux est qu’elles se basent sur le blocage des appels
après la détection. Celle-ci permet de dégrader la qualité de service et ennuyer ainsi les
fournisseurs de services.
Dans notre système, nous avons choisi soit d’accepter le risque (si sa valeur est accep-
table) soit d’appliquer des contremesures pour le réduire. Ces contremesures doivent être
sélectionnées en assurant un compromis entre le coût d’implémentation et la qualité de

79
Chapitre 4 Processus et Modèles de Gestion des Risques

service du système. Pour cela nous proposons d’utiliser la métrique RORI (Return On
Response Investment) qui permet de sélectionner la mesure de sécurité optimale. Cette
mesure permet de réduire l’impact d’une attaque donnée sans sacrifier les fonctionnalités
du système.

4.3.2 Différents modèles de gestion des risques dans le réseau VoIP


Il existe plusieurs modèles proposés de gestion dans un réseau VoIP. Certains travaux
ont présenté des modèles quantitatifs des risques (estiment le risque par une valeur quan-
titative). D’autres travaux ont défini des modèles qualitatifs des risques (présentent le
risque qualitativement). Enfin, des travaux ont présenté des modèles mixtes (présentant
une combinaison des modèles quantitatifs et des modèles qualitatifs) [123].

4.3.2.1 Modèles qualitatifs des risques

En se basant sur le type d’attaquant identifié, les administrateurs de sécurité peuvent


formuler des politiques de gestion des risques efficaces pour un réseau. Ainsi, dans [124],
les auteurs ont affirmé que la séquence d’actions effectuée par un attaquant dans un
réseau VoIP dépend de son niveau social (par exemple son niveau de vie et son niveau
intellectuel). Les auteurs ont étendu cette affirmation et formulé un mécanisme pour
estimer le niveau des ressources essentielles qui peuvent être compromises en fonction
du comportement de l’attaquant des risques. Cette estimation est réalisée en utilisant le
comportement sur la base des graphes d’attaque représentant tous les chemins effectués
par l’attaquant pour accéder à des ressources critiques. Un graphe d’attaque peut être
crée en utilisant la topologie du réseau et diverses vulnérabilités de chaque hôte. Les
graphes d’attaque représentent une séquence d’actions de réseau pour l’exploitation de
chaque ressource du réseau et finalement l’ensemble du réseau. En utilisant ces graphes,
les auteurs ont calculé le niveau de la vulnérabilité et de la sensibilité d’une ressource
critique. Le modèle proposé comporte cinq étapes de détection et d’estimation des risques
à savoir : la création d’un profil de l’attaquant, la construction du graphe d’attaque,
l’affectation des compétences (utilisé pour réaliser une tâche) aux nœuds du graphe, le
calcul de risque et enfin l’optimisation du niveau de risque. L’objectif général de cette
recherche est d’estimer le risque associé à une ressource critique basée sur le comportement
de l’attaquant et un ensemble de vulnérabilités que l’attaquant peut exploiter. Cette
approche implique un répertoire plus fin des stratégies d’atténuation des risques adaptées
à la menace plutôt que d’utiliser comme une seule réponse le blocage de la couverture
de l’activité réseau. Cependant, cette approche ne permet qu’une modélisation partielle
du risque dans l’infrastructure VoIP. En effet, le modèle de risque ne quantifie pas les
conséquences associées en cas de la réussite d’une attaque, bien qu’elles représentent un
élément primordial de ce modèle [95].
Les auteurs dans [125] ont modélisé statiquement le risque. Ce modèle permet à un

80
Chapitre 4 Processus et Modèles de Gestion des Risques

opérateur d’effectuer une analyse des risques en utilisant un modèle de données et un


modèle d’impact basé sur un graphe d’attaque. Ces deux modèles sont combinés avec
un modèle statistique de la communauté de l’attaquant exploitant ses compétences. Le
modèle de données décrit les lignes de données entre les nœuds du réseau. De plus, il
décrit comment les lignes sont copiées et traitées par des logiciels et des hôtes. Le modèle
d’impact décrit la façon dont les vulnérabilités sont exploitées afin d’affecter les lignes de
données de point de vue disponibilité des données, confidentialité et intégrité. En outre,
les auteurs peuvent évaluer le coût de la réussite d’une attaque en accordant une valeur
de perte à un ensemble de données compromises. Ainsi, en modélisant le flux de données,
les auteurs prennent en compte les dépendances entre les différents hôtes et les différents
flux de données. En outre, ils sont en mesure de mettre à jour le calcul du risque dès
qu’ils reçoivent plus de données d’attaque. Les auteurs ont proposé également d’utiliser
un honeypot pour recueillir des données d’attaque historiques. Toutefois, afin de modéliser
la compétence de l’exploitation, chaque instance de vulnérabilité doit être classée par un
expert en exploitant les compétences du niveau requis.
Les auteurs dans [126] ont examiné le problème de l’évaluation du risque par l’inter-
ception d’un appel téléphonique VoIP. Le principe de base est de mener une analyse des
risques [127] qui consiste à prendre en considération les dépendances entre les vulnérabi-
lités du système : évidemment, ces dépendances sont strictement liées à l’architecture du
système. Dans ce contexte, le risque est une fonction de deux variables : le potentiel de
dommages, à savoir la perte moyenne causée par une attaque et le niveau d’exploitabilité
mesurant le niveau de facilité à endommager un composant du système. Dans ce cas, la
procédure d’évaluation des risques a l’intention de déterminer les niveaux d’exploitabilité.
Cette procédure présente cinq étapes : La première étape permet de construire l’arbre
d’attaque, la deuxième étape construit le graphe de dépendance entre les différentes vul-
nérabilités, la troisième étape permet d’évaluer l’exploitabilité, la quatrième étape propage
les dépendances et enfin la cinquième étape assure l’agrégation et l’évaluation des risques.
Ce modèle de risque permet d’évaluer le risque en se basant sur un schéma de vulnéra-
bilités cependant il ne prend pas en compte le paramètre de la potentialité d’attaque.
Ce paramètre est très important puisqu’il reflète la probabilité d’occurrence d’une telle
attaque.

4.3.2.2 Modèles quantitatifs des risques

Les auteurs dans [128] ont suggéré l’automatisation de la gestion des risques lors de
l’exécution : l’objectif est d’adapter dynamiquement l’exposition du réseau de la VoIP et
de ses équipements par rapport à la potentialité d’une attaque donnée. Cette automa-
tisation vise à renforcer le couplage entre la phase d’évaluation des risques et la phase
de traitement des risques. L’exposition est contrôlée d’une façon continue en fonction de
l’activation et la désactivation des contremesures. Une contremesure permet de réduire
l’exécution d’une attaque, mais elle peut aussi détériorer le service en introduisant des

81
Chapitre 4 Processus et Modèles de Gestion des Risques

retards supplémentaires ou en réduisant l’accès à certaines caractéristiques particulières.


Dans ce contexte, les auteurs ont étendu le modèle de risque d’exécution Rheostat [6]. Ce
modèle décrit le risque en se basant sur l’équation 4.3.1

R= P (a) × E(a) × C(a), (4.3.1)


X

a∈A

où a correspond à une attaque donnée et A est un ensemble d’attaques potentielles.


Le risque est généralement défini comme la combinaison de la potentialité de l’attaque
P (a), de l’exposition de l’infrastructure de la VoIP E(a) et de la conséquence C(a) sur
l’infrastructure si l’attaque réussit à atteindre ses objectives. Rheostat exploite un algo-
rithme de réduction des risques et un algorithme de relaxation des risques. L’algorithme
de réduction des risques permet de réduire le niveau de risque lorsque la potentialité de
l’attaque P (a) est élevée. Cette réduction est atténuée en activant les mesures de sécurité
(telles que les mots de passe et les tests de turing). Cette activation réduit l’exposition
E(a) de l’infrastructure, puis diminue ainsi le niveau de risque à une valeur acceptable.
L’algorithme de relaxation des risques permet de minimiser l’impact sur l’infrastructure
en désactivant des mesures de sécurité lorsque le niveau de risque est faible. Les auteurs
ont également défini une architecture fonctionnelle pour supporter la gestion des risques
proposée. Cette architecture est composée d’un système de détection d’intrusion respon-
sable de la détection des menaces dans la plateforme VoIP, un gestionnaire de risque pour
la gestion des risques et la sélection des mesures de sécurité dans un contexte donné, et
un serveur de configuration pour activer ou désactiver dynamiquement les mesures de
sécurité.
La solution proposée a assuré la réduction du niveau de risque d’une façon remarquable
tout en maintenant la continuité du service VoIP de manière dynamique. Cependant,
au cours de cette solution, la sélection des mesures de sécurité est effectuée d’une façon
progressive et séquentielle (c’est-à-dire les auteurs ajoutent les mesures de sécurité de la
plus faible efficacité au plus fort les unes à la suite des autres). Ce choix peut diminuer
la performance réelle du système proposé (de point de vue efficacité de réduction des
risques et temps de réponse). Ainsi, la sélection de la mesure de sécurité optimale est
une solution pour remédier à ce problème. Dans ce contexte, nous adoptons ce modèle
de risque pour concevoir notre système de gestion des risques. Cependant, nous traitons
différemment le risque. En effet, pour réduire l’impact d’une attaque sans sacrifier la
fonctionnalité du système, nous recherchons pour la mesure de sécurité optimale. Cette
mesure peut être une seule ou un ensemble de mesures combinées. Ces suppositions est
assurées en utilisant la métrique RORI puisqu’elle permet de sélectionner la mesure de
sécurité optimale permettant ainsi le meilleur compromis « sécurité-performance-coût ».

82
Chapitre 4 Processus et Modèles de Gestion des Risques

4.4 Conclusion
Il existe une relation entre la séquence des actions du réseau et le comportement de
l’attaquant. Cette relation peut être utilisée pour l’analyse et la gestion des risques du
réseau. La gestion des risques exige que les administrateurs identifient rapidement la
gravité des attaques potentielles et installent les correctifs qui limitent effectivement le
niveau de pénétration de ces attaques.
Dans ce chapitre nous avons élaboré une étude détaillée sur la gestion des risques dans
le contexte générale et dans le contexte de la VoIP. D’après cette étude, nous avons
pu estimer que la gestion des risques comprend essentiellement trois étapes de base :
l’identification des risques, l’évaluation des risques et le traitement des risques. Ainsi,
nous avons proposé l’aspect de notre système de gestion des risques. Une étude détaillée
de ce système sera accordé au chapitre 5.

83
Chapitre 5

Gestion des risques dans un réseau


VoIP

5.1 Introduction
La téléphonie sur IP est un service qui fonctionne en temps réel. De ce fait, elle nécessite
des performances de réseau suffisamment élevées tels qu’un faible taux de rejet d’appel
et une stabilité constante. Ces contraintes garantissent une continuité opérationnelle du
réseau. L’application des mécanismes de protection peuvent avoir un impact significatif
sur un tel service critique [129]. La gestion des risques offre de nouvelles perspectives à
l’égard de ce problème. Outre la découverte des scénarios à risque, elle permet d’expliquer
les mesures de sécurité nécessaire pour protéger le réseau VoIP. Dans ce contexte, nous
proposons une stratégie de gestion des risques afin d’adapter dynamiquement les méca-
nismes de protection du réseau par rapport à la menace potentielle. Ainsi, dans le but de
concevoir un système de gestion des risques, nous devons suivre les trois étapes suivantes :
identification, évaluation et traitement des risques. Pour cela, nous adoptons le modèle de
gestion des risques proposé dans [128]. Cependant, nous traitons différemment le risque.
En effet, pour réduire l’impact d’une attaque donnée tout en maintenant une bonne fonc-
tionnalité du système, nous proposons de sélectionner une contremesure optimale. Cette
dernière est choisie en fonction de la métrique RORI (Return On Response Investment)
qui garantit la réaction la plus appropriée.
Le reste de ce chapitre est organisé comme suit : La Section 5.2 donne un aperçu sur
la classification des contremesures et les différents travaux liés. La Section 5.3 introduit
la métrique RORI ainsi que la méthodologie de sélection des contremesures individuelles
et combinées. Dans la Section 5.4, nous proposons un processus de gestion des risques.
La Section 5.5 détaille les différents résultats expérimentaux. Nous concluons ce chapitre
dans la section 5.6.

84
Chapitre 5 Gestion des risques dans un réseau VoIP

5.2 Aperçu sur les contremesures


Dans cette section, nous proposons d’abord une classification des contremesures tout
en présentant les différents travaux liés. Ensuite, nous analysons les différentes méthodes
de sélection des contremesures.

5.2.1 Classification des contremesures


La réduction d’une attaque donnée dépend de la sélection optimale des mesures de
sécurité. Afin de sélectionner une contremesure, il est important d’identifier ses attributs
et ses propriétés, ainsi que les conséquences de son application. Par ailleurs, plusieurs
auteurs ont proposé des taxonomies de contremesures comme une stratégie qui vise à
analyser et évaluer les mécanismes de sécurité pour atténuer les intrusions et les attaques.
Les auteurs dans [130] ont proposé une taxonomie basée sur les objectifs de sécurité (tels
que la confidentialité, l’intégrité et la disponibilité). Cette dernière est utilisée comme
un environnement pour définir les coûts associés aux services de sécurité de réseau. Les
auteurs [131] ont proposé une taxonomie pour les technologies de sécurité de l’information.
Leur but est de sécuriser les informations au niveau de l’application, de l’hôte et du réseau.
La taxonomie proposée est divisée en deux principales parties : une partie proactive qui
regroupe des mesures utilisées comme une stratégie préventive (avant la violation de
la sécurité) ; et autre réactive qui regroupe les mesures utilisées comme une stratégie de
réponse (dès que la violation de sécurité est détectée). Les auteurs dans [132] ont représenté
une taxonomie de contremesures en se basant sur l’attaque cible. Ces contremesures sont
classées selon 4 dimensions : les normes et les politiques, la bibliothèque et les outils, la
gestion de l’administration et la gestion du système et les outils physiques. Les auteurs
ont présenté une évaluation de chaque technologie de sécurité et de son efficacité dans le
traitement des menaces et des risques possibles.
En se basant sur les travaux cités précédemment, nous proposons une classification des
contremesures en deux catégories proactive et réactive.

5.2.1.1 Contremesures proactives

Les contremesures proactives comprennent tous les contrôles de sécurité utilisés dans le
but de protéger l’infrastructure (actifs, information, réputation, etc.) contre les attaques
[133]. L’objectif principal d’une contremesure proactive est de sécuriser l’infrastructure et
de la rendre plus robuste. Ils existent plusieurs exemples de contremesures proactives tels
que les systèmes de prévention des intrusions (IPS), les dispositifs de contrôle de réseau
et les anti-virus.
Conformément à l’objectif de contremesure, une contremesure proactive peut être clas-
sée comme préventive, détective, dissuasive et déflective. Notons que les contremesures
dissuasives et déflectives peuvent être à la fois proactives et réactives.

85
Chapitre 5 Gestion des risques dans un réseau VoIP

Contremesures préventives

Les contremesures préventives représentent les mesures de sécurité destinées à être


implémentées avant la production d’une intrusion ou une attaque. Ces contremesures
cherchent à contrer les intrus avant de réussir leurs objectifs, ce qui permet de réduire la
probabilité de succès d’une telle intrusion. Des exemples de ces contremesures sont : les
mécanismes de contrôle d’accès, le cryptage, l’application de pare-feu, etc.

Contremesures détectives

Les contremesures détectives représentent les contrôles de sécurité utilisés pour dé-
tecter et pour signaler les événements non autorisés ou indésirables. Ces contremesures
comprennent toutes les équipements ou les techniques dont la mission est la surveillance
du système cible. Il s’agit d’analyser les données en comparant l’activité courante à des si-
gnatures d’attaques connues ou des comportements normaux. Des exemples de ces contre-
mesures sont : les IDS, la détection de mouvement, l’audit système, etc.

Contremesures dissuasives

Les contremesures dissuasives sont conçues pour décourager les attaquants en les invi-
tant à chercher d’autres systèmes plus importants, rapides et moins contrôlés que le pré-
sent système. Elles sont moins performantes que les contremesures préventives puisqu’elles
ne cherchent pas à empêcher l’intrusion. Des exemples de contremesures dissuasives com-
prennent l’affichage de quelques avertissements indiquant que l’accès aux serveurs est
surveillé, ou l’établissement des obstacles afin d’augmenter l’effort des utilisateurs non
autorisés.

Contremesures déflectives

Les contremesures déflectives ont pour rôle de tromper les attaquants. En effet, les
contremesures déflectives visent à séduire l’attaquant en le faisant croire qu’il a réussi
à accéder aux ressources du système alors qu’il est orienté vers un autre environnement
contrôlé pour l’observation. Des exemples de ces contremesures comprennent les faux
systèmes de mis en quarantaine, les faux comptes contrôlés, les pots de miel, etc [134].

5.2.1.2 Contremesures réactives

Les contremesures réactives représentent les mécanismes de sécurité qui visent à retarder
ou à arrêter les attaquants dans la réalisation de leurs objectifs [135][136]. Ces contreme-
sures nécessitent l’activation ou la désactivation des politiques de sécurité telles que le
blocage des utilisateurs, la désactivation des services et le refus d’accès. En fonction de
l’objectif visé, ces contremesures peuvent être classées comme responsives, récupératrices,

86
Chapitre 5 Gestion des risques dans un réseau VoIP

dissuasives ou déflectives. Nous expliquons dans la suite les deux premières catégories
étant données que les mesures dissuasives et déflectives ont été présentées.

Contremesures récupératrices

Les contremesures récupératrices visent à rétablir le système après la survenance d’un


incident ou d’une catastrophe. Des exemples de ces contremesures sont les systèmes de
récupération des catastrophes et les procédures de sauvegarde.

Contremesures responsives

Les contremesures responsives interviennent après la détection d’une attaque. Elles


visent à atténuer les effets et les conséquences d’une attaque donnée en retardant ou en
réduisant les dégâts. Ainsi, ces contremesures sont utilisées pour répondre à une attaque
et corriger l’incident. Des exemples de contremesures responsives sont l’élimination d’un
virus à partir d’un système infecté et la mise à jour du pare-feu pour bloquer une adresse
IP donnée.
Etant donnée la variété de types de contremesures avec des divers coûts, impacts et consé-
quences, il est intéressant de bien choisir la ou les contremesures les plus appropriées. Dans
la suite, nous proposons un aperçu des différents travaux antérieurs visant la sélection op-
timale des contremesures.

5.2.2 Travaux sur la sélection des contremesures


Divers travaux de recherche se sont intéressés à la sélection des contremesures. Dans
ce contexte, il existe des méthodes qualitatives de sélection des contremesures et des
méthodes quantitatives. Bistarelli et al. [137, 138] ont proposé des méthodes qualitatives
(telles que les defense trees et les conditional preference networks). Leur but est d’évaluer
et sélectionner les contremesures en fonction de connaissances des experts, de l’objectif
de l’organisation et d’autres critères utiles. Le degré d’automatisation de ces méthodes
est généralement faible, ce qui signifie que dans la plupart des cas, ces méthodes sont
statiques et nécessitent l’intervention humaine pour sélectionner la contremesure.
Duan et al. [139], Cavusoglu et al. [140], et Ferenc et Salim [141], ont suggéré des mé-
thodes quantitatives (telles que l’algorithme génétique, la théorie des jeux) qui utilisent
des métriques des coûts sensibles afin d’évaluer le rang et de sélectionner les contreme-
sures. Ces méthodes sont généralement dynamiques, et le degré d’automatisation est plus
élevé que celui présenté dans les méthodes qualitatives. Les méthodes quantitatives re-
posent sur des études dans lesquelles les données concernées sont analysées en termes de
nombres. Elles utilisent généralement un ou plusieurs métriques des coûts sensibles afin
d’effectuer l’évaluation et la sélection des contremesures. Ces métriques ont été proposées
comme une approche viable pour trouver un équilibre optimal entre les dommages d’in-
trusion et les coûts d’intervention. Elles permettent de garantir le choix de la réponse la

87
Chapitre 5 Gestion des risques dans un réseau VoIP

plus appropriée sans sacrifier les fonctionnalités du système [142].


Dans ce contexte, nous décidons de choisir une méthode de métriques des coûts sensibles
nommée retour sur l’investissement de réponse ou RORI (Return On Response Invest-
ment). Cette méthode a été initialement introduite par [143], ensuite elle a été améliorée
par [144]. Le but de cette méthode et de sélectionner la contremesure optimale assurant
ainsi un compromis entre « sécurité-efficacité-coût ». Dans le contexte de notre système,
nous employons cette méthode dans la phase de traitement des risques (Voir section 5.4)
pour réduire le risque tout en maintenant la continuité du système.

5.3 RORI (Return On Response Investment)


Dans cette section, nous décrivons en détail la métrique RORI. A cet effet, nous ana-
lysons les paramètres constitutifs de cette métrique et nous discutons le processus de
sélection d’une seule contremesure ainsi que des contremesures combinées.

5.3.1 Définition
La métrique RORI est un modèle de dépendance de service pour la réponse des coûts
sensibles basé sur la comparaison financière des options de réponse [143, 145]. Ce modèle
représente une adaptation du modèle ROSI (Return On Security Investment) [146, 147].
En effet, les paramètres qui constituent métrique RORI sont dérivés des paramètres ROSI
en faisant une analogie entre les coûts de la prévention des intrusions et les coûts de
réponse. La métrique RORI a été initialement introduite par Kheir et al. [143, 145].
Cependant, Gonzalez et al. [144] ont proposé une amélioration de l’indice RORI en tenant
compte des pertes prévues, qui peuvent survenir à la suite d’une attaque, et de la valeur
de l’infrastructure. L’expression du RORI améliorée est représentée par l’équation 5.3.1.

(ALE × RM ) − ARC
RORI = × 100, (5.3.1)
ARC + AIV

où :
— ALE (Annual Loss Expectancy) est la perte annuelle estimée qui représente le coût
de l’impact obtenu en absence de mesures de sécurité. ALE dépend directement de
la gravité de l’attaque et de la probabilité d’apparition. Ce paramètre est exprimé
en (€/an).
— RM (Risque Mitigation) est la Mitigation du Risque qui fait référence au niveau
d’atténuation des risques associés à une réponse particulière. Ce paramètre est ex-
primé en (% d’atténuation).
— ARC (Anuual Response Cost) est le coût annuel de la réponse engendré par une
nouvelle politique de sécurité. Ce paramètre est exprimé en (€/an).
— AIV (Annual Infrastructure Value) est la valeur annuelle de l’infrastructure qui
représente le coût annuel attendu du système indépendamment des contremesures
88
Chapitre 5 Gestion des risques dans un réseau VoIP

appliquées. Ce paramètre est exprimé en (€/an).


Dans la suite, nous allons exprimer en détail les paramètres du RORI afin de sélectionner
dans un premier temps la meilleure contremesure la plus adaptée puis dans le cadre d’une
généralisation, d’une combinaison de contremesures aidant à mieux gérer le risque.

5.3.2 Méthodologie de sélection d’une seule contremesure


Pour la sélection d’une contremesure optimale, nous allons procéder par calculer la
valeur du RORI de chaque contremesure à appliquer. Ainsi, la contremesure optimale
correspond à celle qui contient la valeur la plus élevée. Dans le cas où deux contremesures
ont la même valeur du RORI, la contremesure dont la valeur de l’ARC est la plus faible
est considérée comme optimale. Dans le but d’accomplir cette phase de sélection, nous
devons spécifier les valeurs de chaque paramètre du RORI.

Spécification des paramètres du RORI

La métrique RORI est considérée comme une approche quantitative qui permet d’éva-
luer et de sélectionner la meilleure contremesure qui minimise les effets d’une attaque
donnée. Le calcul des paramètres correspondants suit l’approche proposée par Kheir et
al. [143] pour le modèle RORI ainsi que Kosutic [148] et Lockstep Consulting [149] pour
le modèle ROSI. Dans le reste de cette section, nous allons détailler chaque paramètre.

ALE ( Annual Loss Expectancy)

L’ALE désigne le coût de l’impact produit en absence de contremesures. L’expression


de l’ALE est présentée par l’équation 5.3.2.

ALE = SLE × ARO, (5.3.2)

où :
— SLE (Single Loss Expectancy) représente toutes les pertes estimées,
— ARO (Annual Rate of Occurrence) est le taux annuel d’occurrence.
Pour estimer l’ALE, nous adoptons l’approche proposée par Lockstep [149]. L’approche
est présentée dans le Tableau 5.1 et le Tableau 5.2. Cette solution convertit l’estimation
qualitative de la sévérité (SLE) en valeurs quantitatives des coûts. De la même manière,
elle transforme la probabilité d’occurrence d’un incident en valeur d’ARO.

89
Chapitre 5 Gestion des risques dans un réseau VoIP

Sévérité Description Coût


Négligeable Pas d’impact si la menace est réalisée. 0€
Mineur Entraîne un effet mineur sur la valeur de l’actif. 1,000 €
Significatif Entraîne certains dommages tangibles men- 10,000 €
tionnés par quelques individus ou organismes.
Endommageant Peut causer des dommages à la réputation de 100,000 €
la gestion, et / ou une perte notable de la
confiance dans les ressources ou les services du
système.
Sérieux Peut provoquer une panne de système étendu, 1,000,000 €
et / ou une perte de clients connectés et / ou
une perte de la confiance des entreprises.
Grave Peut provoquer la fermeture du système de fa- 10,000,000 €
çon permanente.

Table 5.1 – Sévérité transformée en coûts probabilistes

Probabilité d’occurrence Description ARO


Négligeable Non susceptible de se produire 0.05
Très faible Avoir lieu deux/trois fois tous les cinq ans 0.50
Faible Avoir lieu une fois par an ou moins 1.00
Moyenne Avoir lieu une fois tous les six mois ou 2.00
moins
Elevé Avoir lieu une fois par mois ou moins 12.00
Très élevé Avoir lieu plusieurs fois par mois ou moins 50.00
Extrême Avoir lieu plusieurs fois par jour 500.00

Table 5.2 – Probabilité d’occurrence transformé en ARO

Suite à cette solution, un SLE «sérieux» représente un coût de 1,000,000 € tandis qu’un
SLE «mineur» représente un coût de 1 000 €. Ainsi, une «faible probabilité» représente
une valeur de ARO=1 alors qu’une «forte probabilité» représente une valeur de ARO =
12.00.

AIV ( Annual Infrastructure Value)

L’AIV représente la somme des coûts des outils de sécurité (à savoir le coût de l’équi-
pement, le coût lié aux personnels, les coûts de service) estimée pour le système quelle
que soit la contremesure implémentée. Il est calculé comme étant la somme de la valeur
annuelle de tous les équipements préliminaires de sécurité (à savoir les PEP (Policy En-
forcement Points)). Ces équipements assurent un niveau de sécurité acceptable dans la
première phase de l’architecture du système.

RM ( Risque Mitigation)

Le RM fait référence à l’atténuation du risque associée à une contremesure donnée.


L’expression du RM est donnée par l’équation 5.3.3.
90
Chapitre 5 Gestion des risques dans un réseau VoIP

RM = EF × SC, (5.3.3)

où :
— EF (Effectiveness Factor) est le facteur d’efficacité qui estime le pourcentage de
réduction du coût de l’incident total donné à partir de l’exécution d’une mesure de
sécurité,
— SC (Surface Coverage) est la surface de couverture qui représente le pourcentage de
la surface d’attaque couverte et contrôlée par une contremesure donnée.
Afin d’assurer le calcul de RM, nous sommes censés de calculer la surface de couverture
de contremesure ainsi que son niveau d’efficacité.
Selon l’équipe Microsoft SDL [150], la surface de couverture représente le pourcentage
des actifs et des menaces qui sont contrôlées par une contremesure donnée. Dans le système
proposé, la couverture de surface est considérée comme étant le pourcentage de la détection
d’une attaque.
Nous suivons l’approche Rheostat [6] afin de quantifier le facteur d’efficacité EF. Cette
approche définit le risque d’une attaque (R) comme étant le produit de l’Exposition de
l’infrastructure (E), de la Potentialité de l’attaque (P) et de la Conséquence (C) de cette
attaque sur les ressources de l’infrastructure (c.à.d, R = E × P × C). Par conséquent, l’EF
est considéré comme étant le pourcentage de réduction du risque résultant de l’application
d’une contremesure donnée. Ainsi, supposons que Ravant = 0, 25 est le risque d’une attaque
donnée avant l’application de contremesures et Raprès = 0, 11 est le risque résultant après
l’application d’une contremesure donnée. L’efficacité est donc exprimée par l’équation
5.3.4.
(Ravant × 100)
EF = 100 − = 56%. (5.3.4)
Raprès

ARC ( Anuual Response Cost)

L’ARC désigne tous les coûts associés à une contremesure donnée (coût d’implémenta-
tion, coût d’entretien et coût des dommages). Afin d’estimer l’ARC, il faut identifier les
coûts directs et indirects. Il est possible de déterminer ces coûts en se basant sur une base
de connaissances des experts et des données statistiques.
Suite à la spécification détaillée de chaque paramètre du RORI, nous pouvons remarquer
que les paramètres ALE et AIV sont statiques et dépendent de l’intrusion ou de l’attaque
détectée. Par contre, les paramètres RM et ARC sont variables et dépendent des mesures
de sécurité proposées.

5.3.3 Méthodologie de sélection de contremesures combinées


Les contremesures combinées resultant de la mise en œuvre de deux ou plusieurs me-
sures de sécurité sont appliquées simultanément pour atténuer une attaque donnée. Une

91
Chapitre 5 Gestion des risques dans un réseau VoIP

contremesure combinée est donc analysée comme étant une mesure de sécurité unique
avec un coût combiné et une efficacité combinée.
Le processus de sélection de la combinaison optimale de contremesures est effectué en
deux étapes : l’évaluation de la contremesure individuelle d’évaluation puis l’évaluation
des contremesures combinées. L’étape de l’évaluation de la contremesure individuelle nous
permet de déterminer les paramètres associés à l’intrusion ou d’attaque (par exemple, ALE
et AIV) et d’évaluer ainsi la métrique RORI pour toutes les solutions individuelles. L’étape
de l’évaluation des contremesures combinées nous permet de déterminer les paramètres
associés aux solutions combinées (par exemple, ARC et RM) et d’évaluer la métrique
RORI pour toutes les solutions combinées.
Mathématiquement, pour combiner plusieurs contremesures, nous devons calculer leur
union et leur surface d’intersection [151]. Etant donné que généralement les surfaces cou-
vertes de multiples contremesures se chevauchent, l’utilisation de plusieurs paramètres (à
savoir la probabilité d’événements, les modèles et les approches combinatoires) est impor-
tante dans le but d’estimer la valeur d’atténuation exacte d’une solution combinée. Dans
ce contexte, la contremesure est considérée comme étant un événement. La probabilité
d’un événement correspond à sa probabilité d’occurrence. Afin de définir l’occurrence de
plusieurs événements, nous distinguons deux cas : Les événements mutuellement exclusifs
et les évènements non-mutuellement exclusifs.

Evénements mutuellement exclusifs

Les événements sont dit mutuellement exclusifs si elles ne peuvent pas se produire
simultanément. Considérons A1 , A2 , .., An une séquence de n événements, la probabilité
d’union de plusieurs événements est exprimée par l’équation 5.3.5 [152].
n n
P( Ai ) = P (Ai ). (5.3.5)
[ X

i=1 i=1

L’intersection de plusieurs événements est représentée par l’équation 5.3.6.


n
P( Ai ) = 0. (5.3.6)
\

i=1

Evénements non-mutuellement exclusifs

Dans le cas où les événements non-mutuellement exclusifs, tous les événements peuvent
se produire dans le même temps. Pour cela, considérons A1 , A2 , .., An une séquence de n
événements, l’union de plusieurs événements est présentée dans l’équation 5.3.7.
n n
!
P (Ak ) − P (Ai ∩ Aj ) + P (Ai ∩ Aj ∩ Ak )
[ X X X
P Ai '
i=1 k=1 1<i<j<n 1<i<j<k<n

+... + (−1) n+1


P (A1 ∩ A2 ∩ ... ∩ An ) . (5.3.7)

92
Chapitre 5 Gestion des risques dans un réseau VoIP

L’intersection de plusieurs événements est représentée par l’équation 5.3.8.


n n
!
Ai = P (Ai ) . (5.3.8)
\ Y
P
i=1 i=1

Lorsque deux ou plusieurs contremesures sont mises en œuvre pour atténuer une attaque
donnée, leur combinaison n’affecte que le RM et l’ARC. Ainsi la valeur de l’ALE et la
valeur l’AIV restent inchangées puisque ces deux paramètres dépendent seulement de
l’attaque. Dans ce qui suit, en se basant sur les travaux de [142], nous évaluons le RM et
l’ARC dans le contexte des contremesures combinées.

Expression de l’ARC des contremesures combinées

Le coût des contremesures combinées est définit comme étant la somme de l’ensemble
des coûts de contremesures individuelles. Il est exprimé par l’équation 5.3.9.
n n
!
Ci = ARC (Ci ) , (5.3.9)
[ X
ARC
i=1 i=1

où Ci est une contremesure individuelle.

Expression du RM des contremesures combinées

La combinaison de RM est autorisée uniquement lorsque les contremesures ne sont


pas mutuellement exclusives ( c-à-dire, les contremesures peuvent être parfaitement com-
binées) et la surface d’une contremesure n’est pas totalement couverte par une autre
contremesure. Dans ce cas, l’atténuation du risque est calculée en se référant à l’équation
5.3.7 et ainsi exprimé par l’équation 5.3.10.
n n
!
= RM (Ck ) − RM (Ci ∩ Cj )
[ X X
RM Ci
i=1 k=1 1<i<j<n

+ RM (Ci ∩ Cj ∩ Ck )
X

1<i<j<k<n

+... + (−1)n+1 RM (C1 ∩ C2 ∩ .... ∩ Cn ) . (5.3.10)

En remplaçant le RM par son expression, l’équation devient


n n
!
= SC (Ck ) × EF (Ck ) − SC (Ci ∩ Cj ) × EF (Ci ∩ Cj )
[ X X
RM Ci
i=1 k=1 i<j

+ SC (Ci ∩ Cj ∩ Ck ) × EF (Ci ∩ Cj ∩ Ck )
X

i<j<k

+... + (−1) n+1 SC (C1 ∩ ... ∩ Cn ) × EF (C1 ∩ ... ∩ Cn ) . (5.3.11)

La surface de couverture de l’intersection des contremesures est calculée comme étant


la moyenne des bornes inférieures et supérieures [142]. En effet, l’intersection de deux

93
Chapitre 5 Gestion des risques dans un réseau VoIP

ou plusieurs surfaces de couverture varie de zéro dans sa limite inférieure, à la surface


de couverture minimal du groupe de contremesures dans sa limite supérieure (c.-à-d.
min {SC (C1 ) , ..., SC (Cn )}). Ici deux cas se distinguent : le cas des surfaces jointes et le
cas des surfaces disjointes.
Une surface de couverture d’une contremesure est considérée comme disjointe d’une
autre surface si les deux surfaces n’ont aucun élément en commun. Dans ce cas, la surface
de couverture de l’intersection est nulle.
Une surface de couverture d’une contremesure est considérée comme jointe si elle est
partiellement ou totalement recouverte par une surface de couverture d’une autre contre-
mesure. Ainsi, dans le cas d’une surface partiellement recouverte, la surface de couverture
de l’intersection représente la moyenne des limites inférieures et supérieures. Son expres-
sion est donnée par l’équation 5.3.12.
 n   n 
+ SC
T T
n
! SC Ci Ci
i=1 inf i=1 sup
Ci = (5.3.12)
\
SC ,
i=1 2

où la valeur des bornes inférieures est exprimée par l’équation 5.3.13.


n

0 SC (Ci ) ≤ n − 1
P
n
! 
 Si
= (5.3.13)
\
SC Ci i=1 ,
n n
 SC(Ci ) − (n − 1) SC (Ci ) > n − 1
P P
Si

i=1 inf

i=1 i=1

et la valeur des bornes supérieures, représentant la couverture totale de la surface la plus


petite, est exprimée par l’équation 5.3.14.
n
!
= min {SC (C1 ) , .., SC (Cn )} . (5.3.14)
\
SC Ci
i=1 sup

Dans le cas d’une surface de couverture totalement recouverte par celle d’une autre
contremesure, la surface de couverture de l’intersection représente la couverture totale de
la surface la plus petite (équation 5.3.14)
L’efficacité de l’intersection est calculée en tenant compte des bornes supérieures et est
donnée par l’équation 5.3.15.
n n
! !
= EF
\ \
EF Ci Ci
i=1 i=1 sup
= min {EF (C1 ) , .., EF (Cn )} . (5.3.15)

La procédure de sélection d’une contremesure individuelle ou de combinaison de contre-


mesures représente une solution adaptée par notre système de gestion des risques afin de
réduire l’effet d’une attaque donnée sur le réseau VoIP.
Dans la section suivante, nous expliquons en détail chaque phase du processus proposé

94
Chapitre 5 Gestion des risques dans un réseau VoIP

du système de gestion des risques.

5.4 Processus proposé de gestion des Risques


Nous proposons dans cette section un nouveau concept de gestion des risques dans
les réseaux et les services VoIP [153, 154]. Nous considérons le cas des attaques SPITs
pour évaluer la faisabilité et l’efficacité de notre approche. Notre objectif est d’appliquer
la solution la plus optimale assurant une réduction de risque avec un coût raisonnable.
Cette solution peut être effectuée suite à l’application d’une seule contremesure ou d’une
combinaison de deux ou plusieurs. Le processus proposé est représenté par la Figure
5.4.1. Ce processus comprend trois étapes de base à savoir l’identification des risques,
l’évaluation des risques et le traitement des risques.

Application de la méthode
de détection des SPITs

Spécification de la liste
des SPITs potentiels
(1) Identification des risques

Evaluation du risque
(2) Evaluation des risques

Risque > Seuil


Non Oui

Acceptation Spécification de la liste


du risque des contremesures

Spécification de toutes Calcul du RORI


les combinaisons possibles de chaque contremesure

Calcul du RORI de chaque


combinaison

Sélection de la
meilleure solution

Réduction du risque

(3) Traitement des risques

Figure 5.4.1 – Processus proposé de gestion des risques

95
Chapitre 5 Gestion des risques dans un réseau VoIP

5.4.1 Identification des risques


Dans cette étape, nous appliquons notre méthode de détection de SPITs déjà propo-
sée dans le Chapitre 3 [155][156]. Selon cette méthode, nous collectons les traces réseau
d’activités vocales et de signalisation. Ces traces sont utiles pour extraire les critères
d’identification des attaques SPIT tels que le taux de rejet d’appel, le nombre moyen
d’appel par appelant, la durée moyenne d’appel, le taux du trafic, le taux des appels et le
temps moyen entre deux appels. Nous utilisons le classificateur AdaBoostM1 permettant
de révéler les activités suspectes. Ce choix a été argumenté dans le Chapitre 3. En effet,
ce classificateur nous a donné le meilleur taux de détection de SPITs.

5.4.2 Evaluation des risques


Pour évaluer le risque, nous choisissons un modèle quantitatif de risque. Ce modèle est
très significatif pour un service critique et interactif telle que la VoIP. Ainsi, il va nous
permettre d’avoir une idée claire sur le niveau de risque, et d’automatiser les processus de
gestion des risques. Pour développer notre modèle de risque, nous adaptons le modèle de
risque de [128]. Ce modèle s’appuie sur le formalisme introduit par Rheostat [6]. Ceci, va
nous permettre d’examiner les propriétés de notre infrastructure VoIP. Une description
détaillée sur ce modèle ainsi que sur l’approche quantitative est déjà donnée dans le
Chapitre 3.
Le niveau de risque peut être exprimé par l’équation 5.4.1.

R= P (tα ) × E(tα ) × C(tα ), (5.4.1)


X

où :
— tα est la signature d’attaque,
— P (tα ) est la potentialité d’attaque,
— E(tα ) est l’exposition de l’hôte face à la menace en fonction de contremesure,
— C(tα ) est la conséquence de l’attaque de l’infrastructure VoIP.
La potentialité d’attaque est calculée en utilisant notre système de détection de SPIT. Ce
système évalue plusieurs paramètres pour décider la nature de l’activité de la voix sur IP.
L’expression de la potentialité d’attaque P (tα ) est définie par l’équation 5.4.2.

P (tα ) = β × CallDurationRate + γ × CallRejectionRate + δ × CallrecipientRate


+ε × CallRate + ζ × CallinterRate + η × T raf f icRate , (5.4.2)

où {β, γ, δ, ε, ζ, η} est un ensemble de facteurs de pondération spécifiés en se basant sur


l’étude décrite dans [68]. D’après cette étude, les valeurs de {β, γ, δ, ε, ζ, η} correspondent
à {0.3, 0.05, 0.5, 0.02, 0.03, 0.1}.
L’exposition de l’infrastructure VoIP face à une menace dépend des contremesures qui

96
Chapitre 5 Gestion des risques dans un réseau VoIP

sont activées ou désactivées dans le réseau. Ces mesures de protection sont utilisées afin
de réduire la vulnérabilité du service VoIP. L’exposition E(tα ) est exprimée par l’équation
5.4.3
E(tα ) = 1 − imp(tα ) × active(ci ) (5.4.3)
X

ci ∈C


— C = {c1 , ..., cn } l’ensemble de contremesures destinées pour contrer l’attaque tα ,
— imp (tα ) désigne une valeur normalisé de l’impact de la contremesure ci sur l’at-
taque tα . Cette valeur est comprise entre 0 et 1. Ainsi, elle dépend des autres
contremesures activées. En effet, la valeur de l’impact peut être réduite si une autre
contremesure est appliquée parallèlement.
— active (ci ) est une fonction booléenne qui indique si la contremesure ci est active ou
non. Ainsi, l’exposition E(tα ) peut prendre la valeur de 1 si aucune des contreme-
sures n’est activée.
Enfin, la conséquence C(tα ) de l’attaque considérée représente une valeur normalisée pre-
nant des valeurs importantes lorsque plusieurs menaces sont évoquées.

5.4.3 Traitement des risques


Après l’étape de l’évaluation du risque, nous comparons la valeur actuelle du risque
avec une valeur de seuil Rthreshold . Si cette valeur est inférieure à Rthreshold , le risque
est accepté. Dans le cas contraire, un ensemble de contremesures sont définies afin de
réduire le risque. La réduction du risque peut être effectuée en utilisant une contremesure
individuelle ou un ensemble de contremesures combinées. Ce choix dépend de la valeur
du RORI correspondante. En effet, seulement la solution optimale est choisie pour être
appliquée. Ainsi, la solution la plus optimale correspond à la valeur de RORI la plus
importante. La Figure 5.4.1 représente une explication détaillée du processus de gestion
des risques.

5.5 Résultats expérimentaux


Afin d’évaluer la performance de notre solution, nous prenons comme entrée les résultats
précédemment décrits dans notre système de détection de SPITs (voir Chapitre 3). Selon
cette étude, 333 Spitters ont été détectés. Nous avons choisi un SPITter dont les valeurs de
n
ses paramètres CallDurationRate , CallRejectionRate , Call- recipientRate , CallRate , Callin−
o
terrate , T raf f icRate sont{0.51, 0.55, 0.06, 0.17, 0.87, 0.83} respectivement. Ainsi, en ap-
pliquant l’équation 5.4.2, le niveau de SPIT correspond à SP ITLevel = P = 0.48. En
tenant compte de la valeur de P , nous supposons que C = 0.4. Par la suite, cette valeur
peut être variée selon les contremesures appliquées. Ce type d’attaque peut être généré par
deux types d’entités : les humains qui effectuent des appels pour des raisons commerciales
et les robots qui initient des sessions en utilisant un ensemble d’adresses déjà collectées.
97
Chapitre 5 Gestion des risques dans un réseau VoIP

Au cours de la détection des attaques de SPITs, nous évaluons le niveau de risque


comme suit : Ravant = P × E × C = 0.48 × 1 × 0.4 = 0.19. Cette valeur correspond au
niveau de risque avant l’application des contremesures. Ainsi, La valeur de l’exposition E
est estimée à 1 (par l’absence de contremesures appliquées). Nous assumons que la valeur
de seuil Rthreshold = 0.15 (la fixation de cette valeur est relative à une valeur seuil de la
potentialité d’attaque estimé à 0.4). Dans ce cas, le risque ne peut pas être accepté. Ainsi,
nous devons sélectionner certaines contremesures afin de réduire ce risque.
Pour contrer les attaques de SPITs, nous choisissons une liste de cinq contremesures
différentes initialement définies et évaluées dans [128]. La liste est indiquée ci-dessous :
— C1 : envoi un message occupé « busy » à l’appelant,
— C2 : demande de saisie d’un code particulier à l’appelant,
— C3 : demande de répondre à une question spécifique,
— C4 : mise en place de l’appelant dans une file d’attente.
— C5 : blocage de l’appelant.
Les contremesures C1, C2, C3 et C4 correspondent à des contremesures proactives et plus
précisément préventives puisqu’elles permettent de protéger le système avant la production
de l’attaque. La contremesure C5 correspond à une contremesure réactive puisqu’elle
permet d’empêcher l’attaquant à atteindre son objectif en le bloquant. De plus, C1, C2, C3
et C4 peuvent être considérées comme des contremesures non mutuellement exclusives et
peuvent être ainsi parfaitement combinées. Cependant, la contremesure C5 est considérée
comme mutuellement exclusive. En effet, nous ne pouvons pas combiner le blocage avec
d’autres contremesures.
Nous calculons la métrique RORI de chaque contremesure ainsi que des tous les com-
binaisons possibles pour sélectionner la solution optimale. Dans ce cas, soit nous allons
opter le choix d’une seule contremesure, soit d’un ensemble de contremesures combinées.
Dans le cas d’une contremesure individuelle, les paramètres de RORI (ALE , AIV ,
RM , ARC) sont évalués comme suit :
— Le SPITter sélectionné a une sévérité estimée « mineur » [128]. En se basant sur le
Tableau 5.1, le coût équivalent est 1000€. Sa probabilité d’occurrence est considérée
«Moyenne» (0, 2 < SpitLevel < 0, 5). Ainsi, en se basant sur le Tableau 5.2, la valeur
d’ARO est équivalente à 2.
— L’ALE est alors équivalente à 2000€ = 2 × 1000 (voir équation 5.3.2)
— L’AIV est calculée comme étant la valeur de tous les PEP qui sont nécessaires pour
être déployés dans la phase préliminaire de l’architecture du système. Nous choisis-
sons Snort en tant que système de détection d’intrusion, avec AIV = 400€ et Cisco
SA 500 Series en tant que système de prévention des intrusions avec AIV = 1000€
[157]. L’AIV est donc estimée à 1400€ (le coût de toutes les solutions choisies).
Le Tableau 5.3 montre les différentes contremesures proposées pour contrer l’at-
taque SPIT. Pour estimer l’exposition et l’impact relatifs à chaque contremesure,
nous nous appuyons sur les résultats de [128]. Pour les autres paramètres, ils sont

98
Chapitre 5 Gestion des risques dans un réseau VoIP

calculés en tenant en compte les différentes équations citées dans la Section 5.3.
— L’ARC de chaque contremesure est estimé en fonction de son impact sur la perfor-
mance du service VoIP. Ainsi, nous utilisons la simulation de Monte Carlo comme
solution d’estimation. Cette approche utilise une séquence aléatoire de nombres pour
construire un échantillon de la population, à partir de laquelle on obtient des es-
timations statistiques du paramètre en question [158]. Après 250 itérations, nous
obtenons la valeur de l’ARC de chaque contremesure.

Contremesures Exposition Impact Coût SC EF


C1 0.9 0.1 50 € 0.1 0.271
C2 0.7 0.4 100 € 0.3 0,706
C3 0.6 0.5 140 € 0.4 0.820
C4 0.3 0.8 300 € 0.7 0.982
C5 0.1 0.9 550 € 0.9 0.990

Table 5.3 – Caractéristiques des contremesures supportant le processus proposée de ges-


tion des risques

Le Tableau 5.4 donne un résumé des paramètres qui composent la métrique RORI.

Contremesures ALE AIV ARC SC EF RM RORI


C1 2000 € 1400 € 50 € 0.1 0.271 0.0271 0,2896
C2 2000 € 1400 € 100 € 0.3 0,706 0.2218 21,57
C3 2000 € 1400 € 140 € 0.4 0.820 0.3280 33,50
C4 2000 € 1400 € 300 € 0.7 0.982 0.6874 63,22
C5 2000 € 1400 € 550 € 0.9 0.990 0.8910 63,17

Table 5.4 – Evaluation des contremesures

Selon le Tableau 5.4, la première alternative (C1) a une efficacité EF et une surface de
couverture SC négligeable. Par conséquent, la réduction du risque reste insignifiante. Dans
l’autre sens, les deux contremesures C4 et C5 fournissent une grande réduction du risque
(68 − 89%). La valeur de RORI de C4 et C5 est équivalent à 63, 22% et 63, 17% respec-
tivement. Nous pouvons remarquer que la réduction du risque de C5 est plus importante
que C4. Toutefois, son coût de mise en œuvre (ARC) est très élevé. Pour cette raison, le
RORI de C4 est le meilleur. Comme conclusion, nous pouvons admettre que dans le cas
de contremesure individuelle, C4 est la contremesure optimale. Cette contremesure est la
mieux adaptée pour contrer le SPITter.
Dans le cas de contremesures combinées, les paramètres ALE et AIV restent inchangés.
Le changement ne concerne que l’ARC et le RM (où apparaît l’influence directe de contre-
mesure). Aussi, nous considérons que les surfaces de couvertures des contremesures sont
partiellement recouvertes par les autres contremesures. Ainsi, afin de calculer le RORI
des contremesures combinées, nous procédons par identifier toutes les combinaisons pos-
sibles. Dans ce contexte, seules les contremesures non mutuellement exclusives (peuvent

99
Chapitre 5 Gestion des risques dans un réseau VoIP

être parfaitement combinées) sont choisies pour être combinées. Dans ce cas, C1, C2, C3
et C4 représentent les contremesures qui peuvent être combinées. En effet, C5 est exclus
puisqu’elle est considérée comme une contremesure mutuellement exclusive (ne peut pas
être combinée avec les autres). En se basant sur le tableau 5.4, C1 représente une faible
valeur de RORI. Ainsi, C1 est exclue de la combinaison puisqu’elle ne va pas apporter
une amélioration pour la réduction du risque. De ce fait, nous sélectionnons C2, C3 et
C4 en tant que candidates pour la combinaison. L’ensemble de toutes les combinaisons
possibles est définit comme étant la somme de la nème rangée des coefficients binomiaux
[159] et exprimée par l’équation 5.5.1.
!
n
= 2n − 1 − n, (5.5.1)
X

0<k<n k

où n est le nombre d’éléments à combiner. Ainsi, pour un groupe de 3 contremesures (C2,


C3 et C4), le nombre maximal de combinaisons possibles est le suivants : 23 − 1 − 3 = 4.
Les différentes valeurs du RORI ainsi que ses paramètres, dans le cas des contremesures
combinées, sont illustrées dans le Tableau 5.5.

Contremesures ALE AIV ARC SC EF RM RORI


C2+C3 2000 € 1400 € 240 € 0.15 0.70 0.433 38.28
C2+C4 2000 € 1400 € 400 € 0.15 0.70 0.793 65.92
C3+C4 2000 € 1400 € 440 € 0.25 0.82 0.810 58.73
C2+C3+C4 2000 € 1400 € 540 € 0.15 0.70 0.916 66.62

Table 5.5 – Evaluation du RORI pour les contremesures combinées

Comme le montre le tableau 5.5, la combinaison (C2+C3) a un faible effet sur la réduc-
tion de l’attaque. Son RORI est ainsi très réduit. Nous pouvons remarquer également que
les meilleures combinaisons sont celles du (C2+C4) et (C2+C3+C4). En effet, ces deux
combinaisons fournissent une réduction de risque très importante (79-91%). Le RORI du
(C2+C4) et (C2+C3+C4) est égale à 65.92% et 66.62% respectivement. Nous pouvons
remarquer que le coût de mise en œuvre ARC de C2 + C3 + C4 est très élevé. Toutefois,
son effet de réduction du risque est très important. Ainsi, la combinaison C2 + C3 + C4
est la meilleure.
En comparant le RORI de la meilleure contremesure individuelle avec celle des contre-
mesures combinées, nous pouvons confirmer que C2 + C3 + C4 est la solution optimale
pour contrer l’attaque de SPITs.
En conclusion, le modèle proposé montre l’efficacité de l’utilisation de la métrique de
RORI dans la gestion des risques pour lutter contre les SPITs. Dans la plupart des cas, les
contremesures combinées fournissent une valeur plus élevée de RORI et donc un avantage
supérieur au système. En outre, la combinaison de deux ou plusieurs politiques de sécurité
couvre une plus grande surface du risque, qui se traduit par un niveau d’atténuation
des risques très élevé. Cependant, il est à noter que la valeur élevée d’atténuation du

100
Chapitre 5 Gestion des risques dans un réseau VoIP

risque ne signifie pas toujours une valeur supérieure de RORI. De même, la solution la
moins coûteuse ne signifie pas toujours une valeur inférieure de RORI. Ainsi, plusieurs
paramètres sont pris en compte afin de choisir la solution qui offre le meilleur rapport
coût-efficacité du système. Cette solution correspond à la valeur du RORI la plus élevée.

5.6 Conclusion
Dans ce chapitre, nous avons proposé un nouveau processus de gestion des risques
dans le réseau VoIP. Nous avons appliqué ce processus sur les SPITs afin d’évaluer la
faisabilité et l’efficacité. Notre modèle de risque comprenait trois étapes : l’identification
des risques, l’estimation des risques et le traitement des risques. Dans la première étape,
nous avons utilisé un modèle de détection d’intrusion basée sur le classifieur AdaBoost
pour détecter les attaques SPIT et évaluer leurs paramètres d’identification. Dans la
deuxième étape, nous avons adopté le modèle Rheostat pour évaluer le risque. Enfin,
nous avons choisi la contremesure optimale ( individuelle/combinée) comme une solution
pour contrer l’attaque. Pour cela, nous avons utilisé la métrique RORI dans le but de bien
choisir la meilleure solution et donc réduire le risque. La meilleure solution correspond
à la métrique RORI la plus élevée. Cette solution représente un bon compromis entre la
sécurité et le coût. Dans notre expérience, nous avons montré que la combinaison de trois
contremesures représente la réaction adéquate contre les attaques SPITs.

101
Conclusion et perspectives

Rappel des objectifs

Le SPIT représente la transposition du SPAM dans le monde de la VoIP. C’est une


menace qui a vu le jour grâce à la quasi-gratuité de la téléphonie sur Internet. Son effet
par contre est beaucoup plus gênant. En effet, les appels téléphoniques en quantité massive
et dans les heures de repos peuvent facilement déranger les utilisateurs.
Les attaques de type SPIT sont difficiles à détecter du fait que le traitement des paquets
de la voix doit s’effectuer en temps réel. De plus, les messages de signalisation d’un
utilisateur légitime et d’un attaquant SPITter sont semblables.
Ce travail de recherche comprend deux objectives de base : Le premier objectif consiste
à concevoir un système anti-SPIT moyennant l’utilisation d’une approche comportemen-
tale. Le deuxième objectif consiste à proposer un système de gestion des risques. Ce
système a pour but de résoudre le problème induit par l’approche comportementale. En
effet, le système anti-SPIT proposé a montré une grande efficacité pour la détection de
SPIT. Cependant, il peut provoquer un impact négatif sur les performances du service de
téléphonie en termes de disponibilité et de qualité de service. Ainsi, la gestion des risques
est une solution qui offre de nouvelles perspectives en ce qui concerne ce dilemme.

Bilan des travaux effectués

Pour concevoir notre approche comportementale nous avons utilisé neufs critères pour
détecter les attaques SPIT. Ainsi, nous avons déployé une topologie d’un réseau VoIP dans
un environnement OPNET. Par le biais de la simulation, nous avons prélevé les traces
réseaux de la signalisation et de l’activité vocale afin d’extraire les critères d’identification
des attaquants SPITter. Nous avons implémenté tout d’abord un algorithme de détection
des SPIT afin de spécifier les critères les plus influents dans la détection. Ensuite, nous
avons utilisé le concept de la « fenêtre glissante » pour maintenir correctement les traces
réseaux et les profils des appelants. De plus, nous avons mené une étude comparative de
dix méthodes de classification supervisée (NaiveBayes, BayesNet, SMO RBFKernel, SMO
PolyKernel, MultiLayerPerceptron 2 couches et 3 couches, NBTree, J48, Bagging et Ada-
BoostM1) en utilisant le logiciel de fouille de données Weka. L’évaluation de performances
de ces méthodes a été réalisée via la métrique de traçage des courbes ROC.

102
Conclusion et perspectives

Afin de concevoir notre système de gestion des risques, trois étapes sont utilisées pour
assurer le bon fonctionnement du processus proposé à savoir l’identification des risques,
l’évaluation des risques et le traitement des risques. Concernant l’identification des risques,
nous avons appliqué notre méthode de détection de SPIT moyennant l’approche comporte-
mentale. Dans la phase de l’évaluation des risques, nous avons utilisé le modèle quantitatif
Rherostat qui repose sur l’évaluation de la potentialité d’attaque, l’exposition de l’infra-
structure et la conséquence de l’attaque. Enfin, durant la phase de traitement des risques,
nous avons utilisé la métrique RORI (Return On Response Investment) qui assure la
sélection d’une mesure de sécurité optimale. Cette mesure va assurer la réduction de l’im-
pact d’une attaque toute en maintenant une bonne fonctionnalité du système. Nous avons
appliqué l’RORI sur des contremesures individuelles et des contremesures combinées.

Apports, limites et perspectives

La méthode de détection de SPIT proposée a montré que les classeurs Bagging et


AdaBoostM1 sont les plus performants et s’approchent beaucoup du cas de détection
idéale. Cependant, nous devons explorer le système proposé dans un émulateur pour voir
son comportement dans un contexte réel.
Le système de gestion des risques a démontré que la combinaison de deux ou plusieurs
mesures de sécurité couvre une plus grande surface du risque, qui se traduit par un
niveau de réduction des risques très élevé. Cependant, il est à noter qu’une valeur élevée
de réduction du risque ne signifie pas toujours une valeur supérieure de RORI. De même,
la solution la moins coûteuse ne signifie pas toujours une valeur inférieure de RORI. Ainsi,
plusieurs paramètres sont pris en compte afin de choisir la solution qui offre le meilleur
compromis entre « sécurité-efficacité-coût » du système. Cette solution correspond à la
valeur de RORI la plus élevée.
Dans le cadre du système de gestion des risques proposé, nous avons utilisé des sta-
tistiques basées sur des travaux de littérature par manque de plateformes réels. Nous
estimons ainsi valider ce système pour un opérateur VoIP.
Comme perspectives de ces travaux de recherche, nous proposons les points suivants :
— Nous envisageons appliquer notre approche comportementale sur d’autres attaques
telles que le DOS et les messages malformés.
— Dans le contexte de gestion des risques, nous pensons appliquer le modèle proposé
sur d’autres attaques de la VoIP. Ceci afin de concevoir un système de gestion des
risques englobant toutes les types d’attaques VoIP ;
— Nous comptons utiliser d’autres modèles quantitatifs de sélection de contremesures
tels que : la matrice de décision [160] et la théorie des jeux [140] et observer ainsi
leurs apports sur la performance du système de gestion des risques proposé.

103
Conclusion et perspectives

— Nous pensons utiliser la stratégie de gestion de risques proposée sur d’autres services
à temps réel tels que : la vidéo à la demande (VoD) et la télévision IP. Le travail
consiste à juger si notre système de gestion de risques est facile à instancier dans ces
environnements et s’il existe des nouvelles menaces et des nouvelles contremesures
réalisables.

104
Annexes
Annexe A

Méthodologies d’apprentissage

Dans cette partie nous présentons les méthodes de classification utilisées : Réseaux
Bayésiens (Réseaux Bayésiens et Réseaux Bayésiens naïfs), Machines à Vecteurs Supports
(noyaux polynomial et radial), Perceptron Multi Couches (à deux et trois couches), Arbres
de Décisions (J48 et NBTree), Bagging et Adaboost.

A.1 Réseaux Bayésiens


Les réseaux bayésiens (RB) sont des graphes orientés acycliques, où les nœuds sont
représentés par des variables aléatoires et la structure décrit les dépendances condition-
nelles entre ces variables. Un RB est défini par un graphe causal orienté acyclique et un
ensemble de distributions locales de probabilités. Le graphe causal constitue une représen-
tation qualitative de la connaissance. Par exemple, s’il existe un arc d’un nœud B vers un
autre nœud A, donc la variable aléatoire B a une influence directe sur celle de A (c.-à-d.
B cause A). Tandis que l’ensemble de distributions locales de probabilités constitue une
représentation quantitative de la connaissance. Une table de probabilités conditionnelles
est associée à chaque nœud quantifiant les effets des parents. Un RB peut être illustré par
la Figure A.1.

B C

Figure A.1 – Exemple d’un Réseau Bayésien.

Le déroulement de classification par la méthode RB passe par ces deux phases [161] :
— Phase I : Apprentissage ou constitution du réseau

106
Annexe A Méthodologies d’apprentissage

Cette première phase consiste à trouver la structure du réseau et les probabilités


associées à partir de la base des données et des traitements statistiques.
— Phase II : Inférence Bayésien
A partir des résultats de la première phase, le réseau permet de calculer des pro-
babilités conditionnelles d’événements reliés les uns aux autres par des relations de
causalité.
Une variante du RB est le RB naïf. Il est caractérisé par une structure simple et unique
à deux niveaux seulement. Le premier niveau est constitué par un seul nœud parent et le
second par plusieurs enfants avec la forte hypothèse naïve d’indépendance entre les nœuds
enfants. La Figure A.2 illustre la structure d’un RB naïf.

x1 x9

x2 x8
x3 x7
x4 x5 x6

Figure A.2 – Structure d’un RB naïf.

Un RB naïfs est un classeur facile à programmer et souvent efficace. Néanmoins, il est


très sensible à la présence d’attributs corrélés.
Dans nos travaux, nous avons utilisé les méthodes RB et RB naïfs (appelés BayesNet
et NaiveBayes dans le package java open source Weka).

A.2 Machines à Vecteurs Supports


Les machines à vecteurs supports ont été proposées par Boser et al. [162] en 1992.
Cependant, Cortes et al. ont les nommées par SVM (Support Vector Machines) en 1995
[163]. Elles sont considérées généralement des classeurs bi-classes qui visent à distinguer les
exemples de chaque classe avec un hyperplan noté H. Cet hyperplan est optimal lorsqu’il
arrive à maximiser la distance entre H et les points les plus proches des deux classes.
La figure A.1 représente une illustration des SVM linéaires, où les points situés sur les
hyperplans H1 et H2 désignent les vecteurs supports.

107
Annexe A Méthodologies d’apprentissage

H1

H
Vecteurs
H2 de support

Marge maximale

Figure A.1 – Hyperplan linéaire dans R2 .

Dans l’objectif d’aborder des problèmes non linéaires, Boser et al. ont proposé des
frontières de décision non-linéaire avec les SVM [162]. L’idée principale est d’utiliser un
noyau de Mercer capable de projeter les données dans un espace plus grand permettant
la séparation linéaire des classes. Différentes formes de noyaux, vérifiant les conditions
de Mercer, ont été proposées. Ces fonctions noyau sont de type : linéaire, polynômial de
degré δ ou radial exponentiel (RBF : radial basis function). Il s’agit donc de déployer un
mécanisme aux SVM permettant la production des surfaces de décision non-planes. La
Figure A.2 montre un exemple de prolongement de R2 dans R3 .

Figure A.2 – Exemple de prolongement non-linéaire.

Les SVM présentent certains avantages en permettant d’aborder des problèmes non
linéaires grâce à l’utilisation des noyaux de Mercer. Néanmoins, elles présentent trois
inconvénients principaux. D’abord, les SVM ne permettent pas la construction des modèles
compréhensibles. Ensuite, elles sont inadaptées à la fouille de très grands volumes de
données puisque les calculs sont lourds. Enfin, le choix du noyau convenable ne peut pas
se faire qu’après la réalisation des essaies.
Une variante des SVM est appelée Sequential Minimal Optimization (SMO). Elle a
été proposée par Platt [164]. Dans nos travaux, nous avons utilisé cette variante. Ici, les
noyaux utilisés sont de type polynomial et radial.

108
Annexe A Méthodologies d’apprentissage

A.3 Perceptron Multi-Couches


Dans un perceptron multi-couches ou MLP (multilayer perceptron), les neurones sont
organisés en plusieurs couches successives, où chaque neurone d’une couche est connecté
à tous les neurones de la couche suivante. Cependant, il n’y a pas de connexion entre les
neurones qui appartiennent à la même couche. Un MLP est composé généralement d’une
couche d’entrée, une ou plusieurs couches cachées et une couche de sortie. L’ajout des
couches cachées permettent au réseau de concevoir des fonctions de décision complexes
non linéaires entre des unités d’entrée et de sortie. Dans un problème de classement, le
nombre d’unités d’entrée et de sortie dépend du problème à traiter, où chaque sortie est
dévouée à une classe donnée. Toutefois, le choix du nombre de couches cachées ainsi que
le nombre de neurones par couche cachée dépend du compromis entre la performance de
classification et la vitesse d’apprentissage souhaitées.
La Figure A.1 représente un réseau à deux couches (une seule couche cachée).
v1

x1
v2 y1

x2
yi

xk vj wij
wjk

Figure A.1 – Perceptron à deux couches.

Dans ce réseau, les unités de sortie, les unités cachées et les unités d’entrée sont repré-
sentées, respectivement, par yi , vj et xk . Les connexions des unités d’entrée aux unités
cachées et des unités cachées aux unités de sortie sont notées, respectivement, par wjk et
wij .
Dans la phase d’apprentissage d’un MLP, un algorithme de rétropropagation du gra-
dient de l’erreur est le plus utilisé [165]. Cet algorithme fonctionne avec deux phases :
— une phase de propagation qui vise à présenter les exemples à l’entrée du réseau.
Ensuite, elle propage cette entrée de proche en proche à partir de la couche d’entrée
jusqu’à la couche de sortie tout en passant par les couches cachées ;
— une phase de rétropropagation qui permet de minimiser l’erreur commise sur la
base d’apprentissage à l’aide de modification des paramètres du réseau. Après avoir
mesuré la variation des poids des connexions pour tous les neurones de sortie, la
variation des poids des connexions de la couche cachée sera déterminée. Par la suite,
les poids des connexions de la couche de sortie jusqu’à la couche d’entrée seront mis
à jour. Ainsi le signal d’erreur sera à son tour rétropropagé. D’où le nom de cet
algorithme « rétropropagation du gradient de l’erreur ».
109
Annexe A Méthodologies d’apprentissage

L’algorithme de rétropropagation du gradient de l’erreur a permis aux réseaux MLP de


résoudre un grand nombre de problèmes de classement. Il souffre toutefois de nombreux
défauts à savoir : le temps d’apprentissage est très long, la grande sensibilité aux poids
initiaux des connexions, la présence éventuelle de minima locaux dans la fonction d’erreur
et le problème de dimensionnement du réseau. Un mauvais choix de la structure du réseau
(le nombre de couches cachées, le nombre de neurones par couche et la topologie des
connexions ) peut détériorer les performances du réseau.
Dans nos travaux, nous avons utilisé les méthodes MLP à deux et à trois couches.

A.4 Arbres de Décision


Les arbres de décision sont des algorithmes d’apprentissage qui construisent des par-
titions arborescentes à partir d’un ensemble d’échantillons. Ils utilisent des mesures pro-
babilistes dans le but d’apprendre des classifications. Les nœuds de ces arbres peuvent
être :
— soit des feuilles contenant des exemples appartenant tous à une même classe. Par
conséquent, les feuilles correspondent à des sous-ensembles de la même classe ;
— soit des nœuds de décision qui subdivisent les données suivant plusieurs sous-ensembles,
où chaque sous-ensemble représente un résultat d’une fonction de test caractérisant
le nœud de décision.
Le déroulement de cette technique passe par deux phases :
— Phase I : Apprentissage ou construction
Le principe de cette phase est de diviser récursivement l’ensemble d’échantillons
d’apprentissage de la façon la plus efficace possible. Pour chaque division, des tests
définis à l’aide des caractéristiques sont appliqués jusqu’à ce que l’on obtienne des
sous-ensembles qui ne contiennent que des exemples appartenant tous à la même
classe.
— Phase II : Tests ou classement
Généralement, les caractéristiques peuvent être binaires, qualitatives (à valeurs dans
un ensemble fini de modalités) ou continues (à valeurs réelles). Dans le cas où les
caractéristiques sont continues, on applique généralement des heuristiques afin de
les discrétiser [166, 167].
Un arbre de décision est marqué par plusieurs avantages alors qu’il ne manque pas d’in-
convénients. En effet, un arbre de décision peut être lu et interprété directement. Il est
donc possible de le traduire en base de règles sans perte d’informations. Toutefois, cette
technique cause une mauvaise performance s’il y a beaucoup de classes et nécessite un
grand nombre d’exemples pour l’apprentissage. Le lecteur intéressé par une description
plus détaillée peut se référer à l’article [155].
Il convient dans ce cadre de signaler la variante NBTree [168] qui représente un type
hybride entre les arbres de décision et les RB naïfs.

110
Annexe A Méthodologies d’apprentissage

Dans nos travaux, nous avons utilisé les méthodes NBTree et J48.

A.5 Bagging
Bagging est une méthode d’ensemble qui prend des décisions à partir de plusieurs
classeurs construits au moyen de la technique du rééchantillonnage [93]. Cette méthode
consiste à produire plusieurs ensembles de données indépendants de même taille que l’en-
semble d’apprentissage original par bootstrap (tirage aléatoire avec remise dans l’ensemble
d’apprentissage original). Par conséquent, quelques exemples peuvent être utilisés plu-
sieurs fois tandis que d’autres ne sont pas selectionnés. Ainsi, un classeur est construit
pour chaque échantillon généré en utilisant le même algorithme d’apprentissage. La dé-
cision finale dans Bagging est obtenue en combinant toutes les décisions des classeurs à
travers un vote majoritaire.
La méthode de Bagging ne fonctionne efficacement que lorsque l’algorithme d’appren-
tissage est instable, c.-à-d. sensible aux changements des données d’apprentissage. Par
exemple, les arbres de décision sont des algorithmes d’apprentissage instables. Les tra-
vaux de [93] montrent que le Bagging fonctionne en minimisant la variance de l’erreur de
la classification tout en gardant le biais inchangé.
Dans nos travaux, nous avons employé la méthode de Bagging combinée avec l’arbre
de décisions (J48).

A.6 AdaBoost
Le Boosting est une méthode itérative d’addition de classeurs faibles dans un ensemble
[169]. Il consiste à varier la base d’apprentissage avec des pondérations sucessives des
mêmes exemples dans le but de se concentrer sur les exemples les plus difficiles, c.-à-d.
les exemples mal classés par plusieurs classeurs. Le classeur, fourni dans chaque cycle, est
pondéré par la qualité de sa classification. Par conséquent, la décision finale est obtenue sur
la base de la somme pondérée des sorties des classeurs élémentaires. La difficulté existante
dans cette méthode est d’incorporer des connaissances a priori et de choisir l’algorithme
d’apprentissage approprié. L’utilisation des classeurs faibles permet d’obtenir de bons
classifieurs.
AdaBoost est une version classique de la méthode Boosting. Elle exige moins d’instabilité
que la méthode de Bagging puisqu’elle permet d’engendrer beaucoup de changements
dans l’ensemble d’apprentissage. Des études comparatives ont montré que la méthode de
Bagging réduit la variance sans influer le biais, alors que la méthode d’AdaBoost diminue
le biais et la variance [169].
Dans nos travaux, nous avons utilisé l’algorithme AdaBoost.M1 [169] combiné avec
l’arbre de décisions (J48).

111
Annexe B

Environnement et modèle hiérarchique

B.1 OPNET
Nous avons utilisé OPNET 14.5 Modeler [170] comme simulateur. Ce dernier est utilisé
dans la conception et l’étude des réseaux de communication. L’intérêt majeur d’OPNET
consiste à simuler le comportement d’un réseau VoIP réellement implanté. C’est un en-
vironnement graphique qui permet le déploiement des réseaux à travers l’exploitation
et l’implémentation des protocoles au niveau de toutes les couches du modèle OSI. En
effet, OPNET offre la possibilité de mettre en œuvre de nouveaux algorithmes et de nou-
veaux modèles, notamment par l’utilisation du formalisme EFSM (Extended Finite State
Machine) [171].
Le «workflow» d’une simulation sous OPNET Modeler est illustré par la Figure B.1.

Création du Choix des Exécution des Analyse des


modèle réseau statistiques simulations résultats

Figure B.1 – Workflow des simulations sous OPNET.

En commençant par la création du modèle réseau, l’analyse de résultats des simulations


exige un choix déterministe des paramètres des statistiques.
OPNET utilise un modèle hiérarchique décrivant d’une façon précise les topologies et
les flux échangés dans un système de communication. Nous avons adaptés le modèle SIP
existant afin d’extraire les critères d’identification d’un attaquant SPITter. Le modèle
hiérarchique d’un réseau VoIP est illustré par la Figure B.2.

112
Annexe B Environnement et modèle hiérarchique

Niveau réseau
Network: Voice-SIP

caller37
caller37
caller37
caller37
caller37
caller36
caller36
caller36
caller36
caller36
caller38
caller38
caller38
caller38
caller38

caller35
caller35
caller35
caller35
caller35
caller39
caller39
caller39
caller39
caller39

caller34
caller34
caller34
caller34
caller34

switch1
switch1
switch1
switch1
switch1
caller40
caller40
caller40
caller40
caller40

caller33
caller33
caller33
caller33
caller33

Niveau nœud
Node Model: ethernet_wkstn_adv

dhcp application CPU

rip tpal

udp tcp rsvp

ip_encap

ip

arp

mac

hub_rx_0_0 hub_tx_0_0

Niveau processus
Process Model: sip_UAC Process Model: gna_voice_called_mgr
(default)

(ESTAB)
req_proc wait
(UAS_FAILURE) send
(OPEN_CONN)

33 / 0 0 / 59
105 / 0
(default) (SEND_FRAME)
(default)
(REQ_PROCESS)

(default)
(ESTAB)
(START_DATA_XFER)
open connect idle

(REQ || RESP) (SERVICE_COMPLETE) (TIMEOUT) (CLOSED) 112 / 37 (ABORT || CLOSE) 0 / 174 1/6
init listen fork lull close end
(RECEIVE_FRAM
(default)
208 / 0 0 / 59 30 / 0 0/9 8 / 16 11 / 0
(ABORT || CLOSE) (CLOSED)
(default)
(default)
(RESP_PROCESS) closed receive

(default) 41 / 1 67 / 1

resp_proc

2/0

Figure B.2 – Modèle hiérarchique d’OPNET.

113
Annexe B Environnement et modèle hiérarchique

Le modèle hiérarchique présente trois niveaux de description :


— Le niveau réseau (Network model) représente la topologie physique comportant un
ensemble de nœuds et d’interconnecteurs.
— Le niveau nœud (Node model) définit le comportement du nœud et contrôle le pas-
sage des données entre les différents éléments fonctionnels à l’intérieur du nœud.
— Le niveau processus (Process model) décrit les protocoles qui sont représentés par
des machines à état finis dont les actions sont écrites à l’aide des fonctions codées
en C/C++.

B.2 Classement sous Weka


L’étape de classement a été mise en œuvre à l’aide du logiciel de fouille de données Weka
[172]. Weka est un open source qui est programmé en java et qui regroupe un ensemble
d’outils de classement, de régression et de classification (clustering).
Il comprend : un "Simple CLI (command-line interface)" qui est une simple interface
de commande en ligne, un "Experimenter" qui permet d’appliquer de méthodes de fouille
de données sur des bases de données multiples, un "Explorer" qui permet d’effectuer des
analyses simples, et un éditeur "KnowledgeFlow" qui permet de réaliser des analyse plus
complexes en modélisant le flux de données à travers les traitement à appliquer. Dans
le but de comparer les différentes méthodes de classification étudiées, nous choisissons le
mode KNOWLEDGE FLOW (enchainement de modules).
Afin de tracer les courbes ROC (Receiver Operating Characteristics) [90] de chaque
méthode de classification, nous avons créé le KNOWLEDGE FLOW illustré par la Figure
B.1.

Figure B.1 – KNOWLEDGE FLOW du traçage des courbes ROC.

Tout d’abord, nous devons charger la source de données (base de données d’appren-
tissage) BD_Détection_SPITters.arff via le composant ArrffLoader. Par la suite, nous
devons filtrer l’attribut adresse de l’appelant puisqu’il n’appartient pas à la liste de cri-
tères d’identification de SPITter à l’aide du composant Remove. Le module ClasseAssi-
114
Annexe B Environnement et modèle hiérarchique

gner, nous permet de spécifier l’attribut que nous souhaitons utiliser comme classe. Afin
de spécifier la classe considérée comme positive (SPITter dans notre cas), nous devons
utiliser le module ClassValuePicker. Par la suite, nous utilisons le composant Training
Set Maker pour la phase d’apprentisage. Pour spécifier que la source de données contient
des échantillons de test, nous utilisons le composant Test Set Maker. Puis, nous devons
spécifier le type de classeur. Ainsi, pour pouvoir tester l’efficacité du classeur et afficher
les résultats du classement, nous devons utiliser Classifier Performance Evaluator. Fina-
lement, le module Model Performance Chart nous permet de visualiser les courbes ROC.
La Figure B.2 illustre le modèle d’enchainement de modules que nous avons créé pour
classer les UA.

Figure B.2 – KNOWLEDGE FLOW de classement des UA.

Ici, la prédiction est réalisée en utilisant le module Predication Appender. Le composant


Arff Saver nous permet de sauvegarder les résultats de prédiction sous la forme de fichier
arff.

B.3 Extrait de trace réseau


La Figure B.1 représente un extrait du fichier trace réseau de la signalisation et de
l’activité vocale.

115
Annexe B Environnement et modèle hiérarchique

ID_Appel @Appelant @Appelé SA RA AI DA IA FC TS DC


37 caller26 callee_non-existent 0 0 1 0.00 21.45 21.45 0.000 0.000
31 caller19 callee_non-existent 0 0 1 0.00 21.46 21.46 0.000 0.000
29 caller17 callee1 0 1 0 0.00 22.80 22.80 0.000 0.000
33 caller21 callee27 0 1 0 0.00 22.80 22.80 0.000 0.000
32 caller20 callee6 0 1 0 0.00 22.80 22.80 0.000 0.000
1 caller2 callee10 0 1 0 0.00 22.80 22.80 0.000 0.000
128 caller58 callee_non-existent 0 0 1 0.00 27.76 27.76 1.000 1.000
83 caller67 callee17 1 0 0 8.16 22.85 31.01 43.443 146.702
77 caller62 callee19 1 0 0 10.52 22.77 33.29 25.503 179.281
39 caller28 callee15 1 0 0 25.27 22.79 48.07 151.530 108.251
73 caller58 callee20 1 0 0 35.30 22.31 57.61 0.000 0.000
36 caller25 callee18 1 0 0 41.84 22.80 64.64 35.036 204.157
40 caller29 callee13 1 0 0 42.97 22.80 65.77 1.000 1.000
43 caller31 callee16 1 0 0 43.05 22.80 65.85 110.766 1.000
51 caller39 callee23 1 0 0 43.64 22.31 65.95 86.521 146.266
82 caller66 callee10 1 0 0 46.28 22.85 69.13 178.389 166.993
34 caller22 callee16 1 0 0 50.89 22.79 73.69 54.444 201.507
76 caller61 callee10 1 0 0 56.50 22.70 79.20 1.000 1.000

Figure B.1 – Extrait du fichier trace réseau de la signalisation et de l’activité vocale.

La Figure B.2 illustre un extrait du fichier des critères d’identification des attaquants
SPITter.

@Appelant % ARep % ARef % AI NT VDA VIA ND VTS VDC


caller1, 100.00, 0.00, 0.00, 2, 234.361, 0.000, 2, 853.382, 2689.08
caller2, 50.00, 50.00, 0.00, 2, 0.000, 0.000, 2, 0.000, 0.000
caller3, 50.00, 0.00, 50.00, 2, 0.000, 0.000, 2, 0.000, 0.000
caller5, 100.00, 0.00, 0.00, 1, 0.000, 0.000, 1, 0.000, 0.000
caller6, 0.00, 0.00, 0.00, 0, 0.000, 0.000, 0, 0.000, 0.000
caller85, 100.00, 0.00, 0.00, 2, 26874.885, 0.000, 2, 0.000, 0.000
caller4, 100.00, 0.00, 0.00, 3, 201895.688, 881353.813, 3, 0.000, 0.000
caller17, 0.00, 100.00, 0.00, 5, 0.000, 128202.883, 1, 0.000, 0.000
caller18, 0.00, 0.00, 100.00, 5, 0.000, 63308.160, 1, 0.000, 0.000
caller19, 0.00, 57.14, 42.86, 7, 0.000, 28188.840, 2, 0.000, 0.000
caller20, 0.00, 100.00, 0.00, 5, 0.000, 153200.109, 4, 0.000, 0.000
caller49, 100.00, 0.00, 0.00, 19, 11078.188, 46263.238, 16, 2567.964, 1582.986
caller55, 88.24, 0.00, 11.76, 17, 9398.217, 59689.363, 4, 0.124, 3468.200
caller56, 75.00, 0.00, 25.00, 12, 12551.593, 60023.063, 4, 5102.357, 0.250

Figure B.2 – Extrait du fichier des critères d’identification des SPITter.

La Figure B.3 illustre un extrait de la base de données d’apprentissage.

116
Annexe B Environnement et modèle hiérarchique

@relation detection_spitters
@attribute caller {caller1,caller2,caller3,caller49,caller50,caller51}
@attribute percentage_succes_call REAL
@attribute percentage_fail_call REAL
@attribute percentage_non_existent REAL
@attribute number_calls INTEGER
@attribute var_call_duration REAL
@attribute var_inter_repetition REAL
@attribute number_invitee INTEGER
@attribute var_silence_length REAL
@attribute var_talk_length REAL
@attribute class {legitimate,spitter}

@data
%***************************************************************************%
% Classe des UA légitimes %
%***************************************************************************%
?, 0, 0, 0, 0, 0, 0, 0, 0, 0, legitimate
?, 100, 0, 0, 1, 0, 0, 1, 0, 0, legitimate
?, 100, 0, 0, 2, 0, 0, 2, 0, 250, legitimate
?, 100, 0, 0, 2, 570, 0, 2, 1440, 0, legitimate
?, 100, 0, 0, 3, 125, 1435, 3, 775, 3455, legitimate
?, 100, 0, 0, 4, 1095, 9535, 3, 4770, 1950, legitimate
?, 100, 0, 0, 4, 6000, 420000, 1, 13000, 4000, legitimate
?, 100, 0, 0, 5, 3000, 3000, 3, 1000, 1000, legitimate
?, 100, 0, 0, 6, 2665, 20885, 4, 615, 1650, legitimate
?, 100, 0, 0, 6, 17860, 18050, 5, 1720, 3250, legitimate
%***************************************************************************%
% Classe des UA SPITters %
%***************************************************************************%
?, 100, 0, 0, 4, 150, 25, 3, 3850, 2080, spitter
?, 40, 20, 40, 5, 14730, 60325, 2, 18725, 1, spitter
?, 0, 100, 0, 6, 0, 77520, 1, 0, 0, spitter
?, 0, 100, 0, 6, 0, 0, 1, 0, 0, spitter
?, 0, 66.67, 33.33, 6, 0, 33155, 2, 0, 0, spitter
?, 14.28, 85.72, 0, 7, 25, 6450, 6, 0, 0, spitter
?, 100, 0, 0, 8, 19080, 32880, 6, 2970, 0, spitterr
?, 100, 0, 0, 11, 14750, 62250, 7, 3150, 0, spitter
?, 100, 0, 0, 11, 16150, 72650, 10, 0, 0, spitter
?, 82.14, 0, 17.86, 28, 10750, 38150, 4, 0, 3350, spitter

Figure B.3 – Extrait de la base de données d’apprentissage.

117
Bibliographie

[1] D. Shin and C. Shim, “Progressive multi gray-leveling : A voice spam protection
algorithm,” IEEE Network, 20(5) : pp. 18-24, Sep/Oct 2006.
[2] J. Quittek, S. Niccolini, S. Tartarelli, M. Stiemerling, M. Brunner, and T. Ewald,
“Detecting SPIT calls by checking human communication patterns,” In IEEE In-
ternational Conference on Communications(ICC 2007), jun 2007.
[3] R. Schlegel, S. Niccolini, S. Tartarelli, and M. Brunner, “SPam over Internet
Telephony (SPIT) prevention framework,” In GLOBECOM, 2006.
[4] P. Kolan and R. Dantu, “Socio-technical defense against voice spamming,” ACM
Trans. Auton. Adapt. Syst., 2(1) , 2007.
[5] V. A. Balasubramaniyan, M. Ahamad, and H. Park, “ CallRank : Combating
SPIT using call duration, social networks and global reputation,” ACM Trans.
Auton. Adapt. Syst., in Fourth Conference on Email and Anti-Spam (CEAS2007),
Mountain View, California USA, 2007.
[6] A. Gehani and G. Kedem, “Rheostat : Real-time risk management,” in Recent Ad-
vances in Intrusion Detection. Springer, 2004, pp. 296–314.
[7] A. Van Wijk and G. Gybels, “Framework for real-time text over ip using the session
initiation protocol (sip),” Tech. Rep., 2008.
[8] C. Perkins, “Ip mobility support for ipv4,” Tech. Rep., 2002.
[9] K. Fleming, D. Hanes, and G. Salgueiro, “Indicating fax over ip capability in the
session initiation protocol (sip),” 2013.
[10] J. Rosenberg, “A framework for conferencing with the session initiation protocol
(sip),” Tech. Rep., 2006.
[11] A. Roach, Session Initiation Protocol (SIP)-Specific Event Notification. RFC 3265,
june 2002.
[12] D. Ng, J. Yang, and M. V. Eyuboglu, “System, method and multipoint control unit
for multipoint multimedia conferencing,” Dec. 5 1995, uS Patent 5,473,363.
[13] N. W. Group, SDP : Session Description Protocol. RFC 2327, avril 1998.
[14] ——, Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification.
RFC 2068, september 1997.

118
BIBLIOGRAPHIE

[15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP : A Transport


Protocol for Real- Time Applications. RFC 3550, 2003.
[16] J. Livingood and R. Shockey, “Iana registration for an enumservice containing public
switched telephone network (pstn) signaling information,” 2006.
[17] S. ZNATY, “Isup : Isdn–user part,” 2005.
[18] D. H. Crocker, Standard for the format of arpa internet text messages. RFC 822,
august 1982.
[19] N. W. Group, Hypertext Transfer Protocol – HTTP/1.1. RFC 2068, january 1997.
[20] G. Camarillo, “The internet assigned number authority (iana) uniform resource
identifier (uri) parameter registry for the session initiation protocol (sip),” Tech.
Rep., 2004.
[21] O. Levin, “H. 323 uniform resource locator (url) scheme registration,” 2003.
[22] J. Postel, “User datagram protocol,” Tech. Rep., 1980.
[23] D. Sisalem, J. Kuthan, S. Ehlert et al., “Denial of service attacks targeting a sip
voip infrastructure : attack scenarios and prevention mechanisms,” IEEE Network,
vol. 20, no. 5, pp. 26–31, 2006.
[24] M. Collier, “Voip vulnerabilities : Denial of service,” 2007.
[25] Y.-B. Lin and M.-H. Tsai, “Eavesdropping through mobile phone,” IEEE Transac-
tions on Vehicular Technology, vol. 56, no. 6, pp. 3596–3600, 2007.
[26] N. Provos, “Vomit : A voice over missconfigured internet telephones,” World Wide
Web, http ://vomit. xtdnet. nl, 2001.
[27] R. Zhang, X. Wang, R. Farley, X. Yang, and X. Jiang, “On the feasibility of laun-
ching the man-in-the-middle attacks on voip from remote attackers,” in Proceedings
of the 4th International Symposium on Information, Computer, and Communica-
tions Security. ACM, 2009, pp. 61–69.
[28] R. T. Hsu and J. Wang, “Packet flow processing in a communication system,” Oct. 2
2007, uS Patent 7,277,455.
[29] K. Khan, R. Syal, and A. Kapila, “Information systems audit and control associa-
tion,” CISA Review Manual, 2006.
[30] R. Zhang, X. Wang, X. Yang, and X. Jiang, “Billing attacks on sip-based voip
systems.” WOOT, vol. 7, pp. 1–8, 2007.
[31] H. Tu, A. Doupé, Z. Zhao, and G.-J. Ahn, “Sok : Everyone hates robocalls : A
survey of techniques against telephone spam,” 2016.
[32] H. Zhao and N. Ansari, “Detecting covert channels within voip,” in Sarnoff Sym-
posium (SARNOFF), 2012 35th IEEE. IEEE, 2012, pp. 1–6.
[33] Y. Zhang and H. Huang, “Voip voice network technology security strategies,” in
Artificial Intelligence, Management Science and Electronic Commerce (AIMSEC),
2011 2nd International Conference on. IEEE, 2011, pp. 3591–3594.
119
BIBLIOGRAPHIE

[34] D. Butcher, X. Li, and J. Guo, “Security challenge and defense in voip infrastruc-
tures,” IEEE Transactions on Systems, Man, and Cybernetics, Part C (Applications
and Reviews), vol. 37, no. 6, pp. 1152–1162, 2007.
[35] M. Laubach and J. Halpern, “Classical ip and arp over atm,” Tech. Rep., 1998.
[36] M. Crawford, “Transmission des paquets ipv6 sur les réseaux ethernet,” 1998.
[37] J. Bartlomiejczyk and M. Phipps, “Preventing layer 2 security threats,” Tech-
Target Networking Tips, http ://searchnetworking. techtarget. com/tip/1, 289483,
sid7_gci1009100, 00. html, 2007.
[38] E. Coulibaly and L. H. Liu, “Security of voip networks,” in Computer Engineering
and Technology (ICCET), 2010 2nd International Conference on, vol. 3. IEEE,
2010, pp. V3–104.
[39] S. Deore and A. Patil, “Survey denial of service classification and attack with protect
mechanism for tcp syn flooding attacks,” 2016.
[40] N. Dadoun, “Security framework for ip telephony,” Polycom White Paper, vol. 15,
2002.
[41] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and
L. Stewart, “Http authentication : Basic and digest access authentication,” Tech.
Rep., 1999.
[42] S. Kent and R. Atkinson, “Rfc2401 : Security architecture for the internet protocol,”
1998.
[43] C. Allen and T. Dierks, “Rfc2246 : The tls protocol version 1.0,” 1999.
[44] B. Ramsdell, “Rfc2633 : S/mime version 3 message specification,” 1999.
[45] C. Heinrich, “Secure socket layer (ssl),” in Encyclopedia of Cryptography and Secu-
rity. Springer, 2011, pp. 1135–1139.
[46] R. Khare and S. Lawrence, “Upgrading to tls within http/1.1,” Tech. Rep., 2000.
[47] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, “Rfc 3711 : The
secure real-time transport protocol (srtp),” Request for Comments, IETF, 2004.
[48] A. P. Ortega, X. E. Marcos, L. D. Chiang, and C. L. Abad, “Preventing arp cache
poisoning attacks : A proof of concept using openwrt,” in Network Operations and
Management Symposium, 2009. LANOMS 2009. Latin American. IEEE, 2009, pp.
1–9.
[49] M. Hansen, M. Hansen, J. Möller, T. Rohwer, C. Tolkmit, and H. Waack, “De-
veloping a legally compliant reachability management system as a countermeasure
against spit,” in Proceedings of Third Annual VoIP Security Workshop, Berlin, Ger-
many, 2006.
[50] G. F. Marias, S. Dritsas, M. Theoharidou, J. Mallios, and D. Gritzalis, “Sip vul-
nerabilities and anti-spit mechanisms assessment,” in Computer Communications
120
BIBLIOGRAPHIE

and Networks, 2007. ICCCN 2007. Proceedings of 16th International Conference


on. IEEE, 2007, pp. 597–604.
[51] J. Rosenberg, C. Jennings, and J. Peterson, “The session initiation protocol (sip)
and spam,” RFC 5039, January, Tech. Rep., 2008.
[52] Y. Rebahi and D. Sisalem, “Sip service providers and the spam problem,” in Pro-
ceedings of the 2nd VoIP Security Workshop, 2005.
[53] R. MacIntosh and D. Vinokurov, “Detection and mitigation of spam in ip telephony
networks using signaling protocol analysis,” in Advances in Wired and Wireless
Communication, 2005 IEEE/Sarnoff Symposium on. IEEE, 2005, pp. 49–52.
[54] R. Schlegel, S. Niccolini, S. Tartarelli, and M. Brunner, “Ise03-2 : Spam over internet
telephony (spit) prevention framework,” in Global Telecommunications Conference,
2006. GLOBECOM’06. IEEE. IEEE, 2006, pp. 1–6.
[55] L. Stevenson and N. Altholz, Rootkits for dummies. John Wiley & Sons, 2006.
[56] P. Stamatiou and D. Gritzalis, “Countering unsolicited calls in the internet tele-
phony : An anti-spit architecture,” quality and reliability, vol. 2, no. 4, p. 5, 2009.
[57] D. R. Kuhn, T. J. Walsh, and S. Fries, “Security considerations for voice over ip
systems,” NIST special publication, pp. 800–58, 2005.
[58] S. I. M. Reyes, G. R. Salgado, and J. P. Ortega, “Defining adaptive whitelists by
using clustering techniques, a security application to prevent toll fraud in voip net-
works,” in Proceedings of the International Conference on Information and Know-
ledge Engineering (IKE). The Steering Committee of The World Congress in
Computer Science, Computer Engineering and Applied Computing (WorldComp),
2016, p. 100.
[59] S. A. Ahson and M. Ilyas, SIP handbook : services, technologies, and security of
Session Initiation Protocol. CRC Press, 2008.
[60] Y. Soupionis, G. Tountas, and D. Gritzalis, “Audio captcha for sip-based voip,” in
Emerging Challenges for Security, Privacy and Trust. Springer, 2009, pp. 25–38.
[61] M. S. S. Niccolini, S. Tartarelli, and M. Stiemerling, “Requirements and methods
for spit identification using feedbacks in sip,” Internet-draft, Tech. Rep., 2008.
[62] B. A. Sundeby and K. U. Lennartsson, “Method and apparatus to provide an im-
proved voice over internet protocol (voip) environment,” Sep. 13 2016, uS Patent
9,443,010.
[63] E. Edelson, “Voice over ip : security pitfalls,” Network security, vol. 2005, no. 2, pp.
4–7, 2005.
[64] V. Srihari, P. Kalpana, and R. Anitha, “Spam over ip telephony prevention using
dendritic cell algorithm,” in Signal Processing, Communication and Networking
(ICSCN), 2015 3rd International Conference on. IEEE, 2015, pp. 1–7.

121
BIBLIOGRAPHIE

[65] T. Dierks, “The transport layer security (tls) protocol version 1.2,” 2008.
[66] S. Niccolini, “Spit prevention : state of the art and research challenges,” in Procee-
dings of the 3rd Workshop on Securing Voice over IP, 2006.
[67] F. Mata, P. Zuraniewsk, M. Mandjes, and M. Mellia, “Anomaly detection in voip
traffic with trends,” in Proceedings of the 24th International Teletraffic Congress.
International Teletraffic Congress, 2012, p. 2.
[68] H.-J. Kim, M. J. Kim, Y. Kim, and H. C. Jeong, “Devs-based modeling of voip
spam callers’ behavior for spit level calculation,” Simulation Modelling Practice and
Theory, vol. 17, no. 4, pp. 569–584, 2009.
[69] N. Chaisamran, T. Okuda, and S. Yamaguchi, “Trust-based voip spam detection
based on calling behaviors and human relationships,” Information and Media Tech-
nologies, vol. 8, no. 2, pp. 528–537, 2013.
[70] M. Amanian, M. H. Y. Moghaddam, and H. K. Roshkhari, “New method for evalua-
ting anti-spit in voip networks,” in Computer and Knowledge Engineering (ICCKE),
2013 3th International eConference on. IEEE, 2013, pp. 374–379.
[71] M. Nassar, O. Festor et al., “Monitoring sip traffic using support vector machines,”
in Recent Advances in Intrusion Detection. Springer, 2008, pp. 311–330.
[72] Y.-S. Wu, S. Bagchi, N. Singh, and R. Wita, “Spam detection in voice-over-ip
calls through semi-supervised clustering,” in Dependable Systems & Networks, 2009.
DSN’09. IEEE/IFIP International Conference on. IEEE, 2009, pp. 307–316.
[73] N. Croft and M. Olivier, “A model for spam prevention in voice over ip networks
using anonymous verifying authorities,” in Proceedings of the 5th Annual Informa-
tion Security South Africa Conference (ISSA), 2005.
[74] B. Mathieu, Y. Gourhant, and Q. Loudier, “Spit mitigation by a network level
anti-spit entity,” in Proc. of the 3rd Annual VoIP Security Workshop, 2006.
[75] K. Srivastava and H. G. Schulzrinne, “Preventing spam for sip-based instant mes-
sages and sessions,” 2004.
[76] D. Shin, J. Ahn, and C. Shim, “Progressive multi gray-leveling : a voice spam
protection algorithm,” Network, IEEE, vol. 20, no. 5, pp. 18–24, 2006.
[77] R. Baumann, S. Cavin, and S. Schmid, “Voice over ip-security and spit,” Swiss
Army, FU Br, vol. 41, pp. 1–34, 2006.
[78] J. Peterson and C. Jennings, “Enhancements for authenticated identity management
in the session initiation protocol (sip),” RFC 4474, August, Tech. Rep., 2006.
[79] H. Tschofenig, R. Falk, J. Peterson, J. Hodges, D. Sicker, J. Polk, and A. Siemens,
“Using saml to protect the session initiation protocol (sip),” IEEE Network, vol. 20,
no. 5, pp. 14–17, 2006.
[80] A. Madhosingh, “The design of a differentiated sip to control voip spam,” Computer
Science Department, Florida State University, 2006.
122
BIBLIOGRAPHIE

[81] R. Dantu and P. Kolan, “Detecting spam in voip networks.” SRUTI, vol. 5, pp. 5–5,
2005.
[82] J. Quittek, S. Niccolini, S. Tartarelli, M. Stiemerling, M. Brunner, and T. Ewald,
“Detecting spit calls by checking human communication patterns,” in Communica-
tions, 2007. ICC’07. IEEE International Conference on. IEEE, 2007, pp. 1979–
1984.
[83] T. Kusumoto, E. Y. Chen, and M. Itoh, “Using call patterns to detect unwanted
communication callers,” in Applications and the Internet, 2009. SAINT’09. Ninth
Annual International Symposium on. IEEE, 2009, pp. 64–70.
[84] B. Mathieu, S. Niccolini, and D. Sisalem, “Sdrs : a voice-over-ip spam detection and
reaction system,” Security & Privacy, IEEE, vol. 6, no. 6, pp. 52–59, 2008.
[85] V. Balasubramaniyan, M. Ahamad, and H. Park, “Callrank : Combating spit using
call duration, social networks and global reputation.” in CEAS, 2007.
[86] S. Ahson and M. Ilyas, SIP HANDBOOK Services, technologies and Security of
session initiation protocol, iSBN : 978-1-4200-6603-6, pp. 461-464, 2009.
[87] A. H. Wang, “Detecting spam bots in online social networking sites : a machine
learning approach,” in IFIP Annual Conference on Data and Applications Security
and Privacy. Springer, 2010, pp. 335–342.
[88] S. Subramanian, V. B. Srinivasan, and C. Ramasa, “Study on classification algo-
rithms for network intrusion systems,” Journal of Communication and Computer,
vol. 9, no. 11, pp. 1242–1246, 2012.
[89] C.-F. Tsai, Y.-F. Hsu, C.-Y. Lin, and W.-Y. Lin, “Intrusion detection by machine
learning : A review,” Expert Systems with Applications, vol. 36, no. 10, pp. 11 994–
12 000, 2009.
[90] T. Fawcett, “An introduction to roc analysis,” Pattern Recognition Letters, 27(8) :
861–874, 2006.
[91] A. P. Bradley, “The use of the area under the ROC curve in the evaluation of
machine learning algorithms,” Pattern Recognition, 30(7) :1145–1159, 1997.
[92] D. B. Wright, “Receiver operating characteristics curves,” Encyclopedia of statistics
in behavioral science, 2005.
[93] R. Kumar and A. Indrayan, “Receiver operating characteristic (roc) curve for me-
dical researchers,” Indian pediatrics, vol. 48, no. 4, pp. 277–287, 2011.
[94] R. J. Ben Chikha, T. Abbes, and A. Bouhoula, “Fixing thresholds to detect spam
over ip telephony attacks,” in Tunisian Japanese Symposium on Science, Society
and Technology (TJASSST 2013), 2013, pp. 1–5.
[95] ISO/IEC 27005, Information Security Risk Management, www.iso.org.
[96] H. Dwivedi, Hacking VoIP : protocols, attacks, and countermeasures. No Starch
Press, 2009.
123
BIBLIOGRAPHIE

[97] G. Stoneburner, A. Goguen, and A. Feringa, “Risk management guide for informa-
tion technology systems : Recommendations of the national institute of standards
and technology, retrieved november 25, 2009,” 2002.
[98] Risk management concepts and methods, Clusif, www.clusif.asso.fr.
[99] B. Violino, “It risk assessment frameworks : real-world experience,” Inter-
net : http ://www. csoonline. com/article/592525/it-risk-assessmentframeworks-
real-world-experience, 2010.
[100] CLUSIF (2007) MEHARI 2007, concepts and mechanisms,
http ://www.clusif.asso.fr/fr/ production/ouvrages/pdf/CLUSIF-risk-
management.pdf.
[101] W. T. A. AWARE and C. LOGICAL, “Information technology–security techniques–
information security management systems–requirements,” 2005.
[102] K. Stolen, F. den Braber, T. Dimitrakos, R. Fredriksen, B. A. Gran, S.-H. Houmb,
M. S. Lund, Y. Stamatiou, and J. Aagedal, “Model-based risk assessment-the coras
approach,” in iTrust Workshop, 2002.
[103] R. Fredriksen, M. Kristiansen, B. A. Gran, K. Stølen, T. A. Opperud, and T. Di-
mitrakos, “The coras framework for a model-based risk management process,” in
Computer Safety, Reliability and Security. Springer, 2002, pp. 94–105.
[104] M. Roesch et al., “Snort : Lightweight intrusion detection for networks.” in LISA,
vol. 99, no. 1, 1999, pp. 229–238.
[105] V. Paxson, “The bro 0.8 user manual,” Lawrence Berkeley National Laboratroy and
ICSI Center for Internet Research, 2004.
[106] S. Niccolini, R. Garroppo, S. Giordano, G. Risi, and S. Ventura, “Sip intrusion
detection and prevention : recommendations and prototype implementation,” in
VoIP Management and Security, 2006. 1st IEEE Workshop on. IEEE, 2006, pp.
47–52.
[107] M. Nassar, R. State, and O. Festor, “Voip honeypot architecture,” in Integrated
Network Management, 2007. IM’07. 10th IFIP/IEEE International Symposium on.
IEEE, 2007, pp. 109–118.
[108] H. Yan, K. Sripanidkulchai, H. Zhang, Z.-Y. Shae, and D. Saha, “Incorporating ac-
tive fingerprinting into spit prevention systems,” in Third annual security workshop
(VSW’06). Citeseer, 2006.
[109] N. V. Verde, G. Ateniese, E. Gabrielli, L. V. Mancini, and A. Spognardi, “No nat’d
user left behind : Fingerprinting users behind nat from netflow records alone,” in
Distributed Computing Systems (ICDCS), 2014 IEEE 34th International Conference
on. IEEE, 2014, pp. 218–227.
[110] H. J. Abdelnur, O. Festor et al., “Advanced network fingerprinting,” in Recent Ad-
vances in Intrusion Detection. Springer, 2008, pp. 372–389.
124
BIBLIOGRAPHIE

[111] H. Yang, Y. Zhang, Y.-p. Hu, and Q.-x. Liu, “Ike vulnerability discovery based on
fuzzing,” Security and Communication Networks, vol. 6, no. 7, pp. 889–901, 2013.
[112] R. Ma, D. Wang, C. Hu, W. Ji, and J. Xue, “Test data generation for stateful
network protocol fuzzing using a rule-based state machine,” Tsinghua Science and
Technology, vol. 21, no. 3, pp. 352–360, 2016.
[113] T. Alrahem, A. Chen, N. DiGiuseppe, J. Gee, S.-P. Hsiao, S. Mattox, T. Park,
I. Harris et al., “Interstate : A stateful protocol fuzzer for sip,” Defcon, vol. 15, pp.
1–5, 2007.
[114] G. Stoneburner, A. Y. Goguen, and A. Feringa, “Sp 800-30. risk management guide
for information technology systems,” 2002.
[115] K. R. M. Rao and D. Pant, “Security risk assessment of geospatial weather informa-
tion system (gwis) : An owasp based approach,” International Journal of Computer
Science and Information Security, vol. 8, no. 5, pp. 208–218, 2010.
[116] E. Wheeler, Security risk management : Building an information security risk ma-
nagement program from the Ground Up. Elsevier, 2011.
[117] O. Dabbebi, R. Badonnel, and O. Festor, “Leveraging countermeasures as a ser-
vice for voip security in the cloud,” International Journal of Network Management,
vol. 24, no. 1, pp. 70–84, 2014.
[118] ——, “An online risk management strategy for voip enterprise infrastructures,”
Journal of Network and Systems Management, vol. 23, no. 1, pp. 137–162, 2015.
[119] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Ste-
wart, “An extension to http : digest access authentication,” 1997.
[120] B. Ramsdell, “Secure/multipurpose internet mail extensions (s/mime) version 3.1
message specification,” 2004.
[121] A. Mayzaud, A. Sehgal, R. Badonnel, and I. Chrisment, “Gestion de risques appli-
quée aux réseaux rpl,” in 9ème Conférence sur la Sécurité des Architectures Réseaux
et des Systèmes d’Information, 2014.
[122] I. Tho, Managing the risks of IT outsourcing. Routledge, 2012.
[123] M. Modarres, Risk analysis in engineering : techniques, tools, and trends. CRC
press, 2006.
[124] R. Dantu, P. Kolan, and J. Cangussu, “Network risk management using attacker
profiling,” Security and Communication Networks, vol. 2, no. 1, pp. 83–96, 2009.
[125] T. Olsson, “Assessing security risk to a network using a statistical model of attacker
community competence,” in Information and Communications Security. Springer,
2009, pp. 308–324.
[126] M. Benini and S. Sicari, “Assessing the risk of intercepting voip calls,” Computer
Networks, vol. 52, no. 12, pp. 2432–2446, 2008.

125
BIBLIOGRAPHIE

[127] D. Balzarotti, M. Monga, and S. Sicari, “Assessing the risk of using vulnerable
components,” in Quality of Protection. Springer, 2006, pp. 65–77.
[128] O. Dabbebi, R. Badonnel, and O. Festor, “Automated runtime risk management
for voice over ip networks and services,” in Network Operations and Management
Symposium (NOMS), 2010 IEEE. IEEE, 2010, pp. 57–64.
[129] P. Thermos and A. Takanen, Securing VoIP Networks. Pearson Education, 2007.
[130] C. Irvine and T. Levin, “Toward a taxonomy and costing method for security ser-
vices,” in Computer Security Applications Conference, 1999.(ACSAC’99) Procee-
dings. 15th Annual. IEEE, 1999, pp. 183–188.
[131] H. Venter and J. H. Eloff, “A taxonomy for information security technologies,”
Computers & Security, vol. 22, no. 4, pp. 299–307, 2003.
[132] H. Wang and C. Wang, “Taxonomy of security considerations and software quality,”
Communications of the ACM, vol. 46, no. 6, pp. 75–78, 2003.
[133] P. Kamat, S. Gite, M. Kumar, and S. Patil, “A critical analysis of p2p communica-
tion, security concerns and solutions,” International Journal of Applied Engineering
Research, vol. 9, no. 24, pp. 30 899–30 909, 2014.
[134] L. R. Halme and R. K. Bauer, “Intrusion detection faq : Aint misbehaving : A taxo-
nomy of anti-intrusion techniques,” in Proceedings of the 18th National Information
Systems Security Conference, pp. 163–172.
[135] W. Kanoun, S. Dubus, S. Papillon, N. Cuppens-Boulahia, and F. Cuppens, “To-
wards dynamic risk management : Success likelihood of ongoing attacks,” Bell Labs
Technical Journal, vol. 17, no. 3, pp. 61–78, 2012.
[136] K. Downer and M. Bhattacharya, “Byod security : A new business challenge,”
in 2015 IEEE International Conference on Smart City/SocialCom/SustainCom
(SmartCity). IEEE, 2015, pp. 1128–1133.
[137] S. Bistarelli, F. Fioravanti, and P. Peretti, “Using cp-nets as a guide for countermea-
sure selection,” in Proceedings of the 2007 ACM symposium on Applied computing.
ACM, 2007, pp. 300–304.
[138] S. Bistarelli, F. Fioravanti, P. Peretti, and I. Trubitsyna, “Modeling and selec-
ting countermeasures using cp-nets and answer set programming,” in 23rd Italian
Convention of Computational Logic, 2008.
[139] C. Duan and J. Cleland-Huang, “Automated safeguard selection strategies,” in CTI
Research Symposium. Citeseer, 2006.
[140] H. Cavusoglu, B. Mishra, and S. Raghunathan, “A model for evaluating it security
investments,” Communications of the ACM, vol. 47, no. 7, pp. 87–92, 2004.
[141] Y. Ferenc and Y. Salim, “A game theory based risk and impact analysis method for
intrusion defense systems,” in International Conference on Computer Systems and
Applications (AICCSA), p. 975.
126
BIBLIOGRAPHIE

[142] G. D. G. Granadillo, “Optimization of cost-based threat response for security infor-


mation and event management (siem) systems,” Ph.D. dissertation, Institut Natio-
nal des Télécommunications, 2013.
[143] N. Kheir, “Response policies and countermeasures : Management of service depen-
dencies and intrusion and reaction impacts,” Ph.D. dissertation, PhD thesis, Ecole
Nationale Supérieure des Télécommunications de Bretagne, 2010.
[144] G. G. Granadillo, H. Débar, G. Jacob, C. Gaber, and M. Achemlal, “Individual
countermeasure selection based on the return on response investment index,” in
Computer Network Security. Springer, 2012, pp. 156–170.
[145] N. Kheir, N. Cuppens-Boulahia, F. Cuppens, and H. Debar, “A service dependency
model for cost-sensitive intrusion response,” in Computer Security–ESORICS 2010.
Springer, 2010, pp. 626–642.
[146] J. Brocke, C. Buddendick, and G. Strauch, “Return on security investments-design
principles of measurement systems based on capital budgeting,” AMCIS 2007 Pro-
ceedings, p. 94, 2007.
[147] W. Sonnenreich, J. Albanese, and B. Stout, “Return on security investment (rosi)-
a practical quantitative model,” Journal of Research and practice in Information
Technology, vol. 38, no. 1, pp. 45–56, 2006.
[148] D. Kosutic, “Is it possible to calculate the return on security investment
(rosi),in http ://blog.iso27001standard.com/2011/06/13/is-it-possible-to-calculate-
the-return-on-security-investment-rosi/,” 2011.
[149] “LOCKSTEP Consulting. A Guide for Government Agencies Calculating ROSI.
Technical report, http ://lockstep.com.au/library/return_on_investment,” 2004.
[150] “SDL Team Microsoft. Attack Surface Analyzer 1.0,
http ://blogs.msdn.com/b/sdl/archive/2012/08/02/ attack-surface-analyzer-1-
0-released.aspx,” 2012.
[151] G. G. Granadillo, M. Belhaouane, H. Debar, and G. Jacob, “Rori-based counter-
measure selection using the orbac formalism,” International journal of information
security, vol. 13, no. 1, pp. 63–79, 2014.
[152] P. Olofsson and M. Andersson, Probability, statistics, and stochastic processes. John
Wiley & Sons, 2012.
[153] R. J. Ben Chikha, T. Abbes, and A. Bouhoula, “Risk management for spam over
ip telephony using optimal countermeasure,” in Digital Economy Emerging Tech-
nologies and Business Innovation (ICDEc), 2016 1st International Conference on.
IEEE, Accepted, pp. 1–7.
[154] ——, “Risk management for spam over ip telephony using combined countermea-
sures,” in International Conference on Informatics and Systems (INFOS), 2016 10th
International Conference on. ACM, Accepted, pp. 1–7.
127
BIBLIOGRAPHIE

[155] R. J. Ben Chikha, T. Abbes, W. Ben Chikha, and A. Bouhoula, “Behavior-based


approach to detect spam over ip telephony attacks,” International Journal of Infor-
mation Security, vol. 15, no. 2, pp. 131–143, 2016.
[156] R. J. Ben Chikha, T. Abbes, and A. Bouhoula, “A spit detection algorithm based
on user’s call behavior,” in Software, Telecommunications and Computer Networks
(SoftCOM), 2013 21st International Conference on. IEEE, 2013, pp. 1–5.
[157] G. Gonzalez-Granadillo, J. Garcia-Alfaro, E. Alvarez, M. El-Barbori, and H. De-
bar, “Selecting optimal countermeasures for attacks against critical systems using
the attack volume model and the rori index,” Computers & Electrical Engineering,
vol. 47, pp. 13–34, 2015.
[158] J. H. Halton, “A retrospective and prospective survey of the monte carlo method,”
Siam review, vol. 12, no. 1, pp. 1–63, 1970.
[159] R. P. Grimaldi, Discrete and Combinatoral Mathematics : An Applied Introduction
2nd Ed. Addison-Wesley Longman Publishing Co., Inc., 1989.
[160] T. L. Norman et al., Risk analysis and security countermeasure selection. CRC
press, 2015.
[161] P. Naïm, P. Wuillemin, P. Leray, O. Pourret, and A. Becker, Réseaux Bayésiens,
2004.
[162] B. Boser, I. Guyon, and V. Vapnik, “A training algorithm for optimal margin clas-
sifiers,” In COLT ’92 : Proceedings of the fifth annual workshop on Computational
Learning Theory, New York, NY, USA, pp. 144–152, 1992.
[163] C. Cortes and V. N. Vapnik, “Support vector networks,” Machine Learning, 20(3) :
pp. 273-297, (1995).
[164] J. C. Platt, “Fast Training of Support Vector Machines using Sequential Minimal
Optimization,” MIT Press, Cambridge, MA, USA, pp. 185–208, 1999.
[165] C. Bishop, “Neural Networks for Pattern Recognition,” Oxford University Press,
1995.
[166] R. Kohavi, J. Dougherty, and M. Sahami, “Supervised and Unsupervised
Discretization of Continuous Features,” In International Conference on Machine
Learning, pp. 194–202, 1995.
[167] D. A. Zighed, S. Rabaséda, and R. Rakotomalala, “Fusinter : A Method for
Discretization of Continuous Attributes,” International Journal of Uncertainty,
Fuzziness and Knowledge-Based Systems, pp. 307–326, 1998.
[168] R. Kohavi, “Scaling up the accuracy of naive-Bayes classifiers : a decision-tree hy-
brid,” International Conference on Knowledge Discovery and Data Mining, pp. 202–
207, 1996.

128
BIBLIOGRAPHIE

[169] E. Saber, A. M. Tekalp, R. Eschbach, and K. Knox, “Automatic image annotation


using adaptive color classification,” Graphical Models and Image Processing, vol. 58,
no. 2, pp. 115–126, 1996.
[170] OPNET v14.5. http ://www.opnet.com/.
[171] K.-T. Cheng and A. Krishnakumar, “Automatic Functional Test Generation Using
The Extended Finite State Machine Model,” International Design Automation
Conference (DAC), pp. 86–91, 1993.
[172] Weka. http ://www.cs.waikato.ac.nz/ml/weka/.

129