Plateforme Analyse Fichiers Logs
Plateforme Analyse Fichiers Logs
Plateforme Analyse Fichiers Logs
*****
*****
Réalisé par :
Basma Mezni
Encadrants
Mr Imed Jabri
Mr Nabil Hosni
A mes parents,
Pour tout leur soutien, pour tous leurs sacrifices, pour leur amour et pour tout
l’enseignement qu’ils m’ont transmis.
A mon fiancé
Pour leurs encouragements incessants.
MEZNI Basma
Remerciements
Je tiens à exprimer toute ma grande reconnaissance à l’endroit de mes encadreurs M. Imed
JABRI, maître de conférence à Ecole Nationale Supérieure d'Ingénieurs de Tunis (ENSIT) et
M. Nabil HOSNI, chef service à l’Agence Nationale de la Sécurité Informatique (ANSI) qui
n’ont cessé de suivre chacun de mes pas tout au long de ce projet, pour ses encouragements,
ses conseils ses rigueurs dans le travail et surtout ses qualités humaines qui nous ont permis
de travailler avec confiance dans un climat détendu.
Tous mes remerciements à tout le corps enseignant d’UVT pour leurs multiples efforts et
sacrifices déployés pour nous garantir une bonne formation.
Enfin, je témoigne ici à tous les membres du jury, toute ma reconnaissance et le respect que
j’ai pour eux pour avoir accepté d’évaluer mon travail.
Sommaire
Introduction générale .................................................................................................................. 1
Chapitre 1 : Etat de l’art ............................................................................................................. 3
I. Présentation de l’organisme d’accueil ................................................................................ 3
II. Etude théorique ................................................................................................................... 4
1. Les fichiers journaux ....................................................................................................... 4
2. Les types de fichiers journaux ......................................................................................... 4
3. Format de fichier journal ................................................................................................. 4
4. Code de réponse de serveur ............................................................................................. 5
5. Dictionnaire d’attaques ................................................................................................... 7
III. Présentation de projet ...................................................................................................... 7
1. Problématique.................................................................................................................. 7
2. Etude de l’existant ........................................................................................................... 8
3. Critique de l’existant ....................................................................................................... 9
4. Solution proposée ............................................................................................................ 9
IV. Méthodologie à adopter ................................................................................................. 11
V. Choix de méthodologie à adopter ..................................................................................... 12
VI. Choix de langage de modélisation ................................................................................ 13
Analyse et spécification des besoins ........................................................................................ 14
I. Spécification des besoins .................................................................................................. 14
1. Les besoins fonctionnels ............................................................................................... 14
2. Les besoins non fonctionnels ........................................................................................ 15
3. Les besoins architecturaux ............................................................................................ 15
a. Architecture centralisée ............................................................................................. 15
b. Architecture client/serveur ........................................................................................ 16
II. Modélisation des besoins .................................................................................................. 18
1. Les acteurs ..................................................................................................................... 18
2. Diagramme de cas d’utilisation ..................................................................................... 19
a. Cas d’utilisation «gérer investigateur » pour administrateur..................................... 20
b. Cas d’utilisation «gérer incident » pour administrateur ............................................ 21
c. Cas d’utilisation «gérer profil » pour utilisateur ....................................................... 22
d. Cas d’utilisation «analyser incident » pour investigateur .......................................... 23
e. Cas d’utilisation «gérer rapport » pour investigateur ................................................ 23
1. Description des cas d’utilisation ................................................................................... 24
a. Description du cas d’utilisation : « S’authentifier » .................................................. 24
b. Description du cas d’utilisation : « Afficher les statistiques des attaques » .............. 25
c. Description du cas d’utilisation : « Inscrire à la plateforme » ................................... 25
d. Description du cas d’utilisation : «Affecter investigateur à un incident » ................ 26
e. Description du cas d’utilisation : « Analyser incident »............................................ 27
f. Description du cas d’utilisation : « Déclarer incident » ............................................ 28
Conception ............................................................................................................................... 30
I. Architecture de système .................................................................................................... 30
II. Déploiement ...................................................................................................................... 31
III. Conception .................................................................................................................... 31
1. Diagramme de classe ..................................................................................................... 31
a. Représentation des classes ......................................................................................... 31
b. Conception de la base de données ............................................................................. 32
2. Diagramme de séquence ................................................................................................ 33
a. Diagramme de séquence de cas d’utilisation « s’authentifier » ................................ 33
b. Diagramme de séquence de cas d’utilisation «inscrire à la plateforme » .................. 34
c. Diagramme de séquence de cas d’utilisation «Déclarer incident » ........................... 34
d. Diagramme de séquence de cas d’utilisation «affecter investigateur à un incident » 35
e. Diagramme de séquence de cas d’utilisation «analyser incident » ........................... 36
f. Diagramme de séquence de cas d’utilisation « afficher statistiques des attaques » .. 36
Réalisation ................................................................................................................................ 38
I. Environnement matériel .................................................................................................... 38
II. Environnement logiciel ..................................................................................................... 38
III. Présentation des interfaces ............................................................................................ 38
1. Interface d’inscription ................................................................................................... 39
2. Interface d’authentification ........................................................................................... 39
3. Interface de déclaration ................................................................................................. 40
4. Interface de travail ......................................................................................................... 42
5. Interface de gestion des incidents.................................................................................. 42
6. Interface d’affectation un investigateur à un incident ................................................... 43
7. Interface de consultation un dictionnaire d’attaque ...................................................... 43
8. Interface de statistique ................................................................................................... 44
Conclusion générale ................................................................................................................. 46
Webographie ............................................................................................................................ 47
Liste des figures
Figure 1:Extrait d’un fichier log de format ELF ........................................................................ 5
Figure 2:Extrait d’un fichier log de format CLF ........................................................................ 5
Figure 3: Les phases du traitement des fichiers logs ................................................................ 10
Figure 4: Le processus 2TUP ................................................................................................... 12
Figure 5: Architecture 2-tiers ................................................................................................... 16
Figure 6: Architecture 3-tiers ................................................................................................... 17
Figure 7: Diagramme de cas d’utilisation général.................................................................... 20
Figure 8: Diagramme de cas d'utilisation "gérer investigateur" ............................................... 21
Figure 9: Diagramme de cas d'utilisation "gérer incident"....................................................... 22
Figure 10: Diagramme de cas d’utilisation « gérer profil » ..................................................... 22
Figure 11: Diagramme de cas d’utilisation « analyser incident » ............................................ 23
Figure 12: Diagramme de cas d’utilisation « gérer rapport » .................................................. 23
Figure 13: Architecture de système .......................................................................................... 30
Figure 14 : Diagramme de déploiement ................................................................................... 31
Figure 15: Diagramme de classe .............................................................................................. 32
Figure 16 : Diagramme de séquence de cas d’utilisation « s’authentifier »............................. 33
Figure 17: Diagramme de séquence de cas d’utilisation «inscrire à la plateforme » ............... 34
Figure 18: Diagramme de séquence de cas d’utilisation «Déclarer incident » ........................ 35
Figure 19: Diagramme de séquence de cas d’utilisation «affecter investigateur » .................. 35
Figure 20: Diagramme de séquence de cas d’utilisation «analyser incident » ......................... 36
Figure 21:Diagramme de séquence de cas d’utilisation « afficher statistiques»...................... 37
Figure 22 : Interface d’inscription ............................................................................................ 39
Figure 23 : Interface d’authentification .................................................................................... 40
Figure 24 : Interface de déclaration un incident (information générale) .................................. 40
Figure 25: Interface de déclaration un incident (type de l’incident) ........................................ 41
Figure 26: Interface espace de travail de l’administrateur ....................................................... 42
Figure 27: Interface de gestion des incidents ........................................................................... 43
Figure 28: Interface d’affectation ............................................................................................. 43
Figure 29: Interface de consultation dictionnaire d’attaque ..................................................... 44
Figure 30: Interface de statistique ............................................................................................ 44
Liste des tableaux
Tableau 1:Liste des codes de réponse de serveur [2] ............................................................................. 7
Tableau 2: Comparaison entre les principales méthodologies de développement [8] ........................ 12
Tableau 3 : Comparaison entre les différentes architectures ............................................................... 18
Tableau 4 : Description du cas d’utilisation « authentifier utilisateur » ............................................... 24
Tableau 5: description du cas d’utilisation « consulter les statistiques». ............................................. 25
Tableau 6: Description du cas d’utilisation « inscrire à la plateforme » ............................................... 26
Tableau 7: Description du cas d’utilisation : «Affecter investigateur à un incident » .......................... 27
Tableau 8: Description du cas d’utilisation : « Analyser incident »....................................................... 28
Tableau 9: Description du cas d’utilisation : « Déclarer incident » ....................................................... 29
Introduction générale
La pérennité de l’entreprise passe par une disponibilité permanente de son système
d’information. Cette réalité influe de nos jours le comportement des entreprises qui devient de
plus en plus mature dans les investissements de la sécurité du système d’information qui est
un élément absolument vital.
Les efforts de sécurisation ne peuvent pas être efficaces que si ces investissements sont
correctement étudiés et ciblés, en mettant en place les moyens de protection qui apportent un
niveau de sécurité favorable adapté aux enjeux de l’entreprise.
Le contexte de notre projet est de réaliser une plateforme qui permet d’investiguer sur un
incident afin de déterminer les responsables et les scénarios d’attaques en partant les traces
(preuves ou logs) nécessaires.
Ce rapport présente l’ensemble des étapes suivies pour développer la solution. Il contient
quatre chapitres organisés.
Le premier chapitre sera dédié à la présentation de l’état de l’art. Nous allons tout d’abord
présenter l’organisme d’accueil et le projet. Ensuite nous passerons à l’étude et à la critique de
l’existant pour enfin proposer une solution adéquate. La méthodologie utilisée y sera
également définie pour nous permettre de réaliser convenablement notre travail.
Le second chapitre sera consacré sur l’analyse des besoins fonctionnels et non fonctionnels.
Nous modéliserons les besoins des utilisateurs via les diagrammes de cas d’utilisation.
Le troisième chapitre sera intitulé conception et fera dans un premier temps une étude
préliminaire en présentant l’architecture de la solution proposée précédemment. Dans un
Page 1
second temps, en se référant à la méthodologie de travail choisie, elle illustrera la plupart des
diagrammes de conception.
Le quatrième chapitre quant à lui sera réservé à la réalisation. Celui-ci, passera en revue
l’environnement de travail et les résultats obtenus.
Pour finir, une conclusion générale de tout le rapport sera nécessaire où nous proposerons les
éventuelles améliorations susceptibles d’être ajoutées ultérieurement.
Page 2
Chapitre 1 : Etat de l’art
Introduction
Dans ce premier chapitre, nous allons introduire le cadre du projet, à savoir l’organisme
d’accueil. Ensuite, nous passerons à la présentation du sujet, et pour terminer, nous
spécifierons la méthodologie du développement et le langage de modélisation à suivre durant
notre projet.
L'agence effectue un contrôle général des systèmes informatiques et des réseaux relevant des
divers organismes publics et privés, elle est chargée des missions suivantes:
Veiller à l'exécution des orientations nationales et de la stratégie générale en systèmes
de sécurité des systèmes informatiques et des réseaux,
Suivre l'exécution des plans et des programmes relatifs à la sécurité informatique dans
le secteur public à l'exception des applications particulières à la défense et à la sécurité
nationale et assurer la coordination entre les intervenants dans ce domaine,
Assurer la veille technologique dans le domaine de la sécurité informatique,
Etablir des normes spécifiques à la sécurité informatique et élaborer des guides
techniques en l'objet et procéder à leur publication,
Œuvrer pour encourager le développement de solutions nationales dans le domaine de
la sécurité informatique et à les promouvoir conformément aux priorités et aux
programmes qui seront fixés par l'agence,
Participer à la consolidation de la formation et du recyclage dans le domaine de la
sécurité informatique,
Veiller à l'exécution des réglementations relatives à l'obligation de l'audit périodique
de la sécurité des systèmes informatiques et des réseaux.
Page 3
II. Etude théorique
1. Les fichiers journaux
Chaque action d'un système informatique (ouverture d'une session, installation d'un
programme, navigation sur Internet...) produit un fichier log. Ces fichiers textes listent
chronologiquement les évènements exécutés par un serveur ou une application informatique.
Ils s'avèrent utiles pour comprendre la provenance d'une erreur en cas de bug.
S'agissant d'un serveur Web, un fichier log va enregistrer la date et l'heure de la tentative
d'accès, l'adresse IP du client, le fichier cible, le système d'exploitation utilisé, le navigateur,
la réponse du serveur à cette requête, éventuellement le type d'erreur rencontré, etc. [1]
Les systèmes informatiques génèrent de nombreux types de fichiers journaux afin de fournir
les informations essentielles sur le système. Parmi ses types, on peut citer les exemples
suivants :
Les fichiers log issus des serveurs,
Les fichiers log issus des sites web,
Les fichiers log issus des systèmes de détection d’intrusion,
Les fichiers log issus des systèmes de surveillance de réseau,
Les fichiers log issus des pare-feu,
Les fichiers log d’accès,
Les fichiers log d’erreurs.
Dans cette partie, nous avons expliqué ces deux formats à travers deux exemples.
Page 4
161.31.132.116 - - [21/Dec/2001:08:42:55 -0500] "GET /home.htm HTTP/1.0" 200 4392
"http://fr.search.yahoo.com/fr?p=peinture" "Mozilla/4.7 [en] (Win98)"
La figure 2 montre un exemple de format CLF de fichier log, ce format est composé, pour
chaque requête d’un utilisateur par les champs suivants :
Les codes de réponse de serveur web sont l’état du protocole http, qui permet à un serveur
web de transmettre des informations et des pages à un client ou un navigateur web.
Page 5
Ces codes ont été divisés en 5 familles, le tableau 1 présente les différents codes de chaque
famille ainsi que ces significations.
Code Signification
1XX Information
100 Continue
2XX Succès
200 OK
201 Créé
202 Accepté
3XX Redirection
403 Interdit
Page 6
404 Non trouvé
5. Dictionnaire d’attaques
Le grand nombre d’attaque et le changement perpétuel de leurs formes nous a obligé à créer
une BD sous forme d’un dictionnaire englobant toutes les attaques ainsi que leurs structures
les plus connues. La comparaison entre un log et une expression rationnelle se fait en se
référant à ce dictionnaire.
Les composants de dictionnaire d’attaques sont : l’identifiant de l’attaque, la catégorie
d’attaque, l’impact et la description de chaque ligne d’attaque.
L’évolution de l’utilisation du réseau Internet sur le territoire tunisien a été suivie en parallèle
par l’augmentation des attaques cybernétiques telles que defacement web, phishing, attaque
virale (malware), etc. Pour cela l’ANSI doit utiliser tous les moyens et les techniques afin de
renforcer la sécurité du cyber-espace tunisien et protéger les systèmes d’informations du
gouvernement et des entreprises tunisiennes.
Page 7
En cas d’incidents, l’ANSI prend en charge leur traitement afin de déterminer les
responsables et les scénarios d’attaque possible, en utilisant des traces (fichiers log)
nécessaires.
L’investigation sur un incident consiste à analyser des fichiers de journalisation log de façon
manuelle en utilisant une ligne de commande Unix. Cette méthode a plusieurs inconvénients
tels que :
Prendre beaucoup de temps,
Inefficace
Ne détermine pas tous les responsables et les scénarios d’attaques.
2. Etude de l’existant
Il existe sur le marché plusieurs logiciels pour l’analyse des fichiers log payants ou open
source. Parmi ces logiciels nous retrouvons :
AWStats :
AWStats est un analyseur de log web mais, FTP, Streaming et mail offrant des vues
graphiques statiques mais aussi dynamiques des statistiques d'accès aux serveurs web. Il
permet d'afficher le nombre de visites, de visiteurs uniques, de pages, de hits, de transfert, par
domaine, hôte, heure, navigateur, OS, etc. AWStats est un logiciel libre. [3]
Webalizer
Page 8
Advanced Log Analyzer
Advanced Log Analyzer est un puissant logiciel d'analyse de trafic de site Web. Il génère un
grand nombre de compte-rendu traditionnels comme les sites référant au visiteur, le nombre
de téléchargements par jour, le nombre de clics et d'hôtes par jour, les moteurs de recherche
les plus populaires, les mots clés de recherche, etc. Il peut être utilisé en tant que compteur de
visiteurs normal et outil de suivi pour surveiller l'activité d'un site Web. L'avantage principal
de cet outil d'analyse réside dans ses comptes rendus. Il peut recréer le chemin du visiteur à
partir des fichiers log, créer un modèle Web du site et produire des comptes rendus sur le flux
d'utilisateurs sur le site. [5]
Sawmill
Sawmill est un analyseur de log universel, capable d'analyser et rendre compte de tout type de
données du journal textuel. Sawmill supporte 850 formats de journaux communes différentes,
à partir de la gamme complète de dispositifs populaires: serveurs web, serveurs de médias,
serveurs de messagerie, les pare-feu, passerelles, etc. [6]
XpoLog
XpoLog fait une plate-forme d'analyse du journal pour les applications, les serveurs et les
applications de cloud computing. Centre XpoLog fournit la gestion du journal, journal de
l'observation, l'analyse des journaux, rapports, analyse des problèmes, la corrélation et de
nombreuses autres fonctionnalités qui aident les groupes d'applications, les opérations et les
administrateurs pour accélérer l'investigation et le monitoring d'applications. [7]
3. Critique de l’existant
Une analyse des solutions existantes montre que la plupart de ces logiciels fournissent des
informations générales et des fonctionnalités de base d’analyse de fichier journaux et ne
déterminent pas les responsables et essentiellement le scénario possible de l’incident.
4. Solution proposée
Après une étude comparative des différentes solutions existantes, il est donc primordial au
regard des inconvénients recensés de proposer une solution qui pourra répondre à nos besoins.
Page 9
Pour cela nous avons choisi de développer une application d’analyse des fichiers logs dont
l’objectif est : Automatiser l’analyse de l’investigation,
Identifier des cybers criminels,
Déterminer le scénario possible de l’incident,
Modéliser des données des attaques selon plusieurs axes.
La figure 3 présente les trois phases du traitement des fichiers logs par la solution proposée:
Dépôt et traitement : les étapes à suivre pour cette phase sont :
Définition de traitement : collecte les informations pour traiter l’incident.
Collection de preuves qui sont les fichiers logs.
Analyse de fichier log en utilisant l’algorithme suivant :
Lancer un script d’optimiser les fichiers logs,
Comparer une partie de logs avec le dictionnaire d’attaque,
Classer par modules les scénarios des attaques.
Synthèse et rédaction du rapport.
Validation d’une liste du rapport logs traitées.
Publication : cette phase comprend un rapport valide avec un scénario probable.
Page 10
IV. Méthodologie à adopter
Pour assurer un bon rendement de développement en termes de qualité et de productivité le
choix de la méthodologie en informatique est primordial. Vue la complexité des systèmes de
nos jours, le génie logiciel doit tenter de remédier à cette complexité en offrant une démarche
à suivre avec des étapes bien précises. C’est le principe des méthodologies de travail.
Page 12
VI. Choix de langage de modélisation
La modélisation permet de mieux comprendre le fonctionnement du système, c’est également
un bon moyen pour maitriser sa complexité et d’assurer sa cohérence.
Pour cela nous avons choisi le langage de modélisation UML (Unified Modeling Language)
qui permet de :
Obtenir une modélisation de très haut niveau indépendante des langages et des
environnements.
Faire collaborer des participants de tous horizons autour d'un même document de
synthèse.
Exprimer dans un seul modèle tous les aspects statiques, dynamiques, juridiques,
spécifications, etc...
Documenter un projet.
Conclusion
Dans ce chapitre, nous avons présenté l’organisme d’accueil ANSI. Puis, nous avons procédé
à une étude des solutions existantes qui nous a conduite par la suite à proposer une solution
dont le but est de combler les limites de ces dernières.
Page 13
Analyse et spécification des
besoins
Introduction
Dans ce chapitre, nous détaillons les besoins fonctionnels, non fonctionnels et architecturaux
afin de bien démarrer notre projet. Enfin, nous ajouterons la modélisation des besoins de
l’application ainsi que les diagrammes de cas d’utilisation.
Analyser un incident.
Consulter statistique,
Télécharger rapport,
Page 14
2. Les besoins non fonctionnels
A part les besoins fondamentaux, notre future application doit répondre aux critères suivants :
L’intégrité des données : Il y a certains traitements pour les mauvaises entrées des
données, tel que les alertes immédiates pour l’utilisateur en cas d’erreur.
Nous devons savoir qu’il existe plusieurs types d’architectures. Parmi ces architectures, nous
pouvons citer :
a. Architecture centralisée
Cette architecture se compose d'un unique serveur, dont le but est de recenser les fichiers
proposés par les différents clients. Il dispose principalement de deux types d'informations :
celles sur le fichier (nom, taille, ...), et celles sur l'utilisateur (nom utilisé, IP, nombre de
fichiers, type de connexion, ...) Du côté du client, rien de plus simple : une fois connecté grâce
au logiciel spécifique, il peut faire des recherches comme avec un moteur classique. On
obtient alors une liste d'utilisateurs disposant de la ressource désirée. Il suffit alors de cliquer
sur le bon lien pour commencer le téléchargement.
Les avantages de cette architecture sont :
Simplicité d’utilisation.
Facilité de recherche.
Page 15
Les inconvénients sont les suivantes :
Faible sécurité : si le serveur est supprimé, le réseau est hors service
Pas d’anonymat : chaque utilisateur est identifié sur le serveur [10]
b. Architecture client/serveur
L’architecture client/serveur est subdivisée entre deux entités client et serveur qui coopèrent
ensemble via des requêtes. Nous distinguons plusieurs types de cette architecture :
Architecture 2-tiers :
Une architecture 2-tiers est composée de deux éléments, un client et un serveur qui se
contente de répondre aux requêtes du client.
Ce type d’application permet d’utiliser toute la puissance des ordinateurs présents sur le
réseau et permet de fournir à l’utilisateur une interface riche, tout en garantissant la cohérence
des données qui restent gérées de façon centralisée.
La gestion des données est prise en charge par un SGBD centralisé sur un serveur dédié. On
interroge ce serveur à travers un langage de requête, le plus courant étant SQL.
Page 16
Architecture 3-tiers :
Cette architecture 3-tiers sépare l’application en 3 couches des services distincts :
Couche présentation : l’affichage et les traitements locaux qui sont pris en charge par
le poste client,
Couche application : les traitements applicatifs globaux sont pris en charge par le
service applicatif,
Couche métier : les services de base de données sont pris en charge par un SGBD.
La figure 6 montre les 3 couches de cette architecture.
Architecture n-tiers :
L'architecture n-tiers est aussi appelée architecture distribuée ou architecture multi-tiers.
L'architecture n-tiers qualifie la distribution d'applications entre de multiples services et non la
multiplication des niveaux de service : les trois niveaux d’abstraction d’une application sont
toujours pris en compte.
Comparaison des architectures 2 tiers, 3 tiers et n tiers
Le tableau 3 présente les différences qu’apportent les architectures 3 et n tiers aux anciennes
architecture 2-tiers. [12]
Page 17
2 tiers 3 et n tiers
Faible Elevée
Encapsulation
(les tables de données sont (le client fait appel à des
des données
directement accessibles) services ou méthodes)
Faible Bonne
(plusieurs requêtes SQL sont (seulement les appels de
transmises sur les réseaux, les services et les réponses
Performance
données sélectionnées doivent sont mis sur le réseau)
être acheminées vers le client
pour analyse)
Non Oui
Lien (via le middleware
Serveur-serveur Serveur/Serveur)
Limitée Excellente
Flexibilité
(possibilité de faire résider
d'architecture
les couches 2 et 3 sur une
matérielle
ou plusieurs machines)
Faible Excellente
(possibilité d'avoir la
Relève en cas de
couche du centre "middle-
pannes
tier" sur plusieurs
serveurs)
Tableau 3 : Comparaison entre les différentes architectures
L’administrateur, l’investigateur et le client sont les acteurs interagissent avec notre système.
L’administrateur peut :
S’authentifier,
Gérer profil,
Gérer client, investigateur,
Page 18
Gérer incident, dictionnaire d’attaque et d’organisme,
Valider rapport,
Consulter statistique,
Télécharger rapport.
L’investigateur peut :
S’authentifier,
Gérer profil,
Analyser incident,
Gérer rapport,
Télécharger rapport.
Le client peut :
S’authentifier,
Gérer profil,
Déclaration d’un incident,
Upload fichier log,
Inscription à la plateforme,
Télécharger rapport.
Page 19
Figure 7: Diagramme de cas d’utilisation général
La figure 8 présente de façon plus détaillé les différentes fonctions pour gérer un
investigateur, alors il est possible de créer, modifier, supprimer ou consulter un investigateur.
Page 20
Figure 8: Diagramme de cas d'utilisation "gérer investigateur"
Page 21
Figure 9: Diagramme de cas d'utilisation "gérer incident"
Page 22
d. Cas d’utilisation «analyser incident » pour investigateur
La figure 11 montre que l’analyse d’un incident exige de générer un rapport et de gérer le
dictionnaire d’attaque.
Pour gérer un dictionnaire d’attaque, il faut ajouter une attaque, un impact et une description
Dans cette partie, nous donnons plus de détails sur les différents cas d’utilisation présentés ci-
dessus. Les cas d’utilisation présentés qui suivent : « s’authentifier », « inscrire à la
plateforme», « déclarer incident », « affecter investigateur à un incident », « analyser
incident», « afficher les statistiques des attaques».
Pour assurer la sécurité de système d’informations, il est important que chaque acteur passe
par une phase d’authentification. C’est le cas de notre système où l’administrateur,
l’investigateur et le client se sont authentifiés avant de pouvoir bénéficier des services offerts
par notre application. Le tableau 4 présente une description de cas d’utilisation
« s’authentifier ».
Etapes Description
Page 24
b. Description du cas d’utilisation : « Afficher les statistiques des attaques »
Description
Etapes
Acteurs : administrateur.
Résumé
Titre : consulter les statistiques des attaques.
Description : le système affiche à l’administrateur le
pourcentage de chaque attaque.
Le système n’a pas pu afficher les statistiques car aucun rapport n’a été
Scénario alternatif
généré.
Page 25
Etapes Description
Acteurs : client.
Résumé
Titre : inscrire à la plateforme d’investigation des logs.
Description : le système affiche au client le formulaire
d’inscription.
Le tableau 7 décrit à son tour les détails du cas d’utilisation «Affecter investigateur à un
incident » qui s’accompagne du scénario nominal et du scénario alternatif.
Description
Etapes
Acteurs : administrateur.
Résumé
Titre : affecter un investigateur à un incident.
Description : le système affiche à l’administrateur la liste des
Page 26
incidents afin de les affecter un investigateur.
Le but principal de notre application est l’analyse d’un incident, le tableau 8 décrit le scénario
nominal de cas d’utilisation « analyser incident » ainsi que le scénario alternatif.
Description
Etapes
Acteurs : investigateur.
Résumé
Titre : analyser un incident.
Description : le système identifie les cybers criminels et le scénario
possible de l’incident.
Page 27
L’administrateur s’est authentifié.
Pré-conditions
Le système est opérationnel.
Les incidents ont été affectés pour l’investigateur.
L’administrateur accède à son espace de travail.
L’administrateur télécharge et vérifie le fichier log.
Description
Etapes
Acteurs : client.
Résumé
Titre : déclarer un incident en ligne.
Description : le système affiche au client le formulaire de
déclaration.
Page 28
Le système est opérationnel.
Le client accède à son espace de travail.
Conclusion
Ce chapitre nous a été utile pour monter notre but, nous avons spécifié les différents besoins
auxquels doit répondre notre système, ainsi que, nous avons fait une étude des différents cas
d’utilisation de notre solution.
Enfin, il nous reste à élaborer une bonne conception afin d’assurer le bon fonctionnement du
système. C’est ainsi que nous pourrons entamer le prochain chapitre sur la conception.
Page 29
Conception
Introduction
L’activité de conception détaillée consiste à façonner le système et à lui donner une forme et
une architecture répondant à tous les besoins y compris les besoins non fonctionnels et
architecturels. Elle consiste une base et un point de départ aux activités d’implémentation et
de test.
I. Architecture de système
Au niveau de cette section, nous avons proposé l’architecture physique à adopter pour notre
application. Notre choix s’est porté sur l’architecture client-serveur et plus précisément sur
l’architecture 3-tiers pour les raisons suivantes :
Elle correspond le mieux à la structure de notre système qui composera d’un serveur
d’application, d’un serveur de base des données et des clients.
Deuxièmement, vu que nous avons besoin d’un client léger (navigateur) qui n’aura
qu’à se connecter au serveur. Donc, il nous a paru d’opter pour une architecture plus
évoluée que l’architecture 2-tiers.
Finalement, l’architecture 3-tiers est plus sécurisée et plus performante que
l’architecture 2-tiers.
Page 30
La figure 13 présente les trois niveaux de notre architecture de système qui sont le client, le
serveur d’application et le serveur de base de données.
II. Déploiement
La figure 14 présente le diagramme de déploiement qui modélise l’architecture physique de
notre système ainsi qu’il affiche les relations entre les composants logiciels et matériels de
notre système.
III. Conception
La conception est l’étape la plus importante dans le cycle de développement de l’application.
Au niveau de cette partie, nous avons détaillé l’aspect statique présenté par le diagramme de
classe ainsi que l’aspect dynamique décrit par le diagramme de séquence de notre système.
1. Diagramme de classe
Le diagramme de classe est une modélisation statique du notre système en termes de classes et
de relations entre ces classes.
La figure 15 illustre les différentes classes intervenant dans notre application, ainsi que les
attributs, les opérations et associations entre les classes.
Page 31
Figure 15: Diagramme de classe
2. Diagramme de séquence
Pour accéder à son espace de travail, chaque utilisateur quel que soit l’administrateur,
l’investigateur ou le client, doit se connecter en utilisant son login et mot de passe.
Le diagramme de séquence présenté dans la figure 16 présente l’enchainement de la phase
d’authentification.
Page 33
b. Diagramme de séquence de cas d’utilisation «inscrire à la plateforme »
Après l’authentification, le client peut déclarer un incident en mettant les informations sur
l’incident ainsi que le fichier log pour faire le traitement nécessaire, ces étapes sont présentées
dans le diagramme de séquence montré dans la figure 18.
Page 34
Figure 18: Diagramme de séquence de cas d’utilisation «Déclarer incident »
Page 35
La figure 19 montre le diagramme de séquence de scénario « Affectation d’un investigateur
pour l’analyse d’un incident »
Le diagramme de séquence de la figure 20, illustre les étapes effectuées par le système pour
analyser un incident et générer un rapport décrivant le scénario d’attaque.
Selon la figure 21, le système invite l’administrateur à consulter les graphiques, correspondant
aux statistiques des différentes catégories d’attaque, identifiées lors de l’analyse des fichiers
logs.
Page 36
Figure 21:Diagramme de séquence de cas d’utilisation « afficher statistiques»
Conclusion
Ce chapitre nous a permis de mettre en avant les phases nécessaires à la réalisation de notre
application à savoir l’architecture du système et les diagrammes de conception.
A cette étape, il devient possible de passer à la phase de réalisation qui constitue l’objet du
chapitre suivant.
Page 37
Réalisation
Introduction
Dans ce chapitre, nous allons commencer par présenter l’environnement matériel et logiciel
du projet. Ensuite, nous nous intéressons à la description de quelques interfaces de notre
application.
I. Environnement matériel
Nous avons utilisé pour les besoins de ce projet un ordinateur portable DELL Inspiron ayant
caractérisé par :
Un Processeur : Inlel(R) Core(TM) i3-2370M CPU @ 2.40GHz 2.40 GHz
RAM : 4 Go
Système d’exploitation Windows 7 Professionnel 32 bits.
Page 38
1. Interface d’inscription
Lorsque le client n’a pas de compte sur la plateforme, il pourrait accéder, via le lien
inscription, tout en saisissant quelques informations personnelles et les paramètres d’accès. La
figure 22 illustre ces informations.
2. Interface d’authentification
Page 39
Figure 23 : Interface d’authentification
3. Interface de déclaration
Page 40
Pour déclarer un incident, un client doit enregistrer toutes les informations nécessaires
concernant cet incident pour qu’il soit convenablement analyser. Le client accède au
formulaire de déclaration et saisi les informations générales, parmi ces informations montrées
dans la figure 24 sont la date, l’heure, l’organisme impacté, la source d’identification,
l’hébergeur, l’adresse IP et le système d’exploitation.
Autre que les informations générales, le client identifie le type de l’incident, ainsi que
télécharger le fichier log à analyser afin de déterminer le scénario d’attaque montré dans la
figure 25.
Page 41
4. Interface de travail
Après authentification, chaque utilisateur accède à son espace de travail. La figure 26 montre
l’espace de travail de l’administrateur qui contient les différentes tâches que l’administrateur
doit effectuer tels que la gestion de son profil, la gestion de client, d’investigateur, d’incident
et la consultation de statistique.
La figure 27 présente la liste des incidents déclarés, cette liste contient les informations
concernant chaque incident ainsi que l’action à faire sur cet incident. Alors l’administrateur
peut consulter ou supprimer un incident, affecter un investigateur ou bien télécharger le
fichier log.
Page 42
Figure 27: Interface de gestion des incidents
Page 43
Figure 29: Interface de consultation dictionnaire d’attaque
8. Interface de statistique
Parmi les tâches de l’administrateur, il peut consulter les statistiques concernant les
différentes catégories d’attaque, identifiées lors de l’analyse des fichiers logs. La figure 30
montre le graphique qui affiche le pourcentage de chaque attaque.
Page 44
Conclusion
Nous sommes parvenus au terme de ce chapitre dont l’objectif principal était de présenter le
produit final obtenu. A cet effet, nous avons tour à tour présentés les outils matériels et
logiciels utilisés d’une part, puis nous avons présenté des interfaces du notre système.
Page 45
Conclusion générale
L’objectif de ce projet de fin d’étude était de développer une application qui permet
d’automatiser l’analyse des fichiers logs afin d’identifier les cybers criminel, de déterminer le
scénario possible de l’incident et de modéliser les données des attaques selon plusieurs axes.
Nous avons confrontés des contraintes dans la phase du développement. En effet, nous avons
passé plus de temps pour comprendre le script « scalp » programmé en langage « phyton » et
les expressions régulières de dictionnaire d’attaque « défault filter ».
Cependant, nous pouvons toujours y apporter quelques améliorations qui feront de cette
application. En ce qui concerne la côté ergonomique de l’application. En effet nous pourrons
aussi développer une partie de l’application dédiées aux mobiles.
De plus, nous pouvons même développer une application qui permet la génération des
modèles de rapports spécifiques à l'ANSI.
Page 46
Webographie
[1]http://www.journaldunet.com/developpeur/algo-methodes/tutoriel-pratique/les-fichiers-
log-des-indicateurs-utiles.shtml
[2]http://www.journaldunet.com/solutions/dsi/erreur-et-codes-http.shtml
[3]https://fr.wikipedia.org/wiki/AWStats
[4] https://fr.wikipedia.org/wiki/Webalizer
[5]http://www.01net.com/telecharger/windows/Internet/vrml/fiches/23742.html
[6]http://www.haage
partner.de/sawmill/workshops/using_sawmill_to_report_on_custom_log_data/using_sawmill
_to_report_on_custom_log_data.html
[7]http://www.predictiveanalyticstoday.com/list-security-event-management-log-analysis-
software/
[8]http://www.freewebs.com/fresma/Formation/UML/Processus%20Unifie.pdf
[9]http://www.uml-sysml.org/modelisation-objet/pourquoi-uml
[10]http://wapiti.telecom-
lille1.eu/commun/ens/peda/options/st/rio/pub/exposes/exposesser2010-ttnfa2011/lemarchand-
hardy/architectures_p2p.htm
[11]http://deptinfo.cnam.fr/new/spip.php?pdoc5259
[12]http://www.grosmax.uqam.ca/Martin/INF5153/tab23tier.htm
Page 47