République Tunisienne

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

École Polytechnique de Sousse

Département Informatique

Année universitaire : 2025–2026

Rapport de Projet de Fin d’Études

Pour l’obtention du diplôme d’Ingénieur en Informatique

Spécialité : Cybersécurité et Systèmes d’Information

Automatisation des opérations SOC et de la réponse aux

incidents cyber
Cas des anomalies liées aux certificats électroniques
 Réalisée par : Imen Ouled Belgacem

Société d’accueil : Agence Nationale de la Cybersécurité

Encadrant académique : Dr Salah Gontara

Encadrante professionnelle : Mme Mariem Jouini

Promotion : 2025/2026

ii
Dédicaces

Je dédie ce travail à ma famille, pour son amour, sa patience et son soutien tout au long de mon parcours.

À mes parents, pour leurs sacrifices, leurs encouragements et leur confiance qui m’ont donné la

force de poursuivre mes objectifs malgré les difficultés.

À mes proches, mes amis et toutes les personnes qui ont cru en moi, je dédie ce projet avec

reconnaissance et gratitude.

Ce travail représente l’aboutissement d’un parcours fait d’efforts, d’apprentissage, de persévérance

et d’amélioration continue.

i
Remerciements

Au terme de ce Projet de Fin d’Études, je tiens à exprimer ma profonde gratitude à toutes les personnes

qui ont contribué à la réalisation de ce travail.

Je remercie mon encadrant académique, Dr Salah Gontara, pour son accompagnement, ses

orientations et ses remarques qui m’ont aidée à structurer le projet et à améliorer progressivement la

qualité de la solution proposée.

J’adresse mes remerciements les plus sincères à l’Agence Nationale de la Cybersécurité pour

m’avoir accueillie dans le cadre de mon stage de fin d’études. Cette expérience m’a permis d’évoluer

dans un contexte professionnel lié à la cybersécurité, à la supervision, à la réponse aux incidents et à la

protection des services numériques.

Je remercie particulièrement Mme Mariem Jouini, mon encadrante professionnelle, pour sa

disponibilité, son suivi et ses conseils. Son accompagnement a permis d’orienter le projet vers une

approche plus opérationnelle et plus réaliste.

Je remercie également l’équipe de l’ANCS pour les échanges enrichissants autour des opérations

SOC, des certificats électroniques et des mécanismes de supervision. Enfin, je remercie ma famille et

mes amis pour leur soutien moral et leurs encouragements constants.

ii
Résumé

Ce rapport présente les travaux réalisés dans le cadre d’un Projet de Fin d’Études portant sur

l’automatisation des opérations SOC et de la réponse aux incidents cyber, avec un focus sur les

anomalies liées aux certificats électroniques. L’objectif est de concevoir une chaîne SOC/SOAR

open-source capable de collecter des événements, détecter des anomalies, enrichir les alertes, corréler

les observables, déclencher une décision analyste et préparer une réponse contrôlée.

La solution proposée repose sur une PKI locale avec EJBCA, des services HTTPS/OCSP, l’analyse

TLS/X.509 avec Zeek, la détection avec Wazuh, l’orchestration avec Shuffle, l’enrichissement par une

API SOC, la corrélation avec MISP, la documentation des incidents dans IRIS et la supervision avec

Grafana et Prometheus.

La réalisation est organisée selon une démarche incrémentale en quatre sprints. Le Sprint 0 formalise

les besoins, les choix techniques et l’architecture globale. Le Sprint 1 met en place l’infrastructure

SOC/PKI et la collecte des logs. Le Sprint 2 traite la détection et l’enrichissement des scénarios.

Le Sprint 3 présente l’orchestration SOAR, la remédiation, le confinement manuel, la réactivation

contrôlée et la supervision avec Grafana et Prometheus.

Deux scénarios principaux sont étudiés : S5, relatif à un certificat TLS révoqué encore utilisé, et

S6-S2, qui combine une phase de brute force SSH et une anomalie TLS liée à un certificat non autorisé.

Le projet montre comment une alerte technique peut être transformée en incident enrichi, documenté et

traité selon une décision analyste.

Mots-clés : SOC, SOAR, Wazuh, Shuffle, MISP, IRIS, EJBCA, Zeek, TLS, X.509, certificats

électroniques, Grafana, Prometheus.

iii
Summary

This report presents the work carried out as part of a final-year engineering project focused on SOC

operations automation and cyber incident response, with a specific focus on anomalies related to

electronic certificates. The goal is to design an open-source SOC/SOAR chain capable of collecting

events, detecting anomalies, enriching alerts, correlating observables, requesting analyst validation and

preparing a controlled response.

The proposed solution relies on a local PKI using EJBCA, HTTPS/OCSP services, TLS/X.509

analysis with Zeek, detection with Wazuh, orchestration with Shuffle, enrichment through a SOC API,

correlation with MISP, incident documentation in IRIS and monitoring with Grafana and Prometheus.

The project is organized into four incremental sprints. Sprint 0 defines the requirements, technical

choices and global architecture. Sprint 1 deploys the SOC/PKI infrastructure and log collection. Sprint

2 focuses on detection and enrichment of the selected scenarios. Sprint 3 covers SOAR orchestration,

remediation, manual containment, controlled service reactivation and monitoring.

Two main scenarios are studied: S5, related to a revoked TLS certificate still being used, and

S6-S2, which combines an SSH brute force phase with a TLS anomaly involving an unauthorized

certificate. The project shows how a technical alert can be transformed into an enriched, documented

and analyst-controlled incident response process.

Keywords: SOC, SOAR, Wazuh, Shuffle, MISP, IRIS, EJBCA, Zeek, TLS, X.509, electronic

certificates, Grafana, Prometheus.

iv
Table des matières

Dédicaces i

Remerciements ii

Résumé iii

Summary iv

Liste des acronymes xviii

Introduction générale 1

1 Cadrage général, analyse de l’existant et méthodologie 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Cadre institutionnel de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Agence Nationale de la Cybersécurité . . . . . . . . . . . . . . . . . . . . . 3

1.2.2 Fiche d’identification de l’organisme . . . . . . . . . . . . . . . . . . . . . . 4

1.2.3 Missions principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.4 Services et structures de l’ANCS . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Contexte et enjeux du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Concepts techniques de référence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1 Certificats électroniques X.509 . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.2 TLS et HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

v
Table des matières

1.4.3 PKI, autorité de certification et révocation . . . . . . . . . . . . . . . . . . . 6

1.4.4 SOC, SIEM et SOAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.5 Threat Intelligence et observables . . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Problématique et question centrale . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.6 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.6.1 Fonctionnement d’un SOC classique . . . . . . . . . . . . . . . . . . . . . . 8

1.6.2 Limites face aux anomalies liées aux certificats . . . . . . . . . . . . . . . . 8

1.6.3 Solutions commerciales proches du besoin . . . . . . . . . . . . . . . . . . 9

1.6.4 Comparaison synthétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6.5 Positionnement de la solution proposée . . . . . . . . . . . . . . . . . . . . 10

1.7 Approche proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.8 Méthodologie de réalisation et planification . . . . . . . . . . . . . . . . . . . . . . 11

1.8.1 Choix d’une démarche Scrum adaptée . . . . . . . . . . . . . . . . . . . . . 11

1.8.2 Rôles Scrum adaptés au projet . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.8.3 Organisation en quatre sprints . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.9 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques 14

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Objectifs et livrables attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6 Périmètre et environnement du laboratoire . . . . . . . . . . . . . . . . . . . . . . . 17

2.7 Analyse comparative et sélection des outils . . . . . . . . . . . . . . . . . . . . . . . 17

2.7.1 Comparaison des solutions SIEM . . . . . . . . . . . . . . . . . . . . . . . 18

vi
Table des matières

2.7.2 Comparaison des solutions SOAR . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.3 Comparaison des plateformes CTI . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.4 Comparaison des outils de gestion d’incidents . . . . . . . . . . . . . . . . . 19

2.7.5 Comparaison des solutions PKI . . . . . . . . . . . . . . . . . . . . . . . . 19

2.7.6 Comparaison des outils de supervision . . . . . . . . . . . . . . . . . . . . . 20

2.8 Architecture cible de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.9 Vue d’activité globale du traitement SOC/SOAR . . . . . . . . . . . . . . . . . . . . 25

2.10 Vue de séquence globale du traitement des alertes . . . . . . . . . . . . . . . . . . . 27

2.11 Backlog global et plan de réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.12 Bilan du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.13 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Sprint 1 : Déploiement de l’infrastructure SOC/PKI et collecte TLS/X.509 29

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Objectifs et livrables attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Architecture technique du laboratoire . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Déploiement de la PKI locale avec EJBCA . . . . . . . . . . . . . . . . . . . . . . . 31

3.6 Services TLS supervisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.7 Collecte et normalisation des logs TLS/X.509 avec Zeek . . . . . . . . . . . . . . . 32

3.8 Intégration des événements dans Wazuh . . . . . . . . . . . . . . . . . . . . . . . . 33

3.9 Inventaire local de confiance et référentiel attendu . . . . . . . . . . . . . . . . . . . 33

3.10 Vue d’activité de la collecte TLS/X.509 . . . . . . . . . . . . . . . . . . . . . . . . 34

3.11 Vue de séquence de la collecte TLS/X.509 . . . . . . . . . . . . . . . . . . . . . . . 34

3.12 Bilan du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.13 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vii
Table des matières

4 Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité 37

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Objectifs et livrables attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 Chaîne de détection et préparation à l’orchestration SOAR . . . . . . . . . . . . . . 38

4.5 Règles Wazuh et logique d’alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.6 Scénario S5 : détection d’un certificat TLS révoqué encore utilisé . . . . . . . . . . . 40

4.6.1 Description du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.6.2 Déroulement du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6.3 Observables du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6.4 Remédiation et confinement prévus pour S5 . . . . . . . . . . . . . . . . . . 42

4.7 Vue d’activité du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.8 Vue de séquence du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.9 Scénario S6-S2 : corrélation SSH brute force et certificat non autorisé . . . . . . . . 44

4.9.1 Description du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.9.2 Déroulement du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.9.3 Phases et observables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.9.4 Remédiation et confinement prévus pour S6-S2 . . . . . . . . . . . . . . . . 46

4.10 Vue d’activité du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.11 Vue de séquence du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.12 Enrichissement contextuel par l’API SOC . . . . . . . . . . . . . . . . . . . . . . . 49

4.13 Matrice de décision et politique de réponse . . . . . . . . . . . . . . . . . . . . . . 50

4.14 Alignement avec MITRE ATT&CK . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.15 Bilan du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.16 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

viii
Table des matières

5 Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle 52

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Objectifs et livrables attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 Workflow SOAR global de traitement des incidents . . . . . . . . . . . . . . . . . . 53

5.5 Mécanisme d’approbation analyste et contrôle humain . . . . . . . . . . . . . . . . . 55

5.6 Vue d’activité de la réponse SOC/SOAR . . . . . . . . . . . . . . . . . . . . . . . . 56

5.7 Critères décisionnels entre remédiation et confinement . . . . . . . . . . . . . . . . 58

5.8 Remédiation contrôlée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.8.1 Principe général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.8.2 Remédiation du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.8.3 Remédiation du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . 60

5.9 Confinement manuel et maîtrise du risque . . . . . . . . . . . . . . . . . . . . . . . 61

5.9.1 Principe général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.9.2 Confinement du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.9.3 Confinement du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . 63

5.10 Réactivation contrôlée du service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.11 Synthèse opérationnelle par scénario . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.12 Intégration CTI avec MISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.13 Documentation et suivi d’incident avec IRIS . . . . . . . . . . . . . . . . . . . . . . 67

5.14 Supervision opérationnelle avec Grafana et Prometheus . . . . . . . . . . . . . . . . 67

5.15 Vue de séquence de la réponse contrôlée . . . . . . . . . . . . . . . . . . . . . . . . 69

5.16 Validation opérationnelle de bout en bout . . . . . . . . . . . . . . . . . . . . . . . 70

5.17 Bilan du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.18 Synthèse du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

ix
Table des matières

Conclusion générale 71

A Commandes de validation 73

A.1 Vérification du certificat présenté par le service . . . . . . . . . . . . . . . . . . . . 73

A.2 Vérification des logs Zeek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.3 Recherche des alertes Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.4 Test de l’API SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.5 Remédiation contrôlée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.6 Confinement manuel et réactivation . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B Règles Wazuh principales 75

B.1 Synthèse des règles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B.2 Exemple de règle S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

C Extraits de l’API SOC 76

C.1 Structure de réponse simplifiée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

C.2 Logique de routage simplifiée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

D Workflows Shuffle 78

D.1 Workflow S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

D.2 Workflow S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

D.3 Workflow de retour en service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

E Preuves du scénario S5 80

E.1 Chaîne de traitement S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

E.2 Mail d’approbation et décision analyste . . . . . . . . . . . . . . . . . . . . . . . . 81

E.3 Certificat du service et changement après remédiation . . . . . . . . . . . . . . . . . 82

E.4 Dossier incident et investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

x
Table des matières

E.5 Observables, IOC et tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E.6 Validation technique et supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

F Bibliographie et webographie 96

xi
Table des figures

1.1 Identité visuelle de l’ANCS et du tunCERT . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Organigramme de l’ANCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Diagramme de Gantt du projet selon l’organisation en quatre sprints . . . . . . . . . 13

2.1 Architecture globale de la chaîne SOC/SOAR proposée . . . . . . . . . . . . . . . . 21

2.2 Sous-architecture soc-cert : environnement supervisé . . . . . . . . . . . . . . . . . 23

2.3 Sous-architecture soc-core : SIEM, stockage et supervision . . . . . . . . . . . . . . 24

2.4 Sous-architecture soc-ir : SOAR, CTI et gestion des incidents . . . . . . . . . . . . . 25

2.5 Diagramme d’activité global du traitement SOC/SOAR . . . . . . . . . . . . . . . . 26

2.6 Diagramme de séquence global du traitement d’une alerte SOC/SOAR . . . . . . . . 27

3.1 Certificat émis ou révoqué dans EJBCA . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Vérification TLS d’un service HTTPS/OCSP . . . . . . . . . . . . . . . . . . . . . 32

3.3 Log TLS/X.509 normalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Diagramme d’activité de collecte et de qualification initiale des événements TLS/X.509 34

3.5 Diagramme de séquence de l’observation TLS jusqu’à Wazuh . . . . . . . . . . . . . 35

