Ameni BEN JEMIA SFE Copy3

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET
DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
INSTITUT SUPERIEUR D’INFORMATIQUE
RAPPORT DE STAGE DE FIN D’ETUDES
Présenté en vue de l’obtention du

Diplôme National de Licence en
Ingénierie des Systèmes Informatiques
Spécialité : Ingénierie des Réseaux et Systèmes (IRS)
Par
Ameni BEN JEMIA
Mise en plase d’une solution SIEM
Encadrant professionnel : Mr Akram ALLANI

Encadrant académique : Mme Sourour MHENNI
Réalisé au sein de Standard Sharing Software
Année Universitaire 2022 - 2023

Dédicaces
Je dédie ce travail à :
Mon père, qui n’a jamais cessé de m’encourager et de me soutenir... Merci mon cher,
pour ton écoute, tes protections, ta patience... Merci d’être toujours présent pour m’avoir
considérablement réparé, redirigé, stoppé... Grâce à toi papa j’ai appris le sens du travail et
de la responsabilité. Je voudrais te remercier pour ton amour, ta compréhension... ton soutien
fut une lumière dans tout mon parcours aucune dédicace ne saurait exprimer l’amour l’estime
et le respect que j’ai toujours pour toi.
Ma mère la plus douce et la plus merveilleuse de toutes les mamans je te remercie pour
ton courage... Merci de m’avoir donné une excellente éducation qui me sert énormément et
me servira toute ma vie. Merci pour ta présence, ton affection, ta dévotion... Merci maman
parce que qu’en touts circonstances tu me témoignes un amour inconditionnel dont seule une
maman est capable d’être ce que tu es malgré tout car, ce que tu es, conditionne la femme
que je suis devenue et la mère que j’espère être...
Ma grande soeur et ma cousine , Merci de si bien accomplir votre rôle. Merci d’être là
quand ça ne va pas. Merci d’être capables de me brasser quand j’ai besoin d’être réveillée et
de me donner le petit coup de pied au derrière dont j’ai besoin pour continuer d’avancer.
Ma grand-mère Zohra, elle nous a quittés, mais cet amour est toujours présent et aussi
fort. Chaque souvenir est ancré au plus profond de moi. Merci d’avoir fait de notre famille,
une équipe soudée et unie.
Mes amies les plus proches Sirine et Ahlem qui ont su m’apporter aide et soutiennent
aux moments propices, je dédie ce travail, reconnaissant et remerciant chaleureusement.
Mon fiancé pour son amour et son soutient.
Mes chères amies, Eya, Afef et Chaima, que j’ai eu le plaisir de rencontrer pendant
mon stage, en reconnaissance de leur encouragement.
Ma tante Najet, qui a déployé tous ses efforts pour m’aider, est une personne exceptionnelle.
Tous ceux qui m’ont aidé de prés ou de loin à la réalisation de ce travail de recherche.
Ameni BEN JEMIA
i
Remerciements
Je tiens à exprimer mes vifs remerciements à mes deux encadrants :
Madame Sourour MHENNI

Monsieur Akram ALLANI
J’ai eu le privilège de profiter de vos vastes connaissances, ainsi que de votre profond savoir faire. j’ai
pu aussi apprécier vos qualités humaines et professionnelles qui ont suscité mon admiration. Croyez
madame et monsieur à mon profond respect, à ma gratitude et mes sentiments de haute estime.
À tous les professeurs de l’institut supérieur d’informatique qui m’ont éduqué durant ces 3
ans pour leurs patiences, leur conseillent, leurs encouragements, leurs bonnes humeurs et leur don
pour remonter le moral.
Je tiens également à exprimer mes remerciements à tous les membres du jury pour l’honneur
qu’ils me font en acceptant d’évaluer ce travail.
Je souhaite exprimer ma gratitude à toutes les personnes qui ont apporté leur contribution,
de près ou de loin, à la réalisation de ce travail. Leurs conseils, encouragements et soutien ont été
précieux.
ii
Table des matières
Introduction générale 1
1 Contexte général du projet 2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Présentation générale de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Présentation de 3S Standard Sharing Software . . . . . . . . . . . . . . . . . . 3
1.1.2 Services offerts par 3S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Cadre générale du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Étude préalable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Etat d’art sur les SIEMs 8

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Protection des données et des systèmes informatiques contre les menaces et les attaques 9
2.1.1 Présentation des services de sécurité . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Mesures de sécurité pour prévenir les attaques . . . . . . . . . . . . . . . . . . 10
2.2 Security Information and Event Management (SIEM) . . . . . . . . . . . . . . . . . . 11
2.2.1 Différence entre SIEM, SEM, SIM . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Rôle d’un Siem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Mode de fonctionnement du SIEM : . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Définition d’un Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Format d’un log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Produits SIEM sur le marché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Produits SIEM open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Produits SIEM commerciaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
iii
2.4.3 Comparaison des solutions disponibles sur le marché . . . . . . . . . . . . . . 18
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Etude de la solution WAZUH 20

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Présentation de la plateforme WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Composantes de WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Wazuh indexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Wazuh server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Wazuh dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4 Wazuh agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.2 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Mise en place de WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.1 Installation et Configuration de WAZUH . . . . . . . . . . . . . . . . . . . . . 25
3.5.2 Collecte des données à partir des machines Ubuntu . . . . . . . . . . . . . . . 29
3.5.3 Collecte des données à partir des machines Centos . . . . . . . . . . . . . . . 30
3.6 Intégration des outils tiers à WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1 Installation et Configuration de MISP . . . . . . . . . . . . . . . . . . . . . . 32
3.6.2 Installation et Configuration de The Hive . . . . . . . . . . . . . . . . . . . . 33
3.6.3 Installation et Configuration de Cortex . . . . . . . . . . . . . . . . . . . . . . 34
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Tests et Validation 41
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Scénario d’attaque brute force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Surveillance de l’intégrité des fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Surveillance de l’exécution de commandes malveillantes . . . . . . . . . . . . . . . . . 44
4.4 Détection de processus non autorisés . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Détection de processus cachés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
iv
4.6 Détection d’une attaque par injection SQL . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7 Détection de fichiers binaires suspects . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8 Détection d’une attaque Shellshock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Conclusion générale 52
Bibliographie 53
Annexes 55
Annexe 1. Installation de Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Annexe 2. Installation de MISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Annexe 3. Installation de The Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Annexe 4. Installation de Cortex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Annexe 5 .Les codes nécessaires pour l’integration de wazuh avec the Hive . . . . . . . . . 62
v
Table des figures
1.1 Les partenaires de 3S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Les solutions mise à disposition par 3S . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Fonctionnement d’un Siem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Exemple d’un commun Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Les composants de Wazuh et le flux de données . . . . . . . . . . . . . . . . . . . . . 23

3.2 Architecture Proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Interface login Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Tableau de bord Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Configuration de serveur syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Configuration de Fortigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Logs reçus de Fortigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Exemple d’un log provenant de Fortigate . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.9 Exemple d’un log provenant d’un switch . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.10 Installation de l’agent wazuh sur Windows . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11 Les logs reçus de la machine Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.12 Installation de l’agent wazuh sur Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.13 Les logs reçus de la machine Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.14 Installation de l’agent wazuh sur Centos . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.15 Les logs reçus de la machine Centos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.16 MISP Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.17 Configuration des paramères MISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.18 Ajout d’un utilisateur dans MISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.19 Configurations de The Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.20 Interface utilisateur de The Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.21 Interface utilisateur de Cortex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.22 Génération de clé de Cortex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.23 Création d’un utilisateur dans Cortex . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.24 Création d’une organisation dans Cortex . . . . . . . . . . . . . . . . . . . . . . . . . 35
vi
3.25 Installation des analyseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.26 Configuration dans /etc/cortex/application.conf . . . . . . . . . . . . . . . . . . . . . 36
3.27 Création d’organisation dans The Hive . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.28 Création des utilisateurs dans The Hive . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.29 Installation du module Python de The Hive . . . . . . . . . . . . . . . . . . . . . . . 37
3.30 Les commandes d’autorisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.31 Modification de fichier /var/ossec/etc/ossec.conf . . . . . . . . . . . . . . . . . . . . 38
3.32 Wazuh-alerte dans the Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.33 MISP configuration dans thehive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.34 Intégration Mips et The Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.35 Intégration Cortex et The Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Les ports ouverts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Attaque brute force . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Détection d’une attaque Brute force par wazuh . . . . . . . . . . . . . . . . . . . . . 43
4.4 Manipulation d’un fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Alerte FIM dans Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6 Les règles d’audit ajoutées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7 Modification du fichier "/var/ossec/etc/ossec.conf" pour l’audit . . . . . . . . . . . . 44
4.8 Règle d’audit pour la détection des commandes suspectes . . . . . . . . . . . . . . . 45
4.9 Détection d’une commande malveillante . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.10 Configuration d’OSSEC : Surveillance de la liste des processus système . . . . . . . 46
4.11 Rôle ajouté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.12 Alerte d’un processus non autorisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.13 Attaque de processus caché lancée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.14 Alerte d’un processus caché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.15 Attaque SQL Injection lancé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.16 Alerte d’une attaque SQl Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.17 Fichier binaire suspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.18 Alerte d’un fichier binaires suspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.20 Attaque shellshok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.21 Alerte shellshock detectée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
vii
Table des figures
Annexe 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
viii
Liste des tableaux
2.1 Tableau comparatif des SIEMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
ix
Liste des abréviations
— 3S = Standard Sharing Software
— API = Application Progrmmaing Interface
— CERT = Computer Emergency Response Team
— CQLSH = Cassanda Query Language SHell
— CSIRT = Computer Security Incident Response Teams
— DNS = Domain Name System
— EMC = Electric Membership Corporation
— FIM = File Integrity Monitoring
— IAM = Identity and Access Management
— IBM = International Business Machines
— IDMEF = Intrusion Detection Message Exchange Format
— IDS = Intrusion Detection System
— IETF = Internet Engineering Taske Force
— IOC = Indicator Of Compromise
— IODEF = Incident Object Description and Exchange Format
— IPS = Intrusion Prevention System
— IPTV = Internet Protocol Television
— ISO = International Standardization Organization
— IT = Information Technology
— MISP = Malware Information Sharing Platform
— NOSQL = No Only SQL
— OSSEC = Open Source Security
— OSSIM = Open Source Security Information Management
— RFC = Request For Comment
— SEM = Security Event Manager
x
— SI = Systeme d’Information
— SIEM = Security Information Event Managment
— SIM = Security Information Manager
— SMS = Short Message Service
— SOAR = Security Orchestration Automation Response
— SSH = Secure SHell
— UDP = User Datagram Protocol
— URL = Uniform Resource Locator
— USM = Unified Security Management
— USM = Unified Security Management
— XDR = Extended Detection and Response
— XML = EXtensible Markup Language
— YAML = Yet Another Markup Language
xi
Introduction générale
Aujourd’hui, les organisations font face à un défi majeuraen matière de sécurité de l’information,
en raison de la multiplication des cybers attaques qui deviennent de plus en plus sophistiquées
etafréquentes. Ces attaques représentent une menace pour la confidentialité, l’intégrité et la disponibilité
des données. Dans ce contexte, il est crucial pour les organisations de mettre en place une solution
de gestion des événements de sécurité et des informations (SIEM)bafin de détecter et prévenir les
incidents de sécurité. Ce rapport de projet de fin d’études se concentre sur la mise en œuvre d’une
solution SIEM basée sur la plateforme Wazuh.
Pour répondre aux différents besoins du projet, il est essentiel de comprendre en profondeur
tous les aspects, notamment ;
• Il est impératif d’évaluercles exigences de sécurité de l’organisation et d’identifier d’éventuelles
failles existantes.
• Il convient d’effectuer une analyse approfondie des fonctionnalités et des capacités de la
solution SIEM Wazuh.
• Une architecture de solution adaptée aux besoins spécifiquesdde l’organisation doit être
élaborée.
• L’installation, la configuration et l’intégration des différents composants de Wazuh doivent
être réalisées.
• Des tests et des vérifications doivent être effectués pour garantir l’efficacité de la solution.
Ce rapport est organisé en plusieurs sections. Le premier chapitre présente une introduction
générale au projet, en exposant le contexte et les objectifs. Le deuxième chapitre explore différents
aspects théoriques essentiels pour comprendre les techniques utilisées dans la réalisation du projet.
Le troisième chapitre se concentre sur Wazuh, en décrivant ses différents composants et en fournissant
une explication détaillée de l’architecture de la solution SIEM basée sur cette plateforme. Il présente
ensuite la mise en pratique de la solution, y compris l’installation et la configuration de Wazuh, ainsi
que l’utilisation de ses outils tiers.
Le quatrième chapitre du rapport est consacré aux tests réalisés dans le cadre du projet.
Il analyse et évalue les résultats obtenus à travers ces tests, mettant en évidence les performances,
l’efficacité et la conformité de la solution SIEM mise en œuvre.
Enfin, nous concluons ce rapport par un résumé du travail accompli.
1
Chapitre 1
Contexte général du projet
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1 Présentation générale de l’organisme d’accueil . . . . . . . . . . . . . . . 3
2 Cadre générale du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Étude préalable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapitre 1. Contexte général du projet
Introduction
Nous débutons cette première section en présentant l’organisme qui accueille notre projet,
ainsi que le contexte dans lequel il s’inscrit. Ensuite, nous aborderons l’étude préliminaire, une étape
essentielle dans le processus de développement de notre projet, qui sera examiné en détail.
1.1 Organisme d’accueil
3S Standard Sharing Software est une solution logicielle complètefconçue pour faciliter la
gestion et le partage efficace des données. Dotée de fonctionnalités avancées telles que la gestion
de versions, la traçabilité des modifications et la sécurité des données, cette solution garantit une
utilisation optimale. Les services inclus dans 3S englobentgla gestion de projets, la gestion documentaire,
la gestion des tâches, la gestion des contacts et des services de reporting ainsi que de suivi de l’activité.
Ces services permettent aux utilisateurs de collaborer aisément et de gérer leurs projets et tâches en
toute fluidité [1].
1.1.1 Présentation de 3S Standard Sharing Software
3S est une entreprise qui se spécialise dans l’intégration de services et d’infrastructures

