UNIVERSITE DE SFAX

REPUBLIQUE TUNISIENNE
***********
FACULTE DES SCIENCES
MINISTERE DE L’ENSEIGNEMENT DE SFAX
SUPERIEUR ET DE LA RECHERCHE ******
SCIENTIFIQUE D EPARTEMENT DE L’ INFORMATIQUE ET

MÉMOIRE DE FIN D’ETUDES

Présenté à
La Faculté des Sciences de Sfax
en vue de l’obtention du
DIPLÔME DE MASTER EN
SÉCURITÉ RÉSEAUX ET CLOUD COMPUTING

Par :
RANIA DEHMANI

“Mise en place d’une architecture SOC moderne

avec solution SOAR moderne et gestion des DFIR”
J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.

Signature et cachet

J’autorise l’étudiant à faire le dépôt de son rapport de stage en vue d’une soutenance.
Dédicace

« Soyons reconnaissants envers ceux qui nous apportent du bonheur »

À mon cher grand-père,

Mon deuxième père, mon soutien et ma source infinie de tendresse. Ton absence est une grande douleur,
mais tes souvenirs restent gravés en moi. Que Dieu t’accorde Son infinie miséricorde.

À la mémoire de mon cher papa,

Même si tu n’es plus là physiquement, ton amour et tes valeurs continuent de me guider chaque jour.
Tu resteras à jamais dans mon cœur.

À ma chère Maman,
Mon roc inébranlable, ma lumière et ma force. Tes sacrifices et ton amour m’ont appris à ne jamais
abandonner. Je te serai éternellement reconnaissante.

À ma famille bien-aimée,
Pour votre soutien, votre amour et votre présence constante à mes côtés face à tous les obstacles. Merci
pour votre confiance.

À moi-même,
Pour ma force et ma persévérance. Malgré les doutes et les difficultés, je n’ai jamais baissé les bras. Je
suis fière du chemin parcouru.

À tous ceux qui m’ont soutenue,

De près ou de loin, par un conseil ou un encouragement. Merci d’avoir fait partie de cette belle aventure.

Rania Dehmani

ii
Remerciements

Je tiens à exprimer ma profonde gratitude à toutes les personnes qui ont

contribué, de près ou de loin, à la réalisation de ce projet de fin d’études.

Je remercie chaleureusement mon encadrant professionnel, Monsieur Sadek

Choura, pour sa disponibilité, ses conseils précieux et son soutien continu tout

au long de ce projet.

Mes vifs remerciements s’adressent également à mon encadrant académique,

Monsieur Naoufel Gueddah, pour ses orientations pertinentes et son suivi

rigoureux.

Je remercie l’administration et le personnel de L’Aéroport International de

Sfax pour m’avoir accueillie et offert l’opportunité de réaliser ce stage dans un

environnement enrichissant.

Mes remerciements s'adressent aussi aux membres du jury pour l’intérêt qu’ils

portent à ce travail, ainsi qu’à mes professeurs pour la qualité de leur formation.

Enfin, un grand merci à ma famille et mes amis pour leur soutien indéfectible et

leurs encouragements constants.

Rania Dehmani

iii
Table des matières

Introduction Générale 1

1 Présentation générale du projet 3

1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Contexte et enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Pratiques actuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Périmètre et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Méthodologie adaptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.1 Étude comparative des méthodologies . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.2 Justification du choix de la méthodologie Agile . . . . . . . . . . . . . . . . . . 8

2 État de l’art 11
2.1 Concepts fondamentaux du SOC moderne .................................................................................... 12
2.1.1 La centralisation et la corrélation (SIEM) ........................................................................ 12
2.1.2 La détection d’intrusions (NIDS et HIDS) ....................................................................... 12
2.1.3 L’orchestration et l’automatisation (SOAR) ..................................................................... 12
2.1.4 La gestion des incidents et l’investigation (DFIR) ........................................................... 13
2.2 Limitations des approches traditionnelles de surveillance ........................................................... 13
2.3 Étude comparative des outils de la solution SOC ........................................................................ 13
2.3.1 Filtrage et détection réseau : pfSense vs iptables/OVS ................................................. 13
2.3.2 Analyse réseau en temps réel : Suricata vs Snort ............................................................ 14
2.3.3 Centralisation SIEM et HIDS : Wazuh vs ELK Stack native ......................................... 14
2.3.4 Supervision de la disponibilité : Zabbix vs Nagios .......................................................... 15
2.3.5 Orchestration SOAR : Shuffle vs Node-RED.................................................................... 15
2.3.6 Gestion des incidents DFIR : DFIR-IRIS vs TheHive .................................................... 16
2.4 La dimension humaine et culturelle du SOC ................................................................................ 18