4.1 Pipeline de détection, de routage et d’enrichissement SOC . . . . . . . . . . . . . . 39

4.2 Alerte Wazuh du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Diagramme d’activité du scénario S5 : certificat révoqué encore utilisé . . . . . . . . 43

4.4 Diagramme de séquence du scénario S5 : certificat révoqué encore utilisé . . . . . . 44

xii
Table des figures

4.5 Alertes Wazuh corrélées du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Diagramme d’activité du scénario S6-S2 : SSH suspect puis certificat frauduleux . . 48

4.7 Diagramme de séquence du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . 49

4.8 Réponse JSON de l’API SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 Workflow SOAR global orchestré par Shuffle . . . . . . . . . . . . . . . . . . . . . 54

5.2 Workflow Shuffle de traitement des incidents . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Email d’approbation analyste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4 Diagramme d’activité de la réponse SOC/SOAR avec timeout automatique . . . . . . 57

5.5 Diagramme d’activité de la remédiation et de ses conditions . . . . . . . . . . . . . 59

5.6 Diagramme d’activité du confinement manuel . . . . . . . . . . . . . . . . . . . . . 62

5.7 Diagramme d’activité de la réactivation manuelle du service . . . . . . . . . . . . . 65

5.8 Événement MISP et observables associés . . . . . . . . . . . . . . . . . . . . . . . 66

5.9 Case IRIS de l’incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.10 Dashboard Grafana SOC/SOAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.11 Diagramme de séquence de la réponse SOC/SOAR contrôlée . . . . . . . . . . . . . 69

D.1 Workflow Shuffle du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

D.2 Workflow Shuffle du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . 79

D.3 Workflow de réactivation manuelle du service . . . . . . . . . . . . . . . . . . . . . 79

E.1 Scénario S5 : vue générale du dossier incident dans DFIR-IRIS . . . . . . . . . . . . 84

E.2 Scénario S5 : informations détaillées du dossier incident . . . . . . . . . . . . . . . 85

E.3 Scénario S5 : champs techniques associés à l’alerte . . . . . . . . . . . . . . . . . . 86

E.4 Scénario S5 : synthèse de l’investigation et des éléments certificat . . . . . . . . . . 87

E.5 Scénario S5 : approbation analyste, remédiation approuvée et résultat opérationnel . . 88

E.6 Scénario S5 : actifs et observables rattachés au dossier . . . . . . . . . . . . . . . . 89

xiii
Table des figures

E.7 Scénario S5 : IOC enregistrés pour le suivi de l’incident . . . . . . . . . . . . . . . . 90

E.8 Scénario S5 : tâches de traitement et de validation . . . . . . . . . . . . . . . . . . . 91

E.9 Scénario S5 : commande OpenSSL et preuve du certificat présenté par le service . . 92

E.10 Scénario S5 : dashboard Grafana de suivi des indicateurs de performance . . . . . . 93

E.11 Scénario S5 : dashboard Grafana de suivi des certificats et alertes . . . . . . . . . . . 94

E.12 Scénario S5 : dashboard Grafana de suivi de l’orchestration SOC/SOAR . . . . . . . 95

xiv
Liste des tableaux

1.1 Fiche d’identification de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 4

1.2 Solutions commerciales proches de la gestion des certificats électroniques . . . . . . 9

1.3 Comparaison entre les solutions existantes et la solution proposée . . . . . . . . . . 10

1.4 Répartition des rôles Scrum dans le cadre du projet . . . . . . . . . . . . . . . . . . 11

1.5 Planification des sprints et livrables du projet . . . . . . . . . . . . . . . . . . . . . 12

2.1 Backlog du Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Besoins fonctionnels de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Besoins non fonctionnels de la solution . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Machines principales du laboratoire . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Comparaison des solutions SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Comparaison des solutions SOAR . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7 Comparaison des plateformes CTI . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8 Comparaison des outils de gestion d’incidents . . . . . . . . . . . . . . . . . . . . . 19

2.9 Comparaison des solutions PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.10 Comparaison des outils de supervision . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.11 Backlog global du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Répartition des composants du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 30

xv
Liste des tableaux

3.3 Processus de création et de déploiement d’un certificat serveur . . . . . . . . . . . . 31

3.4 Services TLS supervisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5 Champs TLS/X.509 exploités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6 Structure logique de l’inventaire local . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Règles Wazuh principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Déroulement du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4 Éléments techniques du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5 Déroulement du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.6 Phases du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.7 Sorties principales de l’API SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.8 Matrice de décision des scénarios retenus . . . . . . . . . . . . . . . . . . . . . . . 50

4.9 Mapping MITRE ATT&CK des scénarios . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2 Décisions possibles dans le workflow SOAR . . . . . . . . . . . . . . . . . . . . . . 56

5.3 Critères de choix entre remédiation et confinement . . . . . . . . . . . . . . . . . . 58

5.4 Remédiation du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 Remédiation du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.6 Confinement manuel du scénario S5 . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.7 Confinement manuel du scénario S6-S2 . . . . . . . . . . . . . . . . . . . . . . . . 64

5.8 Synthèse des actions de réponse par scénario . . . . . . . . . . . . . . . . . . . . . 66

5.9 Observables enregistrés dans MISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.10 Éléments documentés dans IRIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.11 Métriques Prometheus proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.12 Matrice de validation de bout en bout . . . . . . . . . . . . . . . . . . . . . . . . . 70

xvi
Liste des tableaux

B.1 Règles Wazuh utilisées dans le périmètre du rapport . . . . . . . . . . . . . . . . . . 75

E.1 Contenu fonctionnel du mail d’approbation S5 . . . . . . . . . . . . . . . . . . . . . 81

E.2 Évolution attendue du certificat du service S5 . . . . . . . . . . . . . . . . . . . . . 82

xvii
Liste des acronymes

Acronyme Signification

ANCS Agence Nationale de la Cybersécurité

API Application Programming Interface

CA Certificate Authority

CERT Computer Emergency Response Team

CLM Certificate Lifecycle Management

CRL Certificate Revocation List

CTI Cyber Threat Intelligence

HIDS Host-based Intrusion Detection System

IOC Indicator of Compromise

MISP Malware Information Sharing Platform

MITRE Base de connaissances des tactiques et techniques adverses

ATT&CK

MTTD Mean Time To Detect

MTTR Mean Time To Respond

OCSP Online Certificate Status Protocol

PKI Public Key Infrastructure

xviii
Liste des tableaux

SIEM Security Information and Event Management

SOAR Security Orchestration, Automation and Response

SOC Security Operations Center

TLS Transport Layer Security

X.509 Standard de certificats numériques

xix
Introduction générale

La transformation numérique des organisations a profondément modifié la manière dont les services

informatiques sont conçus, exposés et supervisés. Les applications web, les interfaces d’administration,

les API internes et les plateformes critiques reposent de plus en plus sur des communications sécurisées

par TLS et sur des certificats électroniques X.509. Ces certificats assurent l’authentification des services,

la confidentialité des échanges et la continuité de la chaîne de confiance entre les utilisateurs, les

applications et l’infrastructure.

Cependant, la sécurité apportée par les certificats électroniques dépend fortement de leur cycle

de vie. Un certificat expiré, révoqué, mal déployé ou remplacé par un certificat émis par une autorité

non autorisée peut remettre en cause la confiance accordée à un service. Cette situation devient plus

critique lorsque le service reste fonctionnel malgré l’anomalie, car l’incident peut passer inaperçu du

point de vue applicatif tout en constituant un risque important du point de vue sécurité.

Dans un centre opérationnel de sécurité, la gestion de ce type d’incident ne peut pas se limiter à

une alerte isolée. Elle nécessite une chaîne complète capable de collecter les journaux, normaliser

les événements, contextualiser les certificats observés, corréler les informations avec une mémoire

d’observables, documenter l’incident, demander une décision analyste et appliquer une réponse

technique contrôlée. L’automatisation est donc utilisée comme un moyen de standardiser et d’accélérer

le traitement, sans supprimer le contrôle humain sur les actions sensibles.

C’est dans ce contexte que s’inscrit ce projet de fin d’études intitulé : Automatisation des opérations

SOC et de la réponse aux incidents cyber. Le travail consiste à concevoir et mettre en place une chaîne

SOC/SOAR open-source orientée certification électronique. La solution s’appuie sur Wazuh pour la

1
Liste des tableaux

détection, Shuffle pour l’orchestration, une API SOC pour l’enrichissement et le scoring, MISP pour la

corrélation des observables, IRIS pour la gestion d’incidents, ainsi que Grafana et Prometheus pour le

suivi opérationnel.

Deux scénarios principaux ont été retenus. Le premier, S5, traite le cas d’un certificat TLS

révoqué encore utilisé par un service HTTPS/OCSP. Le second, S6-S2, représente une chaîne d’attaque

combinant une phase de brute force SSH suivie de l’exposition d’un certificat frauduleux signé par une

autorité non autorisée. Ces scénarios permettent de valider la capacité du SOC à détecter une anomalie

liée aux certificats, l’enrichir, la corréler, la documenter et proposer une remédiation ou un confinement

contrôlé.

La réalisation suit une démarche incrémentale basée sur quatre sprints. Cette organisation permet de

progresser de manière structurée : cadrer le besoin, concevoir l’architecture, déployer l’infrastructure,

construire les règles de détection, enrichir les alertes, préparer la réponse, distinguer les conditions de

remédiation et de confinement, puis valider les résultats à travers des indicateurs de supervision.

Le rapport est organisé comme suit. Le premier chapitre présente le cadre général du projet,

l’organisme d’accueil, les notions de base, l’étude de l’existant, la problématique, la solution proposée

et la méthodologie de réalisation. Le deuxième chapitre correspond au Sprint 0 et détaille l’analyse

préliminaire, les besoins, les choix techniques, l’architecture globale et les diagrammes de conception.

Le troisième chapitre présente le Sprint 1, consacré à l’infrastructure SOC/PKI et à la collecte des logs.

Le quatrième chapitre présente le Sprint 2, qui traite la détection et l’enrichissement des scénarios S5 et

S6-S2. Le cinquième chapitre correspond au Sprint 3 et détaille l’orchestration SOAR, la remédiation,

le confinement manuel, la réactivation contrôlée et la supervision. Enfin, une conclusion générale

synthétise les résultats obtenus, les limites et les perspectives d’amélioration.

2
Chapitre 1

Cadrage général, analyse de l’existant et mé-

thodologie

1.1 Introduction

Ce chapitre présente le cadre général du projet. Il décrit d’abord l’organisme d’accueil et ses principales

structures, puis introduit le contexte lié aux certificats électroniques et aux opérations SOC. Il présente

ensuite les notions nécessaires à la compréhension du sujet, la problématique, l’étude de l’existant, la

solution proposée et la méthodologie de réalisation adoptée.

1.2 Cadre institutionnel de l’organisme d’accueil

1.2.1 Agence Nationale de la Cybersécurité

L’Agence Nationale de la Cybersécurité est l’autorité nationale de référence en matière de cybersécurité

en Tunisie. Elle contribue à la protection du cyberespace national, à l’accompagnement des organismes

publics et privés, à la veille, à l’assistance, à la prévention et à la réponse aux incidents cyber.

Dans un contexte marqué par l’augmentation des menaces numériques, l’ANCS occupe un rôle

central dans le renforcement de la résilience des systèmes d’information. Ses activités couvrent à la

fois des dimensions stratégiques, techniques et opérationnelles.

3
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

Logo du tunCERT
Logo de l’ANCS
Figure 1.1: Identité visuelle de l’ANCS et du tunCERT

1.2.2 Fiche d’identification de l’organisme

Table 1.1: Fiche d’identification de l’organisme d’accueil

Élément Description

Organisme Agence Nationale de la Cybersécurité

Pays Tunisie

Adresse À compléter selon l’adresse officielle communiquée par l’organisme

Domaine d’activité Cybersécurité, cyberveille, audit, assistance, prévention et réponse aux

incidents

Site web [Link]

Nature de l’activité Organisme national chargé de missions de cybersécurité, de veille,

d’assistance et de coordination

1.2.3 Missions principales

Les missions de l’ANCS couvrent les activités nécessaires à la cybersécurité nationale. Elles comprennent

notamment la prévention, la sensibilisation, la veille technologique, l’alerte, l’assistance aux organismes,

la contribution aux référentiels de sécurité, la coordination de la réponse aux incidents et le suivi des

recommandations issues des travaux d’audit ou d’accompagnement.

Ces missions traduisent une approche complète de la cybersécurité. Elles ne se limitent pas à

la réaction après incident, mais couvrent également la préparation, la gouvernance, l’amélioration

continue, l’accompagnement des structures concernées et le partage d’informations utiles à la maîtrise

du risque cyber.

4
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

1.2.4 Services et structures de l’ANCS

Les services de l’ANCS sont organisés autour de structures de pilotage, de veille, de gouvernance,

d’audit, de technologies de sécurité, de ressources et de réponse aux urgences informatiques. Cette

organisation permet de couvrir plusieurs niveaux d’action : orientation stratégique, accompagnement,

supervision, assistance et traitement opérationnel des incidents.

Parmi les structures représentées dans l’organigramme figurent la Direction Générale, les unités

chargées de la veille et de la gouvernance, la Direction de l’Audit de la Sécurité Informatique, la

Direction des Technologies de Sécurité des Systèmes d’Information, la Direction des Ressources et la

Direction de la Réponse aux Urgences Informatiques et de l’Assistance.

Figure 1.2: Organigramme de l’ANCS

L’organigramme montre la répartition des responsabilités entre les structures de direction, les

unités de suivi, les directions techniques et les structures orientées assistance. Cette lecture permet de

comprendre l’environnement institutionnel dans lequel s’inscrit le projet, sans réduire les services de

l’agence à un seul besoin technique.

5
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

1.3 Contexte et enjeux du projet

Les services numériques utilisent de plus en plus les communications HTTPS et les mécanismes de

confiance basés sur TLS. Cette évolution rend les certificats électroniques indispensables pour établir

l’identité d’un service, sécuriser les échanges et garantir la confidentialité des données échangées.

Cependant, un certificat électronique peut devenir une source de risque lorsqu’il n’est pas correcte-

ment suivi. Un certificat révoqué peut continuer à être présenté par un service, un certificat non autorisé

peut remplacer un certificat légitime, ou un certificat issu d’une autorité inattendue peut indiquer une

