Rapport

Page 1
Mémoire de Projet de Fin d’Études
Pour l’Obtention du Diplôme
Master Spécialisé en Informatique

Option
Réseaux Informatiques, Télécommunications et Multimédia
Sujet
Etude et Mise en place d’une

solution d’accès logique
Soutenu par : Sous la direction de :
M.Abdelhalim SOURI M. Mohamed SENHADJI - ENSIAS

M. Amine HAMDOUCHI M. Annouar BOUCHAAL – Al Barid Bank
Etude et Mise en place d’une
solution d’accès logique
Soutenu par : Membres du jury :
M.Abdelhalim SOURI
M.Amine HAMDOUCHI M. Mohammed EL KOUTBI – Examinateur (ENSIAS)
M. Abdellatif KOBBANE – Président (ENSIAS)
Dédicace
Nous aimerons dédier ce travail :
A nos très chers parents
A tous nos chers amis
A toutes nos familles
A nos chers collègues
A nos chers frères
A nos chères soeurs
Aucun terme et aucune langue ne pourra exprimer notre amour, notre gratitude et nos
sentiments envers vous.
Pour tout le soutien que nous avez offert , nous vous disons MERCI .
1
Remerciements
C’est parce que nous estimons beaucoup tous ceux qui nous ont écouté, conseillé, critiqué
et encadré que nous tenons à leur faire part de toute notre gratitude, et plus particulière-
ment, nous tenons à remercier à travers ces courtes lignes :
Notre encadrant externe Mr Annouar BOUCHAAL qui nous a incité à mener à

bien ce travail, pour son aide, son temps passé pour nous guider, ses efforts pour nous
intégrer dans l’environnement professionnel, pour son dévouement et ses précieux conseils.
Notre encadrant interne Mr Mohamed SENHADJI parce qu’il a accepté de nous

superviser et suivre les détails de l’avancement de notre travail, ainsi que son aide et ses
conseils dans plusieurs étapes du projet.
Tous les membres de l’équipe du système d’information , pour leurs aides, leurs re-
marques, leurs esprits ouverts et leur respect.
Nos familles que nous ne pourrons guère oublier de remercier, pour leur soutien à la
fois moral et matériel durant toute notre carrière et surtout durant les moments difficiles.
Nous tenons aussi à remercier ceux qui ont partagé le même espace de travail dans le
département « Département sécurité du système d’information ».
Et nous tenons aussi à remercier toute autre personne ayant contribué d’une façon ou
d’une autre au bon déroulement de notre projet de stage.
2
Résumé
Le présent document constitue une synthèse de notre projet de fin d’études pour l’obtention
du Diplôme de Master Spécialisé en Informatique option Réseau Informatique , Télécom-
munication et Multimédia , au terme d’un stage effectué au sein de la direction des sys-
tèmes d’information de AL Baird Banque , sous le thème :Etude et mise en place d’une
solution d’accès logique .
Notre projet a pour objectif d’instaurer une politique d’accès aux ressources informatiques
et de proposer une solution qui facilitera la résolutions des anomalies qui surviennent. dans
le système informatique . A cet effet, une étude comparative des différentes solutions exis-
tantes sur le marché, a été menée afin d’aboutir à un choix adéquat répondant aux besoins
ainsi qu’aux contraintes de l’environnement architectural du système d’information de Al
Barid Bank, la mettre en place, la configurer, et la déployer.
Pour ce faire il a fallu commencer par mener une étude de l’existant de l’outil open source
choisi ainsi que l’étude architecturale de l’environnement. En exploitant les résultats
obtenus des études cités précédemment, un cahier de charges a été établi pour cadrer le
périmètre du projet pour but de répondre aux attentes de sécurité du SI de la société .
Après avoir retenu la solution adéquate, nous l’avons déployé sur un environnement de
test qui est une simulation de l’environnement réel.
Mots clés: SIEM, AL Barid Bank .
3
Abstract
This report is the result of four months of work , carried out as part of our graduation
project inside AL BARID BANK. The project objective is to establish a strong authen-
tication policy and manage logical access. The purpose is is indeed classify and define a
security policy that will allow automated permissions management within the company.
To achieve this, our mission is to establish a central platform for the correlation logs to
manage traceability.
Mots clés: SIEM,AL Barid Bank .
4
Liste des figures
1.1 Organigrame Al barid Bank : . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Organisationnelle Al barid Bank . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Diagramme de Gantt : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Architecture de packetFence . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Composants de packetFence . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Architecture Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Matrice de contrôle d’accès : . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Schèma de ORBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Interaction d’ORBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Hiérarchique du modèle ORBAC . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Conflit de permission : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 Simulation du modèle ORBAC . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7 Simulation sur les roles ORBAC : . . . . . . . . . . . . . . . . . . . . . . . 45
5.1 Statistiques des évènement des logs : . . . . . . . . . . . . . . . . . . . . . 53

5.2 Statistiques des transmissions des données . . . . . . . . . . . . . . . . . . 53
5.3 Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Top 10 IP adresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Les champs de l’indice PacketBeat . . . . . . . . . . . . . . . . . . . . . . 55
5.6 L’archivage ou le traitement avec un serveur de cloud d’amazon S3. . . . . 57
5.7 Fonctionnement du packetbeat . . . . . . . . . . . . . . . . . . . . . . . . 59
5.8 Fonctionnement du Packetbeat avec Logstash . . . . . . . . . . . . . . . . 60
5.9 Architecture générale d’ELK . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.10 Les sources des differentes addresses ip . . . . . . . . . . . . . . . . . . . . 61
5.11 Règles de filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.12 Pays visités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.13 Plugin Bigdesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.14 Plugin KOPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.15 Plugin head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.16 Plugin head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.17 Plugin Whatson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5
LISTE DES FIGURES
5.18 Capture d’écran de Logstash . . . . . . . . . . . . . . . . . . . . . . . . . 72
Page 6
Liste des tableaux
1.1 Tableau des livrables de projet . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Comparaison entre les outils opensource NAC . . . . . . . . . . . . . . . . 16
5.1 Etude comparative des outils SIEM . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Etude comparative entre Logstash et Fluentd . . . . . . . . . . . . . . . . 57
7
Liste des abréviations
AAA Authentification , Autorisation, Accounting. 44
ACS Access Control System. 36
AD Active Directory. 19
AP Access Point. 17
BLP Bell et Lapadula. 49
BYOD Bring Your Own Device. 38
CCP compte chèque postal. 5
DAC Discretionary Access Control. 45
DAF directeur des affaires financières. 7
HRU Harrison, Ruzzo and Ullmann. 49
I-BAC Identity Based Access Control. 51
IOS Internet Operating Sytem. 17
MAC Mandatory Access Control. 45
MOA Maître d’Ouvrage. 14
NAC Network Access Control. 9
OrBAC Organisation-Based Access Control. 46
PDP Policy Decision Point. 18
PKI Public Key Infrastructure. 35
RBAC Role-Based Access Control. 46
8
Liste des abréviations
Redis REmote DIctionary Server. 84
SEM Security Event Management. 66
SHA System Health Agent. 18
SIEM Security Information and Event Management. 66
SSO Single Sign ON. 36
TBAC Task-based Authorization Controls. 46
TMAC Team-Based Access Control. 46
VMPS VLAN Management Policy Server. 19
Page 9
Sommaire
dédicace 1
Remerciements 2
Liste des figures 5
Liste des tableaux 7
Liste des abréviations 8
Introduction 2
1 Contexte général du projet : 4

1.1 Présentation de l’organisme : . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 L’organisme d’accueil : . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 L’organigramme organisationnel : . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation du projet : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Contexte du projet : . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Objectif du projet : . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Conduite du projet : . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.4 Planning du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.5 Diagramme de gantt : . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Périmètre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Mission du projet : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Livrables du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Network Access Control 13

2.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Solutions libre et commerciales . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Acteurs commerciaux du NAC . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Cisco System : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 NetClarity NAC Walls : . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Microsoft : Network Access Protection : . . . . . . . . . . . . . . . 14
10
SOMMAIRE
2.3.4 McAfee NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Solution libre du NAC : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 PacketFence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 FreeNac: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3 OpenNac : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.4 Net Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.5 Rings Security Analyser . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Etude comparative des solutions open source . . . . . . . . . . . . . . . . 15
2.6 Solution PacketFence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.1 Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.1.1 Détection des anomalies des Activités du réseau: . . . . . 17
2.6.1.2 Les analyses proactives de vulnérabilité . . . . . . . . . . . 17
2.6.1.3 Isolement de périphériques problématiques . . . . . . . . . 17
2.6.2 Architecture de packetFance . . . . . . . . . . . . . . . . . . . . . . 17
2.6.3 Fonctionnalités : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.3.1 Gestion flexible VLAN et le contrôle d’accès basé sur les
rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.3.2 Accès clients . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.3.3 Profils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.3.4 Plus intégrités sur les types de violation . . . . . . . . . . 19
2.6.3.5 Enregistrement automatique : . . . . . . . . . . . . . . . . 20
2.6.3.6 Authentification flexible : . . . . . . . . . . . . . . . . . . 20
2.7 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Authentification forte 22
3.1 Définition de l’authentification : . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Les facteurs d’authentification : . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Definition de l’authentification forte : . . . . . . . . . . . . . . . . . . . . . 23
3.4 les facteurs d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 OTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Code NIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.4 Biométrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.5 SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.6 ACS (Access Control System ) et l’authentification forte . . . . . . 25
3.4.7 Authentification par Active Directory : . . . . . . . . . . . . . . . . 26
3.5 Etude de l’existant : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1 NeXus Hybrid Access Gateway : . . . . . . . . . . . . . . . . . . . 26
3.5.1.1 -Simplicité pour les utilisateurs . . . . . . . . . . . . . . . 29
3.5.1.2 -Plus de sécurité, moins d’administration . . . . . . . . . . 29
3.5.1.3 La solution hybride : . . . . . . . . . . . . . . . . . . . . . 29
3.6 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.7 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Page 11
SOMMAIRE
3.8 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Autorisation 31
4.1 Définition de la politique d’accès : . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Politique de sécurité : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Définition : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Les politiques et les modèles de contrôle d’accès : . . . . . . . . . . 33
4.3 Les modèles de sécurité informatique : . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Le contrôle d’accès discrétionnaire (DAC) : . . . . . . . . . . . . . . 34
4.3.2 Le modèle I-BAC (Identity Based Access Control ) . . . . . . . . . 35
4.3.3 Le modèle R-BAC (Role Based Access Control) . . . . . . . . . . . 35
4.3.4 Le modèle T-BAC(Task Based Acces Control) . . . . . . . . . . . . 36
4.3.5 Le modèle T-MAC(Team Based Acces Control) . . . . . . . . . . . 37
4.3.6 Le modèle OR-BAC (Organization Based Access Control) . . . . . 37
4.3.6.1 Les objectifs et avantages d’Or-BAC : . . . . . . . . . . . 37
4.3.6.2 Les interactions d’Or-BAC : . . . . . . . . . . . . . . . . . 38
4.3.6.3 La notion de contexte : . . . . . . . . . . . . . . . . . . . 39
4.3.6.4 La notion de hiérarchie : . . . . . . . . . . . . . . . . . . 41
4.3.6.5 La notion de délégation: . . . . . . . . . . . . . . . . . . 42
4.3.6.6 La gestion de conflit : . . . . . . . . . . . . . . . . . . . . 42
4.4 Application du modèle OR-BAC : . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Conclusion: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Centralisation / Corrélation des logs et Traçabilité 46

5.1 Corrélation des logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.1 Définition de l’outil SIEM : . . . . . . . . . . . . . . . . . . . . . . 46
5.1.2 Les fonctionnalités d’un SIEM : . . . . . . . . . . . . . . . . . . . . 47
5.1.2.1 Collecte : . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.2.2 Normalisation : . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.2.3 Agrégation : . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.2.4 Corrélation : . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2.5 Reporting : . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2.6 Archivage : . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.3 Rejeu des évènements : . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Comparaison des outils open source SIEM : . . . . . . . . . . . . . . . . . 49
5.2.1 Les besoins et les contraintes de choix . . . . . . . . . . . . . . . . 50
5.2.2 Les critères du Choix de l’outil SIEM . . . . . . . . . . . . . . . . 51
5.2.3 ELK : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.3.1 Avantages : . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.3.2 Inconvénients : . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4 OSSIM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4.1 Avantages : . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.4.2 Inconvénients : . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.5 Synthèse de choix de la solution . . . . . . . . . . . . . . . . . . . 52
Page 12
SOMMAIRE
5.2.6 Quelques capture d’écran de notre solution ELK : . . . . . . . . . . 53

5.3 Solution ELK : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.1 Les Composantes d’ELK : . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2 Elasticsearch : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.2.1 Stockage dans elasticsearch . . . . . . . . . . . . . . . . . 56
5.3.3 Logstash : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.4 Packbeat : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.5 Kibana : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Traçabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.1 Les contraintes techniques de la traçabilité . . . . . . . . . . . . . 61
5.4.2 traçabilité sur ABB . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5 Perspective : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.6 Installation d’Elasticsearch et ses plugins . . . . . . . . . . . . . . . . . . 64
5.6.1 Plugin Marvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6.2 Plugin BigDesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6.3 Plugin Elasticsearch Kopf . . . . . . . . . . . . . . . . . . . . . . . 66
5.6.4 Plugin Elasticsearch-head . . . . . . . . . . . . . . . . . . . . . . . 67
5.6.5 Plugin Whatson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7 Installation du Logstash . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.8 Installation du Logstash-forwarder . . . . . . . . . . . . . . . . . . . . . . . 72
5.9 Installation du PacketBeat . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.10 Installation du Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Conclusion générale 78
Webographie 79
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Page 1
Introduction
L’information est un élément vital pour l’entreprise du monde moderne, cette ressource
stratégique est confrontée à la diffusion et au partage perpétuellement accentué par le
développement rapide des technologies de l’information, chose qui peut engendrer une
perte de sa valeur et son contenu initial. C’est pourquoi la sécurité et la fiabilité de
l’information doivent impérativement être garanties au sein de l’entreprise. En effet, le
système d’information doit permettre d’effectuer les choix stratégiques de l’entreprise par
un management de qualité. Il permet la coordination entre différentes structures, fa-
cilite les échanges internes, soutient les activités de l’organisation et contribue ainsi à
l’amélioration des performances de l’entreprise. Ainsi, le Système d’Information néces-
site une attention particulière en matière de maintenance et de sécurité, étant donné
qu’il est exposé à des pannes et des menaces qui, de nos jours, ne cessent de s’accroître,
d’où l’exigence de l’instauration d’un système qui garantit la sécurité les données sensi-
bles de l’entreprise. Pour cela, de nombreuses techniques de sécurisation sont mises en
place, afin d’assurer le respect de bonnes pratiques de sécurité. La Sécurité des Systèmes
d’Information devient donc un enjeu crucial pour garantir la continuité des processus «
Métier », la protection du patrimoine constitué par les informations (applications, don-
nées, documents, etc.) et le respect des législations et des réglementations. Partant de
ces considérations, Barid banque ne cesse de développer et d’améliorer la sécurité de son
système informatique en respectant les normes en vigueur afin de renforcer le niveau de
sécurité de toutes les communications engageant le système d’information de la Banque,
cet objectif a été satisfait grâce à la robustesse de la solution déployée. Cependant, malgré
les efforts déployés la banque reste en défi continuel pour améliorer l’administration de
son système informatique tout en essayant de résoudre le dilemme sécurité informatique
et l’entrave à la facilité d’utilisation du système ou à la productivité des employés. Dans
ce contexte, et vu son engagement actif dans l’amélioration et l’évolution structurantes
de ses moyens Informatiques, Barid Banque a décidé de lancer un projet de centralisation
et de corrélation des fichiers journaux. Ce projet vise à déterminer une politique d’accès,
2
SOMMAIRE
garder une traçabilité et renvoyer des alertes en cas d’incidents qui touchent le Data Cen-
ter. Le présent rapport se compose de cinq chapitres. Le premier définit le contexte
général du projet à savoir ; la présentation de l’organisme d’accueil, et la description de
notre projet.
Le second intitulé « Network accès control» débutera par le contexte dans lequel est
apparu le besoin du contrôleur d’accès réseaux pour après définir ce qu’est ce mécanisme ,
faire une étude comparative des outils et ensuite choisir une solution open source (Packet-
Fence), enfin , l’explication détaillé de l’architecture de cet outil sera présenté ainsi qu’une
description de ses fonctionnalités et le chapitre sera clôturé par une simulation .
Le troisième chapitre dit « authentification forte » commencera par une définition de

ce mécanisme, une présentation des facteurs déterminants de cette technologie, ensuite
l’importance d’instaurer l’authentification forte au sein de toutes entreprises marocaines
et enfin une étude de l’existant pour dégager les points fort de cette solution.
Une étude fonctionnelle et technique est présente dans le quatrième chapitre afin de définir
les exigences fonctionnelles de l’autorisation considérée comme la clé de la voute de la
sécurité informatique, suivie d’une description des modèles de la securité , et en une ap-
plication du modèle ORBAC sur les profils de Al Barid Bank .
Arrive juste après le cinquième chapitre «Centralisation / corrélation des logs et Traça-
bilité » dans lequel on trouvera un benchmarking des outils SIEM leurs fonctionnalités
ainsi que leurs descriptions, ensuite on présentera les besoins et les contraintes de notre
choix.
L’élaboration de la partie centralisation et corrélation des logs va nous faciliter le traite-
ment de la partie Traçabilité dans laquelle on va traiter ses contraintes et on va présenter
la matrice de traçabilité ainsi que ses avantages.
Finalement on présentera une conclusion qui reprendra, d’une vision de recul et plus
global, le travail effectué durant notre stage de fin d’étude suivi des perspectives que
pourrait avoir la solution pour ainsi tirer profits des fonctionnalités et services qu’elle
offre.
Page 3
Chapter 1
Contexte général du projet :
Dans ce chapitre, nous exposons le contexte général du projet. On présente dans un

premier temps l’organisme d’accueil et ses services. Ensuite nous allons présenter les or-
ganismes ciblés par notre projet. Et enfin introduire le travail demandé.
1.1 Présentation de l’organisme :