informatiques, et elle exerce principalement ses activités en Tunisie et dans la région de l’Afrique du
Nord. Son principal domaine d’expertise repose sur trois activités principales : le développement de
logiciels, l’intégration de systèmes et l’intégration de réseaux.En plus de ces activités, 3S proposent
également des formations axées sur les nouvelles techniques émergentes telles que les réseaux mobiles,
les logiciels de transaction, les centres d’appels et le commerce électronique. Ces formations permettent
aux clients de se familiariser avec les dernières avancées technologiques et de développer leurs
compétences dans ces domaines en constante évolution [1].
Elle emploie 550kprofessionnels qualifiés, dont 2/3 sont des ingénieurs et techniciens certifiés,
et génère un chiffre d’affaires annuel de 120 millions de dinars. 3S est considérée comme un précurseur
dans le domaine de la technique de l’avenir et elle est reconnue pour son engagement envers la qualité
pour ses clients. En 2019, elle a reçu deux certifications internationales de qualité pour ses systèmes
de gestion, à savoir l’ISO 9001 pour la qualité et l’ISO 27001gpour la sécurité de l’information, ce
qui en fait le premier intégrateur IT en Tunisie à recevoir cette certification [1].
Forte de plus de 34 ans d’expérience, 3S s’engage à rester à la pointe de l’innovation et à
3
anticiper les tendances futures. L’entreprise joue un rôle clé dans le secteur en offrant des solutions
technologiques avancées et adaptées aux besoins spécifiques de ses clients. Elle a crée sa filiale
GlobalNet en 1997, qui a prospéré en tant que fournisseur d’accès Internet. En 2007, elle a établi
un partenariat avec Cisco Systems, consolidant ainsi sa position en tant qu’acteur majeur dans le
domaine des réseaux informatiques. En plus de Global Net, 3S détiennent d’autres filiales opérant
dans le secteur informatique.[1].
La figure 1.1 met en évidence les partenariats stratégiques établis par le groupe 3S avec
des acteurs mondialement reconnus tels que Cisco, Microsoft, IBM, Vmware,pdell EMC, Fortinet et
EMC, au fur et à mesure de son extension.[1].
Figure 1.1 : Les partenaires de 3S
1.1.2 Services offerts par 3S
3S est une entreprise spécialisée dans les domaines des solutions informatiques et des Cleantech.
Avec son expertise, elle est capable de gérer toutes les étapes de votre projet, en prenant en charge à
la fois les infrastructures réseau et les applications. Son objectif principal est de réaliser vos objectifs
commerciaux et d’améliorer la performance de votre entreprise.
En proposant une large gamme de solutions à forte valeur ajoutée et des services de haute
qualité, 3S s’engage à renforcer constamment les compétences de son personnel. De plus, l’entreprise
est en mesure de fournir des solutions innovantes et flexibles pour répondre à vos besoins.
La figure 1.2 met en évidence la diversité des services proposés par 3S, qui couvrent différents
domaines tels que le Cloud Computing,gles datacenters, la collaboration et la communication unifiée,
le stockage et la sauvegarde, la mobilité, la cybersécurité, la vidéosurveillance, l’infrastructure d’entreprise,
l’affichage dynamique et l’IP TV. [1].
4
Figure 1.2 : Les solutions mise à disposition par 3S
1.2 Cadre générale du projet
Avec les progrès rapides des techniques et des réseaux de communication, la sécurité informatique
est devenue une base fondamentale pour les entreprises. Assurer une utilisation adéquatekdes ressources
de l’entreprise afin de protéger son système d’information est essentiel. Les attaques informatiques
peuvent engendrer des conséquences financières, nuire à la réputation,de plus qu’entrainer des
problèmes de confidentialité et de conformité réglementaire. Les acteurs malveillants peuvent exploiter
les failles de sécurité pour accéder aux systèmes d’information de l’entreprise, voler des données
sensibles, voire paralyser entièrement les opérations de l’entreprise. Les exigences de sécurité avancées
nécessitent l’utilisation de solutions telles que les systèmes de gestion des événements et des informations
de sécurité (SIEM). Ces solutions permettent de surveiller activement les systèmes et les réseaux,
en précisant les menaces potentielles avant qu’elles ne deviennent des problèmes extrême. Les outils
SIEM offrent une visibilité en temps réel sur les événements de sécurité, aidant ainsi les entreprises
à diminuer les risques et à se conformer aux réglementations en matière de sécurité.
En résumé, l’adoption d’un SIEM peut aider les entreprises à protéger leurs systèmes d’information
et à éviter les pertes potentielles causées par des attaques malveillantes.
1.3 Étude préalable
Dans cette étude, il est prévu d’évaluer les éléments existants avec un regardgcritique dans le
but d’identifier des opportunités d’amélioration pourgle projet. Les solutions choisies seront ensuite
présentées de manière concise.
1.3.1 Etude de l’existant
Précédemment, 3S avait choisi IBM QRadar comme solution SIEM pour garantir la sécurité
de son système d’information. Récemment, sa licence n’a pas été renouvelée, ce qui entraîne divers
5
problèmes.
Tout d’abord, cette situation a pour conséquences des risques pour la sécurité,puisque l’absence
d’une solution SIEM adéquate expose l’entreprise à d’éventuelles attaques ou violations de la sécurité.
En revanche, les dispositions exigent souvent l’utilisation d’une solution de sécurité spécifique, ce
qui peut entraîner des problèmes de conformité si IBM QRadar n’est pas en place.
En outre, cette situation amène une perte de visibilité et d’efficacité dans la gestion de la
sécurité des systèmes d’information de l’entreprise. Sans une solution SIEM opérationnelle, il devient
plus difficile de deviner et de gérer les incidents de sécurité, compromettant ainsi la protection des
données et la réactivité face aux menaces potentielles.
Les opérations commerciales d’une entreprise peuvent également subir des effets néfastes,
ce qui peut provoquer un préjudice potentiel pour sa réputation. De ce fait, il est crucial pour les
entreprises de sélectionner un système de sécurité performant et de veiller à son entretien régulier
afin d’assurer la protection de leur système d’information.
1.3.2 Critiques de l’existant
IBM QRadar est une solution de gestion de la sécurité des informations et des événements
(SIEM) largement reconnue pour ses performances. Cependant, malgré ses avantages, elle présente
certaines limites. Tout d’abord, le coût élevé de cette solution peut constituer un frein à songadoption
pour certaines organisations. De plus, l’installation et la configuration d’IBM QRadar peuvent
être complexes, nécessitant une expertisegtechnique considérable. Son utilisation requiert également
des compétences approfondies en matière de sécurité et d’analyse de données, ce qui en limite
l’incorporation par les petites entreprises. Par ailleurs, pour fonctionner de manière optimale, IBM
QRadar demande une infrastructure matérielle et logicielle robuste, ce qui peut poser des difficultés
pour les organisations disposant de ressources limitées.
IBM QRadar peut nécessiter un espace de stockage considérable en raison de la grandekquantité
de données collectées. De plus, son interface utilisateur peut être complexe et peu conviviale pour les
utilisateurs non techniques. Il est essentiel de souligner que les limitations de l’outil peuvent varier
en fonction des besoins et des exigences spécifiques de chaque organisation.
6
1.4 Solution
Nous avons choisi d’implémenter la solution SIEM Wazuh en raison de sa capacité à adopter
une approche de sécurité holistiquezqui repose sur l’analyse de données. Cette approche nous permet
de détecter les menaces avancées de manière plus rapide et plus efficace. De plus, WAZUH offre
une gestion centralisée des journaux, ce qui facilite la surveillance, l’analyse et lamcorrélation
des événements de sécurité, même dans un environnement multiplate-forme. Sa flexibilité et sa
modularité nous permettent également de personnaliser la solution et de l’intégrer facilement avec
d’autres outils de sécurité.
De plus, la communauté dynamique de Wazuh offre un soutien constant aux utilisateurs, que
ce soit en termes d’aide pratique, de notifications en temps réel ou de documentation collaborative.
Conclusion
Ce chapitre vise à comprendre les attentes et les exigences du client, ce qui est indispensable
pour proposer une solution qui répond à ses besoins. Les informations collectées sur les préférences
et les contraintes du client ont permis de définir les priorités et de hiérarchiser les fonctionnalités
de la solution en fonction de leur importance. Ainsi, ce chapitre établit les bases solides nécessaires
pour la poursuite du travail et contribue au développement d’un projet couronné de succès.
7
Chapitre 2
Etat d’art sur les SIEMs
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1 Protection des données et des systèmes informatiques contre les menaces

et les attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Security Information and Event Management (SIEM) . . . . . . . . . . 11
3 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Produits SIEM sur le marché . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapitre 2. Etat d’art sur les SIEMs
Introduction
Ce chapitre traite des notions générales relatives à la sécurité informatique. Par la suite, nous
examinerons de manière approfondie le système de gestion des informations et des événements de
sécurité (SIEM), en détaillant sa nature et ses objectifs. Nous mettrons l’accent sur l’importance
vitale des journaux d’événements dans la détection des incidents de sécurité. Enfin, nous terminerons
avec une analyse comparative approfondie des divers produits SIEM actuellement disponibles sur le
marché.
2.1 Protection des données et des systèmes informatiques contre