rupture de confiance. Dans un SOC, ces situations nécessitent une visibilité précise sur les champs

X.509, une corrélation avec un inventaire de confiance et une réponse contrôlée.

1.4 Concepts techniques de référence

1.4.1 Certificats électroniques X.509

Un certificat électronique X.509 associe une identité à une clé publique. Il contient des informations

telles que le sujet, l’autorité émettrice, le numéro de série, l’empreinte, les dates de validité et les

usages autorisés. Dans le cadre du projet, ces champs sont utilisés comme observables afin d’identifier

les services conformes, suspects ou révoqués.

1.4.2 TLS et HTTPS

TLS assure la confidentialité et l’intégrité des échanges entre un client et un serveur. Lors d’une

connexion HTTPS, le serveur présente son certificat au client. L’analyse de ce certificat permet de

vérifier l’identité du service, l’autorité émettrice et le statut de confiance.

1.4.3 PKI, autorité de certification et révocation

Une infrastructure à clés publiques permet d’émettre, gérer et révoquer les certificats. L’autorité de

certification signe les certificats, tandis que la révocation permet de signaler qu’un certificat ne doit

6
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

plus être considéré comme valide avant sa date d’expiration. Les mécanismes CRL et OCSP servent à

vérifier ce statut.

1.4.4 SOC, SIEM et SOAR

Un SOC supervise les événements de sécurité, qualifie les alertes et coordonne la réponse aux incidents.

Le SIEM centralise et corrèle les journaux pour produire des alertes. Le SOAR orchestre les actions de

traitement et automatise certaines étapes répétitives tout en gardant un contrôle humain lorsque les

actions sont sensibles.

1.4.5 Threat Intelligence et observables

La Threat Intelligence permet de conserver une mémoire des observables et de contextualiser les alertes.

Dans ce projet, les observables peuvent être une adresse IP, un nom de service, un numéro de série de

certificat, une empreinte ou une règle Wazuh.

1.5 Problématique et question centrale

La problématique du projet s’inscrit dans un contexte où les certificats électroniques sont devenus

indispensables pour sécuriser les services numériques. Toutefois, une anomalie liée à un certificat ne

provoque pas toujours une indisponibilité visible du service. Un certificat révoqué, remplacé par un

certificat non autorisé ou signé par une autorité inattendue peut donc rester en production tout en créant

un risque de sécurité important.

Dans un environnement SOC classique, ce type d’incident reste difficile à traiter lorsque les journaux

TLS/X.509 ne sont pas normalisés, lorsque les informations du certificat ne sont pas comparées à

un inventaire de confiance et lorsque la réponse n’est pas structurée. L’analyste doit alors consulter

plusieurs sources, vérifier manuellement les observables et décider d’une action sans disposer d’un

contexte complet.

La problématique centrale peut donc être formulée ainsi :

7
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

Comment concevoir une chaîne SOC/SOAR open-source capable de détecter des anomalies

liées aux certificats électroniques et aux accès suspects, d’enrichir automatiquement les

alertes, de corréler les observables et d’exécuter une réponse contrôlée tout en conservant

une traçabilité opérationnelle ?

1.6 Analyse de l’existant

1.6.1 Fonctionnement d’un SOC classique

Un SOC classique collecte les journaux issus des systèmes, des équipements réseau, des applications

et des outils de sécurité. Ces événements sont centralisés dans un SIEM, analysés par des règles de

corrélation puis présentés sous forme d’alertes aux analystes. L’investigation repose ensuite sur la

consultation des logs, la vérification des actifs concernés, l’enrichissement manuel ou semi-automatique

et la décision de réponse.

Cette approche est efficace pour de nombreux cas d’usage classiques, comme les échecs d’authen-

tification, les connexions suspectes ou les événements système. Elle devient toutefois moins directe

lorsqu’il s’agit de détecter une anomalie liée aux certificats électroniques, car les informations X.509

ne sont pas toujours extraites, normalisées ou comparées à un inventaire de confiance.

1.6.2 Limites face aux anomalies liées aux certificats

Les limites observées dans un SOC classique concernent principalement la visibilité et la corrélation.

Une alerte réseau peut indiquer une connexion vers un service HTTPS, sans préciser si le certificat

présenté est attendu, révoqué ou signé par une autorité légitime. Sans normalisation des champs subject,

issuer, serial et fingerprint, l’analyste doit effectuer plusieurs vérifications manuelles.

Ces limites peuvent entraîner une détection tardive, une difficulté à prioriser les incidents et un

manque de traçabilité dans les actions correctives. Elles sont particulièrement visibles dans le scénario

d’un certificat révoqué encore utilisé ou dans une chaîne d’attaque combinant une compromission

d’accès et une modification du certificat présenté par un service.

8
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

1.6.3 Solutions commerciales proches du besoin

Le marché propose plusieurs solutions commerciales de gestion du cycle de vie des certificats.

Ces plateformes couvrent généralement la découverte des certificats, l’inventaire, la supervision, le

renouvellement, la révocation, l’automatisation et le reporting. Elles sont proches du besoin traité dans

ce projet, car elles s’intéressent directement aux certificats électroniques et à la réduction des risques

liés à leur mauvaise gestion.

Table 1.2: Solutions commerciales proches de la gestion des certificats électroniques

Solution Orientation princi- Apport principal

pale

DigiCert Trust Life- Certificate Lifecycle Découverte, inventaire, automatisation, notification et suivi du
cycle Manager Management et PKI cycle de vie des certificats.

CyberArk Certificate Machine identity secu- Découverte, surveillance, renouvellement et contrôle de

Manager rity et CLM conformité des certificats TLS.

Keyfactor Command PKI et certificate auto- Visibilité, gouvernance et automatisation des clés et certificats
mation dans des environnements hybrides.

AppViewX AVX Certificate lifecycle au- Gestion et automatisation du cycle de vie des certificats et des
CLM tomation identités machine.

9
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

1.6.4 Comparaison synthétique

Table 1.3: Comparaison entre les solutions existantes et la solution proposée

Solution Gestion certi- AutomatisationOrientation Limite pour le projet

ficats SOC

DigiCert TLM Forte Forte Moyenne Solution commerciale orientée CLM

global, moins adaptée à un laboratoire
SOC/SOAR open-source.

CyberArk Certifi- Forte Forte Moyenne Plateforme commerciale complète, avec

cate Manager un périmètre plus large que le besoin
académique.

Keyfactor Com- Forte Forte Moyenne Solution entreprise avancée, nécessitant

mand un contexte d’intégration important.

AppViewX AVX Forte Forte Moyenne Plateforme CLM complète, davantage

CLM orientée entreprise et automatisation de
cycle de vie.

Solution proposée Ciblée Contrôlée Forte Couverture CLM limitée, mais

intégration directe avec détection SOC,
enrichissement et réponse SOAR.

1.6.5 Positionnement de la solution proposée

La solution proposée ne cherche pas à remplacer une plateforme commerciale complète de gestion du

cycle de vie des certificats. Elle vise plutôt à démontrer une chaîne SOC/SOAR open-source capable

d’observer les certificats réellement présentés, détecter les anomalies pertinentes, enrichir les alertes,

corréler les observables, demander une décision analyste et exécuter une réponse contrôlée.

1.7 Approche proposée

La solution proposée repose sur une architecture SOC/SOAR open-source organisée autour de plusieurs

briques complémentaires. EJBCA permet de reproduire une PKI locale, Nginx expose des services

HTTPS/OCSP de test, Zeek extrait les informations TLS/X.509, Wazuh détecte les anomalies, l’API

10
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

SOC enrichit les alertes et calcule le risque, MISP conserve la mémoire des observables, IRIS

documente l’incident, Shuffle orchestre la réponse, et Grafana/Prometheus assurent la supervision.

Le principe général de la solution est décrit par le flux suivant : les services surveillés produisent

des événements, les logs sont collectés et normalisés, Wazuh déclenche une alerte, l’API SOC ajoute le

contexte et le score, MISP assure la corrélation, IRIS conserve la trace de l’incident, Shuffle prépare la

réponse et Grafana/Prometheus permettent de suivre l’état final.

1.8 Méthodologie de réalisation et planification

1.8.1 Choix d’une démarche Scrum adaptée

Le projet est organisé selon une démarche incrémentale inspirée de Scrum. Ce choix est adapté à

la nature du travail, car la solution dépend de plusieurs validations successives : mise en place du

laboratoire, disponibilité des services, collecte des logs, détection, enrichissement, orchestration et

supervision.

1.8.2 Rôles Scrum adaptés au projet

Table 1.4: Répartition des rôles Scrum dans le cadre du projet

Rôle Scrum Correspondance Contribution

Product Owner Mme Mariem Jouini Expression du besoin opérationnel, suivi

fonctionnel et validation des orientations.

Scrum Master Dr Salah Gontara Suivi méthodologique, cadrage et validation

progressive de la démarche.

Équipe de développe- Imen Ouled Belgacem Conception, installation, configuration, scripts,

ment workflows, tests et documentation.

1.8.3 Organisation en quatre sprints

Le travail est structuré en quatre sprints maximum. Les intitulés des sprints sont formulés selon

les activités réellement réalisées dans le projet : cadrage de la chaîne SOC/SOAR, déploiement de

11
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

l’environnement SOC/PKI, normalisation des logs et détection, puis orchestration de la réponse et

supervision des KPI.

Le tableau suivant présente la planification des sprints, leurs objectifs, leurs durées, les périodes

associées et les livrables attendus.

Table 1.5: Planification des sprints et livrables du projet

Sprint / Activité Objectif Durée Période Livrables Statut

Sprint 0 : Cadrer le be- Analyser les besoins, défi- 2 sem. S1 à S2 Besoins, architecture, back- Réalisé
soin et concevoir l’archi- nir le périmètre et concevoir log, plan des sprints.
tecture SOC/SOAR l’architecture globale.

Sprint 1 : Déployer l’en- Mettre en place l’environne- 3 sem. S3 à S5 Environnement opération- Réalisé
vironnement SOC/PKI ment de test, la PKI EJBCA, nel, services supervisés,
et collecter les événe- Wazuh, Zeek/watcher et la collecte activée.
ments collecte initiale.

Sprint 2 : Normaliser les Produire les logs JSON 4 sem. S6 à S9 Logs normalisés, règles Wa- Réalisé
logs et détecter les évé- normalisés et implémenter zuh, détection validée.
nements de sécurité les règles Wazuh 110113,
110120 et 110115.

Sprint 3 : Orchestrer la Intégrer Shuffle, IRIS et 3 sem. S10 à S12 Workflows SOAR, inci- Réalisé
réponse et superviser les MISP, automatiser la ré- dents IRIS, corrélation
KPI ponse et construire les da- MISP, dashboards KPI.
shboards Grafana/Prome-
theus.

Transversal : Rédiger le Collecter les preuves tech- En S1 à S13 Rapport, documentation, En

rapport, documenter et niques, rédiger et mettre à continu captures et traçabilité. continu
consolider les preuves jour la documentation.

Le diagramme de Gantt ci-dessous complète cette vue en représentant visuellement la succession

des sprints et la tâche transversale de documentation.

12
Chapitre 1. Cadrage général, analyse de l’existant et méthodologie

Figure 1.3: Diagramme de Gantt du projet selon l’organisation en quatre sprints

1.9 Synthèse du chapitre

Ce chapitre a présenté le cadre général du projet, l’organisme d’accueil, les notions de base, la

problématique, l’étude de l’existant, la solution proposée et la méthodologie adoptée. Le chapitre

suivant présente le Sprint 0, consacré à l’analyse préliminaire, aux choix techniques et à la conception

globale.

13
Chapitre 2

Sprint 0 : Cadrage des besoins, architecture

cible et choix technologiques

2.1 Introduction

Le Sprint 0 correspond à la phase de cadrage technique. Il transforme la problématique générale

en une base de réalisation claire. Cette étape permet d’identifier les besoins, de définir le périmètre

du laboratoire, de comparer les outils open-source utilisés, de concevoir l’architecture globale et de

préparer les scénarios qui seront validés dans les sprints suivants.

2.2 Objectifs et livrables attendus

L’objectif du Sprint 0 est de disposer d’une vision structurée de la solution avant son implémentation. Il

s’agit de préciser les fonctions attendues, les contraintes, les choix techniques, les flux entre composants

et les preuves à produire durant la réalisation.

2.3 Backlog du sprint

Le backlog du Sprint 0 regroupe les tâches de cadrage nécessaires avant le déploiement technique de la

solution.

14
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Table 2.1: Backlog du Sprint 0

ID Tâche Livrable Priorité

S0-T1 Formaliser les besoins fonctionnels et non Besoins validés Haute

fonctionnels.

S0-T2 Définir le périmètre technique du laboratoire. Liste des machines et Haute

rôles

S0-T3 Comparer les outils utilisés dans la chaîne Tableaux de comparai- Haute
SOC/SOAR. son

S0-T4 Concevoir l’architecture globale. Diagramme d’architec- Haute

ture

S0-T5 Définir le workflow général de traitement Diagrammes d’activité Haute

d’une alerte. et de séquence

S0-T6 Préparer les scénarios S5 et S6-S2. Cadre de validation Moyenne

2.4 Exigences fonctionnelles

Les besoins fonctionnels décrivent les capacités attendues de la chaîne SOC/SOAR, depuis la collecte

jusqu’à la supervision.

15
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Table 2.2: Besoins fonctionnels de la solution

Besoin Capacités attendues Résultat visé

Collecte Collecter les logs TLS/X.509, les alertes Wazuh et les Données disponibles pour
événements d’accès. la détection.

Détection Déclencher des règles Wazuh adaptées aux scénarios S5 Alertes exploitables et
et S6-S2. contextualisées.

Enrichissement Produire un résumé, un score de risque, les observables et Aide à la priorisation.

l’action recommandée.

Corrélation CTI Rechercher et enregistrer les observables dans MISP. Mémoire d’incident et
suivi des occurrences.

Gestion d’incident Documenter l’incident dans IRIS avec tâches, Traçabilité opérationnelle.
observables et timeline.

Orchestration Exécuter un workflow Shuffle avec décision analyste. Réponse contrôlée et repro-
ductible.

Supervision Exposer des métriques Prometheus et afficher les Visibilité sur l’activité
indicateurs dans Grafana. SOC/SOAR.

2.5 Exigences non fonctionnelles