1.1.1 L’organisme d’accueil :
Al Barid Bank, filiale de Barid Al-Maghrib, a été lancée le 8 juin 2010, pour être au
service du plus grand nombre de marocains.
Héritière de l’activité des services financiers du groupe Barid Al-Maghrib, Al Barid Bank
s’appuie sur un savoir-faire reconnu. En effet, l’exercice des services financiers par remonte
à 1926, année de création du compte chèque postal CCP.
Citoyenne, accessible, proche de ses clients, Al Barid Bank dispose d’un très large réseau,
avec plus de 1800 agences réparties sur le Royaume, aussi bien dans les zones urbaines
que dans les zones rurales les plus reculées.
Offrant une large gamme de produits et services bancaires à une tarification adaptée, Al
Barid Bank facilite l’accès aux services financiers et contribue ainsi à l’accélération de la
bancarisation des citoyens marocains.
sous le slogan Al Barid Bank se veut la banque de tous, la banque de tous les
Marocains
1.1.2 L’organigramme organisationnel :
L’organigramme Al Barid Bank se présente comme suit :
4
chapitre 1 1.1. PRÉSENTATION DE L’ORGANISME :
Figure 1.1: Organigrame Al barid Bank :
Projet Fin d’Etudes 5 2014-2015

chapitre 1 1.1. PRÉSENTATION DE L’ORGANISME :
Figure 1.2: Organisationnelle Al barid Bank
Barid Bank est hiérarchisé de la manière décrite par l’organigramme précédent. Elle est
constituée d’un directeur général qui collabore avec le directeur délégué. Le directeur
général interagit directement avec la directrice des ressources humaines ainsi qu’avec le
directeur de site. Par ailleurs, le directeur délégué, quant à lui, interagit avec le directeur
des affaires financières DAF , avec le directeur commercial et finalement avec le directeur
du système d’information. En parallèle, le département du système d’information est
divisé cinq parties, à savoir, le département infrastructure, le département application, le
département support ainsi que le département service delivery et dernièrement le départe-
ment qui s’occupe de la sécurité des systèmes d’information dans lequel nous effectuons
notre stage.

chapitre 1 1.2. PRÉSENTATION DU PROJET :
1.2 Présentation du projet :

1.2.1 Contexte du projet :
Al Barid Bank héritière de l’activité des services financiers du groupe Barid al Maghrib
elle s’appuie sur un savoir faire reconnue . Offrant une large gamme de produits et services
bancaires à une tarification adaptée aux citoyens marocains . L’exigence de la securité
des données au sein d’une banque est tres capitale dans nos jours .De nombreuses affaires
récentes ont mis en avant le probléme du respect de la vie privée sur les lieu de travail au
travers de l’utilisation parfois abusive de l’informatique et des reseaux .
Pour lutter contre la menace accidentelle ou intentionnelles de ses données , Al Barid

Bank s’engage à mettre en place des moyens pour réduire la vulnérabilité de son système
. Il convient alors d’identifier les exigences fondamentales en matière de sécurité informa-
tique . Elles caractérisent en quoi s’attendent les utilisateurs de systèmes informatiques
en regard de la securité .
Afin de répondre aux exigences cités ci-dessous ,le département de la securité des sys-
tèmes informatiques a opter pour faire signé un contrat de confidentialité pour chaque
intervenant sur le système informatique .
De surcroit , en vue de suivre les bonnes maniéres de securité des systèmes d’informations
,il est imperatif d’intégrer un système de centralisation des logs et de les corréler afin de
générer des alertes pour un dysfonctionnement du système .
Finalement ,determiner une politique d’accés aux ressources informatiques ainsi que les
rapports d’invesigations seront générés d’une maniéres automatique ou manuelle .En ef-
fet , les rapports seront générées d’une maniére mensuelle et annuelle .Ces rapports sont
destinés pour des investigations des auditeurs internes à la société pour vue de régler le
dysfonctionnement du système et avoir une transparence et une traçabilité des évènements
survenus .
1.2.2 Objectif du projet :

Notre projet a pour objectif d’instaurer une politique d’accès aux ressources infor-
matiques de plus proposer une solution qui facilitera la résolutions des anomalies qui
surviennent dans le système :
• Mise en place d’une solution d’authetification forte .

• Mise en place d’une politique d’accès (Autorisation) .
• Mise en place d’une solution NAC (Network Access Control) basée sur open source.
• Centraliser les fichiers journaux survenus dans un seul serveur .
• Corrélation des fichiers journaux .
• Faciliter la recherche des incidents.
• Génération des rapports mensuelles et annuelle .
• La Traçabilité .
1.2.3 Conduite du projet :

Un processus de développement est une démarche visant à organiser de bout en bout
le bon déroulement d’un projet informatique. C’est une étape très importante dans un
projet informatique qui peut affecter largement son aboutissement, de telle façon qu’un
mauvais choix du processus de développement peut conduire à son échec.
Un processus de développement définit une séquence d’étapes, en parties ordonnées, qui
concoure à l’obtention d’un système logiciel nouveau ou à l’évolution d’un système ex-
istant. Ce processus a pour objectif de produire des solutions informatiques de qualité
répondant aux besoins des utilisateurs dans des temps et des coûts prévisibles. De ce
fait, l’adéquation du projet au processus de développement peut largement affecter le sort
d’un projet informatique.
Vu les spécificités de notre projet résumées dans ce qui suit :
• Une grande évolutivité .
• Les exigences spécifiques de notre encadrant.
• La grande taille du projet.
Nous nous sommes focalisés sur une partie limitée et maitrisable du projet chaque
itération a un but bien précis.
A cet effet , nous avons décidé de travailler avec un processus qui s’adapte le mieux à
notre projet à savoir la méthode agile Scrum. Scrum est une méthode agile basée sur
un concept itératif et incrémental visant à produire des sous-produits à chaque itération
appelée « Sprint ».
Le mode de fonctionnement de la méthode Scrum est comme suit :

• Le projet est divisé en un ensemble de fonctionnalités.
• Les fonctionnalités sont réparties sur des itérations appelées Sprint.
• Chaque sprint dure entre 3 et 4 semaines.
1.2.4 Planning du projet

La planification du projet est une phase importante d’avant-projet. Elle consiste non
seulement à délimiter le périmètre temporel du projet, mais aussi à prévoir le déroulement
des activités tout au long de la période allouée à ce dernier. Cinq étapes ont été définies
: la première est dédiée à l’étude préliminaire pour bien délimiter le périmètre du projet.
La seconde est consacrée à l’étude fonctionnelle dont les objectifs sont de bien cerner le
sujet. Quant à la troisième étape, elle traite l’étude technique du projet. L’étape suivante
consiste en la conception de la solution, et finalement, la dernière étape consiste à la
réalisation, la validation et au déploiement de la solution. La figure suivante détaille la
planification du projet.
1.2.5 Diagramme de gantt :
Figure 1.3: Diagramme de Gantt :

chapitre 1 1.3. PÉRIMÈTRE DU PROJET
La première phase consiste à réaliser une analyse préliminaire technique consistant à :
• Recueillir l’information et les témoignages.
• Déterminer les besoins.
• Établir la liste des contraintes à respecter.
• Réaliser l’étude préliminaire.
• Offrir un deuxième avis concernant une étude préliminaire existante.
La deuxième phase est l’élaboration d’un des outils SIEM open source permettant de
réaliser une comparaison directe des fonctionnalités de chaque outil afin de procéder au
choix de l’outil qui respecte les normes, les besoins fonctionnels ainsi que les contraintes.
La phase suivante à savoir, la phase de l’étude fonctionnelle. Cette phase est divisée en
deux sous parties; la première partie permet de capturer les besoins technique de la société
pour vue de procéder à l’analyse.
La quatrième phase du projet permet l’élaboration d’une étude technique permettant

la capture des besoins techniques à partir de tous les intervenants de l’outil afin de sat-
isfaire au maximum la société en intégrant un outil de la sécurité des systèmes. Ainsi,
éditer un document technique décrivant toutes les fonctionnalités désirées.
La dernière phase de la réalisation du projet est la phase de l’implémentation de l’outil.
Celle-ci permet de suivre un enchainement structuré de l’implémentation de l’outil SIEM.
En effet, pour implémenter la solution il faudrait commencer tout d’abord par centraliser
tous les logs circulants dans le système d’information, ensuite procéder à la corrélation
de certains évènements souhaités. Ensuite, intégrer un détecteur d’intrusion et adapter
la solution du reporting selon les besoins souhaités. Finalement, la dernière sous partie
est de réaliser un jeu de test d’intrusions.
1.3 Périmètre du projet

L’objectif de cette partie est l’identification du projet ainsi que l’organisation de la
mise en oeuvre.
1.4 Mission du projet :

Dans le cadre du projet, des principales missions sont à accomplir, à savoir:

chapitre 1 1.5. LIVRABLES DU PROJET
• Etude préliminaire.
• Etude comparative des outils.
• Etude de l’existant.
• Etude fonctionnelle.
• Analyse.
• Implémentation d’une solution pour chaque partie partie : Authentification , Au-

torisation , la corrélation des événements .
• Intégration et test.
• Déploiement
• Documentation du projet.
1.5 Livrables du projet

A la fin de ce projet, des livrables doivent être clairement définis pour un résultat
conforme à des normes de qualité, pour le moindre coût et dans le meilleur délai possible.
Quelques-uns devront être livrés avec le produit final, alors que d’autres seront à la dis-
position du client et l’équipe de développement comme illustré dans le tableau ci-dessous :
ion
va lidat
e
s a ble d
se able o n
Pha Livr Resp
Initialisation Benchmark des outils MOA
cahier de charge plan-
ning
Analyse Spécifications MOA
générales
Conception Spécification fonction- MOA
nelles ,Spécifications
techniques

chapitre 1 1.6. CONCLUSION :
Réalisation Centralisation des logs MOA

- Corrélation des logs
- Traçabilité - Report-
ing personalisé
Integration et Personnalisation de la MOA
Dépoiement solution existante
Table 1.1: Tableau des livrables de projet
1.6 Conclusion :
Ce chapitre nous a permis de situer le contexte général du projet. Il nous a per-
mis de présenter l’organisme d’accueil, d’avoir un aperçu sur la problématique du projet
ainsi de comprendre ses objectifs. Le chapitre suivant décrira l’ approche de la sécurité
informatique Network Access Control (NAC) .

Chapter 2
Network Access Control
2.1 Introduction :
Network Acces Control : Un Contrôleur d’accès au réseau (Network Access Control
ou NAC) est une méthode informatique permettant de soumettre l’accès à un réseau
d’entreprise à un protocole d’identification de l’utilisateur et au respect par la machine
de cet utilisateur des restrictions d’usage définies pour ce réseau.
Plusieurs sociétés comme Cisco Systems , Microsoft ou Nortel Networks ont développé
des frameworks permettant d’implémenter des mécanismes de protection d’accès au réseau
d’entreprise et de vérifier le respect par les postes clients, des règles de sécurité imposées
par l’entreprise : état de la protection antivirus, mises à jour de sécurité, présence d’un
certificat, et bien d’autres.
Le concept du NAC existe pour répondre à une solution de sécurité toujours croissante. Le
contrôle d’accès au réseau (NAC) tient un rôle toujours plus important dans la stratégie
globale de sécurité du réseau de l’entreprise. Dès lors, les stratégies d’attaque ne dépendent
plus seulement de l’action physique de l’utilisateur, mais dépendent aussi très souvent de
sa machine qui est capable d’initier seule des processus malveillants. Le NAC constitue
donc une nouvelle phase dans la définition des critères d’accès au réseau d’où sa nécessité.
Figure 2.1: Network Access Control
13
chapitre 2 2.2. SOLUTIONS LIBRE ET COMMERCIALES
2.2 Solutions libre et commerciales

2.3 Acteurs commerciaux du NAC
2.3.1 Cisco System :
Cisco Network Admission Control (NAC) exploite au maximum l’infrastructure réseau
pour limiter les dégâts occasionnés par les virus et les vers. Le principal atout de Cisco se
trouve dans IOS (Internet Operating Sytem). Grâce à Cisco, l’entreprise peut fournir aux
unités d’extrémité comme les PC et les serveurs, un accès réseau qui respecte scrupuleuse-
ment les politiques de sécurité en place. Le dispositif de Cisco met en scène 3 acteurs
:
• un serveur chargé de la politique de sécurité du réseau Cisco Secure ACS (Access

Control Server)
• un protocole de contrôle sur le point d’accès au réseau ( AP Wifi, routeur, Switch...),
• un trust agent sur le poste de l’utilisateur (petite application).
2.3.2 NetClarity NAC Walls :

Les appareils de NetClarity « NACwalls » fournissent une évaluation des systèmes
d’extrémité. Cela garantit la conformité aux politiques de sécurité tout en bloquant
les tentatives malveillantes d’accéder au réseau. Les appareils « NACwalls » peuvent
augmenter la qualité de l’audit et elles générent des rapports de conformité qui permet
considérablement de réduire le temps, les efforts et les frais à cet égard, ils fournissent
en temps réel le contrôle interne et l’accès au réseau avec les e-mails ou les téléphones
portables .
2.3.3 Microsoft : Network Access Protection :
Network Access Protection se compose d’un serveur NPS (Network Policy Server),
qui est un serveur RADIUS, des (System Health Validator) chargés de communiquer
avec les SHA (System Health Agent) pour évaluer le système d’extrémité et un serveur
PDP (Policy Decision Point) qui définit la politique de sécurité à accorder pour chaque
machine.
Du coté client on trouve un agent NAP qui se charge de fournir un bilan de santé de
la machine. On peut lui ajouter différents plugins SHA qui regardent chacun un aspect
spécifique du système d’extrémité (anti-virus,pare-feu , registre, etc).
2.3.4 McAfee NAC
La solution McAfee NAC protège les sociétés contre les risques en contrôlant l’accès
à leurs réseaux par leurs employés, invités et sous-traitants, en tout temps et depuis tout
point. McAfee NAC apporte:
Un accès accordé uniquement aux machines exemptes d’infections.
Une gestion et un respect des politiques de sécurité grâce à « McAfee Policy Enforcer»

chapitre 2 2.4. SOLUTION LIBRE DU NAC :
2.4 Solution libre du NAC :

Il existe une multitude de solutions libres pour un NAC. Nous n’en retiendrons que
quelques-unes à savoir : PacketFence, FreeNAC, NetPass, Ring Security Analyser
2.4.1 PacketFence
Une solution comme PacketFence permet de sécuriser les branchements au réseau.
Donc, au moment où on branche le fil réseau dans son ordinateur ou au moment où on se
connecte sur le réseau sans fil, PacketFence vérifie si l’ordinateur s’est déjà connecté.
2.4.2 FreeNac:
C’est un projet actif présenté comme offrant une gestion simplifiée des VLANs, un
contrôle d’accès au réseau et un outil d’inventaire, FreeNAC est basé principalement sur
le protocole VMPS (authentification sur adresse MAC). Il permet aussi l’utilisation 802.1X
en interaction avec un serveur RADIUS. La partie évaluation n’est pas vraiment prise en
compte
2.4.3 OpenNac :
OpenNAC est un opensource Network Access Control pour les environnements LAN
/ WAN d’entreprise. Il permet l’authentification, l’autorisation et l’audit des politiques
sur la base tous les accès au réseau. Il prend en charge les diférents fournisseurs de réseau
comme Cisco, Alcatel, 3Com ou Extreme Networks, et les différents clients comme les PC
avec Windows ou Linux, Mac, appareils comme les smartphones et les tablettes.
Basé sur des composants open source , l’auto-développement et sur les normes de
l’industrie telles que FreeRadius, ,802.1x AD , , ... Il est très extensible, de nouvelles
fonctionnalités peuvent être incorporés car il est architecturé en plugins. Facilement
intégrable avec les systèmes existants . Il fournit des services à valeur ajoutée tels que la
gestion de configuration, réseau, configurations de sauvegarde, la découverte du réseau et
de surveillance de réseau.
2.4.4 Net Pass
C’est un projet non actif, par défaut les systèmes d’extrémité sont positionnés dans
un VLAN de quarantaine, celui-ci laisse passer les requêtes DHCP et DNS mais bloque le
trafic Web sauf liste blanche (sites de mise à jour). L’évaluation est faite avec Nessus, si la
conformité est bonne, le serveur Net Pass change le VLAN du poste. Une réévaluation est
possible à intervalles réguliers. Net Pass est Basé sur Open VMPS, le principe est d’isoler
les systèmes d’extrémité en les positionnant en quarantaine si leurs comportements réseau
ne sont pas en adéquation avec la politique de sécurité.
2.4.5 Rings Security Analyser
C’est un projet en production actuellement créé à l’Université du Kansas, c’est un
portail Web qui utilise une applet Java pour évaluer (système, logiciel anti-virus, etc...)
les machines cherchant à accéder au réseau (autorisation valide pendant sept jours). En
cas d’échec, les accès sont réduits aux sites de mises à jour de logiciels, d’anti-virus,...
2.5 Etude comparative des solutions open source

chapitre 2 2.6. SOLUTION PACKETFENCE
C nce
nNA etFe Nac
Ope Pack Free
Analyse des besoins équitablement oui non internet
authentification oui oui oui
gestion des bandes pas- non oui non
santes
vendor multivendor multivendor multivendor
Support pour oui oui oui
l’infrastructure filaire et
sans fil
Intégration du logiciel oui oui commercial
communauté active active assez active
interface interface web interface web basé principalem
d’administration sur les fenêtres
Compte-rendu oui oui oui
Table 2.1: Comparaison entre les outils opensource NAC
2.6 Solution PacketFence

P acketFence est une solution open source de contrôle d’accès gratuite . Bénéficiant
d’un ensemble de fonctionnalités impressionnantes, y compris un captif portail pour
l’enregistrement et l’assainissement, la gestion centralisée filaire et sans fil, de puissantes
options de gestion du BYOD, support 802.1X, l’isolation de couche 2 du modèle OSI des
dispositifs problématiques; PacketFence peut être utilisé pour sécuriser efficacement les
petits réseaux à très grands réseaux hétérogènes. Parmi ses différents marchés sont:
• Les banques
• Les collèges et les universités
• les sociétés d’ingénierie
• Les centres de congrès et d’exposition
• Les hôpitaux et centres médicaux
• hôtels.
• Les entreprises manufacturières
• les conseils scolaires
• Les entreprises de télécommunications
Distribué sous la licence GPL.