les menaces et les attaques
De nos jours, la sécurité des systèmes informatiques représente une préoccupationlessentielle

pour toutes les organisations. Assurer la confidentialité, l’intégrité et la disponibilité des informations
stockées sur ces systèmes est primordial, tout en les protégeant contre les attaques. Afin de répondre
à ces défis, diverses solutions de sécurité informatique, telles que le SIEM (Security Information
andlEvent Management), ont été développées [2].
2.1.1 Présentation des services de sécurité
Les principes fondamentaux de la sécurité des systèmes d’information sont les suivants :
• Authentification : il s’agit d’un processus permettant de vérifier l’identitéld’un utilisateur
afin de confirmer qu’il est bien la personne qu’il prétend être.
• Confidentialité : seule une personne autorisée peut accéder aux informations, garantissantxainsi
leur protection contre les accès non autorisés.
• Intégrité : il s’agit d’assurer que lespinformations reçues sont identiques.
• Disponibilité : les services et les informations de l’entreprise doiventbêtre accessibles et
fonctionnels lorsque cela est nécessaire.
• Non-répudiation : aucune entité ne peut nier avoir envoyé ou reçu untmessage lors d’un
échange.
9
2.1.2 Mesures de sécurité pour prévenir les attaques
Diverses stratégies sont mises en place pour minimiser les attaques de sécurité, certaines
reposant sur des mesures techniques, tandis que d’autres nécessitent la participation active des
employés.
2.1.2.1 Sensibilisation des Employés
La prise de conscience des employés joue un rôle capital dans la prévention des cyberattaques.
Il est primordial d’établir un programme de formation en sécurité informatique afin de former les
employés et de les sensibiliser aux risques liés à la sécurité informatique.
Ce programme peut englober diverses mesures telles que des sessions de formation régulières,
des simulations d’attaqueszpour mieux comprendre le processus d’attaque, l’établissement de politiques
de sécurité pourzétablir des règles à suivre, des exercices interactifs de sensibilisation pour aborder
les risques, ainsi que des rappels réguliers pour maintenir une sensibilisationsconstante. En formant
et en informant régulièrement les employés, l’entreprise peut renforcer sa protection contre les
cyberattaques, car ces employés constituent souvent la première ligne de défense.
En sensibilisant les employés aux risques de sécurité, l’entreprise peut améliorer sa capacité
à se prémunir contre les potentielles cyberattaques [3].
2.1.2.2 Solutions techniques pour surveiller et gérer la sécurité
Il existe différentes options techniques disponibles pour assurer la surveillance et la gestion

de la sécurité des systèmes informatiques. Parmi ces options figurent des logiciels de détectionzde
menaces, des pare-feu, des systèmes de surveillance en temps réel, des outils de gestion d’identité et
d’accès, des systèmes dezcryptage et de sauvegarde de données, ainsi que des solutions de sécurité
réseau.Toutefois, il est important de mettre en évidence le rôle central joué par le système de gestion
des informations et des événements de sécurité (SIEM). Ce dernier joue une mission principale en
rassemblant, analysant et corrélantzdes données provenant de différentes sources afin de détecter les
menaces de sécurité et les incidents [4].
En résumé, le SIEM occupe une fonction capitale en matière de surveillance et de gestion de
la sécurité des systèmes informatiques.
10
2.2 Security Information and Event Management (SIEM)
Les premiers outils SIEM ont apparu vers la fin des années 1990 dans le but d’aider les
entreprises à surveiller et à gérer la sécurité de leurs réseaux et systèmes à partir d’une plateforme
unifiée. À l’origine développés principalement pour les grandes entreprises, leur installation et leur
maintenance étaient souvent coûteuses. Les SIEM, également connus sous le nom de Systèmes de
gestion des événements et des informations de Sécurité, sont des solutions centralisées qui permettent
une vue d’ensemble de l’activité du réseau et facilitent une réponse en temps réel aux menaces de
sécurité. Ils collectent, interprètent et classifient les données provenant de différentes sources, puis
les analysent afin de fournir des informations exploitables [5].
2.2.1 Différence entre SIEM, SEM, SIM
Le SIEM est une combinaisonldu SIM (Security Information Manager) et du SEM (Security
Event Manager), regroupant ainsi leurs fonctionnalités respectives. Bien que le SEM et le SIM
puissent paraître similaires dans leurs rôles, ils possèdent chacun des caractéristiques distinctes.
Le SEM est capablekd’analyser de multiples événements et de détecter les menaces en temps
réel. Sa tâche principale est de corréler les événements en temps réel et de générer des alertes.
En revanche, le SIMoest responsable de la gestion de la traçabilité, de l’indexation et du
stockage d’un grand volume de données brutes. Il fournit ainsi des fonctionnalités d’indexation et
de recherche pour les analystes et les experts en investigation numérique [6].
2.2.2 Rôle d’un Siem
Les cibles d’un système SIEM sont variés et englobent plusieurs aspects tels que la détection
et la réponse en temps réel aux menaces de sécurité, la garantie de la conformité réglementaire et
le renforcement global de la sécurité de l’entreprise. Le rôle essentiel du système SIEM consiste à
identifier et à classifier les incidents et les événements de sécurité au sein du système informatique de
l’entreprise, puis à les analyser pour repérer les menaces potentielles. Il se concentre principalement
sur deux objectifs clés, à savoir la génération de rapports et l’émission d’alertes.
D’un côté, il génère des rapports détaillés fournissant des informations sur les événements
et les incidents de sécurité survenus dans le système. Ces rapports peuvent contenir des détailscque
les tentatives de connexion réussies ou échouées, les essais d’authentification, les vulnérabilités du
système et d’autres activitésmsuspectes. Ces rapports sont précieux pour surveiller les activités de
11
sécurité, identifier les tendances et les anomalies, ainsi que pour informer les responsables de la
sécurité des événements importants [7].
D’un autre côté, le système SIEM a été spécifiquement conçu pour notifier dès qu’une menace
potentielle ou une violation de sécurité est détectée. Ces notifications sont déclenchées selon des
règles prédéfinies quiwsurveillent les événements et les incidents de sécurité critiques. Lorsque le
système SIEM identifie une activité qui enfreintpces règles, il génère une notification qui est ensuite
transmise aux équipes de sécurité afin qu’elles puissent réagir rapidement. Les notifications peuvent
être envoyées par e-mail, SMS ou via une interface utilisateur dédiée du système SIEM [7].
2.2.3 Mode de fonctionnement du SIEM :
Malgré les variations possibles en termes d’interface utilisateur, de fonctionnalités ou de

méthodes de collecte de données, les fonctionnalités essentielles des marques de SIEM restent généralement
constantes.
2.2.3.1 La collecte
Le système SIEM collecte des données de sécurité provenant de différentes sources telles que
les journaux d’audit, les pare-feu, les systèmes de détection d’intrusion (IDS/IPS), les systèmes de
gestion des identités et des accès (IAM) ainsi que les équipements de surveillance réseau La collecte
de données peut être réalisée de manière passive ou active. Dans le premier cas, elle consiste à écouter
le réseau pour recueillir des informations. Dans le second cas, elle implique le déploiement d’agents
directement sur les équipements ou à distance [8].
Lorsqu’elle est active, la collecte de données est effectuée par le biais d’agents installés sur
les équipements surveillés, qui permettent de recueillir des informations provenant des équipements
et des logiciels de sécurité. Ces informations sont ensuiteztransmises au système de gestion des
informations et des événements de sécurité (SIEM). Certains éléments de sécurité sont spécifiquement
conçus pour être intégrés nativement au SIEM, et ils sont nommés sondes [8].
En mode passif, le SIEM est connecté directementmaux équipements à surveiller. Dans ce
cas, les équipements ou les logiciels envoient activement les informations collectées au SIEM [8].
2.2.3.2 La Normalisation
La normalisation des données recueillies à partir de différents équipements et logiciels est une
étape fondamentale visant à simplifier leur traitement par un système de gestion des informations et
12
des événements de sécurité (SIEM). Ces données proviennent souvent de sources diverses, chacune
utilisant son propre format de données. L’objectif de la normalisation consiste à les rendre homogènes
en les convertissant dans un format standardisé. Il est important de conserver les données brutes
intactes, sans les altérer, afin de préserver leur validité juridique pour faciliter l’échange et le
traitement des informations de sécurité, des formats normalisés ont été développés. Parmi ces
formats, on peut citer : [8]
IDMEF (Intrusion Detection Message Exchange Format) : Établie dans la RFC 4765, cette
norme a pour objectif de favoriser l’interopérabilité entre différents systèmes de détectionmd’intrusion,
qu’ils soient commerciaux, open source ou de recherche. En utilisant le langage XML (Extensible
Markup Language), l’IDMEFmdéfinit un format pour les événements et les alertes de sécurité. Il est
conçu pour permettre le stockage en base de données, l’affichage et la gestion des informations liées
à la sécurité [8].
IODEFm(Incident Object Description and Exchange Format) : Décrit dans la RFC 5070, ce
standard est utilisé pour l’échange d’informations sur les incidents de sécurité entre les équipesmCSIRT
(Computer Security Incident Response Teams). Basé sur le format XML, l’IODEF permet la transmission
d’incidents de sécurité entre différents domaines administratifs et les parties responsables de la
gestionmopérationnelle. Ce modèle de données encode des informations concernant les hôtes, les
réseaux et les services impliqués [8].
2.2.3.3 Agrégation
La première étape du processus de traitement des événements de sécurité consiste en l’agrégation,

qui implique le regroupement des événements en fonction de critères prédéterminés. Ces critères sont
établis à l’aide de règles d’agrégation et sont appliqués aux événements qui présentent desmsimilarités.
Différentes règles de filtrage peuvent être employées à cette étape. Une fois que les critères sont
définis, les événements sont rassemblés en fonction des paramètres spécifiés par la solution SIEM,
puis transmis au moteur de corrélation pour une analyse plus approfondie [8].
2.2.3.4 Corrélation
Le SIEM applique des algorithmes sophistiqués pendant la phase de corrélation afin d’analyser
les données collectées et détecter les comportementsmmalveillants, les vulnérabilités de sécurité, les
attaques en cours et les menaces potentielles. Cette analyse permet d’identifier des motifs d’activités
suspectes qui pourraient indiquer une intrusion ou unemtentative d’attaque contre les réseaux et les
13
systèmes de l’entreprise [8].
2.2.3.5 Gestion des Alertes
Les systèmes SIEM sont chargés de gérerpen temps réel les alertes, afin de notifier les équipes
de sécurité lorsqu’un événement critique nécessite une intervention immédiate. Ces alertes peuvent
être transmises via différents moyens de communication tels que les e-mails, les SMS, etc. Les
SIEMmoffrent plusieurs méthodes pour gérer les alertes, qui peuvent être utilisées simultanément.
Parmi ces méthodes, il y a le reporting, qui génère des rapports synthétiques et des statistiques
sur les intrusions, les vulnérabilitésmexploitées et la classification des attaques. De plus, les alertes,
les incidents et les rapports sont stockés dans des bases de données pour permettre une analyse
ultérieure par les moteurs de corrélation [8].
En outre, il est essentiel que le SIEM intègre des fonctionnalités de réponse aux alertes,
permettant ainsi de prendre des mesures automatiques pour stopper une attaque ou en réduire les
conséquences. Il convient de souligner l’importance de planifier attentivement la réponse aux alertes
dans le cadre d’une stratégie globale de sécurité de l’entreprise et de la coordonner avec les équipes
de sécurité et les responsables opérationnels.
La figure 2.1 présente une illustration simplifiée du mode de fonctionnement du SIEM [9].
Figure 2.1 : Fonctionnement d’un Siem
14
2.3 Logs
Les fichiers logs jouent un rôle essentiel dans les systèmes SIEM en tant qu’élément fondamental.
Ils sont produits par divers systèmes informatiques et applications, tels que les logs d’authentification,
d’accès, de trafic, etc. Chaque type de log possède son propre format. L’objectif principal d’un SIEM
est de recueillir ces logs, de les normaliser selon un format standardisé, puis d’extraire les informations
pertinentes pour générer des rapports, des tableaux de bord et des alertes destinés aux utilisateurs.
Pour accomplir cette tâche, les SIEM utilisent des algorithmes avancés qui analysent ces logs afin
de détecter les anomalies et les comportements suspects.
2.3.1 Définition d’un Log
La journalisation consiste à consigner de manière séquentielle tous les événements liés à un