Les besoins non fonctionnels précisent les contraintes de qualité, de traçabilité et de sécurité à respecter

durant la réalisation.

16
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Table 2.3: Besoins non fonctionnels de la solution

Besoin Description

Traçabilité Chaque alerte doit conserver ses observables, son score, sa décision et son
résultat.

Sécurité des actions Les actions de remédiation et de confinement doivent rester contrôlées et
limitées.

Maintenabilité Les règles, scripts et workflows doivent être lisibles et modifiables.

Reproductibilité Le laboratoire doit être documenté pour permettre la reprise des tests.

Extensibilité La solution doit permettre l’ajout de nouveaux scénarios.

Observabilité Les erreurs, enrichissements, approbations et actions doivent être suivis

par métriques.

2.6 Périmètre et environnement du laboratoire

Le laboratoire est organisé autour de quatre machines principales, chacune ayant un rôle précis dans la

chaîne de détection, d’enrichissement et de réponse.

Table 2.4: Machines principales du laboratoire

Machine Adresse Rôle

soc-certif [Link] PKI locale, EJBCA, services HTTPS/OCSP, Zeek, watcher

TLS et agent de collecte.

soc-core [Link] Wazuh Manager, OpenSearch, Wazuh Dashboard et

Grafana.

soc-ir [Link] Shuffle, API SOC, MISP, IRIS, Prometheus et serveur

d’approbation.

Kali/test [Link] Génération de trafic, tests SSH/TLS et validation des

scénarios.

2.7 Analyse comparative et sélection des outils

17
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

2.7.1 Comparaison des solutions SIEM

Le tableau suivant compare les solutions SIEM étudiées et justifie le choix de Wazuh pour la partie

détection.
Table 2.5: Comparaison des solutions SIEM
Outil Forces Limites Choix

Wazuh Open-source, agents Linux/Windows, Besoin d’une normalisation propre des Retenu
règles personnalisées et intégration logs.
OpenSearch.

Elastic Security Recherche et visualisation puissantes, Configuration plus lourde pour un Non retenu
pipelines flexibles. SIEM complet.

Splunk ES Maturité SOC, corrélation avancée, re- Coût élevé et périmètre trop lourd. Non retenu
porting complet.

2.7.2 Comparaison des solutions SOAR

Le tableau suivant présente les solutions SOAR envisagées pour l’orchestration des réponses aux

incidents.
Table 2.6: Comparaison des solutions SOAR
Outil Forces Limites Choix

Shuffle Open-source, workflows visuels, web- Demande une bonne maîtrise des va- Retenu
hooks, appels HTTP et scripts Python. riables.

Palo Alto XSOAR Playbooks avancés et nombreuses inté- Solution commerciale lourde pour le Non retenu
grations SOC. PFE.

Splunk SOAR Automatisation avancée et intégration Coût et dépendance à Splunk. Non retenu
Splunk.

2.7.3 Comparaison des plateformes CTI

Le tableau suivant compare les plateformes CTI capables de mémoriser et corréler les observables

manipulés par le SOC.

18
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Table 2.7: Comparaison des plateformes CTI

Outil Forces Limites Choix

MISP Open-source, API REST, événements, Nécessite une structure claire des évé- Retenu
attributs, tags et suivi des observables. nements.

OpenCTI Modélisation riche des relations et Déploiement plus complexe pour le cas Non retenu
graphes CTI. ciblé.

ThreatConnect Plateforme CTI avancée et collabora- Commerciale et surdimensionnée. Non retenu

tive.

2.7.4 Comparaison des outils de gestion d’incidents

Le tableau suivant compare les outils de gestion d’incidents utilisés pour documenter les alertes et

conserver la traçabilité.
Table 2.8: Comparaison des outils de gestion d’incidents
Outil Forces Limites Choix

IRIS Open-source, cases, tâches, obser- Demande une modélisation cohérente. Retenu
vables, timeline et API REST.

ServiceNow SecOps Gestion d’incident entreprise, ITSM et Coût élevé et plateforme propriétaire. Non retenu
reporting.

Jira Service Manage- Suivi de tickets, workflows et intégra- Moins spécialisé SOC et observables. Non retenu
ment tion IT.

2.7.5 Comparaison des solutions PKI

Le tableau suivant présente les solutions PKI étudiées pour reproduire un environnement de certificats

électroniques en laboratoire.
Table 2.9: Comparaison des solutions PKI
Outil Forces Limites Choix

EJBCA CE PKI complète, CA, profils, émission et Déploiement plus exigeant Retenu
révocation. qu’OpenSSL.

OpenSSL Léger, disponible partout, utile pour Pas une plateforme PKI complète. Outil de test
tests et vérifications.

Microsoft AD CS PKI intégrée aux environnements Win- Moins adaptée au laboratoire Linux. Non retenu
dows.

19
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

2.7.6 Comparaison des outils de supervision

Le tableau suivant compare les outils de supervision retenus pour visualiser l’état de la chaîne

SOC/SOAR et ses indicateurs.

Table 2.10: Comparaison des outils de supervision
Outil Forces Limites Choix

Grafana/Prometheus Métriques, dashboards, visualisation et Nécessite des métriques SOC définies. Retenu
intégration API.

Zabbix Supervision infrastructure mature. Moins adapté aux métriques SOC/- Non retenu
SOAR.

Nagios Supervision légère et historique. Dashboards moins adaptés au besoin. Non retenu

2.8 Architecture cible de la solution

L’architecture globale représente la chaîne complète mise en place dans le laboratoire. Elle relie

l’environnement supervisé, la collecte TLS/X.509, le SIEM Wazuh, la zone SOAR/CTI, la gestion

d’incidents et la supervision. L’objectif est de montrer comment un événement technique observé sur

un service supervisé devient une alerte enrichie, corrélée, documentée puis traitée par une réponse

contrôlée.

20
 Architecture globale de la chaine SOC/SOAR proposee

soc-ir
Zone de test controlee SOAR, CTI et incidents

Kali / client de test Shuffle SOAR

ssh - curl - openssl webhook et workflow

SSH / TCP 22 Enrichissement et reponse Demande decision analyste Statut approuve / contain / timeout

soc-certif
Environnement supervise

EJBCA CE Scripts de reponse locale Execution action controlee API SOC Serveur d'approbation
HTTPS / OCSP SSH
PKI locale remediation - confinement /enrich - /approval - /respond approve - contain - timeout

Emission et revocation certificats [Link] Metriques d'action Lookup / upsert observables Case, taches, timeline Webhook alerte

soc-core
SIEM, stockage et supervision
Services TLS
Wazuh Agent Prometheus MISP DFIR-IRIS
Nginx HTTPS / OCSP
observables CTI cases et timeline

Handshake TLS reel Evenements agents Metriques SOC/SOAR

Zeek passif Wazuh Manager

Inventaires JSON Evenements normalises Grafana
[Link] - [Link] regles et alertes
CA, services, certificats

Referentiel de confiance [Link] et [Link] Alertes securite

TLS Watcher
normalisation JSON OpenSearch

Consultation alertes

Wazuh Dashboard

Figure 2.1: Architecture globale de la chaîne SOC/SOAR proposée

21
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Lecture globale de l’architecture. L’architecture représente une chaîne SOC/SOAR complète organisée

autour de trois zones techniques principales, en plus d’une zone de test contrôlée. La machine soc-certif

correspond à l’environnement supervisé : elle héberge la PKI de laboratoire, les services HTTPS/OCSP,

Zeek, le watcher TLS/X.509, la collecte locale et l’agent chargé de transmettre les événements. La

machine soc-core porte le cœur SIEM et supervision : Wazuh Manager, OpenSearch, Wazuh Dashboard

et Grafana. La machine soc-ir regroupe la réponse à incident : Shuffle, l’API SOC, MISP, IRIS,

Prometheus et le serveur d’approbation. La machine Kali joue uniquement le rôle de client de test

contrôlé dans le laboratoire.

Logique des flux. Le flux principal part d’un événement observé sur soc-certif, passe par la normalisation

TLS/X.509, puis arrive dans Wazuh pour la détection. Lorsqu’une alerte est générée, elle est transmise

vers Shuffle sur soc-ir. L’API SOC enrichit ensuite l’alerte, MISP assure la corrélation des observables,

IRIS documente l’incident et Prometheus/Grafana exposent les indicateurs de suivi. Cette séparation

rend la solution lisible : soc-certif observe et produit les événements, soc-core détecte et supervise,

tandis que soc-ir orchestre, enrichit, documente et prépare la réponse contrôlée.

Environnement supervisé. Cette sous-architecture correspond à soc-certif. Elle contient les services

de certification électronique simulés dans le laboratoire : EJBCA, les certificats de la CA locale, les

services HTTPS/OCSP supervisés, Zeek et le watcher TLS automatique. Les scripts de normalisation

produisent un événement exploitable à partir des journaux [Link] et [Link]. Le watcher compare

le certificat réellement exposé avec l’inventaire local de confiance afin d’identifier les anomalies liées

au statut, à l’issuer, au serial ou au fingerprint.

22
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Figure 2.2: Sous-architecture soc-cert : environnement supervisé

SIEM, stockage et supervision. Cette sous-architecture correspond à soc-core. Wazuh reçoit les

événements normalisés provenant de l’environnement supervisé, applique les règles de détection

et produit les alertes sécurité. OpenSearch conserve les alertes et Wazuh Dashboard permet leur

consultation. Grafana fournit la visualisation opérationnelle des indicateurs, tandis que les métriques

générées par la chaîne SOC/SOAR sont exploitées pour suivre l’activité, les décisions, les actions et les

erreurs.

23
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Figure 2.3: Sous-architecture soc-core : SIEM, stockage et supervision

Zone SOAR, CTI et incidents. Cette sous-architecture correspond à soc-ir. Elle contient Shuffle, l’API

SOC, MISP, IRIS, Prometheus et le serveur d’approbation. Shuffle reçoit les alertes via webhook et

les route selon [Link]. L’API SOC transforme l’alerte brute en objet exploitable : résumé, score de

risque, observables, politique de réponse et liens d’approbation. MISP conserve la mémoire CTI des

observables, IRIS documente le dossier incident et Prometheus expose les métriques nécessaires au

pilotage. Les actions sensibles restent encadrées par la décision analyste, avec une politique de timeout

limitée aux situations critiques prévues par le workflow.

24
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Figure 2.4: Sous-architecture soc-ir : SOAR, CTI et gestion des incidents

2.9 Vue d’activité globale du traitement SOC/SOAR

25
Figure 2.5: Diagramme d’activité global du traitement SOC/SOAR

26
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

2.10 Vue de séquence globale du traitement des alertes

Diagramme de sequence global - Chaine SOC/SOAR

Environnement Zeek / Watcher

supervise TLS-X.509 Wazuh Shuffle SOAR API SOC MISP IRIS Grafana
Analyste SOC

Trafic TLS, logs

1
SSH et certificats

Evenements
2
normalises

Correlation et
3 regles de
detection

alt [Alerte retenue]

Webhook alerte +
4
champs Wazuh

Demande
5
d'enrichissement

Recherche
6
observables

Correspondances
7
/ historique

Score, scenario,
8 action
recommandee

Creation ou mise
9
a jour du case

10 Email de decision

alt [Approbation analyste]

Remedier /
11 confiner /
investiguer

Executer l'action
12
choisie

Action controlee
13
sur le service

14 Etat apres action

[Timeout critique]
Confinement de
15
securite

Reduction de
16
l'exposition

Mise a jour des

17
metriques