iv
3 Spécification et analyse des besoins 19
3.1 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Identification des intervenants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Composants détaillés de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Réalisation 25
4.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Windows Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 Kali Linux 2024 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.3 Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.4 Wazuh Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.5 Suricata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.6 hping3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Mise en place du SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Mettre à jour le système et installer les prérequis . . . . . . . . . . . . . . . . . 28
4.3.2 Configuration pfsense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.3 Configuration pfsense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.4 Installer Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.5 Installer Wazuh (SIEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6 Installer Shuffle (SOAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.7 Installer DFIR-IRIS (Gestion des incidents) . . . . . . . . . . . . . . . . . . . . 31
4.3.8 Intégration IRIS et Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.9 Intégration MISP et Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.10 Intégration Shuffle, Wazuh et IRIS . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.11 Attaque test par Kali-Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.12 Démonstration d’attaque par force brute SSH . . . . . . . . . . . . . . . . . . . 43
4.3.13 Suricata IPS/IDS (Système de Prévention/Détection d’Intrusions) . . . . . . . 45
4.3.14 Simulation d’une Attaque DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Webographie 50

v
Table des figures

1.1 Étapes et processus de la méthode Scrum appliquée au projet . . . . . . . . . . . . . . 9

3.1 Architecture globale de la solution SOC ....................................................................................... 23

4.1 terminale pfsense .............................................................................................................................. 28

4.2 interface web pfsense........................................................................................................................ 28
4.3 Vérification du statut de Docker .................................................................................................... 29
4.4 Processus d’installation de Wazuh ................................................................................................. 29
4.5 Page de connexion de Wazuh.......................................................................................................... 30
4.6 Page d’accueil de Wazuh ................................................................................................................. 30
4.7 Processus d’installation de shuffle.................................................................................................. 31
4.8 Page d’accueil de Shuffle ................................................................................................................. 31
4.9 Page d’accueil de DFIR-IRIS .......................................................................................................... 32
4.10 Clé API IRIS..................................................................................................................................... 32
4.11 Alerte apparaissant dans IRIS ...................................................................................................... 33
4.12 Configuration du module Shuffle ................................................................................................... 33
4.13 Déploiement du module Webhook .................................................................................................. 34
4.14 Démarrage du Webhook .................................................................................................................. 34
4.15 Alerte Wazuh reçue dans Shuffle ................................................................................................... 34
4.16 Paramètres IRIS ............................................................................................................................... 35
4.17 Contenu du corps IRIS .................................................................................................................... 35
4.18 Bouton de relance ............................................................................................................................. 36
4.19 Automatisation de création de ticket IRIS .................................................................................... 36
4.20 Ticket créé depuis Shuffle ............................................................................................................... 37
4.21 Alerts Dfir-Iris .................................................................................................................................. 38
4.22 Dashboard wazuh ............................................................................................................................. 38
4.23 Dashboard wazuh état Ubuntu........................................................................................................ 39
4.24 Machine Kali-Linux .......................................................................................................................... 40
4.25 Tableau de bord Wazuh avant attaque ......................................................................................... 41
4.26 Tentative d’attaque brute-force avec Hydra .................................................................................. 41
4.27 Alerte de Wazuh sur la tentative d’attaque SSH 1...................................................................... 42
4.28 Détail de l’attaque brute-force en format JSON 1....................................................................... 42

vi
4.29 Détail de l’attaque brute-force en format JSON 2....................................................................... 43
4.30 Attaque ratée .................................................................................................................................... 44
4.31 Tableau de bord Wazuh................................................................................................................... 45
4.32 Tableau de bord Wazuh + Suricata .............................................................................................. 47

vii
Liste des tableaux

1.1 Fiche identificatrice de l’Aéroport International de Sfax . . . . . . . . . . . . . . . . . . 4

1.2 Comparaison des méthodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Comparaison des solutions de filtrage réseau ............................................................................... 14

2.2 Comparaison entre Suricata et Snort ............................................................................................. 14
2.3 Comparaison entre Wazuh et la Stack ELK classique................................................................. 15
2.4 Comparaison des outils de supervision d’infrastructure ............................................................... 15
2.5 Comparaison des plateformes d’automatisation ............................................................................ 16
2.6 Technologies sélectionnées et justifications pour l’architecture SOC ......................................... 17

4.1 Configuration matérielle .................................................................................................................. 26

viii
Liste des abréviations

— APT = Advanced Persistent Threat

— DNS = Domain Name System
— IDS = Intrusion Detection System
— IPS = Intrusion Prevention System
— SIEM = Security Information and Event Management
— SOC = Security Operations Center
— CVE = Common Vulnerabilities and Exposures
— VM = Virtual Machine
— XSS = Cross-Site Scripting

ix
Introduction Générale

Avec l’évolution rapide des technologies de l’information et la digitalisation croissante des

infrastructures critiques, la sécurité des systèmes informatiques est devenue un enjeu stratégique majeur.
Les organisations, en particulier celles gérant des infrastructures aéroportuaires, font face à des
menaces cybernétiques de plus en plus sophistiquées, ciblées et diversifiées, mettant en péril la
confidentialité, l’intégrité et la disponibilité de leurs données opérationnelles et de navigation.
Dans ce contexte, la simple mise en place de barrières défensives ne suffit plus. Il est devenu
indispensable de déployer un Centre d’Opérations de Sécurité (SOC) performant, capable de centraliser
la collecte des événements, de détecter les anomalies en temps réel et de coordonner une réponse rapide
et structurée face aux incidents. Un SOC moderne repose sur une synergie étroite entre la visibilité réseau,
la surveillance des hôtes, la gestion des alertes et l’automatisation des contre-mesures.
Pour répondre à ces exigences au sein d’un environnement virtualisé sous VMware Workstation,
cette solution s’appuie sur une architecture multicouche. La sécurité périphérique et le filtrage des
flux sont assurés par le pare-feu pfSense, couplé à Suri
cata pour l’analyse du trafic réseau et la détection d’intrusions (NIDS) en temps réel. Au niveau
des points de terminaison, la surveillance des hôtes et la détection d’intrusions (HIDS) sont confiées à
Wazuh, qui fait office de SIEM central. En parallèle,Zabbix assure la supervision continue de la
performance et de la disponibilité des équipements de l’infrastructure.

Face au volume massif d’alertes, l’intégration d’une plateforme de SOAR (Security Orchestration,
Automation and Response) comme Shuffle permet d’orchestrer et d’automatiser les réponses aux
incidents, notamment en déclenchant des blocages réactifs via F a i l 2Ban et en notifiant
instantanément les équipes via Slack. Enfin, la phase d’investigation numérique et le suivi des tickets de
sécurité sont centralisés sur la plateforme de gestion d’incidents DFIR-IRIS.
C’est dans ce cadre de défense en profondeur que s’inscrit le présent projet de fin d’études, intitulé
:
« Mise en place d’une solution SOC moderne avec automatisation SOAR et gestion des
incidents DFIR»

Les objectifs principaux de ce travail sont les suivants :

— Déployer un environnement de simulation complet et virtualisé sous VMware Workstation ;
— Assurer le filtrage réseau et la détection d’intrusions à l’aide de pfSense et Suricata ;
— Centraliser et analyser les journaux d’événements des serveurs et des hôtes grâce au SIEM
Wazuh ;

1
Liste des tableaux

— Superviser la disponibilité de l’infrastructure et remonter les alertes techniques via Zabbix ;

— Automatiser la réponse aux incidents (blocage par Fail2Ban, alertes Slack) en concevant des
workflows d’orchestration sur Shuffle ;
— Centraliser le suivi des investigations et la remédiation des cyberattaques sur DFIR-IRIS.
Ce mémoire est structuré comme suit :
— Le chapitre 1 présente le cadre du projet, l’organisme d’accueil (l’Aéroport International de
Sfax), la problématique identifiée et les objectifs poursuivis.
— Le chapitre 2 dresse un état de l’art des concepts clés de la cybersécurité : l’architecture
d’un SOC, les principes du SIEM, du SOAR, de la supervision et de la réponse aux incidents
(DFIR).
— Le chapitre 3 décrit l’analyse des besoins, la spécification des exigences et la conception
de l’architecture technique globale ainsi que les interactions entre les différents outils.
— Le chapitre 4 est dédié à la mise en œuvre pratique, détaillant l’installation et la configuration
de la stack technique, les scénarios d’attaques simulés, les tests d’automatisation et les
résultats obtenus.
— Enfin, une conclusion générale récapitule les acquis de ce projet et propose des perspectives
d’amélioration pour l’infrastructure de l’aéroport.
Ce travail représente une application concrète et multidisciplinaire des compétences acquises tout
au long du Master en Sécurité Réseaux et Cloud Computing, et constitue une réponse pratique et
innovante aux défis de la cybersécurité dans le secteur des infrastructures critiques.

2
 ChaPItre 1

PREsenTaTIon généRaLE DU PRojeT

Plan
1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Contexte et enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

6 Méthodologie adaptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapitre 1. Présentation générale du projet

Introduction

Le présent projet intitulé « Mise en place d’une solution SOC moderne avec automatisation
SOAR et gestion des incidents DFIR » a été réalisé au sein de l’organisme d’accueil l’Aéroport International
de Sfax. Ce projet a pour ambition de renforcer la posture de sécurité et la résilience de l’infrastructure
informatique aéroportuaire par la conception et la mise en œuvre d’un Centre d’Opérations de Sécurité
(SOC) complet. Cette solution combine la surveillance réseau et hôte en temps réel, la supervision de la
disponibilité des équipements, l’orchestration automatisée des contre-mesures et la gestion centralisée
des incidents.

1.1 Cadre du projet

Le présent projet a été proposé dans le cadre d’un projet de fin d’études pour l’obtention du
Diplôme de Master en Sécurité Réseaux et Cloud Computing, dispensé par la Faculté des
Sciences de Sfax. Ce projet s’est déroulé au sein de l’organisme public de gestion aéroportuaire,
spécifiquement affecté à l’**Aéroport International de Sfax**.

1.1.1 Organisme d’accueil

[Link] Fiche identificatrice de l’Aéroport International de Sfax

Dans le tableau 1.1, nous présentons les principales informations relatives à l’organisme d’accueil
de ce projet, géré sous la tutelle de l’Office de l’Aviation Civile et des Aéroports (OACA) au niveau de
l’Aéroport International de Sfax.

Tableau 1.1 : Fiche identificatrice de l’Aéroport International de Sfax

Organisme de tutelle Office de l’Aviation Civile et des Aéroports (OACA)

Structure d’accueil Aéroport International de Sfax-Thyna

Adresse Sfax 3000, Tunisie (à environ 6.5 km au sud-ouest de Sfax)

Téléphone +216 74 278 000

Secteur Transport Aérien et Infrastructures Critiques

[Link] Présentation de l’organisme

L’Aéroport International de Sfax-Thyna est une infrastructure de transport aérien tunisienne

clé, gérée par l’Office de l’Aviation Civile et des Aéroports (OACA). En tant qu’infrastructure d’importance
vitale, l’aéroport s’appuie sur un système d’information critique et interconnecté pour assurer la gestion
des opérations au sol, le traitement des passagers, la logistique de fret, ainsi que la communication et

4
Chapitre 1. Présentation générale du projet

la coordination avec la navigation aérienne.

[Link] Secteurs d’activité et enjeux informatiques

Les principaux domaines technologiques et opérationnels de l’Aéroport International de Sfax

incluent :
— Gestion des infrastructures réseaux : Maintenance de serveurs locaux, routeurs, commutateurs
et équipements de connectivité essentiels.
— Disponibilité des services : Garantie de la continuité d’activité 24/7 pour les applications
métiers opérationnelles.
— Sécurité périmétrique et interne : Protection des données sensibles face aux accès non
autorisés et aux tentatives d’intrusion cybernétique.
— Conformité et souveraineté : Respect des normes de sécurité nationales et internationales
de l’aviation civile en matière de protection des données critiques.

1.2 Contexte et enjeux

Dans un contexte marqué par la recrudescence et la sophistication des cyberattaques ciblant les
infrastructures de transport et les administrations publiques, la sécurisation des systèmes informatiques
aéroportuaires est devenue une priorité absolue. Les menaces telles que les attaques par déni de service
(DDoS), les rançongiciels (Ransomwares), les scans de vulnérabilités et les compromissions d’accès
internes peuvent paralyser des services essentiels.
Pour une infrastructure critique comme l’Aéroport de Sfax, la mise en place de simples barrières
statiques (pare-feux traditionnels) est insuffisante. Il est indispensable d’obtenir une visibilité continue et
corrélée sur l’ensemble de l’activité du réseau et des serveurs. De plus, la détection des menaces doit
s’accompagner d’une capacité de réaction immédiate pour contenir les incidents avant qu’ils n’impactent
la continuité des vols et la sécurité des données.
La mise en place d’un SOC (Security Operations Center) moderne répond précisément à ce
défi en centralisant la collecte des événements, en supervisant l’état des systèmes et en orchestrant de
manière automatique les réponses de remédiation face aux incidents identifiés.

1.3 Étude de l’existant

1.3.1 Pratiques actuelles

L’analyse préliminaire des mécanismes de sécurité et de surveillance de l’infrastructure révèle :

— Une gestion fragmentée des journaux d’événements (logs), obligeant les administrateurs à

5
Chapitre 1. Présentation générale du projet

consulter manuellement et de manière isolée chaque équipement en cas d’anomalie.

— L’absence d’un moteur de corrélation centralisé permettant de lier une activité réseau
suspecte à un comportement anormal sur un serveur.
— Une visibilité limitée sur les tentatives d’intrusion en temps réel au niveau des flux réseau
internes et des configurations des serveurs.
— Une dépendance vis-à-vis d’une gestion des incidents entièrement manuelle, augmentant le
temps de détection et de confinement (MTTD/MTTR) face à des attaques rapides.

1.3.2 Périmètre et limites

Le projet se focalise sur les axes techniques suivants :

— La construction d’un environnement virtuel de simulation et de test complet sous VMware
Workstation.
— Le déploiement et la configuration d’une suite de solutions open source de premier plan :
pfSense, Suricata, Wazuh, Zabbix, Shuffle, DFIR-IRIS, Fail2Ban et Slack.
— L’interconnexion de ces outils pour assurer un flux d’informations continu de la détection à
la résolution.
Les principales limites initiales résident dans la complexité de l’interfaçage de solutions hétérogènes
et la nécessité de concevoir des scénarios d’automatisation rigoureux pour éviter les faux positifs qui
surchargeraient les équipes opérationnelles.

1.4 Problématique

Comment concevoir et implémenter un Centre d’Opérations de Sécurité (SOC) complet, intégré

et adapté aux exigences d’une infrastructure critique, capable de centraliser les événements réseau
et système, d’assurer une supervision continue des performances, tout en orchestrant des réponses
automatisées et coordonnées face aux incidents cybernétiques pour minimiser l’impact opérationnel ?

1.5 Solution proposée

Pour répondre précisément à cette problématique, une architecture de sécurité multicouche et

résiliente a été développée autour des composants suivants :
— Sécurité périmétrique et NIDS : Déploiement de la solution de routage et de pare-feu
pfSense pour segmenter le réseau de simulation, associée à Suricata pour l’analyse du trafic
en temps réel et la détection des menaces réseau.
— Centralisation SIEM et HIDS : Utilisation de la plateforme Wazuh (agents et manager)

6
Chapitre 1. Présentation générale du projet

pour collecter les journaux d’événements des serveurs, surveiller l’intégrité des fichiers système
et détecter les anomalies de comportement des hôtes.
— Supervision de l’infrastructure : Intégration de la solution de monitoring Zabbix afin
de veiller à la disponibilité continue des équipements techniques et de remonter les alertes liées
aux pannes ou surcharges.
— Orchestration SOAR : Configuration de la plateforme Shuffle pour interconnecter le
SIEM avec les outils de réponse, permettant d’automatiser les flux de traitement des alertes
critiques sans intervention humaine initiale.
— Réponse réactive et notification : Mise en œuvre de mécanismes de blocage dynamique
via Fail2Ban combinés à l’envoi d’alertes enrichies en temps réel sur des canaux de communication
dédiés Slack.
— Gestion des incidents et DFIR : Déploiement de l’outil de gestion de tickets d’incidents
DFIR-IRIS, permettant de documenter, d’analyser et de centraliser le suivi des enquêtes
numériques menées par l’analyste SOC.
Cette démarche structurée fournit une solution de défense en profondeur, renforçant la visibilité et la
proactivité des équipes face aux menaces numériques.

1.6 Méthodologie adaptée

Le choix d’une méthodologie de développement constitue une décision stratégique majeure dans
la conduite d’un projet informatique. Bien qu’il existe plusieurs approches possibles, il est essentiel de
procéder à une comparaison afin d’identifier celle qui s’adapte le mieux au contexte de l’implémentation
de cette architecture SOC.
Dans un premier temps, une étude comparative des principales méthodologies de gestion de projet
sera présentée. Ensuite, l’accent sera mis sur la méthodologie Agile, qui a été retenue pour ce projet, avec
une analyse détaillée de ses principes ainsi qu’une justification de son adoption.

1.6.1 Étude comparative des méthodologies

Le tableau ci-dessous présente une comparaison entre différentes méthodologies de gestion de

projet, en tenant compte de critères tels que la flexibilité, la gestion des risques, l’implication des parties
prenantes et la fréquence des livrables.

7
Chapitre 1. Présentation générale du projet

Tableau 1.2 : Comparaison des méthodologies

Méthode Principe Points Forts Points Faibles

Classique Séquentiel, étapes figées. Organisation claire, Rigide, pas de retour

documentation. client.

Unifié Itératif, basé sur Gestion des risques, Lourd, très administratif.
l’architecture. solide.

Agile Cycles courts, Flexible, livraison rapide. Demande beaucoup de

collaboratif. temps client.

1.6.2 Justification du choix de la méthodologie Agile

Après l’étude comparative établie, nous avons décidé de piloter notre projet avec la méthodologie
Agile, et plus précisément avec la méthode Scrum, car ses particularités techniques répondent précisément
aux contraintes d’interconnexion de notre stack technologique.
Le déploiement successif d’outils complexes (comme Wazuh, Shuffle ou DFIR-IRIS) nécessite
une approche modulaire. Diviser la durée du projet en intervalles courts, appelés itérations ou sprints,
permet de configurer, valider et tester chaque interconnexion séparément. Cela facilite grandement
l’isolement des dysfonctionnements (problèmes de flux réseau, erreurs d’API) et garantit la livraison
progressive d’un SOC fonctionnel.
La méthodologie Scrum repose sur trois rôles principaux : Scrum Master, Product Owner
et équipe de développement. L’objectif est de générer une valeur métier ou une avancée technique
concrète à chaque fin de sprint.

Les rôles sont définis comme suit dans notre contexte :

— Product Owner : Il porte la vision du produit de sécurité à réaliser. Il définit les exigences
prioritaires de l’infrastructure (ex : prioriser la remontée des logs de pfSense avant la mise en
œuvre de Shuffle) et valide le bon fonctionnement des livrables.
— Scrum Master : Il assure la bonne application de la méthode Scrum, supprime les obstacles
organisationnels ou techniques qui entravent la progression et joue un rôle de facilitateur pour
optimiser la productivité globale.
— Équipe de développement : Elle a pour mission de traduire les exigences du Product
Owner en briques d’infrastructure opérationnelles. Elle configure les outils, écrit les scripts
d’automatisation et valide l’architecture technique.

8
Chapitre 1. Présentation générale du projet

Figure 1.1 : Étapes et processus de la méthode Scrum appliquée au projet

La figure 1.1 illustre les différentes étapes de la méthode Scrum. Elle met en évidence le
déroulement cyclique des sprints, favorisant une validation continue de chaque outil déployé et une
amélioration progressive des règles de corrélation de notre SOC.
Afin d’assurer un suivi rigoureux, Scrum repose sur quatre événements essentiels :
— Sprint : Cycle de travail de deux à quatre semaines maximum durant lequel une brique
technique spécifique de l’architecture SOC (par exemple, la configuration des workflows
Shuffle) est finalisée et testée.
— La mêlée quotidienne (Daily Scrum) : Réunion quotidienne rapide de 15 minutes
permettant de faire le point sur les configurations de la veille, les tâches du jour et de
lever rapidement les blocages techniques (ex : un port réseau bloqué sur VMware).
— La planification de sprint (Sprint Planning) : Réunion au cours de laquelle les objectifs
techniques et les outils à intégrer lors du prochain sprint sont sélectionnés et planifiés.
— La revue de sprint (Sprint Review) : Organisée à la fin de chaque itération, elle permet
de faire la démonstration des fonctionnalités de sécurité implémentées (ex : démonstration
d’un blocage réussi suite à une fausse attaque) et de collecter les validations nécessaires.

Conclusion

Ce premier chapitre a permis de cadrer clairement le projet en présentant l’organisme d’accueil

qu’est l’Aéroport International de Sfax, son infrastructure ainsi que les défis critiques liés à la protection
de ses systèmes d’information. L’étude de l’existant a mis en exergue le besoin d’une surveillance
centralisée et d’une automatisation réactive face aux menaces actuelles, légitimant la conception d’une
architecture SOC moderne.

9
Chapitre 1. Présentation générale du projet

La problématique posée met l’accent sur la nécessité de corréler efficacement la supervision,

la détection réseau/hôte et la gestion des incidents. La solution globale proposée, s’appuyant sur
l’interconnexion intelligente d’outils open source complémentaires pilotée par une méthodologie Scrum,
pose les fondations des chapitres suivants dédiés à l’analyse et à la mise en œuvre pratique de la solution.

10
 ChaPItre 2

ÉTaT DE L’aRT

Plan
1 Concepts fondamentaux du SOC moderne ..................................................................12

2 Limitations des approches traditionnelles de surveillance.......................................13

3 Étude comparative des outils de la solution SOC .......................................................13

4 La dimension humaine et culturelle du SOC ............................................................... 18

Chapitre 2. État de l’art

Introduction

Ce chapitre présente un état de l’art des concepts, des technologies et des stratégies modernes liés
à la surveillance continue et à la réponse aux incidents au sein d’une infrastructure critique. Il couvre les
fondements d’un Centre d’Opérations de Sécurité (SOC), l’analyse des approches traditionnelles de
surveillance, ainsi que l’étude comparative des solutions de détection, d’orchestration (SOAR) et de
gestion des incidents (DFIR) retenues pour garantir la résilience du système.

2.1 Concepts fondamentaux du SOC moderne

Un Centre d’Opérations de Sécurité (SOC) est une structure centralisée chargée de superviser,
d’évaluer et de défendre la posture de sécurité d’une organisation. Face à l’évolution des cybermenaces,
le SOC moderne a évolué d’une simple cellule de collecte de journaux vers une architecture proactive
reposant sur quatre piliers technologiques majeurs.

2.1.1 La centralisation et la corrélation (SIEM)

Le SIEM (Security Information and Event Management) constitue le cœur analytique du SOC.
Son rôle est de collecter en temps réel les journaux d’événements (logs) générés par les hôtes, les
applications et les équipements réseau. Il normalise ces données et applique des règles de corrélation
complexes pour identifier des comportements suspects qu’un outil isolé ne pourrait détecter (par exemple,
la corrélation entre plusieurs échecs de connexion réseau et une modification de fichier système).

2.1.2 La détection d’intrusions (NIDS et HIDS)

Pour alimenter le SOC en alertes qualifiées, la défense en profondeur impose deux types de
capteurs :
— Les NIDS (Network Intrusion Detection System) : Analysent le trafic réseau en temps
réel, à la recherche de signatures d’attaques (scans de ports, flux malveillants, exfiltration).
— Les HIDS (Host Intrusion Detection System) : Surveillent l’intérieur même des
machines (intégrité des fichiers sensibles, exécution de commandes suspectes, politiques de
sécurité locales).

2.1.3 L’orchestration et l’automatisation (SOAR)

Le SOAR (Security Orchestration, Automation and Response) répond à la problématique de

la surcharge d’alertes (alert fatigue). Il permet d’interconnecter les outils de détection avec les

12
Chapitre 2. État de l’art

outils de remédiation à l’aide de scénarios automatisés appelés Playbooks ou Workflows. Cela réduit
drastiquement le temps moyen de réponse (MTTR) en bloquant instantanément une menace évidente sans
intervention humaine.

2.1.4 La gestion des incidents et l’investigation (DFIR)

Le DFIR (Digital Forensics and Incident Response) englobe la méthodologie d’analyse après une
attaque. Un SOC mature nécessite une plateforme de gestion des cas pour centraliser les preuves
numériques, documenter les étapes d’investigation, suivre la chronologie de l’intrusion et standardiser la
phase de remédiation.

2.2 Limitations des approches traditionnelles de surveillance

L’analyse des architectures de supervision classiques met en évidence plusieurs faiblesses structurelles
qui compromettent la réactivité des équipes de sécurité, en particulier dans les environnements hébergeant
des infrastructures critiques :
— Le cloisonnement des outils : Les pare-feux, les moniteurs de performance et les systèmes
de logs fonctionnent en silos, empêchant une vision globale de la menace.
— La passivité face aux attaques : Les alertes sont souvent stockées pour un audit a
posteriori, plutôt que de déclencher des contre-mesures immédiates.
— Le manque de traçabilité : L’absence d’une plateforme d’investigation centralisée entraîne
une perte de données cruciales lors de l’analyse post-mortem d’un incident.
— La latence humaine : Compter uniquement sur une intervention manuelle pour bloquer
une adresse IP attaquante laisse une fenêtre d’action trop large aux scripts malveillants.

2.3 Étude comparative des outils de la solution SOC

Cette section présente une étude comparative des technologies open source sélectionnées pour
l’architecture du SOC, organisée par domaine fonctionnel.

2.3.1 Filtrage et détection réseau : pfSense vs iptables/OVS

La sécurité périmétrique et la segmentation des flux constituent la première ligne de défense de

l’infrastructure.

13
Chapitre 2. État de l’art

Tableau 2.1 : Comparaison des solutions de filtrage réseau

Critère pfSense iptables / Open

vSwitch
Interface de gestion Interface web intuitive et Ligne de commande
centralisée complexe

Fonctionnalités Pare-feu, routage, VPN, Filtrage de paquets pur,

intégration de packages nécessite des outils tiers

Intégration IDS/IPS Native (via packages Complexe, nécessite une

Suricata/Snort) configuration manuelle

2.3.2 Analyse réseau en temps réel : Suricata vs Snort

Pour l’analyse approfondie du trafic réseau (NIDS), deux moteurs open source de référence
s’affrontent.

Tableau 2.2 : Comparaison entre Suricata et Snort

Critère Suricata Snort (Version 2.9/3)

Architecture moteur Multi-threadé (haute Mono-threadé par défaut
performance sur CPU (historique)
modernes)

Analyse de fichiers Extraction et inspection de Limité ou nécessite des

fichiers intégrées modules

Format des règles Entièrement compatible Format natif unique

avec le format Snort

2.3.3 Centralisation SIEM et HIDS : Wazuh vs ELK Stack native

La collecte et la corrélation des événements au niveau des hôtes nécessitent un moteur spécialisé
en sécurité.

14
Chapitre 2. État de l’art

Tableau 2.3 : Comparaison entre Wazuh et la Stack ELK classique

Critère Wazuh ELK Stack

(Elasticsearch,
Logstash, Kibana)

Orientation native Conçu spécifiquement pour Moteur de recherche de

la sécurité (SIEM/HIDS) logs généraliste

Fonctionnalités de Analyse d’intégrité (FIM), Nécessite le développement

sécurité conformité, détection de de règles personnalisées
rootkits

Réponse active Intégrée (exécution de Nécessite des modules

scripts de blocage sur externes ou licences
l’agent) payantes

2.3.4 Supervision de la disponibilité : Zabbix vs Nagios

Bien que le SOC se concentre sur la sécurité, la supervision de la performance est indispensable
pour détecter les dénis de service ou les anomalies de ressources.

Tableau 2.4 : Comparaison des outils de supervision d’infrastructure

Critère Zabbix Nagios

Configuration Entièrement via interface Fichiers de texte
web, templates riches complexes, courbe abrupte

Modèle de collecte Pull et Push (Agents légers Principalement basé sur

et performants) des scripts de vérification
(Pull)

Graphiques et Visuels Graphiques dynamiques et Basique, nécessite souvent

natifs de haute qualité des plugins tiers

2.3.5 Orchestration SOAR : Shuffle vs Node-RED

L’automatisation des flux d’alertes nécessite un outil d’orchestration capable de manipuler

facilement les API de sécurité.

15
Chapitre 2. État de l’art

Tableau 2.5 : Comparaison des plateformes d’automatisation

Critère Shuffle Node-RED

Spécification Cyber Conçu nativement comme Automatisation généraliste

un SOAR open-source (IoT, domotique)

Partage de workflows Hub communautaire dédié Partage de nœuds

aux outils de sécurité génériques

Gestion des API Intégration simplifiée via Nécessite du code

OpenAPI/Swagger JavaScript personnalisé

2.3.6 Gestion des incidents DFIR : DFIR-IRIS vs TheHive

Pour l’investigation numérique et le suivi des tickets d’incidents, l’interface doit être structurée
pour les analystes.

16
Chapitre 2. État de l’art

Tableau 2.6 : Technologies sélectionnées et justifications pour l’architecture SOC

Composant Technologie Justification de l’intégration

choisie

Virtualisation VMware Permet d’isoler et de simuler un réseau

Workstation local d’entreprise réaliste
(LAN/WAN/DMZ) sur une seule
machine hôte.

Sécurité pfSense Assure le pare-feu, la segmentation

Périmétrique réseau et centralise la collecte des flux
frontaliers.

Analyse Réseau Suricata Inspecte les paquets en profondeur à

(NIDS) la recherche de signatures d’attaques
réseau, directement interconnecté avec
pfSense.

SIEM / HIDS Wazuh Centralise les alertes de Suricata,

collecte les logs des agents serveurs et
détecte les anomalies système.

Supervision Tech Zabbix Surveille l’état de santé des machines

(CPU, RAM, disponibilité) pour
identifier les dénis de service ou pannes
connexes.

Orchestration SOAR Shuffle Reçoit les alertes critiques de Wazuh et

déclenche automatiquement des actions
de blocage et de notification via API.

Contre-mesures Fail2Ban / Slack Fail2Ban applique les bannissements

d’IP réactifs ; Slack notifie
instantanément les analystes du SOC.

Gestion DFIR DFIR-IRIS Fournit l’interface de ticketing pour

documenter les cyberattaques, suivre
les investigations et archiver les
rapports.

17
Chapitre 2. État de l’art

2.4 La dimension humaine et culturelle du SOC

L’implémentation d’un SOC ne se limite pas au déploiement d’outils techniques. L’efficacité de

la structure repose sur la définition claire des processus opérationnels et la coordination humaine.
L’automatisation apportée par le SOAR (Shuffle) ne remplace pas l’analyste, elle lui permet de se
libérer des tâches répétitives pour se concentrer sur l’investigation approfondie sur DFIR-IRIS.
L’organisation d’un SOC implique la mise en place de procédures standardisées (SOP - Standard
Operating Procedures) décrivant précisément les actions à mener pour chaque type d’alerte, garantissant
ainsi une conformité et une efficacité constante face aux crises cybernétiques.

Conclusion

Ce deuxième chapitre a permis de dresser un panorama complet de l’état de l’art concernant

l’architecture des SOC et la gestion des cyberattaques. L’étude comparative a mis en évidence la
pertinence d’associer la puissance de détection de Wazuh et Suricata à la flexibilité d’orchestration
de Shuffle et à la structure méthodologique de DFIR-IRIS. Cette maîtrise théorique des interactions entre
les composants pose les fondations techniques indispensables pour le prochain chapitre, dédié à l’analyse
fonctionnelle et à la conception détaillée de l’architecture de sécurité.

18
 ChaPItre 3

SPEcIFIcaTIon eT anaLyse des besoIns

Plan
1 Objectifs du projet ............................................................................................................... 20

2 Identification des intervenants ......................................................................................... 20

3 Analyse des besoins ..............................................................................................................21

4 Architecture de la solution ............................................................................................... 22

5 Composants détaillés de l’architecture.......................................................................... 23

Chapitre 3. Spécification et analyse des besoins

Introduction

Après avoir présenté le cadre général du projet ainsi que l’état de l’art des technologies SOC
et DFIR, il est désormais nécessaire de définir précisément les besoins fonctionnels et techniques de la
solution proposée. Cette étape d’analyse permet d’identifier les exigences de sécurité, de supervision
et d’automatisation nécessaires à la mise en œuvre d’une architecture SOC moderne adaptée à un
environnement aéroportuaire critique.
Ce chapitre présente ainsi les objectifs du projet, les différents acteurs impliqués, les besoins
fonctionnels et non fonctionnels, ainsi que l’architecture globale retenue pour assurer la surveillance,
la détection et la réponse automatisée aux incidents de sécurité.

3.1 Objectifs du projet

L’objectif principal de ce projet est de concevoir et de déployer une architecture SOC moderne
capable d’assurer une surveillance continue de l’infrastructure, de détecter les activités malveillantes
en temps réel et d’automatiser les mécanismes de réponse aux incidents de cybersécurité.
La solution proposée vise également à renforcer la visibilité sur l’ensemble du système d’information
aéroportuaire tout en améliorant la réactivité des équipes face aux menaces numériques.
Plus précisément, cette architecture doit permettre :
— La mise en place d’un environnement virtualisé complet sous VMware Workstation afin
de simuler une infrastructure réseau réaliste ;
— Le déploiement d’une sécurité périmétrique basée sur pfSense associée à Suricata pour
l’analyse et la détection des intrusions réseau ;
— La centralisation et la corrélation des journaux d’événements via le SIEM Wazuh ;
— La supervision continue des équipements et des ressources systèmes grâce à Zabbix ;
— L’automatisation des workflows de réponse aux incidents via la plateforme SOAR Shuffle ;
— Le blocage dynamique des comportements malveillants à l’aide de Fail2Ban ;
— La notification instantanée des alertes critiques via Slack ;
— La gestion centralisée des incidents et des investigations numériques avec DFIR-IRIS.

3.2 Identification des intervenants

La réussite du projet repose sur la collaboration entre plusieurs intervenants ayant des responsabilités
complémentaires.
— Encadrants académiques : Supervisent l’avancement du projet, valident les choix techniques

20
Chapitre 3. Spécification et analyse des besoins

et assurent le suivi méthodologique.

— Administrateurs systèmes et réseaux : Gèrent l’infrastructure virtualisée, la configuration
des équipements réseau et le déploiement des services de sécurité.
— Analystes SOC : Supervisent les alertes de sécurité, analysent les événements suspects et
assurent le suivi des incidents.
— Équipe sécurité : Met en œuvre les politiques de sécurité, configure les outils SIEM/SOAR
et participe aux investigations numériques.
— Utilisateur final / Organisme d’accueil : Représente les besoins opérationnels liés à la
sécurisation de l’infrastructure aéroportuaire.

3.3 Analyse des besoins

Les besoins identifiés dans le cadre du projet ont été classés en deux catégories : les besoins
fonctionnels et les besoins non fonctionnels.

3.3.1 Besoins fonctionnels

Les besoins fonctionnels représentent les services et fonctionnalités que la solution SOC doit
fournir.
— Déployer une infrastructure virtualisée sous VMware Workstation ;
— Assurer le filtrage et la segmentation du réseau via pfSense ;
— Détecter les attaques réseau en temps réel grâce à Suricata ;
— Collecter et centraliser les journaux système et réseau avec Wazuh ;
— Superviser les performances et la disponibilité des équipements à l’aide de Zabbix ;
— Automatiser les réponses aux incidents via Shuffle ;
— Bloquer automatiquement les adresses IP malveillantes avec Fail2Ban ;
— Envoyer des alertes et notifications en temps réel sur Slack ;
— Centraliser la gestion des incidents et les investigations numériques avec DFIR-IRIS.

3.3.2 Besoins non fonctionnels

Les besoins non fonctionnels définissent les contraintes de qualité, de performance et de sécurité
que doit respecter la solution.
— Assurer une haute disponibilité des services de supervision et de sécurité ;
— Garantir la confidentialité et l’intégrité des données collectées ;
— Fournir une architecture modulaire et évolutive ;

21
Chapitre 3. Spécification et analyse des besoins

— Réduire le temps de détection et de réponse aux incidents (MTTD/MTTR) ;

— Assurer une supervision centralisée et ergonomique ;
— Garantir la compatibilité avec les environnements Linux et les solutions open source ;
— Automatiser les tâches répétitives afin de limiter les erreurs humaines ;
— Fournir une documentation claire et maintenable pour faciliter l’exploitation future de la
plateforme.

3.4 Architecture de la solution

L’architecture proposée repose sur un environnement virtualisé sous VMware Workstation,

permettant de simuler une infrastructure réseau sécurisée composée de plusieurs machines virtuelles
interconnectées.
La sécurité périmétrique est assurée par pfSense, utilisé comme pare-feu et routeur principal.
Le trafic réseau est inspecté en temps réel par Suricata, chargé de détecter les comportements suspects
et les signatures d’attaques.
Les événements de sécurité générés par les équipements et les serveurs sont centralisés au sein du
SIEM Wazuh, qui assure également des fonctions HIDS telles que la surveillance d’intégrité et l’analyse
des journaux système.
La supervision de l’état des équipements, des ressources systèmes et de la disponibilité des
services est réalisée à travers Zabbix.
Afin d’automatiser les mécanismes de réponse aux incidents, la plateforme Shuffle orchestre les
interactions entre les différents composants de sécurité. En cas d’alerte critique, des actions automatiques
peuvent être déclenchées, comme le bannissement d’une adresse IP via Fail2Ban ou l’envoi d’une
notification sur Slack.
Enfin, les investigations numériques et le suivi des incidents sont centralisés sur la plateforme
DFIR-IRIS, permettant aux analystes SOC de documenter les événements de sécurité et de suivre
les procédures de remédiation.

22
Chapitre 3. Spécification et analyse des besoins

Figure 3.1 : Architecture globale de la solution SOC

3.5 Composants détaillés de l’architecture

Les principaux composants de l’architecture SOC sont les suivants :

— VMware Workstation : Plateforme de virtualisation utilisée pour héberger et isoler les
différentes machines virtuelles du laboratoire SOC.
— pfSense : Pare-feu et routeur assurant la segmentation réseau, le filtrage des flux et la
sécurité périmétrique.
— Suricata : Système NIDS chargé d’inspecter le trafic réseau et de détecter les activités
malveillantes.
— Wazuh : Solution SIEM/HIDS assurant la collecte des logs, la corrélation des événements
et la surveillance des hôtes.
— Zabbix : Outil de supervision permettant de surveiller les performances et la disponibilité

23
Chapitre 3. Spécification et analyse des besoins

des équipements.
— Shuffle : Plateforme SOAR utilisée pour automatiser les workflows de réponse aux incidents.
— Fail2Ban : Solution de blocage dynamique des adresses IP suspectes.
— Slack : Plateforme de communication utilisée pour la diffusion des alertes et notifications
SOC.
— DFIR-IRIS : Plateforme de gestion des incidents et des investigations numériques.

Conclusion

Ce chapitre a permis d’identifier les objectifs principaux du projet ainsi que les besoins fonctionnels
et non fonctionnels nécessaires à la conception d’une architecture SOC moderne et automatisée.
L’analyse réalisée a également permis de définir les différents composants de la solution ainsi que
leurs interactions au sein de l’environnement virtualisé.
Cette phase de spécification constitue une base essentielle pour la suite du projet, notamment pour
la conception détaillée et la mise en œuvre pratique de l’infrastructure de sécurité présentées dans le
chapitre suivant.

24
 ChaPItre 4

RéaLIsaTIon

Plan
1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Mise en place du SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapitre 4. Réalisation

Introduction

Ce chapitre constitue le corpus principal de ce travail où nous allons présenter la partie réalisation
tout en donnant un aperçu sur l’environnement de notre travail. Nous commençons par décrire en détail
l’environnement matériel et logiciel utilisé tout au long du processus de mise en place de notre solution.
Enfin, nous mettons en relief la démarche suivie pour mettre en œuvre notre solution, accompagnée
de quelques captures d’écran montrant ses principales fonctionnalités.

4.1 Environnement de travail

Pour savoir les conditions de travail, il est nécessaire de mentionner les caractéristiques de l’outil
de travail. C’est un PC portable msi ayant dans le tableau 4.1 :

Tableau 4.1 : Configuration matérielle

Composant Configuration minimale
Processeur Intel® Core i5, 2 GHz
RAM 32 Go
Disque dur 1 To SDD
Système d’exploitation Windows 10

4.2 Environnement logiciel

En outre, nous avons mis en place cinq machines virtuelles :

4.2.1 Windows Server

Windows Server offre une variété de rôles et de fonctionnalités pour satisfaire les besoins variés
des environnements serveurs.

4.2.2 Kali Linux 2024

Kali Linux se concentre sur la sécurité informatique et le piratage éthique dans sa distribution
Linux.

4.2.3 Ubuntu

Ubuntu est une distribution Linux très appréciée, largement utilisée à l’échelle mondiale.

26
Chapitre 4. Réalisation

4.2.4 Wazuh Master

Le Wazuh Master est un composant central dans l’architecture de surveillance de la sécurité de

Wazuh, fournissant une gestion centralisée, une analyse des données et des fonctionnalités de réponse
aux incidents pour aider à protéger les environnements informatiques contre les menaces.

4.2.5 Suricata

Suricata est un moteur open source de détection et de prévention d’intrusions (IDS/IPS) et de

surveillance de la sécurité réseau. Il est utilisé pour détecter et prévenir les attaques réseau en temps réel,
telles que les injections SQL, les attaques XSS et les attaques par force brute.

4.2.6 hping3

hping3 est un outil de génération et d’analyse de paquets réseau, souvent utilisé pour tester les
pare-feu et les systèmes de détection d’intrusions. Il permet de simuler des attaques réseau, telles que les
attaques par déni de service (DoS), pour évaluer la résilience des infrastructures.

4.3 Mise en place du SOC

L'architecture SOC repose sur les étapes suivantes, la surveillance réseau est assurée par Suricata
(IDS/IPS) et la sécurisation par Wazuh Master, qui reçoit et corrèle les logs système (via agents
Wazuh) ainsi que les alertes réseau de Suricata. Les alertes générées sont ensuite transmises au moteur
IRIS pour orchestration, enrichies par les IOC provenant de MISP et traitées par la plateforme Shuffle
pour investigation et remédiation (enrichissement via VirusTotal API, notifications Slack, partage
d’IOCs).
Enfin, dans l’étape finale, une VM Kali Linux KaliLinux simule des attaques (pentesting,
SSRF, etc.) pour valider la robustesse et l’efficacité de l’ensemble de la chaîne de détection et de réponse
du SOC.

27
Chapitre 4. Réalisation

4.3.1 Mettre à jour le système et installer les prérequis

4.3.2 Configuration pfsense

Figure 4.1 : terminale pfsense

4.3.3 Configuration pfsense

Figure 4.2 : interface web pfsense

4.3.4 Installer Docker

L’installation de Docker est une étape essentielle pour exécuter les conteneurs nécessaires au
SOC. Une fois Docker installé, il est important de vérifier que le service fonctionne correctement.

28
Chapitre 4. Réalisation

Figure 4.3 : Vérification du statut de Docker

4.3.5 Installer Wazuh (SIEM)

Cette étape peut prendre un certain temps selon la vitesse de votre connexion. Une fois
l’installation terminée, déployez l’agent Wazuh avec votre adresse IP.

Figure 4.4 : Processus d’installation de Wazuh

Pour accéder à la plateforme Wazuh, l’utilisateur est invité à se connecter via l’interface web.
Cette étape permet d’accéder aux fonctionnalités de gestion des événements de sécurité.

29
Chapitre 4. Réalisation

Figure 4.5 : Page de connexion de Wazuh

L’interface d’accueil de Wazuh permet de visualiser en temps réel les alertes et les agents
connectés.
Elle fournit une vue d’ensemble de l’état de sécurité du système.

Figure 4.6 : Page d’accueil de Wazuh

4.3.6 Installer Shuffle (SOAR)

Cette étape peut prendre un certain temps selon la vitesse de votre connexion. Une fois
l’installation terminée, déployez shuffle docker avec votre adresse IP.

30
Chapitre 4. Réalisation

Figure 4.7 : Processus d’installation de shuffle

Après le déploiement, accédez à l’interface web via l’adresse [Link]

Créez un compte administrateur pour utiliser la plateforme.

Figure 4.8 : Page d’accueil de Shuffle

4.3.7 Installer DFIR-IRIS (Gestion des incidents)

IRIS est accessible via l’interface sécurisée à l’adresse [Link]

Elle permet la gestion centralisée des incidents de sécurité.

31
Chapitre 4. Réalisation

Figure 4.9 : Page d’accueil de DFIR-IRIS

Étapes d’intégration

4.3.8 Intégration IRIS et Wazuh

Exécutez l’étape 7. Entrez la clé API IRIS (voir profil Administrateur > Mes paramètres).

Figure 4.10 : Clé API IRIS

Puis vérifiez l’intégration via le menu Alertes d’IRIS. Si "0 alerte", exécutez l’étape 14 (cas de
force brute). Rafraîchissez, une alerte devrait apparaître.

32
Chapitre 4. Réalisation

Figure 4.11 : Alerte apparaissant dans IRIS

4.3.9 Intégration MISP et Wazuh

L’intégration de MISP avec Wazuh permet de centraliser et d’automatiser la collecte des

indicateurs de compromission (IoC) partagés via MISP, afin d’améliorer la détection des menaces
au sein de Wazuh. Pour réaliser cette connexion, il est nécessaire d’exécuter l’étape 8 du processus, qui
configure l’interface entre les deux plateformes. Une fois lancée, il convient d’attendre la fin complète de
cette opération pour garantir que les échanges de données soient correctement établis et que les alertes
basées sur les IoC de MISP soient prises en compte dans Wazuh.

4.3.10 Intégration Shuffle, Wazuh et IRIS

Dans Shuffle : Workflow > Nouveau Workflow > nommez > Terminer. Cliquez sur l’icône Shuffle
> paramètre Call : exec > Enregistrer.

Figure 4.12 : Configuration du module Shuffle

Dans l’onglet Trigger, glissez Webhook au centre.

33
Chapitre 4. Réalisation

Figure 4.13 : Déploiement du module Webhook

Cliquez sur le module Webhook > copiez "Webhook URI" > cliquez sur Démarrer.

Figure 4.14 : Démarrage du Webhook

Retournez à l’installateur et collez l’URI lorsque demandé. Vérifiez dans Shuffle > Show Executions.

Figure 4.15 : Alerte Wazuh reçue dans Shuffle

34
Chapitre 4. Réalisation

Renseignez les paramètres :

— Find Actions : Add a new case
— Apikey : (votre clé API IRIS)
— Url : (votre URL IRIS)

Figure 4.16 : Paramètres IRIS

Modifier le paramètre Body :

{"case_customer": "1","case_description": "Test from Shuffle",

"case_name": "$change_me.title",
"case_soc_id": "123"
}

Figure 4.17 : Contenu du corps IRIS

35
Chapitre 4. Réalisation

Soumettre puis vérifier à nouveau Show Executions > Refresh.

Figure 4.18 : Bouton de relance

Si Status = 200, le ticket est créé avec succès.

Figure 4.19 : Automatisation de création de ticket IRIS

Vérifiez aussi sur [Link] > Gérer les cas.

36
Chapitre 4. Réalisation

Figure 4.20 : Ticket créé depuis Shuffle

Interface Dfir-iris alerts

37
Chapitre 4. Réalisation

Figure 4.21 : Alerts Dfir-Iris

Après avoir connecté toutes les machines à Wazuh, nous avons analysé les événements de sécurité
remontés par les agents.

Figure 4.22 : Dashboard wazuh

La figure 4.22 présente le tableau de bord de Wazuh, qui affiche les événements de sécurité
collectés par l’agent. On peut y visualiser les alertes, leur niveau de risque, et les détails associés à chaque
événement.
Grâce à cette surveillance en temps réel, nous avons pu détecter et analyser divers incidents de
sécurité, notamment les tentatives d’accès non autorisées, les erreurs de configuration et les vulnérabilités
potentielles.
L’intégration de Wazuh dans notre infrastructure nous permet d’assurer une gestion proactive

38
Chapitre 4. Réalisation

des menaces et d’améliorer la sécurité des systèmes monitorés.

Figure 4.23 : Dashboard wazuh état Ubuntu

La figure 4.23 montre l’état de connexion des agents dans le tableau de bord Wazuh, y compris
l’état des machines Ubuntu surveillées. On y distingue les agents actifs, déconnectés ou jamais connectés,
ce qui permet un suivi efficace des systèmes.
ID : L’identifiant unique attribué à l’agent Wazuh sur la machine et ubuntu. Cet ID est utilisé
pour identifier de manière unique chaque agent connecté au serveur Wazuh.
Name : Le nom de l’agent ou de la machine. Cela peut être le nom d’hôte de la machine ou
un nom attribué à l’agent lors de sa configuration.
IP Address : L’adresse IP de la machine et ubuntu. Cela indique l’adresse réseau de l’agent.
Group : Le groupe auquel l’agent appartient. Les groupes peuvent être utilisés pour organiser
les agents en fonction de critères tels que leur fonction, leur emplacement ou leur type de système
d’exploitation.
Operating System : Le système d’exploitation de la machine, dans ce cas, ubuntu.
Cluster : Si vous utilisez une configuration Wazuh en cluster, cela indique le nœud du cluster
auquel l’agent est connecté.
Version : La version du logiciel de l’agent Wazuh installé sur la machine.
Status : L’état actuel de l’agent. Cela peut indiquer si l’agent est en ligne, hors ligne, ou s’il
rencontre des problèmes de communication avec le serveur Wazuh.
Action : Les actions que vous pouvez effectuer sur cet agent depuis le tableau de bord, comme
la suppression de l’agent, la mise à jour des configurations, ou la consultation des logs spécifiques à cet
agent.

39
Chapitre 4. Réalisation

4.3.11 Attaque test par Kali-Linux

[Link] Attaques SSH Brute-Force

La force brute est une méthode qui consiste à essayer tous les mots de passe ou clés possibles
jusqu’à ce que le bon soit découvert. Nous avons testé la protection offerte par Wazuh Master contre une
attaque SSH brute-force.
Nous avons utilisé Kali Linux comme machine d’attaque et avons commencé par l’installation de
la machine virtuelle.

Figure 4.24 : Machine Kali-Linux

La figure 4.24 illustre l’interface graphique de la machine Kali Linux utilisée dans le cadre de
la plateforme de supervision et d’analyse de sécurité.
Avant de lancer l’attaque, nous avons surveillé le tableau de bord Wazuh.

40
Chapitre 4. Réalisation

Figure 4.25 : Tableau de bord Wazuh avant attaque

La figure 4.25 présente l’état du tableau de bord Wazuh avant la survenue de toute attaque,
mettant en évidence les événements récents, la conformité et les données système surveillées.
Nous avons utilisé Hydra, un outil de force brute déjà préinstallé sur Kali Linux, pour simuler
une tentative d’attaque SSH sur Ubuntu.

Figure 4.26 : Tentative d’attaque brute-force avec Hydra

La figure 4.26 illustre une attaque par force brute menée à l’aide de l’outil Hydra, souvent
utilisée pour tester la robustesse des identifiants d’accès.
Nous avons constaté que Wazuh a détecté et bloqué la tentative de connexion non autorisée.

41
Chapitre 4. Réalisation

Figure 4.27 : Alerte de Wazuh sur la tentative d’attaque SSH 1

La figure 4.27 met en évidence une série d’alertes générées par Wazuh suite à des tentatives de
connexion SSH échouées, indiquant des échecs d’authentification et des tentatives de connexion avec des
utilisateurs inexistants.
L’alerte détaille l’IP source de l’attaque et l’IP cible.

Figure 4.28 : Détail de l’attaque brute-force en format JSON 1

La figure 4.28 montre un exemple détaillé d’une alerte générée par Wazuh au format JSON.

42
Chapitre 4. Réalisation

On y voit des informations cruciales telles que l’adresse IP source, le programme concerné (‘sshd‘),
l’utilisateur ciblé (‘root‘) ainsi que les identifiants tactiques MITRE.

Figure 4.29 : Détail de l’attaque brute-force en format JSON 2

La figure 4.29 montre un autre exemple détaillé d’une alerte brute-force détectée par Wazuh. Elle
met en évidence le mécanisme d’analyse avec des balises comme ‘description‘, ‘mitre‘, ‘technique‘,
‘tactic‘, et ’fullLog’. Ce qui permet de faire le lien entre les tentatives d’accès et les identifiants MITRE
tels que “Credential Access“ ou “Lateral Movement“.
Jusqu’à présent, aucune attaque n’a été effectuée sur notre point final

4.3.12 Démonstration d’attaque par force brute SSH

Nous utiliserons Hydra, un outil de force brute déjà préinstallé dans Kali Linux pour simuler
un échec d’attaque par force brute ssh sur notre point de terminaison Ubuntu.

43
Chapitre 4. Réalisation

Figure 4.30 : Attaque ratée

La figure 4.30 montre l’exécution d’une commande Hydra tentant une attaque brute-force SSH.
Cette tentative échoue, confirmant que les identifiants sont incorrects. Cette simulation vise à tester la
détection d’intrusion par l’outil Wazuh, qui génère ensuite une alerte correspondante dans son tableau de
bord.
Cette commande Hydra tentera de se connecter à un serveur SSH à l’adresse IP [Link]
en utilisant le nom d’utilisateur "admin" et le mot de passe "test". Hydra : C’est le nom de l’outil,
-l [Link] : Cette option spécifie le nom d’utilisateur à utiliser pour l’attaque. Ici, l’utilisateur est "admin",
-p password : Cette option spécifie le mot de passe à essayer pour l’attaque. Dans ce cas, le mot de
passe est "test", ssh ://[Link] : Cela indique que l’attaque cible un service SSH sur l’adresse IP
[Link].
Nous avons simulé avec succès une attaque par force brute SSH échouée juste pour voir si nous
pouvions obtenir le nom d’utilisateur et le mot de passe SSH et Passons maintenant au tableau de
bord wazuh et surveillons les alertes créées.

44
Chapitre 4. Réalisation

Figure 4.31 : Tableau de bord Wazuh

La figure 4.31 illustre le tableau de bord de Wazuh affichant une alerte générée suite à une tentative
d’accès SSH échouée. Les détails incluent l’adresse IP source ([Link]), le nom d’utilisateur ciblé

(root), le service visé (sshd) et l’heure de l’événement. Ces informations permettent une corrélation rapide
avec une attaque brute-force détectée.
Nous pouvons voir que wazuh a capturé l’échec de la tentative de force brute ssh sur notre point
de terminaison Ubuntu.

4.3.13 Suricata IPS/IDS (Système de Prévention/Détection d’Intrusions)

[Link] Introduction à Suricata

Suricata est un moteur open source de détection et de prévention d’intrusions (IDS/IPS) et de

surveillance de la sécurité réseau. Il est utilisé pour détecter et prévenir les attaques réseau en temps réel.

[Link] Intégration de Suricata dans le SOC

Pour intégrer Suricata dans le Centre des Opérations de Sécurité (SOC), nous l’avons configuré
pour surveiller le trafic réseau et détecter les intrusions potentielles. Les étapes suivantes ont été réalisées
:

1. Installation de Suricata :

sudo apt-get install suricata

45
Chapitre 4. Réalisation

2. Configuration de Suricata : Nous avons configuré Suricata pour surveiller l’interface

réseau et avons défini des règles pour détecter des attaques courantes telles que les injections
SQL, les attaques XSS et les attaques par force brute. Le fichier de configuration (‘/etc/suricata/suricata.
a été modifié comme suit :

af-packet:
- interface: eth0
cluster-id: 99
cluster-type: cluster_flow

3. Intégration avec Wazuh : Nous avons intégré Suricata avec Wazuh pour centraliser la
détection et la réponse aux attaques réseau. Les alertes générées par Suricata sont transmises
à Wazuh pour une analyse approfondie et une corrélation avec d’autres événements de sécurité.

4. Résultats de la Surveillance avec Suricata : Suricata a détecté et bloqué plusieurs

attaques réseau, notamment des tentatives d’injection SQL et des attaques par force brute. Les
alertes ont été enregistrées dans Wazuh, offrant une vue centralisée de la posture de sécurité
de l’infrastructure.

4.3.14 Simulation d’une Attaque DoS

[Link] Introduction aux Attaques DoS

Une attaque par déni de service (DoS) vise à rendre une machine ou une ressource réseau
indisponible en la submergeant de requêtes illégitimes.

[Link] Simulation d’une Attaque DoS

Pour tester la résilience de l’infrastructure face aux attaques DoS, nous avons utilisé l’outil
‘hping3‘ pour simuler une attaque DoS. Les étapes suivantes ont été réalisées :

1. Installation de hping3 :

sudo apt-get install hping3

2. Simulation d’une Attaque DoS : Nous avons utilisé la commande suivante pour simuler
une attaque DoS sur le serveur cible :

46
Chapitre 4. Réalisation

hping3 -c 10000 -d 120 -S -w 64 -p 80 --flood \

--rand-source <ip-cible>

3. Surveillance de l’Attaque avec Suricata et Wazuh : Pendant l’attaque, Suricata a

détecté le flux de paquets SYN et a généré des alertes. Ces alertes ont été transmises à Wazuh,
qui a fourni une visibilité en temps réel sur l’attaque. Le tableau de bord Wazuh a affiché
les détails de l’attaque, y compris les adresses IP sources et le nombre de paquets envoyés.

4. Résultats de la Simulation d’Attaque DoS : L’infrastructure a réussi à atténuer

l’attaque DoS en limitant le trafic entrant et en bloquant les adresses IP malveillantes. Les
alertes générées par Suricata et Wazuh ont fourni des informations précieuses sur l’attaque,
permettant à l’équipe de sécurité de réagir rapidement.

Figure 4.32 : Tableau de bord Wazuh + Suricata

La figure 4.32 présente le tableau de bord Wazuh intégré à Suricata. Ce tableau affiche les alertes
générées suite à la détection de trafic réseau suspect. Les règles comme ET DROP sont déclenchées par

47
 Chapitre 4. Réalisation

Suricata lorsqu’un flux est identifié comme malveillant ou listé comme dangereux. Les alertes fournissent
des détails comme l’agent, l’horodatage, la description de la règle et son niveau de gravité.

Conclusion

Ce chapitre a présenté la mise en œuvre complète de la solution SOC dans un environnement virtualisé
sous VMware Workstation. Nous avons décrit l'environnement matériel et logiciel utilisé, puis détaillé les
étapes de déploiement et d'intégration des différents composants de l'architecture.

La surveillance réseau est assurée par pfSense pour le filtrage du trafic et Suricata pour la détection d'intrusions en
temps réel (IDS/IPS). La centralisation et l'analyse des journaux sont confiées à Wazuh, qui joue le rôle de SIEM
principal en collectant les alertes issues des agents installés sur les machines supervisées. La plateforme Shuffle
orchestre et automatise les réponses aux incidents, tandis que DFIR-IRIS assure la gestion et le suivi des tickets de
sécurité. Enfin, l'intégration de MISP enrichit les alertes avec des indicateurs de compromission (IoC) pour une
meilleure contextualisation des menaces.

Les scénarios de validation réalisés — notamment l'attaque par force brute SSH simulée avec Hydra depuis Kali Linux,
et la simulation d'une attaque DoS avec hping3 — ont confirmé l'efficacité de la chaîne de détection et de réponse mise
en place. Wazuh a détecté et enregistré chaque tentative d'intrusion, Suricata a bloqué le trafic malveillant, et Shuffle a
automatisé la création des tickets d'incidents dans DFIR-IRIS.

Ces résultats démontrent la robustesse de l'architecture SOC déployée et valident les choix technologiques effectués
tout au long de ce projet.

48
Conclusions et Perspectives

Ce projet a permis de concevoir et de mettre en place une solution SOC moderne dédiée à la
surveillance, à la détection et à la gestion des incidents de sécurité. L’architecture réalisée repose sur
l’intégration de plusieurs outils open source complémentaires, notamment Wazuh pour la centralisation
et l’analyse des journaux, Suricata pour la détection des intrusions réseau, MISP pour l’enrichissement
par les indicateurs de compromission, DFIR-IRIS pour la gestion des incidents, ainsi que Shuffle pour
l’automatisation des workflows de réponse.
La mise en place de cette solution a permis d’améliorer la visibilité sur l’infrastructure supervisée,
de détecter les comportements suspects en temps réel et de faciliter le suivi des alertes de sécurité. Les
scénarios de validation réalisés, tels que la simulation d’attaques par force brute SSH, la détection de
malware, le défacement web et l’attaque par déni de service, ont confirmé l’efficacité de la chaîne de
détection et de réponse mise en œuvre.
Au-delà des résultats techniques, ce travail nous a permis de renforcer nos compétences dans
plusieurs domaines liés à la cybersécurité, notamment l’administration des systèmes, la supervision de la
sécurité, l’analyse des journaux, la détection d’intrusions, l’orchestration des réponses et la gestion des
incidents. Il a également mis en évidence l’importance d’une approche centralisée et automatisée pour
réduire le temps de détection et de traitement des incidents.
Comme perspectives, cette solution pourrait être améliorée par l’ajout de nouveaux scénarios
d’attaque, l’enrichissement des règles de corrélation, l’intégration d’autres sources de logs et le développement
de playbooks SOAR plus avancés. Il serait également intéressant d’exploiter l’intelligence artificielle
afin d’aider à la priorisation des alertes, à la réduction des faux positifs et à l’amélioration de la prise
de décision des analystes SOC.

49
Webographie

[WS] Microsoft, Windows Server 2022 – Active Directory Domain Services DNS, Microsoft Docs,
[Link]

[VMW] VMware, Inc., VMware Workstation Pro Documentation, VMware Docs, [Link]
[Link]

[Wazuh] Wazuh, Inc., Wazuh Documentation, [Link]

[Suricata] Open Information Security Foundation, Suricata User Guide, [Link]

[MISP] MISP Project, MISP : Threat Sharing Platform Documentation, [Link]

[IRIS] DFIR-IRIS Project, DFIR-IR IS – Incident Management Documentation, https://

[Link]

[Shuffle] Shuffle Project, Shufle : SOAR Automation Platform, [Link]

[Fail2Ban] Fail2Ban Project, Fail2Ban Documentation, [Link]

[pfSense] Netgate, pfSense Documentation, [Link]

50
Bibliographie

Résumé
Avec l’évolution des cybermenaces et l’importance croissante de la protection des infrastructures
critiques, les organisations doivent disposer de solutions capables d’assurer une surveillance
continue, une détection rapide et une gestion efficace des incidents de sécurité. Ce projet présente
la conception et la mise en place d’une solution SOC moderne basée sur des outils open source.
La solution repose principalement sur Wazuh pour la centralisation et l’analyse des journaux,
Suricata pour la détection des intrusions réseau, MISP pour l’enrichissement par les indicateurs
de compromission, DFIR-IRIS pour la gestion des incidents et Shuffle pour l’automatisation des
workflows de réponse. Les scénarios de validation réalisés, tels que la détection de malware, le
défacement web, les attaques par force brute SSH et les attaques par déni de service, ont permis
de vérifier l’efficacité de la chaîne de détection, d’analyse et de réponse. Les résultats obtenus
montrent l’intérêt d’une architecture SOC centralisée et automatisée pour améliorer la visibilité,
réduire le temps de réaction et renforcer la posture de sécurité de l’infrastructure supervisée.

Mots clés : SOC, cybersécurité, SIEM, SOAR, DFIR, Wazuh, Suricata, Shuffle, MISP, détection
d’intrusions, gestion des incidents

Abstract
With the continuous evolution of cyber threats and the growing need to protect critical
infrastructures, organizations require solutions capable of providing continuous monitoring,
rapid detection and effective incident management. This project presents the design and
implementation of a modern Security Operations Center based on open-source tools. The
proposed solution mainly relies on Wazuh for log centralization and analysis, Suricata for
network intrusion detection, MISP for threat intelligence enrichment, DFIR-IRIS for incident
management and Shuffle for response workflow automation. Several validation scenarios were
carried out, including malware detection, web defacement detection, SSH brute-force attacks
and denial-of-service attacks, in order to assess the effectiveness of the detection, analysis and
response chain. The obtained results demonstrate the value of a centralized and automated
SOC architecture in improving visibility, reducing response time and strengthening the security
posture of the monitored infrastructure.
Keywords : SOC, cybersecurity, SIEM, SOAR, DFIR, Wazuh, Suricata, Shuffle, MISP, intrusion det

51