processus spécifique, qu’il s’agisse d’une application ou d’une activité sur un réseau informatique.
Ces événements sont enregistrés dans un fichier ou une base de données, communément appelés
journaux ou logs en anglais. Les journaux sont généralement organisés selon l’ordre chronologique
et renferment des informations datées sur l’activité interne du processus, ainsi que ses interactions
avec l’environnement. Ils permettent ainsi une analyse approfondie et étape par étape de l’évolution
du processus [10].
2.3.2 Format d’un log
Un journal suit une structure prédéfinie qui dicte la manière dont les informations doivent
être enregistrées. Le format d’un journal peut différer en fonction du système ou de l’application qui
génère les journaux, mais la plupart des formats de journaux suivent une structure de base. Ce format,
souvent appelé "format de journal commun" (COMMON Log format), comprend généralement des
informations telles que [11] :
"%h %l %u %t "%r" %>s %b"
Les champs du log sont les suivants :
— %h : L’adresse IP du client demandeur ou son nom DNS.
— %l : Le nom du log distant, si le champ n’est pas présent, il est remplacé par un tiret.
— %u : Le nom de l’utilisateur distant, si le champ n’est pas présent, il est remplacé par un tiret .
— %t : Le temps de l’événement sous le format DD/Mon/YYYY :hh :mm :ss.
15
— "%r" : L’URL de la requête envoyée.
— %>s : Le code d’état retourné par le serveur.
— %b : Le nombre de bytes envoyés.
La figure 2.2 montre un exemple de fichier Log [11].
Figure 2.2 : Exemple d’un commun Log
2.4 Produits SIEM sur le marché
Les SIEM open source se distinguent par leurmflexibilité et leur capacité à s’adapter à divers
besoins grâce à leur conceptionmouverte, permettant aux utilisateurs de modifier et de partager
librement le code et les outils. Voici ci-dessous une sélection de SIEM open source ainsi que des
solutions commerciales.
2.4.1 Produits SIEM open source
2.4.1.1 OSSIM
AlienVault OSSIM est une solution de gestion des informations et des événements de sécurité
(SIEM) en open source qui effectue la surveillance des dispositifs, collecte les journaux et assure
la normalisation et la corrélation des événements. Il offre une variété de fonctionnalités pour la
surveillance de la sécurité, la collecte de journaux classifiés, ainsi que l’identification et la résolution
des incidents majeurs en mettant l’accent sur les journaux problématiques. De plus, AlienVault
OSSIM est conforme aux exigences de surveillance de la sécurité, d’audit et de conformité concernant
la conservation des journaux [12].
2.4.1.2 Graylog
Graylog est une solution de premier plan pour la gestion centralisée des journaux. Elle offre
des fonctionnalités avancées de capture, stockage et analyse en temps réel des journaux. Conçue
spécifiquement pour répondre aux besoins de l’analyse de journaux modernes, Graylog simplifie
l’exploration des données, les audits de conformité et la détection des menaces. Elle permet de
16
rajouter un sens aux données et de réagir rapidement, ce qui en fait un choix idéal pour les entreprises
cherchant à collecter et à normaliser de manière transparente des données provenant de différentes
sources, avec une analyse plus rapide via une interface conviviale [13].
2.4.1.3 WAZUH
Wazuh est une solution open source de gestion de la sécurité qui propose une variété de
fonctionnalités pour surveiller, détecter, répondre et prévenir les menaces de sécurité dans les environnements
informatiques. Elle recueille et analyse les journaux système, les événements de sécurité et les alertes
générées par les outils de sécurité afin d’identifier en temps réel les comportements et les menaces
suspects. De plus, Wazuh facilite la gestion des vulnérabilités, la réponse aux incidents de sécurité
et la conformité réglementaire [14].
2.4.2 Produits SIEM commerciaux
2.4.2.1 Splunk
Splunk est une plateforme qui simplifie la gestion de la sécurité et de l’information en

rassemblant, connectant et analysant des données de sécurité provenant de diverses sources. Elle
permet également la création de tableaux de bord et de rapportsmpersonnalisés pour une visualisation
optimale des données de sécurité [15].
2.4.2.2 Ibm Qradar
Ibm Qradar estmune plateforme d’analyse de réseau qui détecte les vulnérabilités dans vos
applications, systèmes et périphériques. Elle vous permet d’identifier les failles présentes dans votre
réseau ou zone démilitarisée [16].
2.4.2.3 USM
Unified Security Management est une solution de sécurité complète qui intègre des outils
essentiels tels que la gestion des journaux, la détection d’intrusions, la gestion des vulnérabilités et
la corrélation des événements. Son but est d’améliorer lamdétection et la réaction des organisations
face aux menaces de sécurité. En combinant plusieurs outilsmde sécurité, cette plateforme offre une
approche globale pour répondre aux exigences de sécurité [17].
17
2.4.3 Comparaison des solutions disponibles sur le marché
Tableau 2.1 : Tableau comparatif des SIEMs

Gestion de
Siem Plate-forme SE Déploiement Prix
vulnérabilités
Ossim utilise
des scanners de
vulnérabilités tels
que OpenVAS
Linux, FreeBSD, Gratuit et open
Ossim Sur site pour analyser les
OpenBSD et NetBSD source
hôtes du réseau
et signaler les
vulnérabilités
détectées.
La version
Il offre plusieurs
communautaire
fonctionnalités
est gratuite, la
Linux, Mac OS et pour aider à gérer
Graylog Sur Site et Saas version entreprise
Windows les vulnérabilités
commence à
et les risques de
partir de 1500
sécurité.
dollars par an
Grâce à
La version
Linux, Windows et Mac son module
Wazuh Sur Site et Saas communautaire
OS "Vulnerability
est gratuite
Detection”
Les prix
Linux, Windows et Mac commencent à
Splunk Sur Site et Saas Non
OS partir de 1500
dollars par an
IBM inclut un
Red Hat Enterprise Les prix
scanner qui
Ibm Linux, SUSE Linux commencent à
Sur Site et Saas peut explorer
Qradar Enterprise Server et partir de 10 000
activement les
AIX (Power Systems) dollars par an
hôtes.
USM intègre
les technologies Les prix
Windows, Linux et Mac de détection de commencent à
USM Sur Site et Saas
OS X vulnérabilité partir de 2250
(Nessus, dollars par an
Openvas..)
18
Après une analyse approfondie des besoins de l’entreprise 3S, les cinq exigences suivantes ont
été identifiées :
1. Supervision en temps réel du fonctionnement du système d’information (SI) et du trafic

réseau.
2. Archivage centralisé des événements survenant et corrélation de ces événements.
3. Génération d’alertes en cas d’incidents de sécurité et production de rapports.
4. Tableau de bord fournissant des informations consolidées pour une surveillance en temps
réel de l’environnement de l’entreprise.
5. Réduction des coûts.
Après avoir examiné les options de gestion de l’information et des événementsmde sécurité
(SIEM) disponibles, il est clair que Splunk, QRadar et USM conviennent aux grandes entreprises avec
des opérations complexes et une grandemquantité de journaux. Cependant, ces solutions peuvent être
coûteuses et offrir unempersonnalisation limitée pour les petites et moyennes entreprises. D’un autre
côté, Graylog manque de fonctionnalités dans sa version open source et la communauté OSSIMmest
limitée, ce qui peut rendre la résolution des problèmes difficile.
En revanche, Wazuhmrépond mieux aux besoins des entreprises en offrant une gestion efficace
des vulnérabilités, une intégration avecmd’autres outils et une personnalisation facile. De plus,
Wazuh est plus abordable pour les petites et moyennes entreprises. Par conséquent, nous avons
conclu que Wazuh était la solution la plus appropriée.
Conclusion
Ce chapitre traite de la protection des données et des systèmes informatiques contre les
menaces et les attaques. Nous examinerons le système de gestion des informations et des événements
de sécurité (SIEM) pour comprendre sa nature et ses objectifs. Nous soulignerons également l’importance
des journaux d’événements dans la détection des incidents de sécurité. Enfin, nous effectuerons une
analyse comparative des produits SIEM disponibles sur le marché pour parvenir à une conclusion.
19
Chapitre 3
Etude de la solution WAZUH
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1 Présentation de la plateforme WAZUH . . . . . . . . . . . . . . . . . . . 21
2 Composantes de WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Mise en place de WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Intégration des outils tiers à WAZUH . . . . . . . . . . . . . . . . . . . . 31
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapitre 3. Etude de la solution WAZUH
Introduction
Le but de ce chapitre est d’introduire la plateforme Wazuh, en décrivant ses différentes

composantes, l’environnement de travail associé, et les étapes nécessaires pour mettre en œuvre
WAZUH et intégrer des outils externes à cette plateforme.
3.1 Présentation de la plateforme WAZUH
OSSECyest un système de détection d’intrusion qui surveille les fichiers système, les journaux
et les événements pour repérer les attaques contreyles systèmes informatiques. Wazuh, basé sur
OSSEC, propose des fonctionnalités clés telles que la corrélationydes événements pour obtenir une
vue globale des menaces, la surveillance des fichiers pour détecter les modifications, l’analyse des
vulnérabilitésypour identifier les failles connues, et la détection des logiciels malveillants pour repérer
les menaces nuisibles aux systèmes [18].
Wazuh offreyune grande flexibilité et une personnalisation adaptée aux besoins spécifiques
des organisations. Elle surveille divers environnements comme les serveurs, les postes de travail, les
appareils mobiles et les conteneurs. Elle s’intègre facilement à d’autres outils de sécurité, tels que les
systèmes de gestionydes informations de sécurité et les solutions de gestion des événements et des
incidents de sécurité. Cette intégrationypermet d’améliorer la visibilité et la corrélation avancée des
menaces potentielles, offrant ainsi une protection solide pour les organisations [18].
3.2 Composantes de WAZUH
Wazuh est une solution de sécurité complète qui garantit la protection de vos charges de
travail dans les environnements Cloud, les conteneurs et les serveurs. Elle offre une gamme étendue
de fonctionnalités de détection et de réponsey(XDR) ainsi que de gestion des événements et des
informations de sécurité (SIEM).Pour assurer la surveillance des points de terminaison que vous
souhaitez protéger, Wazuhydéploie l’agent Wazuh. Les données collectées par ces agents sont ensuite
centralisées et analysées par le serveur Wazuh afin de repérer d’éventuelles menaces. Wazuhyinclut
également un indexeur qui optimise la recherche et la corrélationydes événements. Enfin, pour
visualiser les informations de sécurité et les alertes, Wazuh met à disposition un tableau de bord
convivial [18].
21
3.2.1 Wazuh indexer
Le Wazuh Indexer joue un rôle essentiel au sein du système en tant que moteur deyrecherche
et d’analyse de texte intégral extrêmement scalable. Il est chargé d’indexer et de stocker les alertes
produites par le serveur Wazuh [18].
3.2.2 Wazuh server
Le serveur Wazuhyanalyse les données des agents pour détecter des indicateurs connus de
compromission et pour tirer parti des informations sur les menaces. Il peut gérer des centaines voire
des milliers d’agentsyet s’étendre horizontalement grâce à des clusters. Il assure également la gestion
des agents, y compris layconfiguration et la mise à niveau à distance [18].
3.2.3 Wazuh dashboard
Le système de sécurité Wazuhypropose un tableau de bord interactif qui permet aux utilisateurs
de visualiser et analyser les données de manière conviviale. Les tableaux de bord prédéfinisgabordent
divers aspects de la sécurité, tels que la surveillance de l’intégrité des fichiers, la détection des
applications vulnérables et la surveillance des événements dans le cloud. En plus de ces fonctionnalités,il
est également utilisé pour gérer la configuration de Wazuh et surveiller son état [18].
3.2.4 Wazuh agents
Les agents Wazuhfoffrent une grande polyvalence en étant compatibles avec différents types
de terminaux, tels que les ordinateurs, les serveurs, les instances cloud et les machines virtuelles. Ils
garantissent unexprotection complète en matière de prévention, détection et réponse aux menaces, et
sont compatibles avec plusieurs systèmes d’exploitation majeurs, tels queyLinux, Windows, macOS,
Solaris, AIX et HP-UX [18].
En plus de sa fonctionnalité de surveillancebdes périphériques à l’aide d’agents, la plateforme
Wazuh est également capable de surveiller desbdispositifs qui ne sont pas équipés d’agents, tels que les
pare-feu, les commutateurs, les routeurs ou les réseauxbIDS. Les données de journalisation système
peuvent être recueillies via Syslog, et la configuration peut être surveillée grâce à des vérifications
périodiques des données, SSH ou unebAPI, parmi d’autres méthodes possibles.
Le schéma illustré dans la Figure 3.1 met en évidence les composants distincts de Wazuh ainsi que
la circulation des données entre ces composants. Selon ce schéma, les informations recueillies par
22
Wazuh sont transmises au module de détection des intrusions, où elles sont examinées pour repérer
toute activité douteuse ou malveillante [18].
Figure 3.1 : Les composants de Wazuh et le flux de données
3.3 Architecture de la solution
Pour accroître l’automatisationbde la réponse du système de gestion desbinformations et