2.6.1 Conformité
2.6.1.1 Détection des anomalies des Activités du réseau:
les Activités de réseau anormales (virus d’ordinateur, les vers, les logiciels espions,
trafic nié par la politique de l’établissement, etc.) peuvent être détectés à l’aide locale
et distante Snort . Au-delà de la simple détection, les couches PacketFence ont leurs
propre mécanisme d’alerte et de suppression sur chaque type d’alerte.Elles proposent Un
ensemble d’actions configurables pour chaque violation pour les administrateurs.
2.6.1.2 Les analyses proactives de vulnérabilité
Les analyses de vulnérabilité peuvent être effectuées lors de l’enregistrement, prévu
ou sur une base ad hoc. PacketFence corrèle les Nessus / openvas les identifiants de la
vulnérabilité de chaque balayage de la configuration de la violation, le retour est contenu
dans des pages web spécifiques, que la vulnérabilité de l’hôte peut avoir.
2.6.1.3 Isolement de périphériques problématiques
P acketFence prend en charge plusieurs techniques d’isolation, y compris l’isolement

VLAN VoIP avec le soutien (même dans des environnements hétérogènes) pour de
multiples fournisseurs de commutateurs.
2.6.2 Architecture de packetFance
Figure 2.2: Architecture de packetFence

Figure 2.3: Composants de packetFence
2.6.3 Fonctionnalités :
Note : Dans la section suivante, noeud est utilisé pour désigner un dispositif sensible au réseau
qui est contrôlé et surveillé par PacketFence. Il peut être un PC, un ordinateur portable, une
imprimante, un téléphone IP, etc
2.6.3.1 Gestion flexible VLAN et le contrôle d’accès basé sur les rôles
La solution est construite autour de la notion d’isolement du réseau par affectation de
VLAN. En raison de sa longue expérience et plusieurs déploiements, la gestion des VLAN
PacketFence a grandi pour être très flexible au fil des ans. La topologie du VLAN peut
être maintenu telle qu’elle est et que deux nouvelles options doivent être ajoutées tout au
long du réseau: enregistrement VLAN et l’isolement VLAN. En outre, PacketFence peut
également faire usage de rôles soutien de nombreux fournisseurs d’équipements.
Les rôles peuvent être assignés en utilisant les divers moyens:
• Par commutateur (par défaut pour VLAN) .
• Par catégorie de client (par défaut pour les rôles).
• par client.
• Utilisation de toute décision arbitraire (si vous utilisez nos points d’extension de
perl).

Aussi, le procédé par-interrupteur peut être combiné avec les autres. Par exemple, avec
une configuration de PacketFence par défaut, un VLAN ou un rôle peuvent être assignés à
vos imprimantes et vos pc (si classés correctement) sur la base de ce que l’équipement qu’ils
sont connectés. Cela implique que vous pouvez facilement avoir le type par périphérique
par le renforcement des réseaux locaux virtuels.
2.6.3.2 Accès clients
De nos jours, la plupart des organisations traitent avec beaucoup de consultants auprès
de diverses entreprises sur place qui nécessitent un accès à Internet pour leur travail. Dans
la plupart des cas, un accès au réseau d’entreprise est donné avec peu ou pas de vérifica-
tion de l’individu ou le périphérique. En outre, il est rarement nécessaire qu’ils aient accès
à l’infrastructure interne de l’entreprise, il est fait de cette façon pour éviter (gestion de
VLAN par port) les fardeaux administratifs.
PacketFence prend en charge un VLAN d’invité spécial ou le rôle de la boîte. Si vous

utilisez un VLAN invité, vous configurez votre réseau afin que le VLAN invité ne va que
vers l’Internet et le VLAN d’inscription et le portail captif sont les composants utilisés
pour expliquer au client comment s’inscrire à l’accès et comment ses œuvres/ d’accès.
Ceci est habituellement marqué par l’organisation qui offre l’accès au réseau. Plusieurs
moyens des enregistrements des clients sont possibles:
• L’enregistrement manuel des clients.
• Mot de passe de la journée.
• Auto-inscription (avec ou sans pouvoirs).
• Accès invité parrainage (employé se portant garant pour un invité).
• Accès invité activé par courriel de confirmation.
• Accès invité activé par la confirmation de la téléphonie mobile (par SMS).
• Accès invité activé par une authentification Facebook / Google / GitHub
2.6.3.3 Profils
PacketFence soutient le concept de profil du portail. Un profil de portail définit le flux
de travail d’enregistrement qui sera utilisé, avec des pages d’inscription et d’assainissement.
Avec PacketFence, vous pouvez définir des profils de portails différents basés sur un VLAN
ou un attribut SSID. Cela signifie, par exemple, que vous pouvez définir des profils de
portails différents pour vos réseaux filaires et sans fil. Ou, vous pouvez définir par- portail.
2.6.3.4 Plus intégrités sur les types de violation
PacketBeat peut bloquer automatiquement des périphériques particuliers dans votre
réseau . En plus d’utiliser Snort, OpenVAS ou Nessus comme une source d’information,
PacketFence peut combiner les mécanismes de détection suivantes pour bloquer efficace-
ment l’accès au réseau à partir de ces périphériques indésirables:

DHCP empreintes : PacketFence peut bloquer les périphériques en fonction de leur em-
preinte DHCP. Presque tous les systèmes d’exploitation là-bas ont une empreinte DHCP
unique. PacketFence peut faire usage de cet accès de ces dispositifs réseau d’informations
et de bloc. Basé sur les empreintes digitales DHCP, vous pouvez bloquer automatique-
ment, par exemple:
•Appareils Sony PlayStation ou d’autres consoles de jeux .
•les points d’accès sans fil WAP
•les téléphones VoIp.
User-Agent PacketFence: peut bloquer les appareils basés sur la condition User-Agent
lorsque ces dispositifs particuliers effectuent l’activité du réseau en utlisant leur naviga-
teur Web integré . Avec cela , vous pouvez bloquer automatiquement ,par exemple :
•les appareils iPhone ou Apple iPod .
•Toute personne utilisant l’ancien navigateur Web Internet Explorer .
Adresses MAC : PacketFence peut bloquer l’accès réseau aux périphériques ayant une
adresse MAC modèle spécifique. Avec cela, vous pouvez bloquer automatiquement, par
exemples, tous les périphériques à partir d’un fournisseur de réseau spécifique.
2.6.3.5 Enregistrement automatique :
Par dispositif de réseau Un dispositif de réseau (Switch, AP, manette sans fil) peut
être configuré pour enregistrer automatiquement toutes les adresses MAC qui de-
mandent l’accès au réseau. Très utile pour une transition en production.
Par DHCP empreintes digitales Les empreintes DHCP peuvent être utilisé pour en-
registrer automatiquement certains types de périphériques (par exemple. Les télé-
phones ,... ).
Par adresse MAC vendeur La partie de fournisseur d’une adresse MAC peut être
utilisé pour enregistrer automatiquement les périphériques à partir d’un fournisseur.
Par exemple, tous les produits Apple pourraient être enregistrés automatiquement
en utilisant une telle règle.
2.6.3.6 Authentification flexible :
PacketFence peut authentifier vos utilisateurs en utilisant plusieurs protocoles et
normes. Cela vous permet d’intégrer PacketFence dans votre environnement sans
que vos utlisateurs ne soient obligés de se rappeler plusieurs nom d’utlisateurs et
mot de passe . Les sources d’authentification prises en charge sont:
• LDAP
– Microsoft Active Directory
– Novell eDirectory
– OpenLDAP
– ... Ou tout serveur compatible LDAP

chapitre 2 2.7. CONCLUSION :
• RADIUS
– Cisco ACS
– RADIUS (FreeRADIUS, radiateur, etc.)
– Microsoft NPS NPS
– ... Ou tout serveur compatible RADIUS Fichier utilisateur local (format
htpasswd Apache)
• OAuth2
– Facebook
– Google
– GitHub
– LinkedIn
– Microsoft Live
En outre, PacketFence peut également utiliser sa base de données SQL interne pour
authentifier les utilisateurs créés localement.
2.7 Conclusion :
Au terme de notre étude qui portait sur l’étude de la sécurisation d’un réseau par la
mise en ouvre d’un NAC, il en ressort que, l’idée du NAC ressemble à une combinai-
son d’outils de protection déjà connus : authentification renforcée, application de
politiques de sécurité par utilisateurs, application et ressource réseau, vérification
des mises à jour de sécurité et gestion d’un annuaire.
Les solutions de contrôle d’accès réseau permettent aux employés et aux non em-
ployés, ainsi qu’aux équipements gérés et non gérés, de partager un accès à la même
infrastructure de réseau. Ces systèmes de sécurité par le contrôle des accès au réseau
représentent une solution de sécurisation complète des ressources et applications par
le contrôle de l’accès de tous les utilisateurs.
Pour mener à bien notre projet, nous avons fait une étude détaillée des contrôleurs
d’accès réseau et une mise en ouvre d’une solution de sécurité (PacketFence).
Nous pouvons donc retenir qu’avec une solution de contrôle d’accès réseau, l’entreprise
peut contrôler les connexions distantes d’une part, imposer des règles de sécurité
selon les différents réseaux et les rôles des utilisateurs d’autre part, ou bien encore
mettre à jour ses postes de travail et les nettoyer en cas d’infection. Enfin, une solu-
tion NAC gère les profils par le biais d’un annuaire, le pare-feu se reliant directement
aux annuaires.

Chapter 3
Authentification forte
Dans ce chapitre on donnera une définition de l’authentification ainsi que ses dif-
férents facteurs, ensuite on va se focaliser sur l’authentification forte et enfin on
présentera l’outil utilisé par Al Barid Banque pour répondre à ses besoins .
3.1 Définition de l’authentification :

L’authentification est la procédure qui consiste, pour un systeme informatique , à
vérifier l’identité d’une personne ou d’un ordinateur afin d’autoriser l’accès de cette
entité à des ressources (systemes, reseaux , application . . . )1 . L’authentification
permet donc de valider l’authenticité de l’entité en question.
3.2 Les facteurs d’authentification :

L’authentification désigne le processus visant à confirmer qu’un commettant est bien
celui qu’il prétend être. Il existe quatre facteurs d’authentification classiques qui
peuvent être utilisés pour confirmer l’identité d’un commettant:
Facteur mémoriel (ce qu’il sait) • Empreinte : une information qu’il a mé-
morisée.
• Exemples : le nom de sa mère ou un mot de passe.
Facteur matériel (ce qu’il possède) • Empreinte : une information contenue
dans un objet qu’il utilise.
• Exemples : une clé USB, un identifiant sur bande magnétique , un certificat
numérique sur une carte à puce .
Facteur corporel (ce qu’il montre) • Empreinte : une trace corporelle qu’il
peut laisser quelque part.
• Exemples : une empreinte digitale , les caractéristiques de sa pupille, sa
voix.
Facteur réactionnel (ce qu’il fait) • Empreinte : un geste qu’il peut repro-
duire.
22
chapitre 3 3.3. DEFINITION DE L’AUTHENTIFICATION FORTE :
• Exemples : sa signature .
D’autres facteurs d’authentification peuvent parfois être utilisés comme les con-
traintes temporelles ou les capacités de localisation
3.3 Definition de l’authentification forte :

On appelle authentification forte tout système permettant un accès informatique
après une double vérification ,donc c’est une procédure d’identification qui requiert
la concaténation d’au moins deux facteurs d’authentification .L’objectif est de pal-
lier les faiblesses de l’authentification unique par mot de passe. En effet, les mots de
passe peuvent être volés, forcés et posent un problème de mémorisation à l’utilisateur
et de renouvellement à l’entreprise.
L’authentification forte s’appuie sur d’autres concepts que celui des mots de passe.
Le premier d’entre eux étant celui du jeton unique. Le principe est simple : il s’agit
d’un algorithme de génération de mots de passe unique, à durée de vie courte, qui
se synchronise avec une application cliente installée sur le poste de travail. Cet
algorithme peut être installé sur une calculette se contentant alors d’afficher le code
généré, sur une clé USB, qu’il faudra brancher à l’appareil, ou sur une carte à puces
qui transmet le code par contact avec un appareil de lecture. Le mot de passe ainsi
généré n’est valable que pour une période de temps de 1 à 2 minutes.
Il existe également des cartes reposant sur le principe du jeton unique mais sans
code à saisir pour l’utilisateur. La transmission de ce code s’effectue alors par ondes
sonores, mais nécessite la mise en place d’un récepteur. Enfin, le principe du jeton
est aussi appliqué sur des cartes plastiques imprimés. Sur ces cartes figurent une
série de numéro et l’utilisateur découvre leur ordre d’entrée et la composition du
code unique lors de la phase d’authentification. Le logiciel client se charge de lui
indiquer la ligne et la colonne du chiffre à saisir pour s’authentifier.
Deuxième solution d’authentification forte mise en place, cette fois-ci pour sécuriser
les accès aux services Internet : les certificats électroniques, qui appliquent en par-
tie le principe du jeton sur le Web. Les certificats électroniques sont des fichiers
attestant de l’identité de l’auteur en liant par exemple son mot de passe à des ren-
seignements personnels (date de naissance, numéro de sécurité sociale). Le certificat
électronique envoie ensuite ces informations à un serveur central qui vérifie que ce
fichier est bien représenté dans sa base de données avant de lui autoriser l’accès aux
services Web.
Contrairement au principe du jeton, les certificats électroniques disposent d’une
durée de vie plus longue, en moyenne de quelques semaines mais qui peut s’étaler
sur plusieurs années. Autre différence, le jeton n’est pas émis par une carte que
possède l’utilisateur mais par le serveur, après saisie des données personnelles de
l’utilisateur. Aussi, si l’utilisateur perd son certificat électronique, il peut en rede-
mander un autre et s’authentifier rapidement.
Il existe toutefois deux limites aux certificats électroniques. D’abord, cela implique
un cadre juridique strict de gestion des identifiants utilisateurs et il paraît délicat

chapitre 3 3.3. DEFINITION DE L’AUTHENTIFICATION FORTE :
d’imposer à l’utilisateur une base de données centrale où repose l’ensemble de ses

certificats traçant ses connexions. D’autre part, le certificat électronique peut être
intercepté, volé, répliqué et utilisé en accédant au poste de l’internaute, ce qui ne
garantit donc pas que le porteur du certificat soit bien son créateur.
Sans doute la méthode la plus prometteuse, mais aussi la plus délicate à mettre
en ouvre, la biométrie appartient à la catégorie des technologies d’authentification
forte. Elle repose sur des systèmes de capture d’images couplés à une base de
données centrale stockant les informations personnelles. On distingue 4 catégories
d’applications à la biométrie : la reconnaissance digitale, la reconnaissance d’iris,
la reconnaissance faciale et la reconnaissance vocale. L’avantage de ces méthodes
est clair : l’utilisateur a toujours sur lui ses "codes d’authentification" et ne peut les
perdre ou les oublier...
Il existe toutefois - outre son coût - plusieurs limites à la biométrie. Tout d’abord
l’aspect juridique, les droits des personnes étant fichés, leurs caractéristiques mor-
phologiques aussi. Ces bases de données sont à rapprocher de celles utilisées par la
police et donc soumises à des lois très strictes. D’autre part, les données peuvent
être falsifiées dans le cas de la reconnaissance digitale ou de la reconnaissance vocale.
Enfin, la biométrie pose le problème de la qualité de l’authentification. Ces méth-
odes ne sont en effet pas toujours fiables à 100%, ce qui empêche des utilisateurs
de bonne foi d’accéder à leur système. L’un des axes de recherche de la biométrie
porte donc sur la multimodalité, c’est-à-dire la combinaison de plusieurs méthodes
d’identification par voie biométrique
Les solutions d’authentification forte s’appuient sur de nombreux protocoles de sécu-
rité, de manière à acheminer l’information personnelle de l’utilisateur de la manière
la plus sure jusqu’au serveur d’authentification. Sur le Web, le protocole HTTPS se
base sur le procédé de cryptographie SSL (Secure Sockets Layers) qui s’assure que
les paquets échangés entre le serveur et le client ne sont pas lisibles de l’extérieur.
Dans les réseaux étendus d’entreprise, cette fonction est assumée par le protocole
IPSec, géré par la majorité des réseaux privés virtuels (VPN).
Dans les réseaux internes, il existe différentes couches de sécurité. Sur les réseaux
mobiles, le protocole 802.11i remplit ce rôle de cryptage tandis que les réseaux fixes
utilisent depuis longtemps le 802.10. Mais derrière l’ensemble de ces protocoles se
trouve l’algorithme de cryptage AES (Advanced Encryption Standard), créé en 1998
et capable de générer des clés uniques de 128 à 256 bits. Ce système offre des mil-
liards de possibilités de code, ce qui le rend presque insensible à des techniques de
déchiffrage par la force (en essayant de multiples combinaisons).
Parallèlement à AES, il existe le protocole de cryptage PGP, fréquemment utilisé
pour chiffrer le contenu des e-mails envoyés sur Internet. Cet algorithme est mis
à disposition de tous en libre accès depuis 1991 et a donné lieu à de nombreuses
implémentations depuis.
L’authentification est traitée dans le chapitre 11 de la norme ISO/CEI 27001 qui est
le contrôle d’accès, la norme souligne qu’il faut utiliser une authentification à deux
facteurs pour les ressources critiques de l’entreprise, ces ressources seront identifié

chapitre 3 3.4. LES FACTEURS D’AUTHENTIFICATION
lors de la présentation de l’existant dans le chapitre suivant.La certification ISO

27001 est une certification accessible à tous, elle fait une démonstration universelle
et formelle, de sa volonté de s’améliorer en sécurité et de respecter un minimum
en sécurité, elle offre une description pratique et détaillée de la mise en œuvre des
objectifs et mesures de sécurité. La norme fournit des indicateurs clairs et fiables
ainsi que des éléments de pilotage financier aux directions générales ; et permet
entre autre d’identifier plus efficacement les risques et les coûts associés,
3.4 les facteurs d’authentification