Timeline et
18
resultat final
[Pas d'alerte exploitable]
Conservation
19
dans les journaux

Figure 2.6: Diagramme de séquence global du traitement d’une alerte SOC/SOAR

2.11 Backlog global et plan de réalisation

Le backlog global synthétise les principales user stories suivies tout au long du projet, de la conception

jusqu’à la supervision.

27
Chapitre 2. Sprint 0 : Cadrage des besoins, architecture cible et choix technologiques

Table 2.11: Backlog global du projet

ID User story Sprint Priorité

US1 Définir le périmètre SOC/SOAR orienté certificats électroniques. Sprint 0 Haute

US2 Concevoir l’architecture et les workflows globaux. Sprint 0 Haute

US3 Déployer la PKI locale et les services HTTPS/OCSP. Sprint 1 Haute

US4 Collecter et normaliser les logs TLS/X.509. Sprint 1 Haute

US5 Détecter S5 avec la règle Wazuh 110113. Sprint 2 Haute

US6 Détecter et corréler S6-S2 avec les règles 110120 et 110115. Sprint 2 Haute

US7 Enrichir les alertes via l’API SOC et MISP. Sprint 2 Haute

US8 Orchestrer la réponse avec Shuffle. Sprint 3 Haute

US9 Exécuter la remédiation ou le confinement contrôlé. Sprint 3 Haute

US10 Superviser les KPI avec Grafana et Prometheus. Sprint 3 Moyenne

2.12 Bilan du sprint

Le Sprint 0 permet de produire une base de référence claire : les besoins sont formalisés, les outils

sont comparés, le périmètre est défini, l’architecture globale est conçue et les scénarios à valider sont

préparés.

2.13 Synthèse du chapitre

Ce sprint prépare la réalisation technique. Les choix d’outils, les diagrammes de conception et le

backlog global servent de base aux sprints suivants.

28
Chapitre 3

Sprint 1 : Déploiement de l’infrastructure

SOC/PKI et collecte TLS/X.509

3.1 Introduction

Le Sprint 1 met en place les fondations techniques de la solution. Il consiste à préparer les machines,

déployer la PKI locale, installer les services HTTPS/OCSP, activer l’analyse TLS/X.509 et configurer

la remontée des événements vers Wazuh.

3.2 Objectifs et livrables attendus

L’objectif est de disposer d’un environnement fonctionnel capable de générer des événements exploi-

tables pour les scénarios liés aux certificats électroniques. À la fin de ce sprint, les services doivent être

accessibles, les certificats doivent pouvoir être émis et révoqués, et les logs TLS doivent être collectés.

29
Chapitre 3. Sprint 1 : Déploiement de l’infrastructure SOC/PKI et collecte TLS/X.509

3.3 Backlog du sprint

Table 3.1: Backlog du Sprint 1

ID Tâche Livrable

S1-T1 Préparer les machines et les adresses IP. Environnement prêt

S1-T2 Installer Docker et les services conteneurisés. Services isolés

S1-T3 Déployer EJBCA CE et créer la CA locale. PKI active

S1-T4 Créer, installer et vérifier les certificats serveurs. Services TLS sécurisés

S1-T5 Installer Zeek et générer les logs TLS/X.509. Logs disponibles

S1-T6 Configurer la remontée vers Wazuh. Alertes préparées

S1-T7 Mettre en place l’inventaire local de confiance. Inventaire JSON

3.4 Architecture technique du laboratoire

Table 3.2: Répartition des composants du Sprint 1

Machine Composants Rôle

soc-certif EJBCA, Ma- Plateforme métier certificats, services HTTPS/OCSP et

riaDB, Nginx, analyse TLS.
Zeek

soc-core Wazuh, Open- Cœur de détection et visualisation sécurité.

Search, Dash-
board, Grafana

soc-ir Shuffle, API SOC, Enrichissement, réponse à incident, CTI et métriques.

MISP, IRIS, Pro-
metheus

Kali/test OpenSSL, SSH, Génération de trafic et validation des scénarios.

scripts de test

30
Chapitre 3. Sprint 1 : Déploiement de l’infrastructure SOC/PKI et collecte TLS/X.509

3.5 Déploiement de la PKI locale avec EJBCA

EJBCA CE est utilisé pour reproduire une PKI locale réaliste. Il permet de créer une autorité de

certification, de définir des profils, d’émettre des certificats serveurs et de révoquer un certificat afin de

valider le scénario S5. La CA locale représente l’autorité attendue pour les services supervisés dans le

laboratoire.
Table 3.3: Processus de création et de déploiement d’un certificat serveur

Étape Action Preuve attendue

1 Créer ou activer la CA locale. CA disponible

2 Définir le profil de certificat serveur. Profil TLS serveur

3 Créer l’End Entity du service. Sujet et SAN enregistrés

4 Générer la clé et la CSR. Fichiers clé/CSR

5 Émettre le certificat depuis EJBCA. Certificat signé

6 Installer le certificat dans Nginx. Configuration TLS

7 Vérifier avec OpenSSL. Subject, issuer, serial vi-

sibles

8 Révoquer un certificat pour S5. Statut révoqué

Insérer ici une capture EJBCA montrant un certificat émis ou révoqué.

Figure 3.1: Certificat émis ou révoqué dans EJBCA

3.6 Services TLS supervisés

Les services retenus sont centrés sur HTTPS/OCSP afin de garder une démonstration claire autour des

certificats électroniques. Chaque service expose un certificat que Zeek peut observer et que Wazuh

peut exploiter après normalisation.

31
Chapitre 3. Sprint 1 : Déploiement de l’infrastructure SOC/PKI et collecte TLS/X.509

Table 3.4: Services TLS supervisés

Service Port Rôle

EJBCA Web 8443 Interface d’administration de la PKI locale.

[Link] 8444 Service HTTPS principal surveillé par la chaîne SOC.

[Link] 8445 Service utilisé pour valider le scénario S5.

Insérer ici une capture OpenSSL montrant le certificat présenté par le service.

Figure 3.2: Vérification TLS d’un service HTTPS/OCSP

3.7 Collecte et normalisation des logs TLS/X.509 avec Zeek

Zeek est utilisé pour observer les connexions TLS et extraire les informations liées aux certificats. Les

fichiers les plus importants sont [Link], [Link] et le fichier normalisé ssl_x509_flat.log.

Ce dernier facilite l’exploitation par Wazuh et l’API SOC.

Table 3.5: Champs TLS/X.509 exploités

Champ Utilité

src_ip / dst_ip Identifier la source et le service cible.

dst_port Déterminer le service TLS concerné.

server_name Identifier le SNI ou le nom logique du service.

cert_subject Identifier le sujet du certificat.

cert_issuer Vérifier l’autorité émettrice.

cert_serial Suivre le certificat et vérifier la révocation.

cert_fingerprint Corréler l’empreinte dans MISP.

cert_status Déterminer si le certificat est valide, révoqué ou suspect.

32
Chapitre 3. Sprint 1 : Déploiement de l’infrastructure SOC/PKI et collecte TLS/X.509

Insérer ici une capture de ssl_x509_flat.log.

Figure 3.3: Log TLS/X.509 normalisé

3.8 Intégration des événements dans Wazuh

Les logs normalisés sont transmis à Wazuh afin d’être analysés par des règles personnalisées. Le rôle

de Wazuh est de transformer l’événement technique en alerte SOC exploitable, avec un identifiant de

règle, une sévérité et des champs utiles pour la suite du workflow.

3.9 Inventaire local de confiance et référentiel attendu

L’inventaire local définit les services attendus, la CA attendue, les certificats valides, les certificats

révoqués et les sources autorisées. Il permet de comparer l’observation TLS réelle avec l’état attendu

du laboratoire.
Table 3.6: Structure logique de l’inventaire local

Élément Description

trusted_local_ca Autorité de certification locale attendue.

trusted_services Liste des services connus : nom, IP, port et rôle.

trusted_certificates Certificats valides autorisés pour les services.

revoked_certificates Numéros de série ou empreintes révoqués.

source_expected Sources autorisées ou attendues selon le service.

33
Chapitre 3. Sprint 1 : Déploiement de l’infrastructure SOC/PKI et collecte TLS/X.509

3.10 Vue d’activité de la collecte TLS/X.509

Diagramme d'activite - Collecte et qualification TLS/X.509

Generer ou observer le trafic TLS/HTTPS

Capturer les logs Zeek [Link] et [Link]

Extraire les champs certificat et connexion

Normaliser les donnees en JSON

Charger l'inventaire de confiance

Oui Non
Service connu ?

Comparer avec les references attendues Classer comme service inconnu

Oui Non
Certificat conforme ?

Conserver l'observation comme trace normale Qualifier l'observation comme anomalie

Ajouter scenario, service, source et empreinte

Transmettre les donnees a Wazuh

Preparer les elements pour la detection

Figure 3.4: Diagramme d’activité de collecte et de qualification initiale des événements TLS/X.509

3.11 Vue de séquence de la collecte TLS/X.509

34
 Diagramme de sequence - Collecte TLS/X.509

Client de test Service TLS Zeek Watcher TLS Inventaire local Wazuh Agent Wazuh Manager

Connexion
1
HTTPS / OCSP

Certificat et
2
handshake TLS

Ecriture [Link] et
3
[Link]

Lecture des logs

4
TLS

Verification CA,
5 serial, fingerprint,
service

References de
6
confiance

alt [Certificat conforme]

Marquer
7 l'evenement
comme normal

[Anomalie TLS/X.509]
Ajouter scenario
8
et statut suspect

Ecrire evenement
9
normalise JSON

Remonter
10 l'evenement
collecte

Decoder et
11 preparer la
correlation

Figure 3.5: Diagramme de séquence de l’observation TLS jusqu’à Wazuh

35
Chapitre 3. Sprint 1 : Déploiement de l’infrastructure SOC/PKI et collecte TLS/X.509

3.12 Bilan du sprint

À la fin du Sprint 1, l’environnement SOC/PKI est prêt. Les services HTTPS/OCSP sont accessibles,

les certificats peuvent être émis ou révoqués, Zeek produit les logs TLS/X.509, Wazuh peut recevoir

les événements et l’inventaire local sert de base à la détection.

3.13 Synthèse du chapitre

Le Sprint 1 fournit les fondations opérationnelles nécessaires à la détection. Le Sprint 2 exploite ces

fondations pour créer les règles Wazuh, enrichir les alertes et valider les scénarios S5 et S6-S2.

36
Chapitre 4

Sprint 2 : Détection, enrichissement et corréla-

tion des scénarios de sécurité

4.1 Introduction

Le Sprint 2 transforme les événements collectés au Sprint 1 en alertes SOC exploitables. À ce niveau,

l’objectif n’est plus seulement de recevoir des logs, mais de comprendre ce qu’ils signifient, d’identifier

les observables importants et de préparer une décision opérationnelle. Les deux scénarios retenus sont

le scénario S5, lié à l’utilisation persistante d’un certificat TLS révoqué, et le scénario S6-S2, qui

combine une phase de brute force SSH avec une anomalie TLS de type certificat non autorisé.

Ce sprint couvre donc la normalisation des logs, les règles Wazuh, l’enrichissement par l’API SOC,

la corrélation dans MISP, la préparation du dossier IRIS et le rattachement aux techniques MITRE

ATT&CK. Les actions de remédiation et de confinement sont détaillées dans le Sprint 3, mais leur

logique est déjà préparée dans ce sprint à travers le score de risque et l’action recommandée.

4.2 Objectifs et livrables attendus

L’objectif du Sprint 2 est de produire des alertes contextualisées et prêtes à être traitées par le workflow

SOAR. Pour chaque scénario, la solution doit identifier le signal déclencheur, extraire les champs utiles,

calculer un niveau de risque, corréler les observables et préparer les informations nécessaires à la

décision analyste.

37
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.3 Backlog du sprint

Table 4.1: Backlog du Sprint 2

ID Tâche Livrable

S2-T1 Normaliser les logs TLS/X.509 et les événements de Événements JSON ex-
sécurité. ploitables

S2-T2 Développer les règles Wazuh associées aux scénarios Alertes 110113, 110115,
retenus. 110120

S2-T3 Valider le scénario S5. Alerte certificat révoqué

S2-T4 Valider le scénario S6-S2. Corrélation SSH brute

force et anomalie TLS

S2-T5 Enrichir les alertes via l’API SOC. Score, résumé, obser-
vables et action recom-
mandée

S2-T6 Corréler les observables dans MISP. Lookup, upsert et occur-

rence count

S2-T7 Préparer les objets IRIS. Case payload, tâches et

timeline

4.4 Chaîne de détection et préparation à l’orchestration SOAR

La détection repose sur une chaîne progressive qui commence par l’observation des événements et se

termine par une alerte prête à être orchestrée. Les journaux sont collectés et normalisés, puis Wazuh

applique les règles personnalisées. Lorsqu’une alerte est générée, Shuffle la reçoit via webhook et

appelle l’API SOC pour produire le résumé, le score de risque, les observables et l’action recommandée.

Cette organisation respecte le rôle de chaque composant : Wazuh détecte, Shuffle orchestre et l’API

SOC enrichit.

38
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

Pipeline de detection, routage et enrichissement SOC

Logs TLS/X.509, SSH et acces

Normalisation JSON locale

Collecte par Wazuh Agent

Reception par Wazuh Manager

Decodage et correlation par regles

Oui Non
Regle declenchee ?

Creer une alerte securite Conserver l'evenement dans OpenSearch

Router l'alerte vers Shuffle

Appeler l'API SOC pour enrichissement

Calculer score, scenario et criticite

Rechercher les observables dans MISP

Creer ou mettre a jour le case IRIS

Preparer la decision analyste

Publier les metriques vers Prometheus/Grafana

Figure 4.1: Pipeline de détection, de routage et d’enrichissement SOC

Cette organisation permet d’éviter une simple accumulation de logs. Chaque alerte devient un objet

structuré qui peut être compris par l’analyste et exploité par Shuffle dans le Sprint 3.

39
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.5 Règles Wazuh et logique d’alerte

Les règles Wazuh retenues correspondent aux signaux principaux des scénarios. Elles sont volon-

tairement peu nombreuses afin de garder une démonstration claire et directement liée aux incidents

étudiés.
Table 4.2: Règles Wazuh principales

Rule ID Scénario Description MITRE

110113 S5 Détection d’un certificat TLS révoqué encore T1649

présenté par un service.

110115 S6-S2 Détection d’un certificat non autorisé, d’un T1557/T1649

issuer inattendu ou d’une rupture de confiance
TLS.

110120 S6-S2 phase SSH Détection de tentatives répétées T1110

d’authentification SSH.

4.6 Scénario S5 : détection d’un certificat TLS révoqué encore

utilisé

4.6.1 Description du scénario

Le scénario S5 représente un cas critique de gestion du cycle de vie des certificats. Le service HTTPS

ou OCSP continue à présenter un certificat qui a déjà été révoqué. Même si le service reste disponible

techniquement, la confiance associée au certificat n’est plus valide. Cette situation peut provenir d’un

oubli de remplacement, d’une mauvaise synchronisation entre l’inventaire et le service, ou d’une erreur

opérationnelle après révocation.

Dans le laboratoire, ce scénario est détecté lorsque le serial ou le fingerprint du certificat présenté

par le service appartient à la liste locale des certificats révoqués. Wazuh déclenche alors la règle 110113.

L’alerte est enrichie par l’API SOC, corrélée avec MISP puis préparée sous forme d’incident dans IRIS.

40
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.6.2 Déroulement du scénario

Table 4.3: Déroulement du scénario S5

Étape Explication

Observation TLS Le service présente un certificat lors d’une connexion TLS.

Extraction X.509 Zeek extrait le sujet, l’issuer, le serial et le fingerprint.

Vérification locale Le serial ou le fingerprint est comparé à la liste des certificats révoqués.

Détection Wazuh La règle 110113 est déclenchée si le certificat est révoqué.

Enrichissement L’API SOC calcule le score, prépare le résumé et identifie les observables.

Corrélation MISP vérifie si le certificat ou le service a déjà été observé.

Préparation IRIS Un incident est préparé avec les tâches de vérification et de réponse.

4.6.3 Observables du scénario

Les observables importants sont l’adresse IP source, l’adresse IP destination, le port du service, le nom

du service, le sujet du certificat, l’issuer, le numéro de série, le fingerprint et la règle Wazuh déclenchée.

Ces éléments permettent de comprendre quel service est concerné, quel certificat pose problème et

quelle action doit être envisagée.

Table 4.4: Éléments techniques du scénario S5

Élément Description

Règle principale 110113

Service observé Service HTTPS ou OCSP supervisé.

Déclencheur Le serial ou fingerprint appartient à la liste des certificats révoqués.

Criticité Élevée à critique selon l’exposition du service et l’historique MISP.

Remédiation attendue Remplacer le certificat révoqué par un certificat valide signé par la CA
attendue.

Confinement possible Isoler ou arrêter temporairement le service si le certificat valide n’est pas
prêt ou si le risque est immédiat.

41
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.6.4 Remédiation et confinement prévus pour S5

La remédiation de S5 consiste à rétablir la conformité du service. Elle s’applique lorsque le certificat

valide est disponible, que le redémarrage du service est acceptable et que l’analyste valide l’action. Elle

comprend la sauvegarde de la configuration, le remplacement du certificat, le redémarrage contrôlé du

service et la vérification avec OpenSSL, Zeek et Wazuh.

Le confinement de S5 est utilisé lorsque la remédiation immédiate n’est pas possible. Dans ce cas,

l’analyste peut décider manuellement d’arrêter le service, de fermer temporairement le port exposé ou

d’isoler le service concerné. Le confinement ne corrige pas la cause de l’incident ; il réduit seulement

l’exposition jusqu’au remplacement du certificat.

Insérer ici la capture Wazuh/OpenSearch de l’alerte 110113.

Figure 4.2: Alerte Wazuh du scénario S5

42
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.7 Vue d’activité du scénario S5

Diagramme d'activite S5 - Certificat revoque encore utilise

Observer un service TLS actif

Collecter le certificat presente

Extraire serial, issuer et fingerprint

Comparer avec la liste des certificats revoques

Oui Non
Certificat revoque ?

Generer l'alerte Wazuh S5 Traiter comme observation normale

Transmettre l'alerte a Shuffle

Enrichir via l'API SOC

Identifier service, port et certificat concerne

Creer ou mettre a jour le dossier IRIS

Envoyer la demande de decision a l'analyste

Oui Non
Certificat valide disponible ?

Appliquer la remediation Appliquer un confinement temporaire

Remplacer le certificat et redemarrer le service Arreter ou isoler le service expose

Verifier avec OpenSSL, Zeek et Wazuh

Documenter le resultat final

Figure 4.3: Diagramme d’activité du scénario S5 : certificat révoqué encore utilisé

43
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.8 Vue de séquence du scénario S5

Diagramme de sequence S5 - Certificat revoque encore utilise

Service TLS Zeek / Watcher Wazuh Shuffle API SOC MISP IRIS
Analyste SOC

Certificat presente
1 pendant le
handshake

Comparaison
2 avec
revoked_certificates

Evenement S5
3
normalise

Regle certificat
4
revoque

5 Alerte S5

6 Enrichir l'alerte

Rechercher serial
7
et fingerprint

8 Resultat CTI

Score, service,
9 action
recommandee

Ouvrir ou mettre a
10
jour le case

Demande de
11
decision

alt [Remediation approuvee]

Valider la
12
remediation

Remplacer
13 certificat et
redemarrer

Action controlee
14
sur le service
[Confinement choisi]
Demander
15
confinement

Arreter ou isoler le
16
service

Reduction de
17
l'exposition

18 Etat apres action

Timeline, preuves
19
et cloture partielle

Figure 4.4: Diagramme de séquence du scénario S5 : certificat révoqué encore utilisé

4.9 Scénario S6-S2 : corrélation SSH brute force et certificat non

autorisé

44
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.9.1 Description du scénario

Le scénario S6-S2 représente une chaîne d’attaque en deux phases. La première phase est une activité de

brute force SSH détectée par la règle Wazuh 110120, ou une compromission SSH renforcée lorsqu’un

accès réussi est observé après plusieurs échecs. Cette phase ne déclenche pas encore une remédiation

certificat ; elle sert surtout à enregistrer dans MISP le contexte SSH : IP source, serveur cible, compte

visé et tracking key. La deuxième phase est une anomalie TLS détectée par la règle 110115. Dans le

laboratoire, elle correspond à l’apparition d’un certificat frauduleux signé par RogueCA-PFE sur le

vrai service HTTPS [Link], alors que l’autorité attendue est ManagementCA.

L’intérêt du scénario n’est donc pas de détecter deux alertes séparées, mais de construire une

corrélation SOC fiable. Lorsque 110115 apparaît, l’API SOC recherche dans MISP la phase SSH

précédente. Si la même IP source, le même serveur cible et le compte SSH sont retrouvés, la chaîne est

considérée comme confirmée. Le score de risque passe alors au niveau critique et le workflow SOAR

prépare une demande d’approbation analyste. En cas de timeout, seule une politique de confinement

limité peut être prévue pour réduire l’exposition, sans remplacer la validation humaine pour les actions

de remédiation complète.

45
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.9.2 Déroulement du scénario

Table 4.5: Déroulement du scénario S6-S2

Étape Explication

Phase SSH Une source effectue plusieurs tentatives d’authentification SSH.

Détection 110120 Wazuh détecte le brute force et crée une première alerte.

Enrichissement phase L’API SOC extrait l’IP source, le compte ciblé et le contexte MITRE T1110.
1

Fenêtre de corrélation La solution surveille l’apparition d’une anomalie TLS associée.

Phase TLS Un certificat non autorisé ou un issuer inattendu est observé.

Détection 110115 Wazuh déclenche l’alerte liée au certificat suspect.

Corrélation S6-S2 Les deux alertes sont liées dans une même chaîne d’incident.

Décision Le risque devient élevé ou critique et nécessite une réponse contrôlée.

4.9.3 Phases et observables

Table 4.6: Phases du scénario S6-S2

Phase Règle Signal MITRE

Phase SSH 110120 Tentatives répétées de connexion SSH depuis T1110

une source suspecte.

Phase TLS 110115 Certificat non autorisé, issuer inattendu ou T1557/T1649

rupture de confiance TLS.

Corrélation Chaîne S6-S2 Association temporelle et logique entre les Chaîne d’at-
alertes SSH et TLS. taque

4.9.4 Remédiation et confinement prévus pour S6-S2

La remédiation de S6-S2 est plus large que celle de S5. Elle ne se limite pas au certificat. Elle doit

aussi traiter la phase SSH. Les actions prévues sont la vérification du compte ciblé, le contrôle de l’IP

source, la restauration du certificat légitime, le redémarrage contrôlé du service et la vérification de

l’absence de nouvelles alertes 110120 et 110115.

46
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

Le confinement de S6-S2 est utilisé lorsque le risque de progression est immédiat. Il peut inclure le

blocage de l’adresse IP source, la désactivation ou la sécurisation du compte ciblé, ainsi que l’isolement

temporaire du service TLS qui présente le certificat suspect. En fonctionnement normal, cette décision

est validée par l’analyste ; en cas de timeout critique, le workflow peut appliquer uniquement un

confinement limité prévu à l’avance afin de réduire l’exposition.

Insérer ici les preuves Wazuh des règles 110120 et 110115.

Figure 4.5: Alertes Wazuh corrélées du scénario S6-S2

47
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.10 Vue d’activité du scénario S6-S2

Diagramme d'activite S6-S2 - SSH suspect puis certificat non autorise

Recevoir des tentatives SSH repetees

Declencher l'alerte Wazuh de brute force SSH

Surveiller le service TLS associe

Observer un certificat presente par le service

Comparer avec la CA et l'inventaire attendus

Oui Non
Certificat non autorise ?

Correlier phase SSH et phase TLS Conserver l'observation sans escalade

Declencher le scenario S6-S2

Enrichir l'alerte avec l'API SOC

Identifier IP source, compte cible et service TLS

Documenter l'incident dans IRIS

Rechercher les observables dans MISP

Oui Non
Risque critique ?

Demander une decision analyste Poursuivre l'investigation controlee

Oui Timeout
Decision recue ?

Executer l'action choisie Bloquer la source et confiner le service

Verifier l'absence de nouvelles alertes

Mettre a jour IRIS, MISP et les metriques

Figure 4.6: Diagramme d’activité du scénario S6-S2 : SSH suspect puis certificat frauduleux

48
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

4.11 Vue de séquence du scénario S6-S2

Diagramme de sequence S6-S2 - SSH suspect et certificat non autorise

SSH Service TLS Zeek / Watcher Wazuh Shuffle API SOC MISP IRIS
Attaquant / test Analyste SOC

Tentatives SSH
1
repetees

2 Logs [Link]

Alerte brute force

3
SSH

Connexion vers
4
service TLS

5 Certificat presente

Evenement
6 certificat non
autorise

Correlation SSH +
7
TLS

8 Alerte S6-S2

Enrichissement
9
scenario

Recherche IP,
10
serial, fingerprint

Historique et
11
correspondances

Elements de case
12
et observables

Score critique et
13
action proposee

Demande de
14
decision

alt [Remediation]
Valider
15
remediation

Bloquer IP,
16 securiser compte,
restaurer certificat
[Confinement]
Valider
17
confinement

Bloquer IP,
18 verrouiller compte,
arreter service
[Timeout critique]
Auto-confinement
19
limite

Action sur source

20
ou compte

Action sur
21 certificat ou
service

Resultat de
22
l'action

Timeline, preuves
23
et statut

Figure 4.7: Diagramme de séquence du scénario S6-S2

4.12 Enrichissement contextuel par l’API SOC

L’API SOC reçoit l’alerte Wazuh et construit un contexte opérationnel. Elle extrait les observables,

calcule un score de risque, détermine le niveau de criticité, interroge MISP, prépare le contenu IRIS et

transmet à Shuffle les éléments nécessaires pour poursuivre le traitement.

49
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

Table 4.7: Sorties principales de l’API SOC

Sortie Utilisation

ai_summary Résumé opérationnel de l’alerte.

risk_score Score de risque permettant la priorisation.

risk_level Niveau : low, medium, high ou critical.

recommended_action Action recommandée : analyse, remédiation ou confinement.

misp_lookup Résultat de recherche ou d’enregistrement des observables.

iris_case_payload Structure préparée pour documenter l’incident.

email_body Contenu de notification pour la décision analyste.

4.13 Matrice de décision et politique de réponse

La recommandation produite par l’API SOC dépend du scénario, du niveau de risque et de la disponibilité

d’une action corrective. Cette matrice ne remplace pas l’analyste. Elle sert à expliquer pourquoi une

remédiation ou un confinement est proposé.

Table 4.8: Matrice de décision des scénarios retenus

Scénario Condition princi- Remédiation proposée Confinement proposé

pale

S5 Certificat révoqué Remplacer le certificat par un Isoler ou arrêter le service si le

encore présenté. certificat valide et redémarrer le certificat valide n’est pas prêt.
service.

S6-S2 Brute force SSH Sécuriser le compte, restaurer le Bloquer la source, sécuriser le
suivi d’un certificat certificat légitime et contrôler les compte ciblé et isoler le service
non autorisé. logs. TLS suspect.

50
Chapitre 4. Sprint 2 : Détection, enrichissement et corrélation des scénarios de sécurité

Insérer ici la réponse JSON de l’endpoint /enrich.

Figure 4.8: Réponse JSON de l’API SOC

4.14 Alignement avec MITRE ATT&CK

Table 4.9: Mapping MITRE ATT&CK des scénarios

Scénario Technique Justification

S5 T1649 Le scénario porte sur l’usage abusif ou persistant d’un

certificat qui ne devrait plus être accepté.

S6-S2 phase SSH T1110 La première phase correspond à des tentatives répétées
d’authentification.

S6-S2 phase TLS T1557/T1649 La deuxième phase traduit une rupture de confiance TLS ou
l’usage d’un certificat non autorisé.

4.15 Bilan du sprint

À la fin du Sprint 2, les scénarios S5 et S6-S2 sont détectés et enrichis. Les alertes contiennent les

observables utiles, le score de risque, le contexte MISP, les informations nécessaires au dossier IRIS et

une recommandation claire pour le Sprint 3. La solution est donc prête pour l’orchestration SOAR, la

décision analyste et la réponse contrôlée.

4.16 Synthèse du chapitre

Ce sprint valide la capacité de détection et d’enrichissement. Le sprint suivant exploite ces alertes pour

organiser la réponse SOC/SOAR, détailler la remédiation, appliquer le confinement manuel lorsque

nécessaire et suivre les indicateurs dans Grafana et Prometheus.

51
Chapitre 5

Sprint 3 : Orchestration SOAR, réponse contrô-

lée et supervision opérationnelle

5.1 Introduction

Le Sprint 3 relie les alertes détectées au Sprint 2 à une réponse opérationnelle contrôlée. Une alerte

SOC ne doit pas rester un simple événement technique : elle doit être documentée, enrichie, priorisée,

soumise à une décision analyste puis suivie jusqu’à la vérification finale. Ce sprint décrit le workflow

Shuffle, l’approbation humaine, l’intégration MISP/IRIS, la remédiation, le confinement manuel, la

réactivation contrôlée et la supervision avec Grafana et Prometheus.

Dans cette version du projet, les actions sensibles ne sont pas exécutées de manière totalement

autonome. Shuffle prépare les informations, standardise les étapes et trace les décisions, mais la

remédiation complète et la réactivation d’un service restent soumises à une validation humaine. Le

seul automatisme prévu concerne un confinement limité après timeout, réservé aux situations critiques

définies par le workflow, afin de réduire l’exposition sans supprimer le contrôle de l’analyste.

5.2 Objectifs et livrables attendus

L’objectif est de mettre en place une réponse SOC/SOAR capable de traiter les scénarios S5 et S6-S2 de

manière claire et traçable. Le workflow doit recevoir l’alerte, enrichir le contexte, proposer une action,

demander une décision analyste, guider la remédiation ou le confinement, puis vérifier le résultat final.

52
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.3 Backlog du sprint

Table 5.1: Backlog du Sprint 3

ID Tâche Livrable

S3-T1 Construire le workflow Shuffle global. Workflow SOAR

S3-T2 Mettre en place l’approbation analyste. Email de décision et bou-

tons d’action

S3-T3 Intégrer MISP pour lookup et upsert. Observables CTI et oc-

currence count

S3-T4 Documenter l’incident dans IRIS. Case, tâches, obser-

vables et timeline

S3-T5 Définir la remédiation pour S5 et S6-S2. Procédures correctives

S3-T6 Définir le confinement manuel et la réactivation contrôlée. Procédures analyste

S3-T7 Exposer les métriques Prometheus. Endpoint /metrics

S3-T8 Créer les dashboards Grafana. KPI SOC/SOAR

5.4 Workflow SOAR global de traitement des incidents

Le workflow SOAR est centré sur Shuffle. Wazuh produit l’alerte, puis Shuffle la reçoit via un webhook.

À partir de cette alerte, Shuffle appelle l’API SOC pour enrichir le contexte et calculer le risque,

interroge ou met à jour MISP pour la corrélation des observables, puis crée ou met à jour le dossier

incident dans IRIS. Une fois ces étapes terminées, Shuffle prépare la demande de décision destinée

à l’analyste et dirige le traitement vers la remédiation, le confinement validé, l’investigation ou la

politique de timeout prévue.

53
Figure 5.1: Workflow SOAR global orchestré par Shuffle

54
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

Le workflow ne remplace pas l’analyste. Il réduit les tâches répétitives, prépare les informations

utiles et évite les oublis. Les actions de remédiation complète restent soumises à validation. Lorsque

l’analyste ne répond pas dans le délai prévu et que le score indique un risque critique, le workflow

peut déclencher un confinement limité, clairement tracé, afin de réduire l’exposition en attendant une

décision ou une investigation complémentaire.

Insérer ici la capture complète du workflow Shuffle : webhook, enrichissement, MISP,

IRIS, email, décision, action et résumé final.

Figure 5.2: Workflow Shuffle de traitement des incidents

5.5 Mécanisme d’approbation analyste et contrôle humain

L’approbation analyste est l’étape centrale de la réponse. L’email de décision contient le scénario, la

règle Wazuh, le score, les observables, le résultat MISP, le service concerné et l’action recommandée.

L’analyste peut approuver la remédiation, décider un confinement, demander une analyse complémentaire

ou laisser l’incident sous surveillance.

55
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

Table 5.2: Décisions possibles dans le workflow SOAR

Décision Effet opérationnel

Approve / remediate Lancer une remédiation contrôlée lorsque la correction est prête et que le
redémarrage est acceptable.

Contain Appliquer un confinement manuel lorsque le risque est immédiat ou que la

remédiation n’est pas disponible.

Investigate Conserver l’incident ouvert pour analyse complémentaire sans action

technique immédiate.

Timeout Appliquer la politique définie par le score de risque. Pour S6-S2, le choix
retenu est un confinement limité : blocage de l’IP source, sécurisation du
compte et arrêt temporaire du service exposé.

Rollback / reactivation Réactiver manuellement un service après correction, tests et validation

analyste.

Insérer ici l’email d’approbation reçu par l’analyste avec le résumé, le score et les
boutons de décision.

Figure 5.3: Email d’approbation analyste

5.6 Vue d’activité de la réponse SOC/SOAR

Le diagramme suivant décrit la logique globale de réponse. Il distingue les chemins principaux :

remédiation approuvée, confinement validé, investigation et confinement limité lorsque l’analyste ne

répond pas avant le timeout alors que le risque est critique.

56
Figure 5.4: Diagramme d’activité de la réponse SOC/SOAR avec timeout automatique

57
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.7 Critères décisionnels entre remédiation et confinement

La remédiation et le confinement n’ont pas le même objectif. La remédiation corrige la cause de

l’incident. Le confinement réduit l’exposition lorsque la correction n’est pas encore possible ou lorsque

le risque est trop élevé. Dans les deux cas, la décision est tracée et validée par l’analyste.
Table 5.3: Critères de choix entre remédiation et confinement

Critère Remédiation Confinement

Objectif Corriger la cause et revenir à un état Réduire rapidement l’exposition.

conforme.

Disponibilité de la correc- Nécessite un certificat valide, une Peut être appliqué même si la correction
tion configuration prête ou une action n’est pas encore prête.
corrective identifiée.

Impact métier Acceptable si le redémarrage ou la Accepté si le risque sécurité est

modification est maîtrisé. supérieur à l’impact d’indisponibilité.

Validation analyste Obligatoire avant remplacement, Obligatoire, car l’action peut bloquer
redémarrage ou modification sensible. une source, un compte ou un service.

Retour en service Après vérification technique. Réactivation manuelle après correction

et tests.

5.8 Remédiation contrôlée

5.8.1 Principe général

La remédiation consiste à corriger la cause de l’incident. Dans ce projet, elle concerne principalement

deux familles d’actions : corriger un problème de certificat et corriger un problème d’accès suspect.

Elle n’est exécutée que si les conditions sont réunies : cause identifiée, correction disponible, impact

acceptable et validation analyste.

58
Figure 5.5: Diagramme d’activité de la remédiation et de ses conditions

59
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.8.2 Remédiation du scénario S5

Pour S5, la cause est la persistance d’un certificat révoqué sur un service TLS. La remédiation consiste

à remplacer ce certificat par un certificat valide signé par l’autorité attendue, puis à vérifier que le

service présente le bon certificat.

Table 5.4: Remédiation du scénario S5

Étape Action Preuve attendue

1 Identifier le service, le port, le serial et le fingerprint du certificat Alerte Wazuh 110113

révoqué.

2 Vérifier le statut du certificat dans EJBCA ou dans l’inventaire local. Capture EJBCA ou inven-
taire

3 Préparer un certificat valide signé par la CA attendue. Certificat valide dispo-

nible

4 Sauvegarder l’ancienne configuration avant modification. Sortie terminal

5 Remplacer le certificat, le fullchain et la clé privée du service. Fichiers mis à jour

6 Redémarrer le service Nginx concerné. Statut service actif

7 Vérifier le nouveau certificat avec OpenSSL, Zeek et Wazuh. Serial et issuer conformes

8 Mettre à jour IRIS, MISP et les métriques. Timeline et dashboard

5.8.3 Remédiation du scénario S6-S2

Pour S6-S2, la remédiation traite une chaîne d’attaque. Elle doit corriger la partie SSH et la partie TLS.

Il ne suffit pas de restaurer le certificat ; il faut aussi vérifier que le compte ciblé par le brute force n’a

pas été compromis et que la source suspecte ne continue pas l’activité.

60
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

Table 5.5: Remédiation du scénario S6-S2

Action Objectif

Vérifier le compte ciblé Confirmer qu’aucun accès non autorisé n’a été obtenu après les tentatives SSH.

Contrôler l’adresse IP Bloquer, surveiller ou qualifier la source selon le niveau de risque.

source

Restaurer le certificat légi- Remplacer le certificat non autorisé par le certificat attendu.
time

Redémarrer le service TLS Appliquer la correction sur le service concerné.

Contrôler les alertes Vérifier l’absence de nouvelles alertes 110120 et 110115 après action.

Documenter la chaîne Conserver le lien entre la phase SSH et la phase TLS dans IRIS et MISP.

5.9 Confinement manuel et maîtrise du risque

5.9.1 Principe général

Le confinement est une action de réduction du risque. Il est utilisé lorsque la remédiation n’est pas

prête, lorsque l’exposition est jugée dangereuse ou lorsque l’analyste veut empêcher la progression

de l’incident. Dans ce projet, le confinement est normalement déclenché par l’analyste via le bouton

Contain. Pour le scénario S6-S2, un confinement limité peut aussi être déclenché après timeout lorsque

le risque est critique. Shuffle prépare le contexte, l’API SOC applique l’action prévue et le résultat est

ensuite vérifié puis documenté dans IRIS.

61
Figure 5.6: Diagramme d’activité du confinement manuel

62
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.9.2 Confinement du scénario S5

Pour S5, le confinement vise à empêcher l’exposition d’un service qui présente un certificat révoqué.

L’analyste peut arrêter le service, fermer temporairement le port ou isoler le conteneur/service concerné.

Le service reste hors exposition jusqu’à ce qu’un certificat conforme soit installé.
Table 5.6: Confinement manuel du scénario S5

Étape Action Preuve attendue

1 Confirmer que l’alerte 110113 concerne un certificat révoqué encore Alerte Wazuh
présenté.

2 Vérifier l’impact du service concerné. Note analyste

3 Décider manuellement le confinement. Décision tracée

4 Arrêter ou isoler le service concerné. Commande exécutée

5 Vérifier que le port n’est plus exposé. Test réseau

6 Documenter l’action dans IRIS et MISP. Timeline et observables

7 Maintenir le confinement jusqu’à remédiation validée. Statut incident

5.9.3 Confinement du scénario S6-S2

Pour S6-S2, le confinement vise plusieurs éléments en même temps. La source SSH est bloquée par

une règle iptables, le compte ciblé pfeadmin est verrouillé et retiré du contexte d’exécution, puis le

service TLS suspect nginx-demo est arrêté. Cette approche limite immédiatement la progression de la

chaîne d’attaque. Elle a été validée dans le laboratoire par la présence d’une règle DROP sur l’IP source,

le statut verrouillé du compte et l’état exited du conteneur.

63
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

Table 5.7: Confinement manuel du scénario S6-S2

Action Objectif

Blocage de l’IP source Empêcher la poursuite des tentatives SSH ou des connexions suspectes.

Sécurisation du compte ci- Réduire le risque lié au compte visé par le brute force.
blé

Isolement du service TLS Éviter l’exposition d’un service présentant un certificat non autorisé.
suspect

Contrôle des logs après ac- Vérifier l’arrêt des tentatives et l’absence de nouvelle anomalie TLS.
tion

Documentation de la Garder le lien entre 110120 et 110115 dans le dossier incident.

chaîne

5.10 Réactivation contrôlée du service

La réactivation d’un service confiné ne doit pas être automatique. Elle intervient uniquement après

correction de la cause, installation d’un certificat conforme, réussite des tests TLS, absence de nouvelles

alertes et validation analyste. Cette étape protège le laboratoire contre une remise en ligne prématurée

d’un service encore non conforme.

64
Figure 5.7: Diagramme d’activité de la réactivation manuelle du service

65
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.11 Synthèse opérationnelle par scénario

Table 5.8: Synthèse des actions de réponse par scénario

Scénario Remédiation Confinement

S5 Remplacer le certificat révoqué, redémarrer Arrêter ou isoler temporairement le service

le service et vérifier le certificat présenté. jusqu’à disponibilité d’un certificat valide.

S6-S2 Bloquer l’IP source, confiner le compte SSH, Bloquer l’IP source, verrouiller pfeadmin,
restaurer le certificat légitime retirer les privilèges et arrêter nginx-demo.
ManagementCA et redémarrer nginx-demo.

5.12 Intégration CTI avec MISP

MISP est utilisé comme mémoire CTI interne. Le workflow recherche les observables existants et crée

ou met à jour un événement lorsque nécessaire. Le suivi des occurrences permet de savoir si un serial,

un fingerprint ou une IP a déjà été observé.

Table 5.9: Observables enregistrés dans MISP

Observable Utilité

ip-src Source de l’alerte ou de la tentative d’accès.

ip-dst Service cible ou serveur supervisé.

domain Nom de service ou SNI observé.

text Serial, tracking key ou contexte technique.

sha256 Empreinte de certificat lorsque disponible.

Insérer ici la capture de l’événement MISP.

Figure 5.8: Événement MISP et observables associés

66
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.13 Documentation et suivi d’incident avec IRIS

IRIS est utilisé pour documenter l’incident. Le case regroupe le résumé, les actifs, les observables, les

tâches, la timeline et le résultat final. Cette documentation permet de transformer une alerte technique

en dossier structuré.
Table 5.10: Éléments documentés dans IRIS

Élément Contenu

Résumé Description claire de l’incident, du scénario et de l’impact.

Actifs Service, serveur, port et environnement.

Observables IP, domaine, serial, fingerprint, issuer et rule ID.

Tâches Vérification, décision, remédiation, confinement et contrôle final.

Timeline Détection, enrichissement, décision, action et clôture.

Insérer ici la capture du case IRIS final.

Figure 5.9: Case IRIS de l’incident

5.14 Supervision opérationnelle avec Grafana et Prometheus

Prometheus collecte les métriques exposées par l’API SOC et les workflows. Grafana centralise ces

données dans des dashboards permettant de suivre les alertes, les décisions, les actions et les erreurs.

67
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

Table 5.11: Métriques Prometheus proposées

Métrique Signification

soc_enrich_total Nombre d’alertes enrichies.

soc_approval_created_total Nombre de demandes d’approbation créées.

soc_remediation_success_total Nombre de remédiations réussies.

soc_containment_manual_total Nombre de confinements manuels documentés.

soc_misp_lookup_total Nombre de recherches MISP effectuées.

soc_iris_case_created_total Nombre de cases IRIS créés.

soc_api_errors_total Nombre d’erreurs API observées.

soc_api_response_time_secondsTemps de réponse de l’API SOC.

Insérer ici le dashboard Grafana SOC/SOAR.

Figure 5.10: Dashboard Grafana SOC/SOAR

68
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.15 Vue de séquence de la réponse contrôlée

Diagramme de sequence - Reponse SOC/SOAR

Wazuh Shuffle API SOC MISP IRIS Service concerne Grafana

Analyste SOC

1 Alerte securite

Enrichissement et
2
recommandation

Recherche / ajout
3
observables

4 Resultat CTI

Creation ou mise
5
a jour case

6 Contexte complet

7 Email de decision

alt [Decision recue]

8 Action choisie

Demande
9
d'execution

Remediation ou
10
confinement

11 Statut technique
[Timeout critique]
Confinement
12
automatique limite

Action de
13 reduction du
risque

14 Statut technique

15 Rapport d'action

Ajouter preuve et
16
timeline

Envoyer
17 metriques
SOC/SOAR

Figure 5.11: Diagramme de séquence de la réponse SOC/SOAR contrôlée

69
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

5.16 Validation opérationnelle de bout en bout

Table 5.12: Matrice de validation de bout en bout

Étape Vérification Statut

Détection Les règles 110113, 110115 et 110120 apparaissent À valider

correctement dans Wazuh.

Enrichissement L’API retourne le résumé, le score, MISP lookup et l’action À valider

recommandée.

MISP Les observables sont recherchés ou enregistrés correctement. À valider

IRIS Le case contient les tâches, observables et timeline. À valider

SOAR La décision analyste oriente vers la bonne branche. À valider

Remédiation Le service revient à un état conforme après action. À valider

Confinement Le service ou la source est isolé après décision manuelle. À valider

Monitoring Les métriques apparaissent dans Prometheus et Grafana. À valider

5.17 Bilan du sprint

À la fin du Sprint 3, la chaîne SOC/SOAR est complète. Elle ne se limite pas à la détection : elle

enrichit les alertes, les corrèle, les documente, demande une décision analyste, guide la remédiation ou

le confinement manuel, vérifie les résultats et expose les KPI.

5.18 Synthèse du chapitre

Ce sprint valide la valeur opérationnelle de la solution. Les scénarios S5 et S6-S2 sont traités selon une

logique claire : détection, enrichissement, décision, réponse, vérification et supervision. La remédiation

complète et la réactivation restent validées par l’analyste, tandis que le confinement limité après timeout

n’est utilisé que pour réduire rapidement l’exposition dans les cas critiques.

70
Conclusion générale

Ce projet de fin d’études a permis de concevoir une chaîne SOC/SOAR open-source orientée certificats

électroniques. Le travail réalisé couvre la mise en place d’une PKI locale, le déploiement de services

TLS HTTPS/OCSP, la collecte et la normalisation des logs, la détection Wazuh, l’enrichissement

par API, la corrélation MISP, la documentation d’incident dans IRIS, l’orchestration Shuffle et la

supervision avec Grafana/Prometheus.

La démarche par sprints a permis d’avancer progressivement. Le Sprint 0 a clarifié les besoins, les

choix techniques et l’architecture globale. Le Sprint 1 a posé les fondations techniques avec la PKI, les

services TLS et la collecte des logs. Le Sprint 2 a validé la détection et l’enrichissement des scénarios

S5 et S6-S2. Le Sprint 3 a relié la détection à la réponse SOC/SOAR, en distinguant clairement la

remédiation, le confinement manuel, la réactivation contrôlée et le monitoring.

Le scénario S5 a démontré la capacité de la chaîne à détecter un certificat TLS révoqué encore

utilisé, puis à proposer une action de remédiation ou de confinement selon les conditions observées. Le

scénario S6-S2 a permis de montrer l’intérêt de la corrélation entre une alerte SSH brute force et une

anomalie TLS, afin de produire une analyse plus riche qu’une alerte isolée.

La valeur ajoutée principale du projet réside dans l’intégration de plusieurs briques SOC : collecte,

détection, enrichissement, CTI, gestion d’incident, décision analyste, réponse contrôlée et supervision.

Le choix de garder la remédiation complète et la réactivation du service sous responsabilité de l’analyste,

tout en prévoyant un confinement limité dans les situations critiques de timeout, permet de concilier

automatisation, sécurité et maîtrise opérationnelle.

71
Chapitre 5. Sprint 3 : Orchestration SOAR, réponse contrôlée et supervision opérationnelle

Les perspectives d’amélioration concernent l’ajout de nouveaux scénarios, l’automatisation plus

avancée des contrôles CRL/OCSP, l’amélioration du scoring, le renforcement de la gestion des secrets

API, l’automatisation assistée du rollback après validation analyste et l’extension de la solution à

d’autres périmètres ou tenants.

En conclusion, la solution proposée constitue une base opérationnelle pour l’automatisation des

opérations SOC et de la réponse aux incidents cyber, avec une spécialisation concrète autour des

certificats électroniques et de la gestion contrôlée des services TLS.

72
Chapitre A

Commandes de validation

A.1 Vérification du certificat présenté par le service

openssl s_client -tls1_2 \

-connect [Link]:8445 \
-servername [Link] </dev/null

A.2 Vérification des logs Zeek

cd /opt/zeek/logs/current
cat [Link] | tail
cat [Link] | tail
cat ssl_x509_flat.log | tail

A.3 Recherche des alertes Wazuh

curl -k -u admin:password \
"[Link] \
-H ’Content-Type: application/json’ \
-d ’{"query":{"terms":{"[Link]":["110113","110115","110120"]}},"size":10}’

A.4 Test de l’API SOC

73
Annexe A. Commandes de validation

curl -X POST [Link] \

-H ’Content-Type: application/json’ \
-d @alert_s5.json

A.5 Remédiation contrôlée

# Dry-run avant modification reelle

sudo /usr/local/sbin/remediate_s5_ocsp.sh --dry-run

# Remplacement du certificat apres validation analyste

sudo /usr/local/sbin/remediate_s5_ocsp.sh

A.6 Confinement manuel et réactivation

# Le confinement est decide et execute par l’analyste

sudo /usr/local/sbin/contain_s5_ocsp.sh --dry-run
sudo /usr/local/sbin/contain_s5_ocsp.sh

# La reactivation n’est pas automatique : elle se fait apres correction

# et verification du certificat attendu.
sudo systemctl status nginx
sudo systemctl restart nginx

74
Chapitre B

Règles Wazuh principales

B.1 Synthèse des règles

Table B.1: Règles Wazuh utilisées dans le périmètre du rapport

Rule ID Description MITRE Usage

110113 Certificat TLS révoqué encore utilisé. T1649 Scénario S5.

110115 Certificat non autorisé ou issuer non T1557/T1649 Phase TLS S6-S2.
attendu.

110120 Tentatives répétées d’authentification SSH. T1110 Phase SSH S6-S2.

B.2 Exemple de règle S5

<rule id="110113" level="14">

<decoded_as>json</decoded_as>
<field name="cert_status">revoked</field>
<description>[S5] Certificat TLS revoque encore utilise</description>
<mitre>
<id>T1649</id>
</mitre>
<group>pfe,soc,tls,certificate,revoked</group>
</rule>

75
Chapitre C

Extraits de l’API SOC

C.1 Structure de réponse simplifiée

{
"scenario": "S5_CERTIFICATE_REVOKED",
"rule_id": "110113",
"risk_score": 92,
"risk_level": "critical",
"recommended_action": "approval_required_remediation",
"observables": {
"src_ip": "[Link]",
"dst_ip": "[Link]",
"dst_port": 8445,
"cert_serial": "SERIAL_HERE",
"cert_fingerprint": "FINGERPRINT_HERE"
},
"misp_lookup": {
"status": "updated_tracking_event",
"occurrence_count": 2
},
"iris_case_payload": {
"title": "S5 - Certificat TLS revoque encore utilise",
"severity": "critical"
}
}

76
Annexe C. Extraits de l’API SOC

C.2 Logique de routage simplifiée

rule_id = [Link]("rule", {}).get("id")

if rule_id == "110113":
scenario = "S5_CERTIFICATE_REVOKED"
action = "approval_required"
elif rule_id == "110120":
scenario = "S6S2_PHASE1_SSH_BRUTE_FORCE"
action = "track_and_correlate"
elif rule_id == "110115":
scenario = "S6S2_PHASE2_ROGUE_CERTIFICATE"
action = "approval_required"
else:
scenario = "UNKNOWN"
action = "log_only"

77
Chapitre D

Workflows Shuffle

D.1 Workflow S5

Le workflow S5 suit la logique suivante : webhook Wazuh, enrichissement API, lookup MISP,

préparation IRIS, email de décision, branche de remédiation ou de confinement, contrôle post-action et

mise à jour des métriques. Le confinement reste manuel afin de préserver la maîtrise opérationnelle du

service.

Insérer ici la capture du workflow Shuffle S5.

Figure D.1: Workflow Shuffle du scénario S5

D.2 Workflow S6-S2

Le workflow S6-S2 ajoute une étape de corrélation entre la phase SSH brute force et la phase TLS.

Lorsque les deux alertes sont observées dans une fenêtre cohérente, le niveau de risque est augmenté et

une réponse contrôlée est proposée. La remédiation peut restaurer le certificat légitime, tandis que le

confinement manuel peut bloquer la source, sécuriser le compte ciblé ou isoler le service TLS suspect.

78
Annexe D. Workflows Shuffle

Insérer ici la capture du workflow Shuffle S6-S2.

Figure D.2: Workflow Shuffle du scénario S6-S2

D.3 Workflow de retour en service

La réactivation d’un service confiné n’est pas lancée automatiquement par le workflow. Elle est réalisée

après vérification du certificat, absence de nouvelle alerte et validation analyste. Cette étape garantit

que le service ne revient pas en production avec un certificat encore révoqué ou non autorisé.

Insérer ici la capture ou la procédure de retour en service.

Figure D.3: Workflow de réactivation manuelle du service

79
Chapitre E

Preuves du scénario S5

Cette annexe regroupe les captures associées au scénario S5. Elle sert de support de preuve pour

le traitement d’un certificat TLS révoqué encore présenté par un service supervisé. Les éléments

sont organisés selon la logique opérationnelle suivante : ouverture du dossier incident, analyse des

observables, suivi des actions et supervision finale.

E.1 Chaîne de traitement S5

Le scénario S5 démarre lorsqu’un service TLS supervisé continue de présenter un certificat identifié

comme révoqué. La preuve technique est construite en quatre temps : vérifier le certificat exposé,

contrôler les champs X.509, consulter les logs Zeek puis retrouver l’alerte Wazuh 110113.

# 1. Verification du certificat presente par le service OCSP/HTTPS

openssl s_client -tls1_2 \
-connect [Link]:8445 \
-servername [Link] </dev/null

# 2. Controle des informations X.509 extraites

openssl x509 -in [Link] -noout \
-subject -issuer -serial -fingerprint -dates

# 3. Verification des logs produits par Zeek

cd /opt/zeek/logs/current
cat [Link] | tail

80
Annexe E. Preuves du scénario S5

cat [Link] | tail

cat ssl_x509_flat.log | tail

# 4. Recherche de l’alerte S5 cote Wazuh

curl -k -u admin:password \
"[Link] \
-H ’Content-Type: application/json’ \
-d ’{"query":{"term":{"[Link]":"110113"}},"size":5}’

E.2 Mail d’approbation et décision analyste

Après enrichissement, Shuffle prépare une demande d’approbation destinée à l’analyste SOC. Le mail

résume le risque, le service touché et l’action proposée. Il ne déclenche pas directement une action

sensible : la remédiation reste conditionnée par une décision explicite.

Table E.1: Contenu fonctionnel du mail d’approbation S5

Champ Valeur attendue

Objet [S5][Critique] Certificat TLS révoqué encore utilisé

Scénario S5 - certificat TLS révoqué encore présenté par le service

Règle Wazuh 110113

Service concerné [Link]

Risque Niveau critique, car le service expose un certificat non conforme

Action recommandée Remédiation contrôlée après validation analyste

Boutons de décision Approve / Remediate, Contain, Investigate

Dans le cas traité, la capture du résultat opérationnel montre la décision remédiation approuvée.

Elle prouve le passage vers une correction contrôlée. Si le certificat de remplacement n’est pas prêt,

l’analyste peut choisir le confinement temporaire du service.

81
Annexe E. Preuves du scénario S5

E.3 Certificat du service et changement après remédiation

Le changement principal concerne le certificat présenté par le service supervisé. Avant correction, le

service expose un certificat signalé comme révoqué. Après remédiation, le service doit présenter un

certificat valide, signé par l’autorité attendue et cohérent avec le nom de service.
Table E.2: Évolution attendue du certificat du service S5

Élément Avant remédiation Après remédiation

Service [Link] [Link]

Statut certificat Révoqué ou non conforme selon Valide et conforme à l’autorité attendue
l’inventaire de confiance

Issuer Autorité détectée dans l’alerte S5 Autorité attendue par l’inventaire local

Serial / fingerprint Observables enregistrés dans DFIR-IRIS Nouveaux observables contrôlés après
et MISP remplacement

Action SOC/SOAR Alerte critique, création du case, demande Mise à jour du case, fermeture contrôlée
d’approbation ou passage en surveillance

Preuve attendue Alerte Wazuh 110113 et résultat OpenSSL Résultat OpenSSL post-remédiation et
initial absence de nouvelle alerte 110113

# Remediation controlee apres approbation analyste

sudo /usr/local/sbin/remediate_s5_ocsp.sh --dry-run
sudo /usr/local/sbin/remediate_s5_ocsp.sh

# Verification post-remediation
openssl s_client -tls1_2 \
-connect [Link]:8445 \
-servername [Link] </dev/null

# Controle que l’alerte S5 ne se reproduit plus

curl -k -u admin:password \
"[Link] \
-H ’Content-Type: application/json’ \
-d ’{"query":{"term":{"[Link]":"110113"}},"size":5}’

82
Annexe E. Preuves du scénario S5

E.4 Dossier incident et investigation

E.5 Observables, IOC et tâches

E.6 Validation technique et supervision

83
Annexe E. Preuves du scénario S5

Figure E.1: Scénario S5 : vue générale du dossier incident dans DFIR-IRIS

84
Annexe E. Preuves du scénario S5

Figure E.2: Scénario S5 : informations détaillées du dossier incident

85
Annexe E. Preuves du scénario S5

Figure E.3: Scénario S5 : champs techniques associés à l’alerte

86
Annexe E. Preuves du scénario S5

Figure E.4: Scénario S5 : synthèse de l’investigation et des éléments certificat

87
Annexe E. Preuves du scénario S5

Figure E.5: Scénario S5 : approbation analyste, remédiation approuvée et résultat opérationnel

88
Annexe E. Preuves du scénario S5

Figure E.6: Scénario S5 : actifs et observables rattachés au dossier

89
Annexe E. Preuves du scénario S5

Figure E.7: Scénario S5 : IOC enregistrés pour le suivi de l’incident

90
Annexe E. Preuves du scénario S5

Figure E.8: Scénario S5 : tâches de traitement et de validation

91
Annexe E. Preuves du scénario S5

Figure E.9: Scénario S5 : commande OpenSSL et preuve du certificat présenté par le service

92
Annexe E. Preuves du scénario S5

Figure E.10: Scénario S5 : dashboard Grafana de suivi des indicateurs de performance

93
Annexe E. Preuves du scénario S5

Figure E.11: Scénario S5 : dashboard Grafana de suivi des certificats et alertes

94
Annexe E. Preuves du scénario S5

Figure E.12: Scénario S5 : dashboard Grafana de suivi de l’orchestration SOC/SOAR

95
Chapitre F

Bibliographie et webographie

96
Bibliographie

[1] Wazuh Documentation, règles, décodage et alerting SIEM. Disponible sur : https://

[Link]/

[2] Zeek Documentation, logs SSL/TLS et X.509. Disponible sur : [Link]

[3] Shuffle Documentation, orchestration SOAR et workflows. Disponible sur : [Link]

io/docs/

[4] MISP Project Documentation, gestion des observables et CTI. Disponible sur : [Link]

[Link]/documentation/

[5] DFIR-IRIS Documentation, incident response case management. Disponible sur : https://

[Link]/

[6] EJBCA Community Documentation, PKI et certificats X.509. Disponible sur : [Link]

[Link]/ejbca/

[7] MITRE ATT&CK, techniques T1110, T1557 et T1649. Disponible sur : [Link]

[Link]/

[8] DigiCert Trust Lifecycle Manager, gestion du cycle de vie des certificats. Disponible sur :

[Link]

[9] CyberArk Certificate Manager, gestion et automatisation des certificats. Disponible sur : https:

//[Link]/products/certificate-manager/

97
Bibliographie

[10] Keyfactor Command, PKI and machine identity automation. Disponible sur : [Link]

[Link]/products/command/

[11] AppViewX AVX CLM, certificate lifecycle management. Disponible sur : [Link]

[Link]/solutions/certificate-lifecycle-management/

98