des événements de sécurité (SIEM), nous avons instauré une architecture présentée dans la figure
3.2. Cette architecturebfacilite le transfert des alertes du SIEM vers la plateforme de gestion des
incidents, The Hive, qui sera intégrée à Cortex, ainsi qu’à la plateforme d’analyse des indicateurs de
menaces et d’éléments de veille cybernétique (IOC) MISP.
Figure 3.2 : Architecture Proposée
23
3.4 Environnement de travail
Cette section mettra en évidence l’environnement de travail, qui se compose de deux composantes
distinctes appelées environnement matériel et environnement logiciel.
3.4.1 Environnement matériel
Pour ce projet, il est nécessaire de provisionner deux machines virtuelles sur le serveur de
l’entreprise :
La première machine destinée à Wazuh possède les caractéristiques suivantes :
• système Centos 7 Amd64
• processeur : 4
• mémoire : 8 GO
• espace disque : 50 GO
La deuxième machine est spécifiquement conçue pour l’intégration des outils ayant les caractéristiques
suivantes :
• système : Ubuntu 18.04 LTS
• processeur : 4
• mémoire : 16 GO
• espace disque : 50 GO
3.4.2 Environnement Logiciel
Pour déployer Wazuh, nous avons utilisé les éléments suivants :

• Wazuh-Manager : Le Wazuh Managerbanalyse les données et émet des alertes en
cas de correspondance avec une règle spécifique.
• Wazuh-Agent : Il collecte etbtransmet les journaux au serveur Wazuh.
• Filebeat : Achemine lesbévénements et les alertes vers l’indexeur Wazuh.
Les éléments suivants ont été utilisés pour déployer les outils tiers :
• Elasticsearch : Elasticsearchkest indispensable pour la gestion des indexes de données
dans TheHive et Cortex.
• Cassandra :La caractéristiquebremarquable d’Apache Cassandra, la base de
donnéesgNoSQL utilisée par TheHive, réside dans sa capacité à gérer efficacement
l’expansion des données.
24
• Thehive : TheHive estbune plateforme open

source et évolutive destinée à simplifier la gestion des incidents de sécurité [19].
• Cortex : Cortex esthune plateforme logicielle conçue par TheHive Projet.
Elle est open source . Son objectif estzde permettre l’analyse de divers éléments
observables, tels que les adresses IP, les e-mails, les URL, les noms de domaines, les fichiers
et les hachages [19].
• Misp : est unekplateforme open source de renseignement sur les menaces.
• Docker-compose :Docker Composezfacilite la gestion et le déploiement
d’applicationszconteneurisées grâce à un fichier YAML. En une seule commande, tous les
services nécessaires peuvent êtrezdéployés et initialisés sans effort. Son utilisation
pour l’installation de MISP s’est avérée pratique et efficace [20].
3.5 Mise en place de WAZUH
Dans cette section, nous allons décrirezles étapes de déploiementzde la solution et expliquer
comment utiliser les outils précédemment définis.
3.5.1 Installation et Configuration de WAZUH
Les étapes d’installation de Wazuh sont détaillées dans l’annexe 1.

Une fois que la plateforme est installée, il est possible d’y accéder via un navigateurzen entrant
l’adresse IP 172.29.12.6 pour accéder à l’interface Wazuh, comme illustré dans les figures 3.3 et 3.4.
Figure 3.3 : Interface login Wazuh
25
Figure 3.4 : Tableau de bord Wazuh
3.5.1.1 Collecte des données à partir du firewall Fortigate et des équipements

réseaux
Nous avons apporté des modifications au fichier de configuration /var/ossec/etc/ossec.conf

(figure 3.5) afin d’activer la journalisation à distance via le protocole syslog (UDP, port 514). Nous
avons fixé les adresses IP autorisées à se connecter et à envoyer des journaux à distance aux appareils
réseau tels que le firewall Fortigate, les commutateurs et les routeurs.
Syslogz, qui est inclus dans l’installation de Wazuh, simplifie l’échange de journaux entre
systèmes. Il facilite la surveillancezdes périphériques réseau et des systèmes en capturant de manière
concise des informations essentielles telles que leszhorodatages, les messages d’événements, la gravité,
les adresses IP et les diagnostics. Son objectifzprincipal est de détecter les dysfonctionnements, de
générer des alertes pour les événements préconfigurés et de surveiller les activités suspectes à partir
des journaux de surveillance.
Figure 3.5 : Configuration de serveur syslog
26
Une fois que la machine Centos dédiée au serveur Syslog est installée, nous procédons à
la configuration du pare-feu Fortigate en suivant les instructions fournies dans la figure 3.6. Cette
configuration permet l’envoi de messages Syslog vers la machine Centos en utilisant le port 514.
Figure 3.6 : Configuration de Fortigate
Actuellement, les journaux provenant du pare-feu Fortigate sont reçus conformément aux
schémas 3.7 et 3.8. Pour afficher les journaux du pare-feu Fortigate, il est nécessaire de spécifier
explicitement le nom du fournisseur, qui est Fortinet.
Figure 3.7 : Logs reçus de Fortigate
27
Figure 3.8 : Exemple d’un log provenant de Fortigate
L’équipe réseau estzresponsable de la configuration des équipements réseau. Ci-dessous se

trouve un exemple de journal extrait d’un commutateur, tel qu’illustré dans la figure 3.9.
Figure 3.9 : Exemple d’un log provenant d’un switch
28
3.5.1.2 Collecte des données à partir des machines Windows
L’agent Wazuh a été installé sur une machine Windows comme montré dans la figure 3.10.
L’outil Invoke-WebRequestzest employé afin dezrécupérer le fichier d’installation de l’agent Wazuh
à partir de l’URL donnée. Le fichier MSI ainsi téléchargé est sauvegardé dans le répertoire temporaire
de l’environnement Windows, en utilisant la variable ${env:tmp}, et il est nommé "wazuh-agent.msi".
Enfin ,lancer l’agent avec NET START WazuhSvc.
Après cela, la commande "msiexec.exe" estzexécutée pour procéder à l’installation de l’agent
Wazuh en utilisant le fichier MSI téléchargé précédemment.
Figure 3.10 : Installation de l’agent wazuh sur Windows
Les illustrations dans les figures 3.11 montrent comment les logs de la machine Windows sont
actuellement reçus.
Figure 3.11 : Les logs reçus de la machine Windows
3.5.2 Collecte des données à partir des machines Ubuntu
Les illustrations 3.12 et 3.13 démontrent avec succès comment installer l’agent Wazuh sur
une machine Ubuntu et recevoir les journaux.
Après avoir obtenu le paquet Debian du logiciel Wazuh Agent à partir de l’URL fournie et
l’avoir sauvegardé sous le nom "wazuh-agent.deb" dans le répertoire actuel, nous avons ensuite lancé
l’agent.
29
Figure 3.12 : Installation de l’agent wazuh sur Ubuntu
Figure 3.13 : Les logs reçus de la machine Ubuntu
3.5.3 Collecte des données à partir des machines Centos
Pour installer l’agent Wazuh sur un système CentOS, nous avons opté pourzl’utilisation de
Yum, un gestionnaire de paquets. Après cette étape, nous avons activé et lancé l’agent, ce qui nous
a permis de recevoirzles fichiers journaux. Les détails de cette procédure sont présentés de manière
illustrée dans les figures 3.14 et 3.15 ci-dessous.
Figure 3.14 : Installation de l’agent wazuh sur Centos
30
Figure 3.15 : Les logs reçus de la machine Centos
3.6 Intégration des outils tiers à WAZUH
La surcharge d’alerteszdans les SIEM épuise les analystes et rend difficile le traitement manuel
de chaque alerte. Les outils d’automatisation SOARzsont indispensables pour résoudre ce problème,
en automatisant diverses tâches telles que la collecte de données, l’analyse des alertes, la corrélation
des événements et l’exécution d’actions appropriées. Cette automatisation soulage les analystes,
améliore l’efficacité opérationnelle et renforce la sécurité globale.
TheHive et Cortex sontzdeux plateformes spécialement conçues pour automatiser l’analyse
dans les SIEM. TheHive propose un tableau de bord centralisé pour gérer les alertes, faciliter la
collaborationzentre les analystes et suivre les enquêtes en cours. Cortex fournit des connecteurs et
des outils d’analyse automatisée pour enrichir les alertes, effectuer des recherches et exécuter des
actions préprogrammées.
Pour la collaborationzet le partage d’informations sur les menaces, MISP (Malware Information
Sharing Platform) est une plateforme open source largement utilisée. Elle permet aux organisations
de partager de manière structurée des indicateurs de compromission (IOC)zet d’autres informations
liées aux menaces. Les SIEM peuvent utiliser MISP pour partagerzleurs IOC avec d’autres acteurs
de la communauté de la sécurité et les corréler avec d’autres sources de données telles que des listes
de réputation d’adresses IP ou de noms de domaines malveillants.
L’intégration de ces trois plateformes (TheHive, Cortex et MISP) renforcezla sécurité du
SIEM en enrichissant les alertes avec les IOC partagés via MISP, améliorant ainsi la détection des
attaques. Les outilszd’automatisation fournis par TheHive et Cortex permettent l’analyse automatique
des alertes et l’exécution d’actions préprogrammées pour bloquer ou enquêter sur les communications
31
malveillantes. De plus, unezcollaboration efficace entre les membres de l’équipe de sécurité est
favorisée. Cette intégrationzaméliore la réactivité et l’efficacité du SIEM dans la lutte contre les
menaces.
3.6.1 Installation et Configuration de MISP
L’annexe 2 fournit une description détaillée des étapes d’installation de MISP.