3.4.1 OTP
(One Time Password) : technologie basée sur l’utilisation d’un secret partagé qui
permet de s’authentifier avec un mot de passe à usage unique.
3.4.2 PKI
PKI (Public Key Infrastructure) : Infrastructure à clés publiques (ICP) ou in-
frastructure de Gestion de Clefs (IGC), ensemble de ressources et de procédures
destinées à gérer le cycle de vie des certificats numériques. Certificat Numérique
: Carte d’identité numérique dont l’objet est d’identifier une ressource du système
d’information, une autorité de certification fait foi de tiers de confiance et atteste
du lien entre l’identité numérique et la ressource.
3.4.3 Code NIP
: suite de chiffres destinée à authentifier le propriétaire d’une carte de GAB, d’une
carte de paiement, d’une carte à puce ou d’une carte SIM. Le NIP ne doit être
composé que de chiffres, quatre ou plus,
3.4.4 Biométrie
identification des personnes en fonction de caractéristiques biologiques telles que les
empreintes digitales, palmaires, traits du visage, etc.
3.4.5 SSO
L’authentification unique (ou identification unique ; en anglais Single Sign-On :SSO
) est une méthode permettant à un utilisateur d’accéder à plusieurs applications
informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentifi-
cation.
3.4.6 ACS (Access Control System ) et l’authentification
forte
La version actuelle à ABB sous forme d’ACS « appliance » hormis l’usage du mot
de passe pour s’authentifier,ACS supporte l’authentification par certificats électron-
iques pour un usage avec les protocoles d’authentifications (EAP-TLS, EAP- FAST,
PEAP) et pour accéder à l’interface web de l’ACS en utilisant le protocole https.
Pour cela une confiance mutuelle exige que l’ACS a un certificat installé qui peut

chapitre 3 3.5. ETUDE DE L’EXISTANT :
être vérifié par l’utilisateur, ce certificat serveur peut être fournit par une autorité
de certification ou un certificat auto-signé. Avec une bonne gestion l’utilisation des
certificats peut être plus sure que le mot de passe. En ce qui concerne l’intégration
de l’authentification forte il faut généralement passer par un ACS tournant sur un
serveur Windows pour pouvoir l’implémenté avec d’autres solutions
3.4.7 Authentification par Active Directory :
L’Active Directory est un système d’exploitation réseau de «Microsoft», développé
en dessus du système d’exploitation Windows . Ce dernier permet aux administra-
teurs de gérer d’une manière efficace les informations d’une entreprise en s’appuyant
sur un dépôt central de données qui peut être globalement distribué. Les informa-
tions sur les utilisateurs, les groupes, les machines, les applications et les services
sont ajoutés à l’AD, elles sont stockées sous formes d’objets, c’est-à-dire un ensemble
d’attributs représentant un élément concret.
Les objets sont organisés hiérarchiquement selon un schéma (lui-même stocké dans
l’annuaire) définissant les attributs et l’organisation des objets. La base de données
qui va abriter ces objets est stockée dans un fichier NTDS.DIT dans le contrôleur
de domaine.
L’interrogation et la modification du service d’annuaire se fait par le protocole
LDAP. AD utilise le protocole de sécurité Kerberos comme mécanisme d’authentification
.
3.5 Etude de l’existant :

Dans le but de bien sécuriser l’accès à son Datacenter Barid bank a investi dans les
nouvelles technologies par suite il utilise la solution NeXuS pour l’authentification
forte . Cette technologie offre aux utilisateurs et partenaires de Barid bank , des
solutions d’accès distants pour accéder de façon sécurisée aux applications critiques,
depuis tout type de dispositif et depuis n’importe quel lieu
3.5.1 NeXus Hybrid Access Gateway :

NeXus Hybrid Access Gateway est une solution qui nous permet de gérer tout type
d’accès en toute sécurité et avec la simplicité d’une application virtuelle, quels que
soient les équipements. Pas de logiciel à installer ni de système d’exploitation à
maintenir : installez simplement l’appliance par le Cloud . NeXus Hybrid Access
Gateway offre une remarquable solution d’accès distant qui assure la disponibilité
des applications sur site et sur le cloud sur n’importe quel périphérique ou plate
forme. La solution est également parfaitement adaptée à des scénarios de type
BYOD (Bring Your Own Device). L’utilisation des technologies HTML5 et des
websockets permet la virtualisation des applications, les rendant accessibles à partir
de n’importe quels périphérique ou plateforme.Les bénéfices qu’ON pourrait tirer
grâce à l’utlisation de cette solution :

• Une plus grande sécurité .

• Une utilisation simplifiée .
• Une administration minimale.
Parmi les avantages de Nexus Hybrid
Authentification polyvalente et adaptée en fonction des risques : Une au-

thentification solide à plusieurs facteurs protège contre l’hameçonnage, le cas-
sage de mot de passe, les enregistreurs de frappe et autres méthodes d’usurpation
d’identité. La solution NeeXus Hybrid Access Gateway offre un grand nombre
de méthode d’authentification avec différents degrés au sein d’une seule solution
polyvalente et intégrée. Les organisations peuvent autonomiser leurs utilisa-
teurs en leur fournissant une technolo gie d’authentification conviviale, facile à
gérer, économique et sûre. L’étendue des différentes méthodes d’authentification
permet une stratégie d’authentification polyvalente.
Sécurité des applications mobiles : La solution NeXus propose également une
authentification solide et des identités électroniques sécurisées pour les appli-
cations mobiles grâce à la prise en charge des normes OAuth 2.0. Le système
d’autorisation OAuth 2.0 fournit aux applications (sur le web ou mobiles) un
accès délégué et limité à des services HTTP et API.
Politiques d’accès: La fonction SSL VPN / reverse proxy sécurise le canal entre
l’utilisateur et l’application. D’autre part le serveur d’authentification forte
embarqué et la fonction de Single Sign On (SSO) apportent un niveau de
sécurité et une convivialité optimale.
Un portail adaptatif Le serveur web intégré améliore la facilité d’utilisation et la
sécurité. Le portail s’adapte à tout type de dispositifs pour un affichage opti-
mal (écrans tactiles, tablettes, smartphones). Les utilisateurs peuvent organ-
iser leurs favoris et les politiques d’accès garantissent que seuls les utilisateurs
autorisés accèdent à leurs applications et données. Toutes les applications web
sont accessibles. HTML5 et les websockets permettent également l’utilisation
d’applications non web virtualisées dans les browsers ainsi que la prise en charge
des bureaux à distance.

Figure 3.1: Architecture Nexus
-Single Sign On L’authentification unique est une fonction très importante. Elle
réduit considérablement l’administration des mots de passe et simplifie l’expérience
utilisateur qui s’authentifie une seule fois. Le support de SAML ( Security As-
sertion Markup Language ) permet de sécuriser les identités et d’implémenter
la fédération d’identité vers des applications Cloud privées ou publiques. Les
fonctions SAML supportées sont :
• SAML identité et fournisseur de services .
• Les Profils de bases.
• Navigateur Web SSO Profil Avec redirection.
-L’Autorisations et Politiques des Accès Tous les accès au système sont basés
sur des politiques dyna miques pour une sécurité optimale. La gestion des
autorisations est très granulaire et peut s’appliquer sur de nombreux critères
(type d’accès, type d’authentification, plage horaire, etc.). L’Authentification
unique (SSO) est un fondement dans le système : toutes les autorisations
d’accès sont faites par le moteur d’autorisation à l’aide de contrôles d’accès
basés sur les rôles et les attributs.
-L’Administration En tant qu’appliance virtuelle, NeXus Hybrid Access Gateway
bénéficie d’une administration simplifiée en facilitant les dé ploiements, les

mises à niveau et la maintenance, le tout grâce à des processus automatisés

paramétrables dans une interface web.
-L’Audit Lors d’un audit, toutes les données sont à votre disposition. La fonction
d’audit consolidée vous révèle qui a fait quoi, quand, où et comment, appor-
tant une aide précieuse pour les responsables de la conformité. Il est possible
d’effectuer un reporting en temps réel ou historique sous différents formats,
tels que : graphiques par secteurs, linéaires, 3D et histogrammes. Toutes les
données sont exportables en format texte pour qu’elles puissent être facilement
retraitées, par exemple dans un tableur.
-Données des utilisateurs Les données liées aux utilisateurs de NeXus Hybrid
Access Gateway contiennent des informations cruciales telles que les paramé-
trages des méthodes d’authentification, les credentials SSO et les attributs.
Ces objets résident par défaut dans un annuaire LDAP intégré. Il est bien
évidement possible de s’appuyer sur un annuaire tiers, tel que Microsoft Active
Directory (AD), Novell eDirectory, SUN, OpenLDAP.
3.5.1.1 -Simplicité pour les utilisateurs

Ce système simplifie la vie des utilisateurs finaux car tout est géré au moyen d’un
navigateur. Du fait qu’il est indépendant des plateformes, aucune installation sur
les postes clients n’est requise. Le portail web adaptif détecte l’appareil favori de
chaque utilisateur : chacun obtient la même expérience, avec une optimisation pour
les caractéristiques spécifiques de certains appareils, par exemple les écrans tactiles
et les tablettes.
3.5.1.2 -Plus de sécurité, moins d’administration

« Security Through Simplicity » : ce thème est un objectif majeur chez NeXus.
Nous pensons que les solutions de sécurité trop complexes ne sont pas toujours les
plus sécurisantes. Hybrid Access Gateway simplifie l’administration tout en aug-
mentant la flexibilité.
Vous constaterez les avantages au quotidien. Par exemple, pas besoin d’administrer
les appareils mobiles, car rien n’est installé sur les appareils des utilisateurs. La
gestion des groupes d’utilisateurs s’appuie le plus souvent sur les référentiels déjà
en place. Toutes les communications sont chiffrées pour assurer une sécurité opti-
male, et l’authentification forte garantie que seuls les utilisateurs autorisés peuvent
se connecter et accéder au portail.
3.5.1.3 La solution hybride :

Le fort potentiel des applications déployées dans le Cloud crée un nouveau type
d’architecture pour les entreprises dites à « connexions hybrides ». La capacité de
placer des applications dans le cloud et dans les locaux de l’entreprise facilite leur
utilisation tout en supprimant les contraintes liées à l’administration des serveurs.

chapitre 3 3.6. AVANTAGES
La solution Hybride assure également des accès sécurisés aux applications, car les
identités et l’authentification des utilisateurs sont transférées entre des domaines de
sécurité.
3.6 Avantages
NeXus Hybrid Access est une solution qui allie entre la simplicité et l’efficacité parmi
ses avantages on trouve :
• Une vue unifiée pour l’utilisateur final quant aux applications autorisées
• Des étapes de configuration simples
• Une protection instantanée
• Toutes les applications web traditionnelles demeurent accessibles
3.7 Fonctionnalités
Les fonctionnalités de cette solution sont :
• Authentification forte (plusieurs méthodes : authentification à 1/2 facteurs,

authentification tièrces parties, ...)
• Interfaces annuaires Microsoft Active Directory (AD), Novell eDirectory, SUN,
OpenLDAP
• SSO ( Single Sign On)
3.8 Conclusion :
A travers ce chapitre nous avons montré l’importance de l’authentification forte
au sein d’une entreprise et nous avons présenté la solution utilisée par AL BARID
BANK . En adaptant le modèle AAA (Authentification , Autorisation, tracabilité) ,
le chapitre suivant présentera le deuxième point de ce modèle qui est l’Autorisation.

Chapter 4
Autorisation
Ce chapitre est consacré à la définition de la politique de sécurité et la présentation

des différents modèles de contrôle d’accès ainsi que leurs limites et avantages. Après
cette étude , on a choisi le modèle O-RBAC pour réaliser une simulation sur des
profils virtuels .
4.1 Définition de la politique d’accès :

Le contrôle d’accès : consiste à vérifier si un sujet (utilisateur, processus, etc.) de-
mandant d’accéder à une ressource (fichier, mémoire, etc.) possède suffisamment le
droit pour le faire. Le contrôle d’accès est basé sur une politique de contrôle d’accès
qui est spécialisée pour la gestion des permission.La politique de contrôle d’accès
est structurée selon un modèle qui est responsable de la prise de décision (accord ou
refus) d’une demande d’accès. Les modèles traditionnels de contrôle d’accès sont : le
contrôle d’accès par mandat (Mandatory Access Control -MAC ), le contrôle d’accès
discrétionnaire (Discretionary Access Control - DAC ). MAC est un mécanisme de
contrôle d’accès basé sur l’étiquetage (exemple : Top Secret , Secret , Unclassified )
des différentes entités (sujets et objets) du système. DAC est un mécanisme décen-
tralisé basé sur l’utilisateur dans lequel le créateur d’une donnée possède la pleine
discrétion de définir les autorisations. En 2003, il avait l’apparition du modèle de
contrôle d’accès basés sur les rôles (Rôle-Based Access Control-RBAC) .une poli-
tique RBAC est, d’une part un ensemble d’affectation des utilisateurs à des rôles
et d’autre part un ensemble d’attributions des permissions à ces des rôles et par la
suite, une demande d’accès d’un sujet à une ressource est accordée s’il joue un rôle
auquel est associé ce privilège. Plusieurs modèles se sont inspirés de RBAC pour,
soit organiser des politiques au moyen de concepts supplémentaires (par exemple,
équipe, tâche, organisation) pour améliorer leur pouvoir expressif et leur flexibilité:
le contrôle d’accès basé sur l’équipe (Team-Based Access Control - TMAC ), con-
trôle d’accès basé sur des tâches (Task-based Authorization Controls - TBAC ) et
le contrôle d’accès basé sur l’organisationv(Organisation-Based Access Control - ).
Soit de l’étendre en ajoutant par exemple, des contraintes temporelles, spatiales ou
31
chapitre 4 4.2. POLITIQUE DE SÉCURITÉ :
géographiques).
4.2 Politique de sécurité :

4.2.1 Définition :
Une politique de sécurité est « l’ensemble des lois, règles et pratiques qui régissent
la façon dont l’information sensible et les autres ressources sont gérées, protégées et
distribuées à l’intérieur d’un système spécifique» .
Une politique de sécurité se construit en définissant les propriétés à satisfaire par le
système, et en établissant un schéma d’autorisation qui doit avoir, en principe, une
politique cohérente. La politique de sécurité prend en compte les aspects organi-
sationnels et techniques qui définissent comment les utilisateurs peuvent manipuler
l’information. Les propriétés de sécurité peuvent être définies en fonction de la
confidentialité, l’intégrité et la disponibilité . Le développement d’une politique de
sécurité peut être réalisé dans trois directions distinctes, à savoir : physique, ad-
ministrative et logique.
• Physique : Cette politique précise un ensemble de procédures et de moyens

qui protègent les locaux et les biens contre des risques majeurs (incendie, inon-
dation, etc.) et contrôlent les accès physiques aux matériels informatiques et
de communication (gardiens, codes, badges, ...).
• Administrative : cette politique définit un ensemble de procédures et moyens
qui traite tout ce qui ressort de la sécurité d’un point de vue organisationnel
au sein de l’entreprise.
La structure de l’organigramme ainsi que la répartition des tâches (séparation des

environnements de développement, d’industrialisation et de production des appli-
catifs) en font partie. Les propriétés de sécurité recherchées visent, par exemple, à
limiter les cumuls ou les délégations abusives de pouvoir, ou à garantir une sépara-
tion des pouvoirs.
• Logique : C’est la politique de sécurité qui fait référence à la gestion du con-

trôle d’accès logique, lequel repose sur un triple service :
. Service Identification : Identifier de façon unique un sujet grâce à un identi-
fiant.
. Service d’authentification : S’assurer que l’identité du sujet est bien celle
qu’il prétend être.
.Service d’autorisation : Déterminer si le sujet authentifié peut effectuer l’action
désirée sur l’objet spécifié.
Le contrôle d’accès spécifie qui peut accéder à quoi et dans quelle circonstance,
l’autorisation consiste à administrer et à examiner les droits d’accès, en fonction

chapitre 4 4.2. POLITIQUE DE SÉCURITÉ :
des spécifications de la politique de sécurité, ces spécifications sont générale-

ment des :
1. Permission : Sujet a le droit de lire Objet.
2. Interdiction Sujet n’a pas le droit d’écrire dans Objet.
3. Obligation Sujet doit conserver Objet.
4.2.2 Les politiques et les modèles de contrôle d’accès :

Le modèle de contrôle d’accès est matérialisé par un ensemble de mécanismes. Il
peut être défini comme un formalisme, souvent mathématique, qui consiste à vérifier
si un sujet (utilisateur, processus . . . ) demandant d’accéder à un objet (ressource,
autre sujet...) possède les droits nécessaires pour le faire. Le contrôle d’accès per-
met donc de limiter l’accès des sujets aux objets, il a pour but principal de protéger
les données et les ressources du système contre la révélation et la modification non
autorisées tout en assurant leur disponibilité aux utilisateurs légitimes. Le sys-
tème de contrôle d’accès doit être capable de contrôler tout accès au système et
à ses ressources en assurant les accès autorisés et seulement ceux-ci. Les schémas
d’autorisation des politiques de sécurité sont classés en trois grandes familles:
• Les politiques discrétionnaires (Discretionary Access Control - DAC)

• Les politiques obligatoires (Mandatory Acces control-MAC)
• Les politiques basées sur les rôles (Role-Based Access Control - RBAC)
Généralement, on adapte à des organisations particulières d’autres politiques comme:

TBAC (Team-Based Access Control Model) ,TMAC (Task-Based Access Control)
, HRU (Harrison, Ruzzo and Ullmann) , BLP (Bell et Lapadula) et ORBAC (Or-
ganization Based Access Control) . Normalement, il faut construire une politique
de sécurité de telle sorte qu’aucune séquence valide d’applications des règles (du
schéma d’autorisation) ne puisse amener le système dans un état tel qu’un objectif
de sécurité soit violé, en partant d’un état initial sûr (on parle de politique de sécu-
rité cohérente).
Ceci suppose l’utilisation d’une méthode formelle de construction des règles du
schéma d’autorisation, à partir d’une spécification formelle des objectifs de sécu-
rité.
Matrice de contrôle d’accès : La matrice de contrôle d’accès (introduite par

Butler Lampson en 1971 ) est une matrice à deux dimensions représentant, pour
chaque sujet, les actions qu’il peut effectuer sur chaque objet. Il s’agit donc d’une
représentation naturelle des relations entre les sujets et les objets. Les sujets sont
les lignes et les objets (ou les sujets) sont les colonnes de la matrice et chaque cellule
(se trouvant sur la ligne i et sur la colonne j) correspond à un ensemble de droits
d’accès qui constituent l’ensemble des opérations que le sujet (i) peut réaliser sur