Une fois que vous avez terminé l’installation de la plateforme, il vous suffit d’ouvrir un
navigateur pour accéder à l’interface de MISP. Vous pouvez voir cette interface dans la figure 3.16,
qui sera affichée comme illustrée.
Figure 3.16 : MISP Dashboard
Pour débuter, nous allons procéder à la configuration de certains paramètres administratifs

essentiels. Pour cela, nous avons accédé à la section "Administration" et "Scheduled Tasks".
Nous avons configuré "fetch-feeds" à 24, comme indiqué dans la figure 3.17.
Figure 3.17 : Configuration des paramères MISP
La dernière étape de configuration que nous devons accomplir estzla création d’une clé de
communication entre Cortex et The Hive. Pour effectuer cette procédure, il est nécessaire de se
rendre dans l’ongletz"administration". C’est à cet endroit que nous pourrons ajouter un utilisateur
32
et générerzune clé, tel que montré dans l’illustration ci-dessous de la figure 3.18.
Figure 3.18 : Ajout d’un utilisateur dans MISP
3.6.2 Installation et Configuration de The Hive
Les instructions d’installation de The Hive sont fournies en détail dans l’annexe 3.
La configuration nécessaire pour Elasticsearch, Cassandra et le stockage des fichiers est
représentée dans la figure 3.19 du fichier /etc/thehive/application.conf.
Figure 3.19 : Configurations de The Hive
Après avoir exécuté la commandez"sudo systemctl enable soudo systemctl star thehive",Nous
avons accéder à l’interface graphique dezThe Hive en utilisant un navigateur et en connectant au
port 9000, tel qu’illustré dans la figure 3.20.
33
Figure 3.20 : Interface utilisateur de The Hive
3.6.3 Installation et Configuration de Cortex
Les étapes d’installation de Cortex sont détaillées dans l’annexe 4.

Une fois la plateformezinstallée, nous pouvons accéder à l’interface graphique de The Hive
en utilisant un navigateur et en utilisant le port 9001, comme indiqué dans la figure 3.21.
Figure 3.21 : Interface utilisateur de Cortex
Pour assurer l’authentificationzdes cookies contenant les données, il est indispensablezd’intégrer

la clé du serveur play.http.secret key dans le fichier de configuration du cortex. Il est impératif de la
placer dans le fichier /etc/cortex/application.conf, comme illustré dans la figure 3.22 ci-dessous.
34
Figure 3.22 : Génération de clé de Cortex
Nous avons créé un compte administrateur et une organisation comme montré dans les figures
3.23 et 3.24.
Figure 3.23 : Création d’un utilisateur dans Cortex
Figure 3.24 : Création d’une organisation dans Cortex
Les analyseurs sontzconfigurés pour effectuer une inspection approfondie de toutes les bases
de données, afin de repérer tout contenu nocif. Il est essentielzd’avoir Python et Pip installés au
préalable. Les référentiels du cortex-Analyzer ont été téléchargés et tous les packages nécessaires ont
été installés, comme illustré dans la figure 3.25..
35
Figure 3.25 : Installation des analyseurs
Après, dans le fichier de configuration Cortex représenté dans la figure 3.26, nous avons
modifié le chemin d’accès aux analyzeurs.
Figure 3.26 : Configuration dans /etc/cortex/application.conf
3.6.3.1 Intégration de The Hive avec WAZUH
Nous commençons par préparerzThe Hive en configurant une nouvellezorganisation via l’interface
web à l’aide d’un compte administrateur, en nous référant aux figures 3.27 et 3.28. Pour nos tests,
nous ajoutons un nouvel utilisateur aveczdes privilèges d’administrateur à cette organisation. En
utilisant l’API REST de The Hive, nous intégronszWazuh en créant un utilisateur capable de générer
des alertes via l’API. Nous créons donc un compte avec le privilège "analyste" et générons une clé
API pour cet utilisateur.
36
Figure 3.27 : Création d’organisation dans The Hive
Figure 3.28 : Création des utilisateurs dans The Hive
Maintenant, nous devons configurer Wazuh-Manager.

Pour commencer, nous procédons à l’installation du module Python de TheHive qui est
montré dans la figure 3.29.
Ensuite, nous générons le script d’intégration personnalisé en copiant le code Python ci-dessous et
en le collant dans le /var/ossec/integrations/custom-w2 thive.py (voir dans l’annexe 5).
Figure 3.29 : Installation du module Python de The Hive
37
Nous créonszun script bash, "/var/ossec/integrations/custom-w2thive" (voir Annexe 5), pour

exécuter le fichier .py de manière appropriée. En ajustant les autorisations et la propriétézdes fichiers
selon la figure 3.30,nous assurons que Wazuh dispose des permissions nécessaires pour y accéder et
les exécuter.
Pour permettre à Wazuhzd’exécuter le script d’intégration, nous ajoutons les lignes suivantes
dans le fichier de configuration du gestionnaire situé à "/var/ossec/etc/ossec.conf", comme indiqué
dans la figure 3.31.
En utilisant notrezcompte utilisateur de test, nous connectons à TheHive et accédons à
l’onglet "Alertes". Cet onglet nous permet de consulter les alertes générées par Wazuh, comme
montré dans la figure 3.32.
Figure 3.30 : Les commandes d’autorisations
Figure 3.31 : Modification de fichier /var/ossec/etc/ossec.conf
Figure 3.32 : Wazuh-alerte dans the Hive
38
3.6.3.2 Intégration de The hive avec Misp
Nous avons modifié le fichier de configuration de The Hive situézà "/etc/thehive/application.conf".

Ensuite, nous avons ajouté l’URL de MISP (MISPURL)zainsi que la clé (MISPKEY) que nous avons
générées lors du déploiement de MISP, comme indiqué dans la figure 3.33. Enfin, nous avons effectué
une vérification pour garantir le bon fonctionnement de l’ensemble, en suivant les instructions de la
figure 3.34.
Figure 3.33 : MISP configuration dans thehive
Figure 3.34 : Intégration Mips et The Hive
3.6.3.3 Intégration de The Hive avec Cortex
Après avoir généré la cléqà partir du guide de Cortex, nous l’avons copiéebet collée dans
le fichier de configuration de The Hive, comme montré dans la figure 3.35. Ensuite, nous avons
redémarré le service The Hive.
39
Figure 3.35 : Intégration Cortex et The Hive
Conclusion
Pour récapituler, ce chapitre souligne la pertinence de la plateforme Wazuh en tant qu’outil

de surveillance et de protection des systèmes et des réseaux. En raison de son architecture adaptable
et évolutive, ainsi que de son intégration avec des outils externes, Wazuh se présente comme une
solution robuste pour détecter et répondre aux menaces en matière de sécurité.
40
Chapitre 4
Tests et Validation
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1 Scénario d’attaque brute force . . . . . . . . . . . . . . . . . . . . . . . . 42
2 Surveillance de l’intégrité des fichiers . . . . . . . . . . . . . . . . . . . . 43
3 Surveillance de l’exécution de commandes malveillantes . . . . . . . . . 44
4 Détection de processus non autorisés . . . . . . . . . . . . . . . . . . . . 45
5 Détection de processus cachés . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Détection d’une attaque par injection SQL . . . . . . . . . . . . . . . . . 48
7 Détection de fichiers binaires suspects . . . . . . . . . . . . . . . . . . . . 49
8 Détection d’une attaque Shellshock . . . . . . . . . . . . . . . . . . . . . 49
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapitre 4. Tests et Validation
Introduction
Une fois quella solution sera mise en place, nous conduirons des tests dans cette section pour
évaluer son efficacité et vérifier qu’ellelréagit de manière adéquate aux menaces en temps réel. Nous
effectuerons une série de scénarios d’attaques diversifiés et analyserons leslrésultats obtenus dans
Wazuh.
4.1 Scénario d’attaque brute force
La méthode de force brute estlfréquemment utilisée par des individus malveillants pour
contourner les mesures de sécurité et obtenir un accèslillégal à des points d’accès et des services.
Nous avons exécuté une vérificationldes ports ouverts en utilisant la commande nmap, telle
qu’indiquée dans la figure 4.1. Ensuite, nous avons lancé une attaque à l’aide de hydra, comme le
montre la figure 4.2. Par conséquent, une alerte a été détectée par wazuh, comme illustré dans la
figure 4.3.
Figure 4.1 : Les ports ouverts
Figure 4.2 : Attaque brute force
42
Figure 4.3 : Détection d’une attaque Brute force par wazuh
4.2 Surveillance de l’intégrité des fichiers
Le module de surveillancelde l’intégrité des fichiers (FIM) de Wazuh simplifie l’audit des
fichiers sensibles et garantit la conformité aux réglementations en surveillant en permanence l’intégrité
des fichiers.
Pour illustrer son fonctionnement, nous avonslréalisé une expérience où nous avons crée un
fichier, ajouté du contenu après 30 secondes, puis modifié ce contenu après 30 secondes supplémentaires,
comme le montre la figure 4.4. Ensuite, nous avons supprimé le fichier, ce qui a déclenché une alerte
signalant ces manipulations, comme le montre également la figure 4.5.
Figure 4.4 : Manipulation d’un fichier
Figure 4.5 : Alerte FIM dans Wazuh
43
4.3 Surveillance de l’exécution de commandes malveillantes
Auditd estlun utilitaire d’audit natif des systèmes Linux. Il est utilisédpour enregistrer les
actions et les modifications effectuées sur un point de terminaison Linux.
Nous devons avoir Auditdlpréinstallé sur la machine agent. Pour ajouterldes règles d’audit
au /etc/audit/audit rules, nous avons exécuté les commandes perçues dans la figure 4.6. Ensuite,
nous avons ajoutélla configuration correspondant à l’agent Wazuh dans le /var/ossec/etc/ossec conf,
comme indiqué dans la figure 4.7. Nous avonslégalement crée une liste CDB des programmes suspects
dans le fichier /var/ossec/etc/lists/suspicious-programs, puis l’avons intégrée à la section <ruleset>
du serveur Wazuh dans le fichier /var/ossec/etc/ossec.conf. Ensuite, nous avons crée une règle de
gravité élevée qui déclenchera une alerte lors de l’exécution du programme "red". Nous avons ajouté
cettelnouvelle règlelau fichier /var/ossec/etc/rules/local-rules.xml sur le serveur Wazuh Enfin, nous
avons exécuté le programme "red" avec la commande "netcat nc -v", comme toutlest indiqué dans
la figure 4.8, et finalement reçu l’alerte illustrée dans la figure 4.9.
Figure 4.6 : Les règles d’audit ajoutées
Figure 4.7 : Modification du fichier "/var/ossec/etc/ossec.conf" pour l’audit
44
Figure 4.8 : Règle d’audit pour la détection des commandes suspectes
Figure 4.9 : Détection d’une commande malveillante
4.4 Détection de processus non autorisés
La surveillanceldes commandes de Wazuh permet d’exécuter et de surveiller les résultats des

commandes sur un point de terminaison.
Les modifications requislont été effectués sur l’agent Wazuh, comme illustré dans les schémas
4.10 et 4.11. Après avoir exécuté la commande "nc -l 8000" pendant une durée de 30 secondes, des
alertes ont été reçues, comme présenté dans le schéma 4.12.
45
Figure 4.10 : Configuration d’OSSEC : Surveillance de la liste des processus système
Figure 4.11 : Rôle ajouté
Figure 4.12 : Alerte d’un processus non autorisé
4.5 Détection de processus cachés
Nous démontrons comment Wazuh détecte les processus dissimulés engendrés par un rootkit
sur Linux.
Nous avons installé les packageslnécessaires pour construire le rootkit et configuré l’agent
Wazuh pour effectuer des analyses de rootcheck toutes les 2 minutes. La fréquence de vérification a
été ajustée à 120 dans le fichier de configuration de Wazuh.
46
Ensuite, nous avons récupérélle code source du rootkit Diamorphine depuis GitHub et l’avons
compilé. Après avoir chargé le module du noyau du rootkit, nous avons utilisé la commande "kill
63" avec un ID de processuslaléatoire. Le processus rsyslogd est devenu invisible, indiquant que
le rootkit peut masquer certains processus dans la liste "ps". En utilisant le signal "kill 31", nous
pouvonskmasquer ou révéler n’importe quel processus, comme indiqué dans la figure 4.13. Les alertes
sont ensuitelconsultables dans le tableau de bord de Wazuh, comme illustré dans la figure 4.14.
Figure 4.13 : Attaque de processus caché lancée
Figure 4.14 : Alerte d’un processus caché
47
4.6 Détection d’une attaque par injection SQL
L’injection SQLlfait référence à une technique d’attaque où un individulmalveillant insère

du code nuisible dans des chaînes de caractères qui sont ensuite envoyées à un serveur de base de
données.
Après avoir vérifiéll’ouverture du port 80, nous avons effectué une attaque parlinjection SQL,
comme indiqué dans la figure 4.15. Cette attaque a été détectée par Wazuh, et nous avons reçu une
alerte correspondante, comme illustré dans la figure 4.16.
Figure 4.15 : Attaque SQL Injection lancé
Figure 4.16 : Alerte d’une attaque SQl Injection
48
4.7 Détection de fichiers binaires suspects
Wazuh détecteldes programmes suspects, appelés binaires, sur les périphériques finaux.
Nous avons modifié le bloc "<rootcheck>" dans le fichier "/var/ossec/etc/ossec.conf" en
suivant les instructions présentées dans la figure 4.17. Après cela, nous avons lancé l’attaque et reçu
une alerte, comme le montre la figure 4.18.
Figure 4.17 : Fichier binaire suspect
Figure 4.18 : Alerte d’un fichier binaires suspect
4.8 Détection d’une attaque Shellshock
La faillelcritique de GNU Bash, également connue sous le nom de vulnérabilitélShellshock,

permet aux pirates informatiques de manipuler des ordinateurs en injectant des commandes malveillantes
à l’aide d’un bug présent dans Bash.
En analysant les journaux deslserveurs web collectés à partir d’un point de terminaison
surveillé, Wazuh peut détecter une attaque utilisantlla vulnérabilité Shellshock.
49
Pour garantirlle bon fonctionnement de Wazuh-Agent, il est nécessaire d’installer préalablement

le serveur Apache. De plus, il est essentiel d’ajouter le contenu spécifié dans la figure 4.19 au fichier
/var/ossec/etc/ossec.conf. Une fois ceslétapes suivies, nous avons effectué une attaque Shellshock,
comme illustré dans la figure 4.21, et avons reçu l’alerte correspondante, comme indiqué dans la
figure 4.22.
Figure 4.20 : Attaque shellshok
Figure 4.21 : Alerte shellshock detectée
50
Conclusion
Dans cette section, nous avons procédé à des contrôleslafin de garantir le bon fonctionnement
de notre solution de sécurité. Nous avons mené une série de tests au cours desquels nous avons généré
et détecté des incidents grâce à Wazuh. Par la suite, ces incidents ont été automatiquement transmis
à des outils externes pour être traités.
51
Conclusion générale
Les entreprisesksubissent des conséquences importantes sur leur réputation et la confiance

de leurs clients lorsqu’elles font face à des attaques de sécurité, en plus du risque potentiel de
perte de donnéeskclients et de propriété intellectuelle. Cela met en évidence l’importance pour les
organisations d’améliorer leur capacité à repérer et à répondre aux attaques de manière plus efficace.
Dans ce contexte, nos effortskont abouti à la mise en place d’une solution SIEM performante
qui permet la détection, la prévention et la réponse proactivekaux incidents de sécurité de l’entreprise
3S. Les tests effectués ont confirmé l’efficacité dekcette solution, offrant une surveillance constante
des événements de sécurité, une corrélation des journaux et une analyse avancée des menaces.
Dans ce contexte, nos effortskont abouti à la création d’une solution SIEM performante qui permet
la détection, la prévention et la réponsekproactive aux incidents de sécurité. Les tests réalisés ont
confirmé l’efficacité de cette solution en offrant une surveillance constante des événements de sécurité,
une corrélationkdes journaux et une analyse avancée des menaces. Pour atteindre cet objectif, nous
avons initiékle projet en présentant les principes essentiels de la sécurité des systèmes d’informations
et en effectuant une étude comparative des différentes options de produits SIEM disponibles sur le
marché.
Par la suite, nous avons effectuer une étude approfondie de la solutionksur le plan théorique
afin de déterminer les meilleures pratiques pour sa mise en place. Ensuite, nous avons procédé au
déploiement de notre solution et nous avons effectué des expérimentations en intégrantkdes outils
tiers pour évaluer sa performance et sa fiabilité. Grâce à ces démarches, nous avons pu établirkun
système robuste qui renforce la sécurité de notre entreprise et nous permet de réagir efficacement
face aux menaces de sécurité.
Dans une perspective d’évolution future, il est vivement recommandé de persévérer dans les
améliorations continues de la solution SIEM. Cela implique notamment de renforcer la surveillance en
temps réel, d’intégrer de nouvelles sources de données pour une vision plus complète des événements
de sécurité, et de développer des stratégies de réponse aux incidents plus robustes.
52
Bibliographie
[1] « Présentation de 3S. » [Accès le 14-Février-2021]. (), adresse : https://www.3s.com.tn/.
[2] « C’est Quoi un SIEM ? » [Accès le 14-Février-2021]. (), adresse : hhttps://www.splunk.com/

fr_fr/data-insider/what-is-siem.html.
[3] « La sensibilisation des collaborateurs d’une organisation aux risques informatiques : élément
incontournable ? » [Accès le 18-Février-2021]. (), adresse : https://dumas.ccsd.cnrs.fr/
dumas-02995555/document.
[4] « What is SIEM ? And How Does it Work ? » [Accès le 02-Mars-2021]. (), adresse : fhttps:
//logrhythm.com/blog/what-is-siem/.
[5] « the-complete-guide-to-log-and-event-management. » [Accès le 05-Février-2021]. (), adresse :

https : / / studylib . net / doc / 8912353 / the - complete - guide - to - log - and - event -
management).
[6] « Quelle est la différence entre sem, sim et siem ? » [Accès le 15-Février-2021]. (), adresse :
https://fr.theastrologypage.com/what-s-difference-between-sem.
[7] « Role siem. » [Accès le 20-Février-2021]. (), adresse : https://www.ibm.com/topics/siem.
[8] « Le fonctionnement d’un siem. » [Accès le 01-Avril-2021]. (), adresse : https://docshare.

tips/rapport-gs16-groupe-1-siem-12_576dabfcb6d87fc5918b4b3a.html.
[9] « Figure de fonctionnement d’un SIEM. » [Accès le 05-Avril-2021]. (), adresse : https : / /
digitalonomics.fr/gestion-des-evenements-de-securite-la-prevention-avant-la-
catastrophe/.
[10] « Les fichiers Logs. » [Accès le 12-Avril-2021]. (), adresse : https://www.journaldunet.com/

web-tech/developpeur/1008712-les-fichiers-log-des-indicateurs-utiles/.
[11] « Log format. » [Accès le 22-Avril-2021]. (), adresse : https://www.graylog.org/post/log-

formats-a-complete-guide/.
[12] « OSSIM. » [Accès le 26-Avril-2021]. (), adresse : https://cybersecurity.att.com/products/

ossim.
[13] « Graylog. » [Accès le 01-Mai-2021]. (), adresse : https://www.graylog.org/post/siem-

simplified/.
53
Bibliographie
[14] « Wazuh. » [Accès le 01-Mai-2021]. (), adresse : https : / / www . servicepilot . com / fr /
integration/supervision-wazuh/.
[15] « Splunk. » [Accès le 02-Mai-2021]. (), adresse : https://www.splunk.com/fr_fr/resources/

videos/what-is-splunk.html.
[16] « IBM Qradar. » [Accès le 05-Mai-2021]. (), adresse : https://www.ibm.com/docs/fr/qsip/

7.5?topic=manager-overview-qradar-vulnerability.
[17] « USM. » [Accès le 22-Mai-2021]. (), adresse : https://cybersecurity.att.com/products/

usm-anywhere.
[18] « WAZUH. » [Accès le 22-Mai-2021]. (), adresse : https://wazuh.com/.
[19] « The Hive. » [Accès le 23-Mai-2021]. (), adresse : https://thehive-project.org/.
[20] « Docker. » [Accès le 23-Mai-2021]. (), adresse : https://docs.docker.com/compose/.
54
Annexes
Annexe 1 . Installation de Wazuh
Une fois que nous avons téléchargé le script sur la machine virtuelle avec l’adresse IP 172.29.12.6,
nous l’avons exécuté pour démarrer l’installation du serveur Wazuh comme l’indique la figure annexe
1.1.
Figure annexe 1.1 :Installation de Wazuh
Une fois l’installation du serveur Wazuh terminée avec succès, nous prenons soigneusement
note des informations d’identification qui s’affichent (nom d’utilisateur et mot de passe).
Annexe 2 . Installation de MISP
Nous effectuons un clonage du projet MISP à partir de GitHub pour créer une version
identique du projet tel qu’il est montré par la figure annexe 2.1.
Figure annexe 2.1 :Clonnage du projet MISP
Nous procédons à la création d’un répertoire dédié à la base de données MISP, puis nous
initialisons la base de données MISP comme montrée par la figure annexe 2.2.
55
Annexes
Figure annexe 2.2 :Initialisation de la base de données MISP
Nous avons généré un certificat auto-signé pour MISP commme illustrée par la figure annexe
2.3.
Figure annexe 2.3 :Génération d’une certificat pour MISP
Nous avons démarré le conteneur tel qu’il est illustré par la figure annexe 2.4.
Figure annexe 2.4 :Exécution de conteneur Docker
Annexe 3 . Installation de The Hive
Avant de commencer l’installation, il est essentiel de préparer les répertoires nécessaires. Pour
garantir la sécurité et assurer un support à long terme, il est fortement recommandé d’utiliser les
versions d’Amazon Corretto, une distribution d’OpenJDK tel qu’illustré dans les deux figure annexe
3.1 et figure annexe 3.2.
56
Annexes
Figure annexe 3.1 :Préparation des répertoires 1
Figure annexe 3.2 :Préparation des répertoires 2
Apache Cassandra est une base de données reconnue pour son évolutivité remarquable et sa
disponibilité élevée.Lors de l’installation de TheHive, il est crucial d’utiliser la version stable la plus
récente de Cassandra, à savoir la version 4.0.x.Nous avons consulté le référentiel officiel d’Apache
Cassandra. Une fois que nous avons identifié les références nécessaires comme représente dans la
figure annexe 3.3, nous procédons à l’installation du package correspondant comme énoncé dans la
figure annexe 3.4.
57
Annexes
Figure annexe 3.3 :Ajout des références au dépôt Apache
Figure annexe 3.4 :Installation de Cassandra
Pour effectuer des ajustements de configuration dans Cassandra, il est nécessaire de se