chapitre 4 4.3. LES MODÈLES DE SÉCURITÉ INFORMATIQUE :
l’objet (j).
La construction d’une telle matrice nécessite l’identification et le contrôle des objets
à protéger, des sujets qui demandent accès aux objets, et des actions qui peuvent
être exécutées sur les objets. Elle est structurée sous forme d’une machine à états,
où le triplet (S, O, M) représente chaque état, avec :
S est un ensemble des sujets (dans notre cas S= s1,..,sM) O est un ensemble d’objets
(dans notre cas O= o1,..,oN) M une matrice de contrôle d’accès (dans notre cas M
(si, oj)=Lecture) Le modèle de Lampson associé aux DAC, ne permet pas d’exprimer
directement des interdictions ou des obligations, aussi s’ajoute-t-il la complexité de
la mise à jour de la matrice d’accès.
Figure 4.1: Matrice de contrôle d’accès :
Théoriquement, il y a autant de colonnes que de nombre d’objets (et de sujets) du

système et autant de lignes que de nombre de sujets du système, cela rend notre
matrice impraticable, car à chaque fois qu’un sujet est introduit (ou un objet est
créé) dans le système, tous les droits
d’accès accordés devront être enregistrés. Par conséquent, la mise à jour d’une poli-
tique de sécurité exprimée par ce modèle est fastidieuse, d’où l’utilisation de deux
vecteurs:
4.3 Les modèles de sécurité informatique :

4.3.1 Le contrôle d’accès discrétionnaire (DAC) :
Le contrôle d’accès discrétionnaire (Discretionary Access Control - DAC)[14] per-
met à un sujet d’attribuer des permissions à d’autres sujets. Ce contrôle d’accès est

flexible mais il peut générer des erreurs.

Les manipulations des droits d’accès à chaque objet restent à l’entière discrétion du
sujet qui en est le responsable. Dans un tel modèle tout sujet ayant créé un objet
en est le propriétaire.
Ce type de mécanisme est utilisé dans les systèmes d’exploitation traditionnels :
Unix, Linux, Windows et Macintosh, il est implémenté généralement avec des listes
de contrôle d’accès (Access Control Lists - ACL) Les modèles DAC que nous présen-
tons dans cette section sont ceux qui se basent sur la matrice de contrôle d’accès:
le modèle de Lampson et le modèle de Harrison Ruzzo Ullman.
A partir du début des années 70, plusieurs modèles de sécurité se sont succédés :
I-BAC, R-BAC, V-BAC, T-MAC et plus récemment Or-BAC. Nous allons évoquer
brièvement ces modèles de sécurité mais nous marquerons un temps d’arrêt sur le
modèle Or-BAC que nous utiliserons dans la suite.
4.3.2 Le modèle I-BAC (Identity Based Access Control )
I-BAC Premier modèle de contrôle d’accès proposé dans la littérature, ce modèle
introduit les concepts fondamentaux de sujet, d’action et d’objet :
• le sujet est l’entité active du SI (utilisateur, ordinateur, processus, programme,...)

;
• l’objet est l’entité passive du SI (fichier, base de donnée, ordinateur, pro-
gramme,...) ;
• l’action désigne l’effet recherché lorsqu’un sujet accède à un objet (lire, écrire,
modifier,...).
L’objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux ob-
jets via l’utilisation des actions. Ce contrôle est basé sur l’identité du sujet et
l’identificateur de l’objet, d’où le nom du modèle I-BAC.
Le modèle I-BAC présente cependant des limites. La politique d’autorisation de-
vient complexe à exprimer et administrer. Il est en effet nécessaire d’énumérer les
autorisations pour chaque sujet, action et objet. En particulier, lorsqu’un nouveau
sujet ou objet est créé, il est nécessaire de mettre à jour la politique d’autorisation
pour définir les nouvelles permissions associées à ce sujet ou objet.
4.3.3 Le modèle R-BAC (Role Based Access Control)

Le modèle RBAC (Role Based Access Control) propose de structurer l’expression
de la politique d’autorisation autour du concept de rôle. Un rôle est un concept
organisationnel : des rôles sont affectés aux utilisateurs conformément à la fonction
attribuée à ces utilisateurs dans l’organisation. Le principe de base du modèle R-
BAC est de considérer que les autorisations sont directement associées aux rôles.
Dans R-BAC, les rôles reçoivent donc des autorisations de réaliser des actions sur
des objets.
Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir

réaliser une action sur un objet, un utilisateur doit d’abord créer une session et,
dans cette session, activer un rôle qui a reçu l’autorisation de réaliser cette action
sur cet objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors
cet utilisateur aura la permission de réaliser cette action sur cet objet une fois ce
rôle activé. Lorsqu’un nouveau sujet est créé dans le SI, il suffit d’affecter des rôles
au sujet pour que ce sujet puisse accéder au SI conformément aux permissions ac-
cordées à cet ensemble de rôles.
Comparé au modèle I-BAC, la gestion de la politique d’autorisation s’en trouve
simplifiée puisqu’il n’est plus nécessaire de mettre à jour cette politique chaque fois
qu’un nouveau sujet est créé.
Mais comme I-BAC, le modèle R-BAC ne considère que des autorisations positives
(permissions) et fait donc l’hypothèse que la politique est fermée. Bien plus, dans les
modèles I-BAC et R-BAC, les actions correspondent généralement à des commandes
élémentaires, comme la lecture du contenu d’un objet ou l’écriture dans un objet.
Dans les applications récentes, le besoin apparaît de contrôler la réalisation d’actions
composites, appelées tâches ou activités. Par exemple, dans une agence de voyage, la
tâche d’achat d’un billet d’avion se décompose en plusieurs actions plus élémentaires
telles que la réservation du billet, le paiement du billet et l’édition d’une facture.
4.3.4 Le modèle T-BAC(Task Based Acces Control)
Le modèle T-BAC fut le premier modèle à introduire le concept de tâche. D’autres
modèles ont ensuite été développés pour contrôler l’exécution des activités dans un
workflow. En particulier, l’utilisateur ne doit obtenir une permission que lorsque
c’est nécessaire pour poursuivre l’exécution de l’activité considérée ("just in time"
permission). Ainsi, dans l’exemple d’achat d’un billet d’avion, la permission d’éditer
une facture ne doit être activée qu’après la réservation et l’achat du billet. Il est
parfaitement possible de combiner les concepts de rôle et de tâche pour spécifier une
politique d’autorisation et obtenir ainsi un modèle que l’on peut appeler TR-BAC
(Task and Role Based Access Control). Dans ce cas, les permissions affectées aux
rôles portent sur la réalisation des tâches. Diverses contraintes peuvent être spé-
cifiées pour par exemple spécifier qu’un même sujet doit intervenir dans certaines
actions nécessaires à la réalisation de la tâche (éventuellement avec des rôles dif-
férents).
Les modèles R-BAC et T-BAC ont respectivement introduit les concepts de rôle et
de tâche pour structurer les sujets et les actions. Pour faciliter l’expression et la
gestion d’une politique d’autorisation, nous avons également besoin d’un concept
pour structurer les objets. Parmi les modèles de contrôle d’accès proposant une
telle structuration des objets, on peut citer le modèle de sécurité proposé par SQL
pour les bases de données relationnelles.
L’expression d’une politique de sécurité en SQL repose sur le concept de vue. Ce
type de modèle de contrôle d’accès basé sur les vues est appelé V-BAC

4.3.5 Le modèle T-MAC(Team Based Acces Control)

Le modèle T-MAC introduit la notion d’équipe. Dans T-MAC, des autorisations
sont associées aux rôles ainsi qu’aux équipes. Les autorisations que possède un sujet
résultent de la combinaison des autorisations associées aux rôles exercés par le sujet
et des autorisations associées à l’équipe à laquelle est affecté le sujet. Plusieurs com-
binaisons (par exemple, l’union des autorisations) sont envisagées. En fait, le modèle
T-MAC est incorrect car il introduit deux relations binaires : rôle-autorisation et
équipe-autorisation. Si l’on introduit la notion d’équipe, il est en fait nécessaire
de considérer une relation ternaire équipe-rôle-autorisation pour spécifier que les
autorisations dépendent non seulement du rôle mais aussi de l’équipe dans laquelle
est exercé ce rôle. A l’aide d’une telle relation ternaire, on pourra ainsi facilement
spécifier que les autorisations du rôle médecin changent suivant qu’il s’agit d’un
médecin dans une équipe de garde ou d’un médecin dans une équipe d’urgence.
Cette imperfection du modèle T-MAC a été corrigée dans le modèle Or-BAC, que
nous allons présenter dans les sections suivantes.
4.3.6 Le modèle OR-BAC (Organization Based Access Con-

trol)
4.3.6.1 Les objectifs et avantages d’Or-BAC :
L’objectif d’Or-BAC est de permettre la modélisation d’une variété de politiques de
sécurité basées sur le contexte de l’organisation. Pour arriver à ce but, et afin de
réduire la complexité de gestion des droits d’accès, le modèle Or-BAC repose sur
quatre grands principes :
• L’organisation est l’entité centrale du modèle.

• Il y a deux niveaux d’abstraction :
– Un niveau concret : sujet, action, objet.
– Un niveau abstrait : rôle, activité, vue.
• La possibilité d’exprimer des permissions, des interdictions, et des obligations
• La possibilité d’exprimer les contextes.
Ainsi, en plus d’avoir une politique de sécurité indépendante de son implémentation,

Or-BAC a d’autres avantages. Il permet d’exprimer aussi bien des permissions, que
des interdictions et des obligations. Il prend en compte les contextes, les hiérar-
chies et la délégation.
L’introduction d’un niveau permet aussi la structuration des entités comme on le
voit sur le schéma suivant:

Figure 4.2: Schèma de ORBAC
Ainsi dans Or-BAC, un rôle est un ensemble de sujets sur lesquels sont appliquées
les mêmes règles de sécurité. Identiquement, une activité est un ensemble d’actions
sur lesquels sont appliquées les mêmes règles de sécurité et une vue est un ensemble
d’objets sur lesquels sont appliquées les mêmes règles de sécurité
4.3.6.2 Les interactions d’Or-BAC :
Sur le schéma suivant, on peut apercevoir les interactions existantes dans Or-BAC.
Afin de ne pas surcharger celui-ci l’interaction entre le contexte et les entités con-
crètes n’est pas représentée

Figure 4.3: Interaction d’ORBAC
4.3.6.3 La notion de contexte :

On voit apparaître sur ce schéma des interactions d’une entité qui n’apparait pas
dans les autres modèles de contrôle d’accès : le contexte. Celui-ci est défini pour
une organisation, un sujet, une action, des objets donnés. Les contextes permettent
d’exprimer des permissions ou des interdictions dans certaines circonstances (ur-
gence à l’hôpital, heures de travail dans une entreprise,...). Il est facile d’imaginer
que dans un contexte d’urgence, on désirera qu’un infirmier puisse accéder au dossier
d’un patient sans avoir besoin d’appeler l’administrateur afin que celui-ci lui donne
les droits (peut-être trop tard). Cette possibilité de nuancer les autorisations n’est
pas offerte par les autres modèles, alors que dans de nombreuses organisations (hôpi-
tal, entreprise,...) il existe un réel besoin de ne donner des droits que dans des
circonstances précises

Figure 4.4: Hiérarchique du modèle ORBAC
Pour le modèle Or-BAC, on a regroupés les différents contextes par type (comme
sur le schéma ci-dessus) :
contexte temporel : Ce sont des contextes régissant la durée de validité des priv-
ilèges .
contexte spatial : Il peut être lié à l’appartenance à un réseau, ou la position
géographique, ou à toute autre situation spatiale .
contexte déclaré par l’utilisateur : ce type de contexte est activé, par exemple,
par le médecin en cas d’urgence, ou pour signaler que l’on effectue un audit.
Dans ces cas exceptionnels, des permissions peuvent être données alors qu’elles
seraient interdites dans un cas normal. L’utilisateur qui déclare le contexte est
obligé en contrepartie de faire un compte-rendu des opérations effectuées et
peut être des raisons qui l’ont motivé à déclarer ce contexte .
contexte prérequis : Leur utilisation permet de contraindre les sujets concernés
par les permissions ou les interdictions dépendant de ces contextes et qui vient
réduire ou étendre les droits d’accès hérités du rôle associé ;
contexte provisionnel : Ce contexte permet de donner des privilèges en fonction
de l’historique. Par exemple, le contexte "accès limités à 2 fois" regarde si le
document, objet de l’action, a été accédé au moins 2 fois.

A noter que dans une modélisation Or-BAC, on définit toujours un contexte par
défaut.
4.3.6.4 La notion de hiérarchie :
Afin de gérer plus facilement des sous-organisations, en automatisant la dérivation
des permissions, Or-BAC permet de définir des hiérarchies sur les rôles, les activités,
les vues et les contextes. On a ainsi l’héritage des permissions et des interdictions en
descendant dans la hiérarchie des rôles, des activités, des vues et des contextes. Tout
comme dans R-BAC, l’héritage permet de simplifier la tâche de l’administrateur en
automatisant partiellement l’attribution des privilèges. Comme dans R-BAC, il ex-
iste deux façons de définir la hiérarchie de l’héritage :
• La première vision pour définir la hiérarchie est la hiérarchie organisationnelle.

Le directeur est hiérarchiquement supérieur à un ingénieur. Dans certains cas,
il peut donc hériter de toutes les permissions de ce rôle (pour vérifier le travail
de celui-ci). On dit alors que R1 est senior de R2 et R2 est junior rôle de R1,
si un utilisateur jouant le rôle R1 est supérieur hiérarchique de R2 ;
• La deuxième vision est la hiérarchie obtenue par la relation de spécification/général-
isation est définie telle que R1 est un senior rôle de R2 si chaque fois qu’un
utilisateur joue le rôle de R1, elle joue le rôle de R2. Par exemple un ingénieur
est un technicien . Donc à chaque fois qu’un utilisateur est associé au rôle
ingénieur il joue aussi le rôle d’un technicien . Le rôle ingénieur est un senior
rôle du rôle technicien . Un rôle R1 senior de R2 hérite donc les permissions
affectées à R2 .
Dans Or-BAC, ces deux hiérarchies réapparaissent mais les droits qui leur sont as-
sociés sont quelque peut modifiés. En effet, avec le modèle Or-BAC, on peut définir
des permissions mais aussi des interdictions. Dans Or-BAC, on peut aussi spécialiser
un rôle. On voit donc apparaître une hiérarchie liée à cette spécification. Dans cette
hiérarchie si on veut qu’un rôle senior puisse avoir plus de pouvoir que son rôle ju-
nior, alors il faut que le rôle senior hérite des permissions de son rôle junior et que
les interdictions liées au rôle senior soient héritées par son rôle junior. De plus, par
rapport à R-BAC, Or-BAC introduit le concept d’organisation, ce qui donne une
nouvelle dimension à l’héritage. En effet, il est possible qu’un rôle puisse toujours
englober un certain sous-rôle quelle que soit l’organisation dans laquelle on se place.
Par exemple, dans tout département informatique , le rôle d’ingénieur est une spé-
cialisation du sous-rôle technicien. Or-BAC permet donc à l’ingénieur d’hériter de
tous les droits du technicien en ne définissant qu’une seule fois les droits. Le reste se
fait grâce à la relation de spécialisation/généralisation. Identiquement, les vues et
les activités possèdent des sous-vues et des sous-activités. On les hiérarchise donc
afin de créer pour elles aussi cette relation de spécialisation/généralisation.

4.3.6.5 La notion de délégation:

La délégation permet de donner à un utilisateur particulier un privilège, sans donner
ce privilège à toutes les personnes ayant le même rôle que lui. La délégation, bien
que très utilisée, est très peu modélisée dans les politiques de sécurité car ce concept
est très complexe.
En effet, grâce à une délégation, une permission peut être donnée par le détenteur
d’un droit à un tiers pour agir à sa place ou à la place d’un autre. On voit déjà ici
apparaître qu’une délégation peut faire intervenir plusieurs parties :
• Le sujet qui possède le privilège,

• Le sujet a qui on délègue le privilège,
• Le sujet qui délègue le privilège (pour agir à sa place ou à la place d’un autre).
Il existe trois types de situation dans lesquelles la notion de délégation apparaît
:
• La maintenance d’un rôle,
• La décentralisation de l’autorité,
• Le travail de collaboration.
4.3.6.6 La gestion de conflit :

Or-BAC permet d’exprimer des permissions et des interdictions. Or-BAC offre donc
la possibilité de spécifier une politique mixte. Il existe dans Or-BAC une troisième
catégorie de privilège : l’obligation. La notion d’obligation décrit les actions qu’un
utilisateur doit faire sur un ensemble d’objets. Par exemple, dans un contexte
d’urgence, un technicien aura le droit d’accéder aux dossiers d’administration mais
uniquement s’il fait ensuite un rapport, c’est une obligation La politique mixte pose
de nombreux problèmes liés à la gestion des conflits potentiels et des règles redon-
dantes. Afin d’éluder le problème des règles redondantes, on ajoute des prédicats.
Ceux-ci, pour deux règles données R1 et R2, interdisent d’avoir la priorité de R1
moindre que celle de R2, lorsque toutes les conditions suivantes sont vérifiées :
• R1 et R2 sont définies pour une même organisation .

• R1 est définie pour un rôle r1 et R2 est définie pour un rôle r2, avec r1 sous-rôle
de r2 .
• R1 est définie pour une activité a1 et R2 est définie pour une activité a2, avec
a1 sous-activité de a2 .
• R1 est définie pour une vue v1 et R2 est définie pour une vue v2, avec v1
sous-vue de v2 .
• R1 est définie pour un contexte c1 et R2 est définie pour un contexte c2, avec
c1 sous-contexte de c2 .

chapitre 4 4.4. APPLICATION DU MODÈLE OR-BAC :
Il peut apparaître un conflit, par exemple si un même utilisateur possède deux rôles
et que l’un de ces rôles lui permet de faire une activité et l’autre lui interdit. On
est sûr que s’il n’y a aucun conflit au niveau abstrait, il n’y en aura pas au niveau
concret. Ceci est dû au fait que les permissions concrètes sont déduites des permis-
sions organisationnelles, de même pour les interdictions. Donc on résout les conflits
potentiels au niveau abstrait On décide pour cela de donner des priorités aux in-
terdictions et permissions du niveau abstrait. Cependant, si le conflit subsiste (par
exemple: l’interdiction et la permission ont même priorité) alors Or-BAC prévient
le concepteur de la politique. Celui-ci choisit alors de modifier les règles liées aux
privilèges, ou le niveau des priorités des privilèges.
Figure 4.5: Conflit de permission :
Donc, Or-BAC simplifie la conception de la politique de contrôle d’accès en automa-

tisant la dérivation des permissions, il a l’avantage d’offrir une politique mixte qui
gère les problèmes conflictuels.
4.4 Application du modèle OR-BAC :

Dans le cas d’une grande entreprise comme AL BARID BANK les données sont
très critiques et le volume des données est trop grand . Autre chose , Barid Banque
travaille sur l’élaboration d’un profiling pour ses fonctionnaires , pour le moment ce
projet est en phase d’implémentation ,donc on n’a pas eu l’occasion pour appliquer

chapitre 4 4.4. APPLICATION DU MODÈLE OR-BAC :
cette politique d’accès , on a fait juste une simulation pour ce modèle .

les sujets et les objets sont virtuels , on a utilisé l’outil motorbac pour faire la
simulation du politique d’accés ORBAC
Figure 4.6: Simulation du modèle ORBAC

chapitre 4 4.5. CONCLUSION:
Figure 4.7: Simulation sur les roles ORBAC :
4.5 Conclusion:
Pour résumer ce chapitre, on peut dire que la politique d’Accès est d’une importance
remarquable dans la mise en place d’une politique de sécurité et que le choix du
meilleur modèle de sécurité dépend du contexte de l’entreprise et de la confidentialité
des données ainsi que la vision de l’administrateur qui implémente la politique dans
un contexte. Le modèle de sécurité OR-BAC comme tous les autres a des avantages
et des inconvénients mais jusqu’à présent il reste le premier choix dans les grandes
entreprises et les banques. Dans le chapitre suivant on va traiter le troisième point
du modèle AAA qui est (Accounting) traçabilité

Chapter 5
Centralisation / Corrélation des

logs et Traçabilité
5.1 Corrélation des logs

Dans ce chapitre nous vous donnons une vision gobale sur la notion SIEM et les
diffirents outils open source et payantes qui existent , les avantages , les inconvinients
de chacun parmi eux ,puis les critères du choix d’un meilleur outil SIEM .
5.1.1 Définition de l’outil SIEM :
5.1.1.0.1
Le terme SIEM (Security Information and Event Management) est une combinai-
son de la carte SIM (Security Information Management) et SEM (Security Event
Management), qui sont des catégories d’outils disparates. Alors que la carte SIM
est destinée à fournir un stockage à long terme, l’analyse et la présentation des
données des journaux, SEM traite la surveillance en temps réel, la corrélation des
événements, notifications et vues de la console. Maintenant, un SIEM combine ces
deux fonctionnalités dans un seul outil.
Le terme SIEM ( sécurité de l’information et la gestion des événements ) décrit la

capacité de collecte, d’analyse et de présentation de l’information à partir de sources
très différentes que des dispositifs de réseau et de sécurité, l’identité et les applica-
tions de gestion des accès, système d’exploitation, les journaux de base de données
et d’applications et les données des menaces même externes. Habituellement, ils
sont renvoyés de leur source respective de la SIEM que les messages (messages de
log, les déclencheurs, les pièges, les fichiers soumis, présentations de table de base
de données, etc.) Alors que les sources sont au moins en partie très différents de
ceux de la criminalistique informatique, les capacités sont presque les mêmes.
Typiquement, les outils SIEM modernes peuvent également intégrer une fonction-
nalité externe, comme flux de travail et de billetterie par exemple, pour l’ensemble
46
chapitre 5 5.1. CORRÉLATION DES LOGS
du processus de l’incident pour être appliqués dans une seule interface utilisateur.
Étant donné que chaque environnement est différent, les meilleurs outils SIEM of-
frent un ensemble souple des capacités d’intégration. Intégrer un logiciel spécialisé
pour la criminalistique informatique dans un SIEM est donc, par définition, pas un
défi insoluble.
5.1.2 Les fonctionnalités d’un SIEM :
5.1.2.1 Collecte :
Les logiciels de SIEM prennent en entrée les événements collectés du système d’information
d’un environnement spécifique : les journaux système des équipements (pare feux,
routeurs, switch, serveurs, bases de données. . . ), les évènements survenus dans des
machines supervisées, des fichiers retournés par des applications. Ils permettent de
prendre en compte différents formats (syslog, Traps SNMP, fichiers plats, OPSEC,
formats propriétaires, etc.) ou nativement le format IDMEF (Intrusion Detection
Message Exchange Format), spécialement conçu et validé par l’IETF sous forme de
RFC pour partager l’information qui intéresse un système de détection et protection
aux intrusions.
La collecte peut être de façon passive en mode écoute ou active en mettant en place
des agents directement sur les équipements ou à distance. Les solutions permet-
tent également de développer des collecteurs pour prendre en compte des nouveaux
formats de journaux systèmes (API, expression régulière. . . ).
5.1.2.2 Normalisation :
Les traces brutes des évènements survenus sont stockées sans modification pour
garder leur valeur juridique. On parle de valeur probante. Ces traces sont générale-
ment copiées puis normalisées sous un format plus lisible pour une exploitation
normalisée. En effet, la normalisation permet de faire des recherches multi critères,
sur un champ ou sur une date. Ce sont ces évènements qui seront enrichis avec
d’autres données puis envoyés vers le moteur de corrélation.
5.1.2.3 Agrégation :
L’agrégation d’évènements consiste à définir un certain nombre de types d’évènements
produits, de tester la similitude entre eux. De ce constat, plusieurs règles de filtrage
peuvent être appliquées. Ils sont ensuite agrégés selon les solutions, puis envoyés
vers le moteur de corrélation.
Néanmoins, il est communément admis dans les applications de veille en sources
ouvertes que l’information manipulée par les analystes est incertaine à plusieurs
niveaux : l’information en elle-même, la source, les traitements opérés, etc. Pour-
tant de ce constat, nous voulons laisser à l’administrateur le choix final de fusionner
(ou non) deux évènements jugés similaires, et cela dans le but d’éviter toute perte
d’information pouvant survenir avec une fusion totalement automatisée.

chapitre 5 5.1. CORRÉLATION DES LOGS
5.1.2.4 Corrélation :
Les règles de corrélation permettent d’identifier un évènement qui a causé la généra-
tion de plusieurs autres (un hacker qui s’est introduit sur le réseau, puis a manipulé
tel équipement. . . ).Ces règles sont mises en place afin de chercher des séquences et
des motifs dans les évènements du journal qui ne sont pas visibles par une analyse
individuelle. Elles permettent aussi de remonter une alerte via un trap, un mail,
sms ou ouvrir un ticket si la solution SIEM est interfacée avec un outil de gestion de
tickets. Ces alertes représentent les évènements importants produits dans le réseau,
qui sont corrélés, afin d’en tirer profit pour reconnaitre les risques de sécurité.
Les règles de gestion se mettent à jour par l’administrateur, lorsque l’analyse et la
corrélation d’évènements deviennent répétitives.
5.1.2.5 Reporting :
Les SIEM permettent également de créer et générer des tableaux de bord et des
rapports. Ainsi, les différents acteurs du système d’information, responsable de
la sécurité des systèmes d’informations, administrateurs, utilisateurs peuvent avoir
une visibilité sur le système d’information (nombre d’attaques, nombre d’alertes par
jour. . . ).
5.1.2.6 Archivage :
Les solutions SIEM sont utilisées également pour des raisons juridiques et régle-
mentaires. Un archivage à valeur probante permet de garantir l’intégrité des traces.
Néanmoins, l’archivage des logs est effectué pour une certaine durée qui serait pré-
cisée par l’administrateur du système d’information. En cas de défaillance du disque
dur ou pour une raison quelconque, il est nécessaire d’avoir une copie, stockée
quelque part, des données concernant les logs et leurs traitements d’analyse et
pouvoir y accéder en cas de perte de celles-ci. De surcroit, il existe deux types
d’archivages des données présentés comme suit :
.Archivage local : La sauvegarde des données est effectuée sur un dispositif de
stockage alternatif, contenant une copie des informations personnelles, que ça
soit une sauvegarde sur un disque dur externe, sur un disque dur d’une autre
machine.
•Archivage sur internet : La sauvegarde est effectuée sur un site internet qui
offre la possibilité de sauvegarde, tel que la sauvegarde en Cloud. En cas d’un
crash du disque dur, on pourrait éventuellement récupérer nos données en
se connectant sur Les solutions pouvant utiliser des disques en RAID, calculer
l’empreinte, utiliser du chiffrement ou autre pour garantir l’intégrité des traces.
5.1.3 Rejeu des évènements :

La majorité des solutions permettent également de rejouer les anciens évènements
pour mener des investigations post incident. Il est également possible de modifier
une règle et de rejouer les évènements pour voir son comportement

chapitre 5 5.2. COMPARAISON DES OUTILS OPEN SOURCE SIEM :
5.2 Comparaison des outils open source SIEM :

Afin de procéder au choix de l’outil que nous allons utiliser pour collecter, corréler
et finalement de mettre en place un outil de détection d’intrusion, un benchmark-
ing des outils SIEM s’impose en vue de choisir l’outil le plus performant et le plus
adapté aux besoins de la société. Nous allons dans cette partie introduire les deux
concurrents élus d’être l’outil open source capables de répondre aux fonctionnalités
cités précédemment ainsi que de répondre aux besoins et aux contraintes de cen-
tralisation et de corrélation de logs.
ent
l tage
s véni
outi ava n n
i c o n
Logalyse -Exportation des rapports -Documentation assez maigre et
ou des listes aux formats dispersée. -Difficile de bien ex-
CVS,XLS,PDF,HTML. ,Of- ploiter ses fonctionalitées -il n’est
fre deux types de corrélation pas developpé par rapport aux
(corrélation manualle ,corrélation autres projets open source
en temps réel) ,Collecte les
logs a partir de n’importe quel
équipement ,Compatible avec
syslog , rsyslog ,windows et linux
splunk -Moteur de recherche intelligent Surveillence et alert des événe-
pour les logs . -Combine trois ments limités n’est pas open
projet open source Elasticsearch source
, Kibana, Fluentd
Apache ALOIS -Collectant les informations de se- -N’est pas assez amelioré . -N’est
curité , il est destine à la sécurite plus developpé, -N’est compatible
du contenu qu’avec windows -Documentation
dipersée -Il ne support pas des
quantites massives des données
Cyberoam -Compatible avec windows et les équipements cisco supportés:
linux . -Possible de modifier le uniquement cisco asa on ne pour-
code source -Possibilté de person- rait ajouter que 5 serveurs syslog
nalisation en fonction du besoin -
le controle et l’analyse tres rapide
prelude oss -Offre une corrélation en temps -N’offre pas la possibilite de
réel -Corrélation et aggrégation générer des rapports -Pas de per-
avancés -Transmission des don- formance de base de données -
nées sécurisée -Authentifications Le nombre des équipements sup-
https portés ne dépasse pas 50 -N’est
pas compatible avec windows

OSSIM -Unifie plusieurs outils de gestion -Architecture monolithique (illis-

reseau, de securite ,de corrélation ible pour un simple utilsateur
, qualification des données - com- ). -Systeme d’exploitation im-
patible avec tous les agents possi- pose debian version gratuite n’est
ble pas complet. -Moins de fonction-
nalites pour version gratuit.
ELK -Offre une corrélation en temps necessite un administrateur bien
réel. -Corrélation et aggrégation familialisé avec les open sources
avancés. -Transmission des don-
nées sécurisée. -Gratuit et open
source . -Compatible avec win-
dows linux mac ,.. -Moteur de
recherche intelligent pour les logs
. -Pleine de fonctionnalités .
Table 5.1: Etude comparative des outils SIEM
5.2.1 Les besoins et les contraintes de choix

Les besoins fonctionnels qu’il faudrait prendre en considération afin de procéder au
choix de l’outil pour qu’il soit le plus adapté à la solution qu’on voudrait mettre en
place, sont cités ci-dessous :
• Pouvoir centraliser tous les logs générés par les hôtes (machine, serveur), par les
équipements réseaux (swtich, routeur) ainsi que par les logs des fichiers plats
générés par les applications. Ces logs collectés doivent être mis sous un format
défini et adapté pour être exploité de manière facile et visible.
• Avoir la possibilité de corréler les événements collectés à partir des différentes
sources qui interagissent avec la solution, en vue de générer de nouveaux événe-
ments appelés alarmes.
• Permettre d’intégrer un détecteur d’intrusion pour éviter toute tentative d’écouter
le trafic circulant dans le système d’information.
• La solution doit avoir un module de reporting en vue de générer des rapports
personnalisés pour garder la traçe des logs survenus dans le système afin d’être
exploitable par l’auditeur interne à l’organisme ou l’auditeur externe.
Les contraintes à respecter afin de procéder au choix adapté avec l’environnement

de travail sont citées ci-dessous :

• Avoir une solution qui peut être installée sur un serveur Windows, car Barid
Bank dès son départ jusqu’à aujourd’hui a adopté un environnement basé sur
le système d’exploitation Windows.
• La solution permet de collecter les logs à partir des hôtes (machine, serveur)
doté d’un système d’exploitation Windows, ainsi que des équipements réseaux
(switch, serveur) Cisco.
5.2.2 Les critères du Choix de l’outil SIEM

D’après cette étude préliminaire des outils open source existants dans le marché des
solutions SIEM. Nous avons fait le choix de deux outils OSSIM et ELK susceptibles
d’être utils pour répondre à nos besoins ainsi qu’à nos contraintes. Pour ce faire,
nous allons étudier de plus prêt nos deux solutions afin de pouvoir choisir la solution
la plus adéquate à notre situation.
5.2.3 ELK :
E lk Est un projet combiné des outils open source permettant à la fois d’identifier,
analyser, normaliser et indexer les messages entrants afin de pouvoir les stocker.
Il permet également de générer des rapports et des alertes.
5.2.3.1 Avantages :
Les principales fonctionnalités de l’outil ELK sont les suivantes :
• - ELK Collecte les logs à partir de n’importe quel équipements réseaux ou

logiciels ( pare-feu, proxy, Windows, Linux. . . )
• - Il est compatible avec la collecte des logs de plusieurs formats rsyslog, syslog-
ng, snare ,...
• - Convertit les champs analysés dans un format normalisé aux fins d’analyse
et reporting et synchronise l’heure en GMT
• - Le module de corrélation recueille les messages de différents systèmes et de
trouver tous les messages appartenant à un seul évènement
• - Il offre la possibilté de corrélation grace à des règles de filtrage .
• - Il peut détecter les anomalies dans un système de travail (nouveaux messages
non apparus auparavant) La solution permet d’offrir des rapports ou des listes
aux formats CSV, XLS, PDF ou HTML
• - Il offre un dashboard pour l’administration
• - Il utilise un moteur de recherche intilligent pour l’indexation des logs
• - Il utilise multiple techniques pour le stockage des données
• - Une communaué très active et large
• - Il supporte multiple input/out put formats des logs

5.2.3.2 Inconvénients :
Cependant, chaque outil open source aussi puissant soit-il a toujours ses incon-
vénients , ces derniers seront listés ci-dessous :
• ELK nécessite un administrateur expert systéme pour bien organiser , admin-
istrer , collecter et corréler les logs .
• difficile à mettre en oeuvre .
5.2.4 OSSIM :
OSSIM fournit toutes les fonctionnalités qu’une garantie des besoins professionnels
d’une offre SIEM : collecte d’événements, de normalisation, et de corrélation.
Créé et lancé par les ingénieurs de sécurité par nécessité, OSSIM a été créé avec une
compréhension de la réalité, de nombreux professionnels de la sécurité font face: un
SIEM est inutile sans les contrôles de sécurité de base nécessaires à la visibilité de la
sécurité. OSSIM aborde cette réalité en fournissant les fonctions de sécurité essen-
tielles intégrées dans une plate-forme unifiée. Debout sur les épaules des nombreux
contrôles de sécurité open source éprouvées intégrées dans la plate-forme, OSSIM
continue d’être le moyen le plus rapide de faire les premiers pas vers la visibilité de
sécurité unifiée.
5.2.4.1 Avantages :
Les principales fonctionnalités de l’outil open source puissant OSSIM ainsi que ses
avantages par rapport aux autres solutions existantes dans le marché, sont citées
ci-dessous :
• Pouvoir centraliser les logs de tous les équipements systèmes, réseaux et logi-
ciels de nombreuses façons possibles grâce à ses plugins
• La définition des règles de corrélation via des fichiers xml facilement exploita-
bles
• Peut être installé sur tous les types d’agents possibles (Linux,Windows)
• Il offre la possibilité de reporting audit grâce à un plugin puissant iReport
5.2.4.2 Inconvénients :
• Le système d’exploitation est imposé (Debian)
• Architecture monolithique (illisible par un utilisateur non professionnel)
• L’architecture de clusturing est offerte par la solution payante d’Alienvault
(USM)
5.2.5 Synthèse de choix de la solution

Nous remarquons d’après l’étude approfondie des deux solutions susceptibles d’être
choisies,l’outil open source qui répond aux besoins de notre projet ainsi que les
contraintes de notre architecture de Al Barid Bank Group, est ELK .

5.2.6 Quelques capture d’écran de notre solution ELK :
Figure 5.1: Statistiques des évènement des logs :
Cette figure nous donne les statistiques des évènements envoyés au serveur et
l’usage des indices utilisés .
Figure 5.2: Statistiques des transmissions des données
la figure ci-dessus montre les statistiques des transmissions des données et les
Requêtes envoyées au serveur