connecter à Cassandra comme montre la figure annexe 3.5. Ces ajustements peuvent être effectués
de manière interactive en utilisant CQLSH (Cassandra Query Language Shell). CQLSH fournit une
interface en ligne de commande qui permet d’exécuter des commandes et des requêtes dans le langage
de requête de Cassandra.Puis,nous avons testé la connectivité avec netstat comme illustré dans la
figure annexe 3.6.
Figure annexe 3.5 :Connexion à Cassandra
58
Annexes
Figure annexe 3.6 :Verification de connexions réseau pour le port 9042
La configuration du fichier "cassandra.yaml" situé dans le répertoire "/etc/cassandra" tel

qu’il est montré dans la figure annexe 3.7.
Figure annexe 3.7 :Configuration dans /etc/cassandra/cassandra.yaml
Pour assurer le bon fonctionnement de TheHive, en plus de Cassandra, il est également

nécessaire d’installer Elasticsearch, comme illustré dans la figure annexe 3.8 ci-dessous.
Figure annexe 3.8 :Installation elasticsearch
59
Annexes
Configuration du fichier /etc/elasticsearch/elasticsearch.yml comme montre dans la figure

annexe 3.9 et la figure annexe 3.10.
Figure annexe 3.9 :Configuration dans /etc/elasticsearch/elasticsearch.yml (1)
Figure annexe 3.10 :Configuration dans /etc/elasticsearch/elasticsearch.yml (2)
Nous avons ajouté des options personnalisées Java virtual machine au fichier
/etc/elasticsearch/jvm.options.d/jvm.options comme montre dans la figure annexe 3.11.
Figure annexe 3.11 :Inclusion des options personnalisées pour Java Virtual Machine
60
Annexes
L’installation de TheHive se fait à l’aide de la commande sudo apt-get install -y thehive

comme illustre dans la figure annexe 3.12.
Figure annexe 3.12 :Installation de The Hive
Annexe 4 . Installation de Cortex
Pour effectuer l’installation, il est essentiel de disposer de l’environnement d’exécution Java

et d’Elasticsearch 7. Pour commencer,nous devons télécharger le package Cortex-latest.zip.Puis nous
avons extrait son contenu . La figure annexe 4.1 montre les étapes pour cette tache. .
Figure annexe 4.1 :Téléchargement du package Cortex
Pour configurer Cortex en tant que service, il est recommandé d’utiliser un utilisateur spécifique.
Comme le montre la figure 4.2 ci-dessous , nous avons créé un groupe appelé "cortex", ajouté un
utilisateur à ce groupe, et attribué le répertoire /opt/cortex à cet utilisateur.
61
Annexes
Figure annexe 4.2 :
Annexe 5 .Les codes nécessaires pour l’integration de wazuh avec

the Hive
Voici le contenu de custom-w2thive.py
import json
import sys
import os
import re
import logging
import uuid
from thehive4py.api import TheHiveApi
from thehive4py.models import Alert, AlertArtifact
#start user config
Global vars
#threshold for wazuh rules level
lvl_threshold=0
#threshold for suricata rules level
suricata_lvl_threshold=3
debug_enabled = False
#info about created alert
info_enabled = True
#end user config
62
Annexes
Set paths
pwd = os.path.dirname(os.path.dirname(os.path.realpath(file)))
log_file = ’{0}/logs/integrations.log’.format(pwd)
logger = logging.getLogger(name)
#set logging level
logger.setLevel(logging.WARNING)
if info_enabled:
logger.setLevel(logging.INFO)
if debug_enabled:
logger.setLevel(logging.DEBUG)
create the logging file handler

fh = logging.FileHandler(log_file)
formatter = logging.Formatter(’%(asctime)s - %(name)s - %(levelname)s - %(message)s’)
fh.setFormatter(formatter)
logger.addHandler(fh)
def main(args):
logger.debug(’#start main’)
logger.debug(’#get alert file location’)
alert_file_location = args[1]
logger.debug(’#get TheHive url’)
thive = args[3]
logger.debug(’#get TheHive api key’)
thive_api_key = args[2]
thive_api = TheHiveApi(thive, thive_api_key )
logger.debug(’#open alert file’)
w_alert = json.load(open(alert_file_location))
logger.debug(’#alert data’)
logger.debug(str(w_alert))
logger.debug(’#gen json to dot-key-text’)
alt = pr(w_alert,’’,[])
63
Annexes
logger.debug(’#formatting description’)
format_alt = md_format(alt)
logger.debug(’#search artifacts’)
artifacts_dict = artifact_detect(format_alt)
alert = generate_alert(format_alt, artifacts_dict, w_alert)
logger.debug(’#threshold filtering’)
if w_alert[’rule’][’groups’]==[’ids’,’suricata’]:
#checking the existence of the data.alert.severity field
if ’data’ in w_alert.keys():
if ’alert’ in w_alert[’data’]:
#checking the level of the source event
if int(w_alert[’data’][’alert’][’severity’])<=suricata_lvl_threshold:
send_alert(alert, thive_api)
elif int(w_alert[’rule’][’level’])>=lvl_threshold:
#if the event is different from suricata AND suricata-event-type: alert check lvl_threshold
send_alert(alert, thive_api)
def pr(data,prefix, alt):
for key,value in data.items():
if hasattr(value,’keys’):
pr(value,prefix+’.’+str(key),alt=alt)
else:
alt.append((prefix+’.’+str(key)+’|||’+str(value)))
return alt
def md_format(alt,format_alt=’’):
md_title_dict = {}
#sorted with first key
for now in alt:
now = now[1:]
fix first key last symbol
dot = now.split(’|||’)[0].find(’.’)
if dot==-1:
64
Annexes
md_title_dict[now.split(’|||’)[0]] =[now]
else:
if now[0:dot] in md_title_dict.keys():
(md_title_dict[now[0:dot]]).append(now)
else:
md_title_dict[now[0:dot]]=[now]
for now in md_title_dict.keys():
format_alt+=’### ’+now.capitalize()+’\n’+’| key | val |\n| ------ | ------ |\n’
for let in md_title_dict[now]:
key,val = let.split(’|||’)[0],let.split(’|||’)[1]
format_alt+=’| ’ + key + ’ | ’ + val + ’ |\n’
return format_alt
def artifact_detect(format_alt):
artifacts_dict = {}
artifacts_dict[’ip’] = re.findall(r’\d+.\d+.\d+.\d+’,format_alt)
artifacts_dict[’url’] = re.findall(r’http[s]?://(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*
,]|(?:%[0-9a-fA-F][0-9a-fA-F]))+’,format_alt)
artifacts_dict[’domain’] = []
for now in artifacts_dict[’url’]: artifacts_dict[’domain’].append(now.split(’//’)[1].split(’/’)
return artifacts_dict
def generate_alert(format_alt, artifacts_dict,w_alert):
#generate alert sourceRef
sourceRef = str(uuid.uuid4())[0:6]
artifacts = []
if ’agent’ in w_alert.keys():
if ’ip’ not in w_alert[’agent’].keys():
w_alert[’agent’][’ip’]=’no agent ip’
else:
w_alert[’agent’] = {’id’:’no agent id’, ’name’:’no agent name’}
for key,value in artifacts_dict.items():
for val in value:
65
Annexes
artifacts.append(AlertArtifact(dataType=key, data=val))
alert = Alert(title=w_alert[’rule’][’description’],
tlp=2,
tags=[’wazuh’,
’rule=’+w_alert[’rule’][’id’],
’agent_name=’+w_alert[’agent’][’name’],
’agent_id=’+w_alert[’agent’][’id’],
’agent_ip=’+w_alert[’agent’][’ip’],],
description=format_alt ,
type=’wazuh_alert’,
source=’wazuh’,
sourceRef=sourceRef,
artifacts=artifacts,)
return alert
def send_alert(alert, thive_api):
response = thive_api.create_alert(alert)
if response.status_code == 201:
logger.info(’Create TheHive alert: ’+ str(response.json()[’id’]))
else:
logger.error(’Error create TheHive alert: {}/{}’.format(response.status_code, response.text))
if name == "main":
try:
logger.debug(’debug mode’) # if debug enabled
# Main function
main(sys.argv)
except Exception:
logger.exception(’EGOR’)
\end{lstlisting}
\end{document}
66
Annexes
Voici le contenu du script bash "custom-w2thive" :
WPYTHON_BIN="framework/python/bin/python3"
SCRIPT_PATH_NAME="$0"
DIR_NAME="$(cd $(dirname ${SCRIPT_PATH_NAME}); pwd -P)"
SCRIPT_NAME="$(basename ${SCRIPT_PATH_NAME})"
case ${DIR_NAME} in
*/active-response/bin | */wodles*)
if [ -z "${WAZUH_PATH}" ]; then
WAZUH_PATH="$(cd ${DIR_NAME}/../..; pwd)"
fi
PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"
;;
*/bin)
WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
fi
PYTHON_SCRIPT="${WAZUH_PATH}/framework/scripts/${SCRIPT_NAME}.py"
;;
*/integrations)
WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
fi
PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"
;;
esac
${WAZUH_PATH}/${WPYTHON_BIN} ${PYTHON_SCRIPT} $@
67

Ameni BEN JEMIA SFE Copy3

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

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 :

Formats disponibles

Ameni BEN JEMIA SFE Copy3

Transféré par

Droits d'auteur :

Formats disponibles

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET

UNIVERSITE TUNIS EL MANAR

INSTITUT SUPERIEUR D’INFORMATIQUE

RAPPORT DE STAGE DE FIN D’ETUDES

Présenté en vue de l’obtention du

Ameni BEN JEMIA

Mise en plase d’une solution SIEM

Encadrant professionnel : Mr Akram ALLANI

Réalisé au sein de Standard Sharing Software

Année Universitaire 2022 - 2023

Ameni BEN JEMIA

Je tiens à exprimer mes vifs remerciements à mes deux encadrants :

Madame Sourour MHENNI

1 Contexte général du projet 2

2 Etat d’art sur les SIEMs 8

3 Etude de la solution WAZUH 20

1.1 Les partenaires de 3S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Fonctionnement d’un Siem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Les composants de Wazuh et le flux de données . . . . . . . . . . . . . . . . . . . . . 23

4.1 Les ports ouverts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.1 Tableau comparatif des SIEMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

— 3S = Standard Sharing Software

— API = Application Progrmmaing Interface

— CERT = Computer Emergency Response Team

— CQLSH = Cassanda Query Language SHell

— CSIRT = Computer Security Incident Response Teams

— DNS = Domain Name System

— EMC = Electric Membership Corporation

— FIM = File Integrity Monitoring

— IAM = Identity and Access Management

— IBM = International Business Machines

— IDMEF = Intrusion Detection Message Exchange Format

— IDS = Intrusion Detection System

— IETF = Internet Engineering Taske Force

— IOC = Indicator Of Compromise

— IODEF = Incident Object Description and Exchange Format

— IPS = Intrusion Prevention System

— IPTV = Internet Protocol Television

— ISO = International Standardization Organization

— MISP = Malware Information Sharing Platform

— NOSQL = No Only SQL

— OSSEC = Open Source Security

— OSSIM = Open Source Security Information Management

— RFC = Request For Comment

— SEM = Security Event Manager

— SIEM = Security Information Event Managment

— SIM = Security Information Manager

— SMS = Short Message Service

— SOAR = Security Orchestration Automation Response

— SSH = Secure SHell

— UDP = User Datagram Protocol

— URL = Uniform Resource Locator

— USM = Unified Security Management

— USM = Unified Security Management

— XDR = Extended Detection and Response

— XML = EXtensible Markup Language

— YAML = Yet Another Markup Language

Contexte général du projet

1 Présentation générale de l’organisme d’accueil . . . . . . . . . . . . . . . 3

2 Cadre générale du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1 Organisme d’accueil

1.1.1 Présentation de 3S Standard Sharing Software

3S est une entreprise qui se spécialise dans l’intégration de services et d’infrastructures