Figure 5.3: Tableau de bord
La figure ci-dessus nous donne un dashboard en fonction du temps sur les fichiers
journaux stockés dans Elasticsearch et affiché dans kibana
Figure 5.4: Top 10 IP adresses
Cette figure montre les dix premières adresses ip visités par les clients

chapitre 5 5.3. SOLUTION ELK :
Figure 5.5: Les champs de l’indice PacketBeat
Cette figure montre la maniére avec laquelle l’information est organisée dans un
indice du cluster.
5.3 Solution ELK :

5.3.1 Les Composantes d’ELK :
ELK est un outil open source basé principalement sur trois outils open source et
libre .
• Elasticsearch
• Logstash
• Kibana
dans le contexte de notre stage on a ajouté l’outil suivante :
• packetbeat
pour analyser le trafic réseau et perfectionner notre solution.

5.3.2 Elasticsearch :
C’est un moteur de recherche libre open source utilisant Lucene (un des projets de
l’Apache Software Foundation).
• Il est distribué (architecture de type cloud computing).

• Il utilise Lucene pour le stockage de ses données dans un format NoSQL.

• Il utilise la méthode REST. L’indexation des données s’effectue à partir d’une

requête HTTP PUT. La recherche des données s’effectue avec la requête HTTP
GET. Le flux d’information est codé selon le format JSON.
• Il est associé à deux autres produits open source : Kibana et Logstash qui sont
respectivement un visualiseur de données et un ETL (initialement destiné aux
logs).
5.3.2.1 Stockage dans elasticsearch

L’indice peut être soit stocké en mémoire (pas persistance) ou sur disque (par
défaut). En mémoire les indices fournissent une meilleure performance au prix
d’une limitation de la taille de l’index à la quantité de mémoire physique disponible.
Lorsque vous utilisez une passerelle locale (par défaut), le stockage des fichiers
en mémoire est nécessaire pour maintenir la cohérence de l’indice. Ceci est
nécessaire, car la passerelle locale construit l’état de l’indice local de chaque nœud.
Un autre aspect important de stockage à base de mémoire est le fait que Elastic-
Search permet de stocker l’index en mémoire, en dehors de l’espace du pile JVM
.Ce stockage se traduit par le fait qu’il n’y a pas besoin de très grands pile JVM
(avec leurs conséquences) pour stocker l’index dans la mémoire.
Stockage :
5.3.2.1.1 Types de stockage :

Il existe différentes implémentations ou des types de stockage, le meilleur pour
l’environnement d’exploitation sera sélectionné automatiquement :
• File system : est un stockage basé sur le système de fichier c’est le stockage utilisé
par défaut.
• simplefs : Ce type est une mise en œuvre simple de stockage de système de fichiers
en utilisant un fichier d’accès aléatoire.
• niofs : Il permet à plusieurs threads (fils) de lire à partir du même fichier en même
temps. Il est déconseillé sur Windows en raison d’un bug dans l’implémentation
de Sun Java.
5.3.3 Logstash :
Fluentd est un outil concurrent de Logstash , pour choisir la technologie qui
répond le plus à nos besoins et qui respecte les critères imposés par le cahier
de charge on a fait une étude comparative entre ces deux outils afin d’identifier
l’outil compatible avec l’environnement AL BARID BANK .
Logstash et Fluentd sont deux projets open-source qui mettent l’accent sur
le problème de l’exploitation centralisée . Les deux projets portent sur l’aspect

de la collecte et le transport des fichiers journaux utilisant des approches dif-

férentes .
Le problème est de ne pas comprendre ce qui est le meilleur , mais plutôt de

voir quel serait un meilleur ajustement pour notre environnement.
Figure 5.6: L’archivage ou le traitement avec un serveur de cloud d’amazon S3.
l ash td
outi logst fluen
Exigences -Il fonctionne sur la JVM .La -Il fonctionne sur Linux et Mac
d’installation JVM utilise plus de mémoire OSX, mais ne fonctionne pas sur
qu’on veux utiliser pour le trans- Windows pour le moment -Il est
port des journaux -Il peut fonc- principalement développé par une
tionner sur n’importe quel sys- société commerciale
teme d’exploitation :Linux, Mac
OSX et Windows.
Fonctionnalités -Logstash prend en charge un les messages de journal sont con-
nombre d’entrées, des codecs, des vertis en JSON qui fournit la
filtres et des sorties . -Les filtres structure à un message de journal
traitent les actions sur les événe- non structuré .
ments et nous permet de modifier
ou de supprimer des événements
comme s’ils sont traités.
securité les transferts de journaux sont les transferts de journaux sont

chiffrées transférés en claire
Table 5.2: Etude comparative entre Logstash et Fluentd

Probablement la différence la plus significative entre Fluentd et Logstash est

leur foyer de conception. Logstash souligne la flexibilité et l’interopérabilité
alors Fluentd privilégie la simplicité et la robustesse. Cela ne signifie pas
que Logstash n’est pas robuste ou Fluentd n’est pas flexible, mais chacun d’eux
a des priorités caractéristiques différentes .
Fluentd a moins d’entrées que Logstash , mais il gère tres bien l’équilibrage de
charge, les délais d’attente et les tentatives. Ces types de caractéristiques sont
nécessaires pour assurer de manière fiable la livraison des données.
Logstash et Fluentd sont des outils d’exploitation centralisés viables qui peu-
vent transférer des journaux à partir de plusieurs hôtes à un emplacement cen-
tral. Logstash est incroyablement flexible avec de nombreux plugins d’entrée
et de sortie alors Fluentd fournit moins de sources d’entrée et de sortie.
Après cette étude comparative on a choisi Logstash pour l’utliser dans notre
environement AL Brid BANK .
5.3.4 Packbeat :
Packetbeat est un analyseur de réseau en temps réel qui peut être utilisé
avec ElasticSearch afin de fournir un système de surveillance d’application et
d’analyse de performance.
Il fonctionne en capturant le trafic réseau entre les serveurs d’applications, le
décodage des protocoles de couche d’application (HTTP, HTTPS, SSH, etc.),
la corrélation des demandes avec les réponses des opérations et l’enregistrement
des domaines intéressants pour chaque transaction.
Le système se compose des éléments suivants:

• Packetbeat
• ElasticSearch
• Kibana
L’analyseur Packetbeat permet de analyser le trafic qui passe entre les serveurs,
corréler les messages dans les transactions. Actuellement, l’analyseur Packet-
beat supporte les protocoles suivants:
• HTTP
• HTTPS
• SSH
• FTP
• ...
L’analyseur peut insérer les opérations corrélés directement dans ElasticSearch
ou via une file d’attente centrale créée avec Redis et Logstash.
Packetbeat peut fonctionner sur les mêmes serveurs que vos processus d’application

ou sur leurs propres serveurs. Lors de l’exécution sur des serveurs dédiés, il
peut obtenir le trafic en provenance des ports des commutateurs , ou bien
d’autres dispositifs .
Après le décodage des messages de la couche 7 du modèle OSI , Packetbeat
corrèle les demandes avec leurs réponses dans ce que nous appelons les «trans-
actions» et, pour chaque transaction, il insère un document JSON dans Elas-
ticSearch .
Figure 5.7: Fonctionnement du packetbeat
ElasticSearch et l’instance Kibana qui sont utilisés pour analyser le trafic réseau
recueillies par Packetbeat peuvent être utilisés pour analyser les fichiers jour-
naux recueillies par Logstash. De cette façon, vous pouvez avoir le trafic réseau
et l’analyse des journaux dans le même système.
Packetbeat peut également insérer les opérations dans une liste Redis. Cela
permet d’utiliser Redis + Logstash comme un collecteur central et file d’attente
pour les données sur les transactions. Voir l’architecture de Packetbeat avec
Logstash pour plus de détails.

chapitre 5 5.4. TRAÇABILITÉ
Figure 5.8: Fonctionnement du Packetbeat avec Logstash
Redis est un système de gestion de base de données clef-valeur scalable,

très hautes performances, écrit avec le langage de programmation C ANSI et
distribué sous licence BSD. Il fait partie de la mouvance NoSQL et vise à
fournir les performances les plus élevées possibles.
5.3.5 Kibana :
5.3.5.0.2 Kibana
est une interface web permettant de rechercher des infos stockées par Logstash
dans ElasticSearch.
Figure 5.9: Architecture générale d’ELK
5.4 Traçabilité
Dans cette partie nous détaillerons comment faire la traçabilte dans une grande
entreprise comme Al Barid Bank par l’exploitation des logs et des outils cités
ci-dessus ,et à la fin de ce chapitre vous découvrez comment tracer le trafic

entrant et sortant avec l’analyse de ce derniere via un dashboard graphique

et une map de traffic . En exploitant la notion de map pour bien analyser le
trafic dans un réseau et avec l’utilisation de la GEOIP pour bien déterminer
la provenance et la destination de trafic .
5.4.1 Les contraintes techniques de la traçabilité
• Jusqu’où la traçabilité doit-elle aller ?
• Faut-il identifier les événement un par un, ou par groupe ?
• La source et le trajet d’un événement doivent-ils être accessibles au public
?
• Combien de temps conserver les archives, etc.
5.4.2 traçabilité sur ABB
Nous avons utilisé ELK comme solution pour la traçabilité malgré ses lim-
ites , on a amélioré les règles de filtrages par la focalisation sur le champs
Geoip , et d’autres champs pour savoir les sources et les destinataires en
fonctionnement de leurs adresses ip
Figure 5.10: Les sources des differentes addresses ip
Apres l’activation de la régle de filtrage Geoip , on peut determiner toutes

les connexions établies et connaitre la localisation des differents adresses
IP visités comme le montre la figure ci-dessus

Figure 5.11: Règles de filtrage
L’utilisateur peut selectionner la règle de filtrage selon ses besoins par ex-
emple pour déterminer l’emplacement géo-graphique des adresses IP vis-
itées , il doit cocher les champs longitude ,latitude et coordonnées comme
le montre la figure 5.13.
Figure 5.12: Pays visités
on peut savoir les pays visites par les utilsateurs

chapitre 5 5.5. PERSPECTIVE :
5.5 Perspective :
L e but principal de notre projet se manifeste dans la combinaison
de plusieurs solutions open source afin d’obtenir une seule plateforme
simple et facile à gérer par un administrateur Datacenter. Il faut
également noter que nous avons essayé d’homogénéiser le lien entre ces
solutions, cela va nous permettre de faciliter leur gestion.

Annexe
Dans ce chapitre nous présenterons les étapes de déploiement de la solution

choisie (ELK) au sein du système d’information de Al Barid Bank. Nous
allons détailler la configuration de notre plateforme ELK .
5.6 Installation d’Elasticsearch et ses plug-
ins
Pour la mise en oeuvre du plateforme de centralisation/corrélation des logs
On commence par l’installation d’Elasticsearch
1 mkdir −pv p r o j e t
2 cd p r o j e t
3 wget h t t p s : / / download . e l a s t i c . co / e l a s t i c s e a r c h / e l a s t i c s e a r c h /
e l a s t i c s e a r c h − 1 . 6 . 0 . t a r . gz
4 t a r x f e l a s t i c s e a r c h − 1 . 6 . 0 . t a r . gz
5 cd e l a s t i c s e a r c h − 1 . 6 . 0
Pour les familles Ubuntu/debian

1 h t t p s : / / download . e l a s t i c . co / e l a s t i c s e a r c h / e l a s t i c s e a r c h /
e l a s t i c s e a r c h − 1 . 6 . 0 . deb
2 #dpkg − i e l a s t i c s e a r c h − 1 . 6 . 0 . deb
Pour les familles redhat/centos

1 h t t p s : / / download . e l a s t i c . co / e l a s t i c s e a r c h / e l a s t i c s e a r c h /
e l a s t i c s e a r c h − 1 . 6 . 0 . noarch . rpm
2 #rmp −i v h e l a s t i c s e a r c h − 1 . 6 . 0 . noarch . rpm
Dans les deux cas précédent ubuntu/debian et redhat/centos les fichiers

de configurations se trouvent dans le répertoire
1 / etc / elasticsearch /
et les repertoires principales de configuration se trouvent dans le chemin

suivant
1 / usr / share / e l a s t i c s e a r c h /
Puis on va éditer le fichier elasticsearch.yml et on ajoute les lignes suivants

1 http . jsonp . enable : true
2 http . http . enable : true
puis on décommente les lignes suivants et on les modifie
64
chapitre 5 5.6. INSTALLATION D’ELASTICSEARCH ET SES PLUGINS
1 #c l u s t e r . name : e l a s t i c s e a r c h
2 #node . name : " s t a g e p f e "
3 #h t t p . p o r t : 9200
4 #t r a n s p o r t . t c p . p o r t : 9300
5 #i n d e x . number_of_shards : 5
Après l’installation d’Elasticsearch on va ajouter les plugins nécéssaires qui
répondent à nos besoins .
5.6.1 Plugin Marvel
Marvel est un plugin d’Elasticsearch pour simplifier la supervision et la
gestion des logs .
Pour ajouter ce plugin de supervision Marvel il suffit de télécharger la
version d’essaie
1 b i n / p l u g i n − i e l a s t i c s e a r c h / marvel / l a t e s t
5.6.2 Plugin BigDesk

Installer des plugin pour simplifier la gestion du cluster et des noeuds
http://bigdesk.org/
1 . / b i n / p l u g i n − i n s t a l l l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0
BigDesk est un gestionnaire de plugins d’ElasticSearch .
On va télécharger et installer ce plugin via les sources de Bigdesk:
1 −> I n s t a l l i n g l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0 . . .
2 Trying h t t p : / / download . e l a s t i c s e a r c h . o r g / l u k a s −v l c e k / b i g d e s k /
bigdesk − 2 . 4 . 0 . zip . . .
3 Trying h t t p : / / s e a r c h . maven . o r g / r e m o t e c o n t e n t ? f i l e p a t h=l u k a s −
vlcek / bigdesk /2.4.0/
4 bigdesk − 2 . 4 . 0 . zip . . .
5 Trying h t t p s : / / o s s . s o n a t y p e . o r g / s e r v i c e / l o c a l / r e p o s i t o r i e s /
r e l e a s e s / c o n t e n t / l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0 / b i g d e s k − 2 . 4 . 0 .
zip . . .
6 Trying h t t p s : / / g i t h u b . com/ l u k a s −v l c e k / b i g d e s k / a r c h i v e / v2 . 4 . 0 .
zip . . .
7 Downloading
............................................................
DONE
8 I n s t a l l e d l u k a s −v l c e k / b i g d e s k / 2 . 4 . 0 i n t o /home/ halimou / p r o j e c t s
/ e l a s t i c s e a r c h −1.6.0/
9 plugins / bigdesk
10 I d e n t i f i e d a s a _ s i t e p l u g i n , moving t o _ s i t e s t r u c t u r e . . .
ou bien les cloner via github
1 $ g i t c l o n e h t t p s : / / g i t h u b . com/ l u k a s −v l c e k / b i g d e s k . g i t
2 Cloning i n t o ’ bigdesk ’ . . .
3 remote : Counting o b j e c t s : 4 9 4 7 , done .
4 remote : Compressing o b j e c t s : 100% ( 2 7 2 6 / 2 7 2 6 ) , done .
5 remote : T o t a l 4947 ( d e l t a 1 8 3 1 ) , r e u s e d 4883 ( d e l t a 1 7 9 2 )
6 R e c e i v i n g o b j e c t s : 100% ( 4 9 4 7 / 4 9 4 7 ) , 1 7 . 7 8 MiB | 1 . 0 8 MiB/ s ,
done .
7 R e s o l v i n g d e l t a s : 100% ( 1 8 3 1 / 1 8 3 1 ) , done .

1 $ cd b i g d e s k /
2 $ g i t tag
3 [ . . . some t a g s l e f t out f o r b r e v i t y . . . . ]
4 v2 . 4 . 0
5 $ g i t c h e c k o u t v2 . 4 . 0
6 Note : c h e c k i n g out ’ v2 . 4 . 0 ’ .
7 [ . . . o p t i o n a l g i t m ess age s . . . ]
8 HEAD i s now a t 4 a23042 . . . R e l e a s e v2 . 4 . 0 − E x t r a c t t h e c l u s t e r
s t a t u s CSS and . . . .
Figure 5.13: Plugin Bigdesk
5.6.3 Plugin Elasticsearch Kopf

Kopf est un outil simple d’administration web pour ElasticSearch écrit en
JavaScript , angularjs , jQuery , Twitter bootstrap.

Ce plugin offre un moyen facile d’éffectuer des tâches courantes sur un

cluster d’ElasticSearch.
Demarrer Localement :
1 g i t c l o n e g i t : / / g i t h u b . com/ l m e n e z e s / e l a s t i c s e a r c h −k o p f . g i t
2 cd e l a s t i c s e a r c h −k o p f
3 g i t checkout { v e r s i o n }
4 open i n d e x . html
1 . / b i n / p l u g i n −− i n s t a l l l m e n e z e s / e l a s t i c s e a r c h −k o p f /{ v e r s i o n }
2 open h t t p : / / l o c a l h o s t : 9 2 0 0 / _plugin / k o p f
Figure 5.14: Plugin KOPF
5.6.4 Plugin Elasticsearch-head

Ce plugin est une interface web pour un cluster ElasticSearch
1 / b i n / p l u g i n − i n s t a l l mobz/ e l a s t i c s e a r c h −head
2 open h t t p : / / l o c a l h o s t : 9 2 0 0 / _plugin / head /

Figure 5.15: Plugin head
Figure 5.16: Plugin head
5.6.5 Plugin Whatson

Whatson est un Plugin d’ElasticSearch pour visualiser l’état d’un cluster. Il
est inspiré par d’autres excellents plugins:
• ES Head

• Bigdesk
• SegmentSpy
1 b i n / p l u g i n − i n s t a l l xyu/ e l a s t i c s e a r c h −whatson / 0 . 1 . 3
2 open h t t p : / / l o c a l h o s t : 9 2 0 0 / _plugin / whatson /

Figure 5.17: Plugin Whatson

chapitre 5 5.7. INSTALLATION DU LOGSTASH
pour plus des plugins on peut visiter le site
https://www.elastic.co/guide/en/elasticsearch/reference/current/modulesplugins.htmlsite
5.7 Installation du Logstash

Pour la corrélation des logs on va installer l’outil Logstash
1 wget h t t p s : / / download . e l a s t i c . co / l o g s t a s h / l o g s t a s h / l o g s t a s h − 1 . 5 . 1 .
t a r . gz
2 t a r x f l o g s t a s h − 1 . 5 . 1 . t a r . gz
3 cd l o g s t a s h − 1 . 5 . 1
Pour les distributions Linux Ubuntu/debian ou bien Redhat/Centos on télécharge

les paquets rmp /deb .
et on édite un fichier
1 input {
2 s t d i n {}
3 file {
4 path => " / var / l o g / ∗ . l o g "
5 type => s y s l o g
6 }
7 }
8 filter {
9 i f [ type ] == " s y s l o g " {
10 grok {
11 match => { " message " => "%{SYSLOGTIMESTAMP: syslog_timestamp }
%{SYSLOGHOST:
12 syslog_hostname } %{DATA: syslog_program } ( ? : \ [ % {POSINT :
syslog_pid }\]) ? :
13 %{GREEDYDATA: s y s l o g _ m e s s a g e } " }
14 a d d _ f i e l d => [ " r e c e i v e d _ a t " , "%{@timestamp } " ]
15 a d d _ f i e l d => [ " r e c e i v e d _ f r o m " , "%{h o s t } " ]
16 }
17 syslog_pri { }
18 date {
19 match => [ " syslog_timestamp " , "MMM d HH:mm: s s " , "MMM dd HH
:mm: s s " ]
20 }
21 }
22 i f [ type ] == " halimou " {
23 grok {
24 match => { " message " => " H e l l o from HALIMOU" }
25 }
26 geoip {
27 s o u r c e => " c l i e n t i p "
28 t a r g e t => " s r c \ _ip "
29 d a t a b a s e => " / opt / backup / G e o L i t e C i t y . dat "
30 a d d _ f i e l d => [ " [ g e o i p ] [ c o o r d i n a t e s ] " , " %{[ g e o i p ] [ l o n g i t u d e
]} " ]

chapitre 5 5.8. INSTALLATION DU LOGSTASH-FORWARDER
31 a d d _ f i e l d => [ " [ g e o i p ] [ c o o r d i n a t e s ] " , " %{[ g e o i p ] [ l a t i t u d e ] }

" ]
32 }
33 }
34 }
35
36 output {
37 elasticsearch {
38 h o s t => l o c a l h o s t
39 i n d e x => b a r i d l o g
40 }
41 s t d o u t { c o d e c => rubydebug }
42 }
et puis on lance les services

1 . / b i n / l o g s t a s h −f l o g . c o n f
et voici une capture d’écran
Figure 5.18: Capture d’écran de Logstash
5.8 Installation du Logstash-forwarder

On utilise logstash-forwarder comme un agent pour envoyer les logs vers logstash
server
1

2 input {
3 2
4 3 lumberjack {
5 4 p o r t => 5040
6 5 s s l _ c e r t i f i c a t e => / opt / backup / t e s t a / ca . c r t
7 6 type => s y s l o g # s t r i n g ( o p t i o n a l )
8 7 }
9 8 }
10 9 filter {
11 10 i f [ type ] == " s y s l o g " {
12 11 grok {
13 12 match => { " message " => "%{SYSLOGTIMESTAMP:
syslog_timestamp } %{SYSLOGHOST:
14 syslog_hostname}%{DATA: syslog_program } ( ? : \ [ % {POSINT
15 : s y s l o g _ p i d } \ ] ) ? : %{GREEDYDATA: s y s l o g _ m e s s a g e } " }
16
17 13 a d d _ f i e l d => [ " r e c e i v e d _ a t " , "%{@timestamp } " ]
18 14 a d d _ f i e l d => [ " r e c e i v e d _ f r o m " , "%{h o s t } " ]
19 15 }
20 16 syslog_pri { }
21 17 date {
22 18 match => [ " syslog_timestamp " , "MMM d HH:mm: s s " , "MMM
dd HH:mm: s s " ]
23 19 }
24 20 } mutate {
25 21 r e p l a c e => [ " @source_host " , " f i r e w a l l −name . ad . company
. com " ]
26 22 r e p l a c e => [ " @message " , "%{message } " ]
27 23 remove => [ " s y s l o g _ m e s s a g e " , " syslog_timestamp " ]
28 24 }
29 25 kv {
30 26 s o u r c e => " @message "
31 27 }
32 28 }
33 29
34 30 output {
35 31 elasticsearch {
36 32 p r o t o c o l => " h t t p "
37 input {
38 2
39 3 lumberjack {
40 4 p o r t => 5040
41 5 s s l _ c e r t i f i c a t e => / opt / backup / t e s t a / ca . c r t
42 s s l _ k e y => / opt / backup / t e s t a / ca . key
43 6 type => s y s l o g # s t r i n g ( o p t i o n a l )
44 7 }
45 8 }
46 9 filter {
47 10 i f [ type ] == " s y s l o g " {
48 11 grok {
49 12 match => { " message " => "%{SYSLOGTIMESTAMP:
syslog_timestamp }

50 %{SYSLOGHOST:
51 syslog_hostname } %{DATA: syslog_program } ( ? : \ [ % {POSINT
52 : s y s l o g _ p i d } \ ] ) ? : %{GREEDYDATA: s y s l o g _ m e s s a g e } " }
53 13 a d d _ f i e l d => [ " r e c e i v e d _ a t " , "%{@timestamp } " ]
54 14 a d d _ f i e l d => [ " r e c e i v e d _ f r o m " , "%{h o s t } " ]
55 15 }
56 16 syslog_pri { }
57 17 date {
58 18 match => [ " syslog_timestamp " , "MMM d HH:mm: s s " , "MMM
dd HH:mm: s s " ]
59 19 }
60 20 } mutate {
61 21 r e p l a c e => [ " @source_host " , " f i r e w a l l −name . ad . company
. com " ]
62 22 r e p l a c e => [ " @message " , "%{message } " ]
63 23 remove => [ " s y s l o g _ m e s s a g e " , " syslog_timestamp " ]
64 24 }
65 25 kv {
66 26 s o u r c e => " @message "
67 27 }
68 28 }
69 29
70 31 elasticsearch {
71 32 p r o t o c o l => " h t t p "
72 33 h o s t => " 1 2 7 . 0 . 0 . 1 "
73 34 manage_template => f a l s e
74 35 i n d e x => " windows−%{+YYYY.MM. dd} "
75 36 }
76 37 s t d o u t { c o d e c => rubydebug }
77 38 }
78 . / b i n / l o g s t a s h −f windows . c o n f
puis on installe logstash forwarder via la commande suivante

1 g i t c l o n e g i t : / / g i t h u b . com/ e l a s t i c s e a r c h / l o g s t a s h −f o r w a r d e r . g i t
2 cd l o g s t a s h −f o r w a r d e r
3 go b u i l d −o l o g s t a s h −f o r w a r d e r
par la suite on édite le fichier logstash-forward.conf

1 {
2 # The network s e c t i o n c o v e r s network c o n f i g u r a t i o n : )
3 " network " : {
4 # A l i s t o f downstream s e r v e r s l i s t e n i n g f o r our me ssa ges .
5 # l o g s t a s h −f o r w a r d e r w i l l p i c k one a t random and o n l y s w i t c h
if
6 # t h e s e l e c t e d one a p p e a r s t o be dead o r u n r e s p o n s i v e
7 " s e r v e r s " : [ " b a r i d . ma: 5 0 4 3 " ] ,
8 # The path t o your t r u s t e d s s l CA f i l e . This i s used
9 # t o a u t h e n t i c a t e your downstream s e r v e r .
10 " s s l ca " : " / opt / backup / t e s t a / ca . c r t " ,
11
12 # Network t i m e o u t i n s e c o n d s . This i s most i m p o r t a n t f o r

13 # l o g s t a s h −f o r w a r d e r d e t e r m i n i n g whether t o s t o p w a i t i n g f o r
an
14 # acknowledgement from t h e downstream s e r v e r . I f an t i m e o u t i s
reached ,
15 # l o g s t a s h −f o r w a r d e r w i l l assume t h e c o n n e c t i o n o r s e r v e r i s
bad and
16 # w i l l c o n n e c t t o a s e r v e r c h o s e n a t random from t h e s e r v e r s
list .
17 " t i m e o u t " : 15
18 },
19
20 # The l i s t o f f i l e s c o n f i g u r a t i o n s
21 " files ": [
22 # An a r r a y o f h a s h e s . Each hash t e l l s what p a t h s t o watch and
23 # what f i e l d s t o a n n o t a t e on e v e n t s from t h o s e p a t h s .
24 {
25 " paths " : [
26 # s i n g l e paths are f i n e
27 " / var / l o g / m ess age s " ,
28 # g l o b s a r e f i n e too , they w i l l be p e r i o d i c a l l y e v a l u a t e d
29 # t o s e e i f any new f i l e s match t h e w i l d c a r d .
30 " / var / l o g / ∗ . l o g "
31 ],
32
33 # A d i c t i o n a r y o f f i e l d s t o a n n o t a t e on each e v e n t .
34 " f i e l d s " : { " type " : " s y s l o g " }
35 }, {
36 # A path o f " −" means s t d i n .
37 " p a t h s " : [ "−" ] ,
38 " f i e l d s " : { " type " : " s t d i n " }
39 }, {
40 " paths " : [
41 " / var / l o g / apache / httpd −∗. l o g "
42 ],
43 " f i e l d s " : { " type " : " apache " }
44 }
45 ]
46 }
ensuite on lance le service logstash-forward

1 . / l o g s t a s h −f o r w a r d −c o n f i g l o g s t a s h −f o r w a r d . c o n f
mais avant on doit générer une certificat et configurer DNS ou bien seulement
on modifie le fichier /etc/hosts
1 c a t <<END>/ e t c / h o s t s
2 1 2 7 . 0 . 0 . 1 votre_name . com
on crée une certificat sous le nom barid.ma afin de chiffrer le transfère des
fichiers journaux entre l’agent et le serveur.
1 o p e n s s l r e q −x509 −batch −nodes −newkey r s a : 2 0 4 8 −keyout ca . key −
out ca . c r t

chapitre 5 5.9. INSTALLATION DU PACKETBEAT
2 −s u b j /CN=b a r i d . ma
3 s c p ca . c r t user@remote_host : / p a t h _ t o _ l o g s t a s h /
5.9 Installation du PacketBeat

1
2 $wget h t t p s : / / download . e l a s t i c . co / b e a t s / p a c k e t b e a t / packetbeat_1
. 0 . 0 ~ Beta1_amd64 . deb
3 #dpkg − i packetbeat_1 . 0 . 0 ~ Beta1_amd64 . deb
pour les autres distributions on peut télécharger la version compatible,puis on

édite le fichier de configuration .
1 interfaces :
2 33 d e v i c e : any
3 34
4 35
5 36 ############################# P r o t o c o l s
######################################
6 37 p r o t o c o l s :
7 38 http :
8 39
9 40 # C o n f i g u r e t h e p o r t s where t o l i s t e n f o r HTTP t r a f f i c .
You can d i s a b l e
10 41 # t h e h t t p p r o t o c o l by commenting t h e l i s t o f p o r t s .
11 42 ports : [ 8 0 , 8080 , 8000 , 5000 , 8002]
12 43
13 44 # Uncomment t h e f o l l o w i n g t o h i d e c e r t a i n p a r a m e t e r s i n
URL o r forms a t t a c h e d
14 45 # t o HTTP r e q u e s t s . The names o f t h e p a r a m e t e r s a r e c a s e
insensitive .
15 46 # The v a l u e o f t h e p a r a m e t e r s w i l l be r e p l a c e d with t h e ’
xxxxx ’ s t r i n g .
16 47 # This i s g e n e r a l l y u s e f u l f o r a v o i d i n g s t o r i n g u s e r
pass words o r o t h e r
17 48 # s e n s i t i v e information .
18 49 # Only query p a r a m e t e r s and top l e v e l form p a r a m e t e r s a r e
replaced .
19 50 # hide_keywords : [ ’ pass ’ , ’ password ’ , ’ passwd ’ ]
20 51
21 52 mysql :
22 53
23 54 # C o n f i g u r e t h e p o r t s where t o l i s t e n f o r MySQL t r a f f i c .
You can d i s a b l e
24 55 # MySQL p r o t o c o l by commenting t h e l i s t o f p o r t s .
25 56 ports : [3306]
26 57
27 58 pgsql :
On ajoute les NIC (Network interface card) pour l’écoute de trafic

on lancer le service packetbeat
1 #/ e t c / i n i t . d/ p a c k e t b e a t s t a r t

chapitre 5 5.10. INSTALLATION DU KIBANA
5.10 Installation du Kibana

pour avoir une interface web afin de simplifier la gestion on télécharge l’outil
Kibana via le site officiel et on lance le service .
1 h t t p s : / / download . e l a s t i c . co / kibana / kibana / kibana −4.1.0 − l i n u x −x64 .
t a r . gz
2 t a r x f kibana −4.1.0 − l i n u x −x64 . t a r . gz
3 cd kibana −4.1.0 − l i n u x −x64
4 . / b i n / kibana

Conclusion Générale
Ce projet de fin d’études avait pour objectif la mise en place d’une solu-
tion d’authentification, ceci par l’application d’une politique de sécurité bien
adéquate à chaque zone de vulnérabilité ,puis la gestion des autorisations en ap-
pliquant des modèles de sécurité destinés aux données critiques et enfin la mise
en place d’une plateforme centrale pour la corrélation des fichiers journaux. Ce
projet comporte les grandes phases suivantes :
• La création d’une politique d’authentification forte pour chaque zone.

• L’implémentation des modèles de securité.
• Une étude comparative entre les outils Open source et payante du NAC
(Network Access Control) et le déploiement de la solution (packetFence ) .
• Une étude des principes de fonctionnement des SIEM (Security Information
and Event Management) et leurs fonctionnalités.
• Le déploiement de la solution et configuration des outils open source Elas-
ticsearch , logstash , kibana , packetbeatet sur un environnement de test
afin de préparer le déploiement sur l’environnement pilote.
Au terme de ce travail, nous avons pu conduire le projet de mise en place

d’une solution de centralisation et de corrélation des fichiers journaux, qui était
un projet de grande priorité pour AL Barid Bank et ce du fait du caractère
sensible des données manipulés d’où la nécessité de garder une traçabilité des
événements qui se produisent au sein du système d’information.
Par ailleurs, Ce projet nous a permis la mise en application de l’esprit d’analyse
et de synthèse qui doivent être l’une des qualités des études d’ingénierie, de
concrétiser certaines de nos connaissances théoriques et pratiques que nous
avons apprises au sein de l’ENSIAS.
78
Webographie
[1] forensic with moloch and elasticseacrh on server www.github.org

[2] elastic www.elastic.co
[3] logstash www.logstash.net
[4] sans www.sans.org
[5] wiki www.wikipedia.org
[6] orbac www.orbac.org
[7] theses www.theses.fr
[8] security security.stackexchange.com
[9] kernel www.kerne.org
[10] irc irc.freenode.net
[11] CISSP All-in-One Exam Guide https://www.isaca.org
[12] Gestion de l’incertitude et codage des politiques de sécurité dans les sys-
tèmes decontrôle d’accès http://www.theses.fr
79

Langue

Rapport

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Rapport

Transféré par

Droits d'auteur :

Page 1

Mémoire de Projet de Fin d’Études

Pour l’Obtention du Diplôme

Master Spécialisé en Informatique

Réseaux Informatiques, Télécommunications et Multimédia

Etude et Mise en place d’une

Soutenu par : Sous la direction de :

M.Abdelhalim SOURI M. Mohamed SENHADJI - ENSIAS

Soutenu par : Membres du jury :

Nous aimerons dédier ce travail :

A nos très chers parents

A tous nos chers amis

A toutes nos familles

A nos chers collègues

A nos chers frères

A nos chères soeurs

Notre encadrant externe Mr Annouar BOUCHAAL qui nous a incité à mener à

Notre encadrant interne Mr Mohamed SENHADJI parce qu’il a accepté de nous

Mots clés: SIEM, AL Barid Bank .

Mots clés: SIEM,AL Barid Bank .

1.1 Organigrame Al barid Bank : . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Architecture Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Matrice de contrôle d’accès : . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1 Statistiques des évènement des logs : . . . . . . . . . . . . . . . . . . . . . 53

5.18 Capture d’écran de Logstash . . . . . . . . . . . . . . . . . . . . . . . . . 72

1.1 Tableau des livrables de projet . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Comparaison entre les outils opensource NAC . . . . . . . . . . . . . . . . 16

5.1 Etude comparative des outils SIEM . . . . . . . . . . . . . . . . . . . . . . 50

AAA Authentification , Autorisation, Accounting. 44

ACS Access Control System. 36

BLP Bell et Lapadula. 49

BYOD Bring Your Own Device. 38

CCP compte chèque postal. 5

DAC Discretionary Access Control. 45

DAF directeur des affaires financières. 7

HRU Harrison, Ruzzo and Ullmann. 49

I-BAC Identity Based Access Control. 51

IOS Internet Operating Sytem. 17

MAC Mandatory Access Control. 45

MOA Maître d’Ouvrage. 14

NAC Network Access Control. 9

OrBAC Organisation-Based Access Control. 46

PDP Policy Decision Point. 18

PKI Public Key Infrastructure. 35

RBAC Role-Based Access Control. 46

Redis REmote DIctionary Server. 84

SEM Security Event Management. 66

SHA System Health Agent. 18

SIEM Security Information and Event Management. 66

SSO Single Sign ON. 36

TBAC Task-based Authorization Controls. 46

TMAC Team-Based Access Control. 46

VMPS VLAN Management Policy Server. 19

Liste des figures 5

Liste des tableaux 7

Liste des abréviations 8

1 Contexte général du projet : 4

2 Network Access Control 13

2.3.4 McAfee NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Centralisation / Corrélation des logs et Traçabilité 46

5.2.6 Quelques capture d’écran de notre solution ELK : . . . . . . . . . . 53

Le troisième chapitre dit « authentification forte » commencera par une définition de

Contexte général du projet :

Dans ce chapitre, nous exposons le contexte général du projet. On présente dans un

1.1 Présentation de l’organisme :